Progetto Ardomotica: Studio di Fattibilità Finalizzato ... · rete WiFi, sia effettuata in modo...

Università degli Studi della Basilicata DIPARTIMENTO DI MATEMATICA, INFORMATICA ED ECONOMIA

1 di 23

Progetto Ardomotica: Studio di Fattibilità Finalizzato allo Studio, Sviluppo e Sperimentazione di un Framework per Applicazioni Domotiche Multidispositivo

Relazione Finale

Sommario Questo documento descrive le attività condotte nell’arco del progetto. E’ organizzato secondo le tre fasi previste dal programma, e per ciascuna fase riassume le attività svolte e i risultati conseguiti. La terza parte ha una particolare rilevanza, in quanto (a) riassume le specifiche funzionali finali concordate con il committente; (b) descrive i prodotti, le relative tecnologie e metodi; (c) sintetizza alcune possibili estensioni future dei prodotti. Per concludere, in appendice al documento è riportato una descrizione dei passi da compiere da parte di futuri utenti che vogliano utilizzare gli strumenti sviluppati.

Fase 1 – Documento di visione Obiettivi Questa sezione sintetizza le attività svolte nel corso della Fase 1 del contratto, ovvero la fase di analisi delle tecnologie, al termine della quale era prevista “la redazione di un documento con le scelte tecnologiche per l’implementazione del sistema”.

Il documento riassume quanto emerso a valle del primo incontro organizzato da Basilicata Innovazione con gli imprenditori coinvolti, e delle attività di analisi, studio, prima implementazione e test condotti presso il Dipartimento.

Approfondimento della Specifica Nel corso della riunione presso la sede di Basilicata Innovazione il giorno 15 gennaio 2015 sono stati approfonditi alcuni aspetti relativi alle specifiche funzionali del progetto.

E’ stata confermata l’impostazione concordata in fase di stipula del contratto, ovvero la realizzazione di un framework per la realizzazione di applicazioni domotiche multidispositivo basata sull’utilizzo di chip programmabili per applicazioni di tipo embedded. Il framework deve avere le seguenti caratteristiche:

• consentire alle applicazioni client di acquisire valori a partire dal sensori configurati sul chip;

• consentire alle applicazioni client di comandare il funzionamento degli attuatori configurati sul chip;


2 di 23

• consentire la configurazione del chip e la sua connessione alla rete;

• consentire lo sviluppo rapido delle applicazioni client, con particolare riferimento alle applicazioni su piattaforma mobile (Android e iOS).

Nel corso della riunione sono emersi i seguenti requisiti funzionali aggiuntivi:

1. è opportuno concentrarsi su chip della famiglia Arduino, evitando dispositivi di fascia più alta come Raspberry Pi;

2. il chip sarà collegato alla rete WiFi, di cui si assume la disponibilità nell’abitazione in cui viene installato il dispositivo domotico; nel caso in cui questa condizione non sia verificata, sono possibili due soluzioni:

A. offrire al cliente anche la fornitura degli apparati di rete;

B. consentire il controllo del dispositivo con una modalità secondaria (per esempio attraverso un telecomando a radiofrequenza).

3. è importante che la configurazione del chip, ed in particolare la sua connessione alla rete WiFi, sia effettuata in modo estremamente semplificato, per semplificare le operazioni di installazione del dispositivo, e gli eventuali aggiornamenti dovuti alle evoluzioni della rete domestica;

4. sarebbe auspicabile che, oltre al controllo locale attraverso il terminale mobile collegato alla rete WiFi domestica, il dispositivo possa essere controllato anche da remoto attraverso la rete Internet.

Attività Svolte nel Corso della Prima Fase Nel corso della prima fase del progetto sono state svolte attività di studio, analisi e implementazione prototipale finalizzate ad assumere le scelte tecnologiche per la corretta implementazione dei requisiti.

Riportiamo di seguito quanto emerso da queste attività. Configurazione Rapida

La modalità di configurazione immaginata consiste nel predisporre una scheda SD contenente i parametri di configurazione, inserirla nel lettore di schede del chip Arduino, ed effettuare il reset in modo da forzare l’inizializzazione del chip.

Verrà realizzata un’applicazione desktop, facilmente eseguibile dall’operatore che effettua l’installazione sul proprio notebook Windows, Mac o Linux, per scrivere i parametri di configurazione sulla scheda.

I parametri configurabili saranno:

• descrizione e natura degli ingressi (sensori);

• descrizione e natura delle uscite (attuatori);


3 di 23

• parametri per la connessione alla rete WiFi domestica, ed in particolare:

• nome della rete, modalità di protezione e password di accesso;

• strategia di assegnazione dell’indirizzo IP (DHCP o indirizzo manuale);

• IP del gateway, se necessario;

• IP del DNS, se necessario;

• subnet mask, se necessaria;

• password per l’esecuzione di comandi sul dispositivo; questa misura sembra opportuna per evitare che chiunque ottiene una connessione alla rete WiFi possa comandare il dispositivo domotico.

La procedura di configurazione dovrebbe quindi svolgersi rapidamente e con limitato impatto sulle operazioni di installazione. Risulta necessario che il chip Arduino sia dotato di lettore di schede SD. Operazioni di Discovery sulla Rete

Una volta configurato il chip Arduino in modo che si connetta al rete WiFi domestica, è necessario risolvere il problema della connessione dal dispositivo client (es: smartphone). E’ possibile assumere che il dispositivo client conosca l’indirizzo IP del chip Arduino se questo è fisso. Nel caso in cui questo sia dinamico, viceversa, è necessario adottare un protocollo di discovery dinamico sulla rete.

