1

Apontamentos - Internet of Things

Aula 1 – Introdução
O que é IoT?
A Internet das Coisas, também chamada de Internet dos Objetos, semanticamente significa
uma rede mundial de objetos interconectados unicamente endereçáveis, com base em
protocolos de comunicação padrão.
O termo Internet das Coisas passou a descrever uma série de tecnologias e disciplinas de
pesquisa que permitem que a Internet alcance o mundo real dos objetos físicos.
A IoT não é o resultado de uma única tecnologia nova; em vez disso, vários
desenvolvimentos técnicos complementares fornecem recursos que, juntos, ajudam a
preencher a lacuna entre o mundo virtual e o mundo físico.
O termo Internet das Coisas foi adicionado ao Dicionário Oxford em agosto de 2013,
definido como: «Uma proposta de desenvolvimento da Internet em que os objetos do
quotidiano têm conectividade de rede, permitindo-lhes enviar e receber dados»
O National Intelligence Council (NIC) dos EUA listou a IoT nas seis tecnologias com
potencial impacto sobre os interesses dos EUA nos próximos 10 anos.
Fases evolutivas da Internet
▪ Conectividade (digitalizar acesso)
▪ Economia em rede (digitalizar negócios)
▪ Experiências imersivas (digitalizar interações)
▪ Internet das coisas (digitalize o mundo)

Fases evolutivas da Internet

 2

Impacto IoT
As projeções sobre o impacto potencial da IoT são impressionantes.
Cerca de 14 bilhões, ou apenas 0,06%, das “coisas” estavam conectadas à Internet há 5 anos.
A Cisco Systems prevê que no final de 2020 esse número chegará a 50 billion.
Estas novas conexões resultarão em US $ 19 trillion em lucros e economia de custos.

Genesis de IoT
Costuma-se dizer que a era de IoT começou entre os anos de 2008 e 2009.
 3

Durante esse período, o número de dispositivos conectados à Internet ultrapassou a população

mundial.

A pessoa responsável pela criação do termo “Internet das Coisas” é Kevin Ashton.
Enquanto trabalhava para a Procter & Gamble em 1999, Kevin usou essa frase para explicar
uma nova ideia relacionada à ligação da cadeia de abastecimentos da empresa à Internet.
«No século XX, os computadores eram cérebros sem sentidos - eles só sabiam o que lhes
dizíamos. Os computadores dependiam de humanos para inserir dados e conhecimento por
meio de digitação, códigos de barras e assim por diante. IoT vem mudando este paradigma;
no século XXI, os computadores estão a sentir as coisas por eles mesmos.»
O conceito de IoT tornou-se popular pela primeira vez no centro de Auto-ID, MIT
Uma importante iniciativa industrial está agora a ser realizada por grandes corporações onde
o nome Machine to Machine (M2M) é mais comumente usado.
Nomenclaturas alternativas para IoT
USN (ubiquitous (presente em todo lado) sensor networks)
M2M (Machine-to-Machine)
IoE (Internet of Everything)
Cloud of Things
Web of Things
Internet of Bodies
Componentes IoT
▪ Rede de Coisas
 4

▪ Armazenamento de dados
▪ Mecanismos de aprendizagem analítica/de máquina
«Com um trillion de sensores embebidos no ambiente - todos conectados por sistemas de
computação, software e serviços - será possível ouvir o batimento cardíaco da Terra,
impactando a interação humana com o globo tão profundamente quanto a Internet
revolucionou a comunicação.» Peter Hartwell, pesquisador sénior, HP Labs.

Global Datasphere: quantidade de informação digital gerada em cada ano

Um zetabyte é equivalente a um trillion de gigabytes.
Se pudesse armazenar toda a esfera de dados global em DVDs, teria uma pilha de DVDs que
poderia levá-lo à lua 23 vezes ou girar a Terra 222 vezes.
Se pudesse fazer o download de todo o 2025 Global Datasphere a uma média de 25 Mb/s, a
velocidade de conexão média atual na maioria dos países desenvolvidos, então uma pessoa
levaria 1,8 billion de anos para fazer isso, ou se todas as pessoas no mundo pudessem ajudar,
então poderia terminar em 81 dias.
 5

Gestão do Conhecimento - Transformando Dados em Sabedoria

Quanto mais dados são criados, melhor compreensão e sabedoria as pessoas podem obter.

Novas habilidades ➔ Data Science

Arquitetura IoT
6
 7

Padrões IoT

Desafios Tecnológicos da IoT

No momento, a IoT enfrenta muitos desafios, como:
 Escalabilidade
 Segurança
 Privacidade
 Big Data e Análise de Dados
 Interoperabilidade
 Fonte de alimentação
 Tolerância a falhas
 Comunicação wireless
 Complexidade do software
 Padronização Tecnológica
 Interação e comunicação de curto alcance
Desafios da IoT - Escalabilidade
Número de dispositivos aumentando exponencialmente:
- Como estes podem ser tagged/nomeados de forma exclusiva?
- Como os dados gerados por estes dispositivos podem ser geridos?
Embora a escala das redes de IT possa ser grande, a escala de OT pode ser de várias ordens
de magnitude maior.
 8

Desafios da IoT - Segurança

Com mais “things” se conectando a outras “things” e pessoas, a segurança é uma questão
cada vez mais complexa para a IoT.
Se um dispositivo for hackeado, a sua conectividade é uma grande preocupação. Um
dispositivo comprometido pode servir como um ponto de partida para atacar outros
dispositivos e sistemas.
As soluções de criptografia tradicionais gastam recursos de energia e largura de banda na
origem e no destino e, portanto, não podem ser prontamente aplicadas à IoT.
A autenticação é um grande problema, pois os procedimentos de autenticação atuais não são
viáveis no domínio IoT.
A integridade dos dados fica mais complicada quando existem nós autónomos, como RFID
tags.
Desafios tecnológicos da IoT - Privacidade
À medida que os sensores se tornam mais prolíficos na nossa vida quotidiana, muitos dos
dados que eles recolhem serão específicos para os indivíduos e as suas atividades.
Estes dados podem variar desde informações de saúde a padrões de compras e transações
num estabelecimento de retalho.
As preocupações com a proteção da privacidade têm sido uma barreira significativa contra a
difusão das tecnologias envolvidas em IoT.
Ao contrário da Internet, onde os problemas de privacidade surgem principalmente de
utilizadores ativos, os cenários de problemas de privacidade de IoT podem ameaçar até
mesmo as pessoas que não usam nenhum serviço de IoT.
Desafios tecnológicos da IoT - Big Data e análise de dados
A IoT e o seu grande número de sensores irão acionar uma quantidade significativa de dados
que devem ser manipulados.
Esses dados fornecerão informações e perceções críticas, mas apenas se puderem ser
processados de maneira eficiente.
O desafio é avaliar grandes quantidades de dados que chegam de diferentes fontes em várias
formas e fazer isso de forma oportuna e eficiente.
Desafios Tecnológicos da IoT - Interoperabilidade
Como acontece com qualquer outra tecnologia emergente, vários protocolos e arquiteturas
estão competindo por participação no mercado e padronização dentro de IoT.
Alguns desses protocolos e arquiteturas são baseados em elementos proprietários e outros são
abertos.
Os padrões IoT recentes têm ajudado a minimizar este problema, mas geralmente existem
vários protocolos e implementações disponíveis para redes IoT.
 9

Críticas e controvérsias da IoT

Dúvidas sobre as promessas da revolução da computação omnipresente, em áreas como:
 Privacidade
 Segurança
 Autonomia e Controlo
 Controlo social
 Manipulação política
 Impacto ambiental
 Influencia a tomada de decisão moral humana
Aula 2 – Sistemas operativos para IoT
Contexto IoT
A visão da IoT: "Tudo está conectado"
Cenários de aplicação:
• Medição inteligente
• Automação em edifícios
• Smart City
• Smart Grid
• Saúde estrutural
• Logística
Desafios em IoT
• Os dispositivos IoT são mais do que meros dispositivos incorporados com sensores
wireless. IoT é a interconexão de dispositivos de rede de sensores wireless (RSSF) com
espaço na Internet.
• Dispositivos IoT geralmente têm escassez de recursos de energia e memória. Geralmente
são pequenos e operados por bateria, com memória na ordem de 100 kbytes.
• Os dispositivos IoT são equipados com microcontroladores de 8 bits que foram deixados
para trás pela geração atual de desktops e laptops baseados em Windows / Linux / Mac.
• As caraterísticas e restrições distintas de IoT exigem um sistema operativo eficiente,
flexível, portátil e leve com baixo espaço de memória RAM e ROM / Flash.
• Hardware heterogéneo
o Variando desde microcontroladores de 8 bits a smartphones ou routers bastante
poderosos
o Várias interfaces de comunicação (principalmente, mas não se limitando a redes
wireless)
• CPU lenta, geralmente sem FPU
• Pouca memória, geralmente sem MMU (Memory Manage Unit)
• Recursos energéticos limitados
• Robustez e auto-organização
• Requisitos em tempo real
Sistemas operativos para IoT vs. sistemas operativos em tempo real
 10

• Sistemas operacionais típicos em tempo real:

o FreeRTOS
o QNX
o RTLinux

• Não projetado para eficiência energética ou redes restritas

• Sistemas operacionais tradicionais para IoT:

o Contiki
o TinyOS
• Conceitos:
o Design orientado a eventos
o Single-threaded
o Linguagem de programação especializada
O que considerar ao escolher um sistema operativo?
• Arquitetura
• Modelo de programação
• Agendamento/Scheduling
• Networking
• Gestão de memória
• Portabilidade
Recursos desejáveis do IoT OS
• Arquitetura: a arquitetura do kernel (conjunto de rotinas que constitui a interface entre o
programa do cliente/utilizador e o próprio hardware) pode ser monolítica, em camadas e
microkernel modular.
o Objetivo:
 Menor consumo de memória
 Interação de módulo menos dispendiosa
 Maior desempenho
 Maior confiabilidade do sistema
o Cumprir os objetivos sem que o código kernel se torne longo e complexo

 Kernel monolítico vs. Microkernel

O kernel monolítico é um grande processo único executado inteiramente num único
espaço de endereço. É um único ficheiro binário estático. Todos os serviços do kernel
existem e são executados no espaço de endereço do kernel. O kernel pode invocar
funções diretamente.
Nos microkernels, o kernel é dividido em processos separados, conhecidos como
servidores. Alguns dos servidores são executados no espaço do kernel e alguns são
executados no espaço do utilizador. Todos os servidores são mantidos separados e
executados em diferentes espaços de endereço. Os servidores invocam "serviços" uns dos
outros enviando mensagens via IPC (comunicação entre processos). Essa separação tem
 11

a vantagem de que, se um servidor falhar, os outros servidores ainda poderão funcionar

com eficiência.

Base para
Microkernel Kernel monolítico
comparação
Em serviços de utilizador de No kernel monolítico, os serviços
Básico microkernel e kernel, os serviços do utilizador e os serviços do
são mantidos num espaço de kernel são mantidos no mesmo
endereço separado. espaço de endereço.
Tamanho Microkernel são menores em O kernel monolítico é maior que o
tamanho. microkernel.
Execução
Tempos de execução mais lentos. Tempos de execução rápidos.
Extensível O microkernel é facilmente O kernel monolítico é difícil de
extensível. estender.
Se um serviço travar/crash, isso
Segurança Se um serviço travar, todo o
não influencia o funcionamento
sistema trava no kernel monolítico.
do microkernel.
Para escrever um kernel
Código Para escrever um microkernel,
monolítico, menos código é
mais código é necessário.
necessário.
QNX, Symbian, L4Linux, Linux, BSDs (FreeBSD, OpenBSD,
Singularity, K42, Mac OS X, NetBSD), Microsoft Windows
Exemplo Integrity, PikeOS, HURD, Minix, (95,98,Me), Solaris, OS9, AIX, HP-
and Coyotos. UX, DOS, OpenVMS, XTS-400 etc.

 Modelo de programação
o A hierarquia de memória e a simultaneidade decidem o modelo a ser utilizado.
o Afeta o desempenho e a produtividade do sistema.
 12

o Melhor utilizar a arquitetura na parte inferior para as aplicações executados na parte

superior.
o Os programadores podem usar o sistema de forma eficiente
o A linguagem assembly é a melhor alternativa para fazer a interface com o hardware,
mas o suporte a linguagens de alto nível é necessário para um desenvolvimento fácil.
o Programação orientada a eventos/event-driven versus programação multi-thread
 Programação orientada a eventos/ Event-Driven versus programação multi-thread
Problema: como aumentar a escala de processadores para lidar com muitas tarefas
simultâneas
Cargas de trabalho de tarefa normalmente têm muito I/O, um pouco de CPU

 Estratégia de simultaneidade/concurrency nº 1: Thread-per-Request

Executar cada solicitação/request de leitura de sensor na sua própria thread
Assumindo threads de kernel, o bloqueio de operações de I/O apenas paralisa uma thread

 Estratégia de simultaneidade/concurrency nº 2: Execução orientada a eventos/ Event-

driven
o Usar uma única thread para todas as solicitações
o Usar I/O sem bloqueio
 Substituir o bloqueio de I/O por chamadas que retornam imediatamente
 13

 O programa é notificado sobre eventos I/O interessantes

o Isso é filosoficamente semelhante a interrupções de hardware
 “Diga-me quando algo interessante acontecer”
 Programação Orientada a Eventos/Event Driven
o Implica um programa de organização como um autómato de estado finito
o Nunca chama funções de bloqueio
o Quando uma função retorna
 Precisa de um mecanismo de retorno de chamada para invocar o processo, ou
 O processo pode agrupar periodicamente os valores de retorno
o Muito eficiente; Não há switching/troca de contexto!
o Difícil de programar
 Agendamento/Scheduling
o É um dos principais fatores que determinam o desempenho do sistema.
o A latência (tempo de resposta), rendimento, justiça e tempo de espera dependem do
algoritmo de agendamento.
o O agendador/scheduler deve ser um agendador em tempo real
o Os schedulers devem ser eficientes em termos energéticos e suporte em multitasking
 Abordagens de agendamento/Scheduling
Kernel não preemptivo/multitarefa cooperativa
o Cada tarefa deve desistir explicitamente do controlo da CPU
 Por exemplo, retornar do código da tarefa, chamar a função de rendimento
o Os eventos assíncronos são tratados por rotinas de serviço de interrupção (ISRs)
o ISR sempre retorna à tarefa interrompida
o Pode usar código não reentrante (não executa a mesma tarefa/função em paralelo)
o O tempo de resposta do nível de tarefa pode ser mais lento, pois a tarefa mais lenta
deve ser concluída
o Geralmente não precisa de semáforos

Kernel preemptivo
o Em cada ponto de agendamento, a tarefa de maior prioridade pronta para ser
executada recebe o controlo da CPU
o Se uma tarefa de maior prioridade ficar pronta, a tarefa em execução no momento é
suspensa e movida para a fila de pronta
o O tempo máximo de resposta é menor do que no sistema não preemptivo
o Deve-se usar código reentrante (pode executar a mesma tarefa/função em paralelo)
o Dados partilhados normalmente precisam de semáforos (mecanismos de
sincronização de acessos a zonas de memória partilhadas)

 Multitarefa Cooperativa vs. Preemptiva

A diferença básica entre o escalonamento preemptivo e cooperativo é que no
escalonamento preemptivo a CPU é alocada para um processo por um tempo limitado.
Durante o agendamento cooperativo, a CPU é alocada a um processo até que ele seja
encerrado ou mude para o estado de espera.
 14

Um processo em execução em escalonamento preemptivo pode ser interrompido antes de

terminar, enquanto um processo em execução em escalonamento cooperativo não é
interrompido no meio da execução.

Cooperativo

Preemptivo

O agendamento preemptivo tem uma sobrecarga/overhead que resulta da mudança do

processo do estado pronto para o estado de execução e vice-versa, e da manutenção da
fila pronta. Por outro lado, o agendamento cooperativo não tem sobrecarga devido à
mudança do processo do estado de execução para o estado pronto.
No escalonamento preemptivo, se um processo com alta prioridade frequentemente
chega à fila de pronto, então um processo de prioridade mais baixa deve esperar muito
para ser executado e it may have to starve. Por outro lado, no escalonamento
cooperativo, se a CPU for alocada para o processo com maior tempo de burst, então um
processo com menor tempo de burst may have to starve.
O agendamento preemptivo é bastante flexível porque os processos críticos têm
permissão para aceder à CPU à medida que chegam à fila de pronto, independentemente
do processo que está a ser executado no momento. O escalonamento cooperativo é rígido
porque mesmo se um processo crítico entrar na fila de pronto, o processo atualmente em
execução na CPU não será perturbado.
 Sobrecarga/overhead na programação preemptiva
Um processo/thread em execução precisa preservar as suas informações de estado:
o Instrução atual - identificada com program counter
o Call stack - identificada com o ponteiro da pilha
 Argumentos, variáveis locais, endereços de retorno, links dinâmicos
o Outro estado da CPU
 Valores de registo (qualquer coisa que será partilhada e pode ser afetada por
outros processos) - registadores de propósito geral, ponteiro de pilha, etc.
 Status flags (zero, carry, interrupções habilitadas, carry bit, etc.)
o Outras informações: Ficheiros abertos, informações de gestão de memória, número
de processo, informações de agendamento
 15

o Armazenar informações relacionadas a thread num bloco de controlo de tarefa/ Task

Thread Control Block (TCB)
o Bloco de controlo de processo/Process Control Block = PCB ao mudar entre
processos (sobrecarga adicional)

 Estados do Tópico/Thread States

Uma Thread pode estar num dos cinco estados possíveis:
o New: Acabado de criar, mas ainda não está em execução
o Run: As instruções estão a ser executadas (apenas uma thread pode ser executada de
cada vez)
o Wainting/Blocking: O tópico está à espera que um evento ocorra
o Ready: O processo não está em wainting, mas ainda não está em execução (é um
candidato para execução)
o Terminated: o processo não funcionará mais
 16

 Networking
o As entidades IoT devem ser capazes de se comunicar com baixo consumo de
energia.
o Stacks TCP/IP convencionais e tecnologias de rede WSN não são adequadas para
IoT.
o A stack de rede IoT deve ser leve, confiável e habilitada para Internet.
o O Ipv6 é obrigatório em sistemas IoT para ter identidades exclusivas em redes
tremendamente grandes.
o Sistemas de comunicação, protocolos: 6LoWPAN (Rede de área pessoal wireless de
baixa potência sobre IPV6), RPL (Protocolo de roteamento IPv6 para redes de baixa
potência e com perdas) e CoAP (Protocolo de aplicação restrito) são projetados para
sistemas de baixa potência.
o A compressão do header e a inclusão de recursos mínimos ajudam a manter os
protocolos viáveis para IoT.

 Gestão da memória
o O objetivo principal é ter kernels simples e pequenos.
o Os requisitos dependem do tipo de aplicação e do suporte fornecido pelas
plataformas de hardware.
o A alocação de memória pode ser estática/dinâmica.
o Um mecanismo de alocação de memória estática é menos complexo, mas não
fornece a flexibilidade para gerir a memória conforme necessário em tempo de
execução. A gestão de memória dinâmica fornece isso ao custo de uma
implementação de sistema operacional mais complexa.

 Portabilidade
o O sistema operativo deve ser facilmente transportável para diferentes plataformas de
hardware.
o Deve suportar uma grande variedade de arquiteturas de hardware.
o Os microcontroladores usados em IoT variam de 8 a 32 bits.
o O sistema operativo deve ser capaz de aproveitar a arquitetura subjacente.
o O sistema operativo deve ser ajustável às necessidades específicas das aplicações e
fornecer uma abstração razoável dos detalhes de implementação de hardware.
 17

 Lista de verificação para escolher o sistema operativo para IoT

1. A aplicação precisa de desempenho em tempo real ou determinístico?
2. Quais são os recursos disponíveis (memória, capacidade de processamento, etc.)?
o Memória
o Unidade de gestão de memória (MMU)
o Capacidade de processamento
3. Quais são os requisitos de segurança?
4. Como o dispositivo é alimentado/powered?
5. Qual é o hardware escolhido?
6. Quais são os requisitos de comunicação e rede?
7. A interoperabilidade do sistema empresarial é necessária?

 Sistemas operativos para IoT ao longo do tempo

Sistemas Operativos Existentes

 Contiki
 RIOT
 TinyOS
 FreeRTOS (Amazon)
 LiteOS
 Mantis OS
 Nano-RK
 SOS
 NutOS
 uC / OS-III
 uClinux
 Mbed
 OpenTag
 ErikaEnterprise
 18

Tendências:

Sistemas operativos IoT mais populares

 19

Sistemas Operativos Existentes

 Contiki
o Um sistema operativo open source projetado especificamente para IoT.
Desenvolvido por uma equipa mundial de desenvolvedores com contribuições da
Atmel, Cisco, ETH, Redwire LLC, SAP, liderada por Adam Dunkels da
Thingsquare.
o Um sistema operativo com restrição de memória com foco específico em
dispositivos IoT wireless de baixa potência.
o Exemplos onde o Contiki é usado incluem sistemas de iluminação pública,
monitorização de som para cidades inteligentes, sistemas de monitorização de
radiação e sistemas de alarme.
o O Contiki fornece uma pilha/stack de rede IP completa, com protocolos IP padrão
como UDP, TCP e HTTP, além dos novos padrões de baixo consumo de energia
como 6LowPAN, RPL e CoAP.
Protothreads
Protothreads - uma nova abstração de programação
o Para sistemas embebidos com restrição de memória
o Um ponto de design entre eventos e threads
o Ideia muito simples, mas poderosa
Primitiva de programação: espera de bloqueio condicional
o PT_WAIT_UNTIL (condição)
o Fluxo sequencial de controlo: if e while
Protothreads são executados numa única pilha, como o modelo orientado a eventos
o Requisitos de memória (quase) iguais aos orientados a eventos

Princípio Protothread
 20

Um exemplo

A implementação baseada em eventos: uma máquina de estados

Implementação de máquina de estados orientada a eventos: confusão!

 21

Protothreads torna a implementação mais fácil

Protothreads - espera de bloqueio condicional:
PT_WAIT_UNTIL ()
Não há necessidade de uma máquina de estados explícita
Fluxo de código sequencial

A implementação baseada em protothreads é mais curta

 Código mais curto do que a versão orientada a eventos
 O código usa programação estruturada (declarações if e while)
 Mecanismo evidente do código

Contiki Protothreads em Processos

o PROCESS_BEGIN (); // Declara o início de um protothread do processo.
o PROCESS_END (); // Declara o fim do protothread de um processo.
o PROCESS_EXIT (); // Sai do processo.
o PROCESS_WAIT_EVENT (); // Aguarda qualquer evento.
o PROCESS_WAIT_EVENT_UNTIL (); // Aguarda um evento, mas com uma
condição.
o PROCESS_YIELD (); // Aguarda algum evento, equivalente a
PROCESS_WAIT_EVENT ().
 22

o PROCESS_WAIT_UNTIL (); // Aguarda uma determinada condição; pode não

resultar no processo.
o PROCESS_PAUSE (); // Rende temporariamente o processo.

 RIOT
o É um sistema operativo microkernel de open source para IoT. Foi inicialmente
desenvolvido pela Freie Universität Berlin (FU Berlin), Institut National de
Recherche en Informatique et en Automatique (INRIA), França e Hochschule für
Angewandte Wissenschaften Hamburgo (HAW Hamburgo)
o RIOT é um sistema operativo baseado numa arquitetura de microkernel.
o O kernel do RIOT é herdado principalmente do FireKernel, um kernel que foi
originalmente desenvolvido para redes de sensores.

Sistema operative RIOT

o Microkernel (para robustez)
o Estrutura modular para lidar com diversos requisitos
o Agendador Tickless
o Comportamento determinístico do kernel
o Tratamento de interrupções de baixa latência
o POSIX como API
o Porto nativo para teste e debug (gdb, valgrind, threadshark etc.)
o Executa o RIOT também no computador Linux
o Emula uma rede usando dispositivos de rede virtual

Estrutura RIOT
 23

RIOT: microkernel
• kernel minimalista

• Funções do kernel:
o Agendador/Scheduler
o IPC
o Mutexes
o Timer
• Módulos e drivers comunicam-se pelo IPC
• Tempo de execução determinístico de todas as funções do kernel
• Mudança de contexto otimizada
RIOT: Scheduler
• Tickless, ou seja, nenhum evento temporizador periódico
o Mais complexo de implementar, mas mais eficiente em termos de energia
• Run-to-complete, ou seja, o agendador não distribui igualmente para todos os threads
• Baseado em prioridades
o As prioridades devem ser escolhidas com cuidado para cumprir os requisitos de
tempo real
RIOT: Gestão da Memória
• Cada tópico tem a sua própria pilha/stack
• A pilha/stack também contém o TCB
• Não há proteção de memória => um overflow da pilha pode destruir outra pilha
 24

• TinyOS
o TinyOS é um sistema operativo baseado em componentes de software de código
aberto e gratuito e uma plataforma voltada para redes de sensores wireless (RSSFs).
o TinyOS começou como um projeto na UC Berkeley como parte do programa
DARPA NEST para a iniciativa Stardust - um sistema de muitos sistemas
microeletromecânicos minúsculos (MEMS), como sensores, robôs ou outros
dispositivos, que podem detetar, por exemplo, luz, temperatura, vibração,
magnetismo ou produtos químicos
o TinyOS é um sistema operativo embebido escrito na linguagem de programação
nesC como um conjunto de tarefas e processos cooperativos.
Um módulo orientado a eventos simples - BlinkM.nc

• FreeRTOS
o FreeRTOS é um kernel de sistema operativo em tempo real popular para dispositivos
embebidos, que foi portado para 35 microcontroladores. Desenvolvido em parceria
com as principais empresas de chips do mundo ao longo de um período de 15 anos.
o É distribuído sob a GPL com uma exceção opcional.
 25

o A exceção permite que o código proprietário dos utilizadores permaneça como

código-fonte fechado, enquanto mantém o próprio kernel como código-fonte aberto,
facilitando assim o uso do FreeRTOS em aplicações proprietárias.
o Agora Amazon FreeRTOS

Hello World in Contiki

Hello World in RIOT

Hello World in FreeRTOS

Hello World in TinyOS

 26

Aula 3 – Dispositivos Físicos e Controladores

Modelo de Referência IoT
 27

Camada 1: Dispositivos Físicos e Camada de Controladores

