Study, design and development of an integration component with sensory features of objects through IoT middleware

Study, design and development
of an integration component
with sensory features of objects
through IoT middleware
José Miguel da Silva Fidalgo
josemsf@student.dei.uc.pt
Supervisor (DEI): Examination jury (DEI):
Tiago Cruz Vasco Pereira
César Teixeira
Supervisor (Flor de Utopia):
Hélio Palaio
Date: 01 September 2015
Master’s Degree in Computer Engineering 2014/2015
Internship
Final Report

Study, design and development of an integration component
with sensory features of objects through IoT middleware
iii
Resumo
A expressão "Internet das Coisas" foi pela primeira vez usada por Kevin Ashton em 1999 para
descrever um conceito em que objectos físicos estão ligados à Internet, com capacidade de
comunicar e de se identificarem. A infra-estrutura existente da Internet já interliga milhares de
milhões de dispositivos a nível global, oferecendo acesso a um vasto leque de conteúdos e
serviços em qualquer lugar, amplificado pela adopção massiva de telemóveis com ligação à
Internet. O número de objectos conectados que agem como sensores/actuadores também
tem vindo a aumentar, fazendo da Internet das Coisas uma realidade actual.
A disponibilidade generalizada destes objectos com conectividade (objectos inteligentes)
constitui uma fonte de informação potencialmente enorme ou até mesmo um meio de
controlar algo remotamente, possibilitando aplicações inovadoras. Uma possível abordagem
para integrar estes objectos e expô-los como serviços na Internet é através da utilização de
uma plataforma de middleware.
O objectivo deste projecto foi desenvolver uma plataforma de irrigação inteligente com
suporte de sensores e actuadores, alavancando-se num middleware IoT já existente. A
plataforma usa fontes de informação complementares de serviços de previsão meteorológica,
e expõe as suas funcionalidades através de um serviço de forma a permitir acesso remoto.
Palavras-Chave
“Internet das Coisas”, “Middleware”, “Máquina-a-Máquina”, “Redes de Sensores”, “Internet de Serviços”,
“Arquitectura Orientada a Serviços”, “Sistemas Ciber-Físicos”, “Computação Ubíqua”, “Domótica”,
“Sistemas Informáticos Incorporados”, “Irrigação Inteligente”, “Objectos Inteligentes”

i
Abstract
The expression “Internet of Things” was first used by Kevin Ashton in 1999 to describe a
concept in which physical objects are connected to the Internet, being able to communicate
and identify themselves. The existing Internet infrastructure already interconnects billions of
devices worldwide, providing access to a multitude of content and services everywhere,
amplified by massive adoption of mobile phones with internet connectivity. The number of
connected objects acting as sensors/actuators is also increasing, making the Internet of Things
(IoT) a reality nowadays.
The widespread availability of these objects with connectivity (smart objects) constitutes a
potentially huge source of information and even a means of remotely controlling something,
enabling novel applications. One of the possible approaches to integrate these objects and
expose them as services on the Internet is through the use of a middleware platform.
The goal of this project was to develop a smart irrigation platform supporting sensors and
actuators leveraging on an existing IoT middleware. The platform also uses complementary
information sources from weather forecast services and it exposes its functionalities through
a service for remote access.
Keywords
“Internet of Things”, “Middleware”, “Machine-to-Machine”, “Sensor Networks”, “Internet of Services”,
“Service Oriented Architectute”, “Cyber-physical Systems”, “Ubiquitous Computing”, “Domotics”,
“Embedded Computing”, “Smart Irrigation”, “Smart Objects”

v
Acknowledgments
First, I would like to express my gratitude to my supervisors, Tiago Cruz and Hélio Palaio.,
for the time they spent and their support. Without them this project would not have
materialized.
I also express my gratitude to the company Flor de Utopia for creating this opportunity and
for helping me devise an alternative plan for the project when the initial one didn’t go forward.
This gratitude extends to all members of the team, in particular to Nuno Borges who was
more involved in supporting this project.
I also appreciate the contribution of the members of the jury, Vasco Pereira and César
Teixeira, whose feedback helped me to focus on the direction of this project and to improve
its quality.
I would also like to send a big thank you to my friends who accompanied me through these
two years of the Master’s Degree – lots of work and also some fun…
And last, but not the least, I would like to thank my family for their support, in particular my
wife and my parents, and also my daughter for letting me work (most of the time).

vii
Table of Contents
Chapter 1. Introduction ......................................................................................................................1
1.1. Project background.................................................................................................................................1
1.2. Motivation ................................................................................................................................................4
1.3. Goals .........................................................................................................................................................5
1.4. Document structure................................................................................................................................6
Chapter 2. State of the Art..................................................................................................................7
2.1. Architectures............................................................................................................................................8
2.1.1. IoT-A Architecture Reference Model ...................................................................................................... 8
2.1.2. SENSEI Real World Internet Architecture...........................................................................................11
2.2. Middleware.............................................................................................................................................13
2.2.1. OpenIoT.....................................................................................................................................................14
2.2.2. BUTLER....................................................................................................................................................16
2.2.3. IoTCloud....................................................................................................................................................18
2.2.4. IoT@Work.................................................................................................................................................19
2.2.5. LinkSmart / Hydra.................................................................................................................................... 21
2.2.6. Freedomotic............................................................................................................................................... 22
2.2.7. Middleware – final analysis and selection...............................................................................................24
2.3. Commercial Products ...........................................................................................................................26
2.3.1. BlueSpray....................................................................................................................................................26
2.3.2. GreenIQ.....................................................................................................................................................26
2.3.3. Iro................................................................................................................................................................27
2.3.4. IrrigationCaddy.......................................................................................................................................... 27
2.3.5. netAQUA...................................................................................................................................................27
2.3.6. RainMachine .............................................................................................................................................. 28
2.3.7. Skydrop.......................................................................................................................................................28
2.3.8. Ugmo ..........................................................................................................................................................28
2.3.9. Products – summary and comparison.................................................................................................... 29
Chapter 3. Project Approach........................................................................................................... 31
3.1. Methodologies .......................................................................................................................................31

viii
3.2. Tools........................................................................................................................................................33
3.3. Planning ..................................................................................................................................................33
3.4. Requirements .........................................................................................................................................35
3.4.1. User interface.............................................................................................................................................36
3.4.2. Functional requirements...........................................................................................................................36
3.4.3. Non-functional requirements ..................................................................................................................40
3.5. Risks ........................................................................................................................................................41
Chapter 4. Work performed and Results....................................................................................... 43
4.1. Introduction...........................................................................................................................................43
4.2. Testing the middleware ........................................................................................................................44
4.3. Global architecture and mode of operation......................................................................................44
4.4. Development .........................................................................................................................................46
4.4.1. Analysis, tests and bug fixing in Freedomotic.......................................................................................47
4.4.2. Required objects........................................................................................................................................ 47
4.4.3. Required devices/services plugins .......................................................................................................... 50
4.5. Tests and verification of requirements ..............................................................................................60
4.6. Summary.................................................................................................................................................62
Chapter 5. Conclusions.................................................................................................................... 65
References.......................................................................................................................................... 67

ix
List of Figures
Figure 1: interaction of all sub-models in IoT-A Reference Model [12]......................................9
Figure 2: Functional view of IoT-A [12]. ...................................................................................... 10
Figure 3: High level overview of the SENSEI Architecture and core concepts [14]. ............ 11
Figure 4: OpenIoT Architecture [21]............................................................................................. 15
Figure 5: BUTLER Architectural Layering [23]. .......................................................................... 17
Figure 6: IoTCloud Architecture overview [25]. .......................................................................... 18
Figure 7: IoT@Work Architecture Functional Layers [28]. ....................................................... 20
Figure 8: Structural overview of the LinkSmart middleware layers [32]................................... 22
Figure 9: Freedomotic Architecture [34]. ...................................................................................... 23
Figure 10: Scrum process [36]......................................................................................................... 31
Figure 11: Planning for the first semester. .................................................................................... 33
Figure 12: Planning for the second semester................................................................................ 33
Figure 13: Final schedule for the second semester ...................................................................... 34
Figure 14: Representation of a device in a generic IoT system.................................................. 43
Figure 15: Interactions in Freedomotic, from Freedomotic components interaction in the
Freedomotic Wiki [33]...................................................................................................................... 46
Figure 16: Lifecycle of a plugin, showing both polling and push modes of operation. ......... 50
Figure 17: IH300 USB hub from Oregon Scientific I300 weather station............................... 51
Figure 18: Initialization of the IH300 hub captured by USBTrace. .......................................... 52
Figure 19: Example of a capture of all data transmitted for a temperature measurement..... 52
Figure 20: CRC functions in WeatherOS.exe, disassembled and converted into C code...... 53
Figure 21: Analogy of the MockValve plugin and the respective physical devices/plugins.. 58
Figure 22: Freedomotic Java frontend during a test performed. ............................................... 61
Figure 23: Potential outcomes and problems in irrigation systems........................................... 62

