Plataformas de middleware e protocolos de comunicação para IoT

Prévia do material em texto

DESCRIÇÃO
Apresentação das principais plataformas e protocolos utilizados para desenvolver aplicações de
IoT com a descrição de suas características, vantagens e desvantagens.
PROPÓSITO
Compreender as principais plataformas e protocolos utilizados para desenvolver aplicações de IoT.
OBJETIVOS
MÓDULO 1
Descrever as plataformas de middleware mais utilizadas: Xively, WSO2, ThingSpeak, OpenIoT,
ThingsBoard
MÓDULO 2
Reconhecer os protocolos de rede para IoT: MQTT, CoAP, XMPP-IoT, RESTful HTTP, DDS, AMQP
INTRODUÇÃO
A Internet das Coisas, também conhecida como Internet dos Objetos, se refere à interconexão
de objetos físicos (coisas) que contêm sensores com serviços da WEB, nos quais os dados
podem ser processados e, a partir disso, viabilizar tomadas de decisão. Essa conectividade
permite que os objetos possam comunicar-se com as pessoas e entre si. As aplicações da IoT são
diversas, como, por exemplo, o monitoramento e controle das condições de ambientes, de saúde,
de frota de veículos, monitoramento, além do controle industrial e da automação residencial.
As tecnologias e protocolos que possibilitam que as aplicações IoT tenham tido tanto sucesso e
ainda estejam em expansão possuem diversas características que levam em conta as limitações
de recursos, um ponto fundamental nesse tipo de aplicação. Ao longo deste estudo, exploraremos
essas tecnologias e protocolos, destacando seus aspectos principais, vantagens e desvantagens.
INTERNET DAS COISAS
Do inglês, Internet of Things (IoT)
MÓDULO 1
 Descrever as plataformas de middleware mais utilizadas: Xively, WSO2, ThingSpeak,
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
OpenIoT, ThingsBoard
SERVIÇOS DA NUVEM
A integração entre as diversas tecnologias tem se tornado uma realidade cada vez mais atual.
Isso se deve, especialmente, ao uso intensivo dos serviços da nuvem. Basicamente, trata-se de
um conjunto de recursos computacionais que oferece meios para que entidades como programas
e dispositivos possam se comunicar na Internet. Os modelos mais comuns de serviços na nuvem
são:
SAAS
Abreviação para software como um serviço – em inglês, Service as a Software. Trata-se de uma
aplicação oferecida via Internet por um determinado preço, que varia conforme as necessidades
de uso da parte contratante. Ele viabiliza que o usuário utilize apenas as funcionalidades do
sistema que serão úteis para suprir suas necessidades. A facilidade desse serviço é que o usuário
não precisa se preocupar com questões relacionadas à instalação, ambiente para execução,
manutenção e upgrades.
PAAS
Abreviação para plataformas como um serviço – em inglês, Plataform as a Service. Aqui, é
disponibilizado um ambiente de desenvolvimento para que o contratante possa trabalhar na
criação de seus próprios programas. De um modo mais concreto, significa que os
desenvolvedores terão acesso à infraestrutura, servidores, ferramentas, bibliotecas e bancos de
dados.
IAAS
Abreviação para infraestrutura como um serviço – em inglês, Infrastructure as a Service. Nesse
modelo, os servidores, componentes de armazenamento, o espaço físico e a rede são oferecidos
para os contratantes.
DAAS
Trata-se do modelo de desktop como um serviço – em inglês, Desktop as a Service. Basicamente,
é uma máquina virtual disponibilizada na nuvem.
XAAS
Trata-se de um termo genérico usado para referenciar a computação sob demanda. A ideia desse
modelo é “tudo como um serviço”, ou seja, um modelo que oferece qualquer função ou recurso
para uso e pagamento de acordo com a necessidade do contratante. Ele generaliza diversos
serviços, tais como: e-mail, ERP, redes e banco de dados e até mesmo modelos de serviços, tais
como o CaaS, MaaS, DRaaS e NaaS.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
CAAS
Comunicação como um serviço
MAAS
Monitoramento como um serviço
DRAAS
Recuperação de desastres como um serviço
NAAS
Redes como um serviço
Nesse cenário de diversos modelos de serviço na nuvem, ainda existe o IoTPaaS, que é uma
extensão do PaaS que inclui características específicas para aplicações de Internet das Coisas.
Assim, temos diversas plataformas de middleware em que o software viabiliza a comunicação
entre o dispositivo e a rede. A primeira dessas plataformas que vamos abordar é a Xively.
XIVELY
A Xively é uma plataforma de propriedade do Google para a implantação de aplicações de Internet
das Coisas na nuvem que permite que as empresas possam conectar e gerenciar produtos na
rede e, assim, transmitir e analisar os dados produzidos em outros sistemas. Logo que foi criada,
em 2007, ela era conhecida como Pachube. É disponibilizada como Plataforma como Serviço,
inclui serviços de diretório de dados, bem como segurança de dados e uma interface de usuário
da web. Basicamente, trata-se de uma infraestrutura de coleta, gerenciamento e distribuição de
dados. Além disso, ela também fornece API com suporte para as linguagens de programação:
Android, Arduino, C, Python e Java (RAY, 2016).
A Xively fornece ferramentas para modelar a conexão entre as diversas partes de um negócio. Ela
tem suporte para a maioria das estruturas de IoT e microcontroladores do mercado para criar um
projeto ou produto 'inteligente'. Uma interface Xively Web é fornecida para ser usada na
implementação de uma aplicação front end. Ela pode implementar os seguintes protocolos e
recursos:
HTTP
API
MQTT
Na prática, o uso desses protocolos facilita a conectividade dos dispositivos com a nuvem.
A Xively viabiliza a criação de aplicações para processamento em tempo real e armazenamento
na nuvem. Para poder usar os serviços da nuvem Xively, é necessário registrar-se no site de
soluções em nuvem do Google (Google Cloud IoT). Apenas depois de fazer a criação da conta, os
desenvolvedores podem criar aplicações de IoT. A Xively tem dois conceitos básicos:
DISPOSITIVO XIVELY
É o dispositivo, ou o projeto de IoT que será conectado na rede. A ideia é que o dispositivo
funcione como um envelope contendo os dados.
CANAIS
É o fluxo de dados (streaming) relacionados aos sensores. Normalmente, o número do canal é
igual ao número do sensor.
Cada dispositivo conectado recebe um identificador único que serve para especificar o fluxo de
dados e metadados do dispositivo conectado. Assim que isso for feito, as permissões nos
dispositivos IoT são atribuídas usando as API disponíveis. As permissões disponíveis são:
CRIAR
ATUALIZAR
EXCLUIR
LER
Para que uma aplicação possa se comunicar com a plataforma de serviços Xively, é necessária a
utilização de uma API chamada de Xively REST API. Na imagem a seguir, apresentamos a
arquitetura da plataforma Xively.
Imagem: A survey of commercial frameworks for the internet of things, Derhamy, H.; Eliasson, J.;
Delsing, J.; Priller, P. 2015, p. 5. Adaptado por Sérgio Monteiro.
 Arquitetura da plataforma Xively.
Como vimos na imagem, a plataforma fornece um barramento de mensagem central que faz o
roteamento das mensagens entre dispositivos de protocolos diferentes. O barramento de
mensagem se combina com a API Xively para MQTT, HTTP e Web Sockets para fornecer uma
camada de interoperabilidade. Além disso, o framework possui serviços extras que permitem
realizar serviços de negócios e integração de sistemas.
A Xively oferece vantagens e desvantagens, dentre as quais, as principais estão apontadas a
seguir:
VANTAGENS
Suporte direto do Google.
Fácil integração com dispositivos usando API RESTful.

