La Context Awareness in ASSIST: introduzione al modello ASSISTANT Capitolo V

La Context Awareness in ASSIST: introduzione al

modello ASSISTANT

Nel capitolo precedente abbiamo introdotto una strutturazione a componenti cooperanti, con l’esempio di applicazione pervasiva (HPPC) per la gestione delle emergenze di inondazioni. Abbiamo indicato un modo di procedere, generale ed astratto, per quanto riguarda l’adattività al contesto ambientale, che alcune componenti funzionali possono realizzare.

Le applicazioni di High Performance Pervasive Computing sono caratterizzate da richieste degli utenti che innescano computazioni parallele complesse, distribuite sui nodi della Pervasive Grid, sia piccoli nodi mobili decentrati, che nodi di elaborazione tradizionali. Queste computazioni, oltre ad essere adattive al contesto ambientale, sono vincolate da contratti di QoS, che gli utenti richiedono per esempio per il tempo di completamento delle operazioni di una previsione. La necessità di avere vincoli di QoS sui parametri prestazionali di un’applicazione parallela, impone la conoscenza di un opportuno modello dei costi, per valutare le prestazioni e stabilire tutte quelle riconfigurazioni non funzionali per adattare la computazione alle risorse disponibili, mantenendo i vincoli sui tempi di servizio, banda d’elaborazione, tempo medio di completamento, etc… Da questo punto di vista possiamo adottare, come ambiente di programmazione parallela ad alte prestazioni, il modello di ASSIST (A Software development System based on Integrated Skeleton Technology) [8, 9], sviluppato dal gruppo di Architetture Parallele e Distribuite del Dipartimento di Informatica dell’Università di Pisa.

Nel capitolo introdurremo brevemente il modello di programmazione parallela di ASSIST, e gli aspetti di adattività e dinamicità che sono stati già implementati. Inoltre, verrà proposta un’integrazione al modello di programmazione, per la gestione dei processi di Context Awareness, secondo lo schema generale esposto nel precedente capitolo ed applicato in concreto ad ASSIST. Nella proposta, il modello ASSIST, integrato con gli strumenti di adattività al contesto, prenderà nome di ASSISTANT (ASSIST with Adaptivity and coNText awareness).

5.1 Breve richiamo al modello di programmazione di ASSIST

ASSIST è un modello di programmazione orientato allo sviluppo di applicazioni parallele e distribuite ad alta performance, secondo un approccio unificato. La programmazione parallela strutturata, basata sul modello a skeleton [42, 43], è un approccio che va incontro alla complessità di progettazione delle applicazioni ad alta performance. La validità dell’approccio è stata provata per macchine parallele omogenee (MPP, Cluster, cluster di SMP), ma risulta ancora più valida per piattaforme dinamiche ed eterogenee, come le griglie computazionali. In generale la validità dei modelli a skeleton può essere così riassunta:

• I programmi paralleli sono scritti attraverso un linguaggio di coordinamento come composizione di paradigmi paralleli predefiniti, chiamati appunto skeleton.

• Per ogni skeleton è conosciuto un insieme di template d’implementazione, e un modello di costi, entrambi parametrici, che possono essere usati per ottimizzare la compilazione e il supporto a run-time.

• Dai precedenti punti segue che scrivere un programma parallelo è piuttosto veloce e facile, poiché le decisioni più difficili riguardanti l’implementazione parallela vengono delegate alla compilazione e al supporto a tempo d’esecuzione.

Pur con i suoi vantaggi, l’approccio classico a skeleton ha degli svantaggi, in termini di potenza espressiva ed efficienza per applicazioni complesse, flessibilità nell’adattarsi ad una varietà di combinazioni di programmi paralleli, così come in termini di interoperabilità ed idoneità alla programmazione basata su componenti per le applicazioni Grid-Aware. ASSIST da questo punto di vista, invece, si pone come un’evoluzione dei classici modelli a skeleton.

5.1.1 Programmi ASSIST ad alta performance definiti come grafi

In diverse applicazioni le strutture di computazione esprimibili con i classici skeleton di programmazione parallela non sono adeguate. Infatti:

• molte applicazioni possono essere concepite in termini di composizione di componenti, sviluppati indipendentemente, senza una struttura predefinita;

• la struttura della composizione potrebbe seguire alternativamente un modello data-flow o uno non-deterministico (Event-Driven Computation);

• i componenti possono interagire attraverso diversi pattern di comunicazione, stream, eventi o invocazioni singole (esempio Remote Procedure Call);

• molti algoritmi paralleli possono essere espressi in uno stile Divide&Conquer [44], in cui, pur essendo definiti degli skeleton specifici, la performance potrebbe risultare in generale bassa, poiché vi è una grande varietà di configurazioni e situazioni in cui questi paradigmi occorrono.

In ASSIST un programma parallelo può essere strutturato come un grafo generico, in cui i nodi corrispondono a moduli paralleli o sequenziali, e gli archi invece ai canali di comunicazione, sui quali sono trasmessi stream di valori “tipati”. Gli stream quindi costituiscono il meccanismo di composizione generale dei moduli. La figura 5.1 mostra un esempio di applicazione ASSIST complessa, descritta mediante un grafo di moduli e di stream di comunicazione:

Figura 5.1: Esempio di applicazione ASSIST strutturata a grafo.

Altri pattern di comunicazione (invocazione singola, RPC, ecc...) possono facilmente essere espressi come casi particolari di stream, o implementati in un formalismo basato su stream, senza perdita quindi di generalità. I moduli possono avere uno stato che è

inizializzato all’inizio della computazione, e che rimane significativo fino alla conclusione della stessa. Ogni modulo può avere un qualsiasi numero di stream di ingresso e di uscita. In generale gli stream di ingresso sono selezionati non-deterministicamente, in una computazione di tipo CSP [45]. Al contrario, un nodo potrebbe avere un comportamento data-flow con tutti i suoi stream in ingresso, oppure, in un caso più generale, potrebbe avere un comportamento misto, sia non-deterministico sia data-flow. La scelta di grafi e stream in ASSIST non ha solo una valenza generale, ma elimina anche le penalizzazioni di performance menzionate precedentemente. Infatti gli stream sono esplicitamente controllati dal programma, ed è più semplice raggiungere un’implementazione efficiente di semplici canali di comunicazione e comandi con guardia, nei complessi pattern di comunicazione che sono richiesti in generale in una computazione dinamica ed irregolare.

In letteratura sono state sviluppate delle metodologie per realizzare componenti parallele ad alte prestazioni, tra cui componenti CCA (Common Component Architecture) [30, 31, 46] e la versione a componenti di ASSIST [47, 48]. In questo secondo caso, i singoli nodi di un grafo o un intero sottografo corrispondono a componenti, le cui interfacce funzionali sono espresse in termini di stream che attivano le operazioni interne dei moduli. Strutturare quindi un programma ASSIST in termini di grafi e stream è sufficiente per catturare il significato essenziale delle componenti ad alta performance, in un modo che è completamente indipendente dalla specifica tecnologia a componenti usata.

