Gateways in the Cloud: Integrating Devices in the Internet of Things. Information Systems and Computer Engineering

Transcription

1 Gateways in the Cloud: Integrating Devices in the Internet of Things Ricardo José Domingues Martins Baltazar Sequeira Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering Supervisor: Prof. Paulo Jorge Fernandes Carreira Examination Committee Chairperson: Prof. João António Madeiras Pereira Supervisor: Prof. Paulo Jorge Fernandes Carreira Member of the Committee: Prof. Luís Manuel Antunes Veiga November 2016

2 ii

3 iii Dedicated to my parents

4 iv

5 Acknowledgments This long journey had not been possible without the support of my family, teachers and friends. I would like to thank my supervisor, Paulo Carreira, the commitment, comments, and suggestions. Everyone who follow the progress of this work, and who have contributed with comments and suggestions. To my friends, thank you for giving me advice and suggestions throughout this time. Finally, to my family, father, mother and my sister, who supported me in all decisions and moments of my life. v

6 vi

7 Resumo A Internet das Coisas promete simplificar radicalmente a forma como os dispositivos estão ligados e como são coordenados, especialmente no contexto dos sistemas de automação residencial e de edifícios. A prática corrente na IoT favorece a criação de dispositivos com funcionalidades complexas que, tipicamente, expõem essas funcionalidades na rede através de web-services. Na prática, isto significa que existem sistemas que não permitem alterações ao seu comportamento sem alterações ao firmware ou mudanças complexas no sistema. Uma vez que a lógica de comportamento dos dispositivos está distribuída, é difícil conseguir a coordenação, sendo necessário colocar essa lógica num ponto central, em gateways dedicados. Este trabalho explora a ideia de mover a lógica dos dispositivos para a cloud, criando uma infraestrutura, agnóstica dos detalhes dos dispositivos, para suportar a coordenação dos mesmos. Assim, a lógica de coordenação e o desenvolvimento de aplicações tornam-se independentes do firmware dos dispositivos, aumentando a velocidade de desenvolvimento das aplicações e a extensibilidade das funcionalidades, sem modificar o firmware. Este trabalho propõe uma solução que permite mover a lógica de coordenação dos dispositivos para a cloud e abstrair as aplicações dos detalhes dos protocolos e das tecnologias, oferecendo serviços que permitem melhorar a interação com os dispositivos. A solução proposta é validada através de testes de performance e de carga num ambiente controlado, e por testes com dispositivos físicos, em ambiente real. O resultado final é um sistema totalmente funcional, desde os controladores dos dispositivos até à aplicação móvel que actua como interface para os utilizadores finais. Palavras-chave: Internet das Coisas, Computação na Nuvem, Domótica, Automação de Edifícios vii

8 viii

9 Abstract The Internet of Things promises to radically simplify the way devices are connected and coordinated, especially in the context of home and building automation. The current IoT practice favors the creation of devices with complex features that typically expose functionality on the network through web-services. In practice, this means that existing systems do not allow updating their behavior without changing the devices firmware or without complex changes to the entire system. Since the device behavior logic is distributed, coordination is difficult to accomplish or needs to be centralized in dedicated gateways. This work explores the idea of moving the logic from devices to the cloud, creating an infrastructure for device coordination that is agnostic of device details. Coordination logic and application development is thus fully decoupled from the device firmware and physical devices, enabling fast application development and extension of functionality without modifying the device firmware. This work proposes a solution that allows to move the devices coordination logic to the cloud, and abstract the applications of the protocols and technologies details, offering services that improve the way of interaction with devices. Our proposed solution is validated through performance and load tests in a controlled environment, and through tests with physical devices in the real environment. The end result is a fully functional system, from the device drivers to a client mobile application, which acts as an interface used by end users. Keywords: Internet of Things, Cloud Computing, Home Automation, Building Automation ix

10 x

11 Contents Acknowledgments v Resumo vii Abstract ix List of Tables xiii List of Figures xv Nomenclature xvii Glossary xvii 1 Introduction Motivation Problem Statement Methodology and Contributions Document Structure Concepts Internet of Things Cloud Computing Home Automation Related Work Embedded Thin Servers Software Design Patterns in Wireless Sensor Networks ZigBee Gateways for Home Automation Existing Cloud Gateways Systems Intel IoT IFTTT EasyIoT Discussion Solution Requirements Domain Model xi

12 4.3 Architecture Cloud Gateway Mobile App System Management Dashboard Deployment Evaluation Methodology Device Drivers Implementation Hardware Prototype Test Environment Use Case Scenarios Performance Tests Discussion Conclusions Future Work Bibliography 47 A Gateway API Endpoints 53 A.1 Gateway Public API A.2 Gateway Management API xii

13 List of Tables 3.1 Comparison of existing features of IoT Gateways Common Protocols Used in Home Automation Solutions Common Wireless Protocols Used in Home Automation Solutions Delay Observed in Multiple Commissionings Scenario Gateway response time along 12 hours Response Times with Multiple Interactions Commissionings Delay A.1 Cloud Gateway Public API A.2 Cloud Gateway Management API xiii

14 xiv

15 List of Figures 1.1 The representation of the main components of the system described in scenario Main components of Embedded Thin Servers KNX-ZigBee Network Topology LoWPAN Gateway System Architecture Main Domain Entities Solution Architecture Notifications Poll Model Notifications Push Model Solution Components Dependency Diagram Class Hierarchy Representing Physical Devices Android Mobile Application Administration Dashboard Devices Administration Dashboard Users Administration Dashboard Device Drivers Administration Dashboard Deployment Configuration Architecture Light Control Scenario Light Control Scenario (via Mobile Application) Alarming Scenario Multiple Commissionings Scenario Gateway response time along 12 hours xv

16 xvi

17 Glossary 6LoWPAN IPv6 over Low power Wireless Personal Area Networks API Application Programming Interface DBMS Database Management System DDoS Distributed Denial-of-Service GHz Gigahertz HTTP Hypertext Transfer Protocol HVAC Heating, Ventilating, and Air Conditioning IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 IP Internet Protocol IaaS Infrastructure as a Service IoT Internet of Things PaaS Platform as a Service REST Representational State Transfer RSSI Received Signal Strength Indication SNMP Simple Network Management Protocol SSL Secure Sockets Layer SaaS Software as a Service TCP Transmission Control Protocol UPnP Universal Plug and Play WirelessHART Wireless Highway Addressable Remote Transducer Protocol XML Extensible Markup Language ios iphone OS xvii

18 xviii