DESVANTAGEM
Pouco suporte para notificações.
WSO2
A WSO2 é uma provedora de tecnologia de código aberto (A Reference Architecture For The
Internet of Things, 2021). Ela dá suporte para o monitoramento, gerenciamento e interação de
dispositivosde IoT de modo a viabilizar, assim, o processo de comunicação entre a IoT e a
nuvem. A WSO2 possui cinco camadas horizontais que são: comunicação com o cliente
externo, processamento e análise de eventos, camada de agregação, comunicação e
dispositivos; e duas camadas transversais que são: gerenciamento de dispositivos e
identidade e gerenciamento de acesso. Na imagem a seguir, apresentamos como a arquitetura
da WSO2 é estruturada.
Imagem: Sérgio Monteiro
 Arquitetura do WSO2.
Agora, vamos entender melhor o que significa cada camada.
Na camada horizontal, temos:
DISPOSITIVOS IOT
Essa camada tem os recursos necessários para que os dispositivos possam se conectar à
Internet. Podem existir dispositivos de vários tipos, mas para que possam ser considerados
dispositivos IoT, eles precisam ter recursos de comunicação para estabelecer uma conexão direta,
ou indireta à Internet. Alguns exemplos de dispositivos de conexões diretas são:
Arduino com conexão Ethernet Arduino.
Arduino Yún com uma conexão Wi-Fi.
Raspberry Pi conectado via Ethernet ou Wi-Fi.
Intel Galileo conectado via Ethernet ou Wi-Fi.
Exemplos de dispositivos que conectam indiretamente são:
Dispositivos ZigBee conectados por meio de um gateway ZigBee.
Dispositivos Bluetooth, ou Bluetooth Low Energy conectando-se por meio de um telefone
celular.
Dispositivos que se comunicam por rádios de baixa potência com um Raspberry Pi.
Para que um dispositivo possa ser reconhecido, ele precisa de uma identidade. A identidade pode
ser uma das seguintes:
Um identificador exclusivo (UUID) gravado no dispositivo.
Um UUID fornecido pelo subsistema de rádio (por exemplo, identificador Bluetooth, endereço
MAC Wi-Fi).
Um OAuth2 Refresh/Bearer Token.
Um identificador armazenado em memória não volátil, como EEPROM.
CAMADA DE COMUNICAÇÃO
Habilita os dispositivos a se comunicarem com aplicações front-end, painéis e portais Web via
APIS. A camada de comunicação dá suporte para a conectividade dos dispositivos. Existem vários
protocolos para comunicação entre os dispositivos e a nuvem. Os três protocolos potenciais mais
conhecidos são:
HTTP/HTTPS.
MQTT.
Protocolo de aplicativo restrito (CoAP).
AGREGAÇÃO
As comunicações entre os diferentes dispositivos são agregadas e roteadas para um dispositivo
específico. Isso é feito através das transformações realizadas entre diferentes protocolos. A
importância dessa camada tem três motivos:
Capacidade de suportar um servidor HTTP e um broker MQTT para interagir com os
dispositivos.
Capacidade de agregar e combinar comunicações de diferentes dispositivos e de rotear
comunicações para um dispositivo específico.
Capacidade de oferecer API baseadas em HTTP que são usadas como um recurso de
mediação em uma mensagem MQTT indo para o dispositivo.
PROCESSAMENTO DE EVENTOS E ANÁLISES
Captura os eventos que ocorrem no dispositivo IoT e fornece, assim, a capacidade de processar e
agir sobre esses eventos. Um importante recurso dessa camada é o de armazenar os dados em
um banco de dados. Ela pode fazer isso das seguintes formas:
Através do modelo tradicional, ou seja, implementar um aplicativo do lado do servidor com
conexão a um banco de dados.
Usar uma plataforma de análise de big data que seja escalável em nuvem.
Outra abordagem é oferecer suporte ao processamento de eventos complexos para iniciar
atividades e ações quase em tempo real com base nos dados dos dispositivos e do resto do
sistema.
CAMADA DE COMUNICAÇÕES COM CLIENTES
EXTERNOS
Fornece uma maneira para que os dispositivos se comuniquem fora do sistema orientado a
dispositivos. Isso pode ser feito por front-end e portais baseados na web que interajam com
dispositivos e com a camada de processamento de eventos, ou por painéis que tenham
visualizações de análises e processamento de eventos, ou ainda, interagir com sistemas fora da
rede usando comunicações máquina-a-máquina por API.
Na camada vertical, temos:
GERENCIAMENTO DE DISPOSITIVOS
Faz a comunicação com os dispositivos por meio de vários protocolos e fornece controle individual
e de diversos dispositivos. Também faz o gerenciamento remoto dos programas implantados nos
dispositivos. Nessa camada, é mantida a lista de identidades de dispositivos e mapeamento dos
seus proprietários. Ele também gerencia os controles de acesso sobre os dispositivos com a
camada de gerenciamento de identidade e acesso. Existem três níveis de dispositivos:
Dispositivos totalmente gerenciados: são aqueles que ativam e executam um agente de
gerenciamento de dispositivos, por exemplo:
Gerenciar o software no dispositivo.
Ativar/desativar recursos do dispositivo (câmera, hardware etc.).
Gestão de controles e identificadores de segurança.
Monitorar a disponibilidade do dispositivo.
Manter um registro da localização do dispositivo.
Bloquear, ou limpar o dispositivo remotamente.
Os dispositivos não gerenciados: podem se comunicar com o resto da rede, mas não têm
nenhum agente envolvido. Isso pode incluir dispositivos em que as restrições são muito
pequenas para suportar o agente. O gerenciador de dispositivos ainda pode manter
informações sobre a disponibilidade e localização do dispositivo, caso esteja disponível.
Dispositivos semigerenciados: são aqueles que implementam algumas partes do
gerenciamento de dispositivos, como o controle de recursos, mas não o gerenciamento de
software.
GERENCIAMENTO DE ACESSO
Fornece serviços de gerenciamento de identificação e de acesso. Essa camada precisa fornecer
os seguintes serviços:
Emissão e validação do token OAuth2.
Outros serviços de identidade, incluindo SAML2 SSO e suporte OpenID Connect para
identificar solicitações de entrada da camada da Web.
PDP XACML.
Diretório de usuários (por exemplo, LDAP).
Gerenciamento de política para controle de acesso (ponto de controle de política).
A WSO2 oferece a integração de API, serviços Web e de diversas aplicações. Essa característica
– a da integração - é a principal razão da sua existência como plataforma WSO2, com a qual é
possível gerenciar API, acessos e identidades, além de outros tipos de análises avançadas.
THINGSPEAK
A ThingSpeak é uma plataforma com recursos muito semelhantes ao Xively e tem como base a
tecnologia de nuvem pública (ThingSpeak for IoT Projects, 2021). Ela permite que seja feita a
coleta de dados em tempo real e a transmissão de forma privada para a nuvem. Esses dados
podem ser analisados por aplicações desenvolvidas em Matlab e Arduino, por exemplo, e, se
necessário, uma ação pode ser tomada de acordo com o que for programado a partir da detecção
de certos padrões de eventos. Na imagem a seguir, apresentamos um esquema que representa
como o ThingSpeak trabalha.
Imagem: Sérgio Monteiro.
 Esquema de funcionamento do ThingSpeak.