5.1.2 Uno skeleton generico: il PARMOD

Ogni skeleton classico (map, farm, ecc...) corrisponde ad un paradigma specializzato per esprimere il parallelismo. Sebbene in molti di questi ci sia esattamente tutto ciò di cui i programmatori necessitano, ci sono delle applicazioni che richiedono delle strutture più flessibili, per ragioni di efficienza e/o potere espressivo. Degli esempi a riguardo sono:

1. farm stream-parallel con una strategia di scheduling ad-hoc, worker che hanno delle forme di stato interno o delle comunicazioni aggiuntive, o con una strategia specifica di ordinamento dei task.

2. strutture data-parallel con diversi tipi di stencil, che possono essere riconosciuti staticamente o dinamicamente.

3. strategie specifiche di distribuzione dati, che vanno dallo scheduling on-demand a scatter, multicast o broadcast.

4. nessuna limitazione nel numero di stream in ingresso ed uscita, controllati secondo uno stile non-deterministico o data-flow.

5. esistenza di uno stato interno, considerato significativo per tutta la durata della computazione, che di solito non è previsto nella semantica classica degli skeleton data-flow.

6. combinazioni miste di paradigmi stream e data-parallel (computazione sistolica). 7. moduli capaci di comportarsi secondo differenti paradigmi, in differenti fasi della

loro esecuzione.

Tutte queste situazioni possono essere emulate attraverso skeleton specializzati, a scapito della semplicità e/o dell’efficienza del codice. La soluzione di ASSIST è uno skeleton generico, cioè un costrutto general purpose che può essere adattato alla specifica istanza necessaria all’applicazione. Questo costrutto, chiamato modulo parallelo o PARMOD, ha come caratteristica principale, quando descrive la computazione equivalente ad uno skeleton specializzato, di non incorrere in sensibili overhead dovuti alla sua generalità. Un modulo parallelo è definito come segue:

• un insieme di processori virtuali (VP) con loro stato interno. L’insieme è dichiarato con una certa topologia, che fornisce i nomi ai processori virtuali. Le topologie disponibili sono:

o array, per indicare ogni processore virtuale mediante i valori di uno o più indici. Ad esempio nella topologia array [i:N][j:N] VP; il generico processore virtuale si chiama VP[i][j].

o none, nel caso in cui il nome dei processori virtuali non sia significativo per la computazione. Utilizzato specialmente per computazioni task-parallel come il farm.

o one, indica il PARMOD con un solo processore virtuale. Si differenzia da un modulo sequenziale puro, perché permette il non-determinismo sugli stream in ingresso.

Ciascun VP è gestito, a tempo d’esecuzione, da un solo processo reale chiamato Virtual Processor Manager (VPM). Viceversa ciascun VPM gestisce uno specifico insieme di VP. Ogni VPM coordina i propri VP, comunica con le sezioni di gestione degli input e degli output e con gli altri VPM. Il codice sequenziale dei task, eseguiti da ciascun processore virtuale, può essere espresso in un diverso linguaggio di programmazione, in modo da rendere possibile il riuso di codice di applicazioni già esistenti.

• un insieme di stream in ingresso tipati, controllati in modo data-flow o nondeterministicamente. Un volta selezionato, il dato di uno stream in ingresso può essere pre-processato e poi inviato ai processori virtuali, secondo una strategia di distribuzione prescelta (scatter, multicast, broadcast, on-demand), espressa nel programma mediante una specifica dichiarazione.

• un insieme di stream in uscita, controllati attraverso operazioni collettive sui valori dello stato dei processori virtuali. Il post-processing sui dati, da inviare agli altri moduli, può essere eseguito in modo collettivo.

La figura 5.2 riassume lo schema di base del modulo parallelo di ASSIST:

Figura 5.2: Il PARMOD, il costrutto parallelo generale di ASSIST.

Il costrutto PARMOD è quindi usato in ASSIST per parallelizzare l’esecuzione di un determinato algoritmo. La compilazione ASSIST di un PARMOD produce il codice eseguibile dei seguenti processi:

• Processo Input Section Manager (ISM): processo responsabile della gestione della sezione di input e delle politiche di distribuzione dei dati ai VP (e pre-elaborazione dei dati di input).

• Processi Virtual Processor Manager (VPM): sono i processi responsabili dell’esecuzione di un certo numero di VP. Il mapping tra VP e VPM e tra VPM e nodi viene definito dal supporto a run-time di ASSIST , in modo da bilanciare il carico per esempio. Il numero di VPM contribuisce al calcolo del grado di parallelismo effettivo del PARMOD.

• Processo Output Section Manager (OSM): processo responsabile della gestione della sezione di output e delle politiche di raccolta dei dati prodotti dai singoli VP (e post-elaborazione dei dati di output).

In questo modo, tutti gli skeleton specializzati, stream e data parallel, possono essere espressi direttamente in ASSIST. Inoltre, è molto importante è il fatto che nessuna penalità di performance viene pagata rispetto agli equivalenti skeleton specializzati. L’esecuzione di alcuni benchmark scritti in ASSIST [49], ha dimostrato che la performance raggiunta da un PARMOD è paragonabile o migliore a quella raggiunta dagli equivalenti skeleton specializzati, di programmi sviluppati in un linguaggio data-parallel o direttamente sviluppati tramite la libreria MPI [50].

5.2 Il supporto all’adattività delle performance in ASSIST

Nell’ultima versione sviluppata di ASSIST (versione 1.3), è stato realizzato un primo limitato meccanismo di adattività per riconfigurare dinamicamente un’applicazione parallela, con il fine di mantenere un certo contratto relativo alle prestazioni [51]. Nelle versioni precedenti, il grado di parallelismo dei moduli paralleli e il mapping dei processi era fatto staticamente, mediante un file di configurazione XML associato all’applicazione. Con l’ultima versione è stato introdotto il supporto alla dinamicità, ovvero la possibilità di variare il grado di parallelismo dei moduli paralleli a tempo d’esecuzione, senza che questi vengano interrotti o fatti ripartire. Tali considerazioni implicano la necessità che le prestazioni dell’applicazione vengano monitorate, da una entità apposita o da un insieme di

entità specifiche, in grado d’interagire con l’applicazione per orchestrare un piano di riconfigurazione, se questo è necessario. La soluzione realizzata prevede la presenza di entità manager, in grado di ricevere le richieste di riconfigurazione ed attuarle.

Supponiamo di avere dei moduli ASSIST (paralleli o sequenziali), ciascuno dei quali espone delle interfacce funzionali attraverso cui coopera con gli atri moduli dell’applicazione, e delle interfacce non funzionali, adibite al processo di riconfigurazione. Ad ogni modulo parallelo dell’applicazione è associato un manager chiamato MAM (Module Application Manager), responsabile della gestione del grado di parallelismo del modulo e delle sue riconfigurazioni.

Figura 5.3: La dinamicità in ASSIST.

