Conoscenze di fondo/motivazione su MQTT:
MQTT: comunicazione nell’Internet delle cose
L’idea di un internet delle cose comporta un problema basilare: come possono innumerevoli apparecchi, con rendimento diverso, in parte mobili, in parte fissi, spesso collegati con cavi inaffidabili e con tempi di latenza elevati, comunicare tra loro in modo efficiente ed affidabile?
Collegamenti diretti tramite TCP/IP
La maggior parte dei terminali nell’internet delle cose non hanno un indirizzo IP pubblico. Come un telefono senza numero proprio possono chiamare altri apparecchi, ma non possono essere a loro volta chiamati. Se possono, il traffico dati in entrata è spesso filtrato da un firewall. Un collegamento diretto, al di là della rete, tra due terminali non è possibile nella maggior parte dei casi.
Se un apparecchio IoT può essere ugualmente attivato direttamente, si verificano problemi di sicurezza dei dati. Non per niente si sente sempre più spesso parlare di reti Bot che si diffondono attraverso router economici o telecamere IP con firmware obsoleto. Non tutti gli sviluppatori di un nuovo gadget interessante lavorano con la dovuta accuratezza e non tutti i proprietari sono consapevoli della loro responsabilità di amministratori.
Cloud IoT: un approccio basato sui dati
una possibile soluzione è offerta dalle cloud IoT. Si tratta di memorie dati Internet, messe a disposizione da aziende come Google, SalesForce o IBM. Anche i clienti di Wiesemann & Theis possono usufruire della cloud W&T gratuita.
I terminali si collegano con i server dei provider della cloud, per archiviarvi o richiamarvi i dati. Soluzioni software gratuite come ThinkSpeak offrono la possibilità di allestire un (gruppo di) server del genere anche nella propria rete e di salvarvi i dati localmente.
Le cloud funzionano sulla base dei dati. Spesso sono dotate di front-end web, per visualizzare i valori di misura e lo stato dei contatori. L’accesso M2M ai valori singoli e alle serie temporali avviene generalmente tramite interfacce REST specifiche per la piattaforma. I provider della cloud offrono sempre più spesso anche processi di accesso basati sulla comunicazione. Così per esempio BlueMix IBM, Microsoft Azure e Xively supportano il protocollo IoT MQTT.
MQTT: l’approccio basato sulla comunicazione
Come per l’approccio cloud, i partecipanti alla comunicazione (client) in MQTT instaurano attivamente un collegamento con un servizio centrale, il broker.
Il broker, però, non è una memoria di dati, bensì agisce come intermediario in cui i client collegati inseriscono (publish) o si iscrivono (subscribe) a notizie. In base al tema della notizia, del topic, il broker decide a quale client inviare le notizie ricevute (publish).
Un topic è una stringa strutturata gerarchicamente, i cui componenti sono divisi gli uni dagli altri tramite una barra trasversale. Analogamente ad un percorso di sistema file, i topic possono essere strutturati come un albero ed è possibile abbonarsi a un gruppo di topic utilizzando delle wildcard.
Diverse proprietà del protocollo consentono una comunicazione stabile anche in condizioni sfavorevoli. Velocità di trasmissione ridotte, elevati tempi di latenza o occasionali interruzioni del collegamento non rappresentano un problema. Per questo MQTT è adeguato anche per la comunicazione dati mobile.
Interruzioni del collegamento del subscriber:
Persistent Session e Quality of ServiceUn subscriber può indicare al momento dell’avvio del collegamento che desidera stabilire una sessione duratura (persistent session). In questo caso il broker salva temporaneamente i topic a cui il subscriber si è abbonato. In caso di un’interruzione del collegamento salva tutte le notizie, la cui ricezione debba essere confermata dal subscriber. Se sia necessaria una conferma, viene deciso attraverso la qualità del servizio (Quality of Service, abbreviato: QoS) di una notizia. Un messaggio con qualità del servizio QoS0 viene inviato "al massimo una volta" ed eventualmente respinto, se il subscriber non è raggiungibile. Un messaggio con qualità del servizio QoS1 viene inviato finché il subscriber non conferma la ricezione. La qualità del servizio QoS2 garantisce che il subscriber riceva il messaggio esattamente una volta.
Interruzioni del collegamento del publisher:
Last Will e Retained MessagesNel suo "testamento" un publisher comunica al broker al momento dell’avvio del collegamento che messaggio deve essere inviato ai subscriver nell’eventualità di un’improvvisa interruzione del collegamento. Per ogni publisher può essere impostato solo un testamento.
Se un publisher invia un messaggio in cui è apposta la Retained Flag, il broker salva temporaneamente questo messaggio per un topic. Questo messaggio viene da un lato inviato ai subscriber che si sono appena abbonati al topic, dall’altro a subscriber con qualità del servizio 1 che non hanno ancora inviato una conferma della ricezione. Un’applicazione esempio è la trasmissione dell’ultimo valore di misura conosciuto di un sensore di temperatura. Per ogni topic può essere mantenuto esattamente un messaggio.
Comunicazione garantita:
Autenticazione e crittografia
MQTT supporta l’autenticazione dei client attraverso nome utente e passwort. In questo modo il broker può rilasciare autorizzazioni e per esempio fare in modo che solo il sensore della temperatura possa pubblicare localmente messaggi con il topic f2/kuehlthekte/temp. Il nome utente e la password vengono comunicati all’avvio del collegamento e trasmessi non crittografati. Per questo è una buona idea crittografare qualsiasi comunicazione MQTT fin dall’inizio. Poiché il protocollo si trova ai livelli superiori del modello OSI, la crittografia può essere realizzata senza problemi con TLS, purché il relativo terminale sia dotato delle risorse necessarie.
Universale e portatile
MQTT non dispone solo di una struttura di base molto semplice, bensì offre anche ampie libertà nella suddivisione dei topic e non dà istruzioni in merito al contenuto del payload. In questo modo MQTT è un protocollo molto generico e utilizzabile in modo versatile. Anche nella scelta del broker non ci sono praticamente limitazioni: questi sono disponibili come software gratuiti, di aziende commerciali affermate, come servizio in rete o applicazione hardware. Un’applicazione che utilizza MQTT per la comunicazione, funziona con qualsiasi broker MQTT. In questo modo si garantisce la possibilità di cambiare piattaforma in ogni momento e senza particolare sforzo.
Provate voi stessi
Domande sul Web-IO digitale con MQTT?
Il signor Thiel sarà lieto di assistervi.
Telefono: +49 202/2680-110 (Lun-Ven. 8-17)
E-mail: f.thiel@wut.de