Realizzazione di uno strumento web-based per il supporto al design di Reti di Sensori ... › tesi...

I

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

tesi di laurea

Realizzazione di uno strumento web-based per il supporto al design di Reti di Sensori W ireless Anno Accademico 2010/11 relatore Ch.mo prof. Marcello Cinque correlatore Ing. Catello Di Martino candidato Antonella Caniano matr. 885 000 389

II

Ai grandi amori della mia vita, i miei genitori, Carmine ed Elena , che hanno sempre creduto in me, anche quando io stessa avevo smesso di farlo, Francesco, che si è preso cura di me in tutti questi anni restandomi accanto in ogni avversità, e senza il cui supporto ora sarei di sicuro finita in un ospedale psichiatrico (Ciccio come avrei fatto senza di te...), Lilli, il mio piccolo angelo nero. Ragazzi, Marty, Gigio e ultimo acquisto della scuderia, Serena, naturalmente anche voi avete giocato un ruolo determinante, abbiamo riso e pianto insieme, ma soprattutto insieme ne siamo usciti vincenti!!!

III

Indice Introduzione 5 Capitolo 1. Wireless Sensor Network 9 1.1 Introduzione alle Wireless Sensor Network 9 1.2 Scenari Applicativi 13 1.3 Sfide Progettuali di un sistema WSN 14 1.4 Architettura di Rete 17 1.4.1 Physical Layer 18 1.4.2 Data Link layer 18 1.4.3 Network layer 20 1.4.4 Transport Layer 21 1.5 I Sistemi Operativi nelle WSN 22 1.5.1 TinyOs 23 1.5.2 Mantis 25 1.5.3 LiteOS 26 Capitolo 2. Tecniche e Strumenti per la valutazione di WSN 29 2.1 Dependability in un sistema WSN 30 2.1.1 Tecniche di Valutazione Sperimentali 31 2.1.2 Tecniche di Valutazione Modellistiche 31 2.2 Ambienti di simulazione 36 2.2.1 Simulazioni Discrete-Event e Trace-Driven 37 2.2.2 Simulatori e Emulatori 37 2.2.3 Analisi Qualitativa 39 2.3 Osservazioni finali 46 Capitolo 3. Sviluppo di nuove soluzioni per il design di WSN: un approccio Multi-formalismo 48 3.1 Descrizione dell’approccio 49 3.2 Il tool Failure Model WSN Generator 52 3.3 Il simulatore Möbius 53 3.3.1 Il Simulation Engine e il SimulationManager 57 3.4 Il tool WebFAMOGEN 61

IV

Capitolo 4. Progettazione ed implementazione dello Strumento di Simulazione 64 4.1 Analisi dei Requisiti 64 4.2 Use Case Diagram 67 4.3 Architettura della RIA 71 4.4 L’archivio dati remoto 74 4.4.1 La scelta del database 74 4.4.2 La struttura di db_ Möbius 78 4.5 Il componente Model: il tool desktop-based Failure Model WSN Generator 81 4.5.1 La classe MobiusProject del package project e il file scriptShell.sh 81 4.5.2 Le classi del package simulator 84 4.6 I componenti View e Controller: il tool web-based Web Model WSN Generator 105 4.6.1 La scelta del framework 105 4.6.2 Le classi controller e i file.zul 108 Capitolo 5. Un Caso di Studio 112 Conclusioni e Sviluppi futuri 118 Bibliografia 117

Realizzazione di uno strumento web-based

per il supporto al design di Reti di Sensori Wireless

5

Introduzione

I continui progressi tecnologici hanno portato al recente sviluppo di sistemi di elaborazione

sempre più funzionali e performanti; economici e di dimensioni trascurabili, attrezzati con

sensori estremamente avanzati per la rilevazione di grandezze fisiche complesse, e dotati di

connessioni wireless per la comunicazione, questi dispositivi elettronici (più o meno

intelligenti) vengono impiegati in articolati ed efficienti sistemi di monitoraggio embedded,

attraverso la realizzazione di reti di sensore senza fili, meglio conosciute come Wireless

Sensor Network (WSN), che sono così in grado di offrire un'ottima soluzione a basso costo

per la raccolta e l’elaborazione affidabile dei dati, e soprattutto di gestire al meglio le risorse

disponibili.

Queste caratteristiche hanno determinato l’uso consolidato delle WSN nelle più svariate

aree applicative, alcune delle quali con stringenti requisiti di affidabilità: si pensi, ad

esempio, alla possibilità di gettare tali sensori da un elicottero in volo durante un incendio

per individuare i sopravvissuti ed identificare le aree di rischio per i soccorritori, o nel

monitorare strutture per diagnosticarne eventuali cedimenti strutturali, e ancora in ambito

militare nella rilevazione di attacchi chimici, biologici e nucleari. Si intuisce, pertanto,

l’estrema importanza di prevedere e garantire un certo livello di affidabilità per questi

sistemi, poiché un qualsiasi malfunzionamento potrebbe avere delle conseguenze disastrose

anche gravi, ed è necessario che il sistema reagisca nel modo migliore, tollerando gli

eventuali errori. Tuttavia, nonostante l’impiego di tecniche di sviluppo e verifica imposte da

rigorosi standard internazionali, il rischio di fallimenti aumenta rapidamente al crescere

della complessità del sistema; questo, assieme all’inadeguatezza degli approcci e degli



6

strumenti tradizionalmente utilizzati nella valutazione della dependability, ha suscitato da

parte del mondo scientifico una rinnovata attenzione verso di essa: è in questo scenario che

negli ultimi anni è andata muovendosi anche l'attività del laboratorio Mobilab del

Dipertimento di Informatica e Sistemistica, il quale ha apportato un notevole contributo sia

nell'approccio della modellazione e simulazione delle Wireless Sensor Networks, sia

nell'implementazione di framework e strumenti software.

L’obiettivo principale del laboratorio è stato quello di formalizzare e implementare un

approccio finalizzato alla valutazione dell’affidabilità delle reti wireless, tale da risultare

generale, ma soprattutto concepito in modo da considerarne tutti gli aspetti, dall’hardware

impiegato come piattaforma, al sistema operativo, e ancora alle caratteristiche ambientali

del particolare scenario considerato. Esso è basato sulla modellazione e dunque su tecniche

di fault forecasting relative ad un accurato modello dei fallimenti che necessita di una fase

preliminare di raccolta e analisi dei dati comportamentali della WSN da modellare. I

formalismi utilizzati fin’ora con successo per l’implementazione di modelli di fallimento e

per la stima degli attributi della dependability (Reti di Petri, catene di Markov e Reliability

Blocks) non si prestano a garantire una generalità del modello e soprattutto a modellare

aspetti intrinsechi di una rete, quali topologia, canale trasmissivo, o le caratteristiche

ambientali nelle quali essa si trova ad operare. A valle di quanto detto sembrerebbe che una

valida alternativa andrebbe ricercata nella simulazione, tuttavia molte ricerche hanno

concluso che non è possibile soddisfare tutti i requisiti necessari a compiere uno studio

esaustivo delle proprietà comportamentali di una WSN con un unico strumento.

E’ da queste premesse che nasce l’idea di un innovativo e potente approccio per la

composizione di un modello multi-formalismo che risulti flessibile, ma allo stesso tempo

rigoroso, e che fonda le diverse peculiarità di un modello comportamentale e di un modello

formale dei fallimenti, attraverso cui ottenere una valutazione olistica dei vari aspetti di una

WSN. In seguito tale approccio si è concretizzato nell'implementazione di un tool deskto-

based per la generazione automatica di modelli di fallimento, il Failure Model WSN

Generator, il cui utilizzo però, richiedeva notevoli risorse di calcolo, per questo si è pensato



7

di remotizzare il tool, realizzando uno strumento web-based che convogliasse in un

ambiente operativo caratterizzato da immediata disponibilità e da un minore carico

computazionale tutte le funzionalità del generatore automatico: questo è il tool web-based

WebFAMOGEN.

E’ in questo contesto che va ad inserirsi il seguente lavoro di tesi, mirato ad estendere le già

numerose possibilità di funzionamento della web application. Oltre a poter generare in

modo semplice il modello di fallimento della particolare rete da modellare, il sistema è in

grado di fornire tutti gli strumenti per:

• Caratterizzare uno o più scenari da simulare, inserendo attraverso una schermata

grafica, tutti i parametri del modello del caso di studio, come il protocollo di routing

o il sistema operativo adottato sui nodi;

• Simulare sul server remoto il modello generato ed esportarne i risultati, così che

l’utente possa analizzarli nell’ambiente di calcolo più appropriato; operazione,

questa, che ha richiesto un reverse-enginering del complesso software Möbius al

fine di utilizzarne le classi;

• Archiviare su un database remoto MySQL sia i risultati delle singole simulazioni

che le diverse topologie che l’utente impiega nella generazione dei propri modelli.

Il lavoro è stato strutturato in cinque capitoli:

- il Cap. 1 introduce gli aspetti peculiari delle Wireless Sensor Networks che ne hanno

sancito il notevole successo;

- il Cap. 2 fornisce la definizione di dependability per le reti WSN e approfondisce le

principali tecniche di valutazione dei suoi attributi, ed espone una trattazione

sintetica dei più accreditati strumenti di simulazione a supporto dello sviluppo delle

WSN ad oggi sul mercato;

- il Cap 3 presenta l’approccio multi-formalismo proposto in [9] finalizzato a fornire

le semantiche necessarie per l’implementazione di un modello di fallimento di una

WSN capace di una descrizione eterogenea della realtà; contiene inoltre

un’esposizione degli strumenti realizzati a supporto del suo sviluppo e della sua



8

risoluzione, frutto dell’attività di ricerca del laboratorio Mobilab della Facoltà di

Ingegneria Informatica dell’Università Federico II di Napoli;

- il Cap 4 è focalizzato sulle tecnologie e sulle tecniche usate per implementare il tool;

dopo una breve introduzione sul contesto nel quale si inserisce il lavoro di tesi

svolto, saranno illustrate le modifiche realizzate ai tool desktop-based e web-based

al fine di implementare le nuove funzionalità, e la struttura del database sul quale le

applicazioni si appoggiano.

- Il Cap 5, infine, mostra attraverso una serie di screeshot le nuove funzionalità

imlementate nel tool.



9

Capitolo 1

Wireless Sensor Network

“The most profound technologies are those that disappear…”

È con questa frase che Mark Weiser apre il suo celebre articolo del settembre 1991

intitolato “The Computer for the 21st Century”. In questo lavoro Weiser immagina un

mondo sempre più ibrido, in cui le macchine saranno così presenti da inserirsi dappertutto,

diventare quasi indistinguibili dal resto e soprattutto in grado di influenzare e migliorare

tutti gli aspetti della nostra vita. In effetti il futuro immaginato da Weiser non è poi così

lontano e immaginifico: a Cambridge, l’università di Harward e la BBN Technologies

stanno sviluppando CitySense, un progetto che prevede nei prossimi anni di realizzare la

copertura dell’intera città con una serie di sensori wireless, montati su pali del telefono,

semafori e edifici. La rete, progettata secondo un’architettura Mesh, prevede un centinaio di

nodi, ognuno dei quali è grande all’incirca come un Mac Mini e comprende un PC con

Linux e una memoria flash di qualche gigabyte come disco rigido, una comunicazione

wireless 802.11 a/b/g e diversi tipi di sensori.

1.1 Introduzione alle Wireless Sensor Network

Le Wireless Sensor Network (WSN) rappresentano ormai una realtà consolidata,

caratterizzate da elevati livelli di funzionalità, esse sono impiegate nei più svariati campi di



10

applicazione grazie alla loro capacità di interagire con l’ambiente circostante in qualsiasi

situazione. Il loro successo è dovuto ai progressi compiuti negli ultimi anni dai sistemi

microelettromeccanici, dalle comunicazioni wireless e dall’elettronica digitale che hanno

permesso lo sviluppo di sensori di dimensioni sempre più ridotte, a basso consumo

energetico, con un costo infinitamente più basso delle tradizionali reti cablate in termini sia

di manodopera che di materiali per le operazioni di cablatura. Inoltre, se da un lato le

cosiddette reti wired non presentano limitazioni in termini di potenza (poiché laddove è

possibile realizzare una connessione, è anche possibile portare delle linee di alimentazione)

e presentano altissimi livelli di sicurezza e ottime prestazioni, dall’altro, invece, esse sono

di difficile impiego in quei contesti ambientali che presentano caratteristiche fisiche che ne

rendano impossibile non solo la manutenzione, ma la stessa realizzazione.

Una rete di sensori wireless è una rete senza fili formata da nodi distribuiti con una densità

spaziale molto elevata (decine o centinaia di sensori nello spazio di pochi metri), costituiti da

sensori e/o attuatori che cooperano allo scopo di monitorare, rilevare, elaborare e

condividere, comunicando a breve distanza, i dati acquisiti dall’ambiente fisico nel quale

sono immersi. I sensori sono di dimensioni trascurabili, mimetizzabili e poco costosi, ma

soprattutto, la rete risultante risulta semplice da progettare, utilizzare e mantenere.

Quest’ultima, per di più, deve essere in grado di auto-regolarsi e auto-ripararsi poiché

impiegata in ambienti fisicamente remoti, ostili o inaccessibili all’uomo.

Un nodo sensore è generalmente composto da:

• un micro-controller (CPU) che ha il compito di gestire la logica con cui ogni nodo

deve agire collaborando con gli altri nodi per portare a termine le attività di

rilevazione assegnategli;

• una memoria solitamente propria del microcontrollore, utilizzata per salvare le

variabili durante l’esecuzione e per memorizzare il programma da eseguire

all’accensione;

• un modulo radio costituito da un ricetrasmettitore ad onde radio;

• sensori ed attuatori per effettuare le misurazioni sull’ambiente circostante;



11

• una fonte di energia, per alimentare i componenti.

Queste dotazioni fanno sì che ogni singolo nodo abbia specifiche capacità sensoristiche e

sia in grado di rilevare differenti grandezze fisiche, come temperatura, umidità, vento,

pressione, e trasformarle in segnali elettrici che vengono in seguito inviati a un uno o più

Figura 1.1: Architettura comune Wireless Sensor Network

nodi principali, detti sink o gateway, preposti alla raccolta e all’aggregazione dei dati di

tutta la rete e alla loro trasmissione a un server o a un calcolatore.

Caratteristiche stringenti dei sensori risultano essere la potenza di calcolo relativamente

bassa, la memoria limitata e il ridotto raggio di copertura della radio. Inoltre essi sono

normalmente alimentati da sorgenti di potenza che non possono essere in generale

sostituite, o quantomeno non frequentemente, quindi essendo la riserva d'energia limitata e

non rinnovabile, una efficiente implementazione di wireless sensor networking deve

prevedere meccanismi per mantenere costantemente i consumi molto bassi, per garantire

alla rete un tempo di vita sufficientemente elevato da consentirne l’impiego in applicazioni

reali. A tal proposito l’elevata densità di posizionamento, se da un lato implica problemi di

mutua interferenza fra sensori distinti, dall’altro fornisce la possibilità di impiegare

algoritmi di rete multi-hop che consentono l’utilizzo di basse potenze di trasmissione e



12

quindi di migliorare le caratteristiche dei nodi in termini di requisiti di potenza. Non solo,

ma l’elevata densità di sensori che implementano una rete dà luogo a una struttura di controllo

che genera grandi quantità di informazioni le quali possono essere impiegate per migliorare la

qualità dell’elaborazione globale.

La struttura di una WSN non è rigida pertanto, a differenza delle reti cablate, non risulta

difficile aggiungere nuovi nodi alla rete o modificare la posizione di sensori preesistenti

senza dover necessariamente riconsiderare l’intera struttura della rete. Questa flessibilità

della topologia consente la formazione di reti facilmente installabili e non geograficamente

preconfigurate, ma che dipendono solo dalla distribuzione dei sensori sul territorio: la

posizione non è predeterminata, ma può essere casuale, e i nodi della rete sono dotati di

capacità di auto-organizzazione e di una conoscenza diffusa sullo stato della rete.

Una simile tecnologia sembrerebbe essere la soluzione ideale in qualsiasi applicazione,

tuttavia comporta anch’essa una serie di svantaggi che vanno sicuramente tenuti in

considerazione in fase di progettazione e che fanno sì che le reti cablate siano ancora oggi

non del tutto sostituibili:

• la limitazione della velocità di trasferimento, poiché la capacità del canale

trasmissivo deve essere suddivisa tra tutti coloro che ne stanno facendo uso;

• il rischio sicurezza in assenza di specifici controlli, risulta facile infatti per un

intruso intercettare le informazioni che viaggiano nell’etere;

• l’influenza della qualità delle comunicazioni da parte di fattori esterni, come

interferenze elettromagnetiche e ostacoli in movimento;

• il consumo energetico degli apparati di trasmissione radio più elevato di quelli per la

comunicazione via cavo.

In Figura 1.2 sono evidenziate le principali differenze tra le reti cablate e quelle wireless :



13

Figura 1.2: Confronto tra reti Wired e reti Wireless.

1.2 Scenari Applicativi

La nascita delle WSN è sicuramente da attribuire alle applicazioni di carattere militare, basti

pensare alla più recente Smart Dust o “polvere intelligente”, una tecnologia strategica in

fase di sviluppo, costituita da una nube artificiale di microsensori che integrano capacità di

calcolo, parti meccaniche, figlie della nano-robotica, più i sensori elettronici in grado di

captare movimenti o vibrazioni. Di dimensioni ridottissime, questi micro-computer si

mimetizzano nell’ambiente per recepire e inviare informazioni in tempo reale via onde

radio ai satelliti. In un futuro non troppo lontano il Pentagono ha previsto di dispiegare in

massa questi sensori remoti per scopi di ricognizione e sorveglianza degli scenari di

battaglia. Non solo, ma potrebbero anche essere incorporati nelle nuove tute da

combattimento dei marines, inibendo i veleni delle armi chimiche e monitorando la salute

dei militari esposti ad aggressioni batteriologiche. Inoltre poiché i sensori sono visibili ai

raggi infrarossi garantirebbero il riconoscimento tra i soldati nei combattimenti notturni,

evitando, così, le vittime del "fuoco amico".

In generale i campi d’impiego delle reti di sensori wireless sono molteplici e l’elenco delle

applicazioni interminabile, la stessa polvere intelligente non è stata pensata solo per la

guerra, ma verrà presto introdotta in altri settori che vanno dal monitoraggio ambientale (i

sensori, sparsi nelle foreste, hanno il compito di sentinelle anti-inquinamento e nella

prevenzione degli incendi), ai sistemi antisismici, dove sono stati usati all’interno di edifici



14

o ponti per verificarne lo stato di salute dopo essere stati sottoposti a scosse sismiche: la

precisione di queste micro-apparecchiature consente, infatti, di percepire lesioni che

sfuggono agli occhi più esperti ma che possono determinare dei cedimenti strutturali; o

ancora nel campo della home automation, in cui i micro-computer spalmati nelle vernici

delle pareti consentiranno di auto-regolare la temperatura e la luminosità dell'ambiente in

modo da eliminare ogni spreco di energia.

Figura 1.3: Smart Dust a grandezza naturale e ingrandito.

In conclusione il monitoraggio embedded comprende una’ampia gamma di aree applicative:

le WSN sono oggi impiegate nei campi più disparati che vanno dalla domotica, scienza che

si occupa di applicare l’informatica e l’elettronica alle abitazioni, all’ingegneria civile e

ancora, in quello sanitario dove è possibile utilizzare queste reti per monitorare pazienti ed

eseguire accurate valutazioni diagnostiche; tutto allo scopo di migliorare significativamente

a costi irrisori la qualità di vita di ogni individuo.

1.3 Sfide progettuali di un sistema WSN

Sulla base di quanto detto nel paragrafo 1.1, risulta quindi evidente che la fase di

progettazione di una rete di sensori wireless debba tenere in considerazione tutta una serie



15

di fattori che ne influenzano in modo decisivo la realizzazione. Gli aspetti più critici sono:

• la fault tolerance, ovvero la capacità di una rete di garantire le sue funzionalità

anche in presenza di malfunzionamenti da parte dei suoi nodi; ricordiamo che un

nodo può smettere di funzionare semplicemente perché ha esaurito la sua batteria,

anche il quel caso il corretto funzionamento della rete non deve essere pregiudicato.

E’ necessario definire una tolleranza che varierà in funzione della specifica

applicazione e rispettarla attraverso opportuni algoritmi;

• la scalabilità dovrà assicurare che all’aumentare del numero di nodi di una rete, i

diversi dispositivi saranno ugualmente in grado di interagire tra di loro,

scambiandosi informazioni senza tuttavia generare mutue interferenze; questo è uno

scenario più che plausibile dal momento che i nodi possono evolvere nel tempo sia

in termini di posizione che di funzionamento;

• i costi di produzione che risiedono nella tecnologia di comunicazione,

nell’elettronica di condizionamento del segnale e nelle unità di calcolo; come più

volte ripetuto l’impiego di sensori risulta essere piuttosto massiccio all’interno delle

reti, sia per migliorare la qualità delle informazioni ricevute, che per agevolare la

comunicazione dei vari device che avendo un ridotto raggio di comunicazione

vanno pertanto posizionati il più vicino possibile gli uni agli altri; Appare quindi

chiaro il motivo che spinge a cercare soluzioni dal costo sempre più contenuto;

• gli ambienti operativi all’interno dei quali i sensori sono “immersi” sono spesso

impraticabili e fortemente inospitali, pertanto il progetto di una rete non può

assolutamente prescindere dal contesto in cui andrà ad operare;

• la topologia di rete che durante il suo ciclo di vita subisce continue variazioni sia

per la libertà con la quale si possono aggiungere o rimuovere i nodi, sia a causa della

eventualità che un nodo possa spegnersi; trovare una strategia che che garantisca

l’affidabilità della rete anche in corrispondenza dei continui cambiamenti e sia in grado

di bilanciare il consumo di banda e di energia è compito dei protocolli di routing;

• i requisiti hardware legati alla struttura interna dei sensori i quali si differenziano



16

dal tipo di unità di elaborazione, di scheda radio, e soprattutto dall’unità energetica.

E’ quest’ultima che riveste il ruolo principale poiché determina la vita funzionale della

rete che deve essere il più duratura possibile;

• i consumi relativi fondamentalmente alle azioni svolte dai sensori wireless, ovvero

la misurazione di grandezze fisiche (temperatura, umidità..), l’elaborazione

dell’informazione rilevata ed infine la comunicazione di questa agli altri nodi della

rete. Di sicuro il fattore che impatta maggiormente risulta esserre l’attività di

comunicazione poiché ogni qualvolta uno sensore deve trasmettere i dati dovrà

mantenere attivo l’ascolto sul canale radio per verificare che l’informazione sia stata

effettivamente ricevuta dal destinatario; risulta pertanto necessario analizzare

consumi e tempistiche connessi alla trasmissione ed alla ricezione, ma anche ai

consumi dovuti alle fasi di accensione e spegnimento del dispositivo;

• i requisiti sull’affidabilità della WSN:

- sincronizazione affidabile delle misure;

- consegna affidabile di una quantità significativa di misure;

- garanzie sulla copertura dell’area da monitorare;

- minimizzazione dell’ intervento umano sulla rete.

(L’argomento verrà ulteriormente approfonditi nel capitolo 2).

Tutti questi aspetti concomitanti fanno della progettazione e caratterizzazione di una

WSN attività assai complesse. A queste difficoltà si aggiungono i vincoli dettati

dall’applicazione specifica che impediscono di effettuare scelte univoche, risulta

quindi indispensabile conoscere in dettaglio le caratteristiche del sistema reale per

individuare le modalità e la gravità dei sui possibili fallimenti. Da qui l’esigenza di

formalizzare e implementazione tecniche e strumenti che mettano in luce come

queste criticità, dall’hardware al software e al sistema operativo, e ancora le

caratteristiche ambientali di operatività, s’influenzino a vicenda, e che siano di

ausilio ai progettisti durante le fasi di sviluppo di una WSN, al fine di:

• Conferire fiducia nelle scelte progettuali effettuate, validando e confrontando



17

le diverse soluzioni individuate;

• Effettuare una valutazione preventiva che consenta di prevenire e tollerare

possibili guasti che degradino le performance e l’affidabilità della rete;

• Permettere di rilevare, durante la vita operativa del sistema, eventuali colli di

bottiglia e suggerire le soluzioni da adottare in future revisioni.

1.4 Architettura di Rete

Le sfide progettuali che abbiamo esposto nei paragrafi precedenti si riflettono soprattutto

sulla quella che è la scelta del software da installare, ciò ha indotto la realizzazione di vari

protocolli dedicati creati ex novo per le esigenze delle WSN. Tra i vari standard presenti nel

settore, quello più promettente risulta essere lo IEEE 802.15.4, approvato nel 2003, è stato

designato per reti flessibili, di basso costo, bassi consumi energetici e bassi bit-rate. Così

come nel campo delle reti informatiche viene utilizzato il modello di riferimento ISO/OSI

(International Organization for Standardization/Open Systems Interconnection) per

distinguere, in maniera orizzontale, le funzionalità di rete, anche per le reti wireless è

definito uno stack protocollare simile che ingloba tutti gli aspetti relativi alla comunicazione

tra nodi. E’ da sottolineare che la separazione dei layer in una WSN non è ugulmente netta;