Il MAM, in base ai dati sulle performance del modulo parallelo, può eseguire sullo stesso delle operazioni di riconfigurazione, che consentono:

• Aggiunta di un processo VPM al PARMOD.

• Rimozione di un processo VPM al PARMOD.

• Migrazione di un processo VPM da un nodo di elaborazione ad un altro. E’ realizzata mediante le due operazioni precedenti, ovvero prima una rimozione di un VPM e poi l’aggiunta di un VPM sul nodo scelto.

Ogni MAM è collegato al manager centrale dell’applicazione ASSIST, chiamato Application Manager, come mostrato in figura 5.3. La presenza dell’Application Manager centrale è necessaria per coordinare le attività di riconfigurazione relative a più PARMOD, per esempio nel caso di riconfigurazioni “a cascata”. Prendiamo il caso in cui il modulo uno della figura 5.3 debba riconfigurarsi aumentando il proprio grado di parallelismo (aggiungendo VPM), in quanto per esempio il suo tempo di servizio non rispetta più il contratto sulle prestazioni stabilito. L’Application Manager, che viene informato della riconfigurazione eseguita sul modulo uno dal MAM corrispondente, può per esempio ordinare una riconfigurazione da eseguire sul modulo due, per esempio nel caso in cui, a causa di una maggior parallelizzazione del modulo uno, il modulo due diventi il nuovo collo di bottiglia dell’applicazione.

E’ stato inoltre studiato il problema di quando eseguire il processo di riconfigurazione del grado di parallelismo. Questo può essere eseguito tra l’elaborazione di due elementi successivi dello stream di input, oppure durante l’elaborazione del task attuale, in uno specifico punto di sincronizzazione. La realizzazione della riconfigurazione dinamica ha richiesto lo studio di protocolli che garantissero la consistenza dei dati delle elaborazioni, al termine della riconfigurazione. La strategia di base che è stata usata consiste nel bloccare il processo ISM, far svuotare il pipeline del PARMOD, eseguire la modifica del grado di parallelismo, ed infine riaprire i canali di comunicazione. In questo processo, se necessario, lo stato dei VPM viene collezionato dal processo OSM, e successivamente alle operazioni di riconfigurazione viene nuovamente distribuito dall’OSM verso tutti i processi VPM (compresi gli eventuali nuovi processi). Si tratta di una prima possibilità di riconfigurare un’applicazione ASSIST, modificando solo il grado di parallelismo dei singoli moduli paralleli in relazione alle prestazioni.

La figura 5.4 mostra i test su un’applicazione ASSIST, con il supporto alla riconfigurazione dinamica per realizzare l’adattività delle performance. L’applicazione parallela è strutturata in un grafo di moduli sequenziali e paralleli, e per l’intera applicazione è stato concordato con l’utente un determinato contratto relativamente al tempo di servizio complessivo. Il supporto alla dinamicità, come si evince dalla figura, cerca di mantenere il tempo di servizio al di sotto del limite previsto dal contratto stabilito con l’utente, mediante la realizzazione, a tempo d’esecuzione, di attività di riconfigurazione dinamica dei moduli paralleli, che comportano operazioni di aggiunta e rimozione di processi VPM sui PARMOD. Nella figura 5.4 viene indicato, in relazione agli elementi degli stream di input, il tempo di servizio attuale e medio dell’applicazione,

considerando le attività di riconfigurazione che modificano il numero di nodi di elaborazione utilizzati per la computazione.

Figura 5.4: Performance di un esempio di applicazione ASSIST adattiva.

Nel seguito del capitolo sarà presentato un approccio più generale al problema dell’adattività in ASSIST, considerando riconfigurazioni più complesse, che non modifichino solo il grado di parallelismo (numero dei processi VPM) come quelle viste fino ad ora, ma anche aspetti funzionali dei moduli come: il codice sequenziale eseguito, la forma di parallelismo, le modalità di distribuzione degli input e collezione degli output, la ridistribuzione dello stato, tutto ciò in relazione ad eventi esterni, che nel caso particolare possono essere eventi di modifica del contesto ambientale di interesse (Context Awareness), o anche relativi alle prestazioni delle applicazioni parallele.

5.3 ASSISTANT: ASSIST with Adaptivity and Context Awareness

Nel capitolo precedente abbiamo già affrontato il problema di rendere componenti software Context-Aware. La figura 5.5 descrive le idee che sono state formulate e come possono essere applicate ad ASSIST:

Figura 5.5: La Context Awareness in ASSIST.

Nella parte sinistra della figura 5.5 è descritto lo schema di massima che fino ad ora è stato impiegato, per descrivere l’esempio di applicazione pervasiva per il trattamento di emergenze ambientali. Abbiamo descritto l’applicazione in termini di componenti funzionali cooperanti, alcune di queste in grado di adattarsi al contesto, ovvero in grado di modificare il proprio comportamento (algoritmi sequenziali e forma di parallelismo in caso di componenti parallele) in relazione ad eventi esterni. Nella descrizione abbiamo individuato la presenza di componenti di contesto, adibite all’acquisizione dei dati da sevizi di contesto, alla loro memorizzazione e gestione. Lo schema astratto, per realizzare l’adattività delle compoenti funzionali, prevede la possibilità che queste si registrino presso le componenti di contesto, per ricevere determinati eventi ambientali (modifica dello stato di connettività tra nodi, eventi di segnalazione dello stato d’emergenza di diverse aree geografiche, etc…). Le componenti di contesto, al verificarsi di eventi per cui hanno ricevuto delle registrazioni, inviano delle segnalazioni alle componenti funzionali, le quali, mediante le loro politiche di adattività modificano il comportamento di uno o più dei loro moduli, in relazione all’evento ricevuto.

Nella parte destra della figura 5.5 viene invece indicato come intendiamo portare questo schema per la gestione dei dati di contesto e la conseguente adattività, sul modello di programmazione di ASSIST. In ASSIST, come abbiamo descritto brevemente nel paragrafo precedente, è già stata realizzata una prima forma di adattività, fortemente limitata però alla sola variazione del grado di parallelismo dei PARMOD. L’obiettivo è quello di riorganizzare la gestione dell’adattività, considerando forme di dinamicità più complete.

In questo senso possiamo considerare le componenti funzionali dell’applicazione come dei PARMOD oppure dei moduli sequenziali. Per adesso consideriamo il caso dei soli PARMOD, in quanto le considerazioni che faremo saranno facilmente riadattabili a moduli sequenziali. Ogni PARMOD può essere dotato di un manager dell’adattività, realizzato come elemento primitivo e quindi facente parte integrante del modello di programmazione di ASSIST. Il manager è in grado di realizzare tutte le forme di adattività e le conseguenti riconfigurazioni, in base agli eventi esterni ricevuti. Lo schema del PARMOD ASSISTANT adattivo al contesto è mostrato in figura 5.6:

Figura 5.6: Il PARMOD ASSISTANT adattivo al contesto.

