A framework for device interaction in a network of things

Texto

(1)A framework for device interaction in a network of things Pablo César Calcina Ccori. Thesis presented to the Institute of Mathematics and Statistics of the University of São Paulo to obtain the title of Doctor of Philosophy. Program: Computer Science Advisor: Prof. Dr. Laisa Caroline Costa de Biase Co-advisor: Prof. Dr. Flávio Soares Correa da Silva This study was financed in part by the Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - Brasil (CAPES) - Finance Code 001 São Paulo, March, 2020.

(2) A framework for device interaction in a network of things. This version of the thesis contains the corrections and modifications suggested by the Judging Committee during the defense of the original version of this work, in July 8th, 2020. A copy of the original version is available in the Institute of Mathematics and Statistics of the University of São Paulo.. Judging Committee: • Prof. Dr. Flávio Soares Corrêa da Silva (advisor) - IME-USP • Prof. Dr. Jan Rabaey - UC Berkeley • Prof. Dr. Roseli de Deus Lopes - EP-USP • Prof. Dr. José de Jesus Pérez Alcazár - EACH-USP • Prof. Dr. Daniel Macedo Batista - IME-USP.

(3) Acknowledgments I had the rare honor of having three advisors. Three highly talented professors to whom I am very grateful. This thesis was inspired by the insightful work from Dr. Laisa Costa, who patiently accompanied this work from its inception. Her advice and opportune feedback were essential to conduct the present thesis until a satisfactory conclusion. Whenever I was in doubt in the capricious course of the research path, I could always rely on the accurate advice from my second advisor, Prof. Flávio Corrêa da Silva. After long sessions of conversation accompanied by a cup of good coffee, Prof. Corrêa da Silva offered the wise words I needed. My third advisor, Prof. Marcelo Zuffo, was undoubtedly the cornerstone of this cooperation. As the leader of the Interdisciplinary Center of Interactive Technologies (CITI), he is responsible for the development of cutting-edge technology in Brazil, of which this thesis is a humble sample. Proving that the whole if greater than the sum of the parts, the Swarm team at CITI has produced a tremendous work during these years, in the form of scientific articles, system design, software architecture, application development and abundant documentation. This thesis has directly benefited from that development and I would like to express my gratitude to all the talented people that participated in the Swarm team. Mr. Geovane Fedrecheski provided the official SwarmBroker implementation and the initial version of the SwarmLib, on top of which I implemented the framework. Mr. Carlos Laschi actively collaborated in the definition of the Geolocation Ontology for the Swarm that is presented in this work. Mr. Gabriel Duarte and Mr. Phillipe Rangel participated in the definition of the economic model for the Swarm, also presented in this thesis. Mr. Guilherme C. Marques and Matheus Guinezi contributed with the initial version of the SwarmAssistant, which is the basis of the case study used in this work. Also, Dr. Samira Afzal kindly helped with the revision of this document. This work was partially supported by Associação do Laboratório de Sistemas Integráveis Tecnológico (LSI-TEC) and Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES).. i.

(4) ii.

(5) Abstract CALCINA-CCORI, Pablo C. A framework for device interaction in a network of things. 2020. 103 p. Thesis (Doctorate) - Institute of Mathematics and Statistics, University of São Paulo, São Paulo, 2020. As devices in the IoT are increasing in number and capabilities, there is an opportunity of creating networks of smart devices that go beyond the current cloud-centric model of data-gathering and actuation. The Swarm project provides a middleware to create a bio-inspired distributed and organic network of heterogeneous devices. Under the context of the Swarm project, in this thesis, we aim to create a framework for the interaction of devices, consisting of registration in the network, discovery, composition, and mediation of services. Using semantics as a driving technique, we aim to create a communication framework that facilitates the development of IoT applications in the Swarm, as a first step towards constructing a smart self-organizing network for the future IoT. The proposed framework aims to overcome the problems of interoperability and composition by adapting lightweight open standards with a service-oriented architecture and novel composition and mediation mechanisms. To illustrate the use of our framework, we implemented a use case based on the recruiting of services for a surveillance system. The significant contributions of this thesis can be summarized as: an architecture and implementation for device interaction in the IoT, a lightweight model for semantic service description and semantic querying, a ranking algorithm for service selection in an economy-based IoT network, an ontology for IoT services, and a declarative composition and mediation. To evaluate our work, we used two methods. First, we performed a quantitative comparison between an implementation with and without the use of our framework, then, we conduct a qualitative comparison of features offered by our framework with other similar works. Keywords: Internet of Things, device interaction, Swarm.. iii.

(6) iv.

(7) Resumo CCORI, P. C. C. Um arcabouço para interação de dispositivos em uma rede de coisas. 2020. 103 f. Tese (Doutorado) - Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, 2010. À medida que os dispositivos na Internet das Coisas estão crescendo em número e em capacidades, surge a oportunidade de criar redes de dispositivos inteligentes que vão além do modelo atual de coleta de dados e atuação, centrado na nuvem. O projeto Swarm provê um middleware para a criação de redes bioinspiradas de dispositivos heterogêneos. No contexto do projeto Swarm, nesta tese temos como objetivo criar um arcabouço para a interação de dispositivos, que consiste no registro na rede, descoberta, composição e mediação de serviços. Usando semântica como técnica direcionadora, temos como objetivos a criação de um arcabouço de comunicação que facilita o desenvolvimento de aplicações para IoT no Swarm, como um primeiro passo para a construção de uma rede auto-organizável para a IoT do futuro. O arcabouço proposto tem como objetivo atacar os problemas de interoperabilidade e composição, adotando padrões leves com uma arquitetura orientada a serviços e mecanismos novos de composição e mediação. A fim de ilustrar o uso do nosso arcabouço, implementamos um caso de uso baseado no recrutamento de serviços para um sistema de vigilância. As principais contribuições desta tese podem ser resumidas em: uma arquitetura e implementação para interação de dispositivos na IoT, um modelo leve para a descrição semântica de serviços e consultas, um algoritmo de ranqueamento para seleção de serviços em uma rede IoT baseada em princípios econômicos, uma ontologia para serviços para IoT, e um modelo declarativo para a composição e mediação de serviços. A fim de avaliar o nosso trabalho, utilizamos dois métodos para avaliar o arcabouço. Primeiro fazemos uma comparação quantitativa entre a implementação do caso de uso com e sem o uso do arcabouço. Também, fazemos uma comparação qualitativa das características oferecidas por nosso arcabouço com outros trabalhos similares. Palavras-chave: Internet das coisas, interação de dispositivos, Swarm.. v.

(8) vi.