19 Chapter 1 Introduction The Internet of Things (IoT) has been receiving increasing attention from industry and is recognized as an important area of future technology development. The true value of IoT is realized in the ability to efficiently integrate and coordinate new devices in the network [39]. Current IoT systems are designed to provide features based on a lineup of devices that are developed independently of other IoT systems, often from different manufacturers, with distinct protocols and command semantics, which makes it difficult to integrate. Indeed, current IoT devices are not totally interoperable and are part of small systems which are provided independently of each other [32]. To achieve the full potential of the IoT, all devices and systems should be developed aiming to be integrated. Thus, each device should perform a well defined set of functions with a well defined interface. Moreover, device coordination logic should be decoupled from the responsibility of devices to perform simple functions and located at a single point. In practice, however, this is not verified. As in Software Engineering, in which the logic of programs spread over several points of the code (scattering) creates maintainability problems, the distribution of logic across devices firmware also creates cohesion problems in these systems, making maintenance, development and debugging more difficult [37]. The main problem of IoT and Home and Building Automation systems in particular is mostly that the development of these systems does not take into account the definition and implementation of protocols and standards or a clear separation of responsibility that each component of the system must have, not allowing full customization of the devices behavior because the API that each provides is not designed to be coordinated [11, 12]. Some of the challenges to the evolution of IoT have already been the subject of previous research work, it is the approach to the architecture of the systems that constitutes a major problem: devices should implement a well defined set of features and coordination logic should be externalized, encapsulated outside the devices being coordinated. The following requirements suggest that increasing the complexity of devices will result IoT systems that are difficult to maintain: 1. There must be a way to super-impose new behavior of regulating the interaction of devices. This 1

20 regulating behavior implements requirements that are distinct from the device. For the sake of separation of concerns this should be kept outside the device. 2. To make better decisions, devices need to perform increasingly complex analysis tasks, based on large amounts of time-variant data that cannot be effectively stored and processed on a device [1]. Thus, devices need to be able to delegate complex tasks, especially those related to data analysis. 3. Device coordination needs to be performed increasingly based on variables external to devices and application-dependent and that cannot be accounted for upfront. 4. New features need to be developed atop of existing devices, for which the devices were not initially designed. To meet these requirements, and to relieve the devices to perform complex tasks, it is necessary to externalize the logic to a location that has appropriate resources to manage all devices, storing collected data and perform its processing in sensible time. Thus, the need to introduce a gateway arises, that is rich in resources, which is aware of a significant number of devices and where complex computation tasks can be delegated, rather than being locally performed in the devices. This requirement is unoverridable since some tasks need to have a complete overview of the system and require variables and data from multiple devices that are not locally available, nor do they tend themselves to distribution [11]. While this approach, to externalize the coordination logic may seem unconventional, it provides a number of benefits. Development of new features becomes easier, integration of different systems is also simplified and the cost of processing is reduced, since this can be performed in the cloud where resources are used more efficiently. 1.1 Motivation Unfortunately, despite the development of home automation systems, there are still a set of problems regarding systems extensibility. This section presents three scenarios outlining the problems caused by the architecture of the systems that are currently on the market. Scenario 1 A system that can be continuously improved, where new features can be added without changing the devices and can be integrated with other systems to provide better and richer services to the end-user. Consider a scenario where a home automation system controls all devices in a residence, regardless of the manufacturer of each device, they can be integrated into the system. Users can add new devices and manage the entire system via the web, without the need for specialized technical intervention or replace the hardware. Scenario 2 Consider a system composed by two devices, a light sensor and an actuator which controls a lamp (see Figure 1.1a). In this system the sensor and the actuator are associated so that the actuator turns on the lamp if the sensor detects movement. In existing systems, if there is the need to add new requirements, such as a timer that interferes with the actuator behavior, this cannot be done without reconfiguring the system and perform devices commissioning. Moreover, it is not possible to 2

21 a Coordination logic embedded in each device b Module with coordination logic, which controls the actuator behavior according to the sensor data Figure 1.1: The representation of the main components of the system described in scenario 2. add a module, that acts as a coordinator, which receives the sensor data and, after performing some processing, controls the actuator, because sensor is directly connected to the actuator. Figure 1.1b presents this idea of moving to an external coordinator module the coordination logic, enabling to add new behavior to devices by modifying only the logic in coordinator module, without changing the devices. Scenario 3 The problem arises when we need to add a new feature. Once the logic is embedded in devices and is immutable, it is not possible to introduce new features, such as the creation and management of scenarios, as this requires a change in the behavior of each device. However, if there was a coordinator module that is able to control all system devices, also designed to be controlled, it would be possible to add new features to the system controlling only this module responsible for logic and system coordination. 1.2 Problem Statement Currently, IoT devices have been extending their functionality, but this evolution is achieved by increasing the complexity, cost and power consumption of the devices. In the architecture of current systems, the logic is embedded in the devices, forcing each of them to process large amounts of data as to coordinate with one another. According to Drytkiewicz et al., Logic, communication and user interaction often reside in the same code, hidden within the code [19]. To provide new functionality devices are able to process more and more information which cannot be acquired and processed in sensible time due to bandwidth and processing resource constraints. In order to keep the complexity of systems from increasing when new features are introduced, it is necessary to confine the logic in a single point, requesting that the devices perform only simple actions, which result from a more complex processing performed elsewhere, such as in the cloud, where the cost of computational resources is substantially lower. Our hypothesis is that designing a gateway in the cloud would simplify the processing performed on physical devices, simplifying systems management, developing new features, and integrating multiple data sources. Moreover, moving the processing of data to the cloud will require less computing power from each device, thus lowering the cost and power consumption. Also, if logic is centralized, the 3

22 systems can be continuously improved and the development process can also be simplified [36]. 1.3 Methodology and Contributions This work aims at exploring the advantages of moving the coordination logic of devices into the cloud. To validate our ideas, we will develop a gateway that will be running in the cloud to interconnect Home and Building Automation devices. The major contributions of this work will be as follows: An overview on the IoT, Cloud Computing and Home Automation concepts to understand what challenges arise in the development of a gateway, in the cloud, which integrates the physical devices on the IoT and decouple logic from devices firmware. An analysis of the research work already conducted in IoT area and its integration with the cloud, as well as the strengths and weaknesses of the approaches that have been proposed to achieve this integration. The proposal of a system for Home Automation that allows the integration of devices on the IoT, simplifies the integration of new devices and the management of entire system, by moving the applications logic to the cloud. The evaluation of the system to validate that it meets the requirements and is scalable and also a comparison with already existing solutions in terms of performance, response times and features provided. 1.4 Document Structure This document starts by presenting the key concepts related to IoT, Cloud Computing and Home Automation. Chapter 2 detail relevant concepts which are necessary to understand this work. Sections 2.1 and 2.2 describe the concepts of Internet of Things and Cloud Computing, respectively. In section 2.3 we present the concept of Home Automation. Chapter 3 addresses related work, presenting an overview of relevant research work already conducted by the scientific community in this area. Chapter 4 describes the solution proposal for the problem. The evaluation methodology and results are described in chapter 5. Finally, chapter 6 will present the conclusions. 4

23 Chapter 2 Concepts This section describes a series of key concepts for understanding the problem presented in this project. Firstly, in section 2.1 we introduce the concept of Internet of Things, making a brief analysis to its architecture, challenges and opportunities. Next, in section 2.2, we introduce the concept of Cloud Computing, presenting some of its possible applications and advantages. Finally, IoT applications to Home Automation are overviewed in section Internet of Things The concept of Internet of Things, initially proposed by Ashton, refers to the paradigm of connecting the physical world to the digital world, integrating the everyday physical devices, the things, in a continuous Internet access scenario, where devices and software are closely coupled, which gives behaviors to devices that are perceived as intelligent. [5, 29, 20]. The devices can be simple sensors and actuators or more complex systems that have themselves sensors, actuators or processing capacity to interact with the real world [34]. In IoT objects are characterized by three key aspects [43]: Have the ability to communicate; Are identifiable; Interact with the environment, sensing or actuating. Although the main idea of IoT aims to connect all objects, making each a node capable of sensing and actuating in the environment, it is essential that the devices operate invisibly to the user, the objects and their technology must be involved and adapted in the environment so that people are unaware of their presence. This requires that all devices are able to make autonomous decisions, according to the context, needs and preferences of users, without bothering them [28]. There are devices which although are not connected directly to the network they have an indirect connection making them also part of the IoT. RFID tags are an example of devices that are not connected to the Internet but, as they can be detected by a smart phone that is connected to the Internet, 5