Il PARMOD così modificato prende nome di PARMOD ASSISTANT. La novità fondamentale è quella di prevedere all’interno del modulo parallelo la presenza dell’Adaptation Manager. Le sue funzionalità possono essere così riassunte:

• Ricevere dati da un insieme di interfacce di contesto. Queste interfacce possono essere più o meno intelligenti, ovvero possono essere interfacce che forniscono dati di monitoring sulle prestazioni del PARMOD (tempo di servizio, latenza, tempo medio di elaborazione, etc…), oppure interfacce semplici come sensori ambientali, oppure altre forme di servizi (Resource Discovery, System Service, etc…). Il manager deve occuparsi della memorizzazione e gestione di queste informazioni.

Le informazioni raccolte dal manager, tramite le interfacce di contesto, vengono memorizzate e gestite mediante una qualche forma di gestione della conoscenza (esempio rappresentazioni ontologiche).

• L’Adaptation Manager è programmabile esplicitamente mediante una politica di adattività, fornita dall’utente, e descritta mediante un opportuno formalismo che specifichi un insieme di regole di adattività, ciascuna con gli eventi esterni a cui il PARMOD è interessato e le reazioni scatenate al verificarsi di tali eventi.

• Alla ricezione di un evento esterno, per esempio un evento ambientale, l’Adaptation Manager provvede in base alla regola di politica associata ad eseguire delle operazioni di riconfigurazione, sulle diverse sezioni del PARMOD. Le operazioni di riconfigurazione possono riguardare:

1. Riconfigurazioni inviate all’ISM: possono comportare la modifica delle modalità con cui vengono pre-processati i dati di input e su come sono distribuiti, per esempio la modifica della modalità di scatter dei dati, oppure l’utilizzo di diverse forme di primitive di distribuzione (broadcast o multicast anziché scatter, etc…).

2. Riconfigurazioni inviate all’OSM: possono comportare la modifica delle modalità con cui vengono post-processati e raccolti i dati di output del PARMOD.

3. Riconfigurazioni inviate ai processi VPM: possono comportare la modifica del codice sequenziale eseguito da ciascun VP, o la modifica della forma di parallelismo utilizzata, modificando anche lo schema di comunicazione dei VP (es. stencil utilizzato).

In sintesi, possiamo supporre che l’Adaptation Manager realizzi tutte le funzionalità che abbiamo già descritto per le Context Control Component, più il supporto per realizzare i meccanismi di adattività che interessano le sezioni del PARMOD. La figura 5.7 descrive la struttura del manager dell’adattività di un PARMOD ASSISTANT:

Figura 5.7: L’Adaptation Manager del PARMOD ASSISTANT.

In verde vengono evidenziati i moduli del manager responsabili dei dati di contesto. Si tratta delle funzionalità offerte dalla Context Control Component che abbiamo già descritto in precedenza, ovvero la realizzazione del processo di acquisizione, memorizzazione, e gestione dei dati di contesto. In grigio invece sono rappresentati i moduli del manager responsabili dell’esecuzione dei meccanismi di adattività veri e propri. Ogni PARMOD ha associata una politica di adattività che rappresenta il formalismo principale che può essere utilizzato per programmare il manager. La politica è costituita da un insieme di regole di adattività, che specificano per ogni evento esterno a cui il PARMOD è interessato, le operazioni di riconfigurazione che devono essere eseguite. Le regole possono essere definite staticamente, oppure è possibile pensare di prevedere un meccanismo che consenta al manager di ricevere a tempo d’esecuzione nuove regole di politica ed utilizzarle.

La spiegazione dei moduli che formano il manager è relativamente semplice, alla luce delle spiegazioni già fornite nel capitolo precedente:

1. Context Control: è la parte del manager responsabile dei dati di contesto. Realizza le funzionalità già descritte nelle Context Control Component dell’approccio

generico alla Context Awareness. Per ricordare, i moduli di questa parte del manager sono:

a. Context Management Module: si occupa di ricevere le richieste dal modulo Adaptation Policy Module, relativamente alle informazioni di contesto a cui il PARMOD è interessato. Le richieste sono inviate al Context Retrieval Module che si occupa di ricevere i dati richiesti dalle interfacce a cui è collegato. Il Context Management Module è responsabile dell’esecuzione di eventuali processi di estrazione di conoscenza implicita dai dati di contesto, per esempio processi di inferenza e reasoning sui dati in base al modello utilizzato.

b. Context Retrieval Module: si occupa di ricevere dati dalle interfacce di contesto, in base alle richieste del modulo Context Management. Nel caso in cui le informazioni richieste dal Context Management non siano ottenibili dalle interfacce connesse direttamente all’Adaptation Manager, il Context Retrieval è in grado di comunicare con altri Adaptation Manager di altri PARMOD, per ottenere le informazioni di contesto richieste. Questo è particolarmente importante nel caso di contesto partizionato (Figura 5.8):

Figura 5.8: Caso di contesto partizionato.

in cui ogni manager riceve e gestisce i dati da un insieme di interfacce di contesto (esempio dei sensori), e i manager possono comunicare tra di loro in modo da condividere la conoscenza dell’intero contesto ambientale.

c. Context Storage Module: si occupa della memorizzazione (se necessaria) delle informazioni ottenute dalle interfacce di contesto, tramite il Context Retrieval Module e dai processi di reasoning/inferenza dal Context Management Module.

2. Adaptation Policy Module: è il modulo gestore della politica di adattività del manager. Per ogni regola della politica viene definito un evento ambientale e delle operazioni di riconfigurazione da intraprendere. L’evento ambientale viene definito in termine di vincoli su variabili di contesto (banda, connettività, stato di emergenza, etc…), ottenibili dalle interfacce e servizi di contesto. Il modulo è inoltre responsabile dell’interconnessione con altri manager, non solo per lo scambio di dati di contesto, come abbiamo già visto, ma anche per l’orchestrazione dell’applicazione attraverso il processo di adattività globale (come vedremo nell’esempio che verrà introdotto sesto capitolo).

3.

Parmod Adaptator Module: è il modulo responsabile dell’esecuzione del processo di riconfigurazione, in base alla politica attivata dalla ricezione di un evento esterno. La riconfigurazione può riguardare tutti i processi del PARMOD (ISM, OSM e processi VPM), può modificare le funzioni eseguite dai VP, le modalità di collezione nell’OSM, le modalità di distribuzione nell’ISM ed il mapping dei processi sui nodi, come indicato dalla regola di politica attivata.

5.4 Il processo di adattività nel PARMOD ASSISTANT

Il processo di adattività del PARMOD può essere programmato definendo staticamente o prevedendo il passaggio dinamico di politiche di adattività, per “pilotare” il manager. Le azioni intraprese dal PARMOD Adaptator nel manager sono nel dettaglio:

1 Modifica del grado di parallelismo del PARMOD, a seguito del monitoraggio delle sue prestazioni (sono le riconfigurazioni delle performance già implementate in ASSIST, con la variazione del numero e del mapping dei processi VPM).

