Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MQTT: il protocollo che rende possibile l'Internet of Things

12,923 views

Published on

L’Internet Of Things (IoT) rappresenta l'evoluzione tecnologica che oggi consente l’interconnessione sempre più pervasiva tra dispositivi e oggetti di qualsiasi tipologia.
Il protocollo MQTT è alla base della comunicazione tra i dispositivi e la Rete.

La presentazione si focalizza sui seguenti aspetti:
- Cos’è il procollo MQTT e perché è nato?
- Quali sono i vantaggi in termini economici ed infrastrutturali derivanti dall’adozione dell’MQTT nell’Internet of Things?
- Perchè l’adozione dell’MQTT può rappresentare, per l’Internet of Things, un balzo in avanti rispetto all’utilizzo di altri protocolli di comunicazione come l’HTTP?
- Quali sono e come possono essere superate in maniera soddisfacente le problematiche di sicurezza dei dispositivi connessi a Internet?
- In termini prestazionali e comparativi, che livelli di carico può supportare un’infrastruttura basata su MQTT?

Ambiti di applicazione e di interesse:
- Produttori di dispositivi Hardware.
- Produttori di sistemi di automazione a microprocessore.
- Produttori di dispositivi consumer-oriented pensati per l'interconnessione.
- Aziende che operano nei seguenti settori: Domotica, Automotive, Infomobilità, Telemetria, Telematica, Biomedicale, Monitoraggio industriale, Sistemi embedded.

Published in: Software

