development of support tools for the use of iot and context … · 2019. 1. 31. · nowadays the...

Lucas Cristiano Calixto Dantas

Development of support tools for the use ofIoT and context FIWARE components

Brasil

2017


Development of support tools for the use of IoT andcontext FIWARE components

Trabalho de Conclusão de Curso apresentadoao curso de Engenharia de Software da Uni-versidade Federal do Rio Grande do Nortecomo requisito parcial para a obtenção dagraduação em Engenharia de Software.

Universidade Federal do Rio Grande do Norte – UFRN

Departamento de Informática e Matemática Aplicada – DIMAp

Graduação em Engenharia de Software

Supervisor: Carlos Eduardo da Silva

Brasil2017

Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas – SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET

Dantas, Lucas Cristiano Calixto. Development of support tools for the use of IoT and context FIWARE

components / Lucas Cristiano Calixto Dantas. - 2017. 67 f.: il.

Monografia (graduação) – Universidade Federal do Rio Grande do Norte.

Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Bacharelado em Engenharia de Software. Natal, RN, 2017.

Orientador: Carlos Eduardo da Silva.

1. Engenharia de software – Monografia. 2. FIWARE – Monografia. 3. Internet das coisas – Monografia. 4. Biblioteca de desenvolvimento – Monografia. 5. Interface gráfica de usuário – Monografia I. Silva, Carlos Eduardo da. II. Título.

RN/UF/BSE-CCET CDU: 004.41


Development of support tools for the use of IoT andcontext FIWARE components

Trabalho de Conclusão de Curso apresentadoao curso de Engenharia de Software da Uni-versidade Federal do Rio Grande do Nortecomo requisito parcial para a obtenção dagraduação em Engenharia de Software.

Trabalho aprovado. Brasil, 24 de novembro de 2017:

Carlos Eduardo da SilvaSupervisor

Uirá KuleszaExaminer 1

Leonardo Cunha de MirandaExaminer 2

Brasil2017

Este trabalho é dedicado à minha família, que nunca mediuesforços para que meu aprendizado não tivesse limites.

Acknowledgements

Primeiramente a Deus, que durante toda minha vida pessoal e acadêmica me deusaúde, força, paciência e fé para enfrentar todos os desafios e discernimento nas minhas(não poucas) escolhas.

À minha família, especialmente na figura dos meus pais e irmã, por todo o incentivoe apoio e por, através das mais diversas demonstrações de amor, serem para mim exemplosmaiores de pessoas e profissionais a serem seguidos.

À minha namorada, amiga, parceira de todas as horas e futura excepcional psicóloga,que, mesmo ainda em formação, a tantos anos já vem demonstrando seu dom de me escutar,entender e apoiar em tantas das minhas angústias como poucos conseguiriam.

Ao professor, amigo e orientador, Carlos Eduardo da Silva pela confiança, desafios,oportunidades e tantas orientações, que durante o curso me guiaram, provocaram e, acimade tudo, proporcionaram uma formação ampla de que muito me orgulho.

Aos amigos e colegas, pelo todo apoio para a minha formação acadêmica e pormostrar que "mais vale amigo na praça que dinheiro no banco".

À instituição UFRN e todos os seus funcionários, especialmente aos mestres doInstituto Metrópole Digital e Departamento de Informática e Matemática Aplicada, portodos os conhecimentos repassados para uma formação para a profissão e para a vida.

“Viver é como andar de bicicleta:é preciso estar em constante movimento

para manter o equilíbrio.”(Albert Einstein)

Abstract

In the development of Internet of Things (IoT), many factors specific to these types ofapplications should be considered (such as communication protocols, di�erent devices,storage and energy constraints, for example). The various support platforms available todayare intended to facilitate some of these tasks, but many details specific to these types ofapplications must also be configured in them and, in general, the form of configuration variesaccording to the chosen platform. FIWARE is one such platform currently available. Thereare several components that must be configured and a set of APIs that must be known andstudied, all of which must be done before the development of the APIs is actually started,resulting in a huge waste of time, especially when the focus is given to the applicationdevelopment and not the internal details of platform operation. Thus, the present workaims to develop a set of solutions that aim to facilitate both the configuration of theFIWARE components that form the environment for the creation of these applications, aswell as the use of the APIs of the IoT and context management components of the platform.For this, it is presented the specification of a programming library that aims to abstractthese details and facilitate the use of the available services, as well as their implementationperformed using the Python language. In addition, a WEB client application is presented,which enables calls to the functionalities provided by the FIWARE platform throughinteraction with a graphical user interface (GUI), making it even easier to use. Finally,case studies are presented to help to exemplify the use of the developed solutions, as wellas to carry out an initial validation of their usefulness, also making comparisons with othersolutions to platforms currently available.

Keywords: FIWARE. Internet of Things. IoT. Programming library. GUI.

Resumo

Para o desenvolvimento de aplicações de Internet das Coisas (IoT), muitos fatores específicosa esses tipos de aplicações devem ser considerados (como protocolos de comunicação,dispositivos diferentes, restrições de armazenamento e energia, por exemplo). As diversasplataformas de suporte disponíveis atualmente têm a finalidade de facilitar algumas dessastarefas, porém, diversos detalhes específicos a esse tipo de aplicações devem ser tambémconfigurados nelas e, em geral, a forma de configuração varia de acordo com a plataformaescolhida. O FIWARE é uma dessas plataformas disponíveis atualmente. Nele existemdiversos componentes que devem ser configurados e um conjunto de APIs que devem serconhecidas e estudadas, tudo isso deve ser feito antes que o desenvolvimento das seja defato iniciado, resultando em uma enorme perda de tempo, principalmente quando o focoé dado ao desenvolvimento das aplicações e não nos detalhes internos de funcionamentoda plataforma. Assim, o presente trabalho tem como objetivo desenvolver um conjuntode soluções que visam facilitar tanto a configuração dos componentes FIWARE queformam ambiente para a criação dessas aplicações, quanto a utilização das APIs doscomponentes de IoT e gerência de contexto da plataforma. Para isso, então é apresentada aespecificação de uma biblioteca de programação que visa abstrair esses detalhes e facilitara utilização dos serviços disponíveis, bem como a sua implementação realizada utilizando alinguagem Python. Além disso, é apresentada uma aplicação cliente WEB, que possibilitaa realização de chamadas às funcionalidades disponibilizadas pela plataforma FIWAREatravés da interação com uma interface gráfica de usuário (GUI), facilitando ainda maisa sua utilização. Por fim, são apresentados estudos de caso que ajudam a exemplificar autilização das soluções desenvolvidas, bem como a realizar uma validação inicial da suautilidade, realizando também comparações com outras soluções a plataformas atualmentedisponíveis.

Palavras-chave: FIWARE. Internet das Coisas. IoT. Biblioteca de Programação. GUI.

List of Figures

Figure 1 – Overview of FIWARE chapters . . . . . . . . . . . . . . . . . . . . . . 27Figure 2 – IoT, data/context management and security GEs . . . . . . . . . . . . 29Figure 3 – Typical calls on FIWARE IoT components for initial configuration . . . 30Figure 4 – Typical calls on FIWARE IoT components for sending data and commands 30Figure 5 – FIWARE IoT stack overview . . . . . . . . . . . . . . . . . . . . . . . 31Figure 6 – FIWARE IoT basic architecture overview . . . . . . . . . . . . . . . . . 31Figure 7 – Summary of concepts of FIWARE IoT . . . . . . . . . . . . . . . . . . 32Figure 8 – IoT resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 9 – NGSI context entity model . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 10 – Service and Service-Paths . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 11 – Deployed FIWARE architecture . . . . . . . . . . . . . . . . . . . . . . 35Figure 12 – FIoT-Client Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 13 – Architecture of FIoT-Client solution . . . . . . . . . . . . . . . . . . . 37Figure 14 – List of methods from FIoT-Client . . . . . . . . . . . . . . . . . . . . . 39Figure 15 – Typical sequence of calls when using FIoT-Client library for configuration 40Figure 16 – Typical sequence of calls when using FIoT-Client library for sending data 40Figure 17 – FIoT-Client-Python use overview - Import of modules . . . . . . . . . . 42Figure 18 – FIoT-Client-Python use overview - Clients instantiation . . . . . . . . . 42Figure 19 – FIoT-Client-Python use overview - Create service . . . . . . . . . . . . 42Figure 20 – FIoT-Client-Python use overview - Set service . . . . . . . . . . . . . . 42Figure 21 – FIoT-Client-Python use overview - Register device . . . . . . . . . . . 43Figure 22 – FIoT-Client-Python use overview - List devices . . . . . . . . . . . . . 43Figure 23 – FIoT-Client-Python use overview - Initial get entity . . . . . . . . . . . 43Figure 24 – FIoT-Client-Python use overview - Send observation . . . . . . . . . . 44Figure 25 – FIoT-Client-Python use overview - Wait operation . . . . . . . . . . . 44Figure 26 – FIoT-Client-Python use overview - Get entity verification . . . . . . . . 44Figure 27 – Architecture of FIoT-Client-GUI . . . . . . . . . . . . . . . . . . . . . 45Figure 28 – FIoT-Client-GUI - Login screenshot . . . . . . . . . . . . . . . . . . . . 46Figure 29 – FIoT-Client-GUI - Select service screenshot . . . . . . . . . . . . . . . 47Figure 30 – FIoT-Client-GUI - Create service screenshot . . . . . . . . . . . . . . . 47Figure 31 – FIoT-Client-GUI - Context dashboard screenshot . . . . . . . . . . . . 48Figure 32 – FIoT-Client-GUI - Create entity screenshot . . . . . . . . . . . . . . . 48Figure 33 – FIoT-Client-GUI - IoT dashboard screenshot . . . . . . . . . . . . . . . 49Figure 34 – FIoT-Client-GUI - Register device screenshot . . . . . . . . . . . . . . 49Figure 35 – Structure of FIoT-Client-Python example using Arduino . . . . . . . . 51Figure 36 – Device configuration schema on Arduino . . . . . . . . . . . . . . . . . 52

