• Non ci sono risultati.

CoBrA[27, 28] (Context Broker Architecture) `e un framework per applicazio- ni pervasive sviluppato dall’Universit`a del Maryland a Baltimora, con parti- colare attenzione verso gli smart spaces. Rispetto ad Aura i ricercatori hanno focalizzato i loro sforzi nella definizione e nel trattamento delle informazioni di contesto. Tra tutti i sistemi analizzati in questo capitolo CoBrA rappre- senta perci`o quello pi`u evoluto nell’analisi del contesto al fine di inferire nuove informazioni.

L’entit`a centrale in CoBrA `e il Context Broker (da cui il nome del fram- work), che si occupa di gestire il contesto: acquisire le informazioni dai sensori, ragionare su di esse e fornirle ai dispositivi che le richiedono.

In Cobra il contesto `e rappresentato mediante ontologie, che rispetto alle altre tecniche aumenta l’espressivit`a nella definizione delle relazioni tra in- formazioni e permette inferenze pi`u complesse.

Le ontologie sono espresse con il linguaggio OWL (Web Ontology Language), standard nel campo del Web Semantico. CoBrA offre un insieme di ontologie gi`a pronte, COBRA-ONT, che descrivono le informazioni acquisibili in una meeting room intelligente. Lo sviluppatore pu`o utilizzare questo set come base per la propria applicazione, eventualmente espandendolo con altre pi`u complesse legate al particolare dominio applicativo.

3.3.1

Il caso d’uso principale

Riportiamo l’esempio di applicazione riportato in [27], considerato durante lo sviluppo di CoBrA, che tratta una stanza per meeting “intelligente”, dotata di proiettore, sensori e vari dispositivi pervasivi.

Un utente entra nella stanza; grazie ad alcuni sensori l’ambiente di accorge della sua entrata, identifica la persona e cerca di capire le sue intenzioni. Si accorge che in quell’orario `e in programma una presentazione, e che la persona appena entrata `e proprio colui che la deve tenere. Trova tra i file dell’utente

quello per la presentazione, lo invia al proiettore ed avvia il programma per la visualizzazione.

L’utente inizia la presentazione, intanto l’ambiente si accorge che la quan- tit`a di luce nella stanza `e troppo elevata per il proiettore e spegne alcune lampade.

Finita la presentazione, l’ambiente si accorge della presenza di un PDA e ne identifica il proprietario, colui che ha tenuto la presentazione. Deduce che ha dimenticato il PDA nella stanza, e cerca di localizzarlo all’interno dell’edificio, senza successo. Dalla lista di appuntamenti, per`o, trova la pre- notazione di un volo aereo per il pomeriggio; ipotizza quindi che sia gi`a in viaggio; ricerca il suo numero di cellulare e gli invia un sms per informarlo del PDA perso.

Infine si accorge che nella stanza mancavano alcune persone che aveva- no segnalato interesse per questa presentazione; per ognuna individua un contatto email ed inoltra una registrazione del meeting.

3.3.2

Architettura di CoBrA

Come gi`a anticipato, il cuore di CoBrA `e il Context Broker : coordina tutte le entit`a, che possono cooperare tra di loro attraverso questo componente. L’architettura `e quindi come quella rappresentata in figura 3.5, con il context broker al centro del sistema.

Dati i suoi molteplici compiti, questa entit`a `e suddivisa in quattro com- ponenti funzionali:

• Context Knowledge Base: si occupa di immagazzinare tutta la co- noscenza relativa al contesto. In particolare, questa componente gesti- sce le ontologie che descrivono il contesto e la conoscenza acquisita dai sensori.

• Context Reasoning Engine: il motore che analizza le informazioni di contesto per dedurne di nuove. Interpreta quelle presenti nella Know- ledge Base, aggrega dati da pi`u fonti, intercetta e rimuove inconsistenze all’interno della KB.

• Context Acquisition Module: l’insieme di librerie che si occupano di acquisire informazioni dal contesto: sensori, programmi, etc.

• Privacy Management Module: CoBrA presta particolare attenzio- ne alle politiche di sicurezza e gestione della privacy. L’utilizzo di un broker centralizzato favorisce questo tipo di controlli, che sono racchiusi in questo modulo; il suo compito `e controllare i permessi associati alle

