Capitolo 2: Presentazione dello
scenario di lavoro
Il sistema sviluppato consta dei seguenti componenti: software TinyOS, programmatore MIB600, mote Mica2, sensori MTS300, scheda di acquisizione MDA300 e software LabVIEW.
Andiamo a presentarli uno per uno.
Software TinyOS
Si tratta di un sistema operativo open-source che permette di creare il codice che poi andrà ad essere istallato sui moduli Mica2. Il linguaggio utilizzato è il nesC [2], un linguaggio con sintassi simile a quella del C, ma più leggero visto che i moduli Mica2 presentano memoria limitata. Il progetto TinyOS è stato creato proprio in base alle caratteristiche delle reti di sensori: dimensioni fisiche ridotte, bassi consumi, flussi multipli di dati, gerarchie di controllo e operazioni robuste per rendere più semplice lo sviluppo di applicazioni affidabili. Il modello a livelli è quello di Figura 2.
Il codice di programmazione ha una struttura modulare, che segue il funzionamento di una macchina a stati: ogni applicazione consiste di uno o più componenti collegati insieme in modo da poter essere mandati in esecuzione.
Ci sono due tipi di componenti: i moduli e le configurazioni. I moduli forniscono il codice effettivo dell’applicazione, implementando una o più interfacce. Le configurazioni invece si occupano di assemblare tutti i componenti insieme, collegando le interfacce usate da alcuni componenti a quelle fornite dagli altri (wiring). Se il nome dell’applicazione è Misure, la configurazione avrà il nome Misure.nc mentre il modulo MisureM.nc.
In TinyOS si esegue un solo programma che contiene solo i componenti necessari all’esecuzione dell’applicazione desiderata.
La struttura di un componente è formata da: command handler (gestore dei comandi), event handler (gestore degli eventi), set of
tasks (insieme di tutte le elaborazioni) e frame (contenente delle
informazioni di stato).
Ogni componente usa e fornisce delle interfacce bidirezionali, che sono l’unico punto d’accesso e di uscita per tutti gli altri componenti. Ogni interfaccia modella alcune funzioni; ad esempio il componente TimerM fornisce le interfacce StdControl e Timer e usa l’interfaccia Clock:
Module TimerM { provides {
interface StdControl; interface Timer; }
uses interface Clock; } ...
Ogni interfaccia contiene comandi ed eventi: le interfacce fornite implementano i “comandi”, quelle usate gli “eventi”. Andiamo a vedere, a titolo di esempio, come sono implementati comandi ed eventi nelle interfacce fornite ed usate dal componente TimerM:
Figura 3. Schema delle interfacce del componente TimerM
interface StdControl{
command result_t init(); }
interface Timer {
command result_t start(char type, uint32_t interval);
command result_t stop(); event result_ t fired(); }
interface Clock{
command result_t setRate(char interval, char scale);
command result_t fired(); }
Come si vede dal codice, l’interfaccia Timer presenta due comandi (start e stop) e l’evento fired (soglia superata); in Figura 3 i comandi sono rappresentati con una freccia nera rivolta verso il basso e gli eventi con una bianca verso l’alto. Cosa analoga avviene per le altre interfacce del componente TimerM.
Dalla figura si potrebbe però fare un po’ di confusione con le frecce. La struttura del codice è gerarchica; quindi ogni componente fornisce delle interfacce che gli permettono di ricevere i comandi dai componenti di livello superiore e usa delle interfacce, collegate, a loro volta, a componenti gerarchicamente inferiore, con cui può inoltrare dei comandi ai livelli sottostanti. La direzione delle frecce è stata adottata proprio per sottolineare questa organizzazione a livelli, dove in cima abbiamo il componente che implementa la nostra applicazione e man mano che si scende abbiamo quelli necessari al suo corretto funzionamento. All’interno di ogni componente, il command handler si occupa di tutte le istanze relative ai comandi (sia in ingresso che in uscita) mentre gli event handler di quelle degli
eventi. Quindi i componenti di livello più alto, attraverso i propri gestori dei comandi, inviano dei “comandi” a quelli di livello inferiore, che li ricevono con i propri command handler; come riscontro che il comando ha avuto successo i componenti di livello inferiore inviano un “evento”, tramite i loro gestori degli eventi, che viene ricevuto dall’event handler di livello superiore.
Per dare idea di come sia fatta la struttura a livelli di un’applicazione si mostra in Figura 4 il caso del componente di configurazione Surge, un’applicazione di libreria che implementa la lettura del sensore di luce e il protocollo di routing multihop.
Figura 4. Schema della struttura a livelli dell’applicazione Surge
Per gestire tutte le operazioni, si utilizza uno scheduler a due livelli: “task” e “hardware event handlers”. Se un comando o un evento è preceduto dalla keyword async vuol dire che questo deve essere eseguito da un hardware event handler, altrimenti si manda in esecuzione via task. Di solito i task si utilizzano per operazioni che richiedono più tempo per essere eseguite. Per definire un task si usa la seguente sintassi:
task void taskname () {…}
per mandarlo in esecuzione in un secondo momento si usa invece il comando post:
post taskname();
Un task può essere mandato in esecuzione all’interno di un evento, di un comando o di un altro task. Nel momento in cui esso viene lanciato, il task viene inserito nella coda di task dello scheduler, che segue una disciplina FIFO. Una volta che un task viene mandato in esecuzione giunge fino in fondo all’elaborazione, però potrebbe anche essere interrotto da un hardware event handler, che presenta priorità più alta.
Un’altro elemento architetturale del TinyOS che merita la nostra attenzione è lo stack radio [3] per i motes Mica2. Lo schema utilizzato è quello di Figura 5; oltre alla presentazione dello schema, andiamo ad analizzare sia la fase di invio che di ricezione di un messaggio.
Figura 5. Struttura dello stack radio dei motes Mica2
Generic Comm si occupa del multiplexing dei dati per le varie applicazioni e mezzi di trasporto (radio e UART).
AM (Active Message) [4] si occupa della comunicazione e dell’elaborazione dei pacchetti, del collegamento tra le primitive di comunicazione e le funzionalità hardware e di fornire un modello ad eventi distribuiti, che permetta ai nodi di spedire gli eventi l’uno all’altro. Tutti in messaggi contengono un identificativo di gestore, definito dall’utente, (AM type), cioè un identificativo del tipo di
pacchetto, che permette di individuare l’handler che deve gestire il messaggio. Per evitare la congestione della rete, appena arriva un messaggio, si va ad individuare l’AM type e si richiama subito il relativo handler. In TinyOS questo schema viene implementato attraverso il Tiny Active Message che presenta tre compiti di base: trasmissione best effort dei messaggi, indirizzamento, e selezione del gestore appropriato (“dispatch”).
CC1000RadioC è il transceiver. Per i nodi mica2 si utilizza il modello ChipCon CC1000 [5]. Le caratteristiche sono: frequenza impostabile nella regione 300-1000 MHz; modulazione FSK con codifica Manchester; potenza di trasmissione regolabile. Come si può vedere dalla Figura 5 esso segue la logica modulare TinyOS, infatti presenta delle interfacce collegate a due componenti: il CC1000Control e il CC1000RadioIntM; il primo si occupa delle funzioni di gestione, come l’impostazione della frequenza e della potenza di trasmissione, la scelta tra l’operazione di trasmissione o di quella di ricezione, la lettura sui pin I/O speciali; il secondo invece, usando lo schema CSMA/CA, si occupa di trasmettere e ricevere i dati.
Nella fase di trasmissione, nei livelli Generic Comm ed AM, si realizza l’header del pacchetto di tipo TOSMsg, cioè si inseriscono l’ indirizzo del nodo sorgente, l’AM ID (cioè il tipo del pacchetto) e l’indirizzo destinatario; si fa un controllo per evitare le collisioni
(CSMA), quindi si trasmette il messaggio sulla porta SPI (il pacchetto che si invia a tale porta è costituito da 18 byte di preambolo + il frame per il sincronismo + il TOSMsg di al massimo 34 byte + 2 byte di CRC); una volta portato a termine l’invio dei dati si spegne il trasmettitore e si invia all’applicazione un evento di
SendDone().
La fase di ricezione si innesca nel momento in cui arrivano dei byte sulla porta SPI; si cerca il preambolo e la parola di sincronismo; quindi si ottiene il TOSMsg, su cui si fa un controllo (CRC), se il pacchetto è corretto si inoltra al gestore dell’AM indicato, altrimenti lo si scarta; si controlla il group ID (se non si ha una corrispondenza si scarta il pacchetto), quindi si invia all’applicazione un evento
ReceiveMsg().
Software LabVIEW
Si tratta di un programma per lo sviluppo di applicativi, realizzato dalla National Instruments. La versione da noi utilizzata è la 8.2. Tramite questo software abbiamo realizzato l’interfaccia che ci permette di analizzare e graficare i dati provenienti dalla rete di sensori. A differenza della maggior parte dei programmi per PC, non si basa sui comuni linguaggi di programmazione come il C o il
Pascal, ma utilizza un linguaggio grafico, detto G. La scelta è ricaduta su questo linguaggio perchè non necessita di una sintassi specifica per l’applicazione che si intende realizzare, ma tramite dei componenti, rappresentati da icone, e diagrammi a blocco rende possibile la realizzazione di un qualunque eseguibile. Il programmatore si trova a lavorare in modo intuitivo e viene aiutato da numerose librerie (toolkit) ed esempi di applicazioni funzionanti.
I file che vengono realizzati con LabVIEW vengono chiamati “Virtual Instrument” (VI) e presentano estensione .vi (ad esempio
file.vi).
Ogni programma consta di tre parti.
Il front pannel è l’interfaccia utente, cioè il punto di interazione tra macchina e utente.
Su di esso si possono trovare due tipi di elementi: gli ingressi, detti “controlli” e le uscite, dette “indicatori”. I controlli sono utilizzati per permettere all’utente di regolare alcuni parametri dell’esecuzione del programma (di solito si utilizzano manopole, bottoni, interruttori), mentre gli indicatori sono gli elementi che permettono di mostrare i dati ottenuti all’utente (ad esempio grafici, istogrammi).
Ad ogni front pannel corrisponde un block diagram, l’elemento che si occupa di collegare i vari blocchi utilizzati nell’applicazione.
Nell’ambito del linguaggio G, può essere considerato come l’equivalente del codice sorgente per i linguaggi classici.
L’ultimo elemento da considerare è l’icona. Infatti un VI può essere richiamato all’interno di un altro, prendendo il nome di subVI all’interno della gerarchia dell’applicazione. Dall’icona è possibile settare i connettori per permettere al subVI di ricevere dati dall’esterno.
Componenti Hardaware
La rete di sensori è stata realizzata utilizzando il kit di sensori di sviluppo fornito dalla Crossbow. Andiamo a fare una panoramica sui vari componenti utilizzati.
Programmatore MIB600. Il programmatore MIB600 [6] è lo
strumento utilizzato per programmare i moduli mica2. Viene alimentato tramite un alimentatore esterno con tensione di 5V in continua; utilizza un processore compatibile con UISP STK500; presenta una porta ethernet e il connettore a 51 pin.
Il codice viene prima scaricato sul programmatore, attraverso la porta ethernet, e poi questo si occupa di istallarlo sul nodo collegato al connettore a 51 pins.
In più sono presenti tre LED (rosso, giallo e verde) che coincidono con gli indicatori del mote applicato sul programmatore; in più il LED rosso ha anche la funzione di controllo della porta ethernet del programmatore, ad esempio si accende in fase di programmazione; quello verde è legato allo stato dell’alimentazione.
Oltre ad essere utilizzato per istallare le applicazioni sui moduli, il programmatore viene usato come gateway per la nostra rete. Infatti posizionando i mote nel luogo da monitorare e lasciandone invece un altro collegato al connettore a 51 pins del programmatore, esso non fa altro che essere il punto di tramite tra la rete di sensori e il PC, cui è collegato il programmatore, inoltrando tutti i dati che riceve sul canale radio verso la porta ethernet.
La particolarità del programmatore MIB600 rispetto agli altri sta nel fatto che presenta la porta ethernet e quindi è accessibile da remoto, una volta che gli sia stato assegnato un indirizzo pubblico. Questo è proprio quello che viene richiesto alle reti di sensori: permettere ad un utente di effettuare il monitoraggio senza recarsi in loco, ma stando davanti al proprio PC.
Moduli mica2. Sono l’elemento principale della Sensor Network. Ogni Mica2 [7] è dotato di un processore Atmel ATmega 128L, di una memoria flash a 128K bytes; un’antenna e un connettore a 51 pin che permette la connessione al programmatore o al sensore che andrà ad effettuare le misurazioni.. Sono anche presenti tre LED (rosso, giallo e verde) come indicatoti dei dati e della funzionalità del mote e uno switch On/Off per l’accensione e lo spegnimento.
Figura 7. Mote mica2
Sensorboard MTS300. Si tratta della sensorboard di base fornita dalla Crossbow [8], che permette di aggiungere al mote alcuni sensori. Essa, oltre al connettore a 51 pins per essere collegata al mote, presenta i sensori di:
temperatura, il termistore della Panasonic, modello ERT-J1VR103J;
microfono, che presenta due funzioni principali: la prima è effettuare il ranging acustico (cioè la possibilità di misurare la distanza tra due nodi) e la seconda consiste nel permettere la misurazione e la registrazione acustica ;
sounder (o buzzer), un risonatore piezoelettrico alla frequenza fissa di 4 KHz.
Esiste anche una versione migliore di questi sensori, il MTS310, che, oltre ai suddetti sensori, permette di calcolare anche le vibrazioni (accelerometro), e il campo magnetico (magnetometro).
Figura 8. Sensorboard MTS300
Sensorboard MDA300. Ideata come una piattaforma per misurazioni generiche, si tratta di una scheda di acquisizione per segnali analogici e digitali [9].
Figura 9. Scheda d’acquisizione MDA300
Essa presenta (vedi anche Figura 10)
sette canali analogici singoli (A0-A6) a 12 bit con range da 0 a 2,5V e precisione fino a 0,6mV;
tre canali differenziali analogici (A11-A13) a 12 bit, con range da 0 a 2,5V e precisione fino a 0,6mV;
quattro canali differenziali analogici ad alta precisione (A7A10) sempre a 12 bit, però presentano: alto guadagno, range da -12,5mV a -12,5mV e precisione fino a 6µV;
sei canali digitali (D0-D5), usati sia come input che output, il loro risultato può essere salvato nella memoria EEPROM;
un canale counter, dedicato per conteggio ad alta velocità e misure di frequenza;
canali interni, la scheda MDA300 è già fornita con due sensori di temperatura e umidità;
due canali relay, che permettono di attuare fenomeni esterni, di solito non sono mai entrambi attivi, quindi se uno è acceso l’altro è spento;
tre eccitazioni per i sensori esterni, cioè 2,5V 3V e 5V; tre LED con le stesse funzioni di quelli degli MTS300.
