IOT – INTERNET DAS COISAS

AULA 1

Prof. Gian Carlo Brustolin

1
CONVERSA INICIAL

Conheceremos uma tecnologia que tem apresentado evolução vertiginosa em

aplicações e tecnologia. O uso da expressão Internet das Coisas ou IoT (Internet of
Things, em inglês) é reputado a Kevin Ashton, cientista idealizador da padronização de
RFID, em uma conferência em 1999, mas a exata definição de IoT, até o momento em
que concluímos esta publicação, ainda é lacunosa e, como recurso, feita por exclusão.
Intuitivamente, imaginamos IoT como pequenos objetos relativamente
autônomos conectados com a internet. Essa aproximação parece nos bastar
inicialmente, embora não resista a questionamentos básicos. Por exemplo, a partir
dessa definição intuitiva, podemos afirmar que televisões inteligentes ou mesmo
palmtops são objetos IoT? Parece-nos que sim, mas de fato não o são. A nossa
dificuldade em estabelecer os limites entre objetos IoT e outras eletrônicas inteligentes
não impedem, obviamente, a proliferação constante desses objetos. Essa verdadeira
invasão eletrônica não se dá, entretanto,
pacificamente, conforme afirma Brustolin (2022),

a profusão de entidades ligadas à internet gerou alguns problemas clássicos

como a questão do endereçamento, a princípio resolvido pelo IPV6, mas
também alguns problemas inusitados, como a necessidade de conexão sem
fio de pequenos entes computacionais, sem alimentação externa, de forma
segura, sem configurações e de operação simplificada. Esta combinação de
requisitos e exigências torna a flexibilidade de projeto bastante baixa e a
seleção de protocolos viáveis bastante estrita.

Nesta etapa, considerando a necessária associação, por vezes, dicotômica entre

objetos IoT e sua conectividade, abordaremos os fundamentos desses objetos, a
exemplo da arquitetura básica de hardware e software, bem como os conceitos gerais
de alguns protocolos de comunicação voltados a esses objetos.
No decorrer desta caminhada, veremos como esses objetos nos auxiliam em
aplicações residenciais, comerciais e industriais, facilitando a aquisição de dados e a
operação de máquinas, desde o acionamento remoto da refrigeração de sua casa até o
controle de maquinário agrícola autônomo.
Mergulharemos também no interessante tema das cidades inteligentes
indistintamente fundido com a Internet das Coisas. Não nos furtaremos ao
conhecimento das soluções de conectividade para IoT, posto que tais soluções

2
são substancialmente diversas daquelas para redes tradicionais de computadores.
Estudaremos, também, o temerário tema de segurança que assola a todos os projetistas e
usuários dessa tecnologia. Desta forma, ao final desta caminhada, você terá uma visão
técnica geral de IoT, conhecendo suas aplicações e desafios. Vamos, então, dar início a
este empolgante estudo.

TEMA 1 – INTRODUÇÃO À IOT

Você provavelmente está imaginado que, levando em conta a tradução literal do

termo IoT (Internet of Things, em inglês), o estudo da Internet das Coisas deveria ser
um estudo de redes ou de conectividade para “objetos”. Se você pensou assim, não está
errado, em parte, ao menos. Podemos dizer que do ponto de vista stricto, IoT estuda
somente a conexão de eletrônicas à internet, neste sentido, podemos citar Santos et al,
2016, p. 2:

A Internet das Coisas, em poucas palavras, nada mais é que uma extensão da
Internet atual, que proporciona aos objetos do dia a dia (quaisquer que
sejam), mas com capacidade computacional e de comunicação, se conectarem
à Internet. A conexão com a rede mundial de computadores viabilizará,
primeiro, controlar remotamente os objetos e, segundo, permitirá que os
próprios objetos sejam acessados como provedores de serviços. Estas novas
habilidades, dos objetos comuns, geram um grande número de oportunidades
tanto no âmbito acadêmico quanto no industrial.

Este conceito estrito precisa ser, entretanto, ampliado, englobando também os

objetos inteligentes ou, ao menos, a eletrônica que confere essa inteligência a máquinas
e sensores, por motivos que analisaremos em seguida.

1.1 Um pouco de história

A origem da IoT está ligada à automação industrial. As redes de sensores e

atuadores industriais eram inicialmente conectadas entre si (e à rede de computadores da
indústria) por protocolos proprietários de cada fabricante. Essas soluções, embora
robustas e funcionais, padeciam de interoperabilidade entre fabricantes. Se a empresa
adquirisse maquinário dotado de sensores/atuadores próprios, haveria necessidade de
desenvolver um gateway de interconexão entre a rede legada e a nova máquina. Este
era um trabalho de engenharia complexo, caro e demorado.

3
 Essa realidade motivou numerosos estudos sobre interoperabilidade de redes no
ambiente industrial e já várias alternativas consolidadas existem. São redes das quais
se exige a operação segura, em ambientes agressivos e insalubres, com foco
considerável em redução de custos, concomitante à resiliência da operação
(Automation, 2011).
O compromisso entre segurança e baixo custo levou à busca de padrões, não
apenas para a interconexão entre redes de sensores/atuadores, mas também para os
próprios sensores/atuadores (aos quais passaremos a designar “objetos” ou
“dispositivos” indistintamente).
A partir desse ponto, o estudo das redes de objetos, e dos próprios objetos, se
tornou indivisível. Dotar um objeto de capacidade de conexão com protocolos
genéricos, de alta complexidade (para permitir a operação sem falhas), exigiu o aporte
de certa capacidade de processamento (ou inteligência) nos objetos. Uma vez que essa
inteligência foi embarcada, mais usos pode-se fazer dela, a exemplo do pré-
processamento de dados ou tomada de decisões elementares.
A possível interoperabilidade dos protocolos e o baixo custo dos objetos
inteligentes propiciou a extrapolação das fronteiras industriais, com aplicações
comerciais em residências, prédios, agricultura e em áreas públicas. Muito
provavelmente, neste salto, passamos a denominar a essa tecnologia pelo adágio atual,
IoT.
Neste ponto, estamos preparados para tentar, se não uma definição, ao menos um
conceito lógico de IoT.

1.2 Conceito de IoT

Podemos aceitar, sem nos comprometermos com o erro, a ideia de que IoT
envolve objetos eletrônicos, dotados de certa autonomia ou inteligência, conectados a
uma rede que lhes permite contatar, ou serem contatados, por outros objetos. Desta
forma, nosso conceito de IoT engloba não só a conectividade, mas também os objetos.
Esquematicamente, podemos representar o conceito como dois macroblocos: o objeto
inteligente e a interconexão desse objeto à rede, como apresentado a seguir.

4
Figura 1 – IoT como Conectividade + Objeto

Essa representação nos reporta a uma célula na qual o núcleo é formado pela
inteligência do objeto, e a membrana celular, pela conectividade. Essa analogia é útil
uma vez que toda informação externa chega ao objeto através das facilidades de
conexão, da mesma forma que os dados coletados pelo objeto são transmitidos em
sentido inverso.
Considerando essa dicotomia homogênea, entre objeto e conexão, podemos
estudar IoT segundo essas duas aproximações. Por um lado, precisamos entender os
objetos, eletrônicas que foram desenvolvidas para permitir o acesso de baixo custo ao
controle ou memória de máquinas. De outro lado, estará a própria conexão composta
por protocolos que garantam a conectividade segura desses objetos.
Vamos, a seguir, conhecer de maneira genérica, essas duas tecnologias para,
posteriormente, mergulhar, nos capítulos seguintes, em alguns detalhes técnicos
essenciais para a compreensão da tecnologia como um todo.

TEMA 2 – CONECTIVIDADE DA IoT

Ao tratarmos do tópico de conectividade de objetos inteligentes, nossa

imaginação se vê roteada, involuntariamente, para os conceitos de redes tradicionais de
computadores, protocolos padronizados e estruturas clássicas de conexão com a
internet. A conectividade IoT é um tema mais amplo, entretanto,

5
visto que engloba outras formas de interligação entre dispositivos, diversas do
tradicional TCP/IP.
Segundo Ideali (2021, p. 8), a conexão entre objetos e sua inteligência, seja
embarcada no objeto (microcontroladores) ou dispersa na borda (edge e fog
computing) ou internet (cloud computing), é hoje o maior desafio técnico da
conectividade. Isto se deve a exigências bastante particulares de protocolos e técnicas de
interconexão para IoT.
É importante comentarmos que as soluções de conectividade para esses objetos
ainda não estão plenamente sedimentadas, ou seja, não há um protocolo, ou mesmo
tecnologia, padrão de interconexão do objeto com a rede local ou internet. Assim, nosso
estudo precisará contar com certezas tênues, e uma boa dose de incertezas.
Em outro momento, descreveremos alguns padrões de rede de sucesso, usados
em sistemas de sensoriamento ou acionamento industrial, bem como protocolos ainda
em fase de implementação ou testes. Para o momento atual, nos bastará apresentar
conceitos das redes de atendimento aos objetos IoT que subsidiarão os futuros estudos.
Podemos estudar a conectividade a uma rede qualquer sob duas ópticas: física ou
lógica. Do ponto de vista físico, percebemos duas classes distintas de tecnologias: com
o uso de cabeamento (wired, em inglês) ou sem ele (wireless). Do ponto de vista lógico,
enxergaremos a conectividade através dos protocolos, ou algoritmos, que tratam os
dados circulantes pela interconexão, dando-lhes, ao menos, maior robustez e resiliência.
Ao ler este parágrafo, você se lembrou das camadas de redes OSI? Sim, aqui
estão elas novamente. A camada física congrega as interfaces eletrônicas de conexão
com o meio, que, como comentamos anteriormente, podem ser fiadas ou não. Todas as
demais camadas OSI são lógicas, ou seja, códigos computacionais. Um protocolo pode
envolver apenas a camada de enlace, logo acima da camada física, ou subir na pilha,
estabelecendo padrões para as camadas superiores de rede, transporte etc.
Antes de tratar esse aspecto lógico, vamos descrever resumidamente as
possibilidades de conectividade física.

2.1 Conectividade física com fio

6
 A conectividade para objetos IoT nasceu com essa interface nativa. Essa escolha
histórica se deu pela maior resiliência das soluções cabeadas às interferências
eletromagnéticas e à agressividade do meio industrial. O robustecimento das redes sem
fio, já antes da metade da década de 2010, iniciou, entretanto, um processo irreversível
de mudança dessa escolha natural pelas interfaces fiadas. Sensores sem fio são
economicamente mais viáveis do ponto de vista de implantação e manutenção em
relação a seus antecessores cabeados (Ko et al., 2010).
Do ponto de vista de redes industriais, o uso de cabeamento, mormente óptico,
permanece como alternativa de projeto, para conectividade em determinadas condições
altamente agressivas, principalmente por sua imunidade à intensa interferência
eletromagnética (IEM) presente nas linhas de produção. Quando limitações mecânicas
impedem o uso de cabos ópticos, cabos coaxiais são utilizados como alternativa viável.
Para objetos inteligentes com aplicações fora desse ambiente, redes fiadas têm
aplicação cada dia mais restrita. Algumas placas para IoT ainda apresentam interfaces
para cabeamento metálico, disponibilizando conectores RJ45 ou USB, normalmente
com foco na configuração inicial ou como alternativa de segurança. Os protocolos de
comunicação adaptados para camadas físicas ópticas ou metálicas coaxiais são variados
e, por estarem restritos a aplicações industriais, não serão objeto de nosso estudo aqui.

2.2 Conectividade sem fio

A conectividade sem fio é, sem dúvida, a opção mais frequente nas aplicações de
objetos IoT de uso geral. Soluções não cabeadas utilizam majoritariamente
radiopropagação, mas o uso de pulsos de luz é uma solução sem fio alternativa ao uso
de rádio. A interface IrDA (Infrared Data Association), que utiliza luz infravermelha
para transmissão de dados entre duas fontes próximas, é o exemplo mais frequente.
Como a solução, sem uso de radiofrequência, implica em certa proximidade
restritiva, a opção por radiocomunicação é preponderante na conectividade de objetos
IoT.
Em função da aplicação do objeto IoT e das condições do meio no qual ele se
insere, a solução de conectividade pode variar substancialmente. Objetos

7
destinados ao agronegócio, como sensores de características de solo ou válvulas
atuadoras de irrigação, demandam sistemas de comunicação independentes da cobertura
das operadoras de telecomunicações, de baixo consumo de energia e alta resiliência.

Figura 2 – Pecuária de precisão com uso de sensores conectados

Crédito: Ruslan Zagidullin/Shutterstock.

Objetos móveis, a exemplo de sensores de veículos autônomos, por sua vez,

necessitam de protocolos de comunicação capazes de tratar convenientemente a
mobilidade, fornecendo conectividade ubíqua. Soluções de IoT, para uso em residências
unifamiliares e prédios, demandam conectividade de baixo custo, simples e
padronizada.
Podemos citar as LPWANs (tecnologias de radiopropagação de bom alcance,
baixo consumo de energia e taxas de transmissão baixas), a exemplo de LoRa e Sigfox,
como ideias para atendimento a objetos IoT voltados ao agronegócio.
Para permitir a operação em mobilidade, há soluções disponibilizadas pelas
operadoras celulares, como NB-IoT, LTE-M, CAT NB e EC GSM, cada

8
padrão operado em determinadas gerações de equipamentos celulares ou em todas as
gerações celulares, a exemplo do CAT NB. Essas soluções não privadas, com uso de
redes celulares, entretanto, não são boas para suporte de aplicações em residências e
prédios para os quais WiSUM parece ser mais adequado.
Em outro momento, voltaremos a abordar cada grupo de tecnologia com o
necessário aprofundamento. Para subsidiar esse futuro estudo, vamos, a seguir, revisar
os conceitos de camadas de redes.
De forma a darmos foco naquilo que efetivamente utilizaremos neste curso,
abandonaremos o modelo OSI clássico, representado a seguir, para nos focarmos nas
duas primeiras camadas, nas quais os padrões de conectividade para IoT diferem das
demais estruturas de redes.
Esta análise, de parte da pilha OSI certamente, não lhe é estranho. Quando você
estudou o protocolo de rede IP e seu par TCP, particionou-se a pilha na camada de
transporte.

Figura 3 – Modelo OSI clássico de 7 camadas

9
Crédito: Game art assets/Shutterstock.

Antes de iniciarmos a descrição das particularidades das duas primeiras

camadas, com foco nas redes para IoT, vamos repassar o conceito de protocolo para que
não pairem dúvidas sobre sua definição.
Um protocolo é um padrão de comunicação entre máquinas
computacionais conectadas. Esse padrão divide os dados a serem trocados em
segmentos predefinidos, ao quais designamos quadros (ou frames, em inglês). Estes
quadros, possuem, ao menos, um cabeçalho de controle, endereços de origem e
destino, dados úteis e indicador de fim de quadro (Ideali, 2021, p. 26). Como já
aprendemos em nossos estudos de redes de computadores,
cada camada possui seu protocolo próprio e independente, desta forma, podemos falar
em protocolo da camada física (que normalmente é designado pela sigla PHY) ou
protocolo da camada de controle de acesso ao meio (MAC), por exemplo.

1
2.3 Camada física (PHY)

O protocolo da camada física contém os padrões de interface com o meio. No

caso da interface sem fio, que nos interessa para o estudo de IoT, esse protocolo
descreverá a solução técnica de radiopropagação. Em outro momento, aprofundaremos
um pouco mais esse assunto sem descer aos complexos detalhamentos técnicos mais
atinentes à engenharia de telecomunicações. Por hora, nos bastará uma breve conversa
sobre radiocomunicação.
O uso de redes sem fio se tornou um fato corriqueiro em nossas vidas e,
normalmente, não percebemos sua presença e nem nos detemos para meditar sobre sua
natureza. Quando refletimos, entretanto, sobre o funcionamento de um enlace de rádio,
é impossível não nos impressionarmos com a “magia” científica envolvida. Como a
eletrônica é capaz de codificar a informação em pulsos elétricos e, em seguida,
transmiti-los por um meio esparso como o ar ou vácuo?
O entendimento das ondas eletromagnéticas (OEM) nos permitirão explicar
esse processo. Uma OEM é uma emissão de energia, composta, como se supõe, pelo
nome da associação de uma oscilação elétrica e outra magnética. Quando associamos
campos oscilantes elétrico e magnéticos, como ilustrado a seguir, a energia assim
composta ganha a possibilidade de propagar-
se pelo espaço.

Figura 4 – Oscilação eletromagnética

Crédito: Ramos, 2016.

1
 De fato, o que um rádio transmissor faz é tomar uma onda senoidal pura, de
frequência constante (dita onda portadora) e realiza alterações em seu formato,
frequência ou fase. Essas alterações são controladas pelo sinal que desejamos transmitir.
A onda alterada (dita modulada) será então expulsa do meio metálico, onde foi
gerada, para o espaço exterior através de um transdutor. Esse transdutor, que chamamos
de antena, permite que a oscilação modulada seja liberada para o meio externo. A
antena direciona o feixe oscilatório e dá a ele o ganho necessário para que atinja a
antena de recepção.
No receptor, a antena receptora converterá a OEM captada no espaço livre para
uma oscilação elétrica. A eletrônica do rádio, então, decodificará as alterações feitas na
onda portadora, obtendo, finalmente, o sinal que desejávamos transmitir. As primeiras
aplicações de rádio objetivavam a transmissão de sinais de voz analógicos. O diagrama
a seguir ilustra um rádio enlace de voz.

Figura 5 – Radio enlace

Crédito: Medeiros, 2016, p. 99.

A transmissão sem fio de sinais digitais, ou seja, de dados binários, é, em

essência, muito semelhante às transmissões analógicas que descrevemos. Acrescenta-se
apenas um estágio que ajuste os dados binários às necessidades do modulador e a
transmissão se dará da mesma forma que vimos anteriormente.
Transmissões digitais, entretanto, são mais flexíveis que as analógicas em
relação a seu sequenciamento temporal. Podemos perder parte do trem de bits
transmitido sem que isso implique em perda de inteligibilidade da comunicação,
bastando solicitar seu reenvio. Essa flexibilidade permite a criação

1
de técnicas de modulação avançadas, altamente resilientes, com alto aproveitamento do
espectro de transmissão, propícias para o uso em sensores e atuadores IoT.

2.4 Camada de Controle de Acesso ao Meio (MAC)

A camada MAC, como já adiantamos, tem a função de conformar os dados

coletados do meio para que a rede possa acessá-los, ordenadamente e de forma
padronizada.
A figura a seguir ilustra a presença da camada MAC para o padrão LoRa de
conectividade. Nesta figura, a camada de aplicação é empilhada sobre a MAC,
simbolizando a presença de uma aplicação de controle, que normalmente se encontra na
nuvem computacional ou em uma máquina remota.

Figura 6 – Camadas de rede para o padrão WAN

Crédito: Lora, 2017.

A camada MAC envelopa os dados, incluindo o controle do frame (preâmbulo e

fim de quadro), endereço do objeto, seção (caso o objeto seja multifuncional), controle
de erros do quadro e informações de controle do protocolo. Terminado esse processo, os
dados são convertidos em binário (se ainda não o são) e entregues a camada PHY para
transmissão.

1
 Na camada física, os dados, empacotados pela MAC, são seccionados em
tamanhos adequados ao meio de transmissão, ganham novo cabeçalho e, finalmente,
passam pela modulação.
Voltaremos a esses conceitos aprimorando-os, quando descrevermos uma das
interfaces mais comuns de conexão para objetos IoT de uso comercial, o WiFi.

TEMA 3 – ARQUITETURA INTERNA DOS OBJETOS IOT

Em nosso conceito de IoT, introduzimos a ideia da dicotomia entre

conectividade e o objeto IoT. Estudamos, então, brevemente, a conectividade. Neste
tópico, descreveremos os objetos IoT.
Podemos dizer que há objetos IoT próprios e impróprios. Os primeiros são
aqueles objetos criados especificamente para a utilização em IoT. Esses objetos
embarcam, nativamente, a inteligência necessária e as interfaces de comunicação
apropriadas. Há, entretanto, outros, impróprios, que nascem do acréscimo voluntário de
inteligência e conectividade.
Esses últimos são na verdade eletrônicas de controle de máquinas que receberam
uma placa para IoT, que viabiliza a conexão à rede. Por esta via, objetos de uso
cotidiano, como fechaduras eletrônicas, máquinas de lavar, equipamentos de
refrigeração e interruptores elétricos, podem ser conectados “diretamente” à internet
para que possam ser controlados a distância.
Tanto objetos próprios quanto impróprios têm uma arquitetura construtiva
(interna) muito semelhante, a qual discutiremos a seguir, para depois nos debruçarmos
sobre a arquitetura externa, em nosso próximo tópico.

3.1 Arquitetura interna

A arquitetura construtiva, do hardware, de um objeto IoT é comumente

denominada arquitetura interna. Essa denominação tem por objetivo distinguir esse
desenho daquele outro que engloba a conectividade e a eventual partição da inteligência
com a nuvem.
Para que um objeto seja capaz de conectar-se a uma rede ou à internet, será
necessária uma arquitetura de controle e atuação, ao menos, elementar. Trata-se de uma
estrutura eletrônica interna ou arquitetura interna, que permita

1
a conexão com a rede, além de certa inteligência local. Essa inteligência facultará o
sensoriamento ou a atuação do objeto no meio, tratando convenientemente o protocolo
de comunicação, em ambos os sentidos.
Santos et al. (2016) divide a arquitetura interna em seis blocos funcionais (veja
figura a seguir): comunicação, identificação, semântica, computação, sensores e
atuadores (serviços). Por se tratar de blocos funcionais, podem ser, do ponto de vista
eletrônico, agregados em um único ou em vários componentes eletrônicos.

Figura 7 – Blocos funcionais da arquitetura interna

3.2 Blocos funcionais da arquitetura interna

A clara definição de IoT, como já comentamos, é ainda lacunosa, desta forma, a

definição dos objetos inteligentes que se conectam à rede também o será. Apesar dessa
nossa falta de precisão teórica, é possível definir algumas características de desenho,
necessárias à operação de um objeto IoT. A esta coleção de características,
denominaremos arquitetura interna do objeto.

1
 Seguindo o proposto por Santos et al. (2016), podemos dividir a arquitetura
interna em seis blocos funcionais. Naturalmente, dada a aplicação do objeto, alguns
blocos podem estar ausentes. Vamos, então, descrever cada possível bloco, iniciando
por aqueles essenciais a um objeto IoT.
O bloco essencial de Computação controla os demais blocos do objeto,
contém seu código fonte e determina a função do objeto. Esse bloco define quais os
objetos próprios e impróprios, que antes comentamos. Todo objeto IoT deve possuir
certa inteligência que permite tratar os protocolos complexos de comunicação e controla
a atuação do objeto no meio.
O bloco de serviços ou atuação permite a ação do objeto no meio. Trata-se
da eletrônica de controle do objeto. Tome o exemplo de um objeto impróprio: imagine
uma máquina de lavar roupa que recebeu uma placa de IoT, a eletrônica de controle
(bloco de atuação) é nativa a esse objeto. A placa IoT apenas agrega o bloco de
computação e comunicação. Neste caso, a computação extrai, dos dados presentes nos
frames do protocolo de comunicação, os comandos de operação e comanda a eletrônica
de controle da máquina de lavar, como você faria se a operasse presencialmente.
O bloco de sensores, por outro lado, nos permite ler informações do meio
que serão empacotados pelo bloco de computação e enviados para a conexão com a
rede. Retomando o exemplo da máquina de lavar à qual conectamos uma placa de IoT,
podemos querer receber informações sobre a fase de execução de uma lavagem, o bloco
sensor será responsável por adquirir esses dados e disponibilizá-los para a computação.
Certamente, podemos imaginar objetos que possuam apenas um desses dois
blocos anteriores. Um barômetro, por exemplo, pode ter apenas a função de sensor de
pressão atmosférica em dado local, sem que nenhuma ação seja a ele associada. Desta
forma, os blocos de atuação e serviços podem coexistir, ou não, em um mesmo objeto,
mas ao menos um desses blocos é essencial à existência do objeto.
O bloco de comunicação e de identificação não será aqui descrito, uma
vez que corresponde à parte da conectividade IoT, realizada pelo objeto. Já dedicamos
todo um tópico anterior à conectividade, incluindo a descrição desse bloco. Neste ponto,
basta citarmos que a conectividade é um bloco essencial a todo objeto IoT.

1
 O bloco “Semântica” refere-se aos algoritmos de tratamento dos dados