Essa característica de fazer análise e processamento online dos dados, conforme eles chegam, é
um dos motivos pelo qual a ThingSpeak é normalmente utilizada para fazer prototipagem e prova
de conceito de sistemas IoT que requerem análises.
O ThingSpeak permite desenvolver uma aplicação que faça a leitura de sensores, rastreamento
em tempo real da localização de objetos e a criação de uma “rede social de coisas”. A API da
plataforma também permite o processamento matemático de dados como cálculo de média,
mediana, somatório e arredondamento.
Algumas das principais características do ThingSpeak são:
Recursos para fazer agregação, visualização e análise de fluxos de dados em tempo real na
nuvem.
Facilidade para fazer a configuração de dispositivos para usar protocolos IoT populares, como
HTTP, por exemplo.
Visualização dos dados dos sensores em tempo real.
Agregar dados sob demanda de fontes de terceiros.
Integração com o MATLAB que facilita trabalhar com dados de IoT.
Aplicar o IoT analytics para fazer análises automaticamente com base no tratamento dos eventos.
Prototipar e construir sistemas IoT sem a necessidade de configurar servidores, ou desenvolver
softwares da Web.
O ThingSpeakpossui vantagens e desvantagens, dentre as quais, as principais são apontadas a
seguir:
VANTAGENS
Acesso à nuvem pública.
API para armazenamento e análise de dados.
Suporte às operações matemáticas.
DESVANTAGEM
Pouco suporte para conexão simultânea de dispositivos.
OPENIOT
OpenIoT é uma plataforma de IoT de código aberto, que tem como características principais
(OpenIoT: Open Source cloud solution for the Internet of Things, 2021):
Incorporação de dados e aplicativos IoT em infraestruturas de computação em nuvem.
Fornecimento de acesso seguro a aplicações compatíveis.
Fornecimento de suporte para a descoberta de sensores e dados em tempo real.
Suporte a sensores móveis e parâmetros de qualidade de serviço.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
QUALIDADE DE SERVIÇO
QoS
No OpenIoT, as etapas de registro, aquisição de dados e implantação de sensores são
gerenciadas pelo X-GSN, que é o responsável por anotar semanticamente os dados do sensor e
os metadados. O X-GSN é semelhante aos sistemas Apache Storm ou Spark. Ele é usado para
escrever scripts que permitem a integração de qualquer sensor no OpenIoT.
Os dados de todas as entradas (dispositivos móveis, sensores, sistemas corporativos etc.)
chegam ao X-GSN que, por sua vez, anota os dados com os metadados necessários. Antes que
os dados possam entrar no sistema, cada sensor precisa ser registrado no sistema de banco de
dados IoT usando a linguagem de descrição de ontologia SSN. Uma vez registrado, este sistema
pode enviar dados para a nuvem centralizada ou eles também podem ser distribuídos.
ONTOLOGIA
O termo ontologia é muito importante em computação e empregado em diversos contextos.
Alguns dos trabalhos que foram importantes para aplicá-lo em ciência da computação foram
os de Gruber (1995), Guarino e Giaretta (1995) e Fikes e Farquihar (1999). A ontologia é
usada como um modelo de dados que representa um conjunto de conceitos dentro de um
domínio e as relações entre esses conceitos. Por exemplo, ela descreve:
Indivíduos: os objetos básicos.
Classes: conjuntos, coleções ou tipos de objetos.
Propriedades de atributos, recursos, características ou parâmetros que os objetos
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
podem ter e compartilhar.
Relações: maneiras pelas quais os objetos podem se relacionar.
Eventos: a mudança de atributos ou relações.
O X-GSN cuida de todos os dados de streaming e permite que sejam consultados e agregados
antes de serem transferidos para o OpenIoT.
O conceito fundamental do X-GSN é o de sensor virtual, que é capaz de representar qualquer
entidade abstrata (por exemplo, dispositivos físicos) que coleta quaisquer parâmetros. Para tornar
um sensor virtual acessível a partir do restante da plataforma OpenIoT, cada sensor virtual precisa
se registrar no Linked Sensor Middleware.
O LSM é outro componente central do OpenIoT que é responsável por tratar com a cadeia de
coleta de dados do sensor. Ele transforma e anota os dados que vêm de sensores virtuais – por
meio de X-GSN – em uma representação de dados vinculados, ou seja, RDF, e os armazena no
banco de dados.
RDF
RDF é a sigla para Resource Description Framework, que é uma linguagem de propósito
geral para representar informações na Web (RDF 1.1 Turtle, 2021).
LINKED SENSOR MIDDLEWARE
LSM
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
A plataforma OpenIoT depende ainda do OpenLink Virtuoso – também conhecido como Virtuoso
Universal Server – que é um mecanismo de banco de dados híbrido que combina a funcionalidade
de um sistema gerenciador de banco de dados tradicional, sistema gerenciador de banco de
dados orientado a objetos, banco de dados virtual, RDF, XML, texto livre, servidor de aplicativos
da Web e funcionalidade de servidor de arquivos em um único sistema. A arquitetura da
plataforma de dados OpenIoT é ilustrada a seguir.
Imagem: Sérgio Monteiro.
 Arquitetura da plataforma OpenIOT.
 EXEMPLO
Um exemplo de aplicação da OpenIoT é para a melhoria da eficiência em operações industriais,
como manufatura e agricultura. A plataforma OpenIoT pode ser usada para monitorar o
sensoriamento em ambientes de manufatura através da análise dinâmica de sensores em tempo
real dos dados para fornecer indicadores de fabricação necessários, que é um fator que pode
aumentar a agilidade da tomada de decisão e do processo de fabricação.
THINGSBOARD
ThingsBoard é uma plataforma de IoT de código aberto para coleta, processamento de dados,
visualização e gerenciamento de dispositivos (ThingsBoard: Open-source IoT Platform, 2021). Ela
oferece suporte de conexão a protocolos IoT, como:
MQTT
COAP
HTTP
Também dá ao usuário a capacidade de gerenciar dispositivos através do registro, gerenciamento
e monitoramento de diferentes dispositivos, além de fornecer uma API para aplicativos do lado do
servidor para enviar comandos para dispositivos e vice-versa.
O ThingsBoard possui suporte para bancos de dados como HSQLDB, PostgreSQL e Cassandra.
Ele tem um mecanismo para análise de mensagens recebidas e pode ser integrado com Kafka e
Apache Spark para processamento mais complexo. A arquitetura do ThingsBoard é apresentada a
seguir.
Imagem: Sérgio Monteiro.
 Arquitetura do ThingsBoard.
