Struttura di un sistema context-aware

In linea di massima un sistema context-aware pu`o essere implementato in vari modi. Vista l’et`a relativamente giovane del settore, non `e stata ancora definita una tecnica “standard” per la realizzazione di applicazioni context- aware; al contrario, l’approccio da utilizzare dipende spesso dalle caratteristi- che dell’applicazione che vogliamo sviluppare, come la posizione dei sensori (accessibili direttamente oppure tramite gateway), la quantit`a di possibili utenti, la tipologia di risorse utilizzabili, etc.

Uno dei problemi importanti in questo tipo di applicazioni `e definire il metodo con cui i dati di contesto vengono acquisiti, poich´e questa scelta influenza l’architettura dell’intera applicazione. Una delle suddivisioni pi`u utilizzate `e quella di Chen[28], che presenta tre modalit`a per acquisire i dati di contesto:

• Diretto: questo approccio prevede l’accesso diretto da parte dell’appli- cazione ai sensori, per reperirne i dati. Questa tecnica viene utilizzata frequentemente per dispositivi con sensori integrati; non prevede un livello tra i sensori e l’applicazione, che quindi deve essere dotata di driver per accedere ad ogni tipologia di sensore, e richiede all’applica- zione di occuparsi di tutti i dettagli legati ad essi. Per questo motivo non `e utilizzabile in caso di sensori non integrati.

• Tramite middleware: l’approccio con middleware prevede l’accesso ai sensori attraverso una architettura a livelli, dove l’applicazione ri- chiede le informazioni al livello sottostante (il middleware, appunto), che maschera tutti i dettagli sull’accesso ai singoli dispositivi. Rispetto alla precedente questa tecnica `e molto pi`u flessibile e semplifica lo svi- luppo delle applicazioni, che non devono pi`u occuparsi dei meccanismi di accesso alle singole tipologie di sensori.

• Con server di contesto: in questo caso i dati dei sensori vengono tutti raccolti da una singola entit`a, il “context server”, che si occu- pa poi di gestire l’accesso ai dati da parte di una o pi`u applicazioni.

Figura 2.2: I livelli concettuali di un framework per lo sviluppo di applicazioni context-aware

Applicazioni Storage/Management

Preprocessing Raw data retrieval

Sensors Application Storage/Management

Preprocessing Raw data retrieval

Sensor