• A primeira camada do Modelo de Referência IoT é a camada de dispositivos físicos e
controladores. Esta camada engloba as “things” em Internet das Coisas, incluindo os
vários dispositivos de endpoint e sensores que enviam e recebem informações.
• O tamanho dessas “things” pode variar de sensores quase microscópicos a máquinas
gigantes numa fábrica. A sua função principal é gerar dados que podem ser consultados e
/ ou controlados numa rede.
A maioria das redes IoT começa a partir do objeto, ou “coisa”, que precisa ser conectada.
Do ponto de vista arquitetónico, a variedade de tipos, formas e necessidades de objetos
inteligentes impulsionam a variedade de protocolos e arquiteturas de IoT.
Existem diferentes formas de classificar objetos inteligentes. Uma classificação arquitetónica
pode ser:
• Alimentado por bateria ou conectado à energia
• Móvel ou estático
• Baixa ou alta frequência de relatórios
• Dados simples ou ricos/complexos
• Alcance de relatórios
• Densidade de objetos por célula

Alimentado por bateria ou conectado à energia:

• Esta classificação é baseada em se o objeto carrega o seu próprio suprimento de energia
ou recebe energia contínua de uma fonte de energia externa.
• Things alimentadas por bateria podem ser movidas mais facilmente do que objetos
alimentados por uma linha de fornecimento de energia.
• No entanto, as baterias limitam a vida útil e a quantidade de energia que o objeto pode
consumir, aumentando assim o alcance e a frequência de transmissão.
Móvel ou estático:
• Esta classificação é baseada em se a thing deve se mover ou ficar sempre no mesmo
local.
• Um sensor pode ser móvel porque é movido de um objeto para outro ou porque está
preso a um objeto em movimento (por exemplo, um sensor de localização ao mover
mercadorias em um depósito ou chão de fábrica).
• A frequência do movimento também pode variar, de ocasional a permanente.
• O alcance da mobilidade (de alguns centímetros a quilômetros de distância) geralmente
direciona a possível fonte de energia.
Frequência de relatórios/report (recolha de informação) baixa ou alta:
• Esta classificação é baseada na frequência com que o objeto deve relatar os parâmetros
monitorizados. Um sensor de ferrugem pode relatar valores uma vez por mês. Um sensor
de movimento pode relatar aceleração várias centenas de vezes por segundo.
 28

• Frequências mais altas geram maior consumo de energia, o que pode criar restrições na
possível fonte de energia (e, portanto, na mobilidade do objeto) e na faixa de
transmissão.
Dados simples ou complexos/ricos:
• Esta classificação é baseada na quantidade de dados trocados a cada ciclo do relatório.
• Um sensor de humidade num campo pode relatar um valor de índice diário simples
(numa escala binária de 0 a 255), enquanto um sensor de motor pode relatar centenas de
parâmetros, de temperatura a pressão, velocidade do gás, velocidade de compressão,
índice de carbono e muitos outros.
• Dados mais ricos normalmente geram maior consumo de energia.
• Esta classificação é frequentemente combinada com as anteriores para determinar a taxa
de transferência de dados do objeto (baixa taxa de transferência para alta taxa de
transferência). Assim, o rendimento é uma métrica combinada. Um objeto de rendimento
médio pode enviar dados simples numa frequência bastante alta (neste caso, a estrutura
de fluxo parece contínua) ou pode enviar dados ricos em frequência bastante baixa (neste
caso, a estrutura de fluxo parece em bursty).
Intervalo do relatório/Report Range (alcance da transmissão de informação):
• Esta classificação é baseada na distância em que o gateway está localizado.
• Por exemplo, para que a faixa de fitness se comunique com o telemóvel, precisa de estar
localizada a alguns metros de distância, no máximo. O pressuposto é que o telemóvel
precisa estar a uma distância visual para que seja possível consultar os dados relatados no
ecrã do telemóvel. Se o telemóvel estiver longe, normalmente não é usado, e não é
necessário relatar dados da banda para o mesmo.
• Por outro lado, um sensor de humidade no alcatrão de uma estrada pode precisar de
comunicar com o seu leitor a várias centenas de metros ou mesmo Km de distância.
Densidade do objeto por célula (relacionado com a eficiência do canal de comunicação):
• Esta classificação é baseada no número de objetos inteligentes (com necessidade
semelhante de comunicação) numa determinada área, conectados ao mesmo gateway.
• Um oleoduto pode utilizar um único sensor em locais-chave a cada poucas milhas. Em
contraste, telescópios como o telescópio SETI Colossus no Observatório Whipple
implantam centenas, e às vezes milhares, de espelhos em uma pequena área, cada um
com vários giroscópios, gravidade e sensores de vibração
Do ponto de vista da arquitetura de rede, a tarefa inicial é determinar qual tecnologia deve ser
usada para permitir que objetos inteligentes se comuniquem. Esta determinação depende da
forma como as “coisas” são classificadas.
No entanto, alguns setores (como manufatura e serviços públicos) podem incluir objetos em
várias categorias, atendendo a diferentes necessidades.
 29

As categorias usadas para classificar coisas podem influenciar outros parâmetros e também
podem influenciar umas às outras.
É improvável que um objeto inteligente pequeno e altamente móvel exija uma antena grande
e uma fonte de energia poderosa. Esta restrição limitará o alcance da transmissão e, portanto,
o tipo de protocolo de rede disponível para as suas conexões.
A criticidade dos dados também pode influenciar o fator de forma e, portanto, a arquitetura.

Um sensor é um conversor de energia

Essa conversão pode ser direta ou pode exigir transdutores.

Exemplo: Um sensor químico pode ter uma parte que converte a energia de uma reação
química em calor (transdutor) e outra parte, uma termopilha, que converte o calor num sinal
elétrico.
Transdutor
• Dispositivo que converte uma forma primária de energia num sinal correspondente com
uma forma de energia diferente.
Formas de energia primária: mecânica, térmica, eletromagnética, ótica, química, etc.
• Assumir a forma de um sensor ou atuador.
Sensor (por exemplo, termómetro)
 30

• Converte um parâmetro físico numa saída elétrica (um tipo de transdutor, por exemplo,
um microfone)
Atuador (por exemplo, aquecedor)
• Converte um sinal elétrico numa saída física (oposto a um sensor, por exemplo, um
altifalante)
• Dispositivo que gera um sinal ou estímulo

Sistemas de Sensor
Normalmente interessado em sensor eletrónico
• Converter o parâmetro desejado num sinal mensurável eletricamente
Sensor Eletrónico Geral
• Transdutor primário: converte o parâmetro do "mundo real" num sinal elétrico.
• Transdutor secundário: converte o sinal elétrico em valores analógicos ou digitais.

Exemplo de sensor

Função de transferência

Função de transferência – Exemplo

 31

Quais são as grandezas que podem ser medidas?

• Movimento, posição, deslocamento
• Velocidade e aceleração
• Força, tensão
• Pressão
• Fluxo
• Som
• Humidade
• Luz
• Radiação
• Temperatura
• Presença química
Classificação do Sensor
• Passiva
o Não precisa de nenhuma fonte de energia adicional
o Gerar diretamente um sinal elétrico em resposta a um estímulo externo
o Por exemplo. Termopar, foto díodo, sensor piezoelétrico
• Ativo
o Requer energia externa chamada de sinal de excitação
o Sensor modifica o sinal de excitação para fornecer saída
o Por exemplo. termístor, medidor de tensão resistiva

Caraterísticas do Sensor
• Entrada de amplitude ou escala completa/ Span or Full-scale input
o Uma faixa dinâmica de estímulos que podem ser convertidos por um sensor
o Representa o maior valor de entrada possível (margem/gama dinâmica) que pode ser
aplicado ao sensor sem causar uma imprecisão inaceitavelmente grande
o g para acelerómetro
• Saída em escala real/ Full-scale output
o Diferença algébrica entre os sinais de saída elétrica medidos com o estímulo de
entrada máximo e o estímulo de entrada mais baixo aplicado
o Por exemplo. LM35
 32

Accuracy/Precisão
• A precisão é medida como o maior desvio de um valor representado pelo sensor em
relação ao valor ideal ou verdadeiro na sua entrada
• Os limites de precisão geralmente são usados na análise do pior caso para determinar o
pior desempenho possível do sistema
• A classificação de imprecisão pode ser representada de várias formas:
o Diretamente em termos de valor medido
o Em percentagem da amplitude de entrada (escala completa)
o Em termos de sinal de saída

Calibração
 Determinação de variáveis específicas que descrevem a função de transferência geral
o Meios gerais de todo o circuito, incluindo o sensor, o circuito de interface e o
conversor A/D
 Exemplo: uso de díodo polarizado direto para medição de temperatura:
o Função de transferência v = a + bt
o Faça a medição em dois T's e resolva e determine a e b: V1 = a + bt1 e V2 = a + bt2
 Para a função não linear, mais de um ponto pode ser necessário, dependendo da função
de transferência
 Outra maneira é usar uma aproximação por partes
Erro de calibração:
 Imprecisão permitida por um fabricante quando um sensor é calibrado na fábrica
 O erro é de natureza sistemática
 33

Histerese:
Desvio da saída do sensor num ponto especificado do sinal de entrada quando ele se
aproxima das direções opostas

Erro de não linearidade:

Especificado para sensores cuja função de transferência pode ser aproximada por uma linha
reta

Repetibilidade:
 Causado pela incapacidade de um sensor de representar o mesmo valor em condições
idênticas
 34

 É expresso como a diferença máxima entre as leituras de saída, conforme determinado

por dois ciclos de calibração
 Geralmente é representado como % da escala total (FS)
Resolução:
 Os menores incrementos de estímulo que podem ser sentidos
Impedância de saída:
 A impedância de saída Zout é importante saber, para melhor fazer a interface de um
sensor com o circuito eletrónico
 Para um sensor que gera corrente, deve ter uma impedância de saída tão alta quanto
possível e a impedância de entrada do circuito deve ser baixa
 Para a conexão de tensão, é preferível um sensor com Zout menor e o circuito deve ter
Zin o mais alto possível
Selecionar um transdutor
 Qual é a quantidade física a ser medida?
 Qual princípio do transdutor pode ser melhor usado para medir essa quantidade?
 Que precisão é necessária para esta medição?
o Parâmetros fundamentais do transdutor
o Condições físicas
o Condições ambientais
o Compatibilidade do equipamento associado
 Reduzindo o erro total de medição:
o Usando a calibração do sistema no local com correções realizadas na redução de
dados
o Controlar artificialmente o ambiente para minimizar possíveis erros
35
 36

Conectando Sensores / Atuadores a um MCU

As informações detetadas podem estar disponíveis de duas maneiras diferentes:
 Informação Analógica (mais comum)
 Informação digital (a um custo de um aumento na complexidade do sensor/consumo de
energia)
Sensores/atuadores podem ser conectados ao MCU usando diferentes abordagens:
 GPIO: Saída de entrada digital de uso geral
 PWM: modulação de largura de pulso
 ADC / DAC: Analógico – Conversão digital
GPIO
Saída de entrada digital de uso geral
 Input/Output
 Analógico/Digital

Dispositivos de Hardware na Conversão Analógico-Digital

 37

Interface digital com o MCU: Paralela vs. Série

Paralelo Série
Transmite vários dígitos binários (bits) Transmite apenas um bit de cada vez
simultaneamente
Muitos fios / traços (número de condutores Menos fios / traços; A comunicação é
elétricos); Normalmente 1 fio / bit baseada nas bordas ascendentes e
descendentes de uma onda quadrada
Exemplos: ISA, ATA, SCSI, PCI Exemplos: UART, I2C, SPI

Comunicação em Paralelo
 Requer mais traços e, portanto, mais espaço no PCB
 Pode ser mais rápido do que a comunicação em série
 A taxa de transferência de dados pode ser aumentada aumentando o número de conexões
 Usado em parte para parte de comunicação em computadores RAM <-> CPU <-> GPU
Exemplo de LCD paralelo (barramento de dados de 4 bits)

Motivações da interface do bus em série

 Sem usar muitas linhas de I / O
o As linhas de I / O requerem blocos de I / O que custam dinheiro e tamanho
o As linhas de I / O requerem área de PCB, o que custa dinheiro e tamanho
 Conecta sistemas diferentes na mesma interface
o Dois sistemas embebidos
o Um desktop e um sistema embebido
 Conecta diferentes chips no mesmo sistema embebido
o MCU para periférico
o MCU para MCU
 Frequentemente com taxas de dados relativamente baixas
o Mas, às vezes com taxas de dados mais altas
 38

Espaço de design de bus em série

 Número de fios necessários?
 Assíncrono ou síncrono?
 Quão rápido pode transferir dados?
 Suporta mais de dois terminais?
 Suporta mais de um master (ou seja, iniciador txn)?
 Como oferece suporte ao controlo de fluxo?
 Como lida com erros/ruído?
 Quão longe os sinais podem viajar?

UART aplica-se em:

 A porta em série do PC é um UART!
 Serializa os dados a serem enviados por cabo em série
 Desserializa os dados recebidos

Costumava ser usado para acesso à Internet:

 39

UART
 Recetor/transmissor assíncrono universal
 Hardware que traduz entre formas em paralelo e em série
 Normalmente usado em conjunto com padrões de comunicação como EIA, RS-232, RS-
422 ou RS-485

Protocolo
Cada caracter é enviado como
 um bit de início baixo lógico
 um número configurável de bits de dados (geralmente 7 ou 8, às vezes 5)
 um bit de paridade opcional
 um ou mais bits de alto stop lógico
 com um determinado tempo de bit ("baud")
 40

O recetor também verifica se o bit de stop é ‘1’. Caso contrário, reporta “erro de
enquadramento” ao sistema host
 41

O novo bit de início pode aparecer imediatamente após o bit de stop. O recetor irá sincronizar
novamente em cada bit de início
Diagrama de bloco do transmissor

Circuito Inter-integrado (I2C)

Desenvolvido e patenteado pela Philips para conectar periféricos de baixa velocidade a uma
motherboard, sistema embebido ou telemóvel
Multi-master, bus de dois fios, até 100 kbits / s
Uma linha de dados (SDA)
Uma linha de relógio (SCL)
Master controla o relógio para slaves
Cada slave conectado tem um endereço único de 7 bits
I2C
 Inventado pela Philips como interconexão chip-chip para aparelhos de TV
 2 linhas de sinal, Vcc e Gnd
 SDA (dados em série) e SCL (relógio em série)
 Ambos bidirecionais (ativamente puxados para baixo)
 Endereço slave de 7 bits
 Dados em bytes de 8 bits - 100 kbps - 2,4 Mbps
 42

Protocolo
 As transferências são orientadas por bytes, MSB primeiro
 Início: SDA vai baixo enquanto SCL está alto
 O master envia o endereço do slave (7 bits) nos próximos 7 relógios
 Master envia bit de solicitação de leitura / escrita
0 - escrita para slave
1 - leitura do slave
 Slave ACKs puxando SDA para baixo no próximo relógio
 As transferências de dados agora começam

Terminologia
 Transmiter - O dispositivo que envia dados para o bus
 Receiver - Dispositivo que recebe dados do bus
 43

 Master - dispositivo que inicia uma transferência, gera um relógio e encerra uma
transferência
 Slave - Dispositivo endereçado pelo master
 Multi-master - mais de um master pode tentar controlar o bus
 Arbitration - procedimento para garantir que apenas um master tenha controlo do bus a
qualquer momento
 Sincronização - procedimento para sincronizar os relógios de dois ou mais dispositivos
Transferência de dados master to slave
 O relógio é controlado pelo master
 Os dados são gravados no slave nos próximos 8 pulsos de clock
 O recebimento de dados é reconhecido pelo slave no 9º pulso puxando SDA para baixo
 Quando o escravo é libertado, o SDA master pode enviar o próximo byte
 O master acabará por definir uma condição de Stop, fazendo uma transição de baixo para
alto no SDA com SCL alto

Master Write/Read To/From Slave

 44

Extensões I2C
 Endereçamento de 10 bits (até 1024 endereços)
 Modo rápido - até 400 kbits / s
 Alta velocidade - até 3,4 Mbits / s
Serial Peripheral Interconnect (SPI)
 Outro tipo de protocolo serial em sistemas embebidos (proposto pela Motorola)
 Protocolo de quatro fios
o SCLK - Relógio em série
o MOSI / SIMO - Saída Master, Entrada Slave
o MISO / SOMI - Entrada Master, Saída Slave
o SS - Slave Select
 Dispositivo master único e com um ou mais dispositivos slave
 Maior rendimento do que I2C e pode fazer "transferências de fluxo"
 Sem necessidade de arbitragem
 Mas:
o Requer mais pinos
o Não tem controlo de fluxo de hardware
 Protocolo Serial Bus
 Rápido, fácil de usar, simples
 Todos apoiam
Nenhum reconhecimento de slave (o mmaster pode estar a comunicar com o ar e nem mesmo
saber disso)
 45

SPI Basics
 Um protocolo de comunicação usando 4 fios, também conhecido como barramento de 4
fios
 Usado para se comunicar em pequenas distâncias
 Multiple Slaves, Single Master
 Sincronizado
 Sempre Full Duplex
o Comunicação em duas direções ao mesmo tempo
o A transmissão não precisa ser significativa
 Velocidade de transmissão de vários Mbps
 Transfere dados em caracteres de 4 a 16 bits
 Múltiplos slaves
o Possibilidade de encadeamento
Protocolo SPI
 Fios:
o Master Out Slave In (MOSI)
o Master In Slave Out (MISO)
o Relógio do sistema (SCLK)
o Slave Select 1… N
 Master Set Slave Select baixo
 Mestre gera relógio
 Os registos de deslocamento mudam para dentro e para fora dos dados
 46

Comunicação SPI
 MOSI - Carrega dados do Master para o Slave
 MISO - carrega dados do Slave para o Master
o Ambos os sinais acontecem para cada transmissão
 SS_BAR - Linha única para selecionar um slave
 SCLK - relógio produzido pelo master para sincronizar a transferência de dados

Prós e contras do SPI

Prós:
 Rápido e fácil
o Rápido para conexões ponto a ponto
o Permite facilmente streaming / fluxo de dados constante
o Sem endereçamento / Simples de implementar
 Todos apoiam
Contras:
 SS torna vários slaves muito complicados
 Sem capacidade de reconhecimento
 Sem arbitragem inerente
 Sem controlo de fluxo

Aula 4 – Dispositivos físicos e controladores (MCU)

 47

Introdução aos microcontroladores (MCU)

Um microcontrolador (MCU) é um pequeno computador em um único circuito integrado que
consiste numa unidade de processamento central (CPU) relativamente simples combinada
com dispositivos periféricos, como memórias, dispositivos de I/O e temporizadores.
Segundo alguns relatos, mais da metade de todas as CPUs vendidas em todo o mundo são
microcontroladores.

Microcontrolador VS Microprocessador
Um microcontrolador é um pequeno computador num único circuito integrado que contém
um núcleo de processador, memória e periféricos de entrada/saída programáveis.
Um microprocessador incorpora as funções da unidade de processamento central (CPU) de
um computador num único circuito integrado.
 48

Tipos de Processadores
Na computação de uso geral, a variedade de arquiteturas de conjunto de instruções hoje é
limitada, com a arquitetura Intel x86 dominando todas de forma esmagadora.
Não existe tal domínio na computação embebida. Ao contrário, a variedade de processadores
pode ser assustadora para um designer de sistemas.
Coisas que importam: periféricos, simultaneidade e tempo, taxas de clock, capacidade de
memória (SRAM e flash), tamanhos de pacotes.
Caraterísticas Comuns de Sistemas Embebidos
 Single-functioned
o Executa um único programa, repetidamente
 Estritamente restrito/Tightly-constrained
o Baixo custo, baixo consumo de energia, pequeno, rápido, etc.
 Reativo e em tempo real/Reactive and real-time
o Reage continuamente às mudanças no ambiente do sistema
o Deve calcular certos resultados em tempo real sem demora

Tipos de microcontroladores
 49

RISC VS CISC
Existem duas arquiteturas de conjunto de instruções principais:
RISC (Reduced Instruction Set Computer)
CISC (Complex Instruction Set Computer)
Até 1980, a tendência era construir CPUs cada vez mais complexas com um conjunto
complexo de instruções como (CISC)
Conceito RISC: Instrução executada em ciclo único → “Arquitetura que reduz a
complexidade do chip por instruções de processamento mais simples”.
CPUs de arquitetura RISC capazes de executar apenas um conjunto muito limitado (simples)
de instruções.
Abordagem CISC
Conclui a tarefa em poucos códigos de linha em assembly
Exemplo: TASK multiplicar os números das localizações 2:3, 5:2 e colocar a saída na
localização 5:2
Command: MULT 2:3, 5:2
MULT é o que é conhecido como uma "instrução complexa".
A instrução não é concluída na execução de um ciclo.
Hardware do processador que é capaz de compreender e executar uma série de operações.

Abordagem RISC
 50

Os processadores RISC usam apenas instruções simples que podem ser executadas num ciclo
de relógio.
Comando "MULT" dividido em três comandos separados:
 LOAD A, 2:3
 LOAD B, 5:2
 PROD A, B
 STORE 2:3, A
Execução de cada instrução num Ciclo Único

RISC
Vantagens dos computadores com conjunto de instruções reduzidas
 Execução rápida de instruções devido a instruções simples para CPU.
 Os chips RISC requerem menos transístores, o que os torna mais baratos para projetar e
produzir.
 Ênfase no software
 Single-clock, instrução reduzida apenas
 Registo para registo: “LOAD” e “STORE“ são instruções independentes
 Gasta mais transístores em registos de memória
Arquitetura Interna MCU
Todos os MCs usam um dos dois modelos básicos de design: Harvard Architecture e von-
Neumann Architecture.
Eles representam duas maneiras diferentes de trocar dados entre a CPU e a memória.
 51

Tipos de memória
Tipos de memória primária:
a. RAM (Randomly Access Memory) – Memória de escrita/leitura, rápida mas não
persistente
i. SRAM
ii. DRAM
b. ROM (Read Only Memory) – Memória apenas de leitura
i. PROM
ii. EPROM
c. Híbrido
i. EEPROM
ii. NVRAM
iii. Memória flash
Memória primária
O armazenamento primário (ou memória principal ou memória interna), muitas vezes
referido simplesmente como memória, é o único armazenamento diretamente acessível para a
CPU. A CPU lê continuamente as instruções armazenadas e executa-as conforme necessário.
A memória principal está direta ou indiretamente conectada à CPU através de um bus de
memória. Na verdade, são dois buses: um bus de endereço e um bus de dados. A CPU
 52

primeiro envia um número através de um bus de endereço, um número chamado endereço de

memória, que indica a localização desejada dos dados. Em seguida, lê ou escreve os próprios
dados usando o bus de dados.
Está dividido em RAM e ROM.
RAM
A família de RAM inclui dois dispositivos de memória importantes: RAM estática (SRAM) e
RAM dinâmica (DRAM). A principal diferença entre eles é o tempo de vida dos dados que
armazenam.
SRAM retém o seu conteúdo enquanto a energia elétrica for aplicada ao chip. Se a
alimentação for desligada ou perdida temporariamente, seu conteúdo será perdido para
sempre.
A DRAM, por outro lado, tem uma vida útil de dados extremamente curta - normalmente
cerca de quatro milissegundos. Isso é verdade mesmo quando a alimentação é aplicada
constantemente. Um controlador DRAM é usado para atualizar os dados antes que eles
expirem, o conteúdo da memória pode ser mantido vivo pelo tempo que for necessário.
Afinal, a DRAM é tão útil quanto a SRAM.

Tipos de RAM
Double Data Rate (DDR) synchronous dynamic random access memory ou também
conhecida como DDR1 SDRAM é uma classe de memória usada em computadores.
A interface usa double pumping (transferência de dados nas bordas ascendente e descendente
do sinal do clock) para diminuir a frequência do clock.
Uma vantagem de manter a frequência do clock baixa é que isso reduz os requisitos de
integridade do sinal na placa de circuito que conecta a memória ao controlador.

DDR2, DDR e SDRAM

A memória DDR2 é fundamentalmente semelhante à DDR SDRAM. Ainda assim, enquanto
DDR SDRAM pode transferir dados através do bus duas vezes por clock, DDR2 SDRAM
pode realizar quatro transferências por clock. DDR2 usa as mesmas células de memória, mas
duplica a largura de banda usando a técnica de multiplexing.
 53

A célula de memória DDR2 ainda tem o clock na mesma frequência que as células DDR
SDRAM e SDRAM, mas a frequência dos buffers de entrada/saída é maior com DDR2
SDRAM.
O bus que conecta as células de memória aos buffers é duas vezes mais largo em comparação
com o DDR. Assim, os buffers de I/O realizam multiplexing: os dados estão a vir das células
de memória ao longo de um bus largo e estão saindo dos buffers num bus da mesma largura
que no DDR SDRAM, mas com uma frequência duas vezes maior. Isso permite aumentar a
largura de banda da memória sem aumentar a frequência operacional.
Tipos de ROM
As memórias na família ROM são diferenciadas pelos métodos usados para escrever novos
dados nelas (geralmente chamados de programming) e pelo número de vezes que podem ser
reescritas.
Esta classificação reflete a evolução dos dispositivos ROM de hardwired para programáveis
ou para apagáveis e programáveis.
Uma característica comum é a capacidade de reter dados e programas para sempre, mesmo
durante uma queda de energia.
O conteúdo da ROM tinha que ser especificado antes da produção do chip, de forma que os
dados reais pudessem ser usados para organizar os transístores dentro do chip.
PROM
Um passo à frente da ROM mascarada é a PROM (ROM programável), que é adquirida num
estado não programado. Os dados de uma PROM não programado são compostos
inteiramente de 1's.
O processo de escrita dos dados na PROM envolve um equipamento especial denominado
programador de dispositivo. O programador do dispositivo escreve dados no dispositivo, uma
palavra de cada vez, aplicando uma carga elétrica aos pinos de entrada do chip.
Uma vez que uma PROM tenha sido programada desta forma, o seu conteúdo nunca poderá
ser alterado. Caso seja necessário alterar o código ou os dados armazenados na PROM, o
dispositivo atual deve ser descartado. Como resultado, as PROMs também são conhecidas
como dispositivos programáveis de uma só vez (OTP).
EPROM
Uma EPROM (ROM apagável e programável) é programada exatamente da mesma maneira
que uma PROM.
No entanto, as EPROMs podem ser apagadas e reprogramadas repetidamente. Para apagar
uma EPROM, é necessário expor o dispositivo a uma forte fonte de luz ultravioleta. (Uma
janela na parte superior do dispositivo permite que a luz alcance o silício.) Ao fazer isso,
redefine-se o chip inteiro para seu estado inicial não programado.
Embora mais caro do que os PROMs, a sua capacidade de ser reprogramado torna os
EPROMs uma parte essencial do processo de desenvolvimento e teste de software.
 54

Tipos de memória híbrida

