Test dell’applicazione

In considerazione del fatto che l’applicazione Android utilizzerà dei timeout, per il testing dell’applicazione si è pensato che l’analisi dei tempi necessari al discovery fosse superflua. Al contrario è di fondamentale importanza valutare quanto l’applicazione incida sul consumo delle risorse. Per questo motivo, anche in questo caso, si è quindi utilizzato PowerTutor per analizzare i consumi.

Dopo due minuti di simulazione in cui il dispositivo ha eseguito il discovery, si è connesso al gateway ed ha inviato i dati di tutti i sensori ogni dieci secondi, si è potuto notare che l’applicazione ha assorbito mediamente 90mW di potenza con un picco massimo di circa 500mW.

Come si può notare dai grafici in Figura 5.11 i risultati ottenuti nel secondo test di utilizzo di MQTT su Android sono stati confermati: l’assorbimento massimo si verifica quando c’è utilizzo della connessione dati. Terminata la fase di discovery i consumi rimangono comunque accettabili nonostante siano stati attivati tutti i sensori.

5.4

Considerazioni finali

Alla luce di quanto emerso dai differenti test realizzati si può dire che il bundle Kura, a fronte di un numero di client elevato ma comunque reale, scali abbastanza bene e riesca a rispondere in tempi utili a tutte le richieste ricevute.

Anche dal punto di vista dell’utilizzo di risorse ci si può ritenere soddisfatti: l’utilizzo di memoria è totalmente irrilevante, mentre i picchi di accesso alla CPU che si hanno durante le elaborazioni delle richieste non costituiscono un problema, considerando che l’utilizzo medio rimane comunque limitato.

Anche i test effettuati sull’applicazione Android possono essere ritenuti positivi: il consumo medio di batteria, mettendo a disposizione tutti i sensori e comunicando i dati ogni 10 secondi, rimane limitato ed ha picchi elevati soltanto durante l’utilizzo della connessione dati per inviare e ricevere messaggi, che in situazioni normali non dovrebbe impattare in modo considerevole.

L’utilizzo di un payload con i campi strettamente necessari al riconoscimento e all’autoconfigurazione dell’applicazione Android ha consentito di ottenere messaggi di discovery di dimensioni limitate: quelli che i gateway inviano ai client, anche nel caso vengano richiesti al dispositivo tutti i sensori, saranno di circa 550 Byte8. Lo stesso messaggio, utilizzando XML raddoppierebbe la sua dimensione.

Un’ulteriore ottimizzazione ha consentito di ridurre il traffico dati verso il gateway raccogliendo co- stantemente i dati dai sensori e inviandoli in un unico messaggio. In questo modo si è limitato il numero di messaggi da deserializzare all’interno del bundle, il throughput di rete e di conseguenza il consumo di batteria client-side.

L’obiettivo del progetto di questa tesi era quello di realizzare un servizio di discovery che, grazie all’uti- lizzo del protocollo di MQTT, consentisse a dispositivi dalle limitate risorse computazionali di scoprire, connettersi e comunicare con gateway IoT che utilizzano il framework Kura.

Il progetto è stato portato a termine introducendo al contempo diverse ottimizzazioni per migliorare i tempi di risposta dei gateway ed il consumo di batteria lato client.

In fase implementativa sono state prese alcune decisioni che hanno portato ad un miglioramento delle performance delle due applicazioni consentendo la realizzazione di un servizio di discovery MQTT-based che fornisce supporto alla ricerca di gateway in prossimità dello smartphone, realizza un meccanismo di auto-configurazione per l’accesso del dispositivo alla rete WiFi messa a disposizione dal gateway, consente l’invio dei dati application-specific al broker MQTT locale, ed è facilmente configurabile attraverso l’inter- faccia web messa a fornita da Kura.

Dall’analisi dei risultati ottenuti in fase di testing si può dire che il sistema realizzato non presenti proble- mi di scalabilità in condizioni di elevato carico ed abbia un limitato utilizzo di risorse. Questo ne consente l’esecuzione su sistemi con capacità computazionali limitate.

Al termine dell’implementazione sono stati realizzati due componenti: il servizio in esecuzione su Kura e l’applicazione Android.

Il service Kura riceve i messaggi di presenza dei client e, se interessato ai loro sensori, risponde con un messaggio contenente le informazioni per l’auto-configurazione dell’accesso alla rete WiFi. Il service sarà in esecuzione all’interno del framework Kura installato su un Raspberry Pi, che metterà a disposizione dei client un broker MQTT Mosquitto e fungerà da Access Point WiFi.

L’applicazione Android avrà il compito di trovare i gateway nelle vicinanze, connettersi ad uno di questi, ed inviare i dati dei sensori richiesti. L’applicazione realizzata avrà quattro diversi meccanismi per poter eseguire le operazioni richieste: sfrutterà le librerie Paho per realizzare il client MQTT da utilizzare in fase di comunicazione, otterrà le sue coordinate ed i possibili Google Place in cui potrebbe essere localizzato lo smartphone, configurerà l’accesso alla rete WiFi del gateway e si collegherà al broker locale utilizzando le informazioni ricevute in risposta al messaggio di presenza, e raccoglierà i dati dei sensori inviandoli al broker

locale del gateway da intervalli regolari.

In definitiva utilizzando il servizio realizzato sarà possibile trovare un gateway Kura nelle vicinanze del proprio smartphone, connettersi ad esso, e comunicargli i dati dei sensori del dispositivo in modo diretto utilizzando il protocollo MQTT che consente una comunicazione snella anche in condizioni di connettività limitata.

Benché quanto realizzato soddisfi gli obiettivi iniziali, il progetto non è che un punto di partenza. Il discovery in IoT deve tener conto di molti fattori, tra cui gli adattatori di rete disponibili nei vari dispositivi: non tutti gli smart device sono dotati di scheda WiFi o di connessione dati; una futura estensione potrebbe riguardare l’implementazione del servizio di discovery con standard di comunicazione differenti, come ad esempio Bluetooth e, utilizzando MQTT-SN, ZigBee. Queste soluzioni consentirebbero di estendere l’utiliz- zo del servizio anche a dispositivi dalle caratteristiche ancora più limitate di quelle viste in questo progetto e potrebbe essere interessante valutarne le performance.

Un altro sviluppo potrebbe riguardare l’auto-configurazione del bundle Kura in modo da esentare l’am- ministratore dal configurare tutti i parametri. Sarebbe utile, ad esempio, fare in modo che il gateway ad ogni avvio si geolocalizzi o configuri in automatico l’indirizzo del broker locale.

Inoltre potrebbe risultare interessante valutare le performance di una soluzione che preveda l’introduzione di un terzo elemento di architettura che operi in modo simile a quello proposto in fase di analisi, ma che agisca a livello di località riducendo eventuali problemi di scalabilità. Questa soluzione potrebbe prevedere che in caso di presenza dei nodi di località questi ultimi tengano traccia dei gateway nella loro area di copertura e inviino le informazioni ai client in un unico messaggio. Nel caso in cui una località sia sprovvista di nodo centrale, o che quest’ultimo sia momentaneamente guasto, il servizio potrebbe operare come descritto in questo lavoro.