al contrario, essi si sovrappongono tra loro e la motivazione è da ricercare nello sviluppo di

protocolli di comunicazione efficienti, leggeri e capaci di supportare avanzate funzionalità

di risparmio energetico e flessibili ai cambiamenti della rete stessa. Al primo livello

troviamo quello fisico che fa riferimento al canale di comunicazione e alla parte di

sensoristica e di elaborazione dei segnali; segue il cuore di una WSN ovvero i livelli Data

link e Network che ne definiscono il profilo, dal momento che hanno il compito vero e

proprio di risolvere le sfide più difficili; infine il livello di rete e quello di trasporto. I livelli

sovrastanti vengono presi in considerazione solo per il gateway o host su cui girano

particolari applicativi, ad eccezione delle proprietarie che implementano parte del layer

Applicativo nei nodi. Analizziamo nel dettaglio i primi quattro layer.



18

Figura 1.4: stack protocollare nelle WSN

1.4.1 Physical Layer

Il physical layer fornisce i servizi per abilitare la ricezione e la trasmissione dei pacchetti

del trasduttore radio. Rileva l’energia sul canale radio (Energy Detection) attraverso una

stima della potenza del segnale ricevuto; alla ricezione di un pacchetto, effettua una stima

della qualità in termini di bit error rate così da poter caratterizzando il canale radio (Link

Quality Indication); seleziona il canale di comunicazione ottimale ed è inoltre in grado di

effettuare il riconoscimento di canale libero o occupato (Clear Channel Assesment):

essendo l’accesso al canale condiviso, ogni nodo deve poter “ascoltare” prima di trasmettere

e se il canale è già in uso, deve attendere. Il canale viene indicato come ‘impegnato’ se

l’analisi dell’energia in banda rileva che essa è al di sopra di una certa soglia, oppure se

vengono riconosciute particolari caratteristiche di modulazione del segnale. Seppur

importante, perché altimenti la rete nemmeno esisterebbe, in realtà non riveste un ruolo così

determinante poiché le reti di sensori senza fili a bassa potenza sfruttano tutte apparati radio

con caratteristiche simili, ovvero bassa potenza di trasmissione, basso consumo, basso bit-

rate.

1.4.2 Data Link layer

Questo livello si compone di due distinti sottolivelli: LLC e MAC. Il primo, detto Logical



19

Link Control layer, fa da tramite tra i livelli superiori e il livello fisico, consentendo

l’interoperabilità tra diversi tipi di rete. Il livello MAC (Medium Access Control ), è

fondamentale nel determinare le prestazioni di una rete WSN perchè ha l’importante

compito di assemblare i dati in frame tramite l’aggiunta di un header, contenente

informazioni sull’indirizzo, e un trailer, contenente informazioni per la correzione degli

errori; disassemblare i frame ricevuti per estrarre informazioni sull’indirizzo e la correzione

degli errori; ma soprattutto gestire l’accesso al mezzo di trasmissione condiviso. I requisiti

di cui bisogna si solito tener conto nella progetttazione di un protocollo MAC sono l’entità

dei ritardi, il throughput, la robustezza e la scalabilità, ma nel caso specifico delle delle reti

di sensori senza fili riveste un’importanza particolare l’efficienza energetica del protocollo.

I fattori che hanno un significativo impatto sulle prestazioni e sul consumo di energia sono:

• la frequenza delle collisioni che determina la perdita e la ritrasmissione dei

pacchetti;

• l’ascolto prolungato in attesa di pacchetti sul canale;

• la frequenza di overhearing ovvero la ricezione e la decodifica di pacchetti destinati

ad altri nodi;

• l’eccesso di pacchetti di controllo;

• la frequente commutazione fra le diverse modalità di funzionamento nello stato

dormiente e quello di veglia.

I protocolli vengono pertanto progettati in modo da impedire queste criticità, essi possono

essere suddivisi in due macro categorie: Schedule-Based e Content-Based.

Nei primi, l’accesso al canale di trasmissione radio è regolato da una schedulazione

preassegnata ad ogni nodo affinchè uno solo per volta possa occuparlo. Il risparmio

energetico legato a questa tecnica è dovuto principalmente al fatto che i nodi vengono posti

in uno stato di inattività definito “sleep mode” (questo avviene spegnendo la radio) quando

non devono né trasmettere né ricevere dati.

I protocolli Content-based, conosciuti anche come Random Access-Based Protocols, non

richiedono che i nodi si coordino perché l’accesso avviene mediante meccanismi di



20

sincronizzazione del tipo RTS (Request-To-Send) e CTS (Clear-To-Send); il protocollo

risulta più robusto, ma non riduce in maniera significativa il dispendio di energia: in caso di

accesso contemporaneo da parte di più nodi non è possibile eliminare del tutto la possibilità

di collisione, ma solo minimizzarne l’occorrenza.

1.4.3 Network layer

A questo livello viene determinato il percorso ottimale che i pacchetti dovranno attraversare

a partire dai vari nodi dislocati in tutta la rete, fino al sink (o i sink). Abbiamo più volte

ripetuto che i nodi sono caratterizzati da un raggio di comunicazione ridotto, per questo

motivo è necessario che le misurazioni effettuino numerosi hop prima di raggiungere la

destinazione prefissata: il compito di un algoritmo di routing è proprio quello di individuare

il set di nodi intermedi più efficiente in termini di costi energetici e consumo di banda. In

generale il routing ha inizio con la scansione di tutti i nodi attivi nelle vicinanze, così che

ogni nodo si possa creare una mappa locale della rete per effettuare la sceltta ottima. Ad

oggi diverse sono le tecniche di routing che tengono conto delle particolari esigenze delle

reti WSN, vediamone alcune:

• il flooding è una tecnica basata su un approccio di tipo reattivo, in pratica ogni nodo

che riceve un pacchetto di controllo lo rinvia a tutti i suoi vicini. Questa strategia

presenta lo svantaggio di generare un numero enorme (teoricamente infinito) di

pacchetti; esistono tuttavia delle sue varianti che limitano il traffico generato come il

‘selective flooding’ in cui i pacchetti sono duplicati solo sulle linee che vanno

all’incirca nella giusta direzione, o il ‘gossiping’ che anzicchè usare il broadcasting

per la trasmissione, prevede l’invio dei pacchetti ad un solo nodo selezionato in

modo random tra i vicini.

• SPIN (Sensor Protocol for Information via Negotiation) è un protocollo basato sulla

diffusione di metadati sul sensore che sono di dimensioni molto inferiori rispetto a

quelle dei dati, risulta quindi meno oneroso del flooding. I nodi interessati al dato ne

richiedono in seguito l’invio completo. Allo scopo vengono utilizzati dei messaggi



21

specifici: ADV per l’invio dei metadati; REQ, per richiedere il dato e DATA,

contenente il valore vero e proprio fornito dal sensore. I vantaggi risiedono oltre che

nella diminuzione di traffico sulla rete, anche nella significativa riduzione di

ridondanza nella trasmissione e di consumo energetico.

• LEACH (Low-Energy Adaptive Clustering Hierarchy) adotta una topologia in cui i

nodi si auto-organizzano in cluster ed eleggono un nodo capo-cluster. Questi ultimi

comunicano con i capo-cluster vicini costituendo così una struttura gerarchica fino

alla stazione base. Il protocollo minimizza la dissipazione di energia, in quanto il

capo-cluster riceve ed aggrega i dati dei nodi appartenenti al cluster prima di

inviarli alla stazione base. Dopo un certo periodo di tempo la rete entra nuovamente

in fase di setup e inizia nuovamente la fase di selezione dei capo-cluster.

• Geographical routing ha l’obiettivo principale di usare informazioni sulla locazione

dei nodi per formulare un’efficiente ricerca fino alla destinazione. Un algoritmo di

questo tipo è molto comodo nelle reti di sensori perché minimizza il numero di

trasmissioni attraverso la stazione base eliminando ridondanza di dati trasmessi.

1.4.4 Transport Layer

Il livello di trasporto fornisce servizi di trasporto messaggi e di segmentazione dei dati

provenienti dal livello immediatamente superiore: questi, organizzati alla sorgente in catene

di segmenti, vengono poi riassemblati nel messaggio originale una volta giunti a

destinazione. Alcuni fattori critici di progettazione sono :

• il controllo della della congestione e il trasporto dei dati in maniera affidabile;

• la semplificazione del processo di connessione iniziale per accelerare il processo,

aumentare il throughput e abbassare il ritardo di trasmissione; questa potrebbe

essere realizzata utilizzando una tecnica connectionless, come in UDP, in cui lo

scambio di dati tra la sorgente destinatario non richiede l’operazione preliminare di

creare tra di essi un circuito, fisico o virtuale, su cui instradare il flusso di

informazioni;



22

• evitare quanto più possibile le perdite di pacchetto poiché esse si traducono in

spreco di energia; sarebbe utile un controllo di congestione attiva (Active

Congestion Control) attraverso cui, per esempio, il nodo che invia oppure un nodo

intermedio può ridurre la velocità quando la dimensione del buffer raggiunge una

certa soglia; inoltre avvalendosi di criteri di ottimizzazione cross-layer potrebbe

essere possibile aumentare le prestazioni della rete: attraverso le informazioni

inviate dall’algoritmo di instradamento, il protocollo di trasporto sarebbe in grado di

dedurre se il problema è causato dal percorso o da una congestione così da limitare o

meno la velocità di trasferimento.

A valle di quanto descritto, risulta piuttosto evidente che i protocolli di trasporto oggi

esistenti non sono idonei per le WSN: l’assenza d’interazione con i protocolli dei livelli più

bassi, il controllo della congestione end-by-end e non hop-by-hop, la garanzia di affidabilità

al solo livello di pacchetto oppure di applicazione, questi e altri aspetti li rendono inadatti al

singolo impiego nelle reti di sensori wirelss, mentre sarebbe più utile fondere i servizi

offerti da ognuno, in un unico protocollo performante alla specifica applicazione.

1.5 I Sistemi Operativi nelle WSN

Un sistema operativo per reti di sensori, non gode della possibilità di poter usufruire di

abbondanti risorse: il generico nodo sensore dispone di unità di elaborazione molto

elementari (la frequenza di clock è di qualche centinaio di MHZ), di supporti di memoria di

al più un centinaio di KB, ma soprattutto di limitate fonti energetiche quali le comuni

batterie alcaline. Di conseguenza i requisiti funzionali che il sistema operativo deve

soddisfare sono estremamente stringenti e investono aspetti quali il supporto efficiente alla

concorrenza, per ottimizzare l’uso delle limitate risorse e vincoli real-time, la flessibilità e

modularità, per adeguarsi alle diverse piattaforme e scenari applicativi, e l’uso efficiente

delle risorse, per ottimizzare il consumo energetico. Inoltre, anche l'installazione di questi

sistemi deve essere molto semplice: generalmente non è richiesta nessuna formattazione del

disco rigido, ma bensì, essi vengono facilmente installati come un qualsiasi altro



23

programma su un sistema operativo host.

In letteratura, si distinguono principalmente due approcci allo sviluppo di sistemi operativi

per reti di sensori senza filo:

• sviluppare un sistema i cui componenti vengono compilati assieme ad una

particolare applicazione. In altri termini, una volta individuata un'applicazione, essa

viene compilata assieme all'intero sistema operativo, il quale può da quel momento

fornire soltanto le funzionalità di quella precisa applicazione all'utente. I vantaggi

risiedono ovviamente in ridotte dimensioni e bassi consumi, mentre gli svantaggi in

una scarsa versatilità e riconfigurabilità dell'applicazione (TinyOS).

• sviluppare un sistema che includa i tradizionali strati di software dei sistemi general

purpose in versione ridotta (come Mantis e LiteOS). In questo caso è difficile tenere

sotto controllo i consumi e le risorse impiegate, ma si guadagna in versatilità,

potendo eseguire più applicazioni contemporaneamente.

1.5.1 TinyOS

I requisiti funzionali che il Sistema Operativo adottato all’interno dei sensori di una WSN

deve soddisfare sono estremamente stringenti e investono aspetti quali il supporto efficiente

un sistema open-source specifico per Wireless Sensor Network sviluppato dall’Università di

Berkley e il centro ricerche Intel. I principali punti di forza risiedono soprattutto nelle

dimensioni fortemente ridotte (basti pensare che una tipica applicazione TinyOS-Based

occupa in media una decina di KB di cui solo 400B circa competono al sistema operativo),

e in una libreria di componenti legacy che include protocolli di rete, servizi distribuiti,

driver sensor e tool acquisizione progettati per svolgere i più consueti compiti per WSN:

grazie al suo ausilio, nei casi più semplici, lo sviluppo di un'applicazione si riduce al solo

collegamento (wiring) dei componenti di libreria necessari, mentre applicazioni più

complesse richiederanno la scrittura di componenti aggiuntivi ed il loro collegamento con il

kernel, i driver delle periferiche, ed eventualmente, altri componenti di libreria forniti con

TinyOS. Le applicazioni per TinyOS vengono scritte in nesC (network embedded systems

C), un dialetto del C, di cui implementa solo un sottoinsieme di costrutti per limitarne la



24

complessità e soprattutto la potenza espressiva alle sole parti che realmente interessano;

inoltre aggiunge vari nuovi comandi orientati a definire la struttura dell'applicazione stessa

sostituendo la necessita di usare un linker dinamico a tempo di esecuzione. Questo permette

al compilatore, il nescc (uno strumento che si basa sul compilatore gcc della Gnu) di

conoscere esattamente tutti i componenti in uso in una determinata applicazione, come

anche l'occupazione di memoria (dati e programma) e di produrre il relativo codice oggetto,

linkato staticamente con le sole parti richieste del kernel, il tutto quanto più possibile

ottimizzato in termini di dimensioni. La gestione di tutto avviene in maniera statica,

attraverso la Known Programming Interface, una serie di prototipi di funzioni ai quali

potersi appoggiare, linkandole (staticamente) all'atto della compilazione. La scelta di

rinunciare alla flessibilità di un modello di gestione dinamica è legata soprattutto alla

necessità di ridurre al minimo gli sprechi, infatti in questo modo il sistema operativo (e, di

conseguenza, il microcontrollore) non viene caricato dei vari task di gestione delle

operazioni dinamiche.

La sua architettura si basa su un modello a componenti riutilizzabili che comunicano

attraverso l’invocazione di comandi (solitamente da parte dei componenti più lontani a

quelli pù vicini) e sollevando eventi (nel verso opposto), la cui esecuzione avviene al livello

più alto di proprietà dello sheduler.

I componenti differiscono a seconda del ruolo che svolgono:

• Gli Hardware abstractions realizzano il mapping tra le funzionalità fornite via

software e quelle messe a disposizione dall’hardware, creando un’astrazione di

queste ultime che ne facilitano l’uso da parte dei moduli superiori;

• I Syntetic hardware simulano il comportamento di hardware specializzato, più

complesso di quesso realmente presente sul sensore;

• Gli High level software component sono quelli di livello superiore e hanno il

compito di eseguire gli algoritmi che prescindono dal particolare hardware.

Per richiedere un servizio ad un componente è necessario invocare un comando sul

componente stesso; per garantire un alto livello di concorrenza e una gestione più snella dei



25

task, ogni operazione non banale è eseguita come una split phase operation. Questo

significa che il componente chiamante riacquisisce il controllo immediatamente dopo che il

comando che esso ha lanciato ha avviato un task e invece di entrare in uno stato di attesa

bloccante, continua le sue operazioni. Al termine del task, che andrà in esecuzione in un

tempo successivo, verrà notificato un evento al componente che ha richiesto il comando. E’

perciò necessario che il componente utilizzatore del comando definisca determinati event-

handler su eventi del componente utilizzato. Il codice split-phase è sicuramente più lungo e

complesso di quello sequenziale ma ha l’indubbio vantaggio, oltre a quello di consentire

una parallelismo delle esecuzioni delle operazioni di un componente, di ridurre l’utilizzo

dello stack in quanto non è necessario tornare alla funzione chiamante e creare grosse

variabili sullo stack.

1.5.2 Mantis

Mantis OS è un sistema operativo progettato e sviluppato dalla Colorado University. Da un

punto di vista concettuale è corretto dire che esso è opposto a TinyOS, poichè, essendo un

SO general purpose, ha una classica architettura multithread stratificata, inoltre contiene

uno scheduler preemptive con time slicing. Queste caratteristiche rendono possibile in un

nodo sensore, intrecciare l’esecuzione di task complessi con quella di task che hanno dei

requisiti temporali stringenti. Inoltre utilizza meccanismi di sincronizzazione attraverso

sezioni in mutua esclusione, ed ha uno stack protocollare standard per la rete e device

driver. L’occupazione di memoria di Mantis è molto ridotta. infatti in un’immagine che non

supera i 500 byte è contenuto il kernel, lo scheduler e lo stack di rete. Il consumo energetico

in Mantis è molto basso in quanto viene utilizzato uno scheduler che quando tutti i thread

attivi chiamano la funzione sleep() di MOS, spegne il microcontrollore, riducendo

notevolmente i consumi. Le sue caratteristiche principali sono la flessibilità, che garantisce

il supporto per piattaforme diverse, e la gestione di sensori attraverso la ri-programmazione

dinamica da remoto. Quest’ultima risulta estremamente importante poiché studi condotti sul

campo, hanno dimostrato che i nodi sensori necessitano di riconfigurazioni o modifiche



26

periodiche ed essendo i contesti ambientali nei quali essi sono inseriti difficilmente

accessibili, la possibilità di poter effettuare tali riconfigurazioni da remoto semplifica

enormemente la gestione della rete. Mantis quindi consente:

• il reflash dell’intero OS;

• la riprogrammazione di un singolo thread;

• cambiamento delle variabili all'interno di un thread.

Inoltre le modalità attraverso le quali ciò avviene sono due: la programmazione semplice e

quella avanzata.

Nella modalità di programmazione semplice, è necessario un collegamento diretto del nodo

Mantis (ad esempio attraverso la porta seriale del sensore), ad un personal computer per

poter avviare la shell di Mantis. A questo punto (dopo un restart) MOS avvia un boot loader

che cerca eventuali comunicazioni dalla shell, in questo modo il nodo accetterà il nuovo

codice immagine che verrà scaricato dal personal computer attraverso la connessione

diretta. Il boot loader trasferisce il controllo al kernel di Mantis o in seguito ad un apposito

comando dalla shell oppure se durante lo startup non è individuata nessuna shell.

La modalità di programmazione avanzata è utilizzata quando il nodo è stato già messo in

esercizio, di conseguenza è richiesto un collegamento diretto al nodo sensore. La possibilità

di gestire i nodi da remoto è fornita attraverso il Mantis Command Server (MCS) che è in

ascolto sia sulla porta seriale che sull’interfaccia radio di comandi che possono essere

inviati sia dal kernel che dalle applicazioni. L’utente, attraverso un qualsiasi dispositivo

della rete dotato di terminale, può invocare il mantis command client ed effettuare il login

in un nodo sensore; può visualizzare la lista dei comandi supportati dall’MCS, può

ispezionare e modificare la memoria del nodo, cambiare le impostazioni di configurazione,

eseguire o terminare programmi, visualizzare la tabella dei thread e riavviare il nodo.

1.5.3 LiteOS

LiteOS è un sistema operativo open-souce per WSN, nato nel 2007 dalla sinergia dei

dipartimenti di scienze informatiche dell’Università dell'Illinois at Urbana-Champaign,



27

dell’Università del Minnesota e dell’Università della Virginia. Questo OS è stato progettato

per fornire un'astrazione di tipo Unix per una wireless sensor network. I nodi infatti (come

si vedrà in seguito) vengono considerati come delle semplici directory disposte all'interno di

un file system organizzato in una struttura gerarchica. Esso è stato scritto in C, ed adotta un

modello di programmazione più semplice di quello di altri sistemi operativi della stessa

categoria. Attraverso una serie di interfacce semplici, esso ha come obiettivo quello di

ridurre gli sforzi di apprendimento di un generico utente o di un programmatore, che voglia

cimentarsi nella gestione o nell'uso di una WSN. Infatti, già ad esempio TinyOS è un

sistema più difficile da apprendere, poiché, come visto sopra, è scritto in NesC e di

conseguenza adotta un modello di programmazione basato sugli eventi, molto più

complesso. LiteOS invece, offre anche ad utenti inesperti ambienti familiari, basati proprio

su grafiche e interfacce tipiche di sistemi operativi di tipo UNIX. Infatti, per avere un

approccio diretto con LiteOS, è necessario semplicemente:

• Conoscere il linguaggio C;

• Avere un po' di esperienza d'uso di sistemi operativi di tipo UNIX;

• Conoscere il concetto di thread.

Inoltre, poiché l'utente vede ciascun nodo della rete come una semplice cartella, può

interagire con essi in maniera molto semplice, per trasferire un file, o ancora, per ricevere

un pacchetto dati.

Come per i due OS analizzati nei paragrafi precedenti, anche LiteOS dispone di

un'architettura modulare. Tuttavia a differenza di TinyOS e Mantis, i tre moduli di cui essa

è costituita, la Liteshell, il FileSystem, e il Kernel, non si dispongono su diversi livelli

secondo una struttura top-down così da intravedere una netta stratificazione. Inoltre questi

non risiedono tutti sulla stessa apparecchiatura, ma si distribuiscono tra stazione base di

controllo e nodi. Quando un utente, attraverso la shell, realizza una certa operazione su un

nodo, questa in realtà si traduce in una azione sul file system del sistema operativo (questo

perché, come si è già detto, i nodi vengono visti come semplici cartelle), e per questo

motivo l'interazione tra File System e Liteshell, è solo di natura occasionale: cioè, solo se



28

un utente, seduto al terminale della stazione base, richiede di compiere una precisa azione

sui nodi, allora i due moduli interagiscono tra loro, altrimenti non vi è alcuna forma di

interazione.

Il secondo modulo dell'architettura, il file system, è chiamato LiteFS, ed è stato progettato

appositamente per garantire un efficiente meccanismo di montaggio dei nodi: l'allaccio di

un nuovo nodo alla rete è paragonabile all’inserimento di un dispositivo USB ad una porta

di un Personal Computer. Stesso discorso dicasi per quanto concerne il distacco di un

sensore dalla WSN.

Il terzo ed ultimo modulo dell'architettura è il Kernel, Ii vero fiore all'occhiello del sistema

operativo poiché la sua principale caratteristica è quella di realizzare il caricamento

dinamico della memoria, che consente a più threads di occupare aree di memoria in maniera

concorrente, senza generare dei conflitti. La tecnica adottata prevede di salvare gli indirizzi

di memoria riservati ai singoli processi, in un file in formato HEX sotto forma, cioè, di

stringhe di caratteri esadecimali in modo da ridurre al minimo l’occupazione di memoria.



29

Capitolo 2

Tecniche e Strumenti per la valutazione di WSN

Le caratteristiche che sono state approfondite nel capitolo precedente, quali l’assenza o

quasi di robustezza, dovuta alle dimensioni ridotte dei sensori, la significativa limitazione in

termini di potenza di calcolo, memoria e durata energetica, e l’affidabilità, fanno delle WSN

una fonte inesauribile di problemi di ricerca interessanti e stimolanti per la comunità

scientifica. Se fino a qualche anno fa l’attività dei ricercatori era incentrata

prevalentemente su tematiche come lo sviluppo di strategie di routing, protocolli di livello

MAC o ancora algoritmi e protocolli energeticamente efficienti, negli ultimi tre anni

l’attenzione si è spostata verso la modellizzazione dei sistemi, gli studi sulla reliability, in

particolare sulla valutazione della dependability, e sulle soluzioni per la fault tolerant, con

un’attenzione maggiore alle problematiche legate alla security. Esiste infatti una particolare

classe di sistemi tali che se si dovesse verificare un fallimento durante l’esecuzione di una

delle loro funzionalità potrebbe comportare conseguenze di notevole entità, sia in termini di

perdite finanziarie, sia di danni a persone e/o ambiente. E’ evidente perché per tali sistemi,

definiti critici, i concetti di affidabilità e sicurezza assumano un’importanza fondamentale.

Inoltre è opportuno che ad una prima analisi teorica delle soluzioni proposte segua una

ulteriore fase di validazione basata sull’uso di simulatori o di emulatori, indispensabile per

realizzare soluzioni che siano non solo efficienti, ma soprattutto pratiche.

Nel seguito del capitolo verranno quindi approfondite dapprima le principali tecniche di



30

valutazione degli attributi di un sistema dependable; seguirà una esposizione delle

caratteristiche che distinguono i vari simulatori; infine verrà fornita una trattazione sintetica

dei più accreditati strumenti di simulazione a supporto dello sviluppo delle WSN ad oggi

sul mercato, elencando per ognuno di essi punti di forza e limitazioni.

2.1 Dependability nelle WSN

Un sistema può considerarsi dependable se “è possibile riporre fiducia nel suo

funzionamento in modo giustificato” [1], in realtà vari sono i livelli di affidabilità che si

possono raggiungere, i quali dipendono dalle finalità e dalle caratteristiche che devono

essere soddisfatte nella particolare applicazione in cui il sistema andrà ad operare. In

generale però è possibile affermare che un sistema affidabile sarà operativo quando

necessario(availability), terrà un funzionamento corretto durante il suo utilizzo (reliability),