24 they also belong to the IoT. Thus, the objects that have no intelligence are also nodes that are able to communicate with the network and provide useful information. Based on the idea that all things are connected to each other, the IoT devices besides performing their function they can also work together to provide more complex services, with greater utility, rather than several isolated and independent features [62]. Currently, IoT systems are developed in a vertical approach, where applications are extremely dependent on the devices, each application is designed to provide services that depends on a specific device, and most of the existing protocols are proprietary [57, 8]. To build more complex services, that are capable of interacting with various types of systems it is necessary to use a horizontal approach in their development, separating the data collection phase, the transmission phase and the processing phase, so that, in each phase independent protocols can be defined for each level, allowing the systems of processing phase take advantage of data from several sources [11]. The growth in the number of interconnected devices creates many opportunities for new services and features in IoT [28]. However, to take advantage of these opportunities, it is essential to overcome a number of obstacles [16]. The major challenges that must be overcome for the expansion of IoT are: Device Management. On the IoT, because of the number and diversity of devices, manage the entire system is a complex process [11]. The solutions that currently exist to manage devices (SNMP, TR-069) are suitable for resource-rich devices and because of the traffic they generate are unsuitable for resource-constrained devices [11]. To efficiently manage the devices in these systems, there should be a protocol that takes into account the diversity of devices, requires little memory, processing, and does not generate much traffic. Data Management. After the data is transmitted from the devices to other nodes with more processing capability, for example servers, it is essential to analyze them, because the data that are directly collected from the sensors do not allow, in most cases, to obtain relevant information to draw conclusions about the real meaning of the data. Only after analyzing and comparing the obtained data it is possible to distinguish useful information from irrelevant or incorrect information and get some meaning, because collected data is often a set of data containing useful information but also noise. Thus, a precise analysis is needed to get value from the data. [11]. Security. With the increasing number and type of devices the likelihood of security flaws also increases [45]. According to a study, 70% of the most used devices on the IoT have security flaws [56]. The main flaws that exist in these types of devices are derived from the low processing power they have [7, 51, 24]. The lack of encryption and poor access control are the flaws that mostly matter [14]. Although some types of devices do not require a high level of security, there are others in which it is necessary to ensure that data is exchanged securely because they are devices that due to its functionality or the environment in which they operate, contain sensitive data or provide strategic services, such as smart grid or facilities protection [11]. 6

25 Privacy. Any system that has access to personal data of users should ensure privacy [45]. In the IoT devices this issue is particularly important as these devices exist on the user s personal environment and send them over the Internet [51]. Although these data are extremely useful for the IoT service providers, as they allow them to customize users experience according to their preferences, this information may contain details that users may not want to share with third parties, such as data about health, finances or vehicles [31, 54]. The devices that exist in smart homes and buildings are an example in which the devices continuously collect data from the users personal lives and is essential to ensure the protection of these data so that their privacy is not compromised [11]. Energy Efficiency. Currently about 5% of the electricity consumed worldwide is spent by devices connected to the Internet [28]. With the evolution of IoT the increase of network connected devices is unavoidable, having a direct impact on energy consumption [1]. So efficiency proves to be a major concern in this type of devices. So that power consumption does not become a barrier to the development of IoT is essential that the devices perform their functions as efficiently as possible. Distributed Inteligence. The systems that currently exist in the IoT have more features, but this requires an increase in complexity, cost and power consumption of the devices. The architecture of the systems put logic in firmware, each device is responsible for coordinating with others in addition to performing its functionality. For the complexity of the systems does not increase with the introduction of new features it is necessary to concentrate the logic at a single point, requiring the devices that perform only simple instructions, which result from a complex processing performed elsewhere, such as in the cloud, where the cost of computational resources is substantially lower. By moving the processing to the cloud there will be a lower computing power on each device and cost and power consumption can be reduced. Moreover, if the logic virtually reside at a single point, systems can be continuously improved and the development process can also be simplified [36]. 2.2 Cloud Computing The term Cloud Computing is used to describe two different things, a platform and type of application. The concept of Cloud Computing refers to the use of shared computing resources that are provided on-demand, as services, over the Internet. The infrastructure that supports these services is hosted in data centers and is what is typically referred to as the Cloud [61]. Cloud resources are always available, and because they are virtually unlimited, the amount of resources that can be used can be adapted, in real time, to the task to be carried out, using only the required resources [12]. Thus, using the cloud s resources as a service, there is no need to build and maintain computing infrastructures in-house [1]. In cloud computing model, resources, such as compute, storage or software, can be easily provided on-demand in one of three different ways, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS) [50, 22]. The main difference between each of these categories is the purpose and suitability which each has for the different types of systems and applications [60]. 7

26 SaaS model consists of applications that are available to users through the cloud and the only requirement to use them is an Internet connection. In this type of service the user does not need to install the application or worry about managing the infrastructure where the application is installed [1]. Moreover, as the applications are in the cloud, user can access them from anywhere [22]. In PaaS model the developer has access to APIs and middleware that enable the development of applications without the need to install and configure a development environment or setup an infrastructure [26]. The disadvantages of PaaS are the lack of interoperability and portability, because, typically, the applications developed for one platform are not compatible with other platforms, making it difficult to migrate [22]. IaaS enables access to dedicated virtual machines, in which resources (CPU, memory, storage capacity, operating system, etc) can be customized according to the user s needs. In this model the user has full control over the virtual machine and can change the resources allocated to it at any time [26]. Typically, in a public cloud, services are sold on-demand and customers only pay what they consume (CPU, storage, bandwidth), as in the Amazon Elastic Compute Cloud (EC2), Microsoft Azure and Google App Engine [61]. In addition to not having to build a physical server infrastructure, using the cloud has another great advantage, the load balancing, because the servers are constantly monitored and their load is balanced in real time, adjusting the allocation of resources as required by applications [22]. Using the cloud, end-users have access to large data centers with powerful servers that provide high availability, high scalability and excellent stability at low cost [30]. By moving the applications to the cloud it is possible to obtain a better use of existing resources since the hardware is being used more efficiently, due to the sharing of powerful resources. 2.3 Home Automation Home automation is an application of ubiquitous computing which aims to offer a better quality of life and also reduce power consumption [2, 13]. According to Satpathy, a home which is smart enough to assist the inhabitants to live independently and comfortably with the help of technology is termed as smart home. In a smart home, all the mechanical and digital devices are interconnected to form a network, which can communicate with each other and with the user to create an interactive space [53]. The environment of smart homes is composed of systems and devices with very different features and applications and also use a variety of communication technologies [38, 35]. With data measured by sensors, Home Automation systems continuously monitor the home environment and automatically control appliances (such as HVAC or lighting). By using context awareness, these systems can make homes a more comfortable spaces, controlling devices according to user preferences and knowing what happens in the home, they can turn off devices that are not in use, or turn on household appliances when the energy costs are lower [2]. Another advantage of Home Automation systems is the possibility of being controlled remotely, allowing users to operate the appliances, wherever they are [55]. However, although Home Automation systems have had a great evolution, this focuses on the fea- 8