À medida que a tecnologia de memória amadureceu nos últimos anos, a linha entre RAM e
ROM ficou turva.
Agora, vários tipos de memória combinam recursos de ambos. Esses dispositivos não
pertencem a nenhum dos grupos e podem ser chamados coletivamente de dispositivos de
memória híbrida.
As memórias híbridas podem ser lidas e escritas conforme desejado, como a RAM, mas
mantêm o seu conteúdo sem energia elétrica, assim como a ROM.
Dois dos dispositivos híbridos, EEPROM e flash, são descendentes dos dispositivos ROM.
Normalmente, estes são usados para armazenar código.
O terceiro híbrido, NVRAM, é uma versão modificada de SRAM. NVRAM geralmente
contém dados persistentes.
EEPROMS
EEPROMS são eletricamente apagáveis e programáveis.
Internamente, eles são semelhantes às EPROMs, mas a operação de apagar é realizada
eletricamente, em vez de por exposição à luz ultravioleta.
Qualquer byte numa EEPROM pode ser apagado e reescrito. Uma vez escritos, os novos
dados permanecerão no dispositivo para sempre – ou pelo menos até que sejam apagados
eletricamente.
A principal compensação para esta funcionalidade aprimorada é o custo mais alto, embora os
ciclos de escrita também sejam significativamente mais longos do que escritas numa RAM.
Portanto, a EEPROM não é adequada para se utilizar como memória do sistema principal.
Memória flash
A memória Flash combina os melhores recursos dos dispositivos de memória descritos até
agora. Os dispositivos de memória flash são de alta densidade, baixo custo, não voláteis,
rápidos (para ler, mas não para escrever) e eletricamente reprogramáveis.
Estas vantagens são avassaladoras e, como resultado direto, o uso de memória flash
aumentou drasticamente em sistemas embebidos. Do ponto de vista do software, as
tecnologias flash e EEPROM são muito semelhantes.
A principal diferença é que os dispositivos flash só podem ser apagados um setor de cada
vez, não byte-byte. Os tamanhos de setor típicos estão na faixa de 256 bytes a 16 KB. Apesar
desta desvantagem, o flash é muito mais popular do que o EEPROM e também tem vindo a
substituir rapidamente muitos dos dispositivos ROM.
Memória Flash é mais lenta a ler do que a escrever.

Memória NVRAM
O terceiro membro da classe de memória híbrida é NVRAM (RAM não volátil).
 55

A não-volatilidade também é uma caraterística da ROM e das memórias híbridas discutidas

anteriormente.
No entanto, uma NVRAM é fisicamente muito diferente desses dispositivos. Normalmente,
uma NVRAM é apenas uma SRAM com bateria de reserva.
Quando a energia é ligada, a NVRAM opera como qualquer outra SRAM. Quando a energia
é desligada, a NVRAM consome apenas energia suficiente da bateria para reter os seus
dados.
NVRAM é bastante comum em sistemas embebidos. No entanto, é caro. Ainda mais caro do
que SRAM, por causa da bateria. Portanto, as duas aplicações são normalmente limitadas ao
armazenamento de algumas centenas de bytes de informações críticas do sistema que não
podem ser armazenadas de maneira melhor.
Como escolher um MCU para um projeto?
Quais métricas são necessárias considerar?
 Consumo de energia: Não podemos pagar um MCU de mA se o orçamento de energia
do sistema for 3,47 mA.
 Frequência de relógio: kHz é muito lento…; 100 MHz é demais ...
 Pinos IO: muitos periféricos - sensores de imagem, depurador UART, cartão SD,
DAC, ADC, microfone, LED
 Memória: precisamos ter memória suficiente para armazenar os dados do sensor
 Funções internas: Migração de dados do sensor para o gateway via rádio, por exemplo
Real-time Means Reactive
Um sistema de computador em tempo real deve reagir aos estímulos de seu ambiente.
O instante em que um resultado deve ser produzido é denominado prazo/deadline.
Se um resultado tem utilidade mesmo depois de expirado o prazo, o prazo é classificado
como soft, caso contrário, é firm.
Se consequências graves puderem ocorrer se um prazo firme for perdido, o prazo é
considerado hard.
Exemplo: considere um semáforo numa estrada antes de um cruzamento ferroviário. Se o
sinal de trânsito não mudar para vermelho antes da chegada do trem, pode ocorrer um
acidente.
Sistemas RT à prova de falhas com prazos rígidos/ Fail-Safe Hard-deadline RT Systems
Se um estado seguro puder ser identificado e alcançado rapidamente após a ocorrência de
uma falha, chamamos o sistema à prova de falhas/fail-safe.
A proteção contra falhas é uma caraterística do objeto controlado, não do sistema do
computador.
Caso seja detetada uma falha num sistema de sinalização ferroviária, é possível definir todos
os sinais para vermelho e, assim, parar todos os comboios com a finalidade de colocar o
sistema num estado seguro.
 56

Em aplicações à prova de falhas, o sistema do computador deve ter uma alta cobertura de
deteção de erros.
Frequentemente, um watchdog é necessário para monitorizar a operação do sistema do
computador e colocá-lo no estado seguro.
Watchdog Timers
Embora não seja possível lidar com todas as anomalias de hardware e software, o
desenvolvedor pode empregar o uso de temporizadores de vigilância para ajudar a mitigar os
riscos.
Um cronómetro de watchdog é um dispositivo de cronometragem de hardware que dispara
um reset do sistema, ou operação semelhante, após um determinado período de tempo
decorrido.
Um cronómetro de watchdog pode ser um componente de hardware independente ou
embutido no próprio processador.
Para evitar uma redefinição, uma aplicação deve redefinir periodicamente o cronómetro do
watchdog antes que esse intervalo expire. Isso também é conhecido como “kicking the dog”.
Watchdogs externos
Os temporizadores de watchdog externos são circuitos integrados que ativam fisicamente o
pino de reset do processador.
O processador deve declarar um pino de saída de alguma forma para redefinir o mecanismo
de temporização do watchdog.
Este tipo de watchdog é geralmente considerado o mais apropriado devido à total
independência do watchdog do processador.
Alguns watchdogs externos apresentam um reset em “windowed”.
Impõe restrições de tempo para uma redefinição adequada do watchdog.
Minimiza a probabilidade de software incorreto redefinir o watchdog.
Watchdogs - Mars Pathfinder
Em julho de 1997, uma inversão de prioridade ocorreu na missão Mars Pathfinder, depois da
nave aterrar na superfície marciana.
Uma tarefa de comunicação de alta prioridade foi forçada a aguardar um mutex mantido por
uma tarefa “científica” de prioridade mais baixa.
O tempo do software foi comprometido, e um reset do sistema emitida pelo seu cronómetro
de watchdog trouxe o sistema de volta às condições normais de operação.
Na Terra, os cientistas conseguiram identificar o problema e enviar um novo código para
corrigi-lo.
Assim, o restante da missão de $ 265 milhões de dólares poderia ser concluído com sucesso.
 57

Watchdogs - Conclusão
Os cronómetros de watchdog podem adicionar uma grande confiabilidade aos sistemas
embebidos, se usados corretamente.
Para fazer isso, é necessária uma boa abordagem geral. Reiniciar o cronómetro do watchdog
deve fazer parte do projeto geral.
Verificar a integridade de operação do sistema e usar isso como um critério para reiniciar o
cronómetro de watchdog.
Além de validar se o software “faz a coisa certa”, verificar se o faz no tempo esperado.
Supor que o software apresentará um mau funcionamento de hardware ou falha de software.
Adicionar informações de debugging suficientes para ajudar na situação de debug.
Input/Output
Registos de dispositivos mapeados em “portas”; um espaço de endereço separado

Usa instruções especiais de I/O para ler/escrever portas

Protegido ao tornar as instruções de I/O disponíveis apenas no modo kernel/supervisor
Usado, por exemplo, pela arquitetura Intel x86 e sucessores

IO mapeada de memória/ Memory Mapped IO

Registos de dispositivos mapeados em espaço de endereço regular

Usa instruções regulares de load/store (atribuição) para read/write registos

 58

Usa o mecanismo de proteção de memória para proteger os registos do dispositivo

Porquê MMIO para sistemas embebidos?
Portas I/O:
As instruções especiais de I/O dependem da CPU
Memory mapped I/O (MMIO):
O mecanismo de proteção de memória permite maior flexibilidade do que as
instruções protegidas
Pode usar todas as instruções de referência de memória para I/O
Ler e escrever com MMIO não é como falar com RAM
MMIO lê e escreve registos
Leituras e escritas em registos podem fazer com que os periféricos executem uma função
Ao ler dados, pode fazer com que o hardware faça algo
Por exemplo, apaga os sinalizadores de interrupção, obtém o próximo BYTE no
UART
Ao escrever dados, pode fazer com que o hardware faça algo com eles
Por exemplo, envia esses dados pelo bus UART
General Purpose Input/Output (GPIO)
General Purpose Input / Output (GPIO) é um pino genérico em um chip cujo comportamento
(incluindo se é um pino de entrada ou saída) pode ser controlado (programado) pelo
utilizador em tempo de execução.

Mecanismo de interrupção
 Responde a eventos raros, mas importantes
o Condições de alarme, como bateria fraca
o Condições de erro
 Sincronização de I/O
o Dispara interrupção quando o sinal numa porta muda
 59

 Interrupções periódicas
o Gerado pelo cronómetro numa taxa regular
o O temporizador Systick pode gerar interrupção quando chega a zero
o Valor de reload + frequência determinam taxa de interrupção
Uma interrupção:
o Transferência automática de software
o Em resposta a um evento de hardware
Exemplos
o Periodicamente: saída para DAC fazendo som
o Nova entrada: recebe novos dados
o A saída está idle: envia mais dados

Mecanismo de interrupção - Mudança de contexto

Mecanismo de interrupção - Vetores de interrupção

 60

Zolertia Zoule - Texas Instruments CC2538

 61

ARM
 Fundado em novembro de 1990:
o Extraído de computadores Acorn
 Projeta a gama ARM de núcleos de processador RISC
 Licencia projetos de núcleo ARM para parceiros de semicondutores que fabricam e
vendem para seus clientes.
o ARM não fabrica silício ela mesma
 Também desenvolver tecnologias para auxiliar no design da arquitetura ARM
o Ferramentas de software, placas, hardware de debug, software de aplicação,
arquiteturas de bus, periféricos, etc.
 62

Arquitetura do conjunto de instruções ARM Cortex M3 (ISA)

 O ISA é um “contrato” entre arquitetos e programadores e define:
 Conjunto de registo
 Conjunto de instruções
o Modos de endereçamento
o Tamanho da word
o Formatos de dados
o Modos de operação
o Códigos de condição
o Convenções de calling
o Realmente não faz parte do ISA (geralmente)
o Em vez disso, parte da Interface Binária da Aplicação (ABI)
o Mas o ISA geralmente fornece suporte significativo.
ARM Cortex M3 Word Size
 Talvez a caraterística mais marcante de uma arquitetura
o IA-32 (arquitetura Intel, 32 bits)
 O tamanho da word é o que nos referimos quando dizemos:
o Máquina, microcontrolador, microprocessador ou computador de 8 bits, 16 bits, 32
bits ou 64 bits
 Determina o tamanho da memória endereçável
o Uma máquina de 32 bits pode endereçar 2 ^ 32 bytes
o 2 ^ 32 bytes = 4.294.967.296 bytes = 4GB
o Nota: só porque é possível resolver isso, não significa que realmente haja algo lá!
 Em sistemas embebidos, tensão entre 8/16/32 bits
o Densidade / tamanho / expressividade do código
o Desempenho da CPU / memória endereçável

ARM ISA: Conjunto de instruções Thumb2

 63

 Instruções de comprimento variável

o As instruções ARM têm um comprimento fixo de 32 bits
o As instruções Thumb têm um comprimento fixo de 16 bits
o As instruções Thumb-2 podem ser de 16 bits ou 32 bits
 Thumb-2 oferece aproximadamente 26% de melhoria na densidade do código em relação
ao ARM
 Thumb-2 dá aproximadamente 25% de melhora no desempenho em relação ao Thumb
 64

Addressing: Big Endian vs Little Endian

Endian-ness: ordenação de bytes dentro de uma word
 Little - Aumento da significância numérica com o aumento dos endereços de memória
 Biog - O oposto, o byte mais significativo primeiro
 MIPS é big endian, x86 é little endian

Formatos de memória ARM Cortex-M3 (Endian)

 65

Formato de memória padrão para CPUs ARM: LITTLE ENDIAN

Bytes 0-3 contêm a primeira word armazenada
Bytes 4-7 contêm a segunda word armazenada
O processador contém um pino de configuração BIGEND
 Permite que o desenvolvedor do sistema de hardware selecione o formato:
o Little endian
o Big Endian (BE-8)
 Pin é amostrado no reset
 Não é possível alterar o endianness quando fora de redefinição
Ferramentas ARM Cortex M3
Como um programa em linguagem assembly se transforma numa imagem de programa
executável?

Quais são os verdadeiros nomes de executáveis GNU para o ARM?

66
 67

Application Binary Interface/Interface Binária do Aplicativo (ABI)

 A ABI estabelece as responsabilidades do caller/callee (recetor)
o Quem salva quais registos
o Como os parâmetros da função são passados
o Como os valores de retorno são passados de volta
 O ABI é um contrato com o compilador
o Todo o código C assembled seguirá este padrão
 É necessário segui-lo se quiser que C e Assembly funcionem juntos corretamente
 E se escrever tudo em Assembly?
o Talvez menos importante. A menos que se vá estender o código para que outros
possam usá-lo

Regras Básicas ABI

 Uma sub-rotina deve preservar o conteúdo dos registos r4-11 e SP
o Estes são os registos salvos do callee
o Vamos ter cuidado com r9
 Os argumentos são passados de r0 a r3
o Estes são os registos salvos do caller
o Se precisarmos de mais argumentos, colocamos um ponteiro na memória num dos
registos
 O valor de retorno é colocado em r0
o r0 e r1 se 64 bits
 Aloca-se espaço na pilha conforme necessário. Usa-se conforme necessário. Coloca-se
de volta quando terminar ...
o Manter as words alinhadas

Aulas 5 e 6 – Fundamentos de comunicação para IoT

 68

Access Networks/Redes de acesso

• O tipo de conectividade desejado determinará a tecnologia de rede IoT usada.
• Os casos de uso são definidos: o que conectar, onde conectar, quantos dados transportar
em qual intervalo e em que distância.
• Esses casos de uso determinam a banda de frequência, a estrutura do frame e as
topologias correspondentes.
• Algumas tecnologias de acesso foram desenvolvidas especificamente para casos de uso
de IoT, outras não.
• Um parâmetro chave que determina a escolha da tecnologia de acesso é o alcance entre o
objeto inteligente e o destinatário final de informações.

6LoWPAN: Rede de transmissão de baixo débito, ou seja, a largura de banda da comunicação

não é muito elevada, mas permite a transferência de informação me ambientes mais hostis
Os grupos na figura anterior são descritos:
 69

 NFC (Near-Field Communication): escala inferior a 10 cm.

o É uma tecnologia de comunicação segura que permite EMV sem contato.
Tecnologia de pagamentos EMV (Europay, MasterCard e Visa) para garantir a troca
segura de dados entre cartões com chip de pagamento e terminais.
o É mais seguro do que as transações anteriores baseadas apenas em banda magnética
• PAN (Personal Area Network): Escala de alguns metros.
o O espaço pessoal em torno de uma pessoa. Exemplo: Bluetooth.
 HAN (Home Area Network): escala de algumas dezenas de metros.
o Exemplos: ZigBee e Bluetooth de baixa energia (BLE)
 NAN (Neighborhood Area Network): escala de algumas centenas de metros.
o O termo NAN é frequentemente usado para se referir a um grupo de unidades
domiciliares das quais os dados são recolhidos.
 FAN (Field Area Network): Escala de várias dezenas de metros a várias centenas de
metros.
o FAN refere-se a uma área externa maior do que um único grupo de unidades da casa.
o Um FAN às vezes é visto como um grupo de NANs, mas também pode ser um
grupo de HANs ou um grupo de células externas menores.
o Portanto, FAN e NAN podem às vezes ser usados alternadamente.
 LAN (Local Area Network): escala de até 100 m (ou 2.000 m em um campus).
o Exemplos: Ethernet ou IEEE 802.11.
 MAN (Metropolitan Area Network): escala até alguns quilómetros (5-50 km).
o Interliga duas ou mais LANs numa área geograficamente correlacionada: uma
cidade ou um grupo de edifícios.
 WAN (Wide Area Network): mais do que alguns quilómetros.
Numa rede IoT, um “W” pode ser adicionado para indicar que as tecnologias wireless são
usadas.
Exemplo:
– HomePlug é uma tecnologia com fio encontrada num ambiente HAN.
– WHAN (Wireless Home Area Network) indica que uma tecnologia wireless, como
ZigBee, é usada no HAN.
• Distâncias alcançáveis semelhantes não implicam em caraterísticas de protocolos
semelhantes.
• Cada protocolo usa um formato de frame específico e técnica de transmissão numa
frequência (ou banda) específica.
• Quatro tecnologias, representando os alcances de WHAN a WLAN, são comparadas em
relação à taxa de transferência e à faixa que pode ser alcançada em cada caso. Este
assume que o sensor usa o mesmo tamanho de frame, potência de transmissão e ganho de
antena.
 70

Communications Criteria
Critérios para avaliação de casos e soluções:
• Existem várias soluções wireless e wired para conectar things.
• No entanto, o wireless é dominante para a conectividade de objetos inteligentes porque
permite que estes tenham mobilidade.
Caraterísticas e atributos relevantes para conectar objetos inteligentes: alcance, bandas de
frequência, consumo de energia, topologia, dispositivos restritos e redes de nós restritos.
Communications Criteria – Range/Alcance
• Quão longe?
• Qual área?
• Interior, exterior?
Para simplesmente analisar, três intervalos serão considerados:
 Curto alcance: dezenas de metros
 Alcance médio: dezenas a centenas de metros; distância máxima geralmente < 1,6 Km
 Longo alcance: > 1,6 Km
Em implantações reais, as especificações de cobertura máxima não devem ser consideradas
garantidas!
 71

Communications Criteria – Frequency Bands

 O espetro de rádio é regulamentado por países e/ou organizações, como International
Telecommunication Union (ITU) ou Federal Communications Commission (FCC).
 O espetro para várias comunicações é frequentemente um recurso crítico (e escasso).
 Em relação às tecnologias de acesso IoT, as bandas de frequência são divididas entre
bandas licenciadas e não licenciadas.
o O espetro licenciado é geralmente aplicável a tecnologias de acesso de longo
alcance IoT e alocado a infra-estruturas de comunicações montadas por
provedores de serviços e serviços públicos. Os utilizadores devem assinar
serviços ao conectar os seus dispositivos IoT. Isso adiciona complexidade à
implantação, mas a operadora de rede pode garantir a qualidade do serviço.
o Exemplos de espetro licenciado: celular, WiMAX e IoT de banda estreita.
 No entanto, nem todo espetro licenciado exige pagamento. A tecnologia wireless
Digital Enhanced Cordless Telecommunications (DECT) opera em bandas licenciadas
centradas em 1,9 GHz.
DECT Ultra Low Energy (ULE) é definido como um padrão de comunicação wireless
IoT (para casas inteligentes) e não requer um provedor de serviços.
 Sem licença significa que nenhuma garantia ou proteção é oferecida; permite o uso
não coordenado de vários dispositivos de comunicação.
 Não licenciado não significa não regulamentado! Essas são regulamentações
nacionais que definem a conformidade do dispositivo em parâmetros como potência
de transmissão, ciclo de serviço e tempo de permanência, largura de banda do canal e
salto de canal.
 O ITU-T definiu o espetro não licenciado para o setor industrial, científico e médico
(ISM). Essas frequências são usadas em muitas tecnologias de comunicação para
dispositivos de curto alcance (SRDs).
 Para acesso IoT, estas são as bandas ISM mais conhecidas:
o Banda de 2,4 GHz conforme usada por IEEE 802.11b / g / n Wi-Fi
o IEEE 802.15.1 Bluetooth
o Redes de área pessoal wireless IEEE 802.15.4 (WPAN)
 O espetro não licenciado é mais fácil de implantar do que o espetro licenciado porque
não requer um provedor de serviços. No entanto, ele pode sofrer mais interferências.
Portanto, a questão é: uma infraestrutura de IoT deve usar espetro licenciado ou não
licenciado? Com banda licenciada, tenho um service Provider, então dá-me garantias
do bom funcionamento/cobertura da rede. (Este serviço pode não estar adaptado para
as necessidades de IoT). Com gama não licenciada, sou eu que tenho de gerir vários
canais de comunicação.
 Algumas tecnologias de área ampla de baixa potência/Low-Power Wide-Area
(LPWA) são relevantes para responder à pergunta anterior.
 Essas tecnologias LPWA não apenas atendem ao baixo consumo de energia, mas
podem cobrir longas distâncias, que antes só podiam ser oferecidas por provedores de
serviços para dispositivos celulares.
 A frequência de transmissão está relacionada ao alcance.
 Bandas de frequência sub-GHz, mantendo a potência de transmissão dentro do
regulamento:
 72

o permitir distâncias maiores

o penetrar em melhores infraestruturas de construção
o contorne obstáculos
 do que a banda ISM de 2,4 GHz.
 As bandas de frequência sub-GHz, entretanto, têm menor taxa de entrega de dados.
Communications Criteria – ISM Frequency Bands

 Várias faixas sub-GHz foram definidas para ISM. As bandas mais conhecidas estão
centradas em 169 MHz, 433 MHz, 868 MHz e 915 MHz.
 A faixa de 868 MHz foi definida na Recomendação 70-03 da Conferência Europeia
das Administrações de Correios e Telecomunicações (CEPT), no Comité Europeu de
Radiocomunicações (ERC), em 1959, nomeadamente a sua
o potência de transmissão permitida ou EIRP (potência irradiada isotrópica efetiva)
o e duty cycle/ciclo de trabalho
A banda de 868 MHz é aplicável a tecnologias de acesso IoT, como IEEE 802.15.4,
802.15.4g, 802.11ah e LoRaWAN.
 Mais recentemente (2015), a Recomendação 70-03 introduziu uma nova banda: 870-
846 MHz. Essa banda é mencionada no IEEE 802.15.4v e no Wi-SUN 1.0.
 A banda de 169 MHz é usada na Europa para aplicações de medição de água e gás
wireless - Porquê? Esta banda permite uma leitura remota 1x por mês, mesmo em
áreas densamente povoadas, esta banda pode ser utilizada e gerida de forma eficiente.

Communications Criteria – Bandas de Frequência

 73

Em conclusão, segundo Hanes et al. (2017), deve-se considerar:

 As frequências e os regulamentos correspondentes de um país ao implementar ou
implantar objetos inteligentes de IoT.
 Objetos inteligentes que funcionam em bandas não licenciadas podem ser facilmente
otimizados em termos de hardware que suporta as duas principais frequências sub-
GHz em todo o mundo, 868 MHz e 915 MHz.
 Parâmetros como potência de transmissão, antenas e EIRP devem ser selecionados
adequadamente para seguir as configurações exigidas pelos regulamentos de cada
país.
Communications Criteria – Power Consumption
 Powered nodes (conexão direta a uma fonte de alimentação):
o a comunicação geralmente não é determinada pelo consumo de energia
o deployment menos flexível (localizado onde haja uma power-line)
 Battery-powered nodes
o deployment mais flexível
o mobilidade é limitada
o classificados de acordo com a duração da bateria:
 10-15 anos (medidores de água ou gás?)
 5-7 anos (sensores de estacionamento inteligentes?)
 2-3 anos (manutenção regular).
 A necessidade de baixo consumo de energia e conectividade a nós alimentados por
bateria resultou em novos ambientes, como Rede de Área Ampla de Baixa Potência
(LPWA):
o Sigfox, Lora, Ingenu (espetro não licenciado)
o 3GPP-NB-IOT (espetro licenciado)

Qualquer tecnologia wireless pode funcionar com baterias, mas ...

 As tecnologias de acesso IoT com fio que consistem em nós energizados também
devem buscar a otimização de energia. No caso de deployment de medidores
inteligentes, eles não podem consumir 5 a 10 watts de energia, ou isso resultaria, para
uma implantação de 20 milhões de metros em 100 a 200 megawatts de energia para
comunicações.
Nota: O consumo de energia dos medidores inteligentes é um fardo para a empresa de
energia.
Communications Criteria – Topology (star)
Topologia em estrela:
 Usado em tecnologias de curto e longo alcance.
 Dominante em redes celulares, LPWAN e Bluetooth e Wi-Fi interno.
 Exemplo: Num deployment de Wi-Fi interno, pode-se ter um conjunto de nós
formando uma estrela ao redor de seu ponto de acesso (AP).
 74

FFD (Full-Function Device) é um nó intermediário que interconecta outros nós.

RFD (Reduced Function Device) é um nó que não interconecta ou retransmite o tráfego de
outros nós (um nó folha).
Communications Criteria – Topology (peer-to-peer)
Topologia ponto a ponto:
 As topologias ponto a ponto permitem que qualquer dispositivo se comunique
diretamente com qualquer outro dispositivo, desde que estejam ao alcance um do
outro (sem a necessidade de um servidor central).
 Topologias ponto a ponto contam com vários dispositivos de full function.
 As informações podem ser publicadas na rede de forma broadcast.
 Topologias ponto a ponto permitem formações mais complexas, como uma topologia
de rede em malha.

Communications Criteria – Topology (star and mesh/malha)

Topologia de malha/mesh:
 Comum em tecnologias de médio alcance.
 A topologia de malha aparece em: IEEE 802.15.4 e 802.15.4g e PLC com fio IEEE
1901.2a.
 Uma topologia em malha ajuda a lidar com baixa potência de transmissão, pois os nós
intermediários retransmitem o tráfego para outros nós.
 Exemplo. Um Wi-Fi externo pode consistir em uma topologia de malha
interconectando os APs (o backbone da rede), com os nós conectando-se aos APs em
uma topologia em estrela
 75

A topologia de malha requer a implementação, em cada nó intermediário, de:

 Protocolos de encaminhamento da camada 2, chamados de mesh-under ou
 Protocolo de encaminhamento de camada 3, denominado mesh-over
Embora bem adaptada a nós alimentados/powered, a topologia de malha requer uma
implementação devidamente otimizada para nós alimentados por bateria:
 Os nós alimentados por bateria são frequentemente colocados num “modo de espera”
para preservar a vida útil da bateria quando não estão a transmitir.
 Os nós alimentados por bateria devem atuar como nós folha ou como um “caminho de