2. Modifiche delle procedure sequenziali eseguite dai VP, senza modificare lo stato replicato o partizionato e mantenendo la forma di parallelismo del PARMOD.

3. Modifiche delle procedure sequenziali eseguite dai VP, modificando la forma di parallelismo usata dal PARMOD, lo stato replicato o partizionato tra i VP e le modalità con cui questi comunicano tra loro.

4. Modifiche alla modalità di distribuzione dell’ISM. 5. Modifiche alla modalità di raccolta dell’OSM.

6. Un’alternativa funzionale del modulo parallelo può esplicitamente indicare la tipologia di nodi di elaborazione su cui è necessario eseguire i processi del PARMOD. Ciò comporta l’interazione con servizi di Resource Discovery, che forniscano dinamicamente l’elenco e il tipo delle risorse presenti nell’ambiente circostante.

Di seguito cercheremo di analizzare nel dettaglio ciascuno dei sei aspetti elencati sopra, in modo da individuare le problematiche conseguenti alla loro applicazione:

5.4.1 Modifica delle procedure sequenziali dei VP mantenendo la medesima forma di parallelismo

Si tratta del caso più semplice di riconfigurazione delle funzioni. A seguito di un evento ambientale il manager modifica il codice sequenziale eseguito dai VP, ma senza modificare né la forma di parallelismo usata, né le modalità di distribuzione e collezione dei dati dell’ISM/OSM, e né modificando lo stato replicato o partizionato tra i VP. Notiamo che in questa forma di adattività non vengono modificati il numero di processi VPM e quindi il grado di reale parallelismo del PARMOD.

Prendiamo un semplice esempio stream-parallel di un farm puramente funzionale, in cui ogni worker esegue il calcolo di una funzione F su ogni elemento dello stream di ₁ input. A seguito della ricezione di un evento esterno, il manager del PARMOD potrebbe, in base alla regola di politica relativa all’evento, richiedere la sostituzione della funzione calcolata da ciascun worker. In questo caso semplice, la forma di parallelismo non cambia, ma cambia la funzione sequenziale computata dalle entità logiche Virtual Processor, sostituendola per esempio con la funzione F . ₂

La figura 5.9 mostra il codice di un PARMOD che realizza il farm puramente funzionale adattivo:

Figura 5.9: Versioni alternative delle funzioni eseguite dai worker di un farm.

Un problema importante riguarda quando durante l’elaborazione può essere realizzata la riconfigurazione del PARMOD. La soluzione più semplice può essere quella di eseguire la riconfigurazione tra due item successivi nello stream di input, ovviamente successivamente al verificarsi di un evento esterno, che inneschi il processo di adattività. Per chiarire quello che accade possiamo individuare quattro punti successivi della riconfigurazione:

1. In base alle regole all’interno dell’Adaptation Manager del PARMOD, il gestore della politica richiede alla parte di Context Control il campionamento delle informazioni contestuali di interesse, dalle interfacce di contesto a cui il manager è collegato o che è in grado di ottenere dalla rete di manager.

2. L’Adaptation Manager conosce il tipo di riconfigurazione da eseguire. Per esempio nel nostro caso sa che deve sostituire l’algoritmo sequenziale computato dai VP, mantenendo il loro eventuale stato (nel caso del farm può essere solo stato replicato tra i worker). L’Adaptation Manager provvede a bloccare il processo ISM, svuotare

il pipeline ISM, VPM e OSM, ed eseguire la riconfigurazione che comporta la sostituzione del codice sequenziale eseguito da ciascun VP. L’Adaptation Manager sblocca il processo ISM, e per gli item successivi dello stream di input, i worker computeranno la nuova funzione associata all’evento contestuale verificatosi.

Lo stesso meccanismo di adattività può essere realizzato su computazioni parallele miste stream + data parallel. Prendiamo l’esempio di un PARMOD che riceve uno stream di matrici NxN e per ciascuna di queste, esegue una computazione parallela data-parallel, con un determinato stencil per ottenere una matrice di output. E’ possibile che a seguito di un evento ambientale il PARMOD elabori ciascuna matrice di input ricevuta in modo diverso, modificando il codice di alcuni VP e modificando lo specifico pattern dello stencil usato per quella matrice, come in figura 5.10:

Figura 5.10: Versioni alternative di stencil in un Data-Parallel.

In questo caso la riconfigurazione modifica il codice sequenziale eseguito dai VP, ma anche la modalità con cui questi comunicano. Mentre non vengono modificate le modalità di distribuzione e di raccolta dei dati.

5.4.2 Modifica delle procedure sequenziali dei VP modificando anche la forma di parallelismo

Il caso precedente di adattività delle funzioni prevede modifiche al codice sequenziale dei VP, senza modifiche allo stato partizionato o replicato tra questi, e senza modifiche alla forma di parallelismo del PARMOD. Rappresenta comunque un primo esempio di adattività delle funzioni, anche se strettamente limitata.

Nel seguente paragrafo si cercherà di introdurre alla possibilità, da parte dell’Adaptation Manager, di modificare profondamente la natura e le funzioni della computazione di un PARMOD, come conseguenza della ricezione di uno specifico evento esterno. Si intende con questo la modifica non solo delle funzioni dei VP, ma anche del loro stato, eventualmente delle modalità di distribuzione e collezione degli input/output, e quindi una modifica sostanziale della forma di parallelismo associata ad un evento che scatena il meccanismo di adattività.

Prendiamo un esempio molto semplice, ma che in questa fase ci permette di chiarirci le idee. Supponiamo di avere un modulo parallelo che riceve come input uno stream A di vettori di N interi. Per ciascun elemento esegue delle elaborazioni e produce uno stream B di vettori di N interi come rappresentato in figura 5.11:

Figura 5.11: Un semplice esempio di modulo con forme di parallelismo alternative.

Possiamo supporre la presenza di due distinte implementazioni alternative del modulo (figura 5.12), collegate a diverse situazioni ambientali. Nel caso di una situazione di “normalità” del contesto ambientale circostante, il modulo utilizza un’implementazione parallela farm puramente stream-parallel, in cui ogni vettore di input viene elaborato per intero da un worker. In un contesto d’emergenza, in cui sono richieste prestazioni diverse al modulo, si può pensare di ricorrere ad una implementazione stream + data parallel, in cui ogni vettore di input viene ripartito tra un certo numero di processori virtuali, che realizzano in parallelo il calcolo del vettore di output corrispondente:

Figura 5.12: Implementazione task-parallel e data-parallel del modulo.

La seconda implementazione può essere consigliata rispetto alla prima, non tanto per le prestazioni (che sono molto simili), ma specialmodo per l’utilizzo di memoria da parte dei processi VPM. Considerando un valore di N molto grande, la prima implementazione richiede che ogni VP utilizzi tutto il vettore, e di conseguenza i processi VPM su cui i VP sono mappati possono richiedere un utilizzo di memoria che, in contesti di emergenza, non è possibile (per esempio perché sono disponibili nodi mobili con piccole capacità in termini di memoria). Inoltre la seconda implementazione richiede lo scambio di messaggi più piccoli tra ISM e processi VPM, che può essere preferibile in contesti di banda limitata della rete, come in situazioni di emergenza. Le due forme saranno comunque studiate in dettaglio nell’esempio di applicazione ASSISTANT del sesto capitolo.