27 tures and services available to users. The systems that currently exist are composed by a set of software and hardware that depend on each other and there are no standards to enable interoperability between devices from different vendors [33, 44]. Moreover, such systems are difficult to expand, with devices or behavior, especially by users [23]. 9

28 10

29 Chapter 3 Related Work To realize the feasibility of designing a system that allows focus the devices coordination logic in the cloud, we investigated the advantages and disadvantages of protocols and systems that already exist and what problems still need research and more elegant solutions. Since we want to move the coordination logic of home automation systems to the cloud, we explored the features of the main home automation systems, the protocols that are most widely used, the advantages and trade-offs that come from that model, where devices coordination logic centralized in the cloud. Finally, we present a brief discussion of the topics analyzed, the flaws that we found and the contributions that these topics can have on the design and development of our solution. 3.1 Embedded Thin Servers Figure 3.1: The representation of main components of an architecture based on embedded thin servers. In order to move the logic from devices firmware to the cloud there is an approach in which, unlike most of IoT systems, devices contain embedded thin servers and application logic is running in the cloud 11

30 (see Figure 3.1) [36]. In this system each device exports its functionality through REST endpoints and can also be controlled through requests to other endpoints. To get or change the appliance status, the application servers that run the system logic fulfill REST requests to servers embedded in devices. This approach aims to decouple the infrastructure and applications, and fully integrate the devices on the web, using the existing infrastructure, technologies, protocols and abstractions, such as HTTP and REST [36, 46]. This idea allows the infrastructure to be agnostic of applications, simplifies the integration of new devices and the development of new applications is also simplified, since each device provides a lowlevel API to their elementary functionality. However this solution has some disadvantages. The need for a server on each device is one of those disadvantages. With the growth of IoT, the increase of network-connected devices is unavoidable. It is therefore crucial that the cost and power consumption of each device are kept as low as possible. The need for a server on each device increases the production cost, as each one will have to be able to accept, process and respond to requests from application servers. Energy consumption is not optimal because the server will always be active. 3.2 Software Design Patterns in Wireless Sensor Networks Wireless sensor networks consist of autonomous nodes equipped with sensors that can monitor physical or environmental conditions [39]. Such networks may have various network and communication topologies, be self-aware and self-organized. This network nodes are resource-constrained devices, have little processing power and memory, but have a low power consumption, because wireless communication is energy efficient, using protocols such as ZigBee, WirelessHART, IEEE 1451, 6LoWPAN and Bluetooth low energy [48]. The use of design patterns for developing sensor networks or IoT systems could prove essential to allow further development and extension, since such systems comprise a large number of devices. Design patterns are a recognized software design technique that enables code reuse and addressing similar problems in a similar way [25]. However, this technique is not commonly applied in sensor networks. In these systems, which are composed of a large number of devices, the logic that controls the behavior is spread over multiple nodes, making it difficult to extend the functionality due to the complexity introduced by this distribution [4]. Design patterns specify a set of procedures to be followed according to the problem and allow the development of systems that can be easily extended. The existence of design patterns specific to these type of systems, creates an abstraction that facilitates the development of features and clearly define the structure to be applied and what steps should be followed for the development of these features. 12

31 3.3 ZigBee Gateways for Home Automation Wireless technologies are being increasingly used in Home and Building Automation systems. Unlike wired systems, where the network expansion can be difficult and expensive, wireless technology can expand the network coverage at a low cost and ease of installation. ZigBee is one of the wireless technologies that have been widely used in such systems, since it is a protocol that enables reliable, low-rate, low-power and low-cost communication, it proves to be a good solution for operations that home and building automation systems need to accomplish [40]. However, the operation of existing systems is supported by its own protocols. To enable the expansion of these systems, the introduced technologies must support and be compatible with the protocols and standards followed by the existing technologies [41]. For the integration of different technologies to be successful, there must be a gateway that acts as an interface between them. The gateway s role is to connect two or more networks, making the translation of entities and protocols from one network to the other, ensuring the compatibility and integration of different technologies, enabling each system to leverage the benefits of the other system and protocol, without having to change protocols or interfere in parts of the network, keeping them as they are. The ZigBee gateways for Home Automation systems are intended to allow extension of these wired systems, such as KNX, through ZigBee wireless technology, keeping the original features of the system and increasing its coverage. Figure 3.2: The representation of KNX-ZigBee network topology. Figure 3.2 shows the network topology of the system that has been presented in [41]. This system is based on the KNX protocol, which is internationally recognized as a standard, and aims to facilitate the expansion of the wired network used by KNX via a wireless network, using ZigBee, while maintaining compatibility with the KNX protocol by using a gateway that acts as a bridge between the KNX and the ZigBee protocol. Although the two protocols are not fully compatible, ZigBee is particularly well suited to home automation [40]. ZigBee protocol already defines some standard profiles for generic applications and one of these profiles is intended to home automation and contains definitions for various devices (general devices, measurement and sensing devices, lighting devices, HVAC devices, closure devices, security and safety devices and smart energy devices) [3]. Despite being used the ZigBee Home Automation profile there are still differences between the two parts of the network, requiring the gateway perform translations to achieve full integration of both protocols and ensure full compatibility between the systems. These translations, performed by the gateway, are due to differences between the two protocols in terms of attributes, application services and ad- 13

32 dresses used by each of them. Figure 3.3: The representation of the main components of the system based on a 6LoWPAN gateway. In addition to the gateways designed to interconnect, on the same system, parts of the network that use different technologies, there are also gateways whose purpose is to integrate the whole system in IP networks and in the Internet. The system presented by Bjelica et al. in [9] consists of a gateway that is able to interact with IPv6 devices through the 6LoWPAN protocol, taking advantage of the large address space of IPv6 protocol and the low consumption of 6LoWPAN technology (see Figure 3.3). This system takes advantage of full support for UPnP over IPv6 to discover the nodes (devices) in the network and sends a XML description of the devices to a server in the cloud. After the devices were discovered by the gateway and its description is sent to the cloud server, they can be controlled through a web interface that is available on that server. 3.4 Existing Cloud Gateways Systems Currently there are already systems that attempt to solve some of the problems that we found, however none of them can comply with the requirements identified for our solution. This section presents the main systems that now emerge in this area. For each of the systems presented was conducted a survey of its features. In Table 3.1 a comparison between the features of the solutions analyzed is presented Intel IoT The Intel IoT is a platform, developed by Intel, to provide a seamless integration and communication with devices, intending to move data to the cloud, and be able to provide analytics. The main objective of this platform is to exploit and monetize the data. This platform is composed by software that analyzes the data, and dedicated hardware, that collects the data. One of the key components of this platform is the Intel IoT Gateway, a physical board that allows the connection to the cloud. 14