último recurso” para retransmitir o tráfego quando usados como nós intermediários.
Para nós alimentados por bateria, o tipo de topologia e a função de cada nó na topologia são
fatores significativos para uma implementação bem-sucedida.
Communications Criteria – Constrained Devices
 Fala-se de “dispositivo restrito” quando as suas propriedades como um nó de rede não
estão em foco.
 Os nós restritos têm recursos limitados que afetam o seu conjunto de recursos e
capacidades de rede. Portanto, algumas classes de nós de IoT não implementam uma
pilha de IP.
 De acordo com RFC 7228 (2014), nós restritos podem ser divididos em classes 0, 1 e
2:

Communications Criteria – Constrained-Node Networks

RFC 7228 define:
 76

 Constrained Network: uma rede onde algumas das caraterísticas usuais da Internet
não são alcançáveis.
 Challenge Network: uma rede que tem muita dificuldade em manter o que uma
aplicação esperaria hoje do modelo IP de ponta a ponta (por exemplo, exibindo sérias
interrupções na conectividade IP de ponta a ponta ou atraso excessivo).
 Constrained-Node Network: uma rede cujas caraterísticas são influenciadas por serem
compostas por uma porção significativa de nós restritos. Uma rede de nós restritos
sempre é uma rede restrita por causa das restrições de rede decorrentes das restrições
de nós, mas também pode ter outras restrições que já a tornam uma rede restrita.
 As redes de nós restritos são frequentemente chamadas de redes de baixa potência e
com perdas/Low-Power and Lossy Networks (LLNs).
 Os LLNs são geralmente compostos de muitos dispositivos incorporados com energia,
memória e recursos de processamento limitados interconectados por uma variedade de
links, como IEEE 802.15.4 ou Wi-Fi de baixa potência [RFC 7228].
 Redes com perdas indicam que o desempenho da rede pode sofrer interferência e
variabilidade devido a ambientes de rádio adversos.
 Os protocolos da Camada 1 e Camada 2 que podem ser usados para redes de nós
restritos devem ser avaliados no contexto das seguintes caraterísticas para
aplicabilidade de caso de uso: taxa de dados e rendimento, latência e determinismo e
sobrecarga e payload.
 Data Rate and Throughput/Taxa de dados e taxa de transferência:
o Há uma grande variedade de valores de taxa de dados (de 100 bps com Sigfox a
dezenas de megabits por segundo com tecnologias como LTE e IEEE 802.11ac)
o No entanto, a taxa de transferência real pode, às vezes, ser significativamente menor do
que a taxa de dados.
o As tecnologias não especialmente projetadas para IoT, como celular e Wi-Fi, são
adequadas para aplicações de IoT com requisitos de alta largura de banda. Nesse caso,
o design tende a se concentrar nos requisitos da aplicação, como latência e
determinismo.
o As tecnologias de curto alcance também podem fornecer taxas de dados médias a altas
com taxa de transferência suficiente para conectar alguns terminais. Por exemplo, os
sensores Bluetooth que agora aparecem em wearables conectados enquadram-se nesta
categoria. Neste caso, as soluções concentram-se mais na área ocupada e na vida útil da
bateria do que na taxa de dados.
o As tecnologias de acesso IoT desenvolvidas para nós restritos são otimizadas para
baixo consumo de energia, mas também são limitadas em termos de taxa de dados, que
depende da banda de frequência selecionada e da taxa de transferência.
o As redes LPWA são projetadas para um determinado número de mensagens por dia ou
por terminal, em vez de apenas ter um limite de uso de largura de banda puro.
o Numa topologia de malha de acesso, o comportamento de uma aplicação, como
pesquisa de frequência, afeta o design porque todos os dispositivos partilham a
capacidade de largura de banda restrita.
o A taxa de transferência real geralmente é importante para nós restritos que
implementam uma pilha de IP.
 77

Nesse caso, a taxa de transferência é uma percentagem menor da taxa de dados, mesmo
se o nó obtiver toda a largura de banda da rede restrita num determinado momento.
Para ver a diferença entre a taxa de dados e a taxa de transferência/débito de dados,
considere a sub-rede IEEE 802.15.4g implementando a modulação 2FSK a 150 kbps para
a banda de frequência de 915 MHz.
o Para cobrir o caso limite de distância e qualidade do sinal de rádio, Forward Error
Correction (FEC) será ativado, o que reduz a taxa de transferência de 150 kbps para 75
kbps.
o Adicionando a sobrecarga da pilha/stack overhead de protocolo, o tratamento de
comunicação bidirecional e o tamanho do payload de dados variável, a taxa de
transferência máxima será de 30 a 40 kbps.
o Isso deve ser considerado como o melhor valor porque o número de dispositivos que se
comunicam simultaneamente com a topologia e a sobrecarga do plano de controlo
também afetará o rendimento.
o A maioria dos dispositivos IoT inicia a comunicação.
o Consequentemente, o tráfego upstream para um servidor de aplicações tende a ser
maior do que o tráfego downstream do servidor de aplicações.
o Esta caraterização do tráfego é importante para determinar a capacidade de rede
necessária
 Latency and Determinism:
o Assim como os requisitos de rendimento, as expectativas de latência das aplicações IoT
devem ser conhecidas ao selecionar uma tecnologia de acesso.
o Em redes wireless, a perda de pacotes e as retransmissões devido a interferência,
colisões e ruído são comportamentos normais.
o A latência pode variar de alguns milissegundos a segundos, e as aplicações e pilhas de
protocolo devem lidar com estes valores abrangentes.
 Por exemplo, o UDP na camada de transporte é altamente recomendado para
terminais IP que se comunicam por LLNs.
 No caso de topologias em malha, se houver necessidade de comunicação entre dois
dispositivos dentro da malha, a otimização do routing do caminho de
encaminhamento é obtida usando RPL (Protocolo de Roteamento IPv6 para Redes
de Baixa Potência e com Perdas) - RCF 6550.
o Quando a latência é uma grande preocupação, tecnologias de acesso emergentes como
Ethernet Determinística ou o modo Time-Slotted Channel Hopping (TSCH) do IEEE
802.15.4e devem ser consideradas.

 Overhead and Payload:

o Ao considerar tecnologias de rede de acesso restrito, deve-se estar ciente das
caraterísticas do tamanho do payload MAC (capacidade máxima de transmissão por
cada pacote) exigidas pelas aplicações.
o Deve-se também considerar os requisitos de IP. O tamanho mínimo do MTU IPv6 é
estimado em 1280 bytes, que terá que ser fragmentado para se ajustar aos protocolos de
 78

acesso da camada de link com MTUs menores. Nota: O uso de IP em dispositivos IoT é
um tópico aberto de discussão. Lembre-se de que as classes 0 e 1 não têm uma
implementação completa da pilha de IP.
o Para tecnologias que se enquadram na definição de LLN, mas são capazes de
transportar IP (por exemplo, IEEE 802.15.4), as capacidades de fragmentação da
Camada 1 ou Camada 2 e / ou otimização de IP são importantes.
Exemplos:
o O tamanho do payload para IEEE 802.15.4 é de 127 bytes e requer um payload IPv6
com um MTU mínimo de 1280 bytes para ser fragmentado.
o Por outro lado, o IEEE 802.15.4g possibilita payloads de até 2.048 bytes, mais
adequado para transportar IPv6 MTU mínimo de 1280 bytes.
o A maioria das tecnologias LPWA oferece tamanhos de payload pequenos, para lidar
com a baixa taxa de dados e tempo no ar ou requisitos de duty cycle de nós e sensores
de IoT.
 Por exemplo, as cargas úteis podem ter até 19 bytes usando a tecnologia
LoRaWAN ou até 250 bytes, dependendo da Adaptative Data Rate (ADR).
 Embora isso não impeça o uso de um payload IPv6 / 6LoWPAN, como visto em
algumas implementações de endpoint, esses tipos de protocolos são mais
adequados para nós de Classe 0 e 1 (consulte RFC 7228).
6LoWPAN (IPv6 over Low power Wireless Personal Area Networks)
 Conclusão:
o Os critérios de comunicação que acabamos de abordar são fundamentais para
compreender as tecnologias de acesso à IoT, suas caraterísticas e quando são mais
aplicáveis.
o Esses critérios incluem faixa, bandas de frequência, consumo de energia, topologia de
rede, presença de dispositivos e / ou redes restritas e taxa de transferência de dados.
o Do ponto de vista do engenheiro de rede, você deve garantir que uma arquitetura seja
desenvolvida com a abstração adequada para uma tecnologia de acesso específica.
IoT access technologies
 Acabamos de encerrar a descrição dos critérios que ajudam na avaliação das
tecnologias de rede restritas de IoT para o projeto e as operações adequadas.
 No livro de referência Hanes et al (2017), é possível encontrar uma visão geral de
algumas das principais tecnologias de acesso IoT:
o IEEE 802.15.4
o IEEE 802.15.4g e 802.15.4e
o IEEE 1901.2a
o IEEE 802.11ah
o LoRaWAN
o NB-IoT e outras variações LTE
 As tecnologias listadas acima são aquelas que são vistas como tendo market share
e/ou mind share.
Para cada uma das tecnologias de acesso IoT listadas acima, um conjunto comum de
informações pode ser encontrado em Hanes et al (2017), e deve ser usado como referência:
 79

 Padronização e alianças/ Standardization and alliances: os organismos de

padronização que mantêm os protocolos para uma tecnologia
 Camada física: Os métodos wired ou wireless e frequências relevantes
 Camada MAC: Considerações na camada Media Access Control (MAC), que conecta
a camada física com o controlo de link de dados
 Topologia: as topologias suportadas pela tecnologia
 Segurança: Aspetos de segurança da tecnologia
 Tecnologias competitivas: outras tecnologias que são semelhantes e podem ser
alternativas adequadas para a tecnologia dada
IoT access technologies – IEEE 802.15.4
IEEE 802.15.4 é uma tecnologia de acesso sem fio para dispositivos de baixo custo e baixa
taxa de dados que são alimentados ou funcionam com baterias.
 Instalação fácil
 Várias pilhas de protocolo (por exemplo, Zigbee, 6LoWPAN) usam 802.15.4
 É encontrado em:
o Automação residencial e de edifícios
o Redes automotivas
o Redes industriais de sensores wireless
o Brinquedos interativos e controlos remotos
Desvantagens IEEE 802.15.4:
Confiabilidade MAC
Percentagem muito baixa de mensagens de dados entregues corretamente ao nó que
recolhe devido ao algoritmo CSMA / CA (Collision Sense Multiple Access / Collision
Avoidance).
Latência ilimitada
Suscetibilidade à interferência
Desvanecimento multipercurso
Interferência e desvanecimento de multipath ocorrem com IEEE 802.15.4 porque ele não
possui uma técnica de salto de frequência (que está presente em versões posteriores).

 Standardization and Alliances

o IEEE 802.15.4 ou IEEE 802.15 Task Group 4 www.ieee802.org/15/pub/TG4.html

define especificações de camada PHY e MAC de baixa taxa de dados para redes de
área pessoal wireless (WPAN).
 O IEEE 802.15.4 é uma solução para dispositivos wireless de baixa
complexidade com baixas taxas de dados que precisam de muitos meses ou até
anos de bateria.
 80

 O IEEE publicou várias iterações da especificação IEEE 802.15.4, cada uma

rotulada com o ano da publicação.
 Não há aliança ou órgão de promoção para IEEE 802.15.4. No entanto, as
camadas IEEE 802.15.4 PHY e MAC são as bases para várias pilhas de
protocolo de rede, que são promovidas por várias organizações e
frequentemente comercializadas.
Pilhas/Stacks de protocolo usando camadas IEEE 802.15.4 PHY e MAC:
o ZigBee: promovido pela ZigBee Alliance, ZigBee define componentes de camada
superior (rede por meio de aplicação), bem como perfis de aplicação (por
exemplo, automação predial). www.zigbee.org
o 6LoWPAN: Uma camada de adaptação IPv6 definida pelo IETF 6LoWPAN
(IPv6 sobre redes de área pessoal wireless de baixa potência)
o ZigBee IP: Uma evolução da pilha de protocolo ZigBee, ZigBee IP adota a
camada de adaptação 6LoWPAN, camada de rede IPv6 e protocolo de routing
RPL. Além disso, oferece melhorias na segurança de IP.
o ISA100.11a: Desenvolvido pela International Society of Automation (ISA) como
“Wireless Systems for Industrial Automation: Process Control and Related
Applications”. É baseado no IEEE 802.15.4-2006. As camadas de rede e
transporte são baseadas nos padrões IETF 6LoWPAN, IPv6 e UDP.
o WirelessHART, promovido pela HART Communication Foundation, é uma pilha
de protocolo que oferece uma arquitetura de malha/mesh com sincronização de
tempo, auto-organização e autorrecuperação, aproveitando o IEEE 802.15.4-2006
sobre a banda de frequência de 2,4 GHz. Consulte
http://www.emerson.com/resource/blob/ system-engineering-guidelines-iec-
62591-wirelesshart - data-79900. Pdf
o Thread: Construído sobre IETF 6LoWPAN / IPv6, Thread é uma pilha de
protocolo para uma rede mesh segura e confiável para conectar e controlar
produtos em casa. www.threadgroup.org
 Standardization and Alliances – Zigbee
O Zigbee é um dos protocolos mais antigos e conhecidos com base no IEEE 802.15.4.
o A primeira especificação ZigBee foi validada em 2004, logo após o lançamento do
IEEE 802.15.4 um ano antes. Foi prorrogado em 2006 e 2007.
o Inicialmente, era apoiado por mais de 100 empresas, e atualmente mais de 400
empresas (a Aliança Zigbee).
o A Zigbee Alliance é um grupo da indústria formado para certificar a
interoperabilidade entre fornecedores.
o Os fornecedores que implementam perfis de aplicações Zigbee predefinidas, como
Home Automation ou Smart Energy, podem garantir a interoperabilidade entre os
seus produtos.
o As soluções ZigBee são direcionadas a objetos e sensores inteligentes que possuem
baixa largura de banda e baixa necessidade de energia.
As principais áreas onde ZigBee é mais conhecido incluem automação para aplicações
comerciais, residenciais e energia inteligente.
 81

o A pilha ZigBee tradicional é ilustrada na Figura.

o A rede ZigBee e a camada de segurança fornecem mecanismos para inicialização,
configuração, routing e proteção das comunicações da rede.
o Este usa o routing Ad hoc On-Demand Distance Vector (AODV) numa rede mesh.
o Buscando fornecer interoperabilidade com outras soluções de IoT, a Zigbee Alliance
lançou o ZigBee IP, que será discutido a seguir.

 Standardization and Alliances – Zigbee IP

ZigBee IP ainda é baseado em IEEE 802.15.4, mas os protocolos IP e TCP/UDP e vários
outros padrões abertos agora são suportados nas camadas de rede e transporte.
o As camadas específicas de ZigBee agora são encontradas apenas no topo da pilha
de protocolo para as aplicações.
o ZigBee IP foi criado para abraçar os padrões abertos provenientes do trabalho da
IETF em LLNs, como IPv6, 6LoWPAN e RPL. Estes fornecem largura de banda
baixa, baixo consumo de energia e comunicações económicas ao conectar objetos
inteligentes.
o ZigBee IP é uma parte crítica da especificação Smart Energy (SE) Profile 2.0 da
ZigBee Alliance.
Cada camada sob a camada de aplicação é baseada nos padrões IoT atuais!

 Physical Layer
O padrão 802.15.4 oferece suporte a várias opções PHY:
o Frequências de 2,4 GHz a sub-GHz nas bandas ISM.
 82

o IEEE 802.15.4-2003, usando modulação de espetro de difusão de sequência

direta (DSSS), especificado:2,4 GHz, 16 canais, com uma taxa de dados de 250
kbps (O-QPSK)
 915 MHz, 10 canais, com uma taxa de dados de 40 kbps (BPSK)
 868 MHz, 1 canal, com uma taxa de dados de 20 kbps (BPSK)
IEEE 802.15.4-2006, 802.15.4-2011 e IEEE 802.15.4-2015 introduziram opções de
comunicação PHY adicionais, que permitiram estender a data rate de 868 MHz e 915
MHz para 100 kbps e 250 kbps, respetivamente.
BPSK - Bynary Phase Shift Keying
O-QPSK - Offset Quadrature Phase Shift Keying

 O header de sincronização para este frame é composto dos campos Preâmbulo (4

bytes de 32 bits) e Início do Delimitador de Frame.
 O campo delimitador informa ao recetor que o conteúdo do frame começa
imediatamente após esse byte.
 A parte do header PHY permite que o recetor saiba quantos dados totais esperar na
unidade de dados de serviço PHY (PSDU).
 O PSDU é o campo de dados. O seu tamanho é significativamente menor do que o
MTU mais baixo dos protocolos da camada superior. A fragmentação dos pacotes
IPv6 deve ocorrer.

 MAC Layer
o A camada MAC IEEE 802.15.4 gere o acesso ao canal PHY definindo como os
dispositivos na mesma área partilharão as frequências alocadas (CSMA / CA).
o A programação e o routing de frames de dados também são coordenados na camada
MAC.
o A camada 802.15.4 MAC executa as seguintes tarefas:
 Sinalização de rede para dispositivos que atuam como coordenadores (novos
dispositivos usam beacons para ingressar numa rede 802.15.4)
 Associação e desassociação de PAN por um dispositivo
 Segurança do dispositivo
 Comunicação de link confiável entre duas entidades MAC pares
 MAC Layer (nonbeacon)
O modo sem beacon e o modo beacon são dois modos básicos de transmissão do IEEE
802.15.4 (Akbar 2016):
 83

o Num modo nonbeacon, quando um nó deseja transmitir dados, ele detetará o

canal (CSMA / CA sem slot).
o O coordenador é colocado no estado de espera neste modo. Se o canal estiver
ocupado, o dispositivo precisa aguardar um período de tempo aleatório definido
no padrão.
o Não há necessidade de nenhum processo de sincronização por parte do
coordenador; o coordenador é apenas responsável pela associação e
desassociação.
Este modo fornece escalabilidade, bateria de longa duração e auto-organização, mas não
oferece nenhuma garantia para transmissões de dados.
o No modo beacon, o coordenador envia um beacon periodicamente aos
dispositivos para sincronização.
o Ao receber os beacons, os dispositivos conseguem saber a duração do superframe
(período de atividade do coordenador) e quando o dispositivo pode fazer a
transmissão de dados.
o A figura mostra a estrutura do superframe.
 Formato de frame de beacon de IEEE 802.15.4 (Akbar 2016)
 CAP (CFP): período de contenção de acesso (gratuito)
 BO: ordem beacon
 SO: representa o comprimento do BI e a duração do superframe

 MAC Layer
Tipos de frames MAC:
o Data Frame: lida com todas as transferências de dados
o Beacon Frame: usado na transmissão de beacons de um coordenador PAN
o Acknowledgement Frame: confirma a receção bem-sucedida de um frame
o MAC Command Frame: Responsável pelo controlo de comunicação entre os
dispositivos. Cada um desses quatro tipos de frame 802.15.4 MAC segue o
formato de frame mostrado na figura
o O frame 802.15.4 MAC pode ser dividido no header MAC, MAC
o Payload e campo de rodapé MAC, conforme mostrado na figura seguinte
 84

 IoT access technologies: IEEE 802.15.4 – Topology

o É necessário, no mínimo, um FFD atuando como coordenador do PAN para fornecer
serviços que permitem que outros dispositivos se associem e formem uma célula ou
PAN.
o A seleção do path dentro da camada MAC para uma topologia de mesh pode ser feita
na Camada 2 e é conhecida como mesh-under. Geralmente, isto é baseado numa
solução proprietária. Como alternativa, a função de routing pode ocorrer na Camada
3, usando um protocolo de routing, como o RPL. Isto é conhecido como mesh-over.

 IoT access technologies: IEEE 802.15.4 – Security

o A especificação IEEE 802.15.4 usa o Advanced Encryption Standard (AES) com um
comprimento de chave de 128 bits como o algoritmo de criptografia básico para
proteger seus dados.
o Além de criptografar os dados, o AES em 802.15.4 também valida os dados enviados.
Isto é realizado por um código de integridade de mensagem (MIC), que é calculado
para todo o frame usando a mesma chave AES usada para criptografia.
o A introdução desses recursos requer uma modificação do formato:
 Usar o campo Security Enabled na parte Frame Control do header 802.15.4 é a
primeira etapa para habilitar a criptografia AES. Este campo é um único bit
definido como 1 para segurança.
 85

 Depois que esse bit é definido, um campo chamado header de segurança auxiliar
é criado após o campo Endereço de origem, roubando alguns bytes do campo
Payload.
 IoT access technologies: IEEE 802.15.4 – MAC Layer
A Figura mostra o formato de quadro IEEE 802.15.4 em alto nível, com o bit Security
Enabled definido e o campo Auxiliary Security Header presente.

Formato de frame com o campo de header de segurança auxiliar para 802.15.4-2006 e

versões posteriores.
 IoT access technologies: IEEE 802.15.4 – Competitive technologies
Uma tecnologia de rádio competitiva diferente de 802.15.4 nas suas camadas PHY e
MAC é o DASH7.
o O DASH7 foi originalmente baseado no padrão ISO18000-7 e posicionado para
comunicações industriais, enquanto o IEEE 802.15.4 é mais genérico.
o Comumente empregue em implementações de identificação de radiofrequência ativa
(RFID), o DASH7 foi usado pelas forças militares dos Estados Unidos por muitos
anos, principalmente para fins de logística.
o O RFID ativo utiliza ondas de rádio geradas por uma etiqueta alimentada por bateria
num objeto para permitir rastrear continuamente.
o A tecnologia DASH7 atual oferece baixo consumo de energia, uma pilha de protocolo
compacta, alcance de até 1 milha e criptografia AES.
o As frequências de 433 MHz, 868 MHz e 915 MHz foram definidas, permitindo taxas
de dados de até 166,667 kbps e um payload máxima de 256 bytes.
o DASH7 é promovido pela DASH7 Alliance (www.dash7-alliance.org)
 IoT access technologies: Brief overview – IEEE 802.15.4g and 802.15.4e
o O IEEE 802.15.4e-2012 procura remediar as desvantagens associadas ao 802.15.4,
incluindo confiabilidade MAC, latência ilimitada e desvanecimento de caminhos
múltiplos.
o O IEEE 802.15.4e também fez melhorias para lidar melhor com certos domínios de
aplicação.
o O IEEE 802.15.4e aprimorou os recursos da camada MAC do IEEE 802.15.4 nas
áreas de formato de frame, segurança, mecanismo de determinismo e salto de
frequência.
 86

o IEEE 802.15.4g-2012 que, assim como 802.15.4e-2012, foi totalmente integrado na

especificação IEEE 802.15.4-2015 principal. O foco desta especificação é a rede
elétrica inteligente ou, mais especificamente, a comunicação de rede de serviços
públicos inteligentes.

 IoT access technologies: Brief overview – IEEE 1901.2a

o IEEE 1901.2a-2013 é uma tecnologia wired que é uma atualização do IEEE 1901.2.
Este é um padrão para Narrowband Power Line Communication (NB-PLC).
o O NB-PLC aproveita um espetro de banda estreita para baixa potência, longo
alcance e resistência à interferência nos mesmos fios que transportam energia
elétrica.
o Alguns casos de uso do NB-PLC são
 Medição inteligente
 Automação de distribuição:
 Iluminação pública
 Estações de carregamento de veículos elétricos
 Microrredes I Energia renovável
o IEEE 1901.2a especifica o uso de linhas de energia elétrica de corrente alternada e
contínua. Linhas de baixa e média tensão em ambientes internos e externos;
distâncias de múltiplas milhas; taxas de dados de até 500 kbps.

 IoT access technologies: Brief overview – IEEE 802.11ah

Em redes não restritas, o IEEE 802.11 Wi-Fi é muito bem-sucedido.
o Wi-Fi é uma tecnologia-chave de acesso wireless IoT, seja para conectar endpoints
como fog computing nodes, sensores de alta taxa de dados e dispositivos analíticos
de áudio ou vídeo ou para deploying de infraestruturas de backhaul Wi-Fi.
o No entanto, o Wi-Fi carece de suporte sub-GHz para melhor penetração do sinal,
baixa energia para nós alimentados por bateria e capacidade de suportar um grande
número de dispositivos.
o Consequentemente, o IEEE 802.11ah foi desenvolvido. Este especifica uma versão
sub-GHz de Wi-Fi. Três casos de uso principais são identificados para IEEE
802.11ah:
 Sensores e medidores cobrindo uma rede inteligente
 Agregação de backhaul de sensores industriais e dados de medidores:
Potencialmente conectando sub-redes IEEE 802.15.4g
 Wi-Fi de alcance estendido: para hotspot de alcance estendido externo ou
descarregamento de tráfego de celular quando as distâncias já cobertas por IEEE
802.11a / b / g / n / ac não são boas o suficiente IoT access technologies: Brief
overview – LoRaWAN
o As tecnologias wireless conhecidas como Low-Power Wide-Area (LPWA) são bem
adaptadas para terminais de longo alcance e alimentados por bateria.
o O termo LoRa refere-se à camada PHY e LoRaWAN e foca na arquitetura, a camada
MAC e um padrão único e unificado para interoperabilidade contínua.
o LoRaWAN é administrado pela LoRa Alliance, uma organização do setor.
 87

o As camadas PHY e MAC permitem que o LoRaWAN cubra distâncias mais longas
com uma taxa de dados que pode mudar dependendo de vários fatores. A arquitetura
LoRaWAN depende de gateways para conectar terminais a servidores de rede.
o Do ponto de vista da segurança, o LoRaWAN oferece autenticação e criptografia
AES.
 IoT access technologies: Brief overview – LoRaWAN and two competitors

 IoT access technologies: Brief overview – NB-IoT and Other LTE Variations
o As tecnologias celulares existentes, como GPRS, Edge, 3G e 4G / LTE, não são
particularmente bem adaptadas para dispositivos alimentados por bateria e pequenos
objetos desenvolvidos especificamente para IoT.
o 3GPP e fornecedores associados trabalharam em tecnologias celulares para melhor
atender aos requisitos de IoT.
o Novas categorias de dispositivos LTE foram criadas para se alinhar aos requisitos
específicos de IoT, como baixo rendimento e baixo consumo de energia, e também
diminuir a complexidade e o custo dos dispositivos LTE. Isso resultou na definição
do item de trabalho LTE-M.
o Como a nova categoria de dispositivos LTE-M não estava suficientemente próxima
das capacidades LPWA, em 2015 o 3GPP aprovou uma proposta para padronizar
uma nova tecnologia de acesso de rádio de banda estreita chamada Narrowband IoT
(NB-IoT).
o O NB-IoT atende especificamente aos requisitos de um grande número de
dispositivos de baixo rendimento, baixo consumo de energia do dispositivo,
cobertura interna aprimorada e arquitetura de rede otimizada.
o NB-IoT representa o futuro da tecnologia LPWA para os provedores de serviços
móveis que possuem espetro de banda licenciada.
o As especificações relacionadas à IoT devem ser concluídas e publicadas pelo 3GPP
para permitir que fornecedores, provedores de serviços móveis e aplicações
endossem amplamente a tecnologia.
 88