x
List of Tables
Table 1: IoT middleware comparison in Bandyopadhyay et al. [15]. ........................................ 13
Table 2: Comparison of features of commercial products. ........................................................ 29

xi
Acronyms
Acronym Description
API Application Programming Interface
ARM Architecture Reference Model (in the context of IoT-A)
CRC Cyclic Redundancy Check
ERP Enterprise Resource Planning
EU European Union
FP7 European Union’s Seventh Framework Programme for Research
GPS Global Positioning System
HID Human Interface Device (USB specification)
HTTP HyperText Transfer Protocol
ICT Information and Communications Technology
IoT Internet of Things
IoT-A Internet of Things – Architecture
IP Internet Protocol
JMS Java Message Service
JNA Java Native Access
JSON JavaScript Object Notation
MAC Media Access Control (network layer)
MoSCoW “Must, Should, Could, Won’t”
NFC Near Field Communication
OWL Web Ontology Language
RDF Resource Description Framework
REST REpresentational State Transfer
RFID Radio-Frequency Identification
SCADA Supervisory Control And Data Acquisition
SOA Service Oriented Architecture

xii
SOAP Simple Object Access Protocol
SPARQL SPARQL Protocol and RDF Query Language
SSID Service Set Identifier (WiFi networks)
URI Uniform Resource Identifier
URL Uniform Resource Locator
USB Universal Serial Bus
W3C World Wide Web Consortium
WSAN Wireless Sensor/Actuator Network
WSN Wireless Sensor Network
XML eXtensible Markup Language
XOR eXclusive Or (logical operation)

1
Chapter 1.
Introduction
This document describes the work performed at Flor de Utopia, Sistemas de Informação e
Multimédia, Lda. under the internship of the Master in Computer Engineering, from the
Faculty of Sciences and Technology of the University of Coimbra (FCTUC). The supervision
was conducted by Hélio Palaio from Flor de Utopia and Professor Tiago Cruz from FCTUC.
Flor de Utopia was founded in 2001 as a spinoff of Instituto Pedro Nunes and FCTUC. The
company dedicates to the design, development, production and edition of software, having
the know-how to engage in advanced techniques in the fields of Information Systems,
Internet, Multimedia and Artificial Intelligence. Having worked in several areas, it always
strives to maintain a high quality standard in the developed software.
This project’s goal was to create a platform – a smart irrigation system targeted for home use
– supported by an existing Internet of Things (IoT) middleware for connection to sensors and
actuators, using those devices to gather information and perform actions, and online services
(weather forecast) to collect additional data. Remote access to the platform (in addition to
local) for interaction with users or other services was also a requirement.
1.1. Project background
The theme of this project is related to the “Internet of Things”, a concept often regarded as
an evolution of the current Internet (the “future Internet”) and closely associated with
expressions such as “Ubiquitous Computing” or “Ambient Intelligence” [1]. The vision of the
“Internet of Things” involves everyday objects (the “things”) becoming connected to the
Internet. These things then become “smart” as they provide a unique identification, position
and status, eventually exposing services for remote sensing and control and even incorporating
their own processing capabilities (“intelligence”) [1], [2].
These objects can then be considered to become part of the Mark Weiser’s “Ubiquitous
Computing” [3] and also fulfil the meaning of the expression “Internet of Things”, coined by
Kevin Ashton in 1999 [4]. In the opening of IoT Week 2013 Ashton stated that “IoT is here
now; it is not the future but the present” [5, pp. 1–10].
The Internet of Things “is here now” because many of the technological advances on which
it relies upon have already been studied and developed. Effectively, IoT consists on the
combined use of those technologies [2]:
− Communication and cooperation – objects communicate and use external data and
services (among relevant technologies are cellular networks, WiFi or Bluetooth).
− Addressability – objects can be addressed and located, using services like discovery and
lookup, so that they can be interacted with.

2
− Identification – objects are uniquely identifiable, using technologies like
Radio-Frequency Identification (RFID), Near Field Communication (NFC) or even
barcodes, so information about them can be retrieved.
− Sensing – objects gather data about the surrounding environment from sensors and
record, forward or act upon that information.
− Actuation – objects contain actuators so they can manipulate their environment.
− Embedded processing – objects become “smart”, containing hardware to process and
store information, or even analyse that information to take actions based on it.
− Localization – objects possess information about their physical location – enabled
through Global Positioning System (GPS), mobile phone networks or other radio or
even optical technologies.
− User interfaces – objects communicate with people appropriately (for example,
indirectly through the screen of a smartphone, or directly via embedded touchscreen
displays, recognition of voice, image and gestures, and tangible user interfaces).
Not all things that can be considered part of an Internet of Things are required to implement
all these technologies simultaneously, and in the future additional technologies may be
integrated to bring more features.
The possibilities opened by IoT are currently being applied and researched in several
scenarios. They can be divided in many areas of focus [5, pp. 1–10]:
− Transportation/Logistics (e.g. global positioning and real-time tracking of objects).
− Smart Home – cooperation between different devices to improve awareness of many
things inside a house and with external entities, facilitating better resource usage (water,
energy), improved security (fire, theft) and comfort (automatic temperature, lighting).
− Smart Factory – existing product tracking and automated sensing and control systems,
e.g. RFID and Supervisory Control And Data Acquisition (SCADA), can be expanded
through IoT, allowing tighter integration with Enterprise Resource Planning (ERP) and
other systems, either on site or from clients or suppliers.
− Smart Cities – a smart city as defined by Giffinger et al. [6] will perform well in key
“smart” characteristics and benefit from an improved information infrastructure
enabled by IoT: economy, people, governance, mobility, environment and living.
− Retail – IoT can facilitate the flow of information for both consumers (price
comparisons, similar products) and companies (inventory control, customer
information).
− E-Health – remote tracking, monitoring and recording of health history is already
helping to reduce costs in healthcare, by focusing on control and prevention instead of
acting upon sickness and disease.
− Energy – the goal of energy saving, which overlaps with Smart Home and Smart City,
can be materialized by Smart Grids using information to improve efficiency in
production and distribution of electricity, and by Smart Metering to provide
information about energy consumption and usage patterns.
As we can see, these scenarios are made possible through IoT, which according to the
applications can fall into two broad categories [7]: information and analysis (tracking and
monitoring, enhanced situational awareness, sensor-driven decision analytics); automation and

3
control (process optimization, optimized resource consumption, complex autonomous
systems).
To support the scenarios described above with their products or by presenting solutions for
others to use, many companies are increasingly investing in IoT, from the computer industry
(hardware/software) such as Intel, ARM, IBM, Oracle, Microsoft, Cisco, and from other areas
like home appliances from LG, Samsung, Whirlpool for example. They usually have a web
site dedicated to their platform for IoT development or a catalogue of Internet connected
“smart” products.
Even the Open Source world is deeply involved in advancing IoT, with several projects
currently undergoing (some of them are analysed more in detail in Chapter 2 of this
document), and various other contributions mainly related to memory- or computation
capability-constrained devices (protocols, Linux-based operating systems or even portals to
gather several tools such as Eclipse IoT). This project involved research of Open Source
projects to find a suitable middleware providing base functionality for the platform.
Despite all these advantages associated with IoT, there are some challenges to a faster
transition to a full “Internet of Things” [2], [8]:
− Scalability: how to coordinate IoT objects and how they will cooperate, given their
potentially vast numbers – these things should cooperate mainly locally, then aggregate
their functionalities for large-scale environments;
→ This project proposes such an approach – things cooperating essentially on a
local level, then providing a point of access for external access.
− Heterogeneity/Interoperability: how diverse things, from different manufacturers,
having distinct characteristics will cooperate – common standards need to be adopted;
→ To address this challenge an existing platform was used, even though to fully
solve the problem such a platform should have widespread adoption.
− Security and privacy – concerns already present in the current state of the Internet, they
are further aggravated with IoT objects due to their connectivity potentially making
available personal, sensitive data;
→ The risks involved were mitigated (their guaranteed elimination would be
difficult, if not impossible) by making available an authenticated service for
remote access, hiding the objects in their own intranet thus minimizing
possible attack points (with access to the objects still possible through that
service).
− Data volume and interpretation – sometimes things will generate huge amounts of data
or communicate infrequently, possibly providing incomplete data. The challenge is in
the infrastructure to provide storage for large volumes of data and to automatically
make sense from potentially incomplete data;
→ Probably a major concern in industrial environments with lots of sensors and
data, which is not the case in this project aimed for home use. In this project,
the devices themselves or their controller in the platform should make their
best effort to ensure reliable data is gathered.