(9) Contents List of Abbreviations. xi. List of Figures. xiii. List of Tables. xv. 1 Introduction 1.1 Challenges . . . . 1.2 Problem definition 1.3 Objective . . . . . 1.4 Hypothesis . . . . 1.5 Contributions . . 1.6 Thesis structure .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 2 Basic concepts and technologies 2.1 The Swarm . . . . . . . . . . . . 2.1.1 The Swarm project . . . 2.1.2 Swarm Broker . . . . . . 2.1.3 Swarm economic model 2.1.4 CoAP-HTTP proxy. . . . 2.1.5 Swarm minimum broker. 2.1.6 Access control model . . 2.2 Related visions . . . . . . . . . . 2.3 Other related frameworks . . . . 2.3.1 OWL-S . . . . . . . . . . 2.3.2 WSMO . . . . . . . . . . 2.3.3 Hydra . . . . . . . . . . 2.3.4 oneM2M . . . . . . . . . 2.3.5 SWoTPAD . . . . . . . . 2.3.6 OSF . . . . . . . . . . . 2.3.7 ReLL . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. 1 3 4 5 5 5 6. . . . . . . . . . . . . . . . .. 7 7 7 10 11 12 13 13 15 17 17 17 18 18 18 19 19. 3 Framework definition 21 3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 vii.

(10) viii. CONTENTS. 3.2. 3.3. 3.1.1 Device . . . . . . . . . . . . 3.1.2 Network . . . . . . . . . . . 3.1.3 Framework . . . . . . . . . 3.1.4 Interaction . . . . . . . . . . Main components . . . . . . . . . . 3.2.1 Service description . . . . . 3.2.2 Service discovery . . . . . . 3.2.3 Semantic query description 3.2.4 Code generator . . . . . . . 3.2.5 Swarm ontology . . . . . . 3.2.6 Semantic registry . . . . . . 3.2.7 Mediator . . . . . . . . . . . 3.2.8 Service execution . . . . . . 3.2.9 Service composition . . . . 3.2.10 Score computation . . . . . Discussion . . . . . . . . . . . . . .. 4 Framework architecture 4.1 Service description model . . . . 4.1.1 Objectives . . . . . . . . 4.1.2 Structure . . . . . . . . . 4.1.3 Serialization . . . . . . . 4.2 Swarm ontology . . . . . . . . . 4.2.1 Structure . . . . . . . . . 4.2.2 Extension . . . . . . . . 4.3 Query description model . . . . 4.3.1 Structure . . . . . . . . . 4.3.2 Serialization . . . . . . . 4.4 Semantic service discovery . . . 4.5 Semantic registry . . . . . . . . 4.5.1 RDF generator . . . . . 4.5.2 Query generator . . . . 4.5.3 Semantic inference . . . 4.6 Score computation . . . . . . . . 4.6.1 Type equivalence score . 4.6.2 Geolocation score . . . . 4.6.3 Price . . . . . . . . . . . 4.6.4 Reputation score . . . . 4.6.5 Combined score . . . . . 4.7 Code generation module . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. 21 22 22 22 24 24 25 25 25 25 25 25 25 26 26 26. . . . . . . . . . . . . . . . . . . . . . .. 29 29 29 31 34 34 34 36 36 37 38 38 41 41 42 42 42 43 45 46 46 47 47.

(11) ix. CONTENTS. 4.7.1 Structure . . . 4.7.2 Outcome . . . 4.8 Service invocation . . 4.9 Mediation mechanism 4.10 Service composition .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 5 Implementation and use case 5.1 Implementation . . . . . . . . . . . . 5.1.1 Code generator . . . . . . . . 5.1.2 Semantic registry . . . . . . . 5.1.3 Swarm ontology . . . . . . . 5.2 Use case . . . . . . . . . . . . . . . . 5.2.1 Use case description: Lost cat 5.2.2 Participants . . . . . . . . . . 5.2.3 Using the framework . . . . . 6 Results 6.1 Evaluation . . . . . . . . . . . 6.1.1 Programming effort . . 6.1.2 Execution time . . . . 6.1.3 Storage . . . . . . . . 6.2 Comparison with other works. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. . . . . . . . .. . . . . .. . . . . .. 48 48 49 50 51. . . . . . . . .. 53 53 53 54 55 55 55 55 56. . . . . .. 61 61 61 63 64 65. 7 Conclusions 69 7.1 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Bibliography. 81.

(12) x. CONTENTS.

(13) List of Abbreviations API IoT CoAP GUI HTTP IDE RDF REST SOAP SPARQL WoT XML. Application Programming Interface Internet of Things Constrained Application Protocol Graphical User Interface Hypertext Transfer Protocol Integrated Development Environment Resource Definition Framework Representational State Transfer Simple Object Access Protocol SPARQL Protocol and RDF Query Language Web of Things eXtensible Markup Language. xi.

(14) xii. LIST OF ABBREVIATIONS.

(15) List of Figures 1.1 1.2 1.3 1.4 2.1 2.2 2.3. Generic Internet of Things architecture. . . . . . . . . . . . . . . . . . . . . . . . . Simple communication between human and IoT network. . . . . . . . . . . . . . . Overview of the main challenges in the Swarm project. The main challenges of this thesis are highlighted in dark grey. . . . . . . . . . . . . . . . . . . . . . . . . Our framework helps programmers to create rich interaction in IoT applications.. 1 2 4 4. 2.4 2.5. Decentralized structure of the Swarm. . . . . . . . . . . . . . . . . . . . . . . . . Structure of the Swarm Broker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture of the CoAP-HTTP proxy for the Swarm. a) High-level diagram of the CoAP-HTTP communication. b) Data workflow in both directions. . . . . . High-level diagram of the Swarm Minimum Broker. . . . . . . . . . . . . . . . . Architecture of the access control module of the Swarm. . . . . . . . . . . . . .. 3.1 3.2 3.3. Different types of device interaction. . . . . . . . . . . . . . . . . . . . . . . . . . 22 Main components of the proposed framework. . . . . . . . . . . . . . . . . . . . . 24 Main use cases of the framework from the developer point of view. . . . . . . . . 27. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10. Structure of JSON-LD object. . . . . . . . . . . . . . . Example of a semantic service description. . . . . . . Swarm ontology. . . . . . . . . . . . . . . . . . . . . . Example of a semantic query description. . . . . . . . Sequence diagram of the semantic service discovery. Architecture of the Semantic Registry service. . . . . Architecture of the Swarm code generator. . . . . . . Functioning of Service invocation module. . . . . . . An example of the mediation mechanism. . . . . . . . Declarative composition of services. . . . . . . . . . .. . . . . . . . . . .. 31 35 37 39 41 42 48 50 51 52. 5.1 5.2 5.3 5.4 5.5. Excerpt from the generated service code, showing the operation implementation. Services that participate in the use case. . . . . . . . . . . . . . . . . . . . . . . . . Service description of the VisionFinder service. . . . . . . . . . . . . . . . . . . . . Declarative composition of services in the Swarm. . . . . . . . . . . . . . . . . . . Excerpt from the ontology used in the Lost cat use case. . . . . . . . . . . . . . . .. 54 56 57 58 59. xiii. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . 8 . 11 . 12 . 13 . 14.

(16) xiv. LIST OF FIGURES. 6.1 6.2. Comparison of lines of code for the same application before and after using the framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Comparison of execution time for tasks with and without the use of the framework. 64.

