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

III

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

4

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

5

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].

6

• 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 life-

time 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.

7

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

8

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

9

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

10

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 Da 50mA a 10μA in sleep mode

7 Real-Time Operating System

11

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

12

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.

13

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 nesC9[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”

9 Network embedded system C

10 Introdotti dalla versione 2.1 (TOSThreads architecture)

14

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 FIFO11

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

First-in-first-out 12

Un task non può interrompere un altro task.

15

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

16

• 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 GIU14

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

17

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].

18

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

19

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.

20

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.

21

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,...);

22

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;

}

23

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>

24

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.

25

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 ( ).

26

La programmazione può essere effettuata in locale, attraverso un collegamento al PC

via USB o seriale, oppure tramite OTAP15

. 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 open-

source, 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

27

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

28

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].

29

PT_INIT(pt) //Inizializza un protothread.

PT_THREAD(name_args) // Utilizzata per dichiarare un protothread

PT_BEGIN(pt) / PT_END(pt) // Inizio/Fine del corpo di un protothread

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"); // Definizione del processo AUTOSTART_PROCESSES(&Esempio); // 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

30

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 open-

source, 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.

31

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”, 2007,

http://www.btnode.ethz.ch/

[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.

32

[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