4
− Discoverability and automatic configuration – people want to treat their everyday
objects as always, so they must be able to configure themselves without user
intervention; this includes automated discovery, where objects announce their
presence, capabilities and state;
→ These challenges were translated into criteria for selection of a platform in
which they were contemplated. However, the recognition of a device
presented to the platform is also a problem of Heterogeneity/Interoperability,
fully solved only by widespread adoption of common standards.
− Software complexity – many objects will have limited resources, requiring more
complex software infrastructure to be placed in servers;
→ Given the target home use, the platform itself should require a minimal use of
processing and storage resources, to be able to work on low power, low cost,
small size embedded hardware, such as a Raspberry Pi 2. The sensors and
actuators should either connect directly to that device running the IoT
software, or through gateways when they don’t possess suitable connectivity.
− Power supply and communications – things that can be moved need to have their own
energy source, either through batteries or gathering energy from the environment. To
conserve energy, processing and communications (wireless is almost a requirement for
device mobility) must be efficient and low-powered;
→ This is mainly a hardware issue; the software should make use of power saving
features when available and should communicate with devices only when
necessary. The simplicity of the software platform, by allowing it to run on
low power hardware, should also contribute to conserve energy.
− Environment – “smart objects” incorporate electronic components, posing an
additional issue to deal with when disposing of or recycling those objects.
→ Also mainly a hardware issue. The selection of hardware in which the
manufacturers provide detailed documentation and support for developers,
and the use of Open Source software have the potential to at least help by
postponing obsolescence.
The current picture of IoT indeed has many advantages to offer and many opportunities to
exploit, if these challenges can be overcome. For this project in particular, the analysis of these
challenges and the solutions proposed for each of them were a valuable tool to select a suitable
middleware and to help guide the development.
1.2. Motivation
The Internet of Things offers many opportunities in the form of remote monitoring and
control, more complete information of environments, translated into increased efficiencies.
Based on the applications of IoT presented in the previous section, and foreseeing their
expansion in the future, many business intelligence reports predict a huge market opportunity
in this area. For example, in a recent press release [9] it is mentioned that IoT devices “will
grow to 26 billion units installed in 2020”, far more than the 7.3 billion personal computers,
tablets and smartphones not accounted for as IoT devices. This will convert into a $300 billion
revenue increase to IoT product and service suppliers, and an added value of $1.9 trillion in

5
the global economy. Another report [10] of business intelligence predicts similar numbers,
pointing to the enterprise sector as leading the growth in IoT followed by government and
home sectors – main drivers will be increased efficiency and lower costs, while the main
obstacles for adoption are security concerns and the lack of common standards. In summary,
several sources report similar figures, so this growth is expected to become a reality, in fact
many companies regard IoT as a requirement to maintain competitiveness.
It is in this setting that this project can be introduced. The IoT platform for control of
irrigation systems can be applied in many contexts: the main target was specified as the Smart
homes scenario, but its application can also be suitable to some extent in the Smart cities,
Energy and Smart Factory applications. The main benefits are in line with those associated
with IoT, namely remote monitoring and control, intelligence for autonomous operation, and
savings in water and energy while ensuring proper watering.
1.3. Goals
This internship was a first step towards the practical application of knowledge acquired during
the Master’s Degree. The goals for this internship, what to expect from the outcome of the
work performed, will be stated in this section from different perspectives.
Technical goals
The main technical goal was to deliver a prototype smart irrigation system, implementing
an existing IoT middleware.
At the end of this internship it was expected to have a system that could can:
− Use data from sensors to gather information from the environment (such as rain,
moisture, temperature);
− Control actuators to act upon that environment (for example valves and lights);
− Represent sensors and actuators as virtual devices to provide abstraction so that
the system can be hardware agnostic;
− Use information from online services such as weather forecast to support decisions;
− Provide user interfaces to allow user to monitor and control the system (data
visualization, manual operations such as start/stop irrigation, definition of settings);
− Provide an open interface to allow integration with other projects/applications;
− Automatically perform control actions based on current/predicted environment
(from sensor and online services data) and actions defined by the user;
− Register and authenticate users to control access.
Additionally the system should have better performance than legacy irrigation systems by
satisfying the following criteria:
− save water (it must prevent irrigation from starting when weather conditions allow it);
− ensure adequate conditions for plant growth (it must adjust irrigation according to the
environment).
This project did not contemplate the full development of an IoT platform, instead existing
IoT middleware was used as a foundation. Great advantages from this code reuse included

6
support of some hardware devices and adoption by many users and developers, ensuring some
level of interoperability, reusability and quality of the software.
Internship goals
Concerning the internship, the main objective was to apply and consolidate the knowledge
acquired during the Master’s Degree. The internship was an opportunity to gain further
knowledge and experience, and to improve skills such as analysis/research, management,
organization, initiative and problem-solving.
Company goals
The company provided the facilities in which this project took place, beyond the time and
knowledge of a supervisor who afforded support and guidance.
Naturally the company expected the successful completion of this project, ending with a
product they can use and improve, eventually converting it into a marketable product.
1.4. Document structure
This report comprises five chapters, including this introduction establishing the project
background, motivation and goals. The other chapters are organized as following:
Chapter 2 – State of the Art: current projects and products were analysed to highlight the
main features and to identify strengths and weaknesses to be addressed.
Chapter 3 – Project Approach: this chapter is dedicated to describe the way this project was
executed. This comprises the methodologies adopted, technologies and tools used, plan of the
work performed, and a list of risks associated with the project.
Chapter 4 – Work Performed and Results: presents the work performed and the results
obtained, describing the fulfilment of the project goals.
Chapter 5 – Conclusions: this chapter presents a summary of the project and a final
comment on the work realized.

7
Chapter 2.
State of the Art
The purpose of this chapter is to present the research performed to gather the information
necessary to accomplish this project.
The first step was to characterize architectures employed in IoT projects, to extract their base
structure and concepts. Some groups dedicated specifically to this question, producing
generalized architectures, presented in the first section of this chapter.
The following section presents a fundamental part, the identification and analysis of IoT
middleware software which could be used and adapted to the scope of this project.
Finally, current products that can be related with this project were also reviewed to identify
the latest developments in the area and to extract a set of leading edge features from them.
Information available about IoT is vast, even when considering only the topics analysed in
this chapter, due to a great number of IoT projects and products that are available. For that
reason, the approach in this chapter intends to be merely representative of the existing
information about the discussed subjects.

8
2.1. Architectures
The problem of heterogeneity of IoT devices, mentioned in the Introduction of this
document, is related to different devices using specific protocols developed with specific
applications in mind, resulting in the IoT landscape nowadays appearing as highly fragmented.
Many IoT-enabled solutions exist with recognised benefits in terms of business and social
impact, however they form what we can be called a set of Intranets of Things, not an Internet
of Things. Better interoperability can only be attained with the definition and adoption of
common standards, and a first step towards that goal can be the specification of those
standards in a reference architecture. Therefore, in this section two possible architectures for
IoT are presented: IoT-A (Internet of Things – Architecture) Architecture Reference Model
and SENSEI Real World Internet Architecture.
2.1.1. IoT-A Architecture Reference Model
Many currently implemented solutions were developed to solve specific problems and the
interconnection of the smart objects is usually confined within those solutions. Internet of
Things – Architecture (IoT-A) [11] is a project supported by FP7 aiming to raise the
interoperability of IoT solutions. This project investigated the state of the art in IoT to present
an Architecture Reference Model (ARM). While retaining compatibility with existing
solutions, this ARM intends to lay out a plan for IoT interoperability, comprising both a
Reference Model and a Reference Architecture, summarised by a Vision and accounting for
various Business scenarios and Stakeholders [12].
As mentioned, a current common trend in IoT is its application to specific scenarios, targeting
specific problems or domains, in which the solution is best explored in that particular domain.
With systems designed as vertical applications, the focus of intercommunication is between
the smart objects that constitute the system, leaving interoperation with other systems as a
secondary concern.
However, to further explore the potential offered by IoT, communication between diverse
systems should be achieved. A barrier to this achievement is the heterogeneity of the adopted
solutions. The Vison of IoT-A is to reach a high level of interoperability at various levels
(communication, service, knowledge) through the establishment of a common ground for the
different platforms. The project proposes to materialize these goals through a Reference
Model (a common understanding of the IoT domain) and a Reference Architecture (a
common foundation for IoT systems architectures).
Generically, the ARM aims to connect base protocols (e.g. Bluetooth, ZigBee, 6LoWPAN)
and devices (e.g. sensors, actuators, tags), responsible to collect and provide information, to
the various IoT applications which will make use of that information.
The IoT-A ARM is not focused on a specific application but constitutes a baseline built upon
current standards and best practices. From it, a concrete architecture can be generated, thus
serving as a reference to allow faster design and development of interoperable IoT solutions.

