tesi

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
tesi di laurea
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Anno Accademico 2007/2008
relatore
Ch.mo prof. Domenico Cotroneo
correlatore
Ing. Marcello Cinque
candidato
Gabriele D’Avino
matr. 41/3513
Alle persone che ho amato,
che amo e che amerò.
Alle persone che mi hanno
amato, che mi amano
e che mi ameranno.
Indice
Introduzione
7
Capitolo 1. Reti di sensori senza filo (WSN)
1.1
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.3
1.4
1.5
1.5.1
1.5.2
10
Reti ad hoc e reti di sensori: definizioni e differenze
Architettura delle reti di sensori
Struttura di un sensore appartenente ad una WSN
Elementi costituenti un nodo appartenente ad una WSN
Protocolli di comunicazione in una WSN
Fonti energetiche
Scenari applicativi
Progettazione di una WSN
Ambito di utilizzo in esame: reti di sensori volte al monitoraggio ambientale
Progettazione
Considerazioni sulle soluzioni hardware da utilizzare
11
13
14
16
19
23
23
26
29
31
32
Capitolo 2. Sistemi di localizzazione
2.1
2.2
2.2.1
2.2.2
2.3
2.3.1
2.3.2
2.3.3
2.4
33
Caratteristiche principali
Procedura generica di localizzazione
Ranging
Positioning
Esempi di procedure di localizzazione
CBaSA (Coarse-grained Based on Single Anchor)
APIT (Approximated Point In Triangulation)
Considerazioni relative agli algoritmi ed al loro impiego
L’algoritmo ROCRSSI
33
36
36
38
41
41
45
47
49
Capitolo 3. Il ROCRSSI++
3.1
3.2
3.2.1
3.3
3.4
54
L’algoritmo ROCRSSI+
L’idea di base del ROCRSSI++
Vantaggi introdotti dall’algoritmo ROCRSSI++
Descrizione dell’algoritmo proposto: il ROCRSSI++
Migliorie adattative introdotte dal ROCRSSI++
54
56
59
62
69
III
Capitolo 4. Realizzazione dell’algoritmo in ambiente TinyOS
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.3
4.3.1
4.3.2
4.4
4.4.1
4.4.2
4.4.3
4.4.4
Il sistema operativo TinyOS
Architettura di TinyOS
Componenti
Interfacce
Scambio dati in TinyOS
TOS_Msg
Il linguaggio NesC
Caratteristiche principali
Modello a componenti
Modello di concorrenza
Esempio pratico: applicazione TestSwingMessage
Implementazione del ROCRSSI++
Componenti principali del sistema di localizzazione
Wiring dei Componenti
Dettagli d’implementazione
File header: BeaconMsg.h
Componente RocRssiC
Componente BeaInfoStorageC
Componente TestRocRssiC
Capitolo 5. Contesto di utilizzo
5.1
5.1.1
5.1.2
5.2
5.2.1
5.3
5.3.1
5.3.2
5.3.3
Interazione con una WSN
Il tool Serial Forwarder
Interazione con java tramite MIG (Message Interface Generator)
Applicazione SuLocSense
Applicazione Surge_Reliable
Ambito di utilizzo: progetto regionale ed architettura iCAAS
Arcitettura iCAAS
Possibile soluzione WSN con stargate e comunicazione con iCAAS
Altre soluzioni proposte
Capitolo 6. Analisi dei risultati, sperimentazione e testing
6.1
6.1.1
6.1.2
6.2
6.2.1
6.2.2
6.2.3
6.2.4
Hardware e software utilizzato
La piattaforma hardware MICA2
TOSSIM e TinyViz
Sperimentazioni relative al algoritmo ROCRSSI++
Esempio di simulazione
Prove sperimentali n°1: accuratezza posizione stimata relativa al
numero di beacon e tipologia della griglia di posizionamento
Prove sperimentali n°2: confronto accuratezza ROCRSSI – ROCRSSI++
Analisi energetica
73
73
74
75
76
77
79
81
81
83
91
92
99
99
102
106
106
109
113
118
121
121
124
127
132
133
135
136
137
143
148
148
149
155
159
160
162
166
176
IV
6.2.5
6.3
Analisi dei costi
Test del sensor networks access
Conclusioni
Sviluppi futuri
Appendice A: Installazione e configurazione di TinyOS
Bibliografia
Ringraziamenti
182
188
194
195
196
200
203
V
Elenco figure
Figura 1.1
Figura 1.2
Figura 1.3
Figura 1.4
Figura 1.5
Figura 1.6
Figura 1.7
Figura 2.1
Figura 2.2
Figura 2.3
Figura 2.4
Figura 2.5
Figura 2.6
Figura 2.7
Figura 2.8
Figura 2.9
Figura 3.1
Figura 3.2
Figura 3.3
Figura 3.4
Figura 3.5
Figura 3.6
Figura 3.7
Figura 3.8
Figura 3.9
Figura 3.10
Figura 3.11
Figura 3.12
Figura 4.1
Figura 4.2
Figura 4.3
Figura 4.4
Figura 4.5
Figura 4.6
Figura 4.7
Figura 4.8
Esempio di architettura WSN
Schema a blocchi di un sensore
Alcuni esempi di nodi di una WSN
Sensor board equipaggiabile ad un sensore MICA2
Diagramma del circuito applicativo del chip radio CC1000
Esempio di una WSN divisa in cluster
Spazio applicazioni WSN
Regione ricoperta dalle antenne di ciascun anchor node
Calcolo coordinate del sensore attraverso le coordinate dell’anchor node
Errore massimo nel CBaSA
Esempio di sovrapposizione di triangoli
Valutazione della posizione del nodo incognito
Problema del “nodo indeterminato”
Grafico di confronto degli algoritmi APIT e ROCRSSI
Localizzazione tramite 3 beacon con il ROCRSSI
Esempio di regione d’intersezione disconessa
Esempio di localizzazione con tre beacon (A, B e C), nodo incognito nella
posizione S e posizione stimata E
Esempio WSN con 5 nodi beacon
Possibile evoluzione di una WSN utilizzando il ROCRSSI++
Esempio di localizzazione tramite beacon A – B –C con ROCRSSI+
Localizzazione tramite beacon A – B – C – S con ROCRSSI+
Esempio di localizzazione tramite ROCRSSI++
Flow chart che rappresenta l’algoritmo residente nei nodi beacon di 1° livello
Flow chart che rappresenta l’algoritmo residente nei nodi incogniti
Pseudo-codice procedura di localizzazione
Flow chart che rappresenta l’algoritmo residente nei beacon di 2° livello
SD relativo al caso di dichiarazione Ready/NotReady4Beacon
SD relativo al caso Alert – NotReady4Beacon
Architettura TinyOS
Esempio di user-provider interfaccia
Grafico dei componenti nella comunicazione in TinyOS
Incapsulamento messaggio utente nel TOS_Msg
Modello di un componente NesC e relativo codice
Architettura di un’applicazione in NesC
Wiring del componente principale TestSwingMessage
Wiring del componente BeaToRfm
14
15
16
17
19
21
26
42
43
44
45
46
47
49
51
52
55
57
58
59
60
61
63
65
67
68
70
71
75
77
78
81
83
85
93
96
VI
Figura 4.9
Figura 4.10
Figura 4.11
Figura 4.12
Figura 4.13
Figura 4.14
Figura 4.15
Figura 5.1
Figura 5.2
Figura 5.3
Figura 5.4
Figura 5.5
Figura 5.6
Figura 5.7
Figura 5.8
Figura 5.9
Figura 5.10
Figura 5.11
Figura 5.12
Figura 5.13
Figura 5.14
Figura 5.15
Figura 6.1
Figura 6.2
Figura 6.3
Figura 6.4
Figura 6.5
Figura 6.6
Figura 6.7
Figura 6.8
Figura 6.9
Figura 6.10
Figura 6.11
Figura 6.12
Figura 6.13
Figura 6.14
Figura 6.15
Figura 6.16
Figura 6.17
Figura 6.18
Figura 6.19
Figura 6.20
Figura 6.21
Figura 6.22
Figura 6.23
Figura 6.24
Wiring del componente RfmToBea
98
Struttura a livelli dell’applicazione realizzata
101
Wiring componente TestRocRssiC
102
Wiring del componente LocC
103
Wiring componente RocRssiC
104
Wiring del componente BeaInfoStorage
105
Esempio di scansione ed incremento dei contatori
112
Interazione con una WSN tramite server
123
Schema di funzionamento Serial Forwarder
125
GUI Serial Forwarder
126
Output relativo all’applicazione Listen
128
Funzionamento concettuale del MIG
130
Classe CoordMsg generata dal tool MIG
130
Integrazione nell’applicazione SuLocSense
131
Incapsulamento messaggio SurgeMsg
132
Architettura iCAAS
136
Contesto generale nel quale s’inserisce la rete di sensori
138
Procedimento relativo all’invio dati da WSN ad iCAAS
139
Diagramma delle classi relativo al Sensor networks access (lato client)
141
Esempio di funzionamento sistema TinyDB
143
GUI di TinyDB
144
Wiring componenti dell’applicazione TinyDB
146
Piattaforma hardware Mica2
148
Sensor board per MICA2
149
Gateway MIB510 ed adattatore seriale-USB utilizzati
150
Grafico relazione distanza-RSSI
152
Grafico del numero di pacchetti persi in relazione alla distanza tra i nodi
153
GUI di TinyViz
157
Esempio di simulazione tramite TinyViz
160
Grafico della variazione dell’errore all’aumentare del numero di beacon presenti
nella WSN
161
Diverse tipologie utilizzate
163
WSN con tre beacon (0,1 e 2) ed un nodo incognito (3), disposti in maniera casuale 163
WSN con tre beacon (0,1 e 2) ed un nodo incognito (3), disposti in griglia
164
WSN con quattro beacon ed un nodo incognito, disposti in griglia
164
WSN con quattro beacon ed un nodo incognito, disposti in maniera casuale
165
Vista TinyViz relativa alla simulazione del ROCRSSI in un WSN di 5 nodi
(3 beacon e 2 nodi incogniti)
166
Vista TinyViz relativa alla simulazione del ROCRSSI++, WSN di 5 nodi
168
Grafico del confronto degli algoritmi utilizzati sulla stessa WSN
169
Vista TinyViz relativa alla simulazione del ROCRSSI in una WSN di 9 nodi
170
Vista TinyViz relativa alla simulazione del ROCRSSI++ in una WSN di 9 nodi
171
Vista TinyViz relativa alla simulazione del ROCRSSI in una WSN di 15 nodi
171
Vista TinyViz relativa alla simulazione del ROCRSSI++ in una WSN di 15 nodi
172
Confronto riassuntivo sull’accuratezza tra ROCRSSI e ROCRSSI++
173
Grafico della percentuale dei beacon all’interno di una WSN
174
Grafico miglioramento percentuale dell’accuratezza apportato dal ROCRSSI++ per
tipologia di WSN
174
Grafico relativo al dispendio energetico ROCRSSI per minuto di esecuzione
178
VII
Figura 6.25
Figura 6.26
Figura 6.27
Figura 6.28
Grafico dispendio energetico ROCRSSI++ per minuto di esecuzione
Grafico di confronto dispendio energetico ROCRSSI - ROCRSSI++
Grafico relativo all’analisi dei costi effettuata
GUI del tester java realizzato
179
180
186
189
VIII
Elenco tabelle
Tabella 1.1
Tabella 4.1
Tabella 4.2
Tabella 4.3
Tabella 5.1
Tabella 5.2
Tabella 6.1
Tabella 6.2
Tabella 6.3
Tabella 6.4
Principali sorgenti di energia alternativa
Occupazione in memoria del S.O. TinyOS
Dettaglio dei campi nella struct TOS_Msg
Componenti e descrizione
Specifiche e descrizione della varibile d’ambiente MOTECOM
Caratteristiche tecniche Stargate Xbow
Risultati sperimentazioni sui consumi energetici
Tabella dei costi relativi ai moduli Wireless
Tabella dei costi relativi alla diverse sensor board
Tabella dei costi relativi alle stargate
22
74
79
99
125
137
176
183
184
184
IX
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Introduzione
I continui progressi tecnologici nella miniaturizzazione, nella costruzione di circuiti a
basso consumo ed i continui passi avanti fatti nel campo dell’informazione uniti all'ottimo
livello di efficienza raggiunto dai dispositivi di comunicazione ad onde radio, affermano
sempre più una nuova prospettiva tecnologica: le reti di sensori (WSN – Wireless sensor
network). Questa tecnologia nasce dal fatto che i dispositivi elettronici diventano sempre
più piccoli e complessi. Inoltre la tendenza è quella di distribuire l’intelligenza in oggetti
con potenza di calcolo relativamente più bassa ma fortemente legati tra loro, invece di
accorparla in un'unica unità costosa, ingombrante e difficilmente gestibile.
I possibili scenari di utilizzo delle WSN sono molteplici, ed in diversi ambiti. Infatti, la
necessità di monitorare diversi fenomeni fisici è un comune denominatore in diversi campi
dell’ingegneria, dello studio dell’ambiente e territorio, dell’ambito medico, dei trasporti
etc. Attualmente vengono condotti molti studi e ricerche relative alle problematiche
tipiche di una WSN che non ne consentono l’applicazione su larga scala ma vengono
utilizzate solamente per applicazioni di nicchia (ad esempio in ambito militare). Questi
problemi sono relativi alla gestione efficiente delle risorse energetiche per garantire
maggior autonomia alla rete, al protocollo d’instradamento relativo alle comunicazioni tra
nodi, alla raccolta e gestione dei dati d’interesse utente e a come risalire alla posizione
dell’origine dei dati. In particolare, un ambito in cui sono stati fatti e si faranno ancora
sforzi di ricerca, studio e sperimentazione, è quello relativo al problema della
localizzazione che può avere diverse sfaccettature e può essere utilizzato per diversi scopi
in diversi contesti. Per questo motivi molteplici sono le soluzioni proposte, e ciascuna può
essere utilizzata in un particolare contesto. Si capisce quindi, che una soluzione al
10
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
problema della localizzazione non può essere avulsa dal suo ambito reale di utilizzo. In
quest’ambito si costruirà un sistema di localizzazione per effettuare monitoraggio
ambientale ed in particolare, l’analisi dei rischi ambientali derivanti da fenomeni franosi,
prerogativa questa del progetto regionale che va sotto il nome di REMOAM (REti di
sensori per il MOnitoraggio AMbientale). Una volta presa visione dell’ambito di utilizzo,
si possono effettuare considerazioni sui parametri di progetto della WSN, scegliere
l’algoritmo di localizzazione ed elencare le possibili soluzioni per l’inoltro delle
informazioni rilevate dai sensori appartenenti alla rete. Partendo da studi relativi ad
algoritmi di localizzazione esistenti, si è passati alla progettazione ed alla conseguente
implementazione dell’algoritmo di localizzazione ROCRSSI++ che rappresenta un
miglioramento dell’algoritmo originale ROCRSSI (Ring Overlapping Comparision based
on Received Strength Signal Indicator). Il ROCRSSI fa parte della famiglia di algoritmi
range-free e cioè effettua una localizzazione basata non sul calcolo di misure reali, come
ad esempio la distanza tra due nodi, ma basata su comparazioni e costruendo relazioni
d’ordine. In quest’algoritmo, la stima della posizione del nodo incognito, si ottiene
prendendo in considerazione la regione d’intersezione di circonferenze e corone circolari.
Si è partiti da alcune migliorie introdotte e dettagliate in
fino a progettare, e poi
implementare l’algoritmo ROCRSSI++ che rappresenta un’evoluzione dell’algoritmo
originale, che introduce una serie di migliorie adattative. Considerando sempre il
particolare ambito di utilizzo in cui viene calata la WSN, si sono considerate le varie
opportunità relative alla raccolta e gestione dei dati rilevati ed infine sono state effettuate
prove sperimentali ed analisi dei risultati ottenuti. A questo proposito, si capisce che
effettuare da subito prove sperimentali reali sul campo avrebbe richiesto un costo
maggiore in termini economici e temporali, inoltre all’aumentare del numero di nodi
costituenti la rete di sensori insorgono problemi di monitoraggio di tutti i nodi
appartenenti alla rete e problemi relativi alla riprogrammazione di ciascun nodo qualora ci
fossero modifiche al codice dell’applicativo. Inoltre talvolta ci si trova di fronte a
condizioni territoriali sfavorevoli dal punto di vista dell’installazione
di una WSN
dedicata al monitoraggio ambientali. Ecco perché si è scelto di utilizzare strumenti
11
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
simulativi per studiare i comportamenti del sistema di localizzazione proposto. In
particolare, l’approccio utilizzato si articola in due fasi. Nella
prima fase vi è la
sperimentazione reale in ambiente indoor (su piattaforme hardware MICA2) relativa
all’idea che sta alla base dell’algoritmo (e cioè la variazione di RSSI in funzione della
distanza) che rappresenta dunque un parametro critico. Nella seconda fase, basandosi sui
risultati ottenuti in precedenza, vi è la sperimentazione tramite strumenti simulativi che
permettono la valutazione dell’applicazione proposta. Lo scopo di queste sperimentazioni
è quello di dimostrare la bontà dell’algoritmo ROCRSSI++ in fatto di accuratezza della
posizione stimata dai nodi incogniti e consumi energetici. Si è dimostrato inoltre che
rispetto all’algoritmo originale, il ROCRSSI++ introduce un miglioramento medio del
30 % sull’acuratezza media della stima della posizione in relazione alle topologie
considerate;
a scapito di aumento del 6% del consumo energetico. Infine è stata
effettuate un analisi dei costi relativi all’intera realizzazione della rete.
Nel primo capitolo vi è un’introduzione generica sulle reti di sensori: le caratteristiche
principali, l’architettura e l’hardware e si valuteranno i possibili scenari applicativi in
particolare quello in esame.
Nel secondo capitolo ci si sofferma sui i sistemi di localizzazione: le varie topologie, gli
esempi di tecniche di localizzazione e l’algoritmo originale ROCRSSI
Nel terzo capitolo compare la fase di progettazione dell’algoritmo proposto: l’idea di
partenza, la descrizione dell’algoritmo e le migliorie adattative introdotte.
Nel quarto capitolo si va verso l’implementazione della soluzione adottata, partendo dall’
introduzione del sistema operativo TinyOS ed il linguaggio NesC, fino a considerare i
componenti dell’applicazione creata.
Nel capitolo quinto si prenderà visione dell’intero contesto in cui si applicherà il sistema
di localizzazione progettato e si discuteranno le possibili soluzioni riguardanti la raccolta e
la gestione dei dati rilevati.
Nel capitolo sesto infine, verranno analizzati i risultati ottenuti dalle prove sperimentali
effettuate, tramite l’utilizzo di strumenti simulativi e si parlerà del testing effettuato.
12
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Capitolo 1: Reti di sensori senza filo (WSN)
Questo capitolo si prefigge lo scopo d’introdurre al lettore il mondo delle reti di sensori
senza filo. Le Wirless sensor networks (WSN) sono particolari reti caratterizzate da un
elevato numero di dispositivi elettronici, che possono avere diverse nomenclature (nodi,
mote, sensor etc.), i quali grazie ai progressi raggiunti negli ultimi anni nel campo della
tecnologia microelettro-meccanica (MEMS) permettono di integrare in un unico blocco di
silicio sensori in grado di rilevare grandezze fisiche e anche di svolgere delle elaborazioni.
La nascita delle WSN è dovuta ad un’idea di base che prevede l’utilizzo di un numero
elevato di nodi, che consentono di effettuare rilevazioni ed elaborazioni con una maggiore
precisione e frequenza rispetto al caso d’uso di un unico sensore, in grado di fornire
prestazioni migliori a scapito però di costi superiori. Si intuisce che queste differenze sono
le stesse che intercorrono tra sistemi distribuiti e sistemi centralizzati.
Nei paragrafi successivi si introdurranno le reti di sensori viste come particolari reti ad
hoc, verranno definite, se ne descriveranno poi le caratteristiche principali (architettura,
composizione dei nodi e protocolli di comunicazione) ed i requisiti che esse devono
soddisfare, dopodichè si considererà l’importanza della progettazione per il tipo di
applicazione ed infine si elencheranno i possibili scenari di utilizzo, in particolare quello
preso in considerazione ossia relativo alla possibilità di costruire una rete di sensori per il
monitoraggio ambientale ed in particolare lo sviluppo di un sistema di localizzazione
inserito in territori considerati potenzialmente a rischio di frane, per valutare gli
spostamenti del terreno al fine di prevenirle.
13
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
1.1 Reti ad hoc e reti di sensori: definizioni e differenze
Una rete mobile ad hoc (Mobile Ad-hoc NETwork - MANET) può essere considerata
come un sistema autonomo di nodi connessi tramite collegamenti senza filo. Le reti ad hoc
vengono costruite all'occorrenza ed utilizzate in ambienti estremamente dinamici e
possono operare senza l'aiuto di una infrastruttura preesistente, come ad esempio dopo
catastrofi naturali, durante conflitti militari o in altre situazioni d'emergenza.
Generalmente il canale di comunicazione è a radio frequenza, anche se esistono altri tipi di
connessioni come le connessioni ottiche, sfruttando lo spettro della luce infrarossa o la più
recente tecnologia laser. In genere la procedura di configurazione di un nodo all’interno di
una rete ad hoc, consiste nella attuazione di una serie di operazioni che permettono al nodo
in questione di ottenere un proprio indirizzo all'interno della rete, e di comunicare ai vicini
la sua presenza, qualora i protocolli di instradamento adottati lo richiedano. Questa
procedura va ripetuta nel tempo, in quanto per definizione la topologia di questo tipo di
rete è in continua mutazione.
Si è fatta quest’introduzione sulle reti ad hoc perché spesso c’è la tendenza di classificare
le reti di sensori come casi particolari di reti ad hoc. Bisogna però fare attenzione in
quanto le caratteristiche principali delle reti ad hoc non si prestano del tutto a soddisfare le
esigenze di una rete di sensori. Infatti, non possiamo limitarci a considerare le WSN
(Wireless sensor network) semplicemente delle reti multihop su larga scala, per
sottolineare quest’aspetto si evidenziano le principali differenze tra le comuni reti ad hoc e
le reti di sensori:
I nodi di una rete spesso e volentieri sono soggetti a guasti per questo talvolta se
ne usa una quantità superiore per fare fault tollerance
Il numero dei nodi e la loro densità dipende dalla tipologia del fenomeno da
rilevare
A volte può capitare che dato l’elevato numero di nodi che componente un rete
di sensori, l’identificativo (ID) non sia univoco ma vi è una suddivisione in
gruppi dei nodi appartenenti alla rete ed è poi in questi gruppi che è garantita
l’univocità dell’ ID
14
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
In una rete ad hoc solitamente la comunicazione è di tipo peer to peer mentre in
una WSN il flusso di dati è asimmetrico in quanto tutti i nodi solitamente inviano
le informazioni verso l’interfaccia utente (nodo sink o base-station)
Visto che in una WSN l’energia e le capacità elaborative sono limitate, spesso i
criteri di progettazione tendono a favorire il risparmio energetico e la non elevata
complessità di calcolo, a scapito però della qualità del servizio (QoS)
In genere si utilizza una WSN quando si da poca importanza ai dati rilevati da un
singolo sensore ma piuttosto si vuole avere una visione d’insieme del sistema. Se
ad esempio, un nodo si guasta, ma la rete ha un numero di sensori piuttosto
elevato relativamente allo scopo per cui si è costruita, è molto probabile che il
guasto non influenzi il funzionamento del sistema. Questa viene chiamata
centralità dei dati.
Dopo aver visto le principali differenze tra reti ad hoc e reti di sensori o WSN, al fine di
definire una WSN, si darà preliminarmente una definizione di sistema distribuito:
Un sistema distribuito è un sistema formato da un insieme di componenti dislocati su vari
calcolatori connessi tramite una rete, capaci di comunicare e talvolta di coordinare le loro
azioni attraverso lo scambio di messaggi. Inoltre un sistema distribuito è caratterizzato da:
Concorrenza dei suoi componenti
Appartenenza a diversi domini dei suoi componenti
Da meccanismi di sincronizzazione e interazione basati sullo scambio di
messaggi.
Dalla possibilità di guasti indipendenti dei suoi componenti che possono influire
o no sul funzionamento totale
Si può definire una rete di sensori come un sistema distribuito costituito da un insieme di
nodi capaci di eseguire elaborazioni, comunicare tra loro attraverso protocolli di rete
multihop ed ospitare diversi componenti.
15
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
1.2 Architettura delle reti di sensori
Una WSN può anche essere considerata come un sistema intelligente ed autogestito di
rilevazione dove i componenti principali sono i nodi, o sensori, che possono avere
funzioni anche molto differenti. Gli elementi della rete possono essere collocati all'interno
dell'area da monitorare o nelle immediate vicinanze (dipende dal contesto applicativo).
Una delle caratteristiche architetturali più importante è che tipicamente non è prevista
nessuna infrastruttura fissa a cui si possano appoggiare nodi, ecco perché una WSN può
essere considerata come un esempio particolare di rete ad hoc. A seconda della centralità o
meno del sistema distribuito le comunicazioni sono dirette ad un unico nodo che elabora le
informazioni raccolte, oppure distribuite tra i nodi se questi hanno la capacità e
l’intelligenza sufficienti ad elaborare i dati autonomamente. Bisogna fare una
precisazione, nel paragrafo precedente si è accennato all’asimmetria del flusso informativo
riferita però ai messaggi contenenti informazioni di particolare rilevanza nell’ambito
considerato, in quanto solitamente questi messaggi sono tutti destinati al nodo sink (o base
station o gateway) che s’interfaccerà con il mondo esterno alla rete di sensori. In figura
1.1 è riportata una possibile architettura di una rete WSN. Dalla figura si evince che
all’interno della WSN esiste un nodo particolare ossia il nodo sink (in figura rappresentato
dal quadrato rosso), che rappresenta il nodo dedicato alla raccolta dei dati e consente
l’interfacciamento con il mondo esterno. Inoltre in figura è mostrato un esempio di come
un messaggio può attraversare la rete attraverso un routing multihop da un nodo generico
fino al sink, a cui può essere direttamente collegato l'elaboratore dell'utente oppure
un'interfaccia con altre WSN o altre reti eterogenee, per esempio Internet (esempio
mostrato in figura). Si possono prevedere più stazioni di raccolta dati intermedie,
eventualmente anche mobili, come ad esempio un utente dotato di PDA (Personal Digital
Assistant). Vi è la possibilità di percorrere la rete nel percorso inverso, infatti mediante
l'applicazione di gestione della rete, l’utente è in grado di inviare istruzioni ad ogni nodo
della WSN o definire un comportamento globale di essa.
16
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 1.1 – Esempio di architettura WSN
Inoltre come detto in precedenza, ed evidenziato dalla figura, non è detto che i nodi
costituenti una WSN abbiano tutte le stesse funzionalità o la stessa rilevanza in ambito
applicativo, anzi talvolta possono seguire una gerarchia o avere una priorità associata ad
essi, questi accorgimenti permettono, qualora ce ne fosse bisogno. una classificazione dei
nodi all’interno della WSN.
1.2.1 Struttura di un sensore appartenente ad una WSN
Può risultare difficile presentare in maniera esaustiva la struttura di un singolo sensore
componente una WSN, vista la loro varietà. Si può però cercare di costruire uno schema
17
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
che illustri logicamente i blocchi funzionali che rappresentano le parti principali del
sensore. Questo schema è rappresentato in figura 1.2
Figura 1.2 – Schema a blocchi di un sensore
Analizziamo i blocchi della figura:
Unità di controllo (CPU): rappresentata solitamente da un microcontrollore e
svolge tutte le funzioni di gestione, tra cui la traduzione dei segnali elettrici
inviati dai trasduttori, la gestione degli attuatori ed il controllo delle
comunicazioni
Memoria: rappresenta un blocco di memoria volatile che funge da ausilio
all’esecuzione
Trasduttori: che possono essere più di uno, trasformano una qualche grandezza
fisica (temperatura, luminosità, pressione etc…) in un segnale elettrico
Attuatori: che possono essere più di uno e di varia natura (Leds, soner acustici
etc..)
Unità di comunicazione: consente la comunicazione inter-nodo tramite un mezzo
18
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
trasmissivo (di solito radio oppure ottico )
L'unità di controllo solitamente è formata da componenti a bassa potenza di calcolo e
bassi consumi energetici, per consentire consumi ridotti. Proprio il risparmio energetico è
oggetto di numerose ricerche, in quanto esigenza essenziale per la distribuzione su larga
scala delle WSN. Esistono alcuni semplici accorgimenti per ottenere un risparmio
energetico significativo che consistono nello sfruttare i diversi stati energetici in cui si può
trovare il sensore. Ad esempio si possono spegnere i trasduttori e la radio quando non sono
utilizzati, e soprattutto progettare algoritmi di comunicazione efficienti. Nel prossimo
sottoparagrafo si illustreranno nel dettaglio i componenti prima descritti.
1.2.2 Elementi costituenti un nodo appartenente ad una WSN
Esistono diverse piattaforme hardware di nodi per WSN, alcuni esempi sono mostrati in
figura 1.3
Figura 1.3 – Alcuni esempi di nodi di una WSN
19
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Analizziamo i componenti di un nodo nel dettaglio
SENSORI
Erroneamente a volte si definisce sensore l’intero nodo, in quest’ambito invece s’intende
quello che a volte viene denominata sensor board, il cui compito è trasformare la
grandezza fisica acquisita in un segnale elettrico che possa essere elaborato. Riferendoci
allo schema a blocchi di figura 1.2, la sensor board si può considerare come un insieme di
trasduttori. In figura 1.4 è illustrata una sensor board relativa ai sensori Mica2 della
famiglia CrossBow.
Figura 1.4 – Sensor board equipaggiabile ad un sensore Mica2
Come già detto, un nodo può disporre di più sensori, anche di grandezze fisiche diverse,
per soddisfare le esigenze in ambito applicativo; si possono avere ad esempio sensori di
luminosità, pressione, temperatura, prossimità, e così via. Ad ogni grandezza fisica
rilevata, è associata un tipo di elaborazione. Si supponga, ad esempio, di dover
digitalizzare un particolare segnale analogico: la rapidità con cui esso evolve determina la
velocità di campionamento necessaria per acquisirlo correttamente, mentre la precisione
con cui lo si vuol rappresentare stabilisce il numero di bit della parola associata ad ogni
campione. E’ intuitivo comprendere che all'aumentare della velocità di campionamento e
del numero di bit del convertitore analogico digitale, si ha un incremento dei consumi.
UNITA’ DI ELABORAZIONE
La presenza di una CPU permette di equipaggiare il nodo della intelligenza necessaria ad
elaborare la grandezza misurata e gestire le comunicazioni. L’intera elaborazione della
grandezza misurata viene fatta in modo numerico. La maggior parte dei sensori ha un
blocco di conversione analogico-digitale (ADC), che s’interpone tra la fase di acquisizione
20
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
del segnale e la sua elaborazione. Il ruolo della CPU può essere svolto da diverse tipologie
di circuiti logici. Comunemente la scelta ricade su un microcontrollore a basso consumo,
che utilizza blocchi di memoria RAM e ROM, ma è possibile impiegare anche un FPGA
(Field Programmable Gate Array), un DSP (Digital Signal Processing) o un ASIC
(Application Specific Integrated Circuit), non solo in sostituzione ma anche in
affiancamento al microprocessore per diminuirne il carico di calcolo aumentando però i
consumi. La gestione e l'utilizzo delle memorie è un'ulteriore fonte di consumo, per questo
motivo la loro dimensione deve essere opportunamente progettata. Un ulteriore compito
tipico del microprocessore, che introduce criticità dal punto di vista dei consumi
energetici, è la verifica dell'effettiva necessità di utilizzare le risorse, infatti per preservare
la carica della batteria il nodo deve disattivare tutti i dispositivi come chip radio, timer,
oscillatori e quant'altro, ogni volta che questi non sono indispensabili per le attività del
nodo stesso.
RICESTRASMETTITORE
Le reti di sensori sono pensate per un essere utilizzate in aree geografiche abbastanza
ampie, il cui territorio non sempre è pianeggiante e privo di ostacoli, quindi una
connessione via cavo sarebbe impensabile a causa degli ingenti costi dovuti ad un
cablaggio strutturato. L'unica soluzione possibile è adottare un sistema di collegamento
wireless, tipicamente realizzato via radio ma soluzioni alternative sono rappresentate da
comunicazioni via ultrasuoni o comunicazioni ottiche. Solitamente tra tutti i componenti
del nodo, il chip radio è il dispositivo che consuma la maggior parte dell'energia, ecco
perchè è indispensabile che resti attivo solo per il tempo strettamente necessario alla
comunicazione. Per realizzare un sistema di comunicazione robusto ha particolare
rilevanza lo studi relativo alla banda di frequenza utilizzata. La soluzione più semplice che
è poi quella che quasi sempre è adottata, è l'utilizzo di frequenze “libere" (ISM), cioè non
adibite a particolari servizi standard. Solitamente sono utilizzate come portanti le
frequenze a 868 MHz e 2.5 GHz. In figura 1.5 è rappresentato il modello del chip radio
CC1000 (1000 MHz) utilizzato sui sensori Mica2 della famiglia CrossBow.
21
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 1.5 – Diagramma del circuito applicativo del chip radio CC1000
1.2.3 Protocolli di comunicazione in una WSN
Nella progettazione ed implementazione dei protocolli di comunicazione in una rete di
sensori, si può fare riferimento ai primi tre livelli dello stack protocollare ISO/OSI, ossia
(livello fisico, livello collegamento dati, livello rete):
LIVELLO FISICO
Il livello fisico si occupa dell'interazione tra il flusso di bit in arrivo dai livelli superiori e il
mondo reale. In questo livello si provvede a trasformare l'informazione in un segnale
elettrico o di altra natura e inserirla nel canale di trasmissione. In un’ ottica di risparmio
energetico sono continuamente allo studio tecniche di modulazione e codifica efficienti.
LIVELLO COLLAGAMENTO DATI
Il livello di collegamento dati va in supporto al livello fisico e si fa garante della sua
affidabilità. Si occupa di diversi aspetti, tra cui i più importanti sono il controllo del flusso,
il controllo di errore e, fondamentale nelle reti senza fili, il controllo di accesso al mezzo
di comunicazione (MAC).
Il MAC (Media Access Control ) si occupa della comunicazione e dello scambio dei dati
(a livello logico) tra i nodi. Siccome il canale di comunicazione rappresenta una risorsa
22
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
condivisa da tutti i nodi appartenenti alla rete, è necessario disporre di un protocollo di
accesso al mezzo che garantisca a tutti di poter disporre del canale. Il MAC si occupa di
gestire le collisioni ed inoltre fa fronte alla mobilità della rete e quindi alla mutevolezza
della topologia, a seconda degli algoritmi di instradamento che adotta. Tra i sistemi di
accesso multiplo al mezzo analizziamo il CSMA (Carrier Sense Multiple Access) che
rappresenta quello più semplice e più frequentemente utilizzato. Esso si compone di una
fase di ascolto, prima della trasmissione, che stabilisce se altri nodi impegnano il canale;
qualora questo fosse libero il nodo in questione inizia la fase di trasmissione. Oltre al
CSMA altre possibili soluzioni di gestione dell’accesso al canale di comunicazione sono
di seguito riportate (per dettagli fare riferimento a [5],[8]):
Time Division Multiple Access (TDMA): la multiplazione a divisione di tempo
invece consiste nel suddividere l'asse temporale in periodi denominati slot. Ad
ogni trasmettitore verrà associato uno slot, durante il quale trasmettere.
Frequency Division Multiple (FDMA): la multiplazione a divisione di frequenza
consiste nel suddividere la banda utile in un certo numero di sottobande non
sovrapposte, e assegnarne una a ogni trasmettitore.
Code
Division
Multiple
Access
(CDMA):
consiste
sostanzialmente
nell'assegnazione di una parola di codice differente a ciascun utente del canale.
Tale codice, combinato con il segnale da trasmettere, permette al ricevente di
estrarre dall'insieme di tutti i segnali ricevuti, quello inviato da ogni singolo
nodo, a patto di conoscerne la parola di codice relativa.
Se si pensa alle caratteristiche peculiari di una WSN come ad esempio che potrebbero
essere composte da un numero elevatissimo di sensori, risulta facile comprendere che non
è possibile assegnare uno slot temporale o una frequenza diversi ad ogni singolo sensore
(soluzioni rispettivamente relative a TDMA e FDMA). Nelle applicazioni pratiche le
risorse disponibili vengono affidate a gruppi di sensori, che adoperano poi metodi quali il
CSMA per limitare le collisioni.
23
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
LIVELLO RETE
Una delle funzionalità primarie di questo livello è la gestione dell'indirizzamento logico e
l'instradamento (routing) dei pacchetti. In una WSN l'indirizzamento può seguire una
tecnica particolare, per cui la rete viene partizionata in gruppi (cluster ) di nodi, a cui viene
assegnato un indirizzo univoco. In ogni cluster c’è un coordinatore che raccoglie i dati
provenienti dai nodi e li indirizza al centro di raccolta o eventualmente al coordinatore del
gruppo di cluster a cui appartiene. In questo modo lo spazio degli indirizzi viene
salvaguardato, pur mantenendo la possibilità di riferirsi a porzioni determinate della rete.
In figura 1.6 è rappresentato un tipico esempio di applicativo di tutto ciò che è stato detto.
Qui si rappresenta infatti, un’ applicazione pratica dove in una rete di grandi dimensioni, si
raggruppano i sensori in cluster. I nodi cerchiati in rosso agiscono da coordinatori per i
cluster di primo livello, mentre i nodi cerchiati in blu agiscono da coordinatori per i cluster
di secondo livello (quelli più grandi esterni) fino a raggiungere in sink e quindi il centro di
raccolta dati.
Figura 1.6 – Esempio di una WSN divisa in cluster
Per quel che riguarda gli algoritmi di routing invece essi si possono suddividere in tre
principali categorie:
24
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Proactive: questo tipo di algoritmi si basano sul fatto che ogni nodo conosca le
informazioni di instradamento utili a raggiungere ogni altro nodo. Ogni
componente della rete deve avere a disposizione una tabella che contenga tutti i
cammini minimi per le possibili destinazioni. Naturalmente queste informazioni
vanno aggiornate nel caso avvengano riconfigurazioni della rete ma si possono
aggiornare anche quando si verifica un guasto ad uno dei nodi (quindi escludere
tale nodo dalle tabelle) o in condizioni di traffico inteso e possibili congestioni
(magari trovando percorsi alternativi).
Reactive: questi algoritmi invece prevedono che i nodi, ad ogni trasmissione,
determinino il cammino minimo, o almeno qual è il nodo successivo da
raggiungere. Il principale vantaggio è costituito dal fatto che in questo caso non
deve essere memorizzata la tabella d’instradamento e ciò consente un risparmio
di memoria a discapito però evidentemente di un incremento nei tempi di
propagazione dei messaggi.
Tecniche ibride: queste tecniche sono basate su una ricerca del cammino
ottimale, quindi un comportamento simile alle tecniche reactive, ma salvano
queste informazioni costruendo una tabella, e questo comportamento è tipico
delle tecniche proactive. Tali informazioni possono essere utilizzate per ridurre i
ritardi dovuti alle ispezioni della rete.
Bisogna fare un’opportuna precisazione, infatti la stratificazione tipica del modello
relativo allo stack protocollare ISO/OSI non è perfettamente scalabile sulle WSN. Infatti
in questo tipo di reti il protocollo di instradamento (che nel modello ISO/OSI è ua
prerogativa del livello rete (livello tre)) deve necessariamente anche inglobare il controllo
del MAC e dello strato fisico,
proprio per venire incontro ad uno dei requisiti
fondamentali delle WSN ossia ottimizzare i consumi energetici, in questo caso si parla di
approccio “cross-layer”
25
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
1.2.4 Fonti energetiche
Da sempre e ovviamente non solo nella progettazione di una rete di sensori, l’aspetto più
esposto ad attività di studio e sperimentazioni, è volto alla ricerca di fonti di energia
alternative le cui caratteristiche principali siano durata, economicità e potenza. Nella
tabella 1.1 sono elencate le varie possibilità:
Tabella 1.1 – Principali sorgenti di energia alternativa
Ovviamente non si tiene conto della soluzione che possiamo considerare standard cioè
quella di equipaggiare i nodi della rete con batterie ricaricabili. Invece risulta essere molto
interessante lo sfruttamento dell'energia solare, da abbinare ad una batteria tampone, che
possa sopperire ai momenti di scarsa intensità luminosa. Bisogna fare ovviamente, anche
un discorso relativo alla convenienza che è dipendente dall’ambito applicativo, ma
soprattutto bisogna tener presente che queste tecnologie saranno utilizzabili non appena i
sensori avranno dimensioni tali da consentire correnti così basse; tenendo sempre presente
che in ogni caso il modulo di comunicazione necessita di una certa potenza.
1.3 Scenari applicativi
Gli ambiti applicativi all’interno dei quali possono essere calate le WSN sono molteplici
ed eterogenei. Per cercare di essere concisi ma comunque il più possibile esaustivi, si
divideranno le applicazioni possibili per le reti di sensori, in cinque categorie principali:
Ambito militare
Ambito ambientale
Ambito sanitario
26
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Ambito sociale e sportivo
Spazi intelligenti
Vediamoli nel dettaglio.
AMBITO MILITARE
E’ sicuramente l’ambito in cui le WSN trovano più applicazioni in quanto la loro
tolleranza ai guasti e la capacità di auto organizzarsi li rendono particolarmente adatti a
quest’ambito. Ecco perché come spesso accade, questo è stato il primo ambito in cui sono
state utilizzate. Sono davvero tantissime le applicazioni, infatti le reti di sensori
potrebbero: aiutare nella bonifica di territori considerati a rischio in quanto minati o
esposti a qualche tipo di contaminazione (chimica o biologica); essere utilizzate
nell’individuare obiettivi strategici e guidare nell’attacco le cosiddette “armi intelligenti”;
essere usati in ambienti urbani per rilevare attacchi terroristici che impiegano sostanze
radioattive o batteriologice; infine possono essere utilizzate per rilevare informazioni
riguardanti lo spostamento dei nemici o la posizione in cui è avvenuta un’esplosione.
Ovviamente sono stati riportati solo alcuni esempi, le applicazioni possono essere le più
disparate. Si capisce già che per questo tipo di applicazioni c’è bisogno di qualche
accorgimento in più a quelli fatti precedentemente, ad esempio in quest’ambito sarà
sicuramente un parametro di progetto importante l’utilizzo di una comunicazione sicura tra
i nodi della rete, per evitare attacchi maliziosi rivolti alla rete stessa. Ecco perché in
seguito ci sarà un paragrafo dedicato ai parametri di progetto che fornirà un idea su come
progettare una WSN a seconda dell’ambito di utilizzo.
AMBITO AMBIENTALE
Possiamo pensare ad un impiego delle WSN per rilevare o monitorare diverse situazioni
ambientali come: incendi forestali, stato degli oceani, condizioni in cui crescono le colture
o gli allevamenti, livelli d'inquinamento di un territorio o di una metropoli etc.
27
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
AMBITO SANITARIO
In campo sanitario le reti di sensori possono essere impiegate per realizzare interfacce per
disabili, tracking e monitoraggio di pazienti e dottori all'interno di un ospedale e
soprattutto monitoraggio a distanza di dati fisiologici umani. Ad esempio quest’ultimo tipo
di applicazione viene utilizzata dalle agenzie spaziali per monitorare le condizioni fisiche
degli astronauti.
AMBITO SOCIALE E SPORTIVO
L'utilizzo di reti di sensori potrebbe aiutare la società a eliminare tutte quelle barriere che
impediscono ancora oggi a portatori di handicap di poter fruire dei servizi messi a
disposizione di ogni cittadino. Si potrebbe pensare a mezzi di locomozione auto
direzionabili, a sistemi di localizzazione che permettano a utenti non vedenti di muoversi
in sicurezza e raggiungere le proprie destinazioni. Lo stesso sistema di localizzazione e
guida potrebbe risultare utile per indirizzare visitatori all'interno di grandi stabilimenti. Si
può pensare inoltre, sempre grazie ad un sistema di localizzazione, guide turistiche
automatizzate che a seconda del luogo in cui si trova il turista, danno le relative
informazioni. Si potrebbe utilizzare una rete di sensori atti alla sorveglianza di spazi ed
edifici per prevenire crimini come furti e rapine. Ultimamente si utilizzano reti di sensori
anche in ambito sportivo, ad esempio, nel tennis vengono utilizzate come supporto al
sistema denominato Hawk’s eye, questo sistema unisce i dati provenienti da un insieme di
telecamere su campo con i dati rilevati dai sensori, creando un sistema di localizzazione
che consente ai giocatori di verificare se effettivamente la pallina è rimbalzata dentro o
fuori il campo. Si deve tener presente però che queste sono tecnologie sono utilizzabili
solo in particolari ambiti in quanto richiedono costi per alcuni versi insostenibili, data la
complessità e la precisione che questi sistemi devono avere.
SPAZI INTELLIGENTI
Un ambiente in grado di riconoscere l'utente presente al suo interno può predisporre tutta
una serie di servizi personalizzati differenti a seconda di chi è l'ospite. Su questo concetto
28
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
è basato l'home automation o del museo interattivo.
In figura 1.7 è riportato lo spazio relativo agli ambiti applicativi delle WSN. Come si può
facilmente comprendere, sicuramente la versatilità dei sensori rappresenta un pregio in
quanto questi si prestano a svariate applicazioni, ma d'altro canto questo comporta delle
difficoltà nella progettazione sia hardware che software, in quanto l’eventuale
standardizzazione della piattaforma non è cosa banale dato che i requisiti richiesti sono
fortemente legati allo specifico utilizzo. Nel prossimo paragrafo si cercheranno di
specificare quali possono essere i parametri di progetto per tipologia di applicazione
Figura 1.7 – Spazio applicazioni WSN
1.4 Progettazione di una WSN
Nel progettare una WSN bisogna porre particolare attenzione a due aspetti fondamentali:
la progettazione della struttura e dei protocolli di comunicazione, in quanto bisogna gestire
al meglio le limitate ed eterogenee risorse di un sensore. Risulta sempre molto difficile
riuscire a fornire degli standard di progetto per una WSN in quanto queste vengono quasi
sempre progettate, sviluppate e realizzate in maniera molto diversa dipendente dallo
29
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
specifico ambito applicativo. Si opera in questo modo proprio perché i contesti di utilizzo
sono veramente svariati e richiedono particolari ottimizzazioni. Proprio la possibilità di
ottimizzare la rete di sensori si paga in termini di complessità di progettazione e tempi di
sviluppo per una specifica applicazione. Di seguito sono riportati i principali aspetti da
considerare quando si va a progettare una rete di sensori.
COSTO
Affinché sia effettivamente possibile l’impiego di una rete si sensori per un’applicazione
reale, c’è bisogno che questa soluzione sia conveniente rispetto a soluzioni alternative.
Attualmente i costi per ogni nodo si aggirano intorno agli 80 dollari a nodo, a questo
vanno aggiunti costi relativi ai moduli come alimentaori, attuatori, sensor board, ed altri
moduli particolari come ad esempio il GPS (Global Positioning System). Inoltre bisogna
prevedere costi d’installazione e manutenzione della rete.
CONNETTIVITA’
Di solito si parla di rete connessa quando tutti i nodi, di una rete o di una sottorete, sono
in grado di comunicare con tutti gli altri appartenenti alla stessa rete o sottorete. In una rete
di sensori non è detto che ciò accada in quanto molto spesso i nodi sono in lunghi periodi
d’inattività, per risparmiare energia. Questa sorta di connettività ad intermittenza deve
essere opportunamente considerata nella progettazione del protocollo di comunicazione e
nell’inoltro delle informazioni.
HARDWARE
La limitata capacità elaborativa e la limitata memoria, costituiscono un grosso limite alla
complessità degli algoritmi di comunicazione ed applicativi (come può essere l’algoritmo
di localizzazione). Inoltre ogni sensore deve essere di dimensioni piuttosto piccole visto la
possibilità di utilizzo in ambienti più disparati. Non è banale garantire le dimensioni
ridotte di un sensore soprattutto considerato il fatto che bisogna munirlo almeno di
antenna ed alimentazione.
30
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
POSIZIONAMENTO DEI NODI
La disposizione dei nodi rappresenta un parametro di progettazione veramente cruciale,
infatti il posizionamento può influire sulle prestazioni del sistema, sulla comunicazione e
anche sulla localizzazione dei sensori (come si vedrà in seguito). Di solito negli scenari
dove è possibile pianificare il posizionamento, la rete di sensori avrà sicuramente una
gestione più efficiente. Quando invece ciò non è possibile, ad esempio quando si lanciano
sensori da un aereo e quindi avranno un posizionamento casuale, allora talvolta si
sovradimensiona la rete, e quindi diventa importante valutare quale sia il numero di
sensori da utilizzare, per garantire comunque una certa qualità del servizio.
MOBILITA’
In alcuni casi tutti i sensori della rete, o solo alcuni, possono essere parte di un dispositivo
mobile, si parla in questo caso di MANET (Mobile Ad-hoc NETwork); in genere le WSN
sono caratterizzate da un basso grado di mobilità. E’ opportuno specificare che sia la
velocità di spostamento, sia il grado di mobilità influiscono sulla progettazione dei
protocolli.
SCALABILITA’
Il numero di nodi è estremamente variabile: da qualche decina a diverse migliaia. Quindi
tutte le soluzione adottate devono essere scalabili considerando questo intervallo.
ELABORAZIONE IN TEMPO REALE
Alcune applicazioni come il tracking o il puntamento di oggetti richiedono
un’elaborazione in tempo reale. La rapidità di processazione dei dati e la capacità di
sincronizzazione dei nodi per l’invio e la ricezione delle informazioni rappresentano in
quest’ambito, fattori critici.
SICUREZZA
31
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Una WSN può essere soggetta a molteplici tipi di attacco alla sicurezza. Oltre ai problemi
d’intercettazione e d’interferenza, che affliggono le reti radio, le WSN sono soggette a
forme d’intrusione come il tempering che nell’introduzione nella rete di sensori estranei
che la rete potrebbe accettare come propri, consentendo l’alterazione o l’intercettazione
dei messaggi scambiati all’interno della rete.
CONSUMO ENERGETICO
Lo scenario tipico di una WSN, non permette solitamente, di allacciare i nodi ad una rete
di distribuzione elettrica. Visto che il cablaggio ad hoc comporterebbe talvolta un
insostenibile aumento di costi, garantire ai nodi un tempo di vita elevato, è una priorità che
può giustificare la riduzione delle prestazioni. Non va dimenticato inoltre, che le
operazioni di sostituzione delle sorgenti di alimentazione, se possibile, in genere è molto
costosa sia in termini economici sia in termini di tempo. Ecco perché la massima
efficienza energetica di un’applicazione risulta essere la prerogativa principale in una rete
di sensori.
Considerati tutti questi aspetti nel paragrafo successivo, oltre a definire il particolare
ambito di utilizzo in esame, si definiranno anche quali possono essere i parametri di
progetto delle reti di sensori calate in tale ambito.
1.5 Ambito di utilizzo in esame: reti di sensori volte al monitoraggio
ambientale
Occupiamoci ora di un particolare contesto di utilizzo delle reti di sensori senza filo.
Innanzitutto definiamo il progetto a cui si è partecipato ed il suo scopo. Il progetto
REMOAM
(REti di sensori per il MOnitoraggio dei rischi AMbientali) si pone la
prerogativa di monitorare i rischi ambientali e strutture civili tramite reti di sensori senza
filo. Anche se il progetto si focalizza in modo particolare rischi ambientali derivanti dai
fenomeni franosi, ampiamente diffusi sul territorio regionale e nazionale, l’obiettivo è
quello di concepire una soluzione sufficientemente generale e tale da essere applicata ad
32
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
ambiti diversi.
Si capisce fin da subito che per venire incontro alle esigenze del progetto, si deve
progettare una WSN che non solo rispetti i principali parametri di progetto visti in
precedenza (come ad esempio consumo energetico ridotto, scalabilità, costi contenuti etc.)
ma deve essere abbastanza eterogenea per permettere l’implementazione di diverse
funzionalità. Un servizio fondamentale da cui l’applicazione, nell’ambito descritto, non
può assolutamente prescindere, è senza dubbio il servizio di localizzazione. Infatti per
rilevare gli spostamenti del terreno che possono preavvisare un fenomeno di tipo franoso,
si può pensare di utilizzare un rete di sensori i cui nodi siano in grado, periodicamente, di
autolocalizzarsi; in modo da effettuare un monitoraggio che potrebbe consentire la
previsione di una frana. Si capisce, quindi, che avere la possibilità di dotare i nodi dell’
”intelligenza” necessaria a permettere l’autolocalizzazione, significherebbe la fornitura di
un servizio indispensabile per questo tipo di applicazioni. Una volta fornito il servizio di
localizzazione, bisogna capire quali possono esser le azioni che si devono intraprendere in
seguito alle rilevazioni eseguite. Sicuramente dopo che i nodi effettuano tali rilevazioni,
provvederanno ad inoltrarli al loro punto d’accesso (il nodo sink) in modo da destinarli
verso il mondo reale. Questo forwarding delle informazioni è reso possibile grazie ai
protocolli prima considerati ed alle caratteristiche tipiche di una WSN tra le quali
ricordiamo, l’implementazione del multihop. Dotare i nodi di un servizio di localizzazione
è indispensabile ma se si vuole rendere la rete di sensori abbastanza generica affinché
possa essere utilizzata in altri contesti ambientali, si deve implementare un’applicazione
che permetta la rilevazione e allo stesso tempo, l’inoltro delle informazioni rilevate verso
postazioni dedicate alla raccolta e allo studio di esse. In definitiva, come verrà mostrato
più in dettaglio nel capitolo 5, si considera che l’applicazione da sviluppare e che verrà poi
installata su ciascun nodo della WSN, sarà composta da due parti semanticamente distinte:
Un algoritmo che consente di fornire il servizio di localizzazione
Un programma che presenta funzionalità in grado di effettuare rilevazioni
inerenti l’ambiente circostante (luminosità, temperatura, pressione etc.) ed
inviarle nel mondo reale.
33
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Prima di passare ai parametri di progetto, si vuole precisare che il sistema di
localizzazione progettato ed implementato nei capitoli successivi, è basato nel piano e non
nello spazio, ovvero si prenderanno in considerazione solo due coordinate cartesiane
latitudine e longitudine (X ;Y) in quanto si suppone di rilevare la terza coordinata spaziale
mediante l’utilizzo di un altimetro.
1.5.1 Progettazione
Risulta chiaro, come si è detto più volte, che i parametri di progetto non sono tutti di
uguale importanza e soprattutto la loro priorità varia a seconda del particolare ambito di
utilizzo. Ad esempio in un’applicazione militare la sicurezza di una WSN ricopre un ruolo
imprescindibile, in un’applicazione di tracking o di motion capture la rilevanza maggiore è
data dall’elaborazione in tempo reale. In altri esempi come l’utilizzo in contesti sportivi la
massima accuratezza nelle rilevazioni rappresenta il principale obiettivo facendo passare
in secondo piano l’aspetto dei costi e dei consumi energetici. Non avendo purtroppo
sponsorizzazioni paragonabili a quelle esistenti in ambito sportivo, nella progettazione
della rete di sensori per il monitoraggio ambientale, gli aspetti relativi ai costi ed al
risparmio energetico sono quelli predominanti. Si potrebbe infatti pensare di costruire un
WSN formata da sensori tutti muniti di sistema GPS in modo da fornire automaticamente
un servizio di localizzazione senza la necessità d’implementare algoritmi ad hoc. Questa
soluzione è da scartare a priori sia per i costi da sostenere, che sarebbero sempre più
proibitivi al crescere dei nodi, sia per il dispendio energetico dovuto al modulo GPS . Nei
capitoli successivi si vedrà poi che un giusto compromesso potrebbe essere quello di
utilizzare solo alcuni nodi dotati di sistema GPS (che verranno chiamati nodi beacon) per
tutti gli altri sviluppare un algoritmo che, a partire dai nodi beacon, rileveranno la propria
posizione. Un altro aspetto molto importante da considerare per migliorare il servizio di
localizzazione fornito in quest’ambito, è quello relativo al posizionamento dei nodi
all’interno di una WSN, quest’aspetto sarà chiarito nei prossimi capitoli.
34
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
1.5.2 Considerazioni sulle soluzioni hardware da utilizzare
Per realizzare una WSN che meglio si adatti a svolgere i compiti relativi alla particolare
applicazione da implementare, vi è la possibilità di utilizzare piattaforme hardware diverse
che hanno diverse caratteristiche.
Molti sono gli studi e li sforzi che sono stati fatti e che ancora si faranno, da aziende
manifatturiere del settore ICT per cercare di venire incontro a tutte le esigenze dei
particolari ambiti che sicuramente in futuro sono destinati a crescere. Si farà una breve
carrellata della ricerca, dello sviluppo e delle varie piattaforme hardware fatto in questi
anni.Una delle innovazioni più interessanti degli ultimi anni, è rappresentata da ZigBee,
una soluzione completa per reti di sensori che si basa sullo standard IEEE 802.15.4 per
quanto concerne la comunicazione radio e la gestione dell’ accesso al mezzo. ZigBee è
indicato per realizzare una WSN in modo automatico e distribuito, senza la necessità di
sviluppare software ad hoc atto alla gestione ed al controllo. Lo svantaggio principale è la
difficoltà della gestione a basso livello della piattaforma (essendo questa una soluzione a
“scatola chiusa”) qualora si volesse per effettuare ottimizzazioni. Per realizzare
applicazioni che s’inseriranno poi in un particolare contesto d’utilizzo, si deve ricorrere a
piattaforme più flessibili dal punto di vista della gestione dei nodi e dello stack
protocollare. Consideriamo quindi alcune piattaforme che consentono questo: la
piattaforma EyesIFXv2 prodotta da Infineon che fa parte del progetto EYES (EnergY
Efficient Sensor networks), dall’acronimo s’intuisce che questo tipo di piattaforma tende
ad ottimizzare i consumi energetici. In quest’ambito si farà riferimento alla piattaforma
MICA prodotta da Crossbow utlizzata in diversi contesti sperimentali.
35
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Capitolo 2: Sistemi di localizzazione
Si è visto che il requisito fondamentale dell’applicazione relativa al progetto REMOAM è
dotare la rete di sensori, che si calerà in quest’ambito, di un servizio di localizzazione. In
questo capitolo si elencheranno quali sono le caratteristiche principali si un sistema di
localizzazione, si presenteranno le tipologie ed esempi di algoritmi di localizzazione ed
infine si illustrerà nel dettaglio il funzionamento dell’algoritmo ROCRSSI e si motiverà
tale scelta.
2.1 Caratteristiche principali
Le caratteristiche tipiche di un sistema di localizzazione per WSN, dalle quali non può
prescindere il sistema presentato, devono essere la capacità di autorganizzazione,
robustezza a possibili guasti di singoli nodi con conseguenti perdite di connettività,
talvolta creazione di protocolli aggiuntivi per garantire il corretto funzionamento
dell’algoritmo ed errori quanto più possibile piccoli sulle grandezze misurate. Ovviamente
tutto questo deve essere realizzato tenendo sempre in considerazione i problemi energetici
di cui si è ampiamente trattato.
Si possono suddividere i sistemi di localizzazione in due grandi famiglie:
sistemi centralizzati: sono quei sistemi che prevedono l’utilizzo di un super
nodo, dotato di potenza di calcolo o risorse energetiche maggiori, che raccoglie
informazioni da tutta la rete ed esegue elaborazioni per stimare la posizione di
ogni altro nodo.
sistemi distribuiti: si tratta di sistemi in cui ogni nodo colleziona le informazioni
di cui necessita e calcola la propria posizione. Dopodichè può inoltrare la sua
36
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
posizione appena calcolata , ai sui vicini oppure all’interno di un messaggio
destinato al nodo catalizzatore (nodo sync)
Gli algoritmi centralizzati possono raggiungere precisioni maggiori, comportano però costi
notevoli, in termini di occupazione del canale, di costi computazionali ed energetici.
Questi svantaggi diventano sempre più incidenti all’aumentare delle dimensioni della rete
in termini spaziali e di densità dei nodi; ecco perché si considera di gran lunga più
vantaggiosa la strategia distribuita. Infatti questa permette di velocizzare il processo (in
quanto ogni nodo calcola la propria posizione in maniera concorrente), le informazioni
scambiate inferiori (in quanto non si devono inviare informazioni al super nodo ed
aspettare la risposta di quest’ultimo ad elaborazione terminata) con conseguente risparmio
energetico.
Un’ulteriore classificazione degli algoritmi di localizzazione viene fatta in base al metodo
con cui i nodi valutano le distanze o le direzioni dalla sorgente del pacchetto radio. Infatti
secondo questa classificazione possiamo distinguere due tipologie di algoritmi:
Algoritmi range based: utilizzano le stime di distanza punto-punto o di angoli
assoluti per la determinazione delle posizioni. Risulta evidente che l'accuratezza
di queste misure è strettamente dipendente dal mezzo trasmissivo utilizzato,
dall'ambiente circostante (se questo è affetto da molte interferenze che possono
altrare le informazioni) e dall'hardware a disposizione (in particolare riferimento
alla sua capacita e di memorizzazione).
Algoritmi range free: questi al contrario non effettuano una stima delle distanze
assolute ma si basano su valutazioni relative; usano cioè delle informazioni per
ricavare una relazione d’ordine, utile al calcolo della posizione.
Un'ulteriore distinzione può essere fatta tenendo presente il tipo di localizzazione richiesto
per la particolare applicazione:
localizzazione simbolica: si parla di posizionamento simbolico quando cioè si
associa un simbolo alla posizione; per esempio si può voler conoscere la
37
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
posizione di una persona all'interno di un edificio non tanto in relazione alle sue
coordinate geografiche, ma piuttosto alla stanza in cui si trova per poterla
rintracciare
localizzazione fisica: si parla di posizionamento fisico quando invece si vuol
conoscere dove è ubicato un nodo in termini di coordinate nello spazio; è inoltre
possibile distinguere una localizzazione assoluta da una relativa; un nodo può
infatti determinare la propria posizione rispetto altri nodi in maniera relativa, se
inoltre è nota la posizione assoluta dei nodi presi a riferimento è possibile
riportare la localizzazione relativa in coordinate assolute.
Si analizzeranno quali sono, in generale, i criteri utilizzati nella scelta degli algoritmi di
localizzazione:
posizioni stimate attendibili: cioè che l’errore (massimo, medio o la sua
deviazione standard) sia accettabile relativamente al contesto applicativo
semplicità dell’algoritmo: più l’algoritmo è semplice, minore sarà la complessità
computazionale, maggiore sarà il risparmio energetico; inoltre sarà più efficiente
qualora l’applicazione necessiti di una localizzazione in tempo reale
dipendenza tra accuratezza ed hardware: quanto l’accuratezza dipende dalla
piattaforma usata per la realizzazione dei nodi della rete. Ovviamente meno
dipendenza c’è, più l’algoritmo può essere considerato generico ed utilizzato su
piattaforme hardware diverse
A proposito di quest’ultimo punto si precisa che, architetture più sofisticate possono
ridurre notevolmente gli errori di localizzazione ma solitamente ciò avviene a scapito,
oltre che di un aumento del consumo energetico, anche di un incremento del costo dei nodi
stessi, due aspetti fondamentali. Quindi bisogna vedere se è effettivamente conveniente,
considerando i fondi e le risorse energetiche relativamente all’applicazione da
implementare, utilizzare architetture hardware più complesse.
Inoltre c’è un altro aspetto da considerare. Molti algoritmi di localizzazione (compreso
38
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
quello sviluppato in quest’ambito) assumono che alcuni nodi chiamati beacon o anchor
node conoscano già con certezza la loro posizione, questo può avvenire in seguito ad
un'assegnazione a priori delle coordinate o utilizzando un sistema di localizzazione più
preciso di quello riservato agli altri nodi detti unknown node (nodi sconosciuti o
incogniti), ad esempio il GPS. Come già detto posizionare manualmente molti nodi non è
sempre possibile e dotarli di GPS o sistemi analoghi è in genere costoso dal punto di vista
economico ed energetico. Ne consegue che un criterio sensato per la scelta dell'algoritmo
di localizzazione è l'utilizzare il sistema che per una prefissata accuratezza minimizza il
numero di beacon impiegati. Una volta determinato il numero di beacon è importante
considerare se è necessario che siano situati in posizioni specifiche rispetto la topologia
della rete o possano essere collocati dove è più facile posizionarli.
2.2 Procedura generica di localizzazione
In molti algoritmi di posizionamento è possibile distinguere almeno due fasi distinte:
ranging e positioning. Vi è poi la possibilità di utilizzare un’ulteriore fase dopo la stima
della posizione che consiste nel refinement, cioè il raffinamento della posizione tramite la
continua iterazione della fase precedente (il positioning) oppure tramite la riduzione di una
funzione obiettivo.
Nei prossimi sottoparagrafi si descriveranno le varie fasi di cui un sistema di
localizzazione si compone.
2.2.1 Ranging
Esistono diverse tecniche per misurare le distanze fra i nodi o gli angoli tra le direzioni di
seguito vengono riportati i metodi principali per approfondimenti si fa riferimento a [23]:
Time of arrival (ToA):
Ipotizzando che la velocità d’invio del segnale all’interno del mezzo trasmissivo sia nota,
il nodo ricevitore può calcolare la distanza dal trasmettitore attraverso il tempo di
propagazione del segnale inviato. Così è possibile ottenere una buona precisione nella
39
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
stima della distanza, se però i nodi dispongono di clock perfettamente sincronizzati e sono
in grado trasmettere segnali audio, o ultrasuoni, il cui tempo di propagazione è
sufficientemente lungo da essere misurato anche da hardware non troppo sofisticato. Il
fatto di avere sensori perfettamente sincronizzati è un grossissimo limite in quanto questo
richiede un overhead per effettuare la sincronizzazione. Inoltre molte piattaforme
hardware, specie quelle facilmente reperibili in commercio quindi non troppo sofisticate,
tendono a perdere la sincronizzazione in intervalli di tempo relativamente brevi. Ciò
comporta che la sincronizzazione deve essere fatta periodicamente e spesso questo è un
prezzo troppo alto da pagare.
Time Difference of Arrival (TDoA):
In questa tecnica tutti i nodi, perfettamente sincronizzati, effettuano ad un dato istante una
trasmissione, diretta ad un unico ricevitore. Questo, valutando l'ordine di arrivo dei
segnali, stabilisce una relazione d'ordine tra le distanze dei trasmettitori. Anche qui
ritroviamo il grosso limite della sincronizzazione inoltre un nodo deve poter gestire la
ricezione multipla di messaggi.
Angle of Arrival (AoA):
Questo tecnica si può applicare qualora il nodo sia dotato di un sistema multiantenna; in
questo caso, sfruttando il concetto di diversità, determinare l'angolo fra un nodo incognito
e i beacon (almeno tre).
Received Signal Strength Indicator (RSSI):
Grazie a questa tecnica, se si conosce la potenza di trasmissione, è possibile ricavare una
relazione tra la potenza in ricezione e la distanza attraverso il path loss che viene tabulato
empiricamente o modellato da un'equazione. Utilizzando questo metodo si va incontro ad
una serie di errori quali il fading, scattering e shadowing, però utilizzando questa tecnica
non c’è bisogno di hardware aggiuntivo.
40
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Carrier phase:
E’ la tecnica su cui si basa il sistema GPS e consiste nel comparare il tempo e la frequenza
dei segnali in arrivo scanditi da un clock remoto. Per realizzare questo sistema è
necessario disporre di un circuito che si mantenga continuamente agganciato alla portante.
Bit Error Rate:
Una tecnica approssimata si basa sull’idea che all'aumentare della distanza fra due nodi i
messaggi scambiati subiscono un degrado maggiore e quindi aumenta la probabilità di
ricevere un bit errato. E’ possibile valutare la distanza fra i nodi misurando il BER (Bit
Error Rate). Questa è una tecnica molto poco accurata ed approssimata, viene di solito
utilizzata solo come supporto ad un’altra tecnica di ranging più efficace.
2.2.2 Positioning
Questa rappresenta la seconda fase della procedura di localizzazione. Nel positioning il
nodo, basandosi sulle informazioni ottenute con il ranging, cerca di stimare la propria
posizione in un sistema di coordinate relativo o assoluto. Di seguito vengono riportate
svariate tecniche proposte per conseguire quest’obiettivo (con i relativi riferimenti
bibliografici in []):
GPS (Global Position System):
Costituisce la soluzione più semplice ed immediata al problema della localizzazione ma
sfortunatamente non è applicabile a tutti gli scenari possibili a causa del costo, del
consumo energetico e alla inefficienza negli ambiente chiusi.
[14] Lateration:
E’ una delle tecniche più semplici da implementare, consiste nel posizionamento
intersecando circonferenze (almeno tre), centrate in un punto noto (il beacon) e aventi per
raggio la distanza stimata da questo. Oltre ai vantaggi come la semplicità e la generalità
d’impiego, il limite principale consiste nella altissima sensibilità agli errori di misura.
41
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
[15] Active Badge e Active Bat:
Questa tecnica è utilizzata in ambiente indoor e prevede l’installazione di un dispositivo
ad infrarossi (chiamato Active Badge) sui singoli nodi. La tecnica consiste nel tracciare la
posizione di oggetti tramite il dispositivo ad infrarossi, e memorizzare tale informazione in
un database centralizzato. Ad intervalli di tempo programmabili, il badge trasmette il suo
identificativo (ID) ad un ricevitore fisso: un sistema centralizzato calcola la nuova
posizione attraverso un metodo di prossimità cellulare. Il principale svantaggio sta nel
costo elevato e nella necessità d’infrastrutture per realizzare il sistema, inoltre i sistemi ad
infrarossi soffrono dei disturbi causati da fonti luminose e di calore. Esiste un sistema
simile nell’idea ma basato su nodi equipaggiati con ricetrasmettitore a radiofrequenza e
con un trasmettitore a ultrasuoni, questa tecnica è l’ Active Bat . I grossi limiti di queste
tecniche possono essere riassunti dai limiti esistenti nei sistemi centralizzati.
[16] Cricket:
E’ un altro particolare sistema di localizzazione per fornire una localizzazione simbolica
utilizzato in ambienti indoor in cui un'insieme di beacon sparsi nell'edificio inviano
periodicamente informazioni usate dai nodi per stabilire la loro posizione. Non c'è
coordinazione tra i beacon ma la procedura assume che essi siano in numero sufficiente e
ben distribuiti e che trasmettano in istanti casuali per evitare collisioni o interferenze
reciproche. Analogamente all’ Active Bat il ranging adottato si basa su TDoA di segnali
RF e ultrasuoni.
[14],[17] SpotOn:
E’ basato sul ranging RSSI usato per valutare le distanze da utilizzare nella tecnica
Lateration, unitamente ad un’ una infrastruttura fissa di supporto.
[19] Bulus et al:
Ogni nodo riceve dei messaggi da un insieme di beacon contenenti le coordinate dei
beacon stessi e valuta la sua posizione come la media delle coordinate degli anchor node
42
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
ascoltati, ottenendo un'accuratezza pari a circa il 30% della distanza media fra i beacon.
[18] Doherty et al:
Questa tecnica prende il nome dai propri autori che presentano la formulazione del
problema della localizzazione in termini di programmazione convessa e propongono uno
strumento di risoluzione. Il metodo si basa sul fato che la localizzazione venga effettuata
successivamente all'invio verso l'elaboratore delle informazioni da parte di tutti i nodi. In
questo modo si trasferisce gran parte dell’intelligenza sull’elaboratore che ha potenza di
calcolo maggiori ed riserva energetica praticamente illimitata, purtroppo però
all’aumentare dei nodi, il sistema comporta difficoltà nella scalabilità.
[24] AHLoS:
E’ un esempio di tecnica iterativa, che calcola la posizione dei nodi prefiggendosi
l’obiettvo di minimizzare l'errore quadratico fra le distanze misurate e le distanze stimate.
La stima della distanza fra il nodo e i beacon viene fatta attraverso la soluzione di un
sistema linearizzato, una volta che il nodo si è localizzato può fungere da beacon per altri
nodi che non sono in copertura da un numero di beacon sufficienti (collaborative
multilateration).
[25] Hop-TERRAIN:
Possiamo distinguere due fasi: nella prima i beacon propagano informazioni in tutta la rete
che i nodi incogniti utilizzano per una stima iniziale delle posizioni; nella seconda fase i
nodi incogniti effettuano un refinemant relativamente alla propria posizione stimata
attraverso un coefficiente di accuratezza associato alla posizione calcolata nella fase
precedente. Una delle principali caratteristiche di quest’approccio, consiste nel fatto che
nonostante il tipo di ranging utilizzato influisce su costo, accuratezza e consumo
energetico, questo tipo di soluzione non è strettamente dipendente da esso.
43
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
[26] ,[27] Minimun Maximum:
Detto anche Bounding Box, rappresenta uno dei metodi di positioning più semplici, infatti
viene utilizzato in alcuni sistemi di localizzazione per ottenere delle stime iniziali rapide
ma non molto accurate. L'idea di base è assegnare ai nodi la posizione del baricentro
dell'intersezione dei quadrati costruiti attorno a ciascun beacon, aventi il lato uguale al
doppio della distanza stimata fra il nodo incognito e il beacon in questione. Questo metodo
è robusto agli errori di misura e facilmente scalabile. La semplicità di calcolo lo rende
interessante per le situazioni di mobilità in cui la posizione deve essere calcolata
rapidamente.
[28] Cooperative Location Sensing:
Questo metodo di localizzazione è molto simile al lateration, ma invece di cercare il
punto d'intersezione di circonferenze, cerca la regione d'intersezione di corone circolari di
larghezza la deviazione standard sull'errore di misura. Il procedimento di assegnazione
delle coordinate è simile a quello dell’algoritmo APIT presentato più avanti.
2.3 Esempi di procedure di localizzazione
Nel paragrafo precedente si sono elencate alcune delle tecniche esistenti relative al
ranging ed al positioning. Ora si analizzeranno un po’ più in dettaglio due meccanismi di
localizzazione uno range-free l’altro range-based. In particolare rispettivamente APIT
(Approximate Point In Triangle) discusso in particolare in [21] e CBaSA (Corse and fine Grained Based on Single Anchor) trattato in [20]. Si è scelto di analizzare un algoritmo
per ogni tipologia non solo per evidenziare le principali differenze tra gli algoritmi rangefree e range-based , ma anche per valutare i vantaggi e svantaggi relativi a queste
tipologie nel contesto preso in considerazione. Infine si presenteranno le motivazioni che
hanno portato poi all’utilizzo del ROCRSSI.
2.3.1
CBaSA (Coarse-grained Based on Single Anchor)
In generale
nelle tecnice di localizzazione che utilizzano la laterazione, si richiede
44
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
l’utilizzo di almeno k+1 ancore (anchors node)
per calcolare la posizione dei nodi
all’interno della rete in un piano k-dimensionale. Quindi per calcolare la posizione in
termini di coordinate cartesiane (x;y) si necessita di almeno tre anchor node affinché i
nodi possano localizzarsi. Questi algoritmi CBaSA (Coarse-grained) e FBaSA (Finegrained) (si precisa che il funzionamento di entrambi è analogo; cambia la granularità), si
prefiggono lo scopo di proporre una tecnica che richiede soltanto una singola ancora per
determinare la posizione dei nodi in un piano bidimensionale. Analizziamo il
funzionamento del CBaSA. Si suppone che gli anchor node siano dotati di antenne
direzionali lungo il suo perimetro, ed inoltre si suppone siano dotati anche di un modulo
GPS che ne consente la localizzazione. In figura 2.1 si può notare come ogni antenna di
ciascun anchor node ricopre una porzione di regione, ovviamente il numero di antenne
direzionali necessarie a ricoprire l’intera regione (360°), dipende dall’ampiezza
dell’angolo di ciascun antenna.
Figura 2.1 – Regione ricoperta dalle antenne di ciascun anchor node
Inizialmente i nodi sono in ascolto sul canale di ricezione, tutte le antenne direzionali
45
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
trasmettono un segnale di sincronizzazione a tutti i sensori all’interno dell’area coperta
(questa operazione è equivalente a trasmettere un segnale in broadcast da un’antenna
omni-direzionale) . Una volta ricevuto il segnale di sincronizzazione, i sensori fanno
partire un timer. A questo punto gli anchor node trasmettono segnali (che chiameremo
normali) in piccoli intervalli di tempo, uno dopo l’altro, in modo da formare un sequenza
ciclica. Ciascun nodo riceve questo segnale e memorizza l’intervallo di tempo intercorso
tra la ricezione di quest’ultimo e la ricezione del messaggio di sincronizzazione (cioè il
valore corrente del timer). Quest’intervallo di tempo verrò indicato con T1 . Dopodichè i
sensori resettano il timer ed aspettano un altro segnale periodico dall’anchor node, quando
lo riceveranno memorizzeranno il valore del timer che chiameremo T2 . Ricapitolando:
T1 indica l’intervallo di tempo che intercorre tra la ricezione del segnale di
sincronizzazione e la ricezione del segnale normale
T2 indica il tempo necessario a completare un ciclo di 360° ( 2 )
Inoltre i nodi calcolano la distanza dall’anchor node tramite la tecnica di ranging RSSI,
basandosi quindi sulla potenza del segnale normale ricevuto in precedenza. Quindi
conoscendo la distanza del nodo incognito dall’anchor node e siccome si è supposto di
conoscere le coordinate di quest ultimo, in quanto dotato di GPS, possiamo ricavare le
coordinate nel modo illustrato in figura 2.2
Figura 2.2 – Calcolo coordinate del sensore attraverso le coordinate dell’anchor node
46
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Tramite le seguenti formule:
X
Xa
dsen(
)
Y
Ya
d cos(
)
dove d è la distanza, mentre
2 * T1
T2
Riepiloghiamo i vari step dell’algoritmo di localizzazione Coarse-grained :
I sensori aspettano il segnale di sincronizzazione
Gli anchor node inviano il segnale di sincronizzazione
I sensori dopo la ricezione del segnale di sinc. fanno partire un timer
Attraverso l’antenna direzionale, gli anchor node inviano segnali verso tutti i
sensori, uno dopo l’altro in ordine ciclico. Questi messaggi contengono le
coordinate dell’anchor node.
I sensori ricevono il segnale, calcolano la distanza tramite l’RSSI (quindi tramite
la potenza del segnale appena ricavuto) e memorizzano il valore di T1
Dopo un ciclo completo, i sensori memorizzano il valore di T2
I sensori calcolano le proprie posizioni tramite le equazioni viste prima
Il massimo errore che si può commettere con questo tipo di tecnica è:
Em
d cos( / 2) d cos( / 2)
2d cos( / 2)
Come si capisce anche dalla figura:
Figura 2.3 – Errore massimo nel CBaSA
47
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Una possibile miglioria consiste nel considerare il nodo sempre al centro del settore, così
facendo l’errore si riduce a:
Em
d cos( / 2)
I principali limiti di quest'algoritmo sono rappresentati dal fatto che è necessaria una
sincronizzazione preventiva dei nodi che comporta traffico aggiuntivo nella rete, senza
considerare che in questo modo aumenta la complessità dell'algoritmo. Inoltre molti
dispositivi in commercio hanno bisogno di essere risincronizzati periodicamente e queste
operazioni aggiuntive potrebbero influire in maniera consistente sul consumo energetico.
Si potrebbe pensare di utilizzare nodi che non perdano facilmente la sincronizzazione,
quindi utilizzare hardware più raffinato, ma questo è in contrapposizione con uno degli
aspetti fondamentali ossia ridurre i costi d'implementazione di una rete di sensori. Un altro
limite è rappresentato dal numero di antenne direzionali che un anchor node deve avere;
infatti l'accuratezza dell'algoritmo è determinato dal numero di queste, in quanto più
antenne si usano maggiore sarà l'area coperta, ma ovviamente maggiore sarà il costo per
ogni anchor node.
2.3.2
APIT (Approximated Point In Triangulation)
E’ una delle tecniche range-free acronimo di Approximated Point In Triangulation. In
questa tecnica la rete si compone di due entità: i beacon, che fungono da anchor node ed i
nodi incogniti.
Figura 2.4 – Esempio di sovrapposizione di triangoli
I beacon possono essere equipaggiati con moduli GPS oppure possono essere fissati in
modo che le loro coordinate siano note a priori. Quest’algoritmo si basa sulla
48
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
sovrapposizione di triangoli, che permettono l’individuazione dell’area in cui si trova il
nodo incognito. Un esempio è riportato in figura 2.4. Per effettuare la localizzazione di un
nodo, si scelgono terne di beacon le cui posizioni rappresentano i vertici di un triangolo,
fra tutti quelli nel raggio di copertura di ogni nodo e si valuta se il nodo incognito
appartiene o meno alla regione triangolare identificata. Un esempio di questa valutazione è
riportato in figura 2.5
Figura 2.5 – Valutazione della posizione del nodo incognito
Con riferimento alla precedente figura, il nodo incognito M, tramite la comparazione dei
valori di RSSI ricevuti da ciascun beacon, riesce a capire se si trova all’interno del
triangolo che vede come vertici i beacon A,B e C (1° caso) oppure all’esterno (2° caso).
L’intera area in cui si estende la rete, è rappresentata da un griglia ed ogni volta che il
nodo si localizza all’interno di un triangolo, vi è l’incremento del contatore relativo agli
elementi della griglia che rappresentano i punti interni al triangolo. Dopo aver considerato
tutte le combinazioni di beacon, si assegna al nodo la posizione del baricentro dei punti
aventi il contatore più grande. Il principale svantaggio di questo tipo di approccio consiste
nelle ripetute scansioni della griglia per incrementare il contatore: infatti si consumano sia
risorse dal punto di vista energetico e di calcolo, nonché risorse di relative alla memoria; il
consumo di risorse è destinato a crescere se aumenta il rapporto tra area considerata e
passo di scansione.
Inoltre vi è la possibilità che si presenti un problema difficile da eliminare. Supponiamo di
posizionare in maniera casuale i nodi della rete, alcuni di questi saranno i nodi beacon, che
possono essere fissati o dotati di GPS in modo da conoscere a priori le proprie coordinate,
altri saranno i nodi incogniti de dovranno posizionarsi a partire dai beacon. A questo punto
49
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
può verificarsi che un nodo incognito non rientra in nessun triangolo che ha come vertici i
beacon che il nodo riesce a sentire; quest’inconveniente si indica con il nome di “nodo
indeterminato”. Un esempio di tale evenienza è rappresentato in figura 2.6
Figura 2.6 – Problema del “nodo indeterminato”
Questo tipo di problema non è facilmente risolvibile. Una possibile soluzione potrebbe
essere quella di posizionare i beacon in maniera tale d’assicurare che i nodi incogniti
rientrino in almeno un triangolo formato dai beacon.
2.3.3
Considerazioni relative agli algoritmi ed al loro impiego
Sono stati presentati quindi due algoritmi, tra loro molto diversi, che rientrano
rispettivamente nelle categorie range based e range free. Solitamente negli algoritmi range
based ed in particolar modo l'algoritmo in questione CBaSA, viene introdotto un overhead
dovuto alla sincronizzazione dei sensori. Come già ampiamente discusso, questo overhead
è piuttosto sensibile sotto il profilo dei consumi energetici ed inoltre aumenta il traffico
nella rete; quest'ultimo è un aspetto da non sottovalutare in quanto all'aumentare dei nodi
che compongono una rete la scalabilità della sincronizzazione diventa sempre meno
fattibile. Il vantaggio principale del CBaSA non è cosa da poco in quanto utilizziamo un
solo anchor node per calcolare la posizione dei nodi incogniti. Questo comporta un
notevole risparmio in termini economici visto che c'è bisogno di un solo nodo,
50
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
relativamente all'area coperta da esso, montante il modulo GPS o fissato per in modo che
la sua posizione sia definita a priori.
Per ciò che concerne gli algoritmi range-free come APIT, bisogna considerare che
unitamente a molti pregi come la semplicità software ed hardware (considerato che non si
deve disporre hardware aggiuntivo ad eccezione di un eventuale modulo GPS) e quindi
una maggiore indipendenza dalla piattaforma, talvolta presentano problematiche di
difficile risoluzione come ad esempio il "nodo indeterminato", visto in precedenza per
APIT. Inoltre molti studi hanno dimostrato che in una rete di sensori il posizionamento dei
nodi beacon rispetto ai nodi incogniti in un sistema di localizzazione basato su tecniche
range-free, è molto più rilevante rispetto a sistemi di localizzazione range-based. Infatti
questi talvolta richiedono un numero relativamente elevato di nodi beacon ma soprattutto
richiedono che questi siano disposti in maniera ad hoc per permettere la corretta
localizzazione dei nodi incogniti ed evitare le problematiche tipiche che possono
presentarsi.
Nello specifico ambito di utilizzo preso in esame quale è il monitoraggio ambientale volto
alla previsione di fenomeni franosi, si è cercato d'immaginare quali potrebbero essere gli
algoritmi più efficienti e si scelto di intraprendere la strada delle tecniche range-free.
Svariate sono le motivazioni. Una di queste potrebbe essere facilità d'installazione sul
territorio. In quanto per l'algoritmo CBaSA si dovrebbero installare antenne direzionali per
ogni nodo beacon, inoltre è vero che questo tipo di soluzione minimizza il numero di
beacon utilizzati e di conseguenza anche i costi, ma questo non è sempre un pregio in
quanto se l'anchor node in questione si guasta per qualche motivo i nodi incogniti vicini ad
esso non sarebbero più in grado di localizzarsi. Bisogna considerare che il guasto
dell’anchor node, o di una delle sue componenti, non può essere considerato un evento
molto remoto, in quanto questo si installerà su terreni caratterizzati da fenomeni franosi,
tutt’altro che stabili. Un'altra motivazione che rappresenta uno svantaggio estendibile a
tutti gli algoritmi range-based è una maggiore complessità computazionale dovuta ai
calcoli necessari per stimare la distanza assoluta tra due punti. Infatti negli algoritmi
range-based per garantire maggiore accuratezza nella stima, è talvolta richiesto che ci
51
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
siano piattaforme hardware più sofisticate oppure si potrebbe richiedere potenza di calcolo
e memoria tali da introdurre hardware aggiuntivo.
Inoltre alcuni svantaggi legati agli algoritmi range-free in quest'ambito di utilizzo possono
essere superati. Infatti visto che l'installazione dei nodi non deve essere necessariamente
casuale o seguire uno schema particolare, si può pensare di progettare la rete di sensori
ad hoc e posizionare i beacon in modo tale da ottimizzare la localizzazione ed evitare
situazioni da cui possono scaturire problematiche descritte in precedenza. Infine si può
pensare di sovradimensionare la rete con un numero di beacon maggiore rispetto allo
stretto necessario da un lato per migliorare la stima dei nodi incogniti, dall'altro per
fronteggiare un eventuale guasto dei beacon. Si precisa che non è obbligatorio munire i
beacon di sistema GPS ma si possono semplicemente fissare.
In seguito s’illustrerà l’algoritmo ROCRSSI trattato nei riferimenti [21],[30] che
rappresenta un’evoluzione dell’algoritmo APIT [21]. Il ROCRSSI inoltre è l’algoritmo che
sta alla base del sistema di localizzazione realizzato e di cui si discuterà nei capitoli 3 e 4
2.4 L’algoritmo ROCRSSI
Alla fine del paragrafo precedente, si è motivata la scelta d’indirizzamento, relativamente
al particolare contesto d’utilizzo di monitoraggio ambientale, verso gli algoritmi range –
free.
Figura 2.7 – Grafico di confronto degli algoritmi APIT e ROCRSSI realtivo agli studi
effettuati in [21]
52
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Tra questi si scelto di progettare ed implementare una versione migliorata dell’algoritmo
ROCRSSI (Ring Overlapping Comparision based on Received Signal Strength Indicator).
Si è fatta questa scelta in quanto questo rappresenta, sotto molti punti di vista,
un’evoluzione dell’APIT come molti studi sperimentali dimostrano e come testimonia il
grafico di figura 2.7 (per i dettagli si rimanda a [8]).
Proprio la considerevole quantità di studi ed esperimenti fatta in questa direzione,
rappresenta un altro motivo della scelta. Si descriverà adesso, il funzionamento
dell’algoritmo. L’idea di base dell’algoritmo ROCRSSI è molto simile all’algoritmo APIT;
infatti questo tramite la sovrapposizione di circonferenze e corone circolare, riduce
progressivamente l’area in cui si trova il nodo incognito. L’intero meccanismo che si
trova alla base di quest’algoritmo può essere facilmente spiegato utilizzando l’illustrazione
il figura 2.8. In questa figura, S rappresenta un nodo incognito, A B e C invece
rappresentano i beacon. Si indicherà con ij la distanza tra il nodo i ed il nodo j.
Ogni nodo incognito può stabilire una relazione d’ordine basata sulle distanze tra lui ed i
suoi vicini rispetto alla distanza fra coppie di beacon, il procedimento verrà esposto in
seguito. Intanto, analizzando la figura 2.8 a) si può affermare che il nodo incognito S è in
grado di stabilire che la distanza SA è maggiore della distanza AB ma minore della
distanza AC . Basandosi su queste considerazioni, il nodo S può localizzarsi all’interno
della regione delimitata dalla corona circolare centrata in A, avente raggio interno AB e
raggio esterno AC . Facendo lo stesso ragionamento, con riferimento alla figura 2.8 b), il
nodo S stabilisce che la sua posizione è interna alla circonferenza centrata in C e di raggio
BC . Infine relativamente alla figura 2.8 c) S si localizza all’interno della corona circolare,
centrata in B avente raggio interno AB e raggio esterno BC . Per completare l’operazione
di localizzazione, dopo la sovrapposizione delle varie circonferenze e corone circolari, è
sufficiente calcolare il baricentro dell’intersezione di tutte le regioni che lo contengono, il
quale rappresenta la sua posizione stimata. In quest’algoritmo, le regioni vengono
costruite tramite il confronto tra la potenza del segnale inviato da un certo beacon ad un
nodo incognito, e quella dei segnali ricevuti dagli anchor node nel raggio di copertura del
suddetto beacon.
53
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
a)
b)
c)
Figura 2.8 – Localizzazione tramite 3 beacon con il ROCRSSI
Se si considera nuovamente la figura 2.8 a) si può illustrare il
funzionamento dell’algoritmo, si assuma che il beacon A invii un messaggio in broadcast
contenente il suo identificativo e che gli altri nodi B,C e S lo ricevano rispettivamente con
un indice di potenza RSSI AB , RSSI AC e RSSI AS . Se la seguente disuguaglianza è valida:
RSSI AB
RSSI AS
RSSI AC
54
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
allora è possibile scrivere la relazione d’ordine AC
AS
AB se si assume che la
potenza ricevuta sia inversamente proporzionale alla distanza, identificando così la corona
circolare contenente il nodo incognito. Iterando questo ragionamento, si arriva poi alla
stima della posizione con le modalità già discusse. Bisogna tener conto di un
inconveniente che talvolta può occorrere soprattutto se vi sono pochi beacon nelle
vicinanze di un nodo incognito oppure occorrono errori di ordinamento, ovvero ottenere
una regione d’intersezione disconessa così come mostrato in figura 2.9. Questa
rappresenta la situazione più sfavorevole in cui può venire a trovarsi l’algoritmo
ROCRSSI cioè può accadere che l'intersezione delle corone circolari e dei cerchi sia data
da due o più regioni separate, in questo caso è possibile che il baricentro venga a trovarsi
all'esterno di ciascuna regione e quindi il nodo si localizza in una zona in cui ha bassa
probabilità di trovarsi.
Figura 2.9 – Esempio di regione d’intersezione disconessa
In figura 2.9 è mostato come l’errore di localizzazione, nel caso di regione d’intersezione
disconnessa, sia elevato. Infatti, guardando la figura, si può notare come il nodo incognito
S si localizza calcolando il baricentro delle due porzioni di regione evidenziate in grigio
commettendo così un errore relativamente elevato. Purtroppo questo è un problema
esistente nel ROCRSSI e che comunque influenzerà anche i suoi derivati come l’algoritmo
55
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
proposto in quest’ambito: il ROCRSSI++ (descrito nel capitolo 3).
Si ricorda che il ROCRSSI non mappa la potenza misurata in una distanza punto-punto
visto che rientra nella categoria degli algoritmi range-free, il riconoscimento della regione
d’intersezione avviene tramite una procedura di scansione dell’area su cui la rete di sensori
si estende. Questa procedura prevede la suddivisione dell’area in celle ad ognuna delle
quali è associato un contatore; ogni volta che si costruisce una corona circolare o una
circonferenza si scandiscono tutte le celle incrementando il contatore di quelle che ne
fanno parte; terminate tutte le scansioni si definisce la regione d’intersezione come
l’insieme delle celle che hanno il contatore con il valore maggiore. Dopodichè si calcola il
baricentro di tale regione, ricavando così una stima della posizione del nodo incognito.
Tutto il funzionamento di quest’'algoritmo si basa sull'assunzione che all'aumentare della
distanza fra trasmettitore e ricevitore, la potenza del segnale ricevuto dal ricevitore
misurato su un messaggio inviato dal trasmettitore, decresca in modo monotono in tutte le
direzioni. Tuttavia questa asserzione non sempre rispecchia la realtà, molti sono stati gli
studi e le sperimentazioni effettuate con risultati anche molto diversi. Per quanto concerne
quest’argomento, nel capitolo dedicato alle sperimentazioni (capitolo 6) si illustreranno i
risultati sperimentali ottenuti utilizzando sensori MICA2 in ambiente indoor.
56
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
ROCRSSI++
Capitolo 3: IL ROCRSSI++
Partendo dallo studio teorico dell’algoritmo ROCRSSI proposto da T.H. Chong Liu, Kui
Wu [21],[30] visto in precedenza, si è scelto di perseguire la strada degli algoritmi rangefree per realizzare un sistema di localizzazione in una WSN. Considerando gli ulteriori
miglioramenti quali il ROCRSSI+ proposto da Andretto[9], e tenendo conto della tecnica
AHLoS presentata nel capitolo precedente e dettagliata in [24], si è fatta un’analisi dei
possibili miglioramenti applicabili per un utilizzo in ambiti reali che hanno portato alla
progettazione e all’implementazione concreta dell’algoritmo ROCRSSI++.
3.1 L’algoritmo ROCRSSI+
Il punto di partenza per l’algoritmo proposto il ROCRSSI++ è rappresentato proprio
dall’algoritmo proposto in [9],[10] che rispetto all’algoritmo originale introduce alcuni
significativi miglioramenti, ad esempio l’algoritmo ROCRSSI+ considera valide regioni
d'intersezione anche le parti di spazio esterne alla circonferenza tracciata avendo fissato le
dimensioni massime su cui si estende la WSN. L’algoritmo originale infatti, prevede di
ignorare il caso in cui, per un determinato beacon il nodo incognito si trova all’esterno di
tutte le circonferenze tracciate (ossia la distanza beacon-nodo è maggiore di tutte le
distanze beacon-beacon relative al beacon in questione). Questo comportamento può
portare ad una potenziale perdita d’informazione; ecco perché nel caso sopraindicato, si
può considerare il raggio della circonferenza che delimita l’estensione della WSN ed
assumere quindi che il nodo incognito sia: esterno alla massima circonferenza di raggio
beacon-beacon ed interno alla circonferenza di raggio beacon-MaxWSN (MaxWSN sta
57
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
per massima estensione WSN). Questa è proprio la soluzione adottata dal ROCRSSI+.
Ipotizzando quindi che la regione da scandire sia limitata, è possibile incrementare il
contatore anche della parte di spazio esterna alla circonferenza costruita.
Un esempio di come si restringe la regione d'intersezione considerando anche lo spazio
esterno alle circonferenze è illustrato in Figura 3.1. Qui si può notare che nella figura 3.1
b) utilizzando l’algoritmo ROCRSSI+, il nodo incognito S riesce a stimare la propria
posizione in E in maniera più precisa rispetto alla figura 3.1 a) dove si è utilizzato il
ROCRSSI.
Il vantaggio principale di un algoritmo di questo tipo, è che i nodi, dopo aver ricevuto le
informazioni di posizione e potenza dai beacon, possono localizzarsi. Quindi gli unici a
impegnare il canale radio durante l'esecuzione dell'algoritmo sono i beacon; il fatto che
solo loro debbano inviare pacchetti fa si che il carico sia molto limitato in quanto i beacon
rappresentano solo una piccola percentuale di tutti i nodi della WSN.
a)
b)
Figura 3.1 - Esempio di localizzazione con tre beacon (A, B e C), nodo incognito nella
posizione S e posizione stimata E. a) ROCRSSI, b) ROCRSSI+.
Inoltre l’algoritmo ROCRSSI+ si distingue dal ROCRSSI per l’ipotesi di simmetria del
canale, questo permette di considerare indistintamente il valore di RSSI del pacchetto
scambiato dal nodo A al nodo B, oppure da B ad A. Questa considerazione permette di
iniziare la scansione della griglia appena al nodo incognito giunge un messaggio da un
58
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
beacon, senza dover attendere ulteriori pacchetti dagli altri beacon vicini, semplificando ed
ottimizzando l'algoritmo di localizzazione.
Nella particolare soluzione proposta in [9],[10], per quanto concerne il refinement,
compare anche un modulo che si prefigge l’obiettivo di migliorare la localizzazione,
questo è proposto
da X. Nguyen e T. Rattentbury in [20] all'interno del progetto CS 252 Class Project ;
l'idea di fondo, consiste nel determinare una funzione, chiamata funzione obiettivo, che
leghi l'errore sulla posizione alle coordinate stimate e cercare di minimizzarla attraverso
un procedimento iterativo di aggiornamento della posizione. In quest’ambito comunque
non ci focalizzeremo sul refinement ma proporremo una serie di migliorie adattative che
porteranno alla progettazione e poi all’implementazione dell’ algoritmo ROCRSSI++ .
3.2 L’idea di base del ROCRSSI++
L’idea del ROCRSSI++ nasce da alcune considerazioni fatte su studi relativi a sistemi di
localizzazione usati in ambiti reali, in particolare come già detto, si è partiti dalle migliorie
dell’algoritmo ROCRSSI+ e si è cercato di unirle all’idea che sta alla base delle tecnica
AHLoS presentata in [21] per cercare di apportare ulteriori migliorie.
Si parte dall’assunzione che non sia possibile (per questioni di costi o di hardware)
equipaggiare tutti i nodi della mia rete, con dei dispositivi GPS che consentirebbero la
localizzazione senza la necessità d’implementare nessun algoritmo ad hoc. Possiamo
considerare però fattibile l’utilizzo del GPS solo per alcuni nodi che consentiranno a tutti
gli altri di calcolare la loro posizione. Questi particolari nodi, che d’ora in poi chiameremo
beacon, fungeranno da “ancore” che i nodi incogniti sfrutteranno per calcolare la propria
posizione all’interno della rete. In figura 3.2 è mostrato un esempio di distribuzione di
sensori in una WSN con 5 nodi beacon, i punti rossi rappresentano i nodi beacon, mentre i
punti blu rappresentato invece i nodi incogniti che a partire dalla posizione conosciuta dei
beacon, dovranno localizzarsi.
59
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 4.x – Esempio di una WSN con 5 beacon
Figura 3.2 – Esempio WSN con 5 nodi beacon
Una volta tracciata la direzione da intraprendere per costruire il sistema di localizzazione,
vediamo quali possono essere le ottimizzazioni. In base a simulazioni effettuate in [32] si
evince che all’aumentare della percentuale del numero di beacon rispetto al numero totale
dei nodi della WSN, l’errore medio commesso sulla stima della posizione dei nodi
incogniti decresce. Se però fissiamo a priori il numero dei beacon all’interno della rete non
è possibile poi aumentare tale numero per effettuare una stima della posizione dei nodi
incogniti con più precisione. In altre parole fissare il numero di beacon equivale, in certo
senso, a fissare la precisione massima della stima che si può ottenere all’interno della mia
WSN. Ad esempio se un nodo calcola la sua posizione con errore abbastanza elevato, a
meno che non s’introduca un nuovo nodo beacon nelle sue vicinanze, l’errore sulla
posizione resterà costante. L’algoritmo proposto: ROCRSSI++ si prefigge come obiettivo
principale quello di aumentare dinamicamente il numero di anchor node per permettere ai
nodi incogniti una più precisa localizzazione. Affinché questo sia possibile facciamo una
60
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
classificazione: chiameremo beacon di 1° livello quei nodi della rete che possono
autonomamente localizzarsi, beacon di 2° livello quei nodi incogniti che hanno effettuato
una stima abbastanza precisa della loro posizione all’interno della rete e soddisfano
particolari requisiti che li consentono di comportarsi da anchor node, nodi incogniti o nodi
normali tutti i nodi che ancora devono calcolare la loro posizione oppure non soddisfano i
requisiti necessari per definirsi beacon di 2° livello e quindi comportarsi da tali. Com’è
facile notare il ROCRSSI++ introduce una nuova classe di sensori: i beacon di 2° livello
(in verde nella figura 3.3) infatti le altre entità quali i beacon di 1° livello (in rosso) ed i
nodi incogniti (in blu) ed i loro relativi comportamenti li ritroviamo pari pari nel
ROCRSSI e ROCRSSI+. Nei sottoparagrafi successivi si passarà alla descrizione
dell’algoritmo proposto, alle migliorie adattative introdotte, ai dettagli implementativi ed
ad analizzare in particolare gli aspetti dei beacon di 2° livello che rappresentano la
peculiarità del ROCRSSI++.
Figura 3.3 – Possibile evoluzione di una WSN utilizzando il ROCRSSI++
61
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
3.2.1 Vantaggi introdotti dall’algoritmo ROCRSSI++
Nel valutare i vantaggi introdotti dal ROCRSSI++ si ricorda che sia nell’algoritmo
proposto che nel ROCRSSI+ il cuore delle operazioni svolte per la localizzazione è
sempre lo stesso ed è quello descritto nel funzionamento del ROCRSSI. Innanzitutto
cerchiamo di capire, attraverso un esempio grafico, come il numero di beacon può
aumentare la precisione della stima effettuata dai nodi incogniti sulla propria posizione. Si
prende in esame la figura 3.4 dove viene riportato un esempio di localizzazione, i nodi A
B e C rappresentano i beacon, i nodi T e S (in blu) sono i nodi incogniti mentre T’ ed S’
(in rosso) sono le posizioni stimate dopo la procedura di localizzazione. I dettagli sul
funzionamento verranno descritti in seguito, cerchiamo solo di capire come vengono
costruite le
Figura 3.4 – Esempio di localizzazione tramite beacon A – B –C con ROCRSSI+
circonferenze. In base al funzionamento del ROCRSSI, si sa che per ogni beacon si
costruiscono tante circonferenze quanti sono i propri vicini (in questo caso 2) con centro
uguale al beacon stesso e raggio pari alla distanza dal beacon vicino, i nodi incogniti sono
in grado di stabilire una relazione d’ordine ed individuare la regione formata
dall’intersezione delle circonferenze all’interno della quale loro si trovano. In quest’
62
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
esempio si può notare che l’errore commesso è abbastanza elevato.
Consideriamo ora l’esempio di figura 3.5 dove i beacon sono 4 e cioè A – B – C – S il solo
nodo incognito è T, in questo caso l’errore commesso è di gran lunga più basso dato che il
il beacon S è più vicino al nodo T rispetto al beacon C (caso visto prima) e questo ci
permette di effettuare una stima molto più precisa dal momento che la regione
d’intersezione è molto meno estesa rispetto al caso precedente.
Figura 3.5 – Localizzazione tramite beacon A – B – C – S con ROCRSSI+
Si è analizzato quindi un tipico caso in cui l’aumento del numero di beacon all’interno
della WSN migliori l’accuratezza della posizione stimata dai nodi incogniti. Ed è proprio
su questa considerazione che si basa il ROCRSSI++. Ovviamente bisogna fare alcune
considerazioni perché l’esempio rappresentato in figura 3.5 non è effettivamente la
situazione che si verifica utilizzando l’algoritmo proposto. Quindi per capire
effettivamente quali possono essere i miglioramenti introdotti dal ROCRSSI++ facciamo
riferimento alla figura 3.6 dove è rappresentata la medesima tipologia di rete ma per la
localizzazione si utilizza l’algoritmo ROCRSSI++.
Nell’esempio di figura 3.6 i nodi in rosso rappresentano i beacon di 1° livello, quello in
verde è un beacon di 2° livello e quelli in blu sono i nodi incogniti. Inizialmente i nodi
incogniti sono due: T ed S, mentre A, B e C sono i beacon di 1° livello. Si suppone che il
63
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
primo nodo ad eseguire l’algoritmo di posizionamento sia il sensore S, quest’ultimo ha
effettuato una stima utilizzando come anchor node i beacon di 1° livello ed ha stimato la
sua posizione (in figura rappresentata da S’ in verde), in seguito il nodo S si proclama
beacon di 2° livello, il nodo incognito T che ancora deve localizzarsi, può utilizzarlo come
anchor node per calcolare la sua posizione.
Figura 3.6 – Esempio di localizzazione tramite ROCRSSI++
La prima cosa da notare è che siccome il nodo S che poi diventa beacon di 2° livello,
nell’eseguire la propria localizzazione, commette comunque un certo errore, la successiva
stima della posizione del nodo incognito T, che utilizza S come uno degli anchor node,
sarà influenzata dall’errore commesso in precedenza, ecco perché non si ritrova
esattamente la situazione vista in figura 3.5 cioè nel caso in cui usavamo 4 beacon, ma
sicuramente si migliora la stima fatta nel esempio di figura 3.4 dove si usavano solo 3
64
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
beacon; questo miglioramento è quantificabile e non è altro che la differenza tra il
segmento g ed il segmento h che rappresentano rispettivamente l’errore sulla
localizzazione del nodo T utilizzando il ROCRSSI ed il ROCRSSI++. E’ intuitivo
comunque comprendere che in ogni caso, la posizione dei beacon rispetto ai nodi incogniti
può essere più che rilevante ai fini di calcolare l’errore fatto sulla localizzazione, ecco
perché nel capitolo successivo verranno eseguite diverse prove in ambiente simulato
partendo da rilevazioni effettuate in ambiente reale.
3.3 Descrizione dell’algoritmo proposto: il ROCRSSI++
Si passa ora alla descrizione dei vari step di cui l’algoritmo si compone. Innanzitutto si
ricorda che la parte riguardante il calcolo delle coordinate del nodo incognito all’interno
della regione d’intersezione, è praticamente identico a quello del ROCRSSI. Si descrivono
ora nel dettaglio le varie fasi che si attraverseranno, dall’inizializzazione della rete, alla
localizzazione dei nodi incogniti fino all’individuazione dei beacon di 2° livello. Come
detto in precedenza si possono distinguere 3 entità differenti: beacon di 1° livello o
semplicemente beacon che conoscono a priori la loro posizione (perché prefissata oppure
sono dotati di un sistema GPS), beacon di 2° livello che rappresentano quei nodi che
hanno calcolato la loro posizione e possono fungere da beacon e nodi che non hanno
ancora effettuato la localizzazione (che chiameremo incogniti) oppure che non hanno le
caratteristiche per essere beacon di 2° livello.
Si parte dalla descrizione dell’algoritmo residente nei nodi beacon di 1° livello. In figura
3.7 è rappresentato il flow chart rappresentativo dell’algoritmo; il sistema di
localizzazione prevede una fase iniziale, che chiameremo Phase1 a cui partecipano
soltanto i beacon scambiandosi informazioni necessarie poi ai fini della localizzazione dei
nodi incogniti, ed una fase successiva che chiameremo Phase2, dove i beacon invieranno
le informazioni scaturite dalla fase 1 ed i nodi incogniti calcoleranno la loro posizione. Nel
corso della prima fase i beacon di 1° livello, dopo l’inizializzazione dei vari componenti,
iniziano a trasmettere il proprio ID e le proprie coordinate in modalità broadcast, cioè agli
elementi della rete che rientrano nel raggio di copertura del segnale inviato, queste
65
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 3.7 – Flow chart che rappresenta l’algoritmo residente nei nodi beacon di 1° livello
66
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
trasmissioni sono controllate da un timer (TxTimer). Tutti gli altri beacon che ricevono il
messaggio, controllano se hanno già ricevuto questo tipo di messaggi da quel beacon, in
caso affermativo si limitano ad effettuare una nuova rilevazione del RSSI ed aggiungono
tale valore alla propria tabella interna contenente le informazioni relative ai propri vicini;
in caso contrario aggiungono una riga nella tabella con tutte le informazioni ricevute
relative al nuovo vicino.
Nella suddetta tabella troviamo le seguenti informazioni:
ID del nodo
Tipo di beacon (di 1° o di 2° livello )
Coordinate cartesiane (x;y)
Insieme delle rilevazioni del valore RSSI
Allo scadere del timer di fase (PhTimer) o se si è raggiunto il numero massimo di
messaggi ricevuti/inviati, si procede con il calcolo delle medie delle rilevazioni RSSI e si
ordinano le tabelle in maniera decrescente, cioè dal beacon più vicino al beacon più
lontano, in questo modo termina la prima fase. Prima dell’inizio della seconda fase, i
beacon inviano un particolare messaggio (BeaconReady) destinato ai quei nodi che
vogliono diventare beacon di 2° livello che sta ad indicare che la prima fase è finita. Si
passa dunque alla seconda fase, dove se i beacon ricevono una o più risposte al segnale
inviato, provvedono ad aggiornare le tabelle dei vicini con le informazioni ricevute
relative ai beacon di 2° livello altrimenti si passa direttamente all’ invio delle proprie
tabelle in broadcast destinate ai nodi incogniti; dopodichè, periodicamente alloscadere del
ResTimer, si effettua il restart dell’intero algoritmo ripartendo dall’ascolto del canale
relativo prima fase.
Si descrive ora l’algoritmo residente in tutti gli altri nodi (nodi incogniti ed eventuali
beacon di 2° livello). Prendendo come riferimento il flow chart di figura 3.8 si può notare
come si comportano i nodi che devono localizzarsi. Durante la prima fase sono
praticamente inattivi visto che in questa fase gli unici elementi attivi della rete sono i
67
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
beacon, i nodi infatti restano in attesa sul canale di comunicazione. Si supponga di
ricevere un messaggio di tipo BeaconTable . Una volta ricevuto questo tipo di messaggio,
che contiene le informazioni sul beacon e sui suoi vicini, si verifica se le informazioni
contenute al suo interno sono valide o meno ed in base all’esito di questo controllo, si
decide se memorizzare o no il messaggio ricevuto.
Figura 3.8 - Flow chart che rappresenta l’algoritmo residente nei nodi incogniti
Vediamo qual è la struttura dati dei messaggi BeaconTable :
ID del nodo
Tipo di beacon
68
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Coordinate cartesiane (x;y)
Tabella dei vicini
Dove la tabella dei vicini contiene:
Numero dei vicini
Vettore di BeaconMsg
Ed il BeaconMsg contiene:
ID del nodo
Tipo di beacon
Coordinate cartesiane (x;y)
Valore medio RSSI
Una volta che il nodo incognito riceve un BeaconTable può iniziare ad eseguire le
operazioni di localizzazione che sono riportate in pseudo-codice nella figura 3.9.
Sfruttando la rilevazione del valore RSSI del beacon che ha inviato il messaggio, si
dividono i beacon in due gruppi, uno composto dai nodi più prossimi al trasmettitore,
rispetto al nodo che esegue le elaborazioni, l'altro da quelli più lontani. Il risultato di
questa divisione permette di individuare l'area a cui il nodo appartiene, possiamo
distinguere tre possibili casi:
Se l'insieme dei beacon più vicini è vuoto, il nodo è interno alla circonferenza
di raggio minore tra quelle centrate nel beacon che ha trasmesso la tabella e
di
raggio le distanze tra questo e i vari elementi di cui la tebella è composta;
Se al contrario è l'insieme degli elementi più lontani ad essere vuoto, il nodo è
esterno a tutte le circonferenze descritte, e quindi è esterno a quella di raggio
massimo, interna però alla circonferenza rappresentante la massima
estensione della rete;
Infine, se nessuno tra i due gruppi è vuoto il nodo si posiziona all'interno della
corona circolare delimitata dalla circonferenza di raggio maggiore tra quelle
del
69
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
primo gruppo e quella di raggio minore appartenente al secondo.
Nodo incognito
X:
X N : Insieme dei beacon vicini al nodo incognito X
B A : Insieme dei beacon vicini al beacon A
Uno dei beacon in X N
A:
RSSI AB : È la potenza del segnale del nodo ricevuto dal nodo
Procedura di localizzazione ROCRSSI() {
Regione d’intersezione R {};
While X N ! 0
PASSO 1:
Beacon A X N . prossimoBeacon(.);
PASSO 2:
Dividi B A in 2 parti: B A1 e B A 2 tali che:
per ogni elemento I in B A1 risulti RSSI AI RSSI AX
per ogni elemento J in B A2 risulti RSSI AJ RSSI AX
PASSO 3:
d1 d 2 0;
Se BA1! insiemeVuoto
I = elemento con RSSI minore in B A1
d1 = distanza fra J e A
Nel caso che
d1! 0 & d 2 ! 0 : r = corona circolare centrata in A
con raggio interno d1 e raggio esterno d1
d1 0 :r = interno del cerchio centrato in A con raggio d 2
d 2 0 :r = interno del cerchio centrato in A con raggio d1
R
PASSO 4:
PASSO 5:
R
r;
inserimento di r in R.
Calcola l’intersezione delle regioni;
Calcola il baricentro dell’intersezione;
Figura 3.9 – Pseudo-codice procedura di localizzazione
La regione denominata r, viene intersecata con le altre regioni ottenute a partire dai dati di
altri beacon. Infatti ad ogni nuova ricezione di una BeaconTable il nodo incognito verifica
70
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
se si tratta di una tabella valida e non ancora elaborata, e se vi è al più, un solo beacon di
2° livello che funge da anchor; in caso affermativo itera il precedente procedimento, in
caso contrario scarta i dati e rimane in attesa. Dal risultato di questa intersezione viene
infine calcolato il baricentro, punto di cui il nodo fa proprie le coordinate. Dopo
l’esecuzione della procedura di localizzazione il nodo segnala l’avvenuta localizzazione. A
questo punto, una volta ricevuto il messaggio BeaconReady il nodo effettua un controllo
su se stesso al fine di capire se ha le caratteristiche per diventare beacon di 2° livello.
Figura 3.10 – Flow chart che rappresenta l’algoritmo residente nei beacon di 2° livello
In particolare, questo controllo consiste nel valutare se la riserva energetica del sensore è
tale da sopportare il carico aggiuntivo introdotto dal comportamento del beacon di 2°
livello e verificare che la sua localizzazione sia avvenuta sfruttando come ancore
esclusivamente beacon di 1° livello. Se così fosse il nodo risponde con un messaggio del
71
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
tipo Ready4Beacon che sta ad indicare che esso è “pronto” a diventare beacon di 2° livello
e che contiene le informazioni su di esso e i suoi vicini. Per descrivere il comportamento
dei beacon di 2° livello a regime, facciamo riferimento al flow chart di figura 3.10
Dopo l’inizializzazione, che consiste nell’aggiornare le proprie informazioni interne, il
beacon di 2° livello ascolta il canale se non riceve nessun messaggio di tipo BeaconReady
si limita semplicemente ad inviare la propria tabella in broadcast, così come avviene nella
seconda fase dei beacon di 1° livello, fino al restart della prima fase,
altrimenti si
provvede ad effettuare il controllo sullo status del nodo in questione con lo scopo di
controllare se questo può continuare a fungere da beacon di 2° livello. Nel caso in cui, per
questioni di riserva energetica, il nodo non vuole più essere beacon questo dovrà
aggiornare le informazioni interne, comunicare questo cambiamento alla rete tramite
l’invio del messaggio NotReady4Beacon e riprendere a comportarsi come in normale
nodo.
3.4 Migliorie adattative introdotte dal ROCRSSI++
Oltre alle caratteristiche intrinseche dell’algoritmo proposto, si è cercato di perfezionare
ulteriormente il sistema di localizzazione introducendo una serie di migliorie adattative
che possono risultare utili in determinati ambiti di utilizzo. Innanzitutto l’esecuzione delle
operazioni di localizzazione possono essere eseguite solo quando effettivamente
necessarie, si può pensare quindi al seguente scenario: un nodo incognito riceve le tabelle
dai suoi beacon vicini ma inizia a processarle solo allo scadere di un determinato timer, in
questo modo separiamo il lavoro IO bound da quello CPU bound cercando di ridurre il
consumo di energia, infatti possiamo pensare di spegnere il ricevitore radio una volta
ricevute le informazioni necessarie alla localizzazione del nodo. Un’altra miglioria
introdotta è sicuramente quella relativa all’integrazione immediata di un beacon di 2°
livello nel gruppo degli anchor node. Infatti dopo che un nodo si dichiara beacon di 2°
livello, affinché questo fornisca un contributo valido ai fini della localizzazione, dovrebbe
anch’esso partecipare alla prima fase dei beacon in modo che anch’esso possa essere
definito tale. Come descritto nei flow chart precedenti, la miglioria consiste nell’instaurare
72
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
una comunicazione tra il nodo che vuole proclamarsi beacon e gli anchor node esistenti. Si
può riassumere quanto detto, analizzando il sequence diagram di figura 3.11 dove si pone
l’accento sulla modalità d’interazione tra gli elementi della rete di sensori. Allo scadere
della prima fase, i beacon lanciano un messaggio asincrono destinato ai potenziali beacon
di 2° livello, questi dopo aver ricevuto tale messaggio effettuano un check interno
Figura 3.11 – SD relativo al caso di dichiarazione Ready/NotReady4Beacon
per capire se possono dichiararsi beacon ed a seconda dell’esito inviano un messaggio di
Ready/NotReady4Beacon ricevuto tale messaggio i beacon aggiornano le informazioni e
rispondono, infine anche i beacon di 2° livello aggiornano le propire informazioni.
Si descrive adesso, come si comporta il sistema di localizzazione nel caso in cui, a regime,
un nodo non riceve più messaggi da un beacon di 2° livello (in quest’ambito non
consideriamo il caso relativo ad un beacon di 1° livello perché non esistono nodi
gerarchicamente superiori tali da effettuare una verifica). Se per un certo numero di volte
il nodo non riceve più messaggi da un beacon di 2° livello, lancia un allarme destinato ai
73
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
beacon di 1° livello con un messaggio di tipo BeaconAlert contenente:
ID del nodo che invia l’allarme
ID del beacon di 2° livello sospetto
questi provano a contattare il beacon in questione (inviando un messaggio BeaconReady
non più in broadcast ma destinato al solo beacon sospetto) se quest’ultimo risponde
ignorano l’allarme (perché il beacon di 2° livello funziona visto che ha risposto ai beacon
principali probabilmente il nodo non lo “sente” più perché è troppo lontano e
precedentemente l’ha sentito per “caso”) se non risponde o risponde con un messaggio di
tipo NotReady4Beacon lo cancellano dalla tabella dei beacon vicini e rispondono al nodo
che ha segnalato l’allarme. Nella figura 3.12 viene riportato il sequence diagram relativo al
caso in cui un beacon di 2°livello risponde con un messaggio di tipo NotReady4Beacon.
Figura 3.12 – SD relativo al caso Alert – NotReady4Beacon
Un’ulteriore miglioria è quella relativa al fatto che periodicamente un beacon di 2° livello
74
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
può ricalcolare la sua posizione in modo da confrontarla con quella precedentemente
calcolata, se lo scostamento tra la posizione appena calcolata e quella calcolata in
precedenza supera una certa soglia, allora si invia in broadcast la nuova posizione, in
modo da poter aggiornare le varie tabelle. Quest’ultima miglioria è molto utile in alcuni
scenari reali di utilizzo come quello in esame del monitoraggio dei rischi ambientali
derivanti da fenomeni franosi. Infatti, una volta posizionati i nodi costituenti la WSN su un
terreno definito a rischio di frane, si potrebbero creare delle soglie di allarme. In questo
modo, qualora i beacon di 2° livello ricalcolando la loro posizione notassero che lo
scostamento tra la posizione appena calcolata e quella calcolata in precedenza supera una
certa soglia, potrebbero segnalare una situazione a rischio.
A questo punto è doveroso fare un’osservazione, facendo nuovamente riferimento alla
figura 3.3, potrebbe capitare che molti nodi incogniti diventino beacon di 2° livello.
Ovviamente questa è una situazione sconveniente in quanto un beacon di 2° livello
consuma sicuramente più energia di un nodo normale ed inoltre il fatto di avere molti
beacon di 2° livello gli uni vicini agli altri non apporterebbe miglioramenti significativi
dal punto di vista dell’accuratezza. Ecco perché affinché la soluzione proposta apporti
effettivamente delle migliorie in ambito delle reti di sensori non si possono trascurare
questi aspetti. C’è bisogno dunque di qualche accorgimento. A tal proposito riutilizza una
tecnica simile a quelle utilizzate nei livelli MAC (o più in generale nei livelli di
collegamento dati relativi allo stack ISOI/OSI [8] ). Ogni volta che un nodo ha la
possibilità di dichiararsi beacon di 2° livello non effettua subito la trasmissione del
messaggio Ready4Beacon ma ascolta per un tempo casuale il canale di comunicazione. Se
non riceve alcun messaggio da beacon di 2° livello vicini ad esso, allora si dichiara beacon
di 2° livello. In questo modo si evita il prolificare di beacon di 2° livello in quelle
situazioni dove più nodi incogniti vicini tra loro, hanno la possibilità di diventare beacon
di 2° livello.
75
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
ROCRSSI++
Capitolo 4: Realizzazione dell’algoritmo in ambiente TinyOS
Una volta descritto l’algoritmo proposto si è provveduto a realizzarne un’implementazione
reale in ambiente TinyOS 1.1.15. In questo capitolo quindi, si partirà da una descrizione
dell’ambiente in generale, sui tool che esso mette a disposizione, sulle peculiarità del
linguaggio NesC per poi focalizzarsi sui moduli software realizzati, fino ad analizzare in
dettaglio alcuni componenti fondamentali per l’algoritmo ROCRSSI++
4.1 Il sistema operativo TinyOS
TinyOS è un sistema operativo open-source progettato per le reti di sensori senza filo dalla
Berkeley University. La progettazione di una applicazione per una rete di sensori deve
rispondere ad alcune particolari esigenze quali:
dimensioni ridotte in termini di carico computazionale, occupazione in memoria
e dimensioni del sistema operativo
ottimizzazione dei consumi energetici
affidabilità, robustezza ed efficiente modularità
E’ facile intuire quindi che per soddisfare queste esigenze, un sistema operativo
tradizionale non costituisce uno strumento efficiente. Un SO tradizionale, infatti, lo
possiamo immaginare sulle architetture hardware tradizionali, dove si dispone di grandi
quantità di memoria, di complessi sottosistemi per le operazioni di IO, di forti capacità di
elaborazione e sorgenti di energia praticamente illimitate, in una rete di sensori invece, ci
troviamo di fronte a sistemi di piccole dimensioni, fonti di energia limitate, scarsa quantità
76
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
di memoria, modeste capacità di elaborazione, etc. Ecco perché sono necessarie soluzioni
molto semplici ed efficienti e che soprattutto riducano al massimo i consumi di energia ed
ecco perché TinyOS si sta imponendo come uno standard de facto.
Il sistema operativo TinyOS va interpretato più come un framework di programmazione
che come un sistema operativo tradizionale. Esso semplifica notevolmente lo sviluppo di
applicazioni per WSN, grazie ai numerosi componenti già implementati e soprattutto alla
elevata modularità, in seguito ci concentreremo su aspetti che coinvolgono l’architettura e
le entità di TinyOS, l’implementazione e lo scambio di messaggi.
4.1.1 Architettura di TinyOS
TinyOS è stato appositamente concepito per sistemi embedded, cioè per quei sistemi
elettronici a microprocessore progettati appositamente per una particolare applicazione e
su una piattaforma hardware ad hoc. Questo SO adotta un’architettura a componenti che
rende possibile sviluppare rapidamente il software, minimizzare le dimensioni del codice e
rispettare i vincoli stringenti sull’occupazione della memoria. Come detto in precedenza,
TinyOS differisce in maniera sostanziale dai sistemi operativi general purpose: in quanto
non consente l'esecuzione di molteplici applicazioni, né in parallelo né in sequenza, ma si
integra direttamente nel programma sviluppato. Si tratta in effetti di una collezione di
componenti nesC (alcuni dei quali verranno introdotti in seguito) pensati ad hoc per una
rete di sensori, a cui si aggiunge uno scheduler che ha il compito di gestire l'esecuzione dei
task e delle funzioni. Non esiste cioè un kernel (il nucleo del sistema operativo) che
gestisce le risorse disponibili dividendole tra più applicazioni; lo scheduler si limita ad
eseguire in sequenza i task, secondo una politica FIFO, eventualmente interrompibili dagli
eventi, che hanno priorità maggiore. Quando non vi sono più funzioni in attesa di
esecuzione, lo scheduler porta il processore a riposo e attende la segnalazione di un nuovo
evento per riprendere l'esecuzione. La memoria è mappata direttamente nei suoi indirizzi
fisici, infatti questa è considerata come un unico e lineare spazio fisico, che viene
assegnato alle applicazioni a tempo di compilazione. Inoltre il contesto applicativo è unico
e quindi non ha ragione di esistere il concetto di memoria virtuale.
77
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Per avere un’idea di come sia veramente ridotto ai minimi termini il contributo di TinyOS
in un’applicazione standard, facciamo riferimento alla tabella 4.1 dove vengono
rappresentati i componenti indispensabili per l’esecuzione di una qualsiasi applicazione e
la loro rispettiva occupazione in memoria, divisa in area codice ed area dati.
Component Name
Code Size (bytes)
Data Size (bytes)
Processor_init
172
30
TinyOS scheduler
178
16
82
0
432
46
C runtime
Total
Tabella 4.1 – Occupazione in memoria del S.O. TinyOS
Analizzando questi dati possiamo comprendere come sia effettivamente ridotta al minimo
l’occupazione in memoria delle applicazioni sviluppate in ambiente TinyOS. In definitiva
si mostra l’architettura a livelli rappresentata in figura 4.1
Figura 4.1 – Architettura TinyOS
4.1.2 Componenti
Innanzitutto diamo una definizione generica di componente: un componente è un unità
software indipendente che ingloba al suo interno funzionalità alle quali è possibile
accedere tramite l’utilizzo di apposite interfacce. In TinyOS un componente è composto da
78
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
quattro parti correlate tra di loro che sono:
un set di comandi
un set di eventi
un frame di dimensione fissa
una serie di semplici task
Comandi, task ed eventi operano all’interno del frame modificandone lo stato.
Il frame può quindi essere visto come un contenitore di dati del componente, dotato di uno
stato proprio che viene allocato a tempo di compilazione. I comandi rappresentano
richieste di un servizio offerto da un componente di più basso livello. Gli eventi
rappresentano, direttamente o non, interrupt hardware, il componente di più basso livello
(ossia l’hardware abstraction) converte questi interrupt in eventi e poi notifica tali eventi a
i componenti di livello più alto. Da notare che gli eventi sono stati progettati per eseguire
piccole quantità di calcoli e, tipicamente, sono associati a condizioni di risveglio del nodo
sensore. Per tale motivo, è necessario che gli eventi vengano eseguiti nel più breve tempo
possibile, in modo da permettere ai nodi sensori di ritornare in uno stato di riposo.
Passiamo ad una classificazione dei componenti, possiamo distinguere 3 categorie:
Astrazioni Hardware: sono quei componenti che forniscono un’astrazione
dell’hardware di sistema come trasduttori, bus, attuatori etc.
Hardware simulato: questi componenti attraverso le loro interfacce possono
simulare funzionalità di hardware più complesso di quello effettivamente
presente nella piattaforma in uso.
Componenti di alto livello: sono quei componenti di livello applicativo, che
forniscono le funzioni più complesse di elaborazione e risultano essere
indipendenti dalla piattaforma usata
4.1.3 Interfacce
Come si vedrà poi in dettaglio nel paragrafo successivo, in generale le interface
costituiscono quegli elementi software che consentono di accedere alle funzionalità di un
componente dall’esterno. In TinyOS le interfacce rappresentano l’unico punto di accesso
79
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
dall’esterno alle funzionalità di un componente, sono bidirezionali, forniscono un set di
comandi ed un set di eventi e collegano i componenti tra loro. Infatti ci sarà un
componente che funge da user dell’interfaccia ed un altro componente che fa da provider
per quella interfaccia; lo user utilizzerà quell’interfaccia invocando, ad esempio, un
comando dichiarato in essa, il provider dell’interfaccia deve implementare l’azione di quel
comando. Facciamo un esempio, in figura 4.2 è riportato un esempio di linkage di
componenti tramite interfacce. Il componente BlinkM è lo user di 2 interfacce: Timer e
Leds. L’interfaccia Timer viene fornita dal componente SingleTimer, mentre l’interfaccia
Leds è fornita dal componente LedsC .
Figura 4.2 – Esempio di user-provider interfaccia
Quest’esempio è stato preso da un’applicazione TinyOS, chiamata Blink, in
quest’applicazione il sensore, ad intervalli di tempo regolati da un timer, accende e spegne
uno dei suoi led. Quindi il componente BlinkM rappresenta il componente di più alto
livello in quanto implementa il comportamento dell’applicazione, gli altri due componenti
(SingleTimer e LedsC) forniscono ed implementano le interfaccie per fornire i comandi e
gli eventi necessari al modulo di livello superiore (in questo caso BlinkM) per realizzare le
applicazioni.
4.1.4 Scambio dati in TinyOS
In TinyOS (in particolare nella versione utilizzata la 1.15) le comunicazioni radio seguono
80
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
il modello degli Active Message (AM). Gli AM rappresentano un semplice paradigma per
le comunicazioni basate sullo scambio di messaggi usate prevalentemente in sistemi di
calcolo parallelo e distribuito.Ogni AM contiene un nome di un handler di livello utente
che viene invocato sul nodo target all’arrivo del messaggio, a cui viene passato come
argomento il payload del messaggio. Gli handler ricoprono un duplice ruolo: hanno la
funzione di estrarre i messaggi dalla rete e nello stesso tempo inoltrarli per una possibile
elaborazione oppure semplicemente per inviare un messaggio di risposta. Questo schema è
rappresentato in figura 4.3. In questo modo la rete viene modellata come una pipeline con
un minimo di buffer per la memorizzazione dei messaggi. Questo modello di invocazione
degli handler basato sugli eventi, rende la vita più facile agli sviluppatori in quanto:
elimina molte difficoltà dovute all’implementazione di protocolli che prevedono
la gestione dei buffer di invio e ricezione.
consente di evitare le attese quando è in arrivo un messaggio, permettendo al
sistema di svolgere della azioni contemporaneamente all’invio e ricezione dei
dati
Figura 4.3 – Grafico dei componenti nella comunicazione in TinyOS
81
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Per evitare una congestione della rete ed assicurare quindi determinate performance, gli
handler relativi ai messaggi devono essere eseguiti rapidamente ed in modo asincrono.
Grazie a questa predisposizione naturale del modello AM alla programmazione ad eventi,
si può comprendere perché questo modello è l’ideale per la comunicazione in TinyOS.
4.1.5 TOS_Msg
Gli Active Message in TinyOS vengono mappati sul tipo di messaggio TOS_Msg che
rappresenta il messaggio standard all’interno della mia rete di sensori. Il TOS_Msg non è
altro che una struttura dati definita in un file header chiamato AM.h. Di seguito riportiamo
il codice relativo proprio alla definizione di questa struttura
typedef struct TOS_Msg
{
/* The following fields are transmitted/received on the radio.
*/
uint16_t addr;
uint8_t type;
uint8_t group;
uint8_t length;
int8_t data[TOSH_DATA_LENGTH];
uint16_t crc;
/* The following fields are not actually transmitted
* or received on the radio! They are used for internal
* accounting only. The reason they are in this structure is
* that the AM interface requires them to be part of the
* TOS_Msg that is passed to send/receive operations.
*/
uint16_t strength;
uint8_t ack;
uint16_t time;
uint8_t sendSecurityMode;
uint8_t receiveSecurityMode;
} TOS_Msg;
Si può notare che alcuni campi non vengono trasmessi, ad esempio il campo strength,
che viene utilizzato dal ricevitore per avere un’indicazione sulla potenza del segnale
relativo al messaggio ricevuto, oppure i campi ack e time utilizzati per funzionalità
interne. Per analizzare in dettaglio i campi della struttura dati, facciamo riferimento alla
tabella 4.2 dove sono riportati i campi trasmessi e ricevuti nella comunicazione radio. In
particolare nel campo type abbiamo elencato una serie di valori che il campo può
82
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
assumere relativamente alle applicazioni implementate (come si osserverà in seguito),
questo campo è di fondamentale importanza in quanto mi permette di effettuare una
distinzione sul tipo di messaggio ricevuto e prevedere quindi comportamenti diversi. Si
noti che type è di tipo uint8_t quindi viene rappresentato attraverso un solo byte, e
quindi consente di istanziare fino a 255 messaggi utente diversi tra loro. Un altro campo di
particolare importanza è rappresentato dal campo data che contiene effettivamente quelle
informazioni di livello utente rilevanti nell’ambito applicativo.
Tabella 4.2 – Dettaglio dei campi nella struct TOS_Msg
Infatti per inviare un qualsiasi tipo di messaggio bisogna incapsularlo all’interno di un
TOS_Msg. Per comprendere questo ci serviamo della figura 4.4 dove viene rappresentato
83
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
l’incapsulamento di un messaggio utente, che per semplicità chiameremo myAppMsg ,
all’interno di un TOS_Msg. Possiamo dunque considerare il TOS_Msg come un
contenitore del nostro messaggio utente in particolare si può notare che il campo data
funge da puntatore al messaggio utente difatti al suo interno troviamo un riferimento al
contenuto del messaggio myAppMsg.
Figura 4.4 – Incapsulamento messaggio utente nel TOS_Msg
4.2 Il linguaggio NesC
Il linguaggio NesC (NestedC) è una variante del linguaggio C, che si presta in maniera
ottimale alla programmazione dei sensori. Sotto certi aspetti esso rappresenta una vera e
propria estensione del linguaggio, implementando un modello ad eventi che non è previsto
nel C. D'altra parte molte delle funzionalità riguardanti i puntatori e l'allocazione dinamica
della memoria non sono presenti. Di seguito verranno fornite le caratteristiche principali,
una panoramica sul suo funzionamento ed una descrizione della sintassi corredato di
esempio
4.2.1 Caratteristiche principali
Per realizzare un’applicazione NesC si realizzano una serie di componenti. Ogni
84
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
componente deve definire le specifiche del suo comportamento e deve implementare tali
specifiche. E’ possibile definire il comportamento del componente attraverso una serie di
interfacce che, come già detto in precedenza, possono essere fornite oppure utilizzate dal
componente. Elenchiamo adesso le principali caratteristiche del linguaggio:
Modularità: come già detto si sviluppano una serie di componenti che verranno
poi opportunamente assemblati e collegati tra loro per produrre codice eseguibile
Semplicità: in quanto tramite l’utilizzo e l’implementazione di interfacce vi è una
maggiore comprensibilità e tracciabilità delle funzioni.
Staticità: che consente di: raggiungere una velocità di esecuzione più elevata,
un’analisi statica del programma. Quindi a tempo di compilazione è già noto il
wiring dei componenti che sono collegati staticamente tra loro attraverso un file
di configurazione
Il modello di programmazione NesC aderisce al modello TinyOS: Il modello del
compilatore nesC è basato su task, che sono eseguiti fino al loro completamento,
e da eventi, che possono interrompere i task e, se di priorità maggiore, anche gli
eventi stessi. Inoltre In accordo con la politica di utilizzo delle risorse di
alimentazione del sensore, ossia sleep per la maggior parte del tempo e awake
solo durante la fase di elaborazione, il linguaggio NesC permette di definire
un’elaborazione event-driven: i componenti di un’applicazione vengono mandati
in esecuzione solo quando si verificano gli eventi ad essi associati.
Tra le caratteristiche principali del linguaggio si segnala inoltre la split-phase operations:
nelle applicazioni TinyOS ogni operazione complessa è gestita con una tecnica in due
tempi chiamata split-phase. La chiamata della funzione avviene tramite l'invocazione di un
apposito task. Esso viene inserito nella coda di esecuzione e il controllo viene subito
rilasciato. Al momento opportuno è il task che si occupa di segnalare un evento che ne
notifichi il termine ed eventualmente segnali il valore di uscita, come parametro o come
variabile impostata nel contesto globale.
Dal punto di vista pratico, possiamo vedere il NesC come una sorta di precompilatore che
85
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
analizza i moduli creati dall’utente, utilizza l’implementazione dei componenti ed il loro
wiring per creare un unico file.c (in cui troviamo embedded anche i componenti principali
del TinyOS specificati in tabella 4.1) ed effettua poi la compilazione per creare
l’eseguibile.
4.2.2 Modello a componenti
Abbiamo detto che un'applicazione NesC è un insieme di componenti collegati tramite
interfacce. Ogni interfaccia è bidirezionale e modella un servizio offerto o utilizzato.
Questa modello di programmazione permette l'astrazione dei componenti, la cui
implementazione, non interessa a chi poi li utilizza per realizzare le applicazioni. In effetti
ogni componente è caratterizzato solamente dalle interfacce che sfrutta e da quelle che
fornisce. Le interfacce a loro volta sono composte da un sistema di comandi e eventi:
l’implementazione dei comandi deve essere fatta dal componente che fornisce una
interfaccia mentre l'implementazione degli eventi compete al componente che utilizza tale
interfaccia. Un esempio di questa architettura la possiamo trovare nella figura 4.5:
Figura 4.5 – Modello di un componente NesC e relativo codice
86
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
module Componente {
provides {
interface
interface
interface
}
uses {
interface
interface
}
A;
B;
C;
D;
E;
implementation ...
...
}
in quest’esempio il componente fornisce tre interfacce (A,B e C), e quindi ne deve
implementare i comandi (in figura rappresentate con le frecce nere), e all'occorrenza può
segnalare i relativi eventi. Inoltre il componente utilizza due interfacce (D e E) e deve
necessariamente fornire un implementazione per ogni evento dichiarato in queste (frecce
bianche), a prescindere dal suo effettivo impiego. In fase di compilazione comandi ed
eventi vengono tutti tradotti come normali chiamate a funzioni, ma in questo modo il
compito del programmatore risulta decisamente più agevole sfruttando l'astrazione
rappresentata dalle interfacce. Inoltre il modello a componenti consente la portabilità delle
applicazioni: infatti basta riscrivere l'implementazione relativa ai componenti che
dialogano con l'hardware specifico quando si passa da una piattaforma hardware ad un
altra, mentre quelli che si collegano alle interfacce fornite da questi non subiscono
variazioni. L'implementazione di un componente prevede due livelli: un modulo ed una
configurazione. Nel modulo vengono specificate le interfacce utilizzate e fornite, e
troviamo l'implementazione degli eventi delle prime e dei comandi delle seconde. Ogni
modulo gestisce le proprie variabili statiche esattamente secondo la sintassi tipica del
linguaggio C. Nel file di configurazione invece troviamo la specifica di quali componenti
implementano le interfacce dichiarate dal modulo, e stabiliscono i collegamenti tra i
fornitori e gli utilizzatori. Questa è l’operazione chiamata wiring. In figura 4.6 è illustrata
l’architettura di una tipica applicazione in NesC.
87
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 4.6 – Architettura di un’applicazione in NesC
INTERFACCE
Le interfacce sono elementi bidirezionali che specificano l'interazione tra due componenti,
l'utilizzatore ed il fornitore. Ogni interfaccia deve avere un nome identificativo, diverso da
qualunque altra e diverso da qualunque componente. Di seguito è riportato un esempio
d’interfaccia:
interface Send {
command result_t send(TOS_MsgPtr msg, uint16_t length);
command void* getBuffer(TOS_MsgPtr msg, uint16_t* length);
event result_t sendDone(TOS_MsgPtr msg, result_t success);
}
Questa appena descritta è la definizione dell’interfaccia di sistema Send che consente
d’inviare un messaggio in rete. Si può notare che i comandi e gli eventi devono essere solo
elencati, non è necessario fornire nessuna implementazione. Infatti sono i fornitori di
quest’interfaccia che dovranno implementare i comandi send e getBuffer mentre gli
utilizzatori implementeranno l’evento sendDone. Talvolta possiamo trovare la parola
chiave async anteposta a command o event per specificare che il comando o l'evento
possono essere eseguiti durante la gestione di un interrupt. Un esempio di utilizzo della
parola chiave async è fornito dall’interfaccia ADC che rappresenta un tipico esempio di
88
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
interfaccia per la gestione di interrupt hardware:
interface ADC {
async command result_t getData();
async command result_t getContinuousData();
async event result_t dataReady(uint16_t data);
}
La descrizione di un'interfaccia deve essere contenuta in un file con estensione .nc e
dal nome uguale all'identificativo dell'interfaccia.
MODULI
Quando si dichiara un modulo possiamo pensare di definire due parti distinte e
semanticamente separate. Nella prima parte si specificano le interfacce utilizzate e fornite
dal componente, attraverso rispettivamente le parole chiave uses e provides. Tali
parole chiave possono essere ripetute per ogni interfaccia o possono precedere le parentesi
graffe, inoltre è possibile assegnare un alias ad ogni interfaccia tramite la parola chiave as
. Di seguito riportiamo l’esempio del modulo relativo all’applicazione Blink leggermente
modificata per evidenziare alcuni aspetti, quali l’utilizzo della parola chiave as che
permette di utilizzare la stessa interfaccia più volte per diversi scopi, definendo degli alias.
Ad esempio TimerLeds e DummyTimer rappresentano degli alias per l’interfaccia Timer,
una volta definito l’alias bisogna far riferimento sempre a questo e non più al nome
dell’interfaccia.
module BlinkM {
provides {
interface StdControl;
}
uses {
interface Timer as LedsTimer;
interface Timer as DummyTimer;
interface Leds;
}
}
89
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Quindi se ci riferiamo ad un comando o un evento X dell’interfaccia Timer , una volta
definito l’alias LedsTimer, useremo LedsTimer.X invece di Timer.X per riferirci a tale
comando o evento.
Nella seconda parte si passa all’implementazione del modulo. Questa parte inizia con la
parola chiave implementation la sintassi è molto simile al linguaggio C.
All’interno delle parentesi graffe troveremo quindi l’implementazione di ogni comando
previsto dalle interfacce fornite, e l’implementazione di ogni evento delle interfacce usate.
Un esempio d’implementazione relativo sempre all’applicazione Blink:
Si può notare l’utilizzo della parola chiave call che consente di invocare i comandi, per
sollevare eventi invece viene usata la parola chiave signal. Quindi la call viene usata
dall’utilizzatore di un’interfaccia mentre la signal viene utilizzata dal fornitore.
implementation {
command result_t StdControl.init() {
call Leds.init();
return SUCCESS;
}
...
...
event result_t Timer.fired()
{
call Leds.redToggle();
return SUCCESS;
}
}
Infine un’altra caratteristica del linguaggio è la parametrizzazione delle interfacce:
infatti è possibile assegnare un parametro numerico ad una interfaccia, in modo da
caratterizzarla ulteriormente in base al compito da svolgere. Tale parametro viene fornito
come valore racchiuso da parentesi quadre. Si possono dichiarare fino a 255 interfacce
dello stesso tipo. Un tipico esempio è fornito dall’interfaccia SendMsg infatti si deve per
forza usare una parametrizzazione dell’interfaccia se si vogliono inviare più tipi di
messaggi utente. La sintassi è la seguente:
interface SendMsg[uint8_t ID]
...
...
command SendMsg.send[uint8_t ID]
90
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
La procedura equivale a disporre di un certo numero (255) di interfacce identiche.
Focalizziamoci ora sulla logica di esecuzione. L’esecuzione di comandi e degli eventi è
immediata, infatti le parole chiave con le parole call e signal indichiamo chiamate a
funzioni che verranno eseguite da uno specifico componente. In alternativa è possibile
utilizzare i task, la cui esecuzione segue il modello di concorrenza che verrà trattato in
seguito. L'invocazione avviene tramite la parola chiave post, seguita dal nome del task.
Se la chiamata va a buon fine post restituisce immediatamente un unsigned_char di
valore 1, in caso contrario 0. Un task non può avere parametri e non ritorna nessun valore.
L’implementazione del task deve essere fornita dallo stesso componente che lo utilizza, ed
ovviamente la chiamata deve seguire la definizione, esempio:
task void myTask() {
...
...
}
...
...
post myTask();
A volte si ha la necessità di dover eseguire una serie di operazioni in successione, avendo
la garanzia che non avvengano interruzioni. E’ possibile ovviare a tale necessità,
attraverso il blocco atomic. Le istruzioni, racchiuse tra parentesi graffe, che seguono tale
parola chiave, vengono eseguite in una sequenza indivisibile. Ci si trova in questo tipo di
situazione quando ad esempio, si effettuano operazioni che coinvolgono strutture
complesse, in cui i campi vanno modificati garantendo un accesso esclusivo. I blocchi
atomici devono essere molto brevi, e per questo motivo, al loro interno, NesC non solo
non consente l'invocazione di comandi o la segnalazione di eventi, ma neanche le
istruzioni goto, return, break, continue, case, default e label.
CONFIGURAZIONI
Le configurazioni implementano un componente ed inoltre specificano il wiring tra una
collezione di altri componenti. Gli stessi file di configurazione, come i moduli, si
91
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
compongono di due parti: una dichiarazione delle interfacce fornite ed utilizzate, ed una
implementazione. La sintassi della prima parte è già stata descritta ed è uguale a quella per
i moduli. Se si sta creando il file di configurazione relativo al componente principale
dell'applicazione, tale lista può risultare vuota. Per quanto riguarda la seconda parte, ossia
l'implementazione, va specificata innanzitutto la lista dei componenti impiegati, seguita
dalle specifiche di collegamento tra le varie interfacce. Vediamo un esempio di
dichiarazione di lista dei componenti, relativo all’applicazione utente sgarySenseTask
Si può notare che è stato dichiarato un alias Sensor per il componente DemoSensorC.
implementation
{
components Main,
SenseTaskM,
LedsC,
TimerC,
DemoSensorC as Sensor;
...
}
Alla dichiarazione dei componenti utilizzati, di solito fa seguito il wiring che prevede due
diverse modalità per due diversi tipi d’interfacce interne ed esterne:
interface A -> interface B
interface A = interface B
Le interfacce interne rappresentano quelle implementate nel modulo a cui si riferisce il file
di configurazione, mentre quelle esterne vengono implementate in altri moduli.
La prima modalità collega due interfacce interne, il verso della freccia sta ad indicare chi è
l’utilizzatore e chi il fornitore, la seconda modalità può coinvolgere due interfacce esterne
di cui una utilizzata e l’altra fornita oppure un’interfaccia interna ed un’ esterna, entrambe
fornite o utilizzate.
Inoltre è possibile collegare tra loro non solo interfacce ma anche comandi o eventi, con la
stessa sintassi. In entrambi i tipi di wiring le specifiche dei due elementi collegati devono
essere compatibili, essi devono essere entrambi comandi, eventi o interfacce. Se si stratta
di comandi o eventi devono avere la stessa dichiarazione, se si tratta di interfacce devono
essere la medesima interfaccia relativa a diversi componenti. E’ possibile riferirsi alle
92
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
interfacce in maniera implicita. Ad esempio se il componente A ed il componente B
forniscono la medesima interfaccia X le due dichiarazioni seguenti si equivalgono:
A.X -> B.X
A.X -> B
Ovviamente nel caso in cui venga usato un alias si farà riferimento ad esso in sede di
wiring, esempio:
module M1 {
provides {
interface StdControl
...
}
...
...
}
module M2 {
uses {
interface StdControl as SC
...
}
...
...
}
Di seguito riportiamo due equivalenti e corrette sintassi di wiring relative all’esempio:
M2.SC -> M1.StdControl;
M2.SC -> M1;
E’ possibile effettuare collegamenti multipli di un interfaccia. In tal caso ogni evento
sollevato oppure ogni comando invocato, a seconda del ruolo dell'interfaccia in questione,
comporterà l'esecuzione di più funzioni.
Per completezza riportiamo la sintassi completa per un tipico schema di programmazione
di un componente, dichiarazione dell’interfaccia (e dei suoi comandi ed eventi),
configurazione (con la dichiarazione delle interfacce utilizzate e fornite, con la lista dei
componente e l’implementazione) e modulo (con la specifica delle interfacce utilizzate e
fornite e l’implementazione relativa) .
93
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
interface X {
command int f();
event void g(int x);
}
configuration C {
provides interface X;
provides command void hbis();
} implementation{
componentsM;
X=M.P;
M.U -> M.P;
hbis = M.h;
}
module M{
provides interface X as P;
uses interface X as U;
provides command void h();
} implementation{
....
}
4.2.3 Modello di concorrenza
Il modello di esecuzione di un'applicazione NesC prevede due tipi di esecuzione: sincrona,
ed asincrona. Viene eseguita in maniera sincrona tutta quella porzione di codice relativa ai
task e tutti i comandi e le funzioni raggiungibili solo da essi, l’esecuzione avviene in modo
atomico rispetto alle altre funzioni sincrone.
Questo vuol dire che il gestore di esecuzione mantiene una lista, in cui vengono salvati i
riferimenti ai task da eseguire per ogni chiamata effettuata con post, e attende sempre
il termine di un task prima di lanciare il successivo. Viene dunque costruita una coda di
task di dimensioni finite, ogni istruzione post, anche se invoca lo stesso task, occupa una
posizione all’interno della coda. Qualora ad una nuova chiamata tale coda risultasse piena
viene restituito il valore 0 che segnala il fallimento dell'accodamento.
Insieme a queste esecuzioni sincrone vi è un sistema asincrono, rappresentato da quelle
funzioni che possono essere raggiunte da almeno un gestore di interrupt. Esse possono
interrompere in qualsiasi momento l'esecuzione del codice sincrono. Proprio in queste
situazioni possono verificarsi le race conditions , ovvero la modifica da parte del codice
asincrono di una variabile di stato in uso dal codice interrotto, che può essere sincrono o
94
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
no. Ovviamente questo è un comportamento indesiderato in quanto può determinare un
malfunzionamento dell'intera applicazione ed infatti viene segnalato dal compilatore che
in corrispondenza della situazione genera un warning. Certo queste avvertenze a volte
sono frutto di uno zelo eccessivo e possono spesso essere ignorate, per contro è molto
difficile che si possa generare una race conditions senza che il compilatore lo segnali. Il
compilatore segnala come possibili race conditions allorché il codice asincrono interviene
sul valore di variabili globali, che potrebbero essere in uso dal codice interrotto. Per
evitare le segnalazioni si può utilizzare la parola chiave norace prima della dichiarazione
della variabile in questione; tuttavia è consigliabile in questo caso porre molta attenzione
alle possibili situazioni critiche descritte, non sempre evidenti. Se si vuole essere sicuri
che non si verifichi una race conditions pur necessitando all'interno del codice sincrono la
garanzia di accesso esclusivo al contesto globale, possiamo racchiudere il codice relativo
in un blocco atomic tenendo però sempre presente i limiti già esposti. Il compilatore
segnala un errore qualora si tenti di accedere, in un contesto asincrono, a funzioni che non
siano precedute nella loro dichiarazione dalla parola chiave async.
In un contesto asincrono, questo accorgimento consente di garantir l’esecuzione di solo
codice asincrono ed evita che involontariamente venga eseguito del codice in modalità
asincrona senza che il progettista abbia considerato questa possibilità.
4.2.4 Esempio pratico: applicazione TestSwingMessage
In seguito verrà descritta e rappresentata l’intera struttura di una semplice applicazione
utente scritta per TinyOS. Questo esempio lo ritroviamo interamente in seguito
nell’implementazione dell’algoritmo ROCRSSI++. Infatti come si vedrà in seguito, i
componenti principali RfmToBea e BeaToRfm qui definiti, rappresentano rispettivamente i
componenti RfmToSink e NodeToRfm che verranno definiti quando si parlerà
dell’implementazione dell’algoritmo proposto. L’applicazione prende il nome di
TestSwingMessag. Quest’applicazione consiste nel testare lo scambio di messaggi tra i
sensori che compongono la nostra rete. Ogni sensore invia, periodicamente, un messaggio
utente che chiameremo “beacon” , i nodi che ricevono tale messaggio lo “spacchettano”,
95
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
leggono le informazioni contenute al suo interno e verificano se sono quelle attese. In
figura 4.6 viene riportato il wiring dei componenti generato tramite il comando:
ncc <piattaforma> -tosdir=<directory applicazione> -graphviz=y
oppure avendo configurato correttamente il makefile, si può generare la documentazione
relativa ad una applicazione Nesc semplicemente attraverso il comando:
make <piattaforma> docs
Figura 4.7 – Wiring del componente principale TestSwingMessage
Osserviamo il contenuto del file di configurazione TestSwingMessage.nc. Essendo questo
il componente di più alto livello, al suo interno troviamo solamente la lista dei componenti
utilizzati ed il wiring che rispecchia il modello di figura 4.7.
96
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
configuration TestSwingMessage {
}
implementation {
components Main, BeaGen, BeaToRfm, RfmToBea, TimerC;
Main.StdControl -> BeaGen.StdControl;
Main.StdControl -> BeaToRfm.StdControl;
Main.StdControl -> RfmToBea.StdControl;
Main.StdControl -> TimerC.StdControl;
BeaGen.Timer -> TimerC.Timer[unique("Timer")];
BeaGen.MsgLoc -> BeaToRfm;
RfmToBea.MsgLoc -> BeaToRfm;
}
L’applicazione include i seguenti componenti
Main: necessario per l’avvio
BeaGen: che fornisce l’interfaccia StdControl (come tutti gli altri) ed utilizza
l’interfaccia MsgLoc per inviare messaggi allo scadere del Timer
BeaToRfm: che fornisce l’interfaccia MsgLoc
TimerC: che fornisce l’interfaccia Timer
RfmToBea: che utilizza l’interfaccia MsgLoc per ricevere i messaggi dalla rete
ed estrapolare il messaggio utente (che in questo caso è il BeaconInf)
La cosa più interessante da notare è che l’interfaccia StdControl sia collegata a quattro
componenti diversi partendo dal componente principale, questo consente di identificare
quali sono i primi componenti ad essere eseguiti.
In seguito è riportato il codice contenuto nel file BeaGen.nc (ad esclusione dei commenti).
Analizziamo nel dettaglio il componente BeaGen che rappresenta il modulo principale
dell’applicazione: si può notare che nella prima riga dell’implementazione vi è una
dichiarazione di una variabile globale di tipo beaconInfo_t * b che identifica un
puntatore alla struttura dati beaconInfo (definita nel file header LocMsg.h) dopodichè
troviamo l’implementazione dei tre comandi relativi all’interfaccia fornita StdControl:
init(), start() e stop(). In particolare all’interno del comando start() troviamo
una chiamata allo stesso comando per l’interfaccia Timer.
97
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
module BeaGen {
provides {
interface StdControl;
}
uses {
interface Timer;
interface MsgLoc;
}
}
implementation {
beaconInfo_t *b;
command result_t StdControl.init()
{
return SUCCESS;
}
command result_t StdControl.start()
{
return call Timer.start(TIMER_REPEAT, 250);
}
command result_t StdControl.stop()
{
return call Timer.stop();
}
event result_t Timer.fired()
{
call MsgLoc.sendRfmBeaInf(b);
return SUCCESS;
}
}
In seguito troviamo l’implementazione dell’evento event result_t Timer.fired()
relativo all’interfaccia utilizzata. Al suo interno troviamo un’istruzione di call che
identifica una chiamata al comando relativo dell’interfaccia MsgLoc passandogli il
parametro b. In pratica questo componente, allo scadere del timer, quindi all’occorrenza
dell’evento relativo, invia un messaggio di tipo beaconInfo_t in rete tramite
l’interfaccia MsgLoc.
Analizziamo adesso in dettaglio i componenti RfmToBea e BeaToRfm e l’implementazione
dei relativi moduli RfmToBeaM e BeaToRfmM.
Iniziamo con il componente BeaToRfm, questo componente fornisce l’interfaccia MsgLoc
utilizzata dal componente BeaGen per l’invio dei messaggi via radio, il modello è riportato
in figura 4.8
98
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 4.8 – Wiring del componente BeaToRfm
Innanzitutto chiariamo che i collegamenti con linee tratteggiate indicano che il wiring è
stato fatto utilizzando la sintassi :
MsgLoc = BeaToRfmM
StdControl = BeaToRfmM;
utilizzata per riferirsi ad interfacce esterne, mentre i collegamenti con linee intere indicano
il wiring implementato:
BeaToRfmM.SendInf -> Comm.SendMsg[AM_BEAINF];
BeaToRfmM.SendTab -> Comm.SendMsg[AM_BEATAB];
Il componente BeaToRfmM, utilizza due interfacce SendMsg ridefinite tramite i rispettivi
alias SendInf e SendTab, questo permette di inviare due tipologie di messaggi utente.
Come si può notare dal codice, in fase di wiring l’interfaccia SendMsg viene
parametrizzata con i valori AM_BEAINF e AM_BEATAB che identificano il tipo di Active
Message usato per quell’interfaccia. Focalizziamoci ora su alcuni aspetti implementativi
del modulo. Nella definizione delle interfacce utilizzate definiamo l’alias per le due
interfacce SendMsg. Dopodichè nel blocco implementation troviamo la definizione della
variabile
globale
data
di tipo
TOS_Msg
e
l’implementazione
del
comando
sendRfmBeaInf(.): la prima operazione ci consente di associare il campo data della
variabile di tipo TOS_Msg alla struttura dati definita dall’utente beaconInfo_t, poi si
effettua un controllo per garantire la mutua esclusione sull’accesso alla variabile globale
data, si assegna un valore al campo ID utilizzando un blocco atomic, s’invia il
messaggio utente incapsulato in un TOS_Msg cosi come descritto in figura 4.4 ed infine si
ritorna l’esito dell’operazione. Inoltre è riportata anche l’implementazione dell’evento
99
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
SendInf.sendDone(.), al verificarsi di quest’evento resettiamo la variabile booleana
pending ed effettuiamo un signal sull’interfaccia MsgLoc.
module BeaToRfmM
{
uses {
interface StdControl as SubControl;
interface SendMsg as SendInf;
interface SendMsg as SendTab;
}
provides {
interface MsgLoc;
interface StdControl;
}
}
implementation
{ TOS_Msg data;
...
command result_t MsgLoc.sendRfmBeaInf(beaconInfo_t *bi)
{
bi = (beaconInfo_t *)data.data;
if (!pending)
{
pending = TRUE;
atomic {
bi->id = TOS_LOCAL_ADDRESS;
}
call SendInf.send(TOS_BCAST_ADDR, sizeof(beaconInfo_t),
&data);
return SUCCESS;
}
return FAIL;
}
event result_t SendInf.sendDone(TOS_MsgPtr msg, result_t
success)
{
pending = FALSE;
signal MsgLoc.sendComplete(success);
return SUCCESS;
}
Queste operazioni appena descritte sono di particolare rilevanza in quanto sono alla base
del meccanismo di comunicazione che è stato utilizzato per realizzare un’implementazione
NesC dell’algoritmo ROCRSSI++.
Per completezza riportiamo il modello del componente RfmToBea (in figura 4.9) questo
componente ha uno scopo duale al componente visto prima, in quanto gestisce
l’occorrenza di eventi quali la ricezione di messaggi radio estrapolando dal loro interno, il
100
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
messaggio beaconInfo_t . Analogamente a quanto detto prima, anche in questo caso si
utilizzano due interfacce ReceiveMsg che saranno distinte tramite l’uso di alias, che
consentono di particolarizzare il comportamento a seconda del tipo di messaggio ricevuto
Figura 4.9 – Wiring del componente RfmToBea
.
Analizziamo ora il modulo RfmToBeaM (il codice è riportato di seguito). La cosa più
interessante che si evince anche dal codice è l’implementazione di due eventi
receive(TOS_MsgPtr m), uno per ogni interfaccia e quindi uno per ogni tipo di
messaggio. Per quanto riguarda i comandi il discorso è praticamente identico a quello fatto
in precedenza per il modulo BeaToRfmM.
101
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
module RfmToBeaM {
provides interface StdControl;
uses {
interface ReceiveMsg as ReceiveBeaInfMsg;
interface ReceiveMsg as ReceiveBeaTabMsg;
interface MsgLoc;
interface StdControl as CommControl;
}
}
implementation {
command result_t StdControl.init() {...}
command result_t StdControl.start() {...}
command result_t StdControl.stop() {...}
event TOS_MsgPtr ReceiveBeaInfMsg.receive(TOS_MsgPtr m) {
beaconInfo_t *beaInf = (beaconInfo_t *)m->data;
...
return m;
}
event TOS_MsgPtr ReceiveBeaTabMsg.receive(TOS_MsgPtr m) {
beaconTab_t *beaTab = (beaconTab_t *)m->data;
...
return m;
}
...
}
4.3 Implementazione del ROCRSSI++
Nel paragrafo precedente si è cercato di delineare l’ambiente e le caratteristiche del
linguaggio di programmazione NesC, si sono fatti poi esempi di componenti ed interfacce
fino alla realizzazione di una semplice applicazione. Si è cercato quindi di fornire alcuni
elementi base per la comprensione della modalità d’implementazione dell’algoritmo di
localizzazione proposto: il ROCRSSI++. Si partirà dall’analisi del componente di più alto
livello, se ne darà il modello di wiring, si identificheranno i vari componenti fornendo una
loro descrizione dopodichè si entrerà nel dettaglio di alcuni componenti fondamentali fino
all’illustrazione di porzione di codice delle parti più interessanti.
4.3.1 Componenti principali del sistema di localizzazione
Per realizzare concretamente il sistema di localizzazione, l’applicazione è stata suddivisa
102
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
in componenti in modo da garantire i criteri di programmazione quali modularità ed
estendibilità che sono caratteristici della programmazione in TinyOS. Inoltre si è cercato
di implementare il sistema offrendo vari livelli di astrazione, da quello più alto (che
garantisce l’indipendenza dal particolare algoritmo di localizzazione) fino ai livelli di
astrazione hardware, per garantire la portabilità del software svincolandolo dalle
particolari piattaforme hardware. In tabella 4.3 sono elencati i principali componenti
utilizzati che compongono l’applicazione e la relativa descrizione
COMPONENTE
DESCRIZIONE
TestRocRssiC
E’ il componente di più alto livello utilizzato
per far partire l’applicazione
BeaInfoStorageC
Questo componente gestisce tutte le
informazioni necessarie alla localizzazione
LocC
Fornisce un livello di astrazione al sistema in
merito all’algoritmo di localizzazione
RocRssiC
Sviluppa l’algoritmo di localizzazione
ROCRSSI++
ADCC
Utilizzato per la rilevazione del valore di
RSSI e Battery
GenericComm
E’ il responsabile dell’invio e ricezione dei
messaggi radio
TimerC
Fornisce un timer e ne segnala la fine del
conteggio
LedsC
NodeToRfm
RfmToSync
Controlla l’accensione e lo spegnimento dei
led
Utilizzato in fase di test reali su sensore,
invia un messaggio radio
Utilizzato in fase di test reali su sensore,
riceve il messaggio radio e lo invia alla porta
seriale
UARTComm
Si usa per la comunicazione seriale
Tabella 4.3 – Componenti e descrizione
103
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Prima di passare all’illustrazione dei vari componenti si osservi la figura 4.10 dove è
riportata una struttura a livelli dell’ applicazione che dà orientativamente un’ idea di quali
sono i componenti di livello utente e quali quelli di livello più basso
Figura 4.10 – Struttura a livelli dell’applicazione realizzata
Il livello più alto (rappresentato in verde) è costituito dal componente principale ossia
TestRocRssiC, i componenti di primo livello immediatamente successivi (in blu) sono quei
componenti che forniscono le interfacce necessarie per utilizzare il sistema di
localizzazione, i componenti di secondo livello (in arancione) sono i componenti che
implementano l’algoritmo di localizzazione ROCRSSI++ utilizzando i componenti e le
interfacce di sistema sottostanti, queste a loro volta s’interfacciano con il livello di
astrazione hardware fornito da TinyOS.
4.3.2 Wiring dei Componenti
Nell’illustrare i particolari dei componenti principali nonché il loro modello di wiring,
104
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
partiamo dal componente di più alto livello, ossia quello che da il nome all’applicazione:
TestRocRssiC . In figura 4.11 è illustrato il wiring dei componenti relativo ad esso
Figura 4.11 – Wiring componente TestRocRssiC
I nodi rappresentano i componenti mentre gli archi sono le interfacce, il verso degli archi
va dall’utilizzatore dell’interfaccia al suo fornitore. Si può notare che il componente
principale Main utilizza cinque interfacce StdControl per avviare i componenti di primo
livello. Si trascurano i componenti NodeToRfm e RfmToSink, utilizzati solamente in fase di
testing e già nell’esempio del paragrafo precedente e si analizzano gli altri. Il componente
TimerC è un componente di sistema ed è necessario per utilizzare dei timer all’interno
dell’ applicazione. Infatti viene utilizzato, tramite l’interfaccia Timer, da un altro
componente di primo livello quale il TestRocRssiM che rappresenta il modulo del
componente principale, che ha lo scopo di far partire le operazioni di localizzazione e di
gestire l’evento di avvenuta localizzazione. Il componente TestRocRssiM utilizza
l’interfaccia SetAndGetInfo per settare e ricevere informazioni relative ai beacon e ai nodi
105
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
dal componente che detiene tali informazioni ossia BeaInfoStorageC. Infine utilizza
l’interfaccia MsgLoc per inviare il messaggio contenente le coordinate del nodo che ha
effettuato la localizzazione, questo comportamento si ha solo in fase di test. L’ultimo
componente di primo livello è il LocC che fornisce un livello di astrazione relativo
all’algoritmo di localizzazione utilizzato, infatti il componente TestRocRssiC utilizza
l’interfaccia Loc per demandare il compito di effettuare la localizzazione al componente
che fornisce tale interfaccia ossia proprio LocC, quindi in effetti, è a quest’ultimo
componente che spetta la scelta di quale algoritmo di localizzazione utilizzare. In figura
4.12 è riportato il wiring del componente LocC
Figura 4.12 – Wiring del componente LocC
Come si può notare anche dalla figura, il componente LocC rappresenta un’astrazione
dell’algoritmo di localizzazione utilizzato nella nostra applicazione, infatti in fase di
wiring ci limitiamo ad effettuare un’ uguaglianza tra le interfacce Loc e StdControl con il
componente che implementa la localizzazione, in questo caso è RocRssiC. In questo modo
si ha il grande vantaggio di poter sostituire l’algoritmo di localizzazione semplicemente
utilizzando un altro componente al posto del RocRssiC questo ovviamente contribuisce a
rendere il sistema modulare ed estendibile.
Avendo analizzato i componenti di primo livello, occupiamoci adesso di quelli di secondo
livello partendo proprio dal componente che implementa l’algoritmo di localizzazione.
Il wiring del componente RocRssiC riportato in figura 4.13 illustra che questo componente
controlla i componenti RocRssiM e BeaInfoStorage tramite l’interfaccia StdControl ed
106
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
utilizza
l’interfaccia
Loc
fornitagli
da
RocRssiM.
In
pratica
lascia
l’onere
dell’implementazione dell’algoritmo ai due componenti, in particolare utilizza l’interfaccia
Loc sia per avviare il processo di localizzazione che per gestire l’evento di avvenuta
localizzazione. Il componente RocRssiM a sua volta utilizza l’interfaccia BeaInfoStorage
Figura 4.13 – Wiring componente RocRssiC
per utilizzare le informazioni detenute dal fornitore di tale interfaccia ovvero
BeaInfoStorageC. Consideriamo adesso proprio il wiring relativo a quest’ultimo
componente illustrato in figura 4.13. Il componente BeaInfoStorageC delega al
componente BeaInfoStorageM il compito di fornire le interfacce utilizzate dai componenti
di livello superiore. Quest’ultimo componente ha il compito di raccogliere, inviare e
ricevere informazioni che saranno poi utilizzate per realizzare il sistema di localizzazione
ROCRSSI++. A questo punto bisogna fare una precisazione, il modulo BeaInfoStorageM
contiene al suo interno sia le istruzioni dedicate ai beacon sia le istruzioni dedicate ai nodi.
Questo permette di rendere l’intera applicazione più flessibile e riconfigurabile ed inoltre
consente di caricare la stessa applicazione su tutti i nodi della rete, che saranno distinti tra
beacon e nodi incogniti in base al loro ID (che sarà scritto nella memoria EEPROM in fase
d’installazione del programma). Il componente BeaInfoStorageC quindi, detiene per ogni
nodo della rete, informazioni riguardanti:
Il tipo di nodo (beacon di 1° livello, beacon di 2° livello, nodo) ed eventualmente
le sue coordinate (se si tratta di un nodo beacon)
La fase attuale dell’algoritmo
107
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
La tabella dei vicini con le relative informazioni
Contatore di messaggi inviati e ricevuti
inoltre contiene tutta un’altra serie informazioni che illustreremo in seguito. Ritorniamo
all’analisi della figura 4.14, e facciamo una precisazione, in figura non sono riportate
effettivamente tutte le interfacce utilizzate da BeaInfoStorageM e fornite da GenericComm
Figura 4.12 – Wiring del componente BeaInfoStorageC
Figura 4.14 – Wiring del componente BeaInfoStorage
ma solo la loro tipologia: SendMsg e ReceiveMsg infatti vengono utilizzate tante interfacce
SendMsg e ReceiveMsg quanti sono i tipi di messaggio utilizzati. Inoltre si può notare che
il componente BeaInfoStorageM utilizza:
L’interfaccia Leds, fornita da LedsC, per controllare i led del sensore (utilizzabili
anche per scopi di debug)
Le interfacce Rssi e BattLife fornite dal componente ADCC, usate
108
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
rispettivamente per rilevare il valore di rssi e l’autonomia della batteria
Le interfacce PhaseTimer e TxTimer, fornite da TimerC, che rappresentato
rispettivamente il timer di fase ed il timer di trasmissione messaggi
Ovviamente i componenti forniti dal sistema TinyOS come LedsC e TimerC definiscono
nei propri file di configurazione ulteriori wiring di componenti di più basso livello che
però non saranno oggetto di trattazione. In seguito invece verranno trattati alcuni aspetti
implementativi riguardo i vari moduli e configurazioni relativi all’applicazione.
4.4 Dettagli d’implementazione
In quest’ambito non verranno forniti i listati completi dei file riguardanti configurazioni,
moduli ed interfacce dell’applicazione, ma di questi si mostrerà quali sono le funzionalità
peculiari e come sono state implementate. Si partirà dall’illustrezione del file di libreria
contenente le strutture dati e le altre informazioni definite dall’ utente, poi si analizzarà in
dettaglio i componenti che implementano la localizzazione fino ad arrivare ai componenti
di più alto livello. Si sottolinea che anche in questo caso, come avviene abitualmente
nell’implementazione degli algoritmi distribuiti, si è progettata un’unica applicazione per
tutti i tipi di nodi presenti nella rete (beacon e nodi) in modo che ognuno di esso possa
assumere, eventualmente, entrambi i comportamenti. Normalmente il nome di un
componente si riferisce al proprio file di configurazione, nei sottoparagrafi successivi si
continuerà con questa convenzione.
4.4.1 File header: BeaconMsg.h
In questo file sono specificate le struttura dati e tutte quelle definizioni necessarie per lo
sviluppo dell’applicazione, riportiamo frammenti di codice riguardanti la prima parte del
file. Innanzitutto definiamo la grandezza dell’area su cui si estende la WSN (questa
informazione è necessaria per apportare le migliorie introdotte dal ROCRSSI+) in questo
caso è stata fissata ad una grandezza di 10x10 metri. Inoltre definiamo il numero di celle
che compongono la griglia necessaria per le operazioni di localizzazione (in seguito
109
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
...
// Dimensioni dell'area da scansionare [cm]
#define WIDTH 1000
#define HEIGHT 1000
// Griglia
#define DIM_X 51
#define DIM_Y 101
...
enum {AM_BEAMSG = 44,
AM_BEATAB = 45,
AM_COORDMSG = 46,
AM_BEACONREADY = 47,
AM_READY4BEACON = 48};
//Definizione tipo enumerativo ring area
typedef enum ringArea {INSIDE,OUTSIDE,BETWEEN} ringArea_t;
...
// fattore di scalamento
#define SCALE 255/1000
#define SCALE_PC 1000/255
verranno spiegate in dettaglio), dichiariamo un tipo enumerativo che contiene l’elenco dei
messaggi utente sottoforma di Active Message, utilizzati per la parametrizzazione delle
interfacce SendMsg e ReceiveMsg, infine utilizziamo l’enumerazione ringArea_t per
classificare la regione da scansionare (anche quest’aspetto verrà chiarito in seguito). Un
discorso più ampio si deve sulla rappresentazione numerica, infatti data la limitata capacità
di memoria e per limitare i consumi energetici, si è scelto di rappresentare le coordinate
all’interno del sensore, mediante numeri a virgola fissa. Inoltre si deve tener conto che
bisogna memorizzare una grande quantità di coordinate e che queste sono poi inserite
all’interno dei messaggi che vengono trasmessi via radio. Quindi per limitare il payload
dei messaggi e la loro occupazione in memoria si è scelto di discretizzare e quantizzare
tutte le coordinate delle posizioni utilizzando i coefficienti scalati nelle operazioni di
calcolo. Ovviamente questo implica una perdita di informazione, dato che la
quantizzazione non è una trasformazione invertibile comunque dalle prove effettuate si
evince che gli errori dovuti allo scalamento non sono significativi rispetto agli altri errori
che affliggono il sistema. Consideriamo un esempio relativo all’applicazione: la rete si
estende in un’area di 10x10 metri, si esprimano le coordinate in centimetri utilizzando
numeri interi senza segno. Se si vuole memorizzare ogni coordinata in un byte è
110
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
necessario prima normalizzarla dividendo per la lunghezza della regione e
moltiplicando per il numero di valori rappresentabili con un byte (in questo caso quindi la
si moltiplica per il fattore di scala (255/1000)). Nella quantizzazione uniforme l’errore è
dato da:
e
Pq
2
dove Pq è il passo di quantizzazione ed è uguale a:
Pq
1
Fs
dove Fs è il fattore di scala. In questo caso si ha che Fs
255 / 1000 , Pq
1 / 0.255 e
quindi l’errore introdotto dalla quantizzazione è pari a 1.96 cm.
Nella seconda parte sono specificate le strutture dati utilizzate per la memorizzazione e lo
scambio
d’informazioni necessarie ai fini dell’applicazione. Per completezza le
riportiamo di seguito.
Partendo dalla prima struttura dati, di seguito si riportano le relative descrizioni :
coord: contiene le coordinate del nodo
CoordMsg: (AM_COORDMSG) messaggio utilizzato per trasmettere le coordinate
in rete del nodo incognito che ha effettuato la localizzazione
beaconMsg: (AM_BEAMSG) messaggio usato dai beacon durante prima fase
beaconTable: (AM_BEATAB) messaggio utilizzato dai nodi incogniti per
localizzarsi
neighborsTab: tabella contenente le informazioni relative ai propri vicini
beaconReady: (AM_BEACONREADY) messaggio inviato dai beacon al termine
della prima fase
ready4Beacon: (AM_READY4BEACON) messaggio inviato dai beacon di 2°
livello
111
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
...
typedef struct coord {
uint8_t x;
uint8_t y;
} coord_t;
typedef struct CoordMsg {
uint16_t moteID;
uint16_t x;
uint16_t y;
} coordMsg_t;
typedef struct beaconMsg {
uint16_t moteID;
uint8_t type;
coord_t coordinate;
uint16_t rssi_dBm;
} beaconMsg_t;
...
typedef struct neighborsTab {
beaconMsg_t info[MAX];
uint16_t numberOfNeighbors;
} neighborsTab_t;
...
typedef struct beaconTable {
uint16_t moteID;
uint8_t type;
coord_t coordinate;
neighborsTab_t data;
} beaconTable_t;
...
typedef struct beaconReady {
uint16_t moteID;
} beaconReady_t;
typedef struct ready4Beacon {
uint16_t moteID;
bool readyOrNot;
coord_t coordinate;
neighborsTab_t data;
} beaconReady_t;
4.4.2 Componente RocRssiC
Questo componente è utilizzato dai nodi incogniti per effettuare la localizzazione. In
ingresso riceve messaggi contenenti le tabelle dei vicini di ogni beacon ed il relativo
valore rssi e dopo aver effettuato le operazioni necessarie, restituisce le coordinate
sottoforma di (x;y).
112
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
configuration RocRssiC {
provides {
interface StdControl;
interface Loc;
}
}
implementation {
components BeaInfoStorageC, RocRssiM
StdControl = BeaInfoStorageC;
StdControl = RocRssiM;
Loc = RocRssiM;
RocRssiM.BeaInfoStorage -> BeaInfoStorageC;
...
}
Si può notare che il compito di fornire l’interfaccia Loc è rimandato al modulo RocRssiM
qui vi è solo il wiring del componente BeaInfoStorageC utilizzato tramite la propria
interfaccia. Riportiamo quindi le parti salienti del codice relativo al modulo RocRssiM
module RocRssiM {
provides {
interface StdControl;
interface Loc;
}
uses {
interface BeaInfoStorage;
}
}
implementation {
...
void localize(coord_t *,const uint16_t, neighborsTab_t * ){...}
void scan(ringArea_t status,..., coord_t *posBref){...}
...
event result_t BeaInfoStorage.newBeaconMsg(uint16_t avgRssi,
beaconTable_t *pBeaconMsg )
{
…
iterations++;
localize(&(pBeaconMsg->coordinate),
avgRssi,&(pBeaconMsg->data));
…
if (iterations == MIN_NUM_BEACON) {
signal Loc.localizationDone(&position);
}
return SUCCESS;
}
...
}
113
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
interface BeaInfoStorage {
command neighborsTab_t * getNeighborTable();
event result_t newBeaconMsg(uint16_t,beaconTable_t);
}
Quando un nodo incognito riceve un beaconTable viene attivato l’evento
newBeaconMsg relativo all’interfaccia BeaInfoStorage (il cui codice è sopra riportato)
quindi inizia a stimare la propria posizione chiamando la funzione localize(…)
passandogli come parametri: le coordinate del beacon di cui ha appena ricevuto il
messaggio, il valore di rssi rilevato e la tabella dei vicini del beacon. Tutti i nodi incogniti
suddividono l'intera area della WSN (le cui dimensioni sono settate a priori) in celle di una
griglia e li associano un contatore inizialmente con valore pari a zero. Per ogni tabella
ricevuta il nodo individua la regione definita dalla corona circolare oppure dalla
circonferenza entro cui stima di trovarsi. Questa operazione è resa possibile attraverso il
confronto di valori di RSSI memorizzati nella tabella dei vicini con quello di RSSI relativo
al messaggio beaconTable ricevuto che la contiene come descritto in precedenza. A
questo punto, avendo individuato la regione d’interesse, il nodo incognito, può effettuare
la scansione di tutta la griglia tramite la funzione appositamente definita: scan(…),
incrementando il contatore delle celle corrispondenti a punti della rete interni al tale
regione. Iterando questo procedimento si arriverà ad una regione sempre più limitata,
caratterizzata da celle che avranno il contatore con valore maggiore rispetto a tutte le altre.
A scopo illustrativo è fornito un esempio grafico di scansione ed incremento dei contatori
per ogni cella. In figura 4.15 è mostrato un esempio in cui il nodo incognito S si localizza
tramite i tre beacon A,B e C. Il nodo S riceve un messaggio dal beacon A contenente
informazioni sui beacon vicini e si localizza all’esterno della circonferenza di raggio AB ,
quindi s’incrementano i contatori esterni a tale circonferenza. Poi riceve un simile
messaggio dal beacon C e si localizza nella circonferenza di raggio
CB dopodichè
s’incrementano i relativi contatori. Infine, ricevendo il messaggio dal beacon B. il nodo S
s’identifica nella corona circolare di raggio interno BA e raggio esterno BC e incrementa i
contatori delle celle appartenenti a questa corona circolare.
114
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 4.15 – Esempio di scansione ed incremento dei contatori
Per effettuare una stima della posizione del nodo incognito S è sufficiente calcolare il
baricentro della regione avente le celle con i contatori più alti (in figura 4.15 questa
regione è evidenziata inverde), tramite le formule:
1
1
x
xi mi
y
miI
m
yi mi
i I
Dove I è l’insieme dei punti avente contatore più alto,
xi , y i
rappresentano le
coordinate della cella i-esima, mi è il valore del contatore associato ed m è la somma di
tutti i contatori delle celle appartenenti ad I . Visto che tutte le celle di I hanno lo stesso
valore si utilizzano le formule :
x
1
n
xi
y
i I
1
n
yi
i I
Dove n rappresenta la cardinalità dell’insieme I
Vista l’importanza del ruolo ricoperto dalla griglia di celle, in quanto è grazie a questa che
riusciamo ad effettuare le operazioni di localizzazione, è opportuno fare alcune
considerazioni. Disporre di un numero di celle molto alto sicuramente migliora
115
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
l'accuratezza della procedura di scansione, a scapito però di un aumento della complessità
di calcolo e della memoria occupata. Quest’ ultimi rappresentano i parametri di progetto
che devono essere utilizzato nel dimensionare la griglia. Cercando il giusto trade-off tra i
parametri di progetto descritti e l’accuratezza della sima di localizzazione, si è preso
spunto da [29] e si è deciso di costruire una griglia di 101 per 102 celle, assegnando a
ciascuna cella un contatore di mezzo byte (4 bit) per un'occupazione complessiva di 5151
byte. Questa limitazione fa si che si effettuino al più 15 scansioni (che comportano un
relativo aumento del valore del contatore), quindi ogni nodo può acquisire informazioni al
massimo da 15 beacon. Questo è un numero più che ragionevole visto che di fatto, si
scelgono i migliori tre, e che l’area di test è piuttosto limitata. Questo tipo si soluzione
introduce inevitabilmente delle approssimazioni in quanto ad esempio, in una rete che si
estende su un'area di dimensioni 10x10 metri, si è in grado di distinguere punti che distano
almeno circa 10 cm l'uno dall'altro; questo non causa grossi problemi nella determinazione
della posizione stimata in quanto la regione d'intersezione trovata coinvolge un numero di
celle sufficiente a far si che l’effetto dell'approssimazione non sia rilevante.
4.4.3 Componente BeaInfoStorageC
E’ il componente che detiene tutte le informazioni necessarie ai nodi incogniti per
effettuare la localizzazione. Si può notare dal file di configurazione di seguito riportato,
che come avviene in ogni file di configurazione, anche in questo caso, si rimanda al
modulo, in questo caso, BeaInfoStorageM l’onere di fornire le interfacce utilizzate. In
particolare il modulo fornisce l’interfaccia SetAndGetInfo utilizzata dal componente
TestRocRssiC, l’interfaccia BeaInfoStorage utilizzata dal componente RocRssiC ed infine
l’interfaccia RssiUtil non utilizzata in quest’ambito ma pensata per sviluppi futuri qualora
un componente di più alto livello, volesse accedere ad informazioni del modulo inerenti il
calcolo del valore medio di RSSI.
116
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
configuration BeaInfoStorageC {
provides {
interface RssiUtil;
interface StdControl;
interface BeaInfoStorage;
interface SetAndGetInfo;
}
}
implementation {
components …
RssiUtil = BeaInfoStorageM;
StdControl = BeaInfoStorageM;
BeaInfoStorage = BeaInfoStorageM;
SetAndGetInfo = BeaInfoStorageM;
BeaInfoStorageM.SendBeaTab -> Comm.SendMsg[AM_BEATAB];
BeaInfoStorageM.ReceiveBeaTab -> Comm.ReceiveMsg[AM_BEATAB];
…
BeaInfoStorageM.RssiADC -> ADCC.ADC[0];
BeaInfoStorageM.BattADC -> ADCC.ADC[7];
}
Niente di nuovo da dire sul wiring relativo alle interfacce SendMsg e ReceiveMsg. Risulta
invece interessante il wiring relativo all’interfacciamento con il componente ADCC,
infatti qui si deve specificare la porta del canale relativo all’informazione desiderata.
Utilizzando il sensore MICA2 (di cui si parlerà in seguito), per ciò che riguarda il valore
di RSSI ci si metterà in ascolto sul canale 0, mentre per il valore di batteria si ascolterà il
canale 7. Riferiamoci alla parte più interessante ossia al modulo BeaInfoStorageM.
Innanzitutto si riporta, nella pagina seguente, la parte di codice relativa alle interfacce
utilizzate e fornite. Come si può notare dal numero di interfacce utilizza e fornite, questo è
il componente sicuramente più “corposo” sia da punto di vista delle linee di codice, sia dal
punto di vista della complessità. In seguito analizzeremo solamente la parti più
interessanti. Si passa ora a descrivere quali sono le funzionalità di questo modulo.
Innanzitutto implementa il protocollo di comunicazione radio che come già illustrato nel
capitolo 3 può essere distinto in due fasi: la prima, in cui i beacon di 1° livello popolano le
tabelle con i dati relativi al valore RSSI dei messaggi ricevuti dai propri vicini, e la
seconda in cui i nodi incogniti elaborano i dati memorizzati nelle tabelle ricevute.
117
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
module BeaInfoStorageM {
provides {
interface
interface
interface
interface
}
StdControl;
RssiUtil;
BeaInfoStorage;
SetAndGetInfo;
uses {
interface
interface
interface
interface
interface
interface
interface
interface
interface
interface
interface
}
Timer as TxTimer;
Timer as PhaseTimer;
Leds;
SendMsg as SendBeaTab;
ReceiveMsg as ReceiveBeaTab;
SendMsg as SendBeaconReady;
ReceiveMsg as RecBeaconReady;
SendMsg as SendReady4Beacon;
ReceiveMsg as RecReady4Beacon;
ADC as RssiADC;
ADC as BattADC;
}
Durante la prima fase ogni beacon tenta di trasmettere in istanti casuali (secondo il
protocollo MAC utilizzato: CSMA)
messaggi contenenti il proprio ID e le proprie
coordinate note a priori, se i canale è libero trasmette altrimenti se il canale è occupato o
non è impegnato a trasmettere si mette in ascolto. La trasmissione di messaggi è regolata
da un timer (TxTimer). Riportiamo parte della funzione d’invio che si attiva allo scadere
del timer.
void trySendMsg()
{
beaconMsg_t * pack;
pack = (beaconMsg_t *)msg.data;
pack->moteID = TOS_LOCAL_ADDRESS;
pack->type = beaconClass;
pack->coordinate = myCoord;
...
call SendBeaMsg.send(…);
}
...
event result_t TxTimer.fired()
{
msgSendCont++;
...
if (msgSendCont <= numMsg) {
trySendMsg();
} else {...}
return SUCCESS;
}
118
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Ogni volta che il beacon riceve il primo messaggio da un anchor node memorizza le
informazioni contenute e il valore di RSSI con cui ha ricevuto il pacchetto, mentre le volte
successive registra soltanto il valore di RSSI associato al pacchetto. Allo scadere del timer
che regola la durata della prima fase (PhTimer) oppure quando si raggiunge il numero
massimo di messaggi consentiti, ogni beacon calcola la media degli RSSI riferiti ai
pacchetti ricevuti da ciascun anchor node tramite la seguente funzone:
void calcAverages()
{
uint8_t i;
...
for (i=0; i<tableSize; i++) {
if (infoTable[i].ctr > 0) {
...
neighborsTab.info[i].rssi_dBm /= infoTable[i].ctr;
infoTable[i].ctr = 1;
...
}
...
}
}
Dopodichè ogni beacon costruisce una tabella di tipo beaconTable_t vista in
precedenza, contenente tra le altre informazioni anche il valore medio di RSSI appena
calcolato. Nella fase due sono i nodi incogniti a mettersi in ascolto del canale mentre i
beacon con la medesima procedura di trasmissione in istanti casuali, inviano messaggi di
broadcast contenenti la loro posizione e la tabella ordinata al decrescere del RSSI. Da
notare che la procedura d’invio messaggi è sempre la stessa, questo risulta chiaro anche
analizzando il codice:
void trySendMsg() {
...
switch (beaconState)
{
case 1:
...
...
break;
case 2:
...
...
break;
default: break;
}
...
}
//FASE 1
//FASE 2
119
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
infatti grazie alla variabile globale beaconState si riesce a capire in qual è la fase
corrente e ci si comporta di conseguenza. Infine, anche in questo caso, ciascun nodo
incognito calcola il valor medio di RSSI con cui ha ricevuto i messaggi beaconTable_t, ed
usa tale valore come parametro della funzione localize(…), vista in precedenza,
insieme alla tabella appena ricevuta; la funzione restituirà la posizione stimata.
Si precisa che ogni beacon ordina la tabella tramite una strategia di tipo insertion sort
prima di inviarla, in modo che chi la riceve (cioè i nodi incogniti) possa effettuare
immediatamente la suddivisione tra gli anchor node con RSSI maggiore e quelli con RSSI
minore, rispetto al valore RSSI del messaggio appena ricevuto dal beacon. Riportiamo per
completezza anche il codice relativo alla procedura di ordinamento:
void sortTable()
{
uint8_t i,j;
uint8_t id, id2;
coord_t coord;
uint16_t rssi;
dbg(DBG_USR1, "Sorting table\n");
for (i=0; i<tableSize; i++)
{
id = infoTable[i].moteID;
id2 = neighborsTab.info[i].moteID;
rssi = neighborsTab.info[i].rssi_dBm;
coord = neighborsTab.info[i].coordinate;
j = i;
while ((j > 0) && (neighborsTab.info[j-1].rssi_dBm < rssi))
{
infoTable[j].moteID = infoTable[j-1].moteID;
neighborsTab.info[j].moteID = neighborsTab.info[j-1].moteID;
neighborsTab.info[j].rssi_dBm = neighborsTab.info[j-1].rssi_dBm;
neighborsTab.info[j].coordinate = neighborsTab.info[j-1].coordinate
j = j - 1;
}
infoTable[j].moteID = id;
neighborsTab.info[j].moteID = id;
neighborsTab.info[j].rssi_dBm = rssi;
neighborsTab.info[j].coordinate = coord;
}
}
Si ricorda che l’ordinamento è decrescente, quindi si ordina la tabella dall anchor node più
vicino (il cui valore RSSI captato è maggiore) al quello più lontano (valore di RSSI
captato minore). Si precisa che al fine di avere un valore di RSSI captato da ogni nodo tale
da rispecchiare effettivamente la topologia di rete, si può pensare di far riferimento a
120
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
rilevazioni multiple di RSSI riferiti a più messaggi, in quanto sussistono dei fenomeni che
possono alterare il valore rilevato per ogni singolo messaggio. Uno di questi fenomeni è il
fading del canale, ecco perché è utile riferirsi al valore medio di RSSI su più pacchetti
ricevuti, invece che riferirsi ad uno soltanto. In definitiva quindi, il numero di messaggi
inviati in ogni fase è dipendente da quanto il mezzo trasmissivo risente dei fenomeni di
fading del canale. Il numero di messaggi è comunque stabilito in fase di compilazione ed
anche in questo caso bisogna trovare il giusto trade-off tra due parametri composti: da un
lato ci sono grandezze quali traffico di rete totale, invio per ciascun nodo e relativo
dispendio energetico, dall’altro c’è la precisione della rilevazione RSSI dipendente dal
chip radio, dalla varianza dei valori rispetto al rapporto RSSI-distanza, ed effetto di fading
sul mezzo trasmissivo.
4.4.4 Componente TestRocRssiC
Come detto in precedenza si tratta del componente di più alto livello, che controlla
l’inizializzazione e l’avvio di tutti gli altri componenti. Analizziamo parte del suo file di
configurazione:
configuration TestRocRssiC {
}
implementation
{
components ...
...
TestRocRssiM.Loc -> LocC;
TestRocRssiM.SetAndGetInfo -> BeaInfoStorageC;
TestRocRssiM.MsgLoc -> NodeToRfm;
...
}
Essendo il componente primario la sua implementazione si riduce ad un semplice wiring
dei componenti, in particolare si riscontra che è il modulo TestRocRssiM ad utilizzare le
interfacce Loc, SetAndGetInfo e MsgLoc . In particolare ci soffermeremo solo sulle prime
due. Iniziamo con Loc:
interface Loc {
command result_t localize();
event void localizationDone(coord_t *position);
}
121
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
il comando localize() avvia il processo di localizzazione, una volta avvenuta la
localizzazione
da
parte
del
nodo
incognito
viene
segnalato
all’
evento
localizationDone a cui vengono passate le coordinate cartesiane relative alla
posizione appena calcolata .
Passando all’interfaccia SetAndGetInfo, di seguito riportata:
interface SetAndGetInfo {
command result_t becomeBeacon();
command result_t beaconReadyReceived();
}
si può intuire che questa consente ai nodi che si sono localizzati, di poter diventare beacon
di 2° livello utilizzando il comando becomeBeacon() che comporterà l’aggiornamento
delle informazioni contenute nel modulo BeaInfoStorageC oltre all’invio del messaggio
Ready4Beacon in rete. Prima di poter far questo dobbiamo assicurarci di aver ricevuto il
messaggio BeaconReady e questo è possibile farlo tramite l’ utilizzo del comando:
beaconReadyReceived()
Passiamo alle parti di codice più interessanti contenute nel modulo TestRocRssiM
riportato nella pagina seguente. Nel momento in cui si verifica l’evento dell’interfaccia
Loc localizationDone(…) si inviano le coordinate del nodo appena ricevute via radio
tramite la funzione creata ad hoc void dump(…), che utilizza l’interfaccia MsgLoc. In
seguito si invoca la funzione ready4BecomeBeacon() che oltre ad effettuare alcuni
controlli relativi al livello di batteria e sugli anchor node usati per la localizzazione,
utilizza il comando SetAndGetInfo.beaconReadyReceived() visto in precedenza
per appurare se il nodo può diventare beacon di 2° livello. In questo caso s’invoca il
comando SetAndGetInfo.becomeBeacon() anche questo visto in precedenza, ed
inizia a comportarsi come beacon di 2° livello.
122
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
module TestRocRssiM {
...
implementation {
...
void dump(coord_t *position)
{
msg.moteID = TOS_LOCAL_ADDRESS;
msg.x = position->x;
msg.y = position->y;
call MsgLoc.sendCoord(&msg);
}
result_t ready4BecomeBeacon()
{
...
if (call SetAndGetInfo.beaconReadyReceived())
return SUCCESS;
}
...
event void Loc.localizationDone(coord_t *position) {
dump(position);
if (ready4BecomeBeacon()) {
dbg(DBG_USR1,"Ready for become beacon\n");
call SetAndGetInfo.becomeBeacon();
}
}
...
}
123
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Capitolo 5: Contesto di utilizzo
Nei capitoli precedenti (capitoli 3 e 4) è stato presentato il sistema di localizzazione che va
sotto il nome di ROCRSSI++. In particolare si è partiti dall’analisi del problema poi si è
passati alla progettazione valutando quali potevano essere le migliorie applicabili ed infine
se n’è mostrata l’implementazione in linguaggio NesC. In questo capitolo ci occuperemo
principalmente del contesto di utilizzo del sistema realizzato, infatti ci focalizzeremo su
aspetti di particolare rilevanza in quest’ambito quali l’interfacciamento di una rete di
sensori con il mondo reale. Per “mondo reale” s’intende tutta una serie di dispositivi come
ad esempio palmari, cellulari, o semplicemente pc, tramite i quali è possibile ricevere o
inviare informazioni da e verso la rete di sensori costruita. Innanzitutto si descriveranno le
metodologie per l’interfacciamento con una rete di sensori, si vedranno le due soluzioni
possibili e si descriverà nel dettaglio quella più comunemente utilizzata (anche in questo
contesto). Si parlerà poi, dell’applicazione reale installata nei sensori (SuLocSense) che è
dotata del sistema di localizzazione discusso ed inoltre consente un monitoraggio
ambientale generico tramite rilevazioni di luminosità, temperatura etc.
Inoltre si parlerà del progetto regionale entro il quale rientra il lavoro svolto, si descriverà
in breve, l’architettura iCAAS, si vedrà l’interfacciamento ad essa tramite lo sviluppo lato
clientil del protocollo ad hoc costruito ed infine s’illustreranno le altre possibili soluzioni
sperimentate concernenti il forwarding dei dati dalla rete verso il modo reale.
5.1 Interazione con una WSN
Nei capitoli precedenti (in particolare nei primi due) si è visto quali sono i parametri di
progetto di una WSN e quanto questi siano importanti. Nei capitoli 3 e 4 invece si è
124
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
discusso del sistema di localizzazione di cui i nodi appartenenti alla rete devono essere
muniti. Si parte quindi dall’ipotesi che si è in grado di progettare e programmare una rete
di sensori senza filo. Adesso si affronteranno le problematiche relative all’interazione con
la WSN.
Quindi data una rete di sensori, si vedrà quali possono essere le metodologie per:
inviare informazioni da una rete di sensori affinché queste possano essere fruibili
inviare comandi verso di essa.
Innanzitutto possiamo pensare a due tipi di soluzioni d’interfacciamento differenti:
Soluzione ad hoc
Soluzione TinyOS
La prima soluzione prevede lo sviluppo ad hoc di tutte le interfacce necessarie per
interagire con la rete di sensori. Quindi in una soluzione di questo tipo, lo sviluppatore
deve realizzare:
il protocollo di comunicazione tra PC e la gateway della WSN (che rappresenta il
punto di accesso alla rete) questa comunicazione potrebbe avvenire tramite porta
seriale, tramite USB, tramite Ethernet oppure onboard se si utilizza una Stargate
(per i dettagli si rimanda al paragrafo 5.3.2)
il protocollo dell’applicazione della WSN, che consente di distinguere le
tipologie dei pacchetti che viaggiano nella rete ed inoltre consente di effettuare il
parsing dei pacchetti contenenti informazioni di livello applicativo
intelligenza del gateway, cioè il suo funzionamento che può essere semplice
bridging, NAT-like etc.
Si capisce come questa soluzione rappresenti talvolta, una strada proibitiva in quanto
richiederebbe innanzitutto una profonda conoscenza di molti aspetti delle reti di sensori in
quanto si richiederebbe di realizzare il primo strato software quello cioè al livello del
sistema operativo. Inoltre la soluzione implementata può essere soggetta ad errori proprio
125
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
perché complessa è ricca di sfaccettature. Ecco perché quasi sempre si sceglie di utilizzare
la seconda soluzione ossia l’interazione tramite TinyOS che come descritto nel capitolo 4,
rappresenta uno standard de facto come sistema operativo per reti di sensori. Infatti
TinyOS:
implementa un protocollo di comunicazione PC <-> gateway
implementa un’interfaccia comune di accesso al gateway
tramite l’utilizzo del tool MIG (Message Interface Generator) consente la
generazione automatica di codice Java per il parsing dei pacchetti
Come s’intuisce, questa soluzione è molto più semplice e robusta della precedente, infatti
implementa un protocollo affidabile utilizzando parti di TinyOS (quali interfacce NesC di
sistema come UARTComm) e tool Java come SerialForwarder (di cui si parlerà in
seguito), inoltre non è particolarmente complessa in quanto fornisce un livello di
trasparenza alle applicazioni
di livello superiore che inviano e ricevono pacchetti
conformi a quelli scambiati nei sensori costituenti la rete; questo aspetto verrà chiarito in
seguito. In figura 5.1 è illustrata una situazione d’interazione tra la WSN ed il suo server:
Figura 5.1 – Interazione con una WSN tramite server
Questa è una tipica tipologia d’interazione con una WSN ovviamente non è l’unica, difatti
più avanti si presenterà la soluzione che prevede l’utilizzo di una stargate. Si analizzerà un
126
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
possibile comportamento relativo alla figura 5.1. All’interno della rete troviamo i sensori
che eseguono una qualsiasi applicazione, comunicando tra di loro ed eseguendo
elaborazioni. Dopodichè i nodi, inviano le informazioni (derivanti da rilevazioni o
elaborazioni) di livello applicativo alla gateway (chiamata anche base station) questa,
collegata fisicamente al server, provvede ad inviare queste informazioni. Dall’altro lato ci
sarà il server della WSN che sarà sicuramente provvisto di una distribuzione di TinyOS e
grazie a dei tools che questo mette a disposizione, potrà garantire la corretta ricezione dei
messaggi provenienti dalla rete. Ovviamente si ricorda che è possibile il flusso
d’informazioni anche nel verso opposto, ad esempio un operatore umano, operando su
applicazioni del WSN server, che forniscono apposite interfacce, può inviare dei comandi
alla rete, questi saranno inviati dal server verso il gateway e da quest’ultimo verso i
sensori interessati. I particolari di questo funzionamento si discuteranno quando
s’introdurrà il tool MIG e quando di parlerà della particolare applicazione realizzata.
5.1.1 Il tool Serial Forwarder
Il SerialForwarder è un tool sviluppato in java incluso nelle versioni di TinyOS 1.x, la sua
importanza diventa cruciale quando si vogliono costruire applicazioni orientate alla
comunicazione con una rete di sensori. Infatti questo tool è utilizzato per creare un canale
di comunicazione virtuale, tra le applicazioni di livello superiore (cioè quelle applicazioni
create con lo scopo di leggere dati e/o inviare comandi ad una WSN) e la WSN stessa
tramite la sua gateway. Partendo dall’esempio visto in precedenza (figura 5.1), in figura
5.2 è illustrato uno schema che ci aiuta a capire qual è la logica di funzionamento del
SerialForwarder (SF). In riferimento alla figura, da un lato troviamo i nodi che
costituiscono la rete di sensori, che comunicano tra loro utilizzando un collegamento senza
filo, dall’altro il server della WSN. Come si può notare, la gateway oltre a comunicare con
gli altri nodi della rete, è collegata serialmente al server, che tramite il SF può fornire
un’astrazione di collegamento con la rete di sensori. In pratica dal lato WSN, il SF riceve
ed inoltra rispettivamente pacchetti dati e comandi da e verso la rete di sensori utilizzando
il collegamento seriale.
127
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 5.2 – Schema di funzionamento Serial Forwarder
Dal lato server invece, il SF utilizza una socket TCP/IP per consentire ad un’applicazione
remota di collegarsi al server WSN, sempre sfruttando il protocollo TCP/IP, ed interagire
con la rete di sensori. Bisogna precisare però, che la soluzione più conveniente, usata
anche nell’ ambito in questione, è rappresentata dallo sviluppo di un’applicazione locale
che tramite un SF stub collegato alla socket TCP/IP in questione, sfrutta il SF per
interfacciarsi alla rete di sensori.
Come detto in precedenza, il SF è un tool già presente nelle distribuzioni di TinyOS 1.x
utilizzabile tramite il seguente comando ($TOSROOT/tools/java):
java net.tinyos.sf.SerialForwarder –comm <porta seriale utilizzata>:<baud rate>
In questo modo è possibile avviare il SF collegato con la specifica porta seriale alla quale
la gateway della rete sarà connessa. La GUI del SF sarà analoga a quella rappresentata in
128
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
figura 5.3:
Figura 5.3 – GUI Serial Forwarder
Nel text box in alto è specificata il porto a cui il SF fa riferimento, quindi qualora
un’applicazione, tramite SF stub, si volesse connettere ad esso dovrebbe collegarsi allo
specifico porto in questione. Nel text box successivo si specificherà il valore della
variabile d’ambiente MOTECOM, che specifica la piattaforma con cui si vuol comunicare.
I possibili valori di questa variabile sono riportati nella tabella 5.1:
Specifica
Descrizione
sf@<host>:<port>
Comunicazione con il software SerialForwarder
serial@<COMport>:<rate>
Comunicazione seriale RS232 (con gateway
MIB510) oppure USB (con gateway MIB520)
network@<host>:<port>
Comunicazione ethernet con gateway MIB600
tossim-serial@<host>
Comunicazione con il nodo 0 (sink node) del
simulatore TOSSIM
tossim-radio@<host>
Comunicazione con tutti i nodi del TOSSIM
Tabella 5.1 – Specifiche e descrizione della varibile d’ambiente MOTECOM
129
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Si precisa che <port> indica il porto della socket con la quale si vuole comunicare,
<COMport> indica la porta seriale alla quale è connessa il gateway; <host> è un
parametro opzionale, qualora non fosse esplicitato il suo valore di default è localhost .
Come si evince dalla tabella 5.1, nella comunicazione seriale o via software con SF in
cascata, occorre specificare il baud rate con il quale s’intende comunicare che è
dipendente da i sensori costituenti la rete, infatti si potrebbe anche specificare il tipo di
sensori utilizzati al posto del baud rate . I dettagli relativi al simulatore TOSSIM saranno
descritti nel capitolo successivo, ci si limita a sottolineare che questo è incluso nella
distribuzione TinyOS 1.x.
5.1.2 Interazione con java tramite MIG (Message Interface Generator)
Si è visto come il SerialForwarder è una sorta di server che crea un ponte tra i dati in
arrivo dalla comunicazione con la rete di sensori e le applicazioni client di alto livello
residenti nel WSN server. Si vedrà ora come queste applicazioni possono interagire con la
rete di sensori utilizzando il SerialForwarder. Innanzitutto TinyOS mette a disposizione
una serie di classi ed interfacce java che consentono la comunicazione con la WSN,
contenute nei package net.tinyos.message e net.tinyos.packet. Si analizzeranno quelle di
maggior interesse:
net.tinyos.message.MoteIF: rappresenta l’astrazione java di un sensore della rete,
e rappresenta la classe base da utilizzare per ricevere ed inviare dati al gateway
net.tinyos.message.MessageListner: è l’interfaccia che rappresenta un listner per
i messaggi in arrivo dal SF (che a loro volta provengono dal gateway della rete)
net.tinyos.packet.BuildSource: è la classe che rappresenta la sorgente dei
pacchetti destinati al SF, in altre parole rappresenta un’implementazione del
gateway
net.tinyos.packet.PhoenixSource: questa invece è l’interfaccia fornita dal
gateway
Queste classi ed interfacce saranno utilizzate (o implementate nel caso ad esempio di
130
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
MessageListner) dalle applicazioni costruite per comunicare con la rete di sensori, infatti
rappresentano la base per instaurare la suddetta comunicazione. Un esempio di
applicazione java che “ascolta” i messaggi provenienti dal gateway di una rete di sensori, è
l’applicazione Listen .
Questa semplice applicazione, ovviamente supportata dal SF, stampa a video i dati grezzi
provenienti dal gateway. Ecco un esempio di output dell’applicazione invocata tramite il
seguente comando (partendo da questa directory: $TOSROOT/tools/java) a partire dai
pacchetti inviati dall’applicazione relativa al sistema di localizzazione TestRocRssi.nc
java net.tinyos.tools.Listen
Figura 5.4 – Output relativo all’applicazione Listen
Si è utilizzato il simulatore TOSSIM (che verrà trattato nel dettaglio nel prossimo
capitolo) per simulare una rete di sensori che eseguivano l’applicazione vista nel capitolo
4 relativa al sistema di localizzazione implementato, si è utilizzata poi un’istanza del
SerialForwarder per ricevere le informazioni dalla rete ed inoltrarle alle applicazioni
client ed infine si è lanciata l’applicazione Listen che rappresenta un’applicazione client
del SF, che si è messa in ascolto dei pacchetti provenienti da questo ed ha prodotto come
risultato la stampa a video dei pacchetti ricevuti. Si può notare che ogni singolo pacchetto
ricevuto viene rappresentato come una stringa di byte dove (in riferimento all’esempio):
i primi due byte (7E 00) rappresentano l’indirizzo del nodo sorgente
il terzo byte (2E) rappresenta l’ ID del particolare Active Message
il quarto byte (7D) rappresenta il group ID
il quinto byte (06) è la lunghezza del messaggio
i byte sei e sette (03 00) rappresentano l’indirizzo del sensore che ha inviato
131
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
l’informazione
ed i restanti byte rappresentano il payload del messaggio (i primi due byte
rappresentano la coordinata X gli altri la coordinata Y)
Risulta evidente che l’applicazione Listen rappresenta la soluzione più semplice per
l’interazione con una WSN. Anche se molto semplice, questa non rappresenta sicuramente
la soluzione più comoda per ottenere informazioni e monitorare i messaggi che arrivano da
una rete di sensori, in quanto costituisce una soluzione di basso livello. Infatti
quest’applicazione si limita ad effettuare una stampa a video di una stringa di byte
rappresentanti del messaggio ma non effettua alcun parsing dello stesso che consentirebbe
di strutturare il messaggio ricevuto. L’operazione di parsing consiste nell’analizzare un
pacchetto e creare una corrispondenza tra informazioni contenute in esso e byte che
rappresentano tali informazioni. Ovviamente le informazioni contenute nei pacchetti in
arrivo dalla WSN dipendono dalla particolare applicazione installata nei sensori, ad
esempio il sistema di localizzazione realizzato invierà informazioni sottoforma di
coordinate (x;y) del nodo incognito, applicazioni come LightTemp invierà informazioni
quali luminosità e temperatura e così via. Quindi risulta ovvio che si necessità di
un’operazione di parsing in modo da identificare le informazioni provenienti da una WSN.
Il tool che TinyOS mette a disposizione per facilitare quest’operazione è il MIG (Message
Interface Generator). Il tool MIG genera codice java per il parsing dei messaggi relativi
ad una WSN ed inoltre fornisce servizi aggiuntivi, in quanto consente di risolvere i
problemi di cross-plattaform, come ad esempio, il passaggio da un sistema big endian a
little endian e viceversa. Possiamo vedere questo tool anche come una sorta di middleware
in quanto, partendo da strutture dati di livello sensore, crea delle classi java che
contengono metodi per accedere alle informazioni contenute nei messaggi in arrivo dalla
rete di sensori. In figura 5.5 è rappresentato il funzionamento dal punto di vista
concettuale del MIG, partendo da un file header (simile a quelli visti nel capitolo 4), dove
all’interno
troveremo
la
definizione
delle
strutture
dati
utilizzate
poi
nella
programmazione in NesC dei sensori,
132
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 5.5 – Funzionamento concettuale del MIG
si generano classi java contenenti metodi d’accesso a quelle strutture dati a cui si è
interessati. Si farà un esempio relativo all’applicazione presentata nel capitolo 4:
TestRocRssi. Quest’applicazione NesC, è composta da vari componenti memorizzati in
file con estensione .nc, questi includono i file header “BeaconMsg.h” e “BeaconCmd.h” .
Di quest file riportiamo la parte interessata ossia quella relativa alle strutture dati:
“BeaconMsg.h”
enum {AM_COORDMSG = 46}
typedef struct CoordMsg {
uint16_t moteID;
uint16_t x;
uint16_t y;
} coordMsg_t;
“BeaconCmd.h”
enum {AM_BEACONCMD = 43};
typedef struct beaconCmd {
uint8_t cmdType;
union {
uint32_t newRatePhaseTimer;
uint16_t newRateMsgTimer;
} args;
} __attribute__ ((packed)) beaconCmd;
133
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Per generare le classi parser per le strutture dati d’interesse (in questo caso CoordMsg e
beaconCmd) utilizziamo rispettivamente i comandi:
mig –java-classname=BeaconMsg BeaconMsg.h CoordMsg
mig –java-classname=BeaconCmd BeaconCmd.h beaconCmd
in generale la sintassi è la seguente:
mig <opzioni> -java –classname=<classe_java> <file_header> <struct>
dove:
<classe java>: è il nome della classa java (eventualmente completo del nome del
package di appartenenza) che rappresenta il parser
<file_header>: rappresenta il path del file header dov’è definita la struttura dati
<struct>: è il nome della struttura dati
Prima di concludere si vuole precisare che non è stata casuale la scelta dell’esempio
appena visto in quanto rappresenta proprio ciò che è stato realmente utilizzato nel sistema
di localizzazione. In figura 5.6 è illustrata la classe CoordMsg generata dal tool MIG.
Figura 5.6 – Classe CoordMsg generata dal tool MIG
134
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Nel prossimo paragrafo si parlerà dell’applicazione che realizza il sistema di
localizzazione ma offre anche altre funzionalità.
5.2 Applicazione SuLocSense
Come si vedrà in seguito, l’algoritmo di localizzazione progettato ed implementato nei
capitoli precedenti, s’inserisce in un contesto più ampio. Proprio per questo motivo si
capisce che l’applicazione vista nel capitolo 4 (TestRocRssi), che si limita ad offrire il
servizio di localizzazione per i nodi incogniti ed a segnalare la loro posizione a scopo di
test, non è sufficiente visto che comunque ci si trova in un contesto di monitoraggio
ambientale. Ecco perché si è scelto di integrare l’algoritmo che consente la localizzazione
dei nodi incogniti con un’applicazione, per la verità abbastanza generica, che consente il
rilevamento di grandezze fisiche quali luminosità, temperatura, accelerazione etc.
Quest’integrazione ha dato origine all’applicazione che va sotto il nome di SuLocSense. Il
nome stesso dell’applicazione, suggerisce che questa è nata dalla fusione dell’applicazione
che permette la localizzazione (Loc) con l’applicazione Surge_Reliable (Su) che consente
invece la raccolta d’informazioni dall’ambiente circostante quali luminosità, temperatura
etc. tramite l’hardware apposito (Sense). In figura 5.7 è sottolineata quest’integrazione:
Figura 5.7 – Integrazione nell’applicazione SuLocSense
135
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Non si mostrano i dettagli implementativi relativi al wiring dei componenti in quanto
quest’argomento è stato ampiamente discusso nel capitolo precedente, piuttosto ci si
focalizza sull’integrazione dei due componenti (SurgeC e LocC) che generano
l’applicazione SuLocSense che è quella che effettivamente si installa nei sensori costituenti
la WSN utilizzata nel contesto in questione. Dato che nel capitolo precedente, si è discusso
ampiamente del sistema di localizzazione, ci focalizzeremo adesso sull’applicazione.
5.2.1 Applicazione Surge_Reliable
L’applicazione che consente le rilevazioni relative all’ambiente circostante, ovviamente
sempre che l’hardware supporti tale funzionalità, si chiama Surge_Reliable .
Quest’applicazione funziona in questo modo: ogni nodo della rete effettua delle rilevazioni
relative all’ambiente circostante (luminosità temperatura etc.), interrogando ciclicamente i
rispettivi pin della sensorboard, dopodichè i nodi impacchettano queste informazioni in
messaggi che poi inviano in rete. L’impacchettamento di questo tipo di messaggio avviene
in modo leggermente differente rispetto a quanto visto nel capitolo 4 in figura 4.4, infatti
qui oltre all’incapsulamento all’interno del TOS_Msg (che rappresenta l’astrazione degli
Active Message), il messaggio dati in questione (che chiameremo SurgeMsg)
verrà
incapsulato anche nel TOS_MHopMsg (astrazione dei messaggi multihop) come mostrato
in figura 5.8
Figura 5.8 – Incapsulamento messaggio SurgeMsg
136
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Come mostrato in figura, il messaggio SurgeMsg che contiene i seguenti campi:
typedef struct SurgeMsg {
uint8_t moteID;
uint8_t type;
uint16_t reading;
uint16_t parentaddr;
uint32_t seq_no;
uint8_t light;
uint8_t temp;
uint8_t magx;
uint8_t magy;
uint8_t accelx;
uint8_t accely;
uint16_t rssi;
} __attribute__ ((packed)) SurgeMsg;
viene incapsulato all’interno di un messaggio multihop e questo a sua volta è contenuto in
un Active Message . Si apre una piccola parentesi per definire il protocollo multihop.
Innanzitutto definiamo il multihop come un protocollo che consente di trovare un percorso
minimo sul quale inviare un messaggio destinato ad un particolare nodo. Solitamente
viene sfruttato affinché anche nodi fuori dalla portata dal gateway possano inviare
messaggi a quest’ultimo. E’ indispensabile, ai fini di poter sfruttare il protocollo multihop,
effettuare l’incapsulamento visto in figura 5.8, in modo da consentire ai i componenti che
implementano il protocollo di inviare il messaggio (sempre tenendo presente che è
necessario un ulteriore incapsulamento all’interno del Active Message). Questi componenti
sono inclusi nella libreria dedicata al multihop nella distribuzione 1.1.15 di TinyOS. Qui il
protocollo multihop si basa sul valore di LQI. Per definire quest’ultimo precisiamo che il
nodo a cui vengono inviati i messaggi viene chiamato nodo parent e ad esso vengono
associati un costo ed un LQI, ossia un parametro sintetico di qualità del canale e può
essere calcolato in molti modi. In definitiva il protocollo multihop, in questo contesto, è
utilizzato quando si vuol permettere ai nodi “lontani” dal gateway di inviare a questo le
informazioni all’interno dei messaggi SurgeMsg e CoordMsg contenenti rispettivamente le
rilevazioni ambientali (come luminosità, temperatura etc.) e le coordinate dei nodi
incogniti. Concludiamo il discorso relativo all’applicazione Surge_Reliable mostrando
alcune sezioni di codice del file di configurazione SurgeC.nc
137
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
configuration Surge {
}
implementation {
...
SurgeM.Rssi -> ADCC.ADC[0];
SurgeM.Temp
-> PhotoTemp.ExternalTempADC;
SurgeM.Light
-> PhotoTemp.ExternalPhotoADC;
SurgeM.AccelX
-> Accel.AccelX;
SurgeM.AccelY
-> Accel.AccelY;
SurgeM.AccelCtl
-> Accel;
SurgeM.TempStdControl
-> PhotoTemp.TempStdControl;
SurgeM.LightStdControl
-> PhotoTemp.PhotoStdControl;
...
SurgeM.RouteControl -> multihopM;
SurgeM.Send -> multihopM.Send[AM_SURGEMSG];
SurgeM.SendToCOM -> COM.SendMsg[AM_SURGEMSG];
multihopM.ReceiveMsg[AM_SURGEMSG]->Comm.ReceiveMsg[AM_SURGEMSG];
...
}
La prima parte del wiring è relativa ai componenti che effettuano le rilevazioni relative
all’ambiente circostante, mentre l’ultima parte del codice si riferisce al wiring dei
componenti che permettono l’utilizzo del protocollo multihop e l’invio e la ricezione di
messaggi multihop. Si conclude facendo un’osservazione in merito ad una possibile
ottimizzazione dal punto di vista energetico della WSN: si potrebbe pensare di installare
l’applicazione SuLocSense solamente nei nodi beacon in quanto questi li possiamo pensare
dotati di una riserva di energia maggiore o addirittura collegati alla rete elettrica, mentre in
tutti gli altri nodi s’installerà soltanto il sistema di localizzazione. I beacon quindi, sono
indispensabili nel sistema di localizzazione per quanto visto finora, inoltre effettuano
rilevazioni, grazie al componente Surge_Reliable ed implementano il protocollo multihop
che offre il supporto di routing dei pacchetti destinati al gateway (in quanto contenenti
informazioni di livello utente) inviati da nodi fuori dal suo raggio di copertura.
5.3 Ambito di utilizzo: progetto regionale ed architettura iCAAS
Il lavoro svolto in quest’ambito si colloca all’interno di un contesto più ampio ossia quello
del progetto che va sotto il nome di REMOAM. Il principale obiettivo del progetto
REMOAM (REti per il MOnitoraggio AMbientale) finanziato dalla regione Campania è la
138
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
definizione di una nuova generazione di prodotti per il monitoraggio. Il servizio di
monitoraggio fruisce tramite l’utilizzo di prodotti atti a costituire una rete di sensori senza
filo. I nodi (sensori) che compongono questa rete, si occupano del monitoraggio del
territorio interessato, raccogliendo informazioni su di esso. Dopodichè, tramite l’utilizzo
di sistemi software avanzati, vi è la fruizione di tali informazioni. Il progetto in esame, si
riferisce in modo particolare, al monitoraggio dei rischi ambientali che derivano dalle
frane, ovviamente senza trascurare la possibilità di effettuare monitoraggio ambientale in
altri ambiti. Si è scelto di valutare la possibilità di utilizzo delle WSN per il monitoraggio
di frane in quanto oggi per effettuare monitoraggio di questo tipo si utilizzano tecnologie
basate su sistemi inclinometrici che implicano che in sensori vadano installati a profondità
piuttosto elevate. Si capisce subito che questo costituisce un grosso limite per ciò che
riguarda l’installazione di tali sensori su terreni a rischio di frane (non è consigliabile
utilizzare macchine perforatrici su terreni franosi) inoltre ci sono molti problemi relativi al
cablaggio. Si capisce come l’utilizzo di una WSN risolverebbe molti di questi problemi.
Per quanto concerne la possibilità di utilizzare l’intera soluzione concepita in ambiti
diversi, di seguito si farà riferimento all’architettura iCAAS che non verrà trattata nei
dettagli ma piuttosto presentata per introdurre il metodo d’interfacciamento ad essa.
5.3.1 Arcitettura iCAAS
Come già esposto in precedenza, l’architettura iCAAS va ad inserirsi in un contesto mirato
all’analisi di rischi ambientali dovuti a fenomeni franosi. L’obiettivo principale di
quest’architettura quello di offrire una soluzione generica in modo da poter essere
applicata in contesti diversi. La sua struttura è stata concepita per orientarsi verso una rete
di sensori, ma essendo dotata di caratteristiche di estendibilità e configurabilità può essere
applicata in ambiti diversi. In figura 5.9 è rappresentata l’architettura tramite una struttura
a livelli, in sintesi si è cercato di sviluppare un sistema che consenta l’accesso ai dati è
l’interoperabilità tra le reti di sensori ed i terminali utenti, offrendo la possibilità all’utente
non solo di accedere alle informazioni che il sistema mette a disposizione (tramite
terminali eterogenei, computer destop, palmari, cellulari etc…) ma anche d’interagire con
139
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 5.9 – Architettura iCAAS da [48]
esso da punti distanti dal rete di sensori in questione.
I dettagli relativi a quest’architettura esulano dagli scopi e sono illustrati in [48]. In
quest’ambito ci focalizzeremo solamente sull’ultimo livello, vale a dire l’interazione tra la
rete di sensori (in figura Sensor Networks) ed il Sensor networks access, in particolare se
ne illustrerà la parte client.
5.3.2 Possibile soluzione WSN con stargate e comunicazione con iCAAS
Innanzitutto s’identifica una stargate come una sorta di super nodo appartenete alla rete di
sensori, si tratta infatti di una piattaforma hardware ad elevate prestazioni e viene
utilizzata come Wireless Gateway di una rete Wireless. E’ basata sul processore X-Scale
di Intel, su un supporto nativo Linux e mette a disposizione numerosi tool di sviluppo ed
applicazioni grazie all’utilizzo di TinyOS. Di seguito, in tabella 5. sono riportate le
140
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
caratteristiche tecniche relative alla stargate della Xbow.
Proprietà
Caratteristiche
Processore
Processore Intel PXA255, XScale, 400 MHz
Memoria
64 MB RAM, 32 MB flash (22 per programmi)
Embedded Linux open source sviluppato come
Sistema Operativo
progetto da source forge
PCMCIA slot tipo II
Slot
Compact Flash slot tipo II
MICA2 slot a 51 pin
Porta seriale (RS232), USB, Ethernet (RJ45) e
Connessione
Wi-Fi
Tabella 5.2 – Caratteristiche tecniche Stargate Xbow
Quindi possiamo pensare la nostra rete di sensori non più collegata, attraverso il gateway
con un collegamento seriale (o USB), al server della WSN, ma costituita da nodi che
interagiscono tra loro e con la stargate; sarà poi quest’ultima ad avere l’intelligenza
necessaria per inoltrare le informazioni ricevute dalla WSN verso altre mete. Questa
rappresenta una soluzione veramente interessante soprattutto nell’ambito in questione,
infatti l’utilizzo di un server WSN (soluzione vista prima) implica che questo debba essere
collocato nelle vicinanze della rete di sensori in quanto deve essere fisicamente collegato
al gateway per poter ricevere informazioni. Talvolta ciò richiede costi aggiuntivi per
creare un ambiente apposito per l’installazione di un server, o addirittura potrebbe risultare
impossibile tale installazione data la conformazione del territorio nel quale si va a calare la
rete di sensori. Ecco perché soprattutto per quanto concerne il monitoraggio sui rischi
ambientali derivanti da fenomeni franosi, l’utilizzo della stargate potrebbe risultare
indispensabile. Si vedrà adesso, in figura 5.10, un quadro generale dell’ambito d’utilizzo,
partendo dalla rete di sensori, passando per la comunicazione con la stargate fino al
collegamento con l’architettura iCAAS.
141
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 5.10 – Contesto generale nel quale s’inserisce la rete di sensori
S’inizia dall WSN, i nodi sono composti da una base (nello specifico si sono utilizzati per
alcune sperimentazioni i MICA2 però è possibile utilizzare altre piattaforme) e da un
sensorboard (che effettua le rilevazioni). Tutti i nodi della WSN comunicano con la
stargate tramite WiFi. Come si può notare dalle caratteristiche tecniche presentate nella
tabella 5.2, dal punti di vista della potenza di calcolo e memoria centrale la stargate è
142
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
sicuramente inferiore rispetto ai moderni PC che possiamo pensare di utilizzare come
server della WSN nella soluzione prima descritta. Ecco perché si è deciso di sviluppare un
protocollo UDP ad-hoc che fosse innanzitutto più semplice e snello rispetto al TCP/IP e
che consentisse l’inoltro dei dati raccolti verso l’architettura iCAAS. Inoltre il canale tra la
stargate ed iCAAS potrebbe essere wireless, ad esempio tramite GPRS, e dunque il TCP
risulterebbe inadatto, ragione in più per utilizzare il protocollo sviluppato ad-hoc.
Dopodichè quest’architettura rende fruibili queste informazioni attraverso internet. Questo
è il funzionamento generale del sistema creato per questo particolare ambito di utilizzo.
Entriamo ora nel dettaglio del livello Sensor networks access dell’architettura iCAAS lato
client ed analizzeremo il funzionamento del protocollo ad hoc sempre dal punto di vista
del client. Nell’analisi del Sensor networks access si partirà dalla rete di sensori. Si è visto
che dalla WSN arrivano messaggi sottoforma di stringhe di byte, quindi innanzitutto c’è
bisogno di effettuare un parsing dei pacchetti ricevuti, dopodichè si formattano queste
informazioni in un formato che si è scelto standard per il protocollo creato, ed infine
s’inviano queste informazioni all’interno di pacchetti UDP. Questo procedimento è
rappresentato in figura 5.11
Figura 5.11 – Procedimento relativo all’invio dati da WSN ad iCAAS
Come è noto dalla rete di sensori arrivano stringhe di byte, queste vengono interpretate
tramite l’ausilio del tool MIG visto prima, il blocco Application Parser. Si è dato questo
nome in quanto questo rappresenta il parser specifico per l’applicazione residente nei
sensori. Questo fornisce in uscita dati strutturati, tramite il blocco successivo, ovvero
Stargate Protocol Formatter questi dati vengono formattati secondo uno specifico formato
deciso nel protocollo ad hoc utilizzato. Dopodichè grazie allo Stargate proxy Server che
143
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
riceve dal blocco precedente i dati formattati, s’inviano le informazioni all’architettura
iCAAS all’interno di pacchetti UDP. Si precisa che il protocollo UDP creato ad hoc non si
limita ad un semplice forwarding dei pacchetti ma si è creato un protocollo UDP esteso
che prevede la perdita di pacchetti ed il loro rinvio con modalità selective repeat . Si
precisa che si è scelto di dividere il procedimento di parsing dei pacchetti da quello della
formattazione dei dati e da quello dell’invio sottoforma di pacchetti UDP per fornire
modularità e ricusabilità del software. Infatti qualora si volesse cambiare l’applicazione
all’interno dei sensori ma mantenere lo stesso protocollo di comunicazione verso
l’architettura iCAAS, basterebbe sostituire la parte relativa all’Application Parser, se
invece si volesse utilizzare un protocollo differente si dovrebbe cambiare solo la parte
relativa allo Stargate Protocol Formatter infine se si volesse cambiare il destinatario si
dovrebbe implementare nuovamente lo Stargate Proxy Server. Si capisce quindi perché si
è scelto tale metodologia di progettazione. Si vedranno ora alcuni dettagli implementativi
relativi a quanto detto finora. Nel realizzare questo strato software che consente al client
(in questo caso la stargate) di comunicare con il server dell’architettura iCAAS, sono state
create apposite classi ed interfacce java che consentono di comunicare con iCAAS e allo
stesso tempo di essere riutilizzate per altri scopi. In figura 5.12 è rappresentato il
diagramma delle classi che rappresenta il Sensor networks access lato client relativo ad
una generica applicazione per WSN. Partendo dal flusso di byte che arriva dalla rete di
sensori, la classe NesCAppServer rappresenta l’ Application Parser visto in figura 5.11,
infatti questa ha il compito di ricevere i pacchetti lato WSN ed interpretarli (tramite
l’operazione di parsing presentata precedentemente); inoltre utilizza l’interfaccia IStargate
per effettuare anche la formattazione ti tali dati secondo il protocollo (s’implementa quindi
il blocco Stargate Protocol Formatter di figura 5.11).
Si apre a questo punto una piccola parentesi. Nell’applicazione discussa precedentemente
SuLocSense ossia quella ideata per essere utilizzata nell’ambito in questione, all’interno di
questa classe i dati provenienti dalla WSN vengono etichettati con un valore temporale che
serve a creare una relazione d’ordine per le misurazioni effettuate.
144
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 5.12 - Diagramma delle classi relativo al Sensor networks access (lato client)
Tornando all’analisi di figura 5.12, grazie all’interfaccia IStargate è possibile collegarsi a
server iCAAS tramite un proxy rappresentato dalla classe StargateProxy. Quest’ultimo ha
il compito di rendere trasparente l’invio dei dati al server iCAAS, tramite il protocollo
UDP implementato ad hoc, alle classi viste finora. Prima di proseguire nella descrizione
delle classi, si vedrà, brevemente, come funziona il protocollo .
UDP appositamente creato. Innanzitutto c’ è un fase di inizializzazione della connessione,
dove il client (in questo caso la stargate) tenta di contattare il server (architettura iCAAS)
(si noti che è improprio l’utilizzo della parola “connessione” in quanto si utilizza un
protocollo di tipo datagram). Quando il server risponde, il client è pronto ad inviare i
pacchetti UDP all’interno dei quali sono stati memorizzati i dati provenienti dalla WSN.
Prima di inviare il pacchetto dati, il client etichetta quest’utlimo con un numero
progressivo chiamato sequence number. Se il server iCAAS riceve il pacchetto invia un
ACK altrimenti invia un NACK. Se il client riceve un NACK provvede ad rinviare
esclusivamente il pacchetto corrispondente al NACK ricevuto dal server. Tutti i dettagli
145
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
relativi al protocollo si possono trovare in [48]. Fatta quest’introduzione doverosa, si
tornerà all’analisi della figura 5.12.
Il proxy contatta il server iCAAS, e quando questo risponde, il proxy istanzia le risorse
necessarie per inviare/ricevere i pacchetti secondo le modalità del protocollo utilizzato.
Infatti per ogni pacchetto dati inviato dalla stargate, il server iCAAS risponde con un ACK
che sta ad indicare che il pacchetto è stato ricevuto, altrimenti risponderà con un NACK.
Per gestire il flusso dati da e verso il server iCAAS, il proxy si affida all’interfaccia
ISRManager. L’interfaccia ISRManager ha molteplici compiti, uno di questi è sicuramente
il compito d’impacchettare i dati formattati, all’interno di pacchetti UDP secondo le
modalità descritte nel protocollo. Inoltre si appoggia ad una struttura dati (costituita da una
coda circolare) che ha il compito di tener traccia dei pacchetti inviati e ricevuti. Infatti si
crea di volta in volta, relativamente ad ogni invio, una finestra che contiene i pacchetti
inviati di cui però ancora non si è ricevuto un ACK o un NACK da parte del server. Se il
server invia un ACK si rimuove il pacchetto relativo all’interno della finestra, se invece il
server invia un NACK (o scade il timeout relativo al pacchetto) si provvede al rinvio del
pacchetto in questione. L’ ampiezza della finestra è fissa vale a dire che si possono inviare
al più n pacchetti senza bisogno di ricevere alcun ACK, n rappresenta appunto l’ampiezza
della finestra.
ISRManager si affida ai due thread per inviare e ricevere pacchetti
rispettivamente verso e dal
server. In particolare il sender ha il compito d’inviare
pacchetti UDP presenti nella struttura dati verso il server ed il receiver ha il compito di
ricevere le risposte del server ed eventualmente rinviare i pacchetti non ricevuti dal server.
Per concludere le classi window GSDP_Packet e GSData rappresentano rispettivamente la
struttura dati coda circolare, l’astrazione del pacchetto UDP relativo al protocollo iCAAS
e l’astrazione della tipologia di dati contenuti nei pacchetti UDP.
5.3.3 Altre soluzioni proposte
Nel corso dello studio effettuato, si sono studiate soluzioni architetturali, dal punto di vista
client, alternative a quella proposta. Tornando a considerare la figura 5.1 dove
l’interazione con la rete di sensori avviene tramite un server WSN collegato fisicamente al
146
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
gateway, posso utilizzare una soluzione basata su TinyDB.
TinyDB è un sistema di
elaborazione distribuita per estrarre informazioni da una rete di sensori. Si deve tener
presente che questo sistema è basato su TinyOS ed in esso contenuto. Il grande vantaggio
di questa sistema è che non c’è la necessità di scrivere applicazioni NesC ad hoc in quanto
tutto il codice necessario da installare in ogni sensore della rete è già fornito da TinyOS.
Quindi questa soluzione rappresenta il modo più semplice ed intuitivo per estrapolare
informazioni dai sensori della rete. In pratica TinyDB consente di ottenere informazioni
dai nodi della rete tramite delle query espresse mediante una variante di SQL (TinySQL).
Le query possono essere inoltrate dal server WSN ai nodi della rete e possono essere
memorizzate localmente ed elaborate periodicamente. In figura 5.13 un esempio di
funzionamento del sistema TinyDB
Figura 5.13 – Esempio di funzionamento sistema TinyDB
Il server WSN invia la query, ed i sensori forniscono le informazioni richieste
(nell’esempio sono solo due: nodeid e light).
L’aspetto più interessante di TinyDB è che gli algoritmi relativi all’elaborazione dei dati,
147
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
al meccanismo di rilevamento ed al routing sono completamente mascherati all’utente
finale. Infatti questo devo solo preoccuparsi di scrivere la query conforme all’informazioni
che si vogliono ottenere dalla rete di sensori. Talvolta, se le circostanze lo richiedono, non
è detto che bisogna scrivere la query in linguaggio TinySQL infatti si può utilizzare la GUI
di TinyDB che è rappresentata nella figura 5.14. Si mostra un esempio di come viene
inviata una query. In riferimento sempre alla figura 5.14 sulla sinistra troviamo gli attributi
disponibili che possiamo selezionare ed importare negli attributi di progetto (quelli
d’interesse nel particolare contesto). Man mano che s’importano gli attributi, la query si
compone automaticamente e la sintassi compare nell’area in basso. Dopodichè viene
inviata tramite il pulsante “Send Query”. In alto a destra troviamo una console che
permette d’inviare comandi ai nodi della rete, per default i comandi sono inviati in
broadcast (cioè a tutti i sensori) altrimenti si può specificare l’ID del sensore a cui è
destinato il comando. In basso a destra compare l’identificativo di quelle query che sono
in elaborazione.
Figura 5.14 – GUI di TinyDB
Come illustrato in figura, è possibile anche inserire dei predicati tramite la clausola
WHERE. Un’altra funzionalità molto importante è quella che prevede la memorizzazione
148
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
automatica delle informazioni rilevate dalla rete di sensori, all’interno di un database
basato sul DBMS Postgress. Inoltre TinyDB fornisce delle semplici API java per facilitare
lo sviluppo di applicazioni basate su questo sistema. Per completezza si riporta un
esempio, sviluppato per fini sperimentali, di applicazione java stand-alone che consente
d’inviare una query predefinita alla rete di sensori sfruttando le API che TinyDB mette a
disposizione.
package net.tinyos.tinydb.sgary;
import net.tinyos.tinydb.parser.*;
import java.util.Vector;
import java.io.*;
public class sgaryDemoApp implements ResultListener{
public sgaryDemoApp() {
try {
//initialize
TinyDBMain.initMain();
q = SensorQueryer.translateQuery
("select nodeid,light,temp epoch duration 2048", (byte)1);
System.out.println();
System.out.print("Sending query....");
TinyDBMain.injectQuery(q, this);
System.out.println("ok");
System.out.println("waiting for results ...");
} catch (IOException e) {
System.out.println("Network error.");
} catch (ParseException e) {
System.out.println("Invalid Query.");
}
}
...
...
public void addResult(QueryResult qr) {
Vector v = qr.resultVector();
for (int i = 0; i < v.size(); i++) {
System.out.print("\t" + v.elementAt(i) + "\t|");
}
System.out.println();
}
public static void main(String argv[]) {
new sgaryDemoApp();
}
TinyDBQuery q;
}
Nell’applicazione sopra riportata, si può notare in grassetto la definizione della query che
sarà poi inviata tramite il comando TinyDBMain.injectQuery(…) . Dopodichè, si
149
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
attiverà un listner in modo da captare le risposte di ogni singolo sensore e stamparle a
video.
Il grosso limite di TinyDB è l’elevata complessità computazionale a cui sensori sono
sottoposti nel momento in cui s’inoltra una query alla WSN. Infatti ogni volta che viene
inoltrata una query alla rete, parte una fase di sincronizzazione tra i sensori che è quella
più dispendiosa sia dal punto di vista temporale sia dal punto di vista energetico. Inoltre
c’è bisogno comunque di un server WSN per poter gestire le query tramite la GUI, oppure
si potrebbe pensare ad un invio della query che avviene da un terminale remoto verso la
stargate dove sarà installato un sistema che permetta la costruzione dinamica della query
che sarà poi quella effettivamente inviata ai sensori. Questa soluzione comunque può
comportare notevoli problemi, infatti pur essendo un “super nodo” la stargate è comunque
una piattaforma con memoria e capacita di calcolo limitate. Si conclude ricordando
l’ambito di utilizzo ed i requisiti che questo comporta, infatti TinyDB non offre un
servizio di localizzazione. Affinché sia possibile utilizzare quest’applicazione unita ad un
sistema di localizzazione occorre effettuare l’integrazione dei componenti delle due
applicazioni (TinyDB e LocC) a livello NesC, cosa tutt’altro che semplice se si gurada la
figura 5.15 dov’è mostrato il wiring di primo livello dei componenti dell’applicazione
TinyDB.
Figura 5.15 – Wiring componenti dell’applicazione TinyDB
150
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Capitolo 6: Analisi dei risultati, sperimentazione e testing
Questo capitolo presenta i risultati della sperimentazione e testing effettuati per il sistema
realizzato. Nei capitoli precedenti sono state presentate le varie applicazioni implementate,
a questo proposito si precisa che sono state effettuate diverse tipologie di sperimentazioni.
Innanzitutto si è partiti dalle misurazioni hardaware su cui si basa l’intero sistema di
localizzazione, ossia la misurazione relativa al valore di RSSI ricevuto all’aumentare della
distanza. Si è passati poi, utilizzando i dati precedentemente rilevati sull’hardware, alla
sperimentazione simulata tramite strumenti software quali TOSSIM e TinyViz (di cui si
parlerà in seguito). Inoltre si sono fatte sperimentazioni simulate e poi reali relative
all’applicazione Surge_Reliable ed infine si sono effettuati test relativi all’intera fruizione
delle informazioni rilevate dalla WSN ed inviate all’architettura iCAAS tramite il
protocollo ad hoc creato. Nei prossimi paragrafi si partirà da un descrizione dell’hardware
e software utilizzato per le sperimentazioni, dopodichè si analizzeranno i risultati simulati
tramite dei grafici comparativi tra l’algoritmo di localizzazione proposto (ROCRSSI++) e
quello originale (ROCRSSI). Inoltre si illustrerà l’analisi energetica e dei costi effettuata.
Infine s’illustrerà il testing effettuato sul forwarding dei dati e quindi quello relativo al
protocollo realizzato e si presenterà un strumento di test appositamente realizzato per
facilitare l’operazione di testing sull’intera architettura lato client.
6.1 Hardware e software utilizzato
In questo paragrafo si presenteranno le piattaforme hardware e gli strumenti software
utilizzati per la sperimentazione. Si partirà dalla presentazione della piattaforma hardware
utilizzata, ovvero i sensori MICA2 con chip radio CC1000 per poi passare alla definizione
151
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
di quei particolari strumenti software utilizzati per la simulazione (TOSSIM e TinyViz).
6.1.1 La piattaforma hardware MICA2
Innanzitutto definiamo di cosa si compone la piattaforma hardware apertenente alla
famiglia MICA2 della casa costruttrice Crossbow (XBow). Generalmente si commette un
errore nella definizione di sensore, infatti spesso con questo termine s’identifica l’intera
piattaforma che invece è costituita da una sensor board, da una mote board (che spesso
prende il nome della tipologia dell’hardaware in uso in questo caso ci riferiamo ad essa col
nome di MICA2). Il MICA2, rappresentato in figura 6.1, è responsabile delle seguenti
cose:
Elaborazione
Memorizzazione
Alimentazione
Invio dati al gateway
Figura 6.1 – Piattaforma hardware Mica2
Si noti che il MICA2 usufruisce di un chip radio CC1000 (di cui si è parlato
precedentemente) che è quello che consente la comunicazione con gli altri nodi della rete e
con il gateway stesso. La sensor board , rappresentata in figura 6.2, è invece responsabile
del cosiddetto sensing ovvero è quel componente che effettua le rilevazioni.
152
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.2 – Sensor board per MICA2
In figura 6.2, è cerchiato in rosso lo spazio dedicato alla connessione con il MICA2
tramite 51 pin. Le motivazioni che hanno portato a scegliere i MICA2 sono elencate di
seguito:
Rapporto qualità/prezzo
Molti gruppi di ricerca utilizzano i MICA2, quindi vi è molta documentazione
relativa a quest’ambito
Non è richiesto l’utilizzo di un protocollo predefinito (ad eccezione dei Micaz)
Entriamo adesso nei dettagli dei componenti del MICA2. Si elencheranno adesso le
caratteristiche tecniche del sottosistema di elaborazione (MCU). L’MCU (Mica Control
Unit) relativa ai MICA2 è di tipo Atmel AVR Atmega 103L (MCU) le cui caratteristiche
tecniche sono di seguito elencate
Throughput pari a circa 6 MIPS a 4MHz
128KB di memoria flash programmabile
4K Bytes di SRAM interna
4K Bytes di memoria EEPROM programmabile
53 bus I/O programmabili
3 timer hardware
Si capisce che si tratta di elementi hardware con capacità di memoria ed elaborative
piuttosto basse, ecco perché ci si è sforzati di concepire delle applicazioni che siano adatte
153
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
a questo tipo di sensori. Per quanto concerne la sensor board ne esistono di varie tipologie,
quella utilizzata consente di rilevare:
Luminosità
Temperatura
Accelerazione
Possiede un rilevatore sonoro e un magnetometro
Inoltre ha un microfono ed uno speaker
Nel nostro ambito ci limiteremo ad usare la sensor board per la rilevazione della
luminosità e della temperatura, infatti la rilevazione dell’ RSSI rientra nei compiti del
MICA2. Si vedrà a questo proposito, la sperimentazione che si potrebbe definire “base” in
quanto è quella da cui si è partiti ed i cui risultati sono stati utilizzati poi nell’analisi
comparativa degli algoritmi di posizionamento. Si sta parlando della relazione che
intercorre tra distanza e RSSI rilevato. Per effettuare delle misurazioni, sono stati utilizzati
due sensori MICA2, di cui uno inserito nell’apposito slot del gateway e l’altro alimentato
con batterie che chiameremo “sensore mobile”, un connettore/adattatore per collegare il
gateway (di tipo MIB510, in figura 6.3a) con uscita serial al PC con ingresso USB (figura
6.3b), batterie ed alimentatore rispettivamente per il sensore e per il gateway ed un metro.
a)
b)
Figura 6.3 – Gateway MIB510 ed adattatore seriale-USB utilizzati
Si è passati poi all’installazione nei sensori, di un’apposita applicazione implementata per
effettuare le rilevazioni RSSI e stamparle sulla console di TinyOS. L’operazione
154
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
d’istallazione dell’applicazione nei sensori, il cui componente principale è TestRssi , è
avvenuta tramite il comando:
make mica2 reinstall.0 mib510,/dev/ttyS5
in generale si utilizza:
make <piattaforma> reinstall.<id_sensore> <gateway>,/dev/tty<porta_COM>
dove per <piattaforma> s’intende il tipo di sensore (MICA, MICA2, MICA2DOT etc.),
<id_sensore> rappresenta l’identificativo di quel particolare sensore all’interno della rete,
<gateway> il tipo di gateway (MIB510, MIB520, MIB600 etc.) e <porta_COM> è la
porta COM a cui è connessa la gateway (si noti che l’espressione della porta COM è di
tipo linux-like cioè se ci si riferisce alla porta COM1 allora si scriverà /dev/ttyS0, a
COM2 corrisponde /dev/ttyS1 e cosi via). Chiusa questa parentesi, si passa alle
misurazioni. La prima misurazione effettuata consiste nel posizionare i due sensori a
distanza di 50cm l’uno dall’altro. Dopodichè si è acceso il sensore mobile che invia
messaggi conformi alla tipologia dei messaggi utilizzati nell’applicazione di
localizzazione. Il sensore installato sul gateway riceve tali messaggi, ne calcola il valore di
RSSI e lo invia al PC dove, tramite l’utilizzo di un’applicazione per il parsing dei
pacchetti ricevuti, è possibile leggere il valore. Si è iterato questo ragionamento fino a
raggiungere la massima distanza possibile tra i due sensori all’interno del laboratorio in
cui si sono effettuate tali prove, ovvero una distanza di 550cm. Quindi si precisa che tali
misurazioni sono state effettuate in ambiente indoor, ambiente sicuramente più
sfavorevole dal punto di vista di possibili fenomeni di fading del canale di comunicazione.
In figura 6.4 è rappresentato il grafico risultante da questa sperimentazione. Qui appare
evidente che le rilevazioni del valore di RSSI ricevuto partono da una distanza di 50cm
fino ad una distanza di 550cm. Bisogna chiarire un aspetto, l’applicazione costruita ed
installata nei due sensori, ottiene le rilevazioni del valore di RSSI relative ad un messaggio
ricevuto tramite l’interfaccia ADC (che è quella che fornisce l’accesso ai componenti
hardware che effettuano le rilevazioni) in ascolto sul canale 0 e da qui si ottiene un
155
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
numero intero che va da 0 a 255. Per ottenere il valore di RSSI in dBm (Decibel per
milliWatt) dalla rilevazione fatta dal sensore, occorre far riferimento alla seguente
formula:
51,3
BattValue RssiValue
1024
45,5
dove BattValue è il valore della batteria (che nelle prove effettuate è stato fissato ad un
valore tipico) mentre RssiValue è il valore rilevato dall’interfaccia ADC del componente
che consente le rilevazioni hardware.
Figura 6.4 – Grafico relazione distanza-RSSI
Una volta fatta questa conversione si sono ottenuti i risultati visibili sul grafico di figura
6.4. La linea blu rappresenta l’unione dei valori medi di RSSI (valutai su venti rilevazioni)
relativi alle distanze tra i nodi (50cm 100cm 150cm e così via), si può notare il tipico
andamento decrescente, infatti all’aumentare della distanza diminuisce il valore di RSSI.
Le linee rosse verticali invece, rappresentano gli scostamenti del valore rilevato dal valore
156
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
medio, anche qui si è giunti ad una conclusione prevedibile, in quanto analizzata in altri
contesti sperimentali, e cioè che all’aumentare della distanza tra i sensori aumenta anche la
varianza delle rilevazioni intorno al valore medio.
Infine, pur non essendo un argomento chiave in questo contesto, si è fatta un’analisi
relativa al numero di pacchetti corrotti ricevuti dal sensore sulla gateway sulla base di
trenta invii da parte del sensore mobile. Si noti il grafico di figura 6.5
Figura 6.5 – Grafico del numero di pacchetti persi in relazione alla distanza tra i nodi
anche da qui si evince che all’aumentare della distanza aumentano il numero di pacchetti
corrotti ricevuti, ovviamente si dovrebbe fare un discorso molto più ampio su questo
argomento visto che il numero di pacchetti corrotti dipende anche dal numero di byte di
cui un particolare pacchetto è composto. Qui ci si limita ad effettuare l’analisi da un punto
di vista qualitativo, infatti più aumenta la distanza tra i nodi più c’è la probabilità di
ricevere un pacchetto corrotto, quindi nel caso specifico dell’applicazione di
localizzazione, si è fatta la scelta di non basare la misura del RSSI su un singolo
messaggio, ma piuttosto su un numero di messaggi tali da garantire il corretto
157
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
funzionamento dell’algoritmo, per poi considerarne il valore medio.
6.1.2 TOSSIM e TinyViz
Si discuterà ora del software che TinyOS mette a disposizione per simulare il
comportamento di una rete di sensori, questo stesso software è stato utilizzato per le
sperimentazioni. Si partirà dalla descrizione dell’ambiente di simulazione TOSSIM per
poi arrivare al discorso relativo a TinyViz che rappresenta un tool, sviluppato in java e
basato proprio sul simulatore TOSSIM, per cui sono stati sviluppati una serie di plugin
molto utili nel contesto in questione.
TOSSIM è un simulatore di eventi discreti per TinyOS. In precedenza si è visto come
come compilare un’applicazione per le piattaforme hardware, in TinyOS è possibile
compilare un’applicazione anche per la piattaforma PC che consente proprio di effettuare
una simulazione in TOSSIM dell’applicazione in questione. Questa simulazione permette
agli utenti di effettuare il debug o di monitorare l’esecuzione tramite altri tool.
Ovviamente bisogna tener pesente che comunque si tratta sempre di una simulazione, e
che quindi si parte da una serie di assunzioni e semplificazioni fatte dal simulatore nel
momento in cui viene eseguita l’applicazione. Di seguito vengono elencati alcuni
paramentri caratteristici del simulatore TOSSIM:
Fedeltà: normalmente, TOSSIM cattura tutti i comportamenti di TinyOS ad un
livello molto basso. Infatti in queste simulazioni la rete di sensori viene
analizzata ad un livello basso (livello bit). Inoltre TOSSIM considera tutte le
rilevazioni effettuate tramite interfaccia ADC (ovviamente generando numeri
casuali e non rilevazioni reali) ed inoltre genera e gestisce tutti i tipi d’interrupt
all’interno del sistema. Considerati tutti questi aspetti, si può affermare che
TOSSIM rappresenti abbastanza fedelmente, il comportamento della piattaforma
hardware.
Modello: il simulatore TOSSIM non rappresenta un modello del mondo reale.
Infatti si può affermare che le simulazioni effettuate in TOSSIM rappresentano
un’astrazione di alcuni fenomeni del mondo reale. E’ possibile creare un modello
158
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
personalizzato di simulazione tramite alcuni tool di cui si discuterà in seguito.
Imperfezioni:
anche
se,
come
descritto
prima,
TOSSIM
analizza
il
comportamento di TinyOS ad un livello molto basso, parte comunque da una
seria di assunzioni e semplificazioni fatte dal punto di vista hardware. Per
esempio, l’interrupt hardware in TOSSIM non è di tipo prelazionato. Invece nei
sensori reali, un interrupt può verificarsi quando si esegue altro codice, la
prelazione, esistente nei sensori, consente di eseguire immediatamente il codice
relativo all’interrupt che potrebbe portare il sensore in uno stato inconsistente o
irrimediabilmente errato. Ecco perché una delle regole fondamentali di buona
programmazione in NesC, è sviluppare funzioni atte alla gestione degli interrupt
molto semplici e brevi.
Fatta questa panoramica preventiva, si passa all’aspetto pratico di come compilare e
simulare applicazioni tramite TOSSIM. La compilazione dell’applicazione corrente per la
piattaforma TOSSIM viene effettuata tramite il comando seguente:
make pc
questo comando produce l’eseguibile che s’insidierà nel percorso corrente sotto la
directory /build/pc/main.exe. Quindi per far partire la simulazione basterà scrivere il
seguente comando:
./build/pc/main.exe <opzioni> <num_nodes>
dove <num_nodes> specifica il numero di nodi di cui è composta la rete da simulare,
mentre alcune opzioni possono essere:
-h, -help: fornisce l’insieme di opzioni
-gui:
stoppa la simulazione, ed aspetta una GUI che si connetta ad essa
-t=<sec>: specifica il numero di secondi virtuali della simulazione
-b=<sec>: indica il tempo di attesa prima dello startup dei nodi
159
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Queste rappresentano solo alcune opzioni che consentono all’utente di effettuare un
monitoraggio e delle sperimentazioni più ampie. In particolare, in questo contesto è stata
utilizzata quasi sempre l’opzione –gui per non far partire la simulazione prima del
collegamento di altri tool o applicazioni ad essa, monitorando ed analizzando così
dall’inizio l’intera simulazione. Un’ altra particolarità del TOSSIM è il fatto che mette a
disposizione diverse configurazioni di debug a run-time. Infatti è possibile effettuare il
debug all’interno di un’applicazione scritta in NesC, utilizzando il la seguente sintassi:
dbg(DBG_<configurazione>,”VIDEO OUTPUT… =%d\n”,<var> )
la parola chiave per utilizzare il debug è quidi dbg. Analizziamo il comando precedente:
<var> permette di visualizzare a video al posto del carattere %d,
il valore di una
variabile utilizzata all’interno del programma, si precisa che possono essere visualizzate
tante variabili quanti ne sono i caratteri %d, la sostituzione avviene in maniera ordinata
(cioè al primo carattere %d corrisponde la prima variabile elencata e così via). Per quanto
riguarda la <configurazione> si è detto che TOSSIM ne mette a disposizione molte a
seconda del focus che si vuole dare all’operazione di debug, per esempio voglio effettuare
un debug relativo alla comunicazione seriale in questo caso si utilizzerà la configurazione
uart, oppure si è interessati al debug relativo alle operazioni radio in questo caso si
utilizzerà la configurazione radio, per i dettagli relativi alle varie configurazioni si
rimanda a [1]. Per ora ci si limita a dire che esistono tre configurazioni utente che possono
essere
utilizzate tramite le configurazioni usr1, usr2, usr3. Si precisa che in una
simulazione TOSSIM è possibile effettuare un debug relativo ad una singola
configurazione per volta, in base al valore della variabile d’ambiente TinyOS DBG . Infatti
prima di partire con la simulazione, il TOSSIM legge il valore di questa variabile e
visualizza, nel corso della simulazione, i messaggi relativi a quella configurazione di
debug.
Fatta questa doverosa introduzione all’ambiente di simulazione TOSSIM, si passa alla
descrizione di un tool, sviluppato in Java, che permette di potenziare le capacità di
simulazione di TOSSIM tramite l’utilizzo di svariati plugin, il nome di questo tool è
160
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
TinyViz. Questo è incluso nella distribuzione di TinyOS 1.x è fornisce una visualizzazione
Java relativa ad una simulazione TOSSIM. E’ possibile collegare TinyViz ad una
simulazione TOSSIM, lanciando prima una simulazione con l’opzione –gui dopodichè far
partire TinyViz, in questo modo si può gestire la simulazione tramite la GUI di
quest’ultimo che fornisce appunto strumenti molto utili per il debug. In figura 6.6
Figura 6.6 – GUI di TinyViz
è rappresentata una simulazione tramite TinyViz di un’applicazione TOSSIM. Nella parte
sinistra è rappresentata la griglia corrispondente all’area della WSN ed al suo interno i
sensori che costituiscono la rete considerata. Oltre alla barra di menù sulla sinistra, in alto
a destra si può una barra contenente i comandi di controllo della simulazione. Il primo è il
pulsante che accende/spegne un nodo della rete, immediatamente dopo vi è una barra per
l’aumento/diminuzione della frequenza degli eventi nella simulazione, dopodichè c’è il
pulsante che avvia/arresta la simulazione. Inoltre ci sono altri due pulsanti, uno relativo
alla comparsa/scomparsa della griglia l’altro relativo alla pulitura della console di debug.
Poi, come si può notare, ci sono una serie di pannelli (uno per ogni plugin), che offrono
diverse opportunità. In quest’ambito si descriveranno soltanto i plugin utilizzati. Si parte
161
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
da un plugin standard come come del debug messages che consente di monitorare i
messaggi di debug, relativi alla configurazione scelta in TOSSIM, direttamente da una text
area contenuta nel pannello relativo in TinyViz. Un altro plugin utilizzato nel corso delle
sperimentazioni, è il plugin radio links che consiste nella visualizzazione, nella parte
sinistra della GUI di TinyViz, dei collegamenti radio che si vengono a creare tra sensori
durante lo scambio di messaggi. Infine un plugin di particolare importanza è quello che
consente di costruire un modello generale ADC, cioè permette di definire un qualsiasi
valore, relativo ad un particolare canale ADC, rispetto ad ogni nodo della rete in un
qualsiasi momento della simulazione.
In seguito, nel corso della spiegazione delle varie sperimentazioni, si farà riferimento a
questi strumenti software utilizzati per simulare l’applicazione di localizzazione
(ROCRSSI++) creata e fare un confronto con l’applicazione di localizzazione di partenza
(ROCRSSI).
6.2 Sperimentazioni relative al algoritmo ROCRSSI++
Nei capitoli 3 e 4
si è presentato, rispettivamente dal punto di vista logico ed
implementativo, l’algoritmo di localizzazione ROCRSSI++. In questo paragrafo si
discuterà delle varie sperimentazioni effettuate relative a questo sistema di localizzazione.
Come già detto nell’introduzione, si è partiti dalle misurazioni del valore di RSSI al
variare della distanza fatte su sensori MICA2, i risultati sono esposti nel grafico di figura
6.4. Partendo da queste misurazioni hardware effettuate, si sono svolte una serie di
simulazioni dell’applicazione in questione. Si vedrà il primo semplice esempio di
simulazione effettuata, si esporrà la metodologia di sperimentazione (che è comune a tutte
le altre prove) e si analizzeranno i risultati. Gli obiettivi delle misure effettuate sono
relativi all’accuratezza della stima della posizione, alla topologia di WSN, al consumo
energetico dell’applicazione di localizzazione ed ai costi dell’intera rete di sensori e si
mostrerà la bontà della soluzione adottata tramite il confronto con l’algoritmo originale
ROCRSSI.
162
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
6.2.1 Esempio di simulazione
Siccome lo strumento di simulazione utilizzato (TOSSIM) non prevede la simulazione del
valore RSSI in base alla distanza, si sono effettuate preventivamente le rilevazioni
sperimentali mostrate nel grafico di figura 6.4, dopodichè si sono utilizzati questi valori,
all’interno delle simulazioni. Consideriamo ora un esempio pratico. La rete considerata è
formata da un nodo incognito (che sarà il nodo 3) che deve localizzarsi utilizzando tre nodi
beacon (0,1 e 2). Innanzitutto si sono posizionati i nodi all’interno di un sistema di
coordinate che rappresenta l’area, espressa in centimetri, su cui si estende la WSN e si è
tenuta traccia delle coordinate (x;y) dei quattro nodi della rete. Dopodichè si è passati al
calcolo delle distanze tra i vari nodi tramite la formula della distanza euclidea in un piano
bidimensionale:
X1
dove X 1 ;Y1 e
X2
2
Y1 Y2
2
X 2 ;Y2 rappresentano le coordinate dei nodi per i quali si vuole valutare
la distanza tra loro. Una volta calcolate ed annotate le distanze tra i nodi, si è passati
all’assegnazione del valore di RSSI relativo ad ogni distanza calcolata, partendo dalle
misurazioni hardware effettuate e rappresentate nel grafico di figura 6.4. Tale valore è
stato poi assegnato al canale 0 dell’interfaccia ADC tramite il plugin di TinyViz ADC
readings. Si chiarisce questa procedura con un esempio. Si supponga che il nodo 0 invii
un messaggio beacon in broadcast che il nodo 1 riceverà, e si consideri la distanza tra il
nodo 0 ed il nodo 1 pari a 200cm. In base alle misurazioni effettuate, il valore medio di
RSSI (in dBm) relativo a tale distanza è -59,97, quindi la lettura da parte del nodo 1, sul
canale 0 dell’interfaccia ADC dev’essere pari a 72 (che è il valore medio misurato sui
MICA2 corrispondente al valore di RSSI in dBm pari a -59,97). Questo valore è stato
assegnato tramite il plugin su citato. In figura 6.7 è mostrato l’output di TinyViz relativo a
questa simulazione. La metodologia utilizzata nelle sperimentazioni seguenti, sono del
tutto analoghe a quest’appena descritta, con delle piccole eccezioni che si vedranno in
seguito. Una volta chiarita la modalità di sperimentazione, si può passare alla valutazione
dell’algoritmo di localizzazione implementato tramite alcune simulazioni effettuate.
163
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.7 – Esempio di simulazione tramite TinyViz
A questo proposito, si è fatta un’analisi relativa all’accuratezza della posizione stimata dal
nodo incognito in funzione del numero di nodi beacon e della loro posizione, che si vedrà
nel prossimo sotto paragrafo.
Prima di addentrarci nella descrizione della prossima prova sperimentale, si vuole
precisare che l’algoritmo ROCRSSI++ è stato pensato in modo che un nodo incognito
riesca a localizzarsi tramite tre beacon. Quindi anche se ci sono più di tre beacon nella rete
si scelgono i beacon più adatti per fungere da anchor node rispetto al nodo incognito, in
base alla loro posizione. Così facendo si fissa il numero di scansioni della griglia che ogni
nodo incognito farà, cioè per localizzarsi un nodo incognito deve fare soltanto tre
scansioni (pari al numero di anchor node) della griglia con il relativo incremento dei
contatori corrispondenti alle celle (il procedimento è spiegato nel capitolo 4). Si sceglie di
tener conto solo di tre beacon per garantire comunque una certa accuratezza nella stima
della posizione del nodo incognito, ma allo stesso tempo non appesantire troppo il
processo di localizzazione, tenendo sempre conto dei parametri caratteristici delle WSN
quali risparmio energetico e capacità di calcolo limitate.
164
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
6.2.2 Prove sperimentali n°1: accuratezza posizione stimata relativa al numero di
beacon e tipologia della griglia di posizionamento
L’obiettivo di questa prova è dimostrare che utilizzando l’algoritmo proposto
ROCRSSI++, fissato il numero di nodi incogniti all’interno di una WSN, un
posizionamento casuale dei beacon rispetto ad un posizionamento a griglia migliora
l’accuratezza media della stima della posizione del nodo incognito. Inoltre, si vuole
dimostrare che aumentando il numero di beacon diminuisce l’errore commesso sulla
stima.
A tal proposito, si misurerà l’errore, espresso in centimetri, sulla stima del
posizionamento e come questo varia all’aumentare del numero di beacon.
Per quanto concerne la prima prova sperimentale, visto che si tratta di una simulazione, si
è scelto di prendere in considerazione comunque tutti i beacon presenti nella WSN, al
contrario del funzionamento tipico del ROCRSSI++ descritto in precedenza. Questo ha
comportato comunque un’elaborazione più impegnativa ma in questo caso, non ci si
doveva preoccupare degli aspetti energetici visto che si trattava di una simulazione
nell’ambiente TOSSIM. I risultati della prova sono riportati nel grafico di figura 6.8
Figura 6.8 – Grafico della variazione dell’errore all’aumentare del numero di beacon
presenti nella WSN
165
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
In questa prova effettuata, si precisa che visto il numero di nodi sempre crescente, si è
deciso di non inserire manualmente il valore di RSSI relativo ad ogni scambio di
messaggio, tramite il plugin di TinyViz ADC readings visto prima. In questo caso si è
scritta una porzione di codice apposita, relativa alla specifica prova, che consente di
automatizzare per ogni nodo la rilevazione del valore di RSSI a seconda dello specifico
nodo che ha inviato il messaggio e che è stato ricevuto dal nodo in questione. Inoltre si è
introdotto un generatore di numeri casuale nell’applicazione con lo scopo appunto di
simulare le variazioni che possono sussistere nella rilevazione del valore di RSSI (si
consideri il grafico di figura 6.4). Dall’analisi del grafico di figura 6.8 risulta chiaro che
l’algoritmo ROCRSSI++ funziona meglio, dal punto di vista dell’accuratezza della
posizione stimata, se vi è una certa casualità nel posizionamento dei nodi piuttosto che
posizionarli secondo una griglia. Da un certo punto in poi si può notare che i
miglioramenti sono sempre minori, in particolare se si usano 6 beacon oppure 10 beacon il
miglioramento sulla stima della posizione del nodo incognito è nell’ordine di qualche
centimetro. Inoltre bisogna tener presente il discorso fatto prima, ovvero che comunque
qui si riprendono in considerazione tutti i beacon, perciò si fanno tante scansioni quanti
sono i beacon, appare ovvio che visto e considerato che la scansione dell’intera griglia è
l’operazione più dispendiosa in termini temporali (nel caso reale anche in termini
energetici), non vale la pena utilizzare più di sei beacon. Anche perché bisogna
considerare che comunque c’è un limite inferiore rispetto alla precisione della posizione
stimata (argomento discusso nel capitolo 4) e comunque c’è da considerare anche la
grandezza fisica del sensore che fa si che si possa commettere l’errore di qualche
centimetro. Ovviamente bisogna fare un altro tipo di discorso e cioè che la situazione
appena vista rappresenterebbe un assurdo dal punto di vista reale in quanto non ha nessun
senso utilizzare ben sei nodi beacon per un solo nodo incognito, lo scopo di questa prova è
dimostrare che talvolta è più utile posizionare i nodi in maniera casuale piuttosto che
secondo uno schema a griglia.
Si passa ora alla descrizione della prova sperimentale e all’analisi dei risultati scaturiti da
questa.
166
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Si sono prese in considerazione due topologie di posizionamento dei sensori all’interno
della WSN, ovvero posizionamento random e posizionamento in griglia. In figura 6.9 sono
mostrate le diverse tipologie:
a) tipologia a griglia
b) tipologia random
Figura 6.9 – Diverse tipologie utilizzate
Si è partiti nel considerare una rete di sensori composta da un solo nodo incognito, che
deve quindi localizzarsi, e tre nodi beacon, e si sono posizionati una volta in maniera
casuale e una volta a modo di griglia. Dopodichè, tramite la metodologia illustrata
nell’esempio precedente, si sono considerate le varie distanze, si è calcolato il valore di
RSSI corrispondente, lo si è fatto leggere dal nodo corrispondente. Poi si è iterato questo
ragionamento ed infine si è annotata la stima della posizione del nodo incognito. Nelle
figure seguenti sono rappresentate le due topologie di rete viste da TinyViz
Figura 6.10 – WSN con tre beacon (0,1 e 2) ed un nodo incognito (3), disposti in maniera
casuale
167
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.11 – WSN con tre beacon (0,1 e 2) ed un nodo incognito (3), disposti in griglia
Nelle figure 6.10 e 6.11 sono rappresentate rispettivamente le due tipologie di
posizionamento: casuale e random. In entrambe i nodi 0,1 e 2 rappresentano i nodi beacon
riconoscibili anche perché si è costruita l’applicazione in modo che se un nodo è un
beacon di 1° o di 2° livello, ha il led giallo accesso (come si può notare anche nelle
figure), mentre il nodo 3 è il nodo incognito. I cerchi blu intorno ai nodi beacon, stanno ad
indicare che questi inviano messaggi in broadcast, mentre il led verde ha lo stesso
comportamento in tutti i sensori, ovvero si accende e si spegne ad ogni attività radio
(ricezione ed invio di un messaggio). Una volta annotate le stime della posizione calcolata
dal nodo incognito per entrambe le topologie di rete, si è passati alla prossima prova, cioè
si è lasciato uguale il numero di nodi incogniti (cioè uno) e si è aggiunto un nodo beacon
per entrambe le topologie, in modo da avere le seguenti situazioni:
Figura 6.12 – WSN con quattro beacon ed un nodo incognito, disposti in griglia
168
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.13 – WSN con quattro beacon ed un nodo incognito, disposti in maniera casuale
Si è iterato questo ragionamento fino a considerare una rete composta da dieci nodi beacon
ed un solo nodo incognito, e si è valutato come l’errore sulla stima della posizione del
nodo incognito cambiava in funzione del numero dei beacon presenti nella rete e del loro
posizionamento.
6.2.3 Prove sperimentali n°2: confronto accuratezza ROCRSSI – ROCRSSI++
In questa seconda prova si dimostra che il ROCRSSI++ rispetto al ROCRSSI, migliora
l’accuratezza della posizione stimata per tutte le topologie di WSN considerate. Si
analizzano adesso, le prove sperimentali effettuate relative al confronto tra l’algoritmo
originale da cui si è partiti cioè il ROCRSSI, e l’algoritmo proposto ovvero il
ROCRSSI++. La procedura di sperimentazione è la stessa utilizza fin ora e spiegata nei
dettagli nei sottoparagrafi precedenti. Per effettuare un confronto abbastanza generico, ma
che comunque sia rappresentativo sotto diversi punti di vista, si è scelto di confrontare i
due algoritmi, prendendo in considerazione diverse topologie di rete con dimensioni
diverse. La prima prova effettuata è relativa alla sperimentazione dell’algoritmo ROCRSSI
su una rete avente cinque nodi, di cui tre beacon e due nodi incogniti. Come già spiegato,
per quanto concerne la sperimentazione, si rispetta la procedura già citata e cioè si
assegnano delle coordinate ai nodi beacon, si tiene traccia di queste, poi si posizionano i
169
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
nodi incogniti e si annotano le loro coordinate attese. Dopodichè si calcolano tutte le
distanze tra i nodi (si ricorda che le distanze sono rappresentate in cm) e si assegnano i
valori di RSSI per ciascuna di essa. Si precisa che anche in questo caso è stata scritta una
porzione di codice specifica per la prova, sia per evitare di assegnare il valore
manualmente tramite il plugin ADC readings di TinyViz, sia per simulare la varianza
intorno al valore medio di RSSI relativo a ciascuna distanza.
Infine si attende che l’algoritmo di localizzazione fornisca le coordinate stimate dal nodo
incognito (tramite un messaggio di debug visibile in TOSSIM o tramite il plugin Debug
messages di TinyViz) che si confrontano poi con quelle attese e se ne valuta l’errore. In
figura 6.14 è rappresentata la vista in TinyViz della topologia relativa alla rete di sensori
presa in esame. I nodi 0,1 e 2 sono i beacon mentre i nodi 3 e 4 sono i nodi incogniti, cioè
coloro che devono localizzarsi tramite l’esecuzione dell’algoritmo ROCRSSI. Come si
può facilmente intuire già dalla figura, la posizione dei nodi beacon rispetto al nodo
incognito 4 non è ottimale per il posizionamento di quest’ultimo visto che si trova
abbastanza lontano dall’anchor node 1. Per il nodo incognito 3 la situazione è leggermente
diversa, in quanto è più vicino rispetto ai beacon, di quanto non lo sia il nodo 4, quindi ci
si aspetta sicuramente un stima più precisa del nodo 3 rispetto al nodo 4.
Figura 6.14 – Vista TinyViz relativa alla simulazione del ROCRSSI in un WSN di 5 nodi
(3 beacon e 2 nodi incogniti)
170
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Si passa adesso alla seconda prova effettuata , quella cioè relativa alla sperimentazione
della stessa WSN utilizzando però come algoritmo di posizionamento, il ROCRSSI++. La
rete WSN è praticamente identica alla precedente dal punto di vista del posizionamento
dei nodi, per far si che il confronto tra gli algoritmi sia veritiero. In questo caso però
facciamo un’analisi leggermente diversa, i numero di nodi nella WSN è sempre cinque di
cui due nodi incogniti e tre beacon di 1° livello. Questa appena descritta però è la
situazione iniziale, infatti, dopo che il nodo 3 si sarà localizzato, diventerà beacon di 2°
livello e quindi fungerà da anchor node per il nodo incognito 4 che non si è ancora
localizzato. Quest’evoluzione è rappresentata in figura 6.15, nella figura a) ritroviamo la
situazione iniziale dove i tre beacon (0,1 e 2) contrassegnati dal led giallo, fungono da
anchor node per i nodi incogniti 3 e 4. Ad un certo punto il nodo 3 effettua la propria
localizzazione e diventa beacon di 2° livello (comportamento visibile in figura 6.14 b) in
cui anche il nodo 3 accende il led giallo, che sta a significare che è diventato beacon) a
questo punto, il nodo 4 lo utilizza come anchor in quanto più vicino rispetto al beacon 1.
a)
171
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
b)
Figura 6.15 – Vista TinyViz relativa alla simulazione del ROCRSSI++, WSN di 5 nodi
a) Situazione precedente alla localizzazione del nodo 3 (3 beacon di 1° livello, 2 nodi)
b) Situazione dopo la localizzazione del nodo 3 (3 beacon di 1° livello, 1 beacon di 2°
livello, 1 nodo)
In questo modo si è fatto il confronto dei due algoritmi relativi ad una WSN composta da
cinque nodi, con un posizionamento che si può definire casuale. Relativamente alla
particolare WSN presa in esame, la differenza di accuratezza tra i due algoritmi si evince
dall’errore della stima del nodo 4. Infatti la localizzazione del nodo 3 avviene tramite i
beacon 0,1 e 2, e sarà la stessa in entrambi gli algoritmi, mentre la localizzazione del nodo
4 nel caso del ROCRSSI, avverrà tramite i beacon 0,1 e 2, invece nel caso del
ROCRSSI++ avverrà tramite i beacon 0 e 2 (che sono beacon di 1° livello) ed il beacon 3
(che è un beacon di 2° livello). I risultati scaturiti da queste due prove effettuate, sono
riassunti nel grafico di figura 6.16.
Questo grafico mette in evidenza le differenze dei due algoritmi, utilizzati nella medesima
rete di sensori, dal punto di vista dell’errore commesso sulla stima della posizione da parte
dei nodi incogniti. Si può notare che l’errore medio, nel caso del ROCRSSI++, è molto più
basso rispetto al caso in cui si è utilizzato il ROCRSSI.
172
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.16 – Grafico del confronto degli algoritmi utilizzati sulla stessa WSN
E’ giusto precisare ancora una volta che, il miglioramento apportato dal ROCRSSI++ in
questo caso è unicamente relativo alla stima della posizione del nodo 4 in quanto è l’unico
ad usufruire del nodo 3 che diventa beacon di 2° livello, caratteristica questa peculiare del
ROCRRSSI++. Per meglio considerare le differenze tra i due algoritmi, e fornire inoltre
risultati sperimentali rappresentativi di più tipologie di WSN, si sono prese in
considerazione altre due tipologie in cui questa volta, all’interno della rete, i sensori sono
disposti a modo di griglia:
WSN formata da 9 nodi: di cui 4 beacon e 5 nodi incogniti
WSN formata da 15 nodi: di cui 6 beacon e 9 nodi incogniti
Per quanto riguarda la prima tipologia e cioè un WSN formata da 9 nodi, si utilizzano 4
beacon per localizzare 5 nodi incogniti. Si considerano sempre le due prove in maniera
separata, e cioè si effettua prima la localizzazione tramite ROCRSSI, si tiene nota dei
risultati dopodichè si effettua la medesima prova sulla stessa rete utilizzando il
ROCRSSI++ ed anche qui si tiene traccia dei risultati. Come avveniva anche nella prova
173
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
precedente, inizialmente la situazione è identica in entrambe le prove, infatti sia nella
sperimentazione del ROCRSSI che del ROCRSSI++ si ha la situazione illustrata nella
figura 6.17
Figura 6.17 – Vista TinyViz relativa alla simulazione del ROCRSSI in una WSN di 9 nodi
(4 beacon e 5 nodi incogniti)
Come si può notare dalla figura, i beacon sono rappresentati dai nodi 0,1,2 e 3 mentre tutti
gli altri sono i nodi incogniti. I beacon presenti in quest’ esperimento relativo all’algoritmo
ROCRSSI, rappresentano i beacon di 1° livello nell’esperimento relativo all’algoritmo
ROCRSSI++. Infatti come detto in precedenza, la situazione iniziale è esattamente la
stessa nei due esperimenti. Nel caso del ROCRSSI++ però, quando il nodo incognito 4
riesce a localizzarsi, diventa beacon di 2° livello, e funge da anchor node per gli altri nodi
incogniti presenti nella rete, si dunque la situazione illustrata nella figura 6.18:
Come mostrato in figura 6.18, dopo che il nodo 4 è riuscito a localizzarsi, i beacon della
WSN in questione risulteranno essere i nodi 0,1,2,3 e 4, si ricorda che quest’ultimo è un
beacon di 2° livello. Per completare la panoramica su questa serie di esperimenti effettuati,
si illustra anche l’ultima tipologia di WSN presa in considerazione, ovvero una WSN
composta da 15 nodi, di cui 6 beacon e 9 nodi incogniti.
174
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.18 – Vista TinyViz relativa alla simulazione del ROCRSSI++ in una WSN di 9
nodi (4 beacon di 1° livello, 1 beacon di 2° livello e 4 nodi incogniti )
In figura 6.19 è rappresentata la vista in TinyViz dell’esperimento relativo al ROCRSSI
utilizzato in una WSN di 15 nodi, che ricordiamo ancora una volta, è la medesima
situazione che inizialmente sussiste anche nell’esperimento relativo al ROCRSSI++
Figura 6.19 - Vista TinyViz relativa alla simulazione del ROCRSSI in una WSN di 15
nodi (6 beacon di 1° livello e 11 nodi incogniti )
175
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Esaminando la figura, si può notare che i 6 beacon sono rappresentati dai nodi 0,1,2,3,4 e
5. A differenza del ROCRSSI però, nell’algoritmo proposto a seguito dell’avvenuta
localizzazione dei nodi 6 e 7 si avrà la situazione illustrata in figura 6.20
Figura 6.20 – Vista TinyViz relativa alla simulazione del ROCRSSI++ in una WSN di 15
nodi (6 beacon di 1° livello, 2 beacon di 2° livello e 7 nodi incogniti )
I risultati relativi alle tre prove effettuate possono essere riassunti nel grafico di figura
6.21. Nel grafico di figura 6.21 si evince che, dal punto di vista dell’accuratezza media
sulla posizione stimata dai nodi incogniti, in tutte e tre le situazioni sperimentali in esame,
il ROCRSSI++ risulta essere migliore del ROCRSSI. In particolare il miglioramento più
significativo, si è avuto relativamente alla prima prova effettuata cioè quella riguardante
una WSN composta da cinque nodi disposti in maniera casuale. Risultato prevedibile
tenendo conto della sperimentazione precedente dove si evince che l’algoritmo di
localizzazione proposto si comporta meglio se la disposizione dei nodi è casuale rispetto
ad un posizionamento a griglia, questo è ancora più evidente se la rete è composta da
pochi nodi (grafico di figura 6.8).
176
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.21 – Confronto riassuntivo sull’accuratezza tra ROCRSSI e ROCRSSI++
Inoltre bisogna considerare un ulteriore aspetto che sarà un utile strumento poi per il
dimensionamento della rete quando si parlerà dell’analisi dei costi, ovvero la percentuale
dei nodi beacon all’interno della rete. Come si può notare nel grafico di figura 6.22.
All’aumentare del numero totale di nodi all’interno della rete, si sono utilizzati meno
beacon pur ottenendo un accuratezza maggiore come illustrato nel grafico di figura 6.22.
Si precisa che per quanto riguarda il ROCRSSI++, per beacon s’intendono beacon di 1°
livello, ovvero quei beacon che conoscono a priori la loro posizione all’interno di un
sistema di coordinate. In definitiva, guardando anche la linea di tendenza presente i grafici
di figura 6.21 e 6.22, si evince che all’aumentare del numero di nodi che costituiscono la
WSN nonostante la percentuale del beacon presenti nella rete diminuisca, l’accuratezza
della stima della posizione dei nodi incogniti migliora. Si conclude il discorso relativo alle
prove effettuate, mostrando il grafico di figura 6.22 dove è mostrato il miglioramento
percentuale dell’accuratezza media relativa alla stima della posizione da parte dei nodi
incogniti appartenenti a diverse WSN, apportato dall’algoritmo proposto.
177
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura 6.22 – Grafico della percentuale dei beacon all’interno di una WSN
Figura 6.23 – Grafico miglioramento percentuale dell’accuratezza apportato dal
ROCRSSI++ per tipologia di WSN
178
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Si conclude così il discorso relativo alle prove sperimentali effettuate, dicendo che
l’accuratezza relativa alla posizione stimata potrebbe essere ulteriormente migliorata se si
considerassero tutti i beacon presenti nella rete nel raggio di copertura del nodo incognito
in questione. Infatti effettuando tante scansioni dell’area quanti sono i beacon nel raggio di
copertura del nodo incognito, talvolta è possibile restringere l’area l’intersezione ed
effettuare quindi una localizzazione più precisa. Ovviamente questo a scapito di un’
elaborazione più impegnativa, ed un consumo energetico quindi maggiore.
6.2.4 Analisi energetica
Al fine di valutare l’algoritmo ROCRSSI++ da più punti di vista possibili per effettuare
poi comparazioni con il ROCRSSI, si passerà ora ad un aspetto molto importante nelle reti
di sensori senza filo, ossia il consumo energetico. Quest’ultimo rappresenta infatti uno dei
fattori più importanti proprio perché un ottimizzazione significativa in tal senso
“allungherebbe” la vita dei sensori in una generica WSN. Proprio per questo sono stati
molti gli studi rivolti in tale direzione ed è proprio grazie al tanto materiale a disposizione,
che si è fatta un analisi energetica relativa all’algoritmo proposto: ROCRSSI++ in
confronto all’algoritmo originale ROCRSSI, basandosi sul consumo di ogni singola
attività di ogni singolo componente in relazione al funzionamento dell’applicazione nel
tempo. L’hardware preso come riferimento è il sensore MICA2 con chip radio CC1000.
Scendendo nel dettaglio vediamo che questo è composto da vari componenti che possono
essere accessi o spenti indipendentemente e sono:
CPU
Radio
Sensor devices
LEDs
ADC
EEPROM
per ognuno dei quali esistono riferimenti sull’energia dissipata nell’ordine dei mW.
E’ bene sottolineare che non sono state effettuate ne misurazioni hardware (direttamente
179
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
sui sensori) ne misure simulate in ambiente TOSSIM tramite applicazioni apposite, ma
piuttosto si è scelto di fare riferimento ad innumerevoli, precisi e ben documentati
esperimenti, in particolare in seguito faremo riferimento ai risultati sperimentali ottenuti
da Davis – Miller[3] e Victor Shnayder[2] riportati in tabella.6.1. Gli esperimenti fanno
riferimento a test su applicazioni diverse ma entrambi si prefiggono l’obbiettivo di fornire
un power model relativo ai MICA2 mettendo in evidenza i componenti hardware (e lo loro
rispettive attività) e il loro dispendio energetico. Dal momento che i risultati sperimentali
differiscono tra loro in maniera sensibile, si è scelto di fare un media tra le due
sperimentazioni.Innanzitutto osserviamo che i valori considerati in queste tabelle sono
espressi in mA e mW volendo fare una misurazione in mJ, prendiamo in considerazione
un’unità temporale (in questo caso 1 minuto) nella quale consideriamo l’esecuzione.
Infatti
Joule Watt * sec
e quindi possiamo effettuare la conversione in Joule utilizzando la precedente formula.
Avendo scelto 1 minuto dobbiamo essere sicuri che tale minuto sia rappresentativo delle
caratteristiche della nostra applicazione. Si ricorda che entrambi gli algoritmi in esame, si
compongono dove la prima è più breve della seconda, perciò si è scelto di riservare 20
secondi per la prima fase e 40 secondi per la seconda fase.
Davis - Miller 's result
Shnayder's result
Component
Current (mA)
Power (mW)
Current (mA)
Power (mW)
Empty Program
7,5
.02325
8
.024
Leds
2
.006
2,2
.0066
Radio Idle
16
.0496
15
.045
Radio On/Off
4
.0124
3,2
.0096
Radio Trasmit
21
.0651
16,5
.0495
Radio Receive
16
.0496
15
.045
GPS
110,106
.3413
Not Tested
Not Tested
EEPROM Read
11,971
.0371
14,2
.0426
EEPROM Write
32,871
.1019
26,4
.0792
Tabella 6.1. – Risultati sperimentazioni sui consumi energetici
180
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Passiamo quindi all’analisi energetica vera e propria. Partiamo dal ROCRSSI, sappiamo
che ci sono 2 entità distinte nella nostra wsn, i beacon ed i nodi. I beacon sono i nodi
“intelligenti” che potranno essere equipaggiati di GPS (la maggior fonte di consumo
energetico) per rilevare automaticamente la loro posizione, ed i nodi generici che
dovranno localizzarsi nella rete attraverso l’ascolto dei messaggi inviati dai beacon e
l’esecuzione dell’algoritmo di localizzazione. Consideriamo separatamente le 2 fasi; dove
nella prima i soli nodi beacon dialogano tra loro scambiandosi messaggi sulla loro
posizione, mentre nella seconda i beacon trasmettono e tutti gli altri nodi ricevono le
tabelle dai beacon, eseguono l’algoritmo e trasmettono la loro posizione.
In base a queste considerazioni analizziamo in dettaglio il consumo del beacon durante la
prima fase: un beacon deve inviare un fissato numero di messaggi contenente la sua
posizione nei 20 secondi rappresentativi della prima fase, considerando pari a 5 il numero
di messaggi il consumo relativo a quest’attività
è di 1,43 mJ (iterando questo
ragionamento si costruiscono i grafici riportati in seguito).
Per quanto riguarda l’attività di ricezione dei beacon il discorso cambia in quanto il
dispendio energetico risulta essere dipendente dal numero di beacon presenti nella rete
ognuno dei quali poi invia un certo numero di messaggi, per la misurazione si considerano
4 beacon quindi una ricezione da parte di ciascun beacon di un totale di 15 messaggi; nel
restante tempo della prima fase, la radio è inattiva. Analizziamo ora l’utilizzo della CPU in
questa prima fase: i beacon si limitano a memorizzare le informazioni ottenute dai vicini
per il resto la loro CPU è in idle; ecco perché non scorretto considerare il lavoro svolto dai
beacon nella prima fase quasi completamente IO-bound.
Passiamo all’analisi della seconda fase di un nodo beacon: si ricorda che questa fase dura,
relativamente alla scelta del periodo d’osservazione, 40 secondi, innanzitutto qui vi è
un’elaborazione volta a calcolare la media dei valori delle rilevazioni del RSSI dopodichè
l’analisi energetica in questa fase risulta relativamente semplice in quanto i beacon si
limitano solo ad inviare i messaggi, contenenti le tabelle costruite nella prima fase, allo
scandire di un timer e cioè ogni 2 secondi inoltre la cpu è sempre in idle visto che di fatto
181
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
non vengono effettuate operazioni. Quindi nella prima parte di questa fase si svolge lavoro
completamente CPU bound, mentre nella seconda parte invece il lavoro è tutto IO bound.
Consideriamo ora il contributo di energia dissipata da parte dei nodi che devono
localizzarsi, quindi devono ascoltare i messaggi dei beacon, effettuare alcune
comparazioni ed ordinamenti ed infine eseguire l’algoritmo di localizzazione. Durante la
prima fase i nodi non eseguono nessun compito quindi l’energia dissipata è relativa a
quella intrinseca dei componenti del sensore, nella seconda fase i nodi prima ricevono
messaggi dai beacon (lavoro IO bound) dopodichè eseguono l’algoritmo di localizzazione
(lavoro CPU bound). In figura 6.24 è rappresentato il grafico relativo ai consumi
energetici dell’applicazione che implementa il ROCRSSI per un minuto di esecuzione. Si
deve tener presente che per quanto riguarda i nodi incogniti, si è considerato il chip radio
spento durante tutta la prima fase e si è considerato quindi, soltanto il consumo intrinseco
dei vari componenti e quello relativo all’accensione e spegnimento del chip radio.
Le misure rappresentate dal grafico si riferiscono a singole unità hardware (cioè 1 beacon
ed 1 nodo). Osservando il grafico possiamo notare che la dissipazione di energia nei nodi è
maggiore rispetto ai nodi beacon, almeno per quanto riguarda la 2° fase.
Figura 6.24 – Grafico relativo al dispendio energetico ROCRSSI per minuto di esecuzione
182
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Si deve tener presente però che nell’analisi svolta non si è tenuto conto che i beacon
possono essere equipaggiati di GPS che introduce una dissipazione energetica di un ordine
di grandezza superiore alla comunicazione radio come si evince dalla tabella 6.1. La scelta
di non tenere conto di questo contributo non è casuale in quanto lo scopo dell’analisi è
capire in termini di dissipazione energetica, quanto è onerosa per i nodi normali la
localizzazione tramite ROCRSSI, inoltre c’è un’altra questione di particolare importanza e
cioè che mentre i beacon possiamo pensare di equipaggiarli con alimentazione
indipendente, e quindi preoccuparci relativamente meno del consumo energetico di questi,
per i nodi normali la questione è diversa visto che questi saranno equipaggiati con batterie
ed avranno quindi una durata limitata.
A questo punto sono obbligatorie alcune considerazioni: e cioè che le attività di
trasmissione e ricezione (lavoro IO bound) sono più onerose dal punto di vista energetico
rispetto a quelle svolte dalla CPU però meno variabili rispetto al costo intrinseco del
componente Radio (cioè quando il ricetrasmettitore è in idle), mentre troviamo
esattamente la situazione inversa nelle attività CPU bound.
Figura 6.25 – Grafico dispendio energetico ROCRSSI++ per minuto di esecuzione
183
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Passiamo ora all’analisi energetica del ROCRSSI++, nell’algoritmo proposto possiamo
distinguere 3 entità diverse: i beacon di 1° livello, i beacon di 2° livello e i nodi. I beacon
di 1° livello ed i nodi normali si comportano come i beacon ed i nodi visti nel ROCRSSI, i
beacon di 2° livello invece rappresentano una peculiarità del ROCRSSI++, questi infatti,
hanno un comportamento simile a quello dei nodi quando devono localizzarsi dopodichè si
comportano in maniera similare ai beacon.
Quindi volendo fare un’analisi energetica in dettaglio possiamo limitarci a studiare il
comportamento dei soli nodi beacon di 2° livello, come sempre analizziamo separatamente
le due fasi: durante la prima fase questi sono in completa inattività (si comportano come i
nodi normali), nella seconda fase ricevono i messaggi dai beacon, calcolano la loro
posizione dopodichè si proclamano beacon di 2° livello ed iniziano, anche loro, ad inviare
messaggi. Questo appena descritto è un comportamento transitorio, a regime infatti,
durante la 1° fase, i beacon di 2° livello si comportano come i beacon di 1° livello, cioè
inviano messaggi ai beacon effettuano operazioni di media per poi inviare le tabelle ai
nodi.
Figura 6.26 – Grafico di confronto dispendio energetico ROCRSSI - ROCRSSI++
184
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
In figura 6.25 è riportato il grafico relativo al dispendio energetico per singolo
componente dell’algoritmo ROCRSSI++. Com’era prevedibile il grafico mette in risalto il
fatto che gli elementi che dissipano più energia nel ROCRSSI++ sono i beacon di 2°
livello e rendono il ROCRSSI++ leggermente più sconveniente del ROCRSSI dal punto di
vista del consumo energetico. Nel grafico di figura 6.26 è illustrato un confronto fra i due
algoritmi dal punto di vista del dispendio energetico prendendo in considerazione una
WSN di 8 nodi: 3 beacon e 5 nodi nel caso del ROCRSSI e 3 beacon di 1° livello, 2
beacon di 2° livello e 3 nodi per il ROCRSSI++.
Dall’analisi del grafico risulta evidente che l’algoritmo proposto è leggermente più
sconveniente dal punto di vista del consumo energetico, però bisogna tener presente che a
fronte di questo consumo leggermente maggiore, nel caso particolare della WSN
considerata, i due beacon di 2° livello apporteranno miglioramenti sull’accuratezza della
localizzazione dei nodi incogniti.
6.2.5 Analisi dei costi
Come ampiamente spiegato nel capitolo 5, il sistema di localizzazione implementato, si
colloca in un contesto più ampio, cioè quello di creare una WSN che sia in grado di fare
monitoraggio ambientale, ed in particolare monitoraggio di terreni a rischio di frane. In
questo sottoparagrafo, si farà un’analisi relativa ai costi che comporta il sistema nel suo
ambito di utilizzo. Si farà inoltre anche un discorso relativo alle scelte da implementare
visto che si tratta di un ambito particolare che presenta il rischio di perdere una parte della
rete di sensori a causa di frane. Si chiarisce che l’analisi dei costi si riferisce al costo in
denaro della messa in esercizio del sistema. Per quanto concerne la parte di sistema trattata
in questa tesi, si possono individuare due tipi di costo:
Costi relativi all’installazione della WSN e delle eventuali infrastrutture ad essa
inerenti
Costi relativi ai componenti hardware da utilizzare
Per quanto riguarda i costi relativi all’installazione della WSN bisogna considerare molte
185
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
variabili. Infatti questo costo è quello riguardante l’installazione fisica della rete di sensori
e delle infrastrutture che essa necessita dipendono sostanzialmente dall’ambiente
circostante. Ad esempio, se l’ambiente in cui si cala la WSN in questione è
particolarmente ostico a causa, ad esempio, di eccessivi dislivelli o per l’assenza di strade
percorribili a piedi, per raggiungere l’area d’interesse ed effettuare qui l’installazione della
rete di sensori potrebbe essere necessario l’utilizzo di mezzi particolari. Inoltre vi è la
possibilità di affidarsi ad un’impresa del settore, che provvederà all’installazione della
rete. Oltre a questi eventuali costi, bisogna considerare anche i costi derivanti da tutti
quegli accorgimenti che devono essere presi, anche questi dipendenti dall’area
d’installazione. Può capitare, infatti, che in ambiente aperto i sensori costituenti la rete
vengono installati a qualche decina di centimetri dal terreno tramite l’ausilio di piccoli
pali, oppure considerando il caso in questione, si potrebbe pensare di ancorare al terreno in
maniera molto solida, quei nodi che rappresentano i beacon e che quindi sono le ancore
sfruttate da tutti gli altri nodi della rete di sensori per localizzarsi. Sempre riferendoci al
caso preso in esame, come detto nel capitolo 5, si è pensato all’utilizzo di una stargate che,
essendo un sorta di super nodo che consente l’interfacciamento da e verso la rete di
sensori, deve essere preservata maggiormente magari tramite l’utilizzo di particolari
involucri. Un altro aspetto da considerare in questa categoria di costi, è quello dell’
eventuale cablaggio verso un server WSN o di un eventuale allacciamento alla rete di
distribuzione elettrica. Nel capitolo 5, infatti è stata considerata anche la possibilità di
utilizzare un server WSN, connesso fisicamente alla rete di sensori (in particolare al
gateway) tramite porta seriale. Questo ovviamente comporta il cablaggio dal gateway della
WSN fino alla locazione del server, e si è detto che questo talvolta può essere molto
costoso. Infine, come accennato nel sottoparagrafo relativo all’analisi energetica, si può
pensare di dotare i nodi beacon di modulo GPS, per fare questo però risulta quasi
indispensabile dotarli anche di un’alimentazione energetica indipendente, visto l’alto
dispendio energetico dovuto al GPS stesso. Ecco quindi che può esserci l’esigenza di
allacciare i beacon alla rete di distribuzione elettrica andando incontro talvolta, a costi
elevati.
186
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Come si evince dalle considerazioni precedenti, i costi all’installazione della WSN e delle
relative infrastrutture ad essa inerenti dipendono da molti fattori e qundi non ha molto
senso effettuare un’analisi relativa a questi se non si considera un caso reale. Ecco perché
si effettuerà un’analisi dei costi quantitativa relativa ai soli componenti hardware da
utilizzare, tendo sempre presente, per le diverse soluzioni possibili, gli eventuali costi
aggiuntivi di cui si è discusso in precedenza.
Si parte dalla tabella 6.2 relativa ai costi delle piattaforme hardware appartenenti alla
famiglia Crossbow, il prezzo è quello indicato sul sito di riferimento della casa costruttrice
ed è indicato in dollari. Per le prove sperimentali fatte sull’hardware sopra riportate, si
ricorda che si sono utilizzati i sensori MICA2, 900MHz, ma si può estendere quel risultato
alle diverse piattaforme con qualche piccola differenza. Infatti numerosi sono stati gli studi
mirati al legame tra il valore di RSSI rilevato e la distanza tra due nodi. Per maggiori
approfondimenti si rimanda a [4].
Moduli Wireless
Prezzo
MICA2 – CC1000, 900MHz
$155
MICA2 – CC1000, 433MHz
$169
MICAz – CC2400, 2,4GHz
$134
IRIS – 2,4GHz
$155
Cricket
$263
Tabella 6.2 – Tabella dei costi relativi ai moduli Wireless
Si considera, inoltre, il prezzo relativo alle varie sensorboard che possono essere
equipagiate. In tabella 6.3 sono rappresentate alcune delle sensorboard prodotte dalla
Crossbow, le relative funzioni ed il prezzo. Prima di elencare le possibili soluzioni ed
evidenziarne il prezzo, si conclude questa panoramica relativa all’hardware, si elencano in
tabella 6.4 alcune stargate prodotte dalla Crossbow, le relative funzionalità messe a
disposizione ed il prezzo relativo. Si precisa che tutte le stargate hanno lo slot per
l’inserimento di una sensorboard.
187
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Sensor board
Rilevazioni possibili
Prezzo
MICA2/z Sensor Board
Accellerazione bi-dimensionale, luminosità,
$250
temperatura, acustica
Basic Weather
Temperatura, umidità, luce ambientale,
$284
pressione barometrica
GPS Weather
Temperatura, umidità, luce ambientale,
$404
pressione barometrica e dotazione di un
modulo GPS
Tabella 6.3 – Tabella dei costi relativi alla diverse sensor board
Stargate
Funzionalità
Prezzo
XScale platform Intel
Funzionalità tipiche del gateway in una
$300
rete di sensori, ambiente linux integrato,
comunicazione
tramite
lo
standard
802.15.4
NetBridge 100
Web Server integrato ed altri tool per la
$600
gestione delle informazioni provenienti
dalla WSN
Tabella 6.4 – Tabella dei costi relativi alle stargate
Si cercherà adesso di considerare un caso reale relativo all’ambito di utilizzo in questione,
ed effettuare un’analisi dei costi quantizzata dal punto di vista del materiale hardware
utilizzato, elencando le possibili soluzioni e facendo le opportune osservazioni
relativamente a quei costi aggiuntivi derivanti dall’installazione della WSN ed alle
infrastrutture necessarie ad esse.
Lo scopo del progetto, ricordiamo che è il monitoraggio ambientale ed in particolare dei
rischi ambientali derivanti dai fenomeni franosi. Per cercare si soddisfare questi requisiti,
si ricorda che si è implementato un’applicazione ad-hoc che offre un sistema di
188
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
localizzazione ed inoltre un supporto per la rilevazione di misure relative all’ambiente
circostante.
Per effettuare un confronto sui costi tra le diverse possibilità d’implementazione di una
WSN, occorre fissare alcune variabili per limitare le possibili combinazioni di scelte. Per
questo nel seguito si supporrà di utilizzare per ogni nodo beacon della rete, le sensorboard
che consentono la rilevazione delle grandezza fisiche atmosferiche, quindi le Basic
Weather e GPS Weather a seconda dei casi; inoltre si sceglie di attrezzare la WSN di una
stargate di tipo XScale con processore intel che garantisce un potenza di calcolo adeguata
all’applicazione a dei costi contenuti. In quest’ambito infatti, considerata l’architettura
iCAAS che si trova a valle della rete di sensori, è inutile utilizzare un stargate di tipo
NetBridge 100 visto che lo strato software per la gestione dei dati provenienti dalla WSN
è stato creato ad-hoc.
Supponiamo di voler monitorare un’area di 100m 2 e di voler considerare tutte le misure
ambientali rilevabili tramite sensorboard. Considerando le prove effettuate su un’area di
10m2 ed i relativi risultati, e prendendo in considerazione inoltre la possibilità di
sovradimensionare la rete per garantire comunque un livello di qualità del servizio
adeguato anche all’occorrenza di guasti nei nodi, si sceglie di costruire una WSN di 45
nodi. Considerando le prove effettuate, si può notare che all’aumentare dei numero dei
nodi costituenti una WSN, la percentuale dei beacon diminuisce. Tenendo presente
l’andamento mostrato nel grafico di figura 6.22, in un rete composta da 45 nodi ne
possiamo considerare beacon il 20% (ovvero 9 nodi su 45) per avere garantire comunque
una buona accuratezza. A questo punto è doveroso fare un scelta d’implementazione che
dipende anche dalla conformazione del territorio in cui caliamo la WSN. Infatti possiamo
non dotare i beacon di modulo GPS e prefissare le coordinate per ciascun beacon, in
questo modo però dobbiamo preoccuparci di effettuare un posizionamento ad – hoc sul
territorio che rispecchi effettivamente la posizione prefissata nei beacon rispetto al sistema
di coordinate e questo non sempre è possibile. Questo tipo di soluzione è inoltre poco
adattativa, in quanto qualora si dovessero spostare i beacon, questi dovrebbero essere
riprogrammati con le posizioni correnti. L’alternativa è dotare ciascun beacon di modulo
189
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
GPS, per garantire miglior adattatività in quanto la posizione dei beacon non è
prefissatama viene calcolata tramite appunto il modulo GPS. Questa soluzione però è più
costosa non solo dal punto di vista del costo dei singoli beacon, ma anche dal punto di
vista energetico, ecco perché talvolta si sceglie di allacciare i beacon alla rete di
distribuzione elettrica (ovviamente questa soluzione comporta dei costi aggiuntivi per il
cablaggio). In figura 6.27 è rappresentato il grafico relativo all’analisi appena effettuata, i
costi sono relativi a tutti i componenti hardware necessari per la realizzazione della WSN
(moduli Wireless, sensorboard e stargate). Lungo l’asse delle ascisse sono riportate le due
soluzioni (con e senza il modulo GPS) e per tutte le soluzioni vi è l’analisi dei costi
relativa sia ad i MICA2 che ai MICAz. Come si può notare per entrambe le piattaforme
hardware, dal punto di vista dei costi di realizzazione è più sconveniente utilizzare il
modulo GPS per tutti i nodi della rete rispetto ad utilizzare l’algoritmo di posizionamento
ROCRSSI++, senza considerare poi il maggior dispendio energetico che può essere
arginato collegando ciascun nodo
Figura 6.27 – Grafico relativo all’analisi dei costi effettuata
alla elettrica, ovviamente ciò incrementa quei costi relativi all’installazione della WSN ed
190
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
alle relative infrastrutture. Si conclude facendo notare che è più conveniente utilizzare i
MICAz invece che i MICA2 come piattaforma Hardware
6.3 Test del sensor networks access
In questo paragrafo si tratterà la fase di testing dell’intera architettura realizzata, in
particolare ci si focalizzerà sul processo di inoltro dei dati dalla rete di sensori
all’architettura iCAAS, questo processo è illustrato nel dettaglio nel capitolo 5. Si è detto
che nella fase d’inoltro delle informazioni rilevate dalla rete di sensori verso il mondo
reale, vengono effettuati vari passi a vari livelli. Si capisce quindi, che effettuare dei test
esaustivi sui vari livelli e tener traccia dell’occorrenza degli errori (e del relativo livello di
occorrenza) è di fondamentale importanza per sapere dove effettuare il debug. Le prove
del sensor networks access sono state effettuate utilizzando l’applicazione Surge_Reliable
anch’essa presentata nel capitolo 5. Il sensor network access ha come scopo quello
d’inoltrare le informazioni provenienti dalla rete di sensori, al server remoto
dell’architettura iCAAS tramite un protocollo UDP creato ad-hoc che gestisce l’eventuale
perdita dei pacchetti con tecnica selective repeat. Guardando la figura 5.3 si capisce
quanto detto prima, cioè che un errore può verificarsi a vari livelli. Ad esempio può esserci
un errore in fase di parsing del pacchetto ricevuto dalla rete di sensori, può esserci un
errore sul modulo presente sulla stargate relativo alla formattazione dei dati, è possibile
che ci siano errori nei moduli software che gestiscono l’invio e la ricezione dei pacchetti
errori quindi relativi al protocollo, potrebbero esserci errori legati al server e alla
comunicazione con esso etc. etc. Inizialmente per le prime prove effettuate, si sono
utilizzati gli strumenti che TOSSIM mette a disposizione ovvero lo statemet dbg visto nel
primo paragrafo, ed inoltre sono stati utilizzati tool come Serial Forwarder e
l’applicazione ad–hoc creata per realizzare il sensor networks access lato client. Si capisce
però che utilizzando più console TOSSIM con il relativo strumento per il debug,
unitamente al Serial Forwarder ed all’applicazione creata, risulta molto difficile effettuare
un test atto a scovare errori di programmazione ed i relativi livelli di occorrenza. Ecco
perché si è deciso d’implementare una GUI in Java che riassumesse in un’unica
191
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
schermata, i debug relativi ai diversi livelli del sensor networks access. Prima di
continuare il discorso relativo alla GUI costruita, si precisa che nei vari test effettuati
successivamente, la WSN è sempre stata emulata tramite TOSSIM ed invece della stargate
è stato utilizzato un gateway MIB510 connesso serialmente al PC dove c’è l’applicazione
client del sensor networks accesa. Ovviamente dal punto di vista logico non cambia niente
visto che in seguito, l’applicazione client sensor networks access sarà installata
direttamente sulla stargate. Quindi lo scopo fondamentale di questa GUI
creata è
effettuare un debug congiunto relativo ai vari livelli dell’applicativo, inoltre si è integrato
il Serial Forwarder che gestisce il flusso d’informazioni proveniente dalla rete di sensori.
Nella figura 6.28 è riportata la schermata realizzata tramite le librerie grafiche javax.swing
messa a disposizione dalla release 1.41_2 di java.
Figura 6.28 – GUI del tester java realizzato
192
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Si procede con l’analisi di questa schermata. Partendo dall’alto a sinistra compaiono le
informazioni relative al server ovvero il suo indirizzo IP ed il porto, più in basso invece si
trovano le informazioni relative alla stargate ed alla relativa rete di sensori. Qui troviamo
l’identificativo della rete, indispensabile per il server dell’architettura iCAAS nel caso di
gestione di diverse reti, i porti locali di ricezione ed invio pacchetti, il numero massimo di
rilevazioni contenute in un singolo pacchetto ed il periodo di campionamento delle
rilevazioni. Ancora più in basso ci sono i due pulsanti che lanciano ed arrestano
l’applicazione. In basso a sinistra, è praticamente riportata la GUI del Serial Forwarder
con il numero di porto (locale) del server ed la porta di comunicazione con la WSN
(trattandosi di un WSN simulata in TOSSIM in questo caso la porta è tossim-serial). In
alto a destra c’è la console di debug Server Comunications relativa alla comunicazione con
il server, in particolare in questa console vengono riportati tutti gli eventi di
comunicazione con il server principale che è diverso dal server che riceve ed invia
pacchetti contenenti le informazioni. Infatti il server principale è in attesa di un pacchetto
chiamato “HELLO PACKET” da parte di una stargate di una WSN, ricevuto questo
pacchetto invia una risposta contenente il numero di porto del server atto a gestire il
traffico d’informazioni. In basso troviamo la console di debug UDP Messages in questa
console vengono riportati tutti i messaggi di debug relativi ai thread Sender e Receiver che
hanno rispettivamente il compito di inviare e ricevere pacchetti UDP secondo il
protocollo. Inoltre in questa console vengono riportati messaggi relativi alla gestione della
struttura dati atta a contenere i pacchetti che, eventualmente, devono essere rinviati.
Ancora più in basso c’è la console generale di debug che contiene i messaggi di debug
generici oltra a quelli relativi alla formattazione dei dati provenienti dalla WSN secondo la
struttura iCAAS. Infine troviamo la console di debug relativa ai cosiddetti TOS Events che
rappresentano gli eventi relativi alla comunicazione inter-nodo di una WSN, all’inoltro dei
pacchetti dalla rete di sensori verso la stargate ed al loro parsing. In definitiva come
descritto, grazie a quest’interfaccia grafica è possibile prendere in considerazione tutti gli
aspetti del sensor networks access per effettuare così un’operazione di debug più semplice.
193
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Conclusioni
In questa tesi si sono considerati vari aspetti relativi alle reti di sensori. Innanzitutto, si è
parlato del problema relativo alla localizzazione, problematica questa soggetta a numerosi
studi e sperimentazioni. Si sono accennati poi, i diversi ambiti di utilizzo e le diverse
applicazioni che prevedono l’utilizzo di una WSN dotata di sistema di localizzazione. Si è
passati poi alla progettazione ed implementazione dell’algoritmo di localizzazione
ROCRSSI++ e si è considerato l’ambito di utilizzo relativo al progetto regionale
REMOAM . In seguito si sono discusse le varie strategie ed architetture per gestire i dati
provenienti dalla rete di sensori, considerando tutti gli aspetti tipici per ogni architettura.
Dopodichè si è considerata la specifica soluzione adottata in relazione all’ambito reale di
utilizzo, ovvero il problema di localizzazione legato al monitoraggio dei rischi ambientali
derivanti da fenomeni franosi. Infine si è passati alla parte sperimentale. Si sono effettuate
prove che dimostrano la bontà della soluzione elaborata. Prendendo in considerazione
l’errore medio sul posizionamento stimato, si è dimostrato che il ROCRSSI++ introduce
un miglioramento medio del 30% rispetto al ROCRSSI relativamente alle topologie
considerate. Dopodichè si è effettuata un analisi energetica in cui si è dimostrato che a
fronte del miglioramento consistente sull’accuratezza, il dispendio energetico aumenta
soltanto del 6% in relazione alla particolare rete di sensori considerata. Si è effettuata poi
un’analisi dei costi che giustifica lo studio effettuato, dimostrando infatti che costruendo
una WSN basato sull’algoritmo di posizionamento creato vi è un risparmio del 41% sui
costi relativi all’hardware rispetto al caso in cui si utilizzano nodi ciascuno dotato di GPS,
senza considerare che l’accuratezza della stima del posizionamento ed il consumo
energetico sono di gran lunga peggiori in quest’ultimo caso.
194
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Sviluppi futuri
Per quanto concerne gli sviluppi futuri, sicuramente si dovranno effettuare prove
sperimentali su sensori reali in ambiente outdoor per vedere in questo contesto, come si
comportano i sensori. Inoltre, per testare la bontà del sistema di localizzazione, occorrerà
provare l’applicazione di localizzazione su una WSN reale, infatti, qui occorrono diversi
fenomeni difficilmente riproducibili in ambiente simulato (uno tra tutti il fenomeno di
fading) che potrebbero influenzare il comportamento dell’applicazione di localizzazione.
Un'altra misurazione da effettuare, considerando una particolare WSN reale sviluppata ad
hoc per una specifica funzione, è quella relativa all’autonomia dei singoli nodi. Infine per
il particolare contesto in cui s’inserisce il lavoro svolto, è indispensabile effettuare test
dell’intera architettura realizzata (WSN dotata di stargate che comunica tramite protocollo
UDP creato ad hoc con il server dell’architettura iCAAS) inserita nello specifico territorio
che si vuole monitorare. Questa è una prova indispensabile, in quanto le reti di sensori
sono fortemente influenzate dall’ambiente circostante molto di più dei sistemi tradizionali.
195
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Appendice A: Installazione e configurazione di TinyOS
In quest’appendice si affronterà l’aspetto tecnico e pratico di TinyOS ovvero ci
occuperemo della sua installazione su piattaforma Windows e la successiva
configurazione per gli scopi prefissati. Innanzitutto per poter installare una qualsiasi
versione di TinyOS sotto Windows si può utilizzare Cygwin che fornisce una envitrement
linux-like su windows consentendo di effettuare il porting di software che gira su sistemi
POSIX. Un volta installato Cygwin possiamo dedicarci completamente all’installazione di
TinyOS. In quest’ambito è stata scelta la release TinyOS 1.1.11 gratuitamente scaricabile
da:
http://www.tinyos.net/dist-1.1.0/tinyos/windows/
a causa di vari bug relativi alla generazione della documentazione NesC (problemi legati
ai tools per generare la nescdoc) si è scelto di effettuare l’upgrade tramite il file:
tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm
utilizzando il comando:
rpm --force -ivh --ignoreos *.rpm
all’interno della console Cygwin. Ad upgrade completato, innanzitutto verifichiamo se ci
sono dei problemi dovuti all’installazione o alla configurazione dell’ambiente TinyOS,
questa verifica può essere fatta in modo semplice attraverso il comando:
toscheck
196
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Figura A.5 – Esempio di output della console cygwin relativo al comando toscheck
In figura A.5 ritroviamo un esempio di output relativo al lancio del comando visto in
precedenza, si può notare che viene segnalato un warning in quanto la versione JRE (Java
Runtime Envoirment) presente nel sistema non è la versione richiesta da TinyOS 1.1.15
ossia la versione Java 1.4.2. Questo è un problema molto frequente quando si va ad
installare cygwin su una macchina dove è già presente una versione di java più avanzata,
197
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
per risolvere questo conflitto di versione si possono intraprendere varie strade. Una di
queste consiste in un downgrade dalla versione più recente (le versioni di java più recenti
sono 1.6 e 1.7) alla versione 1.4.2, la grossa limitazione di questa soluzione sta nel fatto di
non poter utilizzare alcune librerie java che sono caratteristiche delle versioni successive
alla versione 1.4.2 (ad esempio la libreria java.util.concurrent libreria che fornisce utilità
nella programmazione concorrente).Una soluzione più elegante, che è stata poi quella
adottata, consiste nell’installare la versione di java1.4.2 in una directory visibile a Cygwin
e successivamente creare una variabile d’ambiente in Windows utilizzata esclusivamente
da TinyOS definita come segue:
TINY_JAVA = C:\Programmi\UCB\jdk1.4.1_02\j2sdk1.4.1_02\jre\bin\
Dopodichè nel file di configurazione della console Cygwin chiamato bash.bashrc,
sostituiamo il riferimento alla variabile d’ambiente di sistema con quella appena creata.
Un altro problema molto diffuso ed affrontato anche da noi, è quello relativo alla corretta
configurazione delle librerie javax.comm indispensabili per la comunicazione seriale.
Infatti bisogna essere sicuri di possedere la versione di libreria 1.4.1_02 ed aggiungere il
percorso del file jar (contenente i file.class costituenti la libreria) all’interno della variabile
d’ambiente Classpath, esempio:
CLASSPATH = C:\Programmi\UCB\jdk1.4.1_02\j2sdk1.4.1_02\jre\lib\comm.jar
Una volta che il comando toscheck non rileva ne errori ne warning, possiamo ritenere
l’installazione e la configurazione di TinyOS completata correttamente.
Un ulteriore passo, assolutamente opzionale, ma comunque utile ai fini di automatizzare
determinate operazione, è quello di costruire un ambiente di compilazione tramite i
makefile; infatti tramite l’utilizzo dei makefile è possibile creare una pipe di comandi di
compilazione. Il file principale che gestisce molti aspetti del processo di costruzione delle
applicazioni TinyOS si chiama Makerules situato nella directory /opt/tinyos1.x/tools/make e offre le basi per costruire i makefile utilizzati nelle applicazioni utenti.
Un esempio di makefile utente creato è il seguente:
198
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
COMPONENT = TestStorageMessage
PFLAGS += -I%T/lib/ROCRSSI++
include ../Makerules
DEFAULT_LOCAL_GROUP = 0x33
dove è specificato il componente principale dell’applicazione utente, il path relativo ad
alcuni componenti utilizzati, l’inclusione del file principale Makerules ed infine un
identificativo del gruppo di sensori.
Infine dopo aver compreso il funzionamento dei makefile, si passa alla compilazione di
tutti i tool java presenti nella release di TinyOS installata, digitando i seguenti comandi:
cd /opt/tinyos-1.x/tools/java
make
cd /opt/tinyos-1.x/tools/java/jni
make install
199
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Bibliografia
[1]
Y. Sankarasubramaniam, W. Su - “Wireless sensor networks a survey.”
[2]
T.S. Rappaport - “Wireless communications: principle and practice”
[3]
E. Yoneki, J. Bacon - “A survey of wireless sensor network technologies: research
trends and middleware's role”
[4]
D. Bertsekas, R. Gallager - “Data Networks”
[5]
Moore, Riggs - “Telecomunicazioni” Apogeo and Hill associates
[6]
“EWSN Third European WorkshopAdjunct Proceedings”
[7]
M. Zorzi - “A new contention-based MAC protocol for geographic forwarding in ad
hoc and sensor networks”
[8]
B.A. Forouzan - “I protocolli TCP/IP” McGraw-Hill
[9]
M. Andretto - “Studio e sperimentazione di algoritmi di localizzazione per reti di
sensori”
[10] R. Crepaldi - “Algoritmi di localizzazione per reti di sensori: progettazione e
realizzazione di una piattaforma sperimentale”.
[11] P. Bonnet - “Sensor Networks: An Overview”
[12] Datasheet CC1000, MICA2, MICAz – sito Crossbow: www.xbow.com
[13] M. Zorzi, A. Zanella - “Reti di sensori dalla teoria alla pratica”
[14] J. Hightower, G. Borriello “A survey and taxonomy of location system for
ubiquitous computing”.
[15] R. Want, A. Hopper, V. Falcao, J. Gibbons. “The active badge location system”
[16] Nissanka B. Priyantha, A. Chakraborty, H. Balakrishnan. “The Cricket locationsupport system”. in “Mobile Computing and Networking”
200
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
[17] J. Hightower, C. Vakili, G. Borriello, R. Want “Design and Calibration of the
SpotON Ad-Hoc Location Sensing System”.
[18] L. Doherty, K.S.J. Pister, L. El Ghaoui “Convex position estimation in wireless
sensor networks”. In Proceedings “IEEE INFOCOM” 2001.
[19] N. Bulusu, J. Heidemann, D. Estrin “GPS-less low cost outdoor localization for very
small devices”.
[20] M. Khan, S. Olariu, M. Eltoweissy - “Efficient Single-Anchor Localization in
Sensor Networks”
[21] C. Liu K. Wu - “Performance Evaluation of Range-Free Localization Methods for
Wireless Sensor Networks”
[22] D. Lymberopoulos, Q. Lindsey, A. Savvides - “An Empirical Characterization of
Radio Signal Strength Variability in 3-D IEEE 802.15.4 Networks Using Monopole
Antennas”
[23] X. Huang, X. Cheng, D.Z. Du. – “Ad Hoc Wireless Networking”
[24] A. Savvides, Chih-Chieh Han, M.B. Strivastava – “Dynamic fine-grained
localization in ad-hoc networks of sensors.”
[25] C. Savarese, J.M. Rabaey, K. Langendoen – “Robust positioning algorithms for
distributed ad-hoc wireless sensor networks.”
[26] A. Savvides, H. Park, M. Srivastava. – “The Bits and Flops of the N-Hop
Multilateration Primitive for Node Localization Problems”
[27] K. Langendoen, N. Reijers – “Distributed localization in wireless sensor networks: a
quantitative comparison”
[28] C. Fretzagias, M. Papadopouli – “Cooperative Location Sensing for Wireless
Network”
[29] R. Crepaldi, P. Casari, A. Zanella, M. Zorzi – “Testbed Implementation and
Refinement of a Range–Based Localization Algorithm for Wireless Sensor
Networks”
[30] T. H. Chong Liu, Kui Wu. – “Sensor localization with ring overlapping based on
comparison of received signal strength indicator”
201
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
[31] X. Nguyen, T. Rattenbury - “Localization algorithms for sensor network using rf
signal strength cs 252 class project”
[32] M. Andretto, A. Zanella – “Experimental Localization Results in an Indoor Wireless
Sensor Network Testbed”
[33] Phil Buonadonna, Jason Hill, David Culler - “Active Message Comunication for
Tiny Network Sensor”
[34] D.Gay, P.Levis, D.Culler, E.Brewer: “NesC 1.1 reference manual”
[35] P. Levis - “TinyOS Programming”
[36] Sito ufficiale tinyOS – “http://www.tinyos.net”
[37] Repository del codice sorgente di tinyOS – “http://www.tinyos.net/dist-1.1.0”
[38] D. Gay, P. Levis, R. Von Behren – “The nesC Language: A Holistic Approach to
Networked Embedded Systems”
[39] M. Cinque, C. Di Martino, D. Cotroneo - “TinyOS nesC programming”
[40] S. Lenzi – “Interfacciamento Java & TinyOS”
[41] S.R. Madden, M.J. Franklin - “TinyDB: An Acquisitional Query Processing System
for Sensor Networks”
[42] S.R. Madden, J. Hellerstein - “TinyDB: In-Network Query Processing in TinyOS”
[43] Sito Wikipedia, sezione TinyOS - “http://it.wikipedia.org/wiki/TinyOS”
[44] P. Levis, N. Lee – “TOSSIM: A Simulator for TinyOS Networks”
[45] V. Shnayder – “Simulating the Power Consumption of Large-Scale Sensor Network
Applications”
[46] H. Davis, R. Miller – “Power Management for Mica2 Motes”
[47] D. Lymberopoulos, Q. Lindsey, A. Savvides – “An Empirical Characterization of
Radio Signal Strength Variability in 3-D IEEE 802.15.4 Networks Using Monopole
Antennas”
[48] G. Panzuto – “Progetto e sviluppo di un’architettura interoperabile e configurabile
per l’accesso a reti di sensori”
202
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
Ringraziamenti
Finalmente eccoci qua, la parte più bella da scrivere. Non solo perché ti dedichi a questa
quando sai di aver finito e provi un irrefrenabile senso di liberazione, ma anche perché è
quella che ti emoziona di più. Seguirò il codice:”Prima di tutto, la famiglia!”, non perché è
una frase di uno dei miei film preferiti, ma perché è una cosa in cui credo. Ecco perché
inizierò i ringraziamenti partendo da mia mamma che ha avuto il compito più arduo, cioè
quello di “sopportarmi” (specie in quest’ultimo periodo) pur non facendomelo mai pesare
ma al contario ricoprendomi attenzioni amorose, non so se esistono aggettivi per
descrivere una persona straordinaria come lei, ecco perché mi limito a dirgli grazie.
Ringrazio mio padre, da sempre mio modello comportamentale (a parte purtroppo il fatto
che è tifoso del Milan), per tutto ciò che ha fatto per me: dal regelarmi il mio primo pc,
all’incoragiarmi quando ho ripetuto per la quarta volta l’esame di metodi matematici; se
sono arrivato a questo punto parte del merito va a lui. Grazie. Per ultima (ma solo perché è
la più piccola) ringrazio mia sorella che mi piace considerare la mia “versione femminile”
anche se molto più bella, con un’ineguagliabile e coinvolgente gioia di vivere, forse è
proprio per questo che andiamo così d’accordo, in una parola… la mia vita.
Poi volevo ringraziere mia nonna Giovanna che mi ha sempre incoraggiato e supportato in
questo percorso, mio nonno Ugo la persona che mi ha fatto ridere con più gusto nella mia
vita. Ringrazio poi tutti i miei zii e cugini che fanno parte delle persone più importanti
della mia vita.
Un ringraziamento particolare va alla mia ragazza Stefania, che con la sua dolcezza ed il
suo modo di fare mi ha trasmesso quella tranquillità di cui avevo bisogno.
Poi voglio passare a ringraziare tutti i miei amici più cari. Chi dice che l’amicizia non è
203
STUDIO E SPERIMENTAZIONE
DI SISTEMI DI LOCALIZZAZIONE
PER RETI DI SENSORI SENZA FILO
altro che una parola, non è stato fortunato come me. Non citerò nomi per paura di
dimenticarmi di qualcuno (la stanchezza inizia a farsi sentire), mi limiterò a ringraziare
tutte quelle persone che sono state testimoni della mia vita, con le quali ho condiviso
momenti indimenticabili e che proprio grazie a loro posso di dire di aver vissuto davvero
la mia vita.
Non posso non ringrazire tutti gli amici, colleghi e tutte le persone che ho conosciuto
“vivendo” sette stagioni di animazione nei villaggi, quest’esperienze sono state le più
intense della mia vita e non potendo fare un elenco (ci vorrebbe un’altra tesi!) ringrazio
due persone su tutte: Flaminia ed Antonio.
In ambito accademico, un ringraziamento particolare va a Domenico nella triplice veste di
amico, compagno di tennis e relatore che mi ha saputo consigliare ed indirizzare nella
formazione; e soprattutto a Marcello che mi ha dato consigli preziosissimi per il lavoro di
tesi e che sicuramente mi torneranno utili in altri contesti. Ovviamente voglio ringraziare e
salutare tutte le persone che mi hanno accompagnato nel percorso universitario e cho ho
avuto la fortuna d’incontrare. Persone fantastiche con le quali ho condiviso molto, a
partire da Gianni “o’russ” che nell’ultimo periodo ho sentito più della mia ragazza e con il
quale ho lavorato con piacere; proseguendo con Alberto, o meglio Ad²Alberto, che ho
conosciuto in ritardo rispetto ad altri ma è come un vecchio amico; fino a Michele che è
una delle persone con le quali condivido molti di quegli interessi che hanno contribuito a
ritardare il nostro traguardo. Infine ringrazio Gabriella che forse è stata la prima persona
che ho conosciuto all’università, Mimmo, Vincenzo, Guido e Giancarlo e tutti i
personaggi che si aggiravano per le aule universitarie a quei tempi.
L’intera esperienza universitaria è stata come una grande traversata, un avventura per mari
inesplorati, all’inizio molto divertente ed eccitante, poi via via sempre più logorante.
Fortunatamente negli anni qualcuno mi ha insegnato che si può prendere il timone,
tracciare la rotta e seguirla anche in caso di burrasca, così quando sarà il momento di
dimostrare il proprio valore, tutti resteranno abbagliati dalla luce emanata dalle proprie
vele.
Grazie Francesco.
204