A questo scopo è possibile adottare la suite di protocolli Zero Configuration Network1, ed in particolare la nota implementazione Bonjour2. Esistono implementazioni del protocollo Bonjour per Arduino configurato con il WiFi shield3. Dai test che abbiamo effettuato, questo consente l’individuazione rapida del chip Arduino da parte del client, e quindi la connessione ai servizi. Controllo del Chip via Internet

Un problema decisamente più complesso è rappresentato viceversa dal controllo del chip a distanza attraverso la rete Internet.

Sono state esplorate due vie per risolvere questo problema, che per natura è simile a quello dei sistemi di videosorveglianza via Internet.

Soluzione n.1 : Indirizzo IP pubblico - La prima soluzione è configurare il chip Arduino in modo che ottenga dalla rete domestica un indirizzo IP pubblico. Il vantaggio di questa soluzione è che, una volta completata la configurazione dell’IP pubblico, la connessione

1 http://en.wikipedia.org/wiki/Zero-configuration_networking 2 http://en.wikipedia.org/wiki/Bonjour_%28software%29 3 https://github.com/adafruit/CC3000_MDNS


4 di 23

da parte del client è piuttosto semplice, e richiede solamente che l’utente configuri nel client (es: smartphone) una volta per tutte l’indirizzo in questione. Da quel momento non ci sono più differenze tra connessioni locali e connessioni remote.

Purtroppo, però, l’ottenimento di un IP pubblico è una operazione che spesso ha costi aggiuntivi da parte del provider, e complica decisamente le operazioni di configurazione iniziale del dispositivo domotico e di connessione alla rete. Oltre ad accertarsi che il provider fornisca il servizio di IP pubblico, infatti, è tipicamente necessario intervenire sul router della rete domestica per configurare il cosiddetto NAT (l’inoltro dei pacchetti dalla rete esterna al chip con IP pubblico nella rete interna). Questa operazione potrebbe non essere alla portata dell’installatore del dispositivo domotico.

Soluzione n.2 : Server Pubblico - In alternativa, per evitare questi problemi di configurazione, è possibile adottare soluzioni architetturali più sofisticate, in cui il chip Arduino e il dispositivo client comunicano entrambi con un server raggiungibile ad un IP pubblico. Questo elimina i problemi di configurazione elencati sopra, ma introduce ovviamente costi di gestione decisamente più alti, collegati alla gestione del server. Per un’azienda che non lavori nel settore IP, sembra improbabile la gestione in house di servizi di questo tipo. E’ possibile appoggiarsi a fornitori di servizio, ma questo inciderebbe negativamente sui costi della soluzione.

Alla luce dell’analisi di costi e benefici delle due soluzioni, la decisione su quella da adottare è stata rimandata ad un’ulteriore interazione con gli imprenditori coinvolti.

Selezione del Chip Arduino