Suas principais caraterísticas são:
COMBINA ESCALABILIDADE, DESEMPENHO E
TOLERÂNCIA A FALHAS.
APRESENTA FÁCIL GERENCIAMENTO DE TODOS OS
DISPOSITIVOS CONECTADOS USANDO API DO LADO
DO SERVIDOR.
FAZ A TRANSFORMAÇÃO DOS DADOS DOS
DISPOSITIVOS E FACILITA ALARMES PARA DISPARAR
ALERTAS EM TODOS OS EVENTOS DE TELEMETRIA,
ATUALIZAÇÕES E INATIVIDADE.
TEM CAPACIDADE PARA TRABALHAR COM MUITOS
DISPOSITIVOS AO MESMO TEMPO.
COMPARANDO AS PLATAFORMAS DE IOT
O especialista Sérgio Monteiro demonstra uma comparação das plataformas de IoT abordadas
neste módulo.
VERIFICANDO O APRENDIZADO
1. A INTERNET DAS COISAS (IOT) ESTÁ CADA VEZ MAIS PRESENTE EM
DIVERSAS APLICAÇÕES, COMO O MONITORAMENTO DE EQUIPAMENTOS
À DISTÂNCIA E O CONTROLE REMOTO DE CONDIÇÕES DE AMBIENTE,
POR EXEMPLO. UMA DAS QUESTÕES FUNDAMENTAIS PARA QUE A IOT
TENHA TANTO SUCESSO ESTÁ RELACIONADA ÀS PLATAFORMAS DE
MIDDLEWARE QUE VIABILIZAM A COMUNICAÇÃO ENTRE OS
DISPOSITIVOS (QUE SÃO AS “COISAS”, OU “OBJETOS”) E A INTERNET.
ESCOLHA A OPÇÃO CORRETA QUE DEFINE IOT COMO PLATAFORMA DE
SERVIÇO (IOTPAAS):
A) Oferece ferramentas e demais recursos como bibliotecas que tratam especificamente do modo
como tecnologias de IoT vão interagir.
B) Disponibiliza um ambiente de desenvolvimento, para que o contratante possa trabalhar na
criação de seus próprios programas.
C) Viabiliza a integração entre dispositivos de diferentes tecnologias.
D) Fornece a infraestrutura necessária para que sejam desenvolvidas aplicações de IoT que se
comuniquem com aplicações WEB.
E) É uma abstração das tecnologias e protocolos necessários para viabilizar o desenvolvimento de
aplicações de IoT.
2. A WSO2 É UMA PLATAFORMA PARA DESENVOLVIMENTO DE
APLICAÇÕES DE INTERNET DAS COISAS (IOT) DE CÓDIGO ABERTO. ELA
TEM DIVERSAS CARACTERÍSTICAS INTERESSANTES, TAIS COMO
ESCALABILIDADE, GERENCIAMENTO DE GRANDES VOLUMES DE DADOS,
SEGURANÇA E ADAPTAÇÃO DINÂMICA. A RESPEITO DA ARQUITETURA
DO WSO2, ESCOLHA A OPÇÃO CORRETA:
A) Camada de comunicação: viabiliza a comunicação entre os dispositivos e aplicações WEB via
APIS.
B) Processamento de eventos e análises: armazena dados oriundos dos eventos das aplicações
WEB, como triggers, e envia para os dispositivos, de modo que possam processar e agir sobre
esses eventos.
C) Agregação: faz a análise dos dados dos dispositivos; usa técnicas de BigData, uma vez que os
dispositivos podem gerar muitos dados.
D) Dispositivos IoT: fornece o ambiente seguro para que os dispositivos possam comunicar-se
entre si.
E) Transporte: é aplicada nas situações em que é necessário fazer o monitoramentoremoto de
equipamentos.
GABARITO
1. A Internet das Coisas (IoT) está cada vez mais presente em diversas aplicações, como o
monitoramento de equipamentos à distância e o controle remoto de condições de ambiente,
por exemplo. Uma das questões fundamentais para que a IoT tenha tanto sucesso está
relacionada às plataformas de middleware que viabilizam a comunicação entre os
dispositivos (que são as “coisas”, ou “objetos”) e a Internet. Escolha a opção correta que
define IoT como Plataforma de Serviço (IoTPaaS):
A alternativa "A " está correta.
A IoT como Plataforma de Serviço (IoTPaaS) fornece serviços fundamentais para soluções IoT
através do fornecimento de ferramentas e bibliotecas que viabilizam o desenvolvimento de
aplicações de IoT que se comunicam com aplicações disponibilizadas na nuvem.
2. A WSO2 é uma plataforma para desenvolvimento de aplicações de Internet das Coisas
(IoT) de código aberto. Ela tem diversas características interessantes, tais como
escalabilidade, gerenciamento de grandes volumes de dados, segurança e adaptação
dinâmica. A respeito da arquitetura do WSO2, escolha a opção correta:
A alternativa "A " está correta.
A responsabilidade de fornecer os recursos para viabilizar a comunicação entre os dispositivos e
as aplicações WEB é da camada de comunicação da plataforma WSO2.
MÓDULO 2
 Reconhecer os protocolos de rede para IoT: MQTT, CoAP, XMPP-IoT, RESTful HTTP, DDS,
AMQP
PROTOCOLO MQTT
O MQTT é um protocolo de mensagens. Ele foi desenvolvido pela IBM e lançado em 1999. A sua
primeira aplicação foi monitorar sensores em oleodutos de petróleo através de satélites. Trata-se
de um protocolo aberto que foi liberado ao público de forma gratuita no ano de 2010. No ano de
2014, o protocolo se tornou padrão OASIS (MQTT: The Standard for IoT Messaging, 2021).
MQTT
Message Queuing Telemetry Transport, em português, Transporte de Filas de Mensagem de
Telemetria
OASIS
Organization for the Advancement of Structured Information Standards, em português,
Organização para o Avanço dos Padrões de Informação Estruturada
A comunicação do MQQT é baseada em um broker, que é um servidor que faz a publicação e
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
recebimento de dados com o padrão de mensagens publicação e assinatura – em inglês,
publish/subscribe. O broker recebe todas as mensagens dos seus clientes. Em seguida, ele as
envia aos clientes de destino. Um exemplo desse processo ocorre quando alguns clientes são
sensores IoT – publicadores – e outros clientes são aplicações que recebem os dados dos
sensores e os processa. Na imagem a seguir, é apresentado o esquema de funcionamento do
broker.
Imagem: Sérgio Monteiro.
 Infraestrutura de comunicação do MQQT.
Na imagem, temos os papéis do publicador, assinante, tópico e broker. O broker faz a publicação
e o recebimento dos dados. Publicador e assinantes são clientes nessa infraestrutura. O
publicador transmite (publica) uma mensagem, registrando-a em um tópico de destino. Essa
mensagem, por sua vez, é transmitida ao broker, que vai enviá-la ao assinante inscrito no tópico.
Do mesmo modo, quando um cliente quer se tornar um assinante em um determinado tópico, ele
encaminha uma mensagem de solicitação ao broker, que fará a interligação entre cliente e tópico.
 EXEMPLO
