Departmento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Uma proposta de framework para facilitar o
desenvolvimento de aplicações baseadas em
IoT
Dannylo Johnathan Bernardino Egídio
Uma proposta de framework para facilitar o
desenvolvimento de aplicações baseadas em IoT
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.
Linha de pesquisa: Engenharia de Software
Orientador
Prof. Dr. Gibeon Soares de Aquino Junior
PPgSC Programa de Pós-Graduação em Sistemas e Computação DIMAp Departamento de Informática e Matemática Aplicada
CCET Centro de Ciências Exatas e da Terra UFRN Universidade Federal do Rio Grande do Norte
Natal Julho, 2018
Egídio, Dannylo Johnathan Bernardino.
Uma proposta de framework para facilitar o desenvolvimento de aplicações baseadas em IoT / Dannylo Johnathan Bernardino
Egídio. - 2018. 94f.: il.
Dissertação (Mestrado) - Universidade Federal do Rio Grande do Norte, Departamento de Informática e Matemática Aplicada (DIMAP), Programa de Pós-graduação em Sistemas e Computação (PPgSC), Natal, 2018.
Orientador: Dr. Gibeon Soares de Aquino Júnior.
1. Virtualização Dissertação. 2. Internet das Coisas -Dissertação. 3. Framework - -Dissertação. I. Aquino Júnior, Gibeon Soares de. II. Título.
RN/UF/BCZM CDU 004.43-021.131
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Agradecimentos
Agradeço inicialmente ao pai celestial, por ter me abençoado e protegido durante toda esta caminhada.
A minha amada esposa Francielly Luanne que durante todo o Mestrado tem sido for-taleza em minhas aspirações, e pacientemente tem aguentado meus estresses e frustrações que foram reincidentes durante esta formação.
A meus pais, Vanderlei e Isabel, pelo exemplo que representam em minha vida e por todo o incentivo e amor dedicados a mim desde meu nascimento até agora, esta vitória jamais seria possível sem o amparo, exemplo e dedicação deles.
A meu orientador Gibeon Aquino, pelos ensinamentos e conselhos em minha formação acadêmica, e por ser um exemplo de pro ssional e humano na qual posso me espelhar.
Ao meu orientador da graduação e amigo Héldon José, por ter me motivado desde a graduação a subir mais um degrau na escada do conhecimento e vir fazer este mestrado. A meus amigos do LabCoMU, pelos conselhos, aprendizados, felicidades e frustrações compartilhadas durante este tempo.
Aos amigos Thiago e Bruno, pelas revisões e dicas na produção deste trabalho. Aos amigos Romerito, Sidney, Paulenne e Diego, por terem me acolhido em minha chegada à Natal e pela amizade que foi dedicada a minha pessoa.
E a todos, que de forma direta ou indireta, puderam contribuir nesta caminhada e na realização deste sonho.
à coragem." Allan Kardec
desenvolvimento de aplicações baseadas em IoT
Autor: Dannylo Johnathan Bernardino Egídio Orientador(a): Prof. Dr. Gibeon Soares de Aquino Junior
Resumo
Os últimos anos têm sido marcados por um crescente avanço na computação embarcada, tecnologias de sensoriamento e dispositivos conectados. Tal avanço impactou de maneira expressiva em paradigmas inovadores, tais como o de Internet das Coisas (IoT) que acre-dita que objetos inteligentes capazes de se conectarem na rede poderão cooperar entre si para alcançar um objetivo comum. Tal crescimento alavancou iniciativas de fornecedores em produzir protocolos e padrões de comunicação que viabilizassem essa cooperação. No entanto, a diversidade considerável de dispositivos e consequentemente de protocolos que surgiram, acabaram por di cultar esse processo. Inúmeros desa os foram surgindo, den-tre eles a heterogeneidade e a interoperabilidade. Esses desa os tornaram o processo de desenvolvimento das aplicações IoT uma tarefa complexa e custosa, pois as capacidades destes protocolos e padrões voltadas à descoberta dos dispositivos na rede, comunicação entre eles, entre outras, tornaram-se bastante especí cas para cada dispositivo, obrigando o desenvolvedor a criar estratégias de integração complexas para lidar com essa limita-ção. Desta forma, este trabalho propõe um framework que buscará facilitar o processo de desenvolvimento de aplicações IoT através da virtualização de dispositivos, de maneira que, aspectos heterogêneos ligados aos dispositivos serão abstraídos por esta virtualização e operações comuns dos protocolos tais como descoberta de dispositivos e comunicação com estes serão abstraídos através de uma interface comum entre eles, integrando-os e diminuindo os impactos das características heterogêneas.
Palavras-chave: Internet das Coisas, Framework, Simpli cação, Desenvolvimento, Aplica-ção, Virtualização.
IoT-based applications
Author: Dannylo Johnathan Bernardino Egídio Supervisor: Prof. Dr. Gibeon Soares de Aquino Junior
Abstract
Recent years have been marked by a growing advance in embedded computing, sensoring technologies and connected devices. Such advance had a signi cant impact on innovative paradigms such as the Internet of Things (IoT), which believes that intelligent objects ca-pable of connecting in the network can cooperate among each other to achieve a common goal. Such growth has motivated supplier initiatives to produce protocols and communi-cation standards that would enable such cooperation. However, the considerable diversity of devices and consequently protocols that have emerged have made this process di cult, creating numerous challenges, including heterogeneity and interoperability. These chal-lenges have made the IoT application development process a complex and costly task, since the capabilities of these protocols and standards aimed at discovering the devices on the network, communication among them, have become quite speci c for each device, forcing the developer to create complex integration strategies to deal with this limitation. In this way, this work proposes a framework that seeks to facilitate the process of deve-lopment of IoT applications through device virtualization, so that heterogeneous aspects connected to devices will be abstracted by this virtualization, and common operations of protocols such as discovery of devices and communication with them will be abstracted through a common interface between them, integrating them and reducing the impacts of the heterogeneous characteristics.
Keywords: Internet of Things, Framework, Simplifcation, Development, Application, Vir-tualization.
Lista de guras
1 Etapas da Metodologia . . . p. 19 2 Paradigma de IoT como sendo o resultado da convergência de três visões
(ATZORI; IERA; MORABITO, 2010) . . . p. 22
3 Modelo arquitetural genérico para IoT (KHAN et al., 2012) . . . p. 23
4 Camada de mensagens do CoAP(SHELBY; HARTKE; BORMANN, 2014) . p. 27
5 Implementação proposta para interoperabilidade entre HTTP e CoAP.(BORMANN; CASTELLANI; SHELBY, 2012) . . . p. 27
6 Fluxo de funcionamento básico do UPnP.(ARUNACHALAM; GANAPATHY,
2016) . . . p. 29 7 Fontes de Dados . . . p. 34 8 Veículos de Publicação . . . p. 35 9 Número de publicações por ano . . . p. 35 10 Tipos de soluções encontradas . . . p. 36 11 Abordagens mais utilizadas . . . p. 37 12 Requisitos atingidos pelas propostas . . . p. 38 13 Objetivos das soluções encontradas . . . p. 40 14 Aplicação IoT lidando com a heterogeneidade de Dispositivos. . . p. 46 15 Aplicação IoT utilizando o framework para simpli car o desenvolvimento. p. 47 16 Visão geral da Arquitetura . . . p. 48 17 Estrutura do dispositivo virtual. . . p. 50 18 Funcionamento do Tradutor Proxy. . . p. 53 19 Estrutura de comunicação entre os dispositivos. . . p. 55
21 Diagrama de Classes da estrutura do Framework . . . p. 58 22 Con guração do con g.properties para de nir proxies externos ao
fra-mework. . . p. 60 23 Instanciação do Framework. . . p. 61 24 Sequência de funcionamento do Proxy UPnP. . . p. 63 25 Sequência de funcionamento do Proxy Bluetooth. . . p. 64 26 Cenário do experimento utilizado como objeto de estudo. . . p. 67 27 Aplicativo Android representando um Termostato Bluetooth. . . p. 69 28 Aplicação cliente desenvolvida na plataforma Android. . . p. 70 29 Funcionamento geral da aplicação cliente com o framework. . . p. 71 30 Código utilizado para a instanciação do framework e descoberta dos
dis-positivos na aplicação cliente. . . p. 71 31 Código necessário para a veri cação do estado dos dispositivos e
modi -cação do estado do termostato. . . p. 72 32 Log registrando a alteração bem-sucedida do estado do termostato. . . p. 72 33 LOC por classe mensuradas no experimento do Estudo de Caso. . . p. 74 34 Comparativo da Complexidade Ciclomática das aplicações IoT. . . p. 75 35 LOC para aplicação envolvendo 10 sensores e um atuador. . . p. 76 36 Comparativo da complexidade ciclomática para a aplicação com 10
Lista de tabelas
1 Repositórios de Busca . . . p. 32 2 Iteração de Leituras . . . p. 33 3 Serviços utilitários fornecidos pelo núcleo do framework. . . p. 65 4 Linhas de Código (LOC) extraídas das classes do caso de teste (um sensor
e um termostato). . . p. 73 5 Linhas de Código (LOC) extraídas das classes do caso de teste (dez
Lista de abreviaturas e siglas
IoT Internet of ThingsQoS Quality of Service
SoA Service-oriented architecture
CoAP Constrained Application Protocol REST Representational State Transfer URI Uniform Resource Identi er HTTP Hypertext Transfer Protocol M2M - Machine-to-Machine
UDP User Datagram Protocol UPnP Universal Plug and Play XML eXtensible Markup Language URL Uniform Resource Locator
IEEE Institute of Electrical and Electronic Engineers API Application Programing Interface
JSON JavaScript Object Notation" WMC Weighted Methods per Class CCN Cyclomatic Complexity Number LOC Lines of Code
MQTT Message Queuing Telemetry Transport SOAP Simple Object Access Protocol
Lista de Listagens
4.1 Iniciação do framework e descoberta de dispositivos . . . p. 61 4.2 Solicitando dados dos dispositivos virtuais . . . p. 61 4.3 Enviando dados para os dispositivos virtuais . . . p. 61 4.4 Componentes necessários para a de nição de um novo proxy na camada
Sumário
1 Introdução p. 17 1.1 Motivação . . . p. 17 1.2 Objetivos . . . p. 19 1.3 Metodologia . . . p. 19 1.4 Organização do trabalho . . . p. 20 2 Fundamentação Teórica p. 212.1 Internet das Coisas . . . p. 21 2.1.1 Visões . . . p. 22 2.1.2 Modelo Arquitetural . . . p. 23 2.1.3 Tecnologias envolvidas . . . p. 25 2.2 Constrained Application Protocol . . . p. 26 2.3 Universal Plug and Play . . . p. 28 2.4 Bluetooth . . . p. 30
3 Revisão do Estado da Arte p. 31
3.1 Metodologia . . . p. 31 3.1.1 Planejamento . . . p. 32 3.1.2 String de Busca . . . p. 32 3.1.3 Fontes de Busca . . . p. 32 3.1.4 Execução da Revisão . . . p. 33 3.1.5 Processo de Seleção . . . p. 33
3.2 Resultados . . . p. 34 3.2.1 Análise da QP1 . . . p. 35 3.2.2 Análise da QP2 . . . p. 37 3.2.3 Análise da QP3 . . . p. 39 3.3 Discussões . . . p. 40 4 Um framework para facilitar o desenvolvimento de aplicações
base-adas em IoT p. 44
4.1 Cenário de Exemplo: Controle de temperatura . . . p. 45 4.2 Arquitetura Proposta . . . p. 48 4.2.1 Visão Geral . . . p. 48 4.2.2 Dispositivo Virtual . . . p. 49 4.2.2.1 Componentes de De nição . . . p. 50 4.2.2.2 Componentes de Comunicação . . . p. 51 4.2.3 Gerenciador de Dispositivos . . . p. 52 4.2.4 Servidor CoAP . . . p. 52 4.2.5 Módulo Health . . . p. 52 4.2.6 Tradutor Proxy . . . p. 53 4.3 Comunicação entre Dispositivos Virtuais . . . p. 54 4.4 Operacionalização da Solução . . . p. 56 4.5 Desenvolvimento da Solução . . . p. 57 4.5.1 Estrutura da Solução . . . p. 57 4.5.2 Instanciação do Framework . . . p. 60 4.5.3 Núcleo e Pontos de Extensão . . . p. 62 4.5.3.1 Adicionando novos Proxies . . . p. 62 4.5.3.2 O Núcleo . . . p. 64
5.1 Prova de Conceito . . . p. 66 5.1.1 Planejamento . . . p. 66 5.1.1.1 Questões de Pesquisa . . . p. 66 5.1.1.2 Sujeitos . . . p. 67 5.1.1.3 Objeto . . . p. 67 5.1.1.4 Unidades de análise . . . p. 68 5.1.1.5 Coleta de Dados . . . p. 68 5.1.2 Execução . . . p. 68 5.1.2.1 A aplicação . . . p. 68 5.1.2.2 A coleta e análise dos dados . . . p. 73 5.1.3 Respostas às questões de pesquisa . . . p. 74
5.1.3.1 Qual o impacto do uso do framework em uma aplicação IoT quanto à diminuição do esforço de codi cação de
seu desenvolvimento? . . . p. 74 5.1.3.2 Questão de pesquisa 2: Qual o impacto que pode haver
no aumento da quantidade de dispositivos envolvidos na aplicação no tocante à complexidade de codi cação da
aplicação que utiliza o framework? . . . p. 76 5.1.4 Ameaças à Validade . . . p. 77
6 Trabalhos Relacionados p. 79
6.1 Modelos de representação de Dispositivos . . . p. 79 6.2 Dispositivos abstraídos como Serviços . . . p. 81
7 Considerações Finais p. 83
7.1 Retrospectiva e conclusões do trabalho . . . p. 83 7.2 Contribuições . . . p. 85 7.3 Trabalhos Futuros . . . p. 85
1 Introdução
Este capítulo tem a nalidade de descrever em termos gerais a proposta desta pesquisa, descrevendo os fatores motivadores na Seção 1.1, objetivos gerais e especí cos pretendidos na Seção 1.2, a metodologia utilizada para se atingir os objetivos na Seção 1.3, e por m, como o trabalho está estruturado na Seção 1.4.
1.1 Motivação
Os últimos anos têm sido marcados por um crescente avanço na computação embar-cada, tecnologias de sensoriamento e dispositivos inteligentes sendo amplamente distribuí-dos no mercado. Algumas previsões recentes estimam cerca de 29 bilhões de dispositivos conectados até 2022 (MEHTA et al., 2017). Este expressivo surgimento de tecnologias
mi-niaturizadas inteligentes e conectadas tem propiciado o desenvolvimento de uma série de serviços úteis e importantes para as pessoas.
Tal avanço impactou de maneira signi cativa em conceitos inovadores, como o conceito de Internet da Coisas (IoT ), que preconiza que objetos inteligentes, tidos como "coisas", podem cooperar entre si através da internet para alcançar um objetivo comum (PATEL; CASSOU, 2015). O conceito de IoT ganhou combustível neste cenário e consequentemente o interesse da indústria e mercado em basear os novos serviços e aplicações oferecidas em seus princípios (DATTA; BONNET, 2016). Desta forma, ecossistemas inteligentes têm
sido sugeridos para inúmeros contextos, tais como casas inteligentes, cidades inteligentes, fazendas inteligentes, fábricas inteligentes, entre outros (YEN et al., 2017).
Porém, as tecnologias utilizadas por estas aplicações são portadoras de limitações críticas que são cruciais para a concretização dos conceitos de IoT, dentre elas estão a heterogeneidade e interoperabilidade entre dispositivos e padrões, sendo considerado um dos maiores desa os de IoT (TAYUR; SUCHITHRA, 2017), as restrições de recursos, que
aplicação (CARRANZA-GARCÍA et al., 2016), entre outras limitações em nível de hardware
que de alguma maneira constituem obstáculos para o avanço efetivo do conceito de IoT. Ademais, a própria variedade de dispositivos existentes nos leva a compreender o processo de desenvolvimento de aplicações IoT como algo complexo e custoso (PATEL; CASSOU, 2015). Essa variedade de dispositivos implicam em várias formas de representa-ção de dados, múltiplos protocolos de comunicarepresenta-ção (SASIREKHA; SWAMYNATHAN, 2016),
uma variedade de implementações de serviços em nível de software especí cas para cada dispositivo (ASHRAF et al., 2016). Deste modo, abordagens diferentes podem ser sugeridas
para cada dispositivo especí co.
Compreendendo as limitações voltadas ao vasto número de dispositivos diferentes exis-tentes, torna-se interessante o uso da habilidade de descoberta de dispositivos. Essa habi-lidade representa um princípio de projeto orientado a serviços capaz de tornar os serviços identi cáveis na rede através de meta-dados disponibilizados pelos mesmos facilitando a colaboração entre eles (JARA et al., 2014). Tal modelo é muito adotado por aplicações IoT que planejam facilitar o uso dos dispositivos envolvidos na aplicação (DATTA; BONNET,
2016) .
Observando todos os aspectos que tornam os dispositivos e seus serviços heterogêneos e de baixa interoperabilidade, padrões foram sendo sugeridos por muitos consórcios de fornecedores. No entanto, estes padrões apenas solucionam questões de interoperabilidade para o conjunto de dispositivos que atendem, provendo mecanismos de registro, descoberta e comunicação. Contudo, estes padrões geralmente costumam ser incompatíveis entre si (TAYUR; SUCHITHRA, 2017). Sendo assim, o processo de descoberta e comunicação
envolvendo múltiplos padrões e protocolos em uma aplicação acabam por se tornarem complexos de trabalharem em conjunto.
Desta forma, é perceptível a necessidade de soluções que busquem integrar as ca-pacidades de protocolos heterogêneos, abstraindo as diferenças existentes entre eles e viabilizando a simpli cação do desenvolvimento de aplicações baseadas em IoT. Para tal, acreditamos ser importante buscar uma abordagem orientada à virtualização de disposi-tivos que os representará de maneira uniforme e permitirá o acesso direto às operações e recursos disponibilizados por estes (SILVA et al., 2016; FERRERA et al., 2017). Neste
con-texto, aspectos heterogêneos e capacidades individuais dos mesmos cam abstraídos do ponto de vista do desenvolvedor.
Sendo assim, este trabalho de dissertação baseia-se na hipótese de que a de nição de um modelo homogêneo de representação de "coisas", através da virtualização, auxilia
na simpli cação do desenvolvimento de aplicações baseadas em IoT. As especi cidades funcionais e técnicas, que podem ser heterogêneas, seriam abstraídas por este modelo de representação.
1.2 Objetivos
Este trabalho tem como objetivo geral o desenvolvimento de um framework que visa facilitar o desenvolvimento de aplicações baseadas em IoT, abstraindo e uniformizando capacidades heterogêneas voltadas à protocolos de comunicação tais como mecanismos de descoberta e colaboração entre dispositivos. A abordagem buscará tratar os dispositivos da aplicação de maneira uniforme, propiciando recursos para a representação virtualizada dos mesmos. Desta forma, os objetivos especí cos pretendidos são os seguintes:
• Mapear os requisitos, limitações e abordagens mais comuns levantados em soluções do estado da arte que objetivem a simpli cação do desenvolvimento de aplicações IoT.
• Implementar uma solução que viabilize a simpli cação do desenvolvimento de apli-cações IoT a partir da abstração e virtualização de dispositivos.
• Avaliar sob o ponto de vista da facilidade de desenvolvimento a solução desenvolvida, utilizando-se de métricas que possam validar tal aspecto.
1.3 Metodologia
Esta seção descreve as etapas da metodologia (Vide Figura 1) que foram seguidas para esta dissertação, dividindo-se em três etapas: Revisão Literária, Projeto e Implementação do Framework e Avaliação.
Figura 1: Etapas da Metodologia
A primeira etapa consiste de um processo de pesquisa exploratória. Nessa etapa foi de nida uma string de busca com o objetivo de encontrar trabalhos relacionados à ferra-mentas de software especializadas em simpli car o processo de desenvolvimento de apli-cações IoT. A string foi executada no repositório Scopus da Elsevier pelo fato do mesmo
indexar os principais e mais relevantes repositórios da engenharia e computação. Os re-sultados foram então analisados. Toda a Metodologia é descrita em maiores detalhes no Capítulo 3.
A etapa seguinte, concentra-se no projeto e desenvolvimento do framework na qual essa dissertação tem como objetivo. Nesta etapa, a arquitetura do framework e seus com-ponentes constituintes são projetados de modo a embasar detalhes mais técnicos do seu desenvolvimento. Por m, foi desenvolvida a solução utilizando a arquitetura mencionada. Os detalhes inerentes a esse processo estão descritos no capítulo 4.
O último passo, o de Avaliação, trata-se de uma prova de conceito cujo objetivo é obter resultados que possam avaliar sob o ponto de vista da facilidade de desenvolvimento o framework proposto.
1.4 Organização do trabalho
O restante desse trabalho encontra-se organizado da seguinte forma:
• O capítulo 2 expõe a fundamentação teórica contendo os conceitos necessários ao entendimento deste trabalho;
• O capítulo 3 apresenta a revisão do estado da arte realizada neste trabalho. Tal revisão tem o objetivo de conhecer de maneira mais aprofundada as ferramentas associadas à simpli cação do desenvolvimento de aplicações IoT e alguns detalhes relacionados a estas considerados importantes.
• O capítulo 4 expõe o framework proposto por este trabalho, cujo objetivo será de simpli car o desenvolvimento de aplicações baseadas em IoT.
• O capítulo 5, trata sobre a avaliação do framework proposto neste trabalho, e tal avaliação se deu a partir de uma prova de conceito.
• O capítulo 6 expõe resumidamente os trabalhos relacionados ao proposto por essa pesquisa.
• O capítulo 7 discorre sobre considerações nais deste trabalho, as principais contri-buições do mesmo e os trabalhos futuros propostos pelo autor desta pesquisa.
2 Fundamentação Teórica
Este capítulo discorre sobre os fundamentos no qual sustenta-se este trabalho. Seu objetivo é explicar de maneira sucinta, as características gerais de cada um dos concei-tos utilizados na construção da proposta desta pesquisa. Desta forma, este capítulo está organizado em quatro seções: A primeira, a 2.1 trata sobre conceitualizar a Internet das Coisas, suas visões, modelo arquitetural e tecnologias envolvidas, a 2.2 discorre sobre o CoAP e suas características técnicas, a 2.3 busca explicar o funcionamento do UPnP, por m, a 2.4 explica sobre o funcionamento do protocolo Bluetooth.
2.1 Internet das Coisas
A Internet das Coisas, do inglês, Internet of Things (IoT) trata-se de um paradigma inovador que vai além das soluções computacionais voltadas à desktop tradicionais (GUBBI et al., 2013). O termo foi introduzido por Kevin Ashton no ano de 1998 em um contexto
de gerenciamento de cadeia de suprimentos, e passou a ganhar a partir disto, uma maior atenção da academia e da indústria (GUBBI et al., 2013; BANDYOPADHYAY; SEN, 2011).
A ideia principal do paradigma centraliza-se em objetos comuns de nosso cotidiano inseridos inevitavelmente na rede. Neste cenário, sensores, tecnologias de identi cação, dispositivos inteligentes de toda natureza, estarão em alta para embarcarem invisivelmente em soluções que gerarão uma alta quantidade de dados. Essa massiva quantidade de dados consequentemente necessitará de estruturas que possam comportar e processar tal volume para que assim possa ter valor para a aplicação (GUBBI et al., 2013) .
Além de todos os benefícios oriundos desse novo modelo computacional, Atzori ( AT-ZORI; IERA; MORABITO, 2010) considera como sendo a principal força que norteará os
objetivos do paradigma, o impacto que ela terá no dia-a-dia e nos aspectos comportamen-tais de seus usuários. Neste ponto de vista, o autor acredita que contextos domésticos, de vida assistida, aprendizado e saúde, são apenas alguns poucos exemplos de cenários
em que a IoT desempenhará demasiada liderança no desenvolvimento de aplicações, bem como no âmbito de negócios, havendo considerável impacto em aplicações de automação, manufatura, gestão de negócios, transportes, etc.
2.1.1 Visões
O conceito de IoT é permeado de múltiplas visões e discussões diversas. Isso se dá devido ao próprio nome "Internet das Coisas carregar inúmeras formas de pensar. O termo "Internet nos direciona a uma visão de IoT focada diretamente na rede e em seus recursos, já o termo "Coisas, foca diretamente em múltiplos objetos inteligentes e conectados que realizam operações especí cas e estão integrados no cenário, havendo comunicação entre eles (ATZORI; IERA; MORABITO, 2010). O termo "Coisas"também é
considerado uma nova dimensão da atual interação das aplicações com o ser humano (LU; PAPAGIANNIDIS; ALAMANOS, 2018).
Figura 2: Paradigma de IoT como sendo o resultado da convergência de três visões ( AT-ZORI; IERA; MORABITO, 2010)
.
Contudo, o uso desses termos em conjunto semanticamente nos diz que trata-se de um conjunto de dispositivos heterogêneos, endereçáveis, e interconectados através de proto-colos de comunicação (BANDYOPADHYAY; SEN, 2011). Uma terceira perspectiva também é reconhecida neste aspecto: A semântica. Tal visão é orientada ao endereçamento (ou identi cação exclusiva), armazenamento e processamento da informação gerada nessas aplicações, tal processamento deve considerar a natureza heterogênea da informação
ge-rada e dos dispositivos que a geraram.
Desta forma, acredita-se que o paradigma de IoT é o resultado da convergência des-tas três visões (ATZORI; IERA; MORABITO, 2010), a Figura 2 ilustra esse fato, além de
apresentar algumas das principais tecnologias e conceitos mais comuns de cada visão. Outras de nições podem ser evidenciadas no estudo de Lu (LU; PAPAGIANNIDIS; ALA-MANOS, 2018), dentre estas, sugere-se que IoT seja um conjunto de objetos capazes de
se identi carem e conectarem-se em uma rede. E a de nição proposta pela Comissão Europeia, considerada pelo referido autor como uma das mais representativas de nições de IoT, considerando o paradigma como uma infraestrutura de rede global que agirá de maneira integralizada como uma extensão da futura internet.
2.1.2 Modelo Arquitetural
A arquitetura considerada genérica do paradigma IoT precisa abordar muitos fatores que vão além da arquitetura TCP/IP convencional (KHAN et al., 2012). Isto porque trata-se de um modelo que gerará muito mais informação e tráfego, além dos desa os voltados à privacidade e segurança. Desta forma, um modelo arquitetural ideal para aplicações IoT necessita tratar aspectos voltados à muitos fatores, tais como: interoperabilidade, segurança, con abilidade, QoS , etc (KHAN et al., 2012).
Figura 3: Modelo arquitetural genérico para IoT (KHAN et al., 2012)
.
Compreendendo estes aspectos, um modelo genérico baseado em camadas é proposto por (KHAN et al., 2012) e ilustrado na Figura 3. Este modelo compreende cinco camadas com responsabilidades bem-de nidas: Percepção, Rede, Middleware, Aplicação e Negócio.
A camada de Percepção, que (BANDYOPADHYAY; SEN, 2011) considera como
"Ca-mada de Tecnologias de Borda", compreende todos os dispositivos físicos e sensores que objetivam coletar informações do contexto para as camadas superiores. A camada de Rede basicamente irá transferir as informações geradas pelos dispositivos sensores para os servi-ços de processamento, desta forma, ela é um intermediador entra a camada de Percepção e a de Middleware.
A camada de Middleware por sua vez, padroniza e gerencia os serviços oferecidos pelos dispositivos. Esta pode persistir os dados enviados a ela, bem como realizar processamen-tos e tomar decisões com base nestes. A camada de Aplicação fornece o gerenciamento dos serviços processados pela camada de Middleware, favorecendo o desenvolvimento de múltiplos cenários de aplicação (saúde, agricultura, transporte, negócios, etc.). Por m, a camada de Negócios gera meios de analisar os dados produzidos pelas camadas inferio-res através de recursos diversos que possam ser produzidos, tais como: grá cos, modelos, uxogramas, etc.
Outros modelos arquiteturais também são propostos, eles buscam enxergar o para-digma IoT através de SoA , e um dos modelos mais comuns utilizados é expressado por Li et al.(LI; XU; ZHAO, 2015), o referido autor acredita que modelos baseados em SoA
im-pactam diretamente na heterogeneidade de dispositivos presentes nos ecossistemas IoT. O modelo proposto é formado por 4 camadas de nidas da seguinte forma:
• Camada de Sensoriamento: todos os hardwares dotados de sensores pertencem a essa camada, e juntos proverão dados do mundo real para as próximas camadas. • Camada de Rede: camada responsável pelos componentes que manterão a
comu-nicação entre things.
• Camada de Serviço: camada responsável pela criação e gerenciamento dos serviços necessários para a aplicação e seus usuários.
• Camada de Interfaces: concentrará todos os mecanismos de interação da aplicação com seus usuários.
Tais modelos arquiteturais buscam adapatarem-se às necessidades de cada aplicação, por esta razão são considerados modelos genéricos.
2.1.3 Tecnologias envolvidas
Para atingir os objetivos pretendidos pelo paradigma de IoT, as arquiteturas pro-postam buscam integrar as inúmeras tecnologias desenvolvidas. Dentre essas, Lee (LEE; LEE, 2015) destaca as consideradas por ele como essenciais: Tecnologias de identi cação,
Dispositivos sensores, Middlewares e Computação na nuvem.
• Tecnologias de Identi cação: É basicamente composto por dispositivos capazes de identi car unicamente os objetos presentes na infraestrutura IoT. RFID possui de-masiado destaque nesse caso (LI; XU; ZHAO, 2015), sua estrutura é composta por um ou muitos leitor(es) e tags RFID. As tags são identi cadores únicos e geralmente estão associados a objetos na aplicação. Os leitores buscam constantemente por um sinal apropriado que é emitido pelas tags espalhadas no ambiente. Tal tecnologia é frequentemente utilizada em ambientes que possuem a necessidade de monitora-mento em tempo real (ATZORI; IERA; MORABITO, 2010). Outras abordagens são
utilizadas para a de nição de identi cadores únicos nos dispositivos conectados, Tiwary (TIWARY et al., 2018) destaca que endereços IPv4 e IPv6 são também
alter-nativas utilizadas como estratégias de identi cação.
• Dispositivos sensores: São dispositivos equipados com sensores autônomos que po-dem monitorar as condições físicas ou de ambiente (LEE; LEE, 2015). Estes sensores
são geralmente compostos por uma interface comum para manipulá-los, realizar processamentos unitários, além disso também são dotados de unidades tradutoras e fontes de energia (GUBBI et al., 2013).
• Middlewares: Representam camadas de softwares geralmente posicionadas na arqui-tetura de modo a facilitar a comunicação de componentes da aplicação, esta costuma ocultar detalhes irrelevantes ao ponto de vista do desenvolvedor (LEE; LEE, 2015). O
desenvolvimento de middlewares tem ganhado considerável crescimento face à ne-cessidade de facilitar o desenvolvimento de novos serviços e a integração de serviços novos e antigos. Para tal, arquiteturas orientadas a serviços (SOA) tem sido uma abordagem aconselhada para esta nalidade, pois permite a decomposição de siste-mas complexos e monolíticos em aplicações mais simples e dotadas de componentes bem-de nidos (ATZORI; IERA; MORABITO, 2010).
• Computação na nuvem: Representa um modelo computacional de acesso sob de-manda a recursos de con guração compartilhados (LEE; LEE, 2015). O uso da com-putação na nuvem nos direciona a uma abordagem orientada a recursos da internet,
de modo que possa lidar com a massiva quantidade de dados gerado pelos sensores da aplicação e possa conter recursos que concedam: capacidades de análises de da-dos, armazenamento escalável e capacidades de compartilhamento de dados em alto nível (GUBBI et al., 2013).
2.2 Constrained Application Protocol
CoAP surge como um dos protocolos de nível de aplicação mais amplamente conside-rados no tocante à "rede de coisas no contexto de IoT (RUTA et al., 2017). Ele representa
um padrão entre clientes e servidores provendo uma interface RESTful simpli cada, pois aplicações baseadas em IoT necessitam de protocolos mais leves devido à sobrecarga de tráfego de dados, capacidades energéticas e computacionais. Por esta razão, CoAP dis-ponibiliza uma interface baseada em REST para habilitar sensores e dispositivos de capacidades restritas a se comunicarem pela rede (SALMAN; JAIN, 2015).
O protocolo provê um modelo de interação requisição/resposta, suportando desco-berta de serviços e recursos, incluindo alguns conceitos da Web tais como URI , tipos de mídia, bem como busca ser interoperável com o HTTP (SHELBY; HARTKE; BORMANN,
2014). Dentre as características principais contempladas pela especi cação CoAP, Shelby (SHELBY; HARTKE; BORMANN, 2014) destaca as seguintes:
• Um protocolo WEB para requisitos de comunicações restritas M2M . • Baseado em UDP , suportando comunicação unicast e multicast. • Troca de mensagens assíncronas.
• Proxy simples e capacidades de caching.
Além das características supracitadas, CoAP de ne uma simples camada de mensa-gens para a retransmissão dos pacotes que possam perder-se no processo de transmissão, bem como disponibiliza quatro métodos de requisição similares ao HTTP: GET, PUT, POST e DELETE. Utiliza-se de apenas 4 bytes no cabeçalho seguido de opções, desta forma, requisições típicas costumam possuir de 10 a 20 bytes de tamanho (BORMANN; CASTELLANI; SHELBY, 2012).
A camada de mensagens do CoAP comporta 4 tipos básicos: Con rmable(CON), Non-con rmable(NON), Acknowledgement(ACK) e Reset(RST). Estas ocorrem de acordo com
Figura 4: Camada de mensagens do CoAP(SHELBY; HARTKE; BORMANN, 2014)
a situação da requisição e do retorno da entidade receptora (servidor). Uma mensagem Con rmable requer uma resposta (Acknowledgement) da entidade receptora devido à ser uma comunicação assíncrona. A entidade requisitante irá retransmitir a mensagem (Con rmable) até que a receptora a responda. No entanto, modelos de negócio que não requerem transmissões con áveis podem optar por enviar mensagens Non-con rmable, estas não requerem uma resposta do recebimento dos pacotes na entidade receptora, neste caso, quando ela não pode responder, uma mensagem Reset é gerada (SHELBY; HARTKE; BORMANN, 2014).
Figura 5: Implementação proposta para interoperabilidade entre HTTP e CoAP.(BORMANN; CASTELLANI; SHELBY, 2012)
CoAP e HTTP podem se comunicar plenamente, além de compartilhar as capacida-des inerentes às suas aplicações através da implementação de proxys ou intermediadores implementados sobre clientes. Uma arquitetura muito comumente usada é ilustrada na Figura 5. Neste caso, os intermediadores conversariam ambos os idiomas CoAP e HTTP sem a necessidade de conhecer requisitos especí cos de cada aplicação. Neste caso, não há sequer a necessidade de atualizar os intermediadores nos casos das aplicações envolvidas sofrerem modi cações (clientes ou servidores), tornando-os bem independentes. Esta
capa-cidade é possível devido às particularidades dos protocolos (códigos de resposta, métodos, etc.) serem similares (assim como demonstrado na Figura 5(b)), tornando o mapeamento de sua relação algo bem direto (BORMANN; CASTELLANI; SHELBY, 2012).
2.3 Universal Plug and Play
O UPnP foi desenvolvido pela Microsoft e pelo UPnP Fórum e de ne um conjunto de protocolos que permitem que dispositivos diversos à base de IP possam se conectar na rede. É uma solução para padronizar protocolos na internet e não está voltado a nenhum sistema operacional ou linguagem de programação especí ca (MESHKOVA et al., 2008).
No UPnP, dispositivos e serviços são descritos através de XML , e utilizam-se de um relevante número de protocolos que viabilizam a autocon guração local, reconhecimento na rede, descoberta, interação cliente/servidor, entre outras operações essenciais para seu funcionamento. Deste conjunto de protocolos, estão incluídos o Atuo-IP, SSDP (Sim-ple Service Discovery Protocol), SOAP (Sim(Sim-ple Object Access Protocol), GENA (General Event Noti cation Architecture), entre outros (ALLARD et al., 2003).
A arquitetura considera dois tipos de dispositivos: o dispositivo controlado e o ponto de controle. Dispositivos controlados são considerados os nós da rede que possuem servi-ços disponíveis, e os pontos de controle são dispositivos que podem descobrir dispositivos controlados na rede e utilizarem-se de seus serviços. Um dispositivo pode implementar qualquer um desses conceitos, e em alguns contextos pode possuir ambos (TOSCHI; CAM-POS; CUGNASCA, 2016). A sua proposta está direcionada à seis fases: Endereçamento,
Descoberta, Descrição, Controle, Eventos e Apresentação (SILVA et al., 2016). Cada fase
possui um objetivo especí co para tornar o UPnP um padrão interoperável. Tais fases foram explicadas por Lee (LEE; HELAL, 2002):
• Descoberta: A descoberta do UPnP é baseada em SSDP, desta forma, quando um dispositivo é adicionado na rede, ele imediatamente anuncia para os pontos de con-trole existentes, os serviços que possui. Este processo também ocorre quando um dispositivo (ponto de controle) deseja buscar algum serviço especí co na rede. • Descrição: Após a descoberta, os pontos de controle podem descobrir mais
infor-mações sobre o dispositivo encontrado na rede e suas capacidades através da URL oferecida pelo dispositivo na estrutura da mensagem de descoberta. A descrição é expressa em XML, e além das informações que o identi cam, também é possível
encontrar a lista de serviços disponíveis, estruturas para controle, eventos e apre-sentação.
• Controle: Um ponto de controle, depois de possuir conhecimento sobre um disposi-tivo e seus serviços, pode eventualmente enviar ações para um determinado serviço. As mensagens de controle são também expressas em XML utilizando SOAP, e estas ações podem ou não retornar valores.
• Eventos: O UPnP permite que pontos de controle possam inscrever-se em determina-das ações de serviços na rede, para serem noti cadetermina-das em caso destas ações alterarem suas variáveis de estado (estas que podem representar o estado do dispositivo). Desta forma, quando o dispositivo tem seu estado alterado, o mesmo publica a alteração no sistema de mensagens de evento que noti cará os dispositivos ouvintes. Todas as mensagens são expressas em XML através do GENA.
• Apresentação: Esta capacidade é permitida para que dispositivos consigam expor seu estado em navegadores, através de URLs representativas dos mesmos.
Figura 6: Fluxo de funcionamento básico do UPnP.(ARUNACHALAM; GANAPATHY, 2016)
Em um uxo básico de execução, após um ponto de controle descobrir um deter-minado dispositivo na rede (Descoberta), ele recupera então a URL disponibilizada pelo dispositivo (Descrição), já que o dispositivo possui através desta, além da descrição da sua identi cação, a descrição dos serviços que pode realizar. Para executar as ações (Controle) de qualquer serviço desse dispositivo, o ponto de controle recupera o serviço escolhido, e neste é possível identi car todas as ações e variáveis de estado necessárias para a execução desta ação, o uxo supracitado é ilustrado na Figura 6 (ARUNACHALAM; GANAPATHY,
2.4 Bluetooth
Bluetooth é um padrão baseado em comunicação sem o de dispositivos, projetado para comunicações de curto alcance. O padrão também é conhecido como IEEE 802.15.1 (LEE; SU; SHEN, 2007). Também é considerado uma tecnologia de baixo custo e está
presente em muitos dispositivos populares tais como Notebooks, telefones celulares, entre outros (CHLAMTAC; CONTI; LIU, 2003).
As especi cações do Bluetooth foram estabelecidas a partir de um consórcio de gran-des companhias da indústria tecnológica incluindo IBM, Microsoft, Motorola, Intel, entre outras(CHLAMTAC; CONTI; LIU, 2003). O protocolo é considerado uma tecnologia proe-minente para projetos de casas e cidades inteligentes, no entanto, ainda possui algumas limitações importantes a tratar, tais como a baixa taxa de dados, a descoberta ine ciente de dispositivos, o seu alcance limitado, interferências, etc (SALEM; NADEEM, 2018).
O ciclo de vida da comunicação Bluetooth ocorre em 5 passos: Escaneamento, StandBy, publicidade, iniciação e conexão. Os dois primeiros passos representam o processo de monitoramento passivo da pilha Bluetooth, a fase de publicidade é feita por um dispositivo para anunciar sua disponibilidade através do envio de um pacote especí co. Durante o processo de publicidade, um dispositivo no estado de iniciador ca aguardando este pacote para responder com um outro, que guarda informações especí cas para iniciar a comunicação e trocar os dados nessa mesma comunicação. Logo em seguida, o estado de conexão se mantém e os dispositivos começam a trocar suas informações (SALEM; NADEEM, 2018).
3 Revisão do Estado da Arte
Este capítulo descreve uma revisão literária que utilizará o método exploratório para conhecer as soluções oferecidas no estado da arte que simpli cam o processo de desenvol-vimento de aplicações baseadas em IoT. Também há a pretensão de conhecer os requisitos que estas soluções atingem bem como os desa os e oportunidades relatadas pelos pesqui-sadores. Desta forma, o objetivo deste capítulo é conhecer as tendências que existem no processo de desenvolvimento baseado em IoT, bem como o de explorar as soluções do estado da arte que objetivam a simpli cação do desenvolvimento de aplicações IoT.
A revisão a que este capítulo se propõe, foi conduzida de maneira exploratória, que segundo Zanella (ZANELLA, 2006), trata-se de uma pesquisa que tem como nalidade
acrescer o que se conhece de um determinado fenômeno. Desta maneira, a revisão utilizou a pesquisa exploratória sistematizando alguns aspectos, de modo a ampliar a organização do processo de pesquisa.
Este capítulo está organizado em 3 seções, a seção 3.1 trata da metodologia seguida na revisão do estado da arte, e é subdividida em 4 subseções: O planejamento, a string de busca, as fontes de pesquisa, a execução da revisão e o processo de seleção e a extração dos resultados. A seção 3.2 buscará remontar as questões de pesquisa visando respondê-las baseando-se nos resultados obtidos da execução da revisão, por m, a seção 3.3 discutirá tais resultados visando sintetizar e organizar o conhecimento obtido.
3.1 Metodologia
Esta seção descreverá todos os passos que foram seguidos para a realização da revisão do estado da arte, passos estes que foram sistematicamente divididos em planejamento, string de busca, fontes de dados, execução do protocolo, processo de seleção e por m, processo de extração dos resultados.
3.1.1 Planejamento
O processo de planejamento se propõe a de nir a nalidade da revisão do estado da arte. Desta forma, baseado no seu objetivo foram de nidas três questões de pesquisa (QP) norteadoras:
• QP1 - Quais os tipos de soluções e abordagens existentes para simpli cação do desenvolvimento de aplicações IoT?
• QP2 - Quais requisitos são endereçados pelas soluções identi cadas?
• QP3 - Quais são os desa os e oportunidades para desenvolver soluções que simpli- quem o desenvolvimento de aplicações IoT?
3.1.2 String de Busca
A de nição da string de busca foi baseada nos objetivos da revisão do estado da arte e utilizou-se de termos constituintes que buscassem re nar os resultados, tais termos combinados resultaram na seguinte string:
("IoT OR "Internet of Things") AND ("Framework OR "API ") AND ("Develop-ment AND ("Easing OR "Enabling OR "Easy OR "Enable")))
3.1.3 Fontes de Busca
Para a obtenção dos trabalhos realizados no estado da arte, uma busca foi realizada no repositório Scopus da Elsevier, este é responsável por indexar os repositórios mais importantes e relevantes da computação e engenharia (Vide Tabela 1). Devido a seu grau de importância, os artigos retornados possuem alta probabilidade de relevância para a revisão.
Tabela 1: Repositórios de Busca
Fonte Endereço
IEEExplorer http://ieeexplorer.ieee.org ACM Digital http://dl.acm.org
Science Direct http://www.sciencedirect.com Web of Science http://webofknowledge.com Springer http://link.springer.com
3.1.4 Execução da Revisão
Uma vez de nidos a string de busca e as fontes de pesquisa, o processo de execução buscou utilizar tais elementos para retornar os trabalhos que pudessem ser relevantes para as questões levantadas na fase de planejamento. Desta forma, a string foi executada no repositório Scopus da Elsevier e todos os artigos que não estavam disponibilizados gratui-tamente ou que não fossem escritos em inglês foram descartados. Trabalhos considerados capítulos de livros e tutoriais também foram desconsiderados.
A execução desta fase resultou em um total de 163 artigos que foram dispostos em uma planilha e indexados para um maior controle, destes, 17 foram desconsiderados por tratarem-se de capítulos de livro, tutoriais, ou não possuíam relação com as questões planejadas na seção 3.1.1. Sendo assim, apenas 146 artigos foram considerados para a fase de seleção.
3.1.5 Processo de Seleção
O processo de seleção trata-se de um re namento dos resultados primários obtidos na execução da string nos repositórios de busca. Este processo visa descartar todos os artigos que não respondem as questões de pesquisa propostas na fase de planejamento ou não se enquadram de algum modo no objetivo da revisão.
O resultado da execução, assim como evidenciado na subseção anterior, retornou 146 trabalhos válidos que foram lidos pelo autor deste trabalho no período de dois meses, entre Novembro e Dezembro. Essa etapa foi dividida em três iterações: A primeira foi a leitura dos títulos, resumos e palavras chaves, os artigos que não foram excluídos nesta fase passaram por uma segunda iteração de leitura que compreendia a introdução e a conclusão dos mesmos, os aprovados, passaram por uma leitura completa, sendo esta a última iteração. Os resultados deste processo são explicitados na Tabela 2.
Tabela 2: Iteração de Leituras
Fase Leitura Qtd. de Artigos
1o Fase Títulos, resumos e palavras-chave 146 2a Fase Introdução e Conclusão 63
3.1.6 Extração dos Resultados
O processo de extração foi realizado nos artigos que passaram da 3a fase (Leitura Completa) na fase de seleção. Todos os artigos desta fase foram adicionados a uma planilha do Google que foi preenchida com base nas leituras de cada artigo com dados que pudessem facilitar uma análise mais detalhada dos resultados. A planilha está disponível através do endereço: https://goo.gl/Koaykx
3.2 Resultados
Esta seção discute os resultados que foram extraídos da execução do protocolo da revisão do estado da arte proposto nos capítulos anteriores visando responder as questões de pesquisa que foram elaboradas na subseção 3.1.1.
Figura 7: Fontes de Dados
Assim como mencionado no processo de seleção, descrito na subseção 3.1.5, 30 artigos foram analisados inteiramente e algumas informações pertinentes puderam ser quanti -cadas. Dentre elas, pode-se observar que 58,1% dos artigos de interesse foram publicados em conferências, seguidos de 41,9% publicados em Journals (Vide Figura 8). Também é possível perceber através da Figura 7 que a grande maioria dos artigos de interesse bus-cados nas fontes de dados descritas na subseção 3.1.3 foram encontrados na IEEExplorer (61,3%) seguidos da Springer (19,4%), e Elsevier (9,7%).
A Figura 9 ilustra que a área de pesquisa de interesse desta revisão encontra-se estável quanto ao número de publicações que vinha crescente desde 2014(6) até 2016(8). O fato de apenas 7 artigos serem selecionados como pertinentes à revisão no ano de 2017 não
Figura 8: Veículos de Publicação
representa qualquer queda no número de publicações gerais voltadas à área de pesquisa, visto que os artigos foram buscados em Novembro, podendo haver novas publicações até o m do referido ano.
Figura 9: Número de publicações por ano
Após o levantamento prévio dos resultados obtidos do processo de execução, as ques-tões elaboradas na fase de planejamento foram respondidas fundamentado-se nas leituras consideradas na fase de seleção desta revisão.
3.2.1 Análise da QP1
A QP1 desta revisão, tem como objetivo encontrar no estado da arte, os tipos de soluções e abordagens, ou metodologias que visem simpli car ou facilitar o processo de desenvolvimento de aplicações IoT.
Figura 10: Tipos de soluções encontradas
No sentido de atingir o objetivo desta questão, as leituras mostraram-se promissoras e dos 30 trabalhos que foram analisados por completo, 28 retornaram soluções que visam facilitar alguma especi dade do desenvolvimento de aplicações IoT. Contudo, algumas soluções visam cenários bem especí cos e geralmente atingem requisitos isolados, sem preocuparem-se com a totalidade do desenvolvimento.
A Figura 10 ilustra os tipos de soluções que foram retornadas pelos artigos lidos, das soluções propostas, a maioria (50,0%) concentra-se em oferecer Frameworks com a nalidade de auxiliar o processo de desenvolvimento de ambientes IoT, seguidos de 23,3% das propostas que objetivam oferecer Plataformas como solução, 13,3% voltadas à soluções MDD (Model Driven Development), por m, uma proposta de arquitetura (3,3%). Alguns trabalhos não especi caram a solução, ou simplesmente não ofereceram nenhuma solução para os problemas abordados em suas pesquisas, eles foram categorizados na Figura 10 como "Não Especi cados e representam 10% das soluções, num total de 3 trabalhos.
Dentre os trabalhos destacados, foi possível observar que há uma tendência na adoção das várias abordagens focadas na simpli cação do desenvolvimento IoT, elas representam as estratégias que foram adotadas pelos autores em suas soluções. As abordagens foram categorizadas na Figura 11, demonstrando que as mais adotadas pelas soluções encontra-das são as de Abstração (40%), API's de Serviços (13,3%) e Nuvem (10%). Uma boa parte dos trabalhos revisados não especi caram a abordagem (26,7%) que utilizaram em suas soluções.
As abordagens consideradas como Abstração compreendem técnicas que buscam abs-trair recursos dos cenários de IoT, virtualizando-os, tornando-os legíveis, padronizados, e que podem ou não utilizar recursos de programação. Os exemplos considerados são:
Figura 11: Abordagens mais utilizadas
Anotações semânticas, geradores de código, representações grá cas, etc. A abordagem de nida como API de Serviços compreendem as estratégias que utilizam padrões REST e/ou CoAP em suas comunicações.
As demais abordagens categorizadas como Nuvem, Prototipação, e Integração Mobile focam suas soluções respectivamente, buscando integrar suas estratégias com recursos na nuvem através de plataformas especí cas, utilizam recursos grá cos e modelos para prototipar cenários de IoT prévio ao desenvolvimento, visando um planejamento detalhado e preciso, e por m, estratégias voltadas a utilizarem os dispositivos móveis como recursos de borda, ou dispositivos sensores pertencentes à aplicação.
3.2.2 Análise da QP2
A QP2 desta revisão tem como objetivo identi car nas soluções propostas pelos au-tores quais requisitos foram atingidos por suas propostas.
As leituras evidenciaram muitos requisitos que os autores destacaram como sendo críticos no processo de desenvolvimento e implantação de aplicações IoT. Algumas soluções atendem a mais de um requisito, contudo, a grande maioria concentra-se em requisitos isolados, criando meio de solucioná-los e simpli car o desenvolvimento que o afeta.
A Figura 12 representa os requisitos que foram abordados pelos trabalhos analisa-dos. É possível observar que a grande maioria das propostas lidam com interoperabili-dade (36,7%), tal requisito representa a capaciinteroperabili-dade dos dispositivos comunicarem-se de maneira padronizada uns com os outros, o requisito é citado como sendo um dos mais importantes da área de IoT, seguidos de heterogeneidade (13,3%), que está geralmente
Figura 12: Requisitos atingidos pelas propostas
associado ao massivo número de dispositivos com capacidades distintas de comunicação, processamento, armazenamento, e de serviços. Como terceiro maior requisito atingido, es-tão as propostas que focam em múltiplos requisitos, buscando atender a todos em alguma escala, objetivando atingir uma maior facilidade de desenvolvimento (10%).
Os dados levantados fortalecem os apontamentos considerados por Tayur e Suchithra (TAYUR; SUCHITHRA, 2017) que trata a interoperabilidade como sendo um dos desa os
mais críticos do cenário IoT. As discussões centrais do trabalho de Tayur e Suchithra (TAYUR; SUCHITHRA, 2017) direcionam-se à união das abordagens sugeridas no estado da
arte, pois o mesmo acredita que devido a grande variedade de protocolos existentes que consequentemente conduziu alianças fornecedoras a buscarem soluções diversas para pro-blemas similares, criou-se certa incompatibilidade entre as soluções desenvolvidas. Dentre as soluções citadas pelo autor estão o AllJoyn e o oneM2M (M3 Framework).
O trabalho de Data e Bonnet (DATTA; BONNET, 2016), propõe um framework
mo-dularizado, denominado DataTweet, cujo objetivo é a simpli cação do processo de de-senvolvimento de aplicações IoT. Embora tenha voltado seu foco para o requisito de produtividade, os autores também citam limitações, do ponto de vista dos requisitos, que são muito comuns em aplicações descritas na literatura. Dentre os requisitos citados destacam-se: interoperabilidade, modularização, segurança, dentre outras. O trabalho do autor supracitado foi tratado como produtividade visto que os requisitos elencados pelo mesmo são endereçados de maneira coletiva e integrados para se atingir a produtividade. Um outro requisito pouco explorado pela literatura selecionada nesta revisão foi a autonomia das "things", que na Figura 6 foi tratado apenas por Hernandez ( HERNÁN-DEZ; REIFF-MARGANIEC, 2016) junto ao requisito de interoperabilidade. Seu trabalho
centralizou sua proposta em que objetos inteligentes constituintes do cenário deveriam ter embutidos em si, engenharia baseada em autonomia, ou seja, cada dispositivo deve tomar decisões e modi car lógicas de aplicação de acordo com as entradas capturadas.
Uma síntese das soluções exploradas nesta questão e os requisitos atingidos pelas mesmas podem ser visualizadas no Apêndice A deste trabalho.
3.2.3 Análise da QP3
A QP3 desta revisão tem como objetivo identi car as oportunidades e desa os que foram expostos nas leituras realizadas. Para tal, foram observados os trabalhos futuros e limitações que foram expostos pelos autores.
Para esta questão, as leituras não foram tão promissoras, pois boa parte dos trabalhos não apresentaram desa os, limitações ou possíveis oportunidades de seus experimentos e estudos (71% dos trabalhos). A maioria foca apenas nas características das soluções e nos casos de uso. É importante salientar que os trabalhos revisados não especi cam bem o que são desa os e oportunidades, visto que alguns desa os são considerados potenciais oportunidades que podem bene ciar o contexto das aplicações IoT.
Dos casos que abordaram algum desa o e/ou oportunidade no desenvolvimento de sua pesquisa e nos experimentos abordados, destacam-se as propostas de Mehta (MEHTA et al., 2017), Patel (PATEL; CASSOU, 2015) e Nastic (NASTIC; TRUONG; DUSTDAR, 2015) que
colocaram como características desa adoras a adaptação e adição de recursos em tempo real nos cenários (aplicações), sem a necessidade de atualização ou recompilação da apli-cação, estas características são tratadas por Nastic (NASTIC; TRUONG; DUSTDAR, 2015)
como adaptabilidade, consideradas comuns nestes cenários. O trabalho de Patel (PATEL; CASSOU, 2015) ainda enfatiza questões problemáticas voltadas à metodologias de teste
em aplicações IoT, que embora sejam necessárias, encontram-se escassas na literatura. Os desa os elencados por Venckauskas (VENKAUSKAS et al., 2016) e Paganelli ( PA-GANELLI; TURCHI; GIULI, 2016), são voltados especi camente para as soluções propostas
pelos mesmos, visando otimizar o uso de suas linguagens modelo, estender seus experi-mentos para lidarem com múltiplos domínios e diminuir a complexidade de automação que suas soluções oferecem.
Em resumo, os desa os e oportunidades que o cenário de desenvolvimento de aplica-ções IoT oferece, partindo da análise da literatura retornada na execução desta revisão foram os seguintes:
• Adaptabilidade: Capacidade das aplicações adicionarem novos recursos sem a ne-cessidade de recompilação.
• Metodologias de Teste: Metodologias ou ferramentas capazes de diminuir as potenciais falhas de aplicações IoT.
• Aplicações de múltiplos domínios: A literatura é forte em domínios especí cos e voltados à tecnologias isoladas, ocorrendo assim a necessidade de aplicações que se adaptem à múltiplos domínios e tecnologias.
• Diminuição da complexidade: Devido à aplicações IoT demandarem múltiplos conhecimentos (desenvolvimento de software, sensores, infraestrutura, etc), é desa- ador a existência de uma ferramenta que abstraia as complexidades voltadas aos recursos de suas aplicações, tais como sensores, gerenciamento de energia, etc.
3.3 Discussões
Esta sessão tem como objetivo fazer uma análise dos resultados atingidos por esta revisão, buscando sintetizar os conhecimentos e tendências observadas nas respostas das QPs.
Figura 13: Objetivos das soluções encontradas
Foi possível observar através de uma análise mais geral, que a grande maioria dos trabalhos, embora possuam abordagens facilitadoras, estão focados de maneira bem es-pecí ca em requisitos isolados. A Figura 13 ilustra que 83,3% dos trabalhos possuem essa característica, em um total de 25 trabalhos. Sendo assim, eles não mencionam quaisquer estratégias de integrar os desa os do cenário de IoT. Desta forma, apenas 10,0% estão
focados em atingir os múltiplos requisitos das aplicações IoT, o termo "múltiplos não implica dizer que tratam de todos os requisitos desejáveis das aplicações IoT, mas que objetivam atingir mais de um requisito e os integra em uma mesma aplicação.
Embora as estratégias isoladas apresentem soluções e cazes para os requisitos que estão endereçados, para que haja uma real contribuição no sentido de atingir a totalidade das aplicações IoT, acreditamos que seja necessário buscar uma estratégia integradora onde a maior parte dos requisitos necessários possam ser atingidos e integrem-se nas so-luções propostas. A literatura tem demonstrado que tais soso-luções isoladas de requisitos geralmente não são compatíveis com outras soluções também isoladas, e essa heterogenei-dade não é algo interessante para o avanço no sentido de alcançar a plenitude de aplicações IoT. Tais apontamentos são também evidenciados por Tayur (TAYUR; SUCHITHRA, 2017)
em suas análises mencionadas na seção 3.2.2.
Pode-se observar no trabalho de Carranza (CARRANZA-GARCÍA et al., 2016), uma
abordagem promissora voltada a tornar os serviços da aplicação IoT parte da nuvem, embora a solução seja interessante, os aspectos voltados a escalabilidade e latência, que são comuns em sistemas distribuídos desta natureza não são citados no trabalho. Já a proposta de Datta (DATTA; BONNET, 2016) objetiva um framework muito promissor
no sentido de produtividade e simplicidade do desenvolvimento, o desacoplamento das funções básicas de IoT com a lógica da aplicação possui um característica muito relevante no sentido de tornar a aplicação modular, mas a descrição do framework é muito super cial quanto à aplicabilidade técnica efetiva, pois omite detalhes técnicos que são importantes, tais como: A associação dos dispositivos/serviços físicos à CSE (Common Service Entity), e todas estas questões fazem com que a proposta possua uma abordagem dotada de pouca praticidade.
Algumas propostas apresentam soluções MDD bem interessantes do ponto de vista prático, porém, acreditamos que tais abordagens di cultam em alguns aspectos o de-senvolvimento de tais soluções. Destacam-se as exploradas por Pal (PAL; MUKHERJEE; BALAMURALIDHAR, 2015) que embora apresente um modelo arquiteturalmente rico, não
demonstra detalhes de como os dispositivos poderão trabalhar com os modelos, e Patel (PATEL; CASSOU, 2015), que introduz uma linguagem própria para a criação dos modelos,
denominada "Srijan Vocabulary", que exigiria certa familiaridade do desenvolvedor com tal linguagem, neste caso especí co, acreditamos que o uso de linguagens mais populares e aceitas pela comunidade sejam mais promissoras, tais como XML ou JSON.
adotadas pela comunidade de desenvolvimento para aplicações IoT, os frameworks em sua maioria não são direcionados à tecnologias especí cas ou descrevem dialetos próprios para o desenvolvimento, os trabalhos revisados apresentam mais detalhes de nível arquitetural e uxos de execução bem especí cos, e geralmente os protótipos buscam poupar detalhes técnicos que podiam ser relevantes para análises e validações mais precisas.
Acreditamos que exista a necessidade de uma ferramenta que utilize a expertise dos desenvolvedores para lidar com aplicações voltadas a IoT. Além da própria popularidade de certas tecnologias aceitas, o conhecimento do desenvolvedor aceleraria o processo de desenvolvimento de maneira signi cativa.
A literatura explorada pela revisão pouco abordou soluções voltadas à representa-ção programática desses dispositivos, em outra palavras, sensores, atuadores, e quaisquer componentes constituintes da aplicação poderem ser representados como classes e objetos. Desta forma, a aplicação poderia utilizar-se de métodos próprios de linguagens conhecidas para seu gerenciamento, de maneira que toda a semântica inerente a cada componente pudesse ser abstraída por essas classes, e o desenvolvedor focasse apenas no conhecimento que detém da linguagem ou tecnologias utilitárias utilizadas.
Tal abordagem considera a representação programática de dispositivos como uma das etapas do desenvolvimento de aplicações desta natureza. Sendo assim, cada objeto repre-sentando um dispositivo, conteria os serviços, descrições básicas, identi cação e outras informações que pudessem ser relevantes e acessíveis por métodos ou classes de gerencia-mento.
Um dos trabalhos que buscaram tal abordagem foi o desenvolvido por Bocchino ( BOC-CHINO; FEDOR; PETRACCA, 2015), muito embora sua abordagem acabou omitindo
deta-lhes importantes tais como: o processo de associação dos dispositivos com o framework, e também o fato da utilização de funções básicas dos dispositivos junto da lógica de aplica-ção apresentar um forte acoplamento que pode ser visto como algo prejudicial do ponto de vista da manutenabilidade e extensibilidade da aplicação.
Desta forma, acreditamos que soluções que abordam uma separação de responsabili-dades, similar à exigida por Patel (PATEL; CASSOU, 2015), mas que abstraia de maneira
explícita os dispositivos que estão contidos na aplicação pode ser considerada promissora. Tal abordagem não pouparia detalhes técnicos relevantes voltados ao funcionamento real da solução. Tais soluções devem também buscar estratégias de resolução de requisitos críticos de heterogeneidade e interoperabilidade, e utilizar-se de padrões e tecnologias que aproveitem a expertise dos desenvolvedores, facilitando assim, o processo de
4 Um framework para facilitar o
desenvolvimento de aplicações
baseadas em IoT
O processo de desenvolvimento de aplicações baseadas IoT é caracterizado por um conjunto de múltiplas habilidades combinadas, que estão voltadas a domínios bem especí- cos, a citar: infraestrutura, programação, sistemas embarcados, protocolos de comunica-ção, serviços especí cos, etc (PATEL; CASSOU, 2015). Tal natureza multi-disciplinar e
he-terogênea desencadeia demasiada complexidade e demorado processo de desenvolvimento para lidar em conjunto com todos estes aspectos, surgindo a necessidade de metodolo-gias e ferramentas que possam sanar limitações que são consequentemente criadas destas características (PATEL; CASSOU, 2015).
Desta forma, o desenvolvedor destas aplicações necessitará focar em múltiplos conhe-cimentos para o processo de desenvolvimento, pois cada dispositivo pode adotar alguma especi dade técnica que exigirá do desenvolvedor técnicas complexas para lidar colaborati-vamente com esse conjunto de dispositivos. Os aspectos heterogêneos observados incluem suas capacidades (sensores de umidade, temperatura, luminosidade, etc.), comunicação (Bluetooth, ZigBee, Wi- ), representação de dados (PERERA et al., 2014), ou qualquer
outra característica que possa ser exclusiva ao mesmo, exigindo demasiado esforço para torná-los comunicáveis entre si e aptos a operarem um contexto de aplicação IoT.
O capítulo anterior apresentou uma revisão exploratória na qual pode-se ter conheci-mento do atual estado da arte no tocante à ferramentas facilitadoras no desenvolviconheci-mento de aplicações IoT. Desta forma, constatou-se como um dos grandes desa os, a existência de ferramentas que pudessem reduzir a complexidade de desenvolvimento inerente à apli-cações IoT. Além disso, também foi possível identi car que uma considerável parte das soluções são frameworks que utilizam estratégias baseadas em abstração de dispositivos para várias formas de representação (Modelos, Serviços, Grá cos, etc.), sendo tais escolhas consideradas, a partir da análise da revisão, ideiais para o problema em questão.
Sendo assim, a notável necessidade de ferramentas que possam reduzir a complexidade do desenvolvimento destas aplicações, abstraindo a heterogeneidade comum supracitada, motivou e direcionou a presente proposta. Nossa proposta poderá, nesse ínterim, realizar etapas essenciais como descoberta dos dispositivos na rede e comunicação entre eles sem necessidade de preocupar-se com especi cidades funcionais de cada tipo de dispositivo.
O objetivo do framework proposto neste trabalho é de facilitar o processo de desen-volvimento de aplicações baseadas em IoT. Ele buscará abstrair a heterogeneidade co-mum dos dispositivos existentes, favorecendo um ambiente em que o desenvolvedor possa apenas focar no desenvolvimento da lógica de aplicação, desconsiderando conhecimentos especí cos da cada tipo de dispositivo.
Como um passo importante para a realização dessa proposta, a virtualização dos dis-positivos que estão envolvidos na solução IoT é essencial. Ela garantirá certa harmonização e facilidade de comunicação entre as entidades, representando-as através de procedimentos e abordagens uni cadas e consequentemente mais simples (FERRERA et al., 2017). Através desta abordagem, capacidades necessárias à proposta, voltadas à comunicação e gerenci-amento de lógica de aplicação de forma simpli cada tornam-se passos menos complexos. Este capítulo está organizado em cinco sessões, a 4.1 discorre sobre o cenário motivador em que nossa proposta poderia ser utilizada, a 4.2 discorre sobre a arquitetura proposta para o framework, a 4.3 discorre sobre como os dispositivos se comunicarão com o auxílio do framework proposto, a 4.4, trata de descrever como o framework cará disposto de maneira operacional em uma possível aplicação. Por m, a 4.5 descreve como o framework foi desenvolvido, os procedimentos utilizados para instanciá-lo e estendê-lo.
4.1 Cenário de Exemplo: Controle de temperatura
Para exempli car a utilidade do framework que está sendo proposto por este traba-lho, um cenário típico que pode ser utilizado é de um cômodo, que possua um controle de temperatura. A sala seria composta por um sensor de temperatura que mediria a tem-peratura, e um termostato que regularia a temperatura do ambiente. Ambos possuiriam protocolos de comunicação distintos: O sensor é UPnP, e o termostato funcionaria à base de Bluetooth.
Os componentes envolvidos nesse cenário possuem protocolos e capacidades diferentes que di cultam sua comunicação. Para lidar com o sensor UPnP, será necessário descobri-lo na rede, conhecer seus serviços e ações, e enviar mensagens para suas variáveis de estado.
Figura 14: Aplicação IoT lidando com a heterogeneidade de Dispositivos.
Para o Bluetooth no entanto, será necessário consultar a rede, parear com o dispositivo escolhido, e após obter a conexão, transmitir os dados necessários, encerrando em seguida a conexão.
Para realizar tal operação, serão necessários dois módulos lógicos para lidar com cada um dos protocolos e suas especi cidades. Neste caso, cada módulo conterá o código ne-cessário (que deverá ser escrito pelo desenvolvedor) para atender às características e ar-quitetura de cada protocolo. O desenvolvedor precisará lidar com cada protocolo indivi-dualmente para que a aplicação alcance efetividade.
A Figura 14 ilustra o cenário supracitado: A aplicação solicita ao módulo UPnP os serviços disponíveis (1), esta por sua vez envia seus comandos de descoberta à pilha UPnP (2), e recebe dela os serviços disponíveis para informar à aplicação cliente. De posse dos serviços, a aplicação pode descobrir a temperatura (4), e receber do módulo um formato JSON contendo seu valor (6).
Após a veri cação do valor da temperatura, a aplicação identi cou que a mesma está acima do desejado, então inicia sua comunicação com o módulo Bluetooth (protocolo do atuador) para modi car o estado da temperatura. Para isso, é necessário obedecer os passos exigidos do protocolo: Buscar o termostato (7), ao encontrá-lo na rede, parear com o mesmo (9), de modo que o protocolo nos conceda uma conexão válida com o dispositivo para a comunicação, e en m enviarmos a temperatura adequada (11), que na solução exemplo é 20oC.
As operações necessárias executadas no exemplo, exigiriam demasiado esforço do pro-cesso de desenvolvimento, especialmente pela natureza heterogênea da aplicação. Desta forma, há a necessidade de compreender como cada dispositivo opera e quais são as suas capacidades de serviço, como são implementados, como podem ser acessados e