Figure 37 – Arduino example configuration using FIoT-Client-Python . . . . . . . . 53Figure 38 – Structure of FIoT-Client-Python example using Raspberry Pi . . . . . 54Figure 39 – Device configuration schema on Raspberry Pi . . . . . . . . . . . . . . 55Figure 40 – Raspberry Pi example configuration using FIoT-Client-Python . . . . . 55Figure 41 – Raspberry Pi example code . . . . . . . . . . . . . . . . . . . . . . . . 56Figure 42 – Class diagram of FIoT-Client-Python . . . . . . . . . . . . . . . . . . . 65

List of abbreviations and acronyms

API Application Programming Interface

AMQP Advanced Message Queuing Protocol

CoAP Constrained Application Protocol

GE Generic Enabler

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

IoT Internet of Things

MQTT Message Queuing Telemetry Transport

REST Representational State Transfer

WP Work Package

Contents

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.1 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4 Work Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 BACKGROUND AND CONTEXTUALIZATION . . . . . . . . . . . 25

2.1 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2 FIWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.1 FIWARE IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3 Architecture Design and Deployment . . . . . . . . . . . . . . . . . . 35

3 FIOT-CLIENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1 Modeling FIoT-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.1 FIoT-Client Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.2 FIoT-Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 FIoT-Client-Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.1 Sample Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3 Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 FIOT-CLIENT GRAPHICAL INTERFACE . . . . . . . . . . . . . . . 45

5 CASE STUDIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 RELATED WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

APPENDIX 63

APPENDIX A – FIOT-CLIENT-PYTHON SPECIFICATION . . . . 65A.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.2 Library Modules Documentation . . . . . . . . . . . . . . . . . . . . . 67

21

1 Introduction

Nowadays the Internet of Things (IoT) topic is in great ascending (GARTNER, )and it’s more common to see many IoT applications being developed every day. Theseapplications have the most distinct objectives and use di�erent devices, protocols andprogramming languages.

Many factors are involved and must be considered when developing this kind ofapplications (like protocol to be used, storage, programming language etc.), so the supportplatforms becomes essential to ease this development.

The FIWARE platform is actually one of these platforms that can be chosen,presenting features that meet most of the needs for this kind of applications, making alittle easier to deal with the complexity regarding this development.

1.1 Problematic

The motivation to the development of the work initially emerged from a researchproject that proposed a solution to support research activities that need to monitor andtrack solar movement throughout the day, usually to adjust measuring devices that needto be pointed at the sun with great precision in order to obtain accurate measurements,but which are normally performed manually. For this, the project proposed a solution ofautomatic pointing of these instruments to simplify and improve the precision of thesemeasurements.

To this end, a set of sensors (like location and brightness sensors, for example) needto be monitored to control the state of the environment, as well as a set of actuators (likepointing motors and protection tools) that must also be controlled to adjust the behaviorof the device when necessary.

This problem in itself, already involves several aspects to be considered, typical ofIoT applications (as the management of sensors and actuators, communication with otherdevices and control applications and the capacity of self-adaptation, for example). However,the use of a support platform has also become essential to support the development ofthe solution in order to simplify and facilitate many of these concerns inherent in theapplication.

This work is inserted in the context of the Smart Metropolis project 1. It’s a projectdevelop in the Instituto Metrópole Digital, from the Federal University of Rio Grande doNorte (UFRN), that aims to research and develop solutions to the context of smart cities.1 http://smartmetropolis.imd.ufrn.br/

22 Chapter 1. Introduction

In the start of the project activities, the research group have studied the manydi�erent currently available platforms for supporting the development of applications inthe context of smart cities. These studies resulted in a report (MIDDLEWARE, 2016)that compare the available platforms and concludes that the FIWARE platform is actuallythe one that meets most of the needs for this kind of applications.

Thus, this platform was the chosen one to be adopted by the Smart Metropolisproject and to be studied in more depth by the many groups in the project (called WorkPackages, or WPs), each of which studies di�erent parts of the FIWARE platform. Oncethis work is inserted in the context of this project and this platform was adopted by it,this in this work we also decided to adopt it and study it in more depth.

In this study, it was possible to see that, although the FIWARE platform bringsmany facilities for developers and users of applications, it is necessary some time tobecome familiar with the large number of APIs provided by the di�erent componentsthat the platform presents. This happens because there are many settings and parametersconfiguration to do, that must be known before starting developing from IoT with FIWARE.

Moreover, the use of interfaces that the platform provides by applications is nottrivial. One must make calls to provided REST APIs inside the code, being necessary toset many parameters that configure the request.

These concerns are not suitable, since the study of details from these componentsintroduces a great overhead. Furthermore, ideally, the developer should be focused onlyon specific details of the developed application, and not studying platform details.

1.2 Objectives

This work aims to create a solution to ease the use of FIWARE platform and thedevelopment of IoT applications based on its components. More specifically, we propose aprogramming library for simplifying the use of FIWARE IoT components by abstractingaway details of the REST protocol and request configurations.

Additionally, we also aim to present an auxiliary tool for manipulating IoT deviceswithin the FIWARE platform in the form of a WEB-based graphical user interface. Thishelps people abstracting the how things occurs internally in the platform. For example,for people that are just concerned in projecting hardware and implementing code to thedevice, it will not be required to deal with WEB-based programming or data storageaspects, making easier just to focus on the problem that they aim to solve.

In order to evaluate our proposal, we have developed some case studies, throughsample applications, that demonstrates how to use the proposed solution.

1.3. Methodology 23

1.3 Methodology

To develop this work, initially the FIWARE platform and its components werestudied, to understand their behavior and also their communication occurs. With thisstudy, it was possible to set up an environment, composed by the necessary componentsthat are typically used in the development of IoT applications. After that, it was alsopossible to create sample applications using default APIs from FIWARE and identify themain di�culties when developing them with the platform.

After identifying the improvement points, the programming library was thendeveloped, followed by the implementation of the WEB graphical user interface to furthersimplify the creation of such applications.

Then, some applications were developed using the created solution, making itpossible to evaluate it and to compare with existing tools and platforms, to measure itsutility and application on real IoT problems.

1.4 Work Organization

First the necessary background and contextualization to the development of thework will be presented, as also a overview about FIWARE platform and the requiredcomponents to create an environment needed to develop IoT applications using the platform.Then it’s presented the programming library created, followed by the presentation of thegraphical user interface that also supports the development of this kind of applications.

After that, some case studies that applies the developed tool and exemplifies itsusage are presented, showing some usages of the solution on example problems thatsimulates the concerns usually present on a real IoT applications. In sequence the proposedsolution utility and also its application on the case studies are evaluated, followed by acomparison with existing similar solutions and related works.

25

2 Background and Contextualization

This chapter presents the concepts related to the main topics that have beenapplied in this work, such as Internet of Things and also an overview and some conceptsof the FIWARE platform.

2.1 Internet of Things

Internet of Things (IoT) is characterized as a network of distributed physicaldevices uniquely identifiable and addressable through the internet, and usually equippedwith ubiquitous intelligence (ATZORI; IERA; MORABITO, 2010). They are composedof a set of sensors and actuators that allow to collect information from the environmentwhere they are inserted and also act on it. Since they communicates with other devicesand applications through the network and can be uniquely identifiable, these devices canalso be configured and controlled remotely by other applications. These devices often havelimited processing power, data transfer and energy storage, characteristics that, alongwith a possibility of interaction with the context they are inserted in, require a di�erentapproach when compared to conventional software systems.

In order to emphasize the importance of the topic, and to show how currentdiscussions related to the theme are, can be cited global actions that are being taken inorder to better define and create patterns (like a reference architecture) for the Internet ofThings context (ITU-T, ). In addition, e�orts are being taken by the Brazilian governmentwith the purpose of defining a National Strategic Plan to guide the development andapplication of IoT in the country (Plano Nacional de Internet das Coisas).