9
Reference Model
The Reference Model created in this project (Figure 1) establishes a baseline of understanding
for IoT, modelling its concepts and relations. Forged from business scenarios (such as those
mentioned in Chapter 1 in this document), existing architectures and the concerns of the
various stakeholders, it is materialised in several Models.
Figure 1: interaction of all sub-models in IoT-A Reference Model [12].
Firstly, it is built upon a Domain Model that describes the base concepts, being composed
of:
− Physical Entities with whom a User (not necessarily a human) can interact with on the
real world;
− Devices attached to the Physical Entities (sensors, tags, actuators) which can provide
information or act upon them, acting as a bridge between Physical and Virtual Entities;
− Virtual Entities that represent the Physical Entities in the digital world;
− Resources hosted by the Devices, acting as a placeholder for the information they
gather or for their actuator capabilities;
− Services expose the Resources, providing interfaces for Users to interact with Physical
Entities (through the related Virtual Entity) on a digital level.
An Information Model then uses these concepts to define structures, like relations and
attributes, for all the information involved in the system.
Finally, founded upon the Domain and Information Models is the Functional Model, which
identifies functional groups that interact with instances of the base concepts or manage their
associated information.
Inside the Functional Model, two groups assume special importance, having their models also
specified:
− Communication Model: since communication between different devices is required in
IoT systems, this model is necessary to establish concepts making it possible in the
typical heterogeneous environments associated with those systems;

10
− Security Model: another important concern, especially when communications are
involved, to ensure privacy and security.
Reference Architecture
The project also provides a reference architecture, addressing the concerns of the various
stakeholders, namely elements of the system and their interactions, information management,
operational features and deployment of the system. It is expressed through views
(representations of the structural aspects) and perspectives (guidelines used to address quality
or non-functional properties of the system).
The views included are Functional, Information and Deployment & Operation.
The Functional view (Figure 2) depicts the various functional groups of the model and its
components. The IoT-A Reference Architecture provides a connection between the
Application and the Device functional groups (which are not further detailed in the
architecture).
Figure 2: Functional view of IoT-A [12].
The Information view shows the various static information structures and the dynamic
information flow, describing how that information is to be represented in the system.
The Deployment & Operation view provides guidelines to aid in designing actual
implementations of services, identifying various possibilities in the devices, resources and
services groups. These include communication technologies and protocols, where to deploy
the software for given resources and services, where to store collected information, and where
to deploy the core engine (responsible for managing discovery, bindings and retrieval of
resources and services).

11
The perspectives identified in the document as most important to address the non-functional
requirements of the stakeholders are:
− Evolution and Interoperability addresses the predictable changes that can occur after a
system has been deployed, implying a certain need for flexibility, as IoT systems are
expected to evolve rapidly, particularly under the light of an also changing vision of
IoT;
− Availability and Resilience, because IoT systems are distributed and there is a need to
make sure they are able to handle failures while keeping at least partly operational;
− Performance and Scalability takes into account the nature of IoT systems, generally
distributed, with high connectivity and heterogeneity, translating into a need to cope
with those characteristics and with the processing of great amounts of information;
− Trust, Security and Privacy deal with dependability, confidentiality, integrity, access
policies, accountability and identity management, characteristics whose importance is
once again increased due to the distributed nature of IoT systems.
2.1.2. SENSEI Real World Internet Architecture
SENSEI is an Integrated Project in the European Union’s (EU) Seventh Framework
Programme for Research (FP7) in Information and Communications Technology (ICT) [13].
The project ran for three years with the goal of supporting the vision of Ambient Intelligence
in a future network and service environment.
The main obstacle to the realization of that vision is, as already mentioned, the heterogeneity
of wireless sensor and actuator networks (WSANs). Hence the needs for a common
framework of global scale and for the ability to make those networks available to services and
applications via universal service interfaces. SENSEI creates an open, business driven
architecture to address the scalability problems for those WSAN devices. It also provides
network and information management services, and mechanisms for accounting, security,
privacy and trust.
The results of the SENSEI project include a reference architectural framework with
corresponding protocol solutions to enable easy integration of globally distributed WSANs
into a global system. Figure 3 shows an overview of the architecture, along with the core
concepts [14].
Figure 3: High level overview of the SENSEI Architecture and core concepts [14].

12
To support a “Future Internet” scenario, this architecture specifies a Resource Layer added
on top of the Communication Services Layer (connectivity substrate of the Internet) to enable
access to Real Word Resources by applications and services (Application Layer). In addition
to Resources, the Resource Layer also includes Support Services (discovery, composition and
dynamic creation of Resources and sessions) and Community Management features (identity
management for all entities in the system, consumer and provider account handling, privacy
and security).
As Figure 3 shows, a Resource is an abstraction of (and is associated with) one or more Real
World Entities (acting as sensors/actuators, processing components, or even a combination
of both). A Resource End Point (REP) is the software process implementing Resource Access
Interfaces (RAIs) through which a user can access the resource’s services. This REP is
uniquely addressable within the real world resource layer.
A device executing the software that represents a REP provides the Application Layer
(Resource Users) and Support Services access to the referenced Resource. These Support
Services consist on:
− Resource Directory (provides registration and user lookup of resources);
− Entity Directory (maintains associations and dependencies between Real-World
Entities and Resources; complements Resource Directory by focusing on Entities
allowing their lookup);
− Semantic Query Resolver (receives queries from Users interested in particular
Resources or Entities);
− Execution Manager (provides interfaces that can be invoked by the Semantic Query
Resolver to process requests for real world context and actuation tasks; establishes
sessions between Resource Users and Resources for monitoring).
A materialization of this architecture using existing web technologies is demonstrated, based
on a RESTful design in which each component is available as a Representational State
Transfer (REST) resource, identifiable by a unique Uniform Resource Identifier (URI) and
accessible through the HyperText Transfer Protocol (HTTP) protocol (using GET, POST,
PUT and DELETE to manipulate the resources).

13
2.2. Middleware
Another piece in the puzzle addressing the challenges presented by an effective
implementation of IoT is the use of middleware. This is software whose purpose is to establish
a bridge between diverse hardware devices and the applications that want to use them, by
presenting a common interface.
Several studies have analysed and compared available IoT middleware solutions, for example
those performed by Bandyopadhyay et al. [15] and Zhou [16]. The classification made by
Bandyopadhyay et al. is summarized in Table 1.
Table 1: IoT middleware comparison in Bandyopadhyay et al. [15].
IoT
Middleware
Features of Middleware Interface protocols
Device
Management
Interoperation
Platform
Portability
Context
Awareness
Security
and
Privacy
Zigbee
RFID
WiFi
Bluetooth
Sensor
(others)
HYDRA          
ISMB          
ASPIRE          
UBIWARE          
UBISOAP          
UBIROAD          
GSN          
SMEPP          
SOCRADES          
SIRENA          
WHEREX          
The table shows that many middleware solutions were conceived without special concerns
about interoperability, context awareness, or security and privacy. This is mainly due to the
purpose and focus of the particular middleware, leaving the features to be implemented by
the software adopting those solutions.
Among the middleware platforms referenced in this chapter appearing in Table 1, HYDRA is
presented as a more complete solution, providing a full platform integrating devices and
applications, while being agnostic to interface protocols. In contrast, GSN and ASPIRE are
more limited since their purpose was focused on abstracting interface protocols, hence they
are referenced only as being components of a more complete platform.
These complete platforms are the types of middleware that interest most to this project. In
this section some of them are presented, taking into account that many more are available.

14
2.2.1. OpenIoT
This is an EU FP7 co-funded project to enable “open large scale IoT applications according
to a utility cloud computing delivery model” [17]. The main goal is to develop a middleware
infrastructure to implement and integrate IoT solutions in a “Sensing-as-a-Service” paradigm.
This project is presented as an extension to cloud computing implementations (remote
computational services and resources) where it will provide access to resources and capabilities
from the devices managed by its platform. OpenIoT covers several areas in order to constitute
a more complete solution:
− Middleware to connect sensors and sensor networks to the platform (sensor or data
streams, from physical devices or processing algorithms presented as a virtual devices).
− Sensors integration – represented as virtual sensors, using middleware frameworks for
RFID/ Wireless Sensor Networks (WSN) and IoT such as GSN [18] and ASPIRE [19],
providing baseline functionalities for registration and lookup, integrating sensors with
minimal effort.
− Ontologies, semantic models and annotations to represent information about objects
(according to W3C Semantic Sensor Networks specifications [20]) and access to Open
Linked Data through SPARQL Protocol and RDF Query Language (SPARQL) and
Resource Description Framework (RDF) for better interoperability.
− Cloud/Utility computing, to provide cloud availability with security and privacy.
− Flexible configuration and deployment of algorithms for the collection and filtration
of information streams – visual tools to manage sensors and their data, for composition
of services and for visualisation of data with minimal programming effort.
Beyond this foundation to facilitate the work of developers, the needs of researchers and
businesses are also addressed. Several use cases were defined for demonstration of this project:
− Smart Agriculture (remote sensors providing crop analysis and yield prediction).
− Intelligent Manufacturing (integration of devices, dynamic discovery, data analysis).
− Urban Crowdsensing (availability of information about factors like air quality or traffic).
− Smart Living (location aware services using open data to help people’s everyday lives).
− Smart Campus (student/staff access to campus equipment and collaboration services).
Architecture
The OpenIoT Architecture [21] is based on the reference architecture from IoT-A. The
architectural elements are arranged in three logical planes (as shown in Figure 4):
Utility/Application Plane
− Request Definition enables specification of service requests through a visual interface,
submitting them to the Global Scheduler.
− Request Presentation selects mashups from a library to facilitate service presentation
in a visual interface (using service definitions created in Request Definition) and to
retrieve relevant data from Service Delivery & Utility Manager.
− Configuration and Monitoring enables management and configuration of
functionalities over sensors and services deployed in the platform, allowing health
monitor of deployed modules.