non consentirà alcun accesso non autorizzato(confidentiality) o la modifica delle

informazioni che esso utilizza (integrity) e che il suo funzionamento sarà sicuro sia in

termini di incolumità a persone e/o ambienti, sia di protezione nei confronti di minacce

esterne, di natura naturale o intenzionale (safety). Le tecniche adottate oggi, sono basate su

rigorosi standard internazionali e mirano a prevedere, prevenire, tollerare e rimuovere

eventuali guasti, errori o fallimenti che possano minare l’integrità della rete (un esempio è il

DO-178B impiegato in campo aeronautico).

Esse possono essere classificate in due categorie principali, la prima include quelle basate

su una valutazione probabilistica o quantitativa, e hanno come obiettivo quello si stimare gli

attributi delle dependability del sistema (o delle sue componenti) sopra menzionati; l’altra,

comprende le tecniche impostate su un’analisi di carattere qualitativo, che puntano a

stabilire come eventuali guasti dei componenti possano riflettersi sulla perdita di

funzionalità, prestazioni e su malfunzionamenti di sistema. La valutazione quantitativa può

essere eseguita attraverso tecniche sperimentali oppure tecniche modellistiche [2][9].



31

2.1.1 Tecniche Sperimentali

Le Tecniche Sperimentali o basate su misure, operano direttamente sul sistema reale, quindi

non sono praticabili in assenza del sistema oppure di un suo prototipo. La verifica della

validità delle scelte eseguite in fase di progettazione avviene attraverso una stima delle

grandezze di interesse ottenuta dall’analisi diretta dei dati statistici. Presentano l’indubbio

vantaggio di raccogliere dati con un livello di accuratezza nettamente maggiore rispetto a

quelli ricavati da qualsiasi modello del sistema, tuttavia la loro attuazione può risultare

estremamente costosa a causa della strumentazione apposita necessaria e come spesso

accade in presenza di osservazioni sperimentali, per ottenere campioni statisticamente

significativi di dati, sono necessari lunghi periodi di osservazione, rendendo l’analisi dei

risultati di non facile valutazione; inoltre, in caso di sistema troppo complesso risulta

impraticabile sviluppare il prototipo.

2.1.2 Tecniche Modellistiche

Un modello è l’insieme delle assunzioni semplificative fatte sul funzionamento di un

sistema ed espresse sotto forma di relazioni logico-matematiche. Modellare un sistema

significa rimpiazzarlo con qualcosa che sia più semplice e/o facile da studiare, equivalente

al sistema originale in tutti i particolari aspetti importanti. Un buon modello deve riuscire a

combinare accuratezza e semplicità, fornendo informazioni dettagliate, ma a un costo, in

termini di tempi e risorse, accettabile. Infatti, la motivazione che spinge al loro impiego va

ricercata soprattutto nel fatto che la valutazione della risposta di un sistema in seguito alla

variazione in alcuni dei suoi parametri o caratteristiche strutturali è solitamente ottenuta in

maniera molto più conveniente tramite la soluzione di un modello che dal sistema reale.

Sono da annoverare tra le metodologie di analisi basate sui modelli le Tecniche Analitiche e

quelle Simulative.

Per quanto concerne le prime, i molteplici formalismi usati sono classificati in base alla

tipologia di analisi alla quale si prestano: di tipo combinatoriale o basata sullo spazio degli

stati. Le tecniche combinatoriali hanno il vantaggio di essere molto semplici da trattare, ma



32

non riescono a rappresentare certe dipendenze dei sistemi, poiché necessitano di assunzioni

troppo restrittive, come l’indipendenza delle probabilità di guasto dei singoli costituenti.

Esempi di tali formalismi sono i Fault Trees, caratterizzati da un approccio deduttivo

(procedendo dagli effetti verso le cause puntano a identificare le origini dei fallimenti del

sistema al livello dei componenti elementari), e i Reliability Block Diagram, che invece

adottano un approccio induttivo (procedendo nel verso opposto puntano a determinare come

si ripercuotono al livello del sistema i malfunzionamenti dei componenti). Per ovviare alle

limitazione imposte da questa tipologia di formalismi, possono essere impiegati quelli

basati sullo spazio degli stati, i quali sono, sì, più sofisticati, ma anche più difficili da

trattare, poiché soffrono del problema dell’esplosione degli stati: il fatto che eventi

concorrenti possano essere eseguiti in qualsiasi ordine e che ogni possibile esecuzione

generi sequenze di stati diversi, rende lo spazio degli stati, seppur finito, così ampio non

poter essere analizzato in modo effettivo. E’ in questa categoria che rientrano, ad esempio, i

processi Markoviani, le reti di Petri Stocastiche o le Stochastic Activity Networks (SAN). In

realtà non esiste un formalismo in assoluto migliore degli altri, la scelta varia in funzione

degli aspetti da modellare e degli obiettivi dell’analisi e quindi dalla potenza espressiva

richiesta al particolare linguaggio: sarebbe infatti impensabile modellare un sistema

complesso utilizzando formalismi di elevata potenza espressiva, come quelli basati sulle reti

di Petri, perché se anche si riuscisse a gestire la difficoltà modellistica, si otterrebbe un

modello impossibile da risolvere su qualsiasi elaboratore commerciale.

Quando anche i modelli analitici risultano essere inappropriati a causa dell’elevata richiesta

di risorse computazionali, le tecniche simulative si presentano ad essere l’unica strada

percorribile: una simulazione e’ un sistema che rappresenta o emula nel tempo, il

comportamento di un altro sistema [17], generando così una storia artificiale del sistema

fisico emulato che può essere usata per il suo studio. Come tutte le altre tecniche model-

based, anch’essa presuppone l'esistenza di un modello che sia adeguatamente aderente al

sistema reale oggetto di studio, ossia fornisca con sufficiente accuratezza una descrizione

del comportamento del sistema, e in aggiunta prevede l'esecuzione di un software dedicato,



33

detto simulatore, il cui compito è quello di rappresentare l'evoluzione temporale del sistema

e fornire una stima delle misure di interesse. Le tecniche simulative sono classificate in

statiche se riproducono un sistema in un determinato istante di tempo, e dinamiche se

invece almeno una delle variabili dipende da tempo. Quest’ultimi utilizzano un modello

formato da variabili che permettono di rappresentare lo stato del sistema, si distinguono a

seconda che la variazione rispetto al tempo avvenga in modo discreto, Discrete-Event, (le

variabili di stato cambiano istantaneamente ad istanti di tempo separati, in corrispondenza

di eventi discreti) oppure continuo, Continuous-Event, nel qual caso la simulazione

consisterà tipicamente nella soluzione analitica (esatta) o numerica (approssimata) di

equazioni differenziali.

Modelli Analitici

Da un’analisi approfondita realizzata in [9] sui vari modelli analitici proposti in letteratura

per stimare le caratteristiche prestazionali di WSN, è risultato come le ipotesi semplificative

di affidabilità comunemente adottate nella quasi totalità dei lavori non tengano bene nella

pratica, fornendo una conseguente valutazione errata di parametri critici come, esempio, il

tempo di vita della rete.

In [10] viene supposto che il consumo energetico e la sopravvivenza della rete dipendano

unicamente dall’attività di trasmissione dati; in [11] viene studiato l’effetto che avrebbe

sulla rete l’impiego di nodi sink mobili per la raccolta dei dati, per mitigare il consumo di

quelli fissi. In questi lavori il tempo di vita della WSN è considerato quindi solo funzione

del consumo energetico e del numero di pacchetti trasmessi, senza tenere in considerazione

altri fattori importanti come la probabilità di fallimento dei singoli nodi.

Un concetto più generico viene proposto in [12], che tiene conto dei vari requisiti che

un’applicazione deve soddisfare, come il numero di nodi attivi, la latenza dei tempi di

consegna, la connettività, la copertura etc. Quindi la durata una rete wireless viene a essere

definita dal tempo durante il quale tutti questi requisiti sono soddisfatti.

Il lavoro in [13], invece, focalizza l’attenzione sull’affidabilità e sulle misure di ritardo di



34

consegna dei pacchetti, relativi alla probabilità di operatività dei singoli nodi: si è assunto

che la frequenza con la quale i fallimenti occorrono avviene in modo uniforme su tutta la

rete ed è dovuta essenzialmente all’usura dei componenti, alle interruzioni di corrente e a

catastrofi ambientali, dimostrando che valutare l’affidabilità in una rete generica è in realtà

un problema estremamente complesso e articolato.

In [14] gli autori affrontano il fenomeno dell’invecchiamento dei nodi al quale concorrono

il tasso di consumo energetico e quello di fallimento: è presentata una funzione di

sopravvivenza per ogni componente, in termini di una distribuzione di Weibull. In pratica

viene analizzato il comportamento di una rete organizzata ad albero con e senza tecniche di

aggregazione dei nodi, il che ha messo in evidenza che l’uso di queste ultime ne rallenta in

modo significativo il consumo di energia, avallando la tesi che vede il numero di nodi

intermedi in una trasmissione di dati che adotti una strategia multi-hop, cruciale nel

consumo energetico.

Il lavoro presentato in [15] è uno dei primi ad adottare un modello analitico per

rappresentare i passaggi tra le modalità di funzionamento dormiente/attivo dei nodi, in

particolare in termini di contesa del canale radio e delle problematiche di routing. Tuttavia

l’assunzione che è possibile usare catene Markoviane [9] nella modellizzazione, potrebbe

dar luogo alla formulazione di metriche di performance spesso sopravvalutate.

Tutte le opere che abbiamo citato aiutano a comprendere come gli approcci analitici ben si

prestano alla valutazione di caratteristiche prestazionali di WSN, ma solo sotto particolari

ipotesi semplificative che il più delle volte sono molto lontane dalla realtà, mentre non

bastano a risolvere il problema, dimostrato essere NP-Hard [16], in una rete arbitraria.

Modello dei fallimenti

Per studiare l’affidabilità di una WSN durante la fase di progettazione è necessario essere in

possesso di un suo accurato modello dei fallimenti. Per poter definire delle assunzioni

valide, si è ricorso al prezioso ausilio di studi sperimentali che hanno contribuito a

modellare un comportamento delle reti il più possibile aderente alla realtà.



35

Come descritto in [9], nel lavoro[18] allo scopo di analizzare l’impatto della connettività

sulla reliability della rete, viene analizzata una rete organizzata in clusters, i soli fallimenti

considerati sono quelli del gateway, relativi all’esaurimento delle batterie, e del modulo

radio, dovuti sia a guasti hardware che a fallimenti di nodi nel suo range operativo. Il lavoro

fornisce anche un’analisi teorica sulla soglia del range radio che garantisce la connettività

tra nodi di una rete dislocata casualmente, utilizzando un modello matematico.

In [19], invece analizzano come il fallimento di un singolo nodo si rifletta sullo stato di

funzionamento dell’intera WSN: è stato proposto un limite superiore alla probabilità che

tutti i nodi siano connessi e tutta l’area della rete sia coperta, per nodi uniformemente

distribuiti sul suolo e con probabilità di fallimento anch’essa uniforme in tutta la rete. Non

viene però fornita alcuna analisi sulla connettività in grado di fornire risultati circa i

fenomeni di invecchiamento di una WSN come la ‘morte’ di nodi faulty o con batterie

esauste, ipotesi in cui cadrebbe l’assunzione di densità uniforme della rete.

In [20] viene proposto un modello in cui la rete è organizzata in cluster con cluster-head

rotante. I nodi possono fallire in maniera arbitraria generando mancati o falsi rapporti. Ad

ogni nodo è inoltre associato un ‘indice di fiducia’ per indicarne la credibilità in funzione

dei suoi fallimenti passati: l’indice è poi usato dal cluster head per valutare se gli

eventi generati da un nodo siano o meno ‘credibili’.

In [6] gli autori considerano un modello dei fallimenti in cui le modalità di fallimento sono

crashing oppure Byzantine behavior quindi le cause di un fallimento di un nodo possono

essere sia relative a guasti che a manomissioni. Insieme al modello dei fallimenti viene

utilizzato anche un modello della rete in cui si adottano sia tecniche statistiche sulla

clusterizzazione che tecniche orientate al rispetto della security ricavate da stime sul tasso di

fallimento dei sensori. Viene definita la reliability di una WSN come la probabilità che

esista un cammino tra il sink e almeno un unico nodo funzionante del cluster: adottando

questa definizione viene dimostrato come per reti di topologia arbitraria, la soluzione del

modello di affidabilità considerato rappresenti un problema di complessità non polinomiale,

tranne che per un caso particolare analizzato, per cui vengono fornite anche delle misure



36

ottenute tramite simulazione [3].

2.2 Ambienti di Simulazione

Come più volte ripetuto nel corso di questa tesi, le Wireless Sensor Networks sono formate

da un grande numero di nodi di rete di rilevamento, risulta quindi piuttosto complesso, o

addirittura irrealizzabile, modellare analiticamente una WSN; se pure fosse fattibile, ne

conseguirebbe un’analisi spesso troppo semplificativa, poco aderente alla realtà. D’altro

canto, l’impiego di banchi di prova concreti prevede uno sforzo enorme in termini di costi

di attuazione e di tempi di esecuzione. Eseguire infatti esperimenti sul sistema reale per

effettuarne una valutazione delle prestazioni che sia di supporto in fase di progettazione, è

costoso e difficile, e richiede spesso tempi di analisi piuttosto lunghi. Inoltre la ripetibilità

degli stessi è in gran parte compromessa in quanto molti fattori ne influenzano i risultati

sperimentali, non solo, ma risulta anche difficile isolare i singoli aspetti. Queste sono le

ragioni del recente boom nel settore dei simulatori, strumenti universalmente utilizzati per

sviluppare WSN, soprattutto nella fase iniziale: consentono, infatti di emulare il

comportamento di migliaia di nodi ad un costo contenuto e in tempi di esecuzione molto

brevi, al fine di studiarne gli aspetti critici; impiegati nell’analisi di sistemi ‘ipotetici’,

permettono di determinare il valore ottimale di parametri o i punti critici (bottlenecks). Ci

sono tuttavia due aspetti importanti da non sottovalutare per ottenere conclusioni fondate da

uno studio di simulazione: per ricavare risultati di fiducia è richiesta, da un lato, la

correttezza dei modelli di simulazione, ovvero che siano basati su solide assunzioni,

dall’altro, l'idoneità del particolare strumento impiegato per attuare il modello. Poiché sul

mercato esistono vari software che offrono funzionalità per modellare e riprodurre il

comportamento dei sistemi reali, alcuni dei quali sono progettati per raggiungere buone

prestazioni, mentre altri per fornire un semplice ed amichevole interfaccia grafica o

funzionalità emulative, è necessario trovare un compromesso tra la precisione e la necessità

dei dettagli, e le prestazioni e la scalabilità della simulazione, in base a quelli che saranno i

fini della rete da sviluppare.



37

2.2.1 Simulazioni Discrete-Event e Trace-Driven

Una prima classificazione delle simulazioni può essere effettuata in funzione del tipo di

approccio adottato per condurre la simulazione. La tipologia trace-driven è quella più

comunemente utilizzata dai sistemi reali poiché presenta risultati più credibili e fornisce

un’accuratezza maggiore relativa al carico di lavoro. Essa opera su una sequenza di eventi

ordinati per tempo e registrati dal sistema reale, e non essendo basata su semplici ipotesi

risulta essere sicuramente più affidabile.

La simulazione ad eventi discreti, invece, esamina lo stato del sistema solo in

corrispondenza degli istanti in cui avviene un evento significativo. Con questo approccio si

salta immediatamente da un evento al successivo, senza simulare gli intervalli di tempo che

intercorrono fra due eventi, e questo avvantaggia notevolmente tale tipo di simulatori

rispetto a quelli tempo-continui in termini di complessità computazionale. Un apposito

scheduler degli eventi gestisce la coda di eventi generati dalla simulazione, ed ha la

responsabilità di ordinarli correttamente, nello stesso modo in cui essi si succederebbero

nella realtà. La maggior parte dei simulatori che esamineremo sono ad eventi discreti,

poiché è tipico delle applicazioni per WSN lasciare il processore ed i componenti hardware

in uno stato di sleep per la maggior parte del tempo, allo scopo di risparmiare energia.

2.2.2 Simulatori o Emulatori

Un software d'emulazione è un programma che permette l'esecuzione di software

originariamente scritto per un ambiente (hardware o software) diverso da quello sul quale

l'emulatore viene eseguito. Esistono varie categorie di emulatori, così come esistono diversi

metodi per emulare una piattaforma. È possibile emulare completamente un ambiente sia

hardware che software oppure soltanto uno dei due. Emulare un ambiente software è

tecnicamente meno complicato poiché può essere sufficiente un semplice traduttore di

istruzioni che renda comprensibile all'ambiente sul quale l'emulatore gira le istruzioni del

programma emulato. Nel caso invece dell'emulazione hardware, sarà necessario simulare la



38

circuiteria e il comportamento fisico del sistema. Un emulatore necessita sempre del

software di quel sistema (ottenuto con un processo detto spesso dumping), limitandosi

quindi ad emulare l'hardware, in modo da poter interpretare correttamente i file contenenti i

dump del software (che rimane scritto in un linguaggio comprensibile soltanto al sistema

emulato e non al sistema emulante, o sistema host). Si prefigge lo scopo di replicare il

funzionamento di un sistema. Una categoria particolare di emulatori sono quelli che fanno

uso di emulazione ad alto livello (high-level emulation), che si pongono a metà strada tra un

emulatore e un simulatore, in quanto ricreano le funzionalità di un sistema emulato facendo

uso di funzioni simili o equivalenti nel sistema emulante, raggiungendo alte velocità di

esecuzione a scapito dell'accuratezza. A questa categoria appartengono ad esempio Tossim

e EmStar, che ricompilano il codice ad alto livello e scelgono di perdere un po’ di fedeltà

nell’emulazione, in cambio di una maggiore scalabilità ed attenzione al funzionamento

macroscopico della rete, e Avrora e Atemu che invece puntano ad un’emulazione del codice

in linguaggio macchina o assemblativo, fornendo i addirittura meccanismi per effettuare il

debugging delle applicazioni, dedicando meno attenzione verso quelli che sono gli aspetti

macroscopici della rete

Un simulatore, invece, si prefigge lo scopo di replicare il comportamento di un sistema,

riscrivendo però (in tutto o in parte) le routine del programma da simulare, in modo da

renderlo comprensibile alla macchina su cui gira. Non essendoci alcuna emulazione

dell'hardware (cosa che prende diversi cicli-macchina), un simulatore è per forza di cose più

veloce, tuttavia è spesso poco preciso nel riproporre fedelmente il software simulato ed

inoltre la maggioranza delle volte il suo codice sorgente non è disponibile. Per tali motivi,

se i simulatori hanno dalla loro una notevole velocità di esecuzione, gli emulatori hanno

l'accuratezza (che comprende, ovviamente, anche eventuali bug del software e/o della

macchina originale). Appartengono a questa categoria Omnet++ che riproduce gli aspetti

legati ai protocolli di livello rete, trasporto o MAC, e Ns-2 e J-Sim, che invece puntano solo ad

uno studio applicativo degli algoritmi di instradamento.



39

2.2.3 Analisi Qualitativa

In questo paragrafo analizzeremo le principali caratteristiche dei più accreditati strumenti di

simulazione per WSN. Poiché non è scopo di questa tesi fornirne aspetti dettagliati, per un

approfondimento si rimanda a [6].

NS-2

Ns-2 è un simulatore Discrete-Event utilizzato nella simulazione di protocolli di routing, a

supporto protocolli di rete. Nato nel 1989, si è imposto nel corso di tutti questi anni come

uno dei simulatori di reti più usati, anche grazie alla sua estensibilità ed alla possibilità di

simulare scenari del tipo più disparato. E’ scritto C++ e fornisce un'interfaccia di

simulazione attraverso OTcl, un dialetto object-oriented di Tcl. L'utente descrive una

topologia di rete scrivendo script OTcl, e poi il programma principale si occupa di simulare

la topologia con i parametri specificati. E’ a oggi uno dei più popolari simulatori di rete

non-specifici e supporta una notevole gamma di protocolli a tutti i livelli; inoltre il modello

open source consente di risparmiare i costi di simulazione e la documentazione online

permette facilmente agli utenti di modificare e migliorare i codici.

Tuttavia a causa dell’assenza di una GUI, talvolta la simulazione risulta più complessa e

richiede tempi assai maggiori rispetto ad altri simulatori; l’assenza un supporto grafico pone

gli utenti direttamente a contatto con i comandi testuali dei dispositivi elettronici e devono

pertanto avere familiarità con la scrittura di linguaggi di scripting, le teorie delle code e le

tecniche di modellazione; inoltre a causa dei continui cambiamenti del codice di base e dei

numerosi bug contenuti in alcuni protocolli, i risultati ottenuti possono non essere

consistenti. Altre limitazioni sono invece dovute alle origini di NS-2, legate essenzialmente

alle reti IP, per le quali era stato inizialmente sviluppato. Ad esempio abbiamo detto che è

in grado di simulare i protocolli a vari livelli, ma non il comportamento delle applicazioni

con le quali essi interagiscono, e il fatto che in una WSN non esiste una netta separazione

tra i due, rende spesso NS-2 inadeguato; ancora, poiché è progettato come un simulatore di

rete generale, non prende in considerazione alcune caratteristiche uniche di WSN come i



40

problemi del consumo di banda, potenza o risparmio energetico; soffre di un problema di

scalabilità poiché all’aumentare del numero di nodi, la dimensione del file di traccia ne

renderà difficoltosa la gestione.

TOSSIM

TOSSIM è un emulatore Discret-Event bit-level (ogni volta che un bit è trasmesso o

ricevuto viene generato un evento) specificatamente progettato per WSN e in esecuzione su

TinyOS. La trasmissione a livello del bit lo rende però molto poco scalabile e soprattutto

non adatto alla simulazione di reti realmente complesse. Il modello open-source e la

documentazione online ne fanno un simulatore grandemente estensibile, con funzionalità

che possono essere ampliate notevolmente scrivendo plug-in. E’ caratterizzato da un uso

semplice e immediato grazie alla sua GUI, TinyViz, che permette all’utente di interagire

con i dispositivi elettronici attraverso immagini invece che con comandi testuali. Con

questa interfaccia TOSSIM condivide un event bus attraverso cui essa può essere sempre in

ascolto di tutti gli eventi generati durante la simulazione. Questa strategia fornisce a

TinyViz la capacità sia di visualizzare in tempo reale lo stato della simulazione che di

controllarne l’avanzamento. La sua semplicità non ne limita tuttavia potenza e accuratezza

in quanto, simulando il codice ad un livello molto basso, produce risultati precisi e fedeli

alla realtà. Come emulatore specifico di rete, è in grado di supportare la simulazione di

migliaia nodi e fornire molte informazioni sia sul funzionamento individuale dei sensori che

sul comportamento macroscopico della rete. Essendo progettato specificatamente per

simulare i comportamenti e le applicazioni di TinyOS, non fornisce misurazioni delle

prestazioni di altri nuovi protocolli. Inoltre il fatto che l’eseguibile viene ottenuto attraverso

la compilazione contestuale dei componenti hardware emulati e con quelli di TinyOS

(usando il compilatore nesC, un linguaggio di programmazione event-driven, basato su

componenti e implementata su TinyOS), limita alle sole applicazioni omogenee la

possibilità di essere emulate. Per simulare correttamente i problemi del consumo energetico

nelle WSN viene fornito PowerTOSSIM, un altro simulatore di TinyOS, che estende le



41

numerose potenzialità di TOSSIM. Infine, attraverso un tool chiamato ‘lossy builder’mette

a disposizione un ottimo modello di propagazione radio per topologie a griglia, basato su

dati empirici che forniscono una stima delle probabilità di perdita di un pacchetto.

EmStar

Emstar è un framework concepito per studiare due tipi di WSN: quelle costituite da sensori

Microservers con architettura a 32-bit, che fanno uso tipicamente di sistema operativo

Linux, e quelle composte da sensori Mica a 8-bit, che sfruttano il sistema operativo TinyOs,

fornendo, a seconda dei casi, sia funzionalità di emulazione che di simulazione. La sua

architettura modulare, ma non strettamente livelizzata, permette agli utenti di eseguire ogni

modulo separatamente, senza sacrificare la riusabilità del software; inoltre le sue

caratteristiche di robustezza mitigano i guasti tra i sensori. Il tool principale per eseguire

applicazioni nell’ambiente Emstar è Emrun, progettato per i) lanciare le applicazioni nel

giusto ordine, verificandone le eventuali dipendenze attraverso la consultazione di un file

di configurazione, e massimizzandone il parallelismo; ii)far ripartire le applicazioni

interrotte; iii)individuare le applicazioni che non rispondono per riattivarle. La simulazione

vera e propria avviene usando i tool EmSim, per la simulazione di microservers, e EmCee,

per l’emulazione di radio dispositivi a bassa potenza. Inoltre lo staff della UCLA ha

sviluppato EmTOS che è un’estensione per abilitare anche l’esecuzione di applicazioni

basate su nesC/TinyOS. L’ambiente di simulazione offre anche una serie di servizi utili per

creare applicazioni Linux, come vari algoritmi di routing (tra i quali il Direct Diffusion, che

si occupa di inviare messaggi solo a gruppi di nodi interessati, utile per effettuare query

mirate all’interno della rete di sensori), un servizio di localizzazione che i sensori possono