Rappresenta un ulteriore livello tra i sensori e l’applicazione (il server pu`o a sua volta utilizzare un middleware), e offre maggiori funzionalit`a alle applicazioni finali. Si pu`o infatti presumere che questo server ab- bia una discreta potenza computazionale, che pu`o essere utilizzata per scaricare i dispositivi embedded da operazioni intensive. Rappresenta quindi una risorsa aggiuntiva dell’ambiente, utilizzabile ad esempio per i requisiti di QoS.

La maggior parte dei sistemi per sviluppare applicazioni context-aware utilizzano un accesso ai sensori tramite middleware o server di contesto, uti- lizzando quindi un approccio a “livelli”, che permette di semplificare lo svi- luppo delle applicazioni. Col tempo i livelli di un sistema context-aware sono stati definiti in modo pi`u preciso, e gli attuali framework prevedono una strutturazione a cinque livelli, come in figura 2.2.

Sensor

Questo livello rappresenta l’insieme dei sensori presenti nel sistema che pro- ducono informazioni di contesto. Questa accezione di “sensori” include, quin- di, non solo tutti i sensori hardware che rilevano misure fisiche, ma anche i sensori logici, sulle risorse, etc. In questo senso sono spesso definiti tre ti- pi di sensori[55], con una classificazione che riprende ed estende quella sulle informazioni di contesto.

• Sensori fisici : la tipologia pi`u classica di sensori, che si occupa di mi- surare caratteristiche fisiche dell’ambiente. In tabella 2.1 sono presenti le principali tipologie di sensori fisici.

Informazione Tipi di sensori

Luce Fotodiodi, sensori di colore, IR, UV Immagini Videocamere e fotocamere di vario tipo Audio Microfoni

Movimento Accelerometri, motion detectors Posizione GPS, GSM, etc

Temperatura Termometri

Tabella 2.1: I tipi di sensori pi`u utilizzati

• Sensori virtuali : generano informazioni di contesto in base a dati da ap- plicazioni o servizi. Ad esempio, si pu`o immaginare un sensore virtuale che definisce la posizione di una persona in base alla lista di appun- tamenti giornaliera, oppure l’attivit`a corrente dell’utente controllando gli applicativi aperti sul proprio computer.

• Sensori logici : questi analizzano i dati ottenuti dai sensori fisici e vir- tuali per definire informazioni pi`u complesse; per esempio capire se in una stanza non sono presenti persone, oppure determinare la posizio- ne di un impiegato in base al computer attualmente utilizzato e alla posizione di quest’ultimo all’interno dell’azienda.

Raw Data Retrieval

Questo livello si occupa di acquisire i dati dai sensori, attraverso appositi driver per quelli fisici e API per quelli virtuali e logici. Offre al livello supe- riore un metodo pi`u generale per ottenere i dati, trasparente alla tipologia di sensore utilizzata, in modo da offrire interfacce riusabili anche modificando il livello sottostante. Ad esempio modificare un sistema di localizzazione ba- sato su sensori RFID con uno basato su ricevitori GPS non deve modificare i layer superiori, che continueranno ad utilizzare un metodo getPosition() per ottenere la posizione dell’oggetto, indipendentemente dal sensore sottostante.

Preprocessing

Questo livello `e in realt`a opzionale e non tutti gli ambienti lo offrono. Per- mette di effettuare una prima elaborazione dei dati ottenuti dai sensori, utile ad esempio se la quantit`a di dati ottenuti dagli stessi `e elevata. Questo livello si occupa di analizzare i dati ed interpretarli per renderli pi`u utili per i livelli

applicativi, a cui vengono quindi offerte informazioni ad un livello maggiore di astrazione. Le operazioni di questo livello possono anche essere non banali e lavorare con dati ottenuti da pi`u sensori; tornando all’esempio della loca- lizzazione, una applicazione potrebbe non essere interessata alle coordinate geografiche dell’oggetto, ma alla posizione all’interno dell’edificio (ad esem- pio il piano e la stanza).

In altri casi non si `e interessati a tutti i valori ottenuti dai sensori ma ad informazioni pi`u elaborate, ad esempio capire se la temperatura di una stan- za `e variata sensibilmente, oppure se si discosta in modo elevato da quella media. In questi casi sono necessarie operazioni di analisi statistica e dei dati storici ottenuti o tramite sensori o tramite basi di dati.

Queste operazioni di preprocessing sono comunque facoltative, nel senso che possono essere spostate a livelli differenti: se ne pu`o occupare direttamen- te l’applicazione, oppure si pu`o racchiudere queste informazioni all’interno di sensori logici. Spostare queste operazioni a livello applicativo, soprattut- to se `e presente un server di contesto, potrebbe per`o limitare le prestazioni dell’applicazione, specialmente dal punto di vista della rete, in quanto il pre- processing normalmente prende in ingresso una grande quantit`a di dati per produrne pochi. Per questo motivo trasferire ai dispositivi solo il risultato del preprocessing, e non tutti i dati da analizzare, pu`o permettere un notevole risparmio di banda. Analogamente l’utilizzo del server di contesto per effet- tuare queste analisi libera il dispositivo mobile da computazioni intensive.

`

E quindi preferibile definire un livello di preprocessing delle informazioni di contesto, per facilitare la creazione di applicazioni pi`u semplici e performanti. Un altro problema spesso considerato a questo livello `e quello della ge- stione dei conflitti: le informazioni di contesto ricevute potrebbero essere tra di loro contraddittorie, a causa di ritardi temporali o di sensori di bassa qua- lit`a. Durante la fase di preprocessing ci si occupa quindi di scartare quelle informazioni che renderebbero il contesto “contraddittorio”.

Storage and Management

Questo livello, il pi`u vicino all’applicazione, si occupa di organizzare ed even- tualmente immagazzinare i dati ricevuti da quello sottostante. In questo livello sono definite le interfacce con cui l’applicazione pu`o accedere alle informazioni di contesto.

Normalmente le modalit`a di accesso ai dati si distinguono in:

• sincrono: l’applicazione richiede, quando vuole, le informazioni di con- testo a questo livello, con chiamate in stile RPC. Questa modalit`a `e utile se l’applicazione, durante la sua vita, vuole conoscere l’attuale

stato dell’ambiente. Ma se invece `e interessata ad accorgersi di cam- biamenti del contesto, deve periodicamente richiedere tali informazioni e controllare se sono variate dalle precedenti.

• asincrono: questa modalit`a sopperisce ai problemi della precedente: in questo caso l’applicazione si “registra” su specifici eventi (ad esempio l’arrivo di un nuovo utente nella stanza, il cambiamento della tempe- ratura, etc) e viene “avvisata” quanto questo evento si verifica.

Normalmente la tecnica pi`u utilizzata nelle applicazioni context-aware `e la seconda: per una applicazione di questo tipo, infatti, la prerogativa princi- pale `e adattare il proprio comportamento all’attuale contesto. Questo pu`o essere ottenuto semplicemente modificandosi (se necessario) ad ogni cambio significativo dello stato. L’applicazione ha quindi un comportamento “ad eventi”, che si ottiene nativamente con la modalit`a asincrona.

Application

Il livello finale, in cui si trova l’applicazione context-aware, che utilizza il sot- tostante per ottenere informazioni dal contesto ed in base a queste modifica il proprio comportamento.

Inoltre, come gi`a detto precedentemente, qui si trovano tutte le funziona- lit`a non espresse nei livelli sottostanti. Ci riferiamo principalmente alla parte di preprocessing, che pu`o non essere presente in certi ambienti di sviluppo o essere comunque troppo semplice per descrivere il comportamento voluto.