UNIVERSITÀ DI PISA FACOLTÀ DI INGEGNERIA Corso di Laurea Triennale in Ingegneria Informatica Tesi di Laurea Sperimentazione con il Framework SPINE per WSN e Android RELATORI Prof. Marco Avvenuti CANDIDATO Francesco Piras Ing. Mario G.C.A. Cimino Ing. Daniel Cesarini ANNO ACCADEMICO 2011-2012
A mio padre e mia madre che mi hanno permesso di raggiungere questo importante traguardo.
Riassunto analitico L'obiettivo di questa tesi è stato quello di esplorare il framework SPINE (Signal Processing In Node Environment) e testarne il funzionamento per l'acquisizione e l'elaborazione di dati provenienti da WSN (Wireless Sensor Networks), mediante dispositivi mobili con sistema operativo Android, utilizzando il protocollo Bluetooth per la comunicazione. A tal proposito sono state realizzate due semplici applicazioni per testare eettivamente il funzionamento del framework. Una consente di visualizzare su un piano cartesiano XY i dati acquisiti, l'altra produce dei suoni, in base ai dati acquisiti, attraverso l'utilizzo di PureData. La prima parte della tesi consiste in una breve introduzione alle WSN seguita dalla seconda parte nella quale viene descritto il framework SPINE, il sistema operativo Android e l'integrazione dell'uno con l'altro. Questa tesi vuole essere infatti anche una guida alla congurazione e all'utilizzo del framework con il sistema operativo Android in quanto la documentazione a disposizione non tratta esplicitamente l'argomento. La parte nale riguarda la descrizione delle applicazioni delle quali viene illustrato il funzionamento, alcune scelte implementative e i problemi riscontrati durante la fase di realizzazione e di test. In appendice è fornito il codice e il diagramma delle classi dell'applicazione che visualizza su un piano cartesiano XY i dati acquisiti. I
Indice I. Le WSN 1 1. Wireless Sensor Networks 2 II. SPINE e Android 4 2. Introduzione al Framework SPINE 5 2.1. Architettura di SPINE Lato Nodo..................... 5 2.1.1. Comunicazione............................ 7 2.1.1.1. Radio Controller...................... 7 2.1.1.2. Packet Manager...................... 9 2.1.2. Rilevamento.............................. 11 2.1.3. Elaborazione............................. 12 2.1.3.1. Feature Engine....................... 13 2.1.3.2. Alarm Engine....................... 14 2.1.3.3. Altre Funzionalità..................... 14 2.2. Architettura di SPINE Lato Server..................... 15 2.2.1. API oerte da SPINE........................ 16 2.2.1.1. SPINEListener....................... 16 2.2.1.2. SPINEManager....................... 17 3. Android 20 3.1. Architettura.................................. 20 3.2. Componenti Applicativi........................... 22 3.2.1. Activity................................ 22 3.2.2. Services................................ 22 3.2.3. Content Provider........................... 23 3.2.4. Broadcast Receivers......................... 23 3.3. Attivazione dei componenti......................... 23 3.3.1. Intent................................. 23 3.4. Il le Manifest................................ 24 II
Indice 3.5. L'ambiente di sviluppo............................ 24 3.5.1. Struttura di un progetto realizzato con Eclipse.......... 24 4. Utilizzo di SPINE con Android 27 4.1. Congurazione dell'applicazione....................... 27 4.2. Congurazione e attivazione della WSN.................. 28 4.2.1. Congurazione dei sensori...................... 28 4.2.2. Congurazione del Feature Engine Function............ 28 4.2.3. Congurazione, aggiunta e attivazione delle Feature....... 29 4.3. Avvio della WSN e gestione dei dati ricevuti................ 29 III. Le Applicazioni Mobili 30 5. Le Applicazioni 31 5.1. Model-View-Controller............................ 32 5.2. AndroidSPINE................................ 33 5.2.1. Connessione Bluetooth........................ 34 5.2.2. Congurazione della WSN...................... 34 5.2.3. Acquisizione e stampa dei dati................... 34 5.3. SPINESonier................................. 35 5.4. Test e considerazioni............................. 35 IV. Appendice 38 A. Codice 39 B. Diagramma delle classi 52 III
Parte I. Le WSN 1
1. Wireless Sensor Networks Le Wireless Sensor Networks (WSN) rappresentano una tecnologia che introduce una nuova classe di applicazioni e di sistemi per l'elaborazione delle informazioni attraverso reti di sensori. In particolare, le WSN applicate al corpo umano, conosciute come Wireless Body Sensor Networks (WBSN), rappresentano il sistema più adatto per il monitoraggio e il controllo i parametri sici e biomedici provenienti dal corpo umano, così da supportare applicazioni ad alto impatto per una grande varietà di contesti che vedono l'uomo protagonista (Figura 1.1). La caratteristica principale di questo di tipo di reti è l'architettura distribuita della rete stessa, la quale è realizzata mediante un insieme di dispositivi elettronici autonomi in grado di prelevare dati dall'ambiente circostante (o dal corpo umano se si parla di BSN) e di comunicare tra loro. Il progresso tecnologico nel campo dell'elettronica e delle comunicazioni wireless ha permesso lo sviluppo di dispositivi dai costi contenuti, multifunzionali e capaci di comunicare con tecnologia wireless a corto raggio e soprattutto a bassa potenza. Questi dispositivi, chiamati nodi sensore (sensor node o mote), costituiti da uno o più sensori, sono in grado di rilevare grandezze siche (accelerazione, temperatura, umidità ecc.) attraverso dei trasduttori che si trovano a diretto contatto con le grandezze da misurare, elaborare i dati e comunicare tra loro. I nodi sensore all'interno di una rete hanno la possibilità di collaborare tra loro dal momento che sono provvisti di un processore on-board. Grazie a quest'ultimo, ciascun nodo, anziché inviare dati grezzi ai nodi responsabili della raccolta dei dati, può eettuare delle semplici elaborazioni e trasmettere solo i dati richiesti e già elaborati. Esistono dei Sistemi Operativi sviluppati appositamente per le WSN, il più famoso dei quali è TinyOS. La comunicazione, realizzata tramite tecnologia wireless a corto raggio (Bluetooth, IEEE 802.15.4 e ZigBee), è solitamente di tipo asimmetrico in quanto i nodi comuni inviano le informazioni raccolte ad uno o più nodi speciali della rete, detti nodi sink, i quali hanno lo scopo di raccogliere i dati e trasmetterli tipicamente ad un server o ad un calcolatore. Una comunicazione può avvenire autonomamente da parte del nodo quando si verica un dato evento, o può venire indotta dal nodo sink tramite l'invio di una richiesta verso i nodi interessati. Una delle problematiche principali sulla quale si lavora è il consumo energetico. Ogni 2
CAPITOLO 1. WIRELESS SENSOR NETWORKS sensore ha una riserva limitata di energia e questo implica che debba lavorare mantenendo bassi i consumi, in modo da avere un maggiore ciclo di vita. Una delle soluzioni che viene proposta per mediare questo problema, è quella di attivare la radio per la comunicazione solo quando si hanno dei dati da trasmettere anziché tenerla sempre accesa. Figura 1.1.: Wireless Body Sensor Network 3
Parte II. SPINE e Android 4
2. Introduzione al Framework SPINE SPINE (Signal Processing in Node Environment) è un framework per l'implementazione distribuita di algoritmi per l'elaborazione di segnali nelle reti di sensori wireless. Nato dalla collaborazione dell'università della Calabria con società come Telecom Italia, è distribuito con licenza LGPL. Questo framework fornisce un insieme di servizi direttamente eseguibili sui nodi che possono essere settati e attivati in base alle esigenze dell'applicazione che si intende sviluppare. Attualmente è disponibile la versione 1.3 1. Il framework SPINE ha due componenti principali: Lato Nodo: sviluppato con l'ambiente TinyOS2.x, fornisce servizi direttamente sul nodo come il campionamento, la memorizzazione e l'elaborazione dei dati. Lato Server: sviluppato con Java SE, opera come coordinatore della rete di sensori. Gestisce la rete, congura e attiva i servizi sui nodi in base ai requisiti dell'applicazione. 2.1. Architettura di SPINE Lato Nodo Il framework SPINE si deve occupare della comunicazione tra i nodi all'interno della rete, della gestione dei sensori presenti sui nodi e delle funzionalità di elaborazione del segnali. Le funzionalità presenti sui nodi vengono suddivise in tre blocchi logici (Figura 2.1): Comunicazione: si occupa della comunicazione radio e del relativo duty cicle, della costruzione e dell'analisi dei pacchetti, degli schemi di accesso al canale; Rilevamento: Gestisce il campionamento dei dati provenienti dai sensori e del salvataggio in un buer condiviso; Elaborazione: si occupa dell'elaborazione dei dati acquisiti. 1 http://spine.deis.unical.it/spine.html 5
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE Figura 2.1.: Architettura Lato Nodo Il ciclo di vita del Framework SPINE Lato Nodo è gestito dal componente SPINEApp. SPINEApp agisce come tramite fra i moduli sopracitati e in particolare fornisce i seguenti servizi: Non appena viene ricevuto il messaggio di Service Discovery, vengono richieste informazioni riguardo i sensori supportati dal Sensor Board Controller e le funzionalità del Function Manager e in seguito viene restituito al coordinatore il pacchetto Service Advertisement; Vengono smistati i pacchetti in arrivo in base al loro tipo: Messaggi di SetUpSensor ai moduli di rilevamento (Sensor Board Controller); Messaggi di SetUpFunction e ActivateFunction ai moduli di elaborazione (Function Manager) Gestione dei messaggi di start e reset. 6
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE 2.1.1. Comunicazione Lato nodo, la comunicazione è gestita principalmente da due componenti: il Radio Controller e il Packet Manager(Figura 2.2). Figura 2.2.: Modulo per la comunicazione Lato Nodo 2.1.1.1. Radio Controller Il Radio Controller si occupa dell'accesso alla radio e, quando sono attivi, della gestione della modalità low power e dell'accesso al canale tramite lo schema TDMA (Time Division Multiple Access). Quando viene ricevuto il messaggio di start, il nodo viene avviato con la congurazione impostata precedentemente. Nel payload del messaggio di start, l'applicazione Lato Server può settare due dierenti ag: radioalwayson: quando questo parametro è impostato su FALSE, la radio viene spenta se non bisogna inviare nessun messaggio e viene accesa ogniqualvolta il nodo ha un messaggio da inviare. Tuttavia la comunicazione bidirezionale deve essere ancora garantita quindi il Radio Controller implementa la logica per ricevere eventuali messaggi. Dopo l'invio di un messaggio la radio viene tenuta accesa per un certo periodo di tempo in attesa di eventuali messaggi in arrivo (Figura 2.3). Lato Server, se la rete è stata avviata con l'opzione radioalwayson=false e lo SPINEManager ha un messaggio da inviare ad un nodo, memorizza il messaggio nché non riceve un messaggio da quel nodo. Inoltre, il coordinatore aspetta un riscontro da parte del nodo prima di eliminare il messaggio dalla coda, altrimenti prova a ritrasmetterlo (Figura 2.4). 7
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE Figura 2.3.: Comportamento della radio con radioalwayson=false Figura 2.4.: Diagramma di usso del RadioController con radioalwayson=false enabletdma: quando questo parametro è impostato su TRUE, il Radio Controller applicherà lo schema TDMA a tutte le trasmissioni (Figura 2.5). Dunque, ogni volta che dovrà inviare un pacchetto attenderà il prossimo slot di tempo che gli è stato assegnato. Questo potrebbe essere necessario in scenari dove deve es- 8
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE sere inviata una grande quantità di dati al coordinatore da diversi nodi e uno schema CSMA-CD puro potrebbe non essere abbastanza per ottenere una comunicazione adabile. Il messaggio di start fornirà anche il numero totale di nodi presenti nella rete in quel momento. Questa è la ragione per la quale bisogna programmare i nodi con ID sequenziali (1,2,...) e, se necessario, cambiare il TD- MA_FRAME_PERIOD all'interno del Makele, che ha come impostazione predenita 600ms. C'è da notate che nché il coordinatore non sarà assegnato ad un particolare slot, proverà a inviare pacchetti appena possibile, basandosi sullo schema di accesso predenito della base-station (tipicamente CSMA-CA). Figura 2.5.: Esempio di schema TDMA 2.1.1.2. Packet Manager Il Packet Manager si occupa della costruzione e dell'analisi del payload e degli header dei pacchetti SPINE. Inoltre, se necessario, si occupa della frammentazione dei pacchetti prima di inviarli alla radio. In questo modo, ogniqualvolta il Function Manager deve inviare un pacchetto, non si deve preoccupare della lunghezza e chiamare semplicemente PacketManager.build. In seguito il Packet Manager, se necessario, analizza il pacchetto e invia pacchetti multipli. Lato Server, SPINE Manager ricostruirà il pacchetto opportunamente. Da notare che, a questo stadio, il meccanismo non è implementato nell'altra direzione: conseguentemente il Lato Server non potrà mai inviare frammenti dello stesso pacchetto ma dovrà costruire il pacchetto in accordo con la massima dimensione con- 9
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE sentita. Il Packet Manager può occuparsi di dierenti tipi di pacchetti in ingresso e in uscita per quanto concerne le interfacce denite (InPacket con il comando di analisi e OutPacket con il comando di costruzione). SPINE denisce un protocollo bidirezionale per la comunicazione tra il nodo coordinatore e i nodi sensore. Tutti i messaggi hanno lo stesso header il quale viene mostrato di seguito: In particolare, supporta la gestione dei messaggi dal nodo coordinatore agli altri nodi come: Network Discovery: è un pacchetto vuoto mandato in broadcast in modo che possa essere ricevuto da tutti i nodi della rete. Set Up Sensor: contiene le impostazioni per il campionamento necessarie per congurare il sensore. Set Up Function: contiene le impostazioni generali delle quale una funzione necessita. La lista dei parametri è generalmente una lista di byte in modo da essere generica e possa essere utilizzata per diverse funzioni. Active/Deactive Function: contiene i dettagli delle funzionalità che devono essere attivate. La lista dei parametri è una lista generica di array. Start Network: è un pacchetto inviato in broadcast che funziona come interruttore per avviare il campionamento e l'elaborazione sui nodi. Contiene il numero totale dei nodi presenti nella rete (utilizzato sei il TDMA è abilitato) e i ag RadioAlwaysON e enabletdma. 10
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE Dall'altra parte, i nodi sensore possono inviare al coordinatore i seguenti messaggi: Service Advertisement: riporta le informazioni riguardo i sensori e le funzioni supportate dal nodo. Il campo functions è riempito da una specica Function e contiene codici utili per identicare la funzione stessa e altre sotto funzioni se presenti. Data Packet: contiene il tipo di funzione e una lista di byte con i dati specici. È stato pensato per essere generico e per poter essere facilmente utilizzato per qualsiasi tipo di funzionalità. Service Message Packet: usato dai nodi per noticare avvertimenti ed errori che si possono vericare e per altri messaggi informativi di sistema. 2.1.2. Rilevamento Il modulo di Rilevamento è composto da tre componenti principali: il Sensor Registry, il Sensor Board Controller e il Buer Pool (Figura 2.6). 11
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE Figura 2.6.: Modulo di Rilevamento Il Sensor Board Controller gestisce tutti i sensori che sono registrati a SPINE grazie al Sensor Registry,. La sue funzioni principali sono quelle di impostare i parametri dei sensori e acquisire i dati da essi. I dati vengono poi memorizzati in una serie di buer, Buer Pool, in modalità FIFO. Il Buer Pool è impostato dal Makele tramite i parametri BUFFER_POOL_SIZE e BUFFER_LENGTH per allocare un buer per ogni canale di ogni sensore registrato. Per convenienza BUFFER_POOL_SIZE è impostato automaticamente durante l'utilizzo della sensorboard predenita. La parte di rilevamento può essere estesa aggiungendo nuovi sensori per essere supportati da SPINE. 2.1.3. Elaborazione Il modulo di elaborazione è composto da un Function Manager che si occupa della gestione di tutte le funzioni supportate dal nodo(figura 2.7). 12
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE Figura 2.7.: Modulo di Elaborazione Lato Nodo, una generica funzione deve implementare l'interfaccia Function per poter essere gestita dal Funciton Manager. L'interfaccia è stata denita in maniera molto generica, in modo tale che la logica si possa implementare all'interno della funzione. Il Lato Server invia due comandi dierenti al Function Manager (setupfunction e activatefunction) indirizzando delle speciche funzioni e inviando un array generico di parametri che saranno in seguito decodicati dalla funzione implementata. Il pacchetto dati inviato indietro al Lato Server con i valori computati è composto anche esso da un array generico di byte. L'elaborazione delle funzioni potrà ora iniziare dopo la ricezione del messaggio di start proveniente dal Lato Server. 2.1.3.1. Feature Engine I dati raccolti dai sensori presenti sui nodi potrebbero essere inviati al coordinatore senza nessuna elaborazione (raw data) per essere analizzati in seguito Lato Server. Questa non è la procedura migliore in termini di consumo energetico e utilizzo del canale di trasmissione. In alternativa, i dati possono essere elaborati sul nodo e solo il risultato dell'elaborazione viene inviato al coordinatore. Feature Engine di SPINE fornisce calcoli periodici di semplici caratteristiche dei dati acquisiti. L'applicazione Lato Server può richiedere una caratteristica utilizzando due messaggi di setup: un messaggio di congurazione della funzione (SetUpFunction) con i valori della nestra di lavoro e di shift di un dato sensore, e un messaggio di attivazione della funzione con le caratteristiche desiderate per quel sensore. Le caratteristiche includono: AMPLITUDE (Ampiezza), MAX (valore massimo), MEAN 13
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE (valor medio), MIN(valore minimo), MODE (moda), RAW DATA (dati grezzi), STAN- DARD DEVIATION (deviazione standard), TOTAL ENERGY (energia totale) ecc. Le caratteristiche possono essere calcolate sia sui singoli canali che su canali multipli. 2.1.3.2. Alarm Engine Un'altra interessante caratteristica di SPINE è l'alarm Engine. I dati campionati dai sensori presenti sui nodi possono servire al coordinatore solo se rispettano certe condizioni. Tali condizioni possono essere vericate dal nodo stesso e i dati vengono inviati al coordinatore solo quando necessari: questo è lo scopo dell'alarm Engine. Alarm Engine di SPINE fornisce degli eventi generati sul nodo ogni volta che i valori delle funzioni superano le soglie precedentemente impostate. Gli allarmi possono essere impostati su tutte le caratteristiche supportate, inclusi i dati grezzi, specicando la dimensione della nestra e dello shift oltre i parametri specici per l'allarme. Alarm Engine fornisce notiche per quattro tipi diversi di allarmi su tutte le caratteristiche disponibili sul nodo(figura 2.8). Figura 2.8.: Tipi di allarme 2.1.3.3. Altre Funzionalità SPINE ore delle altre funzionalità come Step Counter. Step Counter è una funzione predenita che, utilizzando i dati provenienti da un accelerometro contenuto dentro un nodo che viene posizionato sulla vita di una persona, conta i passi durante una camminata. Una volta attivato, viene inviata una notica al coordinatore ogni volta che viene rilevato un passo. 14
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE 2.2. Architettura di SPINE Lato Server Il Lato Server ha una struttura tale da permettere di separare la logica del framework dal tipo di rete con la quale deve comunicare cioè il core di SPINE non utilizza alcuna API specica e può essere utilizzato in maniera indipendente dallo stack protocollare sottostante (Figura 2.9). Il framework supporta diversi tipi di nodi quali Telosb, Tmote, Micaz, Shimmer e permettere inoltre l'emulazione dei nodi grazie all'applicazione SPINE Node Emulator. Sempre per quanto riguarda il Lato Server, il framework fornisce delle semplici API Java per lo sviluppo delle applicazioni. Pertanto il punto di forza del framework SPINE è il fatto di consentire al programmatore Lato Server di sviluppare applicazioni per le reti di sensori senza doversi preoccupare della programmazione Lato Nodo. Ciò che è richiesto lato Java allo sviluppatore è di implementare l'interfaccia SPINEListener utilizzando le API fornite dalla classe SPINEManager che verranno trattate in seguito nello specico. Figura 2.9.: Architettura Lato Server Il codice Lato Server è organizzanto nel seguente modo: spine: contiene il core logico di SPINE; spine.datamodel: package che contiene i modelli di dati utilizzati dal Framework; spine.datamodel.functions: sub-package che denisce le strutture delle funzioni; 15
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE spine.datamodel.servicemessages: sub-package che denisce i messaggi di servizio; spine.exceptions: SPINE. sub-package contenente la classe di eccezioni lanciate da Il Lato Server di SPINE fornisce un'implementazione per le reti TinyOS2.x, per le reti Virtual Sersor Network e per la comunicazione via Bluetooth. Inoltre fornisce il supporto per la comunicazione a basso livello con TinyOS: spine.communication.tinyos: contiene la logica e le procedure per la comunicazione a basso livello speciche per TinyOS (chiamando le API da tinyos.jar); spine.payload.codec.tinyos: sub-package contenente i codec dei messaggi a basso livello per la piattaforma TinyOS; per la comunicazione a basso livello con SPINE Node Emulator: spine.communication.emu: contiene la logica e le procedure per la comunicazione a basso livello per Virtual Sensor Node; spine.payload.codec.emu: sub-package contenente i codec dei messaggi a basso livello per Virtual Sensor Node; e per la comunicazione via Bluetooth: spine.communication.bt: contiene la logica e le procedure per la comunicazione a basso livello tramite il protocollo Bluetooth. Grazie a questo package è possibile implementare la comunicazione via Bluetooth utilizzando librerie diverse in base alle esigenze del programmatore e in base alla piattaforma utilizzata (es. Android); spine.payload.codec.bt: sub-package contenente i codec dei messaggi a basso livello per il protocollo Bluetooth. 2.2.1. API oerte da SPINE Come già accennato, quello che deve fare lo sviluppatore Lato Server, è di implementare l'interfaccia SPINEListener utilizzando le API fornite da SPINEManager. 2.2.1.1. SPINEListener L'interfaccia SPINEListener fornisce i seguenti metodi: void received(data data) 16
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE È invocato dallo SPINEManager per i suoi listener registrati quando riceve dei dati da un nodo specico. L'oggetto Node che ha generato l'oggetto Data è contenuto all'interno dell'oggetto Data stesso. void discoverycompleted(java.util.vector activenodes) È invocato dallo SPINEManager per i suoi listener registrati quando il timer della procedura di discovery si esaurisce. void newnodediscovered(node newnode) È invocato dallo SPINEManager per i suoi listener registrati quando riceve un messaggio di ServiceAdvertisement da un nodo della WSN. void received(servicemessage msg) È invocato dallo SPINEManager per i suoi listener registrati quando riceve un ServiceMessage da un nodo specico. L'oggetto Node che ha generato l'oggetto ServiceMessage è contenuto all'interno dell'oggetto ServiceMessage stesso. 2.2.1.2. SPINEManager La classe SPINEManager fornisce i seguenti metodi: void activate(node node, SpineFunctionReq functionreq) Attiva una funzione (o una sotto-funzione) su un determinato sensore. void addlistener(spinelistener listener) Registra uno SPINEListenerRegisters all'istanza di SPINEManager. void bootupwsn() Non fa niente. void deactivate(node node, SpineFunctionReq functionreq) Disattiva una funzione (o una sotto-funzione) su un determinato sensore. void discoverywsn() Ordina allo SPINEManager di eettuare un discovery dei nodi della WSN. void discoverywsn(long timeout) Ordina allo SPINEManager di eettuare un discovery dei nodi della WSN con un determinato timeout. 17
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE java.util.vector getactivenodes() Restituisce la lista dei nodi attivi come un Vector di spine.datamodel.node. spine.datamodel.node getbasestation() Restituisce il nodo che rappresenta la BaseStation. Jade.util.Logger static getlogger() Restituisce il Logger statico del Framework SPINE. Il Logger può essere utilizzato per impostare il livello di logging e la gestione personalizzata (ad esempio scrivere i log su un le). spine.datamodel.node getnodebylogicalid(spine.datamodel.address id) Restituisce un nodo con un determinato indirizzo logico. spine.datamodel.node getnodebyphysicalid(spine.datamodel.address id) Restituisce un nodo con un determinato indirizzo sico. void getoneshotdata(node node, byte sensorcode) Impone ad un determinato nodo il campionamento immediato al primo colpo su un dato sensore. boolean isstarted() Restituisce TRUE se allo SPINEManger è stato richiesto di iniziare l'elaborazione nella WSN. void removelistener(spinelistener listener) Rimuove uno SPINEListener dall'istanza dello SPINEManager. void resetwsn() Impone un reset software dell'intera WSN. void setdiscoveryproceduretimeout(long discoverytimeout) Imposta il timeout per la procedura di discovery. void setup(node node, SpineSetupFunction setupfunction) Imposta una specica funzione su un dato nodo. void setup(node node, SpineSetupSensor setupsensor) Imposta uno specico sensore su un dato nodo. 18
CAPITOLO 2. INTRODUZIONE AL FRAMEWORK SPINE void startwsn(boolean radioalwayson) Avvia la WSN ed elabora le precedenti richieste di impostazione delle funzioni. void startwsn(boolean radioalwayson, boolean enabletdma) Avvia la WSN e elabora le precedenti richieste di impostazione delle funzioni. void syncwsn() Ordina una sincronizzazione software della WSN basata sul clock locale dei nodi. L'istanza dello SPINEManager può essere recuperata solo attraverso SPINEFactory: SPINEManager createspinemanager(string apppropertiesfile) Inizializza lo SPINEManager. I parametri di inizializzazione vengono ottenuti attraverso il le app.properties. 19
3. Android Android è un sistema operativo per dispositivi mobili, basato su kernel Linux, che comprende un sistema operativo di base, dei middleware e le applicazioni di base. Creato da Google in collaborazione con l'open Handset Alliance, un gruppo di 79 aziende che lavorano per lo sviluppo e l'innovazione nel settore mobile, Android è la prima piattaforma completa e Open Source per lo sviluppo di applicazioni mobili. Il progetto nasce nel 2005, viene proposto agli sviluppatori nel 2007 e inizia ad aermarsi a partire dal 2009 dopo la prima versione rilasciata il 23 settembre 2008. Google ha allestito un sito di E-Commerce che funge da punto di incontro tra gli sviluppatori e gli utilizzatori dei dispositivi mobili. Inizialmente diuso con il nome di Android Market, dal 6 marzo 2012 è stato rinominato in Google Play. Su tutti i dispositivi è preinstallata l'applicazione che permette l'accesso a questo servizio attraverso il quale gli utenti possono cercare e scaricare software e altro materiale (gratuitamente o a pagamento). 3.1. Architettura Android è, insieme, un sistema operativo, una piattaforma di sviluppo e una collezione di software di base per l'utilizzo di dispositivi mobili. È un sistema operativo di ultima generazione e quindi abbastanza complesso la cui architettura (Figura 3.1) non ha niente da invidiare ai comuni sistemi operativi presenti su computer desktop e laptop. 20
CAPITOLO 3. ANDROID Figura 3.1.: Architettura di Android Android è bastato sul kernel Linux versione 2.6 (versione 3.x da Android 4.0 in poi). All'interno dello strato del kernel sono presenti i driver per il controllo dei componenti hardware del dispositivo come tastiera, schermo, touch screen, Bluetooth, WiFi, audio ecc. Sopra il kernel si trova lo strato dell'architettura che contiene le librerie fondamentali ereditate dal mondo Open Source come le OpenGL, SQLite e WebKit. Android fa uso di una macchina virtuale (Dalvik Virtual Machine) per l'esecuzione delle applicazioni che insieme ad una libreria fondamentale costituiscono la piattaforma di sviluppo. Durante il processo di compilazione il programma che costituisce l'applicazione viene trasformato in un codice intermedio chiamato bytecode (come avviene con Java) che verrà poi eseguito sulla Dalvik Virtual Machine. Essendo tale macchina virtuale uguale per tutti i dispositivi Android, le applicazioni potranno essere seguite su qualsiasi dispositivo indipendentemente dall'hardware. Nel penultimo strato dell'architettura è possibile individuare i gestori e le applicazioni di base del sistema. Nello strato più in alto dell'architettura sono presenti gli applicativi utilizzabili dall'utente. 21
CAPITOLO 3. ANDROID 3.2. Componenti Applicativi I componenti applicativi sono i blocchi costruttivi essenziali per lo sviluppo di un'appliazione Android. Ci sono quattro tipi di compenenti applicativi fondamentali ognuno dei quali svolge un ruolo diverso per il funzionamento dell'applicazione, ha un proprio ciclo di vita e può essere attivato individualmente. 3.2.1. Activity Una Activity rappresenta una singola schermata con un'interfaccia utente. Tramite essa l'utente può interagire con l'applicazione per compiere operazioni come scattare una foto, leggere un'email, o visualizzare una mappa. Solitamente un'applicazione è costituita da più Activity una delle quali è nominata come main e viene mostrata all'utente quando viene lanciata l'applicazione. Ogni Activity può avviare altre Activity per compiere diverse operazioni. Quando una Activity viene avviata, quella precedente viene sospesa e viene conservata dal sistema in una pila (Black Stack). Quando questo avviene, l'activity che sta per essere sospesa può invocare dei metodi, che fanno parte del suo ciclo di vita, per noticare il cambiamento di stato e per svolgere delle operazioni come ad esempio il rilascio di alcuni oggetti non più necessari. Il sistema operativo stesso può decidere di terminare una Activity che era stata sospesa, se ad esempio la memoria è insuciente. Non appena una Activity viene creata, viene inserita nella pila e viene mostrata all'utente. Essendo la pila una struttura dati che adotta la losoa last in, rst out, quando viene premuto il tasto Indietro, viene mostrata l'ultima Activity che era stata sospesa. Le Activity si realizzano estendendo la classe Activity. 3.2.2. Services Un Service è un componente applicativo che svolge operazioni in background e non fornisce un'interfaccia utente. Un altro componente applicativo può avviare un Service che continua ad essere eseguito in background anche quando l'utente utilizza un'altra applicazione. Un Service può assumere essenzialmente due forme: Started: un Service assume questa forma quando un'applicazione lo avvia chiamando il metodo startservice(). Una volta avviato viene eseguito in background no a quando non viene distrutto, svolge le operazioni richieste e solitamente non restituisce niente al chiamante. Bound: un Service assume questa forma quando un'applicazione lo avvia chiamando il metodo bindservice(). Quando un Service è avviato in questo modo ore 22
CAPITOLO 3. ANDROID un'interfaccia client-server ai componenti che voglio interagire esso ed è eseguito solo nché viene eseguito il componente applicativo al quale è associato I Service si realizzano estendendo la classe Service. 3.2.3. Content Provider I Content Provider gestiscono l'accesso a insieme di dati strutturati. Orono l'incapsulamento dei dati e meccanismi per denire la sicurezza. I Content Provider sono l'interfaccia standard per la condivisione dei dati tra le applicazioni altrimenti inaccessibili per motivi di sicurezza. Un processo può segnalare al sistema di essere un Content Provider di alcune informazioni: grazie a delle speciche API di Android sarà possibile accedere a queste informazioni secondo le modalità specicate (sola lettura, lettura e scrittura). Un esempio di Content Provider è l'elenco dei contatti presenti sul telefono. Un'applicazione, con i permessi necessari, può accedere all'elenco dei contatti per leggere e scrivere informazioni. 3.2.4. Broadcast Receivers Un Braodcast Receiver è un componente che risponde a degli annunci broadcast di sistema. La maggior parte dei broadcast sono generati dal sistema come ad esempio l'avviso che il livello di carica della batteria è basso oppure che lo schermo è stato spento. Anche le applicazioni possono generare dei broadcast per informare le altre applicazioni su qualcosa. Sebbene non dispongano di un'interfaccia graca, essi possono generare una notica che apparirà nella barra di stato per informare l'utente su un evento che si è vericato. Più comunemente, i Broadcast Receiver sono utilizzati come punti di passaggio fra i componenti applicativi. 3.3. Attivazione dei componenti 3.3.1. Intent Tre dei quattro componenti applicativi - Activity, Service e Broadcast Receiver - vengono attivati da un messaggio asincrono chiamato Intent. L'Intent associa i vari componenti l'uno con l'altro a tempo di esecuzione sia che essi appartengano alla stessa applicazione o ad un'altra. Grazie all'intent, Android diventa un sistema interconnesso composto da componenti indipendenti in grado di comunicare l'uno con l'altro. L'Intent permette di lanciare Activity o Service, trasmettere informazioni riguardo eventi che si sono vericati, supportare l'interazione tra le applicazioni installate sul dispositivo. 23
CAPITOLO 3. ANDROID 3.4. Il le Manifest Prima che il sistema Android possa avviare un componente applicativo, il sistema deve sapere che il componente esiste leggendo il le AndroidManifest.xml dell'applicazione. Tutti i componenti presenti nell'applicazione devono essere dichiarati in questo le, il quale si deve trovare della cartella principale del progetto. Inoltre il le ha il compito di: Identicare tutti i permessi utente che l'applicazione richiede Dichiarare il minino API Level richiesto dall'applicazione Dichiarare le caratteristiche software e hardware richieste Librerie API che l'applicazione necessita per essere collegate opportunamente 3.5. L'ambiente di sviluppo Le applicazioni Android sono sviluppate utilizzando un framework che fornisce un'opportuna struttura di supporto sulla quale le applicazioni possono essere organizzate e progettate. Le applicazioni possono essere facilmente progettare e realizzate grazie all'ausilio di un IDE (Integrated Development Environment) come ad esempio Eclipse 1, con integrato il plug-in ADT (Android Developer Tools) che fornisce tra le tante cose gli strumenti di sviluppo per Android (SDK) 2. Le applicazioni Android sono caratterizzate da una parte dinamica rappresentata dai le scritti in linguaggio Java e da una parte statica rappresentata dai le scritti in XML utilizzati per denire il layout. Le applicazioni vengono generalmente distribuite sotto forma di le.apk che permettono l'installazione delle stesse sul dispositivo (sulla memoria interna o scheda SD). Per lo sviluppo delle applicazioni è disponibile una documentazione completa 3. 3.5.1. Struttura di un progetto realizzato con Eclipse La struttura di un progetto realizzato con l'ide Eclipse è rappresentata nella Figura 3.2. 1 http://www.eclipse.org/ 2 http://developer.android.com/sdk/index.html 3 http://developer.android.com/develop/index.html 24
CAPITOLO 3. ANDROID Figura 3.2.: Struttura di un progetto realizzato con Eclipse La cartella src/ contiene il codice sorgente dell'applicazione; La cartella gen/ vine generata durante la compilazione del progetto e contiene alcuni le generati automaticamente da Eclipse; Le Android Dependencies/ contengono ulteriori librerie esterne necessarie per l'applicazione; La cartella assets/ contiene altri le statici che saranno impacchettati nell'applicazione; La cartella bin/ contiene l'applicazione una volta compilata; La cartella libs/ contiene i le jar di terze parti di cui l'applicazione necessita; 25
CAPITOLO 3. ANDROID La cartella res/ contiene le risorse dell'applicazione, come ad esempio il layout dell'interfaccia graca, il le delle stringhe e quello delle preferenze; Il le AndroidManifest.xml descrive come l'applicazione deve essere costruita e quali componenti, Activity e Service sono forniti dall'applicazione; 26
4. Utilizzo di SPINE con Android Come già visto, il framework SPINE fornisce, Lato Server, delle semplici API Java per lo sviluppo di applicazioni con il ruolo di coordinatore. Grazie a questa caratteristica, è stato possibile eettuare il porting del framework sulla piattaforma Android modicando solo le parti relative alla comunicazione via Bluetooth, all'accesso al le system e poche altre cose utilizzando le API speciche per Android, lasciando inalterato il core del Framework. 4.1. Congurazione dell'applicazione Per la corretta esecuzione delle applicazioni che utilizzano SPINE su dispositivi Android, è necessario congurare opportunamente alcuni le e cartelle durante la fase di sviluppo: Aggiungere il le app.properties alla cartella assets. All'interno del le occorre settare i parametri PLATFORM=bt e BT_NETWORK_SIZE=1 per l'utilizzo del Bluetooth. Modicare il le AndroidManifest.xml inserendo le seguenti righe per settare i permessi per l'utilizzo del Bluetooth e per il riconoscimento di SPINE da parte dell'applicazione: <m a n i f e s t... <uses p e r m i s s i o n android : name="android. p e r m i s s i o n.bluetooth_admin"/> <uses p e r m i s s i o n android : name="android. p e r m i s s i o n.bluetooth" />... <a p p l i c a t i o n... android : name="s p i n e. u t i l s. ResourceManagerApplication " >... </ a p p l i c a t i o n > </manifest > Se non esiste, creare la cartella libs dentro il progetto, all'interno della quale andranno messe le librerie esterne (contenute in dei le.jar) le quali dovranno essere aggiunte al Build Path. In particolare occorre che il le spineandroid.jar 1 si trovi all'interno di questa cartella e sia aggiunto al Build Path. 1 http://spine-project.googlecode.com/les/spineandroid.jar 27
CAPITOLO 4. UTILIZZO DI SPINE CON ANDROID 4.2. Congurazione e attivazione della WSN Una volta ottenuta l'istanza della classe SPINEManager tramite SPINEFactory manager = SPINEFactory.createSPINEManager(appPropertiesFile); che viene salvata all'interno dell'istanza della classe che implementa l'interfaccia SPINEListener, la quale a sua volta andrà registrata all'istanza della classe SPINEManager appena ottenuta manager.addlistener(this); si può procedere alla congurazione e all'attivazione della WSN. Bisogna inviare un messaggio di Network Discovery in broadcast per ottenere la lista dei nodi che compongono la rete e i relativi servizi oerti manager.discoverywsn(); Quando la procedura di discovery è stata completata, viene richiamata la funzione discoverycompleted(vector activenodes). A questo punto bisogna congurare i nodi, i sensori e le relative funzioni opportunamente. 4.2.1. Congurazione dei sensori Supponendo di voler congurare il sensore accelerometro con un determinato SAMPLE_TIME espresso in millisecondi, si procede nel seguente modo: SpineSetupSensor sss = new SpineSetupSensor(); sss.setsensor(spinesensorconstants.acc_sensor); sss.settimescale(spinesensorconstants.millisec); sss.setsamplingtime(sample_time); manager.setup(node, sss); 4.2.2. Congurazione del Feature Engine Function Supponendo di voler settare una determinata WINDOW_SIZE e SHIFT_SIZE per il sensore accelerometro, si procede nel seguente modo: FeatureSpineSetupFunction ssf = new FeatureSpineSetupFunction(); ssf.setsensor(spinesensorconstants.acc_sensor); ssf.setwindowsize(window_size); 28
CAPITOLO 4. UTILIZZO DI SPINE CON ANDROID ssf.setshiftsize(shift_size); manager.setup(node, ssf); 4.2.3. Congurazione, aggiunta e attivazione delle Feature Supponendo di voler aggiungere la funzione che calcola il modulo dell'accelerazione (AMPLITUDE) per i dati provenienti dal sensore accelerometro (su tre assi) si procede nel seguente modo: FeatureSpineFunctionReq sfr = new FeatureSpineFunctionReq(); sfr.setsensor(spinesensorconstants.acc_sensor); sfr.add(new Feature(SPINEFunctionConstants.AMPLITUDE, ((Sensor) curr.getsensorslist().elementat(0)).getchannelbitmask())); manager.activate(node, sfr); 4.3. Avvio della WSN e gestione dei dati ricevuti Dopo aver congurato tutti i nodi e i sensori presenti sui nodi si può avviare la WSN con le impostazioni desiderate per i parametri radioalwayson e enabletdma: manager.startwsn(true, true); Una volta avviata la WSN, viene invocata la funzione received(data data) ogniqualvolta viene ricevuto un dato proveniente da un nodo della rete. Sui dati ricevuti, già elaborati sul nodo, si possono compiere ulteriori elaborazioni oppure si possono utilizzare direttamente ai ni dell'applicazione. Il seguente esempio mostra come estrarre dati utili contenuti nell'oggetto Data. public void received ( Data data ) { switch ( data. getfunctioncode () ) { case SPINEFunctionConstants. FEATURE : { Node source = data. getnode () ; Feature [] feats = (( FeatureData ) data ). getfeatures () ; Feature firsfeat = feats [0]; byte sensor = firsfeat. getsensorcode () ; byte featcode = firsfeat. getfeaturecode () ; int ch1value = firsfeat. getch1value () ; break ; default : break ; 29
Parte III. Le Applicazioni Mobili 30
5. Le Applicazioni Sono state realizzate due semplici applicazioni, Lato Server, per testare il funzionamento del framework SPINE. Queste possono essere considerate la base per applicazioni future più sosticate e consistenti, grazie alle numerose funzionalità messe a disposizione dal framework SPINE e dal SDK di Android. Lato Nodo non è stato necessario realizzare alcuna applicazione poiché è stata utilizzata l'applicazione SPINEApp, realizzata dal team che ha sviluppato il framework, la quale può essere caricata su tutti i nodi compatibili e le cui funzionalità oerte da essa possono essere congurate e attivate direttamente Lato Server. I nodi sensore utilizzati sono gli Shimmer2R con accelerometro (Figura 5.1). La piattaforma Shimmer è stata introdotta in SPINE grazie al contributo di Pering Trevor del laboratorio di ricerca della Intel. Attualmente è supportato il sensore accelerometro su tre assi. Figura 5.1.: Nodo sensore Shimmer2R 31
CAPITOLO 5. LE APPLICAZIONI 5.1. Model-View-Controller Le applicazioni sono state progettate utilizzando il pattern Model-View-Controller (Figura 5.2). Figura 5.2.: Model-View-Controller L'architettura del MVC è stata pensata per permettere la separazione tra i moduli che gestiscono il modo di presentare i dati e i moduli che gestiscono i dati stessi. Infatti grazie a questo pattern è stato possibile separare l'interfaccia graca (in generale il modulo di output dei dati) dal modulo per l'acquisizione e l'elaborazione dei dati. In questo modo è risultato abbastanza facile sostituire l'output di tipo graco con l'output di tipo sonoro. I moduli del MVC hanno le seguenti caratteristiche: MODEL Denisce i dati e le operazioni che possono essere eseguite su di essi. Denisce quindi le regole per l'interazione con i dati da parte della View e del Controller, rispettivamente per l'accesso e l'aggiornamento. Inne il Model può avere la responsabilità di noticare alla View eventuali aggiornamenti sui dati, magari in seguito a richieste del Controller, in modo da fornire all'utente dati sempre aggiornati. 32
CAPITOLO 5. LE APPLICAZIONI VIEW Denisce la logica di presentazione dei dati. Si occupa quindi della costruzione dell'interfaccia graca attraverso la quale l'utente visualizza i dati e interagisce con l'applicazione. I dati vengono aggiornati attraverso delle notiche da parte del Model (Push Model). La View delega al Controller l'esecuzione dei comandi richiesti dall'utente. CONTROLLER Ha il compito di trasformare le interazione dell'utente con la View in azioni eseguite dal Model. Il Controller non rappresenta solo un ponte tra Model e View ma implementa la logica di controllo dell'applicazione. Tuttavia il pattern è stato modicato per adattarlo alle esigenze delle applicazioni che verranno esposte in seguito. 5.2. AndroidSPINE L'applicazione AndroidSPINE (Figura 5.3) ore le seguenti funzionalità: Connessione Bluetooth con i nodi sensore Congurazione (statica) della WSN Acquisizione dei dati e stampa su graco cartesiano utilizzando le librerie AndroidPlot 1 1 http://www.androidplot.com Figura 5.3.: AndroidSPINE 33