33 3.4.2 IFTTT The IFTTT ( If This Then That ) is a service that allows users to use event-based programming to interact with the devices. This system is based on the concept of recipes and ingredients, and allows users to schedule the execution of actions when an event occurs. A recipe is composed by ingredients which may be triggers or actions. There can be two kinds of recipes, simple, composed by only one trigger and an action, or complex, composed by multiple triggers and actions. Although this system is not intended for home automation, it can be used for this purpose, since it is able to generate actions on the occurrence of events. However, although users can create their own recipes, they can not extend the system s compatibility with new devices, in addition to those that are already supported. Moreover, this system does not allow the storage of data collected by the devices EasyIoT The EasyIoT is a project, co-financed by the European Union, which aims to provide an interface between the IoT devices and users. This project consists of a framework that allows programming and connecting the devices to the cloud, and a web interface where it is possible to manage and control the physical devices. To connect a device to the cloud through this platform, it is provided a library for the device firmware, consisting of methods that allow the device to connect to the cloud. Currently the number of supported devices is quite limited and can not be added device drivers to increase compatibility with other devices. Moreover, it is not possible to keep the history of the data generated by the devices. Intel IoT Gateway IFTTT EasyIoT Public Access API Sharing Features Virtual Commissionings External Data Integration Protocol Independent History Data Storage Software as a Service Table 3.1: Comparison of features of existing IoT Gateways ( Not Supported Supported). 3.5 Discussion Although currently there are several home and building automation systems, they are not integrable with each other, its features are limited by the characteristics of physical devices and the systems architecture does not allow for easy development and extension [2]. Systems such as the X10 intend to provide some 15

34 automation to homes and buildings, however, due to the limitations of the X10 protocol, the integration of devices on the Internet requires the use of physical gateways. Also, due to the specificity of this protocol, communication between the devices is not completely reliable in all environments, for example in the presence of electrical interference. To improve reliability is necessary to increase the production cost of devices [17]. Table 3.2 shows a comparison of the protocols often used in home automation systems. For each protocol an analysis was conducted taking into account the factors which are relevant when adopting a system, namely, the installation overhead, cost, speed, safety and factors that influence the solution extensibility. Protocol Installation Overhead Cost Data Rate Connectivity Security IP Low Low High High High KNX High High Low Medium High (EIBsec) X10 Low Low Low Low None ZigBee Medium Medium Medium Medium Medium (AES) Table 3.2: Common Protocols Used in Home Automation Solutions There are other systems, such as presented in 3.3, in which the communication is based on mesh networks, i.e., networks in which each node is responsible for routing traffic coming from other nodes. However, these kind of networks have disadvantages in terms of cost, performance and hardware complexity. In mesh networks each node is connected to one or more nodes and also acts as a router, routing the traffic coming. Thus, each network node has to be capable of running complex routing protocols and perform the routing of traffic to other network nodes. Furthermore, due to low processing power at each node, the network throughput is low and tends to fall further with increasing number of hops between devices, needed to route traffic to the final gateway. Moreover, the cloud computing proves to be an efficient alternative to perform the processing of large volumes of data [27]. In the cloud is possible to access virtually unlimited resources according to applications needs at a reduced cost since the resources might be shared with other applications, unlike what happens in dedicated servers, where the hardware is used exclusively for a single application [52]. Besides the low processing capacity, these devices have limited storage capability. Thus, the cloud storage of data generated by the devices has the advantage of reducing the cost and not be restricted to the devices physical capacity [63]. However, in dedicated servers there are resources that are wasted because the applications do not take advantage of all full-time. The integration of home automation systems with cloud computing has many advantages, it is possible to improve the features that already exist and provide new features due to the availability of better resources. With IoT all devices are connected to the Internet, making it possible to offer more and richer features, by integrating IoT devices in home automation systems. The next chapter proposes a solution that meets these requirements. 16

35 Chapter 4 Solution The analysis of related work indicates that no solution exists that complies with the extensibility requirements, centralizing logic and processing in the cloud, while this chapter details a solution that aims improving features that already exist in other systems by eliminating the shortcomings found. This chapter will describe how the system was designed and implemented, highlighting key design options, the challenges encountered in system development and the solutions to overcome them. The developed solution aims to contribute as a gateway in the cloud that allows to extract all the logic, that is currently in the IoT devices, to the cloud and is also intended to provide value-added services The main target of the developed gateway are the home automation devices. As explained earlier, the IoT devices, especially in home automation devices, sensors and actuators have limited storage space and low processing capabilities. In addition, there is a huge diversity of devices and connections (WiFi, Bluetooth, ZigBee, etc.), making it difficult to delegate in application the responsibility for managing devices. In most cases the applications do not need to know the address or the identity of the devices with which they interact, they are more interested in controlling the device behavior and in the content of the data that they provide. For example, an application for managing the air conditioning in a home automation system is more interested in the temperature of each room that in the network address of the sensor. Moreover, multiple applications may be interested in information of the same sensor, but for different features. In this case, each device would have to maintain and manage the connection and communications with multiple applications, requiring more processing power and increasing energy consumption. The main goal of the developed solution is to manage the coordination logic of the devices and provide applications a way to interact with devices, without establishing a direct link with them. This chapter details the requirements, the architecture and the main decisions taken during the development of our solution. We also present the applications that have been implemented, and details about the deployment process. 17

36 4.1 Requirements Currently IoT is facing multiple challenges, a long diversity of devices and various sources of external information. Taking into account these considerations, we define the following set of requirements that our solution must fulfill: Public Access API. Our solution has as main goal to bridge the gap between devices and applications, as well as provide additional services that are common to several applications. To allow external applications to interact with the devices seamlessly through the gateway services should be provided an API that exposes these services. This API should be designed to be: easy to use, hard to misuse, easy to maintain, powerful enough to satisfy our requirements and easy to extend. Remote Control. One of the advantages of the cloud is ubiquitous access. Anywhere in the world, at any time, it is possible to interact with and manage the systems. In home automation systems, remote access and remote control are very important features, as they allow users to control and know, in real time, the state of their homes. In the case of the IoT devices, remote access is also a very desirable feature, because the proliferation of devices and their existence everywhere, proves to be increasingly critical the ability to remotely interact with the devices, eliminating the need for users to move to the physical location of the devices. For example, for managing a network of sensors distributed over a wide area, the possibility of remote access to each of the sensors is proved useful to prevent the trip to each of the sensors. Sharing Features. Residing in the cloud and able to control each user s devices, the gateway has an important responsibility in the users lives. The home automation systems are distinguished from other IoT systems, for example, wearables, by coexisting not only with the owner, but with multiple users, family, friends and others. For this reason, it becomes an added value if the gateway enable social features, such as sharing devices with other users, ie, each device or group of devices can be shared with other users so that the guests are allowed to interact and control these devices. Not forgetting the security concerns, since these devices live at the users homes, the owner must have access to all historical actions and must be able to revoke access to a guest in real time. In the future, taking into account the security and privacy of users, social features can be extended to allow the sharing and use of data collected by the devices of other users, so that these shared data can become external sources, that can be used for new features. Cloud Based Reconfiguration. A home automation system consists of several devices that work together to provide advanced features to its users. The real utility of an automation system is not only the number of sensors and actuators that the system can manage. The true value of such systems is the automation of tasks, based on information gathered by the different sources. The actions that the system does without the direct intervention of the users are the main advantage of such systems. For systems to be able to operate in an intelligent manner, without bothering the users, they have a set of rules that define the actions that must be performed for each set of 18