(17) List of Tables 4.1 4.2 4.3 4.4 4.5 6.1 6.2. Non-functional properties categorized by O’Sullivan et al. (2005) compared to our service description model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties describing the functionality of a service. . . . . . . . . . . . . . . . . Parameters used to compute the score for candidate services. . . . . . . . . . . . Matching degrees between concepts. . . . . . . . . . . . . . . . . . . . . . . . . Partial score matrix for type matching. . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 30 39 43 44 44. Comparison of lines of code between the different tasks performed in the framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Comparison of the features of our framework with similar works. . . . . . . . . . 67. xv.

(18) xvi. LIST OF TABLES.

(19) Chapter 1. Introduction Everyday objects are today provided with microprocessors and Internet connection, unveiling the potential of a global network of devices which interact in new ways; this paradigm is called the Internet of Things (IoT). In the IoT, a wide range of devices, mainly resource-constrained, connected to others to cooperate and reach common goals (Giusto et al., 2010). Current applications of the IoT include transportation, logistics, healthcare, smart environments (home, office, manufacturing), and social applications. As several reviews show (Aggarwal et al., 2013; Atzori et al., 2010; Sethi and Sarangi, 2017), most IoT architectures are mainly cloud-centric. In general, sensor readings are transmitted to the cloud, which stores and analyses the data. After a decision-making stage, actions are taken, by sending commands to the actuators of the network. Figure 1.1 illustrates this generic architecture. Similarly, Taivalsaari and Mikkonen (2017) highlight the evolution of the cloud-centric data-centric Internet of Things towards the so called Programmable World, where smart edge devices become programmable components of complex cyberphysical systems. They also identify several challenges for software developers in the future Internet of Things. Figure 1.1: Generic Internet of Things architecture.. On the other hand, the latest IDC Worldwide Internet of Things Spending Guide forecasts a global spending of USD 1 trillion in 2022 (Siviero et al., 2019). The report also points hardware, software, 1.

(20) 2. 1.1. INTRODUCTION. data analysis and services as the main target of investments by companies. The potential number of people involved in the development of the IoT is also increasing. According to the United Nations (UN HABITAT, 2016), urban population will grow 12% in the next 30 years. In this context, Tsiatsis et al. (2019) recognize the importance of overcoming the barriers for the creation of IoT solutions in the real world. These barriers are related to the large number of heterogeneous devices and the diverse forms of device organization in an IoT system. Besides the training of skills for IoT development, it is necessary to create new frameworks to overcome the challenges of the future IoT. The present thesis aims to contribute in that direction. The Swarm project In order to provide a software infrastructure for the scenario described above, the Swarm platform (Costa et al., 2015b; Lee et al., 2014) was created aiming to be an organic, heterogeneous and decentralized network of things. The Swarm is an ongoing project with an extensive list of challenges, described in Section 1.1. The ultimate objective of the Swarm is to create an intelligent network of resource-sharing devices for the future Internet of Things. Moreover, to contribute to eliminate the barriers of access to a large network of devices, one of the main commitments of the Swarm is to provide rich and high-level communication with people, while encapsulating the complexity of device communication and organization to accomplish sophisticated tasks. This envisioned communication between human and network is illustrated in Figure 1.2. Our framework is designed with the objective of providing concrete advances towards the realization of this communication. Nonetheless, given the complexity of such effort, at this point we focus on providing the necessary tools for a programmer to create this device interaction in an effective way, as depicted in Figure 1.4. IoT network (Swarm). User intention . non-technical user. Expected result. device interaction. Figure 1.2: Simple communication between human and IoT network..

(21) 1.1. 1.1. CHALLENGES. 3. Challenges. The framework proposed in this thesis aims to solve the challenges related to device interaction in the Swarm. Our understanding of device interaction refers to different forms of communication between devices with the purpose of performing a more complex task. We identify four types of interaction, summarized as follows: • Registration is the process of a new device to enter into an existing IoT network, using a service description model. • Discovery is the search of a specific device in the network that fulfills the desired characteristics. It involves a service and query description mechanism. • Composition is the combined use of more than one device to perform a task. • Mediation is the communication of otherwise incompatible devices with the help of an adaptation layer. These interaction types are fully described in Section 3.1. The long-term objective of this framework is to provide the necessary models, specifications, libraries and tools to create an intelligent network of cooperating devices. Figure 1.3 shows the challenges of the Swarm project (ellipses), highlighting the challenges of this thesis in (dark grey ellipses), which are summarized as follows: • Interoperability — The proliferation of heterogeneous and incompatible applications is a common problem in current Internet of Things. To contribute with the solution of this problem we propose the use of a semantic-based unified model for service API, which can be adopted with minimum effort, while not requiring previous knowledge on ontologies from the developer. • Composability — After having interoperable devices, the next challenge is to combine the functionality of several devices to accomplish a larger task. Our framework aims to create models and tools for service composition, including registering, discovery, and mediation. • Rapid application development — As Giang et al. (2015) identifies, there is a lack of tools for agile development of IoT applications, that include the distributed and heteroge-.

(22) 4. 1.2. INTRODUCTION. communication flow. command interpretation real-time processing context awareness. resource sharing. resourceconstrained devices. network topology. Swarm. access control. location. human interface. heterogeneity service-level agreement. mobility. information presentation. proxy. device interaction. network complexity. billing. privacy quality of service. virtual communities. service discovery. query format. service description. automatic composition. authentication. semantic annotation. virtual economy. automatic execution. reputation. security trust. Figure 1.3: Overview of the main challenges in the Swarm project. The main challenges of this thesis are highlighted in dark grey.. neous nature of devices. Creating a general purpose set of tools for IoT applications is a challenging task, and in this work we focus on produce a framework adapted to the Swarm model. These ideas can be adapted and generalized to other types of IoT platform. IoT network (Swarm). User intention . programmer non-technical user. Declarative device composition . Expected result. device interaction. Figure 1.4: Our framework helps programmers to create rich interaction in IoT applications.. 1.2. Problem definition. The problem that this thesis intends to solve can be stated as follows: how to create a framework that permits the agile development of IoT applications with flexible interaction among devices. In this problem definition, we consider the following concepts • Agile development — Referring to the use of simple, legible, easy-to-understand models.

(23) 1.5. OBJECTIVE. 5. for the description of the application. It also includes the creation of tools that automate repetitive, redundant and verbose tasks to save programming effort. • Flexible — Related to the possibility of getting equivalent results for a query, thus extending the coverage of the target results. • Interaction — Related to the diverse forms of communication among devices, which include discovery, composition, and mediation. It also includes the social aspect of interaction, such as the motivation and incentives of devices to choose the conditions for cooperation with other devices.. 1.3. Objective. The main objective of this work can be stated as: 1. Provide the Swarm with platform service to find other services based on a taxonomy of functionalities. 2. Provide a mechanism for automatic invocation of services in the Swarm, based on a machinereadable API. 3. Create a mechanism for services in the Swarm to autonomously organize and combine functionalities in order to perform high level tasks.. 1.4. Hypothesis. Based on recent successful uses of semantics in diverse aspects of the Internet of Things, such as interoperability (Noura et al., 2019), discovery (Zorgati et al., 2019), data exchange (Kolbe et al., 2019) we propose the following hypothesis: using semantics as a driving technique, we can create a communication framework that permits flexible discovery, automatic execution, and composition of services in an IoT network.. 1.5. Contributions. The contributions of this work are summarized below: • The definition and implementation of a framework for discovery, execution, and compo-.