adoperare per costruire e mantenere aggiornata in maniera dinamica la topologia della rete

circostante, un servizio di sincronizzazione tempo virtuale/reale indispensabile nelle

simulazioni ibride, ed altri ancora. Non tutte le componenti hardware di un sensore vengono

simulate da Emtos: è possibile per le applicazioni usare i led, la radio, e l’orologio di

sistema per la gestione dei timer. Non viene simulato l’uso del sensore, né il consumo



42

energetico, e queste sono delle limitazioni importanti in un emulatore che si prefigge lo

scopo di studiare il funzionamento dei sensori a basso livello.

ATEMU

ATEMU è un emulatore costruito in C delle piattaforme Atmel e Mica, dotate di processore

AVR. Il comportamento dei sensori è emulato a livello istruzione, invece il modello della

radio viene simulato. La sua GUI, Xatdb, fornisce la possibilità di utilizzarlo in modo

semplice per eseguire il codice dei nodi di cui è possibile effettuare il debuging, e

monitorarne il processo di esecuzione.

Atemu fornisce una libreria di device hardware come temporizzatori e ricetrasmettitori,

quindi una delle possibilità più interessanti è quella di poter definire l’hardware dei sensori

su cui eseguire le applicazioni. L’architettura hardware di un sensore può essere definita

scrivendo un file in XML, nel quale si indica quali e quanti moduli utilizzare per comporre

il sensore. Il modello di un sensore è piuttosto semplice: l’unica parte che non si può

modificare è il processore AVR, e si possono usare moduli software per emulare il

comportamento di tutti i dispositivi quali radio, led, sensore, ed altri ancora che possono

essere aggiunti. L’utente ha la possibilità di caratterizzare e combinare questi moduli nella

maniera che preferisce; in questo modo può simulare non solo i sensori esistenti,

impostando la corretta configurazione, ma anche sensori che non esistono nella realtà, allo

scopo sperimentale di studiarne il comportamento I vantaggi che comportano dall’impiego

di questo simulatore sono soprattutto due: la capacità di testare applicazioni e sistemi

operativi diversi da TinyOS la possibilità di simulare reti eterogenee di sensori caratterizzati

da hardware differenti (diversamente da quanto accade per esempio in Tossim). Tuttavia

essi sono ottenuti al prezzo di alti requisiti di processazione e limitata scalabilità. La

simulazione avviene ricercando la massima sincronia possibile, eseguendo un colpo di

clock per volta ed attendendo che tutti i nodi della rete ne abbiano portato a termine

l’esecuzione prima di passare al prossimo; l’approccio tempo-continuo è il più semplice per

gestire il delicato problema della sincronia, ma non il più conveniente dal punto di vista



43

della complessità computazionale. Inoltre a suo sfavore c’è da dire anche che esso supporta

un numero limitato di funzioni per la simulazione di problemi di routing e clustering.

AVRORA

Avrora è un emulatore Discrete-Event specificatamente progettato per WSN e sviluppato

interamente in Java, pertanto può solo simulare il comportamento hardware dei sensori

delle famiglie Atmel e Mica, dotati di processore AVR, eseguendo il codice del programma

in linguaggio assemblativo.

La principale differenza con Atemu consiste nel fatto che Avrora è un simulatore ad eventi,

e non tempo continuo. Non viene simulato il funzionamento dei sensori quando essi sono in

sleep, saltando direttamente al prossimo evento nella coda d’attesa di quel sensore che ne

provoca il risveglio ed il funzionamento. A questo si accompagna il fatto che ogni nodo

viene simulato in un thread a parte dal simulatore, il che consente di velocizzare

ulteriormente la simulazione, anche se ciò pone il delicato problema della sincronizzazione

degli eventi che riguardano nodi diversi. Avrora possiede due meccanismi per garantire la

sincronizzazione degli eventi, che è un aspetto cruciale della simulazione. Il primo metodo è

quello degli intervalli di sincronizzazione: ad intervalli temporali regolari, i nodi devono

fermarsi ed attendere gli altri prima di ripartire; questo dà modo a tutti gli eventi di essere

generati, prima di continuare con la simulazione, rendendo impossibile che qualche evento

venga “saltato” da qualche nodo. Questo metodo è efficace quando la simulazione è densa

di eventi. Il secondo metodo è quello di registrare in una struttura dati comune l’istante

virtuale al quale ciascun nodo è arrivato, e fare in modo che un nodo si blocchi quando la

differenza temporale con gli altri nodi diviene eccessiva; tale differenza non deve mai

superare il tempo necessario ad un evento, generato dai nodi vicini, per raggiungere il nodo

in questione. Questo metodo è efficace quando la simulazione è povera di eventi, e i sensori

trascorrono la quasi totalità del tempo in modalità sleep. A causa dell’assenza di

un’interfaccia grafica, per visualizzare i risultati della simulazione bisogna ricorrere

all’utilizzo dei monitor, ossia oggetti che “ascoltano” eventi di vario genere che accadono



44

durante la simulazione, ed elaborano dei parametri sintetici che vengono stampati alla fine

della stessa. Sono dei plug-in che l’utente può scrivere, sfruttando il fatto che il codice del

simulatore è aperto. Ad esempio il monitor interrupt gestisce una struttura dati,

aggiornandola di volta in volta che avviene un’interruzione nella simulazione, elaborando

statistiche su invocazioni, tempo di latenza, tipo, durata di tutte le interruzioni.

J-Sim

J-Sim è un simulatore Discrete-Event basato su componenti, sviluppato completamente in

Java. I principali vantaggi derivano dal notevole numero di protocolli supportati, inclusi i

framework per la simulazione di WSN, forniti di dettagliati modelli e algoritmi di

localizzazione, routing e di diffusione dati. I modelli sono riusabili e intercambiabili,

garantendo la massima flessibilità. Supporta una interfaccia grafica, Jacl, per le operazioni

di tracing e debugging e per la generazione degli script Tcl più semplice, anche se comunque il

lavoro richiede una certa complessità. All’interno di ogni nodo c’è un componente che simula

l’applicazione, ed interagisce con due pile protocollari sottostanti: una rappresenta il

software di rete (con livello di trasporto, rete, MAC, fisico) l’altra invece il sensore (con

uno strato agente ed uno che si occupa della ricezione degli stimoli). Il funzionamento dei

sensori è passivo, effettuano rilevazioni solo quando giungono degli opportuni stimoli

dall’ambiente esterno. Una possibilità offerta da J-Sim, ed assente in altri simulatori, è

quella di piazzare i cosiddetti Target node, ovverosia le sorgenti degli stimoli che verranno

captati dai nodi, e di impostare la politica con cui generano segnali. Anche il modello

energetico è simile a quello di Sensorsim: ci sono moduli che rappresentano la CPU e la

Radio, che possono operare in differenti stati di consumo energetico, ed un modello per

rappresentare la Batteria e la sua legge di scarica. I nodi wireless possono spostarsi

all’interno della topologia tridimensionale, come accade in Ns-2, secondo varie politiche

(spostamento casuale o movimento su di una rotta predefinita), questo vale anche per i

Target Node. Esistono inoltre dei sink, nodi che ricevono i messaggi della rete WSN e che

non sono sensori. C’è la possibilità di creare reti eterogenee, costituite da elementi wireless



45

e wired al tempo stesso.

Un’altra caratteristica in comune con Ns-2, è la presenza di un supporto a livello di libreria

(quindi sotto forma di componenti) per costruire applicazioni basate sul concetto di direct

diffusion, ossia che prevedono un modello di comunicazione publisher/subscriber in cui i

messaggi vengono inviati a gruppi di nodi interessati; utile per sviluppare alcune

applicazioni per WSN, che prevedono l’invio di query, o la ricezione di dati, coinvolgendo

l’insieme di nodi che soddisfano una certa condizione.

OMNeT++

Omnet++ è un simulatore Discret-Event scritto in C++ secondo il paradigma della

programmazione basata sui componenti, che usa il linguaggio Ned per la configurazione

della simulazione. Anche se non supporta in modo nativo librerie specificatamente

progettate per le WSN, grazie al contributo dei team progetto, ora esso è in grado di

supportare protocolli MAC e di localizzazione di WSN seppur in numero molto limitato;

inoltre è possibile realizzare la simulazione dei controlli del canale radio e dei problemi del

consumo energetico delle reti, e estrarre alcuni dati sul traffico di rete. Tuttavia, poiché i

vari moduli aggiunti per consentire di estenderne le funzionalità anche nel settore delle reti

wireless sono sviluppati separatamente dai vari gruppi di ricerca, si prevede un aumento

delle problematiche di compatibilità tra essi: la combinazione di modelli risulterà sempre

più difficile, e i programmi potrebbero avere elevate probabilità di riportare bug.

Omnet++ è fornito di una potente GUI che permette all’utente di effettuare in modo agevole

le operazioni di tracing e debugging, più che in tutti gli altri simulatori visti fin’ora. Il

simulatore è concepito per una rappresentazione astratta dei nodi della rete, che nella

maggior parte dei casi avviene tramite un unico componente, o un insieme di pochi

componenti interni, che si occupano unicamente di descrivere come il nodo in questione

gestisce la ricetrasmissione di messaggi. I messaggi sono semplici strutture dati con poche

informazioni, come ad esempio mittente, destinatario finale, dimensione in bit del pacchetto

per calcolare il tempo di trasmissione su di un link.



46

2.3 Osservazioni finali

Da quanto osservato fin’ora è emerso che sugli approcci tradizionalmente impiegati nella

valutazione delle proprietà non funzionali delle Wsn, come il consumo energetico e

l’affidabilità, pesano in maniera determinante la forte eterogeneità delle applicazioni

all’interno delle quali esse sono impiegate, e la complessità delle dinamiche della rete

stessa, come routing, propagazione radio dei segnali, protocolli di livello Mac, etc... Le

tecniche più comunemente utilizzate sono per lo più basate su simulatori comportamentali e

modelli analitici: un modello simulativo, spesso chiamato behavioral è un modello

operativo che mima il comportamento di un sistema reale e che contiene le sue relazioni

funzionali; un modello analitico è un insieme di equazioni attraverso cui è possibile

caratterizzare un sistema. I primi sono estremamente potenti nel fornire dati statistici ad un

alto livello di dettaglio, ma sono indispensabili modelli minuziosi e un numero significativo

di esperimenti per ottenere risultati realistici, e questo a sua volta aumenta il tempo

necessario per la simulazione. D’altro canto anche i modelli analitici, che sono stati

utilizzati con successo da decenni per la valutazione delle caratteristiche non funzionali dei

sistemi informatici, presentano elevate limitazioni a causa delle forti ipotesi semplificative

sulle quali si fondano e che rendono i risultati dell’analisi poco attendibili; infatti la natura

altamente dinamica della WSN richiede la definizione di modelli complessi che sono

difficili da realizzare, ma soprattutto difficili da riutilizzare in contesti differenti da quelli

per i quali sono stati pensati, richiedendo così un elevato costo di sviluppo.

Per superare i limiti sopra esposti, in [9] è stato concepito un approccio ibrido per la stima

degli attributi della dependability che combina la flessibilità di un modello simulativo e il

rigore di un modello analitico, così da ottenere un modello multi-formalismo e attraverso

cui fornire le semantiche necessarie per l’implementazione di un modello dettagliato e

generale, capace di una descrizione eterogenea della realtà.

Il seguente lavoro di tesi è finalizzato, appunto, a concretizzare tale approccio in uno

strumento web-based di supporto alla progettazione di WSN, attraverso il quale il



47

modellista possa porsi ad un livello di astrazione più alto, lavorando nel proprio dominio

applicativo, e che renda la modellazione stessa più flessibile ed i modelli prodotti generali e

facilmente particolarizzabili. L’idea si fonda sulla costruzione di un modello versatile e

rappresentativo di un’ampia gamma di sistemi da un lato, e sulla possibilità di specializzarlo

attraverso l’uso di un tool di generazione automatica [15], così da ottenere un modello

finale per la simulazione del particolare sistema, senza snaturare la generalità del modello

iniziale e senza apportarne modifiche dirette. Il tutto in un ambiente di sviluppo che

garantisca:

• immediatezza di accesso;

• estensibilità;

• manutenibilità;

• carico di lavoro server-side.



48

Capitolo 3

Sviluppo di nuove soluzioni per il design di WSN: un approccio Multi-Formalismo

Come sempre più spesso accade, l’unica soluzione accettabile per poter modellare i sistemi

reali caratterizzati dalle complesse proprietà strutturali e dinamiche relazionali va ricercata

in tecniche modulari o composizionali in cui modelli eterogenei sono integrati allo scopo di

fornire una visione olistica dell’intero sistema. Una possibile strada per affrontare il

problema consiste nell’adottare tecniche di modellazione multi-formalismo, il cui obiettivo

è di supportare la rappresentazione di sistemi complessi combinando diversi linguaggi e

tecniche di analisi.

Un modello multi-formalismo è un modello costituito da parti, ciascuna delle quali modella

un particolare componente o aspetto del sistema che si intende modellare, utilizzando il

formalismo più adatto allo scopo. I diversi sotto-modelli contribuiscono alla composizione

del modello complessivo che viene pertanto risolto coinvolgendo diverse tecniche e

strumenti di analisi. Un siffatto modello consente una valutazione olistica di attributi di

dependability (per esempio, disponibilità o sicurezza), relativi a modi di guasto definiti a

livello di sistema complessivo, che altrimenti andrebbero valutati attraverso l’analisi di

modelli isolati, con la conseguenza di dover effettuare ipotesi poco realistiche. Questo tipo

di definizione gerarchica dei modelli consente di affrontare l’analisi di un sistema

complesso secondo opportune metodologie. Per esempio è possibile modellare un sistema

definendo un livello che descriva il comportamento dei diversi sotto-sistemi, uno che



49

descriva l’interazione tra i sotto-sistemi mediante una rete e un livello che modelli la rete di

comunicazione. Ancora, è possibile sviluppare dei modelli che consentano di considerare

l’impatto della manutenzione sull’affidabilità e sicurezza del sistema, sviluppando

separatamente e poi componendo un modello di guasto ed uno di riparazione.

Evidentemente, l’analisi di modelli complessi implica la disponibilità di opportune tecniche

di soluzione e di strumenti automatici che supportino anche lo sviluppo del modello. Se è

pensabile, infatti, di sviluppare e risolvere separatamente, utilizzando i tool disponibili,

modelli molto semplici, realizzando “a mano” l’operatore di composizione, ovvero

prelevando il risultato ottenuto dall’analisi del primo modello e immettendolo

opportunamente nel secondo, non è possibile procedere in questo modo nei casi in cui gli

operatori realizzino funzioni complesse, ad esempio nel caso in cui forniscano informazioni

circa l'evoluzione di simulazioni in corso.

In questo capitolo verrà presentato un approccio per la composizione di un particolare

modello multi-formalismo per WSN basato sull’interoperabilità di due classi di modelli,

simulativi e analitici, proposto in [9]; seguirà un’esposizione degli strumenti realizzati a

supporto del suo sviluppo e della sua risoluzione, frutto dell’attività di ricerca del

laboratorio Mobilab della Facoltà di Ingegneria Informatica dell’Università Federico II di

Napoli.

3.1 Descrizione dell’Approccio

Come già anticipato, la potenza di questo nuovo approccio risiede nell’uso combinato di

modelli comportamentali e modelli analitici parametrici di fallimento per effettuare una

valutazione olistica e realistica delle proprietà non-funzionali di una rete di sensori wireless,

quali consumo energetico, sopravvivenza della rete e affidabilità.

Il diagramma in figura 3.1 mostra le cinque fasi salienti dell’approccio:

1. Inizialmente è indispensabile configurare la rete in termini di quelle che sono le

caratteristiche strutturali della particolare rete da analizzare, ovvero il numero e il

tipo di nodi, la topologia della rete, il carico di lavoro, il tipo di chip radio installato



50

sui nodi, l’algoritmo di routing adottato, la tecnologia delle batterie e del sensing

hardware adottati su ogni nodo; inoltre l’utente fornisce anche un set di metriche da

valutare, come per esempio disponibilità, performance, etc. Tutto ciò allo scopo di

performare i diversi esperimenti che serviranno poi a raccogliere le informazioni

necessarie a discriminare i parametri dei modelli di fallimento.

2. Durante questa fase viene mandato in esecuzione il particolare tool di simulazione

adottato (uno dei tanti analizzati nel capitolo precedente) il quale fornisce le stime

necessarie alla specializzazione dei parametri del modello analitico.

3. Alcuni dei parametri che vanno specializzati sono dinamici e variano al mutare delle

condizioni di funzionamento della rete, come il numero dei nodi guasti/isolati o il

rate di trasmissione di ogni nodo: se ad esempio un nodo X smette di funzionare

perché ha esaurito la sua energia, questo si ripercuote sull’albero di routing che va

conseguentemente aggiornato; ma ciò si riflette indirettamente anche su una diversa

velocità con cui si carica la batteria degli altri nodi, e quindi, sul di vita tempo e

dell’intera rete. Poiché questi parametri andrebbero ricalcolati coerentemente con le

nuove condizioni di lavoro, per supervisionare l’evoluzione del modello analitico

l’approccio prevede l’ausilio di un componente aggiuntivo, un motore esterno, che

ha il compito di disaccoppiare la generazione dei modelli analitici dal problema

della gestione dei cambiamenti della rete. Non solo, ma è essenziale per mantenere

la semplicità, la generabilità e riusabilità dei modelli. Durante questa fase quindi il

Model Generator produce modelli analitici partendo da una predefinita libreria di

template modello, e il numero e il tipo di modelli da generare dipendono dagli input

dell’utente. Un altro aspetto legato a queste operazioni è l’altro punto importante

che l’approccio vuole concretare e cioè ridurre lo sforzo di modellazione a carico dei

progettisti attraverso l’automatizzazione della creazione dei modelli analitici.

4. Questo passo riguarda la simulazione del modello analitico generato. Risulta chiaro

come il funzionamento di un singolo nodo modifichi il comportamento dell’intera

rete in modi inimmaginabili, e viceversa differenti scelte da parte dell’utente (come



51

ad esempio l’algoritmo di routing) influenzino il comportamento di ogni singolo

nodo. Per cercare di dominare questa complessità, utilizziamo modelli parametrici e

riusabili, i quali sono autonomi e capaci di adattarsi ai cambiamenti indotti da altri

modelli. Infine, durante la simulazione, vengono valutate le metriche scelte e i

risultati vengono proposti all’utente.

5. A questo punto, in dipendenza dai risultati ottenuti, l’utente può decidere se

necessario di rivedere le proprie scelte e di riprogettare il sistema.

Figura 3.1: Diagramma del nuovo approccio per la modellazione e la simulazione di Wsn

L’approccio appena descritto consente di anticipare le scelte progettuali, valutando

caratteristiche proprietà di una rete di sensori wireless in condizioni di guasto e in diversi

scenari di funzionamento, inoltre adottato in reti già distribuite, è di supporto nella

programmazione di interventi di manutenzione in seguito all’azione previsionale di un

potenziale degradamento delle stesse.



52

3.2 Il tool Failure Model WSN Generator

Il tool Failure Model WSN Generator descritto in [15] non è altro che la concretizzazione

del nuovo approccio alla modellazione esposto nel paragrafo precedente: esso consiste in

un’applicazione desktop scritta in Java con GUI Swing, progettata a partire da un reverse-

engineering del tool di simulazione Möbius, e in grado di generare automaticamente i

modelli a partire da direttive di generazione e librerie fornite dal modellista. Queste ultime

devono fornire i modelli di base per una descrizione generale e vanno poi performati sul

particolare sistema oggetto di studio.

Figura 3.2: Il nuovo approccio alla modellazione e simulazione utilizzato da Failure Model WSN Generator

Attraverso l’interfaccia grafica, l’utente inserisce il path in cui si trovano i file contenenti le

informazioni riguardanti la particolare topologia da usare, seleziona il numero di nodi che

formano la rete di cui si vuole valutare il comportamento, specifica il tempo di simulazione,

infine immette il percorso in cui verranno generati i file del modello di fallimento. A questo

punto cliccando il tasto Generate, il tool è in grado di ricavare dalla topologia, le

descrizioni xml dei modelli SAN (Stochastic Activity Networks), che verranno date in

ingresso al simulatore Möbius per la compilazione dei file. Il codice C++ ottenuto dai

modelli viene linkato alle librerie Möbius che incapsulano comportamenti della simulazione



53

che prescindono dai particolari modelli su cui si vuole effettuare la simulazione stessa, e,

eventualmente, librerie definite dal modellista, producendo l’eseguibile per la simulazione

del modello generato. L’avanzamento dell’elaborazione viene infine comunicato all’utente

attraverso una serie di messaggi inviati ad una JTextArea della GUI.

3.3 Möbius

Nel tempo l’uso di modelli nel settore dell’analisi di sistemi critici per imitarne il

comportamento ed esaminarne prestazioni e affidabilità prima della produzione finale è

divenuto sempre più frequente. Numerosi sono gli esempi di strumenti realizzati ad hoc per

definire e risolvere i modelli analitici, come, ad esempio, i tool UltraSAN, HiQPN,

DEPEND, i quali, attraverso una semplice interfaccia, ne facilitano la costruzione. Questa

semplicità però limita il numero di formalismi supportati da ogni tool che risulta per questo

inefficace nella modellazione di sistemi complessi che avrebbero invece bisogno di

modellare ogni componente con il formalismo più appropriato. E’ in questo scenario che

viene sviluppato il software Möbius, concepito per creare un ambiente di modellazione

estensibile che permette di specificare il modello utilizzando una varietà di formalismi di

modellazione. Möbius è uno dei maggiori progetti di ricerca del Performability Engineering

Research Group (PERFORM) presso il Center for Reliable and High-performance

Computing dell'Università dell'Illinois ad Urbana-Champaign (Il-USA). Il progetto è

supportato da vari enti governativi americani e dal Motorola Center for High-Availability

System Validation. Nasce da un precedente tool del medesimo gruppo di ricerca, Ultra-

SAN, con l'obiettivo di sviluppare un framework di modellazione object-oriented e

formalism-independent per la performance-dependability evaluation.

Il tool è costituito da due componenti principali (Figura 3.3):

1. l’interfaccia grafica e il simulation manager, entrambi implementati in Java;

2. il core del simulatore, il simulation engine, realizzato in C++.

Questa divisione è spiegata dal fatto che mentre da un lato Java permette una buona

gestione degli ambienti visuali ed un'ottima portabilità degli stessi, dall’altro invece, il C++



54

risulta essere molto più performante ma meno portabile e meno adatto alla grafica.

Figura 3.3: architettura del simulatore Möbius.

Lo strumento lavora a step e durante ogni fase l'interfaccia grafica fornisce all'utente una

modalità user-friendly per la definizione dei modelli, dei vari parametri e la presentazione

dei risultati. Segue una breve descrizione delle varie fasi:

• Dapprima occorre definire uno o più modelli atomici attraverso un editor grafico, si

tratta delle unità fondamentali che possono essere caratterizzate anche da

formalismi differenti. Al termine, per ognuno di essi, viene generata e compilata una

classe C++, estensione della classe contenuta nella libreria del formalismo adottato;

l'oggetto risultante contiene due liste, una di state variables (rappresentano parti

dello stato del modello di cui sono componenti basilari), l'altra di actions (innescano

i cambiamenti dei valori delle variabili di stato con conseguenti transizioni di stato

del sistema complessivo modellato).

• La creazione di un modello composto è invece opzionale e avviene con un

approccio gerarchico, utilizzando i submodel definiti precedentemente. Il suo

salvataggio porta alla generazione e compilazione di un'ulteriore classe C++, erede

della superclasse propria del formalismo di composizione, contenente due o più



55

istanze di modelli atomici e le informazioni sullo sharing tra le loro variabili di

stato.

• Indispensabile per la valutazione delle misure di performance del sistema è la

definizione delle performance variables, attraverso il preposto editor, all’interno del

modello di reward. Il salvataggio di tale modello comporta la generazione e la

compilazione di una classe C++ con referenze al modello composto e/o ai submodel

e informazioni circa le variabili.

• Affinché il modello sia risolvibile è necessario infine fissare per ognuna delle global

variables (che vengono usate per parametrizzare le caratteristiche del modello e solo

dopo che è stato assegnato loro uno specifico valore, è possibile applicare una delle

tecniche risolutive) precedentemente definite sui modelli atomico e/o composto, uno

specifico valore. Tale assegnazione determina la creazione di un set di experiments

che insieme vanno a formare lo study, una struttura che consente di esaminare

l’effetto della variazione di queste variabili sulle performance del sistema oggetto di

analisi. Alla fine di questa fase viene generata e compilata un'altra classe che

incapsula i modelli di cui sopra.

• Una volta definita la tecnica di risoluzione analitica/simulazione più adatta alla

classe del problema trattato, il tool provvede alla fase di linking dei file oggetto con

le librerie dei formalismi, dell’interfaccia funzionale (AFI), che consente

l’interazione tra i vari formalismi utilizzati nella composizione del modello e il

solver, e del simulatore/risolutore analitico selezionato. Solo a questo punto il

simulation engine simula il modello, colleziona le osservazioni e le invia al Java

manager che si occupa di calcolare le statistiche sulle variabili di reward definite