o Evolução para eSIMs, que ainda não são amplamente suportados. Um cartão eSIM é
compatível com várias operadoras e também é reconfigurável.
 Conclusion
o Os critérios de comunicação e algumas tecnologias recentes de suporte ao deployment
de objetos inteligentes de IoT foram verificados.
 Em primeiro lugar, foram apresentados os critérios para avaliar objetos
inteligentes e o que é necessário para sua conectividade: faixa de transmissão,
bandas de frequência, consumo de energia, topologia e dispositivos e redes
restritos.
 É fundamental avaliar esses critérios ao lidar com deployments e redes IoT.
o Em segundo lugar, uma discussão detalhada de uma das principais tecnologias para
conectar sensores foi feita (IEEE.802.15.4) e uma breve visão geral de outra solução
foi apresentada.
o Essas tecnologias são novas e devem evoluir ao longo dos anos.
o O objetivo era sensibilizar e basear o conhecimento dessas tecnologias. A
compreensão dessas tecnologias fornecerá uma base para compreender as novas
tecnologias.

Business Case for IP

 Os data centers têm dados fluindo de/para “things”.
 Os data centers estão na cloud ou em locais que podem ser distribuídos ou
centralizados.
 s aplicações são executados em sistemas operativos virtualizados ou tradicionais ou
em plataformas de ponta de rede (por exemplo, computação em névoa).
 Essas aplicações (leves) comunicam-se com os servidores do data center.
 As soluções do sistema combinam várias camadas físicas e de link de dados e exigem
uma abordagem arquitetónica com uma (s) camada (s) comum (s) independente (s)
das camadas inferior (conectividade) e/ou superior (aplicação).
 89

 É assim e por que o pacote de protocolo da Internet (IP) começou a desempenhar um

papel arquitetónico importante no início da década de 1990.
 O IP tem sido preferido tanto nos mercados de TI quanto no ambiente de OT.
Lembre-se de que:
o A tecnologia da informação (TI) oferece suporte a conexões com a Internet
junto com dados relacionados e sistemas de tecnologia e está focada no fluxo
seguro de dados numa organização.
o A tecnologia operativa (OT) monitoriza e controla dispositivos e processos em
sistemas operativos físicos (por exemplo, linhas de montagem e sistemas
rodoviários).
 Usar o pacote de protocolos da Internet não significa que uma infraestrutura IoT
executando IP tenha que ser uma rede aberta ou acessível publicamente.
 Antes de abordar os prós e os contras da adaptação versus adoção, algumas vantagens
do IP para IoT são apresentadas a seguir.
 Business Case for IP – Key advantages of IP (Internet Protocol)
Open and Standards-Based/Aberto e baseado em padrões
o As tecnologias operacionais podem ter otimizado as comunicações através de
soluções de rede fechadas e proprietárias. Mas a Internet das Coisas criou um novo
paradigma.
 Requer implementação, validação e implantação de soluções abertas baseadas
em padrões.
 Existem muitas organizações de desenvolvimento de padrões (SDOs)
trabalhando nas definições, estruturas, aplicações e tecnologias da Internet das
Coisas. A Internet Engineering TaskForce (IETF) é a base para especificar e
otimizar as camadas de rede e transporte. O IETF é um órgão de padrões
abertos que se concentra no desenvolvimento do pacote de protocolos da
Internet e tecnologias e protocolos de Internet relacionados.
Versátil:
o Um grande espetro de tecnologias de acesso está disponível para oferecer
conectividade de “coisas” no último Km.
o Protocolos e tecnologias adicionais também são usados para transportar dados de IoT
por meio de links de backhaul e no data center.
o Nenhuma determinada tecnologia com ou sem fio atende a todos os critérios de
deployment.
o Além disso, as tecnologias de comunicação evoluem num ritmo mais rápido do que a
vida útil esperada de 10 a 20 anos das soluções OT.
o Portanto, a arquitetura IP em camadas está bem equipada para lidar com qualquer tipo
de camadas físicas e de link de dados. Isto torna o IP ideal como um investimento de
longo prazo.
Onipresente/Ubiquous:
o Todas as versões recentes do sistema operativo têm uma pilha de IP dupla (IPv4 e
IPv6) integrada.
 90

o Os protocolos de aplicação IoT em muitas soluções OT industriais foram atualizados

para rodar em IP (principalmente IPv4 e, mais recentemente, IPv6).
o Na verdade, o IP é o protocolo mais difundido quando se olha para o que é compatível
com as várias soluções de IoT e verticais do setor.
Escalável:
o O IP foi amplamente deployed, comprovando a sua escalabilidade. Milhões de nós de
infraestrutura de IP públicos e privados estão operacionais há anos.
o Adicionar um grande número de “coisas” a essas infraestruturas pode exigir
otimizações e regras de design específicas para os novos dispositivos.
o O esforço deve ser semelhante à introdução de voz (e vídeo) sobre IP.

Gestão e altamente seguro/ Manageable and highly secure

o Após 30 anos de redes IP operacionais, os protocolos de gestão e segurança de rede
são bem compreendidos,
o Ferramentas conhecidas de gestão de rede e segurança são facilmente aproveitadas
com uma camada de rede IP.
o Apesar da natureza segura do IP, existem desafios reais nesta área. Especificamente, a
indústria enfrenta o desafio de proteger nós restritos, lidar com protocolos de legacy
OT e escalar operações.
Estável e Resiliente
o Após 30 anos, a IP mostrou que é uma solução viável.
o A IP tem uma base de conhecimento ampla e bem estabelecida.
o IP tem sido usado há anos em infraestruturas críticas, (por exemplo, financeiras).
o O IP foi deployed para serviços essenciais, como voz e vídeo.
o Grande ecossistema de profissionais de TI. O acesso dos consumidores a aplicações e
dispositivos ocorrerá predominantemente por banda larga e infraestrutura móvel sem
fio.
o Os principais dispositivos do consumidor variam de smartphones a tablets e PCs.
o IP é o protocolo comum que conecta a IoT no espaço do consumidor aos dispositivos.

O fator de inovação
o A adoção da PI é um fator para o aumento da inovação.
o IP é o protocolo básico para aplicativos que vão desde transferência de arquivos e e-
mail até a World Wide Web, e-commerce, redes sociais, mobilidade e muito mais.
o A recente evolução da computação de PC para celular e de mainframes para serviços
em cloud são provas claras do terreno inovador habilitado pelo IP.
o As inovações em IoT também podem alavancar uma base de IP.

Summary
o A adoção de IP fornece uma base sólida para a Internet das Coisas, permitindo
recursos de comunicação de dados bidirecionais seguros e que possam ser geridos
entre todos os dispositivos numa rede.
 91

o IP é um protocolo baseado em padrões ubíquos, escalonável, versátil e estável.

o Os serviços de rede, como nomenclatura, distribuição de tempo, priorização de
tráfego, isolamento e assim por diante, são técnicas bem conhecidas e desenvolvidas
que podem ser aproveitadas com IP.
o A partir de arquiteturas em cloud, centralizadas ou distribuídas, o fluxo de dados IP
pode ser desenvolvido e implementado de acordo com os requisitos de negócios.
o O IP é um requisito de ponta a ponta?

 Business Case for IP – Adoption or Adaption of IP

o A adoção de IP na última milha é mais complicada e muitas vezes torna a execução de
IP ponta a ponta mais difícil.
o Inicialmente, havia muitos protocolos na última milha. Por exemplo:
 provedores de serviços padronizados e promovidos X.25 e X.75
 fabricantes de computadores implementaram protocolos proprietários, como
SNA, DECnet, IPX e AppleTalk. e routers multiprotocolo eram necessários.
o Devido aos vários protocolos da camada de rede além do IP, normalmente, um de dois
modelos, adaptação ou adoção, é proposto:
 Adaptação significa que os gateways em camadas de aplicações (ALGs)
devem ser implementados para garantir a conversão entre as camadas não IP e
IP.
 Adoção envolve a substituição de todas as camadas não IP pelas suas
contrapartes da camada IP, simplificando o modelo de deployment e as
operações.

 Business Case for IP – Adoption or Adaption of IP: Exemplos de como a adoção e

adaptação de IP estão a ser aplicadas em IoT na última milha

o As aplicações de controlo de supervisão e aquisição de dados (SCADA) são deployed

usando o modelo de adaptação IP e o modelo de adoção. SCADA é um sistema de
controlo de automação para monitorização e controlo remoto de equipamentos.
 Implementações que fazem uso de adaptação de IP possuem dispositivos SCADA
conectados através de interfaces em série a um gateway de tunneling ou tradução
do tráfego.
 Com o modelo de adoção de IP, os dispositivos SCADA são conectados via
Ethernet a switches e routers que encaminham seu tráfego IPv4.
o Outro exemplo é uma solução ZigBee que executa uma pilha não IP entre dispositivos
e um gateway ZigBee que encaminha o tráfego para um servidor de aplicações.
Portanto, a escolha entre adaptação IP versus modelo de adoção ainda requer
investigação para tecnologias de última milha específicas usadas pela IoT.

 Business Case for IP – Adoption or Adaption of IP: Fatores a serem considerados para
selecionar o modelo para conectividade de última milha

Fluxo de dados bidirecional versus unidirecional:

Esperamos comunicações bidirecionais; no entanto, algumas tecnologias de última milha
oferecem otimização para comunicação unidirecional.
 92

o Algumas classes de dispositivos IoT, conforme definido no RFC 7228

(Terminologia para Redes de Nó Restrito), raramente precisam relatar alguns
bytes de dados para uma aplicação. Exemplos (usando LPWA): alarmes de
incêndio e medidores de água ou gás.
o Para esses casos, não vale necessariamente a pena implementar uma pilha IP
completa.
No entanto, a comunicação unidirecional tem também desvantagens: não é possível fazer
o download de um novo software ou firmware para os dispositivos, e isso torna a
integração de novos recursos e correções de bugs e segurança mais difícil.

Sobrecarga para os caminhos de comunicação da última milha:

o A adoção de IP implica numa arquitetura em camadas com sobrecarga por pacote
que varia de acordo com a versão do IP.
 O IPv4 tem no mínimo 20 bytes de header e o IPv6 tem 40 bytes na camada
de rede IP. Para a camada de transporte IP, o UDP tem 8 bytes de sobrecarga
de header, enquanto o TCP tem um mínimo de 20 bytes.
 Se os dados a serem encaminhados por um dispositivo são raros e apenas
alguns bytes...
o Portanto, a questão é: o modelo de adoção de PI é de fato necessário? Se a
resposta for sim, como pode ser otimizado?
o Isso também é verdadeiro para o tráfego do plano de controlo que é executado
sobre IP para links de baixa largura de banda e de última milha. O protocolo de
routing e outros serviços de rede detalhados podem não ser necessários ou podem
exigir otimização.

Modelo de fluxo de dados

o Um benefício do modelo de adoção de IP é a natureza ponta a ponta das
comunicações.
o No entanto, em muitas soluções de IoT, o fluxo de dados de um dispositivo é
limitado a uma ou duas aplicações. Neste caso, o modelo de adaptação pode
funcionar.
o Dependendo da topologia da rede e do fluxo de dados necessário, os modelos de
adaptação e adoção de IP podem ser relevantes na conectividade de última milha.

Diversidade de rede/Network diversity

o Uma das desvantagens do modelo de adaptação é uma dependência geral de
camadas simples PHY e MAC.
 Por exemplo, os dispositivos ZigBee só devem ser deployed em ilhas de rede
ZigBee. Da mesma forma para nós ITU G.9903 G3-PLC
o Portanto, uma deployment deve considerar quais aplicações devem ser
executadas no gateway que conecta essas ilhas e o resto do mundo.
o A integração e a coexistência de novas camadas físicas e MAC ou novas
aplicações afetam o modo como o deployment e as operações devem ser
planeadas. Isto não é relevante para o modelo de adoção.
 93

The need for optimization

A Internet das Coisas será amplamente construída no conjunto de protocolos da Internet. Mas
alguns desafios persistem:
 a integração de dispositivos não IP
 lidar com os limites nos níveis de dispositivo e rede que a IoT frequentemente impõe
Portanto, otimizações são necessárias em várias camadas da pilha de IP para lidar com as
restrições que estão presentes nas redes IoT.
 The need for optimization – Constrained Nodes
Em IoT, temos (consulte RFC 7228 para obter mais detalhes):
o Dispositivos das classes C0, C1 e C2 (dados e tamanho do código).
o E0, E1, E2 e E9 de acordo com as classes de limitação de energia:

o P0, P1, P9, conforme Estratégias de Uso de Energia para Comunicação

o Uma arquitetura de “coisa” pode ou não oferecer caraterísticas semelhantes em

comparação com um PC ou servidor genérico num ambiente de TI.
o A pilha de protocolo de rede num nó IoT pode ser necessária para se comunicar
através de um caminho não confiável. Isto resulta em mudanças frequentes de
topologia que, mesmo com uma pilha de IP completa, podem causar problemas.
o Finalmente, o consumo de energia impulsiona a seleção de tecnologias de rede.
o A experiência mostra que as pilhas de IP de produção funcionam bem em nós
restritos.
No entanto, a classificação desses nós ajuda na avaliação da adoção de IP versus
seleção do modelo de adaptação.
De acordo com [1], os nós restritos de IoT podem ser classificados como segue:
o Dispositivos que são muito limitados em recursos, podem se comunicar com pouca
frequência para transmitir alguns bytes e podem ter recursos limitados de segurança e
gestão: Isto leva à necessidade do modelo de adaptação de modelo de adaptação de
adaptação de IP, onde os nós se comunicam através de gateways e proxies.
o Dispositivos com energia e capacidades suficientes para implementar uma pilha IP
reduzida ou pilha não IP: pode-se implementar uma pilha IP otimizada e se comunicar
diretamente com os servidores de aplicações (modelo de adoção de modelo de
adoção) ou usar uma pilha não IP e se comunicar através de gateways e proxies
(modelo de adaptação modelo de adaptação).
 94

o Dispositivos que são semelhantes a PCs genéricos em termos de recursos de

computação e energia, mas têm capacidades de rede restritas, como largura de banda:
geralmente implementam uma pilha IP completa (modelo de adoção de modelo de
adoção), mas as restrições de largura de banda se aplicam.

 The need for optimization – Constrained Networks

o No início da Internet, as conexões geralmente dependiam de um modem de baixa
velocidade.
o Hoje temos infraestruturas de alta velocidade - fibra para casa!
o No entanto, essas altas velocidades não podem ser usadas por alguns dispositivos IoT
na última milha. Isso se deve à implementação de tecnologias com baixa largura de
banda, distância e largura de banda limitadas devido à potência de transmissão
regulada e falta ou limitação de serviços de rede.
Quando as caraterísticas da camada de link, geralmente tidas como certas, não estão
presentes, a rede é restringida. Uma rede restrita pode ter alta latência e alto potencial
para perda de pacotes.
o Observação Redes restritas são frequentemente chamadas de redes de baixa potência e
com perdas (LLNs).
o Perda, neste contexto, refere-se à falta de confiabilidade da rede causada por
interrupções no fluxo de dados ou perda de pacotes.
o Os LLNs foram definidos pelo grupo de trabalho do IETF Routing over Low-Power
and Lossy Networks (RoLL) ao desenvolver o protocolo RPL IPv6.
https://datatracker.ietf.org/wg/roll/documents/

Redes restritas têm caraterísticas e requisitos exclusivos:

o Redes restritas são limitadas por links de baixa potência e baixa largura de banda
(sem fio e com fio).
o Estes operam entre alguns kbps e algumas centenas de kbps.
o Não é incomum que a taxa de entrega de pacote (PDR) oscile entre percentagens
baixas e altas.
o Podem ocorrer grandes rajadas de erros imprevisíveis e, às vezes, até perda de
conectividade.
o Ambientes de camada de link instáveis criam outros desafios a nível de latência e
reatividade do plano de controlo. A regra de ouro é uma reação insuficiente ao
fracasso
o Control plane traffic também deve ser mínimo.
o Finalmente, o consumo de energia em nós alimentados por bateria precisa ser
considerado. Um protocolo de plano de controlo detalhado pode reduzir a vida útil
das baterias.

 The need for optimization – IP versions

o A transição de IPv4 para IPv6 ainda está em andamento.
o O PV6 tem uma gama de endereços muito maior do que o IPv4.
 95

o Hoje, as duas versões de IP são executadas pela Internet, mas a maior parte do
tráfego ainda é baseada em IPv4.
o A Internet das Coisas deve oferecer suporte às versões IPv4 e IPv6
simultaneamente, porque o suporte IPv4 é frequentemente necessário.
o Técnicas como encapsulamento e tradução precisam ser empregues (em soluções
de IoT) para garantir a interoperabilidade entre IPv4 e IPv6.
o Vários fatores determinam se IPv4, IPv6 ou ambos podem ser usados numa
solução de IoT.

 The need for optimization – IP versions: principais fatores aplicáveis ao suporte IPv4 e
IPv6 numa solução IoT
Protocolo de aplicação: os dispositivos IoT que implementam interfaces Ethernet ou Wi-
Fi podem se comunicar em IPv4 e IPv6, mas o protocolo de aplicação pode determinar a
escolha da versão IP.
o Os protocolos SCADA, como DNP3 / IP (IEEE 1815), Modbus TCP ou os padrões
IEC 60870-5-104, são especificados apenas para IPv4.
o Os dispositivos IoT com protocolos de aplicação definidos pelo IETF, como HTTP
/ HTTPS, CoAP, MQTT e XMPP, oferecem suporte a ambas as versões de IP.
A seleção da versão do IP depende apenas da implementação.
Provedor e tecnologia de celular: os dispositivos IoT com modems de celular dependem
da tecnologia de celular e dos serviços de dados oferecidos pelo provedor.
o Para GPRS, Edge e 3G, IPv4 é a versão do protocolo base.
o Se o IPv6 for usado com qualquer um dos itens acima, ele deve ser encapsulado em
IPv4.

o Em redes 4G / LTE, os serviços de dados podem usar IPv4 ou IPv6 como

protocolo base.
Comunicações em série: Muitos legacy devices comunicam-se através de linhas em série.
o Os dados são transferidos usando protocolos proprietários ou baseados em padrões,
como DNP3, Modbus ou IEC 60870-5-101.
o No passado, a comunicação desses dados em série em qualquer tipo de distância
podia ser tratada por uma conexão de modem analógico.
 96

o Hoje em dia, é necessário conectar a porta série do legacy device a uma porta série
próxima num equipamento de comunicação, normalmente um router.
o Este router local então encaminha o tráfego série sobre IP para o servidor central
para processamento. O encapsulamento de protocolos seriais sobre IP aproveita
mecanismos como socket bruto TCP ou UDP, disponíveis principalmente em IPv4.
Camada de adaptação IPv6: algumas camadas físicas e de link de dados para protocolos
IoT recentemente padronizados suportam apenas IPv6.
o As camadas físicas e de link de dados mais comuns (por exemplo, Ethernet e Wi-
Fi) definem camadas de adaptação para ambas as versões.
o As tecnologias mais recentes, como IEEE 802.15.4 (Wireless Personal Area
Network), IEEE 1901.2 e ITU G.9903 (Narrowband Power Line Communications)
têm apenas uma camada de adaptação IPv6 especificada.
o Qualquer dispositivo que implemente uma tecnologia que requeira uma camada de
adaptação IPv6 deve se comunicar em uma sub-rede somente IPv6.
o Isso é reforçado pelo protocolo de routing IETF para LLNs, RPL, que é apenas
IPv6.
Mecanismos de transição, como mapeamento de endereço e porta usando tradução
(MAP-T), permitem que o tráfego IPv4 seja encaminhado por uma rede IPv6. Para
obter mais informações, consulte IETF RFC 7599, em
https://tools.ietf.org/html/rfc7599.

Optimizing IP for IoT

Nós restritos e redes restritas exigem otimização em várias camadas e em vários protocolos
da arquitetura IP.

 Optimizing IP for IoT – From 6LoWPAN to 6Lo

o O modelo para empacotar IP em protocolos de camada inferior é frequentemente
referido como uma camada de adaptação.
o A menos que a tecnologia seja proprietária, as camadas de adaptação IP são
normalmente definidas por um grupo de trabalho da IETF e lançadas como RFC. Por
exemplo, RFC 2464 descreve como um pacote IPv6 é encapsulado num pacote de
frame Ethernet.
 97

o Os protocolos relacionados à IoT seguem um processo semelhante.

o Os principais exemplos de camadas de adaptação otimizadas para nós restritos ou
“things” são aqueles sob o grupo de trabalho 6LoWPAN e o seu sucessor, o grupo de
trabalho 6Lo.
o O foco inicial do grupo de trabalho 6LoWPAN era otimizar a transmissão de pacotes
IPv6 em redes restritas, como IEEE 802.15.4.
A Figura mostra um exemplo de uma pilha de protocolo IoT usando a camada de
adaptação 6LoWPAN ao lado da pilha de protocolo IP usual para referência.

o O grupo de trabalho 6LoWPAN na RFC 4944 define frame headers para os recursos
de compactação de header, fragmentação e endereçamento de mesh.
o Esses headers podem ser empilhados na camada de adaptação para manter esses
conceitos separados enquanto reforça um método estruturado para expressar cada
capacidade.
o Algumas pilhas de headers 6LoWPAN típicas:

 Optimizing IP for IoT – Header Compression

o 6oWPAN tira proveito de informações que podem ser inferidas do fato de que os nós
estão na mesma rede 6LoWPAN. O único campo no header IPv6 que sempre precisa
ser carregado por completo é o Hop Limit (8 bits).
o A vantagem da compressão do header é ilustrado (melhor caso) na figura:
 98

 Optimizing IP for IoT – Fragmentation

o A unidade máxima de transmissão (MTU) para uma rede IPv6 deve ser de pelo menos
1280 bytes, enquanto para IEEE 802.15.4, 127 bytes é o MTU.
o Consequentemente, grandes pacotes IPv6 devem ser fragmentados em vários
frames802.15.4 na camada 2.
o O header do fragmento utilizado por 6LoWPAN é composto por três campos
primários:
 Tamanho do Datagrama: tamanho total da carga não fragmentada
 Tag de datagrama: identifica o conjunto de fragmentos para uma payload
 Deslocamento do Datagrama: delinear o quão longe em uma payload ocorre um
fragmento específico (ausente no primeiro fragmento, porque seu valor é
conhecido como zero)
Lembre-se de que IEEE 802.15.4g-PHY tem payload de 2.047 bytes
Se o deslocamento/offset do datagrama for omitido, por que o tamanho do datagrama é
repetido em cada fragmento?

 Optimizing IP for IoT – Fragmentation Header

o O header de fragmentação 6LoWPAN usa um valor de bit exclusivo para identificar
que os campos subsequentes por trás dele são campos de fragmento.
o Como o campo Datagram Offset não está presente no primeiro fragmento, o headerde
uma carga IPv6 tem apenas 4 bytes. Os fragmentos subsequentes terão um campo de
header de 5 bytes (com o valor de deslocamento apropriado).
 99

 Optimizing IP for IoT – Mesh Addressing

o O objetivo da função de endereçamento de mesh 6LoWPAN é encaminhar pacotes em
vários saltos.
o Três campos: endereçamento em mesh (4 bits) e Limite de salto (4 bits), Endereço de
origem e Endereço de destino (ou seja, endereços IEEE 802.15.4 indicando os pontos
finais de um salto IP).
o O limite de salto é diminuído em um conforme o frame é encaminhado. Quando o
valor atinge 0, este é descartado e não é mais encaminhado (como em IPv4 e IPv6).

 Optimizing IP for IoT – Mesh Addressing: mesh under versus mesh-over routing
o Duas opções para estabelecer acessibilidade e encaminhar pacotes:
 mesh-under onde o routing de pacotes é tratado na camada de adaptação
6LoWPAN.
 mesh-over ou route-over, que utiliza o routing IP para levar os pacotes ao seu
destino.
o Quando mesh-under é usado, o routing de pacotes é tratado na camada de adaptação
6LoWPAN. Ele usa o header da mesh e os endereços de origem e destino: não precisa
descompactar o frame IPv6.
o Os nós têm uma tabela de encaminhamento da Camada 2 que eles consultam para
rotear os pacotes para seu destino final dentro da malha. Um border gateway termina
o domínio mesh-under.
o Quando o mesh-over é usado, todo o roteamento e encaminhamento de pacotes são
executados na camada de rede - usando, por exemplo, o protocolo de roteamento IPv6
para redes de baixa potência e perdas (RPL).
o O routing IP Layer 3 é utilizado dentro ou fora do domínio mesh. Cada nó em pleno
funcionamento atua como um router IP, de modo que cada salto da camada de link é
um salto IP.
o A camada de adaptação 6LoWPAN processa os fragmentos recebidos em cada salto
para remontar o pacote de dados IPv6 original e, em seguida, fragmentar novamente,
antes de encaminhar para o próximo salto - isso aumenta a latência de ponta a ponta.
 100

o Quando um LoWPAN foi implementado usando diferentes tecnologias de camada de

link, uma configuração de routing mesh-over é útil.
 Optimizing IP for IoT – Mesh Addressing: mesh-over routing
A camada de adaptação 6LoWPAN processa os fragmentos recebidos em cada salto para
remontar o pacote de dados IPv6 original e, em seguida, fragmentar novamente, antes de
encaminhar para o próximo salto - isso aumenta a latência de ponta a ponta.

 Optimizing IP for IoT – Mesh Addressing: From 6LoWPAN to 6Lo

o O grupo de trabalho 6LoWPAN foi concluído; foi focado em como otimizar a
transmissão de pacotes IPv6 em redes restritas, ou seja, IEEE 802.15.4.
o O trabalho do 6LoWPAN é agora expandido pelo 6Lo, grupo de trabalho,
denominado IPv6 sobre Redes de Nós Restritos por Recursos, com o objetivo de
facilitar a conectividade IPv6 sobre redes de nós Restritos.
6TiSCH
 IEEE 802.15.4e, Time-Slotted Channel Hopping (TSCH), é um add-on para a parte
Media Access Control (MAC) do padrão IEEE 802.15.4.
 Dispositivos que implementam IEEE 802.15.4e TSCH comunicam-se seguindo uma
programação de Acesso Múltiplo por Divisão de Tempo (TDMA).
 Uma alocação de uma unidade de largura de banda ou intervalo de tempo é programada