Arduino è una famiglia di chip programmabili, con diverse caratteristiche e potenzialità. Il dispositivo originale, chiamato Arduino Uno, ha le seguenti caratteristiche (fonte http://arduino.cc/en/Main/arduinoBoardUno): Microcontroller ATmega328

Operating Voltage 5V

Input Voltage (recommended) 7-12V

Input Voltage (limits) 6-20V

Digital I/O Pins 14 (of which 6 provide PWM output)

Analog Input Pins 6

DC Current per I/O Pin 40 mA

DC Current for 3.3V Pin 50 mA

Flash Memory 32 KB (ATmega328), 0.5 KB used by bootloader

SRAM 2 KB (ATmega328)

EEPROM 1 KB (ATmega328)


5 di 23

Clock Speed 16 MHz

Length 68.6 mm

Width 53.4 mm

Weight 25 g

Abbiamo enfatizzato la dotazione di memoria RAM, che nei nostri test iniziale si è rivelata critica. Arduino, infatti, viene microprogrammato in un dialetto del linguaggio C. Come in tutte le applicazioni scritte in C, il microcodice deve essere linkato alle librerie necessarie. Nel nostro caso, queste sono:

• la libreria per le operazioni sulla scheda SD;

• la libreria per il collegamento alla rete WiFi (dal punto di vista hardware, sia la scheda SD, sia la scheda WiFi sono forniti come estensioni - o “shield” - del chip di base);

• la libreria per il protocollo Bonjour.

A queste tre librerie deve essere aggiunto il codice necessario per microprogrammare Arduino a svolgere le operazioni richieste dal framework.

Una volta compilato e collegato, il codice deve essere caricato nella RAM di Arduino. Purtroppo, le tre librerie da sole saturano o addirittura superano la dotazione di RAM di 32KB.

Di conseguenza, Arduino Uno non è adatto a questo tipo di applicazioni.

La nostra scelta è caduta invece su Arduino Mega 2560, una variante più potente del chip le cui caratteristiche sono riportate di seguito (fonte: http://arduino.cc/en/Main/ArduinoBoardMega2560): Microcontroller ATmega2560

Operating Voltage 5V

Input Voltage (recommended) 7-12V

Input Voltage (limits) 6-20V

Digital I/O Pins 54 (of which 15 provide PWM output)

Analog Input Pins 16

DC Current per I/O Pin 40 mA

DC Current for 3.3V Pin 50 mA

Flash Memory 256 KB of which 8 KB used by bootloader

SRAM 8 KB

EEPROM 4 KB

Clock Speed 16 MHz


6 di 23

Arduino Mega 2560 sembra un buon compromesso tra le caratteristiche hardware, specialmente la dotazione di RAM che sale a 256KB, e il costo, inferiore a quello di dispositivi di fascia più alta come Arduino Due o Arduino Yun.

Attività Programmate per la Fase Successiva Completate queste verifiche iniziali, è stato programmato di avviare nella seconda fase l’implementazione del framework secondo le seguenti specifiche tecniche:

• utilizzo del chip Arduino Mega 2560, più shield WiFi;

• configurazione attraverso scheda SD;

• connessione alla rete WiFi e discovery attraverso il protocollo Bonjour;

• comando da dispositivi mobili/desktop appartenenti alla stessa rete WiFi.

Fase 2 – Documento di Progetto Obiettivi Questa sezione sintetizza le attività previste per la Fase 2 del contratto, ovvero la fase di costruzione, al termine della quale è stata prevista “la redazione di un documento di progetto” con le scelte tecnologiche definitive.

Il documento riassume quanto emerso a valle del secondo incontro organizzato da Basilicata Innovazione con gli imprenditori coinvolti per la discussione del primo prototipo realizzato dal Dipartimento.

Stato dell’Arte e Attività Svolte nella Seconda Fase Nel corso della riunione presso il Laboratorio ICAR del Dipartimento di Matematica, Informatica ed Economia del giorno 19 marzo 2015 è stata mostrata agli imprenditori la prima versione del prototipo del sistema di controllo a distanza basato su Arduino realizzato nella seconda fase del progetto.

Il primo prototipo consiste in:

• Un dispositivo Arduino Mega completo di shield WiFi con lettore di schede microSD, configurato con 6 led di diversi colori per simulare 6 output (es: le 6 velocità del motore di aspirazione) e 2 input (un sensore di temperatura e un sensore di luminosità), ed alimentato con una batteria standard da 5V;

• La prima versione del framework lato Arduino, completo per la configurazione e gestione dei comandi a distanza per comandare gli output e leggere i valori degli input;


7 di 23

• L’applicazione desktop in Java per l’installazione ed il test del dispositivo in rete locale. Il client Java consente: (a) di configurare facilmente il comportamento del dispositivo Arduino attraverso l’utilizzo di un file di configurazione salvato sulla scheda SD, come previsto dalle specifiche; (b) di effettuare il test delle 6 uscite e degli ingressi una volta connesso il dispositivo alla rete.

E’ stata fornita agli imprenditori una dimostrazione completa del funzionamento del caso d’uso di configurazione e test del dispositivo in rete locale. Il test di accettazione ha dato esito positivo, dal momento che gli imprenditori hanno riscontrato che il prototipo risponde alle specifiche funzionali concordate per questa prima dimostrazione.

Affinamento dei Requisiti Nel corso della riunione sono stati confermati i requisiti da implementare in vista del rilascio definitivo:

1. è necessario sviluppare le applicazioni clienti su piattaforma mobile Android e iOS;

2. è necessario sviluppare la logica applicativa per il controllo del dispositivo via Internet.

Sono inoltre emersi alcuni requisiti aggiuntivi:

3. è opportuno prevedere la possibilità di eseguire comandi temporizzati, ovvero attivazione di output a distanza di X secondi dall’invio del comando.

Infine, sarà necessario effettuare alcune attività conclusive di pre-ingegnerizzazione:

1. è necessario svolgere test di stress del dispositivo per verificare l’affidabilità della connessione prolungata alla rete;

2. sarebbe opportuno svolgere un test di integrazione installando il dispositivo su un apparato domotico reale (ad esempio un reale aspiratore), per verificare la funzionalità complessiva della soluzione;

3. sarebbe opportuno verificare la tenuta della rete WiFi installata in una reale abitazione (ad esempio, in cima ad un camino), per selezionare lo shield più appropriato ed eventualmente prevedere soluzioni aggiuntive per il miglioramento del segnale.

Scelte di Progetto per la Terza Fase Di seguito vengono riportate le scelte di progetto relative all’implementazione dei requisiti 1-3 elencati sopra. Comandi Temporizzati

Il chip ATmega 2560 con cui è equipaggiato Arduino Mega dispone di vari timer hardware. E’ possibile utilizzare questi timer per l’esecuzione di comandi temporizzati.


8 di 23

Oltre alle due categorie di comandi (URL) già previsti (/write e /read), verrà introdotta una terza categoria denominata “output temporizzato” (/timedWrite). A differenza degli output standard, gli output temporizzati prevederanno la specifica di un parametro nella query string (“timer”) per specificare il ritardo in secondi dopo il quale eseguire il comando.

Per quanto, in linea di massima, sia possibile prevedere l’utilizzo di diversi timer, questo rischia di confondere l’utente. In altri termini, appare molto più naturale l’utilizzo di un unico timer, secondo questo caso d’suo:

• l’utente invia al dispositivo Arduino un comando temporizzato, specificando l’attivazione di un output dopo x secondi (es: alle 12:00 viene inviato il comando “accendi il motore a velocità 3 tra 2 ore”);

• dopo x secondi, il dispositivo Arduino esegue il comando (es: alle 14:00 viene acceso il motore a velocità 3), e il timer viene resettato ed è pronto ad accettare ulteriori comandi;

• prima che siano trascorsi gli x secondi, l’utente può annullare il comando inviato precedentemente; in questo caso, il comando non viene eseguito da Arduino;

• se, prima degli x secondi, l’utente invia un ulteriore comando temporizzato (es: alle 12:30 viene inviato il comando “accendi il motore a velocità 4 tra 1 ora”), il comando precedente viene annullato, e viene temporizzato il nuovo comando (in questo caso il motore verrà acceso direttamente a velocità 4 alle 13:30).

In aggiunta, l’utente avrà la possibilità di interrogare il dispositivo Arduino in qualsiasi momento per sapere se c’è un comando temporizzato in corso di esecuzione, e l’orario previsto per la sua esecuzione. Controllo via Internet

Il controllo via Internet è l’aspetto più delicato dal punto di vista infrastrutturale. Già nel corso della prima fase di progetto è stata scartata l’ipotesi di utilizzare un IP pubblico per la connessione di Arduino alla rete (questa soluzione rischierebbe di essere troppo complessa dal punto di vista sistemistico in fase di installazione).

Di conseguenza, abbiamo optato per una soluzione basata su server pubblico Internet e infrastruttura di tipo “publish ed subscribe”. In questa architettura, il server funge da intermediario tra il client ed Arduino, che non possono comunicare direttamente. In sintesi:

• il client (es: applicazione Android) invia i comandi al server, che li registra in una cache, denominata “canale”; il canale è riservato alla comunicazione con lo specifico dispositivo Arduino;


9 di 23

• Arduino consulta periodicamente il canale connettendosi al server, ed ottiene i messaggi; li esegue e può rispondere fornendo a sua volta informazioni (ad esempio la lettura degli input).

Il processo è diverso da quello sincrono che avviene in rete locale, dove il client effettua direttamente la connessione con Arduino, invia i comandi, ed ottiene immediatamente le risposte. E’ invece un processo “asincrono”, in cui il canale fornisce il buffer di memorizzazione per lo scambio di messaggi.

E’ quindi evidente che la logica applicativa, sia del dispositivo, sia dei client, è completamente diversa nei due casi. Sarà quindi necessario:

• Sviluppare due implementazioni distinte della comunicazione sul dispositivo, una per il controllo “locale”, l’altra per il controllo “internet”;

• La tipologia di controllo potrà essere scelta come parte della configurazione iniziale del dispositivo; una volta configurato in un senso o nell’altro, il dispositivo potrà accettare esclusivamente comandi in locale oppure via internet. Verrà fornito un comando opportuno per effettuare dinamicamente lo switch tra una modalità e l’altra, utile per ragioni di sicurezza o controllo dei costi.

• Analogamente, sarà necessario implementare due diverse interfacce nei client: una per il controllo in locale, l’altra per il controllo via Internet (ad esempio attraverso due diversi “tab” nello schermo principale di controllo).

Si noti che la soluzione di controllo via Internet è decisamente più generale rispetto a quella di controllo locale, ma anche più costosa.

Da una parte, richiede che gli utenti abbiano un accesso Internet. Da questo punto di vista, soprattutto in vista della possibilità che i dispositivi vengano installati in abitazioni in cui non c’è un accesso Internet, pare opportuno rendere disponibile comunque il controllo in rete locale. Questa sarebbe l’unica soluzione nel caso in cui il dispositivo domotico fosse installato in un’abitazione priva di rete locale, e quindi fosse necessario fornire anche l’access point WiFi.

Dall’altra parte, per il controllo via Internet è necessaria la disponibilità di un server pubblico con una disponibilità di banda potenzialmente piuttosto alta, dal momento che ogni dispositivo Arduino deve essere in grado di aprire connessioni persistenti al server. Questo è un aspetto molto delicato. E’ legittimo attendersi che, una volta commercializzata la soluzione, in una fase iniziale il numero di dispositivi installati sia piuttosto basso, e di conseguenza sia sufficiente un server di fascia medio-bassa con banda piuttosto limitata. Al crescere dei dispositivi, viceversa, il carico per il server potrebbe crescere piuttosto


10 di 23

significativamente, fino a raggiungere alcune migliaia di connessioni simultanee (una per dispositivo installato) e quindi una capacità di elaborazione e una banda decisamente più significative.

Il rapporto tra efficacia della soluzione e costi di realizzazione ci pare l’aspetto più delicato. A questo proposito, abbiamo cercato di trovare la soluzione di miglior compromesso. A nostro avviso, invece di realizzare in casa il server ed il servizio di publish and subscribe, è opportuno affidarsi ad una soluzione on demand, ad esempio PubNub (http://www.pubnub.com/). L’adozione di un servizio come PubNub ha notevoli vantaggi:

• consente l’accesso ad un data center e ad una infrastruttura di comunicazione ad alta affidabilità;

• fornisce la possibilità di sperimentare gratuitamente la soluzione durante la fase di sviluppo;

• ha costi accessibili al crescere del numero di messaggi scambiati e del numero di dispositivi (http://www.pubnub.com/pricing/);

• fornisce una libreria per l’utilizzo con Arduino.

Nella fase finale del progetto, verrà quindi sviluppata una soluzione di controllo via Internet basata su PubNub. Applicazioni Mobile

L’attività conclusiva consisterà nella realizzazione dei client per dispositivi mobile. Alla luce dello sviluppo del framework, lo sviluppo delle applicazioni mobile non richiede particolari scelte tecnologiche. La logica applicativa delle applicazioni mobile rispecchierà piuttosto fedelmente quella dell’applicazione desktop di test. Verrà prevista la doppia funzionalità (controllo locale e controllo via Internet).

Attività Programmate per la Fase Successiva Alla luce delle scelte progettuali discusse in questa relazione ed in quella della fase precedente, la terza fase è stata dedicata allo sviluppo del prototipo finale.

Contemporaneamente sono stati effettuati i test di stress e di affidabilità della soluzione in laboratorio.

Fase Finale Riassunto delle Specifiche Nel corso delle precedenti fasi di progetto erano state concordate le seguenti specifiche funzionali per il controllo a distanza di dispositivi domotici.


11 di 23

• I dispositivi vengono controllati con un chip Arduino collegato alla rete WiFi domestica, ai cui pin sono collegati gli ingressi e le uscite del dispositivo da controllare.

• Sul dispositivo Arduino gira il framework per la configurazione e la gestione dei comandi a distanza per attivare gli output e leggere i valori degli input. Il framework è scritto in forma generica, e cioè indipendente dagli specifici ingressi ed uscite del dispositivo.

• Il dispositivo Arduino viene configurato all’installazione da un tecnico che utilizza un’applicazione desktop sul proprio notebook per scegliere i parametri di configurazione e generare il file per la configurazione di Arduino. Il file viene salvato su una scheda microSD, che viene inserita nel dispositivo. All’attivazione, Arduino consulta i parametri contenuti nel file e si configura automaticamente per l’utilizzo. Anche la configurazione è pensata per essere generica, e consente di configurare ingressi e uscite di diverso tipo.

• Gli utenti utilizzano client multipiattaforma per comandare il dispositivo. I client da sviluppare sono:

o Client desktop basato su tecnologia Java (integrato nell’applicazione di configurazione), per l’utilizzo su personal computer.

o Client mobile basato su piattaforma Android.

o Client mobile basato su piattaforma iOS.

• I client devono consentire di eseguire i seguenti comandi:

o Comandi di lettura dei sensori e dello stato del dispositivo (es: valore della temperatura, motore acceso o spento e velocità)

o Comandi di attivazione del dispositivo (es: accendi il motore a velocità 2, solleva l’avvolgibile ecc.)

o Comandi di attivazione del dispositivo, ovvero comandi di attivazione in cui viene fornita la data e un’ora in cui il comando deve essere eseguito.

o Comandi di consultazione della temporizzazione del dispositivo, per scoprire se c’è o meno un comando temporizzato.

o Comandi per annullare la temporizzazione.

• I comandi devono essere inviati attraverso la piattaforma Internet. Viene fornita anche la possibilità di eseguire comandi contattando direttamente il dispositivo attraverso la rete locale.

Scelte di Progetto


12 di 23

Per l’implementazione dei requisiti elencati sono state fatte le seguenti scelte di progetto.

Configurazione del Chip Arduino Per ragioni di memoria, è stato scelto di utilizzare dispositivi della tipologia Arduino Mega 2560, una variante più potente del chip Arduino originale (cosiddetto “Uno”) le cui caratteristiche sono riportate a questo indirizzo: .http://arduino.cc/en/Main/ArduinoBoardMega2560.

Il dispositivo Arduino deve essere equipaggiato con uno shield WiFi e un lettore di schede SD. Per ragioni di robustezza, supporto e compatibilità con le librerie utilizzate, è stato scelto lo shield WiFi ufficiale Arduino, che include anche il lettore di schede SD.

Soluzione di Controllo via Internet Per il controllo via Internet è stata sviluppata una soluzione basata su un’infrastruttura cloud di tipo “publish ed subscribe”. In questa architettura, è necessario un server che funge da intermediario tra il client ed Arduino, che non possono comunicare direttamente. In sintesi:

• il client (es: applicazione Android) invia i comandi al server, che li registra in una cache, denominata “canale”; il canale è riservato alla comunicazione con lo specifico dispositivo Arduino;

• Arduino consulta periodicamente il canale connettendosi al server, ed ottiene i messaggi; li esegue e può rispondere fornendo a sua volta informazioni (ad esempio la lettura degli input).

Per garantire il miglior rapporto possibile tra efficacia della soluzione e costi di realizzazione è stato selezionato il fornitore di servizi PubNub (http://www.pubnub.com/). L’adozione di un servizio come PubNub ha notevoli vantaggi:

• consente l’accesso ad un data center e ad una infrastruttura di comunicazione ad alta affidabilità;

• ha costi accessibili al crescere del numero di messaggi scambiati e del numero di dispositivi (http://www.pubnub.com/pricing/);

• fornisce librerie per l’utilizzo con tutte le piattaforme utilizzate nel progetto (Arduino, Java/Android, iOS).

Soluzione di Controllo in Locale Il processo di esecuzione dei comandi per la modalità Internet – che è un processo “asincrono”, in cui il canale fornisce il buffer di memorizzazione per lo scambio di messaggi – è diverso da quello sincrono che avviene in rete locale, dove il client effettua


13 di 23

direttamente la connessione http con Arduino, invia i comandi, ed ottiene immediatamente le risposte.

Il framework implementa quindi due implementazioni distinte della comunicazione sul dispositivo, una per il controllo “locale”, l’altra per il controllo “internet”. La tipologia di controllo viene scelta come parte della configurazione iniziale del dispositivo; una volta configurato in un senso o nell’altro, il dispositivo potrà accettare esclusivamente comandi in locale oppure via internet. Analogamente, i client forniscono due modalità di comandi, una per il controllo in locale, l’altra per il controllo via Internet.

Si noti che, per via di vincoli tecnici legati alla tecnologia Arduino, per l’esecuzione di comandi in locale utilizzando lo shield WiFi ufficiale Arduino è necessario che il client conosca il numero IP del dispositivo. Non esiste, infatti, una libreria Bonjour/mDNS per lo shield WiFi.4

Sintassi dei Comandi Supportati dalle Librerie Per lo sviluppo semplificato dei client, sono state sviluppate due librerie. Una libreria Java, orientata allo sviluppo dei client Java desktop e Android, e una libreria iOS. Le librerie sono integrate con il framework che gira su Arduino, e supportano le seguenti tipologie di comandi.

Comandi via Internet Per cominciare, tutti i comandi Internet hanno un token, che consente di correlare richieste e risposte in modo asincrono, ed una password, che caratterizza il dispositivo ed impedisce ad estranei l’accesso. Arduino non sopporta la comunicazione attraverso il protocollo crittografato SSL, per cui la password viene inviata in chiaro.

• /read/-temp&phot&pote&token=T0001&password=xxx

i comandi di lettura sono caratterizzati dal prefisso /read, e dall’elenco dei sensori e degli attuatori di cui si vuole leggere lo stato; in risposta ad un comando di lettura, viene restituito lo stato di tutti i sensori ed attuatori richiesti.

In risposta al comando, Arduino pubblica sul canale un messaggio di risposta in formato JSon che contiene il valore di tutti i sensori e gli attuatori richiesti, oppure un messaggio di tipo ERROR nel caso in cui il comando sia scorretto. In caso di successo, il messaggio ha la forma:

{message: temp_25&phot=256&pote=1024, token: T0001}

4 Altri shield WiFi – come quello CC3300 di AdaFruit, pure sperimentato nel corso del progetto – supportano il protocollo Bonjour ma non dispongono di una libreria per PubNub. Peraltro, lo shield AdaFruit ha dimostrato una stabilità inferiore rispetto a quella dello shielde WiFi ufficiale.


14 di 23

Nel caso in cui ci sia un comando temporizzato in corso (come descritto sotto), in risposta al messaggio viene fornito anche lo stato del temporizzatore (comando temporizzato e scadenza): {message: temp_25&phot=256&pote=1024&timer=5000&pin0=1, token: T0001}

• /write/-pin_0=1&pin_1=1&pin_2=1&pin_3=1&…&token=T0001&password=xxx

i comandi di scrittura immediata sono caratterizzati dal prefisso /write, e dall’elenco degli attuatori di cui modificare lo stato, con il valore da assegnare.

In risposta al comando, Arduino pubblica sul canale un messaggio di risposta del tipo SUCCESS o ERROR, a seconda che sia riuscito o meno ad eseguire il comando.

• /timedWrite/-timer=10&led_0=1&led_1=1&led_2=1&…&token=T0001&password=xxx

i comandi di scrittura temporizzati sono caratterizzati dal prefisso /timedWrite, dal valore del timer (in secondi) dopo cui eseguire il comando, e dall’elenco degli attuatori di cui modificare lo stato, con il valore da assegnare. Alla ricezione del comando, Arduino avvia un conto alla rovescia, ed esegue il comando quando il numero di secondi specificati scade.

Il numero di secondi è un valore di tipo long, e quindi consente di temporizzare comandi a distanza di anni.

Per annullare la temporizzazione in corso è sufficiente inviare un comando di temporizzazione con un valore del timer pari a 0; /timedWrite/-timer=0& token=T0001&password=xxx

In risposta al comando, Arduino risponde con un messaggio di tipo SUCCESS o ERROR.

Comandi Locali I comandi inviati attraverso la rete locale utilizzano il protocollo http e, di norma, la porta 80. E’ possibile configurare Arduino in modo da utilizzare una porta alternativa. Il client invia quindi il comando eseguendo una richiesta http di tipo GET, e Arduino risponde fornendo una risposta http standard.

I comandi locali sono quindi eseguiti in modalità sincrona, e quindi non utilizzano token. Non utilizzano nemmeno password, perché si suppone che sia la rete WiFi a cui Arduino è collegato ad essere già protetta da password.

I comandi hanno la seguente sintassi:

• http://ipNumber/read/-temp&phot&pote


15 di 23

In risposta al comando, Arduino produce una risposta http il cui corpo contiene il valore di tutti i sensori e gli attuatori richiesti, oppure un messaggio di tipo ERROR nel caso in cui il comando sia scorretto. In caso di successo, il messaggio ha la forma:

temp_25&phot=256&pote=1024

Anche in questo caso, se c’è un comando temporizzato in corso (come descritto sotto), in risposta al messaggio viene fornito anche lo stato del temporizzatore (comando temporizzato e scadenza): temp_25&phot=256&pote=1024&timer=5000&pin0=1, token: T0001}

• http://ipNumber/write/-pin_0=1&pin_1=1&pin_2=1&pin_3=1&…

In risposta al comando, Arduino genera una risposta http di SUCCESS o ERROR, a seconda che sia riuscito o meno ad eseguire il comando.

• http://ipNumber/timedWrite/-timer=10&led_0=1&led_1=1&led_2=1&…

In risposta al comando, Arduino risponde con un messaggio di tipo SUCCESS o ERROR.

Applicazioni Client E’ stata sviluppata un’applicazione Java Desktop basata sulla libreria per la configurazione rapida del dispositivo. Di seguito è illustrata l’interfaccia per la configurazione del dispositivo. La configurazione mostrata si riferisce al caso di studio selezionato per questo progetto, ovvero il controllo di un aspiratore per camini che può funzionare a 6 velocità. In questo caso, le sei velocità dell’aspiratore sono simulate da sei led, numerati da 0 a 5. In aggiunta sul dispositivo Arduino sono stati configurati un sensore di temperatura, un sensore di luminosità e un potenziometro.


16 di 23

Sono poi state sviluppate tre applicazioni client per il controllo del dispositivo. Le applicazioni client sono forzatamente meno generiche, e si riferiscono specificamente al caso di studio dell’aspiratore di camini.

Applicazione Client Java Desktop Di seguito viene mostrata l’interfaccia dell’applicazione desktop in Java per il controllo dell’aspiratore:


17 di 23

Applicazione Client Android L’applicazione client Android è già disponibile sul Play Store con il nome “Ardomotica”. Di seguito vengono riportati alcuni screenshot. Per attivare una specifica velocità, è sufficiente utilizzare il bottone corrispondente. Per attivare un comando temporizzato, è sufficiente tenere premuto il bottone corrispondente, e compare il selettore della data e dell’orario. I restanti bottoni della toolbar consentono di aggiornare lo stato del dispositivo (leggendo temperatura e velocità, oltre che verificare se ci sono comandi temporizzati), spegnere il dispositivo, e annullare il comando temporizzato.

L’applicazione è completamente internazionalizzata nelle lingue italiano e inglese.

Attraverso la configurazione è possibile stabilire il modo di connessione al dispositivo (Internet o locale), nonché i parametri per la connessione (nome del dispositivo e password per la modalità Internet, o numero IP per la modalità locale).

L’app è sviluppata secondo i canoni del “responsive design” e del “material design” di Google.


18 di 23

Applicazione Client iOS Per l’applicazione iOS valgono molte delle considerazioni fatte per l’applicazione Android, con la differenza che il click prolungato non è un gesto tipico della piattaforma iOS. Di conseguenza, coerentemente con i canoni delle appi OS, per l’invio di comandi immediati e temporizzati sono stati previsti due diversi tab.


19 di 23

Test di Stress e Affidabilità Nel corso del progetto sono stati effettuati numerosi test di stress per valutare l’affidabilità della soluzione. I test sono stati effettuati in due modalità:

• nella modalità di produzione, con Arduino Mega e shield WiFi, tanto in modalità Internet, tanto in modalità locale;

• in una modalità di test in cui Arduino Mega è stato configurato con uno shield Ethernet, invece che WiFi. Questo secondo test è stato utile per valutare più


20 di 23

propriamente la stabilità della soluzione software, utilizzando una tecnologia di rete più stabile e più veloce.

In entrambe le configurazioni la soluzione sviluppata ha dato eccellenti risultati di affidabilità, riuscendo a gestire decine di migliaia di messaggi nell’arco di vari giorni senza malfunzionamenti.

Nella soluzione su rete Ethernet, la percentuale di successo è stata praticamente del 100%, e i tempi di risposta eccellenti, dell’ordine di pochi secondi anche per comandi Internet complessi. Dal punto di vista dei tempi di risposta, la soluzione WiFi ha fornito tempi di risposta più lenti, occasionalmente nell’ordine della decina di secondi, soprattutto in condizioni di rete sovraccarica. In una piccola percentuale di casi, stimabile in meno dell’1%, questo può provocare timeout che causano il fallimento del comando e la conseguente segnalazione di errore all’utente, che quindi deve ritentare l’esecuzione.

Possibili Sviluppi Futuri Il caso di studio adottato in questo progetto verrà sottoposto ad un test finale di integrazione in modo da verificare concretamente eventuali problemi di carattere hardware e meccanico legati al comando di un aspiratore reale.

Nel caso in cui la tecnologia sviluppata nell’ambito del progetto dovesse essere selezionata per la produzione, alcuni sviluppi ulteriori paiono particolarmente interessanti.

Per cominciare, potrebbe essere sperimentata una soluzione in cui Arduino controlla il dispositivo domotico attraverso segnali in radiofrequenza. Questo avrebbe il vantaggio di evitare il collegamento fisico di Arduino al dispositivo per pilotare gli attuatori e leggere i sensori, e quindi renderebbe Arduino un telecomando a distanza intelligente per il dispositivo. In questo modo, il posizionamento di Arduino nell’abitazione sarebbe più agevole, anche e soprattutto per garantire una migliore connessione alla rete WiFi domestica. Per l’implementazione di una soluzione di questo tipo è necessario equipaggiare Arduino con uno shield per la radiofrequenza, e studiare la modulazione dei segnali da e verso il dispositivo domotico.

La seconda estensione interessante consiste nel consentire, in aggiunta ai comandi temporizzati, una programmazione settimanale del dispositivo domotico (del tipo “ogni lunedì alle 10.00 attiva il motore alla velocità 2, e spegnilo dopo due ore”). Per farlo, è necessario equipaggiare Arduino con uno shield RTC (“real time clock”), e sviluppare la logica applicativa per la programmazione settimanale.


21 di 23

L’ultima estensione consiste nell’introdurre ulteriore logica applicativa nel dispositivo per reagire autonomamente a condizioni programmate dall’utente. Ad esempio attivare il motore quando la temperature supera un certo valore. Questa funzionalità pare particolarmente interessante se viene sviluppata, come il resto del framework sotto forma di un linguaggio di regole generale, indipendentemente dalla specifica applicazione. Per farlo, è però necessaria una valutazione attenta delle scelte tecnologiche, dal momento che, a causa delle limitazioni di risorse di calcolo, Arduino Mega potrebbe non essere il dispositivo più adatto.

Potenza, 11 maggio 2015

Prof. Giansalvatore Mecca

Appendice

Manuale Rapido per l’Adozione del Framework Di seguito vengono riassunte le attività che un utente deve poter eseguire per utilizzare il framework in contesti applicativi diversi dal caso di studio di questo progetto.

Attività n.1: Progettazione dell’Interazione con il Dispositivo

Il primo passo da fare è progettare lo scenario di controllo domotico. Dal punto di vista dell’utilizzo del framework, questo consiste nello scegliere le uscite, ovvero i comandi di scrittura da inviare al dispositivo, e gli ingressi, ovvero i comandi di lettura. Ad esempio: supponiamo che un’azienda intenda consentire il controllo via internet delle luci di casa. Potrebbe pensare di associare:

• un comando di uscita digitale a ciascun punto luce tradizionale che ammette solo lo stato acceso spento (es: luceCucina, luceCorridoio, luceBagno);

• un comando di uscita analogico per il punto luce del soggiorno, che supponiamo essere dotato di potenziometro, e quindi consente vari stati (luce spenta, luce bassa, luce media, luce alta, luce massima)

• un comando di ingresso analogico al sensore di luminosità per conoscere la luminosità dell’ambiente.

Una volta progettati gli ingressi e le uscite, è ovviamente necessario progettare i collegamenti hardware del chip Arduino ai dispositivi da comandare. In questo caso è possibile pensare che il chip Arduino venga collocato in un quadro a parete a cui arrivano


22 di 23

gli interruttori di comando di tutte le luci, e che questi siano collegati opportunamente ai pin del chip.

Attività n.2: Configurazione del Framework

Il passo successivo consiste nella configurazione del framework a bordo del chip Arduino perché reagisca correttamente ai comandi di ingresso e di uscita progettati al passo precedente. Questo passo è piuttosto banale, e può essere facilmente condotto utilizzando l’applicazione desktop client scritta in Java, che consente di specificare facilmente i parametri di configurazione per il framework, come mostrato nelle figure riportate nelle pagine precedenti. In particolare:

• parametri per la connessione alla rete WiFi domestica;

• parametri per l’accesso a PubNub (questi vengono forniti non appena l’azienda registra il proprio account PubNub);

• parametri di configurazione per i comandi di ingresso e di uscita.

Questi parametri devono essere salvati in un file CONFIG.TXT su una scheda microsd da inserire nel lettore di schede del chip arduino.

Attività n.3: Accensione e Primo Test di Arduino

Una volta acceso o ripristinato il chip Arduino si collega alla rete WiFi, stabilisce i canali di comunicazione con PubNub, e si mette in attesa di comandi. Tutto il processo di inizializzazione avviene in modo del tutto automatico sulla base del file di configurazione generato al passo precedente.

Effettuata l’inizializzazione, è subito possibile svolgere un test rapido del funzionamento di Arduino. Questo può essere fatto utilizzando la sintassi dei comandi descritta nelle sezioni precedenti. Nel nostro esempio, supponendo di conoscere il numero IP del chip Arduino, è subito possibile digitare nella barra degli indirizzi di un qualsiasi browser il comando: http://ipNumber/write/-luceCucina=1

e verificare che la luce della cucina si accenda. Per effettuare un test rapido del controllo via Internet è possibile utilizzare la console messa a disposizione dal PubNub all’indirizzo http://www.pubnub.com/console/ ; specificando i corretti parametri di configurazione è possibile inviare comandi analoghi al dispositivo, ad esempio: /timedWrite/-timer=10&luceBagno=1&token=T0001&password=xxx

per spegnere la luce del bagno dopo 10 secondi. A questo punto, il dispositivo è pienamente funzionale.

Attività n.4: Sviluppo delle Applicazioni Client


23 di 23

Il passo più oneroso dell’intera operazione consiste nell’adeguare alla nuova logica applicativa le tre applicazioni client. Sarebbe stato possibile, in linea di principio, sviluppare app generiche per il controllo di Arduino, ovvero app che consentissero di inviare comandi arbitrari indipendentemente dallo scenario applicativo.

Abbiamo però volutamente evitato di farlo. E’ infatti improbabile che un utente si accontenti di un’app anonima che non sia opportunamente caratterizzata dal punto di vista grafico e dotata di quegli elementi di usabilità che tutti consideriamo importanti per definire la nostra percezione della qualità dell’applicazione.

Di conseguenza, adottare in framework in un nuovo contesto applicativo richiede di adeguare gli schermi delle applicazioni client sviluppate e mostrate nelle pagine precedenti. Ad esempio, nel caso del controllo delle luci, sarebbe molto più naturale che i comandi fossero inviati attraverso uno schermo in cui è disegnata una schematica pianta della casa, con un’indicazione dei vari locali (cucina, bagno, soggiorno, corridoio) e per ciascuno un pulsante per inviare il comando.

Si noti però che lo sviluppo del codice è stato opportunamente organizzato anche sul lato client in modo da fornire una libreria generica per la connessione a PubNub, l’invio di comandi e la ricezione delle risposte. Questo codice può essere riutilizzato ovviamente senza alcuna modifica. Si tratta quindi esclusivamente di adeguare gli schermi dell’app, senza necessità di intervenire in modo pesante sulla logica di backend. Queste modifiche possono essere fatte in pochi giorni da un programmatore esperto.

Progetto Ardomotica: Studio di Fattibilità Finalizzato ... · rete WiFi, sia effettuata in modo...

Documents

Transcript of Progetto Ardomotica: Studio di Fattibilità Finalizzato ... · rete WiFi, sia effettuata in modo...