15
Virtualized Plane
− Scheduler processes requests for services from Request Definition and ensures their
access to required resources; responsible for sensors discovery and associated data.
− Cloud Data Storage stores data streams from sensor middleware and metadata required
for platform operation – component based on another project, LSM (discussed below).
− Service Delivery & Utility Manager combines data streams to deliver the requested
service (using description and resources identified by the Scheduler) to the Request
Presentation or a third-party application. It also performs metering services, used for
accounting, billing, and utility-driven resource optimization (pay-as-you-go paradigm).
Figure 4: OpenIoT Architecture [21].
Physical Plane – composed by several sensors and middleware to interact with them. Sensor
Middleware collects, filters, combines and semantically annotates data streams from virtual
sensors or physical devices, acting as a hub between the platform and physical world. GSN
middleware is used for this purpose (discussed below).
GSN – Global Sensor Networks
GSN is a middleware designed to facilitate deployment and programming of sensor networks,
adopting a concept of sensors (real or virtual) connected together to build a processing path
(virtual sensors can be created from processing algorithms). Based on the observation that
most of the requirements of sensor networks applications are similar, GSN provides an
integration layer for building hardware-independent applications, facilitating integration.

16
OpenIoT uses an extension called X-GSN (Extended GSN), to further surpass heterogeneity
problems by adding semantics to virtual sensors, providing knowledge about them, their
capabilities and the structure of the data they provide.
ASPIRE – Advanced Sensors and lightweight Programmable middleware for Innovative
RFID Enterprise applications
ASPIRE is the equivalent of GSN for RFID, incorporating much of the solution intelligence
in the middleware for easier integration with low-cost hardware and legacy infrastructures.
LSM – Linked Sensor Middleware
This platform connects real world sensed data and enriches it with semantic descriptions that
can be queried in a SPARQL endpoint. It provides wrappers for real time data collection and
publishing, and a web interface for data annotation and visualisation. Redesigned for OpenIoT
with extra functionalities, it adopted the name Linked Stream Middleware Light (LSM-Light).
2.2.2. BUTLER
A project developed under FP7 and officially over in 2014, with the purpose to enable “the
development of secure and smart life assistant applications thanks to a context and location
aware, pervasive information system” [22]. BUTLER focuses on:
− Improving/creating technologies to implement an IoT that is secure (secure links from
physical to application layers), pervasive (applications cover different scenarios) and
context-aware (adjusts to user’s needs).
− Integrating/developing a flexible SmartDevice-centric network architecture where
devices can be categorized as SmartObjects (sensors, actuators, gateways),
SmartMobile (user’s personal device) and SmartServers (providers of contents and
services).
− Performing field trials to show and help to improve the project.
In contrast to today’s domain-centric vertical solutions, BUTLER provides a horizontal
platform where IoT devices can be reused by various applications from different domains,
designating it a “unified SmartLife environment”.
Architecture
BUTLER based its architecture on existing work, namely IoT-A and FI-WARE architectures.
Four main architectural layers were defined in the final architecture [23], shown on Figure 5.
Communications Layer – handles the end-to-end communication infrastructure (based on
standards as much as possible) connecting SmartObjects, SmartMobiles (client devices) and
service platforms (SmartObject Gateways and SmartServers).
Data/Context Management Layer – specifies data models, interfaces and procedures for data
collection and processing. With context information, transforms raw data to rich information.

17
Services Layer – defines components and interfaces for description, discovery, binding,
deployment and provisioning of context-aware services.
System/Device Management Layer – manages and maintains SmartObjects, Services and
other entities, such as configuration, software and performance management, or diagnostics.
Figure 5: BUTLER Architectural Layering [23].
Platform approach
BUTLER’s platform is a service-oriented, modular approach composed of 3 main blocks [23]:
Smart Object/Gateway is the interface between the cyber world and the physical world (on
which smart objects provide information and perform actions); gateways collect and aggregate
data/actions, providing an abstraction layer for interconnection of heterogeneous IoT devices.
Smart Mobile is the client on a BUTLER mobile application, interfacing between end-users
and the platform. It provides a framework for those applications, abstracting the server side
while exposing its features.
Smart Server processes and mediates information between users and applications, exposing
functionalities like localization, security, user profile management and behaviour prediction.
The Security and Trust Service is transversal to these modules, ensuring only authorized
entities can be integrated into the platform and only authorized applications can access it, thus
enabling end-to-end security while also providing privacy through separate trust assessments.

18
2.2.3. IoTCloud
IoTCloud [24] is a sensor-centric framework supporting various sensor types and large
numbers of smart objects possibly geographically distributed, developed by a team at Indiana
University. The main issues identified with IoT today (and approached in the framework) are
related with scalability, deployment, discovery, management and interoperability of many
types of smart objects.
Architecture
The IoTCloud architecture is presented in Figure 6, showing components and relations [25].
Figure 6: IoTCloud Architecture overview [25].
According to the architecture, the IoTCloud framework consists of four primary components:
IoTCloud Controller – manages the system and coordinates communication between other
components, through standards-based Simple Object Access Protocol (SOAP) Web Services
for sensor registration, discovery, subscription and control. It also maintains a repository of
sensor status and metadata information, used for discovery, filtering, and management
services. It uses the Message Broker component to create message routes (message topics)
between clients and sensors.
Message Broker – handles low level details of message routing. A Java Message Service (JMS)
message broker (Apache ActiveMQ) is used for block data, whereas a streaming message

19
broker (HTTP server using Netty) is used to handle streaming data. In combination with the
Controller, it constitutes the middleware layer for the system.
Sensors – producers of time-dependent data series (they can be smart objects, or even
computational services). A Sensor Module software component links physical sensors to
IoTCloud. The sensors can be either Block Sensors (low frequency messaging, for e.g.
thermometers) or Streaming Sensors (e.g. video feed). These Modules can also receive control
messages to perform actions.
Clients – are able to discover, subscribe to and control Sensors, consuming their data for use
in the respective applications.
It is possible for an object to be both a Sensor and a Client in this model. Other features
available are filtering (to list sensors near a certain location) and notifications (to warn when
sensors join or leave the platform). Sensor, Client and Message Application Programming
Interfaces (APIs) are available for development.
2.2.4. IoT@Work
This is a project led by Siemens AG, also one of the projects funded by FP7, within the ICT
research programme. It focuses using IoT in industrial automation environments, taking into
account their needs in networking and communications [26], [27].
In those environments, communication networks and security systems are highly complex,
making their configuration a challenging task. Normally done manually, this is usually
expensive and prone to failures. This project aims to reduce operational costs in configuring,
commissioning, and maintaining manufacturing solutions mainly by reducing the time needed
for changes to the systems. Based on results of current research projects, IoT@Work focuses
on enhancing communication and middleware infrastructure to build self-managing and
resilient networks, and service oriented application architectures adapted for factory
environments.
The main stated goals are:
− Decoupling the automation application/controller programming from network
configuration and operation;
− Integrating more self-management – develop mechanisms for “Plug&Work” where
devices are automatically connected, configured and become ready to cooperate.
− Ensuring resilience and security in running automation systems.
Architecture
The architecture for this project was developed in cooperation with IoT-A [28], due to
commonalities between IoT@Work application domain and one of the IoT-A use cases.
Figure 7 shows the three main layers of the architecture [29].

20
Device and network embedded services – perform management functions like assigning
identifiers, collecting device semantics and context, managing communication interfaces and
securing physical components.
Device resource creation & management services – perform aggregation and management of
embedded resources and services, and functions such as providing service directories,
abstraction of networks, and low-level system monitoring and security management.
Application level middleware services – support applications with functions like a messaging
bus, assigning descriptions to application resource (e.g. requesting a reliable communication
or a security context) and semantic reasoning.
Figure 7: IoT@Work Architecture Functional Layers [28].
Integrated Technologies
Directory Service – a RESTful service providing information on devices and services deployed
in the manufacturing plant, using a semantically annotated data model.
Auto-configuration of Real-Time Ethernet – enables Plug&Work on devices – assignment of
Internet Protocol (IP) address and Uniform Resource Locator (URL), discovery, real-time
Ethernet configuration.
Event Dispatching (Event Notification Service) – a middleware to connect event sources
(Publishers) and consumers (Subscribers), decoupling them while aggregating events.
Capability-Based Access Control – supports access right delegation, capability tokens
revocation and fine grained access rights.