nell’omonimo modello (tale argomento verrà approfondito nella sezione

successiva).

Ogni formalismo supportato da Möbius per la costruzione di un modello è caratterizzato da

una precisa tipologia di file xml prodotti [15]:

• nella cartella principale del progetto è presente la subdirectory Atomic che contiene



56

a sua volta tante sottocartelle quanti sono i modelli atomici definiti per il progetto,

ogni sottocartella ha il nome del modello atomico così come definito nel project file.

Per la costruzione del modello, Möbius, mette a disposizione vari tipi di formalismi

come buckets and balls, PEPA, fault trees, SAN ed è data la possibilità di definire

nuovi formalismi di modellazione attraverso estensioni del tool. In ogni cartella col

nome del modello atomico, è presente il file xml NOMEMODELLOSAN.san,

insieme a un file cpp, un headerfile e un makefile ottenuti dalla traduzione del

modello in codice C++ e alla sua compilazione effettuata da Möbius per la

generazione dell’eseguibile per la risoluzione del modello stesso.

• I file xml dei modelli composti sono ubicati nella subdirectory Composed, nella

cartella principale del progetto. Ogni modello composed ha la propria cartella, col

medesimo nome del modello, contenente il file NOMEMODELLO.cmp, oltre ai file

ottenuti dalla traduzione del modello in codice C++ e il makefile per la

compilazione. Il file NOMEMODELLO.cmp contiene informazioni sui sottomodelli

di cui il modello composto è costituito, sulle variabili condivise ossia i place che i

modelli mettono in comune, e sugli archi che congiungono i modelli (edge).

Esistono essenzialmente due formalismi per i modelli composed, corrispondenti alle

due operazioni per la composizione di modelli previste da Möbius: all’operazione

di join corrisponde il formalismo ‘graph’ mentre all’operazione di ‘replicate’ il

formalismo rep\join.

• I file dei modelli di reward sono ubicati ognuno in una cartella col medesimo nome

del modello a sua volta posizionata nella cartella Reward, nella directory principale

del modello. E’ presente un file xml NOMEMODELLO.pvm e i file ottenuti da

quest’ultimo traducendo il modello in codice C++ e il makefile per la compilazione

del codice.

• I file dei modeli di study sono salvati nella cartella Study, situata nella main

directory del progetto.Ogni singolo modello di study ha la propria cartella chiamata

col nome del modello stesso. Ripetiamo che uno study dà la possibilità al modellista



57

di esaminare il comportamento del sistema al variare di parametri definiti come

variabili globali nei modelli atomici e composti. Tali parametri assumono uno

specifico valore solo quando, attraverso uno study, si definiscono uno o più

esperimenti. Un esperimento rappresenta così una tupla di valori dei parametri, per i

quali il modello può essere risolto. Möbius supporta due tipi di formalismi per la

definizione di study: range study, che viene salvato in un file

NOMEMODELLO.rsd, e set study salvato in NOMEMODELLO.ssd, oltre questa

tipologia di file saranno ovviamente presenti i file prodotti dalla traduzione del

modello in codice C++ e il makefile per la compilazione. La differenza tra i due

formalismi di study sta nel fatto che il primo permette al modellista di specificare

per i parametri valori fissi o un range di valori, dopodiché Möbius genererà

automaticamente gli esperimenti come il prodotto cartesiano di tutti i valori che

possono assumere le variabili, nel secondo il modellista specifica esplicitamente

tutti i valori dei parametri per ogni singolo esperimento.

• I solver sono situati nella directory $PROJECTROOT\NOMEPROGETTO\Study\

\NOMEMODELLO\ dove NOMEMODELLO sta a indicare il nome del singolo

solver. Möbius fornisce due tipi di solvers per ottenere soluzioni sulle misure di

interesse: simulazione e risoluzione numerica. Concentrandoci sulla simulazione,

questa permette, dopo la scelta dello study da simulare, di settare diverse

impostazione come il generatore di numeri pseudocasuali usato, il seme per la

generazione casuale, le macchine da usare per una simulazione distribuita, il numero

di processori impegnati etc…

3.3.1 Il Simulation Engine ed il Simulation Manager

Il simulation engine e il Java manager usano le standard BSD (Berkley Software

Distribution) sockets per scambiarsi le osservazioni elaborate, i dati relativi alla

registrazione di un processo manager e gli stessi comandi inviati da questo per gestire il

termine della simulazione. In realtà la comunicazione è mediata da un processo child del



58

simulation engine process il quale ha il compito di intercettare i comandi mandati dal

manager e di tradurli in segnali POSIX (Portable Operating System Interface) da inviare al

parent process. In particolare interpreta i comandi di ‘finish’ e ‘quit’ inviati dal manager e li

traduce rispettivamente nei segnali SIGINT , per indicare che la simulazione deve riportare

il set corrente dei risultati al manager e poi terminare, e SIGQUIT, per terminarla

immediatamente. Questa mediazione serve a facilitare la comunicazione di tipo asincrona

tra i due componenti, ma soprattutto ad evitare che il parent process impieghi, a discapito

della esecuzione delle osservazioni, cicli di cpu per monitorare la rete in attesa di ricevere

segnali dal manager.

Al simulation client viene passato come argomento dalla linea di comando, il port su cui si

pone in ascolto il simulation manager; dopo l’istanziazione del modello il child process

inizia una transazione con quest’ultimo allo scopo di effettuarne la registrazione presso il

parent: in questo modo il manager potrà identificare il port che il client usa per ricevere i

comandi visti sopra e verificare che la comunicazione sia possibile. Se si verificano degli

intoppi durante questa fase, allora il client termina e la transazione fallisce.

In aggiunta ai due comandi sopra menzionati, il child process accetta anche un ulteriore

comando di ‘ping’ al quale risponde direttamente, che può essere inviato dall’utente per

assicurarsi che il client stia eseguendo la simulazione; inoltre, sempre allo scopo di evitare

di sottrarre inutilmente cicli del processore all’elaborazione delle osservazioni, esso usa la

funzione ‘select’ di POSIX per entrare in uno stato ‘sleep’ mentre aspetta le istruzioni dal

manager.

Il reporting dei batch osservati al manager, viene fatto direttamente dal parent simulation

engine, eliminando il significativo numero di messaggi che sarebbe necessario scambiare

per la comunicazione tra i due processi padre-figlio. Questo onere aggiuntivo a carico del

parent process sembrerebbe apportare un ulteriore ritardo alla creazione delle osservazioni,

ma così non è poichè, per fortuna, molti sistemi operativi forniscono funzioni di rete per la

consegna quasi istantanea dei piccoli pacchetti di dati usati dal simulatore; questo grazie al

meccanismo di buffering del lower layers del protocollo di livello trasporto adottato, che



59

consente così di utilizzare solo una bassissima percentuale del tempo del processore ai fini

delle comunicazioni su rete.

L’intera gestione della simulazione è condotta dalle classi del Java manager: la sua

architettura può essere organizzata in tre componenti principali, il management simulation

clients, il data collection, e lo user interface.

• Il management simulation clients: la gestione del simulation clients avviene

attraverso una serie di thread che possono essere eseguiti in modo indipendente;

questo è importante dato essi impiegano gran parte del tempo ad attendere che si

verifichino determinate condizioni, come la terminazione di un particolare processo

oppure la ricezione dei dati per calcolare le statistiche sulle variabili di reward.

Evitare anche in questo caso di sprecare cicli del processore è motivato dal fatto che

il simulation manager è progettato per girare in parallelo sullo stesso sistema del

simulation client, del quale non si vogliono compromettere le performance. Per ogni

processore presente sulla macchina, che sia stato selezionato in caso di simulazione

distribuita (ma anche in caso di singolo processore è lo sttesso), viene creato il

relativo thread incaricato di gestirne le operazioni: esso ha il compito di individuare

un esperimento tra quelli attivati, e avviare la sua esecuzione sul simulation client.

Quando l’esecuzione termina, il thread è pronto a selezionare un nuovo esperimento

e a ripetere tutte le operazioni necessarie. La classe responsabile per questo thread è

la ProcessorManager, la quale interagisce quasi esclusivamente con gli oggetti della

classe ExperimentObject, che rappresentano ognuno, uno degli esperimenti definiti

sul modello, e che forniscono tutti i metodi necessari per calcolare, invocando una

particolare classe di oggetti, i risultati statistici sulle variabili di reward. Il

ProcessorManager, inoltre, gestisce un task per l’invio dei comandi di controllo da

inviare al client simulation engine, attraverso una serie di metodi per creare socket e

connettersi al child process del client.

• Il data collection: anche la raccolta dei dati trasmessi dal simulation engine è gestita

attraverso un gruppo di thread, i quali sono controllati da un NetworkThread (in



60

realtà ad esso corrisponde la classe Simulator del Möbius Project, ma in questa sede

viene così chiamato, perchè inteso nel termine generale di gestore della

comunicazione di rete) che ha il compito di istanziarli. Viene creato un

NetworkReader (un oggetto della classe StreamReader) per ogni ProcessorManager

istanziato, ed è questo che gli passa la socket creata in fase di connessione con il

client, indispensabile per leggere i dati dalla rete che verranno in seguito trasferiti in

un buffer locale. Una volta terminata questa operazione, la connessione è chiusa e i

dati vengono formattati e posizionati in una matrice di double che verrà usata dagli

esperimenti. La politica del simulation manager è orientata al riuso degli oggetti

istanziati, così da prevenire un uso non necessario del processore per istanziarne di

nuovi. Allo scopo vengono usate delle liste per tenere traccia degli oggetti che

hanno espletato i propri compiti e sono pertanto inattivi: un esempio sono gli stessi

network reader che, terminato un ciclo di lettura, se necessario, vengono

nuovamente riutilizzati, passando loro dei nuovi stream. Anche per gli oggetti

contenenti i dati formattati vale la stessa cosa: viene istanziato un nuovo oggetto

solo se nel frattempo che un esperimento sta ancora utilizzando i dati

precedentemente trasmessi, arrriva un nuovo pacchetto dal simulation client che

deve essere trasferito.

Per il calcolo delle variabili di reward viene usato un thread separato, il

CalculationThread, che è associato al particolare ExperimentObject e che coordina

un gruppo di oggetti (derivati da una classe base) che hanno il compito di gestire i

diversi calcoli da fare sulle variabili, quali media, varianza, e stime di intervallo e di

distribuzione.

• Lo user interface: l’interfaccia grafica del simulatore di Möbius fornisce varie

opzioni di debugging, e la possibilità di visualizzare in tempo reale lo stato della

della simulazione e di controllarne l’avanzamento. Questo è possibile poiché i valori

mostrati relativi ai singoli esperimenti, vengono aggiornati contestualmente al

calcolo statistico effettuato dal relativo Calculation Object.



61

Figura 3.4: Data Flow del Simulation Manager

3.4 WebFAMOGEN

E’ uno strumento web-based per la simulazione di reti di sensori senza filo, nato dalla

neccessità di remotizzare il tool Failure Model WSN Generator, di cui mette a disposizione

gli strumenti in maniera semplice, rapida e con un carico computazionale esiguo da parte

dell'utente. Attraverso questo tool l’utente è in grado con un thin client di inserire o

disegnare lo scenario topologico da modellare, ottenere automaticamente un modello

analitico atto ad incentrarsi sulla dependability del sistema, scegliere le metriche da valutare

e scaricare il risultato ottenuto. Inoltre è in grado di ricavare dalla topologia come viene

propagata la comunicazione tra i vari nodi sensore attraverso un modello manuale, un

modello di tipo fixed radius e di altri modelli implementabili successivamente.

Le motivazioni del remoting vanno ricercate nei numerosi vantaggi che può offrire una

applicazione web-based rispetto a una desktop-based:

• L’aggiunta di nuovi modelli analitici si propaga in tempo reale ed è subito a

disposizione di ogni utente che accede alla web application;

• L’utente non ha bisogno di installare e configurare particolari software di modellazione

e di simulazione in ogni macchina che utilizza per lo sviluppo di WSN, e può accedere

all’applicazione ovunque e da ogni sistema dotato di un web browser;

• Tutto il codice gestito dalla web application non è ne visibile ne accessibile da parte

Network Thread

Network Reader

Vector-List dei Network Readers

Vector-List degli old Data Objects

Data Object

Vector-List dei nuovi Data Object

Calculation Thread

instaurazione connessione con il Simulation Client

Dati dal Simulation Client



62

dell’utente: tutto ciò a cui il modellista può accedere sono i dati di modellazione e

simulazione;

• Il calcolo computazionale delle simulazioni e della generazione di modelli analitici in

base alla topologia della rete, avviene sul server o potrebbe addirittura avvenire su un

sistema distribuito di server, in modo tale che il modellista possa utilizzare un normale

thin client con notevoli risparmi in ambito economico.

La natura web-based dell’applicazione, intrinsecamente multi-utente, ha reso necessaria la

gestione contemporanea di più utenti che si collegano al servizio, attraverso l’uso di un

accesso protetto con validazione delle credenziali per ogni sessione, ma soprattutto di un

ambiente personalizzato che viene creato eseguendo correttamente il primo accesso al web

server. Ogni modellista, progettista e sviluppatore di WSN, infatti, una volta autenticatosi è

in grado di accedere ai propri file contenenti le topologie, i modelli, e i risultati delle proprie

simulazioni archiviati in un database sul server. Tutto ciò grazie ad una semplice interfaccia

grafica che consente di navigare tra le principali funzionalità messe a disposizione

dell’utente, tra le quali, appunto, quella di fornire gli input necessari per caratterizzare il

sistema in esame e per configurare lo scenario da sperimentare.

Per il corretto funzionamento dell'applicazione è necessario specificare il numero di nodi da

modellare, il tempo di simulazione da valutare, una serie di parametri che andranno a

discriminare il particolare sistema da simulare e la topologia della rete. Quest’ultima può

essere fornita attraverso un upload del file compresso, oppure selezionata dal database

remoto nel quale sia stata precedentemente salvata dall’utente. Suddetta operazione può

essere effettuata in seguito a un upload oppure dopo essere stata disegnata on-line attraverso

le funzionalità offerte dall’applicazione stessa. Essa infatti mette a disposizione una

schermata simile ad un software di disegno, dove è possibile disporre i nodi con un drag

and drop su un piano bidimensionale e modificare, per ogni nodo, le coordinate, il tipo di

radio, il tipo di tecnologia della batteria e l'applicazione installata. Nel tracciare lo scenario

topologico, infine, l'utente può selezionare per la rete di nodi il modello di propagazione del

segnale, il quale differisce dall'ambiente scelto.



63

La schermata principale si presenta sia graficamente sia in termini di funzionalità simile al

tool Failure Model WSN Generator descritto nel paragrafo 3.2, ovvero con delle aree

testuali che rappresentano i log dell'applicazione e dei messaggi inviati alla console di

sistema del server, e con i pulsanti che rendono possibile la generazione, la compilazione o

la simulazione del modello.

Una volta generato ed eventualmente compilato il modello, l'utente può scegliere se

scaricare i file da sottoporre al simulatore Möbius, così da valutare sul proprio computer i

risultati dell’elaborazione, oppure decidere di avviare la simulazione direttamente sul

server. In quest’ultimo caso è possibile attenderne la fine e visualizzarne i risultati

direttamente nella web-application, altrimenti sarà l’applicazione ad avvisare

opportunamente l’utente attraverso una mail. In ogni caso i dati saranno archiviati nel

database remoto e resi fruibili per le successive consultazioni. Il simulatore prende in input

il modello e i parametri specificati nel file dello study, linka le librerie del modello con

quelle del simulatore stesso, e fa partire l’eseguibile. Al termine della simulazione viene

offerta poi la possibilità di esportare i dati ottenuti in un foglio di calcolo .csv oppure .xsl.

In effetti, seppur previste in fase di progettazione, alcune delle modalità di funzionamento

elencate non sono state ancora implementate. L’utente allo stato attuale non è ancora in

grado di:

• gestire in alcun modo gli scenari topologici creati durante la fase di generazione del

modello: può solo disegnare la topologia ed eventualmente esportarla o effettuarne

l’upload sul sistema per fornirlo all’applicazione;

• caratterizzare più di uno scenario di simulazione per volta: il numero di esperimenti

da specializzare è vincolato dal numero limitato (1 soltanto) di valori che è possibile

specificare per il sottoinsieme di parametri descritti nel file dello study, che è

possibile modificare attraverso l’interfaccia grafica dell’applicazione;

• avviare la simulazione del modello generato e gestirne attraverso la visualizzazione

e l’esportazione, i risultati.



64

Capitolo 4

Progettazione ed implementazione dello Strumento di Simulazione

Questo capitolo si pone l’obiettivo di mostrare le tecnologie e le tecniche usate per

implementare il tool. Seguirà una breve introduzione sul contesto nel quale si inserisce il

lavoro di tesi svolto, nella quale verranno analizzati i requisiti funzionali e non che

l’applicazione deve soddisfare; saranno esposti i principali scenari d’uso allo scopo di

osservare il comportamento del tool in base alle richieste dell’utente. Infine sarà esposta

l’architettura della web-application così da individuare e illustrate le principali modifiche

che l’hanno investita, e la struttura del database sul quale essa si appoggia.

4.1 Analisi dei Requisiti

Come descritto in 3.4 questa applicazione nasce con lo scopo di progettare, modellare e

simulare reti di sensori senza filo. Oggetto del presente lavoro di tesi è stato quello di

estenderne le già numerose possibilità di funzionamento.

Avendo ora una visione d’insieme del progetto è possibile fissare quelli che sono stati i

punti focali del seguente lavoro di tesi ovvero i requisiti non ancora implementati nel tool.

E’ stato innanzitutto necessario creare un database remoto che tenesse traccia degli utenti

connessi all’applicazione e rendesse possibile da parte di ognuno di essi, ove richiesto,

l’archiviazione dei file delle topologie disegnate. Infatti se in origine era possibile solo

esportare e salvare sulla propria periferica il file della topologia della rete, ora l’utente ha a



65

disposizione un vero e proprio strumento di gestione degli scenari topologici: una schermata

grafica consente di effettuarne il salvataggio, l’upload, il download e la cancellazione.

Il database ha inoltre il compito di memorizzare, contestualmente all’esecuzione di una

simulazione, i suoi risultati così da renderli fruibili anche durante i successivi accessi.

Notevoli cambiamenti relativi alla generazione del modello sono stati poi apportati

all’applicazione al fine di consentire all’utente di performare anche più esperimenti per ogni

simulazione, così da poter valutare la risposta del sistema in diversi contesti di

funzionamento. E’ ora possibile specificare oltre al numero di nodi e al tempo di

simulazione:

• Il/i tipo/i di sistema/i operativo/i a scelta tra TinyOS e/o Mantis.

• Il/i protocollo/i di routing a scelta tra “MultiHop”, “ReliableMultiHop”,

“Gossiping”, “Floody”, “Random” (in parte descritti in 1.5.3).

• I parametri della batteria quali capacità e voltaggio.

• Il Radio Platform adottato (allo stato attuale è possibile selezionare solo il tipo

CC2420, ma l’implementazione del codice è stata realizzata considerando la

possibilità di aggiungere nuove tipologie).

• Il/i Sensor Board utilizzato/i (per il momento è presente solo il tipo XBOW, ma

come per il radio platform, è stata prevista la possibilità di aggiungerne di nuovi).

• E’ possibile inoltre: abilitare o meno l’occorrenza di guasti software e/o hardware;

usare tecniche di Data Aggregation, specificando nel qual caso, il tempo di

aggregazione desiderato; indicare il Duty Cycle e la dimensione dei pacchetti

trasmessi dai sensori; fare l’upload dei file .txt contenenti le informazioni relative

latency e faults injection; e infine selezionare il file contenete la topologia di rete dal

db remoto o effettuarne l’upload.

Come detto, tutti i dati inseriti serviranno per discriminare i vari scenari di simulazione, allo

scopo di tenere traccia delle diverse condizioni di funzionamento della rete, il nome di ogni

esperimento viene generato come composizione dei vari parametri specificati, ad esempio:

“Tiny_AggrTime:30sec_DutyCycles:1sec_PacketSize:12Bytes_RoutingType:MultiHop_SW



66

_HW”, indica un esperimento per il quale sia indicato TinyOS come sistema operativo

adottato sui sensori, MultiHop come tipologia di routing utilizzata, un DutyCycles di 1

secondo, un PacketSize di 12 byte, in cui sia utilizzata una tecnica di data aggregation con

un AggrTime di 30 secondi; e per il quale siano stati abilitati sia i guasti hardware che quelli

software.

A questo punto sono stati forniti gli tutti gli input necessari affinché il modello possa essere

generato (e/o compilato) e/o compilato e simulato. In quest’ultimo caso una volta terminata

l’elaborazione una finestra visualizzerà un output creato dall’applicazione comprensibile

per l’utente. Esso include, per ognuno degli esperimenti, il tempo di simulazione, il suo

risultato finale (se converge o meno) e il numero di osservazioni effettuate (che può essere

anche inferiore a quello specificato nel file di configurazione della simulazione nel caso la

convergenza dell’esperimento sia stata raggiunta prima di esaminare tutti i batch). Inoltre

cliccando sullo specifico esperimento sarà possibile visualizzare i valori delle variabili di

reward del modello, relativi a tutte le varie osservazioni eseguite. Questi dati vengono

anche forniti in un file formattato come un comma-separated-value file (.csv) contenente,

tra l’altro, tutti i parametri di configurazione della simulazione (come il massimo numero di

osservazioni da eseguire oppure il valore delle variabili globali del modello), e progettato

per essere esportato in modo semplice e usato all’interno di tool di analisi come

Microsoft’s Excel oppure OpenOffice.org’s Calc..

Ad ogni modo, sia che il modello venga solo generato, sia che esso sia anche simulato,

viene offerta la possibilità all’utente di esportare un in un formato zip tutti i file prodotti.

Nell’ultima fase dello sviluppo sono state affrontate le problematiche legate

all’implementazione della simulazione del modello analitico generato e della

visualizzazione e valutazione dei risultati ottenuti. Queste operazioni hanno richiesto

maggiori sforzi e attenzione poiché per la loro realizzazione si è reso necessario un

approccio di reverse engineering sul complesso software Möbius (circa 182K di linee di

codice) per utilizzarne le classi, riadattandole al fine di ottenere nuove funzionalità non

previste dal famoso tool. Infatti, diversamente da quanto accade con il simulatore Möbius



67

(che fornisce i risultati statistici finali di un esperimento solo al termine della sua

esecuzione), la nostra applicazione è in grado di produrre i risultati parziali relativi alle

singole osservazioni così da fornire la possibilità, in future ulteriori estensioni, di plottarli al

fine di tracciarne un andamento nel tempo. In un primo momento è stato necessario

individuare le classi del software Möbius incaricate di comunicare con il simulatore e

interpretare i risultati inviati da esso su un bus ad eventi discreti (si veda 3.4). In seguito

queste sono state importate in un package all’interno del tool Failure Model WSN

Generator (usato dall’applicazione web per la generazione, la compilazione e la simulazione

del modello) denominato simulator. Infine, le modifiche apportate direttamente a queste

classi, sono state finalizzate alla realizzazione di quanto descritto sopra, ovvero intercettare

interpretare ed elaborare i dati inviati dal simulation engine di Möbius, e archiviare per ogni

esperimento e per ogni variabile di reward, tutte le statistiche calcolate.



68

4.2 Use Case Diagram

Dai requisiti sopra analizzati viene proposto il caso d’uso generale in Figura 4.1, di cui

verranno approfonditi solo i casi d’uso principali.

Figura 4.1: Use Case Diagram dell’applicazione



69

CASO D’USO: GENERAZIONE MODELLO

Attori: User.

Pre-condizioni:

1. Lo user effettua con successo la verifica delle sue credenziali.

Sequenza degli eventi:

1. Lo user sceglie di generare il modello.

2. Il sistema visualizza all’utente la schermata relativa alla generazione del

modello.

3. Lo user caratterizza lo scenario di simulazione immettendo i dati

necessari.

4. Lo user seleziona la topologia della rete WSN dal db remoto.

5. IF lo user non seleziona la topologia dal db remoto, l’utente carica sul

server il file .zip della topologia WSN.

6. Il sistema importa la topologia in una cartella personale dell'utente

7. Lo user non seleziona la compilazione del modello.

8. IF lo user sceglie anche la compilazione, il sistema genererà un modello

compilato.

9. Lo user chiede la generazione del modello.

10. Il sistema genera il modello e invia come download il file compresso del

modello all'utente.

CASO D’USO: SIMULAZIONE MODELLO

Attori: User.

Pre-condizioni:

1. Il sistema ha generato e compilato correttamente il modello.



70


1. Lo user richiede la simulazione del modello.

2. Il sistema inizia la simulazione.

3. Durante la simulazione il sistema archivia i risultati parziali relativi alle

osservazioni di ogni esperimento in un database sul server.

4.Terminata la simulazione, il sistema ne visualizza i risultati in una

schermata.

5. Lo user chiede di scaricare i risultati delle osservazioni.

6. Il sistema esporta i dati in un foglio di calcolo .csv e lo invia come

download all’utente.

7. IF lo user non chiede di scaricare i risultati delle osservazioni, lo user

chiede di scaricare il modello generato e compilato, e i risultati della

simulazione.