entre os nós vizinhos. Isto permite a programação de transmissões previsíveis e permite
aplicações determinísticas do tipo industrial.
 Para padronizar o IPv6 no modo TSCH do IEEE 802.15.4e (conhecido como 6TiSCH), o
IETF formou o grupo de trabalho 6TiSCH.
 Este grupo de trabalho trabalha na arquitetura, modelo de informação e configuração
mínima 6TiSCH.

 6TiSCH – 6top
o O grupo de trabalho 6TiSCH especificou 6top, uma subcamada que cola a camada
MAC e a camada de adaptação 6LoWPAN.

o 6top fornece comandos para protocolos das camadas superiores da rede, como RPL.
 101

o Estes comandos tornam possíveis algumas funcionalidades, incluindo decisões de

routing da camada de rede, configuração e procedimentos de controlo para gestão de
programação 6TiSCH.

 6TiSCH – Scheduling
o O padrão IEEE 802.15.4e define uma estrutura de intervalo de tempo, mas não exige
um algoritmo de escalonamento para como os intervalos de tempo são utilizados. Isso
é deixado para protocolos de nível superior como 6TiSCH.
o A programação é crítica porque pode afetar o rendimento, a latência e o consumo de
energia.
o Os programas em 6TiSCH são divididos em células.
o Os nós transmitem apenas quando a programação determina que a sua célula está
aberta para comunicação.
o A arquitetura 6TiSCH define quatro mecanismos de gestão de cronograma e três
modelos de encaminhamento (descritos a seguir).

 6TiSCH – Four schedule management mechanisms defined by the 6TiSCH architecture

o Static scheduling/Programação estática: todos os nós da rede restrita partilham uma
programação fixa. As células são partilhadas e os nós disputam o acesso ao slot de
uma forma slotted aloha. A desvantagem da programação estática é que os nós podem
esperar um pacote em qualquer célula da programação. Portanto, a energia é
desperdiçada ouvindo idly em todas as células.
o Neighbor-to-neighbor scheduling/Escalonamento vizinho a vizinho: Um cronograma
é estabelecido e correlaciona-se com o número observado de transmissões entre os
nós. As células nesta programação podem ser adicionadas ou excluídas conforme os
requisitos de tráfego e largura de banda mudam.
o Remote monitoring and scheduling management: os intervalos de tempo e outra
alocação de recursos são controlados por uma entidade de gestão que pode estar a
vários saltos de distância. O mecanismo de programação leverages 6top e até mesmo
CoAP em alguns cenários. Este mecanismo de agendamento fornece bastante
flexibilidade e controlo na alocação de células para comunicação entre os nós.
o Hop-by-hop scheduling/Programação salto a salto : um nó reserva um caminho para
um nó de destino a vários saltos, solicitando a alocação de células numa programação
em cada salto de nó intermediário no caminho.
 6TiSCH – Three 6TiSCH forwarding model
o Track Forwarding (TF): um caminho unidirecional entre uma origem e um destino.
Este é o modelo de encaminhamento mais simples e rápido. Esta trilha é construída
pelo emparelhamento de pacotes de células recetoras numa programação com um
pacote de células recetoras definidas para transmitir. Assim, um frame recebido
dentro de uma célula ou feixe de células específico é comutado para outra célula ou
feixe de células. Esse encaminhamento ocorre independentemente do protocolo da
camada de rede.
o Fragment forwarding/Encaminhamento de fragmento (FF): Com o FF, é definido um
mecanismo onde o primeiro fragmento é encaminhado com base no header IPv6
presente.
 102

 A subcamada 6LoWPAN aprende a seleção do próximo salto deste primeiro

fragmento, que é então aplicada a todos os fragmentos subsequentes desse pacote.
 Caso contrário, os pacotes IPv6 serão remontados salto a salto. Isto aumenta a
latência e pode consumir muita energia e CPU para um nó restrito.
o IPv6 Forwarding/Encaminhamento IPv6 (6F): encaminha o tráfego com base na sua
tabela de routing IPv6. Os fluxos de pacotes devem ser priorizados pelas operações
tradicionais de QoS (quality of service) e RED (random early detection).
o Para muitas redes wireless IoT, não é necessário controlar a latência e a taxa de
transferência dos dados do sensor. No entanto, quando algum tipo de determinismo é
necessário, 6TiSCH fornece uma solução padrão aberta baseada em IPv6 para garantir
comunicações previsíveis em redes de sensores wireless.
RPL
 RPL – IETF RoLL Wroking Group
o O grupo de trabalho IETF RoLL (Routing em Redes de Baixa Potência e Perdas) foi
criado para determinar as necessidades e requisitos para o desenvolvimento de uma
solução de routing IP Camada 3 para objetos IP inteligentes.
o Após o estudo de vários casos de uso e protocolos existentes, concluiu-se que um
novo protocolo de routing era necessário para objetos inteligentes IP, dadas as
caraterísticas e requisitos das redes restritas.
o O novo protocolo de routing de vetor de distância foi denominado Protocolo de
Routing IPv6 para Redes de Baixa Potência e Perdas (RPL) - RFC 6550.
o O Grupo de Trabalho continua a concentrar-se em questões de routing para LLN e
manter, melhorar e agilizar os protocolos já desenvolvidos, incluindo RPL e MPL. O
foco está apenas no trabalho IPv6.
 RPL – The RPL protocol
o Numa rede RPL, cada nó atua como um router e torna-se parte de uma rede mesh.
o O routing é executado na camada IP. O destino do próximo salto é obtido com base
nas informações contidas no header IPv6; nenhuma informação do header da camada
MAC é usada. Deve ser capaz de responder: Este é um routing mesh-under ou mesh-
over?
o O protocolo define dois modos:
 Modo de armazenamento: Todos os nós contêm a tabela de routing completa do
domínio RPL. Cada nó sabe como alcançar diretamente todos os outros nós.
 Modo de não armazenamento: Apenas o(s) border router(es) do domínio RPL
contém (m) a tabela de routing completa. Todos os outros nós no domínio
mantêm apenas sua lista de pais e usam-na como uma lista de rotas padrão em
direção ao router de fronteira. Isto economiza espaço de memória e CPU.
 RPL – RLP and DOAGs
o Um gráfico acíclico direcionado (DAG) é um gráfico onde não existem ciclos.
o Um DAG orientado ao destino (DODAG) é um DAG enraizado num destino.
o Um processo RPL básico envolve a construção de um DODAG, onde o destino é um
border router conhecido como raiz DODAG.
 103

A figura ilustra as diferenças entre um DAG e um DODAG.

o Num DODAG, cada nó mantém até três pais que fornecem um caminho para a raiz.
Um desses pais é o pai preferido, definindo o caminho para a raiz.
o A implementação do protocolo RPL deve garantir que as rotas estejam livres de loop.
o As rotas ascendentes no RPL são descobertas e configuradas usando mensagens DAG
Information Object (DIO) - essas mensagens determinam os pais e o melhor caminho
para a raiz DODAG.
o Os nós estabelecem rotas descendentes anunciando o seu conjunto pai em direção à
raiz DODAG usando uma mensagem de objeto de anúncio de destino (DAO).
o As mensagens DAO permitem que os nós informem os seus pais da sua presença e
acessibilidade aos descendentes.
o No modo de não armazenamento de RPL (totalmente roteado pela fonte), os nós que
enviam mensagens DAO relatam os seus conjuntos pai diretamente para a raiz
DODAG (border router) e apenas a raiz armazena as informações de routing.
 Com essas informações, a raiz pode determinar as rotas de origem necessárias
para entregar datagramas IPv6 para nós individuais a jusante na mesh.
o Para o modo de armazenamento (totalmente com estado), cada nó mantém o controlo
das informações de routing que são anunciadas nas mensagens DAO.
 Contras: isto consome mais energia e uso da CPU para cada nó;
 Prós: os pacotes podem seguir caminhos mais curtos entre destinos na mesh.
o No modo de armazenamento, os nós podem tomar as suas próprias decisões de
routing; no modo de não armazenamento, todos os pacotes devem ir até a raiz para
obter uma rota para mover para baixo.

 RPL – RPL messages

o Mensagens RPL, como DIO e DAO, são executadas no IPv6.
o Estas mensagens trocam e anunciam informações de routing downstream e upstream
entre um router de fronteira e os nós abaixo dele.
 104

 RPL – Objective Function

o Uma Função Objetivo (OF) define como as métricas são usadas para selecionar rotas
e calcular a classificação do nó. Um OF não é um algoritmo (conforme declarado no
RFC 6719).
o Padrões foram publicados para documentar OFs específicos para certos casos de uso e
tipos de nós:
 RFC 6552
 RFC 6719
 RPL – Node rank
o A classificação é uma aproximação de quão “perto” um nó está da raiz e ajuda a evitar
loops de routing e o problema da contagem até o infinito.
o Os nós só podem aumentar a sua classificação ao receber uma mensagem DIO com
um número de versão maior (o que significa que o DODAG mudou).
o No entanto, os nós podem diminuir a sua classificação sempre que estabelecerem
rotas de custo mais baixo.
o Embora a classificação e as métricas de routing estejam intimamente relacionadas, a
classificação difere das métricas de routing por ser usada como uma restrição para
evitar loops de routing.
 RPL – RPL headers
Header de camada de rede específicos são definidos para datagramas sendo
encaminhados dentro de um domínio RPL:
o RFC 6553 define uma nova opção IPv6, conhecida como opção RPL. A opção RPL é
transportada no header IPv6 Hop-by-Hop. O objetivo deste header é to leverage
pacotes de plano de dados para deteção de loop numa instância RPL. DODAGs têm
apenas caminhos únicos e devem ser livres de loop.
o RFC 6554 especifica o Source Routing Header (SRH) para uso entre routers RPL. Um
border router ou raiz DODAG insere o SRH ao especificar uma rota de origem para
entregar datagramas aos nós a jusante na rede mesh.

 RPL – Metrics for routing in networks with batery-operated nodes

RFC 6551: define um conjunto de novas métricas e restrições para routing:
o Expected Transmission Count (ETX): Atribui um valor discreto ao número de
transmissões que um nó espera fazer para entregar um pacote.
o Contagem de saltos: rastreia o número de nós percorridos num caminho.
o Latência: caminhos com latência mais baixa são preferidos.
 105

o Nível de qualidade do link: mede a confiabilidade de um link levando em

consideração as taxas de erro de pacote causadas por fatores como atenuação de sinal
e interferência.
o Cor do link: Permite a influência manual do routing
o Estado e atributo do nó: identifica os nós que funcionam como agregadores de tráfego
e os nós que estão sendo impactados por altas cargas de trabalho.
o Energia do nó: evita nós com baixa potência
o Taxa de transferência: fornece a quantidade de taxa de transferência para um link de
nó. Essa métrica permite a priorização de caminhos com maior rendimento.
RPL and IPv6
 A integração RPL num domínio de routing segue as mesmas regras dos protocolos de
routing IP mais tradicionais:
o Redistribuição de rota, filtragem, balanceamento de carga e reencaminhamento
dinâmico podem ser implementados da mesma maneira que outros protocolos
conhecidos.
o Por exemplo, em routers IoT, podemos encontrar rotas aprendidas via RPL sendo
redistribuídas em protocolos de routing mais conhecidos, como BGP e EIGRP.
RPL – Summary
 RPL é um novo protocolo de routing que permite que uma solução baseada em padrões
IPv6 seja deployed em grande escala (os LLNs são compostos de algumas dezenas a
milhares de routers).
 O RPL foi projetado para atender aos requisitos de nós e redes restritos.
 O RPL tem se vindo a tornar um dos principais protocolos de routing baseados em IPv6
da camada de rede em redes de sensores IoT.
Authentication and Encryption on Constrained Nodes
 Authentication and Encryption on Constrained Nodes – Authentication and
Authorization for Constrained Environments (ACE)
Os grupos de trabalho ACE e DICE da IETF, com foco na segurança da IoT, são
mencionados.
o A tarefa do grupo de trabalho de autenticação e autorização para ambientes restritos
(ACE) é: avaliar a aplicabilidade dos protocolos de autenticação e autorização
existentes e documentar sua adequação para determinados casos de uso de ambiente
restrito.
o O ACE tem trabalhado numa solução padronizada para autenticação e autorização,
permitindo acesso autorizado (Get, Put, Post, Delete) a recursos identificados por um
URI e hospedados num servidor de recursos em ambientes restritos.
Um servidor de autorização irrestrito executa a mediação do acesso.
 Authentication and Encryption on Constrained Nodes – DTLS In Constrained
Environments (DICE)
Segurança de camada de transporte de datagrama (DTLS) em ambientes restritos -
(DICE):
 106

o Espera-se que novas gerações de nós restritos que implementam uma pilha IP em
redes de acesso restrito executem uma pilha de protocolo IP otimizada.
o Em ambientes restritos protegidos por DTLS, o Constrained Application Protocol
(CoAP) pode ser usado para controlar recursos num dispositivo.
o O grupo de trabalho DTLS concentra-se no grupo de trabalho DTLS na
implementação do protocolo de segurança da camada de transporte DTLS nesses
ambientes. Tarefas:
 para definir um perfil DTLS otimizado para nós restritos;
 considere a aplicabilidade da camada de registo DTLS para proteger mensagens
multicast;
 investigue como o handshake DTLS em ambientes restritos pode ser otimizado.
Profiles and Compliances
 Deploying do pacote de protocolos da Internet para objetos inteligentes requer vários
protocolos e opções que devem ser coordenados com as camadas inferior e superior.
 Portanto, as definições de perfil, certificações e promoção por alianças podem ajudar os
implementadores a desenvolver soluções que garantam a interoperabilidade e/ou
intercambialidade dos dispositivos.
 A seguir, é apresentada uma lista de algumas das principais organizações do setor que
trabalham em definições e certificações de perfil para redes e nós restritos de IoT e os
seus objetivos são destacados.

 Profiles and Compliances – Internet Protocol for Smart Objects (IPSO) Alliance
o Aliança do Protocolo da Internet para Objetos Inteligentes (IPSO) (2008–) A aliança
inicialmente focou na promoção do IP como a solução principal para comunicações
de objetos inteligentes. Atualmente, está mais focado em como usar o IP, com a IPSO
Alliance organizando testes de interoperabilidade entre os membros da aliança para
validar que o IP para objetos inteligentes pode funcionar em conjunto e implementar
adequadamente os padrões da indústria.
Como a IPSO Alliance deseja garantir que “os engenheiros e criadores de produtos
terão acesso às ferramentas necessárias para construir a IoT CERTA”.
 Profiles and Compliances – Wi-SUN Alliance
o A Wi-SUN Alliance (com base na indústria) esforçou-se para definir um perfil de
comunicação que se aplica a protocolos específicos da camada física e de link.
o Atualmente, o Wi-SUN está focado no protocolo IEEE 802.15.4g e seu suporte para
multisserviços e comunicações IPv6 seguras com aplicações executadas na camada de
transporte UDP.
o O setor de serviços públicos é a principal área de foco da Wi-SUN Alliance. O perfil
de rede de área de campo (FAN) Wi-SUN permite que redes de serviços públicos
inteligentes forneçam conectividade resiliente, segura e económica com cobertura
extremamente boa numa variedade de ambientes topográficos, de bairros urbanos
densos a áreas rurais.
 Profiles and Compliances – Thread Group
 107

o O Thread Group (com base na indústria) definiu um perfil wireless baseado em IPv6
que fornece a melhor maneira de conectar mais de 250 dispositivos numa rede mesh
wireless de baixo consumo de energia.
o A tecnologia sem fio usada pelo Thread é IEEE 802.15.4, que é diferente do IEEE
802.15.4g do Wi-SUN.
 Profiles and Compliances – IPv6 Ready Logo
o Inicialmente, o Fórum IPv6 garantiu a promoção do IPv6 em todo o mundo.
o Uma vez que as implementações IPv6 se tornaram amplamente disponíveis, a
necessidade de interoperabilidade e certificação levou à criação do programa IPv6
Ready Logo.
 O programa IPv6 Ready Logo estabeleceu programas de teste de conformidade e
interoperabilidade com a intenção de aumentar a confiança do utilizador ao
implementar o IPv6. O IPv6 Core e os componentes IPv6 específicos, como
DHCP, IPsec e certificações de border router do cliente, foram produzidos.
 Essas certificações são reconhecidas em todo o setor e muitos produtos já são
certificados.
 Um esforço de certificação IPv6 específico para IoT está atualmente em definição
para o programa.
Summary
 O conjunto de protocolos IP foi implantado em redes privadas e públicas nos últimos 30
anos, interconectando billion de dispositivos IP e utilizadores.
 A arquitetura provou ser altamente flexível. Por exemplo, novos tipos de link foram
adaptados, novos protocolos de routing e transporte foram especificados e deployed e o
número de aplicações suportadas excedeu todas as expectativas.
 A grande maioria dos protocolos e tecnologias IP podem ser reutilizados como estão
pelas soluções IoT.
 Onde o IP pode falhar é em cenários onde os dispositivos IoT são nós restritos e/ou se
conectam a redes restritas.
o Para superar esses cenários, o IETF busca otimizar o IP para IoT e comunicações de
objetos inteligentes.
o Os grupos de trabalho da IETF tiveram que desenvolver novos protocolos (por
exemplo, RPL) ou camadas de adaptação (por exemplo, 6LoWPAN).
 A base para a camada de rede nas implementações de IoT está firmemente estabelecida.
 A IETF e outros órgãos de padronização continuam a trabalhar na definição de redes,
protocolos e casos de uso necessários para o avanço da Internet das Coisas.
Aula 7 – Protocolos de aplicação para IoT
 108

IoT Protocol Stack

The Transport Layer

Com o protocolo TCP/IP, dois protocolos principais são especificados para a camada de
transporte:
 Protocolo de controlo de transmissão (TCP): Este protocolo orientado a conexão requer
que uma sessão seja estabelecida entre a origem e o destino antes de trocar dados. É
como um equivalente a uma conversa telefónica tradicional, na qual dois telefones
devem ser conectados e o link de comunicação estabelecido antes que as partes possam
falar.
 User Datagram Protocol (UDP): Com este protocolo sem conexão, os dados podem ser
enviados rapidamente entre a origem e o destino - mas sem garantia de entrega. Isso é
análogo ao sistema de entrega de correio tradicional, no qual uma carta é enviada a um
 109

destino. A confirmação do recebimento desta carta não acontece até que outra carta seja
enviada em resposta.
Métodos de transporte de aplicações IoT
Podemos categorizar os protocolos de aplicação IoT comuns como:
 Protocolo da camada de aplicação não presente: neste caso, a payload de dados é
transportada diretamente no topo das camadas inferiores. Nenhum protocolo de camada
de aplicação é usado.
 Controlo de supervisão e aquisição de dados (SCADA): o SCADA é um dos protocolos
industriais mais comuns no mundo, mas foi desenvolvido muito antes dos dias do IP e foi
adaptado para redes IP.
 Protocolos genéricos baseados na web: protocolos projetados para a web usando
protocolos físicos comumente disponíveis, como Ethernet, Wi-Fi e 4G / LTE, são
encontrados em muitos dispositivos IoT de classe empresarial e de consumidor que se
comunicam em redes não restritas.
 Protocolos da camada de aplicação IoT: os protocolos da camada de aplicação IoT são
concebidos para rodar em nós restritos com uma pequena footprint de computação e são
bem adaptados às restrições de largura de banda de rede em links de celular ou satélite ou
redes LPWAN restritas (6LoWPAN e LoRaWAN por exemplo). O Message Queuing
Telemetry Transport (MQTT) e Constrained Application Protocol (CoAP) são dois
exemplos bem conhecidos de protocolos de camada de aplicação IoT.
Definição : Protocolo
Protocolo: Um conjunto formal de regras que dita como a troca de informações, bem como a
interação entre os objetos (podem ser dispositivos, threads de execução, etc.) devem ocorrer.
As regras especificam:
 O formato das mensagens trocadas;
 Vários estados de protocolo diferentes e quais mensagens podem ser enviadas em cada
estado; esses estados determinam, entre outros, a ordem das mensagens.
 Restrições de tempo e outras propriedades de qualidade, se houver.
Observação:
 'mensagem' inclui chamada de função
 pode-se especificar um protocolo sem ser explícito sobre o serviço geral que ele realiza
Exemplos: HTTP, TCP, UDP, SOAP, DNS

Protocolos de aplicação IoT

 110

Métodos de transporte de aplicação IoT

Pilha/stack de protocolo IoT - Avoiding Overheads

Arquitetura típica de rede IoT

 111

Padrões de integração de dados IoT

IoT Cloud Integration Patterns

Dependendo do contexto da aplicação, diferentes abordagens podem ser estabelecidas para
integração de dados na cloud. Normalmente, as coisas têm acesso à cloud e precisam de um
suporte de cloud poderoso e escalonável. Este é o padrão de integração na cloud.

Padrão de Integração Direta

 112

Algumas coisas têm acesso total à Internet. Essas coisas podem fornecer um servidor HTTP
rodando sobre TCP / IP e podem se conectar diretamente à Internet. Estes podem ser usados
para implementar um padrão de integração direta - REST nos dispositivos.

 Caso de uso típico: a Thing não funciona com bateria e comunica-se com baixa latência
com um dispositivo local como um telefone.
 Exemplo: use um telefone para se comunicar via WiFi (com router WiFi) para um
servidor HTTP em um dispositivo. Use sockets da web para publicar/subscrever, por
exemplo, escuta de telefone para eventos de campainha.
Padrão de integração de gateway
Algumas coisas podem não ter acesso total à Internet. Essas coisas podem suportar apenas
Zigbee ou Bluetooth ou outras especificações baseadas em IEEE 802.15.4. Suponha que não
possamos enviar pacotes IP para o dispositivo - ele é restrito. Este é o padrão de integração
do gateway.

Padrão de Integração da Cloud

Algumas coisas têm acesso à cloud e precisam de um suporte de nuvem poderoso e
escalonável. Este é o padrão de integração na cloud. O Particle Photon, por exemplo, pode
enviar notificações de eventos para a cloud de partículas. A cloud de partículas fornece
publish/subscribe usando web hooks.

Protocolos de camada de aplicação IoT

 113

Protocolos de camada de aplicação mais populares usados hoje em dia:

 CoAP: Constrained Application Protocol/ Protocolo de Aplicação Restrito
 MQTT: Message Queuing Telemetry Transport/Transporte de telemetria de filas de
mensagens
 XMPP: Extensible Messaging and Presence Protocol/Protocolo Extensível de Mensagens
e Presença
 AMQP: Advanced Message Queuing Protocol/Protocolo de filas de Mensagens
Avançado
 WebSocket: Computer Communications Protocol/Protocolo de Comunicações de
Computador
 Alljoyn: Pilha completa de protocolos destinados à IoT. Protocolo de camada de
aplicação não separável

Como funciona a Web?

Os recursos na Web são:
 Geridos por servidores
 Identificados por URIs
 Acedido de forma síncrona por clientes através de paradigmas de request/response
Numa palavra, Representational State Transfer (REST)
 114

An HTTP Request

Protocolo HTTP
HTTP é a abreviatura de Hypertext Transfer Protocol, que consiste num protocolo da camada
de transporte confiável para transferência de dados de host para host. O HTTP está localizado
na camada de aplicação do modelo OSI. Considerando os diferentes usos, o HTTP pode usar
o protocolo TCP para um transporte de dados confiável, bem como o UDP para um transporte
não confiável.
 115

HTTP - História
 HTTP / 0.9 foi o primeiro protocolo HTTP e era muito simples, com apenas um método:
GET. O método pode solicitar uma página do servidor e a resposta sempre é uma página
HTML.
 HTTP / 1.0 funcionou como uma extensão de HTTP / 0.9. Este expandiu o protocolo
adicionando operações estendidas, negociação estendida, meta-informações mais ricas,
vinculadas a um protocolo de segurança. Este ficou mais eficiente ao adicionar métodos
adicionais e campos de header. Mas ainda usava uma conexão separada com o mesmo
servidor para cada transação de request-response.
 O HTTP / 1.1 pode reutilizar uma conexão várias vezes, por exemplo, para fazer o
download de imagens ou documentos para uma página recém-entregue.
Consequentemente, as comunicações HTTP / 1.1 apresentam menos latência, pois o
estabelecimento de conexões TCP apresenta um overhead considerável.
HTTP/TCP Connection Overhead
 116

HTTP Session
Normalmente, o HTTP funciona como um modelo de request-response, ou seja, um modelo
ClientServer.
Os clientes, normalmente Web Browsers, podem emitir um Request usando URLs (Uniform
Resources Locator) ou URIs (Uniform Resources Identifier) e enviá-lo ao Servidor, que
recebe o Pedido, descodifica-o e fornece os documentos / funções solicitadas.