Figura 3.5: L’architettura di CoBrA

entit`a che richiedono informazioni al broker ed eventualmente negare l’accesso ai dati.

Il sistema di inferenza della conoscenza, F-OWL, `e stato sviluppato appo- sitamente per CoBrA e utilizza come base il motore deduttivo XSB, offrendo caratteristiche migliori rispetto ai comuni sistemi di inferenza per ontologie. La scelta di design di utilizzare una entit`a centrale come il context broker ha semplificato molti aspetti, come la creazione di una Knowledge Base, la gestione di privacy e sicurezza, etc. D’altro canto impone grosse limitazioni sulla scalabilit`a dell’architettura: come sottolineano anche gli stessi creatori, in presenza di spazi molto grandi con un numero elevato di dispositivi (come nell’idea di Weiser) il broker potrebbe diventare un collo di bottiglia e non riuscire a gestire l’intero sistema.

Per questo motivo sono state studiate tecniche per permettere la coesi- stenza di pi`u broker, che si suddividono lo spazio da gestire e periodicamente aggiornano le proprie Knowledge Base.

Figura 3.6: Esempio di applicazioni in CoBrA: Interazione tra i componenti di EasyMeeting

Alcuni problemi sorgono comunque in caso di nodi fortemente mobili, che si adattano male ad una architettura cos`ı centralizzata.

3.3.3

Esempi di applicazioni CoBrA

Vediamo ora due applicazioni sviluppate in CoBrA e presentate in [27] come esempio di applicazioni context-aware per smart spaces.

EasyMeeting EasyMeeting `e una applicazione per gestire smart spaces sviluppata a partire da Vigil[75], una infrastruttura per pervasive computing prodotta sempre nell’Universit`a del Maryland in Baltimora. EasyMeeting porta in Vigil il supporto a context-awareness e protezione della privacy uti- lizzando CoBrA. L’applicazione fornisce un gruppo di servizi utili per intera- gire con uno smart space: riconoscimento vocale, visualizzazione di presenta- zioni, controllo della luce, riproduzione di musica, benvenuto personalizzato, etc. In figura 3.6 riportiamo lo schema di interazione dei vari componenti. In EasyMeeting il context broker offre un modello di contesto condiviso da tutti i servizi, che si occupa di mantenere informazioni sulla posizione delle persone nella stanza, la programmazione dei meeting e delle presentazioni, gli auto- ri delle presentazioni e altro, utilizzando sensori e informazioni presenti sul

web. Tutte queste informazioni sono utilizzate dal componente MajorDemo per decidere quali servizi abilitare in un particolare momento.

CoBrA Text Messaging Commands CoBrA Text Messaging Commands `e una applicazione di controllo tramite SMS integrata col Context Broker. Tramite l’invio di messaggi di testo gli utenti possono interagire col broker, ponendo domande o invocando azioni. Il prototipo corrente di CoBrA per- mette di ottenere informazioni sui meeting in programma all’eBiquity group dell’UMBC. Le operazioni offerte dall’applicazione sono le seguenti:

• qMeeting: il sistema risponde, tramite sms, con la lista di meeting presenti nel programma giornaliero.

• qSpeaker [meeting-id]: il sistema invia all’utente alcune informazio- ni utili sul presentatore di un particolare meeting, ad esempio nome, istituzione di provenienza, titolo professionale, ambiti di ricerca etc.

• qInfo [meeting-id]: il sistema offre all’utente informazioni sul mee- ting, come luogo ed ora della presentazione, breve descrizione, etc.

• qFollowup [meeting-id] [email-address]: con questa operazione l’utente richiede l’invio dei documenti associati al meeting ad un in- dirizzo di posta elettronica, per agevolare chi non ha potuto essere presente.