8. Il sistema invia come download il file compresso del modello compilato

contenente anche i risultati all'utente.

CASO D'USO: DISEGNA TOPOLOGIA

Attori: User.

Pre-condizioni:

1. Lo user effettua con successo la verifica delle sue credenziali.


1. Lo user sceglie di disegnare una topologia WSN.

2. Il sistema visualizza all'utente soltanto la parte di disegno topologia

3. Lo user chiede l'archiviazione della topologia, neldatabase sul server.

4. IF lo user non chiede l’archiviazione della topologia, lo user chiede di

esportare ifile contenenti la topologia creata.

5. Il sistema genera un file compresso contenente la topologia WSN e lo



71

invia all'utente.

4.3 Architettura della RIA

Per rendere il tool il più scalabile e modificabile possibile, si è deciso di strutturare il

software secondo il pattern MVC, meglio conosciuto come Model-View-Controller, esso si

basa sull’idea di separare i dati dalla rappresentazione poichè un forte accoppiamento tra

essi comporta che la modifica dell’uno, si rifletta automaticamente in un aggiornamento

dell’altro. Esso quindi prevede che il sistema software sia realizzato secondo un’architettura

“a livelli”, stabilendo il disaccopiamento fra dati e rappresentazione attraverso la

definizione dei tre elementi noti, appunto, come Model, View e Controlleri:

• Il Model è responsabile della gestione dei dati e del comportamento

dell’applicazione; esso coordina la “business logic” dell’applicazione, l’accesso ai

DBMS e tutte le parti critiche “nascoste” del sistema: si è scelto di racchiudere in

questo componente tutte le classi del progetto desktop-based

FailureModelGenerator, compreso il nuovo package “simulator” che incapsula la

logica della simulazione, e il simulatore Möbius.

• La View ha il compito di visualizzare i dati e presentarli all’utente: è l’insieme di

componenti grafici che compongono la pagina web, senza la logica di elaborazione

degli eventi: esso è costituito dai file dell’interfaccia grafica dell’applicazione web,

scritti utilizzando sia il linguaggio ZUML sia HTML;

• il Controller definisce il meccanismo mediante cui Model e View comunicano.

Realizza la connessione logica tra l’interazione dell’utente con l’interfaccia

applicativa e i servizi della business-logic nel back-end del sistema. Una qualsiasi

request verso quest’ultimo, viene acquisita dal controller che individua il gestore

della richiesta (request handler), poi una volta ottenuto il risultato dell’elaborazione,

passa alla view i dati per la presentazzione all’utente. Esso comprende le classi Java

che dialogano con i componenti della view e con le classi del model.



72

Figura 4.1: Architettura della Web Application

Il Flusso di esecuzione della RIA può essere descritto più chiaramente in questo modo:

quando un utente digita l’indirizzo nel proprio web browser, viene fatta una richiesta al web

server, se l’indirizzo è corretto, i tre componenti sopra descritti operano sinergicamente allo

scopo di interpretare e creare correttamente i contenuti della pagina che in seguito sarà

inviata al browser dell’utente. Questi, interagendo con i componenti della pagina, con click

sui componenti grafici o modificando il valore di alcuni campi di input, scatena degli

‘event’ che vengono opportunamente gestiti da ‘handler’ definiti nelle classi Java del

controller. Essi hanno il compito di implementare la logica di controllo dell’intera

applicazione, traducendo in azioni eseguite dal model, gli input utente nella view.

Vediamo alcuni esempi nel dettaglio:

1. Nel caso in cui il client chieda di effettuare una registrazione o un’autenticazione

presso il web server, oppure necessiti di gestire i propri file archiviati sul server, le

classi del model incaricate di gestire l’elaborazione, aprono una connessione con il

Logica della simulazione



73

database remoto e interagiscono con esso al fine di portare a termine le operazioni di

inserimento o di prelievo, richieste; a questo punto la connessione viene chiusa, i

contenuti della pagina aggiornati, e trasmessi nuovamete al web client.

2. Se l’utente avvia operazioni legate alla generazione, alla compilazione e alla

simulazione del modello, viene dapprima individuato l’handler relativo al

componente attraverso cui è stata richiesta l’elaborazione, il quale istanzia gli

oggetti e richiama e i metodi del tool FailureModelGenerator (del model) che

interagendo con il simulatore Möbius, espleta la funzionalità richiesta. In particolare

nel caso in cui l’evento rappresenti la richiesta di una simulazione, sarà necessario

da parte del desktop-based tool, instanziare gli oggetti delle classi del nuovo

package simulator che si occuperanno di avviarla, gestirne l’avanzamento

connettendosi con l’archivio dati remoto e aggiornandone i risultati, e terminarla.



74

4.4 L’archivio dati remoto

4.4.1 La scelta del database

MySQL è un Database management system (DBMS) composto da un client con interfaccia

a caratteri e da un server. Ambedue i componenti sono disponibili sia per sistemi operativi

UNIX che per il sistema operativo Windows. Dal 1996 supporta la maggior parte della

sintassi SQL (Structured Query Language) e si prevede che in futuro supporti

completamente lo standard ANSI. Possiede delle interfacce, dette driver, per diversi

linguaggi i programmazione quali ad esempio Java e per gli ambienti di sviluppo quali

Mono, che opera sotto UNIX, e .NET, che opera sotto Windows. Il codice di MySQL viene

sviluppato fin dal 1979 dalla ditta TcX ataconsult, che ora ha il nome di MySQL AB, ma

solo dal 1996 viene distribuita una versione che supporta il linguaggio SQL , sfruttando del

codice proveniente da un’altra applicazione: mSQL. Il codice di MySQL viene distribuito

dall’omonima società sia sotto licenza GNU-GPL, quindi è codice open source e quindi

free, sia sotto licenza commerciale. Una buona parte del codice che compone il client è

licenziato sotto GNU-GPL e quindi può essere usato per applicazioni commerciali. MySQL

svolge il lavoro di DBMS sulla piattaforma LAMP, una della più usate e installate in

internet per lo sviluppo di siti e di applicazioni web dinamiche.

La scelta è ricaduta su questa tecnologia grazie a tutta una serie di vantaggi che essa

offre[16]:

1. Scalabilità e flessibilità: MySQL è la soluzione più avanzata a livello di scalabilità,

grazie alla sua capacità di integrarsi con applicazioni le cui dimensioni non devono

superare pochi MB, fino ad enormi data warehouse contenenti terabyte di

informazioni. La flessibilità di piattaforma è una funzionalità chiave di MySQL, che

è in grado di supportare Linux, UNIX e Windows. Ovviamente, la natura open

source di MySQL consente inoltre una personalizzazione totale per chi desidera

aggiungere requisiti unici al server database.

2. Prestazioni elevate: l’eccezionale architettura storage-engine consente di configurare

il server di MySQL per applicazioni specifiche, ottenendo prestazioni finali



75

incredibili. Sia che l’applicazione sia un sistema di elaborazione transazionale ad

alta velocità o un sito web che gestisce miliardi di interrogazioni al giorno, MySQL

è in grado di soddisfare le aspettative di qualsiasi sistema a livello di prestazioni.

Grazie alle utility di caricamento dati ad alta velocità, le cache specializzate, gli

indici full text ed altri meccanismi di aumento delle prestazioni, MySQL offre gli

strumenti giusti per i moderni sistemi aziendali di importanza critica.

3. Alta disponibilità: l’assoluta affidabilità e la costante disponibilità sono i punti di

forza di MySQL e i clienti si affidano a MySQL per garantire l’operatività 24 ore su

24. MySQL offre una varietà di opzioni ad alta disponibilità, dalle configurazioni di

replicazione master/slave ad alta velocità, ai server cluster specializzati con failover

istantaneo, alle soluzioni ad alta disponibilità di terze parti per il server di database

MySQL.

4. Solido supporto delle transazioni: MySQL offre uno dei motori database

transazionali più potenti disponibili sul mercato. Le funzionalità includono il

supporto completo per transazioni ACID (Atomic, Consistent, Isolated, Durable),

lock a livello di riga, gestione delle transazioni distribuite e supporto per transazioni

multiversione in cui chi legge non blocca mai chi scrive e viceversa. La completa

integrità dei dati è garantita anche dall’integrità referenziale controllata dal server,

dai livelli di isolamento delle transazioni specializzati e dall’individuazione

istantanea dei deadlock.

5. Punti di forza per Web e data warehouse: MySQL è lo standard di fatto per i siti

web con volumi di traffico elevati, grazie al suo query engine ad alte prestazioni,

alla capacità di inserimento dei dati estremamente veloce e al supporto delle

funzioni web specializzate, come ad esempio le ricerche full text rapide. Questi

stessi punti di forza valgono anche per gli ambienti di data warehousing in cui

MySQL deve gestire terabyte di dati per singoli server o per architetture di scale-

out. Altre caratteristiche, come le tabelle in memoria principale, gli indici B-tree, gli

indici hash e le tabelle di archivio compresse, che riducono le necessità di



76

memorizzazione fino all’80%, rendono MySQL una soluzione unica, sia per le

applicazioni web, sia per le applicazioni di business intelligence.

6. Elevata protezione dei dati: la protezione dei dati aziendali rappresenta la priorità

numero uno dei responsabili dei database, quindi MySQL offre eccezionali

caratteristiche per la sicurezza, che garantiscono la totale protezione dei dati. Per ciò

che riguarda l’autenticazione del database, MySQL offre potenti meccanismi per

assicurare che soltanto gli utenti autorizzati possano accedere al server di database,

con la possibilità di bloccare gli utenti fino al livello della macchina client. Oltre a

ciò, il supporto SSH e SSL garantisce che le connessioni siano sicure. Un sistema

granulare di gestione dei privilegi permette agli utenti di vedere solo i dati per i

quali sono autorizzati, mentre le potenti funzioni di crittografia e decifratura dei dati

garantisce che i dati sensibili siano protetti e non possano essere visualizzati da

coloro che non sono autorizzati. Per finire, le utility di backup e ripristino fornite da

MySQL e da software di terze parti consentono di eseguire il backup fisico e logico

completo, così come il ripristino completo e point-in-time.

7. Sviluppo completo di applicazioni: uno dei motivi per cui MySQL è il database

open source più diffuso al mondo è che fornisce supporto completo per le esigenze

di sviluppo di tutte le applicazioni. All’interno del database è possibile trovare

supporto per stored procedure, trigger, funzioni, viste, cursori, standard SQL ANSI e

altro ancora. Per le applicazioni integrate sono disponibili librerie plug-in per

espandere l'utilizzo del database MySQL a pressoché tutte le applicazioni. MySQL

fornisce inoltre connettori e driver (ODBC, JDBC, ecc.) che consentono a tutti i tipi

di applicazioni di utilizzare MySQL quale server di gestione dei dati. Non importa

che si tratti di PHP, Perl, Java, Visual Basic o .NET: MySQL offre agli sviluppatori

di applicazioni tutto ciò di cui hanno bisogno per realizzare sistemi informativi

basati su database.

8. Facilità di gestione: i tempi necessari per iniziare a usare MySQL sono

incredibilmente ridotti; il tempo medio che trascorre dal download del software al



77

completamento dell’installazione è inferiore ai 15 minuti. Ciò vale per qualsiasi

piattaforma, sia essa Microsoft Windows, Linux, Macintosh o UNIX. Una volta

installato, funzionalità indipendenti come l’espansione automatica dello spazio, il

riavvio automatico e le modifiche di configurazione dinamiche facilitano il lavoro

degli amministratori di database. MySQL offre inoltre una suite completa di

strumenti di migrazione e gestione grafici, che consente ai DBA di gestire, risolvere

e controllare le operazioni di più server MySQL da una singola stazione di lavoro.

Sono inoltre disponibili molti strumenti software di terze parti per MySQL, per

gestire attività che vanno dalla progettazione dei dati e l’ETL, alla completa

amministrazione del database, alla gestione dei job, al monitoraggio delle

prestazioni.

9. La libertà dell'open source: molte aziende esitano ad adottare solo software open

source perché credono di non poter ricevere il tipo di supporto o di servizi

professionali offerti dal software di tipo proprietario, per garantire il successo delle

loro applicazioni di importanza chiave. Un altro aspetto riguarda la questione degli

indennizzi. Queste preoccupazioni possono essere ignorate grazie a MySQL, che

attraverso MySQL Enterprise offre indennizzi e supporto completo 24 ore su 24.

MySQL non è un progetto open source tipico, poiché tutto il software è di proprietà

di Oracle ed è supportato da Oracle; è quindi disponibile un modello di costi e

supporto in grado di offrire una combinazione unica di libertà open source e

software supportato.



78

4.4.2 Struttura di db_ Möbius

Figura 4.2: diagramma ER del database db_ Möbius

Il database MySQL db_Möbius viene creato al triplice scopo di tenere traccia degli utenti

che si collegano all’applicazione, archiviare tutte le topologie che essi utilizzano durante le

simulazioni dei modelli del caso di studio sulle WSN, rendendo più agevole l’operazione di

fornirle al generatore automatico, infine memorizzare i risultati ottenuti, così da potervi

accedere in qualunque momento.

Ora passiamo a dare una breve descrizione di ognuna delle tabelle che costituiscono il

database remoto.

La tabella users

Questa tabella viene utilizzata per memorizzare tutti gli utenti che si registrano per poter

usufruire delle funzionalità dell’applicazione. Ha una chiave primaria che è ‘username’



79

(questo perchè per scelte di progetto non è possibile che due utenti si logghino con lo stesso

username) e i due campi, ‘pwd’ ed ‘email’ per registrare, rispettivamente, la password e la

e-mail dell’utente.

La tabella topology

Questa tabella tiene traccia di tutte le topologie disegnate e in seguito archiviate da un

particolare utente oppure delle quali, questi, ha effettuato l’upload. Ha come chiave

primaria i campi ‘TopologyName’, che contiene il nome della topologia usata, e ‘Author’

che conterrà il riferimento alla chiave della tabella ‘user’, attraverso la quale risalire

all’utente che l’ha archiviata. La scelta è motivata dal fatto che non è possibile che due

diverse topologie di un utente presentino lo stesso nome; infatti esso deve fornire un’idea

immediata della tipologia di scenario che si andrà ad utilizzare. Il campo ‘File’ contiene

l’oggetto di tipo BLOB che rappresenta il file in formato zip della topologia; ‘date’, invece,

è di tipo TIMESTAMP e conterrà la data di archiviazione del file.

La tabella run

Questa tabella memorizza tutte le informazioni relative alle simulazioni effettuate da uno

specifico utente. Ha come chiave primaria il campo ‘ id_run’, di tipo INTEGER

AUTOINCREMENT, per identificare in modo univoco ogni simulazione. I campi ‘users’ e

‘ topology’, contengono i riferimenti relativi alla chiave della tabella topology, così da poter

risalire alla topologia utilizzata e all’utente che l’ha generata, che poi è lo stesso che ha

lanciato la simulazione . Il fatto che possano esistere più simulazioni che utilizzano la stessa

topologia è dovuto alla possibilità da parte dell’utente di poter modificare in qualsiasi

momento le caratteristiche del particolare scenario topologico: quindi può accadere che

venga eseguita una simulazione con una particolare topologia, che in seguito l’utente decida

di apportare dei cambiamenti al file e che riesegua la simulazione con i nuovi dati. I campi

‘start_time’ e ‘ProjectName’ contengono, rispettivamente la data di inizio della simulazione

e il nome del progetto mandato in esecuzione.



80

La tabella experiments

Questa tabella contiene tutte le informazioni relative agli esperimenti di una simulazione.

Ha come chiave primaria i campi ‘id_run’, che contiene il riferimento alla chiave della

tabella run e attraverso cui è possibile risalire alla particolare simulazione, e ‘id_exp’ che

invece contiene l’identificativo con cui il simulation engine di Möbius discrimina i vari

esperimenti. Altri campi sono:

- ‘batch’, per sapere quante osservazioni sono state eseguite alla fine di ogni esperimento;

- ‘node’, per risalire al numero di nodi della rete;

- ‘simulation_time’, per avere un’idea del tempo servito al simulatore per fornire i risultati

di un esperimento;

- ‘experiment_name’, contiene il nome dell’esperimento;

- ‘converged’, per conoscere l’esito dell’esperimento, ovvero se tutte le variabili di reward

sono rientrate nello specifico intervallo di confidenza.

La tabella reward

Questa tabella contiene le informazioni relative a tutte le variabili di reward definite nel

modello del caso di studio. Ha come chiave primaria ‘id_rew’ per identificare

univocamente la singola variabile e come campo aggiuntivo ‘reward_name’, contenente il

suo nome.

Le tabelle mean e variance

Queste tabelle contengono le statistiche delle variabili di reward calcolate sui dati forniti dal

simulatore. Hanno come chiave primaria i campi contenenti il numero di batch osservati

correntemente, gli identificativi della simulazione, dell’esperimento e della particolare

variabile di reward cui fanno riferiento. Alla fine di ogni osservazione le statistiche appena

calcolate, quali media e varianza, saranno inserite rispettivamente nei campi ‘mean’ e

‘variance’. In entrambe le tabelle, i campi ‘confidence_interval’ e ‘converged’ conterranno,



81

al termine di ogni batch osservato, l’intervallo di confidenza e un valore booleano che

indicherà l’avvenuta convergenza della variabile.

4.5 Il componente Model:

il tool desktop-based Failure Model WSN Generator

Come anticipato nel primo paragrafo di questo capitolo, profonde e consistenti modifiche

hanno rivoluzionato la struttura interna del generatore automatico sviluppato in [15]. I

cambiamenti hanno investito tutte le classi adibite alla generazione delle descrizioni xml dei

modelli che caratterizzano il caso di studio sulle reti WSN e, conseguentemente, del Möbius

project file. Questa trasformazione è stata necessaria al fine di garantire la coerenza tra i

risultati prodotti dal generatore e il nuovo modello proposto in [9] per l’analisi delle reti

wireless. Tuttavia, nonostante il notevole impatto che queste modifiche hanno avuto sul

tool, si è preferito in questa tesi tralasciare la loro descrizione (rimandando l’utente che

voglia approfondire, alla lettura del codice allegato), per lasciare più ampio spazio alle

operazioni di reverse-engineering realizzate sul codice di Möbius, che hanno permesso

l’aggiunta della funzionalità di simulazione del modello generato, prima assente. Se in

origine, infatti, era unicamente possibile generare, a partire dai file prodotti, un eseguibile

che andava poi esportato dall’utente perchè lo eseguisse sulla propria macchina (e ciò

presupponeva quindi la presenza del tool di simulazione Möbius sul pc dell’utente), ora

finalmente è realizzabile anche la simulazione, così che il ruolo del possibile fruitore del

tool si limiti alla sola analisi dei risultati ottenuti.

Una particolare attenzione sarà inoltre data alla classe MobiusProject del package project,

del generatore automatico, alla quale sono state aggiunte, tra le varie modifiche, anche le

linee di codice per eseguire lo script avente il fondamentale compito di compilare le librerie

esterne necessarie alla generazione dell’eseguibile.

4.5.1 La classe MobiusProject del package project e il file scriptShell.sh

Dopo la generazione delle descrizioni xml, se richiesto dall’utente, i modelli possono essere



82

compilati richiamando il metodo compileAllModels() di questa classe; esso produce

come output un file di codice C++ con estensione cpp, un headerfile di estensione .h e un

makefile per ognuno di essi; tutti i file oggetto prodotti, vengono linkati alle librerie di

Möbius, e a librerie esterne definite in [9]: il risultato di questa operazione darà luogo

all’eseguibile per il solver, che viene poi lanciato per generare i risultati. Risulta quindi

necessario innanzitutto compilare le librerie esterne; questa operazione viene effettuata

eseguendo lo script contenente i comandi di shell adibiti allo scopo. Riportiamo di seguito

la porzione di codice che implementa quanto detto:

… String makefileName = new String(); String scriptShell = this.getFilePath() + File.sepa rator + "Scripts"+File.separator+"scriptShell.sh"; if(System.getProperty("os.name").equalsIgnoreCase(" Linux")) makefileName = "makefile_LINUX"; else if(System.getProperty("os.name").equalsIgnoreCase ("Win")) makefileName = "makefile_WIN"; else makefileName = "makefile_MAC"; String cmd1 = "chmod +x "+scriptShell; String cmd2 = scriptShell+""+this.getProjectPath()+ ""+ makefileName+""+getZipModelsPath()+"" + this.getDataFilesDirectory(); Process p = null; try { p = Runtime.getRuntime().exec(cmd1); try { sleep(1000); } catch (InterruptedException e) {e.printStackTrace();} p = Runtime.getRuntime().exec(cmd2); BufferedReader in = new BufferedReader(new InputStreamReader(p.getInputStream())); String line; while ((line = in.readLine()) != null) System.out.println(line); } catch (IOException e) {e.printStackTrace();}

Lo shell script è un file di comandi del sistema operativo, scritto nel linguaggio di shell,



83

così da risultare un vero e proprio programma. Per poterlo eseguire da un’applicazione Java

è necessario servirsi della classe Runtime che deriva da Object e che appartiene al

package java.lang . Una sua istanza rappresenta l’esecuzione dell’interprete Java, non è

possibile creare un suo oggetto in quanto ha un solo costruttore che è privato, ma si può

ottenere una referenza all’oggetto correntemente in esecuzione mediante il metodo statico

getRuntime() . Richiamando su tale riferimento il metodo exec(), viene restituito un

oggetto di tipo Process che si occupa di eseguire il comando specificato come argomento

del metodo. Viene eseguito prima il comando cmd1 contenente le direttive per cambiare i

permessi al file sriptShell.sh così che sia reso effettivamente eseguibile, e solo in

seguito è possibile inviare il comando cmd2 con i parametri che verranno passati allo script.

La shell infatti utilizza un tipo particolare di variabili, dette parametri posizionali, per

memorizzare ed identificare i parametri passati allo script sulla linea di comando. Il primo

parametro è memorizzato in una variabile chiamata 1, il secondo parametro è memorizzato

in una variabile chiamata 2 , e così via per tutti gli altri parametri posizionali. Questi nomi

di variabile sono riservati esclusivamente all'ambiente di shell, perciò non possono essere

utilizzati dagli utenti per nominare le proprie variabili. Per accedere al loro contenuto si

deve far precedere il nome della variabile scelta dall'operatore $ (ad esempio per ricavare il

contenuto del parametro posizionale 1 occorrerà scrivere nello script $1). Il parametro

relativo alla compilazione delle librerie (difatti lo script esegue anche altre operazioni che

necessitano di propri parametri, come ripulire le directory che andranno a ospitare i modelli

o decomprimere la cartella contenente le librerie da compilare) è il terzo, ovvero quello

contenuto nell’oggetto makefileName : il suo valore serve a individuare il tipo di sistema

operativo sul quale avverrà la compilazione. Allo scopo è stata utilizzata la classe System ,

anch’essa del package java.lang , che interfaccia il programma Java con il sistema sul

quale è eseguito. Su di essa è stato invocato il metodo getProperty("os.name") che

restituisce il valore della proprietà specificata come argomento, in questo caso il nome del

sistema operativo sul quale gira la Java Virtual Machine, appunto. E’ stato necessario

individuare il tipo di sistema operativo perchè è in relazione a questo che viene richiamato,



84

tra quelli presenti nella cartella delle librerie, il makefile opportuno.

Una volta indicati tutti i parametri, è possibile lanciare anche il secondo comando in modo

da avviare la compilazione delle librerie che verranno successivamente linkate da Möbius

con tutti gli altri file per produrre l’eseguibile che ‘sarà dato in pasto’ al simulatore.

4.5.2 Le classi del package simulator

Di seguito vengono illustrati i package del generatore automatico, così da avere un’idea del

contesto d’inserimento delle nuove classi che consentiranno la simulazione del modello del

caso di studio.

Figura 4.3: package del generatore automatico FailureModelGenerator

Le classi incaricate di generare le descrizioni xml dei vari modelli sono contenute nei

package atomicModels, composedModels, rewardModels, studyModels, solverModels,

mentre quelle contenute in basicelements, sanelements, composedelements hanno il compito

di produrre stringhe xml delle singole entità che concorreranno alla generazione

complessiva. Infine, i package failureModelWSNGenerator e project gestiscono il

salvataggio dei modelli e tutte le loro informazioni, utilizzandole per scrivere i file finali da

sottoporre alla compilazione.

Le classi che appartengono al package simulator sono tutte e sole quelle incaricate di gestire

l’avvio della simulazione, il trattamento dei dati inviati dal simulatore di Möbius per il



85

calcolo dei valori delle variabili definite nel modello di reward (vedi 3.3.2), l’archiviazione

di questi ultimi nel database remoto db_ Möbius, e la terminazione della simulazione. Come

anticipato, tali classi sono state estrapolate dal codice sorgente di Möbius e, solo dopo un

attento studio, sono state oggetto delle modifiche necessarie a conseguire quanto richiesto

dal seguente lavoro di tesi: riuscire ad intercettare e interpretare, allo scopo di calcolare e

memorizzare il valore statistico delle reward variables, i risultati trasmessi dal simulator

engine di Möbius sul bus a eventi condiviso con la nostra applicazione; il tutto alla fine di

ogni singola osservazione (o batch, il cui numero è specificato in uno dei file del solver)

relativa ai vari esperimenti performati nella fase di configurazione dello scenario da

simulare.

