Protocolos de “Nuvem” para IoT - boscojr.com · 2 Roteiro Arquitetura para IoT Web das Coisas...

Protocolos de “Nuvem” para IoT

2

Roteiro

Arquitetura para IoT

Web das Coisas

Formato de Dados

Rest

MQTT

Plataformas de Nuvem

3


4


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


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

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: 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.terra.com.br/


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: 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: 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: 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: 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/protcomseg/form.php


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: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: Arquitetura

Cliente

REQUEST

RESPONSE

ArquivosInterpretador

Script


HTTP: Autenticação

Servidor Web

Básica

Digest

Por Certifcado (SSL)

Aplicação

Tokens


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


Fonte: http://www.restapitutorial.com/httpstatuscodes.html


LAB 1: Servidor Web


Comunicaçção “S2S”


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


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.


Exemplo: MAC Database Vendor

macvendors.com

# curl -k https://api.macvendors.com/FC-A1-3E-2A-1C-33


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;


Componentes de uma API

Funções

Parâmetros

Retorno

Status


O grandes “players” da internet possuem APIs

Google

Facebook

Ebay

Twiter

Amazon

Youtube


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


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.


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


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


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.


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>


XML – TAGS

Tags podem ter atributos:

<note date="12/11/2007">

<to>Tove</to>

<from>Jani</from>

<message>Hello!</message>

</note>


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


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;


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" ] }


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


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}


Remoção:

DELETE http://www.boscojr.com/iot/restfull/{ORG}/{RFIDCOD}


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

Google

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


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


71

FIM

Protocolos de “Nuvem” para IoT - boscojr.com · 2 Roteiro Arquitetura para IoT Web das Coisas...

Documents

Transcript of Protocolos de “Nuvem” para IoT - boscojr.com · 2 Roteiro Arquitetura para IoT Web das Coisas...