Machine-to-Machine (M2M) communication technologies are essential for IoTapplications. Since devices are distributed, di�erent protocols, that define e�cient waysto accomplish this communication, are necessary. These protocols, besides providinginformation exchange, also take into account the physical limitations common to thesedevices.

Some protocols have been defined and make it possible to perform this communi-cation in some ways, like synchronous, asynchronous and publish-subscriber ways. Somefamous examples of protocols also used for this purpose are UL-HTTP, AMQP, MQTTand CoAP (AL-FUQAHA et al., 2015).

Support platforms aim to facilitate the development for IoT, centralizing elementsand activities common to di�erent applications. Thus, developers and users are able tochoose between one of the many platforms currently available, defining which one fits his

26 Chapter 2. Background and Contextualization

and his applications needs.

FIWARE platform is one of the many available platforms. Among the characteristicspresented by the platform, some that can be cited to justify adopting this platform whendeveloping IoT applications are: the ease of implementation of these applications using it;the fact of being composed of open-source projects; the adoption of open API standards;the facility to create a custom environment composed only by the necessary components;and the scalability its components provide.

In addition, some works has also facilitated the choice between these many availableplatforms (MIDDLEWARE, 2016), defining desirable attributes to observe in a platform, insuch a way that it can be considered good for IoT applications. This attributes can also beused to comparing platforms. The referred work also performed an analysis about existingplatforms in which the FIWARE platform stood out, presenting, in that moment, also thebest results regarding the evaluated requirements to the Internet of Things applicationsdesign.

2.2 FIWARE

The FIWARE platform is a middleware projected for developing and provisioningapplications related to the Future Internet. Some of the facilities that the platform bringsare the analysis of large volumes of data and provision of real-time metrics, manipulationof context information, real-time event analysis, information gathering from sensors andaction on actuators, and access control. It also features a set of generic standardized APIsthat, among these other cited facilities, make it easier to communicate with the Internetof Things (IoT) and manipulate context information.

These sets of functionalities that the platform provides are grouped in the form oftechnical chapters. Each of the available chapters has a focus, being related to areas relatedto data/context management, cloud hosting, IoT, security, for example. They consist in aset of Generic Enablers (GEs), nomenclature given to components within the platform,that are related to the chapter they belong to. In Figure 1 its possible to see an overviewof FIWARE chapters and the componentes that each of them presents.

The available technical chapters are: Data/Context Management (context informa-tion manipulation at large scale); Internet of Things (IoT) Services Enablement (man-agement of things, making them available, searchable, accessible, and usable); AdvancedWeb-based User Interface (3D & Augmented Reality - AR capabilities for web-based UI);Security (delivery of services that meet security and privacy requirements); Interface toNetworks and Devices (I2ND) (networking and robotic devices related aspects); Applica-tions/Services Ecosystem and Delivery Framework (creation, consumption, and distributionof applications/services, that addresses all business aspects); and Cloud Hosting (provision

2.2. FIWARE 27

Figure 1 – Overview of FIWARE chapters

of computation, storage and network resources to manage services).

The platform presents an environment based on the OpenStack1 cloud computingplatform, with some modifications, as well as the addition of other components. Theseimported components have the most di�erent objectives (like security, objects storingand dashboard, for example) and were used to take advantage of the already imple-mented features in OpenStack components, serving as a base to develop additional specificfunctionalities.

These components can be selected and combined to deploy an concrete architecture,that presents FIWARE services required for a specific application to run. These concretearchitectures are usually based in the reference architectures that are provided in eachchapter. These architectures show how to combine necessary GEs from one or more chaptersto create a specific scenario, that can instantiated using implementations provided for eachcomponent of the platform. This deploy can be made in an owned infrastructure, that canbe used for tests or to production. However, it’s also possible to use the FIWARE Lab 2

that is a working instance of FIWARE available for experimentation, and is composed bythe main required components of the platform.

The platform is essentially used by applications developers, from areas like IoT,data analysis and Augmented Reality (AR). These users take advantage of the set of

1 https://www.openstack.org/2 https://account.lab.fiware.org/


generic APIs that are common to di�erent applications and are useful for acceleratingtheir development. There are also components less specific that can be used by general,non-technical users. But in the most part, this kind of users take advantages more throughthe applications that are developed that consumes FIWARE services.

2.2.1 FIWARE IoTRegarding IoT applications, the platform provides GEs that allow "things" to become

available, searchable, accessible and usable context resources, enabling the interactionof FIWARE applications with real-world objects. These "things" represent any physicalobject, living organism, person or concept of interest from the perspective of an application,and its parameters are totally or partially attached to sensors, actuators or a combinationof them.

Besides using IoT GEs, this kind of applications also can make use of componentsfrom other chapters, like data/context management and security chapters. In the Figure 2the available components from this chapters are shown.

Using this components that the platform provides helps in abstracting the com-plexity and high fragmentation of IoT technologies and deployment scenarios. This workwill be focused in the components of these chapters, specially the ones from data/contextmanagement and IoT chapters, necessary to implement the main required functionalitiesfor IoT applications.

A typical sequence of actions done when using FIWARE IoT components directlyis shown on Figure 3 and Figure 4. The calls to its components is done using REST HTTPcalls (FIELDING, 2000) to services provided by each component, that must be configuredwith parameters specific to each application on every new call.

Initially, the user of FIWARE APIs optionally does a sequence of steps, usuallyin the first time that configures an environment to a new application (Figure 3). Thesesteps first include creating a new service (context in which requests to APIs will be made)and selecting the recently created service, or a previously existing one. Once a serviceis selected, a device can be registered within its context and, optionally, it’s possiblesubscribing to specific attributes value changes of the registered device, and also enablesending of entity data to desired data storages.

After that, typical IoT applications then tend to pass most of their time in a loopcomposed by the sending of obtained measurements to the platform and also receiving andexecuting commands sent from a external client application that interacts with platformsAPIs (Figure 4).

The components from these main chapters for IoT applications (IoT, data/contextmanagement and security chapters), that were presented above and which services are

2.2. FIWARE 29

Figure 2 – IoT, data/context management and security GEs

consumed by these calls, are organized and communicates as presented in the Figure5, taken from the FIWARE IoT o�cial documentation3. It shows an overview of somecomponents that composes the stack for IoT in the platform, and shows how is therelationship between the GEs of these three chapters.

The lower layer is related to the IoT chapter and is closer to device aspects. Itsmain function is to translate device specific protocols to the default protocol of theplatform used in upper layers. The middle layer belongs to the data/context managementchapter and is responsible for storing context information from devices attributes. Thesuperior layer is also composed by components that are part of this chapter. They presentfunctionalities that act over the context information stored in the middle layer. Amongtheir functionalities are: management of historic data (ST Historic); analysis over datachange events (CEP); and the storage of context information in external configured storagesystems (Connector Framework). Transversal to all these layers, located in the right side

3 https://fiware-iot-stack.readthedocs.io/en/latest/walkthrough/index.html


Figure 3 – Typical calls on FIWARE IoT components for initial configuration

Figure 4 – Typical calls on FIWARE IoT components for sending data and commands

of the diagram, are the security components, that are responsible for the providing aauthentication and authorization system, managing users, roles, permissions to use servicesprovided by components from other layers.

The Figure 6, obtained from the o�cial architecture documentation of the IoTchapter, shows a more detailed view of the architecture of IoT components. Some mainaspects that can be observed in this figure is the separation of IoT components betweenIoT Backend and IoT Edge layers, and how occurs the communication between IoT anddata context components (specifically the Data ContextBroker component).

The first existing level where IoT components are located is in the IoT Backendlayer. It’s related to elements (functions, logical resources and services) that are located

2.2. FIWARE 31

Figure 5 – FIWARE IoT stack overview

Figure 6 – FIWARE IoT basic architecture overview

and hosted in a cloud datacenter. So, this level regards the "logical IoT environment". It’sthe upper layer of the IoT architecture, so, it’s directly linked to the Data ContextBroker.This component (whose utility is better detailed in following sections and chapters) is partof the data/context management chapter and, responsible to store context information,is also crucial to IoT data management. Users and developers access this component tointeract with context and IoT elements, through its provided interface.

The other existing level is the IoT Edge layer. It’s related to elements that compose


the on-field IoT infrastructure, that is closer to devices, and is required to connect developedapplications to devices. Some of the elements it incorporates are devices, gateways andnetwork. It also presents APIs that make it easier to allow the execution of necessaryconfigurations in a lower level and also the integration of new types of devices and gateways.This level is connected to the IoT Backend level, that is also responsible for abstractingspecific low-level details (like device communication protocols) that this layer must dealwith to users of the platform services.

2.2.1.1 Basic Concepts

Understanding some concepts is critical to using the FIWARE APIs and, conse-quently, tools that make use of them. So, some concepts obtained of the o�cial (FIWARE,), that facilitate the understanding of what will be presented during this work, will bedefined below. The Figure 7 summarizes the presented concepts.

Figure 7 – Summary of concepts of FIWARE IoT

Device: Also known as the IoT end-node, it refers to a hardware entity, componentor system. It is responsible for measuring or influencing the properties of a thing/group ofthings (or both, concurrently). Sensors and actuators are examples of devices.

IoT End-Node: The term is used in documentation for complex physical deviceswith multiple sensors and actuators, such as a complex Arduino-based system. Devicesmay use proprietary or standardized communication protocols, which can be natively sentto Backend GEs or translated into another standardized or proprietary protocol in IoT

2.2. FIWARE 33

Gateways, such as the conversion of these specific protocols to OMA Next GenerationServices Interface (NGSI) specification (OMA, 2012) that can be performed in FIWAREGEs, for instance. An Arduino or Raspberry Pi are examples of IoT End-Nodes.

IoT Resource: An IoT Resource (Figure 8) refers to a computational elementthat provides access to sensor/actuator devices. An information model for describing IoTfeatures can include context information, such as location, accuracy and status information,for example. Data at IoT resources consist not only of the measured data, but also ofcontext information, such as data type, time instant, measurement accuracy and thesensor from which measurement was performed. IoT resources can be addressed using auniform addressing scheme and are usually hosted on the device but also have a logicalrepresentation on the IoT Backend level.

Figure 8 – IoT resource

Thing: It concerns any object, person, or place in the real world. They arerepresented as virtual things and, in their representation, they have an entity ID, a typeand several attributes. Sensors can be modeled as virtual things, but things in the realworld, whether concrete or abstract (such as rooms, people and groups), can also bemodeled as virtual things. Data at the level of things consist of descriptions of things andtheir attributes, and may also include information on how the data were obtained throughmeta data.

NGSI Context-Entity: IoT End-Nodes, IoT Resources and "Things" are rep-resented as NGSI Context Entities in the GE Context Broker of the data chapter, sodevelopers need to learn only the same API from that GE, used for context information,to also manage application information IoT. Sensor measurement information can beobtained by reading the attributes of these entities, while actuating commands in actuatorscan be done by updating specific attributes that represent commands in them. The model


is shown on Figure 9.

Figure 9 – NGSI context entity model

Service and Service-Path: They are used to define the scope used to executerequests, so that the desired operations can performed on devices and entities with certainunique IDs within a specific context. For this it’s necessary to set with the ID of thedevice also the Service and Service-Path values, when registering a device or sendingmeasurements from them, for instance. The Figure 10 shows a structure composed ofServices, Service-Paths and their respective devices, where the device with ID LDR001from service UFRNService and service-path /dimap can be accessed only when this contextis currently defined. If a di�erent context is set (with service IFRNService and service-path/library, for instance), this ID would point to a completely di�erent device since there is aregistered device using also this ID in this di�erent context.

Figure 10 – Service and Service-Paths

2.3. Architecture Design and Deployment 35

2.3 Architecture Design and Deployment

This section exposes an architecture that shows how IoT and data/context man-agement concepts presented above, and the components that will be described in sequence,are being used to create a concrete architecture to support the development of the solution.

Each FIWARE GE has a specific and well defined purpose and some of them thatare part of IoT and data context chapters were selected to create the architecture shownon Figure 11.

Figure 11 – Deployed FIWARE architecture

There are some GEs in this architecture and also some components that are notpart of FIWARE components but that act as support for them. The description of thefunction of each component in this architecture is shown bellow:

Context Broker (Orion): The Context Broker is a GE from the data chapterthat is responsible for the management of NGSI Context Entities. On the proposedarchitecture, it’s located in the upper layer and provides a set of APIs through whichapplications can communicate with the FIWARE IoT stack, supporting the control overthese entities and the respective IoT devices they represent. Its implementation is namedOrion.

IoT Agents (IoTA): This component is located in the lower level of the proposedarchitecture and communicates directly to IoT devices. It handles specific IoT protocols(like MQTT, CoAP and UL-HTTP) and is responsible to translate them into the NGSIprotocol (the default protocol used on links between components of the architecture), that


will be used on communication with the Context Broker to query and update entities thatrepresent the devices. This component can be implemented according to specific deviceprotocols used and has standard implementations that use Ultralight 2.0 and JSON, bothsupporting HTTP and MQTT protocols.

Connector Framework (Cygnus): This GE is also linked to Context Brokerand acts as a connector between it and desired storage sources. It subscribes on the broker(named source by the component) and when changes occur on entities states, the changeevents are sent to the configured storages (named sinks). On the proposed architecture,the MySQL, MongoDB and Elastic Search (ELK Stack) were used as storages associatedto the connector, aiming to create and environment that supports access to a relationaland a non-relational database, and also with a powerful search engine to optimize querieson data from entities. The implementation of this component is called Cygnus.

Short Term Historic (Comet): This component provides a point of storage forraw and aggregated historic data from entities. It can be registered as a subscriber of theContext Broker data changes, but in the proposed architecture a di�erent approach wasused, setting it up also as an sink linked to the Connector. Its implementation is namedComet.

To deploy this proposed architecture the platform Docker 4 was used, with its tooldocker-compose. With this tool, it was created a docker-compose.yml file that describeshow the implementations of these components communicate with each other and setsnecessary parameters to run this environment, used in the development of the library.

Since, at the moment of the development of the work, no similar file that configuresthe necessary environment to use FIWARE services that works correctly was found, thisconfiguration also represents a contribution to people that want to explore APIs fromthe platform, or even use the solution proposed in this work, running a local instance ofFIWARE components. This file and instructions on how to deploy this environment areavailable on tutorial repository 5.

4 https://www.docker.com/5 https://github.com/FIoT-Client/fiot-client-tutorial

37

3 FIoT-Client

The FIoT-Client is a project of libraries to simplify the development of applicationsthat consumes APIs from FIWARE IoT and Context components. As shown in the Figure12, these libraries act as connectors between the client applications in the selected languageand FIWARE APIs, making the development easier and faster, since the programmingstyle to consume its services will be the same used in typical applications developed in thelanguage.

Figure 12 – FIoT-Client Overview

Besides being a library to client applications that consume FIWARE IoT andcontext services, the presented solution was also planned to ease the development of devicecode and the use of functionalities that the platform provides by general users, as shownon Figure 13.

Figure 13 – Architecture of FIoT-Client solution

38 Chapter 3. FIoT-Client

There, it is possible to see that one existing option to users of the solution is tointeract directly with client applications created by him, that imports FIoT-Client librariesto communicate with components from FIWARE platform. In the second option, users fromthese applications can use the FIoT-Client-GUI WEB application (presented in details inthe next chapter), that contains a backend that also imports a library implementation,to communicate with the platform. In this architecture, devices can also talk directly tothe platform, using default libraries of the device to use its supported protocols. However,they can also import the library to communicate with the platform easily, using simplecalls to provided methods.

3.1 Modeling FIoT-Client

Having this overview about the role of the FIoT-Client in the development of IoTapplications, in this sections it’s shown the results of the specification of the library. Firstit’s shown how its structure is presented, showing the components that it presents and anoverview of the methods that the specification presents. After that, the behavior plannedto the library is presented, showing briefly how its methods can be used to achieve typicalfunctions of IoT and Context applications that uses the FIWARE platform.

3.1.1 FIoT-Client StructureSome functionalities presented by the library are the service creation, device

registering, measurements and commands sending, entity and devices querying, andsubscription to attribute changes.

In the library, these actions were grouped by their function, verifying if each ofthem is more directly related to IoT or context management, resulting in two di�erentcomponents that group these functions in the proposed library.

An overview of the complete list of methods currently present in the libraryspecification and where each of them are located is shown on Figure 14. More details aboutthe objective of each method, along with its parameters and their expected formats canbe found in the Appendix A and also in the repository of the reference implementation(link given in later section).

The first component is composed by functions more related to context management,like entity creation and subscription to data changes, for example. It’s named FiwareCon-textClient. Some of the groups of functions that are present in this component are relatedto the management of entities and subscriptions, historical data and persistence of data ofthese registered entities.

Meanwhile, the second component groups actions directly liked to IoT management,

3.1. Modeling FIoT-Client 39

Figure 14 – List of methods from FIoT-Client

like administration of devices and its measurements, for example. It receives the nameof FiwareIotClient. This component, in turn, presents groups related to the managementof devices and also the sending of measurements from devices to the platform and thesending of commands from applications to registered devices.

Some groups of functions are also present in both components, like the one relatedto the authentication of the users to access the services provided by the platform and tothe management of services, for example.

3.1.2 FIoT-Client Behavior

The typical sequence of actions done when using FIWARE IoT components directlyguided the development of the library methods. With the previously presented methods,that compose the library specification, it’s possible to accomplish all these necessary stepstypically used on IoT applications development (presented on Figure 3 and Figure 4).

To this end, it’s just necessary to call the provided methods, not being necessary tounderstand all the underlying concepts and configurations, usually necessary to use APIsthat composes the background of IoT and context components of FIWARE platform.

The Figure 15 and Figure 16 present sequence diagrams (similar to the onespresented on Figures 3 and 4) that show how the calls to the library encapsulate andabstract calls to these services, acting as an intermediator between applications and theplatform.

It’s also visible that not only applications on client side can make these callsthrough the library, but also devices can use it to send its readings to specific platformcomponents, for example.


Figure 15 – Typical sequence of calls when using FIoT-Client library for configuration

Figure 16 – Typical sequence of calls when using FIoT-Client library for sending data

3.2 FIoT-Client-Python

The FIoT-Client-Python1 is an implementation of the library project in Pythonlanguage2. This language was chosen since its a multipurpose high level language that

1 https://github.com/FIoT-Client/fiot-client-python2 https://www.python.org

3.2. FIoT-Client-Python 41

can be easily used by high level applications written on language but also by many IoTdevices (like Raspberry Pi3, BeagleBone4 etc.).

In this implementation, each group of functions present in the specification of thelibrary was implemented as a specific class that represents each of these components andhas the same name as in the specification. The structure and the list of methods currentlyimplemented by the library is shown in the class diagram present in the Figure 42 onAppendix A.

There, it’s possible to see in the class diagram that there are two main classesFiwareContextClient and FiwareIotClient (representing context and IoT components,respectively) and a generic class named SimpleClient that has methods common to bothcomponents and that are inherited by each class.

Given the methods provided by these classes of the library implementation, it’spossible to use these calls in Python language to abstract details from FIWARE APIsand quickly start developing IoT and context applications using its services. A simpledemonstration of how the methods provided by this FIoT-Client library implementationcan be used to accomplish some of the typical IoT application tasks are presented in thefollowing section.

3.2.1 Sample UsageIn this subsection it’s shown a simple example that demonstrates the usage of this

sequence of basic steps provided by the implementation. It aims to give a notion about theway that these methods can be used to help the implementation of applications written inPython language that imports the library.

For this, it’s shown a sequence of steps necessary to consume and produce informa-tion data from a device, from the service creation to the measurements sending, using anexample that uses a device composed by a simple Light Dependent Resistor (LDR) sensor.These steps were executed using the tool Jupyter Notebook5, that provides an interactiveterminal in which desired instructions and experimentations can be executed in an easierway. The executed commands and its outputs is shown from Figure 17 to Figure 26.

Initially it’s necessary to import the two modules (IoT and context modules) fromthe programming library (Figure 17), since both IoT and data/context managementfunctionality will be required for the example, for interacting with devices and its entityrepresentations on Data ContextBroker, respectively.

In sequence, it’s also created a client instance for interacting with the services

3 https://www.raspberrypi.org4 https://www.beagleboard.org/bone5 http://jupyter.org/


Figure 17 – FIoT-Client-Python use overview - Import of modules

provided by each module, passing to the constructor the path to the configuration file thatspecifies the endpoints of required FIWARE components (Figure 18). For more details, anexample of this file can be found on tutorial repository.

Figure 18 – FIoT-Client-Python use overview - Clients instantiation

After that, the first call to a FIWARE service is made through the IoT Clientinstance, to create a new service, named "ExampleService" and with the service path"/example" (Figure 19). As the API key for the service was not specified in the parameterslist, a random value will be assigned to the API key and returned in the result of the call.

Figure 19 – FIoT-Client-Python use overview - Create service

Then, it’s necessary to set both clients to use the context of the newly createdservice, and the generated API key, so that following requests will be interpreted in thiscontext (Figure 20).

Figure 20 – FIoT-Client-Python use overview - Set service

Having selected the service, it’s then registered a new device within its context,using the schema file in path defined in the first parameter and the device name "EX-AMPLE_LDR". Since when registering a device, it’s representation in the context brokerwith a new entity is also done, it’s also necessary to define the ID of the entity that willbe created and associated to the device, like the ID "LDR001" defined in this command(Figure 21). The output of this command shows if it was successful or not according tothe returned result code.

3.2. FIoT-Client-Python 43

Figure 21 – FIoT-Client-Python use overview - Register device

To confirm if the device was correctly registered, it’s then executed the commandto list all registered devices in the selected service and in the command output, it’s possibleto see the informations of the newly registered device (Figure 22).

Figure 22 – FIoT-Client-Python use overview - List devices

Posteriorly, the ID specified in the device registration is used in context clientinstance to query the entity information, to confirm that it was correctly created (Figure23). However, since no measurement was sent yet, the output of the command shows theattributes of the entity with no assigned value.

Figure 23 – FIoT-Client-Python use overview - Initial get entity

In the following command, a measurement in then sent to the platform, simulatingthe sending of a value read from a device. It’s necessary to specify the ID of the device thatis sending the reading ("EXAMPLE_LDR" in this case) and the measurement itself (Figure24). If no value is explicitly provided to the protocol parameter, the default transportprotocol (MQTT) is then used. The output of the command shows either the commandexecution was successful or not.


Figure 24 – FIoT-Client-Python use overview - Send observation

After that, just to ensures that the reading value sent from the device was alreadyupdated in the corresponding entity, a time of two seconds is waited (Figure 25).

Figure 25 – FIoT-Client-Python use overview - Wait operation

Lastly, the command to query the entity information is then repeated (Figure26), but this time the output shows in the entity information the record of measurementrecently sent.

Figure 26 – FIoT-Client-Python use overview - Get entity verification

3.3 Final Remarks

In this chapter it was presented an overview about the proposed solutions usage, andalso the specification of the FIoT-Client programming library, showing how it’s structured(what methods composes the specification and their organization) and also how is itstypical behavior (which sequence of steps are usually necessary to accomplish IoT tasksby applications).

In sequence, it was also presented the FIoT-Client-Python, a implementation ofthe specification in the Python programming language. It is shown the implementationstructure (with its class diagram) and how the necessary steps can be executed throughthe available concrete methods of the library (with its sequence diagram). It’s also showna example of the usage of the implementation in the Python language, with a sequence ofcalls of methods provided by the implementation.

45

4 FIoT-Client Graphical Interface

The FIoT-Client-GUI1 is an client application, implemented using Angular andDjango, that acts as a graphical user interface to access FIWARE IoT and context APIsthat were encapsulated by the FIoT-Client-Python implementation.

The FIWARE platform doesn’t provide components for doing tasks common inapplications that control devices or context information through a graphical interface.This is a factor usually present in other platforms, to ease management tasks through anon-programming approach, and to keep up with data changes on a more graphical way.This project aims to provide this graphical interface to facilitate the use of IoT and contextfunctionalities from the platform. This is useful because many users are not developers,and, to accomplish their desired results, doesn’t have the technical knowledge necessary tocreate applications that consumes these services through the created programming library.

With the usage of this application, its possible to execute typical tasks providedby the platform services through the graphical interfaces. This way, IoT functionalities onthe FIWARE platform can be executed similar to what occurs in other platforms. Amongthe functionalities provided also by the graphical interface are the management of entitiesand devices, sending of commands to devices and simulating the submission of commandsfrom registered devices though the interface.

Figure 27 – Architecture of FIoT-Client-GUI

The architecture of the created solution is shown on Figure 27. There it’s possibleto observe that the user of the application that wants to consume provided FIWAREIoT and context services can interact directly with the WEB application GUI provided,selecting desired actions and setting parameters necessary to their execution. This graphicalinterface, implemented in Angular, communicates with a Django backend through HTTP1 https://github.com/FIoT-Client/fiot-client-gui

46 Chapter 4. FIoT-Client Graphical Interface

requests that follows the REST architectural pattern (FIELDING, 2000) and containsnecessary data to actions execution. This backend acts as a client to FIWARE APIs anduses the FIoT-Client-Python programming library to communicate with these APIs andexecute the desired actions.

Similar to the FIoT-Client-Python library, the pages to execute the provided actionsare also divided in IoT and context sections, where the user of the application can findactions grouped by each of these contexts.

The first screen shown to a user of the application is the Login screen (Figure28), that receives the user credentials and allows his access to the system if the insertedvalues are associated to an account registered in the security components of the FIWAREplatform.

Figure 28 – FIoT-Client-GUI - Login screenshot

Once the user is logged in, he must select the context (service) in which he willexecute desired operations in the system, using the service selection screen (Figure 29),that lists services that the current user has permissions to access.

If it’s desired to create a new service, it’s also possible to achieve this task usingthe service creation screen (Figure 30), that creates a new service based on providedparameters and select it.

After selecting a service, the user can already use IoT and context actions thathe has permission to. Actions related to the context management are exhibited in thecontext dashboard screen (Figure 31). There he can execute actions like listing, detailing,updating and deleting registered entities, and also create a new entity.

47

Figure 29 – FIoT-Client-GUI - Select service screenshot

Figure 30 – FIoT-Client-GUI - Create service screenshot

When the user selects to create a new entity, a dialog is shown, where he can insertparameters necessary to create a new entity in the platform (Figure 32).

In a similar way, after have selected a service, he can also execute IoT actions,like listing, detailing, updating and deleting registered devices and also create register anew device in the IoT dashboard screen (Figure 33). In this screen he can also sendingcommands to a device or send to the platform a measurement to specific attributes of adevice.

48 Chapter 4. FIoT-Client Graphical Interface

Figure 31 – FIoT-Client-GUI - Context dashboard screenshot

Figure 32 – FIoT-Client-GUI - Create entity screenshot

After selecting to register a new device, a dialog where he can insert parametersnecessary to this registration is also shown (Figure 34).

With these screens, all the basic actions provided by the FIWARE platform andby the library can be executed also with the usage of the proposed WEB application.

49

Figure 33 – FIoT-Client-GUI - IoT dashboard screenshot

Figure 34 – FIoT-Client-GUI - Register device screenshot

51

5 Case Studies

To validate the usage of the library in a real example, sample applications weredeveloped using an Arduino1 and also with a Raspberry Pi2, composed by some di�erentcomponents, so that they can help to verify whether with the usage of the library the twomain functions of IoT applications are possible and eased: sensors reading and triggeringactuators.

The developed applications also aimed to simulate typical features from IoT systemsin the context of smart houses, monitoring the environment and acting on it when necessary,to make it more comfortable or generate some alerts, with the usage of its sets of sensorsand actuators.

5.1 Arduino

The first sample application created used an Arduino. This example was composedby a temperature and humidity sensor (DHT) and a LED. Its structure can be verified onFigure 35.

Figure 35 – Structure of FIoT-Client-Python example using Arduino

This example aims to show that, in an environment created and configured withthe usage of the library on client side, devices that doesn’t use the library to consumeFIWARE services can communicate with the platform normally.

The first necessary step was to define a schema describing the device and its sensors(humidity and temperature attributes) and actuators (led attributes), used when registering1 https://www.arduino.cc2 https://www.raspberrypi.org

52 Chapter 5. Case Studies

a new device in the platform. Besides defining the sensors actuators IDs and types, thisschema also specifies the used protocol and other necessary settings. Since in the deviceregistration it’s also created an entity representation on data context component, so thatit’s possible to start sending measurements to the platform and commands to the device,the ID of this entity is also present on schema file. There are also some placeholders in thefile, like "[DEVICE_ID]" and "[ENTITY_ID]". It’s a convention adopted for defining thedevice schema, so that it’s possible to create a generic device representation schema fordevices with di�erent IDs, and the library takes charge of replacing them with suitablevalues passed as arguments to the device registration method. This schema can be seen onFigure 36.

Figure 36 – Device configuration schema on Arduino

After creating the schema, it was possible to run the necessary commands forenabling the communication between the device and the platform. The necessary stepswere executed in a Python interpreter session on console. After importing the IoT modulefrom the library (once the necessary steps are related to devices management), it was

5.2. Raspberry Pi 53

necessary to run commands to create the service, select the created service an register thedevice with the defined schema (as shown on FIoT-Client-Python use overview). Lastly,it was registered a listener to attributes value change of the entity associated with thedevice, persisting its data on configured databases with the Cygnus, step that is optionalfor each application. The commands associated with these actions are shown on Figure 37.

Figure 37 – Arduino example configuration using FIoT-Client-Python

After configuring the device on the platform with the previous commands, it waspossible to implement the code of the Arduino, using, when necessary, the same parametersused in the device registration. Since this device is not able to run the Python language(used in the implemented library), the device communicates directly with the FIWAREplatform to send measurements and receive commands, without the usage of the FIoT-Client library on this device. As the device was registered to use the MQTT3 protocol,the code of this device uses MQTT default libraries to communicate with the platformcomponents. Once this device code doesn’t include direct calls to the implemented library,it’s omitted here, but can be found in examples page of the tutorial repository.

In this example, it’s visible that a possible future work, to facilitate the developmentof code also for the device, is to create an implementation in Arduino language of theFIoT-Client library specification.

5.2 Raspberry Pi

The second developed example used a Raspberry Pi. This application was composedby a presence sensor (PIR) and a Fan and its structure can be verified on Figure 38.

In this example, it was also necessary to define a device schema that specifies theset of sensors (presence sensor) and actuators (fan) connected to the device, listing theattributes associated with each of them. The created schema has the same componentspresented in the last example and is shown on Figure 39.

The configuration steps were the same presented in the FIoT-Client-Python useoverview and in the Arduino application example. However, the arguments passed to each3 http://mqtt.org/


Figure 38 – Structure of FIoT-Client-Python example using Raspberry Pi

method were set to use the IDs and schema files associated to this example. The sequenceof steps also executed in a Python interpreter session on console for this example can beseen in Figure 40.

In addition to the usage of the FIoT-Client-Python to configure the platform tocommunicate with the device, since the Raspberry Pi is able to run code written in thePython language, the programming library can also be used in the device side code. Thus,the communication between the device and the platform can also occurs through the usageof the provided library.

On device side, it is possible to use the library to send measurements from PIRsensor to FIWARE APIs and also receive commands (to turn the Fan on or o�) sent fromclients, sending a response to them. The Figure 41 shows the main loop of the device code,that uses an instance of the FiwareIotClient to send to the platform the last value readfrom the presence sensor.

Detailed usage of these calls and full code of this example application can also beverified on tutorial repository of the library.

Considering the application of solar tracking that motivated the development ofthe work initially, as this also uses a Raspberry Pi device and consumes the same setof functionalities presented in the example application above, the implementation ofthe communication of this application with the FIWARE platform can also be greatlysimplified with the use of the developed solution. Currently the application of the solutionin this application is currently being carried out in the research project.

5.3. Discussion 55

Figure 39 – Device configuration schema on Raspberry Pi

Figure 40 – Raspberry Pi example configuration using FIoT-Client-Python

5.3 Discussion

Even if a formal evaluation has not yet been carried out, when comparing in anAd-hoc way the usage of the proposed solution with the traditional approach for consumingFIWARE APIs, it’s possible to see that many request configuration details were abstractedto the final user, resulting in a great saving of time to start developing using the platform.


Figure 41 – Raspberry Pi example code

Also, with the proposed solution to quickly run the IoT environment componentsusing the provided docker-compose files, more time is saved for new users of FIWAREservices, specially the ones that are only interested in consuming this services, and not inthe internal configurations and communications between components. Some testimonies ofnew users of platform services demonstrated the ease of using the available configurationfiles compared to manual configuration approach.

These functionalities, when easing the use of the FIWARE services and the con-figuration of the environment, make the platform even more attractive for new usersthat are choosing a support platform to use, since they insert features (like the supportprogramming library and the WEB control interface) that are not present in the defaultcomponents of the platform but that are present in other platforms.

Currently the work is being evaluated and improved with suggestions of users anddevelopers that are accessing the repositories of the solution and using the solution tocreate his applications.

Some institutions contacted us and are also currently using the solution to supporttheir projects. They are the Instituto Federal de Educação, Ciência e Tecnologia do RioGrande do Norte (IFRN); the Instituto Federal de Educação, Ciência e Tecnologia deGoiás (IFG); and the Instituto Nacional de Telecomunicações (Inatel).

Until now the feedbacks received were very good, showing that the tool really canbe very useful on the development of this kind of applications.

A short paper describing the solution was also submitted to the event X EscolaPotiguar de Computação e suas Aplicações (EPOCA), this year (2017), held by theSociedade Brasileira de Computação (SBC). In the occasion the work was awarded as thebest paper in the track of short papers of the event, also showing the relevance of thesolution to the context of development of applications to the Internet of Things (maintheme of the event in this year).

57

6 Related Work

Some existing projects and platforms motivated and guided some aspects of thedesign of the solutions proposed by the current work. Other tools were also searched andbriefly studied so that it was possible to do a basic comparison with the developed solution.

Some existing tools can be used to make the binding from code to REST APIs orcreate these APIs with connectivity with clients since its creation, approach that couldalso be used to reach some of the results that the implemented library provides. However,this approach was not used in the current work because these tools usually doesn’t providesupport to the specificities of the authentication flow needed by FIWARE components andalso the usage of the NGSI protocol, used by most public components from the platform.These tools usually also require some configurations within the REST service to be binded,and, since the FIWARE components implementations should meet their specificationsexactly, these modifications internal to components would not be possible.

The solutions implemented by this work resembles functionalities present in theOpenStack cloud computing platform, even though it’s not a IoT neither data/contextmanagement platform. OpenStack platform presents a WEB dashboard through whichthe management of components of the cloud can be done. It also presents a command lineclient to use the services of the platform and a set of programming libraries, similar to theone presented by this work, to enable the interaction with its components APIs through itin many di�erent programming languages.

The created solution also presents graphical user interface similar to the onepresented by the GuardiãoCloud1 (CANTANHEDE, 2016), an IoT platform that alsoalso enables the communication between devices and the platform, using HTTP, MQTTor CoAP protocols. This also presents a WEB dashboard, where the management ofregistered devices can be done (in a way similar to what the FIoT-Client GUI presents).This, however doesn’t present any programming library, being necessary to manipulatedetails of the used protocol directly both on the device and in client applications. Someof its ideas, like the information of sensors and the triggering of actuators through itsWEB interface, served as inspiration to the development of the WEB interface for theFIoT-Client GUI.

Recently, the platform dojot2, an open-source IoT platform, was released by theCentro de Pesquisa e Desenvolvimento em Telecomunicações (CPqD), that is part of theBrazilian initiative to the development of the Internet of Things in the country. This

1 http://guardiaocloud.com.br/2 http://www.dojot.com.br/

58 Chapter 6. Related Work

platform is based on FIWARE platform, being its components extended and customizedto provide some specific functionalities directed to Brazilian needs. Some components werealso inserted in this platform when compared to the default FIWARE components, like acontrol panel in a WEB graphical interface and customized APIs. Since these platformcomponents are also based on FIWARE and some of the developed solutions (like theFIoT-Client programming library) currently are not implemented by the platform, thesolutions presented here could be adapted also ease the use of this platform.

The report produced by the Smart Metropolis project (MIDDLEWARE, 2016), inwhich we also participate in the elaboration as authors, also presented some platformsand compared them. The analyzed platforms were EcoDiF, Kaa, Sofia, CityHub and alsothe FIWARE. In general, these platforms provide REST APIs, support to di�erent IoTprotocols (MQTT, CoAP, HTTP etc.) and some of them provide a Software DevelopmentKit (SDK), programming libraries or graphical interfaces to ease the communication withthe platforms. Since most of these functionalities are provided by the FIWARE, the onesthat are not present on it (the programming libraries and the graphical interface) arecomplemented by this work, making the FIWARE platform also usable in similar approachesthat platforms that already presents it use. Also, since the developed programming libraryand the graphical user interface are modular, it can be adjusted separately to be alsoapplied in platforms that doesn’t present some of them.

The FIWARE was the target platform of this work, since it’s inserted in the contextof the Smart Metropolis project, and the solutions proposed by it were directed to thisplatform needs. However, from the experience gained, these solutions could also be adaptedand used to ease the use of most of these other platforms.

59

7 Conclusion

With the execution of this work it was possible to initially make a study of themain concepts and components related to IoT applications and the FIWARE platform.From this study, a docker-compose config file was proposed to set up an developmentenvironment, composed by the main components of the platform for developing context andIoT applications. A stable and functional environment configuration file was not availablebefore the work, since the ones that were found usually presented some failure that madeit impossible to execute the environment or used deprecated versions of FIWARE APIs.With this contribution, tasks as a local deploy of the components to run tests in a localmachine or even to configure a server composed by these components is eased.

Furthermore, in this work it was also possible to create a generic programminglibrary specification that is composed by a set of the main methods necessary to abstractthe usage of FIWARE APIs and eases the development of applications using its services.

From the created specification, it was also created an implementation, using thePython language, that enables both devices and client applications written in the languageto use it to accomplish most of the required steps while developing IoT applications onFIWARE platform.

Both the library specification and its implementation for consuming FIWAREservices weren’t found before the work. So, with the use of this contribution, it’s nowpossible to executing tasks from creating device representation to sending readings fromdevices and commands to them en an easier way in the platform.

In addition, to ease the interaction with applications and devices, specially bynon-technical users, it was also created a WEB based graphical user interface, that is notavailable on standard platform components. With it, the usage of services of IoT anddata/context management components can also be done by these non-technical users anddevelopers focused in other characteristics of IoT applications (not in the platform details),streamlining and facilitating the development process.

All these proposed solutions are publicly available on Github repositories, so thatusers and developers can use it and contribute to its evolution. A tutorial that presentssome concepts of the FIWARE platform and guides the usage of the proposed solutions isalso available in a Github repository.

Although the created solutions are still being evaluated, and a formal comparisonwith other existing tools is yet being done constantly after changes proposed by users, itsusefulness and facilitation for development can already be verified by user’s feedbacks.

60 Chapter 7. Conclusion

Since not all platform API methods and parameters were considered by the library,a possible future works is related to the improvement of the programming library im-plementation, in such a way that all the variations of the APIs are met by the libraryimplementation, making it universally usable by all the kinds of IoT applications withoutneeding to do customizations in the default library.

The consideration of these variations from APIs and the addition of other actionsalso in the web graphical user interface can also be done as a future work. The creation ofa Docker container with the graphical interface implementation and its distribution as aFIWARE component can also be done later.

Currently, the library implementation is only available in the Python language.So, a future work could be it’s implementation in other languages, that eases its usageby other devices (like a Arduino or other devices that use C/C++ language) or by otherclient applications (like web applications written in Java, for example). A future Javaimplementation could ease the usage of the platform also by the currently implementedprojects of the Smart Metropolis, that use the language in many developed applications.

In addition, the proposed tutorial could be improved, so that it includes stepsfor configuring the environment and using the proposed solutions in all the operationalsystems. Also, a documentation of solutions to specific problems in some platforms thatare being related by the users can be added to the tutorial.

61

Bibliography

AL-FUQAHA, A. et al. Internet of things: A survey on enabling technologies, protocols,and applications. IEEE Communications Surveys Tutorials, v. 17, n. 4, p. 2347–2376,Fourthquarter 2015. ISSN 1553-877X. Cited on page 25.

ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. p. 2787–2805,10 2010. Cited on page 25.

CANTANHEDE, R. F. Guardião Cloud - plataforma de apoio para internet das coisas.91 p. Dissertação (Mestrado) — Universidade Federal do Rio Grande do Norte, 2016.Cited on page 57.

FIELDING, R. T. Architectural Styles and the Design of Network-based SoftwareArchitectures. Tese (Doutorado), 2000. Cited 2 times on pages 28 and 46.

FIWARE. Internet of Things (IoT) Services Enablement Architecture. Available on:<https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture>. Accessed: January 20, 2017. Citedon page 32.

GARTNER. Gartner Says 8.4 Billion Connected "Things" Will Be in Use in 2017, Up 31Percent From 2016. Available on: <https://www.gartner.com/newsroom/id/3598917>.Accessed: September 12, 2017. Cited on page 21.

ITU-T. Overview of the Internet of things. ITU. 22 p. Available on: <http://handle.itu.int/11.1002/1000/11559>. Accessed: October 15, 2017. Cited on page 25.

MIDDLEWARE, S. M. W. Requisitos e Plataformas de Middleware para CidadesInteligentes. Instituto Metrópole Digital, Universidade Federal do Rio Grande do Norte,2016. 47 p. Available on: <http://smartmetropolis.imd.ufrn.br/wp-content/uploads/2016/05/RT1-WP5.pdf>. Accessed: June 10, 2017. Cited 3 times on pages 22, 26, and 58.

OMA. Next Generation Service Interfaces Architecture. Open Mobile Alliance, 2012. 16 p.Available on: <http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-AD-NGSI-V1_0-20120529-A.pdf>. Accessed: October 25, 2017. Cited on page 33.

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture

https://www.gartner.com/newsroom/id/3598917

http://handle.itu.int/11.1002/1000/11559

http://handle.itu.int/11.1002/1000/11559

http://smartmetropolis.imd.ufrn.br/wp-content/uploads/2016/05/RT1-WP5.pdf

http://smartmetropolis.imd.ufrn.br/wp-content/uploads/2016/05/RT1-WP5.pdf

http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-AD-NGSI-V1_0-20120529-A.pdf

http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-AD-NGSI-V1_0-20120529-A.pdf

Appendix

65

APPENDIX A – FIoT-Client-Python

Specification

A.1 Class Diagram

Figure 42 – Class diagram of FIoT-Client-Python

66 APPENDIX A. FIoT-Client-Python Specification

A.2. Library Modules Documentation 67

A.2 Library Modules Documentation

fiotclient package

Submodules

fiotclient.context module

Bases: fiotclient.SimpleClient

Creates a new NGSI en�ty with the given structure in the currently selected service

Parameters: en�ty_id – The id to the en�ty to be createden�ty_schema – JSON string represen�ng en�ty schema

Returns: Informa�on of the registered en�ty

Get en��es created with a given en�ty type

Parameters: en�ty_type – The type of the en��es to be searched

Returns: A list with the informa�on of the en��es found with the given type

Get en�ty informa�on given its en�ty id

Parameters: en�ty_id – The id of the en�ty to be searched

Returns: The informa�on of the en�ty found with the given id or None if no en�tywas found with the id

Get historical data from a specific a�ribute of an en�ty

Parameters: en�ty_type – The type of the en�ty to get historical dataen�ty_id – The id of the en�ty to get historical dataa�ribute – The a�ribute of the en�ty to get historical dataitems_number – The number of last entries to be queried. If no value isprovided, the default value (10 entries) will be used

Returns: The historical data on the specified a�ribute of the given en�ty

class fiotclient.context.FiwareContextClient(config_file)

create_entity(en�ty_id, en�ty_schema)

get_entities_by_type(en�ty_type)

get_entity_by_id(en�ty_id)

get_historical_data(en�ty_type, en�ty_id, a�ribute, items_number=10)

Get subscrip�on informa�on given its subscrip�on id

Parameters: subscrip�on_id – The id of the subscrip�on to be searched

Returns: The informa�on of the subscrip�on found with the given id or None if nosubscrip�on was found with the id

Get all subscrip�ons

Returns: A list with the ids of all the subscrip�ons

Removes an en�ty with the given id

Parameters: en�ty_id – The id to the en�ty to be removed

Returns: Informa�on of the removed en�ty

Register a new rule to be evaluated on a�ribute values change and a ac�on to betaken when rule evaluated to true

Parameters: a�ribute – The a�ribute to be monitoreda�ribute_type – The type of the a�ribute to be monitoredcondi�on – The condi�on to be evaluated on changes on a�ribute’svalueac�on – The ac�on type to be taken when condi�on is evaluated true.Currently accepted values to this parameter are ‘email’ and ‘post’no�fica�on_url – The endpoint to which POST no�fica�ons will be sent

Returns: The informa�on of the created rule

Create a new subscrip�on on given a�ributes of the device with the specified id

Parameters: device_id – The id of the device to be monitoreda�ributes – The list of a�ributes do be monitoredno�fica�on_url – The URL to which the no�fica�on will be sent onchanges

Returns: The informa�on of the subscrip�on

get_subscription_by_id(subscrip�on_id)

list_subscriptions()

remove_entity(en�ty_id)

subscribe_attribute_change_with_rule(a�ribute, a�ribute_type, condi�on,ac�on='post', no�fica�on_url=None)

subscribe_attributes_change(device_id, a�ributes, no�fica�on_url)

Create a new subscrip�on on a�ributes to send changes on its values to sinksconfigured on Cygnus

Parameters: en�ty_id – The id of the en�ty to be monitoreda�ributes – The list of a�ributes do be monitored


Create a new subscrip�on on a�ributes to store changes on its values as historicaldata

Parameters: en�ty_id – The id of the en�ty to be monitoreda�ributes – The list of a�ributes do be monitored


Remove a subscrip�on with the given subscrip�on id

Parameters: subscrip�on_id – The id of the subscrip�on to be removed

Returns: True if the subscrip�on with the given id was removed False if nosubscrip�on with the given id was removed

Updates an en�ty with the given id for the new structure in the currently selectedservice

Parameters: en�ty_id – The id to the en�ty to be updateden�ty_schema – JSON string represen�ng new en�ty schema

Returns: Informa�on of the updated en�ty

fiotclient.iot module

Bases: fiotclient.SimpleClient

Creates a new service with the given informa�on

subscribe_cygnus(en�ty_id, a�ributes)

subscribe_historical_data(en�ty_id, a�ributes)

unsubscribe(subscrip�on_id)

update_entity(en�ty_id, en�ty_schema)

class fiotclient.iot.FiwareIotClient(config_file)

create_service(service, service_path, api_key=None)

Parameters: service – The name of the service to be createdservice_path – The service path of the service to be createdapi_key – A specific api key to use to create the service. If no api key isprovided, a random one will be generated.

Returns: The informa�on of the created service

Generate a random api key to be used on service crea�on

Returns: The generated api key string

Get device informa�on given its device id

Parameters: device_id – The id of the device to be searched

Returns: The informa�on of the device found with the given id or None if no devicewas found with the id

Get a list of polling commands of the device with the given id when sending ameasurement group or a list of measurement groups to the FIWARE pla�orm from adevice with POST request

Parameters: device_id – The id of the device to verify pooling commandsmeasurements – A measurement group (a dict where keys are devicea�ributes and values are measurements for each a�ribute) or a list ofmeasurement groups obtained in the device

Returns: The list of pooling commands of the device

List the devices registered in the currently selected service

Returns: The list of devices registered in the service

Get all registered services

Returns: A list with the registered services

sta�c generate_api_key()

get_device_by_id(device_id)

get_polling_commands(device_id, measurements)

list_devices()

list_services()

Register a new device with the given structure in the currently selected service

Parameters: device_schema – JSON string represen�ng device schemadevice_id – The id to the device to be createden�ty_id – The id to the NGSI en�ty created represen�ng the deviceendpoint – The endpoint of the device to which ac�ons will be sent onformat IP:PORTprotocol – The protocol to be used on device. If no value is provided thedefault protocol (IoTA‑UL) will be used

Returns: Informa�on of the registered device

Register a new device loading its structure from a given file

Parameters: device_file_path – The path to the descrip�on file for the devicedevice_id – The id to the device to be createden�ty_id – The id to the NGSI en�ty created represen�ng the deviceendpoint – The endpoint of the device to which ac�ons will be sent onformat IP:PORTprotocol – The protocol to be used on device. If no value is provided thedefault protocol (IoTA‑UL) will be used

Returns: Informa�on of the registered device

Removes a device with the given id in the currently selected service

Parameters: device_id – The id to the device to be removed

Returns: Response of the removal request

Remove a subservice into a service. If Fiware‑ServicePath is ‘/*’ or ‘/#’ remove serviceand all its sub‑services.

register_device(device_schema, device_id, en�ty_id, endpoint='', protocol='IoTA‑UL')

register_device_from_file(device_file_path, device_id, en�ty_id, endpoint='',protocol='IoTA‑UL')

remove_device(device_id)

remove_service(service, service_path, api_key='', remove_devices=False)

Parameters: service – The name of the service to be removedservice_path – The service path of the service to be removedapi_key – The api key of the service. If no value is provided, default value“” will be usedremove_devices – If either its to remove devices in service/subservice ornot. If no value is provided, the default value (False) will be used. Thisparameter is not valid when Fiware‑ServicePath is ‘/*’ or ‘/#’.

Returns: The response of the removal request

(h�p://fiware‑orion.readthedocs.io/en/latest/user/walkthrough_apiv1/index.html#ngsi10‑standard‑opera�ons at “Update context elements” sec�on)

Parameters: en�ty_id – The id of the en�ty that represents the devicedevice_id – The id of the device to which the command will be sentcommand – The name of the command to be called on the deviceparams – The command parameters to be sent

Returns: The result of the command call

Sends a measurement group or a list of measurement groups from a device to theFIWARE pla�orm

Parameters: device_id – The id of the device in which the measurement was obtainedmeasurements – A measurement group (a dict where keys are devicea�ributes and values are measurements for each a�ribute) or a list ofmeasurement groups obtained in the deviceprotocol – The transport protocol to be used to send measurements.Currently accepted values are ‘MQTT’ and ‘HTTP’. If no value is providedthe default value (MQTT) will be used

Returns: The summary of the sent measurements

Sets the api key to use to send measurements from device

Parameters: api_key – The api key of the service to use

send_command(en�ty_id, device_id, command, params=None)

Sends a command from the FIWARE pla�orm to a specific device

send_observation(device_id, measurements, protocol='MQTT')

set_api_key(api_key)

Returns: None

Updates a registered device with the given structure in the currently selected service

Parameters: device_schema – JSON string represen�ng device schemadevice_id – The id to the device to be updateden�ty_id – The id to the NGSI en�ty that represents the deviceendpoint – The endpoint of the device to which ac�ons will be sent onformat IP:PORTprotocol – The protocol to be used on device. If no value is provided thedefault protocol (IoTA‑UL) will be used

Returns: Informa�on of the updated device

fiotclient.utils module

Merge two dicts into a single dic�onary

Parameters: dict_args – The dicts to be merged

Returns: The resul�ng dic�onary from the merge

Load configura�on file and creates a dict with the necessary a�ributes

Parameters: config_file – The file to be read

Returns: A dict with the a�ributes read from the file

Module contents

Bases: object

If you didn’t have a user, go and register first at h�p://cloud.fiware.org

update_device(device_schema, device_id, en�ty_id, endpoint='', protocol='IoTA‑UL')

fiotclient.utils.merge_dicts(*dict_args)

fiotclient.utils.read_config_file(config_file)

class fiotclient.SimpleClient(config_file)

authenticate(username, password)

Generates an authen�ca�on token based on user creden�als using FIWARE Lab OAuth2.0

Authen�ca�on system

Parameters: username – the user’s username from Fiware authen�ca�on accountpassword – the user’s password from Fiware authen�ca�on account

Returns: the generated token and expira�on

Specify the service context to use on opera�ons

Parameters: service – The name of the service to be usedservice_path – The service path of the service to be used

Returns: None

set_service(service, service_path)

development of support tools for the use of iot and context … · 2019. 1. 31. · nowadays the...

Documents