URI = scheme:[//authority]path[?query][#fragment]
Existem vários tipos de recursos que o Server pode transportar, como documentos, imagens e
agora até vídeo e áudio, no padrão HTML5 mais recente.
URI

Scheme: o protocolo que você está a usar

Host: nome do host ou número IP
Porto: número do porto TCP que o servidor de protocolo está a usar
Caminho: caminho e referência de nome de ficheiro do objeto no servidor
Parâmetros: quaisquer parâmetros específicos de que o objeto precisa
Consulta: string de consulta para um programa CGI
Fragmento: referência a um subconjunto de um objeto
URI – Exemplos
 117

HTTP Request/Solicitação
 Uma linha de request: método + URL + versão do protocolo (por exemplo: GET
www.fit.edu HTTP / 1.1)
 Solicitar campo de header
 Corpo do request

HTTP Request Methods

Request Headers
 118

HTTP Response
 Uma linha de resposta: versão do protocolo + código de status + significado do
código. (Por exemplo: HTTP / 1.1 200 OK)
 Campo de header de resposta
 Corpo de resposta
Código de status de resposta

Response Headers

REST
 119

O termo transferência de estado representacional (REST) foi introduzido e definido em 2000

por Roy Fielding na sua tese de doutorado.
O termo tem a intenção de evocar uma imagem de como uma aplicação da Web bem
projetada se comporta:
É uma rede de recursos da Web onde o utilizador avança através da aplicação selecionando
links, como / user / tom, e operações como GET ou DELETE, resultando no próximo recurso
(representando o próximo estado da aplicação) sendo transferido para o utilizador para seu
uso.
Princípios de design da API REST

A REST style request in WoT

 Ainda é melhor usar um formato de mensagem padrão (representações) para valores de

retorno.
 Passa mais tempo projetando o formato do valor de retorno.
HTTP: RESTful
Um request é enviado a um servidor via URL

A resposta geralmente é um texto em HTML, XML ou JSON

 120

Ótimo se está pedindo algo

Que tal “push”
Por exemplo. O servidor quer dizer ao dispositivo para fazer algo
JavaScript Object Notation
O que é JSON?
JSON é um formato de troca de dados de texto leve
JSON é independente de linguagem *
JSON é "autodescritivo" e fácil de entender
* JSON usa sintaxe JavaScript para descrever objetos de dados, mas JSON ainda é
independente de linguagem e plataforma. Existem analisadores JSON e bibliotecas
JSON para muitas linguagens de programação diferentes.
JSON - avalia para objetos JavaScript
O formato de texto JSON é sintaticamente idêntico ao código para criar objetos
JavaScript.
Por causa desta semelhança, em vez de usar um analisador, um programa JavaScript
pode usar a função eval () integrada e executar dados JSON para produzir objetos
JavaScript nativos.
Exemplo JSON

JSON vs XML size

XML: 549 caracteres, 549 bytes
JSON: 326 caracteres, 326 bytes
XML ~ 68,4% maior que JSON!
 121

Mas um grande conjunto de dados será grande, independentemente do formato de

dados que for usado.
A maioria dos servidores gzip ou compactam o conteúdo antes de enviá-lo, a
diferença entre JSON gzipado e XML gzipado não é tão drástica quanto a diferença
entre JSON e XML padrão.
A REST Request

Constrained Application Protocol (CoAP)

Objetivo: habilitar serviços baseados na web em redes wireless restritas
 Microcontroladores de 8 bits
 memória limitada
 redes de baixo consumo
Problema: as soluções WEB dificilmente são aplicáveis
Solução: redesenhar serviços baseados na web para redes restritas -> COAP
Arquitetura CoAP

CoAP features
 Protocolo de transferência da web incorporado (coap: //)
 Modelo de transação assíncrona
 Ligação UDP com confiabilidade e suporte multicast
 Métodos GET, POST, PUT, DELETE
 Suporte URI
 122

 Header de 4 bytes
 Subconjunto de tipos MIME e códigos de resposta HTTP
 Descoberta integrada
 Observação opcional e transferência de bloco
COAP Messaging Basics
Transporte:
 (principalmente) ligação UDP
Troca de mensagens entre endpoints:
 Mensagens com header de 4 bytes (partilhado por request e responses) contendo um
ID de mensagem (16 bits)
 Troca confiável através de mensagens confirmadas que devem ser reconhecidas
(através de ACK ou mensagens de reset).
 Retransmissão Stop-and-Wait simples com backoff exponencial.
 Troca não confiável através de mensagem não confirmada
 Deteção de duplicados para mensagens confirmadas e não confirmadas (através do ID
de mensagem)

COAP Message Semantics

Request/Response REST incorporada em mensagens CoAP
Método, código de resposta e opções (URI, tipo de conteúdo etc.)

COAP Request/Response Examples

 123

CoAP Message Header (4 bytes)

Option Format

Dealing with Packet Loss

Abordagem Stop and Wait:
Repetir um request após um tempo limite caso o ACK (ou RST) não volte
 124

COAP: Separate Response

CoAP é:
 Um protocolo RESTful muito eficiente
 Ideal para dispositivos e redes restritos
 Especializado para aplicações M2M
 Fácil de proxy de / para HTTP
CoAP não é:
 Um substituto geral para HTTP
 compressão HTTP
 Restrito a redes isoladas de "automação"

Protocolos de aplicação IoT

 125

MQTT
 Introduzido pela IBM em 1999
 Padronizado por OASIS (2013)
 Usa mecanismo de Publish/Subscriber controlado por um Broker
 Broker
o Componente de software
o Responsável por distribuir mensagens de Publishers para Subscribers
interessados
 Versões MQTT
o MQTT-SN
o S-MQTT

Detalhes do componente MQTT

 Relacionamento Sub para Pub de muitos para muitos
 Um broker para cada sistema
 Subs autenticados ao broker
 Os subs/pubs podem ser muito restritos
 Pub pode ser apenas um sensor
 O broker deve fornecer mais poder computacional

MQTT
 126

Os pacotes de controlo MQTT são executados num transporte TCP usando o porto 1883. O
TCP garante um fluxo ordenado e sem perdas de bytes entre o cliente MQTT e o servidor
MQTT.
Opcionalmente, MQTT pode ser protegido usando TLS no porto 8883 e WebSocket (definido
em RFC 6455) também pode ser usado.
MQTT é um protocolo leve porque cada pacote de controlo consiste num header fixo de 2
bytes com campos de header variáveis opcionais e payload opcional. De notar que um pacote
de controlo pode conter uma payload de até 256 MB.

Tipos de mensagens MQTT

Padrão de comunicação – MQTT

 Paradigma Publish/Subscribe
 Os clientes não se conhecem
 Paradigma um-para-muitos
 Cada cliente publishes & subscribes
 Paradigma de informação PUSH comparado ao PULL no COAP
 127

Canais em MQTT
Um intermediário de mensagem usa uma sequência de tópicos ou nome de tópico para filtrar
mensagens para os seus subscribers.
Ao assinar um recurso, o subscriber indica um ou mais níveis de tópico que são usados para
estruturar o nome do tópico. A barra (/) num nome de tópico MQTT é usada para separar
cada nível na árvore de tópicos e fornecer uma estrutura hierárquica para os nomes de
tópicos.
Exemplo: adt/lora/adeunis sendo um nível de tópico e adt/lora/adeunis/0018B2000000023A
sendo um exemplo de um nome de tópico
Canais / tópicos em MQTT funcionam como caminhos de ficheiros

Ao subscrever num canal, tem que especificar todo o caminho, ou utilizar caracterer wild-
card + ou #
Canais em MQTT - Wildcards

Controlo de acesso
 O que? Restrições para fazer cumprir as políticas
 Efeito: Permissão / negação de acesso a um recurso específico
 128

Política de controlo de acesso

 Conjunto de regras que permitem/negam acesso
 Regras dependem de atributos
 O controlo de acesso avalia os atributos apenas uma vez no momento do request

Arquitetura MQTT

MQTT - Summary
 129

MQTT é um protocolo de transporte de mensagens de publish/subscribe do Client Server.

Features:
 Simples de implementar (especialmente no lado do sensor)
 Suporte QoS
 Leve e eficiente em largura de banda
 Dados agnósticos
 Conscientização da section
Brokers list:
 Mosquitto
 HiveMQ
HTTP: RESTful Hypothetical Light Switch

MQTT Hypothetical Light Switch

Aula 8 – Development Tools for IoT

 130

REST
Significa Representational State Transfer/Transferência de Estado Representacional
Tem as seguintes restrições:
 Client-Server
 Sem estado
 Cacheable
 Sistema em camadas
 Código sob demanda
 Interface Uniforme

REST na web
Cada tipo de recurso que deseja está num URI diferente
Interage com recursos usando os HTTP verbs
 PUT (Create)
 GET (Read)
 POST (Update)
 DELETE (Delete)
O servidor não controla o estado (exceto para autenticação)
O cliente gere a lógica da aplicação.
Exemplos REST

Node.js
Node.js é um ambiente de tempo de execução JavaScript de código aberto/open-source,
multiplataforma/cross-platform e back-end que corre no mecanismo V8 e executa o código
JavaScript fora de um navegador da web.
O que é Node.js?
 JavaScript é uma linguagem glue para módulos C ++
 131

 Esta é alimentada pelo mecanismo V8 JavaScript da Google

 O Node.js usa um modelo de I/O non-blocking e orientado por eventos
 Node.js é como um navegador da web com um conjunto diferente de módulos C ++
 Este fornece módulos para interagir com recursos do sistema local, como processos,
sistema de ficheiros, rede, etc ...
Node.js vs Web Browser

Gerir Pacotes com NPM

 NodeJS é apenas um interpretador de JavaScript.
 Este vem com um gestor de pacotes chamado npm (Node.js Package Manager)
 O NPM fornece um repositório público de pacotes, uma especificação para construir
pacotes e uma ferramenta de linha de comando para trabalhar com pacotes
 Para usar o Node como um servidor da web, é necessário escrever uma aplicação que
responda aos requests da web.
 O Node tem uma biblioteca (HTTP) para fazer isso, mas é mais fácil usar um
framework, como o Express
 Para aceder uma biblioteca, usar a função require ()
Pacotes locais vs. globais
 Os pacotes podem ser instalados local ou globalmente
 Os pacotes locais são armazenados localmente num projeto, na pasta node_modules
 Pacotes globais são armazenados globalmente no sistema
 Normalmente, os pacotes locais são bibliotecas de código usadas pelo projeto
 Normalmente, os pacotes globais são executáveis usados para realizar algumas
operações num projeto, como a execução de tarefas
 Os pacotes locais estão disponíveis apenas nos seus projetos específicos, e os pacotes
globais estão disponíveis em todo o sistema
Construir um Servidor Web Simples
 Um dos módulos principais para Node.js é o módulo HTTP, que fornece um servidor
web e um cliente web
 O servidor da web é muito flexível, mas requer muita codificação padrão para
construir até mesmo as aplicações mais simples
 Normalmente, outros pacotes como Express ou Hapi são usados para configurar o
servidor web
 132

 Os servidores Web são aplicações de I/O intensivos, tornando-os adequados para

Node.js
 Node.js é ótimo para servidores da web por causa de sua fácil manipulação de dados
JSON
Conclusão
 Node.js é uma ótima aplicação de construção de plataforma, especialmente aplicações
que exigem muito I / O
 Trabalhar com Node.js envolve muitas ferramentas para gerir pacotes, código de
debug e projetos de empacotamento para deployment
 O Node Package Manager (NPM) é usado para instalar pacotes e dividir aplicações
em partes menores reutilizáveis
 Node.js pode ser usado para ferramentas de desenvolvimento, aplicações da web e
aplicações de uso geral
O que é TypeScript?
 Digitação estática
 Classes e interfaces
 Módulos
 Compila para JavaScript
Benefícios do TypeScript
 Reduz erros de digitação
 Reduz erros de refatoração/refactoring
Aula 9 – Instrodução à computação na Cloud
O que é Cloud Computing?
Cloud Computing é um termo geral usado para descrever uma nova classe de computação
baseada em rede que ocorre na Internet,
 Basicamente, uma etapa a partir de Utility Computing
 Uma coleção/grupo de hardware, software e infraestrutura de Internet integrados e em
rede (chamados de plataforma).
 Usar a Internet para comunicação e transporte fornece hardware, software e serviços
de rede aos clientes
Essas plataformas ocultam a complexidade e os detalhes da infraestrutura subjacente de
utilizadores e aplicações, fornecendo uma interface gráfica muito simples ou API (Interface
de Programação de Aplicações).
A computação na cloud é um modelo para permitir acesso à rede conveniente e sob demanda
a um pool partilhado de recursos de computação configuráveis (por exemplo, redes,
servidores, armazenamento, aplicações e serviços) [Mell_2009], [Berkely_2009].
Pode ser provisionado e lançado rapidamente com o mínimo de esforço de gestão.
Fornece abstração de alto nível de modelo de computação e armazenamento.
 133

Tem algumas caraterísticas essenciais, modelos de serviço e modelos de deployment.

Além disso, a plataforma oferece serviços sob demanda, sempre disponíveis, em qualquer
lugar, a qualquer hora e em qualquer lugar.
Pague pelo uso e conforme necessário, escala elástica para cima e para baixo em capacidade e
funcionalidades.
Os serviços de hardware e software estão disponíveis para o público em geral, empresas,
corporações e mercados comerciais.
Caraterísticas essenciais
 On-Demand Self Service: Um consumidor pode fornecer recursos de computação
unilateralmente, automaticamente, sem a necessidade de interação humana com o
provedor de cada serviço.
 Heterogeneous Access: Os recursos estão disponíveis na rede e são acedidos através
de mecanismos padrão que promovem o uso por plataformas heterogéneas de thin ou
thick client.
 Resource Pooling/agrupamento: os recursos de computação do provedor são
agrupados para atender a vários consumidores usando um modelo multilocatário.
Diferentes recursos físicos e virtuais são atribuídos dinamicamente e reatribuídos de
acordo com a demanda do consumidor.
 Measured Service: os sistemas na cloud controlam e otimizam automaticamente os
recursos usados, leveraging uma capacidade de medição nalgum nível de abstração
apropriado para o tipo de serviço.
Fornecerá uma plataforma de computação previsível e analisável.

Modelos de serviço
 134

Modelos de serviço – Cloud Software as a Service (SaaS):

A capacidade fornecida ao consumidor é usar as aplicações do provedor em execução numa
infraestrutura na cloud.
As aplicações são acessíveis a partir de vários dispositivos clientes, como um navegador da
web (por exemplo, web-based e-mail).
O consumidor não gere ou controla a infraestrutura de cloud subjacente, incluindo rede,
servidores, sistemas operativos, armazenamento, ...
Exemplos: Caspio, Google Apps, Salesforce, Nivio, Learn.com.
Modelos de serviço – Vantagens do SaaS:
O SaaS oferece inúmeras vantagens para funcionários e empresas, reduzindo
significativamente o tempo e o dinheiro gastos em tarefas entediantes, como instalação,
gestão e atualização de software. Isto consome muito tempo para a equipe técnica dedicar-se
a assuntos e questões mais urgentes dentro da organização.
Modelos de serviço – Características do SaaS:
Existem algumas maneiras de ajudá-lo a determinar quando o SaaS está a ser utilizado:
 Gerir a partir de um local central
 Hospedado num servidor remoto
 Acessível pela internet
 Os utilizadores não são responsáveis por atualizações de hardware ou software

SaaS Maturity Model

 135

Modelos de serviço – Cloud Platform as a Service (PaaS):

 O recurso fornecido ao consumidor é implantar na infraestrutura de cloud aplicações
criadas ou adquiridas pelo consumidor, criados usando linguagens de programação e
ferramentas suportadas pelo provedor. O consumidor não gere ou controla a
infraestrutura da cloud subjacente.
 O consumidor tem controlo sobre as aplicações deployed e, possivelmente, as
configurações do ambiente de hosting de aplicações.
 Exemplos: Windows Azure, Google App.

 PaaS Advantages:
Não importa o tamanho de uma empresa, PaaS oferece inúmeras vantagens, incluindo:
o Desenvolvimento e deployment simples e económica de aplicações
o Escalável
o Altamente disponível
o Os desenvolvedores podem personalizar aplicações sem a dor de cabeça de manter o
software
o Redução significativa na quantidade de codificação necessária
o Automatização da política de negócios
o Fácil migração para o modelo híbrido

 Caraterísticas de PaaS:
PaaS tem muitas caraterísticas que o definem como um serviço na cloud, incluindo:
o Baseia-se na tecnologia de virtualização, para que os recursos possam ser facilmente
aumentados ou reduzidos conforme a empresa muda
o Oferece uma variedade de serviços para auxiliar no desenvolvimento, teste e
deployment de aplicações
o Acessível a vários utilizadores através da mesma aplicação de desenvolvimento
o Integra serviços da web e bancos de dados

Modelos de serviço – Infraestrutura em nuvem como serviço (IaaS):

 136

 A capacidade fornecida ao consumidor é fornecer processamento, armazenamento,

redes e outros recursos de computação fundamentais.
 O consumidor pode implantar e executar software arbitrário, que pode incluir sistemas
operativos e aplicações.
 O consumidor não gere ou controla a infraestrutura da cloud subjacente, mas tem
controle sobre os sistemas operativos, armazenamento, aplicações deployed e,
possivelmente, controlo limitado de componentes de rede selecionados (por exemplo,
firewalls de host).
 Exemplos: Amazon EC2, GoGrid, iland, Rackspace Cloud Servers, ReliaCloud

 Vantagens IaaS:
IaaS oferece muitas vantagens, incluindo:
o O modelo de computação na cloud mais flexível
o Fácil de automatizar o deployment de armazenamento, rede, servidores e capacidade
de processamento
o As compras de hardware podem ser baseadas no consumo
o Os clientes mantêm controlo total da sua infraestrutura
o Os recursos podem ser adquiridos conforme necessário
o Altamente escalável
 Caraterísticas IaaS:
As caraterísticas que definem IaaS incluem:
o Os recursos estão disponíveis como um serviço
o O custo varia dependendo do consumo
o Os serviços são altamente escaláveis
o Vários utilizadores numa única peça de hardware
o A organização retém o controlo total da infraestrutura
o Dinâmico e flexível
Modelos de serviço em Cloud

Modelos de implantação/Deployment Models

 137

 Cloud privada: A cloud é operada exclusivamente para uma organização. Pode ser
gerida pela organização ou por terceiros e pode existir no local ou fora do mesmo.
 Cloud da comunidade: A infraestrutura na cloud é partilhada por várias organizações e
oferece suporte a uma comunidade específica que partilha preocupações. Pode ser
gerido pelas organizações ou por terceiros e pode existir no local ou fora do local.
 Cloud pública: a infraestrutura da cloud é disponibilizada ao público em geral ou a um
grande grupo do setor e é propriedade de uma organização que vende serviços na cloud.
 Cloud híbrida: a infraestrutura da clou é uma composição de dois ou mais modelos de
cloud (privada, comunidade ou pública).

Cloud – Summary
 A computação na cloud é um termo abrangente usado para se referir ao
desenvolvimento e serviços baseados na Internet
 Uma série de caraterísticas definem dados na cloud, serviços de aplicativos e
infraestrutura:
o Hospedado remotamente: serviços ou dados são hospedados em infraestrutura
remota.
o Ubíquo: serviços ou dados estão disponíveis em qualquer lugar.
o Commodified: O resultado é um modelo de utility computing semelhante ao
tradicional de utilitários tradicionais, como gás e eletricidade - você paga pelo
que deseja!

Arquitetura na Cloud
 138

O que é computação na cloud

 Conjunto partilhado de recursos de computação configuráveis
 Acesso à rede sob demanda
 Fornecido pelo Provedor de Serviços

Caraterísticas de computação na cloud

Características básicas da cloud

 139

 O “no-need-to-know” em termos dos detalhes básicos da infraestrutura, a interface das

aplicações com a infraestrutura através das APIs.
 A “flexibilidade e elasticidade” permite que estes sistemas aumentem ou diminuam à
vontade.
Utilizando os recursos de todos os tipos: CPU, armazenamento, capacidade do
servidor, balanceamento de carga e databases.
 O tipo de computação utilitária “pague quanto usar e precisar” e o tipo de computação
baseada em rede “sempre ligado!, em qualquer lugar”.
 A cloud é transparente para utilizadores e aplicações; estes podem ser construídos de
várias maneiras:
Produtos de marca, código aberto proprietário, hardware ou software ou apenas PCs
prontos para uso.
 Em geral, são construídos em clusters de servidores de PC e componentes off-the-shelf,
além de software de código aberto combinado com aplicações internas e/ou software de
sistema.
Virtualização
Espaços de trabalho virtuais:
 Uma abstração de um ambiente de execução que pode ser disponibilizado
dinamicamente para clientes autorizados usando protocolos bem definidos,
 Cota de recursos (por exemplo, CPU, partilha de memória),
 Configuração de software (por exemplo, O / S, serviços fornecidos).
Implementar em máquinas virtuais (VMs):
 Abstração de uma máquina host física,
 O hipervisor intercepta e emula instruções de VMs e permite a gestão de VMs,
VMWare, Xen, etc.
Fornece API de infraestrutura:
 Plug-ins para estruturas de hardware/suporte

Máquinas virtuais
A tecnologia VM permite que várias máquinas virtuais sejam executadas numa única
máquina física.
 140

Desempenho: a para-virtualização (por exemplo, Xen) está muito próxima do desempenho

físico bruto!
Virtualização – Qual é o propósito e os benefícios?
 A computação na cloud permite que empresas e aplicações, que dependem da
infraestrutura do sistema, sejam sem infraestrutura.
 Ao usar a infraestrutura da cloud em “pagar conforme o uso e sob demanda”, todos nós
podemos economizar capital e investimento operacional!
 Os clientes podem:
o Colocar os dados na plataforma em vez de colocar nos próprios desktops e/ou nos
seus próprios servidores.
o Podem colocar as suas aplicações na cloud e usar os servidores dentro da cloud para
fazer processamento e manipulação de dados, etc.
Cloud-Sourcing
Por que tem se tornado um grande negócio:
 Usando fornecedores de alta escala / baixo custo,
 Acesso a qualquer hora / lugar via navegador da web,
 Escalabilidade rápida; custo incremental e partilha de carga,
 Pode esquecer a necessidade de se concentrar em IT local.
Preocupações:
 Desempenho, confiabilidade e SLAs,
 Controlo de dados e parâmetros de serviço,
 Recursos e escolhas da aplicação,
 Interação entre provedores de cloud,
 Sem API padrão - mistura de SOAP e REST!
 Privacidade, segurança, conformidade, confiança ...
Armazenamento na cloud
 Várias grandes empresas da Web têm explorado o fato de terem capacidade de
armazenamento de dados que pode ser alugada para terceiros.
 Permite que os dados armazenados remotamente sejam temporariamente armazenados
em cache em computadores desktop, telemóveis ou outros dispositivos ligados à
Internet.
 Elastic Compute Cloud (EC2) e solução de armazenamento simples da Amazon
 (S3) são exemplos bem conhecidos
 141

o Serviço de turco mecânico

Oportunidades e desafios
O uso da cloud oferece uma série de oportunidades:
 Permite que os serviços sejam usados sem nenhuma compreensão de sua
infraestrutura.
 A computação na cloud funciona usando economias de escala:
o Potencialmente reduz as despesas para empresas iniciantes, pois não
precisariam mais comprar os seus próprios softwares ou servidores.
o O custo seria por preço sob demanda.
o Os fornecedores e prestadores de serviços cobram os custos estabelecendo um
fluxo contínuo de receitas.
 Os dados e serviços são armazenados remotamente, mas acessíveis de “qualquer
lugar”.
Paralelamente, houve reação contra a computação na cloud:
 O uso da computação na cloud significa dependência de outras pessoas e isso pode
limitar a flexibilidade e a inovação:
o As outras provavelmente se tornarão as maiores empresas de Internet, como
Google e IBM, que podem monopolizar o mercado.
o Alguns argumentam que o uso de supercomputadores é um retorno à era da
computação de mainframe, contra a qual o PC era uma reação.
 A segurança pode ser um grande problema:
o Ainda não está claro como os dados terceirizados são seguros e, ao usar esses
serviços, a propriedade dos dados nem sempre é clara.
 Existem também questões relacionadas à política e ao acesso:
o Se os seus dados são armazenados no exterior, a qual política é seguida?
o O que acontece se o servidor remoto cair?
o Como se acedem aos arquivos?
o Já houve casos de utilizadores que perderam o acesso às contas e perderam o
acesso aos dados.
Vantagens da computação na cloud
Custos de computador mais baixos:
 Não precisa de um computador de alta potência e alto preço para executar as
aplicações web-based da computação na cloud.
 Uma vez que as aplicações são executadas na cloud, não no PC, o PC não precisa do
poder de processamento ou do espaço em disco exigido pelo software de desktop
tradicional.
 Quando se está a utilizar aplicações web-based, o PC pode ser mais barato, com um
disco rígido menor, menos memória, processador mais eficiente ...
 Na verdade, o PC neste cenário não precisa nem mesmo de uma unidade de CD ou
DVD, pois nenhum programa de software deve ser carregado e nenhum ficheiro de
documento precisa ser guardado.
 142

Performance melhorada:
 Com poucos programas grandes ocupando a memória do seu computador, é poss´viel
ver um melhor desempenho do PC.
 Os computadores num sistema de computação na cloud inicializam e funcionam mais
rápido porque têm menos programas e processos carregados na memória ...
Custos de software reduzidos:
 Em vez de comprar aplicações de software caros, pode-se obter a maior parte do que
precisa de graça (ou quase de graça)!
o a maioria das aplicações de computação na cloud hoje, como o pacote Google
Docs.
 melhor do que pagar por software comercial semelhante
o o que por si só pode ser uma justificação para mudar para aplicações na nuvem.
Atualizações instantâneas de software:
 Outra vantagem da computação na cloud é que não é preciso escolher entre software
obsoleto e altos custos de atualização.
 Quando a aplicação é web-based, as atualizações acontecem automaticamente,
disponíveis na próxima vez que se fizer login na cloud.
 Ao aceder uma aplicação web-based, obtém a versão mais recente sem precisar pagar
ou fazer download de uma atualização.
Compatibilidade de formato de documento aprimorada.
 Não precisa se preocupar com os documentos que cria na própria máquina sendo
compatíveis com aplicações ou sistemas operativos de outros utilizadores.
 Potencialmente, não há incompatibilidades de formato quando todos estão a partilhar
documentos e aplicações na cloud.
Capacidade de armazenamento ilimitada:
 A computação na cloud oferece armazenamento virtualmente ilimitado.
 O disco rígido de 1 TByte atual do seu computador é pequeno em comparação com as
centenas de PBytes disponíveis na cloud.
Maior confiabilidade dos dados:
 Ao contrário da computação de desktop, em que se um disco rígido travar e destruir
todos os dados valiosos, um computador travando na cloud não deve afetar o
armazenamento dos dados.
o se o seu computador travar, todos os dados ainda estarão na cloud, acessíveis
 Num mundo onde poucos utilizadores individuais de PC desktop fazem backup dos
seus dados regularmente, a computação na cloud é uma plataforma de computação
segura de dados!
Acesso universal a documentos:
 143

 Com a computação na cloud, você não é necessário levar os seus documentos em

papel, em vez disso, estes ficam na cloud e pode-se aceder sempre que tiver um
computador e uma conexão com a Internet
 Os documentos estão disponíveis instantaneamente de qualquer lugar.
Disponibilidade da versão mais recente:
 Quando se edita um documento em casa, essa versão editada é o que se vê quando se
acede o documento no trabalho.
 A cloud sempre hosts a versão mais recente dos documentos
o contando que esteja conectado, não há risco de ter uma versão desatualizada

Colaboração em grupo mais fácil:

 A partilha de documentos leva diretamente a uma melhor colaboração.
 Muitos utilizadores fazem isso, pois é uma vantagem importante da computação na
cloud, vários utilizadores podem colaborar facilmente em documentos e projetos
Independência do dispositivo.
 Não está mais preso a um único computador ou rede.
 Alterações em computadores, aplicações e documentos acompanham pela nuvem.
 Mudar para um dispositivo portátil e as aplicações e documentos ainda estarão
disponíveis.
Desvantagens da computação na cloud
Requer uma conexão constante com a Internet:
 A computação na cloud é impossível se não se consegue conectar à Internet.
 Uma vez que usa a Internet para se conectar às aplicações e documentos, se não tiver
uma conexão à Internet, não poderá aceder nada, nem mesmo os próprios
documentos.
 Uma conexão de Internet inativa significa nenhum trabalho e em áreas onde as
conexões de Internet são poucas ou inerentemente não confiáveis, isto pode ser um
deal-break.
Não funciona bem com conexões de baixa velocidade:
 Da mesma forma, uma conexão de Internet de baixa velocidade, como a encontrada
com serviços dial-up, torna a computação na cloud dolorosa, na melhor das hipóteses,
e frequentemente impossível.
 As aplicações web-based exigem muita largura de banda para fazer download, assim
como os documentos grandes.
As features podem ser limitadas:
 Essa situação está vinculada a mudar, mas hoje muitas aplicações web-based
simplesmente não são tão completas quanto as aplicações baseadas em desktop.
 Por exemplo, pode-se fazer muito mais com o Microsoft PowerPoint do que com a
oferta baseada na web do Google Presentation
 144

Pode ser lento:

 Mesmo com uma conexão rápida, as aplicações web-based às vezes podem ser mais
lentas do que aceder um programa de software semelhante no PC.
 Tudo sobre o programa, da interface ao documento atual, deve ser enviado do seu
computador para os computadores na cloud.
 Se o backup dos servidores na cloud acontecer naquele momento, ou se a Internet
estiver com um dia lento, não se obterá o acesso instantâneo que espera de aplicações
de desktop.
Os dados armazenados podem não ser seguros:
 Com a computação na cloud, todos os seus dados são armazenados na cloud.
 A questão é: Quão segura é a cloud?
 Utilizadores não autorizados podem obter acesso aos dados confidenciais?
Os dados armazenados podem ser perdidos:
 Teoricamente, os dados armazenados na cloud são seguros, replicados em várias
máquinas.
 Se os dados forem perdidos, não existe backup físico ou local.
Sistemas HPC:
 Não está claro se se pode executar aplicações HPC de computação intensiva que usam
MPI / OpenMP!
 O scheduling é importante com este tipo de aplicação, se se desejar que todas as VMs
sejam colocalizadas para minimizar a latência de comunicação!
Preocupações Gerais:
 Cada sistema na cloud usa diferentes protocolos e diferentes APIs
 Pode não ser possível executar aplicações entre sistemas baseados na cloud
 A Amazon criou o seu próprio sistema de databse (não SQL 92) e sistema de
workflow (muitos sistemas de fluxo de trabalho populares por aí)
 portanto, as aplicações normais terão que ser adaptadas para serem executadas nessas
plataformas.

Exemplo de cloud: o que é EC2?

 Amazon Elastic Compute Cloud (EC2) é um serviço da web que fornece capacidade
de computação redimensionável que se usa para construir e host de diferentes
sistemas de software.
 Projetado para tornar a computação em escala da web mais fácil para os
desenvolvedores.
 145

 Um utilizador pode criar, iniciar e encerrar instâncias de servidor conforme

necessário, pagando por hora pelos servidores ativos, daí o termo "elástico".
 Fornece capacidade de computador escalonável e paga conforme o uso
 Elástico - escala em ambas as direções
Conceitos EC2
 AMI e Instância
 Região e Zonas
 Armazenar
 Rede e segurança
 Monitorização
 Auto Scaling
 Balanceador de carga
Amazon Machine Images (AMI)
 É uma representação imutável de um conjunto de discos que contém um sistema
operacional, aplicações de utilizador e / ou dados.
 A partir de uma AMI, pode-se lançar várias instâncias, que são cópias em execução da
AMI.

AMI e Instância
Amazon Machine Image (AMI) é um modelo para configuração de software (sistema
operativo, servidor de aplicações e aplicações)
Instância é uma AMI em execução em servidores virtuais na nuvem
Cada tipo de instância oferece diferentes recursos de computação e memória
 146

Região e Zonas
 Amazon tem data centers em diferentes regiões do mundo
o 25 regiões lançadas, 80 zonas de disponibilidade, 245 países e territórios
atendidos
 Uma instância pode ser iniciada em diferentes regiões, dependendo da necessidade.
o Mais perto de um cliente específico
o Para atender a requisitos legais ou outros
 Cada região possui um conjunto de zonas
o As zonas são isoladas de falhas em outras zonas
o Conectividade económica e de baixa latência entre zonas na mesma região
Armazenamento
Amazon EC2 oferece três tipos de opção de armazenamento
 Amazon EBS
 Amazon S3
 Armazenamento de Instância
 147

Volume de armazenamento de bloco elástico (EBS)

 Um volume EBS é um disco de leitura/escrita que pode ser criado por um AMI e
montado por uma instância.
 Os volumes são adequados para aplicações que requerem uma database, um sistema de
ficheiros ou acesso ao armazenamento bruto ao nível de bloco.

Amazon S3
 S3 = Serviço de armazenamento simples
 SOA - Arquitetura Orientada a Serviços que fornece armazenamento online usando
serviços da web.
 Permite a leitura, escrita e excluir permissões em objetos.
 Usa protocolos REST e SOAP para mensagens.
Amazon SimpleDB
 O Amazon SimpleDB é um armazenamento de dados não relacional altamente
disponível, flexível e escalonável que alivia o trabalho de administração de database.
 Cria e gere várias réplicas distribuídas geograficamente dos seus dados automaticamente
para permitir alta disponibilidade e durabilidade de dados.
 O serviço cobra apenas pelos recursos realmente consumidos no armazenamento dos
seus dados e no atendimento dos seus requests.
Rede e segurança
 148

As instâncias podem ser iniciadas numa das duas plataformas

 EC2-Classic
 EC2-VPC
 Cada instância iniciada recebe dois endereços, um endereço privado e um endereço IP
público.
o Uma instância de substituição possui um endereço IP público diferente.

O endereço IP da instância é dinâmico.

o novo endereço IP é atribuído toda vez que a instância é lançada
 O Amazon EC2 oferece endereços Elastic IP (endereços IP estáticos) para computação
na cloud dinâmica.
Remapeia o Elastic IP para uma nova instância para mascarar a falha
Pool separado para EC2-Classic e VPC
Grupos de segurança para controlo de acesso à instância
Monitorização, escalonamento automático e balanceamento de carga
 Monitorizar estatísticas de instâncias e EBS
o CloudWatch
 Aumenta e diminui automaticamente a capacidade do Amazon EC2 baseado em regras
o Adicionar e remover recursos de computação com base na demanda
o Adequado para empresas que experimentam variabilidade no uso
 Distribuir o tráfego de entrada em várias instâncias
o Elastic Load Balancing

EC2 - O Básico
 Carregar imagem no S3 e registe-a.
 Inicializar a imagem a partir do serviço da web.
 Abrir as portas necessárias para a imagem.
 Conectar-se à imagem através de SSH.
 Executar a aplicação…

Aula 10 – Análise de dados/ Data analytics

Applications of IoT Analytics
 149

Por que IoT Data Analytics?

 Estabelece uma variedade de ambientes mais inteligentes (casas, hotéis, hospitais, etc.)
 Descobre insights oportunos e acionáveis para máquinas e pessoas
 Permite a realização de objetos, dispositivos, redes e ambientes inteligentes,
 Leva à produção de aplicações e serviços pioneiros e centrados nas pessoas
 Ajuda a apresentar previsões e prescrições precisas,
 Facilita a excelência do processo e a produtividade das pessoas
 Garante a manutenção preventiva das infraestruturas
 Garante a utilização otimizada de ativos distribuídos através de monitorização, medição e
gestão para uma reposição perfeita de stock
 Protege a segurança de pessoas e propriedades
 Monitoriza ambientes complexos para garantir o desempenho, produtividade e resiliência
dos negócios
Análise de dados em clouds públicas para casas mais inteligentes (exemplo)

Os recursos distintos das plataformas de análise de dados de IoT

 Escalabilidade
 150

 Ingestão de dados mais rápida

 Melhor desempenho de leitura e escrite
 Processamento de consulta mais rápido
 Flexibilidade e portabilidade (para executar em border clouds, privadas e públicas)
 Processamento distribuído através de fragmentação automatizada
 Melhor compactação de dados
 Plataforma integrada e ponta a ponta para todos os tipos de dados e análises
 Capacidades de machine e deep learning
 Interfaces RESTful
 Análise na memória e no banco de dados
O que torna o processamento de dados e análise de IoT um desafio?

Cadeia de valor de Big Data

 Coleção - dados estruturados, não estruturados e semiestruturados de várias fontes

 Ingestão - carregamento de grandes quantidades de dados num único armazenamento de
dados
 Descoberta e limpeza - compreensão do formato e conteúdo; limpar e formatar
 Integração - vinculação, extração de entidade, resolução de entidade, indexação e fusão
de dados
 Análise - Inteligência, estatística, análise preditiva e de texto, machine learning
 Entrega - consulta, visualização, entrega em tempo real com disponibilidade de classe
empresarial

Análise de dados - Caraterísticas de dados

 151

Lidando com a integração de dados – Mudança da integração de dados para inteligência em

tempo real

As organizações têm procurado mudar de analítica descritiva para cognitiva

 152

IoT tem impulsionado a rutura digital do mundo físico

IoT Analytics (exemplos)

As categorias de aplicações incluem: (1) notificações push, (2) manutenção preditiva e (2)
análise de fluxo em tempo real.
 153

IoT vs Big Data tradicional

 Diferentes escalas de capacidade de resposta
o Para IoT, o valor dos dados no tempo é essencial: ele recolhe e usa dados em tempo
real para rastrear e monitorizar ativos e ser capaz de agir prontamente, por exemplo,
detetar violações de segurança, corrigir defeitos, etc.
o Big data destaca o longo prazo: geralmente há um lapso entre o momento em que os
dados são recolhidos e quando são analisados, por exemplo, para dar suporte à
inteligência de negócios, planeamento de capacidade, etc.
 Dependências temporais e espaciais
o Os dados de IoT vêm com anotações de tempo e localização, que estão diretamente
associados ao seu valor de negócios em um determinado contexto de aplicação e
devem ser considerados no processamento de dados de IoT
 Mentalidades divergentes
o IoT visa aplicações intensivas: ingestão e análise de dados eficazes e eficientes
quando e onde for necessário
o Big data visa aplicações extensas: recolhe e processa mais rapidamente dados cada
vez mais divergentes (4 V’s)

Big Data ou IoT?

 154

 A cada minuto, enviamos 204 milhões de e-mails, geramos 1,8 milhão de likes no
Facebook, enviamos 278 mil tweets e carregamos 200 mil fotos no Facebook. (BIG
DATA)
 12 milhões de tags RFID (usadas para capturar dados e rastrear o movimento de objetos
no mundo físico) foram vendidas em 2011. Em 2021, estima-se que esse número
aumentará para 209 bilhões à medida que (IoT) takes off.
 O boom de (IoT) significará que a quantidade de dispositivos que se conectam à Internet
aumentará de cerca de 13 bilhões hoje para 50 bilhões em 2020.
 Espera-se que a indústria (BIG DATA) cresça de US $ 10,2 bilhões em 2013 para cerca
de US $ 54,3 bilhões em 2017.
Aplicações Cognitivas vs. Tradicionais - Os Diferenciadores

Compreensão: os sistemas cognitivos entendem como os humanos, seja através da linguagem

natural ou da palavra escrita; vocal ou visual.

Raciocínio: Estes raciocinam. Podem entender as informações, mas também as ideias e

conceitos subjacentes. Essa habilidade de raciocínio pode se tornar mais avançada com o
tempo. É a diferença entre as estratégias de raciocínio que usamos quando crianças para
resolver problemas matemáticos e, em seguida, as estratégias que desenvolvemos quando
entramos em matemática avançada, como geometria, álgebra e cálculo.

Aprendizagem: Nunca param de aprender. Como tecnologia, isso significa que o sistema
realmente se torna mais valioso com o tempo. Desenvolvem “expertise”. Pense no que
significa ser um especialista - não se trata de executar um modelo matemático. Não
consideramos os médicos especialistas nas suas áreas porque eles respondem a todas as
perguntas corretamente. Esperamos que sejam capazes de raciocinar e ser transparentes sobre
o seu raciocínio e expor os motivos pelos quais chegaram a uma conclusão.

Tipos de dados IoT

• Endereços / identificadores únicos (nominais)
o IP (IPv4, IPv6), Bluetooth, Zigbee, LoRa, RFID
• Dados posicionais (contínuos)
o GPS (longitude, latitude, altitude), WiFi (longitude, latitude)
 155

• Dados temporais (contínuos)

o Hora e Data
• Dados do sensor (numéricos)
o Saída de um dispositivo que deteta e responde a algum tipo de entrada do ambiente
físico (movimento, posição, ambiente, massa, biomarcador)
• Dados descritivos (categóricos)
o Objetos, processos e sistemas

Qualidade de dados IoT (DQ)

• Avaliar a qualidade dos dados de IoT criados na natureza (vs. configuração controlada)
• Várias métricas que indicam a adequação dos dados para a tomada de decisão e
planeamento
o Accuracy: erros e ruídos dependendo da calibração do método de deteção e das
restrições de recursos do dispositivo (energia, memória)
o Validade: dados anormais w.r.t. satisfazer os requisitos de aceitação
o Oportunidade/Timeliness: atrasada devido a limitações do protocolo de transmissão
ou da infraestrutura de processamento
o Completude: dados ausentes devido a falhas do dispositivo ou comunicação
intermitente, bem como dados amostrados de forma desigual devido a diferentes
frequências de deteção
o Integridade: dados inconsistentes devido à natureza dinâmica da IoT em adicionar
ou remover coisas de deployments existentes
o Confiabilidade: dados alterados de forma mal-intencionada devido a violações de
segurança

O que é Real Time Analytics?

O valor de tempo dos dados do sensor significa que os dados que tem agora não significarão
tanto numa semana, dia ou mesmo hora a partir de agora!
 156

Edge Processing/Computing [Cisco, Intel]

• Objetivo: empurrar o processamento de dados para longe do núcleo e em direção ao edge
da rede
o ajudar a garantir que a tarefa de processamento de dados certa aconteça na hora e no
lugar certos
• Fatores motivadores:
1. Reduz a latência: executar cálculos de dados diretamente em dispositivos IoT ou
gateways e apenas interagir com a cloudf fora do caminho crítico (por exemplo, para
treinar continuamente modelos de ML com dados recentes)
2. Ser robusto para problemas de conectividade: as aplicações não são interrompidas
em caso de conectividade de rede limitada ou intermitente
3. Preservar a privacidade: garantir que os dados confidenciais sejam pré-processados
no local, e apenas os dados em conformidade com a privacidade sejam enviados para
a cloud para análise posterior, após terem passado por uma primeira camada de
agregação anónima
• Ampla gama de tecnologias: computação em cloud/fog local, computação em grid/mesh,
mobile edge computing, cloudlets, etc.

Modos de interação IoT e análise de dados

 Centralizado: para coisas de baixo custo em que os dados podem ser facilmente
migrados, por exemplo, medidores inteligentes
 157

 Descentralizado: para coisas autónomas com necessidades de desempenho rígidas, por

exemplo drones
 Federado: para coisas que produzem grandes volumes de dados cuja migração é difícil,
cara ou sensível, por exemplo, carros autónomos

A necessidade de Fog Computing

 Por que não posso fazer tudo na cloud?
o A computação na cloud liberta a empresa e o utilizador final de muitos detalhes.
o Essa felicidade torna-se um problema para aplicações sensíveis à latência.
 Por que não pode fazer tudo em sistemas finais?
o Restrições físicas: energia, espaço, etc.,

Casos de uso ilustrativos para conduzir a computação do Fog

 Caso de uso 1: um sistema de semáforo inteligente (STLS)
 Caso de uso 2: parques eólicos
Para abstrair os principais requisitos para propor uma arquitetura que atenda à grande maioria
dos requisitos de IoT.
Caso de uso 1: um sistema de semáforo inteligente (STLS)
Esboço do sistema: STLS exige o deployment de um STL em cada interseção.
O STL é equipado com sensores que:
1. Medem a distância e a velocidade dos veículos que se aproximam de todas as
direções.
2. Detetam a presença de pedestres/outros veículos atravessando a rua.
Emite avisos de “desaceleração” para veículos em risco de passar no vermelho e até modifica
o seu próprio ciclo para evitar colisões.
 158

STLS: Contorno do Sistema

STLS tem 3 objetivos principais:
1. Prevenção de acidentes
2. Manutenção de fluxo constante de tráfego (ondas verdes ao longo das estradas
principais)
3. Recolha de dados relevantes para avaliar e melhorar o sistema
Nota: A meta (1) requer reação em tempo real, (2) em tempo quase real e (3) está relacionada
à recolhja e análise de dados globais por longos períodos.
Requisitos principais impulsionados por STLS
1. Latência do subsistema local: - O tempo de reação necessário é da ordem de <10
milissegundos.
2. Middleware orchestration platform: - Middleware para lidar com um número de
componentes de software críticos. A. Tomador de decisão (DM), B. bus de mensagem.
3. Infraestrutura de rede: Fog nodes pertence a uma família de computação modular e
dispositivos de armazenamento.
4. Interação com a cloud: - Os dados devem ser injetados num Data center/cloud para
análise profunda para identificar padrões de tráfego, poluentes da cidade, etc.
5. Consistência de um sistema altamente distribuído: - Precisa ser consistente entre os
diferentes pontos agregadores.
6. Multilocação: Deve oferecer garantias de serviço rigorosas o tempo todo.
7. Multiplicidade de provedores: pode se estender além das fronteiras de uma única
autoridade de controlo. A orquestração de políticas consistentes envolvendo várias
agências é um desafio exclusivo da Fog Computing.
 159

Caso de uso 2: parque eólico

Apresenta requisitos partilhados por vários deployments de Internet de Todas as Coisas (IoE):
1. Interação entre análises em tempo real e análises em lote.
2. Forte interação entre sensores e atuadores, em loops de controlo fechados.
3. Amplo deployment geográfico de um grande sistema consistente de vários módulos
autónomos, porém coordenados - o que dá origem à necessidade de uma plataforma de
orquestração.
Esboço do sistema:
Existem 4 regiões operacionais típicas:
1. Região 1: a velocidade do vento é muito baixa (digamos, 6 m / s), não tão económica
para operar a turbina.
2. Região2: condição normal de operação (ventos entre 6-12 m / seg), portanto conversão
máxima de energia eólica em energia elétrica.
3. Região 3: Os ventos excedem 12 m / s, a potência é limitada para evitar exceder as
cargas elétricas e mecânicas seguras.
4. Região 4: Velocidades de vento muito altas acima de 25 m / s, aqui a turbina é desligada
para evitar cargas operacionais excessivas.
Requisitos principais impulsionados pelo Parque Eólico
1. Infraestrutura de rede: Uma rede de comunicação eficiente entre subsistemas, sistema e
internet (cloud)
2. Controlador global: recolha de dados, construção do estado global, determinação da
política.
3. Plataforma de orquestração intermediária: Um middleware que faz a mediação entre os
subsistemas e a cloud.
4. Análise de dados: (1) requer reação em tempo real, (2) tempo quase real e (3) relaciona-
se à recolha e análise de dados globais por longos períodos.
Principais atributos da computação Fog
 Os casos de uso que foram discutidos trazem vários atributos que diferenciam a
plataforma de computação Fog da nuvem.
 Aplicações que exigem latência muito baixa e previsível. (STLS, SCV)
 Aplicações geodistribuídos (monitorização de pipeline, STLS)
 Aplicações móveis rápidos (veículo conectado inteligente, trem)
 Sistemas de controlo distribuído em grande escala (STLS, Smart Grid)
 A IoT também traz Big Data com uma diferença: em vez de alto volume, o número de
fontes de dados distribuídas geograficamente

Distribuição geográfica: uma nova dimensão do Big Data

 3 dimensões: volume, velocidade e variedade.
 160

 Casos de uso de IoT: STLS, Connected Rail, monitorização de dutos são naturalmente
distribuídos.
 Isso sugere adicionar uma 4ª dimensão: a distribuição geográfica.
 Já o desafio é gerir o número de sensores (e atuadores) que são naturalmente distribuídos
como um todo coerente.
 Chamada para “mover o processamento para os dados”
 Uma plataforma distribuída inteligente no Edge (Fog computing) que gere recursos
distribuídos de computação, rede e armazenamento.
A interação Edge (Fog) e o núcleo (Fog): Muitos usos dos mesmos dados

IoT Data Analytics

Técnicas de processamento de dados em lote e online
• Agregação e estatísticas
• Análise de série de dados (Spatiotemporal)
• Machine Learning
o Supervisised: Classificação, Regressão, Anomalia / Outlier
o Unsupervised: Clustering, Freq. Mineração do Conjunto de Itens, Anomalia / Outlier
• Deep learning
• Domínio e tipo de dados específico
o Por exemplo, dados do sensor de pressão de um sistema de tubulação, sensores de
dados do sensor acústico de um motor, dados do sensor de vibração numa ponte
suspensa
Poquê “Learn”?
 Para resolver um problema num computador, precisamos de um algoritmo. Um
algoritmo é uma sequência de instruções que deve ser executada para transformar a
entrada em saída.
 Para algumas tarefas, no entanto, não temos um algoritmo - por exemplo, para distinguir
e-mails de spam de e-mails legítimos. Sabemos qual é a entrada: um documento de e-
mail que, no caso mais simples, é um ficheiro de caracteres. Sabemos qual deve ser a
saída: uma saída sim/não indicando se a mensagem é spam ou não.
 161

 Não sabemos como transformar a entrada em saída. O que pode ser considerado spam
muda com o tempo e de indivíduo para indivíduo.
 O que nos falta em conhecimento, compensamos em dados. Podemos facilmente
compilar milhares de mensagens de exemplo.
 Acreditamos que existe um processo que explica os dados que observamos. Embora não
saibamos os detalhes do processo subjacente à geração de dados, sabemos que não é
totalmente aleatório.
 Podemos não ser capazes de identificar o processo completamente, mas acreditamos que
podemos construir uma aproximação boa e útil.
 Acreditamos que ainda podemos detetar certos padrões ou regularidades. Esta é a função
de machine learning.
 Machine learning é sobre a programação de computadores para otimizar um critério de
desempenho usando dados de exemplo ou experiências anteriores.
 A aprendizagem é usada quando:
o A experiência humana não existe (navegando em Marte),
o Os humanos são incapazes de explicar seus conhecimentos (reconhecimento de fala)
o Mudanças de solução no tempo (routing numa rede de computadores)
o A solução precisa ser adaptada a casos particulares (biometria do utilizador)

O que falamos quando falamos sobre “aprendizagem”

 Aprendendo modelos gerais a partir de dados de exemplos particulares
 Os dados são baratos e abundantes (data warehouses, data marts); o conhecimento é caro
e escasso.
 Exemplo no retail: transações do cliente para o comportamento do consumidor:
o Pessoas que compraram “Blink” também compraram “Outliers” (www.amazon.com)
 Construa um modelo que seja uma boa e útil aproximação dos dados.
Data Mining/Mineração de dados
 Retail: análise de cesta de compras, gestão de relacionamento com o cliente (CRM)
 Finanças: pontuação de crédito, deteção de fraude
 Fabricação: controlo, robótica, solução de problemas
 Medicina: diagnóstico médico
 Telecomunicações: filtros de spam, deteção de intrusão
 Bioinformática: motivos, alinhamento
 Mineração da web: motores de busca

O que é machine learning?

 Otimizar um critério de desempenho usando dados de exemplo ou experiência anterior.
 Papel da estatística: inferência de uma amostra
 Papel da ciência da computação: algoritmos eficientes para:
o Resolver o problema de otimização
 162

o Representar e avaliar o modelo para inferência

Aplicações
 Association
 Supervised Learning
o Classification
o Regression
 Unsupervised Learning
 Reinforcement Learning
Classificação: Aplicações
Aka Reconhecimento de padrão
 Reconhecimento facial: pose, iluminação, oclusão (óculos, barba), maquiagem, estilo de
cabelo
 Reconhecimento de caracteres: Diferentes estilos de escrita à mão.
 Reconhecimento de fala: dependência temporal.
 Diagnóstico médico: dos sintomas às doenças
 Biometria: Reconhecimento/autenticação usando características físicas e/ou
comportamentais: Face, íris, assinatura, etc
Aprendizagem supervisionada: usos
 Previsão de casos futuros: use a regra para prever a saída para entradas futuras
 Extração de conhecimento: a regra é fácil de entender
 Compactação: a regra é mais simples do que os dados que explica
 Deteção de outlier: exceções que não são cobertas pela regra, por exemplo, fraude
Aprendizagem Não Supervisionada
 Aprendendo “o que normalmente acontece”
 Sem saída
 Clustering: agrupamento de instâncias semelhantes
 Aplicações de exemplo:
o Segmentação de clientes em CRM
o Compressão de imagem: quantização de cor
o Bioinformática: motivos de aprendizagem

Reinforcement Learning
 Aprendendo uma política: uma sequência de resultados
 Sem saída supervisionada, mas recompensa atrasada
 Problema de cessão de crédito
 Jogando
 Robô num labirinto
 163

 Vários agentes, observabilidade parcial, ...

Por que reduzir a dimensionalidade?
 Reduz a complexidade do tempo: menos computação
 Reduz a complexidade do espaço: menos parâmetros
 Economiza o custo de observar o recurso
 Modelos mais simples são mais robustos em pequenos conjuntos de dados
 Mais interpretável; explicação mais simples
 Visualização de dados (estrutura, grupos, outliers, etc) com plot de 2 ou 3 dimensões
Seleção de recursos vs extração
 Seleção de features: escolher k<d recursos importantes, ignorando os d - k restantes
 Algoritmos de seleção de subconjunto: Extração de caraterística: projetar as dimensões
originais xi, i = 1, ..., d para novas dimensões k <d, zj, j = 1, ..., k
 Análise de componentes principais (PCA), análise discriminante linear (LDA), análise
fatorial (FA)
Traditional vs Deep Learning

Interpretabilidade de algoritmos de ML
 164

Aprendizagem Federada
A aprendizagem federada é um problema de treino de um modelo global partilhado de alta
qualidade com um servidor central de dados descentralizados espalhados entre um grande
número de clientes diferentes

Aprendizagem federada - Features

Deve lidar com:
• Dados não IID (independentes e distribuídos de forma idêntica)
o Os dados de treino em cada nó podem ser idiossincráticos.
• Dados desequilibrados
o Quantidade desigual de dados em cada nó.
• Dados amplamente distribuídos
o Pode ter muito mais dispositivos do que exemplos de treino por nó.
• Comunicação limitada
o Não pode garantir a disponibilidade de nós.

Aprendizagem federada - caso de uso

Quando FL é mais adequado:
 165

• A privacidade é necessária (FL não é a solução completa)

• Largura de banda ou consumo de energia são preocupações
• Alto custo de transferência de dados
• O modelo melhora com mais dados

Aula 11 – Segurança e IoT