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 [email protected]

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


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”

ii

iv


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).

vi


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 Zig

bee

RFI

D

WiF

i

Blu

etoo

th

Sens

or

(oth

ers)

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).

http://www.bluespray.net/

http://greeniq-systems.com/


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.

https://www.rach.io/

http://irrigationcaddy.com/

http://www.roslen.com/


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

http://www.rainmachine.com/

http://www.skydrop.com/

http://www.ugmo.com/


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).

http://postscapes.com/smart-irrigation-controllers


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-142 Project analysis Tue 16-09-14 Fri 26-09-143 Analysis of references provided Mon 29-09-14 Fri 17-10-144 Research on architectures Mon 20-10-14 Wed 29-10-145 Research on middleware Wed 29-10-14 Fri 21-11-146 Analysis of software to be used Mon 24-11-14 Tue 09-12-147 Detailing requirements Wed 10-12-14 Tue 16-12-148 Completing writing of the report Wed 17-12-14 Tue 20-01-159 Preliminary report delivery Wed 21-01-15 Wed 21-01-1510 Review of intermediate report Thu 22-01-15 Mon 26-01-1511 Intermediate report delivery Tue 27-01-15 Tue 27-01-1512 Preparation of project presentation Wed 28-01-15 Fri 30-01-1513 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 15p '14 Oct '14 Nov '14 Dec '14 Jan '15 Feb '15


1 Development Mon 09-02-15 Fri 12-06-152 Sprint #1 Mon 09-02-15 Fri 20-02-153 Sprint #2 Mon 23-02-15 Fri 06-03-154 Sprint #3 Mon 09-03-15 Fri 20-03-155 Sprint #4 Mon 23-03-15 Fri 03-04-156 Sprint #5 Mon 06-04-15 Fri 17-04-157 Sprint #6 Mon 20-04-15 Fri 01-05-158 Sprint #7 Mon 04-05-15 Fri 15-05-159 Sprint #8 Mon 18-05-15 Fri 29-05-1510 Sprint #9 Mon 01-06-15 Fri 12-06-1511 Completing writing of report Mon 15-06-15 Fri 26-06-1512 Preliminary report delivery Fri 26-06-15 Fri 26-06-1513 Final review of report Mon 29-06-15 Fri 03-07-1514 Final report delivery Mon 06-07-15 Mon 06-07-1515 Preparation of project presentation Tue 07-07-15 Fri 10-07-1516 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 1Feb '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-126 Objects and plugins Mon 15-06-15 Tue 15-07-287 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.


36

3.4.1. User interface

RI1 Login Priority: Must

Description: User authentication, permissions verification.

Elements: Username, password, submit button

RI2 Users management Priority: Must

Description: Add/remove users, specify information and permissions.

Elements: Usernames, permissions, other information.

RI3 Configuration Priority: Must

Description: Components management – definition of required parameters for the various elements.

Elements: Sensors, actuators, other elements (virtual devices for data aggregation and decision).

RI4 Data visualization Priority: Must

Description: Visualize device data.

Elements: Single values representing current status of devices, other representations such as charts for historical data.

RI5 Manual control Priority: Must

Description: Elements for manual control (for purposes such as performing tests).

Elements: control of actuators.

3.4.2. Functional requirements

RF1 Acquisition of soil moisture data from sensors Priority: Must

Description: Soil moisture is a factor that by itself indicates that the soil should be irrigated or not. It is essential to maintain the values of this parameter as much as possible inside the adequate interval for a given plant.

Input: sensor data.

Output: soil moisture data (%).


37

RF2 Acquisition of air temperature data from sensors Priority: Must

Description: Air temperature is correlated with the rate of water loss, either by soil evaporation or by plant transpiration (both increase as the temperature increases). This means higher temperatures may indicate additional water requirements; additionally, temperatures around 0 ºC should prevent irrigation, as water could freeze.

Input: sensor data.

Output: air temperature data (ºC).

RF3 Acquisition of precipitation data from sensors Priority: Must

Description: The occurrence of precipitation will supply water to the soil – its duration and intensity will reduce or eliminate the necessity of watering for a certain period of time.

Input: sensor data.

Output: actual precipitation data (mm).

RF4 Acquisition of meteorological data from web services

Priority: Must

Description: When the system doesn’t possess physical sensors, or in order to complement them, some data can be obtained from meteorological web services. These can supply local data for air temperature and precipitation, and some other measurements such as wind speed and air relative humidity, which can also influence water losses from the soil.

Input: data returned by the service – JSON (JavaScript Object Notation) or Extensible Markup Language (XML).

Output: data according to input values – temperature (ºC), relative humidity (%), precipitation (mm), and wind speed (km/h).

This service should act similarly to the virtual representations of physical sensors.

RF5 Acquisition of weather forecast data from web services

Priority: Should

Description: Weather forecast data collected from a web service for a given period of time in the future (normally 3 days to 1 month). The types of data available should match those of current weather data, but they have always a degree of uncertainty associated. Weather forecasts allow making decisions by anticipation, instead of reaction to current conditions.

Input: data returned by the service – JSON or XML.

Output: data according to input values – temperature (ºC), relative humidity (%), precipitation (mm), and wind speed (km/h).

Representation should be the same as in requirement RF4.


38

RF6 Acquisition of data from other sensors Priority: Could

Description: Acquisition of data values from other sensors beyond those mentioned in the previous requirements, which might complement even more the information about the current environment and might allow to better assess irrigation necessities. Examples:

For current conditions (irrigation): • Soil – temperature; • Air – relative humidity, wind speed, pressure; • Other – luminosity.

For current conditions (soil suitability): • Soil – minerals concentration; • Water – pH;

Other types: • Water flow rate (would allow a historical record of water utilization and/or leak

detection); • Water level sensor (in case of using water from a reservoir, to avoid reaching an

empty level); • Webcam (indication of changes in luminosity or in the colour of leaves/fruits).

Input: sensor data.

Output: processed data with values and units in agreement with the sensor type.

RF7 Dispatch of control actions to actuators Priority: Must

Description: Irrigation actions will be performed by opening or closing valves, respectively starting or stopping irrigation.

Input: activation/deactivation of the actuator (on/off event).

Output: open/close valve according to input.

* in case of using pumps instead of valves, operation should be analogous; the same applies when managing a system to supply nutrients instead of water (the flow of a solution with nutrients or pH to the soil can be performed through the opening of valves).


39

RF8 Automatic control Priority: Must

Description: Smart control based on sensor data – trigger irrigation actions when necessary according to the values provided.

Input: values from sensor devices; parameters defined for each device.

Output: activation/deactivation of the necessary actuators (on/off events).

Examples: • If soil moisture < 3 % too low, start irrigation; • If soil moisture > 70 % too high, water being wasted (runoff), stop irrigation; • If air temperature <= 0ºC freezing conditions, deactivate irrigation.

RF9 Manual control Priority: Must

Description: By direct action of a user upon an actuator device representation, the status of the associated physical device is changed accordingly.

Input: user action (turn on/off).


RF10 Definition of an irrigation schedule Priority: Should

Description: Definition of a schedule by the user, acting as a fall-back when no sensor data is available to perform automatic control actions.

Input: user defined start and duration of irrigation events.


* include the possibility of specifying sunrise/sunset as references instead of fixed times.

RF11 Sending notifications Priority: Should