obtidos pelos sensores. Esses algoritmos podem estar ausentes em muitos objetos,
principalmente nas versões iniciais e nas eletrônicas mais econômicas. Eles permitem a
extração de conhecimento das informações colhidas, ou seja, realizam um pré-
processamento dos dados, transmitindo somente a fração desses dados que possuam
informações, ou alterando os dados, de forma a agregar-lhes valor.
Para exemplificar o que afirmamos, imagine uma câmera de vídeo de segurança.
Se esse objeto não possuir o bloco de semântica, transmitirá as imagens captadas
continuamente para a rede, ocupando banda e limitando a capacidade da rede. O bloco
de semântica poderá interpretar a imagem, enviando apenas quadros alterados, ou seja, a
rede só será acessada para transmitir alterações da imagem.
Neste exemplo, a semântica está selecionando os dados que contém
informações. Podemos imaginar uma semântica ainda mais complexa: suponha que
equipemos o objeto com uma pequena rede neural capaz de identificar silhuetas
humanas. Agora, as transmissões não contêm apenas informações, mas informações
valoradas pela inteligência semântica.
Talvez você esteja se questionando o porquê de esse bloco não ser parte
integrante do bloco de computação. Esta, de fato, é uma discussão teórica válida. A
literatura científica tem preferido dividir computação e semântica, como blocos distintos
dos objetos IoT, posto que todos os objetos devem possuir o bloco de computação. O
bloco de semântica, por sua vez, não é essencial, sua existência é benéfica para
desonerar o tráfego de rede ou mesmo para reduzir o processamento de nuvem, mas não
é impositiva, na maioria dos casos.
Por outro lado, voltando aos objetos impróprios, a placa IoT, associada por nós
ao sistema de controle, antes presente no equipamento, não complementará apenas as
funções de gerenciamento e conectividade, mas, eventualmente, acrescentará
capacidade semântica à supervisão do objeto. Na figura a seguir, temos um exemplo de
placa para IoT, a famosa Arduino Uno.

1
Figura 8 – Placa para IoT Arduino (Uno AT mega 328)

Crédito: Hendrik Sejati/Shutterstock.

Certamente, você está curioso quanto às placas IoT, voltaremos a elas em breve,
vamos agora comentar sobre a arquitetura lógica para que, em seguida, possamos
examinar a arquitetura externa dos objetos.

3.3 Arquitetura Interna Lógica

Como já sabemos, um mesmo objeto pode ter blocos de sensores e atuadores.

Também é possível imaginarmos dispositivos com mais de um sensor ou mais de um
atuador. Examine o exemplo de um sensor de temperatura e umidade, como ilustrado a
seguir. Neste caso, há dois sensores em um único objeto.

1
Figura 9 – Sensor de temperatura e pressão

Crédito: Jerome Quek/Shutterstock.

Do ponto de vista de arquitetura de HW e funcional trata-se de um sensor

apenas, mas, para que possamos endereçar cada dado individualmente, será necessário o
conceito de arquitetura lógica.
A arquitetura lógica de um objeto IoT é bastante simples, basta segregarmos em
uma camada o dispositivo (device) e abaixo dela uma camada com as funções do objeto
(traits, em inglês, por analogia à programação) e finalmente os atributos de cada função
(atributs).

Figura 10 – Arquitetura lógica

Crédito: Gian Carlo Brustolin.

Desta forma, para o exemplo da Figura 9, anterior, teríamos o dispositivo com

duas funções: termômetro e barômetro. A função termômetro pode ter

1
atributos como forma de medida (média horária, por exemplo) e unidade (Celsius ou
Fahrenheit).

TEMA 4 – ARQUITETURA EXTERNA DOS OBJETOS IOT (IoT-A)

Já sabemos que um objeto IoT, necessariamente, embarca certa inteligência

(semântica ou não), conectividade com a rede e capacidade de sensoriamento e/ou
atuação. O custo de um objeto está substancialmente ligado à sua capacidade de
processamento local.
Objetos simples, como lâmpadas, ventiladores ou fechaduras, precisam de
eletrônicas mais espartanas e baratas, para que sejam comercialmente viáveis. Colocar
parte do processamento em aplicações externas, como ilustrado a seguir, é uma solução
que permite essa restrição econômica.

Figura 11 – IoT conectado a serviços de nuvem

Crédito: Monk, 2018.

Essa solução implica no vínculo do objeto, não só com sua arquitetura interna,
mas com uma macroarquitetura que também contemple sua conexão e

2
as facilidades de processamento externas. Essa macroarquitetura é denominada IoT-A.
De forma genérica, pode-se pensar a IoT-A como composta por três
camadas: percepção, rede e aplicação. Na camada de percepção, estariam os
objetos inteligentes. Dispositivos de roteamento e gateways comporiam a camada de
rede, ao passo que as aplicações de controle e análise de dados determinariam a última
camada.
Essa IoT-A simplificada pode ser útil em algumas aproximações mais genéricas,
a exemplo da definição de uma estratégia de segurança, mas será insuficiente quando
desejamos entender a tecnologia de forma mais profunda.
Maschietto et al. (2021, p. 62 e seguintes) propõe modelos compostos por
camadas funcionais que examinaremos a seguir. Antes de iniciarmos, entretanto, será
útil conceituarmos superficialmente o que o autor chama de midleware.
Esse conceito não é exatamente uma novidade, sempre que se faz necessário
interconectar uma aplicação de nuvem a distintos sistemas operacionais, é necessária a
presença de um tradutor intermediário, dito middleware (Red Hat, 2021). O mesmo se
aplica a soluções para IoT, dada a grande variação entre as implementações de HW e
SW envolvidas.
Maschietto parte de um modelo de três camadas, cada acréscimo de camada, a
partir dessa arquitetura básica, retira do objeto IoT parte de sua eletrônica,
simplificando-o e, consequentemente, reduzindo seu custo. Esse ganho somente se
justifica em soluções de escala, ou seja, acrescentar camadas externas a uma coleção de
objetos IoT, só tem sentido econômico se a coleção for numerosa.

4.1 IoT-A de três camadas – Front-Loaded

Quando poucos objetos estão presentes em uma rede, um modelo de três

camadas é mais eficiente. Neste caso, o objeto conterá todos os blocos funcionais,
descritos anteriormente, embarcados. Nesta arquitetura, também chamada front-loaded,
o dispositivo conecta-se diretamente a uma rede de transporte (a exemplo da TCP) e,
posteriormente, a de aplicação, presente na rede ou a ela conectada, como ilustrado a
seguir.

2
 O primeiro modelo, IoT-A de três camadas, presume a presença do gateway de
comunicação na eletrônica embarcada dos objetos. Serão objetos de maior custo, porém
de alta flexibilidade e facilidade de uso.

Figura 12 – IoT-A de três camadas

Crédito: Elaborada com base em Maschietto et al., 2021, p. 62.

Este modelo também permite estruturas de comunicação em mesh para

atendimento de redes de sensoriamento mais amplas, como no caso de sensores e
atuadores para agricultura de precisão. Neste caso, além da comunicação direta, existe a
possibilidade de comunicação entre dispositivos a arquitetura front loaded recebe a
segunda denominação de smart client.
Nestas aplicações, embora a quantidade de sensores indique o uso de uma
arquitetura com mais camadas, a complexidade imposta pelas dificuldades de
comunicação exige a presença de um gateway no dispositivo para processar o
protocolo de comunicação. WMN (Wireless Mesh Network) são redes nas quais os
objetos (ditos nós) são capazes de autoconfiguração, assumindo, quando necessário, a
capacidade de gerenciamento e roteamento (Akyildiz et al., 2005) dotando a rede de
alta resiliência.
Neste modelo arquitetônico de três camadas, o processamento local, no objeto,
pode conservar vários níveis de complexidade, mas sempre dependerá do controle
realizado em máquina externa, como em todas as arquiteturas IoT.

4.2 IoT-A de quatro camadas – Spoke-hub

Como acabamos de ver, o modelo de três camadas exige uma eletrônica de certa
autonomia, residente no objeto. Para soluções compostas de grande número de objetos,
em operação padrão, outro modelo pode ser pensado. Sem

2
exigências profundas de resiliência para o bloco de comunicação, podemos reduzi-lo,
inserindo uma quarta camada, que atue como interface para a conexão, conforme
ilustrado a seguir. A esse modelo, chamaremos spoke-hub, em inglês.

Figura 13 – IoT-A de quatro camadas

Crédito: alaborada com base em Maschietto et al., 2021, p. 63.

As funções de coleta e atuação seguem embarcadas no objeto, mas há uma

camada de adaptação, externa aos objetos, que permitem o trânsito de informações
bidirecionais, com um protocolo de comunicação de alto nível.
Neste modelo, assim como no de três camadas, o processamento local
permanece no objeto, podendo ter complexidade discriminatória. Naturalmente,
podemos simplificar ainda mais os objetos em um modelo com mais uma camada, se
reduzirmos ainda mais a autonomia de comunicação e parte do processamento local.

4.3 IoT-A de cinco camadas

A arquitetura de cinco camadas, ilustrada a seguir, manterá, nos dispositivos,

blocos mínimos para a operação. A camada de percepção (onde estão os objetos) inclui
sensores e leitores simples conectados a um gateway

2
externo. A camada de rede faculta a conectividade dos objetos com plataformas de
comunicação, como na arquitetura anterior, porém a camada de gerenciamento opera os
objetos e a função semântica e de pré-processamento será assumida por camada de
processamento externa.

Figura 14 – IoT-A de cinco camadas

Crédito: elaborada com base em Maschietto et al., 2021, p. 65.

Como enfatizamos ao iniciar este tópico, a escolha da IoT-A depende

essencialmente da aplicação e do número de dispositivos envolvidos. Em nosso próximo
tópico, vamos explorar um pouco as aplicações possíveis desses objetos, mas antes
devemos comentar sobre uma camada acrescentada recentemente na estrutura IoT.

4.4 Camada de negócio

2
 Considerando o emprego de IoT, principalmente em cidades inteligentes, como
meio de extração de massas de dados, que permitem tratamentos estatísticos e de
aprendizagem profunda, uma nova camada pode ser imaginada na IoT-A. Por esse viés,
objetos IoT ganham valor como coletores de dados e atuadores para viabilizar ganhos
de conforto, econômicos e de sustentabilidade na vida urbana.
O tratamento dos dados, entretanto, será o principal responsável pelo ajuste das
decisões, que eventualmente retornam à camada de objetos, para sua concretização, por
meio dos atuadores, presentes na rede. Estudaremos esses assuntos, com boa
profundidade, mas, por hora, basta-nos entender que esse novo emprego da tecnologia
justifica o acréscimo de uma camada de negócio, à arquitetura de cinco camadas,
responsável pelo tratamento dos dados.
Santana et al. (2019, p. 78), sondando a literatura científica, propõem um
modelo de cinco camadas no qual a camada de processamento de informações, descrita
na Figura 14, é absorvida pela camada de aplicação, como pré- processamento para uso
bruto da informação. Sobre a camada de aplicação surge, então, a camada de negócio,
responsável pela inteligência de dados, fornecendo gráficos, análises, modelos etc. A
figura a seguir ilustra esse modelo alternativo de cinco camadas.

Figura 15 – IoT-A de cinco camadas com camada de negócios

2
Crédito: elaborada com base em Santana et al., 2019, p. 79.

TEMA 5 – PROJETOS DE IOT E CAMADA DE APLICAÇÃO

Objetos IoT devem ser proporcionalmente baratos em relação aos demais custos
de rede. Nesses custos, devemos incluir não só a aquisição, mas também os valores de
operação e manutenção dos dispositivos.
As possibilidades de aplicação desses objetos inteligentes, conectados à rede,
principalmente às nuvens da internet, são virtualmente infinitas. A escolha do objeto, ou
seja, de sua arquitetura interna e da IoT-A, entretanto, determinarão o sucesso do
projeto. Analisaremos agora algumas vantagens e desvantagens das IOT-A estudadas
bem como os protocolos de comunicação da camada de aplicação.

5.1 IoT-A e Critérios de Projeto

Examinemos o exemplo de uma instalação industrial, com grande coleção de

leitores RFID, sensores de esteiras e acionadores de máquinas. Leitores

2
RFID coletam somente dados, o processamento local se limita à verificação da validade
das leituras. Sensores de esteiras, da mesma forma, apenas coletam dados, a análise de
divergência precisa ser realizada pela máquina computacional que conhece quais devem
ser os padrões de operação, para cada processo produtivo específico.
Se escolhermos uma arquitetura de três ou quatro camadas, dada a grande
quantidade de objetos, os recursos necessários de endereçamento serão elevados, além
disso, o processamento local, nesses casos, como entendemos, é pouco útil. Retirar boa
parte da inteligência do objeto, senão toda, é um caminho interessante para conter
custos. Neste caso, uma arquitetura de cinco camadas é uma escolha viável.
Naturalmente, essa opção arquitetônica tornará os objetos mais “rústicos”,
exigindo do projetista um esforço maior para controlá-los. Certamente, será necessário
agir nos níveis mais baixos de programação, entendendo a comunicação binária e as
instruções de controle de cada tipo de objeto.
Vamos imaginar, agora, uma instalação predial. Neste prédio, cada sala possui
um equipamento de climatização, ao qual queremos embarcar certa inteligência. Os
equipamentos devem perceber, além da temperatura, a presença de pessoas no ambiente
para decidir pela ativação, por exemplo. Suponha que a iluminação de cada ambiente
também seja decidida em função da luminosidade local e da presença.
Neste caso, implementar uma arquitetura que retire a inteligência da borda pode
ser pouco viável. Transportar todos os dados de temperatura, ocupação das salas e
luminosidade, através da rede, para decisão central, apenas ocuparia a rede e o
processamento do controlador. Uma arquitetura de três camadas será mais eficiente e
econômica, deixando-se à aplicação de controle geral, funções de alto nível, como
determinar os valores-limites de ativação ou mesmo horários de bloqueio.
Essa opção arquitetônica dará ao projetista certo distanciamento dos objetos,
permitindo uma programação de mais alto nível, focada no cálculo e controle de
parâmetros de operação e não no controle direto dos objetos.
Além do processamento local, podemos, nesta implantação, conceder aos
objetos, também, processamento colaborativo, de borda (ou edge computing). Imagine
que se detecta a presença de grande quantidade de pessoas em um

2
ambiente, tornando os esforços de refrigeração menos eficientes naquele local.
Equipamentos em salas próximas podem ser acionados para complementar a demanda
por refrigeração.
Essa decisão não precisa ser tomada de forma centralizada, pela aplicação de
controle, mas pode ser delegada aos próprios objetos. O controle desse
coprocessamento, normalmente, é deixado a cargo do midleware, residente em um
objeto mais complexo, ou em uma máquina autônoma próxima. Não há limites para
este downsizing, plataformas de middleware podem agregar algoritmos de IA
sintetizando dados ou alterando os parâmetros de
decisão autonomamente.

5.2 Protocolos da camada de aplicação

Observando as várias IoT-As, a camada de aplicação se mantém inalterável,

como bloco único. Isto assim se faz, para manter a interoperabilidade de uma rede IoT,
em relação a seus usuários externos à rede. A camada de aplicação, entretanto, para
permitir essa transparência, precisa conviver, do lado IoT da rede, com objetos cuja
capacidade de processamento e memória são baixos.
Tradicionalmente, essa comunicação cliente-servidor é baseada em HTTP, para
redes IP, compostas por “objetos” de alta capacidade de armazenamento e
processamento. Um protocolo adaptável a essas limitações precisa ser concebido. A
resposta a essa demanda são protocolos como MQTT e CoAP, vamos detalhá-los então.

5.3 CoAP

Constrained Application Protocol (CoAP) é um protocolo que busca reduzir o

HTTP, mantendo as funcionalidades básicas, tais como GET, POST, DELETE e PUT,
sobre comunicação sem conexão (como UDP, por exemplo). O desenho do protocolo
inclui duas camadas, em sua arquitetura interna, permitindo a interação seguindo os
princípios REST.
Na primeira camada, reside o controle dos mecanismos próprios de
requisição/resposta. Já na segunda camada, o protocolo detecta duplicidade de
mensagens, permitindo comunicação confiável, mesmo em ambientes sem

2
conexão. Para que essa comunicação seja possível, dois tipos de mensagens são
produzidas no CoAP: confirmáveis e não confirmáveis. As mensagens confirmáveis
demandarão a recepção de um acknowledgement, garantindo sua chegada ao destino.
A arquitetura do protocolo baseia-se na criação de Universal Resource
Identifiers (URIs) que permitem a um sensor publicar no servidor informações sobre
serviços distintos por ele disponibilizados.
Feita a publicação, a informação estará disponível no servidor para ser
consumida por todos os assinantes do serviço. Essas facilidades têm um custo de
processamento, que não pode ser assumido por todos os objetos IoT. Dispositivos mais
restritos necessitam de um protocolo ainda mais simples, o MQTT.

5.4 MQTT

Message Queue Telemetry Transport (MQTT) é um protocolo com foco em

dispositivos limitados ao extremo. Criado inicialmente pela IBM e, posteriormente,
padronizado pela norma ISO/IEC 20922.
Esse protocolo pressupõe não apenas limitações de memória e processamento,
mas também de banda disponível para a transmissão, que é uma preocupação bastante
razoável, para boa parte das aplicações de IoT, conforme veremos em outro momento.
Desta forma, a implementação utiliza baixo overhead, no empacotamento de dados.
O protocolo MQTT opera em ambientes conectados (como TCP) e cria uma
arquitetura com três elementos principais, ditos subscriber, publisher e broker. No
caso do IoT, temos o gateway (ou servidor, dependendo da IoT-A), como broker, e o
sensor, como publisher. Nesta arquitetura, o publicador insere dados no broker sobre
determinado tema, acessível a todos os assinantes desse tópico. A figura a seguir ilustra
a arquitetura.

Figura 16 – Arquitetura Publish-Subscribe

2
Fonte: Thangavel et al., 2014, p. 2.

Uma vez que a informação fica disponível no servidor, a comunicação entre

assinantes e sensores é assíncrona, o que reduz significativamente as necessidades de
uso do meio para comunicação, principalmente por parte dos publicadores. O protocolo
possui alguns recursos de controle de qualidade de serviço (QoS) de rede, selecionáveis
em três níveis de qualidade.
Uma implementação, bastante popular e livre desse protocolo, é o servidor
Mosquito, que implementa a maioria das facilidades previstas na norma ISO/IEC
20922.

FINALIZANDO

Nesta etapa, buscamos construir um conceito de IoT associado aos objetos

inteligentes e suas aplicações. Entendemos que a escolha de um objeto, para um dado
uso, depende das arquiteturas interna e externa possíveis, bem como das restrições de
conectividade presentes no meio. Estamos agora prontos para conhecer algumas
aplicações importantes desses objetos em outros momentos.

3
REFERÊNCIAS

AKYILDIZ, I. F.; WANG, X.; WANG, W. Wireless mesh networks: a survey.

Computer networks, v. 47, n. 4, p. 445-487, 2005.

AUTOMATION, R. Converged Plantwide Ethernet (CPwE) Design and

Implementation Guide. 2011. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.352.6198&rep=rep1
&type=pdf>. Acesso em: 26 set. 2022.

BRUSTOLIN, G. C. Redes para IoT – Aula 1, Material Didático para Roteiro de

Aprendizagem do Curso de Tecnologia em Redes de Computadores. Curitiba:
Intersaberes, 2022.

IDEALI, W. Conectividade em Automação e IoT. Rio de Janeiro: Alta Books

Editora. 2021.

KO, H-S. et al. A statistical analysis of interference and effective deployment strategies
for facility-specific wireless sensor networks. Computers in Industry, v. 61, n. 5, p.
472-479, 2010.

LORA Alliance. Lorawan 1.1 Specification. 2017. Disponível em

<https://resources.lora-alliance.org/technical-specifications/lorawan-
specification-v1-1>. Acesso em: 26 set. 2022.

MASCHIETTO, L. et al. Arquitetura e Infraestrutura de IoT. Grupo A, 2021.

(MB)

MEDEIROS, J. C. de O. Princípios de telecomunicações: teoria e prática. 5. ed.

São Paulo: Érica, 2016.

MONK, S. Internet das Coisas: uma introdução com o Photon – Série Tekne.
Grupo A, 2018.

RAMOS, A. Eletromagnetismo. Editora Blucher, 2016.

RED Hat. O que é Middleware e para que serve. Disponível em:

<https://www.redhat.com/pt-br/topics/middleware/what-is-middleware>. Acesso em: 26
set. 2022.

SANTOS, B. P. et al. Internet das coisas: da teoria à prática. Belo Horizonte:

UFMG, 2016.

3
SANTANA, C. et al. Teoria e prática de microserviços reativos: um estudo de caso na
internet das coisas. Sociedade Brasileira de Computação, 2019.

THANGAVEL, D. et al. Performance evaluation of MQTT and CoAP via a common

middleware. In: 2014 IEEE NINTH international conference on intelligent sensors,
sensor networks and information processing (ISSNIP). IEEE, 2014. p. 1-6.

3
IOT – INTERNET DAS COISAS
AULA 2

Prof. Gian Carlo Brustolin

CONVERSA

Até aqui, quando conhecemos o conceito de IoT e as arquiteturas de objetos

inteligentes, citamos exemplos de uso dessa tecnologia, em aplicações industriais, no
agronegócio e em edificações comerciais ou residenciais. Nesta etapa, vamos conhecer,
com certa profundidade, esta última aplicação, em edificações, cujo estudo e projeto
recebe o nome de domótica.
Tradicionalmente, a domótica era focada em automação e controle de pequenas
tarefas, baseadas em eletrônica embarcada, como iluminação e abertura de portas e
portões em edificações residenciais. Neste estudo, veremos como os objetos e redes IoT
se tornaram aplicáveis em projetos de automação residencial que evoluíram a domótica
em direção à ideia da casa inteligente. Além da plena conectividade, a domótica passou
a contar com soluções de cognição, bastante inovadoras, para uso residencial, simples e
econômico (Stevan; Farinelli, 2018, p. 16).
Conheceremos, ainda, alguns objetos inteligentes, próprios para domótica e
entenderemos de que forma placas para IoT podem automatizar utilidades domésticas,
existentes comumente nos lares. Iniciaremos, também, o estudo sobre a conectividade
para domótica, que certamente perturba a todos os usuários das facilidades propiciadas
pela internet. Essa temática será objeto de aprofundamento posterior, em que,
finalmente, compreenderemos como projetar e configurar corretamente um sistema
WiFi residencial.
Peremptoriamente, analisaremos em conjunto as oportunidades de
empreendedorismo, com o uso do conhecimento que adquirimos. Vamos, então, dar
início nesse interessante estudo.

TEMA 1 – INTRODUÇÃO À DOMÓTICA

Com início artesanal, várias soluções para domótica são hoje produzidas em
escala, permitindo a automação de boa parte das atividades domésticas. O envolvimento
de IoT é recente, mas já há equipamentos de baixo custo disponíveis. O próximo passo,
de inserção de inteligência, propiciado pelos objetos IoT e sua arquitetura IoT-A de
processamento em nuvem, em breve popularizará as já existentes aplicações para casas
inteligentes. Vamos entender como isso é possível.
1.1 Um pouco de história

A domótica tem uma história relativamente recente, ligada à popularização dos

semicondutores na década de 1970. A partir daquele momento, a criação de artefatos
eletrônicos se tornou economicamente viável, mesmo para projetos artesanais. Técnicos
em eletrônica projetavam e produziam suas placas de circuito impresso, para automação
de portões, interfones, câmeras de segurança, entre outros novos confortos e facilidades,
para os lares daqueles que podiam contratá-los.
Por serem projetos únicos, a manutenção não poderia ser simples. Normalmente,
o projetista se tornava, também, o mantenedor eterno da solução que a criou. O tempo
selecionou os projetos mais comuns e estes foram incorporados à indústria.
Atualmente, em uma loja de departamentos, provavelmente encontraremos,
disponível para aquisição imediata, mais de uma solução para a mesma facilidade de
conforto ou segurança doméstica. Tomemos o exemplo de portaria eletrônica,
equipamentos produzidos em série, que agregam facilidades, como comunicação por
voz, imagem, controle de fechadura, acionamento de portões e, em boa parte dos casos,
permitem o acesso remoto, pela internet.
Essa disseminação passou a demandar o desenvolvimento de acionadores e
sensores que compartilham parte de sua arquitetura com dispositivos utilizados em
automação industrial. Embora ainda em estágio inicial, a ideia de importar as soluções
utilizadas nas modernas redes interoperáveis de sensores e atuadores industriais é uma
tendência irreversível.
Dotar os objetos de capacidade de conexão com protocolos genéricos de rede
exige embarcar certa inteligência nesses dispositivos. Presente a inteligência, mais usos
dela é possível extrair. Dessa forma, a ideia da casa inteligente se vê viabilizada.

1.2 IoT-A para domótica

Aplicações residenciais precisam ser extremamente fáceis de usar e configurar,

pela óptica do usuário, naturalmente. Como a apresentado na ilustração a seguir, o
usuário busca objetos autoconfiguráveis e que, interconectados com a internet, ou rede
interna, permitem controle simples e homogêneo.
Figura 1 – Objetos autoconfiguráveis para domótica

Crédito: stockwerk-fotodesign/Shutterstock.

Arquiteturas de baixo nível, que demandam programações complexas, são um

bom desafio de engenharia, mas não são aplicáveis em domótica, sob o risco de
retrocedermos aos antigos projetos dedicados, de difícil manutenção e sem
escalabilidade.
A escolha por uma IoT-A, de alto nível, é natural; dessa forma, a arquitetura de
três camadas é sempre escolhida para aplicações em domótica. Prédios inteligentes,
principalmente comerciais, podem admitir arquiteturas com quatro camadas. Nesses
casos, abre-se mão das facilidades de autoconfiguração em prol de sensores/atuadores
mais baratos, que demandarão complementos externos para sua capacidade de conexão
e processamento.
O detalhamento da IoT-A de três camadas está presente em nossa discussão
inicial, vamos apenas relembrar seu desenho (figura a seguir), de forma esquemática e
adaptada à aplicação em domótica.

Figura 2 – IoT-A de três camadas para domótica

Crédito: Maschietto et al., 2021, p. 62.

Como é possível observar, os objetos estão conectados autonomamente à rede

local. Normalmente, essa conexão é sem fio e se dá via WiFi.
A rede local se encarregará da distribuição de endereço, controle de acesso
e, ao menos teoricamente, segurança. A inteligência de
sensoriamento/atuação estará residente no objeto. Na internet, teremos uma aplicação
com a função de comandar os objetos, seguindo o controle do usuário. A mesma
aplicação de nuvem realizará a autenticação dos usuários autorizados. Essa aplicação de
nuvem pode ser desenvolvida por uma empresa prestadora de serviços, que se
responsabilizará por sua manutenção e associará seu fornecimento a outros tipos de
facilidades, como reabastecimento de gás,
segurança patrimonial, manutenção de equipamentos etc.
Aplicações de nuvem gratuitas também existem, fornecidas pelos fabricantes dos
objetos, ou de companhias de internet, como Amazon e Google, mas esse assunto
estudaremos posteriormente.
Para o usuário, essa topologia é transparente. O acionamento dos objetos se dá
de forma similar a um controle remoto local, o que, de fato, está bastante distante da
realidade de rede, como acabamos de estudar.
Nesse ponto, você seguramente está curioso quanto às aplicações e controles
possíveis. Vamos, então, mergulhar, nos próximos tópicos, nos objetos existentes
(próprios e impróprios), na conectividade deles e nas aplicações de nuvem gratuitas.

TEMA 2 – OBJETOS IoT PARA DOMÓTICA

Conhecemos dois tipos de objetos IoT, classificados segundo seu projeto. Há

aqueles que possuem inteligência e conectividade nativas, aos quais denominamos
próprios e outros que necessitam acréscimo de eletrônica
(impróprios). Aqui, vamos conhecer alguns desses objetos e como é possível
acrescentar inteligência e controle a uma eletrônica preexistente.

2.1 Objetos próprios para domótica

Quando fizemos nossa breve revisão histórica da domótica, afirmamos que já

existem, comercialmente disponíveis, objetos inteligentes de baixo custo, para uso em
domótica. De fato, a criação de objetos IoT, próprios para domótica, pode ser encarada
como uma particularidade dos impróprios, cuja aplicação de larga escala tornou a
produção de circuitos eletrônicos dedicados, contendo todos os blocos funcionais,
economicamente viáveis.
Há objetos próprios, que estão suficientemente popularizados, para que
possamos falar deles, sem surpresa alguma. Câmeras de vídeo, caixas de som e sensores
de porta, por exemplo, são dispositivos que podem operar como objetos IoT,
disponíveis em lojas de departamentos.
Existem, entretanto, alguns objetos menos conhecidos, como sensores de CO2,
detectores de metano e sensores de nível de água, com conectividade nativa para WiFi,
ou outras redes para IoT.
A seguir ilustramos um sensor de nível de água com conectividade LoRa. Como
veremos, a seleção dessa interface, embora apresente dificuldades de interconexão
direta com rede WiFi padrão TCP, permite a operação sem alimentação externa, com
uso de baterias pequenas, por vários anos sem necessidade de troca. Essa pode ser uma
vantagem interessante para instalação em locais de difícil acesso e sem rede elétrica
disponível.

Figura 3 – Sensor de nível com interface LoRa

Crédito: Jefferson Schnaider.

Esses objetos, não muito conhecidos, podem ter uma utilidade considerável, no
incremento da segurança residencial. Com o uso de detectores de metano, por exemplo,
podemos evitar a explosão de ambientes em consequência de vazamento de gás de
cozinha. Sensores de CO2 podem evitar o sufocamento de bebês, ou mesmo ligar a
ventilação, em caso de excesso de CO2 em dado ambiente. Aliás, para realizar o
acionamento de um equipamento simples, como um exaustor ou da iluminação, há
interruptores IoT (veja figura a seguir) que se conectam diretamente ao WiFi e
permitem a operação desses equipamentos, diretamente por um aplicativo de nuvem.

Figura 4 – Interruptor de energia inteligente

Crédito: Jefferson Schnaider.

Há vários objetos que atendem, praticamente, a todas as necessidades de

automação residencial. Uma pesquisa na internet é suficiente para localizar uma miríade
de dispositivos. Encontrar, instalar e integrar esses objetos pode ser, inclusive, uma boa
oportunidade de negócios, tópico que discutiremos ainda nesta etapa.
Talvez, depois de pensar sobre os objetos IoT, você pode estar imaginando como
integrar a essa rede objetos domésticos, que não têm conectividade nativa, como
máquinas de lavar e sistemas de aquecimento. Esses são os objetos que podem receber
placas de adaptação, objetos IoT impróprios. Vamos tratar deles a seguir.

2.2 Objetos impróprios para domótica

Ao introduzirmos o tópico, dissemos que máquinas domésticas, como lavadoras,

aquecedores e condicionadores de ar, sem conectividade nativa à internet, podem ter
uma eletrônica agregada que possibilite sua transformação em objetos IoT inteligentes.
A mágica por trás disso são as placas para IoT.
Para entendermos essas placas, devemos voltar ao nosso estudo da arquitetura
interna de um objeto inteligente. Naquele momento dividimos o dispositivo em blocos:
identificação, comunicação, processamento, semântica, serviços e sensores.
Máquinas domésticas, como as que citamos anteriormente, são dotadas de uma
eletrônica embarcada, que permite seu controle local, pelo humano. Dessa forma, são
dotadas dos últimos dois blocos funcionais (serviços e
sensores) e algum processamento, a fim de tornar a interface homem-máquina possível.
O que se pretende é agregar a essas máquinas ao menos os três primeiros blocos, da
arquitetura interna dos objetos IoT.
Por isso, uma placa para IoT deverá conter, minimamente, um processador capaz
de controlar a eletrônica legada e uma interface de comunicação, com a rede TCP
doméstica, preferencialmente sem fio. Essa preferência, no caso das aplicações em
domótica, é importante para que se evite transformar a residência em um emaranhado de
cabos de rede, que certamente desagradaria esteticamente a seus habitantes. Usamos o
termo “preferência” porque existirão objetos que demandarão conexão fiada; sobre essa
discussão, voltaremos em tópico próximo sobre conectividade.
Assim como objetos IoT são produzidos industrialmente e podemos comprá-los
na internet, ou em uma grande loja, placas para IoT também o são.
Seguindo a mesma estratégia pedagógica utilizada para descrever os objetos,
vamos apresentar uma placa para IoT, genérica, pela sua divisão em blocos funcionais.
Os blocos de uma placa para IoT, como mostrados na figura seguinte, podem ser
sintetizados nas funções de processamento, I/O (analógicas e GP), alimentação e
conectividade.

Figura 5 – Blocos rudimentares da placa de IoT

Crédito: Brustolin, 2022.

O processamento de uma placa IoT é composto por um chip de CPU,

normalmente com memórias integradas. Como em uma máquina computacional
tradicional, esse bloco executará a aplicação residente na ROM (firmware), controlando
a placa, a eletrônica legada e a conectividade com a rede.
 Há dois blocos de I/O (In/Out ou entradas e saídas), uma vez que a placa possui
interfaces digitais (um exemplo é a interface USB normalmente presente em placas de
IoT), dita de “propósito geral” (GP – general purpose, em inglês) e analógicas. As
I/Os analógicas permitem a conexão direta a sensores e atuadores, sem a necessidade
de converter níveis de tensão em dados binários. A alimentação de uma placa para
IoT dificilmente é feita pela rede elétrica diretamente, PoIP ou a própria interface
USB, são o uso comum. Uma observação interessante refere-se à capacidade de
adormecimento de algumas dessas placas, que permitem o uso de baterias ou pilhas
sem substituição por
anos.
A conectividade das placas para IoT objetiva a troca de dados com redes TCP
e se dá, predominantemente, pela interface rádio padrão 802.1x, mas como já dissemos,
voltaremos ao tópico de conectividade em breve, dispensando a discussão por ora.
A eletrônica de uma placa para IoT precisa ser bastante compacta, econômica e
flexível, para permitir seu uso nas aplicações de domótica. Para que possamos tomar
contato com essas eletrônicas, a figura seguinte apresenta uma placa IoT Photon, cujas
dimensões se aproximam de uma caixa de fósforos.

Figura 6 – Placa Photon para IoT

Disponível em: <https://www.filipeflop.com/blog/projetos-iot-com-a-particle-photon/>. Acesso em: 3

out. 2022.
 A próxima figura amplia a placa, para que possamos identificar os blocos
funcionais, citados anteriormente.

Figura 7 – Placa Photon para IoT

Crédito: Monk, 2018.

Uma placa para IoT, por ter propósito geral, além do estudo de conexão
eletrônica, precisa ser programada para operar uma máquina residencial. Apenas por
curiosidade, vamos conhecer como essa programação é feita.

2.3 Programação de placas para IoT

Aqui, não temos por objetivo aprofundar os estudos sobre programação de

placas IoT. Apenas forneceremos algumas noções, que serão importantes, caso se
necessite criar aplicação, que integre as placas com outros objetos IoT. Quando
objetivamos programar uma placa para IoT, desejamos, de fato, programar o
processador presente na placa. Você deve estar pensando que estamos para
mergulhar em um daqueles abismos de programação de baixíssimo nível, já que as
placas são muito rudimentares. Essa conclusão está,
apenas, parcialmente correta.
 De fato, toda máquina computacional, mesmo o computador ou celular que você
está, eventualmente, usando para ler esta etapa agora, quando ligado, executa um
programa de inicialização, firmware, que configura o ambiente básico do usuário. Sobre
esse ambiente, será instalado o sistema operacional e as demais aplicações sobre este
último.
A programação de um processador parte desse setup de firmware, cujos
comandos são o próprio conjunto de instruções do processador. Mas, calma, mesmo
nesse baixíssimo nível, há IDEs (Integrated Development Environments) para
auxiliar na codificação em mais alto nível. Precisamos entender, portanto, que nosso
código, para residir na memória não volátil da placa, precisa ser compilado gerando,
inicialmente, o microcódigo (em Assembly). O microcódigo passará um por
assemblador que o converterá em upcode hexadecimal. No momento de gravação na
memória, o upcode será reduzido para binário e, finalmente, gravado!
Naturalmente, a IDE gerencia esse processo e não é necessário, para o humano,
descer ao binário para realizar a tarefa. Por outro lado, é fato que o uso de IDEs, com
linguagens de alto nível, geram códigos de baixa eficiência e alto uso de memória. Esses
são dois fatores a serem evitados em placas para IoT, em que há francas limitações de
espaço de armazenamento e capacidade de processamento (Lenz; Torres, 2019, p. 96).
Isso quer dizer que, se você precisar desenvolver uma interface para essas placas,
precisará ter conhecimento de linguagens mais próximas ao Assembly, como o C, por
exemplo.

TEMA 3 – CONECTIVIDADE IOT PARA DOMÓTICA

Em nossa introdução, comentamos que a conectividade dos objetos IoT, sejam

objetos próprios ou não, é um tema tão importante quanto o próprio objeto. Teremos,
durante nosso estudo, um momento específico para o estudo de soluções de rede para
IoT. Neste tópico, trataremos especificamente da interconexão de objetos por rede
WiFi. A escolha do padrão WiFi se dá pela franca liderança dessa tecnologia em
aplicações residenciais, frente a todas as demais soluções (Tic Domicilios, 2021). Há
um outro padrão relativamente comum, dito ZigBee, usado como alternativa para
conexão de objetos stand alone, quando o consumo de energia dos objetos é um fator
imprescindível para o sucesso do projeto. Esse padrão não será detalhado aqui, mas
reservaremos para ele um breve estudo ainda neste curso.
 As questões de segurança são uma discussão a parte, principalmente em
domótica. A exposição de objetos IoT, de automação residencial, na internet, pode ter
consequências mais danosas que aquelas para redes que não possuam tais objetos.
Trataremos deste tópico de segurança, com detalhes em outro momento, mas não há
cuidado excessivo ao se projetar uma rede sem fio para esse fim, já que os riscos são
consideráveis.

3.1 Introdução ao padrão 802.11 e suas versões

Redes de objetos IoT com conectividade WiFi são bastante comuns e o uso
desse protocolo para IoT não difere dos projetos de redes locais. Dessa maneira, o que
abordaremos a seguir se aplica a redes locais sem fio. As redes sem fio (WLAN –
Wireless LAN) WiFi foram padronizadas pelo Instituto de Engenheiros Elétricos e
Eletrônicos (IEEE) no final do século passado.
No que se refere às versões, a primeira produzida em série foi a 802.11b,
seguida pelo IEEE802.11a, 802.11 g e IEEE 802.11n (que recebeu o apelido de WiFi
4). Esta última versão, com boa velocidade de transmissão, resiliência de conexão e
custo baixo, sacramentou o uso de WiFi como método de acesso preferencial em redes
TCP. O WiFi 4, entretanto, não era perfeito, os problemas surgiram quando a densidade
de usuários das redes começou a subir. Foi necessário, então, contornar o problema de
densidade de usuários. A ideia foi utilizar a solução já sedimentada nas gerações mais
recentes de telefonia celular, adaptando o Multiple-Input Multiple-Output (Mimo), que
passou a fazer parte das versões seguintes.
A primeira versão a utilizar essa técnica, produzida em 2018, foi o IEEE
802.11ac, batizado de WiFi 5. Este ainda é o mais popular em uso corporativo,
enquanto a maioria das implantações residenciais permanece com a versão 4.
O WiFi 5 permite a transmissão de até 400 Mbps, em 2,4GHz e até 7Gbps em
SHF (em condições ideais de propagação). Nessa versão, os problemas de densidade
foram resolvidos, mas como as condições ideais de propagação nunca ocorreram, de
fato, o padrão dificilmente atinge a velocidade prometida.
A observação do comportamento efetivo das colisões de rede deu origem a um
novo padrão, IEEE 802.11 ax, ou WiFi 6, que ainda aguarda uma utilização
extensiva. Novas versões de normas já estão disponíveis no IEEE, mas ainda não há
produtos no mercado que as embarque em número perceptível.
 Em todas as versões (a exceção da versão 802.11 ah, dita HaLow, bastante
recente e de aplicação específica), o IEEE manteve o foco em alto desempenho, baixo
custo e alta densidade de usuários com alta demanda de dados. Dessa forma, o uso de
WiFi para objetos IoT presume que há disponibilidade para alimentação desses
dispositivos. Dispositivos que precisam utilizar baterias próprias, de alta
duração, não podem ser atendidos por WiFi. Esse fato, entretanto, não invalida
a grande quantidade de objetos inteligentes, sem essa restrição, que podem ser
conectados com o uso dessa interface.

3.2 Conexão de objeto IoT ao WiFi

Um objeto IoT, ao ser energizado, inicialmente entra em modo de configuração.

Nesse modo, o rádio interno do dispositivo comporta-se como um ponto de acesso (AP),
gerando uma rede com identificação (SSID) própria. O instalador então conecta-se a
esse AP temporário e fornece as informações de identificação e senha da WLAN na
qual deseja instalá-lo. Em seguida, o objeto é reiniciado e se loga no AP da rede local.
Podemos, então, localizá-lo na rede local e habilitar sua operação pelo aplicativo
de nuvem que controla os objetos da rede.
Muitos fabricantes de objetos têm sites que simplificam o processo de
configuração. Os objetos, após receberem as informações da rede local, ganham acesso à
internet e se logan automaticamente nesses sites. Aqui reside um dos principais
problemas de segurança no uso desses objetos, ao pré-configurar o objeto, deixamos a
rede local acessível para à internet. A segurança é de vital importância, mas trataremos
dela em outro momento.

3.3 Introdução ao padrão IEE 802.15.4g (ZigBee)

A conectividade WiFi foi criada pelo IEEE com foco em desempenho e baixo
custo. Essas interfaces, guardado o que comentamos anteriormente, têm baixa
preocupação com o consumo de energia do rádio e do processamento associado.
O padrão ZigBee teve origem na tentativa de atender a redes de sensoriamento
(WSN – Wireless Sensor Network) para aplicação industrial, com foco em redução
de custos, baixo consumo de energia, baixa taxa de falhas e fáceis de se manterem.
Essas características tornaram, recentemente, ZigBee
uma opção para o agronegócio, para aplicação em agricultura de precisão, por exemplo.
Objetos inteligentes para domótica podem ter demandas semelhantes, quando
são instalados em locações de difícil acesso para a rede elétrica. Limites de propriedade,
caixas d´água, topos de árvores, são exemplos de locações que demandam objetos
stand alone.
O protocolo das camadas superiores do ZigBee não é compatível com o padrão
TCP, exigindo a presença de um gateway de interfaceamento. Se você ficou curioso
sobre os detalhes desse protocolo, acesse a documentação presente em Zigbee, 2020,
referenciada nas fontes de pesquisa desta etapa.

TEMA 4 – CAMADA DE APILICAÇÃO E CONTROLE

Quando descrevemos a IoT-A de um objeto para domótica, apresentamos a

Figura 2, como diagrama esquemático de conexão. Fomos, naquele momento,
propositalmente simplistas. Neste tópico, aprofundaremos nosso conhecimento sobre a
camada de aplicação e controle, típica para objetos IoT, aplicados em domótica.
A escolha de um objeto para domótica está normalmente vinculada à sua
compatibilidade com um “assistente pessoal”, com um gateway ou com uma nuvem
corporativa, a exemplo da Google Home. Vamos agora entender o papel de cada um
desses elementos.

4.1 Solução de nuvem

Há vários objetos IoT para aplicação em automação residencial que são

compatíveis com o protocolo IP e rádio 802.11. Os fabricantes de tais objetos
normalmente seguem o padrão de configuração, que comentamos no tópico anterior e
que disponibilizam integração com algumas aplicações de nuvem de grandes
corporações como Amazon e Google. Essas aplicações podem auxiliar na
configuração do objeto e, posteriormente, permitem seu controle integrado com os
demais objetos.
A nuvem da Google, por exemplo, pode ser controlada diretamente por um
dispositivo móvel. Alternativamente, há também assistentes pessoais, comercializados
por parceiros da empresa, que permitem o controle de forma mais amigável. Um
exemplo desse modelo de controle, com uso de assistente pessoal, é o hardware Echo
comercializado pela Amazon. O dispositivo pode
controlar objetos IoT, além de realizar tarefas de assistência, como busca na internet por
comando de voz, reprodução de músicas etc. O Echo também possui uma IA associada
(Alexa).
A configuração de um Echo é relativamente simples, mas necessita da conexão
ao site da Amazon. O usuário, com o aplicativo Alexa em seu smartphone, é capaz de
personalizar o Echo e acrescentar dispositivos, conforme ilustrado a seguir. A
configuração é concluída com o uso combinado do Bluetouch do smartphone. Esse
recurso evita as buscas por endereços IP e configurações de rede, necessárias no caso de
outras soluções que veremos posteriormente.

Figura 8 – Aplicação de nuvem Amazon Alexa

Disponível em: <https://gizmodo.uol.com.br/alexa-smartphone-nova-tela-inicial-escutar- comandos/>.

Acesso em: 3 out. 2022.

A configuração de dispositivos segue o mesmo procedimento. Será necessário

adquirir objetos compatíveis com a IA da Amazon, mas cumprida essa restrição, todas
as informações necessárias à integração estão disponíveis no servidor da empresa.

4.2 Controle por HW

 Para que um objeto seja controlável em nuvem, conforme já afirmamos, seu
firmware deve ser compatível com as aplicações de nuvem. E se não for? Há uma
segunda solução possível de controle, o uso de um hardware conectado à LAN, dito
gateway IoT. Os gateways podem também receber a designação genérica, leiga, de
hubs inteligentes ou assistentes pessoais. Do ponto de vista técnico, um assistente
pessoal não é um gateway, uma vez que não realiza a conversão de interfaces. Dessa
forma, devemos usar a designação gateway para o hardware que realizará a interface
entre o controle de nuvem ou, no contexto da rede local, por aplicativo de alto nível,
móvel ou não.
O gateway de IoT, para domótica, se conectará com os objetos inteligentes da
residência pelo protocolo IP, da rede local ou por outros protocolos de comunicação,
suportando a interface entre o aplicativo de comando do usuário e esses objetos. Existe
uma boa quantidade de gateways disponíveis no mercado. Comentaremos brevemente
sobre um modelo, para que tenhamos exemplo concreto do que já comentamos.
O gateway Aqara, produzido pelo fabricante chinês Xiaomi integra uma boa
quantidade de objetos ZigBee e WiFi. A configuração desse gateway depende do
acesso a um servidor, mantido pelo fabricante, que contém os pacotes para cada objeto.
O diagrama de conexão é apresentado na figura a seguir. Como já sabemos, o padrão
ZigBee, interface rádio padronizada pela norma IEE802.15.4, suporta conexão a objetos
com menor demanda de energia, em relação ao WiFi, e maior resiliência de conexão.

Figura 9 – Arquitetura de conexão de objetos IoT e gateway Aqara

Disponível em: <https://pt.xiaomitoday.it/xiaomi-possui-500-milh%C3%B5es-de- usu
%C3%A1rios-ativos-em-todo-o-mundo.html>. Acesso em: 3 out. 2022.

Dispositivos gerenciáveis pelo Aqara, com interface rádio ZigBee, podem

permanecer sem troca de bateria por até 2,5 anos.
Concluída a configuração, será necessário utilizar um aplicativo de controle do
gateway. O aplicativo disponibilizado pela Xiaomi é bastante rudimentar, mas há
informações nos sites do fabricante que permitem o desenvolvimento de aplicativo
dedicado.
A Xiaomi, recentemente, buscando uma solução mais simples para o usuário,
integrou o hub com o assistente da Apple, Home Kit, associado com a IA de
assistência, Siri. Outras integrações estão disponíveis, inclusive com a Alexa da
Amazon, mas, nesses casos, ao menos até este momento, é necessário configurar os
objetos no gateway e, posteriormente, integrá-lo a IA.

TEMA 5 – EMPREENDEDORISMO EM DOMÓTICA COM IoT

Aqui, vamos entender algumas oportunidades de negócio ligadas ao IoT e

especialmente relacionadas à sua aplicação em Domótica. Não pretendemos elaborar
um rol taxativo de negócios na área, mesmo porque a própria IoT é uma tecnologia
ainda adolescente e sofrerá constantes e profundas modificações nos próximos anos.

5.1 IoT e mercado de consumo

Se, por um lado, pairam dúvidas sobre o caminho de que a evolução da IoT, por
outro não há questionamento sobre sua presença crescente nos ambientes industriais,
comerciais, públicos e residenciais. Uma boa leitura, para aprofundar este assunto dos
usos e tendências, está em Magrani (2018).
Como forma de exemplificar a significativa compleição dessa tecnologia, para o
comércio, tomemos a questão da satisfação de clientes. Tentar satisfazê- los, em grandes
corporações comerciais, já não é uma vantagem comercial, mas uma questão de
sobrevivência.
Empresas que não possuem sistemas eficientes de avaliação e atuação na
satisfação de clientes perdem participação de mercado, paulatinamente. Prova disso são
os sistemas de CRM (Customer Relationship Management), antes tecnologia
inovadora, fazem agora parte da coleção de SWs essenciais à
administração dos negócios, permitindo gerenciar custos de aquisição de novos clientes,
retenção e manutenção dos clientes conquistados (Lima, 2018, p. 87).
Um diferencial na estratégia de CRM é a resposta rápida aos desejos e
problemas dos clientes. As tentativas, nesse sentido, utilizam, tradicionalmente, estudos
baseados em pesquisas de satisfação e opinião. Mais recentemente aproximações
baseadas em big data e IA aceleram a extração de dados e tornam as conclusões
praticamente instantâneas. O processo, entretanto, é ainda reativo, baseado em dados
passados.
Tecnologias IoT, voltadas ao consumo, podem ser o ponto de inflexão dessa
forma de avaliação de dados para tomada de decisão. Objetos IoT podem ser habilitados
a avaliar necessidades pessoais antes que se tornem impulsos de compra. Podemos
encontrar exemplos de aplicação em saúde, manutenção de veículos, conservação de
prédios etc.
O uso de objetos IoT para esse tipo de aplicação, de predição de consumo, não
apenas beneficia as corporações, mas pode ter impacto positivo na segurança pessoal,
preservação do meio ambiente e qualidade dos produtos.
Certamente, aqui, há várias oportunidades de empreender, dado o estágio inicial
de desenvolvimento da tecnologia.

5.2 Go to Market

Modelos de negócio tradicionais pouco podem ensinar para o “Go to Market”

de um produto IoT. O fato de se tratar de uma tecnologia ainda em estágio inicial faz
com que as possíveis aplicações sejam praticamente infinitas, mas, pragmaticamente,
poucas são implementáveis em curto espaço de tempo. Deve-se esperar uma boa dose
de pesquisa e desenvolvimento para que as soluções se tornem parte da cadeia de
decisão de uma organização ou do dia a dia de um cliente.
Dessa forma, apesar do baixo custo unitário e facilidade de implementação dos
objetos, não se pode esperar que o desenvolvimento de um produto baseado em IoT
tenha essas mesmas características. Estratégias de rápido compartilhamento do custo de
desenvolvimento precisam ser estudadas para viabilizar os projetos.
Um bom caminho é acompanhar a tendência da economia compartilhada, a
exemplo de serviços como Uber, AirBnB, Waze, que permitem a disseminação rápida e
em escala. Outro aspecto, que pode servir de facilitador na remuneração
desses custos é a agregação de IA aos dados coletados pelos objetos inteligentes de
forma a avaliar, de forma preditiva, a experiência do usuário (Magrani, 2018, p. 131 e
seguintes).

5.3 Domótica

As aplicações de objetos IoT em domótica, como pudemos observar no decorrer

de toda a etapa, são múltiplas, de bom custo-benefício e fácil implantação. Dessa forma,
o que sustentamos anteriormente, sobre os problemas de modelagem de negócio, já
estão relativamente superados nas aplicações residenciais. Boa parte dos objetos úteis
para automação residencial já se encontram disponíveis e são integráveis às aplicações
de nuvem.
A criação de um negócio com foco em IoT, para domótica, tem poucas barreiras
de entrada, a exceção do conhecimento técnico, que pode ser por nós adquirida, com
esforço reduzido em relação à população leiga.
Qualquer empreendimento apresenta, naturalmente, alto risco e a simples
vantagem competitiva ligada ao conhecimento não é fator determinante do sucesso.
Planos de negócio precisam ser estruturados e associados a pesquisa de mercado e
demanda. Não há dúvidas que essa aplicação é um campo arável e ainda pouco
explorado, mas há necessidade de substancial apoio mercadológico para qualquer
iniciativa empreendedora.

FINALIZANDO

Nesta etapa, entendemos como objetos IoT podem ser aplicados em prédios e
residências. Estudamos as arquiteturas, interna e externa, necessárias para essa
aplicação, bem como sua solução mais frequente de conectividade. Entendemos a
necessidade de conexão à internet e consideramos os riscos à segurança, provenientes
dessa necessária exposição, deixando sua análise e tratamento para outra ocasião.
Em outro momento, ampliaremos substancialmente nossa visão sobre a
aplicação dos objetos IoT, discutiremos tecnologias emergentes de IoT em smart cities,
tópico empolgante e extremamente interessante para nosso futuro como profissionais de
tecnologia.
REFERÊNCIAS

MASCHIETTO, L. et al. Arquitetura e Infraestrutura de IoT. Disponível em:

Minha Biblioteca, Grupo A, 2021. MB.

LENZ, M.; TORRES, F. E. Microprocessadores. Disponível em: Minha Biblioteca,

Grupo A, 2019. (MB).

LIMA, A. W. B. et al. Indústria 4.0: Conceitos e Fundamentos. São Paulo: Blucher,

2018.

MAGRANI, E. Internet das coisas. Online. Rio de Janeiro: FGV Editora, 2018.
Disponível em:
<https://bibliotecadigital.fgv.br/dspace/bitstream/handle/10438/23898/A%20inter net
%20das%20coisas.pdf?sequence=1&isAllowed=y>. Acesso em: 13 maio 2020.

MONK, S. Internet das Coisas: uma Introdução com o Photon – Série Tekne Grupo
A, 2018. ISBN 9788582604793. MB.

STEVAN Jr, S. L.; FARINELLI, F. A. Domótica - automação residencial e casas

inteligentes com Arduino e ESP826. Disponível em: Minha Biblioteca, Editora Saraiva,
2018.

TIC DOMICILIOS 2021. Pesquisa do CETIC BR. Disponível em:

<https://www.cetic.br/media/analises/tic_domicilios_2021_coletiva_imprensa.pd f>.
Acesso em: 30 set. 2022.

ZIGBEE. Developer Resources Papers. Disponível em:

<https://zigbeealliance.org/developer_resources/?solution_type%5B%5D=zigbe e>.
Acesso em: 5 jun. 2020.
IOT - INTERNET DAS COISAS
AULA 3

Prof. Gian Carlo Brustolin

 CONVERSA INICIAL

Até aqui, conhecemos a aplicação do conceito de internet das coisas (IoT) em

domótica. É bastante provável que esse foi ou será seu primeiro contato com essa
tecnologia. Brevemente, entretanto, nossa relação com objetos inteligentes será muito
mais frequente e comum. Nesta etapa, vamos conhecer a aplicação de objetos
inteligentes e IoT em sistemas públicos de controle de tráfego e veículos autômatos,
entre outras soluções para cidades inteligentes (smart cities).
A ideia de utilizar facilidades tecnológicas, mormente máquinas computacionais
e sua conectividade (as ditas tecnologias da informação e comunicação – TIC), para
otimizar a prestação de serviços públicos não é nova. A questão a ser resolvida era o
alto custo das soluções existentes, dada a quantidade elevada de máquinas e interfaces
para uso público. A consolidação da tecnologia IoT equaciona esse problema de custo.
Novos paradigmas de conectividade estão prestes a tornar viável o sonho da ubiquidade
dos serviços públicos. Esse sonho contempla a otimização de serviços públicos como
provimento de transporte, água, energia; mas, também, permitirá o planejamento
inteligente dos investimentos públicos, dada a disponibilidade de dados, em tempo real,
do comportamento dos contribuintes.
Conheceremos, nesta etapa, alguns objetos inteligentes já desenvolvidos para
cidades inteligentes. Iniciaremos também o estudo do interessante tema de
conectividade para cidades inteligentes, como o fizemos sobre a domótica. Ao final
desta etapa, analisaremos oportunidades de empreendedorismo em cidades inteligentes.

TEMA 1 – INTRODUÇÃO ÀS CIDADES INTELIGENTES

A intensa concentração da população em centros urbanos é um fenômeno

relativamente novo na história humana. O site de internet Wordometer, mantido por
uma associação de cientistas, calcula que, em 2050, 70% da população mundial se
concentrará nos núcleos urbanos. Essa tendência demanda uma dinâmica de
atendimento dos serviços públicos impossível de ser adimplida com mero aumento de
mão de obra nas repartições estatais municipais. O uso de recursos tecnológicos, visto
dessa forma, não tem origem no desejo de conforto da população, mas principalmente
na necessidade de tornar os serviços públicos

2
 viáveis para atendimento a uma população em constante crescimento e concentração.
Tomemos o exemplo da prestação de serviços de saúde. A urbanização gera uma
pressão crescente, sobre o Estado, para que entregue mais e melhores serviços. Essa
pressão, como já percebemos hoje, não poderá ser atendida apenas por novos hospitais e
clínicas, mas mediante soluções de telemedicina e monitoramento de sinais vitais, com
uso de sensores individuais, que certamente estarão disponíveis nas cidades inteligentes,
não apenas universalizando o cuidado com a saúde, mas lhe aportando melhorias. A
definição de cidade inteligente, entretanto, não está ligada apenas ao aporte de
tecnologia, como veremos a seguir.

1.1 O conceito de cidade inteligente

Criar soluções tecnológicas para atendimento a uma população concentrada é

recente – acontece há menos de dez anos. A ideia por trás do aporte de tecnologia nas
cidades inteligentes é o aproveitamento do lado positivo das aglomerações urbanas,
como maior eficiência na distribuição e produção de bens e serviços. Naturalmente, para
explorar tais benefícios, a urbanização deve ser bem administrada (Lofhagen, 2020).
O uso de inteligência de dados, por exemplo, é essencial para o eficiente
planejamento e disponibilização das facilidades de atendimento, gerando a dita
economia inteligente, entendida como um ambiente econômico profícuo para
indivíduos e empresas. Na economia inteligente, serviços públicos como educação e
saúde podem ser redesenhados em função das necessidades locais. O conceito de
cidades inteligentes envolve, também, um ambiente urbano inteligente, e são exemplos
de facilidades ligadas a esse ambiente: controle de iluminação, facilidades de acesso às
informações públicas relevantes e mobilidade urbana inteligente. Lofhagen (2020) ainda
propõe uma outra dimensão, a de governança inteligente. Facilidades de conectividade
facultam a participação em tempo real, da população, nas decisões da Administração
Pública.
Naturalmente, não são apenas esses os avanços possíveis. O tema de
sustentabilidade, por exemplo, também é um dos mais importantes focos de pesquisa em
smart cities. A norma ABNT NBR ISO 37122:2020 é um exemplo de quanto a
produção inteligente, associada a sistemas de economia circular e

3
 tratamento seletivo de resíduos, pode contribuir para o controle de impactos ambientais
(ABNT, 2020).
Cortese, Kniess e Maccarie (2017, p. 7), após conceituarem sustentabilidade
como algo que implica três vertentes, sustentabilidade ambiental, sustentabilidade
econômica e sustentabilidade social, afirmam que

[...] uma cidade sustentável deveria observar os três componentes da

sustentabilidade no seu planejamento. Isso incluiria temas como licitação
verde, construções sustentáveis, redes de transporte coletivo baseadas em
fontes renováveis de energia e destinação adequada de resíduos sólidos e
efluentes líquidos.

As possibilidades são numerosas, mas ainda são poucas as iniciativas

pragmáticas. As primeiras delas surgiram no Japão, onde a concentração de
consumidores de energia elétrica em cidades como Tóquio permitiram investimentos
experimentais em atendimento de demanda inteligente de energia. Naturalmente, foi
necessário desenvolver um protocolo de comunicação eficiente, para esse fim. Esse
protocolo, batizado de WiSUN, foi padronizado pelo Instituto de Engenheiros
Eletricistas e Eletrônicos (IEEE), por meio de suas normas 802.15.4g e 802.15.4.e.
Voltaremos a ele em outro ponto de nossos estudos.

1.2 Smart cities no Brasil

Lai et al. (2020) elencam as características e normas que conduzem a criação de

facilidades inteligentes em cidades e também mencionam avanços relevantes na
implementação, dessas facilidades, em cidades espalhadas em todas as nações. No
território nacional, a cidade citada é Curitiba, capital do Paraná, na Região Sul do país.
Mas Curitiba não é a única cidade brasileira com facilidades inteligentes. Há várias
outras iniciativas em capitais e em cidades populosas no interior do país. Por outro lado,
aqueles que conhecem a capital paranaense sabem que o aporte de tecnologia na cidade
não é tão significativo como essa citação pode aparentar. Algumas facilidades
tecnológicas, presentes em Curitiba, devem, entretanto, ser mencionadas, como controle
de tráfego inteligente e atendimento de emergência inteligente. O principal motivo que
produz a presença da cidade entre as smart cities mundiais, no entanto, está ligado à
intimidade que essa capital possui com a questão da sustentabilidade.
Como comentamos anteriormente, o conceito de cidade inteligente não se limita
ao emprego de tecnologia nos serviços públicos. Há normas e

4
 indicadores ligados ao conforto social, sustentabilidade econômica e ambiental. É
necessário garantir, por exemplo, que o aporte tecnológico não se resuma à mera
automação comercial, com fins de redução de custos para a Administração Pública. De
fato, a questão econômica é importante na mesma medida que os impactos sociais e
ambientais resultantes desses investimentos. Nessa linha, de evolução holística da
prestação de serviço público, a cidade de Curitiba tem, segundo Lai et al. (2020),
merecido destaque entre os demais centros urbanos brasileiros, o que garante sua
presença no rol mundial de smart cities.

1.3 Smart cities e IoT

Você certamente está se questionando sobre a relação entre smart cities e IoT.
De fato, o desenvolvimento de tecnologias inteligentes, sem envolvimento humano, a
exemplo de big data, inteligência artificial (IA) e IoT, são os elos de viabilização do
aporte tecnológico nas cidades inteligentes. A Figura 1 ilustra os componentes
tecnológicos possíveis de uma cidade inteligente.

Figura 1 – Componentes estruturais de uma cidade inteligente

Fonte: Ghazal et al., 2021, p. 432.

5
 Quando imaginamos uma cidade que possua serviços inteligentes de provimento
de energia, água e gás interconectados a prédios inteligentes, sistemas de mobilidade e
infraestrutura dotados de inteligência, conectados à Administração Pública, percebemos
a complexidade tecnológica envolvida nisso. Objetos inteligentes, capazes de
processamento parcial em diversos níveis (fog, edge e cloud), interconectados por
redes resilientes e seguras, são parte indiscutível do aporte tecnológico em smart cities.
Ghazal et al. (2021, p. 434) afirmam que a IoT está no coração das cidades
inteligentes, por ser a tecnologia que permite a digitalização ubíqua, facultando o envio
de dados, tratados ou não, a uma nuvem de decisão. Esses dados serão convertidos em
informações, permitindo a tomada de decisão adaptativa e eficiente. A Figura 2 ilustra
essas conclusões.

Figura 2 – Tomada de decisão adaptativa em uma cidade inteligente

Fonte: Ghazal et al., 2021, p. 435.

TEMA 2 – OBJETOS IoT PARA SMART CITIES

Boa parte da literatura científica, segundo afirmam Gama, Alvaro e Peixoto

(2012), ao tratarem do tema das cidades inteligentes, divide os aportes de TIC, nas
aglomerações urbanas, em ao menos seis dimensões de serviço:

6
 comunicação e governança, saúde, energia, mobilidade ou transporte, educação, água. O
cômputo do nível de maturidade de provimento de cada um desses serviços indicaria o
nível de maturidade da própria cidade inteligente.
Neste tópico, vamos conhecer como alguns desses serviços se relacionam com
os objetos da IoT.

2.1 Smart utilities

As empresas prestadoras de serviços públicos de energia, saneamento e gás são

genericamente chamadas de utilities, em inglês. Nas cidades inteligentes, essas
empresas ganham o epíteto de smart utilities.
As primeiras utilities a incorporarem inteligência em suas redes foram as
distribuidoras de energia elétrica. Essa primogenitura tem origem na afinidade natural
que o fornecimento de energia tem com a tecnologia, pela própria característica da
produção de energia e da operação do complexo sistema elétrico. O negócio de energia
sempre foi inseparável de boa dose de automação. Esse fato tornou naturais os
primeiros ensaios na direção de levar a automação mais próxima às unidades
consumidoras.
Com base no sucesso obtido pela experiência de automação da demanda na
capital japonesa, comentada anteriormente, nesta etapa, processos de estabilidade e
disponibilidade da rede, bem como soluções de microgeração, a exemplo da geração
predial de energia solar, passaram a ser opções para uso de IoT com franca vantagem
em relação aos métodos anteriores, tradicionalmente equacionados por inteligência
computacional adaptativa centralizada.
O aporte tecnológico propiciado pela IoT permitiu, no âmbito desse serviço de
utilidade, a criação das redes elétricas inteligentes (REIs). Segundo Berger e Iniewski
(2015), a arquitetura de uma REI pode ser descrita pela sua divisão em quatro camadas,
seguindo a ideia do modelo de camadas de redes com interconexão de sistemas abertos
(OSI), independentes entre si: aplicação, comunicação, controle de potência e sistema,
conforme ilustrado pela Figura 3.

7
 Figura 3 – Camadas de uma REI

Fonte: Berger; Iniewski, 2015.

Na camada de sistema estão os três negócios ligados ao fornecimento de energia

elétrica: geração, transmissão e distribuição de energia. Os sensores e atuadores IoT
operam na proximidade do consumidor e, portanto, ligados ao negócio de distribuição.
É fato que a automação da REI depende da integração entre os sistemas de controle dos
três negócios; entretanto, para o escopo deste estudo, nos focaremos nas aplicações
dedicadas a esses sensores e atuadores, próximos ao usuário.
Quando estudamos a camada de comunicação dessas redes, para cidades
inteligentes, percebemos ao menos um fator que as diferencia radicalmente das redes
tradicionais. Ao projetarmos ou administrarmos uma rede de área local (LAN)
tradicional, pressupomos que os usuários da rede têm necessidades e interesses não
concorrentes. Naturalmente, nesses casos, precisamos ter atenção com a segurança de
dados, para que um eventual invasor encontre barreiras de acesso. Na camada de
comunicação de uma REI, não há uma necessária relação de afinidade entre usuários.
Mesmo no nível local, em uma rede predial ou rede de área de construção (BAN),
concorrentes comerciais podem compartilhar a mesma rede. Esse problema ganha ainda
maior dimensão quando subimos para o próximo nível de rede, a rede de vizinhança
(NAN), que pode congregar redes residenciais (HANs), de menor

8
 potencial de risco; ou redes industriais (IANs) e BANs de concorrentes. Dessa forma, a
questão da privacidade de dados e da resiliência da rede precisa ser prioritária, no
projeto da interface. Um ator industrial, pouco ético, pode ter forte interesse em causar
uma falha no controle de fornecimento de energia, por exemplo, de seu concorrente,
instalado na mesma NAN.
Como já sabemos, o fornecimento de energia elétrica foi o primeiro serviço de
utilidade pública a ganhar investimentos em automação, graças a sua predisposição
natural a receber esse aporte tecnológico. Mas, embora seja um setor da economia que
permaneça mais avançado em relação às demais utilities, ele não é o único. Iniciativas
no sentido de controle do fornecimento de gás e água, com alto impacto ambiental
positivo, já estão em curso.

2.2 Sensores em cidades inteligentes

As principais aplicações de objetos da IoT, em cidades inteligentes, estão

certamente ligadas a sensoriamento para tomada de decisão. As REIs, que abordamos
anteriormente, são uma proposta interessante por agregarem ao sensoriamento não só a
decisão, mas a própria ação inteligente de alteração das características de operação da
rede. Como podemos imaginar, nem todas as aplicações terão esse ciclo completo.
Vamos conhecer, então, outros sensores típicos para aplicação nos meios urbanos,
seguindo a classificação proposta por Ghazal et al. (2021).

 Sensores de ambiente: esses objetos são responsáveis pela aquisição de

dados ambientais como temperatura, pressão, umidade e iluminação, que
permitem o ajuste de parâmetros de conforto não só em residências, mas
também no mobiliário urbano, com ganhos em termos de otimização de
recursos.
 Sensores biológicos: como já observamos, os investimentos em serviços de
saúde, em grandes aglomerações urbanas, dependem de soluções tecnológicas
inovadoras. Biossensores são objetos responsáveis pela aquisição de dados
biológicos da população. Podemos citar, como exemplos de biossensores, os de
batimentos cardíacos, oximetria, pressão arterial, entre muitos outros.
 Sensores químicos: esses objetos são responsáveis pela aquisição de dados
químicos ambientais como monóxido e dióxido de carbono, fumos

9
 tóxicos, potencial hidrogeniônico (PH) da água etc. Estudos de redução de
emissões poluentes e de adequação de edificações também podem ser levados a
cabo com o tratamento desses dados.
 Sensores de identificação: baseados em tecnologias como a de solicitação
de informação (RFI), têm a função de possibilitar pagamentos ou mesmo
habilitar acesso ao mobiliário público e transportes.
 Sensores de movimento: esses objetos são responsáveis pela coleta de
dados de movimento e vibração e auxiliam numa mobilidade inteligente e em
controle industrial. Entre esses sensores estão os giroscópios e os acelerômetros,
por exemplo.
 Sensores de presença: esses sensores percebem a presença de humanos,
objetos ou animais. Entre esses sensores estão aqueles capazes de estimar a
proximidade de um objeto ou a percepção de presença e movimento em espaços
controlados. Aplicações desses sensores, em smart parkings, já são uma
realidade cotidiana.

TEMA 3 – CONECTIVIDADE DA IoT EM SMART CITIES

Ao tratarmos da estrutura de comunicação de uma REI, comentamos que o

atendimento a redes de objetos inteligentes, em smart cities, demanda redes bastante
especiais, dadas as características não necessariamente amistosas dos usuários. Redes
públicas de telefonia foram construídas com esse paradigma de desconfiança presente.
Em especial, redes de telefonia móvel digital têm um bom potencial de atendimento às
demandas de conectividade. Há, entretanto, outras características, dessas redes, que as
tornam apenas parcialmente adequadas, sobre o que voltaremos a tratar, para
justificarmos essa afirmação. Aceitemos, por ora, esta possível verdade: um padrão
novo precisa ser considerado, para essa nova demanda.
A primeira resposta a isso, focada em cidades inteligentes, foi o padrão Wi-
SUM, seguido pelo Wi-Fi HaLow. As demais tecnologias existentes no momento atual,
a envolver a IoT, são, de fato, adaptações de padrões para permitir o atendimento
relativamente eficiente. Nesse ponto, devemos fazer menção ao 5G, que, embora seja
uma resposta adaptativa de telefonia pública móvel, apresenta promessas de alta
eficiência, quando comparável aos padrões dedicados, antes citados.

1
 Neste tópico, introduziremos os dois primeiros padrões de forma bastante
sintética, mas voltaremos ao tópico, futuramente, para melhor detalhar as soluções
existentes.

3.1 IEEE 802.11 ah – HaLow

O padrão 802.11 ah é a proposta do IEEE para normalização da interface Wi-Fi

e para o crescimento dos objetos inteligentes. No momento em que escrevemos, apesar
da profusão de artigos sobre o padrão, equipamentos com essa tecnologia estão ainda
em fase de testes, sem disponibilidade comercial.
O Wi-Fi HaLow foi padronizado para operar em baixa frequência ultra-alta
(UHF), em torno de 900 MHz. A escolha por frequências mais baixas prioriza a
cobertura (de até 1 km) e a transparência de objetos, permitindo menores demandas de
energia. De fato, analogamente ao LoRa, o padrão permite que o projetista determine o
foco da rede, a velocidade de transmissão excursiona entre 150 Kbps e 8 Mbps, mas,
naturalmente, o uso de maiores velocidades implica menor eficiência energética. Alguns
estudos indicam que a flexibilidade de foco da interface, em função da mutabilidade do
ambiente urbano, necessitaria de uma inteligência adaptativa em tempo real, ou seja, a
interface tem bom potencial de atendimento desde que associada a um processo de
gerenciamento adaptativo.
Um artigo de Tian et al. (2021) fornece informações bastante interessantes para
aqueles que desejarem aprofundamento no conhecimento desse padrão.

3.2 WiSUM

As primeiras experiências em escala para atendimento por REI não encontraram

uma interface de baixo custo, com as características necessárias. O IEEE já havia
emitido uma norma para atendimento por low data rate wireless (LDRW), sobre
comunicações sem fio, de baixa taxa de transmissão, a IEEE
802.15.4. Foi necessário apenas acomodar as especificações mais exigentes, de
medições e atuações na rede elétrica, com o uso de objetos inteligentes. As alterações
redesenharam a camada física (PHY), que passou a ter uma norma específica, a
802.15.4g, operando nas proximidades de 900 MHz. As alterações na camada de
controle de acesso ao meio (MAC) geraram a norma 802.15.4e.

1
 As adaptações na camada física incluíram a análise constante do meio e da
qualidade da radiorrecepção, mantendo, dinamicamente, o sinal mesmo em condições
adversas. A MAC tomou emprestado o controle de colisões de dados, utilizado em
telefonia celular, e o associou a algoritmos de adormecimento de rádios LoRa. O
resultado é uma rede bastante resiliente e adaptável, com boa capacidade de transmissão
e foco em comunicação entre máquinas. Voltaremos a essa solução em outro momento.

3.3 Redes públicas móveis

Comentamos que as redes de telefonia celular, embora fossem as candidatas

mais fortes ao atendimento da conectividade em cidades inteligentes, não são, ao menos
até o momento, a solução preferida. Estudaremos, em outro momento, essas redes com
mais detalhes; entretanto, adiantamos que, no caso, além de algumas impropriedades
técnicas ligadas ao consumo de energia, há a questão da tarifação.
Redes públicas de telefonia não são negócios filantrópicos e os investimentos
em redes, para permitir o atendimento as cidades inteligentes, precisam ser
remunerados. Naturalmente, as companhias celulares já estão presentes nos centros
urbanos e os investimentos são marginais em relação aos já realizados para prover o
serviço de voz e dados. A questão é que as redes celulares evoluíram para prover altas
demandas de dados, para alta densidade de usuários humanos. O atendimento por
comunicação entre máquinas ocupa o espectro, reduzindo a capacidade de faturamento.
Algumas soluções de compartilhamento de banda e alocação dinâmica já
existem para tecnologias 3G e 4G, mas tem ainda o potencial esgotamento dos recursos
de rádio, provocado pelo número elevado de objetos da IoT, que cria uma pressão por
monetizações altas em relação às demais tecnologias que citamos. Dessa forma, o
atendimento a cidades inteligentes só pode ser feito de forma parcial pelo sistema de
telefonia. Esse atendimento parcial terá foco em aplicações cuja demanda de banda
justifique custos envolvidos mais significativos.
Novamente, devemos citar as promessas da nova geração de telefonia, que
parece ter bom potencial para equacionar os problemas técnicos e comerciais
envolvidos no atendimento com uso de IoT.

1
 TEMA 4 – CAMADA DE APLICAÇÃO E CONTROLE

Quando descrevemos as aplicações de objetos inteligentes em smart cities

observamos que não apenas protocolos especiais de rede precisam estar associados a
esses dispositivos, mas também uma boa dose de inteligência de controle e de
tratamento dos dados, para que deles resultem ações efetivas para a população. Vamos,
agora, entender o papel dessa inteligência.