37 inputs. However, in systems that currently exist, it is not easy to change the commissioning between devices, i.e., it is difficult, especially for users, change the rules that control the behavior of the devices. Our solution should be designed taking into account that must allow easy extension of devices and behavior. The set of rules that defines the behavior of the devices should be easy to update. Therefore, should not exist a permanent commissioning of the devices, the connection between these must be mediated by a central component that gathers the logic that controls their behavior, based on an approach of virtual commissionings, allowing easy updating of these commissionings by users. This central component where all devices are connected, acts as a gateway, routing and translating messages sent by each device to other devices, according to the logic that is configured. External Data Integration. Besides the integration with the physical devices, the solution must also allow integration with external data sources, so that the system can control the devices, not only based on internal information, but according to the data provided by these sources. Therefore, the solution must be designed to minimize the effort to add new external integrations. Security. Access to information and system features should be allowed only to authorized entities, upon authentication. There must be a fine-grained access control, so that any action on the system can only be done if it is possible to authenticate and validate the permissions of the entity. The information should be stored so as not to be publicly accessible, and served only to those who prove to have permissions. There should be several roles, to be able to differentiate a user from an administrator that has permissions to manage the system. Protocol Independent. Due to the diversity of protocols used in the IoT systems, and in particular in home automation systems, our solution should not be dependent on any protocol. The services offered by the gateway should only be responsible for implementing the features, and should not contain any logic associated with a specific protocol. Vendor and Technology Independent. In addition to the multiple protocols that exist in home automation systems, there are also several technologies and a wide variety of manufacturers. Moreover, there is no technology that is used by most manufacturers, each vendor uses different technologies, adapted to the needs of their products. The lack of homogeneity among the technologies used in different products have a major impact on interoperability among different devices. This heterogeneity becomes a problem when users want to install in their homes multiple products from different manufacturers. That is, because of the incompatibility that exists with the products that are currently on the market, consumers are faced with a manufacturer s dependency issue, the vendor lock-in. Since most devices are compatible with other devices from the same vendor, when consumers choose a particular system, the choice of all other devices is limited only to devices compatible with those already installed. Further, if consumers need a feature that exists only in devices from 19

38 another manufacturer, the only way of having this feature is to replace the existing home automation system. Having regard to the problem of vendor lock-in, our solution should be independent of the technology that is used and must not be dependent on the vendor of a device. Instead, the system to be developed shall be aimed to functionality, and have the ability to expand the compatibility to other devices, by adding drivers that perform the translation between the protocols used by each device to a uniform interface used by the gateway. Although the purpose of the gateway is to provide features and centralize devices behavior logic in the cloud, it is important that the system architecture is designed to allow the addition of multiple device drivers, so that there is a way to interact with real-world devices. History Data Storage. With the emergence of IoT and home automation systems and the consequent proliferation of sensors and actuators, arise new sources capable of generating data at an unprecedented pace. The collection of data generated by these sources have a huge potential to be analyzed and explored, so that useful information can be extracted and transformed into new services and features. As noted by Ramparany and Cao, future IoT applications including Smart Home, Smart City, Smart Energy services, will require that all data be easily compared, correlated and merged and that interpretation of this resulting aggregate into higher level context, which better matches people needs and requirements, bringing the user experience to the next level [49]. Our solution must have the ability to receive and store the data generated by all those sensors and actuators in order to relieve their physical resources and to allow efficient storage of all these data for later analysis. Low Latency. The time between the generation of an event on the server and the delivery of the notification on the device should be as low as possible, so that the user has the perception that the interaction with the devices is done in real time. Once the delivery time of a message in an IP network depends on a large number of variables, many of which can not be controlled by the applications, it is imperative that the system is designed to minimize this response time, taking into account the factors that influence the delay and which can be controlled by the server, such as processing time and the size of messages. Software as a Service. Currently, in cloud computing, there are several licensing and delivery software models, each with distinct advantages and different purposes. As mentioned in section 2.2, the SaaS model consists of the delivery of a service, typically centrally hosted, over the internet. This software delivery model allows to reduce the costs for the end user, both the infrastructure and maintenance, since the infrastructure can be shared by several users and maintenance is carried out by the applications providers. Another great benefit of this model is related to the updates. As the service is managed by the 20

39 provider, it can update the infrastructure according to application requirements and update applications when new versions are released, in order to keep them up-to-date without user intervention. Thus, taking into account the various software delivery models that exist in cloud computing, the model that best suits the type of our application is the SaaS model because it allows end users to use the service without any concern about the updates and does not require installing any infrastructure or any component of this infrastructure. Moreover, in this model, users are also free from any maintenance, which usually requires some knowledge about the architecture and details of the software. 4.2 Domain Model The domain model is a conceptual model composed of the entities of the system that allow to represent and model data and the behavior associated with the real world concepts, which are part of the solution, so that the information can be processed, stored and later retrieved. The domain model should be designed in order to properly abstracting system concepts, taking into account the requirements, because the correct identification of the domain entities and relations between them are essential to achieve a maintainable, testable and easily upgradeable solution. The domain model should be designed taking into account the type of problem that will be solved and the solution requirements. The domain entities of our solution were modeled taking into account the type of storage where the data would be persisted, a relational database. It is the domain layer that is responsible for synchronizing the entities with the database. This is the layer responsible for the insertion, update and deletion of data and also to keep the constraints defined in the requirements, so that data integrity is preserved. In our solution there are entities which are stored in the database, since they represent the information that the system needs to store for later query, and there are also entities that are not persisted because they only model the behavior of the real world entities, and it is not necessary to store any data about these objects. As illustrated in Figure 4.1, the domain model of our solution consists of several entities related to each other. The key entities of this model are: Device. It is the main entity that composes the system. A device is a physical equipment responsible for interacting with the real world. It can be a sensor that collects data from the surroundings, an actuator, which changes its behavior according to the commands it receives, or even both. Any user can install a device in a location that owns. When a device is installed in a location it will be considered active and the user who performed this installation will be considered the owner of the device, while this installation remains valid. The owner of a device have the permissions for all actions on this device. A device can only be uninstalled by its owner, removing all data associated with the current installation. A device can only be controlled when it is associated with a valid installation. 21

40 Figure 4.1: The main domain entities and the relations between them. Location. The entity location represents a physical space where devices can be installed. A location can be created by any user and each location is associated with a set of data that distinguish it and help the system provide rich and context aware services, such as services based on the geographical position of the user and location. In our solution the location is the fundamental entity to provide social features, since the location can be shared by the owner with other users. Users with whom the location is shared will receive permissions that allow interaction with the devices present in this location, although granted permissions are more restrictive than those granted to the owner of the location. A feature that is very important in home automation systems is the ability to enable the system to record the preferences of users, especially the ability to record individual preferences for each space and according to the user. To achieve this feature, in our solution, each location can have multiple scenarios that can be created by users. User Account. An account represents a system user. This is the entity that stores the information about an user and is also the existence of this entity that allows to provide customized services for each user. An account is associated with all data that a user has in the system, e.g., locations, devices and scenarios. In the developed solution, the interaction with the user is mainly done in two ways, through services exposed by gateway or through notifications sent to the user when certain events occur. As opposed to the gateway services, where the service response comes always following a request made to the service by the client, push notifications are a type of alerts that are sent to clients without a prior request. To support the management and the sending of push notifications, each 22