Em um ambiente em que a refrigeração deve ser mantida dentro de determinadas faixas de
temperatura, precisamos de sensores que meçam a temperatura. Agora, existem duas situações a
serem tratadas: a primeira é o processo de ligar e desligar equipamentos de refrigeração; a
segunda é regular a faixa da temperatura. Em ambos os casos, o tópico a ser assinado é “obter a
temperatura do sensor em uma determinada localização”. Portanto, o processo de publicação
desse exemplo corresponde às mensagens de mudanças de temperatura e cada um dos sistemas
que assinou o tópico vai atuar conforme o que foi programado, ou seja, ligar ou desligar aparelhos
de refrigeração e regular a temperatura do ambiente.
O protocolo MQTT utiliza os protocolos TCP e MQTT-SN para a transmissão de dados. O
cabeçalho de uma mensagem do MQTT pode variar de 2 a 5 bytes. Basicamente, ele traz
informações sobre o tipo de mensagem, um indicador de mensagem duplicada, um identificador
da qualidade de serviço (QoS) do pacote e um bit para indicar se a mensagem deve ser retida
ou não quando alguém se conectar e receber a última mensagem enviada. Os próximos bytes
servem para definir o tamanho do resto do pacote. Ainda sobre o QoS, ele garante a
confiabilidade da entrega da mensagem. O MQQT tem três níveis de QoS:
CABEÇALHO
Conhecido, comumente, pelo termo em inglês header
NÍVEL 0
NÍVEL 1
NÍVEL 2
NÍVEL 0
A mensagem é enviada apenas uma vez. As mensagens são enviadas dependendo da existência
de rede e não há tentativa de retransmissão da mensagem.
NÍVEL 1
A mensagem é enviada pelo menos uma vez, também é chamado de entrega reconhecida. Quem
publica, envia uma mensagem pelo menos uma vez e verifica o estado da entrega.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps1
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps1
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps2
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps2
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps3
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps3
NÍVEL 2
As mensagens são entregues exatamente uma vez. Esse modelo também é chamado de entrega
garantida.
O MQQT tem diversos tipos de mensagens para tratar situações distintas, sendo que os principais
tipos são:
CONNECT
Usado para clientes enviarem solicitações de conexão para o broker.
PUBLISH
Usado pelo cliente/remetente para publicar mensagens para o broker.
SUBSCRIBE
Usado pelo cliente/receptor para receber mensagens do broker.
Na tabela a seguir, apresentamos uma lista dos tipos de mensagens do MQQT.
Valor Nome Direção Descrição
0 Reservado Proibido Reservado
1 CONNECT
Cliente
para servidor
Requisição do cliente 
para conectar ao servidor
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
2 CONNACK
Servidor para
cliente
Reconhecimento da conexão
3 PUBLISH
Cliente para
servidor ou
servidor para
cliente
Publicar mensagem
4 PUBACK
Cliente para
servidor ou
servidor para
cliente
Reconhecimento da
publicação
5 PUBREC
Publicação
recebida
Publicação recebida
(parte 2 do QoS=1)
6 PUBREL
Cliente para
servidor ou
servidor para
cliente
Publicação lançada
(parte 2 do QoS=2)
7 PUBCOMP
Cliente para
servidor ou
servidor para
Publicação completa
(parte 3 do QoS=2)
cliente
8 SUBSCRIBE
Cliente para
servidor
Pedido de inscrição
9 SUBACK
Servidor para
cliente
Reconhecimento de inscrição
10 UNSUBSCRIBE
Cliente para
servidor
Pedido de cancelamento
de inscrição
11 UNSUBACK
Servidor para
cliente
Reconhecimento de
cancelamento de inscrição
12 PINGREQ Requisição Requisição PING
13 PINGRESP
Servidor para
cliente
Resposta PING
14 DISCONNECT
Cliente para
servidor
Cliente está desconectado
15 Reservado Proibido Reservado
Tabela: Tipos de mensagens.
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Entre as principais vantagens do MQTT estão:
Qualquer tipo de dado pode ser transportado pelo pacote. Os dados podem ser texto ou binários,
desde que a parte receptora saiba como interpretá-lo;
Existem algumas opções de Qualidade de Serviço (QoS) que podem ser usadas para garantir a
entrega;
O modelo de publicação/assinatura é dimensionado de maneira eficiente em termos de consumo
de energia;
Existem vários elementos no design que separam o dispositivo e o servidorassinante, o que
resulta em uma estratégia de comunicação mais robusta;
Um dispositivo pode publicar seus dados independentemente do estado do servidor de assinatura.
O servidor de assinatura pode então se conectar e receber os dados quando puder.
Já as principais desvantagens do MQTT são:
MQTT usa o protocolo TCP que demanda por mais recursos de processamento e de memória;
A centralização do broker minimiza a escalabilidade, pois cada dispositivo cliente consome alguma
sobrecarga;
O broken centralizado pode ser o ponto de falha;
Em comparação com HTTP, é mais complexo de implementar.
PROTOCOLO COAP
O CoAP foi desenvolvido pelo grupo de trabalho para Ambientes RESTful Limitados da IETF
(CoAP: RFC 7252 Constrained Application Protocol, 2021). A IETF padronizou diversos protocolos
com o objetivo de incorporar dispositivos com recursos limitados – em energia, memória,
processamento e largura de banda – tais como:
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
IETF
Internet Engineering Task Force
RESTFUL
CoRE - Constrained RESTful Environments
FORÇA-TAREFA DE ENGENHARIA DA
INTERNET
IETF - Internet Engineering Task Force
6LoWPAN para adaptar IPv6 a LLNs, que são redes com baixa potência e perdas.
6LOWPAN
IPv6 over Low-Power Wireless Personal Area Networks
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
LLNS
Low Power and Lossy Networks
RPL para rotear sobre os links flutuantes e compressão para otimizar camadas de protocolo
superiores.
RPL
Routing protocol for wireless networks
O protocolo CoAP completa esta pilha formando um conjunto de protocolos padronizado. Nesse
cenário, a IoT baseada em IP torna-se interessante para aplicações industriais. Ele é formado por
duas subcamadas: uma de transação e outra de solicitação/resposta, conforme podemos ver na
imagem a seguir:
Imagem: Sérgio Monteiro.
 Pilha dos protocolos HTTP e CoAP.
A camada de solicitação/resposta é responsável por gerenciar recursos através dos métodos GET,
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
PUT, DELETE e POST, enquanto a camada de transação percebe o mecanismo de confiabilidade
ao processar mensagens, bem como fornece detecção de duplicação de mensagens. Na camada
de transação, uma mensagem pode ser de quatro tipos (Constrained Application Protocol (CoAP),
2021):
CONFIRMADA (CON)
NÃO CONFIRMADO (NON)
RECONHECIMENTO (ACK)
REINICIAR (RST)
CONFIRMADA (CON)
Algumas mensagens requerem uma confirmação, seja apenas para saber que chegaram ou
também para entregar a resposta a uma solicitação.
NÃO CONFIRMADO (NON)
Algumas mensagens não requerem confirmação. Isso é particularmente verdadeiro para
mensagens que são repetidas regularmente para requisitos de aplicação, como leituras repetidas
de um sensor em que a chegada eventual é suficiente.
RECONHECIMENTO (ACK)
Uma mensagem de reconhecimento confirma a chegada de uma mensagem de confirmação
específica (identificada por seu ID de transação).
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps41
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps41
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps42
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps42
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps43
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps43
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps44
http://estacio.webaula.com.br/cursos/temas/01859/index.html#collapse-steps44
REINICIAR (RST)
A mensagem foi recebida, mas não pôde ser processada, pois falta algum contexto para
processá-la adequadamente.
Veja a seguir as principais vantagens do protocolo CoAP:
É um protocolo adequado para comunicação IoT e M2M (Machine to Machine) devido à sua
simplicidade baseada em UDP, em que os tamanhos dos pacotes são pequenos.
Isso torna os ciclos de comunicação mais rápidos e permite prolongar a vida útil das baterias dos
dispositivos que fazem parte do sistema.
Usa IPSEC para fornecer comunicação segura.
Não necessita de comunicação síncrona.
Tem menor latência em comparação com HTTP.
Consome menos energia do que HTTP.
Ele usa mensagem ACK e, portanto, torna-se confiável como HTTP. Além disso, evita
retransmissões desnecessárias.
As principais desvantagens do protocolo CoAP são:
Por usar UDP, o CoAP é um protocolo não confiável. Portanto, as suas mensagens chegam sem
ordem, ou se perdem quando chegam ao destino.
O tempo de processamento é afetado devido à confirmação de cada recebimento das mensagens.
Além disso, não faz a verificação da qualidade da decodificação da mensagem recebida.
Como o MQTT, é um protocolo não criptografado e usa o protocolo DTLS (Datagram Transport
Layer Security) para fornecer segurança o que, por sua vez, aumenta o custo de sobrecarga de
implementação.
PROTOCOLO XMPP-IOT
O XMPP-IoT é um protocolo aberto, padronizado pela Força-Tarefa de Engenharia da Internet,
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
assim como HTTP e CoAP, (An Overview of XMPP, 2021). Logo no início, ele era conhecido como
Jabber. Foi projetado para ser usado em aplicativos de mensagens instantâneas ou bate-papo.
Devido às suas características, ele é utilizado com sucesso para aplicações de IoT. Basicamente,
é um protocolo de comunicação baseado em XML que usa a arquitetura cliente-servidor rodando
sobre TCP e que possui extensões que possibilitam o uso do modelo de publicação-assinatura.
XMPP-IOT
Extensible Messaging and Presence Protocol for the IoT
XML
Extensible Markup Language
As extensões permitem que entidades XMPP criem tópicos e publiquem informações. Uma
notificação de evento é transmitida a todas as entidades que se inscreveram em um nó específico.
Os clientes e servidores em XMPP comunicam-se entre si usando fluxos XML para trocar dados
na forma de stanzas XML (unidades de dados estruturados semânticos). Três tipos de stanzas são
definidos, (Extensible Messaging and Presence Protocol (XMPP): Core, 2021):
<MESSAGE/>
É um mecanismo de envio. Com ele, uma entidade envia informações para outra entidade, como
acontece com as comunicações em um sistema como o e-mail. Todas as stanzas da mensagem
devem possuir um atributo 'to' que especifica o destinatário da mensagem. Quando recebe essa
stanza, um servidor deve entregá-la ao destinatário alvo.
<PRESENCE/>
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
É um mecanismo do tipo "publicar-assinar". Com ele, várias entidades que se inscreveram a uma
determinada entidade vão receber informações sobre ela. Portanto, uma entidade de publicação
deve enviar uma stanza de presença sem o atributo 'to'. O servidor ao qual a entidade está
conectada deve transmitir essa stanza a todas as entidades assinantes. Pode ocorrer ainda o
caso em que uma entidade de publicação pode enviar uma stanza de presença com um atributo
'to'. Nessa situação, o servidor deve encaminhar, ou entregar essa stanza ao destinatário
pretendido.
<IQ/>
O nome iq é um acrônimo para Info Query. É um mecanismo de solicitação-resposta, semelhante
em alguns aspectos ao [HTTP]. A sua semântica possibilita que uma entidade faça uma
solicitação e receba uma resposta de outra entidade. O conteúdo dos dados da solicitação e
resposta é definido pela declaração de namespace de um elemento filho direto do elemento iq e a
interação é rastreada pela entidade solicitante por meio do uso do atributo id. Assim, as interações
de Info Query seguem um padrão comum de troca de dados estruturados, como get/result, ou
set/result.
A seguir, apresentamos um exemplo deuma sessão do XMPP em que as stanzas de saídas
enviadas pelo cliente são precedidas de C e as de entrada que são entregues pelo servidor são
precedidas de S.
C: <stream:stream>
C: <presence/>
C: <iq type="get">
<query xmlns="jabber:iq:roster"/>
</iq>
S: <iq type="result">
<query
xmlns="jabber:iq:roster">
<item jid="estudante01@servidor.edu"/>
<item jid="estudante02@servidor.edu"/>
<item jid="estudante03@servidor.edu"/>
</query>
</iq>
C: <message from="professor01@servidor.edu"
to="secretaria@servidor.edu">
<body>Dar as boas-vindas aos estudantes de IoT!</body>
</message>
C: <presence type="available"/>
C: </stream:stream>
Uma stanza de presença notifica as entidades sobre atualizações de status. Sua função é fazer a
inscrição no XMPP. Se houver interesse na presença de algum JID, um cliente assina sua
presença e, toda vez que um nó enviar uma atualização de presença, ele será notificado. Uma
stanza iq fornece uma interação do tipo pergunta-resposta. No caso do exemplo anterior, o cliente
C faz uma solicitação da lista de contatos do servidor na linha 3, ao passo que, na linha 6, o
servidor S retorna a lista de contatos. Sua função é semelhante aos métodos HTTP GET e POST.
JID
Jaber ID – um endereço de nó em XMPP
Entre as principais vantagens do protocolo XMPP estão:
A especificação XMPP já incorpora mecanismos de TLS (Transport Layer Security) que garantem
a confidencialidade e integridade dos dados.
Esquema de endereçamento para reconhecer dispositivos na rede.
Arquitetura cliente-servidor.
Descentralização.
Flexibilidade.
Padrões abertos e formalizados.
As principais desvantagens do protocolo XMPP são:
Mensagens baseadas em texto e sem provisão para criptografia ponta a ponta.
Sem provisão para qualidade de serviço.
O protocolo XMPP tem uma grande sobrecarga de dados para vários destinatários.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
PROTOCOLO RESTFUL HTTP
O HTTP é o protocolo fundamental usado para a Web do modelo cliente-servidor em que a
comunicação entre um cliente e um servidor ocorre por meio de uma mensagem do tipo
solicitação/resposta: o cliente envia uma mensagem de solicitação HTTP e o servidor retorna uma
mensagem de resposta, contendo o recurso solicitado, caso a solicitação tenha sido aceita. Já o
REST é um conjunto de regras que especifica como o Servidor e o Cliente devem interagir, ou
seja, é uma arquitetura. Há, ainda, o conceito de RESTful, que basicamente significa que um
serviço da Web implementa o estilo de arquitetura REST. Essa arquitetura, com o protocolo
HTTP, tem sido muito aplicada para sistemas de IoT (DIZDAREVIĆ et al, 2019).
REST
Representational State Transfer
SERVIÇO DA WEB
Web service
A combinação do protocolo HTTP com REST permite que os dispositivos possam disponibilizar
suas informações de estado, devido à forma padronizada de criar, ler, atualizar e excluir dados, ou
seja, às chamadas operações CRUD. De acordo com esse mapeamento, as operações de
criação, atualização, leitura e exclusão de recursos correspondem aos métodos HTTP POST,
GET, PUT e DELETE, respectivamente. Na prática, aplicações REST HTTP possibilitam que os
desenvolvedores possam construir um modelo REST para diferentes dispositivos IoT e trabalhar
com dados nos formatos JSON e XML, por exemplo.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
CRUD
Create Read Update Delete
Na imagem a seguir, apresentamos um exemplo de uma interação de solicitação/resposta REST
HTTP entre dois clientes e um servidor.
Imagem: Sérgio Monteiro.
 Exemplo do Modelo de interação REST HTTP.