21
Complex Event Processing – performs intelligent message processing (fault analysis,
predictive maintenance), supports self-management and allows filtering and combination of
events to create new functionality (using a reasoner and intelligent rules).
Network Slices – network virtualization management tool, a combination of network
virtualization, resource management and policy control, and auto-configuration.
Embedded Access Control – secure Plug & Work and secure communication. Involves device
identification, assessing integrity, authentication and authorization.
2.2.5. LinkSmart / Hydra
LinkSmart is an Open Source Middleware (originally named Hydra) developed within the
Hydra EU project (Sixth Framework Programme) which finished in 2010 [30], [31]. It was
adopted by several other projects to support development of new applications and devices.
The middleware itself is being enhanced on EBBITS, a project targeting support of business
applications and integration of IoT in enterprise systems [32].
The main objective was to develop a middleware based on a Service Oriented Architecture,
supporting both distributed and centralised architectures, security, trust and model-driven
development of applications. An additional objective was to create Development Kits (for
both software and devices) to support development based on LinkSmart.
Interoperability provided by Service Oriented Architecture (SOA) was complemented
through the use of ontologies with semantic web services (named Semantic Model Driven
Architecture – SeMDA). With semantic annotations better interoperability can be attained,
making all devices accessible in a uniform way as semantic web services.
The end result was a platform that can facilitate integration of heterogeneous products from
different manufacturers to provide higher value solutions, hiding complexity behind user
friendly interfaces.
Architecture
LinkSmart middleware is typically installed as a node in the peer-to-peer network,
encapsulating interfaces of internally referenced devices and providing them as semantic web
services to other network nodes (LinkSmart instances). Architecture of the main functional
modules of LinkSmart [32] is illustrated in Figure 8.
The middleware is located between the upper application layer and the physical and operating
system layers at the bottom of the diagram (these layers are not a part of the middleware). The
physical layer provides network connectivity (some examples are presented but LinkSmart can
use many other technologies). The operating system layer enables management of physical
layer objects and provides methods for accessing the resources of network connections. The
application layer contains any kind of user applications.

22
The middleware itself is divided into Application Elements and Device Elements, according
to whether they are close (e.g. on the same machine as the resources used) or distant (remote,
with slow access/performance) respectively. Each of these parts contain several layers
(network, service, semantic, and security) that perform various functions like context sensing,
service requests handling, network management and synchronisation of peer nodes, and
access control.
Figure 8: Structural overview of the LinkSmart middleware layers [32].
The middleware functionality is supported by Web Ontology Language (OWL) ontologies,
which provide a semantic basis for business logic elements. In the ontology for the service
model, Services (tied to devices) are described by the respective capabilities and input and
output parameters such as name, data type, and unit. Similar ontologies are used for modelling
devices, network connections, and security.
Finally, devices that are not able to run middleware components (closed platform, legacy, and
resource constrained devices) can be connected to a LinkSmart network by using device
proxies, which understand the technology and data format used, allowing communication.
2.2.6. Freedomotic
Freedomotic [33] is an IoT framework oriented towards the construction and management of
smart spaces, with the vision of “bridging the gap between physical and digital worlds
connecting People to Things and value-added business Services”. This Open Source software
(licensed under GNU GPL2 license) was created with flexibility and security in mind, to target
both private individuals (for home automations) and business users (suggesting applications
in smart retail environments, ambient aware marketing, monitoring and analytics).

23
The software supports some standard building automation protocols (BTicino, OpenWebNet,
KNX, Modbus RTU, Z-wave), as well as "do it yourself" solutions like Arduino devices, and
it also offers the possibility of integrating web services (including interaction with social
networks). This support is achieved using objects of generic types, using semantics to describe
them, making the platform hardware agnostic.
The platform can expand its functionalities through plugins (a marketplace is available offering
some plugins) which can add support for new devices and services, new frontends and new
object types.
The project is currently in beta phase and is developed in Java, stating that it can run on any
Operating System with support for the language. It is distributed and scalable, which translates
into more flexibility in terms of hardware requirements – according to the intended
application, it supports running on a network cluster to a single PC or embedded devices like
Raspberry Pi.
Architecture
The software is composed by a core (framework), using plugins to expand functionality and
to support physical devices [34]. An illustration of the architecture is presented on Figure 9.
Figure 9: Freedomotic Architecture [34].
The core performs the following functions:
− Implement a language independent messaging system based on Enterprise Integration
Pattern, linking all modules in a flexible and abstract way using channels (topics in a
publish-subscribe pattern);
− Maintain an internal data structure to represent the environment, the objects in zones
and their state;
− Create an abstraction layer to provide users and external software modules with a high
level logic (e.g. to use generic commands like “turn on device X” instead of sending
hardware specific low level commands);

24
− Provide a rules engine with natural language processing so users can define automations
at runtime.
The creation of automations involves the following concepts:
− Events (notifications of facts like status changes or user actions – can be published to
the messaging system by any component);
− Triggers (event listeners and filters – activated when an event is detected and it is
consistent with the defined conditions);
− Commands (instructions to perform actions);
− Reactions (comprised of triggers and commands bound together to form an
automation).
The rest of the functionality is provided by plugins that can implement devices (which send
events and receive commands), frontends and objects (models for virtual representations of
physical objects, describing their properties and behaviors).
2.2.7. Middleware – final analysis and selection
The software projects selected for analysis have in common their capabilities of abstraction
of hardware, their source code available and licensed to be reused in other projects, and the
fact that they have been recently developed.
Freedomotic was the middleware considered the most adequate for this project, taking into
account the following factors:
Availability of documentation and source code – BUTLER, IoT@Work and LinkSmart,
at the time of gathering information for this project, had published their code in separate
components with only some of them being readily accessible. Furthermore, not much
information was available for developers to build upon those projects.
Among these three projects the situation of Linksmart was probably the most favourable, but
the other projects had better availability of source code and documentation for developers.
Abstraction of hardware and representation – IoTCloud is not bound to specific hardware
devices, but it doesn’t specify standards for the characteristics of the represented objects,
unlike other projects which use semantics for that purpose. Using semantics ensures that a
certain device is represented and can be interacted with in a consistent way, independent from
its manufacturer (a required feature in the middleware to adopt).
Purpose concerning the use of devices – while the documentation of OpenIot mentions
sensors and actuators, the project places a strong emphasis on aggregation of data from
sensors for visualization. Implementation of sensors is detailed in the developer
documentation along with concrete examples, but no such thing exists for actuator devices.
Complexity – OpenIoT, the option initially favoured to be adopted, integrates many
components, making the analysis of its code more difficult. This was an important factor when
testing the platform to evaluate its suitability – only the version prebuilt into a virtual machine

25
image worked, a package compiled from the source code didn’t work; additionally, the
documentation presented some contradictory information concerning configuration
parameters.
Hardware requirements – the work to be performed during the internship was initially going
to be more focused on industrial applications, but it was later defined as being targeted for
home applications. In accordance with its complexity, OpenIoT was very demanding in terms
of system requirements for the platform to run, making it less desirable for the intended use;
in contrast, Freedomotic demands little resources, especially when running without the
desktop frontend.
Stability – the solutions that were tested (OpenIoT and Freedomotic) experienced some bugs
which in the case of OpenIoT prevented correct access to the platform. In the case of
Freedomotic, some fixes were applied, but the functionalities offered were never severely
impaired.

26
2.3. Commercial Products
There are many products in development or already available for purchase. They usually claim
to lower water usage in irrigation by using information from various sensors (and sometimes
external data like weather forecasts) to intelligently control valves. Some products are designed
to directly replace older units (working on schedules only), being compatible with the existing
valves.
Some of those products are presented in this section, pointing out their differentiating
characteristics and summarising with a comparison. The respective web sites were accessed
for information on 2014-12-20.
2.3.1. BlueSpray
Website: http://www.bluespray.net
BlueSpray is an irrigation controller currently available from several distributors, configurable
via a web interface. Having internet connectivity, its control interface is available virtually
anywhere, and allows the unit to use weather forecast information to prevent irrigation when
unnecessary.
Sensors are supported, namely rain (to prevent watering when it rains sufficiently) and garage
door (detects if the garage door is open, allowing the unit to command it to close if past a
scheduled time).
2.3.2. GreenIQ
Website: http://greeniq-systems.com
GreenIQ Smart Garden Hub is a controller for garden irrigation and lighting. The device is a
drop-in replacement for existing controllers, optionally also connecting to a lighting circuit. It
allows control and scheduling from anywhere through internet connectivity to GreenIQ
Cloud, where system configurations and user programs are stored.
Internet connectivity is also used to acquire current and forecast weather data to modify
irrigation periods in the schedule according to various factors (temperature, relative humidity,
wind speed and solar radiation). This is the main element supporting the claim of water
savings; some electricity savings can also be achieved here, but mainly through lighting
scheduling and adjustment according to sunrise/sunset times.
The product doesn’t have companion sensors but it can use existing rain sensors, and it can
pair with devices from other companies to gather data, namely Netatmo Weather Stations,
and the sensors Parrot Flower Power and Koubachi (measuring temperature, sunlight,
moisture, among other parameters).