41 user account can be associated with multiple mobile devices, representing the devices where the user has subscribed to receive push notifications, for example, smart phones, tablets or smart watches. Share. One of the advantages of cloud-based systems is the ability to integrate social features and sharing of access and information. In our system each user can have multiple locations that correspond to buildings, floors or rooms that the user owns or in which it has installed devices, making it possible for each user to interact with their devices. Furthermore, the developed system has features that are based on sharing, that is, a user can share a space with other users by granting access to the devices installed in this space, so that they may also interact with all these devices. To support this sharing feature, there is the entity Share that allows a user to grant access to a space to other users. A share can be associated with an end date, from which the share is no longer valid. This feature of sharing spaces proves to be important in the IoT systems, especially in home automation systems, since these systems are typically used to manage devices that are used by multiple users. For example, in a system for managing devices in a hotel, this sharing feature can be used to provide access to the devices of each room to the guests, but only during their stay. Scenario. A scenario allows to combine a set of presets for multiple devices. In order to facilitate interaction with multiple devices, the system allows to create a scenario with a set of presets, so they can be activated at the same time. For example, a user can create a scenario with presets to individually adjust the intensity of the room s lamps and name it as movie time. A scenario belongs to a location, which allows to share the scenario with all users who have access to the location. Schedule. The ability of a home automation system act without frequent user intervention is crucial for the system to be autonomous. One way for a system to not rely on constantly user intervention is allowing tasks to be scheduled to run later or to run periodically. By allowing the task scheduling, a system increases their autonomy to perform actions, in a certain later time, without human intervention. In our solution a schedule is an entity that allows for the scheduling of an action, which will then be performed on physical devices according to user-defined rules. A schedule can also be associated with a periodicity, to be executed repeatedly. 4.3 Architecture Since the main target of the developed solution are the home automation devices, it is crucial that the system can be accessed on any device, permanently. This goal can only be achieved if there is an 23

42 architecture that simultaneously ensures high availability, high throughput and processing almost in real time. Taking into account the solution requirements and processing and communication needs, the features of the system are distributed over multiple components, as depicted in Figure 4.2, in order to optimize and balance the use of resources. Figure 4.2: Solution Architecture. From left to right: the perception layer, composed of sensors and actuators; the Cloud Gateway internal components responsible for the management of devices and users and also for providing the services; the presentation layer, composed of the interfaces with users. The technologies used to develop the system were chosen taking into account the necessary requirements and their suitability for the environment where they will run once deployed. The application server is the main component of the system. This server is responsible for the main features of the system, such as the management of physical devices, and the interface between these devices and applications through the available services. These services, exposed via an Application Programming Interface (API) allows the applications interact with the devices and the gateway via simple HTTP requests, creating an abstraction layer that simplifies the logic in applications, since the clients of this API are independent of implementation, storage and database details [18, 58]. It is also this API that abstracts physical devices details and encapsulates the communication for each device, allowing applications to communicate with devices without needing to know the details of communication protocols. This API that exposes the services provided by the gateway is a REST API that can be used in various applications, across multiple platforms, through simple HTTP requests. This type of API has many advantages for the client applications and also to the server because it is lightweight, platform-independent and does not require the server to maintain state for each client [21]. It is this API that is used in both client applications of our solution, the web application and mobile application. To meet the requirements of our solution there are some features that require communication to be extremely fast, near real-time and asynchronous, i.e. happens after the occurrence of events without the existence of prior request, explicit, by the client application. For example, when the system triggers an alert or alarm, the client application must be notified 24

43 immediately. For this to be possible there are two different solutions: poll and push [15]. Both solutions have advantages and disadvantages that have been carefully considered, and the decision fallen in the use of an architecture in which the server sends push notifications to client applications. Figure 4.3: Architecture of poll-based notifications. In the poll model, as depicted in Figure 4.3, an application periodically makes a request to the server to check for pending messages, while the push model is the server who takes the initiative and notifies the application. In this model the server only needs to maintain a queue which store the messages that the client will download later, but although to the server an architecture based on the model that are clients who poll the server is quite simple, it is an architecture that is not scalable and to decrease the delay between the generation of the event on the server and the receipt of the notification on the client is necessary to reduce the frequency with which the client polls the server, requiring more processing on the server and increasing network traffic. Figure 4.4: Architecture of push-based notifications. In the push model, depicted in Figure 4.4, the complexity of architecture is greater but the benefits achieved justify this increased complexity. In this model, where the server notifies the devices there is a set of data that must be kept on the server, for example, active subscriptions and which devices made these subscriptions, but the need of the devices periodically contact the server to check if there are pending messages is eliminated [59]. Once the server can notify the devices as soon as it receives the event, the time interval between the occurrence of the event and the receipt of the notification on the client application can be as little as possible, excluding network delays, because these depend on the transmission medium that is used [42]. In our solution the data about the devices that have subscribed the events and active subscriptions is stored on the server but the sending of notifications is performed in an external component. When the server receives an event forwards this event to the responsible service for push notifications that sends the notification to the client application. 25

44 This notifications model is especially beneficial when the client applications are mobile applications because the devices where they run have limited resources and the use of these resources by applications should be reduced in order to optimize the battery consumption [47, 6, 10, 15]. 4.4 Cloud Gateway Our solution, the cloud gateway, consists of multiple components that work together to provide high-level features. Taking into account the best practices and principles of software development, the features of our system are implemented by several different components and each component has a well defined responsibility. This approach increases the cohesion and maintainability of the system, since the boundary of each module is limited. Figure 4.5: Solution Components Dependency Diagram Figure 4.5 illustrates the components that are part of system and the dependencies between each. The set of components illustrated in Figure 4.5 can be divided into two sub-categories according to the type of functionality that each module provide: (i) the components that implements the high-level features, such as, user management, authentication or scenarios management, and (ii) all components responsible for managing the physical devices. This last set of components is fundamental in our system, namely: Device Management, Physical Device Management, Device Drivers and Device Commissioning Management. To perform the equipment management and offer an abstraction of the physical devices, we developed a model, presented in Figure 4.6, where each type of device is represented by an interface 26

45 Figure 4.6: Class Hierarchy Representing Physical Devices according to the type of features it provides. This allows client applications of the cloud gateway can disregard the protocols used by each device, since the features do not depend on the brand, model or technology used by it. In Example 4.1 we present the interface of a humidity sensor, that provides a method to read the value measured by the sensor. Example 4.2 reveals the interface for a lamp with basic features, and Example 4.3 represents an RGB lamp, whose features are obtained through inheritance and the addition of new features, typical of this type of device. Example 4.1: Humidity Sensor Interface public interface HumiditySensor extends Sensor { double gethumidity(); } Example 4.2: Lamp Interface public interface Lamp extends Actuator { boolean getstatus(); void turnon(); void turnoff(); int getintensity(); void setintensity(int intensity); } 27