Di seguito riportiamo l’elenco delle classi importate dal Möbius Project nel package

simulator , e il collaboration diagram che ne mostra le relazioni esistenti.

Figura 4.4: classi del package simulator

Sono state omesse dal diagramma le classi adibite al calcolo effettivo dei valori statistici

(quali media e varianza) delle quali sarà riportato un class diagram che verrà analizzato

separatamente. Ci soffermeremo sulle classi che si occupano di avviare le operazioni

preliminari all’avvio della simulazione (la classe Simulator); gestire la comunicazione con

il simulation engine (la classe ProjectManager); intercettare, prelevare e interpretare i



86

risultati trasmessi sul bus di eventi (la classe StreamReader); infine calcolare e archiviare

nel database remoto le statistiche relative a ogni variabile (le classi ExperimentObject e

BaseCalculationObject). Per ognuna di esse verrà data una spiegazione dei metodi e delle

variabili membro principali che aiuterà a comprendere la complessa logica delle operazioni

che realizzano la simulazione nella sua totalità.



87

Figura 4.5: Collaboration Diagram delle classi del package simulator.



88

La classe Simulator

Questa è la classe più importante del package poiché crea le strutture dati indispensabili per

la gestione della simulazione. Le prime modifiche hanno riguardato il costruttore, cui è

risultato necessario passare come argomenti: i) un oggetto di tipo BaseInterfaceclass

attraverso cui gestire l’apertura e il salvataggio dei modelli e mantenere un riferimento alla

classe BaseInfoClass per avere accesso diretto alle principali informazioni su di essi (come

il numero e il nome dei vari esperimenti o lo tipologia di dati statistici da calcolare per le

variabili di reward); ii) il riferimento della connessione al database remoto db_ Möbius, in

cui archiviare i risultati degli esperimenti; iii) l’oggetto della classe Ambvar per accedere

alle informazioni riguardanti l’utente correntemente connesso. Diseguito sono riportate le

porzioni di codice che realizzano i punti i) e ii).

Simulator

+Mobius.BaseClasses.BaseInterfaceClass _baseinterfaceclass+int id_run+Connection conn-Mobius.Solvers.Simulators.SimInfoClass TheInfo-Vector ProcessorManager-StreamReader TheStreamReader-Vector Experiments-FailureModelWSNGenerator.failureModelWSNGenerator.AmbientVar ambvar+...

+Simulator()+void initDb()+void createRewardTable()+void StartSimulation()+void close_db()+void update_Experiment_Table()+void BuildProcessorManager()+void CreateExperiments()+void buildSimulator()+void writeMakefile()-void assignNextExperiments()+void StopSimulation()+...()



89

… ProjectManager theProjectManager = ProjectManager. getProjectManager(); theProjectManager.setRootProjectPath(“pathModelloda Simulare”); Project project = theProjectManager.openProject("no meProgetto", true, false); BaseSolverInterface baseSolverInterface = (BaseSolverInterface)project.getInterface("nomeSol verFile"); …

Nell’ordine:

1. Il primo passo è quello di creare un’istanza del ProjectManager e salvarne il

riferimento; ricordando che questa classe utilizza il pattern singleton, basta chiamare

il metodo getProjectManager() che provocherà anche l’avvio della schermata

grafica principale di Möbius;

2. il secondo passo è quello di settare la directory dove verrà cercato il progetto da

aprire, ed è fatto invocando sul ProjectManager il seguente metodo

setRootProjectPath() ;

3. il terzo passo è aprire il progetto e ottenerne un riferimento. Ciò è fatto invocando il

metodo openProject() sul ProjectManager ottenuto al passo 1;

4. Il quarto passo è quello di ottenere un riferimento ad un oggetto della classe

BaseInterfaceClass, (in realtà si tratta di una classe astratta pertanto verrà passato un

oggetto della classe BaseSolverInterface che viene eredita da essa); Ciò è fatto

invocando il metodo getInterface() sull’istanza del progetto appena aperto.

Per quanto concerne la connessione con il database, occorre innanzitutto caricare il driver

JDBC specifico del db MySQL, chiamato Connector-J, e in seguito si utilizza la classe

DriverManager messa a disposizione da Jave per instaurare la connessione attraverso il

metodo getConnection() , a cui vengono passati il nome del database, quello del suo

amministratore e una password di controllo:



90

… try { Class.forName("com.mysql.jdbc.Driver").newInstance (); Connection conn = DriverManager.getConnection("jdbc:mysql://loca lhost/ db_Mobius?user=amministratore&password=admi n"); }catch (SQLException e) {e.printStackTrace();} …

Ora analizziamo nel dettaglio le variabili membro e i metodi più significativi.

VARIABILI PUBBLICHE E PRIVATE

Accanto a ognuna ci sarà un segnale di spunta a indicare se è stata aggiunta in fase di

sviluppo.

� BaseInterfaceClass _baseinterfaceclass e SimInfoClass TheInfo

Come sopra anticipato questa variabile viene impiegata per accedere alle

informazioni del modello, il suo ausilio è di notevole importanza, non solo perché

ha consentito di automatizzare la simulazione, sollevando lo sviluppatore dall’onere

di fornire tutti i dati necessari alla sua esecuzione, ma soprattutto nell’ottica che il

modello possa essere oggetto di ulteriori cambiamenti, magari con l’aggiunta di

nuove variabili di reward, in seguito alla quale non sarà necessario modificare il

codice esistente per riadattarlo. Questa variabile, infatti, mantiene nel suo attributo

pubblico Information un riferimento alla classe BaseInfoClass che consente in

modo semplice e automatico di ottenere, ad esempio, tutti i dati necessari al

popolamento della tabella delle reward variables nel database db_ Möbius, di

individuare il numero di esperimenti attivi da svolgere o, ancora, di reperire i

parametri di configurazione della simulazione come massimo e minimo numero di

batch da eseguire. Prima di essere utilizzata, ne viene effettuato il cast verso un

oggetto di tipo SimInfoClass per essere in seguito assegnata alla variabile

TheInfo che verrà passata alle altre classi del package.



91

� Connection conn

Contiene il riferimento all’oggetto di tipo Connection che consente di interagire con

il db per le operazioni di inserimento dei risultati delle osservazioni e degli

esperimenti che avvengono durante la simulazione.

� int id_run

Questa variabile è stata aggiunta per individuare in modo univoco attraverso un ‘id’

di tipo intero che si incrementa in modo automatico, le singole simulazioni eseguite

dall’applicazione. Esso serve per inserire in modo corretto nel db i dati relativi a una

specifica simulazione.

• Vector ProcessorManager

E’ un vettore che tiene traccia di tutti i ProcessorManager istanziati per gestire le

esecuzioni concorrenti dei vari esperimenti.

• Vector Experiments

E’ un vettore contenente i riferimenti dei vari ExperimentObject istanziati uno per

ogni esperimento attivo.

• StreamReader TheStreamReader

Il suo compito è quello intercettare i risultati trasmessi dal simulation engine di

Möbius e riconvertirli nel corretto formato in base alle indicazioni fornite da

metadati anch’essi inviati sull’event bus, in modo che possano essere elaborati dalle

classi incaricate di fornire le stime statistiche richieste.

� FailureModelWSNGenerator.failureModelWSNGenerator.AmbientVar

ambvar

Contiene l’oggetto per risalire alle informazioni su utente correntemente connesso e

topologia da lui usata per la simulazione, necessarie per effettuare gli inserimenti nel

db.

METODI PUBBLICI E PRIVATI

Accanto ad ognuno ci sarà un segnale di spunta a indicare se è stato oggetto di modifica



92

(allora saranno illustrati i cambiamenti subiti dal codice) o è stato aggiunto in fase di

sviluppo.

� Simulator()

E’ il costruttore della classe e realizza tutte le operazioni preliminari all’esecuzione

della simulazione. Per farlo riceve come argomenti, nell’ordine: un oggetto di tipo

BaseInterfaceclass, uno di tipo Connection e l’ultimo della classe Ambvar. Quindi le

modifiche hanno riguardato i parametri passati per argomento e l’aggiunta delle

chiamate ai metodi initDb() e createRewardTable().

� void initDb()

Prepara il database per la simulazione inserendo i dati relativi all’utente, il nome

della topologia usata e quello del progetto. Inoltre archivia nella variabile pubblica

id_run il valore assegnato alla simulazione corrente.

Questo metodo non era presente in origine ed è stato implementato ex-novo.

� void createRewardTable()

In realtà il corpo di questo metodo viene eseguito una sola volta, e cioè quando

l’applicazione è resa fruibile e il database db_ Möbius viene acceduto per la prima

volta. Questo perché la tabella delle rewards variables viene lasciata vuota così da

poter essere popolata in funzione del particolare modello oggetto del generatore.

Con questa scelta di sviluppo, se il modello in futuro dovesse essere modificato,

basterebbe ripulire semplicemente questa tabella per continuare a garantire un

comportamento corretto dell’applicazione. Non solo, ma dal momento che allo stato

in cui si sta scrivendo questa tesi, il numero di variabili di reward si aggira intorno

alla sassantina, s’intuisce l’utilità di non doverle trascrivere manualmente nella

tabella.

Il metodo non era presente in origine ed è stato implementato ex-novo. Riportiamo

di seguito parte del codice:



93

… BaseStudyInfoClass basestudyinfoclass = getStud yInfo(); PVInfo pvinfo = basestudyinfoclass.getPVInfo(); Statement stm = null; ResultSet requery = null; PreparedStatement ps = null; final String SQL3 = "SELECT * FROM reward"; final String SQL4 = "INSERT INTO reward( id_rew,reward_name)VALUES(?,?)"; try { if(!conn.isClosed()){ conn.setAutoCommit(false); stm = conn.createStatement(); requery = stm.executeQuery(SQL3); if(!requery.next()) for(int k = 0; k < pvinfo.getNumPVCountingTimeArrays(); k++){ VariableInfoClass variableinfoclass = pvinfo.getVariableInfoCountingTimeArrays(k); ps = conn.prepareStatement(SQL4); ps.setInt(1, k); ps.setString(2,variableinfoclass.getName()); ps.executeUpdate(); } } }catch (SQLException e) {e.printStackTrace();} finally{ try { if(requery!=null && !requery.isClosed()) requery.close(); if(stm!=null && !stm.isClosed()) stm.close(); if(ps!=null && !ps.isClosed()) ps.close(); } catch (SQLException e) {e.printStackTrace();} }

Per avere le informazioni sulle variabili di reward che occorre inserire, viene

ottenuto un riferimento all’oggetto BaseStudyInfoClass sul quale viene invocato



94

il metodo getPVInfo() che restituisce un oggetto PVInfo . A questo punto viene

eseguita una query sul database per verificare se la tabella di reward era già stata

popolata; in caso negativo si accede ai dati, invocando i metodi

getNumPVCountingTimeArrays() , per risalire al numero di variabili, e

getVariableInfoCountingTimeArrays(), per ottenere l’oggetto

VariableInfoClass relativo alla singola variabile (identificata dall’id passatogli

come argomento) e per la quale essa fornisce i metodi get di accesso.

� void StartSimulation()

Questo metodo crea tutte le strutture dati necessarie durante la simulazione e ne

richiama le operazioni preliminari; vengono invocati nell’ordine i metodi

CreateExperiments(), BuildProcessorManager(), buildSimulator(), writeMakefile().

• void CreateExperiments()

Per ognuno degli esperimenti attivi presenti nel file dello study, istanzia un oggetto

di tipo ExperimentObject e lo aggiunge al vettore degli esperimenti visto sopra.

• void BuildProcessorManager()

Istanzia un numero di ProcessorManager pari al numero di processori presenti sulla

macchina che ospita l’applicazione, selezionati per la simulazione. Lo scopo è che

essi gestiscano in modo concorrente l’esecuzione degli esperimenti rappresentati

dagli oggetti contenuti nel vettore degli esperimenti, così da ridurre i tempi necessari

a terminare la simulazione.

• void buildSimulator()

Scrive il makefile del solver e lo compila con il resto dei modelli.

� void StopSimulation()

Questo metodo semplicemente ferma la simulazione: a ogni ProcessorManager

istanziato, viene dato l’ordine di inviare il comando di “QUIT” al simulation engine

e di chiudere la socket sulla quale avveniva la trasmissione dei dati. Inoltre anche lo

StreamReader che era adibito all’ascolto di nuovi flussi di trasmissione viene

chiuso. Infine, viene aggiornata la tabella degli esperimenti, invocando il metodo



95

update_Experiment_Table(), e viene chiuso il database attraverso la

chiamata di closeDb().

� void update_Experiment_Table()

Per ogni esperimento vengono accedute le tabelle nelle quali sono stati archiviati

durante la simulazione tutti i valori delle variabili di reward (vale a dire le tabelle

mean e variance); da esse viene prelevata l’informazione relativa al raggiungimento

dell’intervallo di confidenza che viene inserita, insieme all’id della simulazione,

all’identificativo dell’esperimento (che è lo stesso contenuto nel file dello study), al

numero di osservazioni effettuate, al numero di nodi della rete simulata, al tempo di

simulazione, e al nome dell’esperimento, nella tabella experiments del database. Il

metodo non era presente in origine ed è stato implementato ex-novo.

� void close_db()

Chiude la connessione con il database. Il metodo non era presente in origine ed è

stato implementato ex-novo. Riportiamo di seguito parte del codice:

… try { if(conn!=null && !(conn.isClosed())) conn.close(); } catch (SQLException e) {e.printStackTrace();}

Nonostante le classi che seguiranno non abbiano subito alcun cambiamento, è opportuno

comunque dare una spiegazione di alcuni dei loro metodi al fine di rendere più

comprensibile l’esecuzione della simulazione di un modello.

La classe ProcessorManager

Questa classe ha un ruolo fondamentale sia nella gestione della comunicazione con il

simulation engine, poiché si occupa di avviare e terminare la trasmissione dati, inviando su

una socket aperta allo scopo i relativi comandi, sia nel controllo dell’esecuzione dei diversi

esperimenti. Essa implementa l’interfaccia ProcessFinishedAdaptor di cui definisce



96

l’unico metodo processFinished() che coordina le operazioni per terminare la

simulazione. Alcuni attributi sono gli stessi della classe Simulator quindi ci concentreremo

su quelli non ancora analizzati.


• ProcessMonitor ProcessMon

Questo oggetto viene istanziato per comunicare con la Shell allo scopo di inviare il

comando al simulation engine affinchè si avvii e si metta in attesa di una richiesta di

connessione da parte della nostra applicazione.

• Int DefaultPort

Il port di default è fissato a 10000, ma viene incrementato automaticamente a ogni

tentativo fallimentare di usarlo per la comunicazione.

• Socket MySocket

E’ la socket aperta sul primo port libero trovato a partire da quello di default;

attraverso di essa l’applicazione riceverà i dati formattati da elaborare.

• InputStream MyStream

Questo stream, una volta creato, viene aggiunto alla lista di stream utilizzati

dall’oggetto StreamReader contenuto nella variabile TheStreamReader (istanziato

nella classe Simuletor e passato al costruttore del ProcessorManager), per

intercettare i dati relativi alle singole osservazioni.


• ProcessorManager()

E’ il costruttore della classe e tra i parametri che gli vengono passati occorre

menzionare l’oggetto StreamReader, per il motivo sopra citato, il SimInterfaceClass

che servirà ad ottenere le informazioni necessarie a comporre il comando da inviare

per dare inizio alla simulazione, e infine il Simulator al quale sarà indicato il

termine della simulazione per poter avviare la scrittura dei risultati in un file di



97

output.

• void runExperiment()

A questo metodo viene passato come argomento un oggetto di tipo

ExperimentObject che servirà per risalire all’id dell’esperimento che va specificato

durante la composizione del comando da inviare al simulatore ad opera del metodo

buildCommandArgs(). Fatto questo la stringa risultante viene passata a un’istanza

della classe ProcessorMonitor sul quale è invocato il metodo execCommand(), che

avrà il compito di eseguirla da linea di comando.

• String[] buildCommandArgs()

Viene invocato per comporre il comando da inviare al simulation engine. Attraverso

la variabile TheInfo è possibile risalire a tutti parametri che andranno specificati nel

comando, tra i quali citiamo:

- l’id dell’esperimento da eseguire;

- il numero di osservazioni che il simulatore deve inviare a ogni update;

- il port per la trasmissione dati;

- il Random Number Generator e il Random Number Seed sulla base dei quali

effettare le sperimentazioni;

• void createSocket()

Stabilisce una connessione con il simulatore e crea uno stream che viene aggiunto

alla lista degli stream della variabile TheStreamReader, invocando su di essa il

metodo add().

• void quitProcess()

Una volta terminati tutti gli esperimenti, al suo interno viene richiamato il metodo

boolean sendCommand(), per inviare al simulatore la stringa “QUIT” per indicargli

di terminare la simulazione. Viene eliminato lo stream relativo al particolare

ProcessorManager dalla lista della variabile TheStreamReader e infine viene chiusa

la socket instaurata per la comunicazione.

• void processFinished()



98

Questo metodo viene dichiarato nell’interfaccia implementata dalla classe

ProcessorManager e vuole come argomento un oggetto di tipo ProcessMonitor.

Attraverso quest’ultimo, infatti, viene ottenuta la stringa inviata dal simulation

engine in seguito alla richiesta di terminare la connessione. Il metodo analizza la

stringa per verificare la presenza delle parole "GOOD EXIT" e "SOCKET::Quit"

che indicano la disconnessione avvenuta con successo da parte del simulatore. Nel

caso non venga rilevato alcun riscontro viene stampato a video una stringa di errore

per segnalare all’utente che un qualche problema si è verificato durante la

simulazione.

La classe ExperimentObject

Il compito di questa classe è gestire e fornire tutte le informazioni circa i singoli esperimenti

e l’avanzamento della loro esecuzione, come il tempo di simulazione trascorso (contenuto

nella variabile ElapsedTime) o il numero di batch analizzati fino a un dato istante

(DoneBatches).


I nomi delle variabili sono abbastanza esplicativi dei valori da esse contenute, pertanto ci

soffermeremo solo sulla spiegazione di alcune di esse.

• Vector calculationElements

E’ un vettore creato per ospitare, per ognuna delle variabili di reward definite, i tipi

di misura statistica da calcolare. Ogni tipologia, come vedremo più avanti, è

rappresentata da una diversa classe ereditata dalla classe astratta

BaseCalculationObject.

• PVInfo ThePVInfo

Attraverso questa variabile è possibile accedere a tutte le informazioni relative alle

variabili di reward definite nel reward model, come il numero complessivo o il tipo

di analisi statistica di cui devono essere oggetto.



99

• Vector Processors

Tiene traccia di tutti i ProcessorManager ai quali un dato esperimento è stato

assegnato al fine di ottimizzare le operazioni necessarie.


� ExperimentObject()

Dato che la classe ExperimentObject è incaricata di creare gli oggetti che da un lato,

effettueranno i calcoli necessari per determinare i valori delle variabili di reward, e

dall’altro aggiorneranno contestualmente a questa operazione la tabella affine, è

stato necessario modificare il costruttore della classe in modo che gli venissero

passati come argomenti anche il riferimento all’oggetto Connection e l’id

dell’esperimento, che a sua volta passerà agli oggetti durante la loro istanziazione.

• void addDataobject()

A questo metodo viene passato come argomento l’oggetto di tipo DataObject che

conterrà i dati utili al calcolo delle statistiche. In base alla frequenza con la quale

devono essere aggiornati i valori delle variabili di reward, esso richiama il metodo

updateData() che comunica con gli oggetti incaricati di effettuare i calcoli.

• void updateData()

In pratica questo metodo invoca, su ognuno degli oggetti

BaseCalculationObject contenuti nel vettore CalculationElements, il

metodo Update() per ricalcolare, tenendo conto dei nuovi dati ricevuti e contenuti

in nella variabile NewData, i valori statistici di ogni variabile. Di seguito è riportata

la porzione di codice che richiede il calcolo dei parametri statistici.



100

... for(int j = 0; j < CalculationElements.size(); j++) { BaseCalculationObject basecalculationobject = (BaseCalculationObject)CalculationElements.elemen tAt(j); flag &= basecalculationobject.Update(NewData, i, MinBatches, MaxBatches); DoneBatches = Math.max(DoneBatches, basecalculationobject.getBatches()) ; } ...

Nella variabile booleana flag viene restituito il valore true se tutti i valori calcolati

relativi a tutte le variabili di reward rientrano nell’intervallo di confidenza

specificato, invece DoneBatches contiene il numero di osservazioni effettuate fino

a quell’istante.

Come vedremo più avanti, è proprio all’interno del corpo del metodo Update() ,

ridefinito in ognuna delle classi ereditate da BaseCalculationObject , che è

contenuto il codice necessario a svolgere le operazioni di aggiornamento dei valori

di media e varianza, e il loro inserimento all’interno del database db_ Möbius.

La classe StreamReader

Questa classe costituisce il fulcro dell’elaborazione dei dati inviati dal simulatore. Infatti

sul bus event vengono inviati, oltre ai dati utili formattati come double, anche metadati

riguardanti l’esperimento e la particolare variabile di reward cui essi fanno riferimento,

come pure il tempo impiegato dal processore per eseguire la simulazione. Questo è il

motivo per cui prelevare i dati direttamente dallo stream così come giungono non è

possibile e occorre, invece, conoscere l’ordine in cui essi sono trasmessi e la loro natura.

La classe StreamReader implementa la struttura necessaria a intercettare i dati sul bus, e

individuare il tipo di informazione che essi trasportano per poterli trattare in modo

appropriato. Dall’istante in cui l’oggetto Simulator avvia un suo thread, questo si mette in

attesa di poter prelevare dati dagli input stream che i vari ProcessorManager hanno creato.

Ogni thread, infatti mantiene nel vettore _addStream una lista di tutti gli stream utilizzati

dal simulatore per la trasmissione.



101

Il metodo utilizzato per leggere il flusso di informazioni è readStream(), che ha come

argomenti il riferimento allo stream e al relativo ProcessorManager.

Vediamone una porzione di codice:

… if(datainputstream.available() > 0){ int i = datainputstream.readInt(); if(i > 0){ j++; byte byte0 = datainputstream.re adByte(); switch(byte0) { case -1: readReplyPacket(datainputst ream); break; case -2: readTimePacket(datainputstr eam); break; default: readDataPacket(datainputstr eam, process ormanager); break; } } }

Ogni pacchetto inviato (inteso in senso generale e non di datagramma UDP) contiene una

sorta di header che consente di individuarne il contenuto informativo, così da richiamare tra

i metodi per la lettura evidenziati in grigio, quello più congeniale. Quindi a seconda del

valore della variabile byte0 , seguirà la lettura di un ReplyPacket (inviato solo una volta

all’inizio della connessione), di un TimePacket o di un DataPacket. Questo perchè la natura

del pacchetto stabilisce intrinsecamente una sorta di protocollo da rispettare durante il ciclo

di lettura dei dati dallo stream affinchè essi abbiano senso. Concentriamoci sul metodo

readDataPacket() e analizziamone parte del codice:

…

short word0 = datainputstream.readShort(); short word1 = datainputstream.readShort();

…



102