Il PARMOD con cui si realizza il modulo M deve avere la possibilità di essere riconfigurato dal suo Adaptation Manager, per realizzare le distinte modalità di funzionamento, in base agli eventi esterni a cui queste due implementazioni sono collegate. Le figure 5.13 e 5.14 successive illustrano il codice ASSIST del PARMOD M, nelle due distinte implementazioni alternative, dando una prima idea delle diverse operazioni realizzate nelle due alternative funzionali:

Figura 5.13: Implementazione task-parallel del modulo.

Mentre l’implementazione data-parallel, delle stesse funzionalità che il PARMOD deve offrire, è data da:

Figura 5.14: Implementazione data-parallel del modulo.

Dove è necessario introdurre uno stencil fisso, in quanto ogni elemento del vettore B di output viene calcolato utilizzando più elementi del vettore di input A. Supponiamo che il PARMOD M normalmente utilizzi la prima implementazione. Le regole di politica di adattività nel suo Adaptation Manager possono indicare che, in presenza di un evento di

allarme, il PARMOD deve modificare la propria implementazione mantenendo le medesime interfacce. Il passaggio dall’implementazione uno all’implementazione due del PARMOD, può avvenire tra due elementi consecutivi dello stream A di input, fra due richieste distinte, e comporta la gestione delle seguenti problematiche:

1. Il processo ISM deve modificare la modalità di distribuzione degli array A. Il manager deve riconfigurare l’ISM in modo che gli item non siano più inviati ai VP mediante una distribuzione su domanda, ma che siano partizionati tra i VP.

2. Il processo OSM modifica la propria modalità di collezione degli elementi di output. Con la prima implementazione l’OSM si occupava solo di ricevere gli output dei VP ed inviarli sullo stream di output B dell’intero PARMOD. Con la seconda implementazione invece, l’OSM si occupa di collezionare i singoli elementi ricevuti dai VP, ricostruire l’array di output per ogni specifica richiesta e trasmetterlo sullo stream B del PARMOD.

3. I VP modificano le funzioni eseguite. Nella prima implementazione ciascun VP esegue la funzione uno, che opera su un’intero array di N interi. Nella seconda implementazione è eseguita la seconda funzione che opera su singoli elementi.

4. Viene modificato lo stato dei VP. Nel primo caso i VP sono puramente funzionali e operano solamente sugli elementi del vettore di input. Nella seconda implementazione invece, i VP hanno uno stato partizionato tra di loro. Lo stato è un vettore di N interi, dove ogni VP può modificare l’elemento del vettore corrispondente e leggere tutti gli altri elementi (Owner Compute Rule).

La gestione dello stato associato ai VP, durante un processo di adattività delle funzioni, rappresenta uno degli aspetti più critici che merita un approfondimento.

5.4.3 Gestione dello stato dei VP durante le riconfigurazioni delle funzioni

Un evento esterno può innescare un processo di riconfigurazione che modifica completamente l’implementazione attuale del PARMOD. Uno degli aspetti più critici del

processo di riconfigurazione, riguarda senza dubbio la gestione dello stato replicato o condiviso tra le entità logiche VP. Nel primo caso di adattività che abbiamo affrontato, non era necessario occuparsi di questo problema in quanto eravamo nel caso più semplice, in cui venivano modificate solo le funzioni sequenziali dei VP, senza alternarne il numero, la forma di parallelismo e le modalità di distribuzione e collezione. In questo caso lo stato dei VP non veniva modificato, ma venivano riconfigurate solo le funzioni sequenziali eseguite. Nel caso di riconfigurazioni che modificano la forma di parallelismo invece, il numero dei VP può cambiare, ed inoltre può cambiare lo stato su cui questi operano. Supponiamo che un modulo parallelo riceva un evento contestuale per cui deve cambiare forma di parallelismo, transitando dall’implementazione uno all’implementazione due. Può essere necessario, in questo caso, il salvataggio da parte del supporto di ASSIST dello stato dei VP relativo alla prima implementazione, la modifica del codice dei VP, e la distribuzione del nuovo stato della seconda implementazione. Come mostrato in figura 5.15, il punto di centralizzazione per le operazioni di collezione e distribuzione dello stato può essere direttamente l’Adaptation Manager del PARMOD:

Figura 5.15: Collezione dello stato delle alternative funzionali del PARMOD ASSISTANT.

Ovvero il manager gestisce lo stato dei VP relativo alle specifiche implementazioni alternative del PARMOD, e provvede a distribuire e collezionare lo stato aggiornato per le diverse implementazioni, se necessario, quando si verificano eventi di riconfigurazione delle funzionalità. La figura 5.16 riassume le possibili operazioni eseguite dal manager, nel caso di operazioni di riconfigurazione delle funzioni:

Figura 5.16: Descrizione dell’attività nell’Adaptation Manager del PARMOD.

In questo modo è possibile avere lo stato dell’elaborazione del PARMOD memorizzato dal manager, per ognuna delle alternative funzionali del modulo parallelo. Lo stato può così essere ripristinato nei VP ogni qual volta un processo di riconfigurazione comporti il nuovo utilizzo di un’alternativa funzionale del modulo parallelo.

5.4.4 Mapping tra elementi del PARMOD e tipologie di nodi di elaborazione

Ultimo aspetto che analizziamo è la possibilità di indicare nelle regole di politica di adattività del manager, le tipologie di risorse fisiche (nodi e reti) su cui devono essere eseguiti i processi del modulo, quando viene scelta una specifica alternativa funzionale. Un evento ambientale che scatena un processo di adattività, può comportare la necessità di eseguire le diverse parti del PARMOD su specifiche tipologie di dipositivi e reti. Per esempio un PARMOD in situazioni di “normale” funzionamento, adotta un’implementazione parallela in cui i processi VPM, ISM e OSM sono eseguiti su nodi d’interfaccia e su macchine di un cluster connesse a questi (nel caso dell’esempio applicativo del terzo capitolo). A seguito di un evento ambientale, che verifica la mancanza di connettività tra il nodo d’interfaccia e un certo numero di dispositivi mobili, il PARMOD può prevedere la necessità di eseguire i suoi processi sui PDA a disposizione degli utenti, o su altri piccoli nodi mobili disponibili. In questo caso è necessario prevedere l’interazione tra il manager del PARMOD e servizi di Resource Discovery, che consentano di stabilire dinamicamente il mapping dei processi del PARMOD su specifiche tipologie di nodi disponibili, in base a quanto espresso dalla regola che gestisce lo specifico evento ricevuto. La figura 5.17 descrive proprio questo tipo di interazioni:

Figura 5.17: Interazioni tra Manager e servizi di Resource Discovery.