Description: When certain limits are exceeded (defined automatically or by the user), notifications should be sent to report the situation to a user. This is important mainly to warn about the occurrence of failures, but also to inform the user about events.

Input: An event has an associated value that falls within the defined interval, triggering a corresponding notification and eventually an automatic action.

Output: A notification message is sent (through notification services – e-mail, SMS or push service to the back office or mobile application).


40

RF12 Abstraction of physical devices Priority: Must

Description: The integration of physical devices (sensors and actuators) in the system has to be independent of brands/models. Those devices shall present themselves to the system through an appropriate abstraction for their type (a digital thermometer of a certain brand/model should appear simply as a generic virtual device which reads temperatures).

RF13 Device location Priority: Should

Description: Physical devices shall provide information allowing the user to locate and identify them.

Information: Identification code, latitude, longitude, code/name for the location (for small or closed areas in which proximity of sensors is smaller than the latitude/longitude error). Some information could be gathered upon device installation by using a smartphone to configure and automatically acquire latitude/longitude data.

RF14 Remote access via browser Priority: Must

Description: The system shall provide a web interface for remote access.

RF15 Remote access via API Priority: Should have

Description: The system shall provide access through a well-defined interface to allow interaction with remote applications or other systems.

3.4.3. Non-functional requirements

Portability – The platform will be able to function on different combinations of hardware and Operating Systems. In addition, it should maintain that portability when integrating different physical sensors and actuators (according to requirement RF12).

Usability – The user interface shall be friendly and simplify the representation of multiple devices (using analogies with the physical reality for those representations).

Security – Mechanisms have to be in place to control access to the back office, APIs and data, and to verify permissions to perform certain actions.

Scalability – Appropriate to the purpose: while not excluding applications on a professional or industrial level, this project was conceived as a household application. It is expected to have to manage at most tens of devices, but it should be able to accomplish that task while running on low resources hardware.

Reliability – resistance to failure, sensor redundancy.


41

3.5. Risks

A software project always has associated risks that can compromise certain goals or even cause the whole project to fail. This prompts an assessment of risks in order to prepare mitigation strategies to minimize or eliminate the impact of those risks.

The following list describes the identified risks; it is intended to be dynamic, where risk assessments may be updated or added/removed along the course of the project.

Risk 1

Lack of hardware to test and better demonstrate the product.

Description: This project is related to IoT, but there is a high probability that no physical devices (sensors/actuators) will be available to use for testing and demonstration.

Probability: High Impact: Low

Mitigation: The virtual sensors/actuators representing the respective physical devices will have to simulate as best as possible the behaviour of those devices.

Risk 2

Failure to correctly assess the time needed for certain tasks.

Description: Some inexperience may lead to incorrect estimates of the time necessary to perform certain tasks, eventually leading to delays.

Probability: Medium Impact: Medium

Mitigation: Seek advice with supervisors, divide the Sprint backlog in small tasks and allocate more time to account for unpredicted delays.

Risk 3

Failure to correctly define item priorities.

Description: The integration of certain items from the Product backlog is more important than others. Incorrect prioritization may cause important features to be left out due to lack of time, while lesser features are implemented.

Probability: Low Impact: Medium

Mitigation: Establish priorities at Sprint planning meetings, and if necessary re-evaluate priorities during progress report meetings.


42

Risk 4

Incorrect or incomplete understanding of the scope of the project.

Description: A misunderstanding of certain parts of what is to be done in the project may lead to a result which is less satisfactory than expected, or it may lead to delays due to too ambitious goals.

Probability: Medium Impact: High

Mitigation: Communicate regularly with supervisors, addressing this problem specifically to assess if the proposed goals are reasonable.

Risk 5

Inadequacy of the selected middleware for this project.

Description: This project was initially targeted mainly at industrial use. Some changes had to be made, shifting the focus to home use. Based on those changes and feedback from the intermediate defence, it is possible that the selected middleware may not be the most appropriate for the defined focus and requirements (even though some care was taken to ensure could be used on a smaller scale, which is the case of home use).


Mitigation: Test the middleware software, evaluating its maturity and suitability for the current case. If necessary, evaluate the other middlewares in the same manner. As a last resort, test middlewares that were initially found not suitable (and thus not included in the State of the Art) but that may be the most adequate for the current case.

Risk 6

Failure to meet the deadlines.

Description: This internship takes place during the academic year, having deadlines clearly defined according to that calendar. Any major obstacle arising from the previously mentioned risks, or for other reasons, may prevent the successful completion of this project.


Mitigation: Apply the mitigation strategies devised for each risk. If necessary, allocate extra time to work. In case the July deadline is missed, reschedule the final defence for September.


43

Chapter 4. Work performed and Results

4.1. Introduction

This chapter presents an overview of the work done and the progress made towards fulfilling the objectives of the project.

As mentioned in the Planning section on the previous chapter, the first semester of the internship consisted mostly on getting acquainted with the project and its goals, and on researching relevant information. The second semester was concerned mostly with the development of the platform.

The first step to support development was the definition of an architecture. The IoT-A project provides a good foundation and the recommendations of that project were used in this work. The basic concept on how to represent devices is expressed in Figure 14.

Figure 14: Representation of a device in a generic IoT system.

A Physical Entity is basically a model of a Device and it is represented in terms of software by a Virtual Entity. The composition of both Physical and Virtual Entities constitutes an Augmented Entity. Virtual Entities in turn have Resources and Services associated with them, in which the Services expose those Resources.

The Resources are hosted on the Devices and keep information about the Physical Entities or information on how to act upon them.

With these basic concepts established, which can be applied in general to any IoT project, the next step was to define a global architecture integrating the selected middleware.


44

4.2. Testing the middleware

The initially selected middleware was OpenIoT. It worked as described but only when using the virtual machine image supplied in the project website. Using different methods of deploying packages (even those pre-built inside the image) in the application server caused the software to malfunction (namely in the authentication modules).

Dealing with the errors/warnings was considered, but several other difficulties appeared. The documentation lacked detail in some parts and had inconsistencies in regard to configuration files. The requirement of a JavaEE application server coupled with the large size of source code and compiled packages, indicated that the hardware demands might not be desirable for something intended for home use.

Furthermore, the main focus of OpenIoT is to aggregate data from sensors for visualization and monitoring. Little attention is devoted to presenting an interface for the user to take actions, and to forward those actions to actuators.

Other middlewares presented more or less the same problems, aggravated by the proprietary nature of some components, for which the source code was not readily available.

From the projects researched but initially left aside due to inadequacy to fulfil the original goals, Freedomotic was tested. This software has low hardware demands and its features cover many of the requirements for this internship’s project. Compilation completed successfully passing all the specified tests and no major obstacles were initially found during functioning.

4.3. Global architecture and mode of operation

Having selected Freedomotic, its architecture (presented in Figure 9 on page 23, in Chapter 2 – State of the Art) was adopted for use in this project. The required sensors and actuators, integration of web services and representations of objects not already provided by the middleware were implemented, as much as possible, as plugins. The purpose of this decision was to avoid changing the main application, in order to benefit from the development of future versions bringing along bug fixes, more features and broader support for hardware devices.

The basic class representing a Thing in Freedomotic is EnvObject. This class describes the main characteristics of a Thing in the environment: identification, representations, behaviors and the ways it can interact with the environment (other things or users). Things are stored in the application through the serialization of this class.


45

The class EnvObjectLogic incorporates EnvObject (as a field), providing several methods to perform operations on it. This class serves as a template for the creation of Freedomotic objects.

Object behaviors (the properties the user wants to monitor or control) are defined as implementations of the interface BehaviorLogic. Some base behaviors are available, such as boolean or ranged integer (for example to represent ON/OFF status, or a value bounded by a minimum and maximum, respectively). Definition of higher level behaviors such as temperature or humidity are therefore defined as instances of these bases.

Initially, depending on a template, objects can be considered virtual or not (if they have an attachment to a data source – a plugin). In order to establish correspondence with physical devices, an object must be marked as not virtual, and a protocol and an address must be defined. The protocol just indicates the plugin being used, while the address provides data specific to the protocol (for example, the IP address of network device or web service, or board/ports to be used in Arduino devices).

These classes already provide representations of Things on user interfaces, even allowing interaction with them. However, these are only virtual representations of objects. Interaction with physical objects or web services is accomplished using plugins that translate generic data/commands from Freedomotic to the specific counterparts used in those devices/services and vice versa.

The concept is similar to the one used for Things. Basic information about the plugin (name, version, configuration) is represented by the class Plugin. It is also used in serialization to store that information. The class Protocol extends it with more functionalities, serving as a template for concrete implementations of plugins.

Finally, interactions concerning either virtual objects or plugins involve events. The various concepts present in these interactions were addressed in the State of the Art and are better illustrated in Figure 15.


46

Figure 15: Interactions in Freedomotic, from Freedomotic components interaction in the Freedomotic Wiki [33].

Any plugin can create an event: sensor plugins for devices/services, frontend plugins for direct user interactions, and other plugins for automated actions. Triggers can be activated from those events, if they are consistent with a set of specified conditions. This may cause properties of virtual objects to change (such as an image of a light appearing ON) and/or to perform certain commands (specified in reactions to triggered events).

4.4. Development