27
2.3.3. Iro
Website: https://www.rach.io
This product is available from Rachio and consists of a sprinkler controller which can directly
replace old controllers, having internet connectivity through WiFi. This connectivity allows
control using Rachio’s own mobile or web applications, and it is the basis for integration with
several products/services such as Nest, Wink and IFTTT (a public API is additionally
available).
After an initial synchronization between the application and the Iro device, a custom schedule
is downloaded based on current location (taking into account regional characteristics and
restrictions). That schedule can be changed as necessary, but it is also automatically adjusted
based on yard characteristics (zone slope and shade, type of vegetation, soil and sprinkler
heads) and changes due to weather (rain, wind, humidity) and seasonality.
An additional feature is the possibility to give other people temporary remote access to the
controller.
2.3.4. IrrigationCaddy
Website: http://irrigationcaddy.com
This company offers controllers with internet connectivity, either WiFi or Ethernet. Its
web/mobile application interface allows control and scheduling of watering cycles (including
more complex schemes like even/odd days or each N days).
This system includes a water flow sensor to better monitor water usage. No automatic
adjustment of watering schedules are described for this product.
2.3.5. netAQUA
Website: http://www.roslen.com
This is a web-enabled controller available from the company Roslen. WiFi or Ethernet
connectivity allows access from anywhere, but the units also have a local control interface with
LCD display.
The specified schedules can be adjusted in response to data from various sources and settings:
− soil type (clay content) and slope;
− sensors – rain, temperature (increase or decrease times, or even stop watering at very
low temperatures), flow (to measure water usage and to detect leaks);
− automatically adjust to changing weather from local sensors or Internet weather data
(supplied from Weather Underground) – for example, watering can be stopped in case
of high wind conditions.

28
2.3.6. RainMachine
Website: http://www.rainmachine.com
RainMachine is an irrigation controller with WiFi connectivity which provides local and
remote access via web/mobile applications or directly in the unit’s touchscreen display.
The unit makes use of weather data from United States National Oceanic and Atmospheric
Administration to assess weather conditions and to perform evapotraspiration calculations. In
case of loss of Internet connectivity, the unit will use forecast data for a few days and historical
statistics when forecast is not available. According to this data, the amount of water will be
adjusted (in case of very hot or cold temperatures, or in case of rain).
Different schedules and adjustments can be assigned to various zones by specifying a base
watering amount, thus taking into account plant, soil and nozzle types.
Extra features include Station Delay (to set delays, allowing a source tank to fill up before
watering the next zone) and Cycle & Soak (to split a watering interval in cycles, in order to
avoid runoffs, allowing the soil to soak between cycles).
2.3.7. Skydrop
Website: http://www.skydrop.com
The Skydrop controller unit, like other products already mentioned, has a local interface with
a display and a jog dial, in addition to the remote interfaces (web/mobile applications).
For smart watering, several settings can be specified for each zone besides watering time:
plant, soil and sprinkler types, shade and slope. These settings combined with weather data
from Skydrop cloud service (providing forecast of precipitation, temperature, wind and
others) will provide adjustments to the schedules, namely quantity and frequency of watering
cycles.
In case of unavailability of Internet connection, the device will use historical data to provide
seasonal adjustments, although daily based adjustments won’t be available.
2.3.8. Ugmo
Website: http://www.ugmo.com
The systems from Ugmo comprise irrigation controllers and optional wireless sensors and
internet bridges.
The PH100 is a controller (with up to 6 zones configurable) that uses soil moisture sensor
data to turn off user scheduled irrigation cycles when the soil has sufficient moisture.
The more advanced UG1000 (used in this section for comparison with other devices) is a
smart irrigation controller that uses soil moisture sensor data to determine soil type and correct

29
irrigation runtimes – the user just defines times when irrigation is not wanted (but traditional
cycle runtimes can be specified). Cycles can be split to avoid excessive soaking and water
runoff.
The soil sensors provide temperature measurements in addition do moisture and are
connected wirelessly (using UgMO’s proprietary SenLink wireless sensor network
technology). Sensor terminals are available to connect additional sensors such as flow (to
detect leaks and provide water measurements), rain and others (auxiliary). Additionally there
is an error reporting feature to identify solenoid, sensor and battery failures.
For Internet connectivity a bridge device is necessary, making available software upgrades,
data collection, alerts, monitoring and remote configuration. This connectivity also enables
“agronomic support” to collect, interpret and analyse soil conditions, offering predictive
actions (more uniform irrigation, deeper rooting and predictive disease control).
2.3.9. Products – summary and comparison
The analysis performed intends to assess the general set of characteristics which can be applied
to most of the devices as well as some distinctive features.
A summary of features is presented in Table 2. All the devices can be a direct replacement for
legacy controllers, connecting to existing valves, and they also have Internet connectivity (at
least through WiFi), offering a web interface accessible with a browser and in most cases also
mobile applications. Normally no extra fees are charged for web services.
Table 2: Comparison of features of commercial products.
BlueSpray GreenIQ Iro
Irrigation
Caddy
netAQUA
Rain
Machine
SkyDrop UgMO
Uses
weather        
Internet Wifi
WiFi,
Ethernet
WiFi
WiFi,
Ethernet
WiFi,
Ethernet
WiFi WiFi WiFi
Remote
control
Public
API        
Nr. of
zones
8 8 / 16 8 / 16 10 9/18 12 8 6-24
Sensors
support
rain, garage
door
rain,
other
manuf.
rain rain, flow
rain, flow,
temperature  
moisture,
temperature,
flow, other
Other
devices
garage
door
lighting      
Custom
adjusting   various 
slope, soil
type
base
watering
various 
Season
adjusting        
- application for Apple iOS; - application for Android; - web browser interface