5.5 Le regole della politica di adattività del PARMOD ASSISTANT

Il manager di un PARMOD è un elemento primitivo del costrutto (come la sezione di input, la sezione di output e i processori virtuali), e deve essere programmabile con un

formalismo specifico. Il formalismo deve avere la possibilità di specificare gli eventi esterni che innescano processi di adattività del PARMOD, deve poi consentire di associare ai suddetti eventi le operazioni di riconfigurazione che devono essere realizzate.

Le regole di adattività della politica possono essere definite:

• Staticamente: è possibile supporre di predefinire, a priori, tutte le possibili condizioni di adattività delle funzioni del PARMOD. Ovvero le politiche di adattività sono note completamente in fase di compilazione del modulo parallelo, determinando le alternative funzionali e le relazioni con gli eventi esterni. In questo modo le distinte implementazioni del PARMOD possono essere compilate in un’unica volta, e il manager si occupa del processo di sostituzione di un’implementazione con un’altra, al realizzarsi di specifici eventi.

• Dinamicamente: rappresenta probabilmente il caso che maggiormente ci interessa, in quanto garantisce una maggiore flessibilità del processo di adattività del modulo parallelo. In questo caso non si conoscono a priori tutte le possibili alternative funzionali, né tantomeno il mapping tra queste e gli eventi esterni. Le regole di adattività possono quindi essere aggiunte a tempo d’esecuzione all’Adaptation Manager.

Nel secondo caso, la possibilità di poter assegnare dinamicamente nuove regole di adattività al PARMOD, comporta la necessità di fornire dinamicamente l’implementazione di certe parti del modulo, stabilendo un meccanismo di plug-in che consenta di eseguire nel PARMOD, codice proveniente da altre fonti. La realizzazione di questo meccanismo dinamico, potrebbe sfruttare opportune interfacce del manager, che consentano di ricevere codice da eseguire sul PARMOD. Il codice potrebbe essere la compilazione di una nuova alternativa funzionale del modulo parallelo.

La figura 5.18 propone una prima bozza di sintassi della politica di adattività dell’Adaptation Manager, come è stato indicato già nel quarto capitolo. Come si nota il formalismo deve consentire di definire nuovi eventi esterni, nuovi comportamenti del PARMOD (in questo caso si può usare la sintassi di ASSIST) e di associare i comportamenti agli eventi. La compilazione delle regole e il codice di supporto del manager, deve consentire di innescare il processo di acquisizione dei dati di contesto, e di realizzazione del processo di riconfigurazione. Il formalismo deve inoltre indicare se, a

seguito della riconfigurazione, la nuova implementazione necessita di un diverso stato replicato o condiviso tra i VP, ed in questo caso, come è già stato proposto, può aspettare al manager gestire lo stato dei VP associato alle alternative funzionali. Infine la politica deve indicare le tipologie di nodi su cui vogliamo eseguire la nuova implementazione del modulo parallelo.

Figura 5.18: Un esempio di politica di adattivita del PARMOD ASSISTANT.

Va inoltre ricordato che ogni Adaptation Manager acquisisce e gestisce i dati di contesto di interesse del proprio PARMOD. La definizione di un nuovo evento contestuale, nelle regole di politica, indica al manager di iniziare ad acquisire il valore dei dati di contesto (tempo di servizio, connettività, stato dei nodi di elaborazione, etc…), associate all’evento, in modo da verificare quando tutte le condizioni per cui l’evento è definito si verificano, dando luogo così ad un processo di riconfigurazione delle funzioni o delle prestazioni.

5.6 Considerazioni sui moduli sequenziali adattivi

Le stesse considerazioni che sono state fatte per i moduli paralleli (PARMOD) adattivi al contesto, possono essere formulate in modo più semplice e limitato per i moduli sequenziali di ASSIST. In ASSIST abbiamo due possibilità per creare un modulo sequenziale:

1. Modulo sequenziale “puro”: è costituito fondamentalmente da una lista di procedure e/o funzioni che vengono eseguite sequenzialmente. Ognuna di queste è un programma sequenziale, scritto in un linguaggio tra quelli supportati da ASSIST (C, C++, Fortran, Java, etc…).

2. PARMOD ONE: è un PARMOD particolare, caratterizzato da un solo VP, che esegue sequenzialmente una lista di procedure e/o funzioni. La differenza fondamentale con il primo approccio è quella di usufruire della Input Section per effettuare scelte non deterministiche sugli stream di input, cosa altrimenti impossibile nel primo caso. Inoltre il PARMOD one fornisce una formalizzazione di stato interno, mantenuto tra diverse attivazioni del VP.

In ASSISTANT possiamo realizzare il modulo sequenziale adattivo mediante un PARMOD one, anche in questa situazione dotato di Adaptation Manager come elemento primitivo, oltre alla sezione di input, di output e il Virtual Processor. In questo caso il manager potrà modificare, in base alle regole di politica e agli eventi esterni, il codice sequenziale eseguito dal VP e lo stato su cui questo opera, connesso alle diverse alternative funzionali.

5.7 Descrizione ASSISTANT dell’applicazione pervasiva per la gestione

delle emergenze

In questo paragrafo sarà conclusa l’esperienza fatta con il sistema di esempio per la gestione delle emergenze, formulato con i capitoli tre e quattro di questa tesi. L’esempio ci ha consentito di individuare la necessità di realizzare componenti adattive al contesto e le loro problematiche per applicazioni di High Performance Pervasive Computing. In questo

senso sarà fornita, di seguito, una breve strutturazione dei principali casi d’uso individuati del sistema, descrivendo le componenti del quarto capitolo in termini di componenti ASSIST [47, 48]. Ogni componente ASSIST è un insieme di moduli sequenziali e paralleli interconnessi (una partizione del grafo dell’applicazione completa), con interfacce funzionali (stream di ingresso e uscita dal sottografo) e interfacce non funzionali per le operazioni di adattività e monitoring.

5.7.1 Richiesta di visualizzazione dello stato attuale dell’emergenza

Il primo caso d’uso prevede la richiesta dell’utente per ottenere la visualizzazione, sul suo dispositivo mobile, dello stato attuale dell’emergenza di inondazione. La richiesta richiede l’ottenimento del valore attuale dei sensori di profondità e di velocità del fiume, in modo da poter determinare, in base ai dati sulla morfologia del territorio, il livello attuale dell’inondazione. Le componenti adibite a questo scenario sono mostrate in figura 5.19:

Figura 5.19: Schema della richiesta di visualizzazione dello stato attuale dell’emergenza.

Le componenti Visual Client emettono le richieste indicando la zona d’interesse. Per ogni richiesta, la componente Dispatcher la processa, ottenendo i dati locali dei sensori dalla componente Sensor Data Manager, e quelli di altre celle dalla componente External Data Broker. In relazione alle componenti ASSIST, l’interazione mediante stream può essere descritta come segue in figura 5.20:

Figura 5.20: Schema con componenti ASSIST del primo caso d’uso.