4.1 Arquitetura de redes

Já comentamos as diversas arquiteturas de objetos da IoT, ditas IoT-A. Nas

aplicações em domótica, a grande maioria dos objetos cumpria uma arquitetura de
níveis mínimos, conectando-se, cada objeto, sempre que possível, diretamente à internet.
Em cidades inteligentes, a arquitetura deve conter mais níveis, uma vez que a conexão
com a internet nem sempre é necessária aos objetos, diretamente. Estruturas com
capacidade de inteligência de borda e aptidão para discriminar quais informações devem
ser compartilhadas com os níveis superiores, em direção à aplicação, reduzem essa
necessidade de conectividade.
As experiências bem-sucedidas com utilities de energia tornaram a hierarquia da
camada de comunicação das REIs o padrão mais aceito para redes em cidades
inteligentes. Dessa forma, teremos o primeiro nível, mais próximo ao usuário, HAN ou
BAN, conforme descrevemos nas REIs. As HANs normalmente conterão certa
inteligência de borda, residente em um gateway de processamento e roteamento, que
selecionará e encaminhará as informações para a internet ou para o nível mais alto da
rede, NAN. As NANs têm por finalidade conectar HANs às empresas de utilidade ou
objetos da IoT de uso público, entre si. Esse nível também conta com inteligência de
borda, residente em um gateway de processamento e roteamento que selecionará e
encaminhará as informações para a internet ou para o nível mais alto da rede, WAN.
Nesse último nível transitam dados entre utilities e entre estas e o Poder Público.
Nas primeiras implementações de REIs, as NANs eram denominadas redes de
campo (FAN) e congregavam os equipamentos de medição e operação da rede de alta
tensão de distribuição e de operação de subestações. Com a participação de dispositivos
de domótica integrados às utilities, o termo gradativamente é abandonado.

1
 4.2 Tratamento de dados – data analysis

A mera disponibilidade de dados coletados pelos objetos inteligentes não torna a

cidade inteligente. É necessário preparar e analisar esses dados, transformando-os em
informações. Ghazal et al. (2021, p. 447) propõem que o tratamento dos dados seja feito
em quatro etapas: aquisição, pré- processamento, análise e serviço. A etapa de aquisição
contempla o agrupamento e a memorização dos dados obtidos pelos sensores. Na etapa
seguinte (pré-processamento), os dados passarão por testes de consistência, eliminando-
se erros e ajustando-se escalas, entre sensores, de forma a padronizar os dados para a
próxima etapa. Na etapa de análise, técnicas de ciência de dados serão aplicadas sobre
os dados, para que deles se extraia significado, permitindo então a tomada de decisão ou
a criação de políticas para atendimento inteligente à população, na etapa de serviço.
A etapa de análise é a que mais nos interessa em virtude de seu viés técnico.
Nessa etapa, técnicas de deep learning (DL) farão a extração de parâmetros para que
algoritmos de machine learning (ML) aportem significado às informações. Dito de
outra forma, os dados coletados pelos sensores devem ser tratados por etapas de IA.

4.3 IA em cidades inteligentes

A grande profusão de sensores em cidades inteligentes nos faz presumir a coleta

de infinitos dados, virtualmente. Essa imensa massa de dados não pode ser analisada por
métodos estatísticos sem, antes, dela extrairmos os padrões e eliminarmos as
invariâncias. Esse tratamento só é possível com uso de redes neurais profundas. A
descrição detalhada desse processo não é objeto deste curso, mas alguns de seus
conceitos devemos abordar, para permitir o entendimento de sua aplicação em IoT.
Inicialmente, é possível intuir, mesmo sem conhecimentos de neurociência
computacional, que uma rede neural artificial é composta pela associação de neurônios
artificiais. Duas são as formas de associar neurônios artificiais: redes alimentadas
adiante (ANNs clássicas) e redes recorrentes (RNNs). Nas ANNs, um neurônio de uma
camada é conectado apenas a neurônios da camada seguinte, ou seja, não há laços de
recorrência. Nas RNNs, as saídas dos neurônios são reinseridas na rede. De forma
bastante rudimentar,

1
 podemos dizer que uma ANN é capaz de aprender a identificar padrões em um conjunto
de dados; já uma RNN pode fazer reconhecimentos com memória. Dessa forma, as
RNNs têm a possibilidade de analisar uma entrada, não apenas em relação ao conjunto
de dados, mas também em relação às entradas anteriores.
A Figura 4 representa uma ANN clássica, totalmente conectada. Nessa rede
podemos ver três camadas, a saber: a de entrada (neuônios 1 e 2), a camada oculta (3 e
4) e a camada de saída.

Figura 4 – ANN totalmente conectada

Fonte: Russel; Norvig, 2013, p. 637.

Redes profundas são redes neurais com várias camadas ocultas entre as camadas
de saída e de entrada. O aumento da profundidade das redes incorpora a possibilidade de
reconhecimento autônomo de padrões nos dados. Assim, de forma simplista, ao
oferecermos uma massa de dados a uma ANN profunda, ela será capaz de criar
classificações (datasets) que podem ser tratadas por algoritmos estatísticos de ML.
Essas redes profundas, entretanto, têm baixa eficiência no reconhecimento de
invariâncias. Invariâncias são variações sem importância nos dados, como a rotação ou
variações de luminosidade, em uma imagem de um mesmo objeto. Redes neurais
convolucionais (CNNs) são eficientes na eliminação dessas invariâncias. A Figura 5
apresenta a arquitetura de uma pequena CNN. Observe que, distintamente da ANN
clássica, a conexão entre camadas, naquela, não é plena.

1
 Figura 5 – Arquitetura de uma rede convolucional (autoral)

Os dados, após passarem pelo tratamento neural, são então analisados por
algoritmos de ML. Segundo Ghazal et al. (2021, p. 449), os algoritmos mais utilizados
em análise de dados para cidades inteligentes são Support Vector Machine (SVM),
Random Forests (RF), Decision Tree (DT), Naive Bayes (NB), K-Means, K-Nearest
Neighbor (K-NN) e Logistic Regression (LR). Esses algoritmos criam árvores que
permitem visualizar as concentrações de dados (RF, DT, NB) ou ajudam na criação de
uma equação regressiva, para descrição de dado fenômeno. O diagrama da Figura 6
ilustra essa sequência de passos entre a captação de dados pelos sensores e a obtenção
de significado com uso de IA.

1
 Figura 6 – Extração de significado dos dados, para gestão pública

SENSORES

Dados

Redes Neurais

Algoritmos de ML

Informações para Gestão

Concluído esse processo, o administrador público será capaz, por exemplo, de

entender qual público é mais demandante de dado serviço, identificar lacunas de
serviços ou mesmo alterar equipamentos urbanos em direção à sustentabilidade. Esses
possíveis resultados são interessantes, mas, se pensarmos que podem ser obtidos em
tempo real, permitindo prestação de serviços adaptável, temos um vislumbre do real
potencial das cidades inteligentes.

TEMA 5 – EMPREENDEDORISMO EM SMART CITIES COM IoT

O tópico das cidades inteligentes é substancialmente mais complexo que nossos

estudos anteriores sobre domótica e, de certa forma, é possível dizer que as casas
inteligentes se incorporam como um componente das smart cities. Dessa forma, as
oportunidades de negócio que surgem nesse caso não excluem as antes comentadas,
apenas as ampliam. Vamos, então, introduzir algumas oportunidades de negócio ligadas
às cidades inteligentes, como já o fizemos. Este tópico não pretende ser uma relação de
negócios, mas apenas indicar possibilidades para que você possa, se o desejar, visualizar
oportunidades de empregabilidade e empreendedorismo.

1
 5.1 Serviços inteligentes

As facilidades de obtenção de dados, em cidades inteligentes, permitem

oportunidades de desenho de serviço customizado não apenas para o setor público. As
informações, se compartilhadas, podem também motivar empreendimentos privados.
Alguns exemplos interessantes são: coleta circular de resíduos, telemedicina, segurança
privada e tecnologia da informação.
A coleta de resíduos, realizada pela Administração Pública, faz uso de sensores
inteligentes para direcionar a equipe de coleta. Com um pouco mais de tratamento dos
dados, é possível aplicar conceitos de economia circular, que permite o
reaproveitamento de resíduos, principalmente industriais, em processos que os
consumam como insumos. Dessa forma, além de se gerar um negócio economicamente
interessante, colabora-se com a sustentabilidade da cidade.
Telemedicina é uma tendência que ainda está em consolidação. Assim, muitas
são as oportunidades, tanto ligadas ao médico quanto ao paciente. O primeiro
necessitará de facilidades de acesso e tratamento dos dados; já os pacientes têm
interesse na celeridade de diagnóstico e pré-diagnóstico. Diagnósticos prévios ao
aparecimento de moléstias podem, também, motivar mudanças de hábitos sem a
intervenção direta do profissional médico.
Quanto à tecnologia da informação, as oportunidades que se abrem são
inúmeras, e alguns exemplos são o desenvolvimento de front ends personalizados, a
implementação de algoritmos de IA, de algoritmos de computação de borda etc.

5.2 Segurança e privacidade de dados

Outro aspecto que demanda consideráveis esforços de programação, em cidades

inteligentes, se refere à segurança e privacidade dos dados coletados. A presença ubíqua
de sensores de todos os tipos, no ambiente urbano, gera a real possibilidade de
devassamento da intimidade dos munícipes. Modelos de tratamento que mantenham os
dados brutos inacessíveis ainda estão em desenvolvimento, mas, mesmo após sua
padronização, riscos de subtração de dados ou vazamentos inadvertidos têm altíssimo
potencial de ocorrência. Trataremos, ainda neste curso, das questões de segurança de
um produto da IoT; mas, neste ponto, é importante que visualizemos as
oportunidades

1
 profissionais ligadas ao tópico de segurança de dados, geradas nas cidades
inteligentes.

FINALIZANDO

Nesta etapa, entendemos como objetos da IoT podem ser aplicados em sistemas
urbanos complexos que permitirão o atendimento eficiente de serviços prestados aos
munícipes, mesmo em metrópoles com altas concentrações populacionais. Estudamos as
redes elétricas inteligentes, que são a primeira materialização dos conceitos de cidades
inteligentes, já em operação no Brasil. Apresentamos, finalmente, os processos de back
end relacionados ao tratamento de dados e conversamos, brevemente, sobre as
oportunidades de negócio que surgem do conceito de smart cities.
Certamente percebemos, nesta etapa, a complexidade ligada às soluções de IoT
em aplicações amplas, como as enormes massas de dados geradas em cidades
inteligentes. Em outro momento, voltaremos nossos olhos para o estudo da engenharia
de software necessária para o desenvolvimento de códigos relacionados a essas
aplicações complexas.

1
 REFERÊNCIAS

ABNT – Associação Brasileira de Normas Técnicas. ABNT NBR ISO 37122:2020:

cidades e comunidades sustentáveis – indicadores para cidades inteligentes. Rio de
Janeiro, 9 jul. 2020.

BERGER, L. T.; INIEWSKI, K. Redes elétricas inteligentes: aplicações,

comunicação e segurança. Rio de Janeiro: LTC, 2015.

CORTESE, T. T. P.; KNIESS, C. T.; MACCARIE, E. A. (Org.). Cidades

inteligentes e sustentáveis. São Paulo: Manole, 2017.

GAMA, K.; ALVARO, A.; PEIXOTO, E. Em direção a um modelo de maturidade

tecnológica para cidades inteligentes. In: SIMPÓSIO BRASILEIRO DE SISTEMAS
DE INFORMAÇÃO, 8., 2012, São Paulo. Anais... Porto Alegre: SBC, 2012. p. 513-
518.

GHAZAL, T. M. et al. IoT for smart cities: Machine learning approaches in smart
healthcare – A review. Future Internet, v. 13, n. 8, p. 218, 2021.

LAI, C. S. et al. A review of technical standards for smart cities. Clean

Technologies, v. 2, n. 3, p. 290-310, 2020.

LOFHAGEN, J., C. P. Startups: transformando cidades tradicionais em cidades

inteligentes. Curitiba: Contentus, 2020.

RUSSEL, S.; NORVIG, P. Inteligência artificial. 3. ed. Rio de Janeiro: LTC, 2013.

TIAN, L. et al. Wi-Fi HaLow for the Internet of Things: An up-to-date survey on IEEE
802.11ah research. Journal of Network and Computer Applications, 13 mar.
2021.

2
IOT – INTERNET DAS COISAS
AULA 4

Prof. Gian Carlo Brustolin

CONVERSA INICIAL

Até aqui, conhecemos os conceitos básicos e duas importantes aplicações dessa

tecnologia. Iniciamos agora uma abordagem um pouco mais profunda tecnicamente nos
próximos momentos, o que incluirá o estudo de técnicas de programação voltadas a IoT,
tecnologias de redes e conceitos de segurança para IoT. Apesar do foco mais técnico,
não é objetivo aqui o mergulho em códigos computacionais ou em programação de
dispositivos, mas sim orientar o estudante na aplicação das técnicas estudadas em outros
contextos do IoT.
Dessa forma, neste capítulo, que abordará aspectos de programação, não
devemos esperar códigos e APIs. Abordaremos, sim, aspectos de engenharia de
software, que particularizam o desenvolvimento para estes dispositivos, a exemplo da
computação de névoa e microsserviços. O objetivo geral será sempre conduzir o
estudante para a compreensão das particularizações, ou seja, indicar como os
conhecimentos desenvolvidos em seus estudos anteriores podem ser utilizados em
projetos envolvendo IoT. Deixaremos, entretanto, indicadas as referências para revisão
ou aprofundamento dos tópicos.
Ao final deste capítulo, você terá uma visão técnica geral de desenvolvimento
para IoT e, como de hábito neste estudo, conhecendo as inevitáveis incertezas e desafios
ligados ao assunto.
Vamos então dar início a este empolgante estudo.

TEMA 1 – INTRODUÇÃO AO DESENVOLVIMENTO PARA IoT

Quando imaginamos o desenvolvimento de software para IoT, diante do que já

conhecemos sobre a tecnologia, construímos uma ideia de modularidade ou de
segmentação. Existem, de fato, vários desenvolvimentos em IoT, cujo escopo e
complexidade, variarão, conforme a IoT-A escolhida. Como discutimos, em outro
momento, em uma arquitetura mais simples, composta de objetos inteligentes mais
complexos, de três camadas, teremos códigos para a programação do objeto em si, back
end, para o tratamento da interconexão com o servidor e o front end de controle. A
complexidade cresce ainda um pouco mais, quando desejamos (e normalmente o
fazemos) que o front end possa ser acessado ou residir remotamente.
 IoT-As que permitem objetos mais simples, desprovidos de algumas dos blocos
funcionais não essenciais, delegam a códigos intermediários a complementação das
funcionalidades ausentes. Dessa forma, podemos esperar complexidade crescente no
desenvolvimento, conforme simplificamos os dispositivos da camada sensorial.
Além da questão da IoT-A, conforme o uso pretendido, o tratamento parcial dos
dados pode ocorrer mais próximo aos objetos (Edge e Fog Computing) ou mais
próximo à camada de negócios (Cloud Computing). Essa escolha impactará,
igualmente, na engenharia de desenvolvimento. Vamos inicialmente estudar essas
estruturas.

1.1 Computação em nuvem e CoT

A diversidade de usos e de objetos IoT resultaram na criação de vários

ecossistemas sem integração. Além dessa necessidade de interoperabilidade, as
implementações IoT, de grande porte, requerem funcionalidades, para gerenciar dados e
dispositivos e garantir a entrega e o uso correto desses dados. Soluções, baseadas em
computação em nuvem, foram as primeiras a serem propostas para equacionar a
prestação de serviços e a interoperabilidade.
Nessa aproximação, a nuvem age como um transdutor e controlador. Ao
transitar os dados de cada objeto para a nuvem, esta poderá garantir a segurança dos
dados e a comunicação entre objetos.
A computação em nuvem, antes de sua aplicação ligada ao IoT, foi imaginada
para permitir o uso de recursos computacionais oferecidos como serviços. Se a
implantação é externa à rede privada do usuário, o modelo pay- as-you-go (pagamento
por uso) permite flexibilidade e custo linear, proporcional ao crescimento da rede. A
computação em nuvem, escalável e resiliente, se tornou a solução preferida pela maioria
das aplicações web
Com a sedimentação das tecnologias ligadas ao IoT, a nuvem se tornou a opção
ideal, para complementar a baixa capacidade computacional, inerente aos objetos
inteligentes. Como já estudamos, objetos para domótica têm forte tendência ao uso de
nuvem, tanto para operação isolada, com apoio de servidores do fabricante, quanto para
uso integrado, via plataformas como Google e Amazon.
 Esse paradigma, batizado CoT (Cloud of Things ou nuvem de objetos, em
português), ilustrado na Figura 1, tem algumas vantagens interessantes, que discutimos
quando falamos em domótica. A conexão dos objetos se dá ao middleware (direta ou
indiretamente, conforme a IoT) e este se conecta diretamente à nuvem.

Figura 1 – CoT

Fonte: Santana et al., 2019, p. 81.

Como você já deve estar imaginando, a CoT tem algumas limitações severas que
impedem o uso desse paradigma como único (Santana et al., 2019). Em soluções CoT,
a conectividade com a nuvem, se perdida, impede o funcionamento do objeto. Outra
fragilidade se refere à demanda por largura de banda, na nuvem, visto que todos os
objetos a ela se conectam diretamente. Embora as demandas individuais sejam baixas, a
copiosidade de objetos torna o trânsito total significativo, impactando no tempo de
resposta, gerando alta latência.
Sistemas que devam funcionar permanentemente ou com baixa latência não
serão aderentes à CoT. Uma solução que aproxima as facilidades de nuvem do objeto é
a computação de neblina.

1.2 Computação de Neblina ou Névoa e FoT

Proposta por Bonomi et al. (2012) e Bar-Magen (2013), a arquitetura de

computação de névoa prevê a realização de parte do processamento na rede
local. A princípio, o paradigma de computação em névoa (Fog Computing) é aplicável,
como arquitetura, para qualquer rede de computadores. Quando consideramos o
vertiginoso crescimento do tráfego de sistemas e redes IoT, entretanto, que em muitos
casos já supera a demanda humana, percebemos o real potencial da névoa. Levar todos
os dados para a nuvem e lá selecionar os que devem voltar para a camada de percepção
e atuação parece uma arquitetura pouco lógica, diante dessa imensa geração de dados.
Nos primeiros estudos de aplicação em IoT do conceito de névoa (FoT, Fog of
Things), imaginou-se o processamento realizado por alguns dispositivos de maior
capacidade pertencentes à rede de objetos. Em uma implementação ZigBee, por
exemplo, os nós roteadores poderiam assumir certo processamento local. A ideia
evoluiu para que um concentrador tivesse capacidade de processamento e,
consequentemente, de tratamento de dados e, eventualmente de decisão. A conexão com
a nuvem se faz a partir desses concentradores.
O conceito de computação em neblina é, no entanto, distribuído, prevendo o uso
da capacidade computacional onde ela for encontrada. Assim, uma rede de ativos
composta de roteadores, gateways, servidores etc., com capacidade de processamento
local, pode estar associada à camada de percepção.
O FoT não necessariamente elimina a necessidade da conexão à nuvem, mas
presta os serviços locais possíveis e envia dados processados para as infraestruturas
virtuais. A proximidade com os objetos facilita a obtenção de baixa latência. A Figura 2
ilustra o paradigma de neblina.

Figura 2 – Computação de neblina

Fonte: Santana et al., 2019, p. 82.

 A consequência desse ganho de latência se reflete em possibilidades de uso em
tempo real, mobilidade e escalabilidade. Há, ainda, um ganho lateral de resilência,
resultante da autonomia dos dispositivos, em relação à conectividade com a nuvem. Se
existir a necessidade de complementariedade de serviços, providos pela nuvem, os
dados podem ser armazenados em neblina para envio posterior.

1.3 Computação de borda

A computação de borda (Edge Computing, em inglês) é o paradigma

arquitetural que devolve a capacidade de processamento para os objetos. Nessa
arquitetura, no entanto, não retornamos apenas a uma LAN de pequenos processadores,
como inicialmente podemos imaginar, embora isso seja possível em determinados usos.
Essa arquitetura prevê, de fato, a possibilidade de computação distribuída na
borda. Além da virtual independência de conexão com a internet ou nuvem, outras
facilidades se tornam viáveis, como baixa latência, mobilidade dos dispositivos e
segurança de borda.
O tempo de processamento de soluções, envolvendo decisão centralizada em
nuvem ou neblina, se tornou problemático para aplicações em Vanet (Vehicular Ad
Hoc Networks), ou seja, quando veículos autônomos necessitavam tomar decisões em
milissegundos (El-Sayed et al., 2017)
A arquitetura não abandona a camada de neblina, de forma análoga ao que
comentamos em FoT, dando a ela funções de provimento de serviços para os objetos.
Parte do processamento, entretanto, volta a ser realizado nos objetos. A Figura 3 ilustra
a topologia.
Figura 3 – Topologia Edge para IoT

Fonte: El-Sayed et al., 2017, p. 1709.

O conceito de computação de borda em IoT possibilitou, além de veículos

inteligentes, implementações como monitoramento de tráfego, semáforos inteligentes,
smart grid e monitoramento de tubulações de gás, por exemplo.

1.4 Introdução à programação para IoT

Entendida a diversidade de paradigmas de computação, associada à miríade de

objetos, com variados níveis de inteligência e arquitetura, podemos construir nosso
pensamento, quanto aos métodos de programação necessários para esses objetos.
O problema inicial repousa sobre o próprio projeto de dispositivos: embora
existam padrões de interfaces de rede, que estudaremos, nascem, frequentemente,
objetos de baixa interoperabilidade. Esse problema, todavia, se
agrava exponencialmente quando tentamos desenvolver aplicações para gerenciá-los,
uma vez que, ainda não existem padrões consolidados para as interfaces de software.
Todavia algumas características devem ser mantidas em foco sempre que
projetamos um software para IoT. A primeira delas é o gerenciamento de energia: os
programas devem levar em conta que boa parte dos dispositivos precisa sobreviver por
anos, sustentado por uma pequena bateria autônoma. Os sistemas operacionais dos
objetos normalmente assumem o gerenciamento de energia da conectividade e do
processamento, mas os serviços não são conhecidos do SO, e algumas decisões, como
desligamento das requisições ao objeto, só podem ser tomadas pelo sistema
demandante.
Uma segunda característica importante é a latência. Mesmo em arquiteturas de
borda, o acesso ao dispositivo é feito em janelas determinadas de tempo para permitir o
adormecimento. Assim, certa tolerância à latência deve ser prevista. Outra
característica, ligada à conectividade, são os objetos que operam em modo não
conectado, transmitindo os dados em intervalos de tempo constantes, de forma
independente de requisição. Esse modo de operação de dispositivos simples pode gerar
problemas na camada de aplicação, com a chegada de dados de forma assíncrona às
necessidades dessa camada. Será, então, necessário depurar e corrigir os dados.
Alguns dados em sensores multifuncionais ou em redes com sensores de
tecnologias diversas, com a mesma função, podem demandar metadados que devem ser
considerados nos algoritmos de depuração, para construir um dataset adequado.
Para agregar um pouco mais de complexidade, a IoT tem uma característica
ubíqua: um objeto pode estar em mobilidade e gerar dados em redes diversas. A camada
de aplicação precisa estar preparada para a ubiquidade.
Namiot e Sneps-Sneppe (2014, p. 25) enfrentam esse problema de forma
sistemática. Como muitos sensores não suportam instruções ou comandos impedindo o
interfaceamento por APIs (Application Program Interfaces), estratégias envolvendo
DPIs (Data Program Interfaces) parecem sem mais genéricas, por permitirem o
acesso também a esses objetos simples. Com uso
de DPIs, hipoteticamente seria possível padronizar o acesso a todos os sensores bem
como a respostas destes que poderiam gerar um arquivo JSON simples.
Dessa forma, a aplicabilidade de programação em entidades, sejam APIs ou
DPIs, sedimenta a ideia do uso de microsserviços reativos, como método prioritário de
desenvolvimento para IoT. Logo iremos explicar melhor este conceito. Para que
possamos aprofundar um pouco mais este assunto, precisamos, antes, conhecer alguns
SOs típicos, residentes em objetos inteligentes.

TEMA 2 – SISTEMAS OPERACIONAIS PARA IoT

Após visitarmos as topologias computacionais e compreendermos seu impacto

sobre a programação, precisamos conhecer os sistemas operacionais que controlam os
dispositivos IoT. Sabemos antecipadamente que existem níveis diversos de inteligência
ligados a esses dispositivos e, por tal motivo, devemos esperar sistemas operacionais
simples e leves e, em casos extremos, resumidos a temporizadores e transdutores.
Excetuando-se esse caso extremo, como os objetos inteligentes possuem
recursos limitados, os SOs devem consumir poucos recursos. Os dois principais
sistemas operacionais dedicados para objetos inteligentes são Contiki e TinyOS, além
do Android e algumas versões de Linux que podem ser orientadas à IoT.
Vamos agora conhecer esses sistemas operacionais de forma genérica.

2.1 Contiki OS e Contiki-NG

Os primeiros sistemas operacionais para IoT exigiam do programador bom