30
Among the distinctive features is the number of zones that can be specified, which varies
between devices but generally this number can be increased by using more devices. Another
distinction is the main source of information that is used for automatic adjustment of watering
schedules - manufacturers either focus on using weather forecasts from online services while
giving minimal importance to sensor data, or they use only sensors and no online weather
data.
→ Recognizing that both types of sources can contribute with valuable information, this
project intends to use them cooperatively.
A negative point in many of the products is that they are targeted specifically for North
American markets, so their use in other countries can be impaired in varied degrees (different
supply voltages can be easily solved with a power adapter, but weather data can be less accurate
or even unavailable).
→ This project does not deal specifically with hardware issues, but by using Open Source
software at its base it may offer more opportunities for improvement, facilitating
support for both new/alternative devices and services.
Only products being sold (as of January 2015) were compared, selected from a list on
Postscapes web site (http://postscapes.com/smart-irrigation-controllers). Several other
products were listed, including do-it-yourself projects, sensors and products with features
already presented in this analysis (some still in development). Certain products offered
integration with cloud platforms (such as SmartThings or IFTTT).

31
Chapter 3.
Project Approach
In this chapter it is described the approach used to perform this internship project. This
encompasses the software development methodologies used, the main technologies and tools
chosen for the development of the product, the project planning and the main risks identified.
3.1. Methodologies
This project involved a single developer. Since the requirements weren’t rigidly specified and
the final product was intended as a prototype, there was a certain degree of flexibility required
and even desirable in the development.
Furthermore, with the need to involve the supervisor from Flor de Utopia, where the project
was developed, good communication was a key necessity.
Combined with the need to organize and prioritize requirements, along with the intention to
deliver incrementally working over small sprints, prompted the adoption of an Agile
methodology. Among many Agile methodologies, Scrum corresponded to the description of
the desired process of development, although intended for team projects. As a single
developer project, merely some of the principles which could be applied were adopted from
the Scrum methodology.
The Scrum guide [35] describes it as a “framework within which people can address complex
adaptive problems, while productively and creatively delivering products of the highest
possible value”. It employs an iterative, incremental approach to optimize predictability and
control risk and is founded on empirical process control. An overview of the process is
presented on Figure 10.
Figure 10: Scrum process [36].

32
In the Scrum process the following is defined:
− roles (Product Owner, Scrum Master and Development Team);
− events, used to create regularity and to minimize the need for meetings (a Sprint is a
container for all other events, corresponding to an iteration);
− artifacts, representing actual work which can be inspected and adapted (backlogs
contain lists of features, functions, requirements, enhancements, and fixes that
constitute the changes to be made to the product, while increments constitute the
product of a Sprint, namely the completed items from the backlog).
In the context of this project those roles do not apply, as they are meant for teams. The tasks
related with the Product Owner (representation of stakeholders and definition of a Product
Backlog, its items and ordering) can be thought of as being carried out by the supervisor at
Flor de Utopia; the other tasks, namely the development work, were performed by the author
of this thesis.
Initially planned to be performed iteratively with a planned duration of two weeks for each
iteration, this project later accommodated that duration to one month to coincide with the
monthly meeting with the supervisors. In these meetings the work of the previous iteration
was reviewed and the next iteration was planned. During the iteration there were no planned
events, as there was always someone available at Flor de Utopia to provide help or
clarifications when necessary.
The backlog consisted of the specifications described later in this chapter, from which some
items were selected in each iteration, according to their priorities. The backlog was initially
stated in the form of user stories and later detailed in technical requirements. The priorities were
assigned according to the MoSCoW [37] technique.
MoSCoW is a technique employed to define the importance of each requirement, in order to
support decisions concerning the order of requirements implementation. It involves an
analysis which will result in the separation of requirements into four categories: Must, Should,
Could, and Won’t. Category descriptions, as stated in the reference [37], are as follows:
− Must: Describes a requirement that must be satisfied in the final solution for the
solution to be considered a success.
− Should: Represents a high-priority item that should be included in the solution
if it is possible. This is often a critical requirement but one which can be satisfied in
other ways if strictly necessary.
− Could: Describes a requirement which is considered desirable but not necessary.
This will be included if time and resources permit.
Won’t: Represents a requirement that stakeholders have agreed will not be
implemented in a given release, but may be considered for the future.

33
3.2. Tools
In line with the preferred Architecture and Middleware selected for use and adaptation
(described in the State of the Art in Chapter 2 of this document), the language used for
development was Java (version 7). Likewise, Maven was used for dependency management
and build automations, while Git was the source control system.
Eclipse (Luna Service Release 2 – version 4.4.2) was the chosen Integrated Development
Environment. Maven and Git operations were performed using its included plugins.
3.3. Planning
The internship was divided in two semesters, in which the first was used as a research and
preparation phase for the project. The planning for this semester is shown in the chart in
Figure 11, where the tasks performed are detailed.
Figure 11: Planning for the first semester.
The initial planning for the second semester consisted on the development phase and final
preparations. In Figure 12 we can see the several 2 week sprints, followed by the preparations
for the final report and project defence. For each sprint the goals and requirements were to
be further detailed in the beginning, also presenting a summary of the work performed in the
previous sprint.
Figure 12: Planning for the second semester.
ID Task Name Start Finish
1 Presentation of the company Mon 15-09-14 Mon 15-09-14
2 Project analysis Tue 16-09-14 Fri 26-09-14
3 Analysis of references provided Mon 29-09-14 Fri 17-10-14
4 Research on architectures Mon 20-10-14 Wed 29-10-14
5 Research on middleware Wed 29-10-14 Fri 21-11-14
6 Analysis of software to be used Mon 24-11-14 Tue 09-12-14
7 Detailing requirements Wed 10-12-14 Tue 16-12-14
8 Completing writing of the report Wed 17-12-14 Tue 20-01-15
9 Preliminary report delivery Wed 21-01-15 Wed 21-01-15
10 Review of intermediate report Thu 22-01-15 Mon 26-01-15
11 Intermediate report delivery Tue 27-01-15 Tue 27-01-15
12 Preparation of project presentation Wed 28-01-15 Fri 30-01-15
13 Intermediate project defense Mon 02-02-15 Mon 02-02-15
15-09
21-01
27-01
02-02
07 14 21 28 05 12 19 26 02 09 16 23 30 07 14 21 28 04 11 18 25 01 08 15
p '14 Oct '14 Nov '14 Dec '14 Jan '15 Feb '15
1 Development Mon 09-02-15 Fri 12-06-15
2 Sprint #1 Mon 09-02-15 Fri 20-02-15
3 Sprint #2 Mon 23-02-15 Fri 06-03-15
4 Sprint #3 Mon 09-03-15 Fri 20-03-15
5 Sprint #4 Mon 23-03-15 Fri 03-04-15
6 Sprint #5 Mon 06-04-15 Fri 17-04-15
7 Sprint #6 Mon 20-04-15 Fri 01-05-15
8 Sprint #7 Mon 04-05-15 Fri 15-05-15
9 Sprint #8 Mon 18-05-15 Fri 29-05-15
10 Sprint #9 Mon 01-06-15 Fri 12-06-15
11 Completing writing of report Mon 15-06-15 Fri 26-06-15
12 Preliminary report delivery Fri 26-06-15 Fri 26-06-15
13 Final review of report Mon 29-06-15 Fri 03-07-15
14 Final report delivery Mon 06-07-15 Mon 06-07-15
15 Preparation of project presentation Tue 07-07-15 Fri 10-07-15
16 Final project defense Mon 13-07-15 Fri 17-07-15
26-06
06-07
01 08 15 22 01 08 15 22 29 05 12 19 26 03 10 17 24 31 07 14 21 28 05 12 1
Feb '15 Mar '15 Apr '15 May '15 Jun '15 Jul '15

34
The effective work performed is detailed on Figure 13. As stated before, each iteration ends
with a meeting with the supervisors.
The first step involved an analysis of detailed requirements for this project and some
experimentation with OpenIoT, the initial selected middleware.
After that, some other middlewares were evaluated, along with the development of code for
collecting data from a digital thermometer and online services.
This was followed by the evaluation of Freedomotic and its selection as the middleware to
use. Some initial development tasks were also performed (simple objects and plugins, in
preparation for the next iteration).
The final development iterations involved integrating the sensor and online services through
plugins and respective objects, followed by a testing and fixing phase.
Although the report was constantly being updated along with the development, some time
was reserved before preliminary delivery to finish off the report.
One more week was reserved for a final review of the work, followed by the scheduled dates
for report delivery and project defense. After the report review, it was planned the preparation
of the final presentation.
Figure 13: Final schedule for the second semester
1 Development Mon 15-02-09 Tue 15-08-11
2 Requirements, study
OpenIoT
Mon 15-02-09 Thu 15-03-19
3 Temperature sensor and
services
Fri 15-03-20 Mon 15-04-20
4 Study Freedomotic; initial
development
Tue 15-04-21 Thu 15-05-28
5 Sick days Fri 15-05-29 Fri 15-06-12
6 Objects and plugins Mon 15-06-15 Tue 15-07-28
7 Testing and bug fixing Wed 15-07-29 Tue 15-08-11
8 Completing writing of report Wed 15-08-12 Tue 15-08-25
9 Preliminary report delivery Tue 15-08-25 Tue 15-08-25
10 Final review of report Wed 15-08-26 Mon 15-08-31
11 Final report delivery Wed 15-09-02 Wed 15-09-02
12 Preparation of project
presentation
Tue 15-09-01 Fri 15-09-04
13 Final project defense Mon 15-09-07 Mon 15-09-07
07 15 23 03 11 19 27 04 12 20 28 06 14 22 30 07 15 23 01 09 17 25 02 10 18 26 03
'15 Feb 08 '15 Mar 01 '15 Mar 22 '15 Apr 12 '15 May 03 '15 May 24 '15 Jun 14 '15 Jul 05 '15 Jul 26 '15 Aug 16 '15

35
3.4. Requirements
Requirements were initially specified in the form of user stories, statements with the format
As a <role>, I want <goal/desire> so that <benefit>.
These statements use the stakeholder’s language to transmit his or her desires of what the
product should do, capturing those expressed needs into simple requirements.
Following is a list of the captured user stories discussed with the company supervisor, along
with their identification:
US.1 As a user, I want an intelligent irrigation control system so that I can benefit from water
and energy savings.
US.2 As a user, I want an intelligent irrigation control system so that my plants grow healthy,
never lacking or getting too much water.
US.3 As a user, I want the system to have an interface for monitoring and manual control so
that I can be informed about the status of my garden/plantation or manually control it.
US.4 As a user, I want to access the system from anywhere so that I can still use it when I’m
away, on vacation for example.
US.5 As a user, I want to be able to connect sensors so that I can monitor parameters and
specify actions to occur according to those parameters.
US.6 As a user, I want the system to be able to connect to valves so that it can perform
control, not only monitorization.
US.7 As a user, I want the system to gather information from the Internet (for example
weather, soil type, plant requirements) so that it can better decide what actions to take.
US.8u As a user, I want the system to have possibility of expansion so that I can connect
devices from different manufacturers and use them with the system.
US.8d As a software developer, I want the system to have an open interface so that I can
develop my own software to interact with it.
US.8m As a device manufacturer, I want the system to have an open interface so that my
devices can be made compatible with it.
From this list, more detailed requirements were derived in the form of discrete items that
could be implemented during an iteration, prioritizing them with the MoSCoW technique.
Those requirements are presented next, grouped by their type: user interface, functional and
non-functional.

Study, design and development of an integration component with sensory features of objects through IoT middleware

Study, design and development of an integration component with sensory features of objects through IoT middleware

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (17)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Study, design and development of an integration component with sensory features of objects through IoT middleware

Ähnlich wie Study, design and development of an integration component with sensory features of objects through IoT middleware (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Study, design and development of an integration component with sensory features of objects through IoT middleware