Summary of options for international development support to LDCs

O KNoT-Gateway é o componente central da plataforma KNoT, servindo como meio de acesso entre os dispositivos e as plataformas de nuvem. Portanto, esta seção detalha a estrutura interna do KNoT-Gateway em dois aspectos: hardware e software.

2.2.1.1 Arquitetura de Hardware

Para ter várias capacidades de rádio, o KNoT Gateway deve ser composto por elementos de hardware capazes de lidar com diferentes pilhas de protocolos sem fio, bem

Capítulo 2. Conceitos Básicos 32 Figura 14 – Arquitetura hub-and-spoke

Fonte: https://www.knot.cesar.org.br/ - User Guide

como periféricos de comunicação utilizados para se comunicar com cada interface de rádio. Além disso, o gateway precisa de poder computacional suficiente para lidar com todas as pilhas de protocolos e executar serviços em nuvem que implementam recursos de intermediação de mensagens, armazenamento de dados e processamento de dados. A arquitetura de hardware do gateway é representada na Figura 15. Nela, o principal componente do gateway é uma placa baseada em um microprocessador ARM, ideal para executar uma versão personalizada da versão Linux embarcada. Essa placa também deve ser capaz de lidar com o maior número possível de periféricos de comunicação para gerenciar o tráfego de dados dos diferentes rádios.

A maior parte da demanda exigida pelos nós de IoT refere-se ao consumo de energia devido a interfaces sem fio (ALIOTO; SHAHGHASEMI, 2018). Para lidar com esse problema, a arquitetura de hardware foi projetada para fornecer suporte a redes como Low-Rate Personal Area Networks (LR-PANs), Local Area Networks (LANs) e Mesh Local Area Networks (Mesh-LANs), comuns no contexto de IoT. Ao contrário dos nós IoT (Things), que alternam períodos de operação ativa com períodos em modos de consumo ultrabaixo, o gateway deve estar ativo na maior parte do tempo. Nesse cenário, um gateway alimentado por bateria exigiria uma grande fonte de energia ou uma substituição constante de bateria. Para evitar isso, espera-se que o gateway seja constantemente conectado à rede de energia.

Como discutido anteriormente, há alguns requisitos para o hardware do gateway, como a capacidade de executar um sistema operacional e lidar com diferentes protocolos

Capítulo 2. Conceitos Básicos 33 Figura 15 – Arquitetura de hardware do KNoT Gateway

Fonte: (BARROS et al., 2019)

de comunicação. Para lidar com essas preocupações, o Raspberry Pi foi escolhido para a implementação de referência do KNoT Gateway. Essa placa é capaz de lidar com vários periféricos de comunicação (como I2C 5_{, SPI} 6_{, USART) e possui quatro portas USB} e Ethernet. Além disso, é poderoso o suficiente para executar uma distribuição Linux customizada, permitindo a criação de vários daemons para manipular protocolos de rádio e conectar-se a serviços em nuvem.

Como representado na Figura 16, duas interfaces de rádio são atualmente suportadas pela implementação de referência do gateway, ou seja, um rádio RF de 2,4 GHz (LR-PAN) e um rádio IEEE 802.15.4 (MESH-LAN). Cada um deles possui um hardware específico que manipula a pilha de rádio e usa interfaces periféricas específicas.

Figura 16 – Implementação de referência de hardware do KNoT Gateway

Fonte: (BARROS et al., 2019)

O rádio 2,4 GHz usado é um módulo nRF24L01+, um transceptor de ultra baixa potência amplamente disponível em lojas eletrônicas. Uma placa de expansão compacta foi