(24) 6. INTRODUCTION. 1.6. sition of services in an Internet of Things network. This is the main contribution of this work and comprehends the other contributions. • A simple description format for declarative description of semantic services. • A basic ontology for semantic service description. • The concept of service mediators, that permit communication among otherwise incompatible services. • A declarative mechanism for service composition. • A tool for code generation from declarative service description. • A ranking mechanism for choosing the most suitable device in an interaction process. • An ontology for geolocation of devices in an IoT network.. 1.6. Thesis structure. This thesis is structured as follows. Chapter 2 introduces the Swarm project and explores relevant work related to this thesis. In Chapter 3 we provide an overview of the main concepts and the functioning of the proposed framework. Chapter 4 explains in detail the components of the framework. Next, in Chapter 5 we describe the implementation of the framework and its integration into the Swarm platform. The results of this work are presented in Chapter 6, and Chapter 7 provides a final discussion on the thesis..

(25) Chapter 2. Basic concepts and technologies 2.1. The Swarm. The swarm term was first proposed by Rabaey (2011) to refer to sensory found at the edge of the cloud, and identified the opportunity for the realization of areas such as cyber-physical systems, cyber-biological systems, immersive computing and augmented reality. Rabaey also identified the key challenges to leverage the potential of this swarm. Those challenges include the transparent integration of sensors with the environment; the self-contained and self-sustaining nature of the nodes; the non-linear, non-deterministic adaptive and complex nature of the swarm network; and the creation of a general framework that enables a seamless communication among heterogeneous devices. Subsequent work led to a more concrete definition of the Swarm. Lee et al. (2014) proposed an initial architecture for the Swarm in the context of a larger project called TerraSwarm. They also outlined a common framework for resource sharing among devices, called SwarmOS. The architecture of the SwarmOS framework was further developed by Costa et al. (2015b), complementing the already existing distributed storage system (data plane) with a module responsible for the sharing and management of resources (control plane). 2.1.1. The Swarm project. The Swarm project1 is the umbrella project where this thesis has its basis. This project is under active development in the Centre of Interdisciplinary and Interactive Technologies of the University of São Paulo (CITI-USP)2 in cooperation with the SwarmLab at University of Berkeley3 . The main objective of the Swarm project is to overcome the limitations of cloud-centric IoT architectures. The Swarm is defined as a self-adaptive network for autonomous smart objects, where devices do 1. http://iotswarm.info/ http://www.lsi.usp.br/citi/en/ 3 http://swarmlab.berkeley.edu/ 2. 7.

(26) 8. BASIC CONCEPTS AND TECHNOLOGIES. 2.1. not rely on the cloud for storage and processing, but instead, part of this work can be performed in the device itself. The Swarm is a heterogeneous network constituted of different kinds of devices, with variable computing power and energy capabilities. In Figure 2.1 we illustrate the general structure of the Swarm. Making a parallel with swarm of bees, with specialized bees contributing to a common goal, the Swarm is composed of specialized devices whose interaction solves a common problem. The Swarm network behaves like an organism and shows an organized behavior that results in an emergent collective intelligence. Figure 2.1: Decentralized structure of the Swarm.. Device functionalities are exposed and shared to the network as services. Thus, the Swarm can be seen as a large network of interacting services. Every service is specialized in a specific functionality, and many services can perform similar or equal functionalities. The true potential of the Swarms resides in the composition of services, which dramatically extends the functionalities offered by the network. Given the intersections with the microservices architectural style, we adopted many of its concepts for the Swarm, such as the use of services as the main building block; loose coupling and high cohesion; decentralized governance; decentralized data management; and evolutionary design (Fowler and Lewis, 2014). Interaction among devices is performed opportunistically, with no prior agreement. The connection among devices is established in real-time, based on the availability of devices in the network. As a response to an external event, devices in the network form groups in order to perform an action or give an answer. Although those groups formed are transient, the success of each interaction is recorded in the network and serves to build a measure of reputation for each device..

(27) 2.1. THE SWARM. 9. Key challenges Key challenges to achieve the Swarm vision, include a large variety of aspects that are currently under development, which are summarized as follows: • Heterogeneity — Heterogeneity in the Swarm is present in many aspects. Differences in participant devices can be found in functionalities, computing power, description formats, communication protocols, and response time, among others. The project aims to provide a common communication framework that takes advantage of existing open and mature standards. A particular focus on resource-constrained devices is given, since the installation of software on those devices is not straightforward, and must be done with minimum impact. • Security — Although the security challenge in computer systems is not new, in the context of the IoT and the Swarm it is even more challenging. Many devices do not have enough computing power and energy to support strong cryptographic algorithms, used in authentication and authorization. Additionally, the need for rapid development and release of products in the consumer market precludes the exhaustive testing of basic security capabilities in new products. Finally, as the Swarm network is composed of autonomous devices, policies for a fair interaction must be provided to avoid abuse. • Device interaction — Once the barriers of heterogeneity and security have been overcome, the next challenge consists in guaranteeing the device interaction. This interaction happens in the service level, as services are the building block of the Swarm network. To effectively create an organic and self-organizing network of services, they must be capable of composing automatically, based on network demand. The first step to initiate an interaction is to perform a search for services (discovery). Then, services must be capable of invoking others automatically, based on its machine-readable description. Finally, services must be capable of automatically combining its capabilities to perform a higher level task. • Resource sharing — After the device interaction is guaranteed in the Swarm network, the next step is the creation of a rewarding mechanism for service invocation. This effectively constitutes a network of cooperation among devices. New concepts arise in the.

(28) 10. BASIC CONCEPTS AND TECHNOLOGIES. 2.1. network such as trust, virtual currency, billing, reputation, and a full virtual economic system. This phenomenon represents a perfect parallel to a growing trend in current world economy called sharing economy, which favors the sharing of physical resources over the acquisition of new ones. Resource sharing in the Swarm represents its digital equivalent. A consequence of resource sharing is a reduction of uncontrolled consumption and a better global use of resources. • Human interface — The Swarm described so far is composed mainly of machine-tomachine (M2M) interactions. Nonetheless, the human component is essential as it is the main source of external events and request to the network. Innovative ways of interaction with this large network constitute a major challenge. Humans should have no barriers to take full advantage of the network, by asking actions in a high-level language. The format of the response and the establishment of a communication flow must also be carefully studied. The Swarm network must take advantage of the diversity of devices for acquisition and presentation of information. 2.1.2. Swarm Broker. One of the most important components in the Swarm platform is the Swarm Broker, which is a software installed in every IoT device and acts as a communication facilitator. Some functions provided by the Swarm Broker include service registry, semantic service discovery, access control policy enforcement, service contracting, and blockchain-based reputation. Additionally, the Swarm Broker provides a transaction model that mediates contracts between service consumers and providers which are through the service discovery mechanism. That interaction creates an economic model for resource sharing in the IoT. We define two categories of services in the Swarm: platform service, that constitute the core functionalities of the Swarm network; and application services, which are all other services that participate in the Swarm. Thus, the Swarm Broker can be seen as the collection of platform services. Figure 2.2 illustrates the landscape of platform services that constitute the Broker. As the Swarm network is composed of heterogeneous devices, the number of platform services varies across devices, according to its capabilities. Less powerful devices will provide fewer platform services. Current implementations include C, Lua, Java, and Elixir programming languages, with further targets are expected..