Le componenti Sensor Data Manager ed External Data Broker sono componenti critiche, che possono essere costituite da PARMOD Context-Aware di ASSISTANT. Possiamo supporre che, in base al contesto di connettività presente fra sensori e nodo d’interfacca, i PARMOD utilizzino diverse implementazioni alternative. Nel caso di connettività “scarsa”, i moduli possono eseguire dei modelli predittivi dei dati, oppure nel caso di “buona” connettività possono ottenere i dati reali prodotti periodicamente dai sensori. Nella figura 5.20, le interazioni tra moduli etichettate con (2) sono relative al caso in cui lo stato attuale dell’emergenza sia elaborato dalla componente Dispatcher, nella situazione in cui il dispositivo dell’utente non abbia sufficienti capacità di calcolo. Nel caso opposto (1), i dati dei sensori dell’emergenza (reali o simulati) sono inviati dal Sensor Data Manager o External Data Broker direttamente sul dispositivo mobile dell’utente, per l’elaborazione locale da parte della componente Visual Client.

5.7.2 Richiesta di previsione dell’emergenza di inondazione

Analizziamo il secondo caso d’uso collegato alla richiesta, da parte dell’utente, di una previsione dell’inondazione, data un’area di interesse ed un arco di tempo di sviluppo della previsione stessa. Le componenti Visual Client emettono le richieste di previsione con i parametri corrispondenti, mentre la componente Dispatcher si occupa di inoltrare le richieste alle componenti adibite alla loro realizzazione, in questo caso alle componenti Forecasting Component. La componente si occupa di ottenere le informazioni necessarie alla previsione (velocità del fiume, altezza del fiume) dalle componenti Sensor Data Manager ed External Data Broker, che forniscono i dati relativamente alla cella dove si

trova l’utente nel primo caso, e delle altre celle del sistema nel secondo. Le informazioni per l’esecu1zione del modello di previsione vengono ottenute limitatamente all’area su cui l’utente ha richiesto di eseguire la previsione, che viene comunicata nella richiesta originale dell’utente. La figura 5.21 riassume queste interazioni:

Figura 5.21: Schema della realizzazione della previsione del fenomeno di inondazione.

In relazione ale componenti ASSIST, l’interazione mediante stream può essere descritta come in figura 5.22:

Figura 5.22: Schema con componenti ASSIST del secondo caso d’uso.

In particolar modo, immaginiamo che le componenti Visual Client producano uno stream di richieste di previsione alla componente Dispatcher, che invia le richieste al Sensor Data Manager e all’External Data Broker, che producono uno stream di dati per eseguire la previsione.

In questo caso possiamo considerare le componenti Forecasting Component, Sensor Data Manager ed External Data Broker strutturate con moduli ASSISTANT adattivi al contesto. In pariticolar modo la Forecasting Component è costituita da PARMOD adattivi, che eseguono la previsione. Esistono in letteratura molti modelli che possono essere usati, come FLDWAV [52], MIKE21 [53], MIKE11 [53] e SMS [54]. I modelli numerici eseguiti sono normalmente basati sul metodo degli elementi finiti. Questi metodi sono usati per risolvere, in maniera approssimata, problemi descritti da equazioni differenziali alle derivate parziali, riducendo quest’ultime ad un sistema di equazioni algebriche.

La complessità dei modelli previsionali è diversa in relazione ai loro obiettivi. Per esempio abbiamo modelli complessi, in grado di fornire simulazioni attendibili per periodi a medio lungo termine dell’inondazione [27, 28], oppure modelli prevalentemente pensati per previsioni a breve termine, con attendibilità limitata e dati scarsi [29]. La componente Forecasting Component, costituita da PARMOD ASSISTANT adattiviti, utilizza diversi modelli in relazione allo stato di connettività dei dispositivi che richiedono la previsione. Se l’utente richiede la previsione dell’emergenza, e si trova in una situazione di limitata connettività con il sistema (nell’esempio il PDA dell’utente non è connesso al nodo di interfaccia e quindi i dati dell’emergenza attuale sono pochi e frammentati), in questo caso il PARMOD può eseguire la soluzione numerica di modelli più a breve termine, meno attendibili ma che richiedano dati di input limitati. Nel caso opposto invece, in situazioni di piena connettività, possono essere eseguiti modelli più complessi ed esaustivi, che per la complessità ed il numero di operazioni calcolate, richiedano la distribuzione dei processi dei PARMOD su un numero elevato di nodi di elaborazione (nodo d’interfaccia, PDA, nodi di un cluster, etc..).

5.7.3 Richiesta di intervento del sistema di supporto alle decisioni per l’inondazione

Il terzo scenario d’uso è quello del sistema di supporto alle decisioni, che l’utente può utilizzare per richiedere, dato lo stato attuale dell’emergenza, oppure una previsione della stessa, suggerimenti che possono essere intrapresi per la gestione e la mitigazione del fenomeno di criticità. Un sistema di supporto alle decisioni deve operare su una grande quantità di dati, in qualche modo organizzati, aggiornati e tenuti consistenti. Il Data Mining rappresenta una delle fasi più critiche del processo di supporto alle decisioni. Indica il processo di esplorazione ed analisi di un insieme di dati, generalmente di grandi

dimensioni, per individuare eventuali regolarità, estrarre conoscenza e ricavarne regole ricorrenti significative. Tra le varie applicazioni del Data Mining individuiamo:

o Clustering(ricerca di sottogruppi omogenei nelle informazioni di interesse) o Association( ricerca di associazioni di qualche tipo tra i vari dati di interesse) o Sequencing(analisi di serie storiche)

o Forecasting(dati previsionali)

Nel nostro esempio di applicazione per la gestione di emergenze naturali, abbiamo incapsulato l’esecuzione di questi processi di estrazione di conoscenza, nella componente DSS Component, senza descriverli esplicitamente. La figura 5.23 mostra l’attività relativa allo scenario d’uso:

Figura 5.23: Schema della realizzazione del supporto alle decisioni.

Le componenti Visual Client emettono uno stream di richieste d’intervento del sistema di supporto alle decisioni (DSS), per la gestione del fenomeno di inondazioni. Le richieste vengono ricevute dalla componente Dispatcher, che provvede a processarle inviandole alla componente DSS Component, responsabile della realizzazione dei modelli di DSS. L’esecuzione di questi algoritmi richiede un grande dataset di informazioni ambientali (ottenute dalla componente Sensor Data Manager per i dati locali della cella, e dalla componente External Data Broker per quelli di interesse, ma di competenza di altre celle di copertura). La componente External Data Broker è inoltre responsabile dell’ottenimento dei dati esterni da servizi GIS o servizi Meteo. La componente DSS Component può essere considerata strutturata da più moduli ASSIST sequenziali o paralleli cooperanti, in cui i PARMOD della componente eseguono implementazioni diverse di algoritmi di Data Mining (clusterizzazione, classificazione, etc…).

La figura 5.24 mostra queste interazioni, per il supporto alle decisioni: