FN_104

SETTEMBRE 2020 FIELDBUS & NETWORKS 52 sati iscritti. In genere, il broker non conserva i messaggi e il meccanismo store&forward non viene esplicitamente preso in considerazione. Sono definiti tre diversi modelli di consegna dei dati, e corrispondenti livelli di Quality of Service (QoS). Quando viene utilizzato il livello di QoS 0, i mes- saggi vengono inviati una sola volta e l’arrivo a destinazione non è garan- tito, pertanto i messaggi possono andare persi. Il livello QoS 1 abilita un meccanismo di handshake a due vie, quindi ogni messaggio viene inviato almeno una volta; tuttavia, se la conferma di ricezione viene persa, si pos- sono verificare più consegne. Infine, il livello di QoS 2 invia il messaggio esattamente una volta, utilizzando un handshake a quattro vie completo. Ovviamente, con QoS di livello 2 nessun messaggio viene perso, ma sono previsti ritardi end-to-end relativamente più lunghi. Esiste anche una versione ‘più leggera’ di Mqtt, che viene trasportato su TCP, denominata Mqtt-SN (Mqtt for Sensor Network). Va inoltre consi- derato come Mqtt sia orientato al supporto di client con poche risorse e connessi tramite reti di prestazioni eterogenee. Di conseguenza, è una scelta consolidata nelle applicazioni IIoT grazie alla sua efficienza; le sue eventuali carenze possono essere risolte comunque a livello di applica- zione. Tuttavia, nell’ottica di un suo impiego in ambito industriale e su scala mondiale, non sono generalmente disponibili metodologie mirate a valutare l’impatto delle latenze introdotte dall’infrastruttura di rete, so- prattutto in scenari globali. Una metodologia per stimare i ritardi su scala intercontinentale È per colmare questa lacuna che un gruppo di ricerca (del quale faccio anch’io parte) ha definito una metodologia, supportata da una serie di verifiche sperimentali su scala intercontinentale, dei ritardi introdotti da un middleware di comunicazione per (I)IoT, con particolare attenzione al protocollo Mqtt. Quando il percorso dei dati include il cloud, molte se non tutte le parti costituenti l’infrastruttura sono delle ‘scatole nere’ per l’utente e la stima della latenza complessiva si basa su scenari simulati o su specifici esperi- menti pilota. In teoria, il ritardo end-to-end può esseremisurato come l’in- tervallo temporale tra la ricezione e l’invio dell’informazione di interesse, a patto che sia supportato un qualche meccanismo di sincronizzazione temporale tra i partner della comunicazione. In particolare, è prassi co- mune riferirsi al tempo UTC, che può essere ottenuto tramite un ricevi- tore GPS, o basandosi su protocoli comeNTP (Network Transfer Protocol). Quest’ultimo approccio è il più adatto per i dispositivi che hanno già una connessione Internet, proprio come i dispositivi IIoT considerati, permet- tendo però un’accuratezza di sincronizzazione generalmente nell’ordine delle decine di millisecondi. È possibile però avere dei server NTP locali, che derivano il loro tempo da ricevitori GPS, con prestazioni nettamente superiori ed è questa soluzione ibrida che è stata considerata nell’approc- cio del gruppo di lavoro. È stato dunque progettato un esperimento per valutare il tempo necessa- rio a trasferire un’informazione tra due partner attraverso un broker (Mqtt) collocato nel cloud, come mostrato in Figura 1. La procedura si basa su un’iterazione ciclica secondo il seguente schema: ! " # - nizio. Diviene pertanto semplice determinare il ritardo end-to-end E2E nelle due direzioni come: E2E12 = T2-T1 e E2E21 = T4-T3 Un set up sperimentale è stato realizzato per verificare la metodologia $ % & '( )") * + attraverso il framework Node-RED e sincronizzati tramite due NTP ser- ver (Stratum 1) dotati di ricevitori GPS (Symmetricom Datum 6000. I due partner sono posti, rispettivamente, presso il campus dell’Università di Brescia (Italia) e il campus della scuola di ingegneria di São Carlos (Uni- versità di São Paulo - Brasile). Negli esperimenti i broker considerati sono stati test.mosquitto.org , e broker.hivemq.com , entrambi gratuiti e pubblici a scopo di test. La posi- zione esatta dei server è però sconosciuta. Il payload Mqtt è sempre inferiore a 1 kB; Mqtt è senza autenticazione; i topic Mqtt non sono persistenti; il ritardo K è pari a 60 s. Il livello di QoS è impostato allo stesso valore per entrambi i partner. I risultati del case study riportati in Tabella I e Tabella II confermano un elevato grado di variabilità del ritardo. In particolare, è statomisurato un ritardo end-to-end massimo che passa da poche centinaia di ms per QoS 0 non confermato a meno di 2 s per QoS 2. Sembra che QoS 1 sia il miglior compromesso tra ritardo end-to-end basso e ridotta variabilità, almeno quando broker pubblici sono considerati. Fieldbus & Networks Il set up sperimentale considerato Tabella II - End-to-end delay, trasferimento dati dal Brasile all’Italia (ms) Tabella I - End-to-end delay, trasferimento dati dall’Italia al Brasile (ms)