Redes IOT 1

Prévia do material em texto

REDES PARA IOT 
AULA 1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Gian Carlo Brustolin 
 
 
CONVERSA INICIAL 
Nesta aula de Redes para IoT enfrentaremos alguns problemas bastante 
novos para a engenharia de redes. A própria definição de IoT, até o momento 
em que concluímos esta publicação, não está suficientemente sedimentada e 
normalmente é feita por exclusão. De qualquer forma, sabemos intuitivamente 
que redes para IoT atendem pequenos objetos autônomos que necessitam 
dessa conexão, normalmente com a internet, para cumprirem suas funções. 
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. Essa combinação de 
requisitos e exigências torna a flexibilidade de projeto bastante baixa e a seleção 
de protocolos viáveis bastante estrita. 
Considerando que a segura definição do foco de nosso estudo está ainda 
aguardando a solução definitiva, podemos esperar uma série de certezas 
tênues, ou mesmo incertezas, no que se refere às redes de interconexão dessas 
entidades à internet ou às intranets. Por esse motivo, estudaremos alguns 
padrões de rede já consolidados para interconexão de sistemas de 
sensoriamento, por exemplo, e também protocolos ainda em fase de 
implementação em larga escala. Essas duas classes de padrões são atualmente 
as soluções utilizadas e as perspectivas de futuras soluções para as redes de 
atendimento aos objetos IoT. 
Nesta aula abordaremos os conceitos introdutórios de IoT: seus 
fundamentos, a arquitetura básica de hardware e software, sistemas 
operacionais, sensores, atuadores e objetos inteligentes, bem como 
mergulharemos com considerável profundidade em alguns protocolos de 
comunicação desses objetos. 
Será um estudo um tanto robusto e necessitaremos de todo apoio que a 
literatura de base puder nos fornecer. Neste sentido, convidamos você a 
acompanhar nossos estudos com um mergulho na literatura recomendada ao 
final de cada capítulo, sem a qual a compreensão dos temas apresentados será 
sobremodo árdua. O conhecimento prévio de conceitos introdutórios de 
 
 
radiopropagação, WiFi, WiMax, sistemas celulares, Zigbee e LoRa são 
pré-requisitos para o entendimento do exposto na presente publicação. 
Sugerimos fortemente que os leitores iniciem os estudos apenas após a revisão 
dos conceitos básicos destes temas. 
TEMA 1 – INTRODUÇÃO À IOT 
A evolução da eletrônica e a miniaturização dos componentes permitiu o 
acréscimo de determinada capacidade de processamento em objetos de uso 
cotidiano como máquinas de lavar, fechaduras e geladeiras. A popularização do 
acesso à internet, na grande maioria de lares e escritórios, por outro lado, 
associada a essa eletrônica reduzida e barata, hipoteticamente, permite a 
interconexão destes objetos autonomamente à internet, surge assim a ideia da 
conexão das “coisas” diretamente à internet, sem a intervenção humana. A 
internet das coisas (Internet of Things – IoT) tem assim uma origem singela, 
como forma de facilitar a operação de utensílios do cotidiano humano pela sua 
conexão à rede (Pacheco, 2018). 
Breve se percebeu o potencial da ideia. Sistemas embarcados, sensores 
e atuadores se incorporaram a lista de “coisas” conectáveis. A figura abaixo 
ilustra esta conexão autônoma com a internet. 
Figura 1 – IoT conectado diretamente a nuvem 
 
 
Fonte: Monk, 2018. 
A qualidade de vida humana está fortemente impactada pela presença de 
objetos autônomos conectados à internet na agricultura, pecuária, indústria, 
saúde, transporte, controle de trânsito, segurança… Nossa visão de futuro, hoje, 
inclui invariavelmente transportes autônomos, cidades inteligentes, 
reconhecimento de imagens, sensoriamento e outras facilidades providas pela 
IoT. 
Diante do que argumentamos, podemos tentar conceituar o tema. IoT 
refere-se a conexão de objetos à internet, e não aos objetos propriamente ditos. 
Os objetos conectáveis à internet são (não muito precisamente) chamados, em 
português, de objetos IoT. Pelo fato desses objetos terem certa capacidade de 
processamento, sensoreamento e atuação sobre o meio, como veremos em 
breve, muitas vezes são chamados de objetos inteligentes. Ainda como 
complemento a esta tentativa de definição de IoT podemos citar Santos e 
colegas (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. Todavia, estas possibilidades 
apresentam riscos e acarretam amplos desafios técnicos e sociais. 
O autor, além de nos presentear com uma boa definição, nos deixa uma 
admoestação quanto à questão de segurança, que embora não seja objeto 
desse estudo, deve ser tema de aprofundamento por cada um de nós, dada sua 
especial importância. 
TEMA 2 – ARQUITETURA DOS OBJETOS IOT 
Um objeto capaz de conexão à internet tem uma arquitetura de controle e 
atuação elementar. Dito de outra forma, qualquer objeto para ser controlado ou 
fornecer dados ou ambos precisam de uma estrutura eletrônica interna básica, 
que chamaremos de arquitetura interna, bem como demandará uma 
superarquitetura externa, de suporte à sua operação (doravante dita IoT-A), a 
 
 
exemplo de um middleware de nuvem e uma camada de aplicação. Vamos então 
detalhar essas arquiteturas. 
2.1 Arquitetura interna 
Basicamente, a arquitetura interna de um objeto IoT é uma eletrônica com 
capacidade de conexão e também de processamento local, mesmo que limitado. 
Além do processamento deve ser possível acrescentar as capacidades de 
sensoriamento e atuação. 
Imaginemos que enviamos um pacote de dados endereçado a um atuador 
IoT. Esse objeto deve possuir a habilidade de tratar o protocolo de comunicação 
e extrair os bits correspondentes ao comando a ser executado. Deve, 
igualmente, ser capaz de converter esse comando binário em um pulso de 
atuação para a máquina que é por ele controlada. 
De forma equivalente, um sensor IoT deve possuir a habilidade de 
converter a percepção externa em um código binário, empacotá-lo segundo o 
protocolo de comunicação utilizado e enviá-lo para a rede. Naturalmente, as 
funções de atuação e sensoriamento do meio não precisam ser independentes, 
ou seja, o mesmo equipamento IoT pode sensorear e atuar sobre o meio, 
compartilhando a capacidade de processamento. 
Genericamente podemos definir seis blocos funcionais para um objeto IoT 
(veja Figura 2, abaixo): comunicação, identificação, semântica, computação, 
sensores e atuadores (serviços). Por se tratarem de blocos funcionais, eles 
podem ser, do ponto de vista eletrônico, agregados em um único ou em vários 
componentes eletrônicos. 
A função de comunicação e de identificação dispensa, neste momento, 
explicações, assim como as funções de atuação, computação e sensoriamento, 
uma vez que a elas dispensamos seções específicas mais a frente em nosso 
estudo. 
A função semântica refere-se ao tratamento dos dados obtidos pelos 
sensores de forma a extrair conhecimento das informações colhidas segundo 
alguns algoritmos padronizados. 
 
 
 
Figura 2 – Blocos funcionais de objetos IoT 
Fonte: Santos et al., 2016. 
Para exemplificarmos, uma lâmpada conectada à internet deve ser capaz 
de processar os comandos de intensificar, reduzir ou desligara fonte luminosa. 
Não basta, entretanto, interpretar a sequência de bits recebidos; também é 
necessário que o trem de bits seja convertido em um nível de tensão sobre a 
lâmpada. Essas funções normalmente são realizadas por microcontroladores 
instalados em placas que contêm alguns acessórios eletrônicos, os quais 
facilitam a atuação e recepção de estímulos do meio externo. 
Uma distinção importante que precisamos fazer desde cedo quando 
tratamos de objetos inteligentes, se refere à integração do controlador em 
relação ao objeto. Para que possamos bem sedimentar esse conceito, devemos 
investigar o que é um sistema embarcado. 
Sistemas embarcados são uma eletrônica de controle que permite a 
operação de equipamentos de uso cotidiano. Vamos tomar o exemplo de um 
ar-condicionado de parede. A operação desse equipamento depende de um 
controle (local ou remoto) ou, dito de outra forma, de uma eletrônica embarcada 
de controle (Maschietto, 2021). 
 
 
Não necessariamente um sistema embarcado estará conectado à 
internet, mas havendo um sistema embarcado de controle, será possível 
embarcar também um sistema inteligente de IoT. 
Esse procedimento normalmente é feito pela associação de uma placa 
IoT ao sistema de controle presente no equipamento. Essa placa complementará 
as funções de gerenciamento, acrescentando conectividade e eventualmente 
capacidade semântica à supervisão do objeto. Na figura abaixo temos um 
exemplo de placa para IoT, a famosa Arduino Uno. 
Figura 3 – Placa para IoT Arduino Uno com microcontrolador AT mega 328 
Crédito: Arduino/CC. 
Existem, entretanto, sistemas embarcados que têm todas as 
características IoT nativas, exemplos são as smart TVs e fechaduras 
inteligentes. Nesses casos, naturalmente, não há necessidade de se agregar 
placas IoT aos controles embarcados. 
2.2 IoT-A 
 Como comentamos acima, certos objetos já embarcam em seu sistema 
de controle a possibilidade de conexão com a internet. Essa implementação, 
normalmente, tem por objetivo reduzir o custo eletrônico, principalmente se 
 
 
considerarmos objetos simples como lâmpadas, ventiladores ou aquecedores 
por exemplo. Dessa forma, retira-se parte das exigências do dispositivo 
inteligente, permitindo a construção de eletrônicas embarcadas mais simples e 
mais baratas. 
Imagine agora uma macroarquitetura que permita repousar parte da 
solução em aplicações residentes na nuvem. Essa solução permitirá eletrônicas 
embarcadas ainda mais espartanas e econômicas sem perdas de 
funcionalidade. 
A macroarquitetura que envolve não só o objeto inteligente, mas os 
recursos necessários para sua operação em rede, é chamada IoT-A. 
Alguns são os modelos de referência de IoT-A. Conforme Maschietto e 
colegas (2021, p. 62), os modelos podem ser compostos por três a cinco 
camadas funcionais. O modelo mais elementar, IoT-A de três camadas, 
representado na figura abaixo, inclui um gateway na eletrônica embarcada dos 
objetos, mantendo a função de endereçamento e handshake do protocolo de 
comunicação no objeto. A gestão da comunicação entre o cliente e o objeto, 
entretanto, nesse modelo, será feita pela camada de middleware sob o controle 
da aplicação. 
Figura 4 – IoT-A de 3 camadas 
Camada detecção física 
 
G
a
te
w
a
y
 
 
C
o
is
a
 Sensores 
Atuadores 
Sistemas embutidos 
 
IoT Middleware 
 
S
e
g
u
ra
n
ç
a
 
Serviço de descoberta 
Gerenciamento de contexto 
Gerenciamento QoS 
Dispositivo de descoberta 
 
 
 
Camada de aplicação 
Consumidor/coisa 
Controle/comando 
 
Fonte: Maschietto et al., 2021, p. 62. 
Outro modelo possível é a IoT-A de quatro camadas, na qual os objetos 
necessitam de um adaptador, ou interface, para a conexão. As funções de coleta, 
armazenamento de informações e identificação seguem embarcadas no objeto, 
mas uma camada superior de comunicação adapta as informações bidirecionais 
e as conformam a um protocolo universal de comunicação. Acima dessa camada 
está a de internet, que extrai informações dos dados e gerencia a comunicação. 
Ainda temos uma quarta camada, de aplicação, que fornece a interface humana 
de operação. Essa IoT-A é ilustrada abaixo. 
 
Figura 5 – IoT-A de 4 camadas 
Camada de 
aplicação 
App 1 App 2 App 3 App 4 App N 
Camada de 
internet 
Internet 
Camada de 
adaptação Adaptador Adaptador Adaptador 
Camada 
das coisas 
 
 
 
 
Fonte: Maschietto et al., 2021, p. 63. 
 
 
O IoT-A de cinco camadas, ilustrada abaixo, tem por base a camada de 
percepção que pode incluir sensores e leitores simples conectados um gateway 
próximo. A camada de rede permite a múltipla conectividade dos objetos com as 
plataformas de comunicação, roteando e cuidando do endereçamento. A 
próxima camada, de gerenciamento, é responsável pela operação dos objetos, 
monitoramento seu status. A função semântica e de armazenamento fica a cargo 
da camada de processamento. A camada de aplicação fornece a interface de 
operação. 
Figura 6 – IoT-A de 5 camadas 
 
Fonte: Maschietto et al., 2021, p. 65. 
 Essas macroarquiteturas são, como comentamos desde o início da 
exposição, meras arquiteturas de referência, ou seja, cada implementação 
escolherá aquela que melhor se adapte aos requisitos de projeto. 
Para entender essas possibilidades de escolha, suponha uma instalação 
industrial com grande profusão de objetos, como leitores RFID, sensores de 
esteiras e de posicionamento e acionadores de equipamentos. Conectar cada 
objeto à rede em uma arquitetura de três ou quatro camadas não seria 
 
 
economicamente interessante, dada a grande quantidade de objetos, fato que 
exigiria recursos consideráveis de endereçamento e adaptação ao protocolo de 
rede para cada objeto. Nesse caso, uma arquitetura de cinco camadas é mais 
viável, permitindo economia de recursos. 
Tome, agora, uma outra instalação predial, na qual, em cada sala, temos 
um equipamento de climatização inteligente, por exemplo. Nesse caso, 
implementar uma arquitetura de cinco camadas pode ser inviável, dadas as 
distâncias entre objetos. A arquitetura de três camadas será, então, mais 
eficiente e econômica. 
TEMA 3 – MIDDLEWARE IOT 
 Comentamos anteriormente que, de forma independente da IoT-A 
escolhida, parte das funcionalidades de IoT podem ser delegadas a um 
middleware. V amos agora entender este processo. 
3.1 Middleware 
Inicialmente, é importante que entendamos a ideia de um middleware de 
forma genérica. De fato, a expressão middleware não foi cunhada para o IoT. 
Toda vez que distintos sistemas operacionais precisam se conectar a uma ou 
várias aplicações, é necessária a presença de um tradutor intermediário, ou 
middleware. Esse código computacional permitirá uma operação transparente 
entre usuários, dados e aplicações em sistemas distribuídos. A sedimentação de 
aplicações em nuvem tornou a criação destes softwares imprescindíveis. 
As organizações buscam o middleware como uma maneira de 
administrar essa complexidade e manter o desenvolvimento rápido e 
econômico de aplicações. O middleware é capaz de oferecer suporte 
a ambientes de aplicação que funcionam de maneira estável e 
consistente em uma plataforma altamente distribuída. 
Independentemente de você criar em um ambiente e implantar em 
outro, não haverá discrepâncias no funcionamento graças ao 
middleware subjacente às aplicações. (Red Hat, 2021) 
Desta forma, a utilização de camadas intermediárias de interconexão de 
arquiteturas distintas é uma solução que permite boa flexibilidade de projeto bem 
como de manutenção. 
 
 
3.2 Middleware para objetos IoT 
Os objetos inteligentes são equipamentos tipicamente heterogêneos, com 
capacidades e arquiteturas computacionais distintas. Incluir uma camada de 
middleware não só permite maior liberdade ao projetista de equipamentos para 
IoT como também facilita o interfaceamento entre estes objetos e o controle 
humano. 
Plataformas de middleware podem agregarprocessos de IA, tratando 
dados em grandes quantidades para produzir informações sintéticas. Por outro 
lado, a utilização desses códigos permite também flexibilidade nas redes de 
conexão com os objetos, mesmo para eletrônicas embarcadas simples, ou seja, 
alterações na rede de conexão ou alterações no posicionamento do objeto 
podem ser facilmente detectadas pelo middleware, o qual realizará as alterações 
de endereçamento necessárias em relação as aplicações que necessitem deste 
objeto. 
TEMA 4 – CONECTIVIDADE PARA IOT 
Quando estamos estudando o tema de IoT e tocamos no assunto de 
conectividade, nosso pensamento se volta às estruturas clássicas de redes 
locais e a conexão com a internet. De fato, conectividade é um tema mais amplo 
englobando todas as formas de interligação entre dispositivos. 
Segundo Ideali (2021), conectividade, em eletrônica, é a capacidade de 
interligação entre equipamentos de forma adequada para viabilizar as trocas de 
dados e informações entre eles. 
Atualmente, a conectividade das máquinas computacionais é tão 
importante quanto são as próprias máquinas. Máquinas isoladas perdem, 
paulatinamente, sua utilidade. Esse fato se vê particularmente maximizado com 
a sedimentação dos objetos inteligentes em todos os ambientes, tanto no âmbito 
industrial, de onde se originaram, como em aplicações comerciais e residenciais. 
Soluções de interligação entre microcontroladores e sensores/atuadores, 
além da própria conexão entre microcontroladores isolados, são hoje o maior 
desafio técnico da conectividade, dadas as exigências bastante distintas de 
protocolos e técnicas de interconexão (Ideali, 2021, p. 8). A este tema nos 
dedicaremos brevemente nas próximas linhas. 
 
 
4.1 Protocolo 
A conexão entre máquinas computacionais deve seguir um padrão de 
comunicação comum, conhecido por elas. A esse padrão de comunicação 
damos o nome de protocolo. Um protocolo divide os dados a serem trocados em 
segmentos predefinidos, ditos quadros (ou frames, em inglês). Os frames, de 
maneira geral, são compostos minimamente de um cabeçalho de controle, 
endereço de origem, endereço de destino, dados úteis e finalizador (Ideali, 2021, 
p. 26). 
Tomando o modelo de camadas OSI, cada camada terá um protocolo 
próprio e independente das demais camadas. Assim, ao conectar dois hosts em 
uma rede local por um cabo de RJ45, através de um switch camada 3, por 
exemplo, temos o protocolo da camada física, o protocolo da camada de enlace 
e o protocolo da camada de rede operando simultaneamente. O padrão Ethernet 
é um exemplo de protocolo de enlace, embora o padrão IEEE 802.3, do qual é 
originário, estabeleça parâmetros para a camada física também. 
4.2 Conectividade com fio 
O uso de cabos metálicos ou ópticos como solução para conectividade de 
objetos inteligentes tem aplicação a cada dia mais restrita. Cabeamentos 
clássicos baseados em RJ45 para essa aplicação estão em desuso, embora 
algumas placas para IoT ainda apresentem essa interface por constituir uma 
forma bastante econômica e segura de conexão. 
Há uma segunda interface fiada bastante comum em placas para IoT: 
trata-se da USB. Essa interface é preservada em placas para IoT, principalmente 
para viabilizar as primeiras configurações. É fato que existe uma franca 
tendência a migrar esse estágio de configuração também para a interface sem 
fio, cabendo ao fabricante a decisão em função dos custos associados. 
Dedicaremos, em breve, alguma atenção à interface USB dada sua popularidade 
na tecnologia que estamos estudando. 
Em usos industriais de objetos inteligentes predominam cabeamentos 
ópticos, imunes aos intensos ruídos eletromagnéticos presentes nas linhas de 
produção. Em alguns casos, quando limitações mecânicas impedem a utilização 
de cabos ópticos, cabos coaxiais são uma solução possível. 
 
 
Os protocolos de comunicação adaptados para camadas físicas ópticas 
ou metálicas coaxiais são variados e restritos a aplicações industriais. 
4.3 Conectividade sem fio 
Claramente, nas aplicações de objetos IoT de uso geral, há uma clara 
tendência à utilização de conectividade sem fio. As soluções sem fio incluem 
principalmente o uso de radiopropagação, mas também são possíveis soluções 
ópticas, como a interface IrDA (Infrared Data Association) que utiliza radiação 
infravermelha para transmitir dados entre duas fontes próximas. Naturalmente 
essa solução implica em certa visibilidade e proximidade, o que impede uma 
operação suficientemente flexível. Dessa forma, a opção por radiocomunicação 
é preponderante na conectividade de objetos IoT. 
TEMA 5 – PROTOCOLO USB 
O protocolo USB está presente em hipoteticamente todas as placas para 
IoT na atualidade, como forma de acesso primário, ao menos para as 
configurações iniciais. Algumas placas exigem que configuremos alguns 
parâmetros da USB; por esse motivo, será necessário conhecê-la ao menos 
basicamente. Para um detalhamento completo sobre a interface, a USB 
Organization fornece extensa documentação gratuita disponível em: 
www.usb.org/documents (acesso em: 16 fev. 2022), cujo acesso recomendamos 
para aprofundamento do tema. 
Segundo Ideali (2021), o Universal Serial Bus (USB), desenvolvido em 
1995, é um conjunto de padrões de interface fiada de alta velocidade entre 
periféricos de sistemas eletrônicos. Foi idealizado como uma expansão externa 
do barramento de um computador para permitir a conexão de periféricos em 
hotswapping, ou seja, sem a necessidade de alterar a operação do computador. 
5.1 Versões 
A primeira versão do protocolo foi comercializada em 1994, USB 1.0, com 
capacidade de até 12Mbps e número máximo de dispositivos 127. Em 1996, o 
USB foi integrado ao Windows e passou a fazer parte das interfaces 
computacionais padrão. 
 
 
A versão presente na maioria dos equipamentos atualmente é a USB 3.0, 
compatível com as versões anteriores e capaz de transferir até 4,8 Gbps. 
Versões mais rápidas como a 3.2 e a Thunderbolt 3, mais raras, podem atingir 
20 e 40 Gbps. 
O USB–C é um padrão mais robusto de conectorização e modifica vários 
aspectos do que afirmamos sobre as versões anteriores do USB. Padronizado 
pelo USB–IF (USB Implementers Forum) em 2014, usa 24 pinos, permitindo 
transferir diversos padrões de dados, além do tradicional USB, como HDMI e 
Thunderbolt. O recurso de entrega de energia é também uma novidade 
interessante que permite tensões de 20 Vcc em até 5ª, o que provavelmente o 
tornará um interessante padrão de alimentação de dispositivos inteligentes e 
acionadores de baixa potência. O power delivery protocol (protocolo de entrega 
de potência) da versão USB 3.0, de fato, é bastante flexível, permitindo 
inicialmente quatro níveis de tensão nominal (5 V, 9 V, 15 V e 20 V), embora com 
acréscimo de facilidades de software seja possível programar o nível de tensão 
em etapas de 20 mV ou mesmo fornecer carregamento de corrente constante. 
Recentemente, para permitir a interligação direta entre periféricos e 
smartphones, surgiu o padrão USB On-The-Go, que permite essa conexão 
desde que o aplicativo correspondente exista no telefone celular. Não se trata 
propriamente de um novo padrão de protocolo, mas apenas de uma aplicação 
que utiliza o protocolo já existente, controlando o periférico e permitindo a 
adaptação do cabo. 
 
 
 
Figura 7 – Cabo USB On-The-Go 
Crédito: Taweephoto/Shutterstock. 
5.2 Topologia e fluxo de dados 
A topologia típica do sistema USB é estrela em camadas, ou seja, 
podemos expandir o número de portas USB acrescentando um hub, até cinco 
camadas de hubs são aceitas pelo protocolo, como ilustrado abaixo. 
 
 
 
Figura 8 – Níveis possíveis para USB 
Fonte: USB, 2000, p. 16. 
O endereçamento possui 7 bits (o que justifica o número máximo de 
dispositivos suportados), mas um equipamento conectado a um hub pode, em 
outra porta, conectar-se a outro hub sem a necessidade de compartilharo 
endereçamento entre os hubs. 
As portas USB disponíveis em máquinas computacionais são ditas portas 
de upstream, ao passo que as portas de periféricos são chamadas de 
downstream. Uma porta upstream USB pode suportar periféricos compostos 
(microfone e fone de ouvido, por exemplo) ou singulares. Nesse sentido, a 
interface deve ser capaz de tratar múltiplas conexões entre um host e um mesmo 
periférico, ditas funções (functions, em inglês). Logicamente, as conexões se 
comportam como seções, conforme ilustrado abaixo. 
 
 
 
Figura 9 – Conexão física x lógica USB 
Fonte: USB, 2000, p. 32. 
Na figura, pode-se observar que a camada física controla basicamente a 
conexão fiada, ao passo que há uma conexão lógica entre o host e o periférico 
(equivalente a camada de enlace no modelo OSI). Nessa conexão, o host 
controla o periférico como um equipamento único composto de várias 
terminações (endpoints). A próxima camada de conexão lógica trata as 
interfaces de cada função e seria equivalente, por aproximação, a camada de 
rede do modelo OSI. 
Os dados são decodificados do padrão de linha (descrito nas próximas 
seções) e então direcionados para as terminações lógicas as quais se 
conectarão com a interface lógica de cada função do periférico. Cada terminação 
 
 
lógica do periférico recebe uma numeração definida em fábrica. Uma terminação 
lógica, entretanto, é um ente de comunicação simplex, ou seja, é necessário criar 
para cada interface lógica um endpoint de leitura e outro de escrita. O tamanho 
dos pacotes de dados também pode ser distinto entre os diversos endpoints de 
um mesmo periférico. 
Todo periférico deve possuir uma operação default no endpoint “0”, ou 
seja, o host fará o handshake com essa terminação lógica default, chamada 
default control pipe. 
Do lado host são criados buffers. Cada buffer estará relacionado a uma 
única interface de função. Dessa forma, o host poderá ter SWs distintos (SWs 
Clientes) para controlar cada função do periférico sem que essas aplicações 
sofram interferências mútuas. A esse canal virtual entre os SWs Clientes e as 
interfaces lógicas designou-se pipe. Dessa forma, um pipe representa a 
possibilidade de comunicação entre um software cliente no host, via buffer de 
memória, e uma terminação lógica (endpoint) no periférico. O SW de controle da 
interface USB (dito SW de Sistema) terá o controle do Default Control Pipe. 
5.3 Camada física 
Na camada física, vários são os conectores possíveis, como se vê na 
figura abaixo. Originalmente foram criados os conectores A e B. Nestes, os 
soquetes do tipo A podem ser usados em portas upstream ou downstream; já no 
tipo B, apenas em downstream. Com a proliferação e redução física dos 
equipamentos celulares, padrões de menores dimensões foram disponibilizados. 
O tipo C foi desenvolvido para maior compactação, velocidades maiores e boa 
capacidade de transmissão de energia, para alimentação. 
 
 
Figura 10 – Portas USB 
Fonte: Kinast, 2019. 
Os formatos dos conectores, como se observa na Figura 10, são bastante 
variados. A função de cada pino foi inicialmente padronizada para os tipos A e B 
com apenas quatro pinos, conforme abaixo: 
• Pino 1 – Vcc (alimentação de 5 V corrente contínua) – fio vermelho 
• Pino 2 – Dados (pino de retorno para dados) – fio branco 
• Pino 3 – Dados – fio verde 
• Pino 4 – Terra (retorno da alimentação de 5 V corrente contínua) – fio 
preto 
Os novos formatos miniaturizados, como podem atender 
simultaneamente a host e periféricos, ganharam um quinto pino (ver Figura 11), 
que permite identificar esta diferença. A nova função de cada pino está descrita 
 
 
abaixo; conectores USB do tipo C são, entretanto, um padrão bastante diverso 
do apresentado nesta seção. 
• Pino 1 – Vcc (alimentação de 5V corrente contínua) – fio vermelho 
• Pino 2 – Dados (pino de retorno para dados) – fio branco 
• Pino 3 – Dados – fio verde 
• Pino 4 – Tipo de equipamento – Tipo A se conectado a Terra, Tipo B se 
aberto. 
• Pino 5 – Terra (retorno da alimentação de 5V corrente contínua) – fio preto 
Figura 11– Pinagem das portas USB 
Fonte: Marques, 2013. 
5.4 Protocolo da camada física 
O protocolo da camada física do padrão USB utiliza formato NRTZI (Non-
Return to Zero Inverted), obtido pelo uso dos pinos D- e D+ em push-pull, ou 
seja, quando sinal em D+ for +Vcc o sinal em D- será -Vcc. Essa técnica, além 
de garantir maior excursão do sinal, também reduz ruídos sistemáticos. As 
tensões aceitáveis para reconhecer D- serão aquelas abaixo de 0,3 V (ViL), ao 
passo que D+ será aceito se a tensão ultrapassar 2,8 V (ViH), como ilustrado 
abaixo. 
Figura 12 – Níveis de D- e D+ 
Fonte: USB, 2000, p.128. 
 
 
O protocolo utiliza todas as combinações de estados D+ D- com 
significados próprios antes do início da transmissão de informações entre host e 
periférico. 
Os símbolos básicos para interfaces de baixa velocidade são: 
• “J” D+ baixo e D- Alto 
• “K” D+ Alto e D- baixo 
Já em interfaces de velocidade padrão estes símbolos serão invertidos. 
Para ambas as velocidades temos: 
• SE0 (Single-ended zero) ambos baixos e 
• SE1 (Single-ended “1”) ambos altos 
O nível lógico 0 é obtido pela transição entre os níveis J e K, já o nível 
lógico 1 é interpretado pela não transição de níveis. 
A presença de resistores de pull-down (conectados a -Vcc) no host faz 
com que a interface fique em SE 0 enquanto livre. Um periférico terá resistores 
de pull-up; assim, ao se conectar, levará a linha de dados ao estado J. O host 
perceberá a variação de tensão na interface, e poderá então dar início a 
comunicação. 
A interface USB é síncrona, ou seja, a cadência de transmissão deve 
seguir determinado relógio com velocidade definida, o qual será sincronizado no 
 
 
periférico a partir da recepção do sinal SYNC do host. Para que esse processo 
ocorra corretamente é necessário que o host conheça a velocidade de operação 
do periférico previamente. O posicionamento do resistor de pull-up do periférico 
informará ao host se o dispositivo é de baixa velocidade ou de velocidade padrão 
da interface, como ilustrado abaixo. 
Figura 13 – Identificação de velocidade do USB 
Fonte: USB, 2000, p. 141. 
Assim há uma conexão inicial de controle de baixa velocidade ou em 
velocidade padrão, selecionada em função da posição do resistor de pull-up. 
Dispositivos de alta velocidade serão inicialmente identificados como padrão, 
mas o host enviará sequências de setup e aguarda a resposta do periférico 
informando sua eventual capacidade de conexão em alta velocidade. 
Quando um periférico é conectado a um hub ou host, haverá um período 
de deboucing ou de quarentena de 100 ms, no qual o host aguardará a 
 
 
estabilização elétrica do periférico. Logo após a quarentena de conexão, o host 
enviará um sinal de reset, que será composto de D+ e D-como a 
estandardização das trocas de pacotes. A primeira característica interessante do 
USB é a ordem dos bits a serem transmitidos. A leitura se dá da esquerda para 
a direita. Os bits são colocados então no barramento a partir do menos 
significativo. 
Quando um dispositivo novo é conectado à rede USB, ocorrerá 
inicialmente o reset do dispositivo, como descrevemos acima. Após o reset, o 
host enviará um pacote de token constituído de um byte de sincronismo para 
USB de baixa velocidade e 32 bits para alta, dito SYNC. O objetivo desse quadro 
é apenas sincronizar o novo dispositivo com a rede. Os últimos 2 bits desse 
pacote identificarão o fim do sincronismo e o início do pacote de dados 
propriamente dito. Por tal motivo, esses bits recebem o nome de Start-of-Packet 
(SOP). 
Concluído o sincronismo, há um byte de identificação de tipo de pacote 
(PID – Package Identification Data) composto de um nible e de seu 
complemento. 
O PID identifica se o pacote é de token, dados, handshake ou especial, 
conforme a figura abaixo. 
Figura 15 – Tipos de PID 
PID Type PID Name PID* Description 
Token OUT 
IN 
SOF 
SETUP 
0001B 
1001B 
0101B 
1101B 
Address + endpoint 
number in host-to-
function transaction 
Address + endpoint 
number in function-to-
host transaction 
Start-of-Frama marker 
and frame number 
Address + endpoint 
number in host-to-
 
 
function transaction for 
SETUP to a control pipe 
Data DATA0 
DATA1 
DATA2 
MDATA 
0011B 
1011B 
0111B 
1111B 
Data packet PID even 
Data packet PID odd 
Data packet PID high-
speed, high bandwidth 
isochronous transaction 
in a microframe 
Data packet PID high-
speed for split and high 
bandwidth isochronous 
transactions 
Handshake ACK 
NAK 
STALL 
NYET 
0011B 
1011B 
0111B 
1111B 
0010B 
Receiver accepts error-
free data packet 
Receiving device cannot 
accept data or 
transmitting device 
cannot send data 
Endpoint is halted or a 
control pipe request is 
not supported 
No response yet from 
receiver 
Special PRE 
ERR 
SPLIT 
PING 
Reserved 
1100B 
1100B 
0100B 
0000B 
(Token) Host-issued 
preamble. Enables 
downstream bus traffic 
to low-speed devices. 
(Handshake) Split 
Transaction Error 
Handshake (reuses 
PRE value) 
(Token) High-speed 
Split Transaction Token 
(Token) High-speed flow 
control probe for a 
bulk/control endpoint 
Reserved PID 
 
Fonte: USB, 2000, p. 196. 
 
 
Seguindo um PID estarão 11 bits, 7 de endereço do destino (DA – Device 
Adress) e um nible de fim de endereçamento (ENDP). O ENDP permite a 
identificação do endereçamento de funções em um mesmo periférico. 
Concluído o endereçamento, 5 bits de redundância cíclica (CRC5) são 
acrescentados se o pacote for de token. A CRC5 é calculada para os bits após 
o PID e antes do bit stuffing. 
Para pacotes não token a CRC será de 16 bits. Transmitida a CRC, 3 bits 
de fim de pacote “001” (EOP – End of Package) são incluídos para informar o 
fim da transmissão. 
Concluído o reset e recebido o pacote de token, o novo dispositivo 
assumirá o endereço enviado e responderá com um pacote de handshake de 
aceitação (ACK – acknoledge). Um pacote de handshake é constituído apenas 
pelo SYNC, PID e EOP. Segundo Ideali (2021), o segmento PID desse tipo de 
pacote pode conter os códigos de ACK, NAK (não aceito), STALL (indicando erro 
no dispositivo), NYET (dispositivo ocupado, aguardando fim de transmissão) e 
ERR (transmissão recebida com erro). 
O próximo pacote do host também será de token, e poderá indicar se o 
host está pronto para receber dados (Token IN), se enviará dados para o 
dispositivo (Token OUT) ou se o host precisa configurar algo no dispositivo 
A partir desse ponto o periférico estará pronto para trocar dados com o 
host participando da rede USB existente. 
FINALIZANDO 
Nesta aula buscamos construir o conceito de IoT e dos objetos 
inteligentes, descrevendo algumas das arquiteturas possíveis para essas 
eletrônicas e inteligência. Introduzimos o conceito de conectividade dos objetos 
IoT e finalmente nos debruçamos sobre o estudo de uma interface bastante 
tradicional, mas onipresente nestes objetos, a interface USB. 
 
 
 
REFERÊNCIAS 
IDEALI, W. Conectividade em automação e IoT. Rio de Janeiro: Alta Books, 
2021. 
KNAST, P. O que é USB e quais os tipos? Oficina da Net. 2019. Disponível em: 
https://www.oficinadanet.com.br/hardware/24810-quais-os-tipos-de-cabos-usb-
e-qual-deles-usar. Acesso em: 17 fev. 2022. 
MASCHIETTO, L. Arquitetura e infraestrutura de IoT. Grupo A, 2021. 
MARQUES, E. Futuro conector USB será menor e poderá ser encaixado 
independentemente de orientação. MacMagazine. 2013. Disponível em: 
https://macmagazine.com.br/post/2013/12/05/futuro-conector-usb-sera-menor-
e-podera-ser-encaixado-independentemente-de-orientacao/. Acesso em: 17 fev. 
2022. 
MONK, S. Internet das coisas: uma introdução com o photon. Grupo A, 2018. 
PACHECO, L. A. B. Arquitetura para privacidade na integração de internet 
das coisas e computação em nuvem. Dissertação de mestrado. Brasília: UnB, 
2018. 
RED HAT. O que é middleware e para que serve. 2021. Disponível em: 
https://www.redhat.com/pt-br/topics/middleware/what-is-middleware. Acesso 
em: 16 fev. 2022. 
SANTOS, B. P. et al. Internet das coisas: da teoria à prática. Belo Horizonte: 
UFMG, 2016. 
USB. USB 2.0 full documentation. Universal Serial Bus specification. Revision 
2.0. 2000. Disponível em: https://www.usb.org. Acesso em: 16 fev. 2022.