Data Stream Management System (DSMS)

Una delle parti pi`u importanti del centro di controllo risiede nel DSMS che `e responsabile dell’acquisizione, memorizzazione e manipolazione degli stream di dati in arrivo dalle OBU. Questi dati saranno geo e tempo localizzati. La scala-bilit`a e le performance richieste dal sistema possono essere garantite solo se i dati

vengono gestiti in maniera efficiente. Inoltre devono essere previste le ottimiz-zazini delle query, il cui scopo e’ quello di produrre un ’piano di esecuzione’ il piu’ possibile efficiente, basandosi su quanto e’ specificato dall’albero della query. I dati, all’interno del DSMS, dovranno essere gestiti in maniera flessibile e differen-ziata a seconda che si tratti di dati recenti o dati storici. I dati recenti dovranno essere gestiti in memoria principale e indicizzati in opportune strutture dati in modo che l’accesso ad essi sia rapido, mentre i dati storici, che generalmente non hanno un utilit`a immediata, potranno essere migrati su memoria secondaria, ad esempio all’interno di un DBMS, e serviranno per effettuare analisi statistiche e predizioni sul traffico futuro in modo da gestire preventivamente il traffico.

Figura 1.4: Interazione tra Store Manager e Query Processing Engine Come mostrato in figura 1.4, il DSMS `e un sistema composto da due moduli, il Query Processing Engine (QPE), che si occupa della ricezione e ottimizzazione delle query da eseguire e lo Storage Manager (SM), che si occupa della gestione e indicizzazione dei dati in arrivo dai veicoli e dei dati storici [1, 4, 9]. L’SM

dovr`a inoltre offrire al QPE una opportuna interfaccia di comunicazione per poter recuperare i dati.

Query Processing Engine

Il Query Processing Engine (QPE) `e quella parte del DSMS che si occupa del-l’ottimizzazione e gestione delle query da eseguire nel sistema. Sugli stream di dati in ingresso dovranno essere eseguire delle query continue per monitorare lo stato del traffico e rilevare eventuali situazioni anomale.

Le query che vengono sottomesse al QPE vengono ottimizzate, parserizzate e trasformate in una serie di comandi di lettura presso lo Store Manager, il quale restituir`a i dati richiesti. Queste query vengono anche chiamate query ’consuma-tore’, in quanto ’consumano’ le tuple presenti nello Store Manager che potranno quindi essere successivamente gestite come dati storici in quanto non pi`u utili per le operazioni real-time. Le query possono interrogare sia i dati recenti che quelli storici.

La caratteristica principale del Query Processing Engine `e il fatto di dover ge-stire query molto differenti rispetto alle normali query di un DBMS tradizionale. La prima grossa differenza riguarda la tipologia di dati che bisogna interrogare. Bisogner`a interrogare dati referenziati spazialmente e temporalmente. Questo necessita di query in cui la clausola WHERE deve essere applicata su una cer-ta finestra temporale, superacer-ta la quale il dato `e considerato troppo ’vecchio’ e quindi non pi`u valido. Potranno essere sottomesse query del tipo: forniscimi il numero totale di vetture che hanno attraversato la strada X nell’ultima ora; da-to un punda-to, calcolami il numero di veicoli che si trovano all’interno di un cerda-to raggio da quel punto; ecc.. Inoltre bisogner`a poter definire query continue che si ripetono ad intervalli regolari in modo da monitorare costantemente il traffico di dati in input.