No exemplo, o cliente REST HTTP (A) solicita adicionar um recurso no lado do servidor (B). Para
isso, é necessário especificar no cabeçalho do método POST a raiz do recurso que será
adicionado (/resources), a versão HTTP (no caso é 1.1), o tipo de conteúdo (Content-Type), que,
neste caso, é um arquivo JSON (application/json) que representa um recurso específico e,
finalmente, o próprio objeto JSON ({“id”: 1, name: “test”}). A resposta do servidor especifica se a
solicitação foi bem-sucedida, especificando os códigos de status padrão HTTP. No caso do
exemplo, o servidor respondeu o código 201.
Ainda analisando o exemplo, no caso do cliente (C), é feita uma solicitação de um recurso. Então,
nesse caso, ele precisa utilizar o método GET com a especificação de um URI específico. No caso
de exemplo, ele usou GET /resources /1, que contém a raiz do recurso e o id do próprio recurso.
Agora, o servidor retornou o objeto JSON que representa o recurso.
Algumas das principais vantagens do REST são:
Separação entre o cliente e o servidor: com a separação da interface do usuário do servidor e do
armazenamento de dados, é possível melhorar a portabilidade da interface para outros tipos de
plataformas, o que implica no aumento da escalabilidade, flexibilidade e confiabilidade dos
projetos, pois os desenvolvedores podem trabalhar de forma independente nos diferentes
componentes do projeto.
Independência de plataforma e de linguagens de programação: isso ocorre porque a comunicação
com as aplicações é feita através de API REST que permitem utilizar servidores PHP, Java,
Python ou NodeJS.
Veja algumas das desvantagens do REST:
Apesar do uso do protocolo de transporte TCP que fornece entrega confiável de grandes
quantidades de dados, o que é uma vantagem em conexões que não têm requisitos estritos de
latência, ele cria desafios em ambientes com recursos limitados. Um dos principais problemas é
que os nós restritos, na maioria das vezes, enviam pequenas quantidades de dados
esporadicamente e a configuração de uma conexão TCP leva tempo, produzindo sobrecarga
desnecessária.
Utilização do protocolo TLS (Transport Layer Security) como mecanismo de segurança. O TLS usa
um processo de handshake que, na prática, adiciona tráfego adicional a cada estabelecimento de
conexão que pode consumir os recursos dos dispositivos de IoT.
PROTOCOLO DDS
O DDS define um modelo de comunicação do tipo publicação/assinatura em tempo real totalmente
distribuído ponto a ponto, ou seja, sem broken (Object Management Group, 2014). Ele fornece
comunicação de alto desempenho, escalabilidade e disponibilidade e dá suporte para a
especificação de contratos de QoS entre publicadores e consumidores de dados, além de ter
mecanismos para tratar com aspectos de tempo real, como prioridade e outras políticas de QoS
específicas. Ele permite a interoperabilidade entre programas desenvolvidos em diferentes
linguagens de programação, bem como descoberta automática de publicadores e assinantes de
DDS. De forma semelhante ao que ocorre com o MQQT, possui Tópicos DDS que são entidades
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
para transferência de informações onde as aplicações podem publicar, ou assinar e podem ser
considerados como tabelas de banco de dados relacionais distribuídas.
DDS
Data Distribution System, em português, Sistema de Distribuição de Dados
As principais entidades na arquitetura DDS incluem:
Domínio
Participante do Domínio
Tópico
Publicador
Assinante
DataWriter (escritor de dados)
DataReader (leitor de dados)

