Elaborato Ruggiero Roberto N46000200

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Programmazione II
Analisi di piattaforme per lo sviluppo di
applicazioni su reti di sensori senza filo
Anno Accademico 2014 - 2015
Candidato
Roberto Ruggiero
matr. N46000200
Indice
Indice................................................................................... III
Introduzione ......................................................................... 4
Capitolo 1: Reti di sensori senza filo ................................... 5
1.1 Stato dell’arte .............................................................................. 7
1.2 Applicazioni delle reti di sensori .............................................. 11
Capitolo 2: Piattaforme software ....................................... 12
2.1 TinyOS ...................................................................................... 13
2.2 Contiki ...................................................................................... 16
2.3 Nano-RK ................................................................................... 17
Capitolo 3: Modelli di programmazione ............................ 18
3.1 Programmazione ad eventi ....................................................... 19
3.1.1 La sintassi in TinyOS ................................................................. 21
3.1.2 Esempio: PowerUP .................................................................... 22
3.2 Waspmote programming model ............................................... 24
3.2.1 Ambiente di sviluppo ................................................................. 26
3.2.2 Esempio: lettura dall’accelerometro ........................................... 27
3.3 La programmazione in Contiki ................................................ 28
3.3.1 Struttura di un programma ......................................................... 29
Conclusioni ........................................................................ 30
Bibliografia .......................................................................... 31
III
Introduzione
I progressi nelle tecnologie dei sistemi microelettromeccanici MEMS, delle
comunicazioni senza filo e dell'elettronica digitale, hanno permesso lo sviluppo di
piccoli dispositivi a bassa potenza dai costi contenuti, multifunzionali e capaci di
comunicare tra loro tramite tecnologia wireless. Questi piccoli apparecchi,
chiamati nodi sensore, o mote, hanno un costo di produzione molto basso e sono
caratterizzati da dimensioni e peso ridotti. Essi sono in grado di rilevare e acquisire
grandezze fisiche mediante sensori: particolari trasduttori che si trovano in diretta
interazione con il sistema misurato1. Inoltre sono in grado di elaborare i dati acquisiti
e scambiare informazioni con altri nodi sensore.
Una rete di sensori, o sensor network, è un insieme di nodi disposti in prossimità
oppure all'interno del fenomeno da osservare.
L’idea che sta alla base delle reti di sensori senza filo nasce molti anni fa, con il
concetto "Smurt Dust"[1]. Lo scopo delle reti di sensori senza filo è principalmente
quello di produrre, su un periodo esteso di tempo, un’informazione in tempo reale,
globale, significativa, a basso costo anche in ambienti ostili [3], mediante una serie di
dati locali provenienti dai singoli sensori.
Negli ultimi anni le reti di sensori hanno subito un grosso sviluppo tecnologico, non
solo dal punto di vista hardware. Come verrà approfondito nei capitoli 2 e 3 di questo
elaborato, il progresso tecnologico ha “colpito” anche i sistemi operativi per i nodi
delle reti senza filo, ed i modelli di programmazione delle applicazioni. Tale sviluppo
ha permesso l’impiego delle reti di sensori senza filo, in numerosi ambiti[2], che vanno
da quelli militari a quelli scientifici, industriali, medici e domestici.
1
In base alla norma UNI4546 Misure e Misurazioni
4
Capitolo 1
Reti di sensori senza filo
Per comprendere appieno cos’è una rete di sensori senza filo risulta interessante
partire dalle unità costituenti di tali infrastrutture: i nodi sensore. In figura 1 possiamo
vedere una generica architettura hardware di un nodo sensore.
Figura 1 – Architettura hardware di un nodo sensore
•
Microcontrollore: è la CPU del nodo e si occupa di rilevare i dati, elaborarli,
decidere dove e quando spedirli, ricevere dati da altri nodi, gestire gli attuatori
e i sensori. Si utilizzano i microcontrollori come unità di calcolo, poiché
richiedono poca energia, hanno una memoria integrata, sono facilmente
programmabili e si interfacciano bene con sensori e attuatori.
•
Memoria: la memoria è di tipo RAM, usata per le variabili temporanee,
oppure di tipo EEPROM o FLASH per il codice e lo storage dei dati raccolti.
•
Dispositivo di comunicazione: solitamente un trasmettitore ad onde radio.
Può operare a diverse frequenze e con diversi livelli di affidabilità nella
trasmissione dei dati. I trasmettitori più impiegati sono quelli che operano a
2.4Ghz, seguendo lo standard IEEE 802.15.4 (ZigBee)[4].
5
•
Sensori: attraverso i convertitori ADC e le periferiche dei microcontrollori, un
mote è capace di accogliere svariati tipologie di sensori sia digitali che
analogici.
•
Fonte di alimentazione: solitamente batterie. Le reti che devono avere un lifetime molto lungo, spesso ricorrono a fonti energetiche ausiliare per ricaricare
le batterie dei nodi[5].
Una rete di sensori senza filo può essere costituita da poche decine a centinaia di nodi
sensore, in cui ciascun nodo, ha la capacità di accumulare e di instradare i dati fino ad
uno o più nodi speciali della rete, detti nodi sink. I sink hanno lo scopo di raccogliere i
dati e trasmetterli tipicamente ad un server o ad un calcolatore e quindi all'utente
finale. La topologia dei nodi nell’area di sensing2 generalmente può essere: a stella,
mash o peer-to-peer, oppure ad albero.
E’ importante evidenziare che le reti di sensori senza filo, o reti di sensori wireless,
presentano sostanziali differenze dalle reti ad hoc. Ciò è evidente dal fatto che: il
numero di nodi di una rete di sensori può essere di alcuni ordini di grandezza
maggiore rispetto al numero di nodi in una rete ad hoc, la topologia di una rete di
sensori può cambiare frequentemente a causa di guasti o per la necessità di variare i
punti di misura, i nodi utilizzano un paradigma di comunicazione broadcast e non
punto-punto, sono limitati rispetto ad alimentazione, capacità di calcolo e memoria,
solitamente non possiedono un identificatore globale. Per tali motivi, questa tipologia
di rete necessita di algoritmi pensati e realizzati in maniera specifica per gestire la
comunicazione e l’instradamento dei dati. La maggior parte delle reti di sensori, ad
esempio sono modellate come dei database distribuiti.
Un’ulteriore problematica circa le reti di sensori wireless è la riserva d'energia limitata
e quasi sempre non rinnovabile dei nodi sensore. Ciò ha spinto fin da subito numerosi
gruppi di ricerca a rivedere le tecniche di programmazione per mantenere
costantemente bassi i consumi e aumentare il ciclo di vita dei nodi.
Il primo meccanismo per ridurre i consumi è stato quello di permettere ai nodi di
effettuare le elaborazioni sui dati grezzi prima di trasmetterli al sink, in modo da
2
Area all’interno della quale sono disposti i nodi sensore.
6
trasmettere solo i dati richiesti e già elaborati. In questo modo si riesce ad avere
notevoli risparmi energetici e un abbattimento dei tempi in cui è attiva la trasmissione
dati. Un’ulteriore metodo per ridurre il consumo energetico delle reti di sensori è
quello di dotare i nodi sensore di capacità auto-organizzative. In questo modo i motes,
possono effettuare un auto-apprendimento circa la loro posizione relativa al nodo sink
più vicino, evitando così trasmissioni inefficienti o a potenza sovradimensionata.
Fin ora abbiamo evidenziato due delle problematiche principali delle reti di sensori
wireless: l’instradamento e la trasmissione dei dati raccolti e la gestione delle risorse
energetiche dei motes. Le reti di sensori senza filo, allo stesso tempo, forniscono tutta
una serie di benefici, quali: costi di cablaggio ridotti, bassa complessità di
installazione in sito, numero elevato di punti di misura, topologia variabile della rete,
scalabilità a basso costo, fault-tolerance3.
1.1 Stato dell’arte
In
commercio
sono
disponibili
diverse
piattaforme.
La
scelta
dipende
dall'applicazione specifica che si vuole creare, dal contesto in cui la rete di sensori
wireless verrà adoperata, dalle dimensioni massime ammissibili dei nodi della rete, dal
costo sostenibile, dalla loro efficienza energetica e dalla robustezza richiesta. Tra le
piattaforme hardware più importanti, alcune delle quali ormai fanno parte della storia
delle reti wireless, abbiamo:

Mica Family (Mica, Mica2, Mica2dot, MicaZ) della Crossbow Technology[6];

Telos Family (Telos, TelosA, TelosB, TmoteSky) della Moteiv Corporation[7];

BTnodes dell'ETH di Zurigo[9];

FireFly della Carnagie Mellon University[8];

Lotus Cortex dalla Memsic[10];

Waspmote dalla Libelium[15];
3
Capacità di un sistema di non subire avarie anche in caso di guasti
7
Dal punto di vista architetturale, questi nodi sensore sono tutti simili e rappresentabili
come in figura 1. Di fatto sono tutte evoluzioni del nodo Mica.
I nodi sensore Mica sono stati sviluppati dall'Università della California a Berkeley,
verso la fine degli anni ‘90. Sono quattro i modelli appartenenti a questa serie: Mica,
figura 1.1.1, Mica2, figura 1.1.2, Mica2Dot e MicaZ, figura 1.1.3, che differiscono in
base a caratteristiche tecniche e dimensioni (distribuiti dalla Memsic[10]). Sono dotati
tutti di microcontrollore Atmel[34] 8 bit a 4 Mhz, con 4 Kbyte di RAM, ADC a 10 bit
a 8 canali, 128 Kbyte di memoria FLASH programmabile e 512 Kbyte per i dati. La
sostanziale differenza tra i vari membri della famiglia dei Mica è il chip radio, nel
MicaZ è il CC2420 con data rate di 250Kbit/s e compatibile con IEEE 802.15.4.
Tutti i nodi della famiglia Mica non posseggono sensori integrati ma, attraverso dei
pin di espansione, possono accogliere numerose tipologie di sensori per il rilevamento
di temperatura, umidità, accelerazioni, pressioni, campi magnetici,…
Figura 1.1.1 – Mica
Figura 1.1.2 – Mica2
Figura 1.1.3 – MicaZ
I motes della famiglia Telos, naturale evoluzione dei nodi Mica, sono disponibili in
quattro versioni: Telos, TelosA, TelosB, figura 1.1.4, e TmoteSky. A differenza dei
Mica, i Telos montano un nuovo microcontrollore. Si tratta dell’MSP430[11] a 16 bit,
dotato di 10 Kbyte di memoria RAM, 48 Kbyte di memoria FLASH, di un
convertitore ADC a 12 bit e di un controllore DMA4. Ogni nodo della famiglia Telos è
dotato di 1 Mbyte di memoria FLASH esterna e dispongono on-board di sensori di
temperatura, umidità e luminosità.
Fig 1.1.4 – TelosB
4
Direct Memory Access
8
I BTnode[9], figura 1.1.5, sono nodi sensore progettati principalmente dall’ETH di
Zurigo, è realizzati in tre versioni: la più recente, chiamata BTnode rev3, è la
piattaforma che ha avuto più successo anche grazie alle numerose interfacce di
comunicazione e periferiche quali: ISP, UART, SPI, I2C, GPIO. La parte di
trasmissione radio rappresenta la particolarità di questo mote: consiste in un doppio
sistema di trasmissione, dispone sia di un chip radio Bluetooth che di una scheda radio
CC1000. In questo modo con il primo metodo di trasmissione può offrire una
comunicazione molto affidabile e con un data-rate alto, ma con una copertura più
bassa, con il secondo metodo si ottiene invece una comunicazione radio con una
copertura superiore, ma con un data-rate più basso.
Figura 1.1.5 – BTnode
Il nodo sensore Firefly[3], visibile in figura 1.1.6, è nato per il monitoraggio nelle
miniere. E’ dotato di un processore Atmega128L con 8 Kbyte di memoria RAM e 128
Kbyte di ROM. Attraverso una porta SDIO 5 si possono utilizzare schede di memoria
FLASH. La trasmissione è garantita dal modulo radio CC2420 compatibile con lo
standard IEEE 802.15.4. I consumi di questa tipologia di nodo sono estremamente
ridotti: la durata prevista delle batterie è di quasi due anni. Questo è reso possibile da
complessi meccanismi di sincronizzazione tra i vari nodi della rete che permettono di
poter mandare i nodi sensore in sleep-mode molto rapidamente, minimizzando i
periodi di idle.
Figura 1.1.6 – FireFly
5
Secure Digital Input Output
9
Il Lotus Cortex, figura 1.1.7, prodotto dalla MEMSIC[10], possiede un’architettura
estremamente avanzata. Adotta componenti di ultima generazione che migliorano
notevolmente le prestazioni del nodo, rispetto ai motes precedenti, mantenendo
comunque i consumi molto bassi6. Monta una CPU Cortex® M3[12], 10-100 Mhz a 32
bit e ha un modulo radio compatibile con IEEE 802.15.4. La memoria on-board è
costituita da 64KByte di SRAM, 512KByte di memoria FLASH e 64 Mbyte di serial
FLASH per i dati raccolti.
Figura 1.1.7 – Lotus Cortex
Con 51-pin di espansione il Lotus supporta: ingressi analogici su ADC, digital IO,
I2C, SPI e UART. Viene configurato di fabbrica per accogliere sistemi RTOS7, come
TinyOS[13], MoteRunner[14] e tutta una serie di software open source.
Il Waspmote, figura 1.1.8, nodo sensore di casa Libelium[15] è tra le piattaforme
hardware, nate per le reti di sensori senza filo, più versatili.
Figura 1.1.8 – Waspmote
Il Waspmote ha un microcontrollore ATmega1281[34] con una frequenza di 14 MHz,
SRAM da 8KByte, EEPROM da 4KByte, memoria FLASH da 128KByte e uno slot
per SD Card fino a 2GByte. Il Waspmote on-boad presenta un accelerometro MEMS e
un sensore di temperatura. Attraverso tutta una serie di pin e board di espansione è
6
7
Da 50mA a 10μA in sleep mode
Real-Time Operating System
10
possibile equipaggiarlo con vari tipi di sensori. L'azienda spagnola si è imposta una
visione della connettività dei dispositivi altamente variegata, facendo in modo che le
piattaforme hardware supportino diverse tecnologie di trasmissione: dalla lunga
distanza, 3G/GPRS fino a 802.15.4, Bluetooth e NFC; inoltre supporta diversi
protocolli: ZigBee, LoRa, IPv6 radio, Bluetooth… a diverse frequenze di
trasmissione: 2.4GHz, 868MHz, 900MHz. Inoltre i Waspmote gestiscono tutta una
serie di protocolli industriali come Modbus, RS234, RS485, CANbus…
1.2 Applicazioni delle reti di sensori
Negli ultimi anni sono stati numerosi i gruppi di ricerca che hanno applicato le reti di
sensori senza filo in contesti reali, dimostrando le effettive potenzialità di tale
tecnologia. Come si può osservare in figura 1.2, una rete di sensori può essere
impiegata principalmente per due scopi: il monitoraggio e il tracking. I campi
d’applicazione riportati in letteratura([2][16][17][18][19][20]) sono numerosi.
Figura 1.2 – Applicazioni delle reti di sensori
11
Capitolo 2
Piattaforme software
Il mondo delle reti di sensori senza filo richiede, oltre ad un insieme di componenti
hardware specifici, come abbiamo visto nel capitolo precedente, anche piattaforme
software dedicate ([21][22][23]).
Ogni nodo sensore, data la sua architettura, è in grado di effettuare operazioni
complesse, come il campionamento e la trasmissione dei dati via radio. Risulta quindi
fondamentale avere un sistema operativo compatto che possa essere flessibile e adatto
all’architettura hardware tipica dei nodi sensore.
Un sistema operativo per i nodi di una rete di sensori wireless deve possedere le
seguenti caratteristiche:
•
Elaborazione con poche risorse: i microcontrollori hanno memorie di
qualche decina di Kbyte, sono progettati per il risparmio energetico, a
discapito delle prestazioni.
•
Consumi energetici ridotti al minimo: i sistemi operativi devono essere
pensati per il risparmio energetico, sia in fase di elaborazione che in fase di
trasmissione dei dati.
•
Alta concorrenza: la velocità e la prontezza del sistema operativo è
essenziale. Il sistema operativo deve essere in grado di gestire le
comunicazioni via radio e i sensori, in maniera concorrente.
•
Gestione diretta dell’hardware: l’hardware deve essere gestito mediante un
sottile strato software, che astrae i comandi di accesso alle risorse. Esistono
pochi controller secondari, nei motes il microcontrollore gestisce direttamente
il chip radio e gli ADC che governano i sensori.
•
Robustezza: le reti di sensori senza filo sono pensate per un utilizzo intensivo
e continuativo. Il software, deve essere semplice, robusto e affidabile.
12
Si possono distinguere due macro tipologie di sistemi operativi per nodi sensore:
quelli in cui i componenti del sistema operativo vengono compilati insieme
all’applicazione, come TinyOS[13], e i sistemi invece con i tradizionali strati software
general purpose, in versione ridotta, come Contiki[26], Nano-RK[28], MoteRunner[14].
La prima tipologia di sistema operativo solitamente ha una sola applicazione in
esecuzione. Ciò permette di avere consumi molto ridotti, non essendoci in genere
context switch e bassa occupazione di memoria. Lo svantaggio derivante da tale
approccio è la limitata versatilità e i seri vincoli di riconfigurabilità dell’applicazione.
Nel secondo caso è più difficile tenere i consumi sotto controllo e risparmiare risorse
hardware, ma si guadagna in versatilità potendo eseguire più applicazioni
contemporaneamente.
2.1 TinyOS
Le soluzioni attualmente esistenti alle problematiche sopra citate sono molteplici.
TinyOS8 è sicuramente il più noto e diffuso sistema operativo per reti di sensori senza
filo. E’ un sistema open - source, originariamente sviluppato come progetto di ricerca
dall’Università della California, Berkeley, in collaborazione con Intel. La sua
popolarità negli anni è cresciuta tantissimo, fino ad avere una comunità internazionale
di sviluppatori e utilizzatori. La prima versione del sistema è stata rilasciata nel 2000,
mentre l’ultima, la versione 2.1.2, è del 2012.
Il linguaggio di programmazione con cui è stato sviluppato TinyOS è il nesC 9[24], che
offre un modello di programmazione basato su eventi.
TinyOS, ha dimensioni molto ridotte, l’occupazione di memoria è di circa 10 Kbyte, e
può essere visto come un ambiente di esecuzione che segue un modello ad eventi.
Infatti è un sistema operativo completamente non bloccante, in cui non è previsto il
supporto per i threads10. L’Architettura è component-based, fornisce una ricca libreria
di componenti predefiniti: tra cui protocolli di rete, servizi distribuiti, astrazioni
8
Tiny Operating System, sistema operativo “minuscolo”
Network embedded system C
10
Introdotti dalla versione 2.1 (TOSThreads architecture)
9
13
hardware, timer, driver per sensori e strumenti di acquisizione dati. Tutti questi
componenti possono essere utilizzati così come sono, oppure ridefiniti. Grazie
all’architettura a moduli di TinyOS, sui nodi sensore verranno caricati solo i
componenti strettamente necessari all’applicazione da eseguire.
Il componente principale, responsabile del funzionamento di TinyOS è lo scheduler.
Tale componente manda in esecuzione i task con una politica FIFO 11 run to
completion12. Lo scheduling ha due livelli di priorità: normale, per i task, e quello più
alto per gli eventi o comandi, i quali possono interrompere i task.
Il modello a componenti di TinyOS possiede i command handlers e gli event handlers.
I componenti comunicano tra loro invocando comandi, e sollevando eventi. Comandi
ed eventi, vengono eseguiti a livello alto di priorità dello scheduler.
Ogni componente presenta un frame, che rappresenta l’area dati del componente,
allocata staticamente, dato che in TinyOS non è prevista l’allocazione dinamica.
I componenti possono essere suddivisi in: hardware abstractions, componenti che
mappano le funzionalità fornite sull’hardware via software, creando un’astrazione
dello stesso e rendendolo utilizzabile dai moduli superiori, ad esempio un componente
che legge un bit da un canale radio. I synthetic hardware, moduli che simulano il
comportamento di hardware più sofisticato di quello realmente presente sul mote, ad
esempio un componente che assembla 8 bit e li invia a quelli ai livelli superiori. Infine
gli high level software component, componenti di livello più alto che si occupano di
eseguire algoritmi e gestire protocolli che si distaccano dal particolare hardware
presente, ad esempio il componente che implementa un protocollo di comunicazione.
Active Messages (AM) è la tecnologia di rete utilizzata da TinyOS per gestire la
comunicazione radio, da mote a mote, o seriale, da pc a mote. Non specifica
meccanismi connection-oriented, ogni pacchetto è un’entità indipendente.
La comunicazione con AM avviene tramite messaggi, che presentano un identificatore
chiamato AM Type, che identifica il tipo di evento da generare nel nodo che riceve il
messaggio.
11
12
First-in-first-out
Un task non può interrompere un altro task.
14
Il principale svantaggio dell’approccio Active Messages è che tutti i nodi comunicanti
devono avere lo stesso software o implementare un componente che definisca lo
stesso tipo di identificatore.
La versione più recente di TinyOS, la 2.1.2, apporta lievi migliorie rispetto alla
versione 2.1. Per questo ai fini della nostra analisi considereremo la versione 2.1.
Il più grosso miglioramento del “sistema operativo minuscolo” è avvenuto con il
passaggio dalla versione 1.x alla 2.x. La versione 2.x, si presenta come una riscrittura
completa del TinyOS 1.x con lo scopo di riorganizzarlo, ottimizzarlo con nuove
funzionalità. Tale riscrittura, però, ha reso incompatibili i software eseguibili tra le
due versioni.
Vediamo ora, quali sono state le maggiori novità introdotte in TinyOS versione 2.1:
•
Lo scheduler diventa un componente modulare che può essere sostituito o
modificato con maggiore facilità.
•
Supporto per i threads, attraverso la libreria TOSThreads e protezione della
memoria a run-time attraverso il meccanismo Safe TinyOS.
•
La struttura architetturale basata su livelli di astrazione è stata rivisitata per
migliorare il supporto con l’hardware. Nuove piattaforme possono accogliere
così TinyOS, inoltre alcuni servizi livello applicazione sono stati migliorati.
•
Nuovi protocolli di comunicazione e instradamento dei frame introducono un
miglioramento del 35% sull’efficienza e sull’occupazione di memoria
RAM[13].
•
Le funzionalità radio sono state impostate in modo tale da essere sempre non
operative dopo il boot del sistema. E’ necessario uno start esplicito ed
esclusivo. Così si evitano sprechi energetici.
•
Il formato dei frame 802.15.4 viene modificato per supportare in un futuro reti
6LoWPAN13 e un livello MAC compatibile sempre per le reti 802.15.4.
•
La struttura dei buffer dei messaggi è stata modificata e riorganizzata, in modo
tale da avere differenti modalità di accesso per le varie tipologie di
comunicazione, così da rendere più semplice la programmazione.
13
IPv6 over Low power Wireless Personal Area Networks
15
•
I timer diventano solo di tipo assoluto. E’ stata rimossa la possibilità di
implementare timer relativi. Non è più possibile reimpostare il clock hardware
interno con un valore differente di quello impostato in fase di boot.
2.2 Contiki
Contiki[26] è un sistema operativo open - source, multitasking, nato nel 2002 e giunto
alla versione 2.7. Sa adattarsi ad un vasto numero di piattaforme, che vanno dai
computer a 8 bit ai sistemi embedded e quindi ai microcontrollori. Il kernel di Contiki
è stato sviluppato principalmente da Adam Dunkels al "Networked Embedded Systems
group" dell'Istituto svedese di Informatica. In seguito, hanno preso parte allo sviluppo
di tale sistema operativo anche importanti sviluppatori provenienti da Atmel, Cisco,
ENEA, politecnico di Zurigo, RWTH Aachen University, Oxford University, SAP,
Sensinode, ST Microelectronics, costituendo un’importante community[27].
Contiki è scritto nel linguaggio di programmazione C. La sua occupazione di memoria
RAM è di soli 10 Kbyte, che arrivano a 30 Kbyte nel caso di GIU 14 grafica, e 30
Kbyte di memoria ROM per il codice. Lavora con velocità di elaborazione dell’ordine
dei MHz e una banda di rete dell’ordine di qualche centinaia di Kbit/secondo.
Contiki, offre un kernel che permette di poter allocare dinamicamente i programmi.
Lo scheduling è di tipo non-preemptive, ovvero la CPU viene rilasciata dal processo
solo se quest’ultimo termina oppure si blocca in attesa di un evento. I processi di
Contiki sono costituiti da threads molto snelli, chiamati protothreads, che comunicano
attraverso l’uso di messaggi.
Le caratteristiche offerte da questo sistema operativo, alcune delle quali opzionali,
sono le seguenti: multitasking kernel, application preemptive multithreading, TCP/IP
networking including IPv6, windowing system and GUI, networked remote display,
web browser, personal web server, simple telnet client, screensaver.
14
Grafic User Interface
16
Contiki funziona su un grosso numero di piattaforme: per quanto riguarda i
microcontrollori, gira sui TI MSP430[11], Atmel AVR[34], STMicroelectronics
STM32W, Microchip PIC32, Freescale MC13224, LPC2103, TI CC2430[11], TI
CC2538[11], TI CC2630[11] e CC2650[11].
Contiki è stato utilizzato in svariati contesti reali, implementando sistemi di
illuminazione delle strade, monitoraggio del suono per le città intelligenti, sistemi di
monitoraggio delle radiazioni e sistemi di allarme.[25]
2.3 Nano-RK
Nano-RK[28], è un sistema operativo open-source, real-time della Carnegie Mellon
University, specifico per le reti di sensori senza filo. E’ scritto in C e funziona sulla
piattaforma di nodi sensore FireFly con microcontrollori Atmel[34], e sulla piattaforma
hardware MicaZ con microcontrollore MSP430[11].
Il consumo di memoria di Nano-RK è di soli 2 Kbyte di RAM, mentre sono 18 Kbyte
quelli occupati in memoria FLASH.
Lo scheduler di Nano-RK è a una priorità fissa, full-preemptive, con una serie di
primitive di sincronizzazione per il supporto all’attività real-time. I tasks, fanno
richiesta di risorse e il kernel di Nano-RK garantisce e controlla gli accessi alla CPU
del mote, controllando anche i consumi di ogni operazione, riducendo la frequenza di
trasmissione se quest’ultima è troppo dispendiosa. Nano-RK supporta tecniche di
power-management e provvede direttamente a funzioni di routing, occupandosi
dell’incapsulamento dei pacchetti e della trasmissione [29].
17
Capitolo 3
Modelli di programmazione
Se si vuole sviluppare un’applicazione destinata ai motes delle reti di sensori senza
filo, bisogna riflettere su alcuni requisiti:
•
Risorse hardware limitate: i sistemi embedded, quindi i motes delle reti di
sensori, hanno a disposizione una quantità limitata di risorse, nella loro
progettazione c’è sempre un compromesso tra costi, dimensioni e consumo di
energia. Una prima criticità da considerare nella programmazione è la ridotta
quantità di memoria per il codice da caricare sulla piattaforma. Una seconda, e
non ultima criticità, è quella di mantenere i consumi più bassi possibili se si
desidera che la rete rimanga operativa a lungo senza bisogno di interventi.
•
Affidabilità: come già accennato nel capitolo 1, questo tipo di reti viene
utilizzato per il monitoraggio e il trekking di parametri di vario genere e, in
molti casi, si ha la necessità che la rete di sensori continui a funzionare per
lunghi periodi di tempo senza bisogno di interventi umani.
•
Reattività: le reti di sensori senza filo, nella maggior parte dei casi sono
sistemi real-time. Pertanto nello sviluppo software dei nodi, bisogna sempre
considerare le limitazioni temporali, in modo tale che l’informazione sia
acquisita e trasmessa entro un tempo prefissato.
In questo capitolo verranno trattati nello specifico i modelli di programmazione delle
reti di sensori senza filo, cioè, l’insieme degli strumenti e delle astrazioni concettuali
fornite agli sviluppatori per scrivere il codice sorgente di un programma.
Nell’ambito delle reti wireless, uno dei problemi fondamentali, affrontati nei modelli
di programmazione, è la gestione della concorrenza. Le applicazioni dei motes, sono
fondamentalmente di tipo asincrono: un frame radio, ad esempio, potrebbe presentarsi
18
in qualsiasi momento. Uno dei modi più semplici per la gestione di tali contesti è
quella del polling, ovvero la verifica ciclica di un determinato evento atteso. Tale
modello, però, in alcuni casi utilizza eccessivamente la CPU con il rischio di ritardi
nelle elaborazioni.
Nei paragrafi che seguono vedremo il modello, o paradigma, di programmazione ad
eventi, utilizzato in TinyOS, quello utilizzato per i Waspmote di casa Libelium, infine
dei brevi cenni circa il paradigma di programmazione di Contiki, basato su
protothread. Non verranno trattati, in questa sede, modelli di programmazione più
complessi come il paradigma publish/subscribe.
3.1 Programmazione ad eventi
Il modello di programmazione ad eventi, o event-driven, è un paradigma di
programmazione concettualmente molto semplice: il sistema gestisce un evento,
mediante una fase di polling e le interrupt. Un evento può essere derivante
dall’hardware: sensori, ricezione radio,… Dal software: timer, operazioni effettuate da
applicazioni… Oppure da entrambi.
In questo elaborato prendiamo in esame il paradigma di programmazione ad eventi
associandolo a TinyOS. Come abbiamo visto nel capitolo 2, dalla versione 2.1 in poi,
TinyOS permette anche un modello programmazione a thread, attraverso apposite
librerie. Quest’ultimo paradigma di programmazione, però verrà trattato nel paragrafo
3.3, in Contiki.
In TinyOS, un evento viene gestito da una breve sequenza di istruzioni che compie
solo le attività più elementari e semplici. L'elaborazione effettiva, degli eventuali dati
acquisiti, viene gestita separatamente e disaccoppiata dalla routine dell’evento. Di
conseguenza, questo modello di programmazione basato su eventi crea due diversi
contesti: uno per gli eventi, time-critical, e uno per i normali flussi di istruzioni. C’è
da dire, che nel caso di applicazioni di dimensioni maggiori, i programmatori possono
trovare tale metodologia di programmazione più complicata, rispetto ad un approccio
tradizionale, basato su stack e switching del contesto di esecuzione.
19
Le applicazioni in TinyOS vengono scritte in nesC, linguaggio di programmazione
molto simile al C e adatto per gestire i problemi derivanti dai requisiti stringenti delle
applicazioni su reti di sensori senza filo. Questo linguaggio presenta alcune restrizioni
quali la gestione della memoria statica, l’assenza di puntatori a funzione e di
ricorsione. Al tempo stesso però permette una stesura dei programmi con una
strutturazione a componenti, con un modello di programmazione ad eventi e la cui
concorrenza è basata su task ed eventi.
NesC implementa un sottoinsieme dei costrutti del linguaggio C, allo scopo di
limitarne la potenza espressiva alle sole parti che realmente interessano, definendo
vari nuovi comandi, orientati a strutturare le applicazioni, eliminando la necessita di
usare un linker dinamico a tempo di esecuzione. Questo permette al compilatore, il
NesCC, che si basa sul GCC della GNU, di conoscere esattamente tutti i componenti
in uso in una determinata applicazione, come anche l'occupazione di memoria,
producendo il relativo codice oggetto, linkato staticamente con le sole parti richieste
del kernel, in modo da avere un codice flessibile e modulare, il tutto quanto più
possibile ottimizzato in termini di occupazione di memoria.
Grazie all’architettura modulare di TinyOS, una tipica applicazione può essere
implementata assemblando tra loro vari componenti. Per questo motivo, la
programmazione in TinyOS viene detta anche component-based. In TinyOS, il
programmatore ha l’arduo compito di rendere il codice per la gestione degli eventi,
quanto più semplice e breve possibile, in modo da ridurre al minimo i tempi di
risposta.
L’unità software fondamentale di un programma scritto in TinyOS è il componente.
Solo attraverso le interfacce è possibile accedere ad un componente. L’interfaccia
definisce i comandi e i gestori degli eventi. I comandi definiscono i servizi offerti da
un determinato componente, mentre i gestori degli eventi notificano il verificarsi di un
determinato evento.
Esistono due tipi di componenti: i moduli e quelli di configurazione. I moduli
implementano i comandi e i gestori degli eventi. I componenti di configurazione
invece sono delle unità software che assemblano componenti già esistenti, per crearne
nuovi più complessi.
20
Come supporto per il programmatore, TinyOS include una libreria di componenti
progettati per svolgere le più classiche operazioni sulle reti di sensori senza filo. Per
questo motivo, lo sviluppo di un'applicazione, nei casi più semplici, può consistere nel
solo collegamento dei componenti di libreria necessari. Nei casi più complessi invece,
bisognerà scrivere i componenti aggiuntivi ed i loro collegamenti con il kernel e con le
periferiche.
Vediamo a questo punto alcuni frammenti di codice, utili per comprendere appieno la
programmazione in TinyOS.
3.1.1 La sintassi in TinyOS
NesC per gestire i comandi e gli eventi usa le seguenti parole chiave: command, event,
call, signal, return. Con type, indica il tipo della variabile.
Un comando deve essere associato ad un’interfaccia, la sintassi è la seguente:
command type my_interface.my_command (type variabile,...) {
// Qui si inserisce il codice che costituisce il comando
return(stato);
}
La chiamata di un comando non può avvenire all’interno del componente che lo
implementa, ma deve venire tramite dall'apposita interfaccia:
call my_interface.my_command (variabile,...);
La chiamata in seguito all’esecuzione del codice fornisce lo stato risultante.
Anche un evento deve essere connesso ad un’interfaccia, la sintassi è la seguente:
event type my_interface.my_event (type variabile,...) {
// codice per la gestione dell'evento
return(stato);
}
Come per i comandi, anche la chiamata di eventi deve essere effettuata attraverso
un’apposita interfaccia. Si usa la seguente sintassi:
Signal my_interface.my_event (variabili,...);
21
All'interno di un componente, potrebbe presentarsi la necessità di invocare una
funzione, oppure definire come eseguire una porzione di codice. In questi casi
esistono le funzioni e i task.
Le sintassi per gestire una funzione è la seguente:
type my_function (type variabile) {
// Qui si inserisce il codice della funzione
}
Per chiamare una funzione basta la seguente sintassi:
my_function (variabile,...);
La sintassi per gestire i task è la seguente:
Task void my_task () {
// Codice del task
}
Per fare in modo che il sistema operativo esegua un task prima possibile, si utilizza la
seguente sintassi:
Post my_task ();
3.1.2 Esempio: PowerUP
L’esempio di codice che segue, accende il led della piattaforma dopo la fase di avvio
della stessa. E’ il classico codice utilizzato per testare l’ambiente di sviluppo.
L’applicazione è formata da due moduli: PowerupC che realizza la logica e
PowerupAppC che collega PowerupC con i componenti di TinyOS necessari.
module PowerupC
{
uses interface Boot;
uses interface Leds;
}
22
implementation
{
event void Boot.booted() {
call Leds.led0On();
}
}
Vengono utilizzate le interfacce Boot e Leds:
interface Boot {
event void booted();
//Implementa il gestore degli eventi booted
richiesto da Boot
}
interface Leds {
command void led0On(); //Accende il led 0 invocando il comando
led0On di Leds
command void led0Off();
}
Infine viene assemblata l’applicazione usando i componenti predefiniti MainC e
LedsC:
configuration PowerupAppC{ }
implementation {
components MainC, PowerupC, LedsC;
MainC.Boot <- PowerupC;
// Assemblaggio dei componenti
PowerupC -> LedsC.Leds;
}
TinyOS possiede un sistema di compilazione basato su Makefiles. Nel caso
dell’esempio risulta:
COMPONENT=PowerupAppC
include $(MAKERULES)
Per compilare un programma basta usare il comando:
make <platform>
23
Il risultato della compilazione sarà un file binario che include TinyOS e tutti i
componenti dell’applicazione.
Infine è importante dare alcune note sull’ambiente di sviluppo. Applicazioni per
TinyOS possono essere sviluppate sotto Linux e Windows, attraverso Cygwin[33]. Per
i sistemi Mac OS invece esistono dei port. Tutto il necessario e maggiori chiarimenti
sono presenti sul sito[13]. Inoltre molto interessante e utile per il programmatore è il
tool NesDoc che permette di visualizzare, attraverso un documento ipertestuale, una
rappresentazione grafica dei collegamenti tra i vari componenti e accedere al
componente specifico, così da comprendere le interfacce che offre, le funzioni e le
variabili implementate.
3.2 Waspmote programming model
L'architettura del Waspmote[15] si basa sul microcontrollore Atmel ATMEGA 1281.
Quest’unità di elaborazione, prima di eseguire la prima istruzione del codice
sviluppato dal programmatore, e caricato in memoria, avvia l'esecuzione del
bootloader. Tale fase consiste in una serie di primitive che eseguono operazioni di
inizializzazione, tra cui, caricare in memoria librerie, header file, inizializzare i
registri, periferiche.., in modo da permettere l'esecuzione del programma caricato in
memoria.
La fase di bootloader dura circa 62.5ms, se un nuovo programma da eseguire viene
inviato in memoria durante questo intervallo di tempo, verrà eseguito, sostituendosi al
codice presente in precedenza.
I programmi per Waspmote vengono scritti in C, seguono un paradigma di
programmazione ad eventi, o event-driver, estremamente semplificato rispetto a
quello utilizzato in TinyOS. Infatti, esiste un’unica funzione, che attraverso un loop
gestisce gli eventi; non ci sono altri event hendlers e dispatcher e non esiste una vera e
propria coda degli eventi.
Il codice di un programma per Waspmote si suddivide in due parti, o procedure:
setup( ) e loop( ). L’esecuzione è di tipo sequenziale all’interno di queste funzioni.
24
Nel file “.pde”, estensione di un programma per Waspmote, setup( ), ha lo scopo di
configurare la piattaforma hardware. Il suo codice viene eseguito solo una volta dopo
la fase di bootloader (e ogni volta che il Waspmote viene resettato). In questa
procedura vengono inizializzati i moduli del Waspmote che si vogliono utilizzare.
Terminata la parte di setup( ), viene eseguita la seconda parte del programma, che
consiste in un ciclo infinito loop( ). Nella seconda parte del codice del programma,
vengono effettuate le operazioni di misura, l’invio delle informazioni, vengono gestite
eventuali
interruzioni
ed
infine,
per
il
risparmio
energetico,
lo
stato
attivo/sleep/hibernate del Waspmote.
Uno schema generale di codice per Waspmote è il seguente[15]:
// 1. Include Libraries
// 2. Definitions
// 3. Global variables declaration
void setup( ) {
// 4. Modules initialization
}
void loop( ) {
// 5. Measure
// 6. Send information
// (7. Routine of interrupt)
// 8. Set sleep mode
}
Una tecnica di programmazione comune per il risparmio energetico è quella basata sul
blocco dell’esecuzione del programma, mandando il dispositivo in sleep mode oppure
in hibernate mode, fino a quando non si verifica un determinato evento. Attraverso le
interruzioni e, assegnando ad esempio un flag ad un particolare evento, si possono
ottenere notevoli risparmi energetici. Quando Waspmote viene ripristinato,
l’esecuzione ricomincia a partire dalla funzione loop ( ).
25
La programmazione può essere effettuata in locale, attraverso un collegamento al PC
via USB o seriale, oppure tramite OTAP 15. Quest’ultimo metodo di programmazione,
con i nuovi concetti di reti di sensori wireless, può risultare fondamentale. Da qualche
anno l’OTAP si può effettuare, oltre che attraverso le tecnologie di telefonia mobile
come 3G e GPRS, anche attraverso protocolli come: WiFi/FTP e 802.15.4/ ZigBee.
Nella programmazione dei Waspmote, suddivisa in parti, presentata in precedenza, si
concentra tutta la filosofia di sviluppo delle applicazioni per questi motes. L’idea che
c’è alla base è di non cercare di scrivere codici, abilitando tutte le funzionalità fin
dall'inizio, ma sfruttare il motto "Keep it simple!". In poche parole rendere i codici più
semplici possibili, attraverso l’utilizzo solo delle funzionalità strettamente utili.
Qualsiasi sia il progetto da sviluppare, la suddivisione del codice in parti, permette
allo sviluppatore, passo dopo passo di arricchire sempre più il programma, scegliendo
quali funzionalità sono necessarie e quali no. In questo modo, anche la fase di test
dell’applicazione scritta, risulterà più semplice.
3.2.1 Ambiente di sviluppo
Libelium fornisce librerie API, compilatore e numerosi strumenti come un IDE opensource, in modo tale da rendere la programmazione dei motes molto semplice.
Waspmote Pro IDE è l’ambiente di sviluppo integrato (IDE) per i Waspmote di casa
Libelium. Il Waspmote Pro IDE deriva dall’IDE di Arduino, ha infatti le stesse
caratteristiche e funzionalità e una veste grafica molto simile. Come tutti gli IDE,
possiede tutta una serie di funzionalità: permettere la stesura del codice sorgente,
attraverso un editor di testo dotato di alcune particolarità, come il syntax highlighting,
il controllo delle parentesi, e l'indentazione automatica. E’ in grado di compilare,
caricare il codice eseguibile all’interno del Waspmote, visualizzare i risultati frutto del
programma sviluppato, monitorare l’uscita seriale ed effettuare il debug del codice.
15
Over The Air Programming
26
3.2.2 Esempio: lettura dall’accelerometro
Il seguente esempio mostra il codice dell’applicazione che permette di effettuare le
letture dei valori dall’accelerometro triassiale presente on-board.
void setup()
{
ACC.ON();
// Attivazione l’accelerometro
USB.ON();
// Attivazione della comunicazione USB
USB.println(F("Lettura Accelerazioni"));
}
void loop()
{
//
Controllo
per
verificare
il
corretto
funzionamento
dell’accelerometro
// in caso di esito positivo deve restituire 0x32 come valore
byte check = ACC.check();
//Lettura del valore lungo l’asse x
int x_acc = ACC.getX();
//Lettura del valore lungo l’asse y
int y_acc = ACC.getY();
//Lettura del valore lungo l’asse z
int z_acc = ACC.getZ();
USB.print(F("\n------------------------------\nCheck: 0x"));
USB.println(check, HEX);
//Stampa del registro
USB.println(F("\n \t0X\t0Y\t0Z"));
//per il check
USB.print(F(" ACC\t"));
USB.print(x_acc, DEC);
//Stampa in decimale (OUTPUT)
USB.print(F("\t"));
// per ogni asse
USB.print(y_acc, DEC);
USB.print(F("\t"));
USB.println(z_acc, DEC);
delay(1000);
}
Esempio di output:
Lettura Accelerazioni
----------------------------Check: 0x32
0X 0Y 0Z
ACC -14 4
988
27
3.3 La programmazione in Contiki
Un altro modello di programmazione, sicuramente più articolato di quello dei
Waspmote, è quello basato sui protothread[30] in Contiki.
Inizialmente i modelli di programmazione thread-driven, sono stati messi da parte
nello sviluppo di applicazioni su reti di sensori senza filo, a causa delle risorse
estremamente limitate delle piattaforme hardware esistenti in passato. In seguito però
questa scelta è stata contestata e sono state sviluppate, non solo in Contiki, ma anche
in LiteOS[31], Mentis[32], applicazioni basate su tale modello di programmazione.
Un protothread è un'astrazione che permette una programmazione efficiente per la
memoria e più semplice per il programmatore, il quale è in grado di ragionare più
facilmente sull’esecuzione sequenziale dei programmi.
Come già trattato nel paragrafo 2.2, Contiki presenta un kernel ad eventi, sul quale le
applicazioni, scritte nel linguaggio di programmazione C, vengono caricate e scaricate
dinamicamente a run-time. La CPU del dispositivo viene rilasciata dal processo solo
quando termina o si blocca in attesa di un evento.
Il vantaggio principale dei protothread è il loro basso overhead sul sistema. Essi non
hanno uno stack, bensì lavorano su variabili globali, in questo modo occupano
pochissimo spazio in memoria e non sovraccaricano la CPU del mote con le
operazioni di context-switch. In risposta a un evento interno o esterno, il kernel
richiama il thread “leggero” associato al particolare evento del processo in esecuzione.
In questo modo è garantita la risposta in tempo reale del sistema. Esempi di eventi
interni possono essere i timer. Eventi esterni sono i sensori che raccolgono dati oppure
i pacchetti in arrivo da motes vicini.
Esistono diverse primitive utilizzate per la programmazione di applicazioni in Contiki,
primitive per la gestione dei processi, protothread, timer, connessioni e
multithreading. Per brevità, riporterò solo alcune primitive circa i protothread,
rimandando il lettore alla documentazione ufficiale per le ulteriori primitive [26].
28
PT_INIT(pt)
//Inizializza un protothread.
PT_THREAD(name_args)
// Utilizzata per dichiarare un protothread
PT_BEGIN(pt)
// Inizio/Fine del corpo di un protothread
/
PT_END(pt)
PT_WAIT_UNTIL(pt, condition)
//Blocca l'esecuzione del protothread
PT_WAIT_THREAD(pt, thread)
//Blocca l'esecuzione del protothread in
attesa della conclusione del thread indicato come parametro.
PT_RESTART(pt)
// Blocca l'esecuzione del protothread e lo reinizializza
PT_EXIT(pt)
// Termina l'esecuzione di un protothread.
PT_SCHEDULE(f)
// Invoca l'esecuzione del thread passato come parametro
PT_YIELD(pt)
// Sospende l'esecuzione dando modo ad altri di eseguire
PT_YIELD_UNTIL(pt, cond)//Sospende
fino a quando la condizione non diviene vera
3.3.1 Struttura base di un programma
Un'applicazione in Contiki si sviluppa definendo anzitutto un processo. La struttura
base di un programma è la seguente:
#include "contiki.h"
//Deve essere incluso
#include "process.h"
PROCESS(Esempio, "Esempio di processo");
AUTOSTART_PROCESSES(&Esempio);
// Definizione del processo
// Avvio
PROCESS_THREAD(Esempio, ev, data)
{
PROCESS_BEGIN( );
// Inizio del processo
while(1){
PROCESS_WAIT_EVENT ( );
// Si attende l’evento
// Quì si scrive l’applicazione
}
PROCESS_END( );
}
Infine il Makefile, si definisce attraverso la seguente sintassi:
CONTIKI = ../..
// In base alla posizione del progetto
all: app-name
include $(CONTIKI)/Makefile.include
29
Conclusioni
Il lavoro di analisi svolto per questo elaborato mette in evidenzia che, dal punto di
vista hardware, l'evoluzione tecnologica consentirà lo sviluppo di microcontrollori
sempre più piccoli, efficienti e performanti, come si è potuto notare osservando le
piattaforme presentate nel capitolo 1, in particolare il Lotus Cortex e il Waspmote.
Da una prospettiva software, l’estrema semplicità della programmazione delle nuove
piattaforme per reti di sensori senza filo, abbiamo visto in particolare i Waspmote, il
gran numero di librerie API, tool di sviluppo, nella maggior parte dei casi opensource, le comunità di supporto, costituite da accademici, professionisti e semplici
appassionati, i sistemi operativi, sempre più ricchi di funzionalità, permettono una
stesura dei programmi applicativi semplificata, efficace e sempre più innovativa, con
la conseguente possibilità di utilizzare tale tecnologia, in numero crescente di contesti
reali.
E’ facile immaginare che in un prossimo futuro sarà necessaria l'adozione di nuovi
standard e tecniche di programmazione per sviluppare applicazioni sempre più
complete e sofisticate, per gestire meglio la comunicazione tra sensori e sviluppare
sistemi di service discovery, per creare interazioni tra nodi appartenenti a reti diverse,
in modo da implementare impianti costituiti da più reti di sensori senza filo che
lavorano insieme.
30
Bibliografia
[1]
http://robotics.eecs.berkeley.edu/~pister/SmartDust/
[2]
C. Buratti, A. Conti, D. Dardari, and R. Verdone, “An overview on wireless sensor networks
technology and evolution,” Sensors, vol. 9, no. 9, pp. 6869–6896, 2009. [Online]. Available:
http://www.mdpi.com/1424-8220/9/9/6869
[3]
http://www.ece.cmu.edu/firefly/
[4]
http://www.zigbee.org/
[5]
A. Kansal and M.B. Srivastava, “An Environmental Energy Harvesting Framework for Sensor
Networks”. In Proceedings of the International Symposium on Low Power Electronics and
Design (ISLPED), Seoul, Korea, August 2003.
[6]
Crossbow Technology Inc. web site, http://www.moog-crossbow.com/
[7]
Moteiv Corporation web site, http://www.moteiv.com.
[8]
“RealTime Wireless Sensor Network Platforms”, 2007, http://www.ece.cmu.edu/firefly/
[9]
“BTnodes A Distributed Environment for Prototyping Ad Hoc Networks”,
http://www.btnode.ethz.ch/
2007,
[10] Memsic web site: http://www.memsic.com/wireless-sensor-networks/
[11] http://www.ti.com/
[12] http://www.arm.com/
[13] http://www.tinyos.net/
[14] http://www.zurich.ibm.com/moterunner/
[15] http://www.libelium.com
[16] Riccardo Crepaldi. “Algoritmi di localizzazione per reti di sensori: progettazione e realizzazione
di una piattaforma sperimentale”. PhD thesis, Università degli Studi di Padova Dipartimento di
Ingegneria dell’Informazione, 2006.
[17] A. Bonivento, C. Fischione, A. Sangiovanni-Vincentelli, F. Graziosi, and F. Santucci. Seran: “A
semi random protocol solution for clustered wireless sensor networks”. In Proc. of MASS,
Washington D.C., November 2005.
[18] D. Culler, D. Estrin, and M. Srivastava. “Overview of sensor networks”. IEEE Computer,
37(8):41_49, August 2004.
[19] D. Snoonian. Smart buildings. IEEE Spectrum, pages 18_23, 2003.
31
[20] Jennifer Yick, Biswanath Mukherjee, Dipak Ghosal . “Wireless sensor network survey”
Department of Computer Science, University of California, Davis, CA 95616, United States.
April 2008. Computer Networks 52 (2008) 2292–2330www.elsevier.com/locate/comnet
[21] D. Gay, P. Levis, D. Culler “Software Design Patterns for TinyOS”, reperibile su
www.tinyOS.net.
[22] D. Gay, P. Levis, D. Culler and other “The nesC Language: A Holistic Approach to Networked
Embedded Systems”, sito www.tinyOS.net
[23] A. Zanella, M.Zorzi “Reti di sensori: dalla teoria alla pratica”, Notiziario Tecnico Telecom
Italia, Anno 15 n. 1 Giugno 2006.
[24] D. Gay, P. Levis, R. von Behren, M.Welsh, E. Brewer, and D. Culler. “The nesC language: A
holistic approach to networked embedded systems”. In Proceedings of Programming Language
Design and Implementation (PLDI). 2003.
[25] Adam Dunkels, Bj Granvall, and Thiemo Voigt. “Contiki - a lightweight and flexible operating
system for tiny networked sensors”. Local Computer Networks, Annual IEEE Conference on.
2004.
[26] Contiki OS. http://www.contiki-os.org/
[27] Contiki Community. http://www.contiki-os.org/community.html
[28] Nano-RK OS. www.nanork.org
[29]
A. Eswaran, A. Rowe and R. Rajkumar, "Nano-RK: An Energy-Aware Resource-Centric
Operating System for Sensor Networks," IEEE Real-Time Systems Symposium, December 2005.
[30] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali, “Protothreads: Simplifying Event-Driven
Programming of Memory-Constrained Embedded Systems”, Proc. ACM SenSys, Boulder, CO,
USA, Nov 2006.
[31] Cao, Q., Abdelzaher, T., Stankovic, J., He, T.: “The LiteOS Operating System: Towards UnixLike
Abstractions for Wireless Sensor Networks”. Proceedings of the International Conference on
Information Processing in Sensor Networks (IPSN) pp. 233–244 (2008)
[32] Bhatti, S., Carlson, J., Dai, H., Deng, J., Rose, J., Sheth, A., Shucker, B., Gruenwald, C.,
Torgerson, A., Han, R.: MANTIS OS : “An Embedded Multithreaded Operating System for
Wireless Micro Sensor Platforms”. In: ACM/Kluwer Mobile Networks & Applications
(MONET), Special Issue on Wireless Sensor Networks, August. Secaucus, NJ, USA (2005)
[33] Cywin web site: https://www.cygwin.com
[34] Atmel web site: www.atmel.com
32