Infine la possibilit`a di eseguire pi`u query contemporaneamente, fornire risposte approssimate e ottimizzare il query plan dinamicamente rientra tra le caratter-istiche principali di un motore QPE in cui le performance e la scalabilit`a sono gli obbiettivi principali.

Figura 1.5: Il data stream in arrivo dalle OBU viene inserito una finestra temporale su cui verranno eseguite le query.

Storage Manager

Lo Storage Manager `e quella parte del DSMS che si occupa della gestione dello stream di dati in arrivo dalle OBU. I dati sono georefenziati e temporalmente or-dinati, pertanto l’utilizzo di un GIS (Geographic(al) Information System) risulta fondamentale. Il GIS consente di mettere in relazione tra loro dati diversi, sulla base del loro comune riferimento geografico in modo da creare nuove informazioni a partire dai dati esistenti. I GIS presentano normalmente delle funzionalit`a di analisi spaziale ovvero di trasformazione ed elaborazione degli elementi geografici degli attributi.

Esempi di queste elaborazioni sono:

• Overlay topologico: Si effettua una sovrapposizione tra gli elementi dei due temi per creare un nuovo tematismo (ad esempio per sovrapporre il tema dei confini di un parco con i confini dei comuni per determinare le superfici

di competenza di ogni amministrazione o la percentuale di area comunale protetta).

• Query spaziali : Sono interrogazioni alle basi di dati che sfruttano criteri spaziali (vicinanza, inclusione, sovrapposizione, intersezione, ecc.). Questa tipologia di query risulta di fondamentale importanza nel sistema in esame in quanto, ad esempio, rilevare le vetture vicine al luogo di un incidente per inviargli una notifica, valutare le distanze da un punto di interesse e calcolare i tempi di percorrenza sono tra i requisiti del progetto.

• Buffering: E’ una regione di una specifica grandezza costruita intorno ad un punto, una linea o un area. Ad esempio una query effettuata in PostGIS del tipo:

SELECT BUFFER((SELECT thegeom FROM tubature

WHERE nome=’pincopallino’), 2);

Restituisce il luogo dei punti con distanza inferiore o uguale a 2 dalla geometria selezionata.

In genere queste elaborazioni vengono utilizzate per le analisi di prossimit`a. • Segmentazione dinamica: Sono algoritmi che di solito sono applicati su temi lineari per determinare un punto ad una determinata lunghezza dal-l’inizio del tema. Gli elementi lineari, in una visione del mondo di tipo geografico, raffigurano oggetti come strade, fiumi o limiti amministrativi. Utilizzando l’estensione al modello dati di tipo georelazionale chiamata segmentazione dinamica, `e possibile rappresentare tali elementi lineari ed associare delle informazioni (gli attributi) a qualsiasi porzione degli archi che rappresentano tali elementi. La rappresentazione all’interno di un GIS di elementi geografici come un reticolo stradale o fluviale viene effettuata memorizzando una serie di coordinate X, Y in un dato sistema di riferi-mento. Un altro metodo per identificare la posizione di un elemento ge-ografico potrebbe essere anche la sua posizione lungo una strada od un fiume (ad esempio: al 12esimo chilometro dell’autostrada A14). Questo metodo semplifica enormemente l’acquisizione dei dati, in quanto consente di memorizzare e gestire solamente una coordinata di posizione invece che due e di usare un sistema di riferimento pi`u vicino alla realt`a

dell’utilizza-tore finale.

Le funzionalit`a di segmentazione dinamica permettono quindi di rapp-resentare e gestire in maniera estremamente efficace delle informazioni associabili ad elementi geografici lineari.

• Network Analysis: Sono algoritmi che da una rete di elementi lineari (es. rete stradale) determinano i percorsi minimi tra due punti. Anche questa funzionalit`a risulta fondamentale nel progetto in quanto, ad esempio, per i servizi che riguardano la smart navigation calcolare il percorso minimo tra un punto di partenza e uno di arrivo `e un requisito richiesto.

• Spatial Analysis: Sono algoritmi che permettono di creare, interrogare ed analizzare dati raster ed eseguire analisi integrate tra dati raster e dati vettoriali. Le analisi della distanza tengono conto dell’orografia (branca della geografia fisica che studia i rilievi della Terra), della presenza di zone pi`u agevolmente transitabili, di ostacoli naturali e artificiali per individuare i percorsi pi`u brevi e accessibili tra determinati punti.

Tutti questi aspetti rendono l’utilizzo di un GIS fondamentale.

