La Context Awareness in ambienti di calcolo pervasivi
ad alte prestazioni
In questo capitolo saranno introdotti due aspetti fondamentali per la comprensione della tesi, ovvero sarà fornita una rapida introduzione ai sistemi di Pervasive Computing e alle problematiche di Context Awareness inerenti, fornendo una visione di massima dello stato dell’arte esistente. Ci soffermeremo ulteriormente sull’individuazione delle caratteristiche degli ambienti di High Performance Pervasive Computing (HPPC), individuando le applicazioni tipiche e le problematiche di programmazione di sistemi di questa tipologia.
2.1 Il Pervasive Computing
Il Pervasive Computing [7], anche detto Ubiquitus Computing, è quel tipo di “elaborazione distribuita” che si ottiene collegando tra di loro molti piccoli dispositivi digitali dedicati. Già oggi una persona qualunque ha che fare con decine di piccoli e grandi dispositivi digitali, dotati di una loro CPU, di RAM e ROM, spesso di un sistema operativo e di software applicativo, molti dei quali sono dispositivi “embedded” e quindi sostanzialmente invisibili. Sono un esempio di questi dispositivi:
•
Telefoni digitali• Palmari PDA (Personal Digital Assistant) • Computer portatili (laptop computer)
• Navigatori satellitari (Global Positioning System) • SmartCard (carte di credito, badge elettronici) • Wearable device (dispositivi indossabili)
• Sensori (dispositivi in grado di restituire informazioni sullo stato dell’ambiente istante per istante)
Il punto saliente nella visione del Pervasive Computing consiste nella creazione di ambienti caratterizzati dalla presenza di molte risorse di calcolo, anche piccolissime, perfettamente integrate tra di loro e con l’ambiente circostante, ed in grado di interagire in modo amichevole e spesso trasparente con gli utenti finali. Consideriamo per esempio un paziente cardiopatico, con un dispositivo pervasivo (un piccolo sensore) posizionato vicino al suo cuore. Immaginiamo che questo dispositivo possa comunicare con un server indicando la situazione del paziente e segnalando eventuali disfunzioni in tempo. Un’applicazione di questo tipo può essere utile per effettuare prontamente i dovuti soccorsi, oppure per prevenire mediante notifiche una possibile situazione di infarto. Questo è soltanto un primo banale esempio delle migliaia di applicazioni sviluppabili in ambiente pervasivo, e possiamo intuire come queste possano effettivamente sfruttare il progresso tecnologico e la trasparenza dei dispositivi mobili embedded, per fornire servizi di estrema sensibilità.
Il primo a proporre questo nuovo modello fu Mark Weiser [7] con il suo articolo del 1991. A quell’epoca Weiser era direttore scientifico delle ricerche tecnologiche allo Xerox Park di Palo Alto in California. La visione che aveva in mente fu considerata dalla comunità scientifica dell’epoca eccessivamente avveniristica, poiché richiedeva hardware e software con caratteristiche che erano troppo distanti dalla realtà di quei giorni. Oggi, invece, siamo in grado di creare dispositivi piccoli, mobili, indossabili, in grado di comunicare mediante onde radio e di avere una sufficiente autonomia. Ci sono quindi tutti gli ingredienti per poter concretizzare il modello di calcolo pervasivo proposto da Weiser più di vent’anni fa.
Il paradigma del Pervasive Computing propone il concetto di ambiente pervasivo o ubiquo, caratterizzato da un insieme di dispositivi interconnessi con una rete di comunicazione opportuna, ed un insieme di sistemi software eseguiti su questi dispositivi, per fornire servizi specifici agli utenti. Le caratteristiche di un ambiente di questo tipo sono:
1. Ubiquità: l’interazione tra gli utenti e l’ambiente deve avvenire ovunque, senza vincoli specifici, ogni qual volta l’utente ne abbia bisogno.
2. Trasparenza: il sistema deve essere il più possibile trasparente all’utente, non intrusivo, in grado di autoconfigurarsi ed integrarsi senza l’intervento esplicito degli utenti.
Possiamo classificare due dimensioni che ci consentono di caratterizzare gli ambienti di Pervasive Computing rispetto agli altri sistemi esistenti:
1. Mobilità dell’utente: rappresenta la libertà che ha l’utente di spostarsi nell’ambiente mentre interagisce con il sistema.
2. Trasparenza delle interfacce: Indica lo sforzo che l’utente deve produrre per interagire con il sistema.
La figura 2.1 indica, in relazione alle due dimensioni descritte, le caratteristiche degli ambienti di Pervasive Computing.
Figura 2.1: Caratteristiche di un ambiente di Pervasive Computing.
Dalla figura 2.1 comprendiamo come nel Pervasive Computing sia massimizzata, sia la mobilità dell’utente, che la trasparenza delle interfacce, definendo ambienti in cui le capacità comunicative e computazionali siano talmente integrate con l’utente, tanto da diventare una “tecnologia che svanisce”, utilizzata in maniera spesso inconsapevole.
2.2 Le problematiche introdotte con il Pervasive Computing
L’aspetto peculiare del calcolo pervasivo è l’elevata disponibilità di risorse di calcolo, anche integrate in dispositivi piccolissimi, a disposizione degli utenti. La nuova ottica in
cui ci poniamo quindi, è assai differente dal recente passato dell’informatica, in cui le risorse di calcolo erano estremamente “rare” e costose. Nel calcolo pervasivo la disponibilità di nodi d’elaborazione estremamente eterogenei, con elevata mobilità, sia degli utenti che dei dispositivi, propone problematiche in parte già affrontate in altri contesti, in parte nuove. Una rete di dispositivi pervasivi è costituita da nodi di elaborazione che hanno la necessità di scambiarsi informazioni. In questo senso, quindi, gli aspetti già studiati nel Distribuited Computing, come la comunicazione remota tra nodi di elaborazione, la gestione dei fallimenti, la sicurezza nell’accesso alle risorse distribuite e l’accesso remoto alle informazioni memorizzate nei nodi (file system distribuiti), possono trovare campo d’applicazione nel calcolo pervasivo, ovviamente con i vincoli derivanti dalle particolari architetture hardware dei dispositivi, anche miniaturizzati.
La mobilità delle risorse comporta molte problematiche già affrontante nel Mobile Computing, come il Mobile Networking e lo sviluppo di protocolli di comunicazione wireless, l’accesso alle informazioni distribuite su nodi mobili, tecniche per la gestione del risparmio energetico, problematica quest’ultima molto importante nel caso di piccoli dispositivi. Altre questioni risultano invece nuove, tra cui specialmente:
1. La Context-Awareness: gli ambienti di calcolo pervasivi sono estremamente dipendenti dal contesto ambientale e dalle user intention. Spesso le computazioni che devono essere eseguite, possono essere realizzate con modalità differenti, in base al tipo di risorse disponibili, allo stato della connettività, o in base a situazioni o contesti in cui si trova l’utente (se impegnato in una conversazione, se disponibile, etc…).
2. L’invisibilità delle risorse pervasive all’utente è spesso realizzata minimizzando le interazioni tra l’utente e il sistema. La riconfigurazione del sistema e delle sue funzionalità deve coinvolgere l’utente il meno possibile, e il sistema deve adattarsi in base alla specifica percezione dell’ambiente.
3. Il sistema deve gestire situazioni di “uneven conditioning”, ovvero situazioni che comportano l’adattività dell’applicazione, per fornire, nonostante una situazione per esempio d’emergenza, i servizi richiesti in modo diverso.
Figura 2.2: Complessità delle problematiche introdotte con il Pervasive Computing.
2.3 Le applicazioni per il Pervasive Computing
La ricerca nel Pervasive Computing si sta muovendo verso lo sviluppo di ambienti caratterizzati dalla presenza di molti dispositivi di calcolo, eterogenei, integrati negli strumenti più comuni (telefoni, palmari, orologi digitali, etc…). Un requisito fondamentale nel calcolo pervasivo consiste nel fornire un sistema di supporto, in cui gli strumenti di calcolo presenti vengano integrati nelle applicazioni esistenti. Calcolatori come workstation, palmari, PDA, cellulari, smartcard, sono le risorse tipiche di questi ambienti. La loro eterogeneità richiede un’elevata adattabilità del sistema, che deve riconoscere le caratteristiche e le capacità dei dispositivi in un certo momento disponibili, e fornire servizi conformi alle risorse a disposizione. Un ambiente pervasivo è quindi formato da una pluralità di dispositivi, che possono essere ricondotti a tre classi fondamentali:
• Sensori: dispositivi di input che rilevano cambiamenti nell’ambiente circostante (temperatura, luminosità, rumore, movimento, etc…). Possono essere più o meni intelligenti e fornire servizi di diversa tipologia (esempio restituire il valore primitivo di una grandezza fisica come la temperatura, oppure fornire servizi più elaborati sull’ambiente e il suo stato).
• Processori: dispositivi in grado di acquisire i dati di input, interpretarli ed elaborarli per ottenere informazioni più complesse.
• Attuatori: dispositivi di output, in grado di modificare l’ambiente circostante mediante mezzi elettronici o meccanici.
I dispositivi descritti devono integrarsi nell’ambiente e collaborare tra di loro. Questo richiede l’autonomicità [10] del sistema, ovvero la capacità di configurarsi da solo, riconoscere i dispositivi presenti, individuare le loro funzionalità senza richiedere l’intervento esplicito dell’utente. Queste considerazioni ci suggeriscono come lo sviluppo delle applicazioni deve seguire metodologie di sviluppo e pattern architetturali non tradizionali, in modo da sviluppare componenti software in grado di offrire un elevato grado di adattabilità, scalabilità, autoconfigurabilità, ed in grado di interagire tra loro in modo autonomico.
2.3.1 Caratteristiche delle applicazioni per il Pervasive Computing
Consideriamo adesso le caratteristiche delle applicazioni per ambienti pervasivi, caratterizzati dai dispositivi descritti nel precedente paragrafo. Queste applicazioni, per realizzare gli obiettivi di trasparenza e autoconfigurazione suggeriti da Weiser [7], devono essere costituite da componenti con le seguenti caratteristiche:
• Adattatività: le applicazioni devono essere in grado di adeguare il loro comportamento all’ambiente circostante, fortemente dinamico ed eterogeneo. Pensiamo ad un’applicazione che è in grado di adeguare l’output che produce, agli strumenti che sono disponibili nell’ambiente. Consideriamo un utente che utilizza la propria workstation per un’applicazione di teleconferenza, e successivamente deve spostarsi ed abbandonare quella postazione di lavoro. L’applicazione deve essere in grado di proseguire su un altro dispositivo mobile dell’utente, senza essere riavviata o sostituita. Il nuovo dispositivo può essere un telefono cellulare o un PDA per esempio, ed è essenziale che al fine della trasparenza, l’utente non sia in nessun modo coinvolto nel processo di adattività e di riconfigurazione dell’applicazione.
• Proattività: l’applicazione in base alla conoscenza dell’ambiente circostante e alla cronologia delle richieste dell’utente, deve poter prevedere le conseguenze della propria elaborazione ed intraprendere delle scelte per massimizzarne il risultato. Prendiamo l’esempio di un utente che si trova in aeroporto, in attesa del proprio volo, ed intende inviare un documento mediante una email. L’applicazione che è a conoscenza degli impegni dell’utente e quindi dell’orario d’imbarco, deve garantire che l’email verrà spedita entro il tempo di partenza. Per questo può segnalare all’utente se la banda attualmente disponibile non è sufficiente all’invio entro il tempo limite, e suggerire zone con requisiti di banda e connettività opportuni.
• Self-Tuning: l’applicazione per realizzare requisiti di adattabilità alle risorse disponibili e di proattività nell’esecuzione, deve essere in grado in modo del tutto autonomo di trasferire lo stato della propria esecuzione da una piattaforma ad un’altra. Per esempio da un calcolatore desktop ad un portatile, un palmare o un telefono cellulare, ed adeguare il proprio comportamento alle risorse usate.
• Mobilità: le applicazioni devono poter supportare gli utenti, in qualsiasi momento e luogo. In questo senso il sistema deve poter gestire, sia la mobilità degli utente, che la mobilità dei dispositivi.
Per la realizzazione delle funzionalità descritte, le applicazioni devono essere realizzate con pattern architetturali che tengano conto di questi aspetti. In particolar modo in fase di progettazione [11], è necessario che le applicazioni siano definite senza una specifica conoscenza dei dispositivi che verranno utilizzati. Non devono essere fatte assunzioni sui dispositivi di input e di output che saranno impiegati, l’applicazione deve essere quanto più possibile “device-neutral”. Similmente, il programmatore non deve fare alcuna assunzione su quelli che sono i possibili servizi presenti nell’ambiente. I servizi di cui l’applicazione necessita, devono essere espressi in modo astratto, a tempo d’esecuzione poi l’applicazione utilizzerà quelli esistenti, stabilendo un “mapping” tra i servizi astratti necessari e quelli realmente disponibili. Le applicazioni per ambienti pervasivi quindi, necessitano di un supporto a run-time estremamente complesso [11], in quanto l’estrema dinamicità di questi ambienti comporta la necessità di riconfigurare e ristrutturare l’applicazione, durante la sua computazione. Le risorse nell’ambiente devono essere dinamicamente “scoperte”, ed il
sistema deve essere in grado di adattare il proprio comportamento alle risorse disponibili. Le applicazioni devono quindi essere descritte in termini dei requisiti necessari alla loro esecuzione, mentre i dispostivi presenti nell’ambiente in termini delle loro capacità. Il supporto del sistema pervasivo dovrà essere in grado di mediare le richieste con le offerte in modo da consentire all’applicazione di essere eseguita con le risorse disponibili. Di conseguenza occorre affrontare problematiche come, il Resource Discovery delle risorse disponibili, e lo sviluppo di protocolli di negoziazione per assegnare i servizi alle applicazioni che ne hanno bisogno.
E’ necessario, inoltre, monitorare l’esecuzione delle applicazioni, valutare le loro prestazioni e ridistribuire le risorse impiegate in modo opportuno. Può essere necessario eseguire operazioni di “handoff”, ovvero di migrazione di una o più componenti di un’applicazione da un ambiente ad un altro (esempio da un portatile ad un dispositivo indossabile). Tutte ciò deve essere eseguito con il minimo impatto sull’utente, ed in modo trasparente. Questo complica oltremodo la complessità di realizzazione delle applicazioni rispetto ad ambienti di sviluppo tradizionali.
2.3.2 Problematiche inerenti lo sviluppo delle applicazioni pervasive
Le innovazioni tecnologiche necessarie alla diffusione di sistemi pervasivi, producono come abbiamo visto scenari applicativi nuovi, che richiedono lo sviluppo di sistemi software per ambienti distribuiti, molto più complessi di quelli fino ad ora realizzati.
Da questa ottica il punto di riferimento è senza ombra di dubbio il Grid Computing [5]. Negli ultimi anni i progetti di Grid hanno portato allo sviluppo di sistemi in grado di realizzare un’infrastruttura di elaborazione collaborativa su piattaforme distribuite, diffusa ed estremamente eterogenea. Tuttavia il Pervasive Computing introduce complicazioni nuove, come la realizzazione di sistemi in grado di auto-organizzarsi, proattivi ed adattativi, in un ambiente fortemente dinamico, costituito da dispositivi miniaturizzati. In particolar modo è richiesto di gestire:
• L’eterogeneità dei dispositivi hardware e software coinvolti. • L’adattabilità dei diversi servizi ai dispositivi disponibili.
• La trasparenza e spontaneità nell’interazione dell’utente con l’ambiente e i suoi dispositivi.
Da questo si evince come sia necessaria l’implementazione di strumenti, che possono anche evolvere dal Grid Computing, ma che massimizzino la loro attenzione su ulteriori aspetti come:
• Interoperabilità, integrazione, collaborazione tra i dispositivi. • Dynamic Resoure Discovery.
• Negoziazione dei servizi disponibili ed accesso sicuro alle risorse.
• Garantire la potenza di elaborazione necessaria on-demand, in modo che le applicazioni possano ottenere le risorse necessarie in base a quelle disponibili.
A questo scopo, l’obiettivo del prossimo capitolo è quello di descrivere alcuni progetti di ricerca attuali, atti alla realizzazione di sistemi in grado di gestire piattaforme distribuite di strumenti pervasivi, fornendo servizi in grado di garantire i requisiti fondamentali necessari. Si tratta prevalentemente di progetti di middleware, ovvero il tentativo di fornire, tramite servizi a livello di sistema, le funzionalità base necessarie all’implementazione della dinamicità, adattatività e proattività in ambienti distribuiti e pervasivi. In questo modo si cercherà di fornire una panoramica sullo stato dell’arte della ricerca nel settore del Pervasive Computing, con l’obiettivo di identificare gli eventuali limiti degli approcci che sono stati impiegati.
2.4 Soluzioni middleware per ambienti pervasivi
Un middleware è un sistema software di livello intermedio, tra le risorse hardware disponibili e le applicazioni. La figura 2.3 illustra questa semplice strutturazione a livelli:
La realizzazione di un sistema di questo tipo ha come obiettivo quello di fornire alle applicazioni l’utilizzo delle risorse, mediante funzionalità di base, comuni a tutte le applicazioni. Queste funzionalità dovranno essere invocate dalle applicazioni, mediante opportune chiamate al sistema di middleware. Alcuni servizi base offerti possono essere:
1. Interazione tra dispositivi ed ambiente: il middleware deve consentire all’ambiente il riconoscimento dei dispositivi in ingresso, e a questi, di ottenere l’accesso ai servizi offerti dalla rete. In questo modo abbiamo un’interazione tra i dispositivi e l’ambiente del tutto spontanea, senza la necessità di configurazioni ad hoc da parte dell’utente.
2. Resource Discovery: il sistema deve realizzare un registro aggiornato dei servizi disponibili, e aggiornarlo in base ai dispositivi che sono presenti nella rete. Le risorse registrate devono fornire le indicazioni sulle loro capacità, sia computazionali che di memoria.
3. Sicurezza negli accessi: la trasparenza dei dispositivi e la loro capacità di autoconfigurarsi, può generare problematiche di sicurezza nuove rispetto agli ambienti tradizionali. Il middleware deve consentire l’accesso alle risorse a chi ne ha diritto, fornendo l’uso dei servizi agli utenti che hanno determinati profili.
4. Fault Tolerance: il middleware deve fornire servizi di tolleranza ai guasti e di affidabilità. In un ambiente pervasivo, i dispositivi possono entrare ed uscire con elevata dinamicità, il middleware deve gestire queste possibili disconnessioni e consentire un corretto funzionamento delle applicazioni.
Nel seguito saranno presentati alcuni progetti di middleware per ambienti pervasivi.
2.4.1 Progetto GAIA
GAIA [12] è una infrastruttura middleware sviluppata dai ricercatori dell’Università dell’Illinois, con l’obiettivo di creare una piattaforma comune per l’utilizzo di “Smart House” (anche dette Active Space in generale). Con questo termine intendiamo uno spazio
chiuso (esempio una stanza o una casa), contenente un certo numero di utenti e di dispositivi pervasivi eterogenei. Lo spazio è considerato attivo, poiché è presente un’infrastruttura software e hardware sensibile all’ambiente, che consente agli utenti di interagire con il sistema in modo automatico ed adattivo, per usufruire di specifici servizi.
Il middleware consiste in tre componenti fondamentali: il Kernel GAIA, un Application Framework e le applicazioni. Il kernel consiste in un Component Management Core (CMC) che si occupa di creare, caricare, trasferire e distruggere le applicazioni, e in una serie di servizi base tra cui:
1. Event Manager: un Active Space deve avere delle meccanismi da utilizzare per poter segnalare i cambiamenti del suo stato. Mediante l’utilizzo di canali e di eventi, le applicazioni GAIA sono informate della presenza di nuovi servizi, applicazioni, utenti, errori, etc… Attualmente viene usato il CORBA event service per l’implementazione di questo servizio.
2. Context Service: questo servizio consente alle applicazioni di registrarsi per ricevere specifiche informazioni sull’ambiente. Le informazioni vengono ottenute mediante dei Context Provider, implementati con sensori, in grado di rilevare diverse caratteristiche ambientali (luminosità, temperatura, etc…). La dipendenza dal contesto ambientale verrà presentata con maggior dettaglio successivamente nel capitolo, perché come vedremo rappresenta un aspetto comune e cruciale di molti sistemi di Pervasive Computing.
3. Presence Service: GAIA mantiene aggiornate le informazioni sulle risorse presenti nell’ambiente. Le risorse possono essere: risorse fisiche e risorse logiche. Le prime sono prevalentemente dispositivi, mentre le seconde sono applicazioni e servizi.
4. Space Repository: il repository mantiene informazioni su tutte le entità software e hardware presenti nell’ambiente. Le applicazioni utilizzano lo Space Repository per richiedere dal sistema, l’elenco delle risorse presenti con certi requisiti. Ogni risorsa è accompagnata da una descrizione in XML, che fornisce la descrizione delle sue proprietà. Non appena il Presence Service individua una nuova risorsa, lo Space Repository la contatta per ottenere l’elenco delle features fornite e memorizzarle per richieste future.
5. Context File System: GAIA fornisce un file system Context-Aware, che consente di rendere i dati personali degli utenti disponibili alle applicazioni, e consente di ottenere i dati in un formato basato sulle preferenze dell’utente e sulle caratteristiche dei dispositivi su cui attualmente l’applicazione è in esecuzione.
GAIA definisce uno schema progettuale che le applicazioni devono rispettare per essere eseguite sul middleware. Questo schema fa riferimento al noto Model-View-Controller [13] tipico delle applicazioni grafiche, e prevede le seguente entità:
• Modello: implementa la logica dell’applicazione e del suo stato.
• Presentazione: consente di esportare i dati dell’applicazione, rendendoli disponibili agli utenti.
• Input Sensor: consente agli utenti di interagire con l’applicazione.
• Controller: consente di collegare gli eventi di input con metodi che modificano il modello dell’applicazione.
• Coordinator: componente che controlla tutta l’applicazione.
La figura 2.4 schematizza le componenti prima descritte, indicando le interazioni che sono presenti fra queste:
Figura 2.4: Il modello di applicazione utilizzato dal framework GAIA.
2.4.2 Progetto ATLAS
Il secondo progetto che analizziamo consiste in un middleware per ambienti pervasivi, sviluppato dall’Università della Florida, di nome ATLAS [14]. L’idea di questo progetto parte dall’analisi delle difficoltà d’integrazione sia a livello hardware, che a livello software, delle componenti di un ambiente pervasivo. Molti progetti si sono spesso
scontrati con la difficoltà di dover integrare dispositivi molto diversi, dovendo acquisire tutti i dati relativi alle caratteristiche di ciascuno di questi, ed individuare la soluzione integrativa ad hoc per ogni specifica situazione. E’ sorta quindi l’idea di realizzare un’architettura standard, che consenta di programmare ambienti pervasivi in modo relativamente più semplice. ATLAS introduce una nuova piattaforma hardware, usata dai nodi per interconnettere dispositivi hardware eterogenei, e un sistema per fornire su questa infrastruttura servizi software, che possono essere utilizzati dalle applicazioni eseguite sull’ambiente pervasivo. La struttura di ATLAS è riassunta nella figura 2.5.
Figura 2.5: Schema di massima del framework ATLAS.
La struttura del framework ATLAS prevede quattro livelli. Il livello più basso è il livello fisico, consistente in un’eterogeneità di dispositivi reali tra cui sensori, processori ed attuatori presenti nell’ambiente. Il secondo livello è il livello dei nodi ATLAS (ATLAS Node). Il progetto prevede la realizzazione di un dispositivo hardware “standardizzato”, per l’interconnessione di diversi sensori ed attuatori. Ogni ATLAS node integra un certo numero di sensori ed attuatori del livello sottostante, fornendo una visione orientata ai servizi ai livelli superiori. I nodi di questo secondo livello possono interpretare i dati prodotti dai sensori e modificare l’ambiente, inviando opportuni comandi agli attuatori.
Il terzo livello è quello dei servizi, normalmente implementato su un unico centralizzato server nella rete pervasiva (normalmente una workstation). Consiste in un registro di tutti i servizi presenti nell’ambiente e in un servizio di Service Discovery. Il livello prevede un Context Module, che organizza in un grafo tutti i possibili stati in cui si può trovare l’ambiente, in relazione a caratteristiche osservabili come la temperatura, luminosità, qualità dell’aria etc… Ad ogni possibile stato viene attribuito un diverso grado
di preferenza da parte dell’utente. Il modulo è responsabile di individuare se nel sistema si creano situazioni di contesti non consentiti, e se possibile di eliminarli automaticamente.
L’ultimo livello è il livello delle applicazioni. Si tratta di un ambiente d’esecuzione che fornisce l’accesso mediante librerie software ai servizi presenti, in base alle risorse disponibili. Per esempio servizi per regolare la luminosità della stanza in relazione a determinate condizioni ambientali. Un ATLAS node può collegare un sensore che determina se la televisione è accesa, ad un attuatore per regolare la luminosità della stanza. Se il televisore viene acceso dall’utente, il servizio consente di regolare la luminosità assicurando una buona visione all’utente stesso.
Ulteriori considerazioni le merita il concetto di ATLAS node, la nuova soluzione hardware standard per ambienti pervasivi. Questa piattaforma consente di integrare un insieme di sensori ed attuatori in una rete di dispositivi, ciascuno dei quali può essere interrogato e controllato mediante una comune interfaccia, in modo da facilitarne l’uso alle applicazioni.
Ciascun nodo è un dispositivo hardware modulare, composto da un determinato numero di livelli, ciascuno dei quali implementa un certo insieme di specifiche funzionalità. La configurazione base del nodo prevede tre livelli fondamentali, ciascuno indipendente dall’altro:
1. Processing Layer: è il livello responsabile delle operazioni principali dei nodi ATLAS. E’ dotato di un microcontrollore a 8 MHz, di una memoria flash di 128 KB e di una memoria RAM di 64 KB per le elaborazioni. E’ un livello in grado di garantire un basso consumo energetico e quindi un’elevata autonomia.
2. Communication Layer: il trasferimento dei dati sulla rete dei nodi ATLAS viene gestito mediante le funzionalità di questo livello. Attualmente sono disponibili quattro opzioni: ethernet 10baseT, 802.11b Wi-Fi, Bluetooth e USB.
3. Device Connection Layer: questo livello è utilizzato per collegare i vari sensori ed attuatori ai nodo ATLAS. Attualmente il livello è in grado di collegare fino 32 sensori ed attuatori allo stesso nodo.
Il firmware viene eseguito sull’hardware del primo livello, e consente di integrare i sensori e gli attuatori al middleware ATLAS. Il firmware individua il tipo di
Communication Layer presente, e comunica con il middleware per registrare tutti i dispositivi connessi al nodo ATLAS.. Dopo questa fase di inizializzazione, il nodo è in grado di ricevere comandi e di controllare i sensori e gli attuatori a lui connessi.
Il punto fondamentale di questo progetto è la realizzazione di una piattaforma hardware comune ai nodi di un ambiente pervasivo. In questo modo si può astrarre ai livelli software le problematiche d’integrazione di dispositivi diversi, usufruendo di un’interfaccia comune per l’accesso alle risorse fisiche. Questo semplifica l’integrazione delle componenti hardware e software, che come abbiamo visto è uno dei problemi principali nella realizzazione di applicazioni complesse per ambienti pervasivi. D’altro canto questa soluzione obbliga ad una scelta tecnologica, quella di un nodo ATLAS con specifiche caratteristiche tecnologiche. La speranza degli autori in questo senso, è che tale piattaforma venga accettata come standard de facto dalla comunità scientifica, per lo sviluppo di sistemi di Pervasive Computing.
2.5 La Context Awareness in ambienti di Pervasive Computing
Dalla panoramica che è stata fornita nei precedenti paragrafi, sono emerse le caratteristiche fondamentali di un sistema pervasivo, tra cui la principale che sarà oggetto di studio della tesi, la Context Awareness. Un sistema Context-Aware [1, 2, 3], anche detto Sentient System, è un sistema complesso in grado di adattare le proprie operazioni allo stato dell’ambiente circostante, senza l’esplicito intervento degli utenti, con il fine di migliorare l’usabilità e l’efficacia prendendo in considerazione i dati del contesto ambientale, in cui gli utenti e le risorse si trovano.
Le informazioni di contesto possono essere acquisiste dal sistema in diversi modi: mediante l’utilizzo di sensori, informazioni di rete, lo stato dei dispositivi, oppure utilizzando gli user profile degli utenti. Nelle prime accezioni dei sistemi Context-Aware [15], il contesto veniva descritto principalmente come la locazione delle entità, tra cui persone, risorse ed oggetti in generale. Si parla in questo caso di Location-Aware System, dove l’informazione di contesto appartiene solamente alla tipologia di informazioni necessarie a derivare la posizione geografica rispetto ad un ambiente di riferimento.
Negli anni il termine contesto ha assunto significati più complessi e ricchi di espressività rispetto alle sole informazioni di locazione; una delle definizione più accurate di context in letteratura [1, 2], lo definisce come qualsiasi informazione che può essere
utilizzata per caratterizzare la situazione in cui si trovano le entità (persone, oggetti, luoghi, etc…), che sono considerate rilevanti per l’interazione tra gli utenti e le applicazioni.
Una modalità molto diffusa per classificare le informazioni di contesto, è quella di riferirsi alle diverse dimensioni dei dati contestuali. In [2] si fa riferimento alla distinzione tra la dimensione esterna ed interna dei dati di contesto, ovvero:
1. External (physical) dimension: si riferisce ai dati di contesto che sono acquisibili e misurabili con sensori hardware o interfacce di contesto più complesse (stato della connettività tra nodi, temperatura, tipologia di dispositivi presenti, etc…).
2. Internal (logical) dimension: è una dimensione associata agli utenti, e si riferisce alle interazioni tra gli utenti e i loro comportamenti come: lo stato emotivo, gli obiettivi, i compiti, gli interessi, le preferenze, etc…
Nel resto della tesi ci riferiremo principalmente alla prima tipologia di dati contestuali. La Context Awareness è una caratteristica peculiare di molti sistemi pervasivi, in relazione alla miniaturizzazione dei dispositivi e alla loro elevata mobilità, il rapporto tra il sistema e il contesto ambientale diventa estremamente critico. Possiamo individuare una strutturazione a livelli concettuali di un sistema pervasivo Context-Aware (figura 2.6):
Figura 2.6: Strutturazione concettuale di un sistema Context-Aware.
Partendo dal basso, il primo livello consiste in una collezione di differenti sensori di contesto. La parola sensore non si riferisce solamente a sensori hardware comunemente citati, ma anche qualsiasi sorgente di dati, che può fornire informazioni di contesto utilizzabili. In questo senso i sensori possono essere classificati in due gruppi:
1. Sensori Fisici: sono il tipo di sensore più comunemente utilizzato. I sensori hardware sono in grado di fornire stream di informazioni relativi alle misurazioni di un certo dato contestuale (temperatura, locazione, velocità, accelerazione, luminosità, etc…).
2. Sensori Virtuali: sono sorgenti di informazioni di contesto relativi alle applicazioni software e ai servizi in generale. Per esempio, uno strumento che fornisce dati sulle performance (tempo di servizio, banda di elaborazione, tempo medio di elaborazione, etc…) relativamente ad un certo componente o ad un certo servizio, può essere considerato un sensore virtuale.
Nel resto della tesi considereremo con il termine generico sensori entrambe le tipologie elencate.
Il secondo livello è responsabile della raccolta dei dati primitivi ottenuti dai sensori, utilizzando appropriati driver e API per l’accesso ai dati di sensori fisici e virtuali. Il terzo livello di occupa delle attività di pre-elaborazione dei dati contestuali raccolti. Sono proprie di questo livello le attività di reasoning e di inferenza sui dati dei sensori, attività di interpretazione dei dati in relazione ad uno specifico modello per rappresentare la conoscenza del contesto. Il Context Model è necessario per rappresentare i dati ambientali, in una forma “processabile” dalle applicazioni. Alcuni modelli in letteratura [2] sono:
• Key-Value Model: questo modello rappresenta il modo più semplice di strutturare le informazioni di contesto. La chiave rappresenta un identificatore univoco del tipo di dato contestuale, con un certo valore associato (esempio: Temperatura_Stanza1 = “25 C°”).
• Markup Scheme Model: la rappresentazione dei dati di contesto può essere realizzata definendo un linguaggio di markup XML, che consente di definire una gerarchia di elementi con propri attributi e contenuti.
• Object Oriented Model: la modellazione del contesto ambientale può utilizzare tecniche orientate agli oggetti, in modo da utilizzare la loro potenza espressiva (ereditarietà, incapsulamento, riusabilità, etc…).
• Ontology Based Model: la modellazione può utilizzare il concetto di ontologia. Un’ontologia rappresenta una descrizione del contesto di interesse, in termini di entità con propri attributi, e di relazioni tra queste entità. L’ontologia è uno strumento estremamente usato in letteratura per modellare le informazioni di contesto [16, 17], in modo formale ed espressivo, fornendo la possibilità di utilizzare tecniche di reasoning ed inferenza, per derivare conoscenza implicita dai fatti di contesto disponibili.
Il quarto livello si occupa del processo di memorizzazione e gestione delle informazioni di contesto, organizzando i dati raccolti ed inferiti, offrendoli ai clienti mediante interfacce pubbliche. I clienti rappresentano le applicazioni del quinto livello del framework. Possiamo individuare due modalità di accesso ai dati di contesto da parte delle applicazioni:
1. Modalità Sincrona: le applicazioni richiedono un’informazione contestuale esplicitamente al livello sottostante, sospendendo la propria computazione, ed in base al risultato determinano il proprio comportamento in relazione al contesto.
2. Modalità Asincrona: le applicazioni si registrano per specifici eventi di contesto, e continuano la loro elaborazione. Quando un evento, per cui un’applicazione si era registrata, si verifica, il framework provvede ad inviare una notifica, che viene utilizzata dall’applicazione per eseguire un determinato comportamento, per esempio per adattare le proprie funzionalità al nuovo contesto ambientale.
Nel quinto ed ultimo livello, quello delle applicazioni, sono implementate le reazioni alle segnalazioni di contesto. Il punto focale della tesi sarà proprio l’analisi dei meccanismi di adattività, che le applicazione Context-Aware possono mettere in atto in relazione allo stato del contesto. Il più comune approccio, alla progettazione e sviluppo dei framework Context-Aware distribuiti, è un sistema gerarchico con un’infrastruttura centralizzata, che realizza i livelli interni (2, 3, 4) della pila indicata in figura 2.6, per esempio in una workstation o in un server centrale. Questo approccio è utile per superare i vincoli stringenti di memoria e capacità computazionale dei dispositivi pervasivi, ma comporta un singolo punto di fallimento del sistema e quindi una potenziale mancanza di robustezza.
Un esempio di questo approccio viene descritto nel paragrafo successivo, in modo da fornire una minima visione dello stato dell’arte dei sistemi software Context-Aware.
2.5.1 COBRA: The Context Broker Architecture
COBRA (COntext BRoket Architecture) [18, 19] è un modello architetturale per Pervasive Environment, sviluppato nel 2004 dall’Università del Maryland in Baltimora, con particolare attenzione alle problematiche del Context-Aware Computing in relazione al modello delle case intelligenti (Smart House). Come abbiamo visto, con il termine casa intelligente si intende un ambiente chiuso e limitato, in cui sono presenti dispositivi pervasivi in grado di interagire con gli utenti umani. L’obiettivo dei sistemi di questo tipo è di percepire lo stato dell’ambiente circostante, con il fine di fornire servizi che incontrino in ogni caso le preferenze degli utenti nella vita di tutti i giorni.
Il cuore dell’architettura è caratterizzato da un’entità server specializzata ed intelligente, il Context Broker, che riceve informazioni legate al contesto dai dispositivi e dagli agenti presenti, le relaziona, definendo un modello centralizzato e condiviso dell’ambiente e di tutto ciò che si trova ad operare al suo interno, e si preoccupa di mantenerlo nel tempo coerente, e privo di inconsistenze a seguito di nuove acquisizioni.
Un punto chiave nella realizzazione di quest’architettura è lo sviluppo e l’utilizzo di una serie di ontologie comuni, attraverso le quali agevolare la comunicazione fra i diversi agenti e modellare l’ambiente attuale della Smart House. Tale ambiente è descritto da un insieme di ontologie definite nel linguaggio di mark-up OWL (Ontology Web Language) [20], per abilitare agenti a processare e ragionare sul contesto, includendo un motore inferenziale [21] per derivare conoscenza implicita, ed individuare e risolvere inconsistenze, applicando un approccio policy-based per controllare come condividere tra gli utenti le informazioni di contesto. La struttura del Context Broker è costituita da quattro componenti funzionali:
• Context Knowledge Base: con il compito di immagazzinare in maniera persistente la conoscenza del contesto. Fornisce un set di API per consentire alle altre componenti di accedere alle informazioni memorizzate. Contiene anche l’ontologia dello specifico ambiente e le regole euristiche associate ad esso (livello 3 e 4).
• Context Reasoning Engine: è un motore che applica algoritmi di inferenza sulle informazioni di contesto immagazzinate. Si possono avere inferenze che usano le ontologie per dedurre conoscenza di contesto implicita, ed inferenze che usano la conoscenza per individuare e risolvere inconsistenze (livello 3 della figura 2.6).
• Context Acquisition Module: è una libreria di procedure che rappresenta una sorta di middleware, per l’acquisizione di informazioni dai sensori (livello 2 figura 2.6).
• Policy Management Module: è un insieme di regole d’inferenza definite, sia per valutare i privilegi d’accesso associati alle differenti entità, sia per condividere particolari frammenti delle informazioni di contesto, e ricevere notifiche dei cambiamenti dell’ambiente.
Il modello con broker centralizzato affronta due problemi chiave del Pervasive Computing: supportare dispositivi con limitate capacità e gestire la privacy dell’utente. Grazie ad un Context Broker che opera su un computer fisso, la complessità di acquisire e ragionare su informazioni contestuali è spostata dai dispositivi mobili, verso il broker dotato di elevate risorse, inoltre le complicazioni nel garantire security, trust, e privacy polices, sono semplificate dalla presenza di un manager centralizzato.
In base al progetto di tale architettura è stato realizzato il prototipo di una “intelligent meeting room” che usa COBRA. Tale modello di prova offre servizi ed informazioni ai partecipanti, sulla base delle loro necessità correnti. In futuro gli sviluppatori di questa architettura prevedono di migliorare il meccanismo di inferenza logica utilizzato, utilizzando per processi di ragionamento un meta interprete Prolog.
2.6 Una visione più estesa, l’High Performance Pervasive Computing
Nell’ultimo paragrafo abbiamo introdotto un limite della letteratura attuale nell’affrontare le problematiche del Pervasive Computing, ovvero il riferimento continuo a situazioni di case intelligenti. In ambienti di questo tipo, il problema dell’integrazione di componenti eterogenee è più semplice da affrontare, alla luce dell’estrema semplicità dei dispositivi in gioco e della limitatezza dell’ambiente circostante (come estensione e come complessità degli eventi). Nel resto della tesi è invece obiettivo introdurre le problematiche
del Pervasive Computing, in situazioni più complesse ed imprevedibili, che introducano la necessità di un’integrazione tra diverse componenti base, sia hardware che software, in applicazioni complesse, caratterizzate dalla forte necessità di elaborazioni ad elevate prestazioni. Possiamo parlare in questo senso di High Performance Pervasive Computing (HPPC), ovvero un sistema pervasivo di dispositivi ubiqui, in cui le prestazioni rappresentino un elemento cruciale. Un esempio di applicazioni di questo tipo, analizzato nei capitoli successivi della tesi, sono le applicazioni per la gestione delle emergenze ambientali [22].
La gestione delle emergenze richiede che operatori mobili e non (polizia, medici, vigili del fuoco, operatori ambientali, dirigenti della protezione civile, ecc…) collaborino in situazioni critiche e pericolose, e/o con continuità, avendo accesso ed elaborando in tempo reale una grande quantità di informazioni e di conoscenza, allo scopo di automatizzare gli specifici processi di controllo e di decisione.
La piattaforma distribuita per queste applicazioni, include come componenti essenziali gli operatori di cui sopra (piattaforma “user centric”), ma deve integrare anche risorse di calcolo, di conoscenza e comunicazione le più eterogenee, tra cui possiamo individuare:
• sistemi centrali basati su tecnologia commodity, come server general-purpose (cluster di PC/WS, multicluster, server multiprocessor SMP, macchine parallele, eventualmente mainframe) e server specializzati (Data & Knowledge Server), eventualmente organizzati in Virtual Private Network o Grid;
• sistemi decentrati sia di tipo fisso che mobile, come sensori, attuatori, PDA, cellulari, dispositivi per Wearable Computing;
• vari tipi di reti di comunicazione: oltre che fisse, sono di interesse in particolare le reti wireless, reti di sensori, reti ad hoc, etc…, con protocolli e prestazioni diverse a seconda dello standard adottato.
Durante la gestione delle emergenze, alcune funzionalità anche non banali sono effettuate in locale nelle unità decentrate, sia singolarmente che attraverso la loro collaborazione. In alcuni casi, le unità decentrate dispongono di una certa potenza di elaborazione, in altri possono essere dotati di opportuni nodi d’interfaccia, con specifiche capacità di calcolo, memorizzazione e comunicazione. Altre funzionalità sono delegate in
tempo reale a sistemi centrali, per esempio: simulazioni complesse, classificazione del rischio, supporto alle decisioni (Decision Support System, DSS), azioni proattive, etc… Complessivamente viene utilizzata dinamicamente una molteplicità di risorse eterogenee, dislocate su più siti, con modalità che garantiscano la Qualità del Servizio (QoS) richiesta nelle varie fasi della gestione delle emergenze. Tra le componenti base si può inoltre assumere tutta una serie di servizi:
• localizzazione di eventi, condizioni climatiche, di traffico, etc…
• riconoscimento di eventi, di persone e di comportamenti, congestione di risorse, per la gestione delle emergenze o per la gestione del traffico, etc…
• esecuzione di modelli complessi di simulazione, gestione della conoscenza, sistemi di supporto alle decisioni, gestione dei dati, etc…
Il raggiungimento dell’obiettivo della QoS richiede la capacità di integrare la molteplicità di risorse, componenti (hardware, software e utenti) e servizi, in applicazioni complesse di Pervasive Computing, con vicoli prestazionali importanti (da cui il termine High Performance Pervasive Computing).
Un approccio “classico”, o “tradizionale” di Grid Computing, che si limiti alla gestione dinamica di risorse di calcolo generali (e comunicazione) nei confronti di Web/Grid Service, non risolve il problema della complessità dell’integrazione in una applicazione di gestione delle emergenze. Occorre, invece, la capacità di sviluppare applicazioni che compongano servizi e funzionalità aventi caratteristiche molto diverse da quelle tradizionali di calcolo scientifico o di Web Computing, con vincoli stringenti di QoS, facendo convivere nella maniera migliore e non convenzionale, le risorse dei diversi “strati” del sistema (applicazioni, nodi, sensori, reti di comunicazione, etc…). Le funzionalità delle applicazioni di HPPC comprendono tra l’altro:
a) elaborazioni “pesanti” dal punto di vista computazionale e/o della gestione dei dati, come previsioni, simulazioni, algoritmi di Data Mining e Profiling, spesso basati su modelli che comportano un’esplorazione intensiva dello spazio delle soluzioni, e su modelli operanti su grandi basi o stream di dati, così come elaborazione di strategie di comunicazione (classificazione, Network Topology Discovery, ecc).
b) trattamento di eventi asincroni relativi ai cambiamenti nel contesto ambientale, e conseguente attivazione di azioni da parte di dispositivi e/o operatori (processo di adattività).
Fondamentale è la constatazione che, per risultare efficaci, le elaborazioni e le azioni devono tener conto prioritariamente: del contesto in cui si svolgono, e delle intenzioni o preferenze degli utenti. Il problema di sviluppare applicazioni con il desiderato livello di QoS, tipicamente variabile durante lo svolgimento dell’applicazione, adattandosi agli eventi ed alla conoscenza ricavata dinamicamente, con caratteristiche di location & context-awareness, comporta una complessità ed un grado di innovazione, scientifica e tecnologica, ben maggiore rispetto alla semplice invocazione e composizione di servizi come in una Grid tradizionale.