(29) 2.1. THE SWARM. 11. Figure 2.2: Structure of the Swarm Broker.. 2.1.3. Swarm economic model. The rich interaction among the participants of the Swarm network poses important challenges to guarantee the soundness and integrity of device interactions. As a result, De Biase et al. (2018b) proposed an economic model for the Swarm, that aims to regulate the transactions of services in the network. Relevant concepts are part of this model, such as trust, reputation, rewarding mechanism, and billing. The introduction of a rewarding mechanism in the Swarm platform is of major importance for the service ecosystem, as it leverages a concrete incentive for resource sharing. Devices can share its functionalities either in exchange for the use of other devices, or to accumulate credits in the SwarmCoin currency. In the economic model of the Swarm, the Swarm Broker is responsible for linking the parties and for facilitating transactions. The price of a resource represents the number of credits necessary for the service provider to grant access to the service consumer. Credits belong to the owner and are used by the service to contract or purchase any service on behalf of its owner. The Swarm economic model is based on the price of a service and the reputation of both service consumer and provider, hence it is called the pricereputation model. A service provider defines the number of credits necessary to allow a third party to use it. During the transaction process, reputation points evaluate the success of the operation. The price-reputation transaction is the simplest transaction defined for the Swarm framework: the consumer gets the service by paying a number of credits settled by the provider, depending on.

(30) 12. BASIC CONCEPTS AND TECHNOLOGIES. 2.1. their behavior, they both get reputation points during the process. Regarding security, the distributed and decentralized nature of the Swarm requires a new model for transactions. Traditional technologies, such as the public key infrastructure (PKI), are not suitable as they demand a centralized certificate authority (CA). Accordingly, the Swarm adopted the blockchain technology, used in the Bitcoin cryptocurrency, to create a decentralized mechanism for trust in the economic model of the Swarm network (De Biase et al., 2018b). The advances in an economic model for the Internet of Things go in the same direction of a growing trend in the world economy: sharing economy. As in the physical world, the Swarm favors the digital sharing of resources over the acquisition of dedicated devices. As a consequence, it produces a reduction of device consumption and better global use of resources. 2.1.4. CoAP-HTTP proxy.. The Constrained Application Protocol (CoAP) is a standard application protocol, designed to implement RESTFul services in constrained devices, thus being an optimized alternative to HTTP. Esquiagola et al. (2017) proposed a proxy mechanism for the Swarm that permits seamless communication between services that implement both protocols. Figure 2.3-a illustrates the highlevel communication between services in the Swarm, grouped by the implemented protocol. Services send a request to the associated broker, which forwards it to the proxy for message translation and, in turn, forwards the message to the target service. That way, none of the services needs to know in advance that the communication is being performed through another protocol. Additionally, Figure 2.3-b shows the bidirectional implementation of the proxy, which permits CoAP-HTTP and HTTP-CoAP communication, thus extending the coverage of the Swarm network for resource-constrained devices.. Figure 2.3: Architecture of the CoAP-HTTP proxy for the Swarm. a) High-level diagram of the CoAP-HTTP communication. b) Data workflow in both directions..

(31) 2.1 2.1.5. THE SWARM. 13. Swarm minimum broker.. To overcome the challenge of heterogeneity in the IoT, a Swarm Minimum Broker (MB) contains the core features necessary for a device to be part of the Swarm network. That way, devices with resource-constrained resources can use an external software proxy to translate communication (De Biase et al., 2018a). The basic requirements for Swarm participants are being discoverable and usable. Thus, a simplified implementation can provide support for requests through different protocols, such as HTTP and SSDP. Figure 2.4 illustrates the interaction between Minimum SwarmBroker and common Swarm Broker, focusing on the discovery process.. Service. Service. Minimum Broker. Swarm Broker. supports: - registry - locate. full support for platform services . Figure 2.4: High-level diagram of the Swarm Minimum Broker.. 2.1.6. Access control model. Security in the Swarm platform includes both the protection of exchanged messages and a flexible access control mechanism over shared resources. Furthermore, managing the access control of a large number of devices becomes a significant challenge. The access control mechanism of the Swarm platform is based on the Attribute-Based Access Control (ABAC) model (Hu et al., 2015). In ABAC, a subject requests to perform operations on objects and is granted or denied, based on attributes of the participants. The referred attributes can be related to the subject, the object, environment conditions, and policies. The ABAC-based model created in the Swarm platform is called ABAC-them (Fedrecheski et al., 2018) and focuses on combining simplicity and expressiveness. The main characteristics of ABAC-them model are:.

(32) 14. BASIC CONCEPTS AND TECHNOLOGIES. 2.2. • Enumerated policies — attribute enumeration allows the creation of policies that are easy to parse and to embed into small devices. • Hierarchical attributes — allow the creation of high-level policies that are easier to write and understand. During execution time, low-level attributes present in access requests benefit from attribute hierarchies, which allow them to match with the high-level policies. • Typed attributes — provides a counterbalance to policies that can grow large when using enumeration, such as those involving numerical ranges. • Multiple attributes — very specifically, this feature allows easy creation of conjunctions when using enumerated policies. The ABAC-them model was implemented within an architecture based on the NIST recommendation for ABAC systems (Hu et al., 2014). The architecture contemplates four main components. The Policy Decision Point (PDP) evaluates policies that are managed through the Policy Administration Point (PAP), while the Policy Information Point (PIP) is responsible for gathering context and other attributes, and the Policy Enforcement Point (PEP) intercepts requests and verify their permission with the PDP. While the original NIST architecture proposes that PDP, PIP, and PAP reside in an authorization server, the SwarmOS implementation puts all points inside the IoT device, thus enhancing its autonomy and security. Figure 2.5 illustrates the current architecture of the ABAC-them model in the SwarmOS.. Figure 2.5: Architecture of the access control module of the Swarm..