Un’altra caratteristica dei dati di cui lo Storage Manager deve tenere conto `e la loro alta variabilit`a temporale. In pratica non si devono gestire dati statici come generalmente avviene in un DBMS tradizionale ma dati che variano con-tinuamente nel tempo e la cui ’importanza’ cambia nel tempo. Questa caratter-istica rende impossibile la gestione di tali dati tutti in memoria primaria perch`e gli stream di dati in ingresso sono potenzialmente infiniti, pertanto serviranno politiche che permettano di differenziare i dati e gestirli in maniera diversa. Ad esempio, bisogner`a differenziare i dati recenti da quelli passati, in quanto sui dati recenti generalmente si hanno requisiti hard real-time (rilevazioni di inci-denti, situazioni anomale, segnalazione di emergenze, ecc.), mentre i dati storici serviranno per analisi statistiche e predizioni future [5].

POI ed EOI

Il DSMS fa uso di ontologie per la gestione dei POI e degli EOI. Un’ontologia `e una rappresentazione formale, condivisa ed esplicita di una concettualizzazione di un dominio di interesse. Permette di descrivere le parole comuni e i concetti (significati) usati per descrivere e rappresentare un’area di conoscenza (dominio).

La parte di gestione delle ontologie `e separata rispetto al DSMS in modo da ren-dere il DSMS indipendente dal contesto applicativo nel quale lo si inserisce. Le ontologie permettono una gestione flessibile ed estendibile dei punti di interesse e degli eventi e aggiunge un livello di astrazione rispetto ai dati ’grezzi’ in arrivo dalle OBU, in modo da categorizzare nello stesso modo informazioni che sono molto simili tra di loro. Il dominio ontologico relativo ai POI ed EOI pu`o crescere dinamicamente in quanto nuovi concetti possono venire aggiunti e popolati con i nuovi dati in arrivo. I dati relativi ai POI possono essere gestiti come dati storici in quanto, analizzando la storia di una particolare OBU, si possono descrivere e definire i gusti e comportamenti tipici degli utenti.

Per quanto riguarda gli EOI vengono modellati molti eventi di interesse (inciden-ti, code, lavori, ecc.) che servono a definire le condizioni del traffico. Gli eventi sono individuati analizzando le informazioni ricevute dalle OBU, ad esempio analizzando la velocit`a e il trend di accellerazioni si pu`o capire se `e presente un coda oppure no; se due veicoli vicini hanno velocit`a nulla per un lungo periodo di tempo potrebbe essersi verificato un incidente. Inolte gli eventi possono essere rilevati utilizzando dei metodi simulativi o predittivi, come le DPM (Dynamic Probabilistic Models) o le HMM (Hidden Markov Models) [21]. Quest’ultimo metodo, in particolare, data una sequenza di osservazioni sulla velocit`a del traf-fico presente, stimano lo stato di traftraf-fico futuro pi`u probabile. La bont`a delle predizioni viene calcolata osservando le distanze tra il valore predetto e quello reale.

Le ontologie relative agli eventi descrivono l’evento stesso e le regole che genera-no l’evento (trigger condition). L’evento ’scatta’ quando le informazioni raccolte dalle OBU rispettano le regole definite dall’ontologia relativa a quell’evento. La rilevazione di un evento fa eseguire all’interno del DSMS le query legate a quell’evento, come ad esempio il monitoraggio della zona in cui si `e verificato l’incidente e la comunica ad un operatore, e continuano ad eseguire fin tanto che l’evento non si `e risolto (stop condition). Quindi le ontologie sugli eventi avranno anche delle condizioni che definiscono la risoluzione dell’evento stesso e di conseguenza di tutte le query ad esso associate. Ad alto livello si potrebbe rappresentare questo concetto in questo modo:

QUERY: < Monitoraggio del traffico in un raggio di 500m dall’incidente >

TRIGGER: < Vetture ferme nello stesso punto per pi`u di 5 minuti > STOP CONDITION: < Le vetture tornano in movimento >

Questa query pu`o essere inserita, ad esempio, nell’ontologia ’Incidente’.