Un esempio di applicazione di HPPC per la gestione delle
emergenze
Nel capitolo precedente abbiamo introdotto alcuni concetti chiave della tesi: il Pervasive Computing, i sistemi Context-Aware, lo stato dell’arte di questi paradigmi, ed è stato infine descritto il settore che ci interessa maggiormente, l’High Performance Pervasive Computing. Nel seguente capitolo l’obiettivo sarà quello di introdurre le caratteristiche della struttura degli ambienti di HPPC, introducendo la Pervasive Grid e presentando un esempio concreto di applicazione per la gestione delle emergenze, formulato nel corso della tesi.
3.1 La Pervasive Grid
Nel paradigma del Grid Computing, le Griglie Computazionali [5] sono costituite da risorse di calcolo eterogenee, quali, ad esempio, computer server, cluster, workstation, mainframe, grandi archivi di dati, etc…, connesse da reti caratterizzate da differenti bande di comunicazione e caratteristiche tecnologiche. Una Griglia Computazionale è caratterizzata da un insieme di servizi (middleware), che includono autenticazione, sicurezza, autorizzazione, naming, scheduling e meccanismi per l’esecuzione remota, che rendano uniforme l’interfaccia verso i diversi gestori locali.
La congiunzione dei paradigmi di Grid Computing e di Pervasive Computing [23, 24] ha portato allo sviluppo del paradigma del Pervasive Grid Computing, il cui scopo è quello di estendere le griglie classiche con caratteristiche di pervasività, quali l’integrazione spontanea e trasparente di dispositivi mobili, la Context Awareness, la proattività, e così via dicendo. Si parla in questo senso di Next Generation Grid [24], ovvero una nuova visione del concetto di Grid Computing, che non sia più solo destinata ad applicazioni scientifiche, ma che consenta di utilizzare una collettività di risorse di calcolo, distribuite e mobili, per applicazioni di notevole importanza per la collettività.
Una Grid nasce allo scopo di permettere una condivisione flessibile, sicura e coordinata di risorse tra gruppi dinamici di individui, istituzioni e sistemi. L’attributo “pervasivo” indica una combinazione di elevata mobilità ed integrazione nell’ambiente: il software è pervasivo se è in grado di adattarsi ai dispositivi che si rendono disponibili. Dunque una griglia pervasiva può essere vista come una rete dinamica di dispositivi eterogenei, per caratteristiche e per mobilità, che permette una condivisione flessibile e coordinata di risorse di vario tipo, per l’esecuzione di computazioni distribuite su nodi d’elaborazione estremamente eterogenei, tra cui:
• Nodi delle Grid tradizionali: workstation, cluster, multiprocessor SMP/NUMA, etc…
• Nodi del Pervasive Computing: sensori, interfacce di contesto, palmari, dispositivi indossabili, etc…
La figura 3.1 riassume l’eterogeneità dei dispositivi della Pervasive Grid, che rappresenta l’ambiente di riferimento per le considerazioni e sviluppi della parte restante della tesi.
Il paragrafo successivo introduce un esempio originale, formulato durante il lavoro di tesi, di applicazione ad alte prestazioni per la gestione delle emergenze ambientali. La necessità di introdurre un esempio concreto di HPPC, nasce dall’esigenza di individuare le caratteristiche fondamentali dell’adattività al contesto ambientale, in modo da procedere poi con l’individuazione di tecniche risolutive al problema della Context Adaptation, che verranno illustrate nei capitoli successivi.
3.2 Introduzione ad un esempio di applicazione pervasiva per la gestione
delle emergenze
L’esempio che è stato formulato durante la tesi è ispirato al lavoro compiuto dall’Università di Lancaster [25], relativamente alla gestione delle situazioni di inondazioni fluviali. Queste situazioni d’emergenza sono estremamente frequenti in Gran Bretagna, dove il clima particolarmente piovoso rende questi scenari più una consuetudine autunnale, che situazioni sporadiche. Ecco quindi la necessità di impiegare “strumenti informatici” per lo sviluppo di sistemi integrati di gestione delle emergenze.
In termini economici, i danni collegati ad un fenomeno d’inondazione sono direttamente proporzionali al livello dell’inondazione, e al ritardo con cui vengono generati gli allarmi necessari ad avvisare la collettività dell’insorgere dell’emergenza [25]. L’obiettivo principale di questo sistema è quello di generare messaggi d’allarme alla protezione civile e alla collettività, pianificando gli interventi per la gestione dell’emergenza, fornendo un valido sistema di supporto alle decisioni [26].
Gli idrogeologi hanno spesso affrontato negli anni il problema della previsione di fenomeni d’inondazione. In alcuni sistemi tradizionali, le informazioni sul livello e sulla velocità dell’acqua in diversi punti di un fiume sono sia trasmessi a server remoti, che ottenuti manualmente dagli operatori. Questi dati sono spesso usati come input per modelli complessi di simulazione [27, 28], che tipicamente richiedono capacità computazionali notevoli, per poter essere eseguiti con un tempo di completamento accettabile. Per questo frequentemente sono state utilizzate piattaforme distribuite di griglia. Purtroppo questi approcci tradizionali soffrono di alcune carenze importanti, tra cui:
• Ai sensori nella rete viene spesso attribuito un ruolo minimo e marginale. Modificare il comportamento dei sensori richiede spesso un intervento umano.
• I sensori sono strumenti che non sono in grado di adattare il loro comportamento alle esigenze dell’ambiente (per esempio modificando l’accuratezza dei dati prodotti), ma sono dei semplici strumenti in grado di eseguire solamente misurazione e nessun calcolo specifico.
• A seguito di cambiamenti ambientali, il sistema può necessitare di una riconfigurazione, sia dell’hardware che delle sue applicazioni, che richiede un intervento manuale di tecnici specializzati.
• I nodi locali d’elaborazione non sono in grado di realizzare un uso intelligente dei dati dei sensori, ma sono spesso usati solo per il trasporto dei dati prodotti verso sistemi di back-end, in grado di eseguire i complessi modelli di simulazione (esempio cluster di nodi server all’interno di un’istituzione).
• Le applicazioni sono utilizzate solo da esperti, in grado di interpretare i dati forniti dalle previsioni e di avvisare il personale della protezione civile. Non ci sono interazioni real-time tra i soccorritori ed il sistema distribuito di previsione, e non esiste un vero e proprio supporto alle decisioni.
Questo esempio di sistema per il trattamento delle emergenze ha invece l’obiettivo di riconsiderare il ruolo tradizionale dei sensori e dei dispositivi mobili, che non sono più una rete indipendente, ma fanno parte integrante di un’infrastruttura di calcolo unica e distribuita, che abbiamo definito nel paragrafo precedente con il termine di Pervasive Grid.
3.2.1 Architettura dell’esempio applicativo
Nel seguente paragrafo sarà descritta l’architettura proposta per il sistema d’esempio per la gestione delle emergenze d’inondazione. I dispositivi hardware presenti e i loro ruoli nell’architettura sono i seguenti:
1. Sensori: sono dispositivi pervasivi usati dal sistema per rilevare dati ambientali. Possiamo avere sensori di diverso tipo, tra cui in particolare possiamo individuare:
• Sensori di pressione: sono usati per determinare la profondità di un flusso d’acqua, producendo uno stream di misurazioni.
• Ultrasound flow sensor: sensori in grado di determinare la velocità di un flusso d’acqua, producendo uno stream di misurazioni.
• Fotocamere digitali: sono dispositivi in grado di realizzare fotografie digitali ad alta definizione dell’area del fiume di loro competenza.
I sensori sono organizzati in insiemi disgiunti di dispositivi, ciascuno assegnato ad una specifica area geografica del fiume. Tutti i sensori appartenenti ad uno stesso insieme sono collegati, tramite connessioni wireless (bluetooth, WI-Fi, etc…), ad un nodo specifico d’interfaccia con il resto del sistema.
2. Nodi d’interfaccia: si tratta di nodi con un’importanza cruciale nella Pervasive Grid. Tali dispositivi hanno le seguenti funzionalità:
• Raccogliere i dati ricevuti tramite rete wireless dai sensori..
• Ogni nodo d’interfaccia è un Acess Point, in grado di coprire una opportuna area geografica di competenza (cella), e quindi di servire le richieste ricevute dai client presenti in quell’area e di gestire i dati dei sensori relativi alla propria cella.
• Alcuni nodi d’interfaccia sono in grado di collegarsi con reti wired di specifiche istituzioni. Possono essere collegati a cluster di workstation, a griglie tradizionali e a sistemi che offrono servizi esterni (servizi meteorologici, informazioni GIS, rete GSM o UMTS, etc…).
3. Dispositivi pervasivi degli utenti: si tratta di dispositivi mobili a disposizione degli utenti del sistema. Possiamo avere PDA (Personal Digital Assistant) a disposizione del personale della protezione civile, che effettua i soccorsi, e telefoni cellulari a disposizione degli abitanti delle aree protette dal servizio di gestione e previsione dell’emergenza di inondazione. I dispositivi a disposizione degli utenti
sono collegati, tramite collegamenti wireless, ad un nodo d’interfaccia, che copre la cella dove attualmente l’utente si trova. Tramite il nodo d’interfaccia, a cui è collegato, l’utente può utilizzare i servizi e le risorse disponibili nella Pervasive Grid.
4. Altri nodi di elaborazione: si tratta di piattaforme distribuite ad alte prestazioni, come cluster di macchine, reti di workstation, etc... Forniscono il supporto, al resto della Pervasive Grid, per l’esecuzione delle computazioni più pesanti, che richiedono tempi di completamento fortemente stringenti. Fanno sempre parte dell’infrastruttura di back-end, sistemi che erogano servizi esterni, utili nel nostro caso alla previsione delle inondazioni. Per esempio la rete di un’istituzione specifica, che fornisce dati sulle previsioni meteo, oppure sistemi per i servizi GIS (Geographic Information System). Nell’esempio, la distinzione tra risorse di back-end e dispositivi mobili sullo scenario d’emergenza, è puramente una distinzione logica, nel senso che le computazioni eseguite possono essere realizzate su qualsiasi dispositivo della griglia pervasiva, sia fisso che mobile, in base alla disponibilità delle risorse e dei collegamenti presenti.
A livello di rete sono tipiche le problematiche già affrontate sulle reti cellulari, per quanto riguarda la copertura dei nodi d’interfaccia, la gestione di procedure di handover, per consentire ad un client in movimento di usufruire senza interruzioni dei servizi del sistema, per esempio effettuando lo “switch” delle comunicazioni tra un nodo d’interfaccia ed un altro vicino. Nel seguito del testo trascureremo queste problematiche di rete, che comunque sono già state studiate e risolte in altri contesti, cercando di dare enfasi su cosa ci aspettiamo che l’applicazione faccia per il supporto all’emergenza, cercando di individuare i suoi possibili casi d’uso.
La successiva figura 3.2 riassume quanto detto in precedenza sulla struttura fisica del sistema, individuando le tipologie di risorse della Pervasive Grid, le diverse reti di comunicazione wired o wireless, e il partizionamento in aree di competenza di ciascun nodo d’interfaccia, che consente una gestione più semplice dei clienti e delle informazioni ambientali, strutturando la gestione dell’emergenza in sottosistemi cooperanti e distribuiti.
Figura 3.2: Architettura dell’esempio di applicazione per la gestione delle emergenze di inondazioni.
3.2.2 Casi d’uso del sistema di gestione dell’emergenza
Nel seguito di questo paragrafo saranno descritti informalmente alcuni casi d’uso dell’applicazione di esempio. Il sistema che abbiamo introdotto ha due scopi fondamentali: per prima cosa fornire previsioni del fenomeno dell’emergenza di inondazione, ed in secondo luogo suggerire, a chi si occupa della mitigazione del problema, le scelte da intraprendere per la sua gestione.
1) Funzionalità di previsione e supporto alle decisioni:
L’applicazione per il supporto alle inondazioni, prevede la presenza di un modulo client, eseguito sui dispositivi a disposizione dei soccorritori (personale della protezione civile, vigili del fuoco, etc…). Possiamo in questa sede immaginare, in modo informale, alcune funzionalità che sono d’interesse per questo modulo:
1. Come abbiamo già visto, ogni PDA è collegato mediante rete wireless ad un nodo d’interfaccia, che copre l’area di pertinenza. Il terminale deve costantemente informare l’utente della qualità del segnale con il nodo d’interfaccia, e segnalare all’utente quando è necessario cambiare nodo d’interfaccia a cui siamo connessi (handover, che può avvenire manualmente o automaticamente).
2. L’utente sul suo PDA può monitorare lo stato attuale della Pervasive Grid. Ovvero l’utente ha la possibilità di verificare quali nodi nella rete sono attualmente collegati al nodo d’interfaccia corrente, in modo da sapere quale copertura fornisce il sistema istante per istante.
3. L’utente può esplicitamente richiedere di visionare i dati prodotti dai sensori, richiedendo operazioni su questi. Per esempio può richiedere il calcolo della velocità di crescita del livello del fiume in un certo tempo, oppure richiedere il valore medio della velocità dell’acqua, su un certo tratto specifico da lui indicato graficamente sul dispositivo (per esempio su un Touch Screen nel palmare).
4. L’utente deve avere la possibilità di monitorare, sul suo palmare, lo stato attuale dell’emergenza. Deve cioè avere sempre sotto osservazione la mappa geografica della porzione d’interesse del fiume, e avere informazioni visive sull’attuale stato dell’inondazione, come il livello dell’acqua nelle diverse aree colpite o meno dall’emergenza.
5. I dati meteorologici possono essere, sia richiesti dal sistema per l’esecuzione di algoritmi di previsione, sia richiesti dall’utente direttamente, indicando una specifica zona a cui è interessato e il termine della previsione meteo. Questi dati possono essere ottenuti da servizi esterni al sistema, per esempio relativi ad istituzioni specializzate alla produzione e gestione di questo tipo di dati.
6. Similmente al caso precedente, anche l’interconnessione con un sistema GIS (Geographic Information System) può essere necessaria, soprattutto per l’esecuzione di algoritmi di supporto alle decisioni, che possono avere la necessità di richiedere quali risorse sono dislocate nel territorio, quali infrastrutture sono
Le funzionalità che abbiamo immaginato richiedono l’interconnessione della Pervasive Grid con sistemi esterni, che forniscano specifici servizi. Molto importante è inoltre la capacità del sistema di supportare i soccorritori, con previsioni dell’inondazione. Possiamo considerare la possibilità di effettuare due tipi di previsioni:
• Previsioni locali e a breve termine. Si tratta di previsioni di corto raggio rispetto alla posizione attuale dell’utente (poche centinaia di metri o chilometri), e che riguardano alcuni minuti o massimo decine di minuti successivi all’istante attuale della richiesta da parte dell’operatore.
• Previsioni globali a medio lungo termine. Si tratta di previsioni nell’ordine delle ore o al massimo dei giorni rispetto al tempo della richiesta di previsione, e per scenari complessivi dell’inondazione.
Esistono diversi modelli di previsione, alcuni di questi rientrano nella prima famiglia [29], mentre altri nella seconda [27, 28]. L’utente deve avere la possibilità di eseguire queste previsioni, indicando, tra l’altro, alcuni parametri prestazionali o funzionali che possono essere tra gli altri:
• Un possibile tempo massimo di completamento della previsione. L’operatore è interessato ad ottenere il risultato della previsione, sul suo dispositivo mobile, in un tempo utile alla gestione e mitigazione dell’emergenza, in modo da decidere come operare.
• Un grado di attendibilità che si immagina di ricevere per i dati ottenuti dalla previsione. L’attendibilità dei risultati della previsione dipende dal modello matematico di previsione che è stato utilizzato. In molti modelli presenti in letteratura [27, 28, 29], la complessità dei calcoli, sia in tempo, che in spazio occupato, dipende direttamente dalla precisione richiesta (in particolare dal numero di equazioni differenziali da risolvere utilizzando metodi numerici).
Spetta al sistema la scelta dell’algoritmo di previsione migliore, in base alle richieste fornite dall’utente, e di avvisarlo se i vincoli indicati sono eccessivamente stringenti per l’esecuzione del modello scelto. L’esecuzione in tempo utile dei modelli di previsione è un
primo caso, che giustifica la scelta di un esempio di questo tipo per descrivere il settore dell’High Performance Pervasive Computing. L’esecuzione della previsione richiede vincoli prestazionali (contratti di QoS adeguati) per essere completata in tempo, che comportano la scelta di implementazioni alternative degli algoritmi utilizzati, e una distribuzione del calcolo e dei dati, tra i nodi della griglia pervasiva, sia questi singoli nodi mobili ubiqui, che sistemi tradizionali come cluster o nodi multiprocessor. L’esecuzione parallela e distribuita dei task possono richiedere diverse risorse di calcolo, che dipendono dal tipo di modello richiesto (globale o locale) e dal tempo di completamento indicato. In base alla situazione attuale d’emergenza, l’esecuzione può avvenire sui diversi dispositivi, organizzando una computazione complessa, distribuita ed organizzata.
Riprendiamo l’analisi informale delle funzionalità del sistema. La previsione del fenomeno di crisi comporta le seguenti necessità:
7. L’utente deve avere la possibilità di eseguire delle previsioni e visualizzare i risultati sulla mappa nel proprio dispositivo. I risultati delle previsioni possono essere resi pubblici agli altri utenti del sistema, in modo da condividere informazioni.
8. Il sistema, dopo l’esecuzione di una previsione, deve consentire agli operatori, se necessario, di segnalare mediante una notifica specifica lo stato dell’emergenza, ed eventualmente richiedere l’evacuazione del personale civile dall’area colpita. In questo senso l’interconnessione tra il sistema e la rete radiomobile GSM/UMTS può essere utile per eseguire le notifiche, in modo immediato e capillare.
Fino ad ora tutte le funzionalità espresse descrivono un sistema per la previsione dell’evoluzione di un’emergenza. Il sistema comunque deve supportare gli utenti anche nella gestione del fenomeno corrente. Ulteriori funzionalità possono quindi essere:
9. Dopo aver prodotto i dati della previsione, il sistema deve suggerire all’utente le azioni da intraprendere. Per esempio, se la previsione indica che il livello e l’espansione dell’inondazione renderanno pericolosa o inutilizzabile una certa via di comunicazione, il sistema deve segnalarlo all’utente, suggerendo per esempio delle vie alternative, o comunque la necessità di avvisare la popolazione (il modello
meteorologici per la previsione e i dati del GIS per la gestione dell’emergenza). Il soccorritore può utilizzare queste informazioni per chiudere preventivamente determinate strade, in modo da prevenire incidenti.
10. Il sistema deve indicare all’utente la presenza delle squadre di soccorritori nel territorio. L’utente può ricevere dalla direzione centrale dell’emergenza, richieste d’intervento per specifiche aree.
2) Direzione centrale di coordinamento dell’emergenza
Un sistema per la gestione dell’emergenza deve senz’altro offrire un supporto locale ai singoli soccorritori. Ma un’emergenza deve essere anche affrontata nella sua complessità globale, analizzando il problema in modo centralizzato, così da pianificare l’uso delle risorse sia materiali che umane. In questo senso l’applicazione prevede una direzione centrale dell’emergenza, in grado di effettuare una gestione di alto livello e centralizzata. L’accesso al sistema, da parte del personale di coordinamento e amministrativo, può avvenire mediante terminali fissi, dotati di moduli client per l’accesso al sistema generalmente diversi da quelli a disposizione nei PDA dei soccorritori. In questo caso occorre:
1. Supportare la direzione centrale eseguendo modelli di previsione prevalentemente a lungo termine e per vaste aree di interesse.
2. Accompagnare le previsioni con suggerimenti sulla gestione delle risorse, avvisandoli il personale interessato mediante messaggi sui PDA.
3.2.3 Descrizione informale dei casi d’uso
Nel seguito del paragrafo saranno descritte informalmente le caratteristiche dei casi d’uso dell’applicazione che prendiamo in esempio. Faremo questo utilizzando degli schemi tipo grafi di workflow (figure 3.3, 3.4 e 3.5), senza avere nessuna pretesa di utilizzare per la loro definizione strumenti formali, presenti in letteratura, ma cercando di fornire un’idea di massima delle scelte e delle conseguenti azioni del sistema che cerchiamo di descrivere.
Figura 3.4: L’utente richiede una previsione dell’emergenza di inondazione.
Le considerazioni, del tutto informali e discorsive, che sono state fornite nella parte precedente del capitolo, hanno l’obiettivo di fornirci una prima inquadratura di un’applicazione di supporto alla gestione delle emergenze, in ambiente di Pervasive Grid, con l’obiettivo di individuare la dipendenza del software nei confronti dell’ambiente e della sua estrema dinamicità in situazioni di emergenza.
Dai grafi che sono stati descritti emerge come i tre principali scenari d’uso individuati, cioè:
1. la richiesta del monitoraggio dello stato attuale dell’emergenza, 2. la richiesta di previsione dello stato dell’emergenza,
3. la richiesta di esecuzione di modelli di supporto alle decisioni per l’emergenza, siano dipendenti da aspetti di contesto relativi a:
1. Stato della connettività tra i nodi mobili degli utenti e i corrispondenti nodi di interfaccia.
2. Stato della connettività tra i nodi d’interfaccia ed il resto del sistema. 3. Stato della connettività dei sensori con i nodi d’interfaccia.
4. Capacità di calcolo e di memorizzazione dei dispositivi utilizzati dagli utenti. In particolar modo emerge come un sistema di questo tipo debba adattarsi dinamicamente alla situazioni ambientali elencate, dove per adattamento identifichiamo attività di riconfigurazione delle computazioni eseguite dai servizi del sistema. Le riconfigurazioni possono essere prevalentemente di due tipologie:
1. Riconfigurazioni non-funzionali: hanno come obiettivo la variazione di proprietà non-funzionali di una componente o di un modulo del sistema, mantenendo le medesime interfacce. Esempi di proprietà non-funzionali sono la performance, la latenza, la disponibilità. Queste riconfigurazioni sono quindi assimilabili ad ottimizzazioni, almeno nel caso in cui riescano a migliorare le proprietà non-funzionali in oggetto.
Un esempio di riconfigurazioni di questo tipo è quello in cui una stessa struttura di una computazione si adatta (si riconfigura), per poter rispettare un certo contratto di QoS, ad esempio per garantire il desiderato valore del tempo di servizio o il
desiderato valore del tempo di completamento di un componente/modulo (o di una collezione di componenti/moduli). L’esigenza può essere originata dal fatto che le prestazioni degradano, a causa di modifiche dinamiche nel valore/dimensione dei dati, o della presenza di una situazione d’emergenza, oppure dalla modifica a tempo d’esecuzione del contratto richiesto dagli strati superiori. In tali casi, fondamentalmente si tratta dello stesso componente o modulo che può riconfigurarsi, ad esempio replicando processi o partizionando dati parametricamente, ma senza comportare una modifica del codice delle funzionalità. Questo caso verrà definito nel corso della tesi come adattività delle proprietà non funzionali del sistema (nel caso particolare adattività delle performance). In riferimento all’esempio, per garantire il tempo massimo di completamento di una richiesta di previsione, il modulo che esegue la computazione può variare dinamicamente il proprio grado di parallelismo (se si tratta di un modulo parallelo), in modo da mantenere il contratto di QoS richiesto dall’utente. La variazione può essere necessaria, a causa di eventi ambientali che comportino la disconnessione di un insieme di nodi d’elaborazione, oppure una situazione di congestionamento delle risorse dovuta all’emergenza.
2. Riconfigurazioni delle funzioni: Un’altra situazione è quella in cui la computazione viene ristrutturata profondamente, cambiando l’implementazione delle funzionalità di un modulo o componente, o parti di esse. La sostituzione dell’implementazione di un modulo o componente con un’implementazione alternativa, può essere necessaria come reazione ad un cambiamento del contesto ambientale, in cui l’esecuzione della seconda versione è preferibile. Si può ancora distinguere due sottocasi di interesse: uno in cui le implementazioni alternative sono prefissate, l’altro in cui le stesse sono fornite dinamicamente, a tempo d’esecuzione, ad esempio mediante plugin associati ad un nuovo contratto richiesto dagli strati superiori. In entrambe le accezioni, questi casi sono definiti nella tesi come adattività delle funzioni o ristrutturazioni delle funzioni.
Nel capitolo successivo si analizzerà una soluzione generale del problema dell’adattività del sistema di gestione dell’emergenza di inondazione, proponendo una sua strutturazione a componenti, che consenta di risolvere le problematiche di Context