46 Example 4.3: RGB Lamp Interface public interface RGBLamp extends Lamp { long getcolor(); void setcolor(long color); } To realize these abstractions, the system needs to translate the protocols of each device, through drivers, that map the protocol-specific commands to methods of the interface corresponding to the type of device. This approach simplifies the way the client applications interact with the devices, reducing the communication complexity to simple methods that represent the features of devices, while allowing the existence of complex devices, rich in features, by composing the interfaces that represent the device types. Further, by distributing the complexity of the communication by different layers, our solution enables also simplify the creation of new device drivers. Once implemented the device driver, another component of the system in which this device driver will be registered, handles communication with the devices, managing equipments connected to the system and choosing the suitable device driver for each of them. Figure 4.6 presents, in addition to the interfaces that represent the devices, the container of device drivers, and an example of a device driver that translates a protocol for the interfaces used by the gateway, in this case the CloudLamp and the CloudEnvironmentSensor drivers, that have been implemented to evaluate the feasibility of the proposed solution. Initially, these devices were implemented in software, consisting of an emulator of devices and the device drivers for them. Later, the protocol was also implemented in hardware, in physical devices. As explained previously, in home automation systems there is the concept of commissionings, i.e. associations between devices that cause actions on a device triggered by an event on another device. Typically, in this type of systems the commissioning between devices is configured locally, making it difficult to change. In our solution, we have developed an engine that allows to configure the associations between devices, dynamically and easy to change, i.e. virtual commissionings, which enable to interconnect the devices, in order to create behavior rules based on events generated by other devices. Example 4.4 presents a virtual commissioning which connects an actuator, in this case a switch, to a lamp, and triggers a change in lamp status when a change in the switch state occurs. 28

47 Example 4.4: Virtual Commissioning that associates the action of a Switch to a Lamp public class SimpleLampSwitchCommissioning extends LampCommissioning { public SimpleLampSwitchCommissioning(Switch switchsensor, Lamp lamp) { super(switchsensor, lamp); public void triggeraction(devicenotification devicenotification) { if (devicenotification instanceof SensorMeasureNotification) { if (((Switch)triggerSensor).getStatus()) { lamp.turnon(); } else { lamp.turnoff(); } } } } In the Example 4.5 it is presented a commissioning between a motion sensor and a lamp, when the sensor detects movement, the lamp is turned on for a period of time. This approach allows to configure device commissionings dynamically and also allows to create behavior based on complex rules, by compose multiple commissionings, but keeping all the coordination logic in a single point, in the cloud. Example 4.5: Virtual Commissioning that causes a lamp to turn on when motion is detected in a sensor public class MotionSensorLampCommissioning extends LampCommissioning { private int time; public MotionSensorLampCommissioning(MotionSensor motionsensor, Lamp lamp, int time) { super(motionsensor, lamp); this.time = time; public void triggeraction(devicenotification devicenotification) { if (devicenotification instanceof SensorMeasureNotification) { if (((SensorMeasureNotification) devicenotification).getmeasure() > 0) { lamp.turnon(time); } } } } The device model we developed, based on interfaces, and the way we structured the commissionings manager, makes simple and easy the development of new types of commissiongs and their registration in the system. Moreover, this model allows the integration with external data sources that can be used 29

48 to interfere in the devices behavior. For example, it is possible to create a commissioning that periodically checks the users s mobile device location, through a third-party service, and when it detects that the user is moving home, turns on the HVAC system. 4.5 Mobile App In order to create a fully functional system, we developed a mobile application, for the Android platform, which acts as an interface to the services provided by the gateway. The developed application allows the registration of new users, management of user locations and devices, and also features related to the sharing of spaces. This application uses the REST API provided by the gateway and also supports receiving push notifications, via Google Cloud Messaging, a service that is also used by the gateway. Further, this application is aware of the context, it uses the device s location and the information of the network where it is connected to determine the position of the device, for example, to determine whether the user is in a space that is registered in the application. Aiming to improve the user interface and user experience, we had a number of concerns when we designed the application layout. When the user interacts with a device through the application, sending the action is immediately reflected in the interface, but the confirmation only appears after receiving the server acknowledge. This separation into two steps is very important in this kind of applications, where the operation execution is not immediate, so it is necessary to present to the user the actual operation status. a User Locations Activity b Activity to Manage and Control Devices Figure 4.7: Android Mobile Application. Figure 4.7 depicts two screenshots of the mobile application that was developed. The screen where 30

49 are listed the spaces to which the user has access, and the screen for which the user transits after selecting a space, which is composed by the devices installed in that space, the current status and the actions available for each device. 4.6 System Management Dashboard The system management dashboard is a web application, developed in AngularJS, which allows to check the system status and perform all administration tasks. This application allows to query all devices registered in the system, know where they are currently installed, what are their current status, and what errors occurred. Moreover, it allows to perform management of users, mobile devices, device drivers and system configuration. The existence of this interface allows all management to be carried out via the web, without the need for specific knowledge about the internal architecture of the system. In Figure 4.8 is shown the screen that contains a summary of the system status, and Figure 4.9 shows the screen that allows the management of devices. Figures 4.10 and 4.11 show, respectively, the screen for user management, and the screen that allows the management of device drivers. Figure 4.8: Administration Dashboard - Web Application Figure 4.9: Devices Administration Dashboard - Web Application 31

50 Figure 4.10: Users Administration Dashboard - Web Application 4.7 Deployment Figure 4.11: Device Drivers Administration Dashboard - Web Application To make the system available in the cloud and also to conduct the evaluation of the developed solution, we need to design an architecture of components in order to ensure maximum performance and scalability, since it is a system where it is expected that there will be a lot of devices, and in which the messages round trip time should be as low as possible, near to real time. Taking advantage of the cloud benefits, we setup an infrastructure with multiple components, which aims to balance the load and provides the ability to scale, according to the needs. The main infrastructure components, depicted in Figure 4.12, are the components that comprise the system core: namely (i) the cloud gateway server, (ii) the web application and (iii) the HTTP server, responsible for acting as the entry point to the system. Each of these modules runs inside an independent docker container, which decreases the infrastructure management effort and increases the flexibility, scalability and fault tolerance. Moreover, in this architecture, each container is connected to an isolated virtual network, that allows our containers communicate with each other, while remaining isolated from the outside, and from other containers. To realize some features in the HTTP transport level, such as load balancing and SSL termination, we placed an HTTP server, specifically an instance of nginx, as the entry point to the system. The 32

51 primary function of this server is to serve as a reverse proxy for the other system components. The configuration of the nginx server as reverse proxy delegates in this component the responsibility of receiving all HTTP traffic and the subsequent routing of that traffic to the corresponding docker container, the cloud gateway server or the web application. This configuration of the infrastructure, where the nginx server is the only entry point to the system, allows to restrict to a single point some concerns related to security, such as the implementation of Secure Sockets Layer (SSL) termination, load balancing or the mitigation of distributed denial-of-service (DDoS) attacks, features that are often required, but that are too complex to implement in each application. This architecture is also composed of two components responsible for the storage, which are external to the server. The storage components, both file storage and database are separate from the application server, for reasons of security and performance. Due to the specificity of storage components, the separation of these allows to customize the resources of each machine to the needs of each component. While the database server needs a larger amount of memory to perform queries, the file storage server requires more disk space and greater bandwidth. The management of users mobile devices, i.e., the devices on which users install the mobile application is partially delegated to an external component, that is not fully managed by this architecture. The delegation of this responsibility to an external component is very important, since it removes from the application server all the complexity of the management and delivery of notifications to mobile clients. The management of mobile devices is particularly complex because it involves (i) the discovery of devices, (ii) adaptation of the notification format the operating system used by the mobile device and finally (iii) sending notifications quickly and efficiently to these devices. Figure 4.12: Deployment Configuration Architecture. 33