Os Publicadores e Assinantes são divididos em Domínios que permitem o isolamento da
comunicação dentro de nós que possuem interesses comuns.
Os tópicos são definidos pelo programador de uma aplicação DDS. Ele escreve um arquivo IDL
com a descrição dos nomes, tipos de dados e as chaves que identificam as instâncias (que podem
ser vistas como linhas de banco de dados) de cada tópico.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
IDL
Interface Definition Language


Um compilador recebe o IDL como entrada e gera código para stubs de comunicação na
linguagemde programação escolhida pelo programador.
Com os stubs gerados, as aplicações podem ingressar em um domínio DDS, publicar e assinar os
dados desse domínio.

O Domínio DDS que contém o espaço global de dados compartilhados é totalmente distribuído
pela rede ponto a ponto formada pelos nós da rede sem qualquer agente intermediário, ou
entidade de gerenciamento centralizado como o broken.
Na imagem a seguir, apresentamos o modelo conceitual do espaço global de dados.
Imagem: Sérgio Monteiro.
 Modelo conceitual do espaço global de dados.
O participante do domínio é o ponto de entrada para a troca de mensagens em domínios
específicos que fazem a associação entre publicadores e assinantes e os domínios aos quais
pertencem. Ele é usado para criar editores, assinantes, escritores de dados (Data Writer), leitores
de dados (Data Reader) e tópicos em um domínio.
 ATENÇÃO
Publicadores e assinantes são as entidades de produção e consumo de dados que publicam e
recebem dados por meio do espaço global de dados, mas não podem fazer isso por conta própria.
Em vez disso, os publicadores usam os Data Writer para enviar dados e assinantes usam leitores
de dados Data Reader para receber dados com a correspondência entre os dois por meio de
tópicos, ou seja, para se comunicarem, publicadores e assinantes devem usar o mesmo tópico.
Entre as principais vantagens do protocolo DDS estão:
FACILIDADE DE INTEGRAÇÃO
A abordagem centrada em dados usada pelo DDS permite a definição de modelos de dados
comuns e extensíveis para interoperabilidade oculta dos detalhes de conectividade e topologia das
aplicações.
EFICIÊNCIA DE DESEMPENHO E
ESCALABILIDADE
As implementações de DDS podem alcançar latências ponto a ponto muito baixas e taxa de
transferência de vários milhões de mensagens por segundo.
SEGURANÇA AVANÇADA
Fornece autenticação padronizada, criptografia, controle de acesso e recursos de registro para
permitir conectividade de dados segura de ponta a ponta em um sistema de IoT.
PADRÃO ABERTO
A especificação de middleware OMG DDS é um padrão aberto que tem a participação de diversos
fornecedores e usuários.
HABILITADO PARA QOS
Possui um conjunto de políticas de QoS que permite que o DDS controle todos os aspectos da
distribuição de dados, como pontualidade, priorização de tráfego, confiabilidade e uso de recursos.
DESCOBERTA ESCALONÁVEL
Para sistemas dinâmicos de grande escala, o DDS oferece descoberta automática, com a
funcionalidade plug-and-play para simplificar a integração e orquestração do sistema.
APLICABILIDADE
O DDS pode abordar de forma transparente comunicação ponto a ponto, dispositivo a dispositivo,
dispositivo a nuvem e nuvem a nuvem.
E entre as principais desvantagens do protocolo DDS estão:
É muito pesado para ser usado em sistemas embarcados.
DDS não faz interface com serviços da web.
DDS consome duas vezes a largura de banda do protocolo MQTT.
As políticas de QoS são aplicadas apenas em ambientes DDS restritos.
PROTOCOLO AMQP
AMQP é um protocolo da camada de aplicação de padrão aberto que segue o paradigma publicar-
assinar, conforme definido pelo OASIS, 2012. Ele é projetado para redes orientadas a mensagens
e tem suporte para arquitetura de publicador/assinante. Ele faz uso do TCP como protocolo de
transporte para fornecer comunicação confiável. Além disso, para fornecer QoS, garante três
níveis de entrega, (Protocols and Interoperability, 2021):
AMQP
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
Advanced Message Queueing Protocol, em português, Protocolo Avançado de
Enfileiramento de Mensagens
QOS 0: MAIS UMA VEZ
Garante que uma determinada mensagem só seja recebida pelo assinante no máximo uma vez.
Isso significa que a mensagem pode nunca chegar. O remetente e o destinatário tentarão entregar
a mensagem, mas se algo falhar e a mensagem não chegar ao seu destino (por exemplo, devido
a uma conexão de rede), a mensagem pode ser perdida. Esse QoS tem a menor sobrecarga de
tráfego de rede e menos carga para o cliente e o broker e geralmente é útil para dados de
telemetria, em que não importa se alguns dos dados são perdidos.
QOS 1: PELO MENOS UMA VEZ
Garante que uma mensagem chegará ao destinatário pretendido uma ou mais vezes. O remetente
continuará a enviar a mensagem até receber uma confirmação do destinatário, atestando que
recebeu a mensagem. O resultado dessa QoS é que o destinatário pode receber a mensagem
várias vezes, aumentando a sobrecarga da rede mais do que no QoS 0, (devido a acks). Além
disso, mais carga é colocada sobre o remetente, pois ele precisa armazenar a mensagem e tentar
novamente caso não receba uma confirmação em um tempo razoável.
QOS 2: EXATAMENTE UMA VEZ
O mais caro do QoS (em termos de tráfego de rede e carga para o remetente e o receptor), esse
QoS garantirá que a mensagem seja recebida por um destinatário exatamente uma vez. Isso
garante que o receptor nunca obtenha cópias duplicadas da mensagem e, eventualmente, as
receba, mas ao custo extra de sobrecarga de rede e complexidade exigida pelo emissor e pelo
receptor.
Com publicadores e assinantes, ambos usando um broker, o AMQP tem mais dois componentes:
trocas e filas de mensagens.
Na imagem a seguir, apresentamos um exemplo de como ocorre a comunicação no AMQP.
Imagem: Sérgio Monteiro.
 Comunicação no AMQP.
