Study, design and development
of an integration component
with sensory features of objects
through IoT middleware
José Mig...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
iii
Resu...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
i
Abstra...
ii
iv
Study, design and development of an integration component
with sensory features of objects through IoT middleware
v
Acknow...
vi
Study, design and development of an integration component
with sensory features of objects through IoT middleware
vii
Tabl...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
viii
3.2...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
ix
List ...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
x
List o...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
xi
Acron...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
xii
SOAP...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
1
Chapte...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
2
− Iden...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
3
contro...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
4
− Disc...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
5
the gl...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
6
suppor...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
7
Chapte...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
8
2.1. A...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
9
Refere...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
10
− Sec...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
11
The p...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
12
To su...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
13
2.2. ...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
14
2.2.1...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
15
Virtu...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
16
OpenI...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
17
Servi...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
18
2.2.3...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
19
broke...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
20
Devic...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
21
Compl...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
22
The m...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
23
The s...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
24
− Pro...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
25
image...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
26
2.3. ...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
27
2.3.3...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
28
2.3.6...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
29
irrig...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
30
Among...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
31
Chapt...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
32
In th...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
33
3.2. ...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
34
The e...
Study, design and development of an integration component
with sensory features of objects through IoT middleware
35
3.4. ...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Study, design and development of an integration component with sensory features of objects through IoT middleware
Upcoming SlideShare
Loading in …5
×

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

8,930 views

Published on

Development of a smart irrigation system using an existing IoT middleware.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,930
On SlideShare
0
From Embeds
0
Number of Embeds
6,815
Actions
Shares
0
Downloads
62
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Study, design and development of an integration component with sensory features of objects through IoT middleware José Miguel da Silva Fidalgo josemsf@student.dei.uc.pt Supervisor (DEI): Examination jury (DEI): Tiago Cruz Vasco Pereira César Teixeira Supervisor (Flor de Utopia): Hélio Palaio Date: 01 September 2015 Master’s Degree in Computer Engineering 2014/2015 Internship Final Report
  2. 2. Study, design and development of an integration component with sensory features of objects through IoT middleware iii Resumo A expressão "Internet das Coisas" foi pela primeira vez usada por Kevin Ashton em 1999 para descrever um conceito em que objectos físicos estão ligados à Internet, com capacidade de comunicar e de se identificarem. A infra-estrutura existente da Internet já interliga milhares de milhões de dispositivos a nível global, oferecendo acesso a um vasto leque de conteúdos e serviços em qualquer lugar, amplificado pela adopção massiva de telemóveis com ligação à Internet. O número de objectos conectados que agem como sensores/actuadores também tem vindo a aumentar, fazendo da Internet das Coisas uma realidade actual. A disponibilidade generalizada destes objectos com conectividade (objectos inteligentes) constitui uma fonte de informação potencialmente enorme ou até mesmo um meio de controlar algo remotamente, possibilitando aplicações inovadoras. Uma possível abordagem para integrar estes objectos e expô-los como serviços na Internet é através da utilização de uma plataforma de middleware. O objectivo deste projecto foi desenvolver uma plataforma de irrigação inteligente com suporte de sensores e actuadores, alavancando-se num middleware IoT já existente. A plataforma usa fontes de informação complementares de serviços de previsão meteorológica, e expõe as suas funcionalidades através de um serviço de forma a permitir acesso remoto. Palavras-Chave “Internet das Coisas”, “Middleware”, “Máquina-a-Máquina”, “Redes de Sensores”, “Internet de Serviços”, “Arquitectura Orientada a Serviços”, “Sistemas Ciber-Físicos”, “Computação Ubíqua”, “Domótica”, “Sistemas Informáticos Incorporados”, “Irrigação Inteligente”, “Objectos Inteligentes”
  3. 3. Study, design and development of an integration component with sensory features of objects through IoT middleware 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”
  4. 4. ii
  5. 5. iv
  6. 6. Study, design and development of an integration component with sensory features of objects through IoT middleware 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).
  7. 7. vi
  8. 8. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  9. 9. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  10. 10. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  11. 11. Study, design and development of an integration component with sensory features of objects through IoT middleware x List of Tables Table 1: IoT middleware comparison in Bandyopadhyay et al. [15]. ........................................ 13 Table 2: Comparison of features of commercial products. ........................................................ 29
  12. 12. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  13. 13. Study, design and development of an integration component with sensory features of objects through IoT middleware 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)
  14. 14. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  15. 15. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  16. 16. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  17. 17. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  18. 18. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  19. 19. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  20. 20. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  21. 21. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  22. 22. Study, design and development of an integration component with sensory features of objects through IoT middleware 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;
  23. 23. Study, design and development of an integration component with sensory features of objects through IoT middleware 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).
  24. 24. Study, design and development of an integration component with sensory features of objects through IoT middleware 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].
  25. 25. Study, design and development of an integration component with sensory features of objects through IoT middleware 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).
  26. 26. Study, design and development of an integration component with sensory features of objects through IoT middleware 13 2.2. Middleware Another piece in the puzzle addressing the challenges presented by an effective implementation of IoT is the use of middleware. This is software whose purpose is to establish a bridge between diverse hardware devices and the applications that want to use them, by presenting a common interface. Several studies have analysed and compared available IoT middleware solutions, for example those performed by Bandyopadhyay et al. [15] and Zhou [16]. The classification made by Bandyopadhyay et al. is summarized in Table 1. Table 1: IoT middleware comparison in Bandyopadhyay et al. [15]. IoT Middleware Features of Middleware Interface protocols Device Management Interoperation Platform Portability Context Awareness Security and Privacy Zigbee RFID WiFi Bluetooth Sensor (others) HYDRA           ISMB           ASPIRE           UBIWARE           UBISOAP           UBIROAD           GSN           SMEPP           SOCRADES           SIRENA           WHEREX           The table shows that many middleware solutions were conceived without special concerns about interoperability, context awareness, or security and privacy. This is mainly due to the purpose and focus of the particular middleware, leaving the features to be implemented by the software adopting those solutions. Among the middleware platforms referenced in this chapter appearing in Table 1, HYDRA is presented as a more complete solution, providing a full platform integrating devices and applications, while being agnostic to interface protocols. In contrast, GSN and ASPIRE are more limited since their purpose was focused on abstracting interface protocols, hence they are referenced only as being components of a more complete platform. These complete platforms are the types of middleware that interest most to this project. In this section some of them are presented, taking into account that many more are available.
  27. 27. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  28. 28. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  29. 29. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  30. 30. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  31. 31. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  32. 32. Study, design and development of an integration component with sensory features of objects through IoT middleware 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].
  33. 33. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  34. 34. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  35. 35. Study, design and development of an integration component with sensory features of objects through IoT middleware 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).
  36. 36. Study, design and development of an integration component with sensory features of objects through IoT middleware 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);
  37. 37. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  38. 38. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  39. 39. Study, design and development of an integration component with sensory features of objects through IoT middleware 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).
  40. 40. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  41. 41. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  42. 42. Study, design and development of an integration component with sensory features of objects through IoT middleware 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
  43. 43. Study, design and development of an integration component with sensory features of objects through IoT middleware 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).
  44. 44. Study, design and development of an integration component with sensory features of objects through IoT middleware 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].
  45. 45. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.
  46. 46. Study, design and development of an integration component with sensory features of objects through IoT middleware 33 3.2. Tools In line with the preferred Architecture and Middleware selected for use and adaptation (described in the State of the Art in Chapter 2 of this document), the language used for development was Java (version 7). Likewise, Maven was used for dependency management and build automations, while Git was the source control system. Eclipse (Luna Service Release 2 – version 4.4.2) was the chosen Integrated Development Environment. Maven and Git operations were performed using its included plugins. 3.3. Planning The internship was divided in two semesters, in which the first was used as a research and preparation phase for the project. The planning for this semester is shown in the chart in Figure 11, where the tasks performed are detailed. Figure 11: Planning for the first semester. The initial planning for the second semester consisted on the development phase and final preparations. In Figure 12 we can see the several 2 week sprints, followed by the preparations for the final report and project defence. For each sprint the goals and requirements were to be further detailed in the beginning, also presenting a summary of the work performed in the previous sprint. Figure 12: Planning for the second semester. ID Task Name Start Finish 1 Presentation of the company Mon 15-09-14 Mon 15-09-14 2 Project analysis Tue 16-09-14 Fri 26-09-14 3 Analysis of references provided Mon 29-09-14 Fri 17-10-14 4 Research on architectures Mon 20-10-14 Wed 29-10-14 5 Research on middleware Wed 29-10-14 Fri 21-11-14 6 Analysis of software to be used Mon 24-11-14 Tue 09-12-14 7 Detailing requirements Wed 10-12-14 Tue 16-12-14 8 Completing writing of the report Wed 17-12-14 Tue 20-01-15 9 Preliminary report delivery Wed 21-01-15 Wed 21-01-15 10 Review of intermediate report Thu 22-01-15 Mon 26-01-15 11 Intermediate report delivery Tue 27-01-15 Tue 27-01-15 12 Preparation of project presentation Wed 28-01-15 Fri 30-01-15 13 Intermediate project defense Mon 02-02-15 Mon 02-02-15 15-09 21-01 27-01 02-02 07 14 21 28 05 12 19 26 02 09 16 23 30 07 14 21 28 04 11 18 25 01 08 15 p '14 Oct '14 Nov '14 Dec '14 Jan '15 Feb '15 ID Task Name Start Finish 1 Development Mon 09-02-15 Fri 12-06-15 2 Sprint #1 Mon 09-02-15 Fri 20-02-15 3 Sprint #2 Mon 23-02-15 Fri 06-03-15 4 Sprint #3 Mon 09-03-15 Fri 20-03-15 5 Sprint #4 Mon 23-03-15 Fri 03-04-15 6 Sprint #5 Mon 06-04-15 Fri 17-04-15 7 Sprint #6 Mon 20-04-15 Fri 01-05-15 8 Sprint #7 Mon 04-05-15 Fri 15-05-15 9 Sprint #8 Mon 18-05-15 Fri 29-05-15 10 Sprint #9 Mon 01-06-15 Fri 12-06-15 11 Completing writing of report Mon 15-06-15 Fri 26-06-15 12 Preliminary report delivery Fri 26-06-15 Fri 26-06-15 13 Final review of report Mon 29-06-15 Fri 03-07-15 14 Final report delivery Mon 06-07-15 Mon 06-07-15 15 Preparation of project presentation Tue 07-07-15 Fri 10-07-15 16 Final project defense Mon 13-07-15 Fri 17-07-15 26-06 06-07 01 08 15 22 01 08 15 22 29 05 12 19 26 03 10 17 24 31 07 14 21 28 05 12 1 Feb '15 Mar '15 Apr '15 May '15 Jun '15 Jul '15
  47. 47. Study, design and development of an integration component with sensory features of objects through IoT middleware 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 ID Task Name Start Finish 1 Development Mon 15-02-09 Tue 15-08-11 2 Requirements, study OpenIoT Mon 15-02-09 Thu 15-03-19 3 Temperature sensor and services Fri 15-03-20 Mon 15-04-20 4 Study Freedomotic; initial development Tue 15-04-21 Thu 15-05-28 5 Sick days Fri 15-05-29 Fri 15-06-12 6 Objects and plugins Mon 15-06-15 Tue 15-07-28 7 Testing and bug fixing Wed 15-07-29 Tue 15-08-11 8 Completing writing of report Wed 15-08-12 Tue 15-08-25 9 Preliminary report delivery Tue 15-08-25 Tue 15-08-25 10 Final review of report Wed 15-08-26 Mon 15-08-31 11 Final report delivery Wed 15-09-02 Wed 15-09-02 12 Preparation of project presentation Tue 15-09-01 Fri 15-09-04 13 Final project defense Mon 15-09-07 Mon 15-09-07 07 15 23 03 11 19 27 04 12 20 28 06 14 22 30 07 15 23 01 09 17 25 02 10 18 26 03 '15 Feb 08 '15 Mar 01 '15 Mar 22 '15 Apr 12 '15 May 03 '15 May 24 '15 Jun 14 '15 Jul 05 '15 Jul 26 '15 Aug 16 '15
  48. 48. Study, design and development of an integration component with sensory features of objects through IoT middleware 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.

×