(33) 2.2. 2.2. RELATED VISIONS. 15. Related visions. Several ideas and initiatives intersecting with the Swarm network were previously proposed. In this section we review work with focus on decentralized, self-adaptive and organic systems, which we consider the features that better characterize the differentiation of the Swarm from centralized IoT systems. Weiser (1995) proposed the term Ubiquitous Computing as a future reality with computers strongly present in human activities while being almost invisible. Such invisibility refers to not having prominence in the interaction, but acting as a facilitator. Weiser envisioned computers as invisible and ever-present tools for human tasks. Despite the experimental work done to demonstrate this concept, the technological enablers were not enough at that time. Horn (2001) while working at IBM, identified the important challenge that complexity represented for the future of computing systems. It manifests in overlapping connections, interactions, and dependencies of heterogeneous systems, whose managements goes beyond human capabilities. According to him, the solution to manage complexity is to create systems that mimic the functioning of the human autonomic nervous system. An essential feature of an autonomic system is its self-management. It is analogous to the regulation of heart rate or body temperature in response to external conditions, to maintain a steady internal state. A system of this nature should implement four basic features: self-configuration, self-optimization, self-healing, and selfprotection. Elements of an autonomic system are also autonomic and interact according to its own goals. The need for self-managed systems gains a renewed importance in the context of increasing complexity of the Internet of Things. The Swarm vision shares many concepts with Autonomic Computing. Boley and Chang (2007) proposed an analogy between biological and digital ecosystems. Several different species co-exist in an environment. Species get necessary resources from environment and also preserve it. Members of a species are individuals. Four aspects are essential for ecosystems: interaction and engagement, that includes sharing resources and forming groups, thus guaranteeing the social well-being; balance, that maintains the harmony of the ecosystem and contributes to its sustainability; domain clustered and loosely coupled, individuals, on their own.

(34) 16. BASIC CONCEPTS AND TECHNOLOGIES. 2.2. choice, form groups according to similar interests and objectives; and self-organization, which implies the autonomy of species, and the coordination through swarm intelligence. In digital ecosystems a swarm is defined as a set of agents interacting and engaged agents that solve a common problem. Also, Boley and Chang highlight the advantages of using semantic web technologies for information exchange, modeling of attributes and integrity check. The interaction among devices inspired in swarm intelligence and the self-organization capabilities also served as inspiration for the device interaction in the Swarm. Atzori et al. (2012) work share some similarities with the Swarm vision. They study the relationships of cooperation among IoT devices. Unique identification and description of resources are necessary for this cooperation. However, the proposed architecture for Social IoT relies on a central server that is responsible for composing services. That server has three modules a database with device information; a module for device interaction; and an application layer that provides service composition. The Swarm vision shares the treatment of devices as participants of a social group and extends this idea to create the concepts of trust, reputation and even a virtual economy. Zambonelli (2012) calls superorganism a system formed by a group of organisms that exhibit intelligent and adaptive collective behavior, giving as examples, colonies of ants, honeybees, and termites. Zambonelli foresaw the emergence of urban superorganisms, composed by sensing devices deployed across the city, enriched by information from human users, in order to create an aggregate system capable of providing value added to its environment. The author also highlights the challenges to achieve this vision, such as models and software for sociotechnical processes, the understanding the human-device interaction in large scale, and, incentives for sharing, including a monetary approach. The Swarm vision shares some challenges with this approach, and many of the ideas served as inspiration. In the last decade, the cloud has emerged as the main responsible for storing and analyzing information. The IoT adds a communication layer between the physical and logical world, by adding sensor and actuator devices to software systems. In a first stage of the IoT, resource-constrained devices act as providers of data that feeds the cloud. Currently, IoT devices are empowered and less dependent on third parties. Evidences of this new paradigm can be found in recent work,.

(35) 2.3. OTHER RELATED FRAMEWORKS. 17. named as fog computing (Bonomi et al., 2012) and edge computing (Shi et al., 2016). In fog computing, part of the processing and storage is delegated to general purpose computers and network equipment closer to IoT devices. In edge computing, devices themselves run the services needed for the operation of the network. The definitions of edge and fog have points of intersection and agree on performing computing closer to the devices. The Swarm vision has many coincidences with the edge computing paradigm. Both aim to make the devices less dependent of the cloud, and favors a more decentralized IoT. The Swarm, however, goes beyond the ideas of independence and decentralization. We stress the cooperation of devices and the emergence of collective intelligence.. 2.3. Other related frameworks. In this section we review other related frameworks, in order to explore the similarities with the present work. In Chapter 6 we provide a comparison and in Table 6.2 we present a summary of this analysis. 2.3.1. OWL-S. OWL-S was one of the first initiatives to integrate the Semantic Web into existing Web service technologies (Martin et al., 2004). As a result, OWL-S proposes an ontology to describe a service using the Web Ontology Language (OWL)4 . Due to the time of creation of OWL-S, it was designed to interact with SOAP Web services, which are considered heavyweight and are not suitable for IoT applications. Several efforts based on the OWL-S project proposed important contributions, such as automatic service composition (Klusch et al., 2005; Sirin et al., 2004) and service mediation (Vaculín and Sycara, 2007). 2.3.2. WSMO. The WSMO project was a European initiative (Jos de Bruijn et al., 2005) that aimed to provide a complete platform for the development of semantic Web services, including an ontology (WSMO), a powerful modeling language for the specification of service descriptions and queries (WSML), an Eclipse-based programming environment (WSMT), and a runtime execution environment (WSMX). Similarly to OWL-S, the WSMO project was targeted to SOAP projects, nonetheless, 4. https://www.w3.org/OWL/.