The repository with the original Freedomotic source code was cloned from the GitHub project page (https://github.com/freedomotic/freedomotic).

The fork thus created (at https://github.com/jmf-tls/freedomotic) established a code base to work, mostly to apply bug fixes and propose their integration back into the original code. An important part of the development was concerned with analysing the code to understand how it worked, and with identifying the causes of errors, writing corrections when needed.

A private repository (on Bitbucket, which offers that service for free) was also created to host the changes specific to this project – as a personal work to be developed under this internship, it wouldn’t be suitable to share it allowing collaboration from the global community.

To separate the artifacts developed in this project from those of the main application, a project folder was created inside the freedomotic-plugins folder. Object plugins were created under “extra-objects”, while each device/web service plugin was created in its own folder.

https://github.com/freedomotic/freedomotic

https://github.com/jmf-tls/freedomotic


47

4.4.1. Analysis, tests and bug fixing in Freedomotic

During development, in situations where the documentation was inexistent or insufficient, it was necessary to analyse the code of the Freedomotic framework and the available plugins, to find out how the required functionalities worked.

In many of those situations I found that things didn’t work as described, either because of bugs in the code or simply because the plugins were outdated. This posed additional obstacles that required a further testing and a deeper analysis of the framework to correct those situations.

The contributions to the main Freedomotic project included: − updating plugins to the current API level; − fixing bugs in the Freedomotic core and Java frontend (user interface); − adding enhancements to the core and frontend, when those enhancements were

required by this project and couldn’t be implemented in a plugin.

At the time of writing this report several commits (under the username jmf-tls) were already accepted in the main repository, while some others were still pending.

4.4.2. Required objects

Freedomotic already provides some useful objects concerning weather data, such as thermometer, hygrometer and barometer. It also provides other objects related with home automation, like doors, lights, light sensors for example.

For this project, more objects were necessary. Most of them were required to simply act as a virtual representation of a measuring device (a sensor), featuring a single physical property. This was the case for the anemometer, flow meter, rain sensor and soil moisture sensors.

These were all created in this project by extending the class GenericSensor. To allow Freedomotic to recognize these objects and add them to the interface, XML template files were created for each of them. Among the information specified in these files is the sensor name, the measured properties (designated as “behaviors” in Freedomotic) and suitable representations (small pictures for the object).

Valve objects were another case of implementation simplified by the Framework. In this case we want to represent an actuator – a device that doesn’t need to represent a numerical value like a sensor, but requires a representation of its ON/OFF state. This object was developed by extending the ElectricDevice class. The XML template created for this object as a “powered” behavior to represent the ON/OFF state and 2 corresponding pictures for representation.

Finally, virtual objects that didn’t fit the simplicity of the ones previously described, required further development on the supporting Java classes. The implementation of these objects is clarified next.


48

GeoLocator

In Freedomotic neither objects nor the environment possess information about geographic location. Each object stores its position in the form of (x,y) coordinates, but that is merely an absolute position of its representation in the user interface. However, geographic location data is important for other plugins to be able to make calculations or to request information from services in which the current location is required.

To fulfil this need, the GeoLocator object was developed as a placeholder for geographic location data. The corresponding Java class extends EnvObjectLogic which, as mentioned before, is the parent class for things in Freedomotic. A XML template to allow creation of GeoLocator objects was also generated, to specify the representation of the object in the environment and default data.

Two behaviors, latitude and longitude, were defined for this object, both as ranged integers. The values for these behaviors can be specified directly in the user interface for this object, if the geographic coordinates are known. Otherwise, a device or service plugin is required to supply that information.

Such a companion plugin was developed for this project (location service, described in the next section). The XML template for the GeoLocator object already includes the location service as a predefined data source, so that all newly created objects of this type already use that plugin to get location data.

In order to automate the use of the plugin, this class specifies a Trigger (“when this object is clicked”). Creating an automation is simply a matter of accessing the Automations tab in the object interface and binding the trigger to the “update location” command of the location service plugin. The end result is that clicking a GeoLocator sends a request to that plugin, which returns data to update the object.

An important remark is that all GeoLocators, upon creation, already define location service as the protocol to use (basically, the plugin to use); the address (defined in the Properties tab in the user interface of objects) should contain a string identifying the current location (for example, “house Coimbra”). The purpose is to allow placing GeoLocators in distinct environments corresponding to distinct locations, and to update each one independently.

WeatherForecast

The idea here was to have an object aggregating several weather related measurements, instead of having separate objects for each one. It was already mentioned that at the time of this project, objects representing thermometer and barometer were available, but not objects to represent anemometers or rain sensors; furthermore, a single object representing all of them was also unavailable.

One of the main contributors of Freedomotic started creating a similar object, weather-thing, but it wasn’t yet integrated. Likely to be adopted in the main repository, it served as a reference to have common designations for weather-related behaviors, both for the WeatherForecast object and for the individual objects (“temperature”, “pressure” and “humidity” were


49

designations already present in Freedomotic objects; “rain”, “wind-speed” and “wind-degree” were adopted from weather-thing for the objects developed in this project). This weather-thing object also includes a “conditions” behaviour which stores a designation of the current weather conditions (clear sky, cloudy, etc.). While this isn’t very relevant for the needs of this project, it was also included in the WeatherForecast object.

Finally, two other concerns had to be addressed: the storage of forecast information and the specification of the current location.

Weather forecast information is important mostly to indicate if an irrigation schedule can be reduced or eliminated, thus utilizing rainwater. Since this is a structure containing values for several measurements, including rain and temperature for example, along with the respective times, a “PropertiesBehavior” was used to store that information into a property in the object.

The current location is specified by pointing to a GeoLocator object. It is only necessary to supply the name of the intended GeoLocator in the address of the WeatherForecast object (in its user interface).

Like the GeoLocator, this object is created by a Java class extending EnvObjectLogic and a corresponding XML template. Also like the GeoLocator, this object has a corresponding weather service plugin (WeatherUnderground) to retrieve the necessary information from an online service provider. Having specified a GeoLocator as the address, and having the protocol predefined (by the XML template) to use the weather service, is sufficient to receive data – the service plugin automatically updates this object periodically.

MockValve

This object was developed for two purposes: to learn more and to experiment with the Freedomotic API, in preparation for the development of the more complex IrrigationController object; to have another demonstration of the capabilities of the software, since the only physical device used was a digital thermometer.

A limitation of Freedomotic objects is that for each behavior only one data source can be directly specified. For the irrigation controller it should be possible to acquire data from several sources, such as multiple thermometers. Likewise, for a controlled valve its “powered” status should be acquired from a data source from the plugin interfacing with its corresponding valve physical device – even though it is possible to use the graphical interface to activate or deactivate the valve, an irrigation controller should also be able to control it.

This object is similar to the Valve object, in which both use the same image for representation and both are an extension of an ElectricDevice (thus having a “powered” behaviour). The MockValve simply adds a list of target flow meters in order to indicate which one would be affected when that valve is opened/closed.

A companion MockValve plugin was developed, where most of the logic resides. It is further explained in the next section.


50

IrrigationController

Once the MockValve was completed, it was easier to create the IrrigationController object, require by this project. Like other objects mentioned in this section, this is also composed of a Java class and a XML template.

Like the MockValve, this was developed to be a placeholder for data and a model for representation in user interfaces, so the user can visualize data, perform actions and set parameters. Also like the MockValve, it has a corresponding plugin where the code for control is effectively located.

This object has boolean behaviors (power on/off, irrigation on/off), ranged integer behaviors (default irrigation duration, irrigation time remaining) and lists (for source sensors and target actuators).

4.4.3. Required devices/services plugins

Whereas the object plugins provide a representation of objects, device plugins provide the means to interact with physical devices (and also web services).

Freedomotic provides an online repository where prebuilt plugins can be downloaded. Those plugins (and also the ones available locally, such as those developed in this project) must be placed in the plugins folder so that they can be loaded and used in the application (the lifecycle of these plugins is shown in Figure 16).

Figure 16: Lifecycle of a plugin, showing both polling and push modes of operation.

Device plugins can be started automatically or by user interaction, depending on their configuration. After being started, they interact with Freedomotic by listening to events or by executing received commands; if necessary, they can directly access virtual objects through the API.

The configuration decides their mode of operation: upon starting they can start a new thread that will collect data from the attached device whenever it is read (push mechanism); or they

Loaded

Started

onStop onStart

onRun Thread run

POLLING

onEvent

onCommand

PUSH


51

can specify a polling period defining a time interval for Freedomotic to request data (polling mechanism).

Regardless of the mechanism that may be more suitable to a device or service, the collected data is sent to Freedomotic using event notifications.

In Freedomotic the acquisition of data doesn’t necessarily require a physical device directly connected to the machine running the software. A Freedomotic plugin can just as well interface with a remote service, providing data from measurements of remote devices, or any other kind of data.

Thermometer device plugin

A digital thermometer was available and was used to illustrate how a real device would be represented on the software.

Even though using this specific device was not required, its inclusion in this project highlights the interaction between the real world and the software in a way that wouldn’t be possible otherwise (no other devices were made available).

The hardware is an Oregon Scientific I300 weather station, composed of 3 devices communicating wirelessly:

- a temperature sensor (remote); - a screen (remote) which presents data from the embedded temperature and humidity

sensors, and from remote temperature sensors, along with date, time and weather forecast transmitted from the Universal Serial Bus (USB) hub;

- a USB hub (Figure 17), which connects to a computer; it collects temperature readings from its embedded sensor and from remote temperature sensors to show on a proprietary software, and uses that software to collect weather forecast information which it then transmits to the screen.

Figure 17: IH300 USB hub from Oregon Scientific I300 weather station.

For this project only the USB hub embedded sensor was used for temperature data. The communication protocol between the hub and the software didn’t have any official documentation available. However, some information (from reverse engineering) for other devices from the same manufacturer was found, which prompted me to check if it could be applied to this one. This information allowed to know the packet separator, the code for

Device manufacturer:

Manufacturer website: http://global.oregonscientific.com

Characteristics: Thermometer; optional extra thermometer and hygrometer.

http://global.oregonscientific.com/


52

temperature sensors, their positions at the beginning of packets, and that at least one byte was used for checksum.

Further analysis was required, so an inspection of the communication between the hub and the manufacturer’s Windows program (WeatherOS) was performed. The capture of data was accomplished using USBTrace (http://www.sysnucleus.com/index.html).

Figure 18: Initialization of the IH300 hub captured by USBTrace.

Figure 18 shows the initial exchange of information that occurs when the device is connected and the manufacturer’s program is active. The highlighted packet is the first one sent to the device and performs initialization. In this case it was also noticed that, unlike other devices from Oregon Scientific, packets are restricted to 8 bytes. Thus I deduced that a data packet should be composed of a group of sequential input or output raw packets.

Most of the raw packets begin with “07”. Lower values only appeared at the beginning (along with the separator bytes) or at the end of each transmission, which hinted that the first byte was the number of bytes to consider in each raw packet.

Knowing the code signalling a temperature data packet allowed to isolate and analyse a group of raw packets that compose it.

01 FF 01 0F 2B 18 11 0E

07 FF 00 42 80 CD 00 1C

07 14 00 00 20 0F 33 18

06 11 0E 12 01 0F 2B 18 Figure 19: Example of a capture of all data transmitted for a temperature measurement.

The example in Figure 19 shows 8-byte raw packets, each represented on a line, for a temperature data packet. The first byte indicates the number of data bytes – in the first line only one byte is used, the others are carried over from the previous packet and are ignored (the same applies to the fourth packet).

http://www.sysnucleus.com/index.html


53

The bytes representing the current temperature were found by converting all bytes to decimal values and comparing with the current value shown on the WeatherOS user interface.

Furthermore, the following bytes coincided with the date/time of the capture. Finally, by performing an exclusive OR (XOR) operation sequentially on all the bytes, it was found that the penultimate byte corresponded to the XOR of all the previous. This left the final byte to represent an additional check, using an unknown algorithm.

For this particular measurement, the bytes extracted from the USB packets would then be FF FF 00 42 80 CD 00 1C 14 00 00 20 0F 33 18 11 0E 12 01 0F 2B where the interesting bytes are emphasized:

− FF FF is a separator; − 42 is the code for temperature; − CD 00 is the measurement (CD hexadecimal = 205 decimal 20.5 ºC); − 0F is a checksum (XOR); − 2B is an error-detection code (later found to be CRC-8-CCITT); − remaining bytes carry additional information like date and time.

A major difficulty appeared at this point, as the initialization packet was only enough to return a single temperature measurement. The WeatherOS program was sending further initialization data before temperature measurements could be returned regularly from the device. More captures revealed that weather forecast information, obtained from an online service, needed to be sent to the remote screen (this required to setup a local server providing static information, as the original Oregon Scientific server is no longer functional).

Figure 20: CRC functions in WeatherOS.exe, disassembled and converted into C code.


54

Although most of the needed content was identified, knowledge of the final check algorithm was required in order to build valid packets. To not waste the time spend in the analysis carried out until this point, a final effort was performed using IDA Disassembler and Debugger (https://www.hex-rays.com/products/ida/index.shtml) to find out the missing parts.

Some documentation for these kind of devices pointed to a cyclic redundancy check (CRC), which in this case should be 8-bit. While debugging with IDA, I searched for functions named “CRC”. A SetCRC function was found, which was being called right before sending and also after receiving data. Figure 20 shows the C code for that function, resulting from disassembly and conversion. We can see that first the nibbles in each data byte are swapped and then the result is used to calculate a CRC code (an implementation using the CRC-8-CCITT polynomial). This knowledge finally allowed to send the additional initialization packets (with arbitrary data) to obtain data from the device.

Finally, all this information was used to develop a Freedomotic plugin to allow the collection of temperature data from the sensor. The plugin required the use of the HID4Java library (https://github.com/gary-rowe/hid4java) in order to communicate with USB Human Interface Device (HID); this library in turn uses JNA (Java Native Access) and various native libraries, to use USB under different operating systems and machine architectures.

Temperature readings from the device occur at approximately each 5 seconds, but the process can be interrupted at any time with requests for more weather data. Due to this, the plugin implements a push mechanism, only sending data to Freedomotic whenever a temperature reading is received from the device. Data is transferred using events, sending values associated with a “temperature” behaviour, targeted at a Thermometer object.

Location Service

As mentioned in the GeoLocator object, the Freedomotic API has properties related with the location of objects in the environment (which should match their physical location), but not their geographic location.

For this project only the approximate geographic location of the environment is required. Positioning devices generally available usually aren’t capable of enough precision to distinguish the location of close objects, especially in a home environment; basic information about the region should be enough for this project (information that can be acquired from approximate location includes sunset/sunrise times and local weather data from web services, normally won’t vary much within a certain region).

Skyhook was chosen as provider, since it offers the needed data and has both a simple API and registration process. Google offers similar services but currently requires billing to be enabled, which in turn requires registration with a credit card.

Service provider:

Provider website: http://www.skyhookwireless.com/

Characteristics: Latitude/longitude information from IP address or WiFi networks.

https://www.hex-rays.com/products/ida/index.shtml

https://github.com/gary-rowe/hid4java

http://www.skyhookwireless.com/


55

After registration the service offered a client (Windows executable) to communicate with the API. Though the documentation of the API wasn’t detailed about the data required to be sent, the executable generated logs which allowed to extract the necessary information. For each request, an HTTP POST with authentication information in the body (XML format) is sent to the API address at https://api.skyhookwireless.com/wps2/type, where type stands for the intended location method. The API returns information, also in XML format, containing the latitude/longitude coordinates.

The location method can be either ip-location, where coordinates are estimated from the current IP address, or location, where a better estimate can be attained from the list of nearby WiFi networks.

The IP location method always works, provided that a network connection is available and the service is available. The accuracy of this method depends on the network configuration: if the service gets the IP address of a proxy server, for example, the reported location may be on another region, or even another country.

The WiFi method can be more accurate, but requires a WiFi network card. To gather wireless network information generally available utilities were used, specific for each OS (netsh in the case of Windows, iwlist for Linux based OSs). Directly using OS calls was avoided, because they would be more specific to OS versions and would likely require administrator privileges. After determining OS type, the Java class responsible for WiFi information executes the respective utility and parses the output. The list of access points found and their data is sent to the Skyhook API – for each access point, the relevant data consists in Media Access Control (MAC) address, Service Set Identifier (SSID – network name) and signal strength (dBm).

In this plugin was also included a command template (“Update location”, specified in a XML file) so that objects can use it to initiate a location request. In response, events are sent to the objects with the requested values for latitude/longitude. Since geographic location isn’t expected to change frequently, the included command is the only way to request data from this plugin; periodic mechanisms like pull or push are not used.

WeatherUnderground

As part of this project, a stated goal was to use weather data from web services. A Freedomotic plugin is available to get weather information from other providers, but it doesn’t contemplate weather forecasts, only current weather.

Weather Underground was selected as provider, since it offers all the data that was deemed relevant to use in the project. The service requires registration to obtain a key – the “Anvil Developer” plan was chosen, as it provided the most features while still being free and allowing a reasonable number of calls to the service.

Service provider:

Provider website: http://www.wunderground.com

Characteristics: Current and forecast weather from current location.

http://www.wunderground.com/


56

The Weather API is described at a dedicated page, listing the various features, supported by examples (http://www.wunderground.com/weather/api/d/docs?d=index). Each request is accomplished by using HTTP GET to the API address, composed of the information: http://api.wunderground.com/api/key/features/settings/q/query.format

− key refers to the API key obtained when registering the service; − features specifies the combination of data features needed in the response – in this

case, conditions and hourly were used, corresponding to current weather and hourly forecast for the next 36 hours respectively (sunset/sunrise times, less detailed forecasts, historical data, among other things might also be requested);

− settings indicates optional parameters; − query identifies the current location – the latitude/longitude format was used for this

project, but it also supports city name or zip code; − format to choose the output format between JSON (the one selected) or XML.

The API documentation is very limited in regard to information returned in the response. Only the expected field names are listed, with no description of their meaning, or even types and ranges of values. Therefore several queries were tested for various locations (with known current and forecast weather conditions obtained from the main web site), to find out the meaning of fields.

The example query http://api.wunderground.com/api/key/conditions/hourly/q/lat,lon.json (where the terms in italic are the actual key, and latitude and longitude are coordinates for the city of Coimbra, Portugal) returns the following structure (only relevant information is shown): "response": { … , "features": { "conditions": 1, "hourly": 1 } }, "current_observation": { … , "display_location": { "full": "Coimbra, Portugal", "latitude": "40.220000", "longitude": "-8.450000", … }, … , "local_epoch": "1438792444", … , "temp_c": 27.0, "relative_humidity": "42%", … , "wind_kph": 12.6, "wind_gust_kph": "15.8", … , "precip_1hr_metric": " 0", … , "precip_today_metric": "0", … }, "hourly_forecast": [{ "FCTTIME": { … , "epoch": "1438794000", … , }, "temp": { "english": "79", "metric": "26" }, … , "wspd": { "english": "10", "metric": "16" }, … , "humidity": "45", "qpf": { "english": "0.0", "metric": "0" }, … },

{ "FCTTIME": … } … … … ]

http://www.wunderground.com/weather/api/d/docs?d=index


57

From this and other responses, it was possible to infer the needed information: − for current weather, the interesting fields were those labelled with epoch (Unix time),

temp (temperature), relative_humidity, wind and precip (precipitation). The respective units are part of the field name (for precipitation it is mm). Measurements with both metric and “english” units are provided in the response, but for this project only the metric units were used.

− for weather forecasts the response contains an array of JSON objects. Each object corresponds to data for 1 hour intervals in the requested 36 hour period and contains date/time information, along with the fields labelled temp, wspd, humidity and qpf (temperature, wind speed, relative humidity and precipitation respectively – “qpf” stands for quantitative precipitation forecast).

After collecting and processing all the information, this plugin sends data using event notifications to virtual objects. Each data type (temperature, humidity, wind, precipitation and forecast) is sent separately, so it can be reflected in individual objects such as a thermometer. This data can also be represented in a single object created for this purpose, the WeatherForecast object.

This plugin gets the required location information from the available GeoLocator objects.

The API from Weather Underground doesn’t send notifications when new data is available, so this plugin uses a polling mechanism to periodically check the service.

Sunrise/sunset

This information is relevant to the conservation of water. Irrigation before sunrise or after sunset will minimize losses to evaporation and maximize absorption into the soil (this interval corresponds to the period where solar radiation doesn’t fall directly on the soil).

Several online services are available that can provide this information. However, it is possible to calculate sunrise and sunset times for a given date with good accuracy, provided we have location information (such information would be nevertheless required for online services also). This way the corresponding events can be generated, without depending on network connectivity or service availability.

To develop this plugin a library implementing a Sunrise/Sunset algorithm was used to perform calculations. It is available at https://github.com/mikereedell/sunrisesunsetlib-java and it is based on the algorithm published on the Almanac for Computers (1990) published by Nautical Almanac Office (United States Naval Observatory).

This plugin is responsible for creating the events which signal the sunrise/sunset at the appropriate times, so other objects can use them. Like the WeatherUnderground plugin, it also uses the GeoLocator object to get the current location.

https://github.com/mikereedell/sunrisesunsetlib-java


58

MockValve plugin

This plugin serves as an extension to the MockValve object presented before. It provides an interface for simulating both a physical valve (thus receiving open/close commands from the MockValve) and a flow meter (providing water flow measurements to a FlowMeter object).

One of the functions of this plugin is to gather a list of FlowMeter objects already present on the API and provide that information on the flowmeter behaviour of MockValve objects. It is then possible to select a target FlowMeter upon which the actions that MockValve will be reflected (thus increasing or decreasing flow).

When any of these objects is created or deleted, the lists are updated. This relies on the synchronization mechanism of the API, normally used to notify remote Freedomotic instances of changes to local objects, by listening to change events and updating the lists accordingly.

Figure 21: Analogy of the MockValve plugin and the respective physical devices/plugins.

The other main function is to act as a device plugin for valves and flow meters (thereby simulating the corresponding physical devices). The analogy between how a real valve and a real flow meter would be managed by Freedomotic, and how the MockValve simulates that scenario, is represented in Figure 21.

A real valve interacts with the software through an adequate valve plugin, which reads the status and updates the Freedomomtic object accordingly, and also sends open/close commands from the API. Likewise, readings from the real flow meter are gathered and interpreted by the flow meter plugin, which then updates the corresponding Freedomomtic object.

The MockValve plugin performs the same functions as the valve and flow meter device plugins. However, instead of routing commands to physical devices and gathering their data,

Freedomotic

Flow meter

Valve

Physical devices Simulated devices

Flow meter device plugin

Valve device plugin

MockValve plugin


59

it internally bypasses the need for physical devices, acting like valve and flow meter plugins directly passing information between each other.

IrrigationController plugin

This plugin is the extension to the IrrigationController object, containing the logic to gather data from sensors and for controlling actuators. Its development was supported by the preliminary work in the MockValve plugin.

Similar to the MockValve plugin, it is responsible for gathering a list of potential data source objects for IrrigationControllers. The suitability of objects is evaluated according to the behaviors they contain (for example, a thermometer would be a suitable source, as it measures temperature). Essentially any object containing a weather related data can be selectable as a source. Targets objects can be valves, but other objects that can be turned on/off like pumps are suitable as well (the types of target objects are defined on a list, initially only valves are allowed).

In order to have data to decide upon irrigation times, minimum and maximum values of each source behavior (e.g. temperature) since last irrigation are maintained. This avoids depending on the Harvester plugin, which is a solution for storing the measurements in a database.

Irrigation can be initiated by a defined trigger, or by a user on demand. The calculation of how much irrigation is necessary works as follows:

− If no sensors or weather services are available, just irrigate according to schedule, with a duration specified in the default irrigation time;

− If temperature and/or wind sensors are available (or that data from weather services) use their measurements to adjust the irrigation time;

− If a rain sensor is available (or that data from weather services), postpone or skip irrigation according to rain measurements;

− If weather services with forecast are available, use the information to adjust irrigation time, or to postpone or skip irrigation;

− If a soil moisture sensor is available, use it instead to irrigate to prevent water saturation. This sensor’s data can also be used to start irrigation when moisture is low. The availability of this sensor makes the use of other sensors unnecessary, however weather forecasts (if available) can still be used to postpone or skip irrigation.

After requesting the start of irrigation, and available data is used to adjust the process, the actuators (in this project, objects representing physical valves) are notified to let water flow (in the case of valves, open them). When the process is finished (due to reaching stop time or measuring soil moisture at top limit), both the IrrigationController and the target objects are notified.


60

4.5. Tests and verification of requirements

This project relied on testing to support development and to assess fulfilment of the requirements.

In the Thermometer device, Location service, WeatherUnderground and Sunrise/Sunset plugins, unit tests (using JUnit) were specified to support development. The test cases were specified to verify that the devices/services/libraries returned the intended results (in some cases, it was just a matter of getting a valid answer).

The freedomotic main software and some of its plugins also define unit tests. The changes I performed to fix bugs and introduce enhancements didn’t affect the outcome of those tests.

Finally, working system tests were performed to verify if the requirements were satisfied.

Regarding the user interface, User management and Data visualization (RI2 and RI4) were incomplete. User management can only be partially accomplished through the user interface, full functionality can only be achieved in the configuration files. Data visualization is also possible for each object, but representation of charts requires plugin (Harvester and Harvester-chart) which are quite outdated. Due to time constraints, derived from the initial problems with middlewares, this area was not further improved. An advantage of using Freedomotic was that in some degree all user interface requirements were satisfied from the beginning; many aspects were improved with my contribution to the software.

Concerning functional requirements, some sensor representations were initially available from Freedomotic, temperature (RF2) and others (relative humidity and pressure – RF6). Though a real device was only available for temperature, the plugin to acquire data from it demonstrated how the mechanism could be implemented, applying the same principles to other devices. Objects for soil moisture (RF1), precipitation (RF3), and wind speed and water flow rate (both in RF6) were missing in Freedomotic and were developed for the project.

Features related to the abstraction of physical devices were more requirements for the chosen middleware rather than something that was supposed to be developed in this project. Freedomotic satisfies RF7, RF9, RF11 and RF12.

Though plugins were available to acquire meteorological data from web services (RF4), the objects to hold that data were not implemented. Furthermore, those services, or at least their Freedomotic plugin implementation didn’t support weather forecast data (RF5). Plugins for this feature and to conveniently provide location information (RF13) were developed in this project.

Automatic control (RF8) and definition of schedules (RF10) are also features inherent to the middleware, namely through the use of trigger, commands and automations. However, for the more complex control actions required by this project, involving data from several sensors, the Irrigation controller had to be developed, thus satisfying RF8. The definition of schedules


61

is enhanced by the availability of sunset and sunrise times, through a plugin which was also developed for the project.

Remote access features (RF14 and RF15) were verified as already present (and working) in the base Freedomotic installation.

This platform met, at least in part, the specifications for non-functional requirements. These were also used as criteria for selection of the middleware. Scalability and reliability were less achieved, but they were also stated as being of lower importance overall, compared to the other requirements.

Figure 22: Freedomotic Java frontend during a test performed.

The tests were performed on a running instance of freedomotic. In Figure 22 we can see on the left pane the Weather Underground plugin activated, among others, and on the right, in the environment, the respective Weather Forecast object showing the stored measurements.

Other objects that were tested along with their plugins were the GeoLocator, the Thermometer (with the IH300 USB device), and the Irrigation Controller. On the top right there is also a Valve with an attached Flow meter.


62

4.6. Summary

Using a middleware such as Freedomotic was expected to save a lot of work. Even though it required some initial effort to understand how it works, there were several benefits: all user interface requirements for this project were satisfied from the start, at least in part; many sensor representations were implemented and others benefited from great simplicity in implementation.

However, like many other solutions tested, additional efforts were needed to find and fix bugs.

The availability of physical devices for use in this project was limited to the thermometer. A demonstration of the product fully working will not be possible, but some characteristics can be highlighted in a comparison with the capabilities of other kinds of systems.

Figure 23: Potential outcomes and problems in irrigation systems.

A comparison of the expected performance and potential problems in various irrigation systems is illustrated in Figure 23. Two lines are represented on each graph:

− Saturation occurs when the soil is not capable of holding any more water. At this point, any water added will simply drain away and won’t be used by the plants;

− Wilting point defines the minimal limit for moisture in the soil. If moisture decreases below this point the plants begin to wilt, as they cannot absorb water;

− Soil moisture should always be between these two lines.

Legend:

Saturation point

Wilting Point

Irrigation event

Rain event

Hot weather

Legacy system

System using only sensors

System using only online info

System using both sensors and online info


63

The system developed in this project can work in a similar way to any of the systems presented in the picture, depending on the availability of sensors and network connectivity (and availability of the online services). The picture also illustrates how a legacy system can be much improved by using several sources of information.

A legacy system usually consists on a defined irrigation schedule, many times integrating a rain sensor (which blocks irrigation upon detecting a set amount of water from rain).

− this system cannot predict rain (the second irrigation event occurs as scheduled and soil moisture raises past the saturation point, because the soil was still wet when irrigation begun);

− it also doesn’t account for punctual situations of very hot weather, which increases moisture loss (when the last irrigation event occurs, soil moisture is already below wilting point).

A system complemented by sensors is much more capable than the previous. It doesn’t need to rely on predefined irrigation schedules, since a soil moisture sensor can determine when and how much irrigation is needed. Other sensors, such as temperature can help even more.

− unlike what happens on the legacy system, irrigation amount can be reduced to avoid passing the saturation point, and the schedule can be more flexible, starting irrigation sooner when moisture level is low.

− however, it can’t also use weather predictions, so if it rains right after an irrigation event has completed, water from the rain will be wasted (the duration of irrigation should have been reduced to save water).

A system complemented by online weather information is also more capable than the legacy one. It doesn’t need to rely so strictly on predefined irrigation schedules, as the weather information allows to estimate water losses and irrigation needs.

− the system can take into account current and previous weather data, as well as weather forecasts. This way rain or hot/cold weather can be predicted, adjusting irrigation accordingly;

− weather information may not always be the most accurate for a specific place. The lack of sensors (especially moisture sensors) may cause irrigation to be excessive or insufficient.

Having analysed the strengths and weaknesses of the systems described, both aspects of sensor data and online weather data were integrated in the system developed in this project. It is expected that such a system should perform better than those previously described, namely using less water and achieving a proper irrigation. With further testing on real world situations it should outperform the commercial products mentioned in the State of the Art which, as described, tend to focus more on either the sensors or the online services.


64


65

Chapter 5. Conclusions

The Internet of Things is increasingly gaining popularity and presents a great opportunity for development. Among the concerns discussed, a major one is still interoperability, but it is beginning to get addressed. Efforts towards that goal include the definition of reference architectures and the development of middleware platforms, both analysed in this document.

In the first semester of the internship, the work performed involved mostly research about IoT, current tools and solutions, and about commercial products implementing some of the premises of IoT. The research showed an area undergoing growth where there is room for improvement on the existing developments, besides good prospects for new developments.

The main difficulty initially found relates to the vast amount of information available (a parallel with the number of devices in interconnected IoT landscapes), which created a challenge to filter and summarize:

− the vast materials with information about IoT; − the number of available middleware solutions (from complete Operating Systems

designed for constrained devices or protocols for communication, to cross-domain platforms such as the ones mentioned);

− the number of products available with similar purpose as this project (only those with Internet connectivity and which could be called “IoT products” were considered).

Additionally, while the initial focus was going to be mainly for an industrial application, only at the end of the first semester this project established home applications as a target. This implied a rethinking of the requirements and goals, but allowed to establish them more clearly.

The second semester began with the definition of detailed requirements and analysis of the initially selected software, OpenIoT. This involved a lot of testing and problem solving but in the end, neither this software nor the others that were initially thought appropriate were chosen. Nevertheless, this allowed me to be acquainted with several frameworks, which may be useful in the future. Finally, Freedomotic was selected because the goals were better aligned with this project and because it worked right after installation.

This highlighted another major difficulty in this project, much due to the status of current IoT solutions. The software analysed stated a broad scope but naturally was developed mainly to address the needs of their groups of stakeholders. Even if presented as Open Source, much of the source code, as well as the documentation, was somewhat incomplete or even withhold as a proprietary part of the software. In the end, this hints at major players in the software industry as the ones being the most likely to present solutions that are simple, capable of reaching a large user base, and that are able to achieve a good level of interoperability.


66

The selected Freedomotic software wasn’t without its flaws. Moving forward in this project required achieving a good level of understanding of its inner workings and also identifying and fixing (or working around) those flaws. Since Freedomotic is an open project developed by those who can contribute to it, my small participation in it with fixes and enhancements (some of them accepted, others still pending) was gratifying.

All of the project’s requirements deemed essential were satisfied. It should be noted that many of those requirements were satisfied from the start (or greatly simplified) by the use of Freedomotic, especially those concerning the user interface. That was essentially one of the goals of this project: simplify much of the work through the use of middleware. Even though many of the other things could have been simpler and there was some resistance created by mismatches between the software capabilities and the needs of this project, overall the use of middleware was facilitating (with the added benefits of an established base of users and developers, and hardware support).

In sum, I recognize that this internship and this project were an enriching experience, reinforcing my knowledge and skills. The information acquired in the area of the project, the Internet of Things, is a valuable asset, as this is an increasingly important subject.

Finally, the achievements of this project barely touch what can conceivably be accomplished with IoT. Even though the final product integrates sensors and online services as intended, many aspects could be improved. An example would be user interfaces, which are currently being developed (for web browsers and for Android devices) in the Freedomotic software itself.

A project using more real devices would have had a better demonstration of its capabilities. Another weakness is the lack of testing in the field in a real situation, to verify the performance and to make adjustments in parameters and algorithms (for example, making better use of data by using machine learning). As a software designed for home automation, Freedomotic offers vast opportunities to accomplish many more tasks than only serving as the base for an irrigation system.

The outcome of this project can be regarded as an example and definitely leaves room for future development, with an open possibility of being utilized in a commercial product.


67

References

[1] D. G. Velev, “Internet of Things – Analysis and Challenges,” Econ. alterntives, no. 2, pp. 99–109, 2011.

[2] F. Mattern and C. Floerkemeier, “From the Internet of Computers to the Internet of Things,” in From active data management to event-based systems and more, Springer, 2010, pp. 242–259.

[3] M. Weiser, “The computer for the 21st century,” Sci. Am., vol. 265, no. 3, pp. 66–75, 1991.

[4] A. Kevin, “That ‘Internet of Things’ thing, in the real world things matter more than ideas,” RFID J., vol. 22, 2009.

[5] A. Bassi, M. Bauer, and M. Fiedler, Enabling Things to Talk. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.

[6] R. Giffinger, C. Fertner, H. Kramar, R. Kalasek, N. Pichler-Milanovic, and E. Meijers, “Smart cities-Ranking of European medium-sized cities,” 2007.

[7] M. Chui, M. Löffler, and R. Roberts, “The Internet of Things,” McKinsey Quarterly, Mar-2010. [Online]. Available: http://www.mckinsey.com/insights/high_tech_telecoms_internet/the_internet_of_things.

[8] T. Teixeira, S. Hachem, V. Issarny, and Nikolaos Georgantas, “Service Oriented Middleware for the Internet of Things: A Perspective,” in Towards a Service-Based Internet, vol. 6994, no. 257178, W. Abramowicz, I. M. Llorente, M. Surridge, A. Zisman, and J. Vayssière, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 220–229.

[9] J. Rivera and R. van der Meulen, “Gartner Says the Internet of Things Installed Base Will Grow to 26 Billion Units By 2020,” Gartner, Dec-2013. [Online]. Available: http://www.gartner.com/newsroom/id/2636073. [Accessed: 10-Jan-2015].

[10] J. Greenough, “The ‘Internet of Things’ Will Be The World’s Most Massive Device Market And Save Companies Billions Of Dollars,” Business Insider, 05-Jan-2014. [Online]. Available: http://www.businessinsider.com/how-the-internet-of-things-market-will-grow-2014-10. [Accessed: 10-Jan-2015].

[11] “Internet of Things - Architecture.” [Online]. Available: http://www.iot-a.eu/. [Accessed: 08-Dec-2014].


68

[12] M. Bauer, M. Boussard, N. Bui, F. Carrez, P. Giacomin, S. Haller, E. Ho, C. Jardak, J. De Loof, C. Magerkurth, S. Meissner, A. Nettsträter, A. Olivereau, A. Serbanati, M. Thoma, and J. W. Walewski, Internet-of-Things Architecture – IoT-A Deliverable D1.3 – Updated reference model for IoT v1.5, no. 257521. Internet of Things - Architecture, 2012.

[13] “SENSEI project description.” [Online]. Available: http://www.ict-sensei.org/index.php?option=com_content&task=view&id=12&Itemid=65. [Accessed: 08-Dec-2014].

[14] V. Tsiatsis, A. Gluhak, T. Bauge, F. Montagut, J. Bernat, M. Bauer, C. Villalonga, P. Barnaghip, and S. Krco, “The SENSEI real world internet architecture,” Towar. Futur. Internet Emerg. Trends from Eur. Res., pp. 247–256, 2010.

[15] S. Bandyopadhyay, M. Sengupta, S. Maiti, and S. Dutta, “Role Of Middleware For Internet Of Things: A Study,” Int. J. Comput. Sci. Eng. Surv., vol. 2, no. 3, pp. 94–105, 2011.

[16] H. Zhou, The Internet of Things in the Cloud - A Middleware Perspective. CRC Press, 2013.

[17] “OpenIoT.” [Online]. Available: http://openiot.eu/. [Accessed: 08-Dec-2014].

[18] “GSN - Global Sensor Networks project.” [Online]. Available: http://lsir.epfl.ch/research/current/gsn/. [Accessed: 08-Dec-2014].

[19] “ASPIRE Project (Advanced Sensors and lightweight Programmable middleware for Innovative Rfid Enterprise applications).” [Online]. Available: http://www.fp7-aspire.eu/. [Accessed: 08-Dec-2014].

[20] “W3C Semantic Sensor Networks specifications.” [Online]. Available: http://www.w3.org/2005/Incubator/ssn/. [Accessed: 08-Dec-2014].

[21] “OpenIoT Architecture.” [Online]. Available: https://github.com/OpenIotOrg/openiot/wiki/OpenIoT-Architecture. [Accessed: 08-Dec-2014].

[22] “BUTLER.” [Online]. Available: http://www.iot-butler.eu/. [Accessed: 08-Dec-2014].

[23] B. Copigneaux, F. Clari, J. Galinowski, A. Ramakrishnan, D. Preuveneers, C. Götze, S. Poilinca, F. Sottile, F. Rizzo, A. Andrushevich, R. Kistler, D. Noferi, M. Valla, P. Smadja, P. Enjolras, M.-A. Monjas, M. F. Salazar, A. M. Cantera, J. A. Ruiz-Ruano, F. Nacabal, J. Sancho, J. Rico, L. Gurgen, C. Munilla, and M. Grella, “D5 . 2 BUTLER Final Platforms and Quality Assessment.”

[24] “IoTCloud.” [Online]. Available: https://sites.google.com/site/opensourceiotcloud. [Accessed: 08-Dec-2014].


69

[25] G. C. Fox, S. Kamburugamuve, and R. D. Hartman, “Architecture and measured characteristics of a cloud based internet of things,” in Proceedings of the 2012 International Conference on Collaboration Technologies and Systems, CTS 2012, 2012, pp. 6–12.

[26] “IoT@Work - Internet of Things at Work.” [Online]. Available: https://www.iot-at-work.eu. [Accessed: 08-Dec-2014].

[27] A. M. Houyou and H.-P. Huth, “Internet of Things at Work: Enabling Plug-and-Work in Automation Networks,” in Communication Systems & Control Networks, Embedded World Conference, 2011.

[28] D. Rotondi, A. Galipò, S. Piccione, H.-P. Huth, A. M. Houyou, J. W. Walewski, C. Kloukinas, H. Trsek, and J. Claessens, “IoT @ Work D1.1 – State of the art and functional requirements in manufacturing and automation,” 2011.

[29] D. Rotondi, S. Piccione, G. Altomare, A. M. Houyou, J. Gessner, C. Kloukinas, K. Mahbub, and H. Trsek, “IoT @ Work D1. 3 – Final framework architecture specification,” 2013.

[30] “The Hydra project (LinkSmart).” [Online]. Available: http://hydramiddleware.eu. [Accessed: 08-Dec-2014].

[31] “LinkSmart Middleware Portal.” [Online]. Available: https://linksmart.eu. [Accessed: 08-Dec-2014].

[32] P. Kostelnik, M. Sarnovsk, and K. Furdik, “The semantic middleware for networked embedded systems applied in the Internet of Things and Services domain,” Scalable Comput. Pract. …, vol. 12, no. 3, pp. 307–315, 2011.

[33] “Freedomotic.” [Online]. Available: http://www.freedomotic.com/. [Accessed: 07-Apr-2015].

[34] “Freedomotic whitepaper.” Department of Information Engineering and Computer Science (DISI), University of Trento, Trento, pp. 1–5, 2013.

[35] J. Sutherland and K. Schwaber, “The Scrum Guide,” The Definitive Guide to Scrum: The Rules of the Game, 2011. [Online]. Available: http://www.scrumguides.org/scrum-guide.html.

[36] G. Verheyen, “Scrum - A pocket guide,” A smart Travel companion. Zaltbommel Van Haren, 2013.

[37] “Requirements Analysis,” in A Guide to the Business Analysis Body of Knowledge - Version 2.0, International Institute of Business Analysis, 2009, p. 102.