2.3 CloudSensor
In questa sezione viene illustrato un sistema, chiamato CloudSensor, che permette la rilevazione di dati ambientali da dispositivi mobili Android e la loro pubblicazione sul server SOS.
Come già discusso nella precedente sezione, il SOS e il SPS forniscono un middleware che permette all'applicazione cliente di comandare l'acquisizione di dati e recuperare dal database tali dati senza doversi interfacciare diret- tamente con i vari sensori. Il CloudSensor è anch'esso un middleware che si con gura come l'astrazione di una rete dinamica di sensori i cui nodi sono i vari sensori incorporati all'interno degli smartphone.
L'architettura del sistema presenta due componenti distinte: il Cloud- Sensor Service (CSS) e il CloudSensor Acquisition and Management System (CSAMS). Il CSS costituisce il front-end del sistema, eseguito su un calco- latore sso, mentre il CSAMS è l'applicazione in esecuzione sul terminale mobile.
CSS
Il CSS è un servizio web, accessibile attraverso il protocollo HTTP, che of- fre un sottoinsieme delle operazioni rese disponibili da SOS e SPS. È formato da tre componenti:
• Naming Service: gestisce i binding <numero telefonico, indirizzo IP>, che devono essere periodicamente aggiornati in quanto l'indi- rizzo IP assegnato ad uno smartphone non è statico. Ogni richiesta indirizzata ad un dispositivo mobile, identi cato dal numero di telefo- no, implica quindi un'interrogazione del Naming Server per ottenere il corrispondente indirizzo IP.
• SPS Plugin: strato software di mediazione tra SPS e dispositivi mobi- li, implementa gli handler delle operazioni SPS supportate dal sistema (registrazione del sensore, Submit e Cancel).
• SOS Plugin: riceve le osservazioni grezze da CSAMS, le codi ca in documenti XML (secondo le speci che del SWE) e le invia al SOS. Il lato server del CloudSensor è quindi composto dalle tre componenti proprie del CSS e dalle istanze dei servizi web SOS e SPS, come mostrato in Figu- ra 2.8. Le applicazioni clienti comunicano direttamente con i servizi SOS e SPS, mentre l'applicazione CSAMS si interfaccia con il CSS.
2.3. CLOUDSENSOR
Figura 2.8: Architettura CloudSensor
CSAMS
Il CSAMS ha il compito di gestire i singoli sensori installati sullo smart- phone, sia in fase di attivazione che in fase di produzione dati. CSAMS mette a disposizione del possessore dello smartphone un'interfaccia gra ca che con- sente di speci care una serie di parametri per la gestione delle rilevazioni, come ad esempio la massima frequenza con cui queste possono avvenire, e selezionare quali sensori rendere accessibili al mondo esterno; si è quindi nel- l'ambito del participatory sensing.
Una volta avviato il sistema, i sensori selezionati vengono registrati al SOS e al SPS, attraverso la comunicazione con gli appositi plugin, e sono dunque accessibili da parte di un'applicazione cliente; in particolare, possono essere attivati a generare osservazioni tramite l'operazione di submit SPS. Il SPS Plugin gestisce tale richiesta e la inoltra al CSAMS, che esegue uno studio di fattibilità per veri care se dispone delle risorse necessarie ad eseguire il task richiesto; in caso positivo avvia il rilevamento dati. I dati raccolti sono inviati tramite query string al SOS Plugin, che provvederà all'inserimento nel database del SOS.
Riassumendo, i compiti del CSAMS sono i seguenti:
• Registrazione dei sensori supportati a SOS e SPS in fase di bootstrap dell'applicazione.
2.3. CLOUDSENSOR • Chiamate alle librerie di gestione dei sensori per eseguire le operazioni
richieste.
• Rilevamento dati ambientali.
• Invio al SOS Plugin delle osservazioni prodotte; tali osservazioni 'grez- ze' sono composte dalla seguente quadrupla:
- valore della misurazione
- timestamp dell'istante di produzione dell'osservazione
- identi catore SOS del sensore che ha prodotto l'osservazione - identi catore del fenomeno misurato
Va notato come, in fase di registrazione, sia necessario associare un iden- ti catore univoco ad ogni sensore: l'identi catore viene costruito utilizzando un codice che identi ca la tipologia del sensore (ad esempio '0' indica un sensore di posizione GPS) e il numero di telefono dello smartphone.
Nel seguito si farà riferimento ad osservazioni ottenute dal sensore GPS di uno smartphone Samsung Galaxy S dotato di sistema operativo Android, utilizzando il sistema CloudSensor.
Capitolo
3
Architettura di Tra cAnalysis
I
n questo capitolo verrà descritta l'architettura software secondo cui è strut- turata l'applicazione Tra cAnalysis. Saranno analizzati in particolare lo scopo e le funzionalità dei vari moduli componenti, rimandando al successivo capitolo i dettagli implementativi.Alcune scelte progettuali sono state obbligate dalla presenza di software di terze parti con il quale è stato necessario interfacciarsi, come ad esem- pio il modulo che interroga il SOS per ottenere una serie di osservazioni: in questo caso saranno riportati gli standard di comunicazione utilizzati. Al- tri moduli si occupano dell'implementazione degli algoritmi di classi cazione standard riportati nel capitolo precedente, aggiungendo una serie di funzio- nalità speci che di supporto al presente ambito applicativo. Un ulteriore settore dell'applicazione sarà in ne dedito alla creazione dei feature vector, cioè il procedimento tramite il quale vengono estratte dai raw data prodotti dai sensori delle caratteristiche di interesse per la rilevazione di condizioni di tra co. La scelta di tali feature rappresenta il punto focale dell'intero lavoro, in quanto qualunque operazione di classi cazione è subordinata alla presen- za di parametri che bene descrivano le diverse situazioni del mondo reale da analizzare. All'argomento sarà dedicata un'intera sezione dove saranno elencate le caratteristiche selezionate, mostrando il modo in cui forniscono informazioni utili per realizzare un sistema che riesca a distinguere le diverse condizioni di tra co.
A questo proposito è necessaria una breve de nizione del concetto di condi- zione di tra co e a come tale concetto venga inteso nel presente lavoro. Per condizione di tra co si intende un comportamento macroscopico rilevabile dall'osservazione dell'andamento di un autoveicolo su un determinato tratto stradale. Nel seguito si focalizzerà l'attenzione su due particolari condizioni: la condizione di tra co intenso e la condizione di tra co scarso o assente. È
3.1. STRUTTURA AD ALTO LIVELLO evidente come tali due situazioni rappresentino una schematizzazione molto generica del problema, ma allo stesso tempo siano le principali condizioni di interesse per il singolo guidatore, interessato soprattutto a sapere se un deter- minato percorso presenta una buona viabilità. Il vantaggio di tale approccio si riscontra anche durante la fase di training di un sistema supervised quale K-NN, durante la quale un operatore umano deve classi care 'a mano' una serie di osservazioni; in questo caso l'operatore deve dare un giudizio secondo l'esperienza personale delle condizioni riscontrate sul tratto stradale appena percorso. Tale operazione risulta essere immediata e non presenta grandi di coltà nel caso della classi cazione binaria scelta; viceversa, se venissero considerate un maggior numero di possibili condizioni sarebbe più complesso decidere quale condizione meglio si adatta al singolo caso, ed aumenterebbe notevolmente la probabilità di errore.
Un ultimo aspetto da trattare riguarda la gestione dei tratti stradali sui quali si è interessati ad eettuare il monitoraggio del tra co: ognuno di essi presenterà infatti caratteristiche peculiari e sarà quindi necessaria un'analisi speci ca ed indipendente di ogni singolo tratto. Nel seguito si mostrerà come è possibile arontare tale situazione e quali strumenti sono stati utilizzati per distinguere i vari tratti.
3.1 Struttura ad alto livello
L'architettura dell'applicazione Tra cAnalysis è riassunta in Figura 3.1. Il server sul quale sono installate i web service del Sensor Observation Service (SOS) e del Sensor Planning Service (SPS) rappresenta l'unico punto di con- tatto dell'applicazione con il sistema di rilevamento dati. In questo modo è possibile un'astrazione completa del sottostante strato di sensori, e il compito dell'applicazione si riduce all'utilizzo delle osservazioni prodotte, senza alcun interesse circa la tipologia di dispositivi che ha originato tali osservazioni. Le osservazioni di interesse sono costituite esclusivamente da tre campi:
- coppia di valori GPS latitudine/longitudine che rappresenta la posizio- ne nello spazio del dispositivo
- timestamp dell'osservazione che rappresenta l'istante temporale in cui l'osservazione ha avuto luogo
- identi catore univoco che rappresenta il dispositivo che ha prodotto l'osservazione
Il modulo Gestore Osservazioni ha la funzione di interfacciarsi via HTTP con il SPS e il SOS, utilizzando gli standard prede niti dalle speci che
3.1. STRUTTURA AD ALTO LIVELLO
3.2. SCELTA DELLE FEATURE