conhecimento de linguagens de baixo nível, como Assembly e normalmente
demandavam algumas incursões no opcode hexadecimal. O Contiki surgiu como uma
opção a estes SOs rústicos, em 2006. Possui bibliotecas que permitem a operação com
várias soluções de conectividade, além da alocação e controle de memória. Do ponto de
vista de conectividade, o Contiki foi o primeiro SO compatível com o protocolo IP e
capaz de tratar endereçamento IP V6 (µIPv6). Este SO, em seu desenvolvimento
original, tem código extremamente enxuto com apenas 100KB e necessita de parcos
10KB de memória volátil para operação.
 Seu kernel foi desenvolvido em código aberto, utilizando a linguagem C,
tornando-o leve e portável.

Saiba mais

O sistema operacional Contiki está disponível para estudo no link a seguir: GIT
HUB. The Contiki Open Source OS for the Internet of Things. Git Hub,
S.d. Disponível em: <https://github.com/contiki-os>. Acesso em: 5 out. 2022.

O kernel é orientado a eventos tornando a execução eficiente em termos de

energia e rápida, em relação a eventos externos. Outra característica desse OS é permitir
a conexão com APIs cooperativas, multitarefa.
Para permitir testes de carga desse SO foi desenvolvido um simulador de rede de
dispositivos, batizado de Cooja (Contiki OS Java), que permite simular nós com distinta
memória e número de interfaces.
Em 2017, uma nova versão do SO, batizada de Contiki-NG foi publicada
(Meriksson, 2022). Essa versão permite o controle de objetos com processadores 32
bits e suporta padrões recentes de protocolos como o IEEE
802.15.4 TSCH, 6LoWPAN, 6TiSCH, RPL, CoAP, MQTT, and LWM2M.
A nova versão também é agnóstica em relação ao hardware, mas há drivers
disponíveis para adaptá-lo a eletrônicas específicas. Apesar de conter várias atualizações
de segurança, o uso do C como base de programação mantém certas vulnerabilidades,
ligadas a alguns problemas clássicos do C, as quais comentaremos em outro momento.
A seguir, um exemplo do inevitável código “Olá Mundo” para Contiki. Observe
que, por ser um sistema multitarefa, é necessário startar os processos desejados:

#include"contiki.h"
# i n c l u d e < s t d i o . h>

PROCESS( o l a M u n d o P r o c e s s , " O l a m u n d o " ) ;

AUTOSTART_PROCESSES(& o l a M u n d o P r o c e s s ) ;

PROCESS_THREAD( o l a M u n d o P r o c e s s , ev , d a t a )
{
 PROCESS_BEGIN ( ) ;
p r i n t f ( " Ola Mundo \ n " ) ;
PROCESS_END ( );
}

2.2 TinyOS

Esse sistema operacional baseia sua arquitetura em entidades computacionais

independentes, ditas componentes, ligadas aos serviços oferecidos pelo objeto. Esses
componentes, que operam como classes de APIs, se dividem em três tipos básicos, a
saber: comandos (requisições para execução de serviço), tarefas (serviços internos do
processador) e eventos (que sinalizam o estado de um serviço).
Existem bibliotecas de APIs que facultam a programação modular e
reaproveitável para esse SO.

Saiba mais

Assim como Contiki, este SO tem código aberto, que pode ser encontrado
acessando o link a seguir:
TINYOS. Disponível em: <https://github.com/tinyos>. Acesso em: 5 out.
2022.
Há também um simulador de hardware que permite exercitar o uso do TinyOS
mesmo na ausência de HW, o código deste simulador, chamado de Tossim, bem como
instruções de uso podem ser encontradas acessando o link a seguir:
TINYOS. Tossim. Tinyos, S.d. Disponível em:
<http://tinyos.stanford.edu/tinyos-wiki/index.php/TOSSIM>. Acesso em: 5 out. 2022.
Esse simulador é, de fato, uma biblioteca do SO.

TinyOS foi desenvolvido em nestC, uma variação do C, com foco em sistemas

embarcados, LPWAN e redes de sensores. Imaginou-se uma rede de sensores
extremamente simples conectados a um gateway, mas parte do HW necessário aos
sensores reside em uma eletrônica centralizada, como se vê na Figura 4. Esse tipo de
IoT-A já foi descrito e tem a vantagem de reduzir o custo total da rede, permitindo
potências de rádio transmissão mais baixas.
Figura 4 – IoT-A para sensores com TinyOS

Fonte: Levis; Gay, 2009, p. 4.

O foco desse sistema operacional é o consumo extrabaixo de energia na camada

de percepção (nós sensores). O uso de APIs, associado a essa estratégia, permite o
adormecimento dos nós por até 99% do tempo de operação (Levis; Gay, 2009, p. 7).
O desenvolvimento de uma aplicação pode ser feito em linguagens de mais alto
nível e traduzidas para nestC. Dada a simplicidade dos nós para os quais o SO foi
desenvolvido, todavia, essa estratégia pode resultar em APIs pouco otimizadas, que
consumirão recursos excessivos dos nós. Após concluído o código em nestC, a
implantação em um nó é feita pelo download, com uso da interface USB, suportada por
um computador com o IDE Tiny instalado.

2.3 Android

Esse SO não foi, como os anteriores, desenvolvido para objetos IoT e sim para
dispositivos móveis de maneira geral. Como as tecnologias para esses dispositivos,
principalmente em telefonia celular, estão bastante sedimentadas, é de se esperar que o
ambiente, em torno do Android, também seja estável e rico em opções. De fato, há
muitas APIs, bibliotecas e mesmo midlewares para ele.
Esse SO é baseado em um kernel Linux empilhado sob bibliotecas nativas do
Android e uma máquina virtual (Android Runtime) que gerencia a execução das APIs.
Acima dessa camada está o framework de serviços que isola a base da pilha,
fornecendo serviços de alto nível para os desenvolvedores. Por
não ser um sistema operacional dedicado a LPWANs e objetos IoT, apresenta
limitações de uso, exigindo dispositivos de maior complexidade e disponibilidade de
recursos.

2.4 Linux

O desenvolvimento do mundo IoT atraiu adeptos dos sistemas operacionais

Linux, tradicionalmente leves em relação a outros SOs, para uso em máquinas
computacionais. Surgiram então distribuições Linux adaptadas ou adaptáveis ao IoT,
como o Ubuntu Core, uma versão do Ubuntu otimizada para sistemas embarcados.

Saiba mais

Baseada em containers, essa distribuição apresenta alta resiliência e boa

