Post on 08-Nov-2018
Protocolos de “Nuvem” para IoT
2
Roteiro
Arquitetura para IoT
Web das Coisas
Formato de Dados
Rest
MQTT
Plataformas de Nuvem
3
Arquitetura para IoT
4
Arquitetura para IoT
http://www.boscojr.com/iot/wot.pdf
WoT (Web of Things)
Um novo paradigma para desenvolvimento de aplicações inspirado na ideia do IOT;
Utiliza protocolos e padrões amplamente aceitos na internet como HTTP e URI;
O objetivo é fazer com que a internet também possa englobar os objetos do dia-a-dia (geladeira, ar-condicionado, tv, carro, etc.)
Fonte: http://www.nce.ufrj.br/labnet/pesquisa/cidadesinteligentes/minicurso-
wot-fnal.pdf
http://www.boscojr.com/iot/wot.pdf
WoT - Protocolos
HTTPtransporte de dados, também usado para manipular os objetos através dos métodos HTTP tais como GET, POST, PUT e DELETE; Através destes métodos é possível expor as funcionalidades de um dado objeto na internet;
URI (Uniform Resource Identifer)Fornecem endereços únicos e globais para identifcaçção dos recursos;
REST Estilo arquitetural para desenvolvimento de aplicações distribuídas
http://www.boscojr.com/iot/wot.pdf
HTTP
Hypertext Transfer Protocol
Implementa o serviço web arquitetura TCP/IP;
Baseado no modelo Cliente-Servidor;
Utiliza os serviços de transporte orientado a conexão na porta 80/TCP;
Envio e recebimento de mensagens;
http://www.boscojr.com/iot/wot.pdf
HTTP: Teste
# telnet www.terra.com.br 80Connected to www.terra.com.br.Escape character is '^]'.GET /index.html HTTP/1.1host: www.terra.com.brUser-Agent: Mozilla/4.0
HTTP/1.1 200 OKServer: nginxDate: Thu, 07 Aug 2014 15:25:31 GMTContent-Type: text/html...Connection: keep-alive
C:
S:
DIGITE
Digite <enter>
http://www.boscojr.com/iot/wot.pdf
HTTP: Sessão
Uma sequência de transações de requisição resposta usando a mesma conexão TCP;
O cliente inicia a comunicação estabelecendo uma conexão TCP para uma porta do servidor, por omissão a porta 80;
O servidor escutando naquele IP e naquela porta, retorna com “HTTP/1.1 200 OK”, juntamente com o resultado da requisição ou erro informado;
http://www.boscojr.com/iot/wot.pdf
HTTP: URI
Em TI, um Identifcador Uniforme de Recursos (URI) - Uniform Resource Identifer (em inglês) é uma cadeia de carateres compacta usada para identifcar ou denominar um recurso na Internet (wikipedia).
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
http://www.boscojr.com/protcomseg/form.php?qualquer=algo#Cap1
http://www.boscojr.com/iot/wot.pdf
HTTP: Métodos
Também chamados de verbos
Usados para indicar a ação desejada sob o recurso
O Recurso é indicado pela URI
Principais métodos utilizados
HTTP 1.0 → GET, POST e HEAD
HTTP 1.1 → OPTIONS, PUT, DELETE, TRACE and CONNECT
http://www.boscojr.com/iot/wot.pdf
HTTP: Métodos
GET: Usado para solicitar um recurso do servidor;HEAD: É idêntico ao GET mas só vem o cabeçalho da resposta a requisição;POST: O método post é usado para solicitar ao servidor o processamento de informações enviadas no corpo da requisição. É maneira padrão usada para processar formulários web;PUT: Solicita que o objeto enviado junto a requisição, seja armazenada sob a URI fornecida. Se o recurso não existe ele é criado, se existe ele é modifcado.DELETE: Pode ser usado para remover um recurso específco.OPTIONS: Retorna os métodos http que o servidor suporta para determinada URL. Isso pode ser usada para checar a funcionalidade do servidor. CONNECT: Converte o pedido de conexão em um túnel TCP/IP transparente, geralmente para facilitar a comunicação criptografada com SSL (HTTPS) através de um proxy HTTP não criptografado.PATCH: Aplica modifcações parciais para um determinado recurso.Um servidor web mínimo deve ter pelo menos os métodos GET e HEAD
http://www.boscojr.com/iot/wot.pdf
HTTP: GET x POST
É possível usar o método GET para enviar dados de formulário para um servidor, porém não é aconselhável, pois os dados serão passados na URL, e podem ser facilmente reproduzidos numa tentativa de fraude no sistema. O método correto para envio do formulário é o metodo POST.
Entrada no html para o método GET:
<FORM action=form.php method=GET>
Entrada no html para o método POST:
<FORM action=form.php method=POST>
Exemplos:
: www.boscojr.com/protcomseg/form.php
http://www.boscojr.com/iot/wot.pdf
HTTP: SSL
S-HTTP o primeiro protocolo de internet com criptografa, desenvolvido por Allan Schifman e Eric Rescorla em 1993. Eles também desenvolveram o Secure Mosaic o primeiro navegador com suporte a esse protocolo.
Em 1994 a Netscape Communications desenvolveu o Secure Sockets Layer (SSL) e este veio a ser o protocolo padrão para segurança de comunicações na WEB. É capaz Prover autenticação, privacidade e integridade.
O HTTPS é uma combinação de HTTP + SSL.
O SSL foi desenhado para ser independente da aplicação. Podendo ser usada para prover segurança para outros protocolos.
Em janeiro de 1999 o IETF adotou uma versão melhorada do protocolo SSL que foi chamada de Transport Layer Protocol (TLS) 1.0 ou SSL 3.1 defnida na RFC 2246.
Em 2008 o IETF lançou a ultima versão TLS 1.2 (SSL 3.3) defnida na RFC 5246.
http://www.boscojr.com/iot/wot.pdf
HTTP:SSL
TLS está colocada acima da camada TCP.
Possui duas camadas:
Record Layer: é usada para encapsular os protocolos de mais alto nível do próprio TLS, tais como Handshake (alert, change cipher spec, como também os protocolos de aplicação, http, ftp, smtp).
A camada TLS Handkshake consiste dos protocolos de handshake, alerta, change cipher spec.
A linha amarela com todas as caixas combinadas, incluindo o http compões o Hiper Text Transfer Protocol Secure (HTTPS).
http://www.boscojr.com/iot/wot.pdf
HTTP: Arquitetura
Cliente
REQUEST
RESPONSE
ArquivosInterpretador
Script
http://www.boscojr.com/iot/wot.pdf
HTTP: Autenticação
Servidor Web
Básica
Digest
Por Certifcado (SSL)
Aplicação
Tokens
http://www.boscojr.com/iot/wot.pdf
HTTP: Códigos de Retorno
200 OK
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
500 Internal Server Error
503 Service Unavailable
http://www.boscojr.com/iot/wot.pdf
Fonte: http://www.restapitutorial.com/httpstatuscodes.html
http://www.boscojr.com/iot/wot.pdf
LAB 1: Servidor Web
http://www.boscojr.com/iot/wot.pdf
Comunicaçção “S2S”
http://www.boscojr.com/iot/wot.pdf
API - Aplication Programing Interface
é um conjunto de rotinas e padrões estabelecidos por um software para a utilizaçção das suas funcionalidades por aplicativos que nção pretendem envolver-se em detalhes da implementação do software, mas apenas usar seus serviços.
“How to design a good API and why it matters” Joshua Block - Google
http://www.boscojr.com/iot/wot.pdf
API – Comunicação “S2S”
As APIs permitem que software fale com software. Para fornecer um serviço o “elemento de software” deve possuir uma interface de programação de aplicativo ou API.
O Sistema operacional tem uma API (SPI)
Muitos Protocolos de Aplicação fazem uso de uma API.
http://www.boscojr.com/iot/wot.pdf
Exemplo: MAC Database Vendor
macvendors.com
# curl -k https://api.macvendors.com/FC-A1-3E-2A-1C-33
http://www.boscojr.com/iot/wot.pdf
Características de uma boa API
Fácil de Aprender e usar, mesmo sem documentação;
Fácil leitura e manutenção de código que a usa;
Fácil de estender;
Apropriada a para o público alvo;
http://www.boscojr.com/iot/wot.pdf
Componentes de uma API
Funções
Parâmetros
Retorno
Status
http://www.boscojr.com/iot/wot.pdf
O grandes “players” da internet possuem APIs
Ebay
Twiter
Amazon
Youtube
http://www.boscojr.com/iot/wot.pdf
Demonstração: ALPR
# curl -X POST -F image=@./car1.jpg 'https://api.openalpr.com/v2/recognize?recognize_vehicle=1&country=br&secret_key=seu_token
29
Formato de Dados para IoT
RAW/Binary
JSON
XML
CSV
http://www.boscojr.com/iot/wot.pdf
Binário vs Texto
Formatos binários são performáticos para os computadores tratar mas ruins para leitura por humanos;
Formato texto são mais faceis de serem entendidos por humanos mas geram quantidade excedente de dados. Ex:
150.68.44.4: Representaçção em 11 Bytes
10010110 01000100 00101100 00000100 (32bits)2521050116: 4 Bytes
Em formatos binários a formatação dos dados deve ser conhecida pelo software;
Em formatos texto a formatação é normalmente um padrão ou está no próprio documento. Ex: XML, CSV, JSON.
http://www.boscojr.com/iot/wot.pdf
CSV
Comma-separated values
Valores separados por virgula (,)
Estabelecida pela RFC4180 de 2005
Campos separados por virgula
Registros separados por quebra de linha (CRLF)
Os principais software de planilha podem importar arquivos CSV
Qualquer caractere pode ser usado como separador
http://www.boscojr.com/iot/wot.pdf
XML
XML é uma recomendação do W3C
W3C – World Wide Web Consortium
Responsáveis pela padronizaçção da Web
XML - EXtensible Markup Language
Ou Linguagem de Marcaçção Extensível
XML é uma linguagem de marcação bem como a HTML
XML foi projetada para descrever dados
As tags XML não são pré-defnidas.
Você deve defnir suas próprias tags
http://www.boscojr.com/iot/wot.pdf
XML vs HTML
A XML foi projetada para transportar dados.
A XML não é um substituto para a HTML.
A XML e a HTML foram projetadas com objetivos diferentes:
A XML foi projetada para descrever dados e enfocar o que os dados sção.
A HTML foi projetada para exibir os dados e enfocar como os dados aparecem.
A HTML está relacionada com a exibição de informação, enquanto a XML está relacionada com a descrição de informação.
http://www.boscojr.com/iot/wot.pdf
XML - TAGS
As TAGS não são defnidas
Uso de <> e </> para limitar o escopo. Ex:
<bilhete>
<para>José</para>
<de>Maria</de>
<título>Lembrete</título>
<corpo>Nção me esqueça neste fm-de-semana!</corpo>
</bilhete>
http://www.boscojr.com/iot/wot.pdf
XML – TAGS
Tags podem ter atributos:
<note date="12/11/2007">
<to>Tove</to>
<from>Jani</from>
<message>Hello!</message>
</note>
http://www.boscojr.com/iot/wot.pdf
XML vs IOT
<device>
<id>001</id>
<timestamp>2018-09-01: 10:00</timestamp>
<sensor type=”temp” unit=”oC”>50</sensor>
<sensor type=”humid” unit=”%”>80</sensor>
</device>
Device: 001
temp
Humid
http://www.boscojr.com/iot/wot.pdf
Json
JSON (JavaScript Object Notation - Notação de Objetos JavaScript);
Formatação leve de troca de dados;
Para seres humanos, é fácil de ler e escrever;
Para máquinas, é fácil de interpretar e gerar;
Atualmente padronizada na RFC7159;
http://www.boscojr.com/iot/wot.pdf
JSON - Estrutura
Objeto: Uma coleção de pares nome/valor. Em várias linguagens, isto é caracterizado como um object, record, struct, dicionário, hash table, keyed list, ou arrays associativas.
{ "name":"John", "age":30, "car":null }
Array: Uma lista ordenada de valores. Na maioria das linguagens, isto é caracterizado como uma array, vetor, lista ou sequência.
[ "Ford", "BMW", "Fiat" ]
Exemplo:
{ "name":"John", "age":30, "cars":[ "Ford", "BMW", "Fiat" ] }
http://www.boscojr.com/iot/wot.pdf
JSON - Tipos
Observe o seguinte json:{ “key” : value }
Neste caso “value” pode ser:Um outro objeto: { "key" : { "subkey" : value} }
Um array: { "key" : [ value , value ] }
Uma string (texto): { “key” : “value” }
Observe o uso das aspas
Um numero: { “key” : value }
Sem aspas
Valores lógicos também sção suportados (sem aspas)
true: { “key” : true }
false: { “key” : false }
Valores nulos (null): { “key” : null }
Sem aspas
http://www.boscojr.com/iot/wot.pdf
Crie o CSV, XML, JSON
S1
D1
S1
D2
S2 S1
D3
S3S2
Nuvem
Dado Dado Dado
● S1: Temp● S2: Humid● S3: CO2
41
REST
REST – REpresentative State Transfer;
Transferência de Estado Representativo;
Defnido por Roy T. Fielding em sua tese de PhD;
Estabelece um conjunto de princípios para aplicações web distribuídas;
Diz-se RESTful as aplicações que seguem esses princípios.
42
Principios de REST
A interface da aplicação deve ser uniforme;
Stateless: Uma requisição não depende de outra anterior, Toda informação necessária ao processamento deve está na própria requisição;
Cacheable: O resultado das requisições podem ser armazenadas em cache;
Client-Server: A comunicação deve ser cliente-servidor;
Layered System (Camadas): O cliente não deve enxergar além das camadas adjacentes;
Code-on-Denand: A aplicação pode opcionalmente gerar código para que o cliente execute. Ex: Javascript.
43
REST: Em resumo
Todas as coisas devem ter pelo menos um identifcador
Vincule as coisas
Utilize métodos padronizados
Recursos com múltiplas representações
Comunique sem estado
Fonte: http://www.infoq.com/br/articles/rest-introduction
44
1) Dê a todas as coisas um Identifcador
Use URIs para identifcar tudo o que precisar ser identifcado, especifque todos os recursos de "alto nível" que seu aplicativo oferece, se eles representam itens individuais, conjuntos de itens, objetos virtuais e físicos, ou resultados de computação.
“Coisas” individuais
Conjuntos de “Coisas”
45
2) Vincule as coisas
Use links para referenciar coisas que possam ser identifcadas (recursos) sempre que for possível.
A resposta a uma requisição pode conter links para outros recursos
46
3) Utilize os métodos padrão
47
4) Recursos com múltiplas representações
O cliente pode querer escolher a forma que deseja receber as informações. Ex.:
XML
Vcard (vcf)
48
5) Comunique sem Estado
Uma requisição do cliente para o servidor não deve depender de requisições anteriores;
REST exige que o estado seja transformado no estado do recurso. O estado deve ser transformado em algo que possa ser consultado;
Ou o estado do recurso é enviado ao cliente e lá deve ser mantido.
49
REST
50
LAB 2: Preparando o Servidor para REST
51
EXEMPLO: API RESTCadastro de TAGS RFID
URI: http://www.boscojr.com/iot/restfull
Cadastro ORG: (todos RFID pertencem a um ORG)
PUT http://www.boscojr.com/iot/restfull/{ORG}
Retorno: 200 OK, 409 Confito, 400 Mal Formado
Cadastro RFID:
PUT http://www.boscojr.com/iot/restfull/{ORG}/{RFIDCOD}
Retorno: 200 OK, 409 Confito, 400 Mal Formado
Consulta TAG:
GET http://www.boscojr.com/iot/restfull/{ORG}/{RFIDCOD}
Retorno: 200 Ok, 404 Nção Encontrado, 400 Mal Formado
Consulta todas as TAG:
GET http://www.boscojr.com/iot/restfull/{ORG}
Retorno: 200 Ok, 404 Nção Encontrado, 400 Mal Formado
Remoção:
DELETE http://www.boscojr.com/iot/restfull/{ORG}/{RFIDCOD}
Retorno: 200 Ok, 404 Nção Encontrado, 400 Mal Formado
52
LAB 3: Implementando uma API REST
53
MQTT
Message Queue Telemetry Transport
Assíncrono
Publish/Subscribe (Pub/Sub)
Comunicação em uma direção (Pub → Sub)
Pouca complexidade
Pacote pequenos (mínimo 2 bytes)
Otimizado para cenários de conectivade restrita
Banda Baixa
Latência Alta
Ruido Alto
54
Modelo Publish/Subscribe
Mensagem: Informação do Sensor ou comando para o atuador
Fila, Tópico, Broker
Publishers (Publicadores)
Subscribers (Assinantes)
Operações (PUT[M], GET, SUBSCRIBE)
Funcionamento:
Os ASSINANTES registram o seu interesse em tópicos específcos de um determinado BROKER (SUBSCRIBE).
O PUBLICADOR envia (PUT) uma mensagem para a FILA de um TÓPICO existente em um BROKER. Neste momento todos os assinantes daquele TÓPICO sção avisados e devem consumir (GET) a mensagem gerada.
55
MQTT: Modelo Publish/Subscribe
Fila
Tópico
Broker
56
Brokers (On-Primise)
RabbitMQ
Kafka
Mosquitto (MQTT)
57
Brokers MQTT Cloud
58
MQTT: A HORA DO DEMO!
Mosquitto local
Mosquito clientes no cloudmqtt
MQTT Dash
59
Plataformas de Nuvem
Amazenamento (Cloud data store)
Lógica para Eventos (Event logic)
Integração com outras Plataformas (Platforms integration)
Fonte:https://dzone.com/articles/internet-of-things-4-free-platforms-to-build-iot-p
60
IoT Estratégias de Nuvem
Desenvolvimento Próprio (IaaS, PaaS, Hosting)
Serviços de IoT
Amazon
Azure
…
61
IoT Estratégias de NuvemGoogle
62
Porquê Ubidots (ubidots.com)
30 dias “free”
Modo educacional “free”
Não necessita Cartão de Crédito
Armazenamento
DashBoads
Protocolos HTTP e MQQT
63
Ubidots
Device (Gateway)
Variáveis (Sensor ou Atuador)
Dashboard
Eventos
64
Ubidots: Device x Variáveis
Device é uma entidade que pode ser equiparada ao gateway em nossa arquitetura de referencia
Conectado a um device pode existir vários sensores ou atuadores. Na plataforma Ubidots tanto sensores como atuadores são representados por variáveis.
WemosD1
Lâmpada
Fechadura
Ventilador
Temperatura
Presença
Humidade
0 | 1
0 | 1
0 | 1 | 2
0 | 1-10 → 100
0 → 100
Device“Sala”
Lâmpada
Fechadura
Ventilador
Temperatura
Presença
Humidade
Sensores/Atuadores Variáveis
65
Ubidots: DashBoards
Permite visualizar e interagir com variáveis
66
Ubidots: Dashboard
67
Ubidots: Eventos
Permite executar ações com base no valor das variáveis
Se Temperatura > 100 envia e-mail
Se temperatura < 0 envia faz um tuite
68
Preparação do Ambiente
Baixa o Curl for windows
LAB: Monitoração e Controle via Plataforma de IoT
69
Crie um token de autencação
Crie uma conta em Ubidots.com
Crie um device com duas variáveis
Temperatura
Interruptor
Crie uma dashboad com dois widgets
Chart → Line Chart
Control → Switch
Crie um evento
Se temperatura > 100 e-mail para e-mail de sua escolha
LAB: Monitoração e Controle via Plataforma de IoT
70
Teste 1: Enviar um valor (Após o envio veja a dashboard)
C:\> curl -X POST -H "Content-Type: application/json" -d '{"value":30}' http://things.ubidots.com/api/v1.6/devices/SALA/temperatura/values?token=SeuToken
Teste 2: Enviar um valor (Após o envio veja a dashboard)c:\> curl -X POST -H "Content-Type: application/json" -d '{"value":110}' http://things.ubidots.com/api/v1.6/devices/SALA/temperatura/values?token=SeuToken
Teste 3: Recuperar o valor de uma variável
curl http://things.ubidots.com/api/v1.6/devices/SALA/interruptor/lv?token=SeuToken
Pressione o switch na dashboard e verifque e repita o procedimento. Verifque a mudança no valor
LAB: Monitoração e Controle via Plataforma de IoT
71
FIM