Achieving IoT Interoperability through a Service Oriented In-Home Appliance Federico Montori∗ , Luca Bedogni∗ , Filippo Morselli∗ , Luciano Bononi∗ ∗ Department
of Computer Science and Engineering, University of Bologna, Italy Email: {federico.montori2, luca.bedogni4, luciano.bononi}@unibo.it,
[email protected]
Abstract—The Internet of Things (IoT) environments are no more a vision as they are already surrounding the everyday life of citizens. Its pervasive nature brings IoT ecosystems closer and closer to the end users, facilitating their domestic lives through home automation appliances and platforms. Several M2M communication technologies and data representation techniques have been standardized and often established by the manufacturers. For such reasons, many Home Automation Systems (HAS) are irreconcilable due to the incompatibility of their communication technologies. In order to take a step towards HAS interoperability, in this paper we propose RouteX, an experimental crosstechnology platform able to manage home devices belonging to different networks and using different technologies. It leverages the potential of Service Oriented Architectures (SOA), providing the user with an abstraction layer over a multitude of home sensors and actuators. We also present a practical user interface, through which the user is able to administrate efficiently all his or her home appliances no matter which technology they use.
I. I NTRODUCTION The Internet of Things (IoT) paradigm is rapidly becoming a reality, after years of development and standardization efforts. Nowadays it is possible to find several smart objects, ranging from smart lights to smart thermostats, which are able to provide enhanced in-home services to the user. Since the IoT leverages the possibility to access heterogeneous data, that has necessarily to be integrated on a common platform, achieving interoperability is imperative. Reports show that the number of devices per person is constantly increasing [1], a challenge that inherently carries heterogeneity among the devices about the protocol they use, the access technologies and the data format, just to name few examples. However, often devices belonging to one manufacturer are able to interact only within their ecosystem, hence making integration with other devices hard or even impossible. Moreover, the number of people building smart devices for themselves at home, often making use of developers’ boards like Arduino1 or the ESP82662 , is constantly increasing. Data sharing among such entities is often as well managed by the makers, through customized web services and data storages, which still lack the possibility to integrate data coming from other smart objects together. This problem is often referred to as the Islands of Things, or the Intranet of Things [2]. In addition, the heterogeneity of the devices is found not only at the storage level, but also at the communication level, 1 https://www.arduino.cc/ 2 http://bbs.espressif.com/
since multiple wireless technologies are in use such as Zigbee, WIFI, 433 MHz and similar. Often manufacturers build their devices choosing one technology or the other, depending on the complexity of both the devices and their architecture. To fully unleash the potential of the IoT, Things should be able to exchange data regardless of the manufacturer or the communication technology they refer to. Interoperability at the data level can be obtained through the use of ontologies, and by integrating data originating from different sources in a common platform in the cloud [3]. This brings the advantage for users to have access to a huge amount of data, and therefore they can customize their preferred services, possibly adding data coming from their local installations. In this context, privacy issues may arise, since not all the data can be published online, as some, such as the user presence in a certain location, should be kept private. For such reason, an additional integration must take place closer to the user, who should be able to share data among the installed devices regardless of the technology or the protocol used. Hence, they can exploit additional information coming from a remote platform, and enrich it with local data without necessarily sharing it. In this paper we present RouteX, a novel Service Oriented Architecture (SOA) for Home Automation Systems (HAS), able to offer services and applications leveraging different wireless technologies and acting as a bridge through the management of the different technologies and requirements of the appliances. It provides an application protocol for devices, which makes them able to join the network and publish their services, either involving sensors or actuators, and their energy capabilities as well. RouteX also exposes a web interface, through which the user can create his or her own services, and an Android mobile application, which offers a convenient way to access the data and invoke commands against the inhome actuators. Moreover, RouteX offers the possibility to set triggers, which perform actions in response to certain events, regardless of the device type and wireless technology used to interact with it. The rest of this paper is organized as follows: in Section II we present related works from literature; the paper continues with Section III, which details the RouteX architecture; Section IV shows the implementation of the RouteX platform in all its parts, while Section V concludes the paper and highlights future works.
II. R ELATED W ORKS Nowadays, interoperability among things and systems of things is being faced as a key challenge. IoT-based ecosystems are more and more organized in closed clouds that rely on their own protocols and policies, thus forming the so-called “Intranet of Things” [2]. Furthermore, smart home appliances often bind the user’s capabilities and interaction to what has been devised by the manufacturers. For such reasons, it is hard, sometimes impossible, to reuse components, software and devices in a horizontal approach, i.e. among different solutions [4]. The problem gained a broad audience and can be seen under different perspectives: the data perspective, the architectural perspective and the device perspective. In the first case, the task of unifying different data collection systems has been largely explored and it is currently under study. A clear example is given by [3], in which several open IoT data platforms collecting sensor data are queried and a common paradigm for data classification is given. Many proposals exist also for the architectural approaches, in which middlewares for different M2M sub-networks are proposed as service-based orchestrators. This approach is quite common and, indeed, it has been concretized in several architectural proposals and service layer platforms for M2M scenarios such as the ones in [5] and [6]. Such approaches, however, require a dedicated proxy for each subnet, since the solution is based on application layer protocols. In [7] the typical approach to heterogeneous scenarios, the so-called Global Sensor Network (GSN) systems, are reviewed with a particular stress on the Constrained Application Protocol (CoAP), which is one of the most widely used application protocols for constrained devices, since it resembles the functionalities of HTTP, and includes a service oriented discovery policy. A sample scenario is also proposed, leveraging 6LoWPAN as a global routing paradigm, however, the deployment of a gateway implementing the virtual GSN middleware is required for every single subnet. In [8] the authors propose an architecture for heterogeneous sensing in location-aware scenarios, using IEEE 802.11 and ZigBee as leading technologies, able to merge information coming from two coexistent networks at a high level of abstraction. In particular, such system has been designed for elderly people indoor localization. In [9] the authors propose an Arduino/Android based architecture for home automation with a central controller for scheduling and interaction purposes. The approach is quite similar to ours, however it sticks to only one wireless technology, since the work in not focused on M2M compliancy. The approach proposed in this paper follows the concept of the device perspective, in which end devices are directly connected to a central entity regardless of the M2M communication technology that they come with. It needs unavoidably a multi interface router, which is a poorly explored solution in literature concerning closed environments such as HAS and Building Automation Systems (BAS). Indeed, heterogeneous HAS and BAS commonly address the problem of coexistence between IP and non-IP solutions through a middleware ap-
proach, that is “moving up one level of abstraction”, while we aim to act at a technology level. A prototype close to our work is presented in [10], in which the authors implemented an IoT gateway able to deal with ZigBee and GPRS subnet and defined a packet policy for commands and reporting actions. Nevertheless, such work was limited to a reduced utilization, since the router is a message forwarder with some analytic capabilities. The utilization of a smart gateway is also a fundamental building block within the context of the Web of Things (WoT), in which constrained devices are seen as RESTful resources. In such cases, a gateway that opens up the doors from the IP world to non-IP based WSN is, again, imperative [11]. III. A RCHITECTURE AND P ROTOCOL In this section we describe our proposed architecture, and the protocol messages that are exchanged between the devices. A. Scenario As we are relentlessly increasing the amount of smart devices we bring into our homes, we are unavoidably creating a challenging situation for the future IoT as the one depicted in Figure 1. By increasing the devices, we are also extending the platoon of communication technologies, either wireless or wired, that are used to exchange messages. This is driven by innovation, as device manufacturers select the most appropriate technology for their product, such as low power wireless technologies like 433 MHz for battery operated devices (popular for electric automated gates), to WiFi for devices that have to directly interact with users, to Bluetooth and many others. Even though this helps in tailoring the desired technology for the foreseen product, at the same times it makes difficult to exchange information between devices using different technologies. Our proposed architecture is driven by a central coordinator, called RouteX, able to exploit different communication technologies to query devices. We hereby define the four different entities foreseen in the RouteX architecture. At first, we have the DEVICE, which is any component able to provide raw data, such as temperature and humidity, through a number of sensors or able to perform an action in the real world through a number of actuators Clearly, a device can carry both one or more sensors and one or more actuators, however it is identified by one communication technology. A DEVICE exposes one or more SERVICES, which are the software component in charge of providing data or receiving commands, each related to a sensor or an actuator. The ROUTER is the main entity of the RouteX architecture, which takes care of delivering messages through the various interfaces, and handle possible protocol differences, and, in our deployment, is implemented and running on a Raspberry Pi with all the communication interfaces attached. Finally, the CONTROLLER is a client application that communicates with the ROUTER and acts as a user interface, providing the user with the capabilities of monitoring the devices and send commands.
Fig. 1. Heterogeneous IoT smart home architecture.
Before joining the network, devices have to call Routex::JOIN, directed to the ROUTER’s local address. Immediately after joining, upon an acknowledgement by the ROUTER, each DEVICE declare its capabilities through a ROUTEX::SERVICE call. The capabilities can be either in the form of a sensor read (i.e. a SERVICE providing a value) or an actuator (i.e. a SERVICE which performs an action and holds a status). Clearly, a DEVICE can declare multiple SERVICES if it is able to provide them. A DEVICE is also requested to declare a default state, which can be either ROUTEX::ALWAYSON or ROUTEX::SLEEP. This instructs the ROUTER whether it is possible to query the DEVICE if it is always awake, or whether it has to listen for messages coming from it. Although each DEVICE can be programmed as desired, it is straightforward to understand how DEVICES offering actuators will be probably always ROUTEX::ALWAYSON, while DEVICES offering sensors which might be powered by batteries can be put to sleep to save it, hence cannot be directly queried by the ROUTER. SERVICES can also respond to more than one command, for such reason, if the SERVICE is not related to a pure sensor (a pure sensor has only one command, namely “get”, thus it is assumed as implicit and therefore does not need to be specified), the DEVICE performs a ROUTEX::COMMAND for each command exposed by each SERVICE. To have an overview of the interactions between the different components we show a sequence diagram in Figure 2, in which the interactions with the CONTROLLER are shown as well. As technologies differ not only for their PHY, but might differ also on the upper layers, the ROUTER maintains a table in which it stores the device name, obtained from the ROUTEX::JOIN, and the technology to contact it. Hence, DEVICES can interact thanks to the ROUTER without caring about the technology used to communicate.
IV. I MPLEMENTATION
Fig. 2. Sequence diagram showing the interactions between the ROUTER, the CONTROLLER and the DEVICES.
B. Protocol Here we describe the protocol we use to exchange messages between the DEVICES and the ROUTER. The Protocol takes care of both adding nodes to the network as well as receiving sensor updates and performing actions on actuators.
In this section we aim to describe the logic behind the implementation of RouteX, and all its capabilities. Recall that the architecture is totally centralized, we can assume the ROUTER as the server application, while all the entities DEVICE and the CONTROLLER are client application. Indeed, the whole system behaves as a SOA, in which the ROUTER is the service broker, instantiating contracts between the service producers and consumers. In particular, a DEVICE, whenever performing a ROUTEX::JOIN operation, a number of parameters are specified: the technology used for communication and the ALWAYSON or SLEEP parameter. Furthermore, during a ROUTEX::JOIN operation, every DEVICE defines a number of SERVICES it can provide and exposes their interfaces to the broker. SERVICES can be characterized by a number of get operations (e.g. a sensor read) and post operations (e.g. a parametrized command to an actuator).
Fig. 3. Our device hosting the ROUTER and 6 different communication interfaces.
Fig. 4. The test clients we deployed in order to prove the interoperability among the 5 wireless communication technologies.
A. Technologies In order to grant the claimed interoperability, the ROUTER needs to implement a hook for each communication technology that aims to support. In particular, we used a Raspberry Pi version 2 in order to host the ROUTER application, due to its ease of deployment, native support for ethernet connection, low power consumption and support for both USB and serial interfaces. We developed a software module and installed the hardware appliances for the following technologies: • Ethernet: the ethernet socket is natively supported by the router. • WiFi: we used this technology as the basis for our application. Clearly, both WiFi and ethernet, since are not basically point-to-point, need a separate router to act as the technology AP. Furthermore, either WiFi or Ethernet has necessarily to be managed and installed to be used by the CONTROLLER (in fact, the CONTROLLER is an HTTP-based application), not only by the DEVICES. Our deployment uses a WiFi USB dongle. • Bluetooth: a well-known and used technology. Due to its characteristics and its integration in wearables and smartphones, it is a necessary feature in each smart home. We used a Bluetooth USB dongle. • ZigBee: a low-power mesh protocol based on IEEE 802.15.4 MAC layer. It is highly widespread and it has been the leading technology for large M2M WPAN deployments for several years due to its native support for a high number of endpoints [12]. We used an XBee S2 shield3 by Digi International inc. accessed through a SparkFun XBee Explorer Dongle. • ANT: this technology is a multicast ultra low power alternative to WiFi, which does not include mechanisms like association and authentication. For this reason, it is suitable for point-to-point communications over the 3 XBee S2 product productdetail?pid=3430
specification:
https://www.digi.com/support/
•
2.4 GHz bands for highly power-constrained devices in short distances [13]. We used the nRF24L01 module4 by Nordic Semiconductor ASA. 433 MHz RF: this technology is a simple PHY that transmits few bits over the 433 MHz spectrum bands. It is the simplest among our technologies and the most affected by interferences, however it is important since many home appliances are running over such technology (e.g. the automatic gates). Every module willing to transmit and receive needs both a transmitter and a receiver. In particular, we equipped the router with a WRL-10534 RF link transmitter5 and a WRL-10532 RF link receiver6 , both produced by SparkFun Electronics.
B. Command Logic After many devices have joined our system, our main server side contribution is given by the logic and the command automation. Assuming that every DEVICE in our ecosystem is either a sensor (providing data upon command) or an actuator (executing concretely commands) we define the command types as the ways in which the controlled can interact with the environment: • Explicit Command: whenever a specific command is manually invoked. This happens when the end user, interacting through the CONTROLLER is willing to retrieve an information “here and now” from a sensor or explicitly perform an action through an actuator. • Scheduled Command: a specific command can be scheduled in two different ways. A user can either establish a repetition of the command over time specifying a time frequency with a granularity of one second and a 4 nRF24L01 product specification: http://www.nordicsemi.com/eng/ Products/2.4GHz-RF/nRF24L01 5 WRL-10534 product specification: https://www.sparkfun.com/products/ 10534 6 WRL-10532 product specification: https://www.sparkfun.com/products/ 10532
(a)
(b)
Fig. 5. Screenshots of the web desktop application implementing the CONTROLLER. Figure (a) shows the list of services registered in ROUTEX, while (b) shows the wizard that leads to the instantiation of a trigger.
•
maximum time span of 24 hours or specify a defined time (hour and minute) at which the command will be executed every day. This is the typical application for users willing to monitor a certain condition in their houses, for instance, a user might be interested in monitoring the temperature of a specific room every hour and keep an historian of it. Triggered Command: a command that is triggered whenever a specific condition occurs. Both the conditions and the command to be executed are specified by a trigger, a data structure explained separately in Section IV-C.
Logically, DEVICES that are labeled with the property SLEEP cannot be queried upon request. For such reason, the ROUTER suspends any occurring command directed to such devices and keeps it in memory in a dedicated file and, whenever a SLEEP device wakes up and forewarns the router, the latter replies with the commands. Each SERVICE can also be labeled with the THINGSPEAK flag. If true, any result coming from such SERVICE will be also sent to a public data channel in the ThingSpeak global open data platform7 . The first time it occurs, if the channel does not exist, it is created, provided that the user holds an API key in a configuration file. This choice has been introduced in order to comply with the open data philosophy and the integration of heterogeneous data sources within the Collaborative Internet of Things (C-IoT) [14]. It is also an easy way to access remotely a subset of the relevant data without exposing the router outside the home subnet. C. Triggers Triggers are a type of data that specify a set of conditions under which a certain command is immediately invoked. They resemble the paradigm on top of which orchestration services such as “If This Then That” (IFTTT) [15] are founded. In particular, they are in the form if (C)then(CM D), where C is a condition and CM D is a specific command. In this specific case, CM D can be replaced with a notification though an email to a certain person. A condition C can be any boolean 7 ThingSpeak
open data platform: https://thingspeak.com/channels/public
expression, in our current implementation it is formally defined as: C ::= (v > k)|(v = k)|(v < k)|C ∧ C where v is a value returned from a SERVICE, while k is a numeric constant value. In particular, v refers to the last value, thus it does not imply a command to the relative SERVICE itself, which has to be queried necessarily using other command policies. Furthermore, as it can be observed, a condition might be referring to more services at the same time, hence a coordinated monitoring of such services is imperative in order to grant a sufficient precision. At the moment, such task is totally left to the user. D. Controller Interface The entity named CONTROLLER in our ecosystem is more easily described by the client application that puts the user in contact with the ROUTEX environment. In particular, we developed a web desktop application as well as an Android mobile app that allow the user to interact with all the features we implemented in our system. Examples of the application layout are presented in Figures 5 and 6, in which we show two screens of the desktop application and two of the mobile app. In any case both the platform present the exact same screens. When the user logs in, the “Device view”, composed by 3 tabs, is introduced. The first tab displays a list of all the devices that performed a ROUTEX::JOIN together with all their parameters and the adopted wireless technology. The whole set of devices that we used for a demonstration environment is observable in Figure 4. Switching the tab, it is possible to access to the list of services, presented in particular in Figure 5(a), in which all the services exposed by the devices are enlisted and accessible for commands. The example shows clearly a DHT11, a sensor commonly used for temperature and humidity measurements, installed on a ZigBee device, a BMP180, a sensor that measures temperature and barometric pressure, installed on a WiFi device, and a led controlled by an nRF24L01-equipped device. The third tab in this view leads to the trigger screen, in which all the active triggers are listed and it is possible to add a new trigger to the list through a wizard. Figure 5(b) shows the user view of the wizard, in which the
using Bluetooth, WiFi, ANT, ZigBee and RF 433 MHz and express dependencies through a simple trigger-based approach. We believe that interoperability in small ecosystems such as in home automation can be achieved easily though small and highly abstractive solutions like RouteX, therefore we proved the usability of the platform through a user-friendly client in its mobile and desktop versions. This is just an example of how a simple integration can exponentially increase the number of functionalities of an IoT system, which is necessary in a future-oriented vision. R EFERENCES
(a)
(b)
Fig. 6. Screenshots of the mobile application implementing the CONTROLLER. Figure (a) shows the wizard for the instantiation of a schedule, while (b) shows the graph about a temperature sensor over few days.
CM D is selectable in the top part (either a direct command or an e-mail send) and the set of and-linked conditions C in the bottom part. The example shows a trigger that commands the green led on the nRF24L01 devices to turn on whenever the temperature measured by both the ZigBee and the WiFi devices drops below 20°C. If the user selects by clicking a specific service, the “Service view”, composed by othe 3 tabs is introduced. In the first tab, the properties of the service and the last measured value are displayed as well as a clickable button for each command associated to the service. Through such buttons, the user can explicitly invoke what we defined as an Explicit Command, thus invoking a sensing operation or an action. Furthermore, the user can activate through a button the coupling with a Thingspeak channel (which is created upon the first coupling request). Such coupling can be activated and deactivated dynamically upon request. In the second tab, the user can visualize the list of schedules active for the service and, through a wizard, he or she can set up a new one, recall that either the time of the day, in case the command has to e executed once per day, or a time frequency, which represents how often the command is invoked from that moment on, should be specified. Such wizard is displayed in Figure 6(a) in its mobile version. The third tab, displayed in Figure 6(b), hosts a time-driven chart reporting all the values returned by the service within a defined and dynamically adjustable time span. V. C ONCLUSIONS In this paper we presented RouteX, a novel architecture for IoT ecosystems in smart houses. We demonstrated the feasibility of integrating different wireless technologies using a join-based SOA paradigm. In particular, we showed how our prototype is able to manage communication among devices
[1] T. J. Barnett, A. Sumits, S. Jain, and U. Andra, “Cisco Visual Networking Index (VNI): Global Mobile Data Traffic Forecast Update, 20152020,” Cisco White Paper, 2016. [2] M. Zorzi, A. Gluhak, S. Lange, and A. Bassi, “From today’s INTRAnet of things to a future INTERnet of things: A wireless- and mobilityrelated view,” IEEE Wireless Communications, vol. 17, no. 6, pp. 44–51, 2010. [3] F. Montori, L. Bedogni, and L. Bononi, “On the Integration of Heterogeneous Data Sources for the Collaborative Internet of Things,” in 2nd International Forum on Research and Technologies for Society and Industry (RTSI), 2016. [4] S. Krco, B. Pokric, and F. Carrez, “Designing IoT architecture (s): A European perspective,” in Internet of Things (WF-IoT), 2014 IEEE World Forum on. IEEE, 2014, pp. 79–84. [5] M. B. Alaya, Y. Banouar, T. Monteil, C. Chassot, and K. Drira, “OM2M: Extensible ETSI-compliant M2M service platform with selfconfiguration capability,” in Procedia Computer Science, vol. 32, 2014, pp. 1079–1086. [6] J. Swetina, G. Lu, P. Jacobs, F. Ennesser, and J. Song, “Toward a standardized common M2M service layer platform: Introduction to oneM2M,” IEEE Wireless Communications, vol. 21, no. 3, pp. 20–26, 2014. [7] L. Mainetti, L. Patrono, and A. Vilei, “Evolution of wireless sensor networks towards the Internet of Things: A survey,” SoftCOM, pp. 1–6, 2011. [8] F. Viani, F. Robol, A. Polo, P. Rocca, G. Oliveri, and A. Massa, “Wireless architectures for heterogeneous sensing in smart home applications: Concepts and real implementation,” Proceedings of the IEEE, vol. 101, no. 11, pp. 2381–2396, 2013. [9] K. Baraka, M. Ghobril, S. Malek, R. Kanj, and A. Kayssi, “Low cost arduino/android-based energy-efficient home automation system with smart task scheduling,” in Proceedings - 5th International Conference on Computational Intelligence, Communication Systems, and Networks, CICSyN 2013, 2013, pp. 296–301. [10] Q. Zhu, R. Wang, Q. Chen, Y. Liu, and W. Qin, “IOT Gateway: BridgingWireless Sensor Networks into Internet of Things,” 2010 IEEE/IFIP International Conference on Embedded and Ubiquitous Computing, pp. 347–352, 2010. [11] D. Guinard and V. Trifa, “Towards the Web of Things : Web Mashups for Embedded Devices,” in Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009), 2009, pp. 1–8. [12] P. Baronti, P. Pillai, V. W. Chook, S. Chessa, A. Gotta, and Y. F. Hu, “Wireless sensor networks: A survey on the state of the art and the 802.15.4 and ZigBee standards,” Computer Communications, vol. 30, no. 7, pp. 1655–1695, 2007. [13] P. Christ, B. Neuwinger, F. Werner, and U. R¨uckert, “Performance analysis of the nRF24L01 ultra-low-power transceiver in a multi-transmitter and multi-receiver scenario,” in Proceedings of IEEE Sensors, 2011, pp. 1205–1208. [14] F. Montori, L. Bedogni, and L. Bononi, “A collaborative internet of things architecture for smart cities and environmental monitoring,” IEEE Internet of Things Journal, 2017. [15] S. Ovadia, “Automate the internet with ”if this then that” (IFTTT),” Behavioral & Social Sciences Librarian, vol. 33, no. 4, pp. 208–211, 2014.
