UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA
CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO
DOUGLAS SANTOS DA SILVA VASCONCELOS
KNoT-Fog-Connector-AWS-IoT:
Uma biblioteca para conectar dispositivos da plataforma KNoT com a plataforma AWS
RECIFE 2019
DOUGLAS SANTOS DA SILVA VASCONCELOS
KNoT-Fog-Connector-AWS-IoT:
Uma biblioteca para conectar dispositivos da plataforma KNoT com a plataforma AWS
Monografia apresentada ao Centro de Informática (CIN) da Universidade Federal de Pernambuco (UFPE), como requisito parcial para conclusão do Curso de Engenharia da Computação.
Orientador: Prof. Dr. Kiev Gama.
RECIFE 2019
DOUGLAS SANTOS DA SILVA VASCONCELOS
KNoT-Fog-Connector-AWS-IoT:
Uma biblioteca para conectar dispositivos da plataforma KNoT com a plataforma AWS
Monografia submetida ao corpo docente da Universidade Federal de Pernambuco, defendida e aprovada em 5 de dezembro de 2019.
Recife, ___ de _____________ de 2019.
BANCA EXAMINADORA
___________________________________________
Prof. Dr. Kiev Gama
(Orientador)
Universidade Federal de Pernambuco
___________________________________________
Prof. Dr. Vinícius Cardoso Garcia
(Examinador)
Dedico esse trabalho a todos que colaboraram de alguma forma com o meu crescimento profissional e acadêmico.
AGRADECIMENTOS
Depois de uma longa jornada acadêmica, nada mais necessário do que agradecer a todos que me apoiaram e me incentivaram com esse sonho de realizar algo que eu amasse.
Agradeço a Deus por ter chegado onde estou hoje, à minha família por sempre ter me dado a base que precisei para alcançar meus objetivos.
Aos professores por terem passado seus conhecimentos e incentivado o meu crescimento.
Aos meus amigos de curso por terem compartilhado tristezas e alegrias de tantas cadeiras cursadas e noites viradas em projetos.
Aos meus amigos que me acompanharam de fora da universidade, me incentivando e apoiando.
A todos da equipe KNoT do CESAR, que sempre se mostraram disponíveis quando eu precisava, tirando dúvidas, opinando sobre o trabalho e sempre ajudando.
A todos que contribuíram com a escrita desse trabalho tirando um pouco de seu tempo para auxiliar, dando dicas, ajudando diretamente.
A mim mesmo, por ter chegado ao final do curso e ter conquistado o direito de concluir a graduação de Engenharia da Computação pelo Centro de Informática.
“Tempos difíceis não duram. Pessoas fortes duram.”
RESUMO
Com o avanço da tecnologia de internet das coisas, a criação de aplicações conectadas à internet que através de dispositivos inteligentes, sensores e atuadores, capturam dados e interagem com o meio onde estão inseridos, têm se tornado algo comum. Para atender aos requisitos demandados por essas aplicações como, comunicação segura e estável, armazenamento de dados e alta disponibilidade, plataformas de serviços para IoT vêm se aperfeiçoando de modo que novas funcionalidades são criadas e integradas com novas tecnologias para facilitar e agregar mais valor no desenvolvimento das aplicações. Embora existam muitas opções de plataformas, ainda existe o problema de heterogeneidade desses sistemas, pois não existe uma padronização para os diversos protocolos de comunicação disponíveis. Para minimizar esse problema a meta-plataforma para IoT, chamada KNoT, foi implementada, e esse trabalho tem como proposta a criação de uma biblioteca para realizar a integração entre a plataforma de serviços em nuvem para IoT oferecida pela Amazon com o protocolo de comunicação do KNoT, resultando no desenvolvimento de uma camada que abstrai os protocolos e processa a tradução das mensagens trocadas, entregando ao usuário final os dados já tratados.
Palavras-chave: Internet das Coisas. Plataforma de Serviços em Nuvem. Meta-plataforma
ABSTRACT
With the advancement of IoT technology, the creation of internet-connected applications that, through intelligent devices, sensors and actuators, capture data and interact with the environment in which they are inserted, has become commonplace. To meet the demands of these applications such as secure and stable communication, data storage, high availability, IoT service platforms have been improving so that new functionalities are created and integrated with new technologies to facilitate and add more value in development of applications. Although there are many platform options, there is still the problem of heterogeneity of these systems as there is no standardization for the various communication protocols available. To minimize this problem, the IoT meta-platform, called KNoT, was implemented, and this work aims to create a library to integrate Amazon's IoT cloud services platform with the IoT KNoT communication protocol, resulting in the development of a layer that abstracts protocols and processes the translation of exchanged messages, delivering to the end user the data already processed.
LISTA DE ILUSTRAÇÕES
Figura 1 – Diagrama de modelos de serviço com demonstração das atribuições de gestão de
cada modelo...19
Figura 2 – Relação de plataformas de IoT disponíveis no mercado...20
Figura 3 – Fluxograma de uma aplicação que utiliza AWS IoT...22
Figura 4 – Arquitetura e especificação de cada componente da meta-plataforma KNoT...24
Figura 5 – Arquiterura da KNoT-Cloud dividida em seus dois principais componentes...26
Figura 6 – Diagramação de blocos de arquitetura da FIWARE...27
Figura 7 – Visão geral da arquitetura destacando as contribuições ao KNoT...30
Figura 8 – Visão arquitetural dos componentes de comunicação do KNoT Fog...31
Figura 9 – Modelo utilizado para troca de mensagens entre plataformas...32
Figura 10 – Modelo de política de acesso utilizada para a aplicação criada no caso de uso...34
Figura 11 – Configurações para requisições HTTPS...35
Figura 12 – Variáveis para conexão via protocolo MQTT com o IoT Core...35
Figura 13 – Pseudocódigo do constructor...37
Figura 14 – Pseudocódigo do método start()...37
Figura 15 – Pseudocódigo do método addDevice()...38
Figura 16 – Pseudocódigo do método removeDevice()...38
Figura 17 – Pseudocódigo do método getDevice()...39
Figura 18 – Pseudocódigo do método listDevices()...39
Figura 19 – Pseudocódigo do método authDevice()...40
Figura 20 – Pseudocódigo do método publishData()...40
Figura 21 – Pseudocódigo do método updateSchema()...41
Figura 22 – Pseudocódigo do método onDataRequested()...42
Figura 23 – Pseudocódigo do método onDataUpdated()...42
Figura 24 – Pseudocódigo do método onDisconnected()...43
Figura 25 – Pseudocódigo do método onReconnected()...43
Figura 26 – Pseudocódigo do método onDeviceUnregistered()...44
Figura 27 – Fluxograma dos passos realizados nos testes...46
LISTA DE QUADROS
LISTA DE ABREVIATURAS E SIGLAS
Sigla Significado
IoT Internet of Things
KNoT Knot Network of Things
AWS Amazon Web Services
GCP Google Cloud Platform
NIST National Institute of Standard and Technologies API Application Program Interface
MQTT Message Queuing Telemetry Transport REST Representational State Transfer
HTTPS Hyper Text Trasfer Protocol Secure
SDK Software Development Kit
TLS Transport Layer Security
knotd KNoT Device Manager
JSON JavaScript Object Notation
SUMÁRIO
1 INTRODUÇÃO ... 13 1.1 CONTEXTO E MOTIVAÇÃO ... 13 1.2 OBJETIVOS ... 15 1.3 ESTRUTURA DO DOCUMENTO ... 15 2 CONCEITOS BÁSICOS ... 17 2.1 COMPUTAÇÃO EM NUVEM ... 17 2.2 PLATAFORMAS IoT ... 19 2.3 AWS IoT ... 20 2.4 KNoT ... 22 3 TRABALHOS CORRELATOS ... 25 3.1 KNoT-CLOUD ... 255 3.2 KNoT-FI ... 26 3.3 DISCUSSÃO...27 4 AMBIENTE KNoT-AWS-IoT ... 29 4.1 PROPOSTA ... 29 4.2 ESTRATÉGIA ... 30 4.3 IMPLEMENTAÇÃO ... 32 5 CASO DE USO ... 45 5.1 SIMULAÇÃO ... 45 5.2 DISCUSSÃO ...47 6 CONCLUSÃO ... 49 6.1 DIFICULDADES ENCONTRADAS ... 49 6.2 TRABALHOS FUTUROS ... 5013
1 INTRODUÇÃO
1.1 CONTEXTO E MOTIVAÇÃO
Um dos termos dentre os mais falados na área de tecnologia da informação nos dias atuais é o de internet das coisas, que tem sua origem do termo em inglês Internet of Things (IoT). De acordo com a empresa de tecnologia Amazon, uma das maiores do mundo na área, a definição para o objetivo do IoT pode ser descrita como "conectar coisas, animadas ou inanimadas, à internet com identificadores exclusivos que oferecem contexto, o que proporciona visibilidade à rede, aos dispositivos e ao ambiente. [1]". Com a tecnologia de IoT cada vez mais integrada ao nosso dia a dia, termos como cidades inteligentes, casas conectadas e carros inteligentes, que antes eram conceitos bastante futurísticos, vêm se tornando cada vez mais viáveis e irão passar a fazer parte de nossa vida.
A tecnologia de internet das coisas é bastante inovadora pelo fato de permitir que qualquer objeto com possibilidade de fornecer dados, através de sensores, conectados com a internet, possam processar essas informações e serem capazes de gerar valor, permitindo que decisões sejam tomadas com base nos dados coletados. Projeções estimam que em 2020 a quantidade de equipamentos conectados com a internet, irá crescer de forma exponencial e irá chegar aos 50 bilhões de dispositivos [2] sendo maior que o número de pessoas no mundo.
O potencial da internet das coisas pode crescer ainda mais devido a possibilidade dela se unir com outras tecnologias que também estão entre as mais atuais, como big data [3] e inteligência artificial [4]. No âmbito industrial, IoT demonstra ter um enorme potencial na criação de produtos e serviços que geram receita [5], o que pode criar um grande impacto no crescimento econômico do mundo todo [6]. Além da indústria, diversas outras áreas de escala maior como agricultura, saúde, educação e transporte, que têm potencial, estão cada vez mais se tornando adequas com as redes de dispositivos inteligentes.
Projetos que utilizam dispositivos IoT, muitas vezes têm que se restringir às limitações técnicas inerentes aos componentes e às especificações, como por exemplo, fonte de energia, tamanho do equipamento, tipo de comunicação, tipo do material e frequência de leitura de dados. Como objetos conectados costumam produzir uma grande massa de dados através da leitura dos variados tipos de sensores, a tarefa de realizar o processamento e armazenamento dessas informações é bastante limitada, se tratando apenas das capacidades do próprio dispositivo. O controle dessa quantidade de dados, é uma tarefa fundamental, fazendo com que seja necessário a utilização de uma estrutura de gerenciamento robusta [7], para isso a
14
computação em nuvem é considerada uma das melhores alternativas. Para o NIST (National Institute of Standard and Technologies), a definição para computação em nuvem é “um modelo para habilitar o acesso a uma coleção de recursos computacionais configuráveis através de uma rede de maneira ubíqua, conveniente e sob demanda” [8].
Os serviços em nuvem, além do armazenamento podem prover toda uma infraestrutura virtual de utilitários como serviços de monitoramento, ferramentas analíticas, plataformas de visualização de dados, dentre outros tipos diversos de serviços [9]. Várias plataformas de serviços em nuvem que possuem serviços voltados especificamente à tecnologia de IoT vêm surgindo no mercado [10], por exemplo a Meshblu [11], FIWARE [12], Google Cloud Platform (GCP) [13] e a Amazon Web Services (AWS) [14].
Ambas tecnologias, tanto IoT como serviços em nuvem, são tecnologias que se auto complementam, mesmo tendo sido criadas com propósitos tão diferentes. Para o lado da internet das coisas, os serviços em nuvem abrem várias possibilidades para suprir as limitações de hardware e processamento que possui, já para o lado da nuvem, a possibilidade de se criar novos serviços exploráveis que interajam ainda mais com os usuários utilizando os dispositivos conectados.
Mesmo havendo uma visível sinergia entre as tecnologias, ainda existe muita heterogeneidade nesse meio. Para as plataformas de serviços em nuvem, não existe um único modelo de comunicação, que faça com que seja fácil a mudança entre nuvens, caso um usuário deseje trocar uma aplicação de plataforma. Para cada plataforma que existe no mercado, pode haver uma forma diferente para estabelecer a comunicação, seja por um formato da mensagem diferente, ou pela utilização de chaves de acesso, varia de acordo com a arquitetura que a comunicação da plataforma foi projetada. Da mesma forma ocorre com a tecnologia de IoT, como existem várias plataformas de prototipação e desenvolvimento de aplicações, nem sempre é fácil migrar uma aplicação, devido aos requisitos técnicos, requisitos tanto de hardware como de software e à arquitetura de cada plataforma. Esse problema acaba fazendo com que aplicações sem muita flexibilidade sejam criadas. Para tentar mitigar esse problema, plataformas de middleware são uma proposta para gerir a conexão entre as plataformas de nuvem e IoT, criando funções canônicas que possam abstrair o protocolo de comunicação.
Uma das alternativas para plataformas de middleware que existem é o Knot Network of Things (KNoT), uma meta plataforma de internet das coisas de código aberto, que utiliza componentes tanto de software como de hardware, criada com o objetivo de diminuir a complexidade da criação de uma aplicação com IoT, desde a captura dos dados por sensores, o envio dessas informações para armazenamento em uma nuvem, até a disponibilização desses
15
dados para uma aplicação, oferecendo suporte de interoperabilidade entre os serviços, criada pelo o Centro de Estudos e Sistemas Avançados do Recife (CESAR) [15].
Entretanto, mesmo com o auxílio do KNoT para preencher essa lacuna e integrar ambos os lados, IoT e serviços em nuvem, ainda existe uma limitação que se refere à quantidade de plataformas na nuvem que a meta-plataforma oferece suporte. Atualmente o KNoT atende apenas a duas plataformas de nuvem, são a FIWARE e o KNoT-Cloud criado a partir da Meshblu, o que impossibilita ao usuário a utilização de outras plataformas que podem oferecer mais suporte na criação de aplicações, como é o caso da AWS IoT, serviço de nuvem voltado para IoT, criado pela plataforma AWS.
1.2 OBJETIVOS
Pensando em estudar os métodos de APIs e arquiteturas de serviços para realizar conexões entre plataformas heterogêneas, utilizando a meta plataforma de internet das coisas KNoT como camada de middleware, esse trabalho tem como objetivo geral:
Contribuir com a variedade de opções de plataformas de nuvem conectadas ao KNoT, de modo a atender as necessidades da comunidade através da criação da biblioteca KNoT-Fog-Connector-AWS-IoT, responsável por realizar a interpretação entre o protocolo da nuvem AWS IoT, e o componente de conexão do KNoT, presente no KNoT Gateway, denominado KNoT Fog Connector.
E como objetivos específicos:
• Realizar um estudo da plataforma KNoT e de sua arquitetura de comunicação • Realizar um estudo do serviço de IoT criado pela AWS
• Contribuir com a comunidade open-source através do KNoT
• Integrar a plataforma de nuvem AWS ao conector da plataforma KNoT • Criar a biblioteca KNoT-Fog-Connector-AWS-IoT
1.3 ESTRUTURA DO DOCUMENTO
Os próximos capítulos estão divididos em 3 partes, na primeira falaremos sobre a contextualização dos temas abordados no projeto, necessários para um bom entendimento do que será explanado nos capítulos seguintes. Na segunda etapa, é descrito como está o estado da
16
arte atualmente dentro do KNoT, como é realizado o acesso à nuvem e quais plataformas são atendidas. Na terceira parte teremos a descrição do projeto que foi elaborado para defesa desse trabalho, detalhando as principais partes do código desenvolvido, estratégias utilizadas e descrevendo um caso de uso. Ao final teremos uma conclusão sobre o projeto e uma sessão de possíveis trabalhos futuros, para desenvolvimento de novas features e melhorias.
17
2 CONCEITOS BÁSICOS
Neste capítulo, são introduzidos alguns termos e conceitos necessários para o entendimento desse trabalho, as abordagens serão dadas de forma objetiva, focando nos temas mais importantes.
O tema de computação em nuvem será abordado e a partir disso é possível mostrar como o conceito dessa tecnologia formou o conceito das plataformas em nuvem. Em seguida é mostrado o conceito de plataformas de IoT, tanto de hardware como de software e como as empresas provedoras de plataformas em nuvem estão criando serviços focados em IoT para atender a essa nova demanda. A plataforma de nuvem para IoT da Amazon, a AWS IoT Core. é mostrada no terceito tópico desse capítulo, sendo explicado como é seu funcionamento. Ao final do capítulo, é demonstrada a meta-plataforma open-source para internet das coisas KNoT e como ela foi projetada para criar essa ponte entre plataformas de hardware e plataformas de nuvem para IoT.
2.1 COMPUTAÇÃO EM NUVEM
A computação em nuvem nada mais é do que um modelo de computação ubíqua, que oferece um conjunto de serviços sob demanda, capazes de serem configurados, por meio de uma disponibilização ágil, da qual não é necessária muita interação com o usuário para o fornecimento dos serviços, segundo a definição do NIST. Esse modelo de computação em nuvem é definido como tendo cinco características e três padrões de disponibilização de serviços, esses últimos mostrados na Figura 1.
Características:
• Disponibilidade sob demanda: O usuário pode utilizar recursos computacionais como armazenamento aplicações, rede, a qualquer momento, sem ser necessária uma interação direta com o provedor.
• Acesso via internet: Os recursos devem estar disponíveis na internet e possíveis de serem acessados a partir de qualquer plataforma.
18
• Provisão de serviços por região: Provisão dos serviços de um provedor mais próximo ao usuário para reduzir problemas de latência, disponibilizando os serviços dinamicamente de acordo com a demanda, tornando o usuário mais independente.
• Elasticidade: Os recursos são providos de forma dinâmica e ágil, de forma automaticamente, para dar a sensação ao usuário de que os serviços são ilimitados e sempre disponíveis.
• Medição para otimização: Os serviços são medidos, de acordo com cada tipo, para que haja uma automatização no controle e otimização, levando em conta as demandas dos usuários.
Padrões de disponibilização:
• Infraestructure as a Service (IaaS): Nesse terceiro modelo, o usuário adquiri mais autonomia para implantar suas aplicações na nuvem, podento ter acesso a serviços de armazenamento, processamento, memória e outros recursos de forma limitada. Contudo, o usuário não consegue configurar a infraestrutura da nuvem, tendo um controle ainda restrito apenas ao que lhe é concedido.
• Platform as a Service (PaaS): Nesse segundo modelo, o usuário já tem um pouco mais de liberdade com a plataforma, mas não muita. Nele é possível implantar aplicações que foram criadas pelo usuário ou que ele adquiriu, onde a aplicação pode utilizar da infraestrutura dos serviços oferecidos pela plataforma, mas não é permitido, gerenciar ou configurar os recursos que a aplicação implantada utiliza.
• Software as a Service (SaaS): Nesse primeiro tipo de modelo, o usuário é capaz de utilizar aplicações que foram fundamentadas nos serviços de uma plataforma em nuvem, no entanto, não é permitido ao usuário, configurar ou gerenciar os serviços que são utilizados pela aplicação.
19
Figura 1 – Diagrama de modelos de serviço com demonstração das atribuições de gestão de cada modelo. Fonte: mycloudblog [16]
2.2 PLATAFORMAS IoT
As Plataformas de IoT são soluções de middleware que oferecem infraestrutura para diversos componentes, das mais variadas funções e complexidades, que utilizam sensores e atuadores para coletar dados e interagir com o meio, conectando-os à internet, de modo que os objetos possam gerar mais valor às suas finalidades. Essas plataformas são formadas por diferentes serviços, que se integrados, são capazes de criar soluções mais complexas e otimizadas. Os componentes podem envolver soluções tanto de hardware [17] como de software, podem ser de uso proprietário ou open-source, assim como podem ser placas de prototipação, componentes eletrônicos, serviços na nuvem, frameworks para linguagens computacionais, onde cada um desses componentes, compõem a plataforma num todo.
Como IoT é uma tecnologia em expansão, ainda apresenta muitas lacunas [18], no que diz respeito à plataforma. N nos últimos anos uma grande quantidade de novas tecnologias e serviços vêm surgindo para tentar preencher esses vãos, onde cada solução procura suprir uma ou mais necessidades específicas. Esse grande número de tecnologias acaba agregando positivamente para a plataforma e acelera o crescimento da comunidade como um todo.
A Figura 2 mostra uma lista com diversas empresas de variados segmentos, que já possuem ou estão desenvolvendo suas plataformas para IoT na nuvem, algumas delas open-source, com serviços abertos ao público e outras oferecendo um serviço pago, a relação das empresas mostradas na figura abaixo, foi feita com base nas plataformas disponíveis até o primeiro semestre de 2019.
20
Figura 2 – Relação de plataformas de IoT disponíveis no mercado. Fonte: tudosobreiot [19]
2.3 AWS IoT
AWS IoT é um serviço em nuvem, disponível na plataforma de nuvem da Amazon, a AWS, voltado especificamente para aplicações de IoT, que proporciona uma comunicação bidirecional e segura entre os dispositivos conectados e a nuvem. A plataforma ainda possibilita que ao utilizar da AWS IoT, o usuário possa usufruir de outros serviços da própria nuvem de forma que possa agregar às aplicações implantadas permitindo a criação de outras funcionalidades que consumam os dados coletados [20].
O serviço AWS IoT conta com os seguintes componentes:
• Message Broker: Componente responsável em prover um mecanismo robusto de gestão de troca de mensagens entre os dispositivos e as aplicações conectadas à AWS, utiliza uma comunicação baseada no paradigma Publish/Subscribe, com o protocolo MQTT, ou também podendo utilizar o protocolo MQTT por Websocket. Ainda existe a possibilidade de utilizar o protocolo HTTP com requisições REST para realizar requisições de dados.
• Mecanismo de regras: Esse componente pode habilitar através de regras, permissões a outros componentes e serviços de acordo com a demanda da aplicação.
21
• Serviço de segurança e identidade: Responsável pela criação de certificados de acesso para cada dispositivo, que devem ser utilizados para estabelecer a comunicação do dispositivo com a nuvem. Já no lado da nuvem, é fornecida uma camada de segurança responsável pelo Message Broker e pelo mecanismo de regras.
• Registro: Cria um registro único para cada dispositivo na nuvem, onde também é possível criar atributos e chaves que auxiliem na identificação e segurança de cada um deles.
• Device Shadow: É uma representação do estado atual de cada dispositivo, armazenada no formato de um JSON, utilizada para recuperar e atualizar as informações do dispositivo. Permite que aplicações possam consumir esses dados sem a necessidade de um acesso direto ao dispositivo a cada nova requisição.
• Serviço de provisionamento de dispositivos: Pode fornecer uma tripla de serviços, que representam as configurações iniciais dos dispositivos, são eles: um thing, um certificado e as políticas, representando respectivamente, o registro dos atributos do dispositivo, o certificado de autenticação do dispositivo na nuvem e as permissões de operações que o dispositivo pode realizar.
A Figura 3 mostra como é o fluxo de informações dentro da plataforma AWS IoT. Começando pelos devices, representados pela cor laranja na imagem, que serão programados e conectados com a plataforma através de um registro de identificação, após a realização do cadastro, a troca das mensagens desses devices com a o serviço AWS IoT, representado pela cor verde na imagem, é gerenciada pelo Message Broker, e em seguida acessando o componente Device Shadow, atualizando seus atributos correspondentes, todas ações realizadas conforme as políticas de acesso pré-configuradas e utilizando chaves de autenticação que garantem a confiabilidade, em seguida a aplicação pode utilizar os outros serviços da AWS, representados pela cor azul na imagem, como o Kinesis ou Lambdas, também de acordo com as suas permissões, no final as informações ficam disponíveis e podem ser consumidas por aplicações de visualização dos dados, aplicações representadas na imagem pela cor roxa.
22
Figura 3 – Fluxograma de uma aplicação que utiliza AWS IoT. Fonte: AWS IoT Guia do Desenvolvedor [21]
Ainda na Figura 3, a comunicação entre as caixas é representada por setas com traçado contínuo, já as setas com traçado pontilhado representam as requisições de segurança feitas internamente pelo serviço da plataforma, para realizar verificações das mensagens e que não precisam ser realizadas pelo usuário
2.4 KNoT
A meta-plataforma para internet das coisas que foi criada no CESAR, KNOT [22], surgiu com o propósito servir como um integrador entre plataformas tanto de hardware como de software, que são heterogêneas entre si, ou seja, não possuem um padrão de comunicação comum, possam realizar essa comunicação. Através da integração de plataformas open-source, o KNoT é capaz de realizar esse endereçamento, abstraindo várias camadas de protocolos de comunicação, permitindo que o usuário possa escolher qual plataforma deseja utilizar de acordo com as suas necessidades.
O KNoT possui uma arquitetura que é representada por três componentes principais, Thing, Gateway e a Cloud. O primeiro dos componentes, chamado de KNoT Thing, contém um microcontrolador capaz de realizar processamentos básicos e coletar dados dos sensores, assim como passar comandos para atuadores. Ele precisa estar ligado a uma fonte de energia para operar normalmente. Os dados lidos são enviados através de um módulo de rádio frequência (RF) para o segundo dispositivo.
O segundo componente é o KNoT Gateway, construído baseado no Buildroot [23], um projeto open-source para desenvolver sistemas Linux especializados para aplicações
23
embarcadas. A versão foi montada utilizando serviços Linux que permitem ao componente ter um maior poder de processamento dos dados, e além dos serviços já existentes, outros foram desenvolvidos para gerir os processos realizados pelo Gateway.
O Gateway é capaz de atender à vários Things, através de um módulo de comunicação de rádio frequência, que recebe as informações atuando como um hub [24], trocando informações com os diversos dispositivos conectados a ele por comunicação sem fio. Possui um módulo internet, que permite conectá-lo com a rede, onde irá transmitir os dados recebidos para a nuvem, assim como também pode receber comandos provindos de lá e transmiti-los aos Things, como um proxy. Dentro do Gateway, ainda há um outro componente menor, o KNoT Fog, ele atua como uma pequena instância da nuvem e pode armazenar os últimos dados lidos pelos Things, também é ele quem gerencia a conexão feita do Gateway com a nuvem. Como cada nuvem tem suas peculiaridades na comunicação, a Fog tem o papel importante de realizar essa tradução para cada plataforma. O principal componente interno do KNoT Gateway é o Gerenciador de Dispositivos do KNoT (knotd), que tem como papel gerenciar a comunicação entre os protocolos de rede dos dados que chegam ao Gateway com o KNoT Fog, se tornando o ponto central do componente.
O terceiro dispositivo, a Cloud, é uma plataforma em nuvem que através de um servidor fornece provisionamento de serviços como armazenamento dos dados, gestão das mensagens entre as aplicações e outros dispositivos que a consomem, entre outros serviços, para que a aplicação trabalhe com suas funções normais. A Cloud escolhida para a aplicação, deve ser configurada pela interface gráfica web do KNoT Gateway, essa chamada de knot-web, para que os parâmetros utilizados na comunicação como portas, certificados, hostnames entre outros, sejam setados para estabelecer a comunicação.
A meta-plataforma ainda conta com bibliotecas que se encarregam de fornecer acesso aos dados, por meio de uma comunicação entre nuvem e as aplicações finais, que são aplicações mobile ou páginas web, que consomem os dados. A arquitetura do KNoT pode ser visualizada através da Figura 4, a qual mostra através de um fluxograma como é feita a comunicação entre cada um dos três componentes, os Things representados pelos dispositivos comuns do nosso cotidiano, capazes de gerar dados, o gateway, intermediando a comunicação, e a cloud que pode ser escolhida pelo usuário, conectando com o gateway por meio da fog. Cada plataforma de nuvem tem suas peculiaridades, cabendo a biblioteca da fog, realizar essa tradução.
24
Figura 4 – Arquitetura e especificação de cada componente da meta-plataforma KNoT. Fonte: Site do KNoT [22]
Após o entendimento dos conceitos demonstrados nesse capítulo, é possível compreender a abordagem que é realizada para criação da biblioteca KNoT-Fog-Connector-AWS-IoT, criada para conectar a plataforma AWS com a plataforma KNoT, mas antes de se trabalhar mais em como foi contruída a lib, alguns trabalhos correlatos, são mostrados no capítulo seguinte, com o intuito de realizar uma comparação entre os serviços utilizados e como eles colaboraram para a elaboração da biblioteca.
25
3 TRABALHOS CORRELATOS
Nessa sessão são mostrados alguns trabalhos semelhantes que foram encontrados nas pesquisas. São abordados o KNoT-Cloud e o KNoT-FI, ambos componentes que utilizam serviços cloud-based. Ao final do capítulo é feita uma comparação entre os serviços prestados pelos componentes citados com o desenvolvido para esse trabalho, apontando os principais pontos que serviram de apoio para a construção da biblioteca e os pontos de fragilidade e como a solução propõe resolver esses problemas.
3.1 KNoT-CLOUD
Criado pelo CESAR, esse componente foi desenvolvido utilizando ferramentas de uma plataforma open-source, a Meshblu [25] por meio da qual, é possível criar uma camada de comunicação segura, utilizando um sistema baseado em nuvem, que integra diversos protocolos e permite a conexão com os dispositivos finais, objetos inteligentes e aplicações.
A arquitetura do sistema é dividida em duas partes principais, a dos micro-serviços e a das bibliotecas utilizadas por esses componentes. No lado dos micro-serviços, existe um componente encarregado de processar e gerenciar as mensagens, tanto as que são provindas dos objetos inteligentes, como as requisições que são enviados para eles. Esse gerenciador de mensagens por ser baseado em micro-serviços, proporciona uma maior escalabilidade e agilidade ao processo. Para armazenar os dados das mensagens, um banco de dados não relacional é utilizado, além disso, também existe uma interface gráfica que pode ser utilizada para gerenciar as aplicações e os dispositivos conectados à nuvem. Um outro componente chamado Autenticador mantém o controle da plataforma, identificando cada dado e dispositivo que passa pela plataforma. Para cuidar da comunicação entre os serviços principais e o SDK do KNoT-Cloud, responsável por se comunicar com as aplicações, um adaptador de protocolos que utiliza websocket, realiza a tradução dos comandos do SDK aos modelos de requisição utilizados na camada de serviços.
Na camada de bibliotecas, a complexidade dos serviços é abstraída através de APIs do SDK, tornando a experiência de uso mais fácil para o desenvolvedor que queira criar alguma aplicação e consumir os dados. Na Figura 5 podemos visualizar a arquitetura da plataforma.
26
Figura 5 – Arquiterura da KNoT-Cloud dividida em seus dois principais componentes. Fonte: What is KNoT-Cloud? [26]
3.2 KNoT-FI
O componente KNoT-FI [27], também desenvolvido pelo CESAR, é baseado no framework de código aberto da plataforma cloud-based, FIWARE [28]. Essa plataforma por sua vez, é composta por um conjunto de componentes também open-source, que auxiliam na realização das funcionalidades oferecidas, onde podem ser acessados via API.
O componente principal que caracteriza qualquer plataforma que utilize a FIWARE é o gerenciador de dados de contexto Orion Context Broker, esse componente é responsável por gerir dados que representam o estado atual dos dispositivos conectados à plataforma, sendo possível realizar por meio do Orion, ações de atualização, requisição e outras operações.
Em conjunto ao Context Broker, uma série de componentes complementam os serviços disponíveis na FIWARE, que são categorizados em três tipos e um adicional referente a deploy.
Na Figura 6 é mostrada a divisão em blocos da arquitetura interna à FIWARE.
• Interface com dispositivos IoT e sistemas terceiros • API de gerenciamento de dados
• Processamento, análise e visualização de dados de contexto • Implantação de aplicações
27
Figura 6 – Diagramação de blocos de arquitetura da FIWARE. Fonte: FIWARE Developers [29]
A integração entre o KNoT e a FIWARE, é feita por um conector específico para essa nuvem, chamado KNoT-Fog-Connector-FIWARE. No lado do KNoT, interno ao Gateway, para se comunicar diretamente com o componente de entrada da FIWARE, é responsável por realizar as traduções das mensagens e requisições, disponibilizando nos devidos formatos para que ambos os lados entendam e efetuem os processamentos.
No lado da FIWARE, o componente de entrada é chamado de IoT Agent, ele é responsável de repassar os dados para o componente principal, o Orion, e de cuidar de fatores de segurança da plataforma. A plataforma ainda conta com serviços adicionais que podem ser integrados nas soluções desenvolvidas, oferecendo funcionalidades de análise, processamento e visualização dos dados, através de bibliotecas e APIs.
3.3 DISCUSSÃO
Os trabalhos citados nos tópicos acima, após a análise e estudo, serviram de base para a construção da biblioteca proposta nesse trabalho. Os principais pontos em comum entre as bibliotecas que foram implementadas para a estabelecer conexão do KNoT com as plataformas FIWARE e KNoT-Cloud, que foram aproveitados na estruturação da biblioteca KNoT-Fog-Connector-AWS-IoT, foram as funções canônicas, referentes às funções de requisição de dados dos devices, chamadas pelo Connector base, em resposta às solicitações do Gateway, com seus devidos parâmetros e retornos, respeitando ao protocolo de comunicação AMQP e ao padrão
28
de mensagens estabelecido pelo KNoT. Já os pontos de melhoria que foram notados, foram abordados pela utilização da própria plataforma da Amazon e serão abordados no próximo capítulo que mostrará em mais detalhes a implementação da lib.
29
4 AMBIENTE KNoT-AWS-IoT
Este capítulo apresenta a visão geral da implementação realizada para a biblioteca KNoT-Fog-Connector-AWS-IoT. Na primeira sessão é discutida a proposta para qual a biblioteca foi criada. Na segunda sessão é descrita qual foi a estratégia utilizada para poder integrar as duas plataformas com protocolos diferentes. Na terceira sessão, é detalhado o funcionamento dos principais componentes do código através de pseudocódigos, a abordagem escolhida para desenvolver as funções canônicas que configuram a comunicação entre a cloud e a fog. Todo o código desenvolvido nesse trabalho está disponível no GitHub [30] para acesso livre da comunidade.
4.1 PROPOSTA
Nesse trabalho foi desenvolvida a biblioteca KNoT-Fog-Connector-AWS-IoT, que tem como propósito, conectar a meta plataforma de internet das coisas, KNoT, com a plataforma de nuvem para IoT provida pela Amazon, a AWS IoT Core, através da criação de serviços de tradução e processamento das mensagens fornecidas e providas aos protocolos de comunicação das plataformas, integrando os componentes. A biblioteca consegue agregar mais valor ao KNoT, por oferecer a possibilidade de conectar os dispositivos IoT à uma plataforma em nuvem que proporciona a implementação de diversas aplicações, que utilizem tecnologias de ponta como serviços de machine learning, inteligência artificial, big data, clusters para grandes processamentos de dados, entre outros serviços disponíveis.
Ao integrar a KNoT-Fog-Connector-AWS-IoT ao catálogo de libs do KNoT, há influência direta no aumento da comunidade de usuários da plataforma de IoT, através do engajamento, pois trata-se de uma das plataformas em nuvem mais bem aceitas no mercado, devido a sua documentação bem estruturada e ao seu serviço de suporte disponibilizado. A biblioteca foi implementada utilizando a linguagem JavaScript, pois é uma das linguagens com SDK disponível, dentre os oferecidos pela Amazon, e também pelo fato que o componente KNoT Fog Connector, é escrito em JavaScript, facilitando a integração entre o Connector específico e o Connector base. A lib foi estruturada pensando em exigir menos interação possível do usuário, no entanto, cabe a ele a tarefa de criar uma conta na plataforma da AWS, para poder criar uma instância do serviço AWS IoT.
30
Os componentes propostos desenvolvidos nesse trabalho estão em destaque azul na Figura 7. A biblioteca do Connector específica e a definição da configuração necessária na plataforma de nuvem da AWS IoT Core.
Figura 7 – Visão geral da arquitetura destacando as contribuições ao KNoT Fonte: Autoria própria.
4.2 ESTRATÉGIA
A arquitetura do KNoT foi elaborada baseada na à necessidade de modularizar os serviços e atribuir responsabilidades para cada componente, a fim de evitar sobrecargas de código. Com a possibilidade de cada vez mais plataformas se integrarem ao sistema, a estratégia consiste em ter um componente geral de conexão e pequenos componentes específicos atrelados ao geral, responsáveis por realizar a conexão com a plataforma escolhida se encarregando de manter o padrão de comunicação que atende aos requisitos tanto do KNoT como da plataforma em nuvem.
Essa interface de comunicação entre o KNoT e a plataforma de nuvem escolhida, a AWS, é feita no KNoT Fog, localizado no Gateway, por se tratar de um ponto centralizado na
31
plataforma, e pelo fato de que é o primeiro lugar onde se cria uma instância do objeto que contém o estado das informações dos Things, que são armazenados em cache para um acesso mais ágil quando necessário, se tornando o melhor lugar para realizar a conexão com a nuvem. O componente geral de conexão do sistema na Fog, o Fog Connector e os componentes específicos referidos, as libs implementadas para esse componente, podem ser visualizados através de um diagrama de blocos na Figura 8 que mostra a relação entre os componentes.
Figura 8 – Visão arquitetural dos componentes de comunicação no KNoT Fog. Fonte: Adaptado de Batista et al [31]
A implementação da lib permite que uma aplicação que já exista e que utilize alguma das outras nuvens suportadas pelo KNoT, FIWARE ou KNoT-Cloud, já configurada no gateway, possa transferir de plataforma de nuvem para a AWS IoT Core, sendo apenas necessário realizar as configurações necessárias para que a aplicação rode utilizando a nova nuvem. O papel da biblioteca é fazer essa abstração para o usuário, de modo que a aplicação no Thing não perceba que mudou de nuvem e sendo requisitado o mínimo de alteração nas configurações para o desenvolvedor.
Ter que atender ao padrão de mensagens utilizado pela API do KNoT Fog e ao padrão de mensagem aceito pelo AWS IoT, gerou a necessidade de ter um padrão próprio de mensagem que facilitasse o gerenciamento dos dados. Para isso, o modelo mostrado na Figura 8 foi elaborado, que com poucas modificações pode atender tanto ao gestor de mensagens do serviço AWS IoT, como as funções canônicas do Fog Connector. A estrutura em si foi montada para
32
facilitar a o envio dos dados para a nuvem, os campos state e desired, são obrigatórios para reconhecimento da mensagem pela AWS IoT, logo em seguida aparece o campo devices que representa uma lista de gateways conectados na plataforma. Para cada device há uma tupla de chaves das quais, id, name e token identificam cada thing conectado ao determinado gateway, ainda há o campo lastValues e schema, que representam respectivamente, uma lista de sensores conectados ao Thing e uma lista de schemas que caracterizam os sensores conectados, através de seu tipo, unidade de medida, nome e o tipo representativo para o KNoT. A Figura 9 demonstra a estrutura de mensagem criada a partir dos requisitos analisados de ambos os protocolos das APIs.
Figura 9 – Modelo utilizado para troca de mensagens entre plataformas. Fonte: Autoria própria.
4.3 IMPLEMENTAÇÃO
Todo o código da biblioteca foi desenvolvido em Node.js, um framework para Javascript, orientado a eventos assíncronos, ideal para construir aplicações com serviços escaláveis, é uma tecnologia que propicia um fluxo de código sem dead-locking. O SDK para
33
JavaScript, fornecido pela Amazon foi utilizado para requisições e conexões. Para versionamento de código foi utilizada a ferramenta Git, que permitiu a implementação de vários modelos de teste, até o resultado final, todos hospedados no repositório remoto. A IDE utilizada para desenvolvimento foi o Visual Code Studio, ferramenta de projeto open-source desenvolvida pela Microsoft, foi optada por ser uma ferramenta leve e com vários plugins que auxiliaram no desenvolvimento.
A implementação dos métodos do Fog Connector específico seguiu os padrões das funções canônicas que são chamadas por default pelo componente genérico da Fog. Eles realizam operações básicas de criação, remoção, atualização e autenticação dos Things e dos dados. Também há funções de callback, disparadas apenas quando a nuvem realiza alguma requisição para a Fog, seja ela de atualização de dados ou de configuração da conexão.
A nuvem da Amazon também precisou ter seu serviço configurado, para isso foi necessário criar uma conta no console da AWS, logo após ao entrar no serviço IoT Core, uma instância teve de ser gerada, como terceiro passo foi criado um objeto chamado Thing, esse objeto representa a conexão estabelecida entre a nuvem e o KNoT, pois a biblioteca monta todas as suas requisições sobre esse objeto, dentro do Thing também foi criado um Device Shadow, lugar da instância responsável pelo armazenamento das mensagens acessadas pela aplicação. Após isso, a etapa de segurança na comunicação foi destacada, um certificado de autenticação, uma chave pública e uma privada e foram geradas pelo console da AWS, essas chaves foram utilizadas para realizar a autenticação da comunicação entra as requisições da lib e a conta utilizada na Amazon, foram salvas no arquivo de configuração do Fog Connector genérico. Como um
Para finalizar, ainda no console da AWS, foi criado um grupo para o Thing anteriormente criado, no qual variáveis e atributos são permitidos serem adicionados para verificações no código, além disso foi criada uma política que concedeu as devidas permissões da aplicação utilizada para testes, aos serviços da AWS disponibilizados para o IoT Core, o padrão de permissão concedido para o Thing criado pode ser observado na Figura 10. A política de acesso utilizada para o caso de uso permitia acesso a todos os serviços disponíveis no IoT Core para facilitar a realização dos testes.
34
Figura 10 – Modelo de política de acesso utilizada para a aplicação criada no caso de uso. Fonte: Autoria própria.
Dos métodos implementados na lib, pode-se categorizá-los em três tipos, os métodos que são utilizados para configurar a conexão com a nuvem, chamados logo no início de toda aplicação, para estabelecer a comunicação devida com a nuvem e assim possível realizar as chamadas dos outros métodos, os que são utilizados para comunicação da Fog com a cloud e os utilizados para comunicação da cloud com a Fog. Dois protocolos diferentes foram utilizados para comunicação entre as plataformas, HTTPS e MQTT via websocket.
O protocolo HTTPS foi optado para realizar as requisições da Fog para a cloud, através dos métodos de GET e POST, para executar os comandos de atualização dos dados na nuvem, adicionando, atualizando ou removendo dispositivos. Por se tratar de um comando direto do Thing, não é necessário uma comunicação por tópicos, apenas um comando direto no momento da chamada, além de que o protocolo se destaca por estabelecer uma comunicação mais segura, utilizando o certificado de autenticação e as chaves de acesso, além do protocolo de segurança TLS, adotado pela AWS. Para configurar as conexões do tipo HTTPS, algumas variáveis foram pré-estabelecidas para poder dar acesso as requisições, essas variáveis podem ser visualizadas na Figura 11.
35
Figura 11 – Configurações para requisições HTTPS Fonte: Autoria própria.
O protocolo MQTT foi utilizado para implementar as chamadas da nuvem para a Fog. Através do protocolo de Publish/Subscribe, a Fog se inscreve nos tópicos pré-determinados pela AWS e pode assim ser notificada quando uma nova mensagem é publicada no tópico específico de determinada ação, podendo ser de requisição, atualização ou deleção de dados. Para estabelecer a conexão com a AWS através do protocolo MQTT, também foi necessário configurar algumas variáveis utilizadas como parâmetros para estabelecer a comunicação, essas variáveis podem ser analisadas na Figura 12.
Figura 12 – Variáveis para conexão via protocolo MQTT com o IoT Core. Fonte: Autoria própria.
A AWS estabelece para cada protocolo utilizado para se conectar com o IoT Core, duas maneiras de realizar o acesso através de chaves de autenticação assim como suas respectivas
36
portas. As formas de autenticação escolhidas para as conexões feitas pela biblioteca foram, para comunicações via MQTT, autenticação via SigV4 na porta 443, já para a comunicação via HTTPS, autenticação via certificado X.509 na porta 8443. A relação entre as autenticações e os protocolos existentes, pode ser visualizado no Quadro 1.
Quadro 1 – Protocolos, autenticação e portas.
Protocolo Autenticação Porta
MQTT Certificado do cliente X.509 8883, 443 HTTPS Certificado do cliente X.509 8883, 443 HTTPS SigV4 443
MQTT pelo WebSocket SigV4 443
Fonte: Autoria própria. Adaptado de: Protocolos AWS IoT [32]
Os métodos da biblioteca KNoT-Fog-Connector-AWS-IoT são detalhados logo abaixo, com características sobre cada um. Para melhor entendimento foram divididos nas três categorias definidas anteriormente, métodos de configuração inicial, comunicação Fog com nuvem e comunicação nuvem com Fog.
Configuração inicial:
• constructor(settings)
Esse método pré-configura as variáveis utilizadas pelo protocolo MQTT, que serão necessárias nas funções de call-back, para leitura de comandos provindos da AWS IoT. Essas variáveis são carregadas a partir do arquivo de configuração.
Parâmetros:
37
Figura 13 – Pseudocódigo do constructor Fonte: Autoria própria.
• start()
Método responsável por inicializar os métodos de callback e a variável responsável pela conexão com a plataforma de nuvem.
Sem parâmetros.
Figura 14 – Pseudocódigo do método start() Fonte: Autoria própria.
Comunicação Fog com nuvem:
• addDevice(deviceObject)
Responsável por registrar novos Things na nuvem. O método verifica se o id passado já existe no Device Shadow, se não existir, ele gera um token para ser utilizado como identificador do Thing a ser adicionado, em seguida registra o novo device, salvando na nuvem.
Parâmetros:
38
Figura 15 – Pseudocódigo do método addDevice() Fonte: Autoria própria.
• removeDevice(id)
O método realiza uma requisição GET para obter os dados do Device Shadow, em seguida faz uma varredura para encontrar o Thing referente ao id passado como parâmetro e depois removê-lo da mensagem, enviando novamente para ser salva na nuvem.
Parâmetros:
id: Refere-se ao identificador do device que foi gerado no momento de seu registro.
Figura 16 – Pseudocódigo do método removeDevice() Fonte: Autoria própria.
• getDevice(id)
O método faz uma requisição GET ao IoT Core e retorna apenas o device referente ao id passado Parâmetros:
39
Figura 17 – Pseudocódigo do método getDevice() Fonte: Autoria própria.
• listDevices():
O método inicialmente realiza uma requisição GET e filtra apenas as três chaves necessárias para identificação de cada Thing, id, nome e token, retornando a lista dessas tuplas.
Sem parâmetros.
Figura 18 – Pseudocódigo do método listDevices() Fonte: Autoria própria.
• authDevice(id, token)
Esse método realiza uma verificação para saber se o id e token passados como parâmetros, correspondem a de um Thing já registrado na nuvem. Para isso, o código primeiro faz uma requisição GET para comparar se algum dado já existia na nuvem com o mesmo id e token. Retorna true se for localizado na nuvem e false caso ele não esteja registrado.
Parâmetros:
id: Identificador do Thing
40
Figura 19 – Pseudocódigo do método authDevice() Fonte: Autoria própria.
• publishData(id, dataList)
Método utilizado para fazer publicação, dos valores lidos pelos sensores, no Device Shadow, cada sensor é capaz de envir um único dado de valor lido e precisam estar previamente registrados. O método requisita os dados do Device Shadow, e procura pelo Thing correspondente ao id passado como parâmetro, ao localizar realiza as devidas alterações no campo de lastValue.
Parâmetros:
id: Identificador do Thing ao qual os sensores pertencem.
dataList: Lista contendo uma tupla com o sensorId e o valor correspondente a esse sensor
Figura 20 – Pseudocódigo do método publishData() Fonte: Autoria própria.
41
• updateSchema(id, schemaList)
Método utilizado para atualizar valores dos schemas, que correspondem às configurações do sensores, do determinado Thing. O método requisita os dados do Device Shadow, e procura pelo Thing correspondente ao id passado como parâmetro, ao localizar realiza as devidas alterações no campo de schema.
Parâmetros:
id: Identificador do Thing que se deseja realizar as alteraçõs
schemaList: Lista de schemas, onde cada item da lista contém o sensorId para identificação do sensor e os campos para alteração.
Figura 21 – Pseudocódigo do método updateSchema() Fonte: Autoria própria.
• onDataRequested(cb)
Método responsável por se cadastrar no tópico padrão de requisição de dados do Thing. Ao receber uma requisição, significa uma solicitação de dados foi realizada pela nuvem. Após isso, processa a lista de Things do Device Shadow e retorna os dados referentes aos Things solicitados.
Parâmetros:
42
Figura 22 – Pseudocódigo do método onDataRequested() Fonte: Autoria própria.
• onDataUpdated(cb)
Método responsável por se cadastrar no tópico específico de atualização de dados do Thing, onde ao receber uma requisição, significa que houve uma solicitação de atualização de dados provinda da cloud. Após isso irá solicitar uma nova leitura dos sensores para a partir disso atualizar os valores no Device Shadow.
Parâmetros:
callback: Método que será chamado após realização de procedimentos.
Figura 23 – Pseudocódigo do método onDataUpdated() Fonte: Autoria própria.
43
• onDisconnected(cb)
Método responsável por escutar um tópico personalizado para desconexão. Ao receber uma mensagem desse tópico, o método encerra a conexão com a AWS IoT Core e retorna ara a callback.
Parâmetros:
callback: Função registrada para ser chamada pela callback
Figura 24 – Pseudocódigo do método onDisconnected() Fonte: Autoria própria.
• onReconnected(cb)
Método responsável por escutar um tópico personalizado para reconexão. Ao receber uma mensagem desse tópico, o método realiza uma reconexão com a AWS IoT.
Parâmetros:
callback: Função registrada para ser chamada pela callback
Figura 25 – Pseudocódigo do método onReconnected() Fonte: Autoria própria.
• onDeviceUnregistered(cb)
Método responsável por escutar um tópico personalizado para remoção de Thing. Ao receber uma mensagem desse tópico, o método realiza uma remoção do Thing passado como parâmetro atualizando o Device Shadow.
44
Parâmetros:
callback: Função registrada para ser chamada pela callback
Figura 26 – Pseudocódigo do método onDeviceUnregistered() Fonte: Autoria própria.
45
5 CASO DE USO
Este capítulo descreve um caso de uso para a biblioteca KNoT-Fog-Connector-AWS-IoT, como foi realizada a validação, o que foi necessário ser utilizado e qual foi o resultado. Ao final do capítulo é mostrado de que forma a lib contribuiu para o KNoT e quais dificuldades foram minimizadas.
5.2 SIMULAÇÃO
O teste utilizado simulou uma aplicação simples que liga e desliga uma lâmpada remotamente, enviando o valor true ou false, para o Thing e também o próprio Thing se desligando e ligando, em intervalos de tempo, enviando o valor atual para a nuvem. Com isso é possível demonstrar o funcionamento de todos os métodos implementados pela lib, tanto de conexão, como os que envio de dados da Fog para a cloud e da cloud para a Fog, assim como é mostrado o funcionamento do console da AWS.
Para a realização dos testes da biblioteca KNoT-Fog-Connector-AWS-IoT, foi utilizada uma infraestrutura que permitiu simular separadamente cada um dos componentes envolvidos no ciclo da aplicação, de forma automática e local, para facilitar a depuração do código.
Para simular o KNoT Gateway, bastou que o serviço do knotd fosse reproduzido, responsável pelo gerenciamento da comunicação interna no Gateway. Foi utilizado a ferramenta, Docker Compose que executou uma imagem pré-configurada enxuta do Gateway, contendo todos os requisitos mínimos necessários para simular o componente, como o Node.js, RabbitMQ, e as libs utilizadas pelo sistema. O arquivo docker-compose.yml utilizado para montar o ambiente pode ser encontrado no repositório do knot-service-source.
Para simular o KNoT Fog Connector específico, foi necessário executar o KNoT Fog Connector base, com o arquivo de configuração criado para conectar com a lib desenvolvida, apontando para a versão de build do código do KNoT-Fog-Connector-AWS-IoT e inserir a biblioteca no escopo do código do Connector base. Dessa forma, quando o Connector base ralizava alguma requisição, chamava os métodos implementados pela lib.
Para simular o KNoT Thing, foi utilizado um programa implementado em Python que chama todas as instruções de conexão, registro e também chamadas de atualização e autenticação, que um dispositivo Thing normalmente chama. Os dados utilizados para as requisições de publish e register, eram dados estáticos, onde o código simulava a leitura de um sensor através do envio dos dados chamando o método de publicação em um intervalo de tempo.
46
O código em Python para realizar a simulação, também se encontra no repositório do knot-service-source.
Na plataforma AWS IoT Core, foi criado um objeto Thing para receber os dados da aplicação de teste. As chaves de acesso e o certificado criados a partir desse objeto, foram mockeados no código para facilitar o processo de testes, a política de acesso configurada no console, foi definida para aceitar todos os tipos de requisições.
Os passos comentados acima, podem ser visualizados na Figura 27, que mostra através de um fluxograma, a ordem que cada passo foi executado, para validar o funcionamento da biblioteca implementada. Como critério de validação, foi avaliado se o serviço knotd estava conseguindo chamar as funções canônicas do Connector, através de verificação dos logs do console, também foi avaliado se as mesmas mensagens que estavam sendo enviadas pelo Thing, estavam chegando na nuvem, também foi verificado através do método authDevice(), se os tokens correspondiam ao dispositivo criado.
Figura 27 – Fluxograma dos passos realizados no teste. Fonte: Autoria própria.
A Figura 28 mostra o estado da mensagem no Device Shadow após interações de requisições entre a plataforma de nuvem e a aplicação. O campo delta é gerado automaticamente pelo próprio console na mensagem e mostra o estado recebido, antes da última requisição de alteração, esse recurso pode ser utilizado por aplicações para realizar alguma ação de acordo com a diferença entre esses dois estados.
47
Figura 28 – Estado da mensagem recebida no Device Shadow do console AWS. Fonte: Console AWS da aplicação.
5.3 DISCUSSÃO
Esse trabalho propôs trazer uma nova abordagem para soluções com plataformas web services. Integrando a Amazon ao catálogo do KNoT e possibilitando que soluções mais complexas e abrangentes possam ser criadas, devido ao grande catálogo de serviços que essa plataforma de nuvem disponibiliza, ferramentas de visualização de dados, de processamento em larga escala, de armazenamento, de geração de gráficos dinamicamente, além de oferecer
48
infraestrutura para hospedagem de outros serviços instanciados em servidores, dentre tantos outros serviços.
Oferecer mais opções de conexão através da meta-plataforma, vai conceder à ferramenta uma maior visibilidade dentro da comunidade de IoT, agregando mais valor ao KNoT, mostrando que ele está em constante crescimento e expansão de serviços suportados. Outro importante ponto de contribuição é a própria literatura em si, a criação de uma documentação que unifica informações e demonstra as dificuldades encontradas durante o processo e como resolvê-las para se gerar uma aplicação, é de grande valor para a comunidade de desenvolvedores.
O caso de uso implementado foi uma aplicação mais simples que apenas liga e desliga uma lâmpada remotamente, mas ainda assim a biblioteca serviu para abstrair muitos conceitos na comunicação e tradução dos protocolos. Para o caso de implementação de aplicações mais elaboradas que utilizem os serviços da cloud, a biblioteca também facilita o processo de comunicação. Uma solução que não utilize a lib terá que entender todo o funcionamento da API e dos protocolos utilizados para segurança da comunicação, respeitando o formato do JSON aceito, com os campos obrigatórios pelo serviço da Amazon. Para o caso de o desenvolvedor escolher utilizar o KNoT para criar uma solução complexa, mas escolha trabalhar com alguma das outras libs, como o KNoT-Cloud e a KNoT-FI, não terá acesso aos outros recursos que a AWS disponibiliza, tendo que procurar serviços externos e integrá-los para que às plataformas executem o que se deseja.
49
6 CONCLUSÃO
Aplicações que utilizam a tecnologia de IoT vêm conquistando um mercado cada vez maior, o futuro das coisas é se tornarem conectadas com a internet gerando dados a todo momento. Devido a essa grande oportunidade, a quantidade de plataformas tecnológicas que surgem também vem crescendo e cada uma delas tenta propor uma solução para algum problema específico da tecnologia IoT. O problema que acaba se criando com essa grande quantidade de plataformas, é a falta de uma comunicação entre elas, as vezes por serem produzidas por empresas diferentes, por utilizarem protocolos diferentes, implementados em linguagens diferentes ou conceitos de arquitetura diferentes, entre outras causas, elas acabam resolvendo os problemas específicos, mas não o da plataforma de IoT como um todo.
Essa heterogeneidade das plataformas entre si, gera a necessidade de padronização através de uma camada de tradução e adaptação dos protocolos de comunicação dos diferentes serviços. Esse trabalho apresentou a biblioteca KNoT-Fog-Connector-AWS-IoT, que através dela foi possível criar uma ponte de conexão entre as duas plataformas heterogêneas entre si, a meta-plataforma de IoT, KNoT e a plataforma de nuvem para IoT da Amazon, facilitando a criação de aplicações que utilizem serviços tanto do KNoT como da AWS IoT, permitindo que soluções cada vez mais complexas sejam idealizadas.
6.1 DIFICULDADES ENCONTRADAS
Durante a implementação desse trabalho, foram encontradas algumas dificuldades. A primeira foi a de modelar a mensagem padrão utilizada para estabelecer a comunicação entre os componentes, de forma que pudesse ser aceita tanto pelos padrões do Device Shadow do AWS IoT Core, como também pudesse ser facilmente ajustada pelos métodos implementados na biblioteca, sempre atendendo ao padrão de chaves e valores do protocolo AMQP utilizado no KNoT Fog Connector base.
Outra dificuldade encontrada foi a de configurar no código, as variáveis de conexão contendo as chaves de acesso utilizadas pela biblioteca para se conectar com a AWS, pois se caracteriza como uma comunicação segura exigida pela Amazon, mas a própria plataforma dispunha de um certificado TLS antigo, o que foi necessário acionar uma flag do lado do Connector, para ignorar o protocolo obsoleto utilizado.
50
6.2 TRABALHOS FUTUROS
Como futuras possibilidades de melhoria para o crescimento da biblioteca KNoT-Fog-Connector-AWS-IoT, algumas atividades podem ser realizadas
• Disponibilização de serviços da AWS pela interface do KNoT: A plataforma de cloud da Amazon oferece inúmeros serviços que podem ser agregados às aplicações do KNoT, a partir do momento que as credenciais do usuário para a plataforma, são disponibilizadas na biblioteca, esses recursos se tornam disponíveis, gerando novas possibilidades, serviços como o Kibana para visualização de dados em gráficos, EMR para processamentos mais complexos dos dados, entre outros. Criar uma interface no KNoT que possibilite o gerenciamento desses serviços para as aplicações do usuário.
• Construção de aplicações que utilizem o KNoT-Fog-Connector-AWS-IoT: Com a criação de aplicações utilizando a biblioteca, novas necessidades e possíveis defeitos irão normalmente aparecer com o tempo, à medida que a biblioteca for aplicada às soluções. Portanto, é esperada a evolução da lib a partir dos feedbacks dos usuários.
• Criação de testes automatizados: Como toda solução de software, é esperado a utilização de testes automatizados, sejam eles unitários ou de integração. Portanto uma evolução necessária para a plataforma é a criação de testes que podem ser disparados de forma automática e gerem logs com informações sobre o status da aplicação, validando as operações e a conexão.
• Utilização da Alexa: Uma ferramente bastante interessante da Amazon é a tecnologia de inteligência artificial disponibilizada pela plataforma, chamada Alexa, que pode ser utilizada para desenvolver diversas aplicações. Uma abordagem interessante seria integrar os serviços da Alexa à aplicações do KNoT através dessa nova conexão entre as plataformas.
51
REFERÊNCIAS
[1] Amazon Web Services, AWS IoT, “O que é a Internet das Coisas?”, Disponível em
https:/aws.amazon.com/pt/iot/what-is-the-internet-of-things/, Acessado: 2019-12-23 [2] A. L. Albertin, R. M. M. Albertin, “A Internet das Coisas irá muito além das coisas”,
GV-executivo, 2017, vol. 16, nº 2, pp 12-17.
[3] H. Cai, B. Xu, L. Jiang, A. V. Vasilakos, “IoT-Based Big Data Storage Systems in Cloud Computing: Perspectives and Challenges”, IEEE, 2017, Issue 1, Vol. 4, pp 75-87
[4] A. A. Osuwa, E. B. Ekhoragbon, L. T. Fat, “Application of artificial intelligence in Internet of Things”, IEEE, 2017
[5] P. Middleton, J. Tully, P. Kjeldsen, “Forecast: The Internet of Things, Worldwide”, Gartner Research, 2013.
[6] M. Garcia, “The Impact of IoT on Economic Growth A Multifactor Productivity Approach”, IEEE, 2015.
[7] M. Ma, P. Wang, C. Chu, “Data Management for Internet of Things: Challenges, Approaches and Opportunities”, IEEE, 2013
[8] P. Mell, T. Grance, “The NIST definition of cloud computing”, Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, 2011.
[9] J. Gubbi, R. Buyya, S. Marusic, M. Palaniswami, “Internet of Things (IoT): A vision, architectural elements, and future directions”, Elsevier, Future Generations Computer Systems 29, 2013
[10] E. A. Oliveira, B. F. Lóscio, K. S. Gama, “Um Survey dobre Plataformas de Mediação de Dados para Internet das Coisas”, ReserarchGate, 2015.
[11] Meshblu, Disponível em https://meshblu.readme.io/, Acessado: 2019-12-08 [12] FIWARE, Disponível em https://www.fiware.org/, Acessado: 2019-12-08
[13] Google Cloud Platform, Disponível em https://cloud.google.com/, Acessado: 2019-12-08
[14] Amazon Web Services, Disponível em https://aws.amazon.com/pt/, Acessado: 2019-12-08