MQTT: il protocollo che rende possibile l'Internet of Things

  1. 1. MQTT: il protocollo che rende possibile
 l’Internet Of Things Davide Pozza – Omnys (www.omnys.com) davide.pozza@omnys.com http://it.linkedin.com/in/davidepozza 1
  2. 2. /42 Davide Pozza ▪ Mi occupo di progettazione e delivery di infrastrutture software “mission critical”
 ▪ Negli anni ho avuto modo di affrontare tematiche funzionali e tecnologiche relative agli ambiti più svariati tra cui: ▪ Internet banking ▪ Ecommerce ed integrazione con sistemi di legacy ▪ ICT e telecomunicazioni ▪ Interazione con dispositivi “smart”
 ▪ Sono socio di Omnys, software house presente sul mercato dal 09/09/1999 che si occupa principalmente di: ▪ System Integration e Architetture Cloud ▪ Piattaforme web (ecommerce, turismo, infomobilità, editoria digitale) ▪ APP mobile ▪ Internet of Things (wearable, medical, home automation) 2
  3. 3. /42 The Internet of Things 3 ▪ Smartphone & wearable ▪ Controllo veicoli, persone, animali, … ▪ Dispositivi embedded ▪ Automazione industriale ▪ Monitoraggio consumi energetici ▪ Impianti di sicurezza e sorveglianza ▪ Smart Building/Home & City ▪ Telemedicina e Salute ▪ Everyday things…
  4. 4. /42 Verso l’interconnessione totale “The Web is becoming more and more pervasive as an applications platform, and effective standards are crucial for reducing the costs of deploying applications across a wide range of devices and environments, whether in the office, at home or on the move. The Ubiquitous Web will provide people with access whenever and wherever they find themselves, with applications that dynamically adapt to the user's needs, device capabilities and environmental conditions.” Philipp Hoschka, Ubiquitous Web Domain Leader Ubiquitous Web Web 1.0 Web 2.0 Social Web Mobile Web 4
  5. 5. /42 Una crescita esponenziale A fine del 2014: 9 miliardi di dispositivi connessi Entro il 2020: • 57.000/sec
 nuovi dispositivi che si connetteranno
 • 212 miliardi
 di dispositivi in grado di connettersi
 • 30 miliardi
 di dispositivi connessi 5
  6. 6. /42 Internet of Things: il problema Persone + Oggetti + Sensori + Dispositivi = tantissimi endpoint 
 che emettono segnali 6
  7. 7. /42 Internet of Things: una nuova sfida ▪ Richiede un modello di comunicazione in real-time ed event-driven ▪ Le informazioni devono poter essere inviate in modalità one-to- many ▪ Capacità di recepire (“listening”) un evento non appena si verifica ▪ Necessità di ridurre al massimo la dimensione dei pacchetti dati scambiati ▪ Necessità di gestire l’invio di messaggi anche su reti degradate (reliability) 7
  8. 8. /42 L’HTTP è adatto per gestire SEGNALI? ▪ E’ “document-centric” (XML, ecc) e basato sul paradigma request/ reply ▪ Ha un elevato overhead di rete ▪ E’ estremamente verboso: PUT/POST/GET/DELETE prevedono comunque l’invio di molti bytes e non sono sempre la scelta migliore nello sviluppo di applicazioni dove la comunicazione deve essere “ultralight” ▪ Non prevede nessuna garanzia built-in sulla comunicazione 8
  9. 9. /42 Internet of Things: non è il WEB! ▪ I firmware dei dispositivi sono limitati (potenza, memoria, batteria)
 ▪ Possono essere necessari anche migliaia di dispositivi per monitorare un sistema industriale (es. gasdotti, piattaforme petrolifere,…) ▪ La connettività può essere molto degradata e/o estremamente costosa (GPRS, Satellite) 9
  10. 10. /42 L’alternativa MQTT = MQ TELEMETRY TRANSPORT “A light weight event and message oriented 
 protocol allowing devices to asynchronously 
 communicate efficiently across constrained 
 networks to remote systems” 10
  11. 11. /42 MQTT: i principali benefici ▪ Rende semplice la connessione tra il mondo degli oggetti e il mondo dell’ IT evitando il “polling” dei sensori
 ▪ Consente la trasmissione di dati su reti soggette a frequenti interruzioni
 ▪ Fornisce il massimo disaccoppiamento possibile garantendo comunque la trasmissione/ricezione dei dati (QoS)
 ▪ Riesce a gestire la comunicazione con un elevato numero di dispositivi 11
  12. 12. /42 Il protocollo MQTT in SINTESI • Semplice: solo 3 funzioni: – connect + publish + subscribe (un client può funzionare su un controller a 8 bit e 256kb di RAM) • Affidabile: QoS per supportare reti degradate
 • Leggero: overhead minimo ed estrema efficenza: – no envelope, o headers; pacchetti anche da 2 bytes • Aperto: standard definito e aperto (royalty-free)
 12
  13. 13. /42 Il trend di interesse per l’MQTT Google Trends evidenzia un interesse in forte crescita in relazione al termine “MQTT” 13
  14. 14. /42 Ambito dell’MQTT Intelligence & Analytics Traditional Backend Systems BigData Interconnection Mobile & Web Embedded Controllers, Sensors, Actuators, … Data/Alert Respond Control Sense 14
  15. 15. /42 Il modello Publish/Subscribe ▪ Il PUBLISHER invia (publish) un messaggio su un TOPIC (subject) 
 ▪ Il SUBSCRIBER è un consumer che si mette in ascolto (subscribe) sui messaggi pubblicati su un TOPIC specifico ▪ Il BROKER (server di smistamento messaggi) si occupa di effettuare il matching tra SUBSCRIBER e PUBLISHER con il conseguente dispatching del messaggio. Subscriber Broker Publisher Topic Publisher Topic Subscriber Subscriber 15
  16. 16. /42 Comunicazione asincrona e bidirezionale MQTT Broker 1. CONNECT to MQTT broker 2. PUBLISH on:
 <house_id>/s/energyConsumption
 <house_id>/s/solarEnergy 3. SUBSCRIBE to:
 <house_id>/thermostat/setTemp 1. CONNECT to MQTT broker 2. SUBSCRIBE on:
 <house_id>/s/* 3. PUBLISH to:
 <house_id>/thermostat/setTemp 16
  17. 17. /42 Garanzia nella comunicazione ▪ Keep-Alive message (PINGREQ, PINGRESP): – il Broker riesce ad identificare una disconnessione non esplicita del client ▪ Will message: – viene impostato nel messaggio di CONNECT con topic, QoS e retain. In caso di disconnessione inaspettata il messaggio “Will” viene mandato ai subscribers registrati ▪ Retain message: – un messaggio pubblicato su un topic viene mantenuto sul broker. Un successivo subscriber che si connette sullo stesso topic riceve il messaggio (last known good message) ▪ Persistent Session: – dopo la disconnessione del client, tutte le sottoscrizioni vengono mantenute nel broker e recuperate alla connessione successiva 17
  18. 18. /42 Cos’è il livello di qualità del servizio (QoS) ? E’ un “agreement” tra il mittente ed il destinatario di un messaggio in relazione alla garanzia di “delivery” del messaggio stesso. Il QoS è una delle più potenti caratteristiche del protocollo MQTT in quanto rende molto più semplice lo scambio messaggi su reti degradate attraverso la gestione automatica della ri-trasmissione. Ci sono tre livelli disponibili: ▪ QoS 0 – at most once: garantisce il “best effort delivery”; è detto anche “fire & forget” e non contempla la conferma di ricezione che quindi è la medesima del trasporto TCP/IP ▪ QoS 1 – at least once: garantisce la consegna del messaggio almeno una volta verso un ricevente; il messaggio però può essere ricevuto anche più volte ▪ QoS 2 - exactly once: garantisce la consegna del messaggio una ed una sola volta verso un ricevente 18
  19. 19. /42 Come funziona il QoS BrokerPublisher Subscriber BrokerPublisher Subscriber PUBLISH (QoS = 0) PUBLISH Delete message Store message PUBLISH (QoS = 1) Store message Delete message Delete message PUBLISH BrokerPublisher Subscriber Store message PUBLISH (QoS = 2) Store message Delete message Delete message PUBLISH QoS 0: At most once (fire & forget) QoS 1: At least once QoS 2: Exactly once PUBREC PUBREL PUBCOMP PUBACK 19
  20. 20. /42 Sicurezza nella comunicazione 3 livelli di sicurezza: ▪ PROTOCOLLO ▪ Username/Password in CONNECT ▪ Possibilità di criptare il Payload ▪ TRASPORTO ▪ MQTT over TLS (v1.2) ▪ Autenticazione del client con certificato ▪ BROKER ▪ Gestione dei permessi su Publish/Subscribe e Topic ▪ Possibilità di integrare altri sistemi di autenticazione/autorizzazione (es. LDAP, OAuth 2.0) 20
  21. 21. /42 MQTT vs HTTP (long polling): prestazioni Test di spedizione (1024 messaggi con payload da 1 byte) http://stephendnicholas.com/archives/1217 21
  22. 22. /42 MQTT vs HTTP: la struttura del messaggio MQTT: dimensione header 2 byte HTTP: dimensione header
 REQ/RES > 300 byte 22 GET /service Host: www.endpointm2m.com Accept:text/xml Accept-Encoding:gzip, deflate, sdch Connection:keep-alive HTTP/1.1 200 OK Connection:Keep-Alive Content-Length:33452 Content-Encoding:gzip Content-Type:text/xml Keep-Alive:timeout=15, max=100 Last-Modified:Fri, 17 May 2013 14:50:39 GMT Connection:close
  23. 23. /42 MQTT-SN ▪ E’ un’evoluzione dello standard MQTT pensata per i dispositivi embedded (SN = Sensor Networks) ▪ Non richiede lo stack TCP/IP: può essere utilizzato su seriale, UDP, ZigBee, RF, … 23
  24. 24. /42 MQTT … in pratica 24
  25. 25. /42 I principali Broker MQTT MOSQUITTO 25
  26. 26. /42 Soluzioni MQTT in Cloud ▪ Pagamento a consumo di risorse (“pay per usage”) ▪ Opzione “free tier”: sotto soglie ben definite il servizio è gratuito ▪ Soluzioni IaaS / PaaS ▪ Elevati QoS (99.9%) ▪ Elevata scalabilità ▪ Tempi di startup estremamente ridotti 26
  27. 27. /42 IBM Bluemix ▪ Sul fronte dei servizi Cloud MQTT/IoT sono i primi arrivati (GIU-14), nonché i principali promotori e ideatori dello standard MQTT ▪ Fornisce un soluzioni “full stack” (boilerplate), tra cui quella dedicata esclusivamente all’ IoT e basata su MQTT ▪ Basata su CloudFoundry con deploy in 3 step: ▪ Selezione di un Runtime (Node, Java, PHP, …) ▪ Selezione dei Servizi ▪ Installazione dell’applicazione ▪ Freemium plan: ▪ 20 dispositivi ▪ 100MB di traffico dati al mese ▪ 1GB di storage 27
  28. 28. /42 IBM Bluemix 28
  29. 29. /42 Amazon AWS IoT: overview ▪ Offre la più elevata quantità di servizi Cloud dislocati in ben 11 regioni geografiche e vanta la miglior offerta in termini di scalabilità e computazionalità ▪ AWS, nato nel 2006, solo pochi giorni fa (OTT-15) ha lanciato la soluzione “AWS IoT” (attualmente in “Beta”) che sfrutta il protocollo MQTT ▪ Free tier of 250K messages (IN/OUT) per month for 12 months. Therefore 5$ per million messages 29
  30. 30. /42 Amazon AWS IoT: caratteristiche 30
  31. 31. /42 Microsoft Azure IoT Suite ▪ La Suite IoT è stata lanciata molto recentemente (MAR-15) ▪ Microsoft ha dichiarato di puntare molto sull’IoT (Windows 10 for Raspberry Pi) ▪ L’approccio è quello di mettere a disposizione “finished applications to speed development of common scenarios” ▪ E’ possibile utilizzare il protocollo MQTT solo come layer aggiuntivo in quanto non è incluso come soluzione nel “core” della Suite. 31
  32. 32. /42 Eurotech ▪ La suite EDC (Everywhere Device Cloud - iPaaS) fornisce una soluzione completa (HW & SW) che offre la connettività sicura e scalabile basata su MQTT ▪ La suite ESF (Everywhere Software Platform) è un framework finalizzato a rendere il più semplice possibile l’integrazione tra i dispositivi ed il cloud (EDC) ▪ Utilizza un’enhanced version del protocollo MQTT che ad esempio può gestire la “birth date” del dispositivo ▪ Modello di pricing basato su numero di dispositivi e/o numero di messaggi scambiati ▪ La suite può funzionare su AWS, Azure o anche in modalità standalone 32
  33. 33. /42 Eurotech EDC/ESF 33
  34. 34. /42 Client di riferimento MQTT Disponibile per i seguenti linguaggi: ▪ C++ ▪ C for embedded ▪ Go ▪ Java ▪ JavaScript ▪ Lua ▪ .Net ▪ Objective-C ▪ Python Altri: 
 https://github.com/mqtt/mqtt.github.io/wiki/libraries • Client di riferimento per l’ecosistema MQTT • Disponibile open-source 34
  35. 35. /42 Alcuni casi d’uso 35
  36. 36. /42 Monitoraggio oleodotti e piattaforme 36
  37. 37. /42 Facebook Messenger ▪ More than 850M Users ▪ Chat application ▪ Improved Battery ▪ Lower latency ▪ Less bandwidth https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920 “By maintaining an MQTT connection and routing messages through our chat pipeline, we were able to often achieve phone-to-phone delivery in the hundreds of milliseconds, rather than multiple seconds.” 37
  38. 38. /42 Una “smart home” open source ▪ Mosquitto MQTT + openHab su Raspberry Pi ▪ Arduino per la gestione dei sensori ▪ Monitoraggio e controllo remoto da tablet/ smartphone con app openHab http://www.instructables.com/id/Uber-Home-Automation-w-Arduino-Pi 38
  39. 39. /42 Infomobilità e autotrasporti ▪ Ogni mezzo dispone di un device che raccoglie e invia i dati su posizione, velocità e consumi ▪ I dati raccolti vengono inviati “dove serve” ▪ Le informazioni sono analizzate e le decisioni sono prese in tempo reale da un singolo backend 39
  40. 40. /42 Salute e medicina ▪ Ogni dispenser comunica con il server centrale in tempo reale inviando dati su mancate/errate assunzioni ▪ Le informazioni relative ad eventi di allarme scatenano delle azioni immediate (notifica telefonica, SMS, ecc) 1. il paziente non 
 assume il farmaco 2. Il dispositivo invia allarme al server centrale (MQTT over GPRS) 3. Il server centrale (broker) invia notifica istantanea al medico 4. Il medico contatta il paziente 40
  41. 41. /42 Credits ▪ MQTT official web site : http://mqtt.org ▪ Mosquitto : http://mosquitto.org / https://www.eclipse.org/mosquitto ▪ Mosca: https://github.com/mcollina/mosca ▪ HiveMQ : http://www.hivemq.com ▪ M2Mqtt C# Client : http://m2mqtt.codeplex.com ▪ Eclipse Paho project : http://www.eclipse.org/paho/ ▪ MQTT-SN: http://mqtt.org/2013/12/mqtt-for-sensor-networks-mqtt-sn ▪ Amazon AWS IoT: https://aws.amazon.com/iot/ ▪ IBM Bluemix IoT: https://www.ibm.com/cloud-computing/bluemix/solutions/iot/ ▪ Microsof Azure IoT Suite: http://www.microsoft.com/en-us/server-cloud/internet-of-things/ ▪ Eurotech: http://www.eurotech.com/ 41
  42. 42. /42 Grazie per l’attenzione! DOMANDE ? 42 OMNYS - Information Technology www.omnys.com @SMAU Milano 2015: PAD. 1 - STAND E11

×