segurança, permitindo a configuração remota dos objetos (mais informações podem ser
obtidas em:
UBUNTU. Disponível em: <https://ubuntu.com/core>. Acesso em: 5 out.
2022.

Saiba mais

Outra distribuição digna de citação é a RIOT, desenvolvida por acadêmicos,

hobbistas e empresas, tem foco em IoT de baixo recurso, como os SOs Contiki e Tiny,
mas, por ser uma versão do Linux, permite o desenvolvimento de APIs em várias
linguagens. O site acessível no link a seguir possui informações sobre as facilidades e
implantação deste SO:
RIOT. Disponível em: <https://www.riot-os.org/>. Acesso em; 5 out. 2022.

Cabe ainda citar o Raspian, baseado no Debian, mas nesse caso com foco em
uma placa IoT específica, a Raspberry. Esse SO é bastante popular entre os
desenvolvedores e prototipadores por possuir milhares de APIs, já compiladas, de fácil
uso, disponíveis e convenientemente documentadas.

TEMA 3 – COMPUTAÇÃO ORIENTADA A SERVIÇOS

 Comentamos, sem justificar convenientemente, que uma boa aproximação para
programação de dispositivos IoT se dá por meio do uso de microsserviços reativos.
Embora possamos intuitivamente compreender a expressão é importante que lhe demos
uma abordagem acadêmica. Vamos então aos fundamentos da programação reativa e de
microsserviços.

3.1 Introdução a SOC

SOC (Service-Oriented Computing) ou computação orientada a serviços,

é um paradigma de programação, que tem por base a disponibilização, como serviços,
de funcionalidades aplicacionais independentes.
Classicamente, dividem-se as funcionalidades da SOC em três camadas,
iniciando nos serviços propriamente ditos, como camada de base. Sobre essa camada se
estrutura a comunicação e a agregação entre os serviços, composta por um conjunto de
sobresserviços chamados web services. O gerenciamento dos serviços compõe a
camada superior.
A camada de agregação permite a construção de macrosserviços compostos
pelos serviços de base. Essa agregação pode se dar por duas soluções principais: web
services SOAP (Simple Object Access Protocol) e web services restful. No
primeiro caso, as interações ocorrem por chamadas entre os serviços de base formatadas
em XML. A segunda solução, mais recente, segue a arquitetura Representational
State Transfer (REST), que cria métodos padronizados (PUT, POST, GET e
DELETE) de troca de mensagens entre serviços, utilizando HTTP no paradigma
stateless (não há troca ou armazenamento de contexto, que permanece no cliente).

3.2 Programação reativa

Programação reativa é uma estratégia de programação SOC que leva em conta

os fluxos de dados durante a operação do código, permitindo serviços eficientes,
responsivos e elásticos, estáveis mesmo sobre alta densidade de requisições. Os
primeiros códigos baseados em FRP (Functional Reactive Programming) foram
criados para controle de robôs. Esse tipo de controle precisa lidar com atuadores e
sensores contínuos, como motores e componentes discretos, a exemplo dos
processadores. Dessa forma, a comunicação não pode
ser plenamente conectiva, ou seja, os dados e comandos precisam ser gerados de forma
relativamente assíncrona a sua leitura, pelo processador, ou execução, pelos atuadores.
Nesse paradigma, esperam-se execuções assíncronas de serviços motivadas
pelos fluxos de dados. Voltando ao exemplo do robô, as ações serão provenientes de
decisões baseadas em leituras do meio. Essas leituras podem se assíncronas em relação
à execução do programa de controle.
De forma geral, pode-se dizer que, nesse tipo de programação, são geradas
passagens assíncronas de dados entre serviços. A liberação do programador para esse
paradigma não síncrono permite a estabilidade de aplicação, mesmo em ambientes
pouco previsíveis.
Sistemas reativos não são propriamente uma novidade. A arquitetura de
software em ambientes distribuídos baseia-se sobre programação orientada a serviços.
De acordo com esse paradigma, é necessário dissociar transmissor e receptor de uma
mensagem, criando-se um espaço de armazenamento virtual das mensagens. Esse
espaço é, de fato, um endereço distribuído nos servidores ou objetos que compõem a
rede. Naturalmente a escolha do armazenador deve estar ligada à resiliência relativa
intrínseca deste.
Como em redes IoT a assincronicidade é importante para permitir o
adormecimento dos objetos, a programação reativa é um modelo de desenvolvimento
bastante aceitável.

3.3 Microsserviços

Segundo Namiot e Sneps-Sneppe (2014, p. 25), a ideia de um microsserviço é o

particionamento de uma API em uma coleção de pequenos segmentos de código,
independentes, que contenham um serviço ou parte segregável de um serviço. Cada
serviço conterá seus processos, mantendo a independência e a autonomia. Um
mecanismo leve de comunicação, ao estilo do HTTP, será implementado para permitir a
conexão entre serviços, pelo armazenamento das mensagens necessárias a serem
trocadas. Por esse método, a camada de gerenciamento dos microsserviços será
independente e agnóstica em relação aos serviços gerenciados. A arquitetura de
microsserviços é baseada também em SOC, embora, no caso dos microssserviços,
ocorra uma
redução a apenas um serviço independente, e não a uma coleção de serviços, como em
uma API.
Há várias vantagens no uso dessa estratégia, inclusive quanto à manutenção do
código. Afirma Carrusca (2018, p. 2) que

uma aplicação composta por microsserviços permite corrigir um problema

localizado num dado microsserviço, sem que para isso toda a aplicação fique
indisponível. Isso facilita também a adição de novas funcionalidades, pois é
necessário apenas desenvolver e realizar o deploy de um novo microsserviço
sem que para isso existam conflitos com os já presentes.

Vamos comparar, para melhor entendimento, um exemplo de aplicação

monolítica, em relação a outra, estruturada em microsserviços, sugerido por Carrusca
(2018, p. 10). Suponha uma aplicação de e-commerce que, ao receber um pedido de
usuário, verifica o estoque, o crédito do usuário e finalmente faz o despacho. A Figura 5
mostra essa aplicação no paradigma monolítico e, em seguida, com uso de serviços.

Figura 5 – Arquitetura monolítica versus microsserviços

Fonte: Carrusca 2018, p.10-11.

 Observe que, no modelo de serviços, a responsividade e a elasticidade são
maiores, mas há também desvantagens associadas a essa arquitetura. A performance
pode ser um problema se um serviço utilizar chamadas a outros serviços encadeados,
resultando em latência alta. Microsserviços reativos contornam esse problema pela
atualização assíncrona dos dados, na camada de comunicação. Essa estratégia agrega
resiliência ao sistema. Naturalmente, um novo problema surge dessa solução: manter a
consistência dos dados. A camada de gerenciamento deverá implementar controles
para contornar a inconsistência temporal, derivada da assincronicidade da comunicação
entre serviços.

TEMA 4 – ARQUITETURA DE MICROSSERVIÇOS REATIVOS PARA IOT

Já sabemos que microsserviços reativos são um bom paradigma de programação

para IoT, contemplando estruturas de computação em borda, névoa ou nuvem
transparentemente. Vamos agora estudar como uma arquitetura de microsserviços
reativos pode ser concebida eficientemente

4.1 Comunicação

Como já discutimos, uma aplicação IoT, no paradigma de microsserviços, será

composta por um conjunto de microsserviços (μS) reativos, distribuídos em dispositivos
e servidores, localizados na borda da rede, na névoa ou na nuvem. Podemos dividir a
comunicação, nessa arquitetura, em duas possibilidades: externa e interna.

4.1.1 Comunicação externa

Para que os μS se comunique com um cliente, a camada de agregação pode

implementar essa conexão diretamente, serviço a serviço, ou criando um gateway, que
fornecerá a comunicação também como um serviço.
Na primeira aproximação, o cliente faz o pedido diretamente ao μS, utilizando
um endpoint público. Como a granularidade dos μS é grande, um cliente muito
provavelmente precisará realizar inúmeras requisições, a vários μS, para obter os dados
pretendidos.
 Na segunda técnica, cria-se um gateway, como ponto único de acesso aos μSs.
Esse gateway oculta, para o cliente, a arquitetura interna do sistema, fornecendo uma
API para cada tipo de cliente, que agregará os dados necessários. Essa aproximação
simplifica o código do cliente e padroniza o acesso à camada de percepção.

4.1.2 Comunicação interna

Para que os μSs se comuniquem entre si, será necessário implementar um

modelo de interação entre processos. Assim como em redes de computadores, a
interação pode ocorrer de um para um ou de um para muitos. O modelo pode ser
implementado ainda prevendo a comunicação assíncrona, por buffers – nesse caso o μS
solicitante fará uma notificação ao μS destino, ou uma publicação, no caso de
solicitação a múltiplos μSs. A comunicação síncrona também pode ser utilizada no modelo
pedido/resposta, mas essa estratégia é pouco prática para IoT, pelos motivos já
expostos.

4.2 Gestão de dados

Percebemos que o uso de μS reativo pode ter por consequência uma queda na
consistência dos dados. Um dado de uma amostragem anterior pode ainda estar presente
quando se inicia uma nova coleta por uma API.
Requisitar o refresh dos dados não é uma boa aproximação, uma vez que gera
tráfego desnecessário e consumo de energia dos dispositivos, obrigados a sincronizar as
informações. Uma estratégia de publicação voltada a eventos, reativa, é uma solução
boa, como já percebemos. Um serviço somente publicará seus dados em caso de
alteração nas suas tabelas internas de dados. Os outros microsserviços, interessados
nesses dados, os subscreverão, executando procedimentos motivados pela atualização,
se necessário. Esse processo é realizado por um componente denominado Message
Broker, que fará então um query na tabela do serviço.
Um mecanismo alternativo similar é o Event Store. Nesse caso, é criada uma
tabela com apenas as alterações sofridas (eventos).

4.3 Descoberta de serviços

 Em arquiteturas de μSs reativos, podem surgir novos componentes, ou as
localizações dos μS podem ser alteradas. Um componente de gerenciamento, chamado
Service Registry, constrói uma base de dados, com a identificação e localização de
cada μS.
Quando a descoberta de um μS precisa ser feita por um cliente externo, dois são
os procedimentos possíveis: contato direto com Service Registry ou uso de um Load
Balencer, que interfaceará esse contato. Neste último caso, a este componente se dará
também a faculdade de, caso existam serviços semelhantes, balancear a carga de
requisições. Naturalmente, neste segundo caso, há necessidade da criação e manutenção
desse componente de balanceamento, que deverá possuir alta disponibilidade, uma vez
que se tornará o caminho crítico da disponibilidade do sistema.

4.4 Containers

Em computação de borda, uma boa estratégia para conter o uso de recursos

computacionais de um microsserviço é a virtualização por containers.
A ideia de um container é a concentração, em num único pacote, de todas as
dependências, em termos de bibliotecas e definições, para a execução de um serviço ou
aplicação. Essa técnica potencialmente reduz o uso de recursos da máquina, já que
restringe a operação do serviço ao próprio container. Esse recurso é especialmente útil
quando o desenvolvimento do código do serviço é feito em linguagens interpretadas.
A máquina que executa o container deverá naturalmente rodar um motor de
container, como Mesos Containerizer ou o famoso Docker. Quando desejamos rodar
vários containers, em uma mesma máquina, sistemas de orquestração, como o
Kubernetes, controlam a execução de cada serviço e cuidam do provisionamento
dinâmico de recursos, buscando-os em outras máquinas, inclusive, quando necessário
Essa estratégia é especialmente importante para microsserviços, permitindo a
abstração dos serviços em relação à máquina e o controle efetivo do uso de recursos
desta, fato bastante importante em redes IoT.
Uma visão geral da arquitetura de microsserviços, proposta por Santana
et al. (2019), pode ser vista na Figura 6:
Figura 6 – Visão geral de arquitetura de microsserviços para IoT

Fonte: Santana et al., 2019, p. 95.

TEMA 5 – SDN E IOT

Redes de computadores (ou objetos) com arquiteturas definidas dinamicamente

por software (SDN – Software Defined Networks) são um assunto bastante
complexo, que certamente não poderá ser descrito suficientemente neste estudo. Por
outro lado, o esforço pela criação de um processo de programação, para dispositivos e
redes IoT, elástico, responsivo e resiliente, pode ser bastante simplificado, se a rede à
qual esse dispositivo se conecta puder sofrer adaptações dinâmicas.
Dito de outra forma, se a percepção do objeto quanto à estrutura da rede se
mantém constante, mesmo diante da entrada de dispositivos e ativos novos ou mesmo
diante de mudanças de arquitetura física, o esforço para criação de aplicações tolerantes
cai substancialmente. Controlar o uso e o compartilhamento de recursos da rede e de
segurança é um exemplo de problemas que podem ser resolvidos por redes SDN,
desonerando a programação dos serviços (Bera; Misra; Vasilakos, 2017).
Dessa forma, vamos iniciar um estudo superficial sobre esse tema, que envolve
tecnologias de ponta, tanto no aspecto de rede, quanto de dispositivos.

5.1 SDN

Redes definidas por SW são aquelas nas quais o encaminhamento dos pacotes,
ou plano de dados, é desassociado do controle da arquitetura da rede,
ou plano de controle. Dessa forma, a configuração dos ativos de rede não é mais feita
manualmente, a cada inserção na rede, mas controlada por software, de forma
centralizada. A ilustração a seguir demonstra as diferenças entre aproximações.

Figura 7 – Rede tradicional versus SDN

Fonte: Kreutz et al., 2014, p. 5.

Embora, pela observação da figura, possamos imaginar a centralização física do

controle da rede, a centralização é apenas lógica. Isso é explicável em função da
existência de redes complexas e destruídas entre geografias.
Redes configuradas e controladas por SDN tratam problemas clássicos de
congestionamento e vulnerabilidades de segurança do TCP com alta eficiência,
adaptando a rede ao tráfego e à segurança, dinamicamente. A criação, por exemplo, de
redes virtuais e de dutos seguros dentro da rede, que originalmente demanda a
interferência, mesmo que remota, nos equipamentos, passa a ser delegada a uma
inteligência centralizada de gerenciamento. O acréscimo de técnicas estatísticas de ML
incorpora IA a rede, abstraindo completamente o plano de dados do seu gerenciamento
humano. Exemplos de aplicações de ML em SDN são: predição de QoS e QoE (quality
of experience), classificação de tráfego e gerenciamento dinâmico de segurança.
 Saiba mais

Neste nosso estudo, não nos aprofundaremos além deste ponto, mas o estudo do
artigo a seguir pode fornecer o aprofundamento se desejado.
KREUTZ, D. et al. Software-defined networking: a comprehensive survey.
Proceedings of the IEEE, v. 103, n. 1, p. 14-76, 2014.

5.2 SDN e IoT

Redes de objetos IoT sofrem uma série de limitações originadas nos próprios
objetos ou nos protocolos heterogêneos de rede. Estudos envolvendo redes de sensores,
a exemplo de Seol, Shin e Kim (2015), anteriores à sedimentação do conceito de
cidades inteligentes, já propunham a criação de uma software-defined wireless
sensor network (SDWSN), como forma de contornar problemas de interoperabilidade,
delegando o controle dos gateways a uma inteligência central.
Em cidades inteligentes, o trânsito de dados, proveniente da borda em direção à
nuvem, é considerável e assimétrico. Em relação ao tempo, configurações fixas de rede
exigem o dimensionamento pelo pico de transmissão, levando a um investimento não
ótimo em ativos e conectividade. A Figura 8 ilustra a contribuição que redes definidas
por SW podem fazer às estruturas de IoT.
Figura 8 – SDN em IoT

Fonte: Ghaffar et al. 2021, p. 15.

A conexão entre borda e nuvem e a harmonização da heterogeneidade não são as
únicas contribuições possível de sistemas SDN; a elasticidade, a mobilidade e a
segurança também se vêm facilitadas com o emprego de inteligência no gerenciamento
de rede.

Saiba mais

Infelizmente, não podemos nos aprofundar além deste ponto neste estudo, mas
os artigos a seguir podem fornecer o aprofundamento se desejado: BERA, S.; MISRA,
S.; VASILAKOS, A. V. Software-defined networking for internet of things: a survey.
IEEE Internet of Things Journal, v. 4, n. 6, p. 1994-
2008, 2017. Disponível em: <https://bit.ly/3e68BS3>. Acesso em: 5 out. 2022.
GHAFFAR, Z. et al. A topical review on machine learning, software defined
networking, internet of things applications: Research limitations and challenges.
Electronics, v. 10, n. 8, p. 880, 2021. Disponível em:
<https://www.mdpi.com/2079-9292/10/8/880>. Acesso em; 5 out. 2022.
FINALIZANDO

Neste capítulo, conhecemos os métodos recomendados de desenvolvimento de

software voltados para IoT. Esses paradigmas complexos de programação,
naturalmente, são aventados para aplicações de larga escala para as quais não apenas a
programação precisa ser minuciosamente planejada, mas também as estruturas de rede.
Considerando a heterogeneidade das tecnologias em torno dos objetos IoT, as redes que
os atendem precisam ser dotadas de boa dose de inteligência e flexibilidade. Boa parte
dessa heterogeneidade advém, entretanto, de protocolos particulares de conectividade
entre objetos. Em outro momento, vamos conhecer algumas dessas soluções.
REFERÊNCIAS

BAR-MAGEN, J. Fog computing: introduction to a new cloud evolution. In: CASALS,

J. F. F. (ed. lit.); NUMHAUSER, P. (ed. lit.). Escrituras silenciadas: paisaje como
historiografía. Alcalá: Editorial Universidad de Alcalá, 2013. p. 111- 126.

BERA, S.; MISRA, S.; VASILAKOS, A. V. Software-defined networking for internet

of things: a survey. IEEE Internet of Things Journal, v. 4, n. 6, p. 1994- 2008,
2017.

BONOMI, F. et al. Fog computing and its role in the internet of things. In: GERLA,
M.; HUANG, D. Proceedings of the first edition of the MCC workshop on Mobile cloud
computing. In: SIGCOMM '12 CONFERENCE, Helsinki: : ACM SIGCOMM, 17 ago.
2012, p. 13-16.

CARRUSCA, A. V. Gestão de micro-serviços na Cloud e Edge. Dissertação

(Mestrado em Engenharia Informática) – Faculdade de Ciências e Tecnologia, Lisboa,
2018.

EL-SAYED, H. et al. Edge of things: The big picture on the integration of edge, IoT
and the cloud in a distributed computing environment. IEEE Access, v. 6, p. 1706-
1717, 2017.

GHAFFAR, Z. et al. A topical review on machine learning, software defined

networking, internet of things applications: Research limitations and challenges.
Electronics, v. 10, n. 8, p. 880, 2021.

LEVIS, P.; GAY, D. TinyOS programming. Cambridge: Cambridge University

Press, 2009. Disponível em: <http://csl.stanford.edu/~pal/pubs/tos- programming-
web.pdf>. Acesso em: 5 out. 2022.

KREUTZ, D. et al. Software-defined networking: a comprehensive survey.

Proceedings of the IEEE, v. 103, n. 1, p. 14-76, 2014.

MERIKSSON, J. Version 4.8. Contik-Ng, 14 jul. 2022. Disponível em:

<https://github.com/contiki-ng/contiki-ng/releases>. Acesso em: 5 out. 2022.

NAMIOT, D.; SNEPS-SNEPPE, M. On iot programming. International Journal of

Open Information Technologies, v. 2, n. 10, p. 25-28, 2014.
SANTANA, C. et al. Teoria e prática de microsserviços reativos: um estudo de caso na
Internet das Coisas. In: XXV SIMPÓSIO BRASILEIRO DE SISTEMAS
MULTIMÍDIA E WEB: MINICURSOS. Anais... Sociedade Brasileira de Computação,
2019.

SEOL, S.; SHIN, Y.; KIM, W. Design and realization of personal IoT architecture
based on mobile gateway. International Journal of Smart Home, v. 9, n. 11,
p.133-144, 2015.
IOT – INTERNET DAS COISAS
AULA 5

Prof. Gian Carlo Brustolin

CONVERSA INICIAL

Nesta etapa, finalmente vamos estudar as soluções possíveis de conectividade

para objetos IoT. Vamos evitar tratar das interfaces fiadas, uma vez que a sua
utilização é bastante restrita, com foco maior em aplicações industriais. Dessa
forma, nos resta o estudo das interfaces de radiocomunicação. Como já comentamos, o
estudo de radiopropagação é consideravelmente complexo, pois envolve conceitos
físicos e matemáticos de engenharia de telecomunicações. Por esse motivo, nesta etapa
não vamos nos aprofundar nas camadas físicas dos diversos padrões de interface em
uso. Vamos fazer um estudo de revisão, apresentando as diversas soluções possíveis na
atualidade e
comparando-as em termos de aplicação e eficiência.
Inicialmente, vamos fornecer uma visão geral dos tipos de redes para o
atendimento à tecnologia, para em seguida apresentar alguns conceitos rudimentares de
telecomunicação, que complementam o que estudamos. Após os tópicos iniciais,
estamos prontos a conhecer as soluções técnicas que apresentam, até o momento, bons
resultados no atendimento à tecnologia IoT. Para este estudo, selecionamos alguns
padrões de conectividade já consolidados para os sistemas de sensoriamento, avaliando
ainda alguns protocolos em fase inicial de implementação.

TEMA 1 – INTRODUÇÃO ÀS REDES PARA IOT

Considerando a vestibularidade do assunto de IoT como um todo, podemos

esperar uma considerável dose de incertezas quanto às redes de interconexão dos
dispositivos IoT à internet ou às intranets. Não existem ainda soluções definitivas para
atendimento desses objetos. As respostas clássicas de atendimento são aquelas usadas
em redes de sensoriamento, que acolhem satisfatoriamente os objetos com baixo
consumo de dados, ainda que não sejam eficientes para dispositivos de vídeo ou para
aplicações mais complexas em domótica, por exemplo. Assim, embora existam muitas
alternativas, a escolha dependerá essencialmente da aplicação, inexistindo, ao menos
por hora, uma solução abrangente para todas as demandas.

1.1 Um pouco de
 Já sabemos que as redes industriais são a origem tanto dos objetos quanto das
redes de IoT. Nesses momentos iniciais da tecnologia, redes sem fio eram uma solução
de última escolha, com foco principal em confiabilidade e resiliência. Inexistia a
preocupação com demandas de dados mais elevadas, já que as aplicações industriais não
apresentam essa exigência. As redes que não atendem humanos diretamente são
chamadas, genericamente, de redes M2M (Machine to Machine), ou redes de
interconexão entre máquinas. Redes LPWAN são um tipo de rede para M2M. Redes
M2M para sensores ou atuadores industriais apresentam tipicamente a velocidade de
algumas dezenas de Kbps.
Com a disseminação de objetos inteligentes para além do âmbito industrial, as
exigências mudaram. Aplicações em áreas rurais, como agricultura de precisão, por
exemplo, demandam, além de resiliência, baixo consumo de energia. Essa característica
é essencial nessa aplicação, uma vez que os dispositivos costumam estar locados em
pontos de difícil acesso.
Outro fato interessante é que os objetos inteligentes apresentam características
de operação que invertem o sentido predominante de transmissão. As redes de objetos
IoT normalmente operam com predominância de pacotes de uplink, ao passo que redes
tradicionais esperam downlinks significativos como característica dominante do tráfego
de rede.
Os padrões desse tipo de atendimento são chamados LPWAN (Low Power Wide
Area Networks) ou WANs de baixo consumo de energia. Entre as tecnologias listadas
nesta denominação, estão LoRa, Wi-SUN, RPMA, Weightless e SIGFOX (Prando et
al., 2019).
As aplicações em cidades inteligentes e domótica são mais recentes, exigindo
maior demanda de dados, no caso de domótica, e de mobilidade, nas smart cities. Redes
M2M LPWAN normalmente não são capazes de atender essas novas exigências. A
mobilidade, por exemplo, está mais próxima a sistemas celulares, ao passo que
downstreams elevados podem ser providos por sistemas WiFi.
Percebemos assim que tecnologias distintas estão sob o guarda-chuva genérico
das redes M2M. Por esse motivo, é necessário categorizá-las de forma distinta, como
faremos a seguir.

1.2 Redes públicas e

 Serviços públicos precisam estar presentes em determinados locais. Cabe ao
Estado garantir a sua existência e funcionamento. Exemplos de serviços públicos são a
tríade clássica composta por serviços de saúde, segurança e educação. Além deles,
existem outros, como serviços de saneamento, provimento de energia elétrica e
telecomunicações. Assim, a disponibilidade de facilidades de telecomunicações acaba
sendo um serviço de utilidade pública. Por essa razão, a área é regulamentada pelo
poder estatal.
No Brasil, até a década de 1990, a maior parte do território apresentava serviços
de telecomunicações providos por empresas estatais, o famoso sistema Telebras. As
primeiras operações de telefonia celular foram implantadas por essas empresas, que
pertenciam ao Estado. O processo de privatização, levado a cabo a partir de 1995,
retirou das mãos estatais o serviço de telecomunicações. Porém, como na maioria das
nações, o controle do serviço foi mantido por uma agência reguladora, a Anatel, que
passou a estabelecer regras de concessão para as empresas que desejassem operar
esses serviços.
Em telefonia celular, além das regras de concessão, a agência interfere na
reserva de radiofrequências para a operação das concessionárias de serviço móvel,
chamadas frequências licenciadas.
Assim, uma rede pública de telefonia é regulamentada pelo Estado, por meio
de concessão para a operação. O exemplo que mais nos interessa é o das redes de
telefonia móvel, ou seja, de telefonia celular que atendem também serviços de dados
móveis. Como sabemos, esses serviços, tanto de voz quanto dados, são regulamentados
por leis e dispositivos infralegais. Essa regulamentação engloba não apenas a qualidade
da rede, como também a cobertura e a densidade mínima de atendimento. A Resolução
Anatel n. 680 (Brasil, 2017) apresenta uma tabela de destinação de faixas com as bases
de regulamentação dos serviços de telecomunicações no Brasil.
As demais redes sem fio operam em frequências não licenciadas, sendo
conhecidas como redes privadas. Tais redes não podem ser dedicadas à prestação
onerosa de serviço público de voz ou dados. Não há restrição, entretanto, à construção
de uma rede privada que dê suporte à prestação de um serviço remunerado. A prestação
de serviço remoto (de segurança predial, por exemplo) pode ser levada a cabo por uma
estrutura privada de telecomunicações.
1.3 Padrões públicos e privados

É bastente comum que as pessoas confundam redes públicas com padrões

públicos de redes. Redes públicas são controladas pelo Estado, enquanto um padrão
público de rede é uma norma técnica que estabelece as especificações técnicas de
operação de uma tecnologia, sempre dispoível para consulta pública. O padrão WiFi,
por exemplo, é um padrão público, cujas características de desenho das interfaces estão
disponíveis para consulta no IEEE ou na associação internacional certificadora do
padrão, a WiFi Aliance.
Uma rede pública opera preferencialmente em padrões públicos, dependendo de
autorização especial para a utilização de padrões obscuros, ao passo que uma rede
privada pode utilizar padrões públicos ou privados.
Um exemplo interessante, que vamos estudar ainda nesta etapa, é a rede Sigfox.
Ela oferece comunicação de dados em frequências não licenciadas. Portanto, deveria ser
uma rede privada. No entanto, por comercializar serviços de telecomunicações
diretamente, depende de autorização do Estado – logo, seria uma rede pública. No fim,
o padrão de operação da rede Sigfox é de propriedade de uma empresa homônima,
sendo mantido de forma propositalmente restrita.
No estudo dessas e de outras soluções de rede para conectividade IoT, é
importante conhecer um pouco melhor a base de telecomunicações das interfaces
físicas.

TEMA 2 – RUDIMENTOS DE TELECOMUNICAÇÕES PARA IoT

Uma vez que esta etapa não é voltada apenas para engenheiros de
telecomunicações, não podemos presumir que todos tenham domínio de certos
conceitos físicos e matemáticos dessa área de conhecimento. Também é importante
destacar que um tema não é suficiente para trabalhar toda a base conceitual necessária.
Assim, vamos propor algumas simplificações, sem perda de verdade científica, para que
todos possam construir um entendimento elementar dessa ciência. Preste atenção às
obras que nos serviram de base, pois elas podem ajudá-lo, caso deseje se aprofundar no
tópico.

2.1 Introdução às técnicas de modulação

 Não é o objetivo aqui, como já comentamos, detalhar as complexas equações
relevantes para o estudo das tecnologias, como cálculos de radiopropagação. No
entanto, devemos ter uma noção básica dos princípios físicos envolvidos, para que
sejamos capazes de colaborar com o processo de tomada de decisão entre interfaces ao
longo da nossa carreira.
Vamos começar pelo princípio do processo. Vamos supor que precisamos
interconectar uma aplicação, residente em máquina computacional, com um coletor de
dados IoT qualquer – um medidor de temperatura ambiente, por exemplo. O coletor será
provido de inteligência nativa, ou ainda agregada por nós, como já exploramos em outra
oportunidade. Além da eletrônica inteligente, o objeto IoT deverá apresentar uma
interface (nativa ou agregada) de comunicação. Neste estudo, vamos considerar que ela
é sem fio. A figura a seguir exemplifica essa arquitetura.

Figura 1 – Conectividade sem fio IoT

Os dados são coletados pelo sensor e convertidos pela eletrônica embarcada em

binário. A camada MAC insere o handshake (endereços, controle de erro, controle de
frames...) e entrega o trem de bits à camada física (PHY), para que sejam transmitidos à
rede por rádio comunicação.
O equipamento radiotransmissor toma os dados binários para transformá- los em
ondas eletromagnéticas (OEM), que podem ser propagadas pelo espaço livre. Essa
transformação ocorre por alerações nas características de uma ou várias OEM
portadoras. Esse processo é conhecido, em telecomunicações, como modulação.
As técnicas de modulação da OEM portadora, que permitem a transmissão dos
dados binários, são processos de descrição física com matemática complexa. Apenas
para se ter uma ideia do seu funcionamento,
vamos cosiderar um método de modulação digital elementar extremamente eficiente: o
BPSK (Binary Phase Shifting Keying).
Imagine a onda portadora como uma senoide cuja frequência de oscilação é a
frequência da portadora. Podemos modular essa portadora pela alteração temporal de
sua fase, se desejamos transmitir determinado bit. A figura a seguir ilustra esse conceito.

Figura 2 – Portadora modulada por BPSK

Fonte: Elaborado com base em Tanenbaun; Wetherall, 2011, p. 81.

O gráfico da Figura 2 representa o sinal binário de rede. O segundo representa a

onda portadora já modulada. Observe que, a cada mudança de sinal binário, a fase da
portadora se altera. O sinal modulado, depois de convenientemente amplificado, pode
ser transmitido por uma antena para um ponto distante.
Os poderosos algoritmos de modulação QAM, que facultam transmissões de alta
resiliência e velocidade, são baseados na técnica elementar de BPSK, com a utilização
de múltiplos ângulos de defasamento, permitindo a codificação de n-uplas de bits
simultaneamente.
No que se refere à frequência da portadora, respeitadas algumas limitações
estabelecidas por Nyquist, qualquer frequência pode ser viável. A seleção da frequência
da OEM portadora, entretanto, depende da aplicação do rádio.
Baixas frequências apresentam boa transparência a objetos – ou seja, não são
facilmente obstruídas por paredes ou montanhas. Porém, não se adequam bem à
transmissão de taxas elevadas de dados. Altas frequências, por sua vez, viabilizam essas
transmissões. Em caso de colisão com objetos, como
gotas de chuva, ocorrem atenuações significativas, dificultando transmissões de longa
distância sem repetições (Tanenbaun; Wetherall, 2011, p. 67).
O posicionamento das frequências usadas em telecomunicações, espectro
eletromagnético conhecido, está representado na figura a seguir.

Figura 3 – Espectro eletromagnético

Fonte: Elaborado com base em Tanenbaun; Wetherall, 2011, p. 66.

Soluções com o uso simultâneo de várias portadoras são capazes de contornar as

desvantagens citadas. Existe ainda um outro aspecto a ser considerado na seleção da
frequência da portadora: a antena. A antena é o transdutor de saída do radiotransmissor,
ou seja, através dela o sinal modulado é liberado no espaço livre. As dimensões da
antena, buscando viabilizar a liberação do sinal, devem ser compatíveis com o
comprimento de onda da portadora. O comprimento de onda é inversamente
proporcional à frequência, de modo que frequências baixas demandam antenas de
grandes dimensões. Considerando uma relação de grandeza, transmissões de ondas
longas, para a comunicação com submarinos (sinais abaixo das dezenas de Khz), são
fisicamente complexas, pois demandam de antenas de centenas de metros dispostas no
litoral.

2.2 Problemas de radiopropagação

Nem tudo é uma maravilha quando utilizamos de comunicação sem fio. Quando
falamos de redes WiFi, sublinhamos que as frequências mais altas são menos
permeáveis a objetos. Um objeto, quando alvejado por uma OEM, pode apresentar três
comportamentos distintos, mas não excludentes – ou seja, pode apresentar todos os
comportamentos em intensidades distintas.
 Maxwell estudou a propagação de OEMs e descreveu, de forma matemática, as
reações da onda no espaço livre, frente a um objeto. Sem mergulhar na famosa
complexidade das equações de Maxwell, vamos descrever tais reações de forma sucinta.
Um objeto pode refletir a OEM, absorvê-la ou refratá-la. Na realidade, se um
objeto absorve parcialmente uma OEM, a energia não absorvida será propagada para
fora do objeto por refração.
Como comentamos anteriormente, os três comportamentos podem acontecer de
forma concomitante. Esse fenômeno é estudado nos níveis inferiores de educação,
quando examinamos a propagação da luz, que é também uma OEM, mas de frequência
alta em relação às ondas de rádio. O exemplo clássico que ilustra esse comportamento é
a propagação da energia luminosa incidente em uma superfície de água. Ao penetrar no
meio aquoso, parte da energia luminosa é refletida novamente para o meio gasoso, parte
é absorvida e parte é refratada para o interior do corpo de água. O ângulo de incidência
da OEM e a diferença de densidade entre os meios nos ajuda a definir as frações de cada
comportamento.

Figura 4 – OEM e refração

Fonte: Keiser, 2014, p. 37.

Os mesmos fenômenos ocorrem com as ondas de radiocomunicação. Entretanto,

considerando as conclusões de Maxwell, a frequência da portadora influencia no
percentual de energia refletida, absorvida ou refratada, e não apenas o ângulo de
incidência e na densidade.
Dessa forma, a presença de objetos que obstruam o feixe de OEM, mesmo que
parcialmente, é capaz de gerar perturbações na inteligibilidade de recepção. Como
assim?
 Sistemas robustos de comunicação por rádio utilizam várias portadoras
simultaneamente, de frequências distintas. Como a reação da OEM à colisão com
objetos depende da frequência, o sinal terá um comportamento anômalo ao enfrentar
uma obstrução.
Um quarto fenômeno não está relacionado diretamente com o objeto, mas sim
com a sua geometria: a difração. A OEM, ao encontrar uma aresta ou orifício, sofre uma
alteração no ângulo de propagação. Essa alteração pode inclusive gerar dispersão em
direções variáveis, conforme vemos na figura a seguir.

Figura 5 – Difração

Fonte: Elaborado com base em Ribeiro, 2009, p. 94.

O ângulo de difração, contra anteparo anguloso, também depende da frequência

da onda incidente. Esse é outro fator que gera distorções na rádio comunicação. Ainda
assim, existem outros fenômenos a considerar.
Uma OEM pode chegar ao receptor por diferentes percursos, como ilustra a
figura a seguir. Percursos diferentes significam retardos de chegada diferentes, com
distorção do sinal recebido. A essa distorção chamamos de multipercurso.

Figura 6 – Multipercurso de OEM

A presença de gotículas de água na região entre as antenas de recepção e

transmissão ocasiona pequenas variações de densidade do meio. Adivinhe –
também tem influência sobre a qualidade da recepção do sinal, fazendo com que a
propagação seja irregular.
Em comunicações móveis, comuns em aplicações de smart cities, o efeito
doppler sobre a frequência, gerado pelo deslocamento do transmissor em relação ao
receptor, altera a frequência da portadora, prejudicando a recuperação do sinal.
Existem ainda outros problemas a considerar, como a presença de ruído ou a
interferência de operações de rádio próximas. Neste momento, você deve estar
pensando em desistir do uso de rádio para a conexão de objetos IoT. Não se desespere,
pois existem soluções que contornam esses problemas.

2.3 Técnicas de modulação resilientes

Técnicas de modulação clássicas, como acabamos de estudar, enfrentam

copiosos problemas de propagação, dificultando a comunicação por rádio. A solução a
esses desafios dependia de cuidadosos cálculos topográficos e de altas potências de
transmissão. Tais respostas tradicionais falham quando o projeto demanda flexibilidade,
baixo custo e mobilidade, características importantes das redes para IoT.
Aplicações militares de radiocomunicação enfrentavam, além de tudo que já
comentamos, um problema suplementar: a necessidade de indetectabilidade.
Engenheiros militares encontraram uma forma de solucionar essa demanda: dispersão
da informação no espectro de frequência, ou seja, em múltiplas portadoras. Essa técnica,
batizada de espalhamento espectral (SS – Spread Spectrum, em inglês), transmite a
informação segmentada e modulada em várias portadoras, com baixa potência e
redundância de transmissão. Com essa técnica, a eventual detecção de uma portadora
pelo inimigo não permite a decodificação da mensagem. A redundância de transmissão
(quando a mesma informação é transmitida em mais de uma portadora) permite a
operação em potência baixíssima. O algoritmo de recepção extrai os segmentos de
informação das portadoras de melhor qualidade em um determinado momento,
remontando o sinal transmitido.
Essa técnica converte os problemas de radiopropagação em vantagens, por meio
do espalhamento da informação. Com essa implementação, mesmo que algumas faixas
de frequência pereçam, a informação estará preservada em
outra área do espectro. A presença eventual de ruído sintonizado (na mesma frequência
de uma portadora) contaminará apenas parte da energia do sinal, não afetando a
inteligibilidade.

Figura 7 – Transmissão de dados por espalhamento espectral

Fonte: Maxim Integrated, 2003.

Rádio enlaces SS, em função das baixas potências de transmissão, normalmente

não superam os 30km. Suplantar esse limite com o uso de repetições é viável, mas
distâncias acima de 150km implicam custos de equipamento e manutenção que, no fim,
são inviáveis.

TEMA 3 – REDES PRIVADAS PARA IoT

A principal solução para conectividade de objetos IoT, ao menos atualmente,

passa pelas redes privadas. Tais redes, como estudamos, podem se basear em protocolos
públicos ou privativos. Nesta secção, vamos estudar padrões de alta aderência às
normalizações do IEEE, como o WiSum, até há pouco tempo bastante restritos – como
o LoRa, que apesar de sua popularidade como solução LPWAN, ainda apresenta
problemas de interoperabilidade.

3.1 WiFi

A norma IEEE 801.11 estabelece as bases dessa tecnologia. Nas versões

atualmente em operação, duas faixas de rádio frequência estão padronizadas para uso e
liberadas em todas as geografias pelas agências reguladoras, uma de 2,4GHz (em UHF)
e outra de 5,7 GHz (em SHF).
Na faixa de 2,4GHz, estão disponíveis 11 canais de 5MHz. No entanto, a técnica
de modulação utilizada pelo padrão (espalhamento espectral) faz com que apenas três
canais possam ser usados simultaneamente sem que ocorra
interferência. A figura a seguir ilustra a interferência do canal 3 nos canais 1 e 4, bem
como a ausência de interferência quando selecionados os canais 1, 6 e 11, classicamente
indicados para essa aplicação.

Figura 8 – Interferência entre canais WiFi operando em 2,4GHz

A faixa SHF (Super Hight Frequency), com até 165 canais disponíveis, é
composta por frequências consideravelmente mais altas que o UHF (Ultra Hight
Frequency). Sinais em frequências mais altas são menos permeáveis a objetos,
dificultando o projeto físico da rede. Paredes, que são transparentes para o UHF, se
tornam barreiras intransponíveis de reflexão para a operação em SHF. Esse fato,
considerando ainda a menor presença de interfaces SHF nos dispositivos WiFi, faz com
que a maioria das redes atuais operem em 2,4GHz, principalmente em aplicações de
domótica. Além disso, como já comentamos, as redes para domótica normalmente se
baseiam na versão WiFi 4 (IEEE 802.11 n).
Aqui, não é o nosso objetivo detalhar o protocolo, mas apenas fornecer algumas
noções gerais de operação, o que nos ajuda a entender o correto funcionamento da
interface.
Em uma descrição elementar, uma instalação WiFi permite a conexão de um
dispositivo à rede através de um ponto de acesso AP (Access Point, em inglês). O AP é
basicamente composto por rádio transmissor, antena (que pode ser única ou não),
inteligência de controle de acesso e autenticação. O AP é conectado a um roteador, que
por sua vez permite acesso à internet. Em uma residência, normalmente temos uma rede
sem fio composta por um AP, integrado ao roteador, em um único equipamento. Essa é
a solução mais simples. Existem instalações, em residências amplas, que contam com
mais de um AP. O diagrama a seguir ilustra essa arquitetura.
Figura 9 – Arquitetura elementar de WLAN

No caso de APs múltiplos, é necessário que eles sejam configurados para que
ocupem canais não interferentes. Como vimos anteriormente, a operação em UHF
disponibiliza apenas os canais 1,6 e 11 para a comunicação não interferente. É comum
que residências contíguas apresentem os próprios sistemas de WiFi em operação.
Assim, é preciso levar em conta a presença desses sinais externos para a escolha da
canalização. Devemos buscar intercalar os canais como ilustra a figura a seguir.

Figura 10 – Canalização ideal para WLAN

É preciso evitar o uso de canais aparentemente livres fora dessa tríade. Como a
banda ocupada por cada canal invade os vizinhos, o uso dos canais intermediários reduz
a velocidade máxima de transmissão, já que a modulação, utilizada pelo rádio 802.11n,
cria dependência entre a banda disponível e o máximo trânsito de dados.
Quando implantamos uma WLAN WiFi, escolhemos uma identificação de rede
(RFID) e uma senha de acesso, que será comum a todos os APs, conectados à rede.
Todo dispositivo que deseja se conectar à rede deve ter essas duas informações. Uma
boa descrição de protocolo, para aqueles que
desejam aprofundar a compreensão do tema, pode ser encontrada em Tanenbaun e
Wetherall (2011).

3.2 LoRa

O surgimento de sensores e atuadores sem fio comerciais levou à criação das

primeiras padronizações do conceito de Low Power Wide-Area Networks (LPWANs),
redes de longo alcance e baixo consumo. Empresas de tecnologia, atentas ao emergente
potencial de mercado, iniciaram o desenvolvimento de interfaces de rádio para atender a
LPWANs. A Semtech foi uma delas. Sua solução, chamada de LoRa, que engloba
hardware e software (LoRaWAN), obteve grande sucesso entre os projetistas de redes
para IoT, por ser a primeira a atender a grandes áreas de cobertura, sem necessidade de
estações ou nós repetidores, com consumo bastante baixo dos dispositivos.
A LoRa resolve o problema de extensão de cobertura pela otimização do
algoritmo de espalhamento espectral clássico. A ideia dos engenheiros da Semtech foi
codificar sequências de bits em rajadas multifrequenciais. Correndo o risco de
simplismo em excesso, a técnica chamada de Chirp-spread-spectrum (CSS) transforma
n-uplas de bits em uma sequência de frequências próximas. Dessa forma, se o receptor
for capaz de identificar ao menos uma das frequências da sequência, mesmo que as
demais sejam perdidas, ele será capaz de recompor a n-upla de bits original.
Naturalmente, existem restrições de velocidade e de latência de pacotes para que a
banda de transmissão seja aceitável.
A camada física LoRa, baseada na modulação CSS, como já adiantamos, é
bastante resiliente, permitindo comunicação efetiva mesmo quando o nível do sinal
transmitido está abaixo do ruído presente. Assim, baixíssimos níveis de transmissão (e
consequentemente de consumo) são possíveis.
A LoRa utiliza frequências não licenciadas na faixa de 902 a 928 MHz, com
banda de transmissão setável em 125 kHz ou 250 kHz. A distância típica entre terminais
pode chegar, sem dificuldades, a 8km (Marais; Malekian; Abu- Mahfouz, 2017).
A camada de controle de acesso ao meio e o roteamento (LoRa MAC) controlam
a cadência das trocas de mensagens, respeitando as regras de
handshake. A figura a seguir ilustra a disposição das camadas em equipamentos LoRa.

Figura 11 – Camadas LoRaWAN

Fonte: Lora Alliance, 2018.

Uma rede LoRa é estruturada segundo uma topologia “estrela de estrelas”.

Nessa arquitetura, um dispositivo está conectado a um gateway enquanto os gateways se
conectam a um servidor central de rede. O padrão só contempla a camada física e de
controle de acesso. A conexão entre gateways é feita por uma rede TCP alheia ao
padrão LoRa.
A padronização LoRa foi tornada pública recentemente, com a criação de uma
associação internacional nos moldes do WiFi. Essa origem restrita gerou versões
incompatíveis de rádios, produzidos antes da criação da LoRa Aliance, com os quais
convivemos ainda hoje.

3.3 IEE 802.15.4g (ZigBee)

O ZigBee é normalmente usado em redes com topologia mesh. Nessa topologia,

um dispositivo pode ter múltiplas funções. O objeto será configurado pela rede como
cliente (apenas a função de sensor/atuador), coordenador ou roteador, conforme a
necessidade, para manter a resiliência da operação.
Nas aplicações em domótica, entretanto, essa facilidade é pouco utilizada. Os
objetos participam da rede como meros clientes, relegando a função de roteamento e
coordenação para o gateway IoT, que opera em estrela. Vamos falar sobre o gateway na
sequência desta etapa.
ZigBee tem foco totalmente diferente do seu primo, o WiFi. Para permitir baixo
consumo e imunidade a ruídos e interferências, as taxas típicas de transmissão estão
entre 20 e 250kbps. Baixas potências de transmissão, além
da facilidade configurável do modo “sleep”, que reduz drasticamente o consumo de
energia em escuta, complementam as restrições para a manutenção das caraterísticas de
desenho.
Na camada PHY, os rádios ZigBee operam nas faixas de 2.400 a 2.4835 MHz,
competindo com o espectro WiFi, porém com 16 canais de até 250Kbps efetivamente
disponíveis, modulados por O-QPSK (Offset Quadrature Phase Shift Keying). A técnica
de modulação distinta e as baixas potências de transmissão, entretanto, evitam a
interferência desse padrão com o WiFi.
A camada MAC, proprietária do padrão, complementa o isolamento das
tecnologias pelo uso de estratégias de prevenção de colisão que impedem a transmissão
em momento de interferência. A camada de rede, também padronizada pela ZigBee
Alliance, chamada PRO, apresenta algoritmos de descoberta de dispositivos,
roteamento, gestão de rede e dispositivos.
Finalmente, há uma camada de aplicação que “traduz” as aplicações, fornecendo
um ambiente de facilidades de uso do dispositivo. Nessa camada, o gateway IoT fará a
interface do protocolo com a rede local ou a internet. A seguir, a figura relaciona as
camadas ZigBee com o padrão OSI.

Figura 12 – Camadas ZigBee

Fonte: ZigBee Alliance, 2022.

O protocolo é um pouco complexo e seu estudo extrapola os objetivos desta

etapa. Consulte a documentação referenciada em nossa bibliografia (ZigBee, 2022) para
o aprofundamento desse padrão.

3.4 IEEE 802.15 (WiSUN)

 O IEEE idealizou, inicialmente, o padrão 802.15 para atender a conectividade de
sistemas inteligentes de medição e gerenciamento de energia elétrica residencial, com
foco na otimização do consumo. O Japão foi escolhido para o primeiro teste de escala.
Dezenas de milhões de unidades consumidoras foram monitoradas e otimizadas com
sucesso. A partir dessa aplicação inicial, novos campos de aplicação, como agricultura
de precisão e cidades inteligentes, passaram a ser o objetivo da evolução do padrão
(Harada et al., 2017).
A norma de base para a camada física do Wi-SUM é a IEEE 802.15.4g,
enquanto a norma IEEE 802.15.4e estabelece os parâmetros para MAC. A
implementação dessas normas resulta em uma rede de baixíssimo consumo de energia,
mesmo com boa densidade de objetos (milhares) conectados por segmento de rede.
Considerando o foco inicial do padrão, a velocidade de troca de dados da rede
não é alta (300Kbps) porém o alcance é elevado (4Km) e suporta repetição ou
prolongamento por arquitetura mesh.
Quanto às frequências de operação, a Wi-SUM opera tanto em 2,4GHz, para
conexões indoor e em baixo UHF, quanto próximo dos 900MHz, para conexão outdoor.
A latência, em torno de 20ms, é baixa em relação a outros padrões LPWAN, o que torna
o padrão viável para o controle de provimento de serviços públicos em tempo real.
A associação regulamentadora da tecnologia, a WiSUM Aliance, normalizou a
operação de um dispositivo WiSUM em relação ao consumo de energia. O dispositivo
deve ser capaz de operar ao menos 15 anos, sem exaurimento de baterias, o que faz com
que a solução seja bastante interessante para aplicações IoT. O consumo de energia é
baixo mesmo em termos de transmissão (14mA) e latência (2μA).

TEMA 4 – REDES PÚBLICAS PARA IoT

Vamos agora sedimentar o conceito de redes públicas, por meio do estudo das
principais soluções para o atendimento M2M (especialmente para IoT) por essas redes.
Vamos apresentar ainda uma solução mista, operada como rede pública, ainda que não o
seja propriamente: trata-se do Sigfox. Essa curiosa rede pode ser utilizada no
atendimento a dispositivos IoT com características díspares, como veremos a seguir.
4.1 Introdução às redes públicas de telefonia móvel

Como você já estudou, nem todo provimento de telecomunicações sem fio é

regulamentado. Um campus universitário pode prover conectividade a seus alunos e
mesmo ao público visitante sem sofrer, diretamente, a regulamentação da Anatel, mas
há restrições quanto às frequências e quanto à potência de operação
O serviço de telecomunicações móvel foi criado com foco exclusivo em voz.
Pequenas mensagens de texto, os SMSs (do inglês Short Message Service), foram a
versão inicial da comunicação digital entre assinantes, que atualmente domina a
comunicação pública móvel. Essas primeiras gerações apresentavam interface física
baseada em rádios analógicos por modulação de frequência. Nessa técnica, utilizada nas
rádios FM comerciais, a voz (sinal de entrada) altera a frequência da portadora entre
limites determinados. A modulação analógica FM, entretanto, não permite a criptografia
das transmissões, o que torna a comunicação entre pessoas facilmente devassável.
Embora as primeiras gerações tenham apresentado problemas, elas provaram a
viabilidade do conceito de atendimento aos assinantes em células (como veremos a
seguir), dando origem inclusive à nomenclatura usual de telefonia celular.

Figura 13 – Sistema celular (autoral)

A próxima geração de equipamentos de telefonia celular, chamada de 3G,

abandonou a comunicação analógica. A voz passou a ser codificada, ou seja,
transformada em dados, viabilizando o uso de técnicas de espalhamento espectral
altamente resilientes. Mesmo com essa primeira convergência entre voz e dados, o foco
permaneceu na voz. A geração seguinte distanciou-se desse
foco, mas ainda manteve a ótica de provimento de facilidades para usuários humanos.
Soluções de conectividade para M2M estão bastante distantes desses objetivos
iniciais do serviço celular, mas a recente demanda por esse atendimento motivou a
adaptação das redes celulares, principalmente com o surgimento das cidades
inteligentes.
As operadoras celulares já estão presentes nos centros urbanos. Porém, o
investimento para o atendimento aos objetos IoT é, proporcionalmente, pequeno.
Surgiram, assim, os padrões NB IoT, CAT NB, LTE-M e EC GSM, considerados, por
semelhança tecnológica, LPWANs licenciadas, uma vez que utilizam radiofrequências
licenciadas pela agência reguladora.
Tais padrões diferem entre si pela “geração” em que operam: NB IoT e EC
GSM, por exemplo, já estão presentes em estações 3G, mas LTE-M e CAT M
demandam a presença da tecnologia 4G. Vamos analisar um pouco melhor essas
diferenças.

4.2 Redes para IoT sobre GSM

As redes GSM, também chamadas de geração 3 ou 3G, foram as primeiras a

apresentar foco em comunicação digital e acesso à internet. Para essa geração, foram
criados os padrões NB IoT (Narrow Band for IoT) e EC GSM (Extended Coverage
GSM, ou GSM de cobertura extendida). Nesses padrões, a taxa de transmissão média
está em torno de 20Kbps, enquanto o alcance não supera algumas dezenas de
quilômetros.
O fato de um padrão atender às primeiras gerações celulares não o torna
antiquado. O EC GSM, por exemplo, foi implantado em 2018, embora já estivessem
disponíveis operações 4G. Isso acontece porque os equipamentos de 3G foram
deslocados para áreas de menor densidade populacional, como pequenas cidades ou
áreas rurais – justamente nos locais onde surgiram novas demandas por redes sem fio,
para atender à agricultura de precisão, por exemplo.
A adequação da tecnologia celular para o atendimento de redes M2M nessa
geração, entretanto, não tratou convenientemente o problema de demanda de energia
nos dispositivos. Sabemos que as redes móveis atendem a equipamentos, como
smartphones, que podem apresentar alto consumo de
energia, uma vez que sofrem recargas diárias. Essa característica, própria da tecnologia
do rádio e do algoritmo de modulação das redes 3G, não se altera nos padrões NB IoT e
EC GSM.
O consumo elevado restringe as aplicações a dispositivos que possam ser
alimentados de forma contínua, fazendo com que a solução seja imprópria para boa
parte da agricultura.

4.3 Redes para IoT sobre LTE

As redes 4G (ou LTE, do inglês Long Term Evolution) buscam atender à

comunicação multimídia, otimizando dinamicamente os recursos da rede, tanto do lado
do assinante quanto da operadora. Em relação ao 3G, ele apresenta como novidade a
total comutação por pacotes, voltando-se para o roteamento IP sem, entretanto, perder a
compatibilidade com as gerações anteriores. As taxas de transmissão podem chegar a
100Mbps de download e 50Mbps de upload por usuário, em condições ideias.
Você deve estar se perguntando por que motivo, no 4G, seria necessário
desenvolver um padrão para comunicação M2M, já que o LTE é uma rede convergente.
A questão é que o número de objetos IoT (em uma smart city, por exemplo) pode
facilmente suplantar o número de assinantes humanos, congestionando a rede. Também
é fato que a demanda por dados desses objetos é de modo geral baixa, em relação aos
downloads de internet solicitados pelos assinantes.
A tecnologia 4G permite flexibilidade de banda para os assinantes. O padrão
LTE-M (também chamado de eMTC – enhanced Machine Type Communication),
desenhado para atender objetos IoT, reparte a banda de um canal de assinante típico,
mas herda a flexibilidade de expansão do 4G, facultando a conexão tanto de objetos de
baixo consumo de dados (como no padrão anterior) quanto daqueles demandantes de
alto tráfego, como realidade aumentada e vídeo de alta resolução.
O problema é que de fato o 4G não foi pensado para o atendimento a M2M, e
sim para a convergência de redes de uso humano. O LTE-M é uma adaptação. Por conta
disso, apresenta falhas quando a exigência se aproxima dos limites da tecnologia.
Objetos que demandam bandas de transmissão altas, como os que já citamos, operam
em baixa latência e alta mobilidade. Tais
facilidades também são cobertas pelo LTE-M, mas com certas lacunas tecnológicas.
A questão de área de atendimento foi igualmente enfrentada posteriormente à
implantação do 4G. Porém, a “maldição das telecomunicações” permaneceu. Alcance
elevado implica piores índices de qualidade de rede. O padrão LTE-M contorna esse
problema com a normalização de dois modos de operação. O primeiro (dito Modo A ou
Cat – M1) fornece alta qualidade de rede e mobilidade, com foco em atendimento
urbano. O segundo, Modo B, está focado em áreas de baixa densidade populacional,
com cobertura estendida.
O Modo B assemelha-se ao NB IoT, mas a taxa de transmissão pode superar os
300Kbps com até alguns segundos de latência. O alcance do LTE Cat–M2 é bastante
diverso do seu primo mais velho, permitindo o uso de algumas dezenas de repetições.

4.4 Promessa do 5G

Já sabemos que o 4G comporta-se mal quando dele exigimos baixa latência, alta
densidade de usuários (ou objetos) e altas taxas de conexão por usuário. Demandas de
novas aplicações IoT, como realidade aumentada, utilização em sistemas de saúde,
câmeras de vigilância de alta resolução e streaming de vídeo em alta densidade não são
convenientemente suportadas pelo algoritmo de roteamento, tampouco pela camada
física dos sistemas 4G (Oliveira; Alencar; Lopes, 2018). Esse novo tráfego só pode ser
bem atendido se a disponibilidade de rede, para o uso original de smartphones, for
limitada.
A observação das redes de pacotes roteadas, como as LANs TCP, quando
exercitadas em alto tráfego e densidade, permitiram alterar os protocolos de roteamento
do 4G, acrescentando arquiteturas dinâmicas aos algoritmos desse padrão. Outras
associações poderosas foram: virtualização e técnicas de controle de cobertura por
antenas inteligentes e o uso de espectros de frequência não licenciados como apoio à
operação.
Tais implementações permitiram um salto tecnológico no atendimento sem fio
móvel, o chamado 5G, que supre as deficiências que antes elencamos. A figura a seguir
demonstra as aplicações, bem como a sua demanda por altas taxas, baixa latência e alta
densidade de objetos.
Figura 14 – Triangulo de demandas de rede para novas aplicações IoT

Fonte: Elaborado com base em Oliveira; Alencar; Lopes, 2018.

Na camada MAC do 4G, o roteamento ligado às demandas do usuário era feito

da mesma forma que o controle de rede (controle de login, tarifação, mobilidade entre
estações...). No 5G, as duas demandas são segregadas, com a criação de um Plano de
Usuário (PU) e de um de controle (PC), cada qual com a sua própria comutação e
gateway. Como podemos imaginar, a independência de planos permite alterações de
banda, para um dado usuário, sem que sejam necessárias alterações no PC.
As novas interfaces PHY permitem conexões, além das frequências licenciadas
para telefonia pública, também nas frequências de WiFi (IEEE 802.11) e IEEE 802.16,
e também em altas frequências, acima de 24GHz, sempre de forma transparente para o
usuário. Essa flexibilidade no uso de frequências, associada ao roteamento bipartido,
viabiliza altas taxas de transmissão, contornando restrições de cobertura inerentes a
cada faixa.
Objetos IoT, principalmente em aplicações urbanas, apresentam demandas de
rede profundamente diversas, como podemos ver no triângulo da figura. A estrutura
dinâmica do 5G permite um atendimento flexível, mesmo para altas densidades de
dispositivos conectados simultaneamente. Além disso, a possibilidade de uso de rádios
de frequências não licenciadas nas estações de rádio base permite maior proximidade ao
dispositivo, reduzindo a demanda de energia. Essa última propriedade transforma o 5G
em uma alternativa real de conectividade para IoT.
4.4 0G Network

Existe uma rede privada que é operada como se fosse pública. A 0G (zero G) é
uma rede internacional de operadores de um padrão de radiocomunicação privado,
chamada Sigfox, que permite interoperabilidade mundial.
A Sigfox é focada em taxas de transferência de dados extremamente baixas
(máxima de 600bps), mas com bom alcance (maior que algumas dezenas de km).
Os rádios Sigfox utilizam modulação BPSK diferencial ou D-BPSK de baixo
custo e consumo. A rede 0G opera em sete frequências distintas, definidas pela região
geográfica, dita RC (Radio Configuration Zone), onde se encontra a operação. Brasil,
Canada, México, Porto Rico e EUA estão na RC2, com frequências de operação
próximas a 900MHz.
A tarifação é calculada segundo o número de upstreams diários (normalmente
menor do que uma dezena) e o tamanho do pacote transitado.

Saiba mais

Para mais informações sobre a tecnologia e sobre casos de uso da

tecnologia, acesse:

0G UNITED NATIONS. Disponível em: <https://www.0gunitednations.com/>. Acesso

em: 6 out. 2022.

TEMA 5 – COMPARAÇÃO ENTRE SOLUÇÕES

Neste tópico, vamos elencar as principais exigências das redes para IoT que as
diferenciam das demais redes sem fio. Veremos ainda como cada solução estudada
atenda tais exigências.

5.1 Exigências para redes de atendimento a IoT

Redes para IoT apresentam algumas características em relação às redes

tradicionais. Vamos estudar apenas as três principais que definem, basicamente, as
soluções aceitáveis e as mais eficientes.

 Segurança: quando apresentamos as redes de atendimento às REI, em cidades

inteligentes, comentamos que tais redes são distintas de redes
 TCP tradicionais, com LANs e WANs, principalmente no que se refere à
segurança. Redes de objetos IoT podem congregar dispositivos pertencentes a
concorrentes comerciais ou a proprietários que não guardam qualquer relação de
confiança entre si. Assim, os protocolos devem ser seguros tanto do ponto de
vista de resiliência (safety, em inglês), para evitar atuações indevidas de
dispositivos, quanto em relação à inviolabilidade do conteúdo da comunicação
(security).
 Baixo consumo de energia: comentamos sobre esse aspecto quando
apresentamos as diversas tecnologias. É um fato que nem todos os dispositivos
IoT exigem um consumo de energia baixo, mas a maioria das aplicações o
prefere. Ao instalar um objeto inteligente, para qualquer finalidade, a ausência
de preocupação com a alimentação certamente é uma vantagem comercial e
econômica. Existem aplicações nas quais a durabilidade das baterias é essencial.
Agricultura e pecuária de precisão, além de vigilância de perímetro e
sensoriamento, em domótica, são alguns exemplos. Para que o consumo de um
objeto, no bloco de conectividade, seja baixo, o rádio deve operar com baixa
potência de transmissão, desligando o transmissor quando estiver fora de uso.
Ou seja, deve existir um algoritmo de controle de adormecimento.
 Resiliência: nem todas as aplicações demandam resiliência. Ainda assim,
aplicações em segurança (tanto safety quanto security) exigem dispositivos que
não possam operar indevidamente. Além de segurança, o sensoriamento para a
tomada de decisão também requer resiliência da comunicação. O algoritmo de
controle da camada física deve ser capaz de tratar erros, seja por recuperação ou
retransmissão. Sistemas com redundância de recepção, nas estações de rádio
base, são uma solução interessante para perpetuar a resiliência, sem
complexidade excessiva no algoritmo do lado dispositivo e sem a exigência de
retransmissões, poupando energia no objeto.

5.2 Adequação das soluções de redes

Todas as tecnologias que estudamos nesta etapa atendem às redes IoT

– ou seja, não descartaremos nenhuma delas em absoluto como possível solução
para certos objetos. Quando apresentamos as principais aplicações
desses objetos, indicamos o padrão de uso mais frequente para atender a uma aplicação
em particular. É fato que algumas soluções, por terem a sua origem em padrões de
atendimento voltados a IoT, são mais genéricas do que outras. O exemplo marcante é o
Wi-SUM, que foi desenvolvido especialmente para uso em redes para IoT. Ainda assim,
apenas ele não é capaz de atender com vantagens as altas demandas por dados. De
qualquer forma, vamos conhecer as debilidades de cada tecnologia apresentada no
atendimento aos três requisitos citados anteriormente.

 Segurança: todas as tecnologias citadas apresentam algum nível de segurança

nativo. Neste requisito, as soluções mais devassáveis serão ZigBee e WiFi.
Principalmente no segundo padrão, a segurança não é elevada, uma vez que os
seus protocolos de criptografia são voltados para o desempenho, com baixa
eficiência na proteção dos dados. Há soluções que agregam níveis suplementares
de segurança a esses padrões, de forma que, quando selecionadas, será preciso
concentrar especial atenção no reforço de segurança.
 Baixo consumo de energia: como comentamos, ao apresentar as tecnologias das
redes públicas, o grande problema no uso daquelas soluções é o consumo de
energia exigido do dispositivo. Esse inconveniente é tão significativo que, nos
gráficos de comparação entre redes para IoT, elas estão fora de escala. A
implementação de estações 5G reduzirá esse problema, por conta do uso de
frequências não licenciadas em proximidade ao objeto. Como ainda não existem
dados experimentais sobre o assunto, será necessário esperar a consolidação do
5G para entender melhor a sua adequação ao IoT. A figura a seguir compara as
diversas tecnologias em termos da energia necessária para que o objeto transmita
um bit de informação.
Figura 15 – Energia necessária para transmitir um bit

Fonte: Ruckebusch et al., 2018, p. 108.

 Resiliência: a resiliência da rede parece estar do lado das soluções públicas,

como vemos na figura a seguir. Naturalmente, quando utilizamos maior potência
nos rádios (com consumo maior de energia dos dispositivos), a qualidade da
transmissão aumenta, uma vez que podemos operar com o sinal acima do ruído e
da interferência sintonizada. Essa comparação, como já percebemos, aponta as
soluções de telefonia celular como ideais para o atendimento a objetos de grande
demanda de banda de transmissão, com baixa restrição de fornecimento de
energia.

Figura 16 – Comparação de taxa erro de pacotes

Fonte: Mroue et al., 2008, p. 5.

FINALIZANDO

Nesta etapa, estudamos as principais soluções de conectividade para IoT.

Buscamos entender os requisitos mais importantes que tais redes devem apresentar,
comparando as soluções pertinentes.
 Podemos concluir que ainda não há uma solução definitiva para o atendimento
às redes para IoT. Não se trata de uma conclusão assombrosa, uma vez que tanto as
aplicações quanto os objetos estão em constante evolução, por vezes disruptiva, em
relação ao que já está sedimentado. Já existem, entretanto, padrões criados
especificamente para o atendimento a IoT, que evoluem em conjunto com a tecnologia
IoT.
Trabalhamos nesta etapa a questão de segurança de forma genérica, voltada à
estabilidade das conexões. Em outros momentos, vamos ampliar esse estudo, discutindo
os riscos envolvidos no uso das tecnologias emergentes de IoT.
REFERÊNCIAS

BRASIL. Resolução Anatel n. 680, de 27 de junho de 2017. Diário Oficial da União,

Poder Legislativo, Brasília, DF, 29 jun. 2017.

HARADA, H. et al. IEEE 802.15: 4g based Wi-SUN communication systems.

IEICE Transactions on Communications, v. 100, n. 7, p. 1032-1043, 2017.

KEISER, G. K. Comunicações por Fibras Ópticas. Porto Alegre: Grupo A, 2014.

Disponível em:
<https://integrada.minhabiblioteca.com.br/#/books/9788580553987/>. Acesso em: 6
out. 2022.

LORA ALLIANCE. LoRaWAN Resource Hub Files. 2018. Disponível em:

<https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf>. Acesso em: 6
out. 2022.

MARAIS, J. M.; MALEKIAN, R.; ABU-MAHFOUZ, A. M. LoRa and LoRaWAN

testbeds: a review. IEEE Africon, p. 1496-1501, 2017.

MAXIM INTEGRATED. An Introduction to Spread-Spectrum Systems. 2003.

Disponível em: <https://www.maximintegrated.com/en/design/technical-
documents/tutorials/1/1890.html>. Acesso em: 6 out. 2022.

MROUE, H. et al. MAC layer-based evaluation of IoT technologies: LoRa, SigFox and
NB-IoT. IEEE Middle East and North Africa Communications, p. 1-5, 2008.

OLIVEIRA, L. A. N.; ALENCAR, M. S.; LOPES, W. T. A. Evolução da Arquitetura de

Redes Móveis Rumo ao 5G. Revista de Tecnologia da Informação e
Comunicação, v. 8, n. 2, p. 43-50, 2018.

PRANDO, L. R. et al. Experimental performance comparison of emerging low power

wide area networking (LPWAN) technologies for IoT. In: WORLD FORUM ON
INTERNET OF THINGS (WF-IoT), 5., 2019. Proceedings… IEEE, 2019.

RIBEIRO, J. R. J. A. Comunicações ópticas. São Paulo: Saraiva, 2009. Disponível

em:
<https://integrada.minhabiblioteca.com.br/#/books/9788536521930/>. Acesso em: 6
out. 2022.
RUCKEBUSCH, P. et al. Modelling the energy consumption for over-the-air software
updates in LPWAN networks: SigFox, LoRa and IEEE 802.15. 4g. Internet of
Things, v. 3, p. 104-119, 2018.

TANENBAUN, A.; WETHERALL, D. Redes de computadores. São Paulo:

Pearson Education do Brasil, 2011.

ZIGBEE ALLIANCE. Developer Resources Papers. Disponível em:

<https://zigbeealliance.org/developer_resources/?solution_type%5B%5D=zigbe e>.
Acesso em: 6 out. 2022.