As trocas executam a funcionalidade de roteamento fazendo o encaminhamento das mensagens
para as filas de mensagens apropriadas. Essas mensagens podem ser armazenadas em filas de
mensagens antes de serem encaminhadas aos assinantes. AMQP usa dois tipos de mensagens
diferentes:
Ele usa QoS e, portanto, garante a passagem segura de dados importantes.
O AMQP usa a arquitetura de publicação/assinatura já estabelecida para compartilhamento de
dados, conforme usado pelo protocolo MQTT.
Garante a interoperabilidade de aplicações implementadas em linguagens distintas.
Oferece conexão segura para usuários usando protocolo SSL como CoAP, MQTT, HTTP e XMPP.
Entre as principais desvantagens do protocolo AMQP estão:
Tem problemas de compatibilidade com suas versões mais antigas.
A implementação de soluções é mais complexa do que HTTP.
Requer largura de banda maior, ao contrário do MQTT/CoAP/XMPP.
A descoberta de recursos não é compatível com CoAP/HTTP/XMPP.
CONHECENDO OS PROTOCOLOS DE REDE
PARA IOT
O especialista Sérgio Monteiro demonstra os protocolos de rede para IoT apresentados neste
módulo.
VERIFICANDO O APRENDIZADO
1. O PROTOCOLO MQTT É UM DOS MAIS UTILIZADOS PARA APLICAÇÕES
DE INTERNET DAS COISAS. ELE POSSUI VÁRIOS TIPOS DE MENSAGENS
PARA TRATAR SITUAÇÕES ESPECÍFICAS NA COMUNICAÇÃO ENTRE
DISPOSITIVOS E APLICAÇÕES WEB. EM RELAÇÃO AOS TIPOS DE
MENSAGENS DO MQTT, SELECIONE A OPÇÃO INCORRETA:
A) CONNECT: os clientes utilizam para enviarem solicitações de conexão para o broker.
B) PUBLISH: é usado para publicar mensagens para o broker.
C) SUBSCRIBE: os clientes e receptores utilizam-no para receber mensagens do broker.
D) CONNACK: é utilizado como reconhecimento da conexão.
E) UNSUBSCRIBE: pedido de solicitação de nova inscrição.
2. O PROTOCOLO COAP POSSUI CARACTERÍSTICAS PARA TRATAR AS
LIMITAÇÕES INERENTES PARA DISPOSITIVOS UTILIZADOS EM PROJETOS
DE INTERNET DAS COISAS. A SUA ARQUITETURA POSSUI DIVERSAS
CAMADAS QUE TÊM FUNÇÕES BEM DEFINIDAS, COMO A CAMADA DE
TRANSAÇÃO. A RESPEITO DOS TIPOS DE MENSAGENS DA CAMADA DE
TRANSAÇÃO DA COAP, SELECIONE A OPÇÃO CORRETA.
A) Confirmada (CON): corresponde à confirmação que o cliente dá para o servidor quando recebe
uma mensagem.
B) Não confirmado (NON): é usada quando o servidor não consegue verificar a integridade do
dado enviado pelo cliente.
C) Reconhecimento (ACK): confirma a chegada de uma mensagem de confirmação específica.
D) Reiniciar (RST): corresponde a uma mensagem do servidor para que o dispositivo cliente seja
reiniciado.
E) SUBSCRIBE (SUB): é uma solicitação de inscrição do servidor no cliente, para que possa sernotificado da ocorrência de eventos.
GABARITO
1. O protocolo MQTT é um dos mais utilizados para aplicações de Internet das Coisas. Ele
possui vários tipos de mensagens para tratar situações específicas na comunicação entre
dispositivos e aplicações WEB. Em relação aos tipos de mensagens do MQTT, selecione a
opção incorreta:
A alternativa "E " está correta.
O tipo de mensagem UNSUBSCRIBE corresponde a um pedido de cancelamento de inscrição.
2. O protocolo CoAP possui características para tratar as limitações inerentes para
dispositivos utilizados em projetos de Internet das Coisas. A sua arquitetura possui
diversas camadas que têm funções bem definidas, como a camada de transação. A respeito
dos tipos de mensagens da camada de transação da CoAP, selecione a opção correta.
A alternativa "C " está correta.
O tipo de mensagem de reconhecimento (ACK) confirma a chegada de uma mensagem de
confirmação específica através da identificação pelo seu ID de transação.
CONCLUSÃO
CONSIDERAÇÕES FINAIS
No decorrer dos módulos, apresentamos as plataformas mais utilizadas para o desenvolvimento
de aplicações de IoT: Xively, WSO2, ThingSpeak, OpenIoT, ThingsBoard, em que exploramos as
suas características, pontos fortes e fracos. Além disso, também analisamos os protocolos de rede
para IoT: MQTT, CoAP, XMPP-IoT, RESTful HTTP, DDS, AMQP sob a mesma ótica:
características, vantagens e desvantagens.
A compreensão de como essas plataformas e protocolos funcionam nos dá elementos para
fazermos escolhas mais adequadas quando vamos montar um projeto de IoT. Os desafios
relacionados à construção de um projeto desse tipo abrangem a confiabilidade dos objetos da
rede e dos dados que estão sendo transmitidos e recebidos, pois são esses dados que vão dar
suporte para a tomada de decisão. Então, é necessário assegurar-se de que sejam confiáveis.
Os benefícios da utilização dessas plataformas e protocolos são diversos, como a padronização
do desenvolvimento, uso de recursos pré-prontos que podem ser conectados ao projeto, além de
contar com o suporte dos fornecedores. Outro ponto interessante que precisamos destacar é que
muitas dessas aplicações de IoT possuem um grande volume de dados e, portanto, existe uma
interessante ligação entre elas e as áreas de Big Data e de Aprendizado de Máquina.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
APACHE. Protocols and Interoperability. Consultado em meio eletrônico em: 05 fev. 2021.
APACHE. Protocol DDS Interoperability, Wire Protocol Specification, V2.2. 2014. Consultado
em meio eletrônico em: 05 fev. 2021.
COAP. CoAP: RFC 7252 Constrained Application Protocol. Consultado em meio eletrônico em: 05
fev. 2021.
Derhamy, H.; Eliasson, J.; Delsing, J.; Priller, P. A survey of commercial frameworks for the
internet of things. In: Proceedings of the 2015 IEEE 20th Conference on Emerging Technologies
& Factory Automation (ETFA), Luxembourg, 8–11 September 2015; pp. 1–8. Consultado em meio
eletrônico em: 05 fev. 2021.
Dizdarević, J.; Carpio, F.; Jukan, A.; Masip-Bruin, X. A survey of communication protocols for
Internet of Things and related challenges of fog and cloud computing integration. In: ACM
Comput. Surv., vol. 51, pp. 116, jan. 2019. Consultado em meio eletrônico em: 05 fev. 2021.
FIKES, R.; FARQUHAR, A. Distributed Repositories of Highly Expressive Reusable
Ontologies. In: IEEE Intelligent Systems & their applications, v. 14, n. 2. Mar/Apr, pp. 73-79, 1999.
Consultado em meio eletrônico em: 05 fev. 2021.
GOOGLE. Google Cloud IoT. Consultado em meio eletrônico em: 05 fev. 2021.
GRUBER, T. R., Towards principles for the design of ontologies used for knowledge sharing.
In: Int. J. HumanComputer Studies, v. 43, n.5/6, 1995. Consultado em meio eletrônico em: 05 fev.
2021.
GUARINO, N.; GIARRETA, P. Ontologies and Knowledge Bases – Towards a Terminological
Clarification. In: Mars, n. j., (ed.), Towards Very Large Knowledge Bases: Knowledge Building and
Knowledge Sharing, IOS Press, Amsterdam, pp 25-32, 1995. Consultado em meio eletrônico em:
05 fev. 2021.
MQTT. The Standard for IoT Messaging. Consultado em meio eletrônico em: 05 fev. 2021.
OASIS. OASIS Advanced Message Queuing Protocol, (AMQP) Version 1.0. OASIS Standard,
29 October 2012. Consultado em meio eletrônico em: 05 fev. 2021.
Object Management Group. Documents Associated with the Real-Time Publish-
SubscribeWire. Consultado em meio eletrônico em: 05 fev. 2021.
OpenIoT. Open Source cloud solution for the Internet of Things. Consultado em meio
eletrônico em: 05 fev. 2021.
Ray, P. P. A survey of IoT cloud platforms. In: Future Comput. Inform. J., vol. 1, no. 1, pp. 35-46,
2016. Consultado em meio eletrônico em: 05 fev. 2021.
ThingsBoard: Open-source IoT Platform. Consultado em meio eletrônico em: 05 fev. 2021.
ThingSpeak. ThingSpeak for IoT Projects. Learn More About ThingSpeak. Consultado em meio
eletrônico em: 05 fev. 2021.
TOOLS.IETF. Constrained Application Protocol (CoAP). Consultado em meio eletrônico em: 05
fev. 2021
XMPP. Extensible Messaging and Presence Protocol (XMPP): Core. Consultado em meio
eletrônico em: 05 fev. 2021.
XMPP. An Overview of XMPP. Consultado em meio eletrônico em: 05 fev. 2021.
WSO2. A Reference Architecture for the Internet of Things. Consultado em meio eletrônico em:
05 fev. 2021.
W3. RDF 1.1 Turtle. Consultado em meio eletrônico em: 05 fev. 2021.
EXPLORE+
Para saber mais sobre os assuntos tratados neste tema, pesquise:
O site oficial do OASIS e do OMG e aprenda mais detalhes sobre tecnologias para IoT.
O site Google APIs no GitHub e aprenda mais sobre API para desenvolver aplicações de IoT
na nuvem.
CONTEUDISTA
Sérgio Assunção Monteiro
 CURRÍCULO LATTES
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);