(36) 18. BASIC CONCEPTS AND TECHNOLOGIES. 2.3. further initiatives proposed integration with RESTful services, such as WSMO-lite (Vitvar et al., 2008) and hRESTS (Kopeck`y et al., 2008). 2.3.3. Hydra. The Hydra5 project (Lanthaler, 2013) aims to provide a semantic description of Web APIs for RESTful services. This project was created by the same author of the JSON-LD model 6 , and was built on top of it. JSON-LD provides a general purpose format to describe linked data, in the form of Web resources. The Hydra project constitute a common vocabulary to describe Web APIs with semantic annotations, by modelling a service, its operations, input and output parameters, grounding information, and human-friendly textual descriptions. The service description that we propose in this thesis has been inspired by the Hydra Core Vocabulary. 2.3.4. oneM2M. The oneM2M7 initiative consists on an international partnership that aims to provide a global M2M service platform, by developing a set of technical specifications that constitute a service layer to be used in M2M applications. The range of specifications developed by the oneM2M project includes protocols, APIs, security and privacy, interoperability, data collection, and device management. Additionally, oneM2M provides a set of tools to aid in the creation of applications, including clients in different programming languages. Regarding the interoperability efforts, the oneM2M project provides a Base Ontology 8 created in order to be extended by external organizations when creating specific domain applications. Also, oneM2M provides semantic discovery of devices through the use of SPARQL queries. 2.3.5. SWoTPAD. The SWoTPAD project (Silva et al., 2019), proposes a semantic framework to aid the development of IoT applications. SWoTPAD is inspired by the Semantic Web of Things (SWoT) paradigm, that uses RESTful services to model the functionalities of IoT devices. Another inspiration for SWoTPAD is the WSMO project, that provides a rich language (WSML) for creating semantic Web services. Despite being powerful, the WSML language has several disadvantages, related to its 5. https://www.hydra-cg.com/spec/latest/core/ http://www.w3.org/json-ld11 7 https://www.onem2m.org/ 8 https://git.onem2m.org/MAS/BaseOntology 6.

(37) 2.3. OTHER RELATED FRAMEWORKS. 19. complexity. In response to that, the SWoTPADL language offers a simplified, yet powerful notation for service description, including service hierarchies and instances. One of the main highlights of the SWoTPAD framework is the implementation of automatic composition of services through the use of a hierarchical task planning (HTN) algorithm, and the generation of modules for automatic discovery. 2.3.6. OSF. The OSF project (Mayer et al., 2017) was proposed to leverage the use of semantic technology into the Internet of Things. The main tasks that OSF framework provides include the acquisition, augmentation, maintaining, and reasoning over semantic knowledge. The OSF contains a set of core ontologies, common to several application domains, which are distributed in knowledge packs. Additionally, OSF provides a visualization tool, including 2D and 3D visualizations. That project was tested with an Industrial IoT application, integrating models from different subdomains of an application for workplace safety. 2.3.7. ReLL. In contrast to the focus on WS-* style Web services of initial projects, such as OWL-S and WSMO, the Resource Linking Language (ReLL) (Alarcon et al., 2011) proposed a mechanism for RESTful service composition. The ReLL annotation for services is based on XML and later transformed to RDF, to be stored and queried through SPARQL. Additionally, ReLL uses a model based on Petri Nets for static service composition..

(38) 20. BASIC CONCEPTS AND TECHNOLOGIES. 2.3.

(39) Chapter 3. Framework definition In this chapter we present a high-level overview of the functioning of the framework, introducing the main concepts and how they relate to accomplish the objectives of this work. The framework we propose was designed to assist developers to build IoT applications with rich device interaction. Although this framework was initially conceived to be integrated into the Swarm platform, the ideas presented here can be applied independently without loss of generality. We begin by stating our understanding of device interaction, then we present the basic building blocks of the framework, and discuss the use of the framework.. 3.1. Definitions. The Internet of Things in the forthcoming years will be composed of smarter devices that form decentralized networks. Accordingly, the Swarm vision, presented in Section 2.1, stresses the importance of device interaction to accomplish the goal of producing a large self-organizing network of smart agents. Next we define the concepts used in our work. 3.1.1. Device. We consider as device any piece of hardware with enough computing power and networking capabilities to send and receive messages to other devices. This definition also corresponds to the commonly used for thing in the Internet of Things literature. Similarly, as we adopted a serviceoriented approach for the framework architecture, every device that participates in the network exposes its functionality through a service, particularly a RESTful web service (Fielding and Taylor, 2002). As such a service is a representative of the underlying device where it runs, therefore, in this work we use the terms device, thing and service interchangeably as we are focused on the interactions the devices have through the services that represent them.. 21.

(40) 22. FRAMEWORK DEFINITION. 3.1.2. Network. 3.1. We define the network as the set of devices that are mutually reachable through a common communication protocol. In the context of our work, we consider that these services also share an implementation of our software library and exchange messages following according to the object models specified by our framework. 3.1.3. Framework. We define the framework as the collection of all object model specifications, their communication flow, and the respective software implementation, which runs on the devices of the network. 3.1.4. Interaction. We define service interaction as the different types of communication among devices that occur in a network of things. The ultimate goal of device interaction is to combine the functionality of individual things in order to produce an articulated behaviour of the participants that eventually creates an intelligent network. Figure 3.1 shows the device interaction considered in the context of this thesis.. discovery. creation. registration. composition. mediation. Figure 3.1: Different types of device interaction..

(41) 3.1. DEFINITIONS. 23. Creation Although it is not properly an interaction among devices, the creation of a service is the starting point in the lifetime of a service, and it represents the initial contact for the programmer with the framework. The service creation includes the definition of the service API, its implementation and execution in a concrete hardware. Registration Once a service is running, it needs to find other services in the network to interact. To accomplish this, the service scans the network to find other devices and sends its service description file to them. Among the network participants, there is one special service called semantic registry, that acts as a service directory, storing the description files of other participants. Discovery The discovery interaction consists in finding a service in the network that matches the desired functionalities based on a query file that specifies these parameters. The discovery interaction occurs with the participation of the semantic registry service, which contains the information of other participants in the network. Composition Service composition is one of the most powerful interactions and consists in combining the functionality of several services to act as a single software agent. Our framework helps the developer to define the composition of services in a declarative way. By defining the characteristics of the services to be composed, the framework performs a discovery process and then compose the execution of those services. Mediation A mediator service M helps the composition of a pair of services A and B with different input and output (incompatible). To accomplish this, M is specialized in transforming data. Formally, we express the input and output datatype of a services A and B as: A : Adomain → Arange and B : Bdomain → Brange . Then, the mediator service M is defined as M : Arange → Bdomain . The mediation mechanism is inspired in the adapter programming pattern (Gamma et al., 1995).

(42) 24. 3.2. FRAMEWORK DEFINITION. and applied to a service-oriented architecture. Mediator services are treated as special services in our framework, as there is no need to specifically declare them in a composition list. The use of service mediators greatly extends the composition potential of the network. It is important to note that the benefits of the mediation mechanism will depend on the active participation of the developers of the Swarm community to create and share these services.. 3.2. Main components. Based on the interaction types defined in previous section, we identify the key components that serve as building blocks for the framework. A high-level overview of these concepts is depicted in Figure 3.2 showing the main relationships. Service discovery Query Description. Semantic Service Description. Code generator. Service. Semantic registry. Score computation. Mediator. Swarm Ontology. Service. Service composition and execution. Figure 3.2: Main components of the proposed framework.. 3.2.1. Service description. A simple human-readable file that contains essential service information, including the provided operations. This file contains semantic information about the service types and exchanged data. Writing this file does not require previous knowledge about semantics from the service creator. Additionally, this file permits the developer to declaratively define a list of services to be discovered and composed. This service description model is presented in detail in Section 4.1..

(43) 3.2 3.2.2. MAIN COMPONENTS. 25. Service discovery. The process of searching a service in the network, given expected functional and non-functional properties, such as geolocation, input and output type, service and operation type, price, and reputation. 3.2.3. Semantic query description. A simple human-readable file that contains the necessary information to find a service in an IoT network. The format of the Semantic query description is presented in detail in Section 4.3. 3.2.4. Code generator. A module that takes a semantic service description file as input and produces a service implementation ready to run in the IoT network, thus facilitating the development of IoT applications. This module is presented in detail in Section 4.7. 3.2.5. Swarm ontology. An ontology that models the structure of services in the Swarm network, including operations, geolocation, reputation, and price. This ontology is used as the basis for a full taxonomy of services, and data types, ready to be extended by the community of developers. The Swarm ontology is introduced in Section 4.2 3.2.6. Semantic registry. A service that stores and retrieves the description files of other services in the network through the processing of query description files. The Semantic registry is presented in Section 4.5 3.2.7. Mediator. A powerful concept inspired on the Adapter pattern (Gamma et al., 1995). Mediator is a special type of service that permits the communication among services with incompatible data types, thus enriching the possibilities of service composition. Several mediators can exist for the same task and are ranked according to their relevance. 3.2.8. Service execution. A module responsible for automatically invoking a service based on the service description information with no prior knowledge of the API. This mechanism is explained in Section 4.8..

(44) 26. FRAMEWORK DEFINITION. 3.2.9. Service composition. 3.3. A simple mechanism for declarative service composition, based on operation, input, and output types. The composition of services is enriched by the participation of mediator services, as explained in detail in Section 4.9. 3.2.10. Score computation. A ranking is performed to select the best candidates in a service discovery process, based on the score of each candidate against the requested service. The computation of this score considers the relevant information in service and query description models. The complete description of this score is explained in Section 4.6.. 3.3. Discussion. From the developer point of view, we can summarize the main uses of the framework in Figure 3.3, showing the main use cases, the action required from the developer, and the expected functionality provided by the framework..

(45) 3.3. DISCUSSION. developer. framework. sd.jsonld. Creation. { ——— ——— ——— } service description. $ generate sd.jsonld. generates a runnable project includes dependencies. command line. sd.jsonld. Registration. { ——— ——— ——— } service description. swarmlib.register(sd.jsonld). scans network finds other participants sends service description. code snippet. qd.jsonld. Discovery. { ——— ——— ——— } query. Composition. swarmlib.discovery(qd.jsonld). compares the query against registered services returns a list of ranked service candidates. code snippet. ... compose : { f: { ——— }, g: { ——— }, h: { ——— } } .... discoveries f, g and h. executes f(g(h())). service description. Figure 3.3: Main use cases of the framework from the developer point of view.. 27.

(46) 28. FRAMEWORK DEFINITION. 3.3.

(47) Chapter 4. Framework architecture In Chapter 3 we presented a high-level panorama of the framework, describing the main concepts and its relationships. This chapter provides a detailed description of the rationale and functioning of these concepts. An entire section is devoted for each component, explaining the rationale, architecture and examples.. 4.1. Service description model. A service description file serves to document and advertise the service functionalities in a network. It contains all the information for the service to be discoverable and usable by other software agents. The properties contained in a service description file are usually classified in functional and non-functional. Functional properties are related to the execution of a service and constitute the actual service API, such as endpoint, input, output. All other properties are considered non-functional and serve to specify and constrain the use of the service, including properties such as price, quality of service, and reputation (O’Sullivan et al., 2002). The functional properties of the service are contained in operations section. Accordingly, the non-functional properties of our framework are summarized in Table 4.1, based on the thorough analysis of non-functional properties by O’Sullivan et al. (2005). Thus, geolocation, pricing, reputation and @id, in conjunction with operation serve to fully describe a service in our framework. Regarding the temporal model in Table 4.1, the Swarm access control model, proposed by Fedrecheski et al. (2018) and described in Section 2.1.6, defines a policy-based mechanism to constrain the temporal use of a service. In future versions of this framework, both models will be unified in a single comprehensive block. 4.1.1. Objectives. We have identified the following objectives to accomplish through the use of the service description model. 29.

(48) 30. 4.1. FRAMEWORK ARCHITECTURE. Category. Description. Framework equivalent. Locative model. Physical and digital service location. geolocation. Service provider. Unique identification of providers. @id. Obligations. Mutual service responsibilities. pricing and reputation. Temporal model. Availability described in time units.. In access control model*. Service availability. Combination of locative and temporal. defined on demand by Broker. Table 4.1: Non-functional properties categorized by O’Sullivan et al. (2005) compared to our service description model.. 1. Advertise the service functionality in an IoT network. That way the service is discoverable and executable by other services in the network. The service description file must be sent to the network and stored in a service directory for further search (Section 4.5). 2. Define a common API for services. Third-party services must be able use this model to describe their operations and interact in the Swarm network through the semantic discovery mechanism (Section 4.4). 3. Facilitate agile service implementation across several platforms. Through the use of a Code generator tool (Section 4.7), a software project for the service must be generated, thus saving development time. Additionally, specific code for different target platforms can be generated. 4. Serve as an API documentation. As the service description model contains the detail of the service operations, including input and output data types, it can be used as a humanreadable documentation, similar to the popular Swagger1 model. 5. Permit automatic service invocation. The model must contain the necessary information for the service to be executed without prior knowledge of its API. A similar initiative for documenting APIs is the Hydra Vocabulary 2 (Lanthaler, 2013), which was proposed to follow the hypermedia as the engine of application state (HATEOAS) principle (Fielding and Taylor, 2002). 6. Declarative service composition. In an initial step towards automatic service composition, we consider the manual description of a service composition, specifying the characteristics 1 2. https://swagger.io https://www.hydra-cg.com.

(49) 4.1. SERVICE DESCRIPTION MODEL. 31. of the services that compose the declared service. (Section 4.10). 4.1.2. Structure. The structure of the service description model closely follows the Swarm ontology, presented in Section 4.2, thus, it contains the sections: root, operations, pricing, and geolocation. Additionally, as the structure of the service description model is based on JSON-LD (Section 4.1.3), it inherits its basic structure, illustrated in Figure 4.1. @context : abstracts all the prefixes used in object definition @id. :. unique object identifier(URI). @type. :. resource type (URI). property :. value. property :. value. .... :. other object properties. .... Figure 4.1: Structure of JSON-LD object.. • Section root The most external section contains general properties related to the service. – @context — The @context field is inherited from JSON-LD format. It can be an URI or an inline object that defines the vocabulary used in the document. The default @context for Swarm services is a link to the Swarm Ontology (Section 4.2), which defines the default concepts used in the Swarm. – @id — A valid URI that identifies the service in the network. The @id value can be an IP or a resolvable URL that points to the service. – @type — A valid URI specifying the type of the service. This should inherit the Swarm Service concept in Swarm Ontology. – broker (URI) — The URL of the Swarm Broker associated to this service (Section 2.1.2)..

(50) 32. FRAMEWORK ARCHITECTURE. 4.1. – description (text) — A human friendly description of the service. • Section operations Operations are the functional units of the service, that execute atomic actions. This section contains the list of operations that the service provides. Operation information is used for service discovery. Each operation provides the necessary information to be invoked by other agents. An operation is defined through the following fields: – @type (URI) — A valid URI specifying the type of the operation. The Swarm Ontology provides four default operations, based on the basic Hydra3 (Lanthaler, 2013), which in turn map to the basic functions for persistent storage: CreateOperation, ReadOperation, UpdateOperation, and DeleteOperation (CRUD). When extending those operations, the value of this field must inherit from the hydra:Operation class. – entry (URL path) — A valid URL path used in conjunction with @id field to identify the address of the service operation for further use (invocation). – description (text) — Human friendly text that describes the provided operation. This field serves as a documentation for the service API. – expects (URI) — A valid URI that describes the type of the input parameter. Only one parameter is supported, which must contain all the required information for the service execution. It is equivalent to the body of an HTTP request. – returns (URI) — A valid URI that describes the type of the operation output. An only response is returned. It is equivalent to the response of an HTTP request. – method (HTTP method) — A valid HTTP method (GET, POST, UPDATE, DELETE). Following the REST principles it should be chosen according to the semantics of the operation. • Section pricing 3. https://www.hydra-cg.com/spec/latest/core/.