for(int k = 0; dataobject != null && k < word1;){ short word2 = datainputstream.readShort(); byte byte0 = datainputstream.readByte(); int i = datainputstream.readInt(); try{ for(j = 0; j < i; j++){ double d = datainputstream.readDouble(); dataobject.addValue(word2, byte0, d); } k++; }catch(EOFException eofexception){continue;}

La prima lettura dello stream riguarda l’identificativo dell’esperimento cui fa riferimento il

pacchetto inviato, che verrà messo nella variabile word0 ; word1 conterrà il numero

complessivo di dati utili da leggere; lo short word2 conterrà l’identificativo della

particolare variabile di reward di cui calcolare le statistiche; byte0 il tipo di struttura dati

all’interno della quale memorizzare i dati contenuti nella variabile d (si tratta dei risultati

veri e propri delle osservazioni effettuate), infine i indicherà il numero di dati double che

occorre leggere successivamente (quest’ultimo parametro dipende dal numero di

osservazioni inviate per ogni variabile dal simulatore, specificato nel solver file). A questo

punto, terminata la lettura del pacchetto, i dati e tutte le informazioni necessarie a risalire a

quale variabile di reward essi fanno riferimento, sono archiviate nella matrice di double

dell’oggetto della classe DataObject.

Invocando il metodo retrieveExperiment() , è possibile recuperare l’esperimento di

cui calcolare le variabili dal vettore che tiene traccia di tutti gli esperimenti correntemente

in esecuzione sul simulatore. Solo a questo punto si possono avviare le operazioni

finalizzate al calcolo delle statistiche, attraverso la chiamata del metodo

addDataObject() sul riferimeto dell’ExperimentObject sopra ottenuto, e iniziare così un

nuovo ciclo di lettura.

… ExperimentObject experimentobject = retrieveExperim ent(word0); if(experimentobject != null){ experimentobject.addDataObject(dataobject); }



103

La classe astratta BaseCalculationObject

Figura4.6: class diagram delle classi adibite all’elaborazione statistica dei dati

In figura è stato riportato il diagramma delle classi che vengono utilizzate dall’oggetto

ExperimentObject per determinare i valori delle variabili di reward definite nel reward

model. Le classi incaricate di calcolare i valori statistici di ognuna sono quattro, ma di esse

solo due, MeanCalculatinoObject e VarianceCalculationObject, vengono usate durante la

simulazione del modelli del caso di studio. Tuttavia per completezza e in vista di eventuali



104

modifiche sul modello abbiamo preferito importarle comunque tutte nel package simulator.

La classe ‘genitore’ dalla quale esse ereditano è la BaseCalculatinObject, in cui viene

dichiarato il metodo astratto Update() che riceve come argomenti: un vettore di oggetti

DataObject, per risalire ai dati inviati dal simulation engine relativi a una data osservazione,

la dimensione del vettore, infine minimo e massimo numero di batch da eseguire. Il metodo

viene poi implementato in ognuna delle classi derivate specializzandone il comportamento a

seconda della tipologia di statistiche che esse devono restituire ovvero, media o varianza. E’

nel corpo di questo metodo, infatti, che risiede il codice che implementa tutte le operazioni

sui dati.

Sono stati modificati i costruttori delle due classi sopra citate poiché era necessario che

venissero passati loro il riferimento all’oggetto Connection indispensabile per le

comunicazioni con il database, e l’identificativo della simulazione e dell’esperimento, così

da poter effettuare correttamente l’inserimento dei valori nella tabella opportuna. Allo

scopo sono state aggiunte le variabili Connection conn_db , int id_run e int

id_exp ed è stato implementato il metodo update_run_reward_Table() che viene

richiamato in coda al codice contenuto nel metodo descritto sopra.

Poichè l’implementazione è simile in entrambe le classi (differisce infatti solo nella natura

dei dati inseriti e nella particolare tabella utilizzata), verrà analizzato il codice relativo

all’inserimento, nella tabella ‘mean’ del database db_Möbius, dei valori di media e di

intervallo di confidenza, calcolati nel metodo Update() della classe

MeanCalculatinoObject :



105

… PreparedStatement ps = null; final String SQL = "INSERT INTO mean(id_run, id_exp , id_rew, batch,mean,converged,confidence_interval)VALUES(?,? ,?,?,?,?,?)"; try { if(!conn_db.isClosed()){ conn_db.setAutoCommit(false); ps = conn_db.prepareStatement(SQL); p s.setInt(1, id_run); ps.setInt(2, id_exp); ps.setInt(3, getPVNumber()); ps.setInt(4, (int)getBatches()); ps.setDouble(5, getMean()); ps.setBoolean(6, getConverged()); ps.setDouble(7, getConfidenceInterval()); ps.executeUpdate(); }…

Quindi, una volta calcolate le statistiche sui nuovi valori pervenuti, vengono inseriti nel

database :

1. l’id della simulazione e quello dell’esperimento, passati al costruttore;

2. l’identificativo della variabile di reward di cui si sono effettuati i calcoli; questo è

ottenuto invocando il metodo getPVNumber() ;

3. il valore della media, ottenuta invocando il metodo getMean() ;

4. il numero di batch osservati, ottenuti invocando il metodo getBatches() ;

5. una variabile booleana che indica l’avvenuta convergenza relativa alla particolare

variabile, ottenuta invocando il metodo getConverged() ;

6. l’intervallo di confidenza, ottenuto invocando il metodo

getConfidenceInterval() .

Tutti i metodi invocati sono implementati nella particolare classe in oggetto.



106

4.6 I componenti View e Controller :

il tool web-based Web Model WSN Generator

In questo paragrafo verranno descritte le modifiche che sono state applicate al tool web

based allo scopo di implementare le nuove funzionalità, esposte in 4.2, che esso deve essere

in grado di fornire. Poichè in [14] sono state ampliamente discusse le fasi di progettazione

dell’applicativo, si rimanda ad esso per eventuali approfondimenti.

Si ricorda che il componente software controller racchiude le classi realizzate per il

controllo che dialogano sia con i componenti ZK dell’interfaccia web, sia con le classi del

model; inoltre, questo componente, include anche il file .jar del progetto zkDiagram, un

porting opensource della libreria JavaScript draw2d necessaria per implementare la

funzionalità disegno topologia WSN. La View, invece, è composta di soli file .zul

dell’interfaccia grafica dell’applicazione web, scritti utilizzando sia il linguaggio ZUML sia

HTML.

4.6.1 La scelta del Framework

Zk è un web framework basato su componenti Ajax, scritto interamente in Java e che

permette di creare ricche intefacce grafiche per applicazioni web senza alcun bisogno di

utilizzare il linguaggio JavaScript nè Ajax. ZK è open source, ed ha di recente adottato la

licenza LGPL che permette di usarlo liberamente anche in ambito commerciale. La parte

centrale di ZK consiste in un meccanismo event-driven basato su oltre duecento componenti

Ajax, e un linguaggio di mark-up (XUL/XHTML) usato per disegnare interfacce grafiche.

A differenza di altri framework basati su Ajax, ZK non richiede al programmatore alcuna

conoscenza di Javascript per sviluppare applicazioni, perchè il framework si occupa

autonomamente di generare il codice Javascript necessario al corretto funzionamento

dell’applicazione. Per sviluppare correttamente una applicazione è necessario dunque, oltre

alla conoscenza di un linguaggio di programmazione ad oggetti tra quelli supportati, come

Java o Python, una minima conoscenza di HTML.

Il punto di forza di questo framework, quindi, è la possibilità di sviluppare una applicazione

web come se fosse una applicazione desktop, secondo un principio che viene definito dagli



107

stessi sviluppatori come Direct RIA, in cui la parte grafica ed il controllo associato vengono

sviluppati come in una normale applicazione Swing o SWT. E’ possibile ad esempio

l’utilizzo di componenti grafici (predefiniti dagli sviluppatori di ZK) comuni ad altre

tecnologie, come TextBox, Label e Button da aggiungere liberamente nell’interfaccia

grafica (pagina web) che si vuole sviluppare. Automaticamente verranno creati listener di

eventi comuni da monitorare (onClick, onChange etc.) e si potranno definire delle funzioni

da eseguire quando questi eventi si verificano.

Il linguaggio ZUML consente di aggiungere e posizionare questi componenti all’interno

della pagina web. Si tratta di un linguaggio di mark-up con una sintassi XML style che

permette lo sviluppo veloce di RIA. E’ inoltre disponibile un plugin per Eclipse che

permette, alla stregua dei tool RAD per applicazioni desktop, la progettazione visuale delle

interfacce.

Il framework ZK si è rivelato inoltre uno strumento facile da apprendere, e che ben si presta

allo sviluppo veloce di RIA, nonostante non sia particolarmente adatto ad applicazioni web

spiccatamente client side, per cui si consiglia l’uso di Flash o JavaFX.

Il pattern architetturale Model-View-Controller (MVC, talvolta tradotto in italiano con

Modello-Vista-Controllore) adottato nell’applicazione, è basato sulla separazione dei

compiti fra i componenti software che interpretano tre ruoli principali. Secondo tale

modello possiamo articolare un software secondo tre ruoli. Il primo, il model, fornisce i

metodi per accedere ai dati utili all’applicazione. Il secondo, il view, visualizza i dati

contenuti nel modem e si occupa dell’interazione con utenti ed agenti. Il terzo, il controller,

riceve i comandi dell’utente (in genere attraverso la view) e li attua modificando lo stato

degli altri due componenti. Si tratta di un modello molto diffuso nello sviluppo di interfacce

grafiche di sistemi software object oriented e che implica anche la tradizionale separazione

tra logica applicativa (logica di business) a carico del controller e del model, e l’interfaccia

utente a carico della view.

Il pattern MVC non è obbligatorio in ZK, ma ne è fortemente consigliato l’utilizzo da parte

degli sviluppatori. Per utilizzare il pattern MVC in ZK è sufficiente suddividere



108

l’applicazione in due file : nel primo, con estensione .zul andrà definita la parte grafica

dell’applicazione, mediante il linguaggio ZUML già presentato; nel secondo, con estensione

.java, andrà l’implementazione dei listener degli eventi, e quindi la parte Model e Controller

dell’applicazione.

4.6.2 Le classi controller e i file.zul

All’interno del componente Controller è stato implementato ex-novo il package ‘database’

contenente tutte le classi che, richiamate dai file .zul attraverso l’attributo “apply”,

dialogano con il database db_Möbius al fine di gestire i file archiviati nella tabella

‘topology’. In particolare di questo package fanno parte le classi:

• DatabaseManagement_ctrl: crea dinamicamente e visualizza la lista di tutti i file

delle topologie salvati dall’utente nel database; per ognuno di questi, di cui sono

specificati nome e data di inserimento, sono consentite le operazioni di esportazione

e di cancellazione innescate attraverso i pulsanti ‘Download Topolgy’ e ‘Delete

Topolgy’ definiti nel file DataBase.zul. Inoltre è possibile effettuare l’upload di un

nuovo file in formato .zip o, ancora, ripulire l’intera tabella delle topologie mediante

i pulsanti ‘Upload Topology’ e ‘Clean DataBase’.

• DbTopology_ctrl: permette all’utente di selezionare dal database il file della

particolare topologia che verrà poi esportata nella cartella dell’utente (creata all’atto

della sua registrazione) per essere utilizzata durante la generazione del modello. Il

file che essa controlla è WinDbTopology.zul.

• SaveTopology_ctrl: questa classe viene invocata dal file SaveTopology.zul e ha il

compito di implementare le operazioni per l’archiviazione del file compresso di una

topologia dopo che questa sia stata disegnata dall’utente attraverso la schermata

grafica messa a disposizione dall’applicazione; nel caso in cui il nome specificato

per la memorizzazione corrisponda a un file già presente nel db, è necessario

indicare un nome diverso, poichè questo deve intrinsecamente fornire un’idea

immediata della natura della topologia.

Fanno, invece, parte del package ‘webfamogen.controller’ tutte le classi che controllano il



109

funzionamento della GUI web e che dialogano con i software desktop installati nel server.

Di esso alcune classi sono state create ex-novo, altre, invece, sono solo state oggetto di

modifiche. In particolare di questo package fanno parte le nuove classi:

• RegisterBoxController: si occupa della registrazione dell’utente attraverso

l’interfaccia del file WinRegister.zul. E’ necessario indicare un nome utente, una

password alfanumerica e un’e-mail, i dati sono poi inseriti nella tabella ‘users’ del

database db_Möbius. Vengono utilizzati i metodi delle classi di utilità per creare i

file e le cartelle necessarie al funzionamento della simulazione remota alle quali

viene in seguito collegata la sessione corrente.

• LoginBoxController: è responsabile della sessione e dell’autenticazione dell’utente

attraverso l’interfaccia del file WinLogin.zul. L’autenticazione viene eseguita

inserendo username e password con i quali l’utente si è registrato, e si conclude

collegando la sessione corrente con i file e le cartelle necessarie al funzionamento

della simulazione remota create in fase di registrazione.

• ShowResults_ctrl: viene richiamata all’interno del file ShowResults.zul al termine di

una simulazione, al fine di crearne dinamicamente e visualizzarne la lista di tutti gli

esperimenti. Mostra per ognuno di essi: il nome, il tempo di simulazione, i batch

osservati e se esso ha raggiunto o meno la convergenza.

• ShowAllResults_ctrl: crea e visualizza dinamicamente tutte le informazioni relative

a un singolo esperimento, riporta per ogni osservazione eseguita: il nome della

variabile, il numero di batch correnti, il valore della media e il suo intervallo di

confidenza, infine il valore della varianza e il suo intervallo di confidenza. Questa

classe controlla il file ShowAllResults.zul.

• Download_ctrl: consente all’utente di effettuare il download del modello appena

compilato e simulato oppure di esportarne solamente i risultati. Queste operazioni

vengono innescate rispettivamente dai pulsanti “Download Model” e “Download

Results” definiti nel file ShowResults.zul. In particolare l’esportazione dei risultati

prevede la creazione di un file .csv direttamente a partire dal database db_Möbius



110

che conterrà il nome del progetto, il numero di nodi che costituiscono la rete, la

topologia utilizzata, il nome di tutti gli esperimenti e per ognuno di essi la durata

della simulazione, il numero di batch osservati e se esso ha raggiunto o meno la

convergenza; sono inoltre riportati per ogni variabile di reward: il nome, i valori di

media e varianza e i rispettivi intervalli di confidenza relativi a tutti i batch

osservati durante la simulazione.

Le classi del package oggetto di modifiche sono state invece:

• DesignerController: fa parte del package topology.designer ed è la classe controller

responsabile del disegno della topologia WSN (inclusi il posizionamento dei nodi, il

disegno dei link a seconda del metodo di propagazione selezionato, e il controllo

degli input dell’utente. Essa dialoga sia con l’interfaccia grafica implementata in

TopologyDesigner.zul, sia con la libreria ZKDiagram.jar. Le è stato aggiunto il

codice necessario a creare il componente definito dal file SaveTopology.zul per

l’archiviazione all’interno del database db_Möbius, del file compresso contenente la

topologia disegnata.

• WebTopologyController: è la classe che controlla l’interfaccia principale del tool

web-based, responsabile di due compiti: emulare il comportamento del tool desktop-

based (sia nell’interfaccia che nelle funzionalità) e gestire le scelte utente nella

modellazione e simulazione delle WSN. Le modifiche hanno riguardato la necessità

di gestire i nuovi eventi definiti nel componente Generator.zul e innescati

dall’immissione dei parametri discussi in 4.2, con i quali è possibile caratterizzare il

particolare modello di studio.

• ModelGeneratedUtil: è la classe che gestisce il modello generato o compilato con la

sinergia del tool desktop-based e di Möbius. Essa fornisce all’utente la possibilità di

salvare i modelli generati nel proprio sistema piuttosto che conservarli sul server,

sfruttando il metodo org.zkoss.zul.Filedownload.save, messo a disposizione dallo

ZK Framework.



111

Inoltre, nel caso si sia scelta, in fase di generazione, la compilazione del modello,

sarà possibile avviarne la simulazione digitando il pulsante ‘simulate’

dell’interfaccia definita dal file Model_Generated.zul controllato dalla classe, e

aspettare la visualizzazione dei rirultati.

• WebUtil: tutte le classi fin’ora analizzate, per espletare le loro funzioni, devono

dialogare con questa classe, la quale ha subito i maggiori cambiamenti poichè

contenente i metodi di ausilio a tutte le altre. Essa contiene i metodi per:

a. la creazione e il controllo (attraverso l’utilizzo del packages java.io.File), e

la restituzione dei rispettivi path, delle directory e dei file creati all’atto della

registrazione al sistema da parte dell’utente;

b. la decompressione dei file .zip delle topologie caricati dall’utente, e la

compressione del modelli generati, compilati, e simulati; in particolare allo

scopo vengono utilizzati i packages java.io.File per la manipolazione dei file

e directory, java.util.zip per la compressione/decompressione,

org.zkoss.util.media e org.zkoss.zul.Fileupload per l’upload della topologia.

Inoltre sono stati implementati ex-novo i metodi per realizzare la comunicazione

con il database db_Möbius al fine di:

• gestire le topologie di uno specifico utente attraverso le operazioni prima

descritte;

• prelevare dal database i risultati delle simulazioni così da presentarli in

formato grafico, o, se richiesto, esportarli in un file .csv che possa essere

scaricato sulla propria macchina dall’utente.



112

Capitolo 5

Un Caso di Studio

Il capitolo racchiude gli screenshot delle nuove funzionalità implementate, esse riflettono il

funzionamento descritto nel paragrafo 4.2 dedicato ai casi d’uso.

Inizialmente l’utente accede all’applicazione digitando correttamente l’indirizzo all’interno

del suo web browser. Attraverso la schermata che viene visualizzata egli può inserire e

validare le sue credenziali (il nome utente e la password con cui si sia precedentemente

registrato) così da poter accedere alle funzionalità del tool.

Fig. 5.1 – Login Page del tool



113

Dal menu principale è possibile selezionare i sottomenu sulla sinistra:

• “Topology Designer”: l’applicazione apre una schermata simile ad un software di

disegno nella quale è possibile disporre i nodi su un piano bidimensionale; nel

tracciare lo scenario topologico, l'utente può selezionare per la rete di nodi, il

modello di propagazione del segnale, il quale differisce dall'ambiente scelto, e

settare manualmente la probabilità di errore sui vari link, indicando per ognuno la

coppia di nodi che lo identifica. Terminata la configurazione della rete, mediante le

funzionalità offerte dal sottomenu sulla destra “Settings”, l’utente può decidere se

esportare la topologia appena creata oppure memorizzare i file all’interno dell’archivio

remoto. In quest’ultimo caso si aprirà una finestra che riporterà le topologie presenti nel

database con le rispettive date di immissione, e attraverso la quale sarà necessario

inserire il nome del nuovo scenario creato.

Fig. 5.2 – Disegno della topologia WSN – archivio della topologia nel database remoto



114

• “Database Management”: l’applicazione visualizza una schermata contenente la

lista dei file relativi a tutte le topologie inserite da un utente fino a un dato istante;

selezionando una particolare topologia è possibile cancellarla dall’archivio oppure

esportarla sul proprio computer, cliccando rispettivamente i pulsanti “Delete

Topology” e “Download Topology”. Inoltre l’utente può decdere di caricare un

nuovo scenario topologico, o ancora, ripulire il database da tutti i file (pulsanti

“Upload Topology” e “Clean Database”).

Fig. 5.3 – Pagina della Gestione delle Topologie – upload, download, delete, clean

• “Model Generator”: si apre una schermata che consente la caratterizzazione degli

scenari simulativi mediante l’immissione dei valori dei vari parametri del particolare

modello di fallimento. Il numero di esperimenti finale sarà determinato dalla

combinazione di tutti i valori inseriti: ad esempio indicando come algoritmi di

routing i protocolli “Multihop” e “Gossiping” e “Random” e come OS entrambi i



115

sistemi, “TinyOS” e “Mantis”, verranno generati sei esperimenti, relativo ognuno a

una delle combinazioni possibili: Multihop-TinyOS /Multihop-Mantis, etc…

Fig. 5.4 – Pagina del Failure Model WSN Generator per la generazione del modello: caratterizzazione degli scenari di simulazione

Una volta inseriti tutti gli input necessari alla generazione del modello compilato, si aprirà

una finestra che consentirà di esportare il modello così prodotto, oppure avviare la

simulazione sul server; in quest’ultimo caso una schermata visualizzerà lo stato della

simulazione.



116

Fig. 5.5 – Generazione del modello e simulazione del modello generato

Fig. 5.6 – Simulazione del modello generato – attesa dei risultati della simulazione



117

Terminata la simulazione, i risultati degli esperimenti saranno presentati all’utente

all’interno di una finestra, specificando per ognuno il nome del progetto all’interno del

quale sono stati definiti, il nome, i batch osservati, il tempo di simulazione e l’eventuale

convergenza: cliccando sul singolo esperimento è inoltre possibile visualizzare nel dettaglio

i valori delle variabili di reward del modello. Per ogni variabile vengono riportati il nome

della variabile, il numero di batch a cui si riferiscono i successivi valori di media e varianza

e i rispettivi intervalli di confidenza.

Infine l’applicazione mette a disposizione un sottomenu sulla sinistra, attraverso il quale

l’utente può decidere di esportare in un file .csv i soli risultati delle simulazioni (pulsante

“Downloads Results”), oppure l’intero modello generato, compilato e simulato.

Fig. 5.7 – Presentazione dei risultati della simulazionedel modellogenerato



118

Conclusioni e sviluppi futuri

Il presente lavoro di tesi è stato finalizzato allo sviluppo di uno strumento di supporto alla

progettazione di Wireless Sensor Network che guidi le scelte dei progettisti per prevedere,

prevenire, tollerare, e rimuovere eventuali guasti, errori o fallimenti che possano minare

l’integrità della rete o che possano deteriorarne performance e affidabilità. Il punto di

partenza è stato il tool “Web Model WSN Generator” ( basato sul generatore automatico di

modelli di fallimento [15] e sul simulatore Möbius), una Rich Internet Application (RIA)

attraverso la quale l’utente è in grado, in maniera semplice, rapida e con un esiguo carico

computazionale, di inserire o disegnare lo scenario topologico da modellare, ottenere

automaticamente un modello analitico atto ad incentrarsi sulla dependability del sistema,

scegliere le metriche da valutare e scaricare il risultato ottenuto.

Ci si è quindi concentrati su quelle che erano le funzionalità assenti nel tool:

• Consentire la gestione delle topologie disegnate o caricate dal singolo utente;

• Caratterizzare contestualmente più scenari simulativi, al fine di valutare la risposta

del sistema in diversi contesti di funzionamento;

• Simulare da remoto il modello generato ed esportarne i risultati, così da sollevare

l’utente dall’onere di dover configurare, installare e manutenere il software

necessario alla simulazione, ma soprattutto in modo che egli possa concentrarsi

sull’analisi dei risultati ottenuti, lavorando nel suo dominio di competenza;

• Mantenere i risultati delle simulazioni al fine di renderli sempre fruibili.

Allo scopo è stato aggiunto un database MySQL per il Topology Management, lo User

Management e il Simulation Management; inoltre sono state apportate modifiche che hanno



119

riguardato da una lato lo sviluppo di nuove interfacce grafiche all’interno del tool web-

based, e dall’altro lo sviluppo di nuove classi nel tool desktop-based, a partire da un reverse

engineering del tool Möbius, al fine di implementare la simulazione remota dei modelli

generati.

Le scelte di progetto nella realizzazione dell'applicazione web e delle sue nuove funzionalità

sono state mirate a rendere il risultato ottenuto quanto più estensibile possibile.

Successivamente, infatti, è possibile l’aggiunta di altri modelli di propagazione, di altri

modelli analitici e di ulteriori metriche di valutazione che possono essere aggiunti in

maniera semplice anche se si tratta di sfruttare librerie esterne o software di terze parti. Si

potrebbe inoltre pensare di sviluppare ulteriore software per consentire all’utente di

interagire direttamente con il simulatore adottato, modificandone i parametri di elaborazione

come il numero di batch osservati che è necessario garantire per poter terminare la

simulazione o ancora la frequenza di update delle stime effettuate.

Ancora, occorrerebbe integrare l’applicazione di ulteriori strumenti finalizzati alla gestione

remota dei risultati degli esperimenti delle simulazioni lanciate dall’utente, e al reporting

grafico degli stessi al fine di consentire un’analisi visiva dell’evoluzione statistica delle

metriche di valutazione adottate in funzione del numero di campioni osservati.



120

Bibliografia

[1] A. Avizienis, J. Laprie, B. Randell. “Fundamental Concepts of Computer System

Dependability”, 2001.

[2] F. Flammini, N. Mazzocca, V. Vittorini. “Modelli per l’analisi di sistemi critici”,

2009.

[3] A. M. Law, W. D. Kelton. “Simulation Modelling Analysis – Third Edition, Book,

McGraw-Hill”, 2000.

[4] J. Banks. “Introduction to Simulation”, Proceedings of the 1999 Winter Simulation

Conference.

[5] E. Egea-López, J. Vales-Alonso, A. S. Martínez-Sala, P. Pavón-Mariño, J. García-

Haro. “Simulation Tools for Wireless Sensor Networks”.

[6] R. Aquilone. “Analisi comparativa di simulatori di reti di sensori wireless”, 2006.

[7] Thomas J. Schriber, Daniel T. Brunner. “Inside discrete-event simulation software:

how it works and why it matters”, 1997.

[8] http://it.wikipedia.org/wiki/Emulatore

[9] Catello Di Martino. “Resilency Assessment of Wireless Sensor Networks: a

Holistic Approach”, 2009

[10] Isabel Dietrich and Falko Dressler. “On the lifetime of wireless sensor networks.

ACM Trans. Sen. Netw., 5(1):1–39”, 2009.

[11] M. Achir and L. Ouvry. “probabilistic model for energy estimation in wireless

sensor networks. In Proc. of first International Workshop on Algorithmic

Aspects of Wireless Sensor Networks”, 2002.

[12] F. Chiasserini and M. Garetto. “Modeling the performance of wireless sensor



121

networks. In Proc. of the IEEE Conference on Computer Communications

(Infocom ’04), page 310”, 2004.

[13] Jeffrey Stanford and Sutep Tongngam. “Approximation algorithm for maximum

lifetime in wireless sensor networks with data aggregation”, 2006.

[14] Luigi Rossi. “Realizzazione di uno strumento web-based per la simulazione remota

di reti di sensori senza filo”, 2009.

[15] Umberto Sannolo. “Generazione automatica di modelli di fallimento per la

simulazione di reti WSN”, 2008.

[16] http://www.mysql.it/why-mysql.

[17] R.Fujimoto, “Parallel and distributed simulation systems”.

[18] G. Gupta and M. Younis. “Fault-tolerant clustering of wireless sensor

networks. IEEE”, 2003

[19] S. Shakkottai, R. Srikant, and N. Shroff. “Unreliable sensor grids: Coverage,

connectivity and diameter”, 2003.

[20] Mark D. Krasniewski, Padma Varadharajan, Bryan Rabeler, Saurabh Bagchi, and Y.

Charlie Hu. Tibfit. “Trust index based fault tolerance for arbitrary data faults in

sensor networks”, 2005.

Realizzazione di uno strumento web-based per il supporto al design di Reti di Sensori ... › tesi...

Documents

Transcript of Realizzazione di uno strumento web-based per il supporto al design di Reti di Sensori ... › tesi...