5 _{https://www.i2c-bus.org}

Capítulo 2. Conceitos Básicos 34 projetada para conectar rádio, LEDs e botões, como mostrado na Figura 17. O hardware IEEE 802.15.4 usado é o dongle USB nRF52840, que é conectado ao Raspberry Pi através de uma porta USB e implementa um Network Co-Processor (NCP) 7_{. A placa base do} gateway também possui dois botões, um para reinicializar a placa e outro como botão do usuário, além de três LEDs para fornecer feedback sobre o status da operação. É importante ressaltar que essas placas de expansão não são vitais para o funcionamento do gateway, são apenas meios facilitados de conectar os periféricos ao Raspberry. O gateway pode ser composto somente pelo Raspberry e pelos rádios desejados, instalados da maneira disponível ao usuário.

Figura 17 – Hardware do KNoT Gateway

Fonte: (BARROS et al., 2019)

2.2.1.2 Arquitetura de Software

O KNoT Gateway faz uso do Buildroot 8_{, projeto de código aberto para compilar um} sistema Linux embarcado e construir uma distribuição Linux leve e eficiente. A distribuição KNoT Linux foi criada selecionando alguns serviços Linux necessários para o gateway operar, como serviços de gerenciamento de rede, servidor Web e banco de dados NoSQL. Além do uso de pacotes de software existentes, foi necessário desenvolver novos serviços para manipular a operação de um gateway IoT. Uma característica importante é que todo o software desenvolvido e utilizado pelo KNoT são projetos de código aberto, isso é essencial para que o KNoT Gateway tenha uma boa aceitação e adoção como uma plataforma de gateway multi-rádio. Os daemons gerenciadores do KNoT Gateway são:

7 _{https://openthread.io/guides/ncp} 8 _{buildroot.org}

Capítulo 2. Conceitos Básicos 35 • Network Manager (nrfd): O PAN Network Manager é responsável por estabelecer uma Personal Area Network (PAN) com dispositivos que usam esse tipo de pilha de protocolos. Na presente implementação de referência, o rádio nRF24l01+ foi usado para a rede PAN. O daemon nrfd possui os drivers NRF24L01 +, com as camadas PHY, Link e de rede dessa pilha.

• Gerenciador de rede MESH (inetbrd + wpantund): O Mesh Network Mana- ger é responsável por criar uma rede MESH para dispositivos que usam esse tipo de comunicação. Na presente implementação de referência, o serviço wpantund é um fork da implementação OpenThread (openthread.io), que permite que o gateway atue como roteador de borda com uma pilha IEEE 802.15.4. O daemon inetbrd cria uma ponte IP para enviar o tráfego das interfaces locais para o KNoT Device Manager knotd.

• LAN Network Manager (bluetoothd): O LAN Network Manager lida com dispositivos que implementam pilhas de protocolos sem fio da LAN, como o Bluetooth. Este daemon faz parte da arquitetura do KNoT Gateway, mas não está atualmente disponível na implementação de referência.

• Outros Gerenciadores de Rádio: A arquitetura do KNoT Gateway foi projetada com várias pilhas de protocolos sem fio em mente. Portanto, uma arquitetura flexível foi proposta para suportar outras tecnologias no futuro.

• Gerenciador de Dispositivos do KNoT (knotd): O knotd é um daemon que atua como proxy entre os gerenciadores de rede e a KNoT Fog, fornecendo assim um ponto central para lidar com dispositivos KNoT, tradução de protocolos e capacidades de encaminhamento de mensagens.

• KNoT Gateway Web UI (knot-web): O KNoT Gateway UI é uma interface Web para gerir dispositivos KNoT provenientes de todas as redes e também para gerenciar o próprio gateway em termos de configuração IP, credenciais de usuários, etc.

• KNoT Fog: O KNoT Fog é responsável por fornecer recursos de nuvem local (fog) IoT no gateway, como gerenciamento de mensagens, armazenamento de dados e processamento de dados, bem como para fornecer acesso local a dispositivos quando a conexão com a Internet não estiver disponível. A presente implementação de referência usa um fork do Meshblu messege broker 9_{, que permite a criação de} dispositivos virtuais, com armazenamento dos seus dados e comunicação através de alguns protocolos, como HTTP, WebSocket, MQTT ou COAP.

Capítulo 2. Conceitos Básicos 36 • KNoT Fog Connector: O Fog Connector, resultado da presente dissertação,

sincroniza os dados do dispositivo entre o KNoT Fog e outras plataformas de nuvem IoT. Para implementar o Fog Connector, foi necessário desenvolver uma interface e conector para a plataforma de nuvem IoT desejada (neste caso, a FIWARE) com operações para gerenciar dispositivos (CRUD), descrever dispositivos, enviar e receber dados e configurações do dispositivo.

A Figura 18 mostra a relação entre todos esses os serviços. As informações são compartilhadas entre eles usando vários protocolos de comunicação, como D-Bus, Unix Socket e WebSocket.

Figura 18 – Arquitetura de software do KNoT Gateway

Fonte: (BARROS et al., 2019)