Implementazione di meccanismi real-time su sistemi distribuiti data-centrici realizzati con tecnologie di reti di sensori wireless

Transcript

1 Università Politecnica delle Marche Facoltà di Ingegneria Laurea Specialistica in Ingegneria Informatica Implementazione di meccanismi real-time su sistemi distribuiti data-centrici realizzati con tecnologie di reti di sensori wireless Relatore: Prof. Aldo Franco DRAGONI Candidato: Daniele ALESSANDRELLI Correlatore: Dr. Paolo PAGANO A.A

2 ii Ai miei genitori

3 Prefazione Le Wireless Sensor Network (WSN) vengono utilizzate per il monitoraggio di ampie superfici laddove risulta complesso il provisioning di connessione di rete e alimentazione elettrica. È interessante astrarre le WSN come basi di dati per permettere il recupero delle misurazioni ottenute dai sensori effettuando operazioni di selezione (filtering) ed aggregazione dei dati. In questo senso è utile codificare uno strato intermedio di software (middleware) che permette di operare la WSN (cfr. figura 1) come un entità singola attraverso l esportazione di un numero finito di punti di servizio (Service Access Point). Figura 1: Una WSN usata per il monitoring di ampie superfici Rispetto allo stato dell arte in questo settore (p.e. TinyDB, Matè) si è implementato un Software che, mantenendo le funzionalità dei middleware sopra citati, ne estende le caratteristiche garantendo vincoli real-time sulle transazioni. Ciò si è reso possibile per il supporto real-time fornito a livello di sistema operativo da ERIKA iii

4 (sviluppato dal Retis laboratory della Scuola Superiore Sant Anna di Pisa e distribuito dalla spin-off company Evidence s.r.l.) e a livello di stack di comunicazione in R/F da µwireless, un package compliant con lo standard IEEE che ne implementa, fra le altre, le funzionalità di allocazione di banda. In questa tesi, dopo aver fornito un quadro di riferimento per gli obiettivi, espressi attraverso una lista di requisiti per il software, si parlerà dell architettura del middleware data-centrico MIRTES, della sua implementazione e della sua validazione sperimentale. iv

5 Indice 1 Introduzione Wireless Sensor Network Scenari di applicazione Requisiti tipici Middleware per WSN IEEE e LR-WPAN Ruoli e tipi di dispositivi Topologie di rete Architettura di IEEE Modalità di funzionamento Sistema Embedded Sistema Real-Time Specifica dei requisiti Descrizione generale del sistema Requisiti funzionali Query semplici Query di aggregazione Query con restrizioni Query snapshot e query periodiche Requisiti non funzionali Supporto al real-time Trasparenza e Data-centrismo In-network processing Adattabilità alla specifica applicazione Efficienza energetica Robustezza Estensibilità Supporto multipiattaforma Scalabilità v

6 Eterogeneità hardware Vincoli sull implementazione Ambiente di Sviluppo Piattaforma Hardware FLEX embedded board Microcontrollore dspic33fj256mc Piattaforma Software Supporto Microchip ERIKA Enterprise µwireless Strumenti di debugging Chipcon CC2420 Packet Sniffer Progettazione del sistema Definizione del problema Architettura del sistema Livello di interfaccia Livello di controllo Livello di sensing Mappatura delle funzionalità sui componenti hardware Definizione delle strutture dati Strutture dati relative al DataBase Strutture dati relative alle query Definizione delle componenti software Componenti del client PC Componenti del coordinator Componenti dei device Implementazione Implementazione del client PC Implementazione del software per coordinator e device Implementazione dei componenti software del coordinator Implementazione dei componenti software dei device Implementazione delle strutture dati su coordinator e device Risultati sperimentali Motivazione Installazione sperimentale Hardware setup Software setup vi

7 6.3 Acquisizione dati Il framework Scilab/Scicos Il framework ROOT Attività sperimentale Esperimento di monitoring Analisi delle funzioni di aggregazione Analisi delle caratteristiche real-time Conclusioni 68 Bibliografia 69 Ringraziamenti 72 vii

8 Elenco delle figure 1 Una WSN usata per il monitoring di ampie superfici iii 1.1 Topologie a Stella e Peer-to-Peer (Mesh e Cluster-Tree) Lo stack di IEEE Struttura del superframe in una PAN beacon-enabled Rigidità dei vincoli temporali in relazione alla criticità dell applicazione Struttura generale del sistema Architettura Modulare della FLEX board FLEX Base Boards FLEX Demo Board schema generale del dspic 33 DSC Architettura di ERIKA RTOS Screenshot del framework Eclipse con il plugin RT-Druid Architettura stratificata del sistema di comunicazione µwireless compliant con lo standard IEEE basato su Erika La board Texas Instruments CC2420 EB con l estensione CC2420EM Interfaccia del Chipcon CC2420 Packer Sniffer Ruolo dei componenti hardware in MIRTES Esempio di diffusione della richiesta e raccolta dei risultati Architettura a tre livelli del sistema Mappatura delle funzionalità sui componenti hardware Strutture dati relative al concetto di database Strutture dati relative al concetto di interrogazione e loro relazioni con le altre strutture dati Componenti software del client PC Componenti software del coordinator Componenti software del device Output del client jmirtes (eseguito direttamente dall IDE Eclipse). 51 viii

9 5.2 Implementazione della classe Column Implementazione dell interfaccia ICondition Il set-up sperimentale usato per la validazione del middleware MIRTES Il modello a blocchi per il monitoring in Scicos Esempio di andamento temporale delle tre componenti dell accelerazione sui device 3, 5, 7 e Lo scenario sperimentale usato per la misura degli aggregati Andamento del costo elettromagnetico in funzione del valore di soglia THR Andamento della luminosità media in funzione del valore di soglia THR Andamento della latenza di transazione in funzione del tempo in assenza di Admission Control Andamento della latenza di transazione in funzione del tempo. Sovrapposta alla figura il numero di query aperiodiche accodate e completate nell unità di tempo (iperperiodo) ix

10 Capitolo 1 Introduzione 1.1 Wireless Sensor Network Le Wireless Sensor Network (WSN) sono una delle aree di ricerca più interessanti e promettenti degli ultimi anni[1]. Una WSN è una rete wireless, composta da dispositivi autonomi aventi lo scopo di effettuare il sensing di grandezze fisiche variabili in funzione dello spazio (collocazione geografica del nodo) e del tempo. I nodi di una WSN sono dispositivi embedded dotati di funzionalità di rete, strumenti di misurazione ed un certa capacità computazionale. Per queste caratteristica e per il fatto che collaborano tra loro per espletare il proprio compito, essi vengono spesso chiamati smart sensor o sensori intelligenti. Le WSN offrono numerosi vantaggi rispetto ai tradizionali sistemi di misurazione, tra cui un elevata pervasività del monitoraggio e un intrinseca tolleranza ai guasti. Tuttavia il vero punto di forza delle WSN è la loro versatilità, esse sono infatti in grado di supportare applicazioni molto differenti tra loro. Questa flessibilità complica però la definizione di un insieme di requisiti specifici per le WSN e di conseguenza l individuazione di un unica soluzione tecnica in grado di coprire l intero spazio di applicazione Scenari di applicazione I parametri fisici che possono essere monitorati da una WSN sono molteplici, essi comprendono ad esempio temperatura, suono, vibrazione, pressione, movimento, inquinamento, ecc. Di conseguenza i campi di applicazione delle sensor network sono i più disparati. Esempi di possibili applicazioni sono: Applicazioni militari Come è accaduto per molte altre tecnologie, la ricerca sulle sensor network nasce in ambito militare[2], dove esse vengono inizialmente impiegate per il rilevamento e per il tracciamento di unità nemiche. Questo 1

11 CAPITOLO 1. INTRODUZIONE 2 tipo di impiego rimane tutt oggi il principale, tuttavia ad esso si sono affiancati altri utilizzi tra cui il monitoraggio di equipaggiamenti e munizioni, la stima dei danni di una battaglia ed il riconoscimento del tipo di attacco (nucleare, biologico o chimico). Applicazioni ambientali In questo ambito le principali applicazioni riguardano il monitoraggio dell ambiente per l individuazione e, ove possibile, la prevenzione di disastri ambientali[3, 4], come incendi, alluvioni. Altri utilizzi sono nell ambito delle scienze biologiche, come lo studio dell habitat di determinate specie animali o vegetali[5]. Applicazioni medico-sanitarie Utilizzi in questa categoria includono il telemonitoraggio dei dati fisiologici dei pazienti, il controllo della somministrazione di medicine, il tracciamento di dottori e i pazienti all interno di un ospedale, ecc. [6] Applicazioni domestiche Le sensor network possono essere utilizzate in applicazioni domotiche avanzate come ad esempio l Ambient Assisted Living (AAL)[7], si può infatti immaginare di dotare ogni elettrodomestico di un opportuno nodo sensore e creare così una rete che permetta un controllo automatico o a distanza degli elettrodomestici presenti nella casa. Applicazioni industriali e commerciali Le applicazioni in ambito industriale e commerciale delle sensor network sono molteplici, tra cui sistemi di gestione del magazzino (Inventory System)[8], della flotta aziendale (Car Tracking)[9], degli edifici aziendali (Smart Office), ecc Requisiti tipici Dato l ampio numero di possibili applicazioni delle WSN non è possibile definire per esse dei requisiti validi in generale, ma solo dei requisiti tipici. Essi comprendono[10]: Scalabilità Poiché il numero dei nodi di una WSN può aumentare nel tempo e diventare molto elevato, l architettura ed i protocolli utilizzati devono essere in grado di supportare tale crescita senza un eccessivo degrado delle prestazioni della rete. Tempo di vita In molte applicazioni i nodi saranno alimentati a batteria e quindi potranno disporre di una quantità limitata di energia. Poiché la sostituzione di tali batterie è spesso impraticabile, la WSN dovrà operare in maniera energyefficient al fine di aumentare il proprio tempo di vita. Diversi livelli di densità In una WSN il numero di nodi per unità di area può variare considerabilmente. Diverse applicazioni avranno diversa densità dei nodi.

12 CAPITOLO 1. INTRODUZIONE 3 Anche nell ambito della stessa applicazione, la densità può variare nel tempo e nello spazio perché i nodi si guastano o si spostano; inoltre non è detto che la densità sia omogenea, la rete dovrà dunque adattarsi a tali variazioni. Tolleranza ai guasti Poiché i nodi possono terminare la propria energia o essere danneggiati, oppure la comunicazione tra due nodi può essere interrotta, è importante che la WSN nel suo insieme sia tollerante a tali guasti. Programmabilità I nodi dovrebbero essere programmabili in modo da poter cambiare funzionamento nel caso sia necessario svolgere nella WSN nuovi compiti. Infatti, un processamento statico dell informazione non è spesso sufficiente. 1.2 Middleware per WSN A causa delle proprie peculiarità e della loro stretta integrazione con l ambiente fisico, lo sviluppo di applicazioni basate su WSN è non banale. L utilizzo di un middleware per WSN è un possibile metodo per ridurre le difficoltà di progettazione ed implementazione di tali applicazioni. Un middleware per WSN astrae la rete, nascondendo la complessità dei singoli nodi e fornendone una visione olistica. Esso può essere visto come un infrastruttura software che fonde insieme l hardware, il sistema operativo dei nodi, lo stack di rete e le applicazioni. Il middleware dovrà occuparsi della gestione della rete e garantire che essa rispetti i requisiti precedentemente descritti (cfr ). I middleware per WSN possono essere classificati in base al tipo di astrazione che forniscono. Una possibile classificazione è la seguente[11]: Classic Middleware I middleware classici forniscono astrazione sulla comunicazione (primitive e paradigmi di comunicazione). Alcuni di essi forniscono anche funzionalità di riprogrammazione della WSN. A questa categoria appartengo middleware come Impala[12], TinyLime[13] e EnviroTrack[14]. Data-Centric Middleware Un middleware data-centrico astrae la WSN come un database, permettendo l esecuzione di query inviata alla rete dall esterno, generalmente per mezzo di un linguaggio SQL-like. Esistono diversi middleware di questo tipo, tra cui TinyDB[15] e Cougar[16]. Molti di questi middleware utilizzano modalità di esecuzione delle query atte a ridurre il consumo di energia nella rete, ma trascurano completamente problematiche relative al QoS, ed in particolare al real-time. Virtual Machine In questo approccio la rete è un insieme di interpreti che eseguono pragrammi/script. Ciò permette di scrivere applicazioni suddivise in moduli

13 CAPITOLO 1. INTRODUZIONE 4 ciascuno dei quali verrà eseguito su un diverso nodo. Questi moduli possono essere inseriti nella rete a run-time, aumentando così la flessibilità della rete. Esempi d middleware di questo tipo sono Maté[17] e SensorWare[18]. Adaptive Middleware Il principale aspetto tenuto in considerazione da questo approccio è l adattabilità della WSN alla particolare applicazione. Essa può essere di tipo reattivo (l adattamento avviene a seguito del verificarsi di certi eventi) o proattivo (il sistema è costantemente monitorato e adattato di conseguenza). Esempi di adaptive middleware sono MiLAN[19] e TinyCubus[20]. Per un ulteriore approfondimento sull argomento si rimanda a [21]. 1.3 IEEE e LR-WPAN Il protocollo MAC è stato standardizzato nell Ottobre del 2003 dall Institute of Electrical and Electronics Engineers (IEEE) [22]. Lo standard definisce lo strato fisico e lo strato MAC (Medium Access Control) delle WPAN (Wireless Personal Area Network) a basso rate trasmissivo (LR - Low Rate). Una LR-WPAN è un rete di comunicazione semplice e a basso costo che permette di avere una connettività wireless in applicazioni con risorse energetiche limitate e requisiti di throughput poco stringenti. I principali obiettivi di una LR-WPAN sono la facilità di installazione, l affidabilità del trasferimento dati, un funzionamento a corto raggio, un costo estremamente ridotto e una durata ragionevole delle batterie; il tutto tramite un protocollo semplice e flessibile. Alcune delle caratteristiche di una LR-WPAN sono le seguenti: ˆ trasmissione wireless con rate di 250 kb/s, 100kb/s, 40 kb/s e 20 kb/s; ˆ topologia a stella o peer-to-peer; ˆ allocazione opzionale di guaranteed time slots (GTSs) ˆ protocollo di accesso al canale CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance); ˆ ridotto consumo di energia Ruoli e tipi di dispositivi All interno della LR-WPAN un nodo può ricoprire uno dei seguenti due ruoli:

14 CAPITOLO 1. INTRODUZIONE Device - semplice nodo sensore che colleziona delle misurazioni nell ambiente in cui è collocato e invia il risultato di tali misurazioni al nodo Coordinator o PAN Coordinator. 2 - Coordinator o PAN Coordinator - nodo responsabile della gestione della rete/sottorete WPAN; svolge funzioni molto più complesse rispetto al semplice Device. Lo standard IEEE distingue inoltre due tipologie di dispositivi che possono partecipare alla realizzazione di una LR-WPAN: 1 - Reduced Function Device (RFD) - dispositivo che dispone solo di un sottoinsieme delle funzionalità MAC e che per questo può comunicare solo con altri dispositivi RFD. Un RFD può operare solo come device. 2 - Full Function Device (FFD) - dispositivo che dispone di tutte le primitive MAC e che quindi può comunicare sia con dispositivi RFD che con altri dispositivi FFD. Un FFD può operare nella rete come PAN Coordinator, ossia coordinatore dell intera PAN, come semplice Coordinator, oppure come Device Topologie di rete Una LR-WPAN può essere configurata secondo due topologie (fig.1.1): la topologia a stella e la topologia peer-to-peer (che a sua volta permetta la formazione di reti più complesse, come le reti mesh e cluster-tree). La scelta della topologia dipende dal tipo di applicazione che si intende realizzare. Topologia a stella Nella topologia a stella viene stabilita una comunicazione tra i device ed un singolo nodo centrale, il PAN Coordinator. Tipicamente un device ha associato un qualche tipo di applicazione ed è o il punto iniziale o il punto terminale di una comunicazione. Il PAN Coordinator è il controllore della rete, esso viene utilizzato per iniziare, terminare o inoltrare una comunicazione nella rete; ciò non toglie che esso possa avere anche una specifica applicazione. Per quanto riguarda l alimentazione, il PAN Coordinator è spesso collegato direttamente alla rete elettrica, mentre i device sono generalmente alimentati a batteria. Topologia peer-to-peer Anche nella topologia peer-to-peer è prevista la presenza del PAN Coordinator, ma in questo caso i device possono comunicare direttamente tra loro purché siano in

15 CAPITOLO 1. INTRODUZIONE 6 ED ED PC ED ED b) MESH ED PC ED R R ED ED ED R R ED a) STAR ED ED ED R ED R ED ED = End Device R = Router PC = Pan Coordinator R R PC R ED R ED c) CLUSTER TREE Figura 1.1: Topologie a Stella e Peer-to-Peer (Mesh e Cluster-Tree) visibilità radio l uno con l altro. La topologia peer-to-peer permette la formazione di reti più complesse, come le reti a maglie. Un esempio di utilizzo della topologia peer-to-peer è il cluster-tree. Una rete cluster-tree è un particolare tipo di rete peerto-peer nella quale la maggior parte dei nodi sono FFD, che in quanto tali possono comunicare direttamente tra loro. Ciascuno di questi FFD può agire da Coordinator e fornire servizi di sincronizzazione agli altri dispositivi. Solo uno di questi Coordinator potrà essere il coordinatore dell intera rete, ovvero il PAN Coordinator. I nodi RFD possono connettersi ai vari FFD in qualità di end-point della rete (foglie). Un rete peer-to-peer può essere ad-hoc, self-organizing e self-healing. Inoltre essa può permettere la comunicazione multi-hop tra qualunque device della rete. Queste funzioni, tuttavia, non sono parte delle standard, ma devono essere fornite dai livelli superiori dello stack.

16 CAPITOLO 1. INTRODUZIONE Architettura di IEEE L architettura di IEEE (fig. 1.2) è basata sulla pila ISO/OSI. I livelli definiti dallo standard sono solamente i primi due, ovvero livello fisico (PHY) e il livello datalink (MAC). È inoltre prevista l interazione con i livelli superiori tramite un sub-layer LLC (Logical Link Control) ed un SSCS (Service Specific Convergence Sublayer); il livello SSCS esegue le azione necessarie per richiedere la trasmissione dati in base al servizio richiesto (creazione di una PAN su un canale fisico, setting del duty cycle dei nodi, setting della topologia, utilizzo della modalità beacon-enabled); il livello LLC definisce i tipi di servizio ottenibili per un trasferimento dati (ad esempio error detection, controllo di flusso ed error recovery). Figura 1.2: Lo stack di IEEE Il livello fisico Il livello fisico di IEEE (PHY) si occupa dell impostazione della frequenza e successivamente della generazione della portante trasmissiva, del riconoscimento del segnale e della modulazione e codifica dei dati. Rispetto alle tradizionali trasmissioni radio, lo stato fisico di IEEE è stato progettato per ridurre al minimo il consumo energetico. I servizi offerti dal livello fisico ai livelli superiori sono i seguenti: ˆ attivazione e disattivazione del transceiver; ˆ rilevazione del livello energetico nel canale in uso (Energy Detection ED);

17 CAPITOLO 1. INTRODUZIONE 8 ˆ rilevamento della qualità del collegamento (Link Quality LQ); ˆ supporto al protocollo CSMA/CA; ˆ selezione della frequenza di comunicazione; ˆ trasmissione e ricezione dati dalla portante. I bitrate offerti dal PHY sono mostrati in tabella 1.1. Come si può vedere il bitrate massimo è di soli 250Kbps. Data Rate Symbol Rate Banda Canali Modulazione 20Kbps 20Ksyms MHz 1 BPSK 40Kbps 40Ksyms MHz 10 BPSK 250Kbps 62.5Ksyms GHz ISM 16 O-QPSK Tabella 1.1: PHY Bitrates Il livello MAC Il livello MAC (Medium Access Controll) fornisce l interfaccia tra il livello fisico e quelli superiori, quali possono essere il livello di rete o direttamente un applicazione. I principali servizi che il livello MAC deve fornire sono: ˆ generazione dei network beacon; ˆ sincronizzazione del superframe (cfr ); ˆ supporto all associazione e alla disassociazione dalla PAN; ˆ supporto alla sicurezza della comunicazione; ˆ gestione e utilizzo del meccanismo CSMA-CA per l accesso al mezzo; ˆ creazione e mantenimento del meccanismo GTS. Il livello MAC definisce i seguenti frame: ˆ Beacon Frame - utilizzato dal coordinator per definire la struttura del superframe (se utilizzato) e per permettere ai device di localizzare la rete; ˆ Command Frame - utilizzato per effettuare richieste di servizio; ˆ Data Frame - utilizzato per tutti i trasferimenti di dati; ˆ Acknowledgment Frame - utilizzato per confermare la ricezione di un data frame o di un command frame.

18 CAPITOLO 1. INTRODUZIONE Modalità di funzionamento Lo standard prevede due diverse modalità di accesso al mezzo: beacon-enabled : è basata su una struttura a superframe che si ripete periodicamente. Tramite il superframe i nodi possono sincronizzarsi con il coordinator: in questo modo si è in grado di disciplinare la comunicazione tra i vari nodi della rete. non beacon-enabled : non prevede l uso di un superframe di sincronizzazione della comunicazione, pertanto l accesso al canale avviene in modo completamente asincrono. Entrambe le modalità prevedono che i device si associno al nodo coordinator tramite un apposita procedura. I compiti che deve svolgere un nodo coordinator all interno della PAN sono: ˆ mantenere aggiornata la lista dei device associati; ˆ inviare periodicamente il frame di beacon se in beacon mode; ˆ scambiare pacchetti dati con i device o con altri coordinator. Struttura del superframe Lo standard prevede l uso opzionale di una struttura a superframe il cui formato è definito dal coordinator. Il superframe è delimitato dalla presenza dei beacon (cfr ed è suddiviso in 16 slot temporali. Tutti i superframe hanno la stessa lunghezza e possono opzionalmente essere divisi in un periodo attivo e un periodo non attivo durante il quale il coordinator e i device possono spegnere la radio ed entrare in una fase di risparmio energetico. La lunghezza del periodo attivo e del periodo inattivo, come anche la durata del singolo slot temporale sono completamente configurabili tramite i parametri BO (Beacon Order) e SO (Superframe Order), come illustrato in figura 1.3. Il periodo attivo può essere ulteriormente suddiviso in un periodo di accesso a contesa (CAP - Contention Access Period) seguito da un periodo di accesso senza contesa (CFP - Contention Free Period). Il CFP permette di supportare applicazioni real-time che necessitano di allocazione di banda e di una latenza massima finita e nota a priori. Durante il CAP i dispositivi possono comunicare utilizzando il protocollo CSMA- CA. Invece, durante il CFP l accesso al canale avviene per divisione di tempo. Il CFP è infatti suddiviso in intervalli temporali, chiamati Guaranteed Time Slots (GTS), ciascuno dei quali viene assegnato dal coordinator ad un certo device. I device che

19 CAPITOLO 1. INTRODUZIONE 10 utilizzano i GTS devono garantire che tutte le trasmissioni terminino prima dell inizio del prossimo GTS o entro la fine del CFP. Durante il CFP non viene utilizzato il meccanismo CSMA-CA ma la trasmissione avviene immediatamente quando un pacchetto è disponibile. I device sono attivi nella fase di trasmissione o ricezione tramite GTS solo se hanno una GTS allocata. Il coordinator può allocare fino a 7 GTS per superframe e ciascuna GTS può occupare più di un time slot. Tuttavia il superframe deve sempre contenere una porzione minima di CAP. È invece possibile eliminare del tutto il CFP, in modo tale che il CAP occupi l intero periodo attivo del superframe. Figura 1.3: Struttura del superframe in una PAN beacon-enabled 1.4 Sistema Embedded Con il termine embedded si identificano tutti quei sistemi di elaborazione che non rientrano nella categoria general-purpose, definizione che lascia ben intuire la vastità delle applicazioni in cui sono coinvolti. In sostanza sono dei sistemi progettati per svolgere una particolare attività e vengono quindi definiti, in contrapposizione ai classici calcolatori, dispositivi special-purpose. I sistemi embedded sono dei circuiti integrati di elementi elettronici ed unità di calcolo. Tali sistemi possono essere realizzati con pure tecniche elettroniche ( Application- Specific Integrated Circuit ) oppure mappando alcune funzionalità richieste in software. Seguendo questa linea l utilizzo di microcontrollori programmabili ha esteso il dominio delle applicazioni dei sistemi embedded nonché la loro flessibilità applicativa. L incremento delle prestazioni dei dispositivi, nonché la loro miniaturizzazione,

20 CAPITOLO 1. INTRODUZIONE 11 fa sì che oggi i sistemi basati su microcontrollori siano una delle soluzioni principali in molti settori nell industria (automotive, controllo industriale) e del mercato consumer (cellulari, lettori MP3). Nel 2008 sono state vendute oltre 4 miliardi di unità di sistemi embedded; le previsioni parlano di 16 miliardi di unità in funzione entro il 2010 e 40 miliardi entro il 2020[23]. 1.5 Sistema Real-Time I sistemi real-time sono quei sistemi di calcolo in cui la correttezza di funzionamento non dipende soltanto dalla validità dei risultati ottenuti ma anche dal tempo in cui i risultati sono prodotti[24]. In un sistema in tempo reale un insieme di attività (task) sono rilasciate periodicamente e devono essere completate entro le loro deadline. Gli stimoli provenienti dall ambiente esterno possono inoltre attivare task aperiodici che devono essere processati in maniera concorrente con quelli periodici. La modalità con cui il sistema gestisce la programmazione concorrente è detta politica di schedulazione e può essere basata su priorità assegnate a ciascuna attività. La qualità principale che deve possedere un sistema operativo in tempo reale è la prevedibilità. In generale per prevedibilità di un sistema si intende la capacità di determinare in anticipo (ad esempio all istante di creazione) se uno o più processi potranno essere completati entro i propri vincoli temporali. La criticità della specifica applicazione determina quanto rigorosamente dovranno essere rispettati i vincoli temporali (fig. 1.4).

21 CAPITOLO 1. INTRODUZIONE 12 Figura 1.4: Rigidità dei vincoli temporali in relazione alla criticità dell applicazione

22 Capitolo 2 Specifica dei requisiti Così come prevedono le più comuni tecniche di ingegneria del software, la fase iniziale del lavoro è stata la raccolta e l analisi dei requisiti. In questo capitolo vengono riportati i principali requisiti individuati, suddivisi in funzionali e non funzionali. 2.1 Descrizione generale del sistema Il sistema dovrà permettere all utente di interfacciarsi con una WSN come se fosse una base di dati. In particolare esso dovrà permettere di estrarre dalla rete le misurazioni dei nodi sensori. La struttura generale del sistema è riportata in figura 2.1. L utente potrà accedere alla WSN tramite un PC a sua volta collegato alla rete. Il PC permetterà all utente di inserire interrogazioni (query) e di visualizzarne il risultato. Il PC è collegato con un collegamento dedicato ad un particolare nodo della rete, che fungerà da punto di accesso alla rete (Service Access Point). Tale nodo è responsabile di diffondere l interrogazione al resto della rete, di raccoglierne i risultati e di inviarli al PC. Le grandezze fisiche misurabili dalla rete potranno essere molteplici, inoltre non è detto che ciascun nodo sensore sia in grado di misurarle tutte. In generale ogni nodo sensore potrà essere dotato di uno o più tipi di sensori, sarà il sistema ad individuare quali nodi contattare, in base allo specifico tipo di misura richiesta. 2.2 Requisiti funzionali I requisiti funzionali definiscono quali sono i servizi che il sistema dovrà fornire, ovvero quali sono le sue funzioni. Una funzione è descritta in termini di input, comportamento atteso ed output. 13

23 CAPITOLO 2. SPECIFICA DEI REQUISITI 14 Figura 2.1: Struttura generale del sistema Nel caso di MIRTES il generico servizio offerto è l interrogazione dei nodi sensore. I tipi specifici di query che il sistema dovrà supportare sono descritte nei paragrafi seguenti Query semplici Il sistema, prendendo in input il nome di una certa grandezza fisica, dovrà restituire tutte le sue misure al momento disponibili nella rete. Se richiesto, ogni misura dovrà essere associata al nodo che l ha generata. Nel caso di grandezze fisiche vettoriali si potrà specificare anche solo un sottoinsieme delle sue componenti Query di aggregazione Il sistema dovrà prendere in input il nome di una certa grandezza fisica ed una o più funzioni di aggregazione, applicarle alle misure ad essa relative e restituire i risultati così ottenuti. Una funzione di aggregazione restituisce un singolo valore a partire da un insieme di valori di input. Esempi di funzioni di aggregazione sono la media, la somma, il minimo, il massimo.

24 CAPITOLO 2. SPECIFICA DEI REQUISITI Query con restrizioni Per entrambe le query precedentemente descritte dovrà essere possibile indicare un insieme di condizioni sui valori delle misure o degli aggregati. Per condizione si intende una relazione binaria tra tali valori ed una costante. Esempi di possibili relazioni sono <,, =, e >. Nel caso di query semplici, si potranno specificare solo condizioni sulle misure; il sistema dovrà restituire come output solo le misure che verificano tali condizioni. Nel caso di query aggregate si potranno specificare anche condizioni sui valori aggregati; il sistema dovrà calcolare la funzione di aggregazione solo sull insieme delle misure che verificano le relative condizioni e dovrà restituire come output solo i valori aggregati che verificano le condizioni ad essi relative Query snapshot e query periodiche Le query precedentemente descritte dovranno poter essere eseguite in due modalità. Nella prima modalità la query verrà eseguita una sola volta e su esplicita richiesta dell utente. Si parlerà in questo caso di query snpashot o aperiodica. Nella seconda modalità la query, dopo una prima attivazione esplicita da parte dell utente, verrà rieseguita ciclicamente ad intervalli regolari in maniera automatica. Si parlerà in questo caso di query periodica. Il periodo sarà specificato dall utente al momento della richiesta. Il sistema terrà traccia delle query periodiche e ne permetterà l interruzione da parte dell utente. 2.3 Requisiti non funzionali I requisiti non funzionali sono vincoli sul sistema o sul suo processo di sviluppo. Essi definiscono come il sistema deve essere e non cosa deve fare. Per quanto riguarda MIRTES i requisiti non funzionali sono quelli tipici di un middleware data-centrico per WSN, i quali includono a loro volta quelli di un sistema distribuito. A questi si aggiunge l importante requisito del supporto al real-time, che come già detto è l aspetto più innovativo di questo lavoro. Sono inoltre presenti vincoli precisi sull hardware e sul software da utilizzare per l implementazione. Nei paragrafi seguenti vengono descritti nel dettaglio tutti requisiti non funzionali individuati Supporto al real-time Un definizione generica di sistema real-time è già stata data in 1.5; in MIRTES essa si applica alla gestione delle query periodiche. Queste sono infatti fondamentali per qualunque sistema di controllo si voglia realizzare sulla WSN. MIRTES dovrà garantire la periodicità di tali query e la loro latenza massima: ogni query periodica

25 CAPITOLO 2. SPECIFICA DEI REQUISITI 16 dovrà terminare entro l inizio del periodo successivo. Tutto ciò indipendentemente dal carico del sistema; in particolare il sistema dovrà schedulare le query aperiodiche in modo che non interferiscano con quelle periodiche. Infine, quest ultime, prima di essere accettate nel sistema dovranno passare un apposito test di accettazione, che garantisca il futuro rispetto dei vincoli temporali propri e delle altre query periodiche già presenti Trasparenza e Data-centrismo Per trasparenza di un sistema distribuito si intende la sua capacità di nascondere agli utenti la propria natura distribuita, apparendo e funzionando come un normale sistema centralizzato. Per quanto riguarda MIRTES esso dovrà apparire all utente come una base di dati, nascondendo la complessità della WSN sottostante. In particolare per richiedere le misure relative ad una certa grandezza fisica non dovrà essere necessario conoscere l indirizzo dei sensori in grado di misurarla (data-centrismo) In-network processing Come visto i nodi di una WSN sono dotati di una certa capacità computazionale che può essere utilizzata per un pre-processamento dei dati raccolti (cfr 1.1). MIRTES dovrà sfruttare questa possibilità, in particolare le operazioni di aggregazione e di verifica delle condizioni dovranno essere effettuate all interno della WSN e non sul PC. Inoltre si dovrà, per quanto possibile, distribuire il carico computazionale sull intera rete, in modo da non sovraccaricare il SAP Adattabilità alla specifica applicazione Un middleware per WSN è per definizione in grado di supportare qualunque tipo di applicazione, tuttavia esso dovrà prevedere dei meccanismi per adattarsi alla specifica applicazione per la quale verrà utilizzato. MIRTES dovrà tener conto di questo aspetto, prevedendo ad esempio un meccanismo per regolare i parametri di funzionamento della comunicazione wireless, in modo da adattarli alle esigenze specifiche Efficienza energetica L efficienza energetica è una proprietà importante in una WSN, in quanto i nodi sensore sono spesso alimentati a batterie, la cui sostituzione è spesso non agevole e delle volte del tutto impossibile. Nella progettazione di MIRTES si dovranno dunque adottare degli accorgimenti atti a contenere il consumo energetico del sistema, in particolare si dovrà limitare al massimo l utilizzo della rete da parte dei nodi sensori, in quanto la comunicazione wireless è la principale causa di consumo in una WSN.

26 CAPITOLO 2. SPECIFICA DEI REQUISITI Robustezza Per robustezza si intende la capacità di un sistema di resistere ai guasti. Un sistema è robusto se un guasto ad una sua componente (generalmente hardware) non compromette il corretto funzionamento del sistema, ma comporta al massimo un degrado delle prestazioni. La tolleranza ai guasti è una proprietà fondamentale per MIRTES, in quanto, in una WSN, il malfunzionamento di un nodo sensore è evento frequente Estensibilità Un sistema è detto estensibile se lo sforzo necessario per modificare le funzionalità esistenti o aggiungerne di nuove è contenuto. MIRTES dovrà essere progettato per supportare estensioni, sia di lieve entità, come l aggiunta di una nuova funzione di aggregazione o di un nuovo tipo di condizione, sia di portata maggiore, come l introduzione di un meccanismo di generazione di eventi (funzionamento event-centric) Supporto multipiattaforma Un applicazione software è detta multipiattaforma se funziona ed è in grado di interoperare con più di una piattaforma (combinazione hardware e sistema operativo). MIRTES dovrà essere multipiattaforma nel senso che qualunque sistema dovrà potersi interfacciare con esso Scalabilità In una WSN per scalabilità si intende la possibilità di aumentare il numero dei nodi senza che ciò comporti un eccessivo deterioramento delle prestazioni generali. Affinché MIRTES sia scalabile è necessario che il tempo di esecuzione di una query cresca in maniera lineare con l aumentare dei nodi Eterogeneità hardware Un sistema distribuito è detto eterogeneo se contiene componenti diverse in hardware e software. MIRTES dovrà permettere l utilizzo di una WSN eterogenea in hardware, ovvero in cui i nodi sensori siano implementati su hardware differenti Vincoli sull implementazione Per l implementazione del sistema sono stati imposti vincoli ben precisi: ˆ il sistema dovrà essere scritto per il micro-kernel real-time ERIKA Enterprise (cfr );

27 CAPITOLO 2. SPECIFICA DEI REQUISITI 18 ˆ per la comunicazione wireless si dovrà utilizzare lo standard IEEE , ed in particolare l implementazione fornita della libreria µwireless (cfr ); ˆ il sistema dovrà essere in grado di funzionare utilizzando come hardware per il SAP e per gli altri nodi della WSN le schede FLEX (cfr ). Per ulteriori dettagli sull ambiente di sviluppo da utilizzare e sui vincoli da esso imposto si rimanda al capitolo successivo.

28 Capitolo 3 Ambiente di Sviluppo Quando si parla di applicazioni su sistemi embedded l ambiente di sviluppo è inevitabilmente caratterizzato da Hardware e Software. Nella programmazione dei sistemi general-purpose si ha normalmente, grazie all astrazione dovuta ai sistemi operativi ed ai linguaggi di programmazione ad alto livello, la tendenza ad ignorare la prima di queste due componenti. Sui sistemi embedded, al contrario, l HW è fondamentale e solo grazie ad una sua completa conoscenza si può pensare di affrontare lo sviluppo SW. Questo capitolo presenterà prima l ambiente HW, fornendo una panoramica sulle caratteristiche delle board di sviluppo, del microcontrollore e del transceiver , e quindi quello SW, introducendo il sistema operativo real-time ERIKA e la libreria µwireless. Verranno infine descritti gli strumenti di debugging utilizzati. Questa trattazione non ha lo scopo di essere esaustiva ed è da considerarsi un introduzione necessaria per affrontare le problematiche implementative. Per maggiore dettaglio si rimanda ai riferimenti presenti in questo capitolo. 3.1 Piattaforma Hardware Per realizzare applicazioni su microcontrollore è necessario disporre di sistema hardware di supporto che prende il nome di evaluation board o scheda di sviluppo FLEX embedded board FLEX è una scheda embedded basata sui microcontrollori della famiglia dspic DSC di Microchip [25], nata dalla collaborazione di due aziende italiane, Evidence [26] ed Embedded Solutions [27]. Si tratta a tutti gli effetti di una evaluation board che permette sviluppo e testing di applicazioni real-time per dspic DSC in breve 19

29 CAPITOLO 3. AMBIENTE DI SVILUPPO 20 Figura 3.1: Architettura Modulare della FLEX board tempo ed in modo relativamente semplice. Questo è dovuto a due caratteristiche fondamentali che contraddistinguono il sistema: 1 - Architettura hardware modulare, unita ad una buona robustezza della parte elettronica; 2 - Supporto del kernel real-time Erika Enterprise e del suo ambiente di sviluppo (cfr ). Architettura modulare L architettura FLEX prevede la presenza di una scheda madre principale e di un insieme di schede figlie (daughter boards) che possono essere montante in combinazione con la board di base per costituire dei dispositivi complessi. La Figura 3.1 riassume simbolicamente l architettura. Base Board La FLEX base board ha fondamentalmente lo scopo di esportare i piedini del microcontrollore all esterno, garantendo un uso in sicurezza del dispositivo anche da parte di utenti non completamente esperti. I pin del dspic sono accessibili per mezzo di connettori standard a passo 2.55mm, semplificando così l interconnessione con circuiti elettronici esterni. Esistono due versioni disponibili della scheda: FLEX Light e FLEX Full (vedi figura 3.2). Tra le varie caratteristiche ricordiamo, oltre al microcontrollore Microchip dspic DSC dspic33fj256mc710 di cui parleremo tra poco, i connettori di alimentazione, le cui tensioni di ingresso nel caso Light sono nel range 9 12V, ed un insieme di led (molto utili in fase di sviluppo). La versione Full ha un circuito di alimentazione più complesso e molto più robusto, ed altri componenti hardware.

30 CAPITOLO 3. AMBIENTE DI SVILUPPO 21 Tuttavia la FLEX Light board risulta più compatta ed adatta per sistemi distribuiti alimentati a batteria. Daughter Boards Le schede figlie possono essere montate al di sopra della base board sfruttando i connettori standard a passo 2.55mm. Sono delle schede sulle quali possono essere presenti dispositivi di qualunque genere che si interfacciano con il microcontrollore. Inoltre è possibile montare una daughter board su un altra in modo da costruire sistemi anche molto complessi. La daughter board utilizzata nell ambito di questo lavoro è la FLEX Demo Board (figura 3.3) che permette di aggiungere alla FLEX base board diverse funzionalità tra cui: ˆ 2 output DAC (con risoluzione a 12 bit); ˆ un accelerometro a 3 assi; ˆ un set di 4 bottoni; ˆ un set di 8 LED; ˆ un LCD (16 caratteri x 2 linee); ˆ un buzzer; ˆ un potenziometro ; ˆ un sensore di temperatura; ˆ un sensore di luminosità; ˆ un connettore per transceiver In particolare i LED e il display LCD sono stati utilizzati nella fase di implementazione come strumenti di debug, mentre si è fatto uso dell accelerometro e del sensore di luminosità durante la fase di validazione sperimentale (cfr. 6) Microcontrollore dspic33fj256mc710 Il microcontrollore della FLEX board è il dspic33fj256mc710 della famiglia dspic DSC (Digital Signal Controller) di Microchip [25]. È un architettura a 16 bit dotata di un unità DSP che permette di ottenere alte prestazioni nell elaborazione di segnali digitali. Le periferiche presenti ed un elevato numero di pin digitali a disposizione (fino ad 85), rendono questo microcontrollore molto adatto per complesse applicazioni di sensing o di controllo.

31 CAPITOLO 3. AMBIENTE DI SVILUPPO 22 (a) FLEX Light (b) FLEX Full Figura 3.2: FLEX Base Boards

32 CAPITOLO 3. AMBIENTE DI SVILUPPO 23 Figura 3.3: FLEX Demo Board Architettura In Figura 3.4, estratta dal manuale relativo al dispositivo, è mostrato lo schema a blocchi generale del dspic in questione. D ora in avanti si farà sempre riferimento allo specifico modello dspic33fj256mc710. L architettura dell MCU è di tipo Harvard modificata. L instruction set e quindi il bus per la memoria codice sono a 24 bit, il data path ed i relativi bus dati sono a 16 bit; il dspic utilizza due bus dati per accedere parallelamente a due zone di memoria. La memoria in particolare è organizzata nel seguente modo: ˆ Data Memory I primi 2 KB servono a mappare in memoria gli Special Function Register (SFR) ovvero i registri usati dalla CPU e dalle periferiche. Seguono 30 KB di SRAM che costituiscono spazio per: X Data RAM (accessibile dal relativo X Data Bus), Y Data RAM (accessibile dal relativo Y Data Bus), DMA RAM (2K di memoria dual-port dedicata al DMA). Infine è possibile mappare una parte della memoria codice (di programma) nella memoria dati (Program Visibility Space - PSV).

33 dspic33fjxxxmcx06/x08/x10 MOTOR CONTROL FAMILY CAPITOLO 3. AMBIENTE DI SVILUPPO 24 FIGURE 1-1: PSV & Table Data Access Control Block dspic33fjxxxmcx06/x08/x10 MOTOR CONTROL FAMILY GENERAL BLOCK DIAGRAM Y Data Bus Interrupt Controller X Data Bus PORTA PCU PCH PCL Program Counter Stack Loop Control Control Logic Logic Data Latch X RAM Address Latch Data Latch Y RAM Address Latch 16 DMA RAM DMA Controller 16 PORTB Address Latch Address Generator Units PORTC Program Memory Data Latch Address Bus 24 ROM Latch EA MUX PORTD Instruction Decode & Control Instruction Reg Literal Data 16 PORTE Control Signals to Various Blocks DSP Engine OSC2/CLKO OSC1/CLKI Timing Generation FRC/LPRC Oscillators Precision Band Gap Reference Voltage Regulator Power-up Timer Oscillator Start-up Timer Power-on Reset Watchdog Timer Brown-out Reset Divide Support 16 x 16 W Register Array 16-bit ALU PORTF PORTG VDDCORE/VCAP VDD, VSS MCLR PWM QEI Timers 1-9 ADC1,2 ECAN1,2 IC1-8 OC/ PWM1-8 CN1-23 SPI1,2 I2C1,2 UART1,2 Note: Not all pins or features are implemented on all device pinout configurations. See pinout diagrams for the specific pins and features present on each device. DS70287A-page 14 Figura 3.4: schema generale del dspic 33 DSC 2007 Microchip Technology Inc.

34 CAPITOLO 3. AMBIENTE DI SVILUPPO 25 ˆ Program Memory Memoria flash di 256KB per il codice. La CPU è costituita da una parte MCU e da una DSP. È possibile lavorare con differenti clock, il massimo che si può ottenere con l oscillatore interno e la PLL è una frequenza di clock di 40MHz che corrisponde ad un rate massimo di istruzioni dichiarato dal costruttore di 40MIPS. Nel dspic è presente anche un controllore DMA ad 8 canali. Periferiche Tra le periferiche presenti sul dspic33fj256mc710 si ricordano: ˆ 9 Timers a 16 bit (con prescaler programmabile); 8 di questi possono essere usati in coppia per formare timers a 32 bit. ˆ 8 canali di Input Capture e 8 canali di Output Compare ˆ 2 SPI, 2 I 2 C TM, 2 UART, 2 Enhanced CAN (ECAN TM ) ˆ 8 canali Motor Control PWM ˆ 1 modulo Quadrature Encoder Interface ˆ 2 moduli ADC Supporto per Programmazione/Debugging I microcontrollori dspic 33 hanno delle interfacce per la programmazione e la diagnostica del dispositivo stesso. In particolare sono messe a disposizione tre modalità: In-Circuit Serial Programming TM (ICSP TM ), Enhanced ICSP e Joint Test Action Group (JTAG). La prima di tutte è uno strumento proprietario di Microchip e sviluppato per consentire la programmazione dei propri dispositivi. È quindi integrata direttamente nel core del microcontrollore dove è presente una macchina a stati che regola la scrittura in memoria. Il processo deve comunque essere supervisionato dell esterno con HW e SW opportuno. ICSP gestisce anche un canale per il debugging sul chip (in-circuit debugging). In questo caso è necessario utilizzare un dispositivo esterno appropriato che carichi nel microcontrollore il SW appropriato per il debugging. MPLAB ICD2 è un oggetto in grado di gestire questo processo in modo automatico e che può essere comodamente controllato da PC nell ambiente di sviluppo di Microchip (MPLAB IDE).

35 CAPITOLO 3. AMBIENTE DI SVILUPPO Piattaforma Software L ambiente di sviluppo SW è costituito dal supporto del costruttore (Microchip) e dal sistema operativo real-time ERIKA Supporto Microchip I componenti principali sono il driver per la gestione del programmatore/debugger MPLAB ICD2 ed il compilatore. MPLAB IDE Microchip fornisce un ambiente di sviluppo chiamato MPLAB IDE. Questo integra insieme diverse funzionalità: organizzazione dei progetti (gestione dei files), editor per i sorgenti, compilatori, programmazione e debugging con MPLAB ICD2. Per quel che riguarda questo progetto l IDE verrà utilizzato solo per la gestione dell MPLAB ICD2 cioè per la fase di programmazione/debugging. Il resto sarà direttamente gestito nell ambiente di sviluppo di ERIKA. Compilatore C30 Uno degli strumenti più importanti per la realizzazione di un sistema embedded è il compilatore. MPLAB C30 è un compilatore ANSI-C compliant che include alcune estensioni nel linguaggio per i microcontrollori della famiglia dspic DSC. È un porting del compilatore GCC della Free Software Foundation e viene chiaramente distribuito insieme ad un assemblatore ed al linker. Alcune delle differenze sostanziali rispetto all ANSI-C sono: ˆ specifica di attributi per le variabili; ˆ specifica di attributi per le funzioni; ˆ definizione di funzioni inline; ˆ associazione di variabili a specifici registri; Il compilatore è distribuito anche in una versione student liberamente scaricabile dal sito di Microchip [25]. Per maggiori informazioni consultare il manuale di riferimento.

36 CAPITOLO 3. AMBIENTE DI SVILUPPO ERIKA Enterprise ERIKA (Embedded Real time Kernel Architecture)[28] è un sistema operativo realtime (RTOS) pensato per soluzioni embedded su piccoli microcontrollori e con una API simile a quelle proposte dal consorzio OSEK/VDX [29]. È distribuito da Evidence s.r.l. [26] in doppia licenza (commerciale e GPL). Il kernel è accompagnato da RT-Druid che costituisce un ambiente di sviluppo per il sistema operativo fornendo strumenti per la scrittura, la compilazione e l analisi dell applicazione. Per il progetto sarà utilizzato ERIKA Enterprise (EE) con licenza GPL. Alcune delle caratteristiche di sistema operativo sono le seguenti: ˆ quattro classi di conformità OSEK; ˆ scheduling Fixed Priority (FP) e Earliest Deadline First (EDF); ˆ multitasking di tipo preemptive e non-preemptive; ˆ gestione della condivisione dello stack; ˆ gestione delle risorse condivise (Resource) con Immediate Priority Ceiling; ˆ semafori generalizzati (Semaphore); ˆ attivazione periodica dei task mediante allarmi (Alarm). Architettura del kernel L architettura di EE, mostrata in Figura 3.5, è costituita da due livelli: Kernel Layer e Hardware Abstraction Layer (HAL). Il livello del Kernel implementa la gestione dei task e le varie strategie di schedulazione adottate. Esporta per il livello di applicazione una serie di RTOS API per Task s, Alarms, Resources e Semaphores. L HAL si occupa della parte del sistema operativo dipendente dall hardware, ad esempio la gestione delle interruzioni e delle commutazioni di contesto. Le architetture attualmente supportate sono: ˆ Microchip dspic ˆ Atmel AVR5 ˆ Altera NIOS II ˆ ARM7TDMI ˆ Tricore ˆ Motorola PPC ˆ Hitachi H8 ˆ ST10

37 CAPITOLO 3. AMBIENTE DI SVILUPPO 28 Application Kernel Hardware Abstraction CPU MCU Board Figura 3.5: Architettura di ERIKA RTOS Standard OSEK Uno degli aspetti più interessanti di ERIKA è l aderenza a quattro classi di conformità OSEK [30]. Lo standard OSEK (Offene Systeme und deren schnittstellen für die Elektronik im Kraftfahrzeug - open system and corresponding interfaces for automotive electronics) è un progetto congiunto di alcune industrie automobilistiche per lo sviluppo di sistemi di controllo distribuiti nei veicoli. Il consorzio prende il nome di OSEK/VDX (VDX sta per Vehicle Distributed executive) poiché si occupa della definizione di un insieme di API per sistemi operativi real-time (OSEK) e di un sistema per la gestione di rete (VDX). Esempi di applicazioni tipiche dello standard riguardano sistemi di controllo con vincoli temporali molto stretti ed orientati a produzione di massa. Ne consegue che OSEK risulta molto orientato all ottimizzazione (memoria, risorse, prestazioni, ecc). Pertanto le caratteristiche principali sono: scalabilità (supporto per molte architetture HW), portabilità (interfaccia ISO/ANSI-C), configurabilità (OSEK Implementation Language - OIL) e allocazione statica (elementi del kernel allocati a tempo di compilazione). RT-Druid Come già anticipato RT-Druid può essere considerato l ambiente di sviluppo per EE. È un set di plugin per il framework Eclipse [31](fig. 3.6) ed è composto da una parte

38 CAPITOLO 3. AMBIENTE DI SVILUPPO 29 Figura 3.6: Screenshot del framework Eclipse con il plugin RT-Druid per la generazione del codice ed una parte per l analisi di schedulabilità. Il code generator è disponibile anche in una versione stand-alone indipendente da Eclipse. Si tratta principalmente di un compilatore per OIL (dello standard OSEK) che, in base alle specifiche definite nella configurazione del sistema, costruisce la struttura necessaria alla compilazione di ERIKA (makefiles, inizializzazione delle strutture dati, ecc). Inoltre fornisce una serie di template project ovvero un insieme di esempi di applicazioni pronte per essere compilate ed eseguite sulla FLEX board. Il plugin per l analisi della schedulabilità permette di modellizzare, analizzare e simulare il comportamento temporale del sistema embedded che si vuole progettare. È disponibile solo nelle versioni commerciali del sistema operativo.

39 CAPITOLO 3. AMBIENTE DI SVILUPPO 30 Figura 3.7: Architettura stratificata del sistema di comunicazione µwireless compliant con lo standard IEEE basato su Erika µwireless µwireless è un implementazione (parziale) dello stack per Erika Enterprise sviluppato dal laboratorio Retis della Scuola Superiore Sant Anna. Esso manca principalmente di un meccanismo per l associazione dinamica dei dispositivi, ma include il supporto alla modalità beacon-enabled con GTS. Tra le numerose funzionalità esportate al livello applicativo da µwireless si riportano le seguenti: ˆ possibilità di configurare la durata del superframe e dei timeslot tramite i parametri BO e SO; ˆ invio in modalità CSMA/CA o GTS; ˆ possibilità di sincronizzare l applicazione con gli eventi della rete (ricezione di un frame, inizio e fine del superframe o del singolo time slot, ecc.) tramite la tecnica delle callback; ˆ possibilità di impostare il payload del beacon frame. Come si può vedere in figura 3.2.3, µwireless fa uso delle primitive software messe a disposizione da Erika. Le funzionalità dello stack sono infatti implementate all interno di appositi task che vengono attivati per mezzo di allarmi periodici. 3.3 Strumenti di debugging Lo sviluppo di MIRTES è stato supportato da tre principali strumenti di debugging. Due di questi, la Flex Demo Board e la coppia MPLAB IDE/MPLAB ICD2 sono

40 CAPITOLO 3. AMBIENTE DI SVILUPPO 31 Figura 3.8: La board Texas Instruments CC2420 EB con l estensione CC2420EM stati già presentati (cfr e cfr ). Nel paragrafo seguente verrà presentato il CC2420 Packet Sniffer, strumento per l analisi del traffico di rete Chipcon CC2420 Packet Sniffer L analizzatore di rete Chipcon CC2420 Packet Sniffer for IEEE [32] permette di catturare i frame IEEE per mezzo della scheda Texas Instruments CC2420EB dotata dell estensione CC2420EM (fig ). La sua interfaccia grafica (fig ) mette a disposizione le seguenti funzionalità: ˆ elenco dei pacchetti ricevuti con relativi timestamp; ˆ interpretazione dei pacchetti con evidenziazione dei differenti campi; ˆ filtraggio dei pacchetti; ˆ lista dei device presenti nella rete.

41 CAPITOLO 3. AMBIENTE DI SVILUPPO 32 Figura 3.9: Interfaccia del Chipcon CC2420 Packer Sniffer

42 Capitolo 4 Progettazione del sistema La progettazione del sistema è fortemente influenzata dai requisiti non funzionali, in particolar modo dal requisito di supporto real-time per le query periodiche. Come visto (cfr. 1.5) una caratteristica fondamentale di un sistema real-time è la predicibilità. Nel caso di MIRTES si è interessati alla predicibilità del tempo di esecuzione delle query. Il principale ostacolo a ciò è la diffusione della query e la conseguente raccolta dei risultati, che, se non adeguatamente progettata, può introdurre ritardi indefiniti. Per prima cosa è stato dunque ideato un meccanismo di diffusione della query all interno della WSN tale da garantire a priori il tempo di esecuzione di una query. Successivamente è stata definita l architettura del sistema e sono state individuate le sue principali funzionalità. Queste ultime sono state poi mappate sui vari componenti hardware. Infine sono state individuate le varie componenti software da implementare, nonché la loro collocazione all interno del sistema distribuito. In questa fase si è posta particolare attenzione a suddividere la struttura dati dalla logica funzionale del sistema, in modo da soddisfare requisiti non funzionali quali l estensibilità e l adattabilità. 4.1 Definizione del problema Come previsto per la comunicazione wireless tra i nodi della rete si è utilizzato lo standard IEEE ed in particolare la sua implementazione in µwireless. Ciò, se da un lato ha limitato le scelte possibili per la topologia della rete, dell altro ha messo a disposizione l utile meccanismo dei GTS. Poiché µwireless non fornisce alcun meccanismo di routing tra i nodi e poiché l implementazione di tale meccanismo non era tra gli obiettivi della tesi, ci si è orientati verso una topologia a stella, in cui il SAP svolge il ruolo di coordinator e tutti gli altri nodi quello di device. Un esempio di rete in cui sono indicati i ruoli dei vari 33

43 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 34 Figura 4.1: Ruolo dei componenti hardware in MIRTES componenti hardware è riportato in figura 4.1. Nella figura è rappresentata anche la scelta architetturale di permettere nella rete la presenza contemporanea di device dotati di sensori differenti. Una limitazione dovuta a µwireless è l impossibilità di avere un associazione dinamica dei device, di conseguenza il coordinator dovrà essere programmato con la lista dei nodi (e relativi indirizzi) che saranno presenti nella WSN. L idea è di aggiungere nella memoria del coordinator anche informazioni sui sensori installati su ogni device. In questo modo sarà possibile sapere quanti di essi dovranno essere contattati per poter rispondere ad una query. Se poi si utilizza la trasmissione beacon-enabled con GTS, e si alloca un GTS per ogni nodo da contattare, sarà anche possibile conoscere il tempo esatto di esecuzione di ogni query. In realtà per ottenere le informazioni da un nodo sensore è necessario effettuare due comunicazioni, una di richiesta, dal coordinator al device, e una di risposta, dal device al coordinator. Per la seconda si utilizzano i GTS, mentre la prima viene inviata nel payload del beacon, e quindi in modalità intrinsecamente broadcast. Ciò è possibile

44 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 35 in quanto la richiesta è uguale per tutti i device da contattare. I nodi sensori non in grado di rispondere alla query, poiché privi della sensoristica necessaria ignoreranno la richiesta. L invio della richiesta nel payload del beacon offre numerosi vantaggi tra cui: ˆ evita la sincronizzazione temporale a livello applicativo tra SAP e nodi sensori; ˆ è per natura broadcast su banda garantita (tutti i device sono in ricezione durante l invio del beacon); ˆ è inviato dal nodo che amministra la banda. Per ragioni di semplicità si è deciso che un beacon conterrà al massimo una richiesta. Di conseguenza il tempo di esecuzione di una query sarà multiplo del periodo di beacon (T BI ), anche detto beacon interval. In particolare esso sarà pari all intero superiore della divisone tra il numero di device interessati dalla query (n q ) ed il numero di GTS allocati in ogni beacon interval (N GT S ) nq T q = T BI (4.1) N GT S Ovviamente poiché il numero massimo di GTS allocabili in un intervallo di beacon è pari a 7, si avrà N GT S 7. La scelta di un N GT S minore di 7 è giustificata nel caso si voglia eseguire sulla rete un altra applicazione con requisiti di banda garantita. Riassumendo, la diffusione di una query all interno della WSN e la raccolta dei relativi risultati segue i seguenti passi: 1 - al momento dell invio del beacon, il coordinator inserisce la richiesta nel payload e alloca i GTS ai primi N GT S device (ancora) da contattare; 2 - i device che hanno un GTS allocato rispondono al coordinator nel proprio GTS; 3 - il coordinator raccoglie le risposte dei nodi; 4 - se ci sono altri nodi da contattare, si torna al punto 1, altrimenti l esecuzione della query è terminata e si possono inviare i risultati al PC. In figura 4.2 è riportato un esempio di esecuzione di una query che coinvolge 9 nodi. Come si può vedere vengono utilizzati 7 GTS (ciascuno composto da 2 time slot) per ogni beacon interval (N GT S = 7), di conseguenza la durata della query è di 2 BI. Come visto utilizzando questo metodo il tempo di esecuzione di una query sarà multiplo del periodo del beacon, che quindi può essere visto come il tempo di clock di

45 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA Beacon with coordinator request and GTS descriptors Device 1 response Device 2 response Device 3 response Device 4 response Device 5 response Device 6 response Device 7 response Device 8 response Device 9 response Legend GTS Beacon Frame Data Frame Figura 4.2: Esempio di diffusione della richiesta e raccolta dei risultati una CPU. Si può creare un parallelismo tra una query che viene diffusa nella rete ed un task che viene eseguito su una CPU: alla query vengono assegnati dei beacon interval, al task dei tick di CPU. Ciò permette di pensare al problema della schedulazione di query come a quello della schedulazione di task, problema ampiamente studiato in letteratura. In particolare per la schedulazione di task periodici con deadline uguale al periodo esiste una soluzione ottima, l algoritmo di schedulazione Earliest Deadline First (EDF)[33]. Esso prevede che in ogni istante il task in esecuzione sia quello con la deadline assoluta più imminente. Si tratta dunque di un algoritmo di schedulazione che prevede la possibilità di preemption tra task. Questa è facilmente implementabile nel caso delle query, è infatti possibile interrompere la query al termine di ogni beacon interval, salvarne i risultati intermedi e riprenderne la diffusione successivamente. È quindi possibile utilizzare EDF per la schedulazione delle query. EDF ha anche il vantaggio di permettere le verifica della schedulabilità di un insieme di task periodici attraverso un semplice test di garanzia. Esso consiste nel verificare che la somma delle utilizzazioni dei singoli task (rapporto fra tempo di esecuzione del task e periodo) sia minore di uno: i C i T i 1 (4.2) Tale test può essere utilizzato anche per verificare la schedulabilità delle query, a patto di definire l utilizzazione di una query come il rapporto fra il numero di beacon interval che richiede ed il suo periodo (espresso in beacon interval). Poiché in MIRTES non dovranno essere eseguite solo query periodiche, ma anche query aperiodiche (seppur senza vincoli temporali) è necessario trovare un modo

46 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 37 per assegnare loro dei beacon interval senza violare i vincoli temporali delle query periodiche. Una soluzione è l utilizzo di un processo periodico (server) dedicato al servizio delle richieste aperiodiche. Tra i vari tipi server descritti in letteratura si è deciso di utilizzare il Total Bandwidth Server caratterizzato da un meccanismo di funzionamento particolarmente semplice ed efficiente. Esso prevede la definizione di un fattore di utilizzazione U s (banda) per gli aperiodici, ovvero di una percentuale di tempo dedicato alla loro esecuzione. Quando la k-esima richiesta aperiodica arriva al tempo t = r k essa riceve una deadline: d k = max(r k, d k 1 ) + C k U s, (4.3) dove C k è il tempo di esecuzione della richiesta aperiodica (numero di beacon interval richiesti per la diffusione della query). Il task aperiodico, ora dotato di una deadline fittizia, può essere schedulato assieme ai task periodici utilizzando EDF. Affinché l insieme dei task periodici ed aperiodici risulti schedulabile deve essere verificata la seguente condizione[34]: U p + U s 1, (4.4) dove U p è l utilizzazione totale dei task periodici. 4.2 Architettura del sistema Per la progettazione di MIRTES è stata adottata un architettura modulare a tre strati: ˆ livello di interfaccia; ˆ livello di controllo; ˆ livello di sensing. Ognuno di questi livelli può inizialmente essere visto come un unico grande componente (fig. 4.3). Ognuno di essi svolge le funzionalità di client rispetto al livello inferiore e quelle di server rispetto al livello superiore. Nei paragrafi seguenti vengono descritte le funzionalità di ogni livello Livello di interfaccia Il livello di interfaccia svolge essenzialmente due compiti: 1 - permettere all utente di inserire query;

47 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 38 Interface Control Sensing Environment Figura 4.3: Architettura a tre livelli del sistema 2 - visualizzare i risultati delle query. Entrambe queste funzionalità necessitano dello schema logico del database che astrarrà la WSN. Poiché viene definita una tabella per ogni grandezza fisica che può essere misurata dalla WSN, l interfaccia dovrà conoscere quali tipi di sensori sono presenti nella rete, ma non in che numero e su quali nodi. La conoscenza dello schema logico è richiesta dalla prima funzione per poter effettuare un controllo sulla validità semantica della query inserita dall utente. Invece, la seconda funzionalità necessita dello schema logico perché deve conoscere i nomi delle colonne e soprattutto il loro tipo, al fine di poter visualizzare correttamente i risultati della query. Il livello di interfaccia viene direttamente utilizzato dall utente e a sua volta utilizza direttamente il livello di controllo Livello di controllo Il livello di controllo è il principale responsabile per l esecuzione delle query. I suoi principali compiti sono:

48 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA tenere traccia delle risorse disponibili sulla rete (nodi presenti, banda disponibile, ecc.); 2 - diffondere la query nella rete e raccoglierne i risultati; 3 - processare i risultati della query (controllo delle condizioni ed esecuzione delle aggregazioni); 4 - garantire il rispetto dei vincoli temporali sulle query periodiche. Il punto 1 è funzionale per i punti 2 e 4. Infatti, come visto, per poter diffondere la query nella rete e stimare il suo tempo di esecuzione è necessario conoscere quanti e quali nodi dovranno essere contattati, quanta banda è al momento disponibile, ecc. La funzionalità al punto 2 è, come già detto, la più importante dell intero sistema. Alla sua progettazione è stato dedicato il paragrafo 4.1. Il punto 3 richiede la conoscenza dello schema logico del database. Infatti per effettuare aggregazioni o verificare condizioni su una certa colonna è necessario conoscerne il tipo, definito appunto dallo schema. Infine l ultimo punto implica la presenza di un idoneo meccanismo schedulazione delle query periodiche ed aperiodiche. Il livello di controllo viene utilizzato dal livello interfaccia e a sua volta utilizza il livello di sensing Livello di sensing Il livello di sensing ha lo scopo di effettuare misurazioni sull ambiente esterno e comunicarle al livello di controllo quando richiesto. Ciò può essere fatto in due modi: 1 - l ambiente viene monitorato ad intervalli regolari e quando arriva una richiesta da parte del livello di controllo viene comunicata l ultima misura disponibile; 2 - la misurazione viene effettuata direttamente al momento della richiesta da parte del livello di controllo. La prima modalità permette di ridurre i tempi di risposta, ma comporta un maggior consumo di energia dovuto al continuo monitoraggio. Questa modalità andrebbe dunque utilizzata solo quando il tempo di misurazione è elevato e dunque potrebbe creare un ritardo eccessivo nel sistema. La seconda modalità permette invece di ridurre il numero delle misurazioni e quindi il consumo di energia, tuttavia aumenta il ritardo nella risposta. Questa modalità va utilizzata solo quando il tempo di misurazione è trascurabile e si ha la garanzia che non comprometta il funzionamento real-time del sistema.

49 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA Mappatura delle funzionalità sui componenti hardware Il sistema è costituito da tre tipi di componenti hardware: 1 - i nodi sensori; 2 - il SAP/coordinator (che, sebbene possa utilizzare lo stesso hardware dei nodi sensori, viene distinto da essi per via della diversità dei suoi compiti); 3 - il personal computer. Il mapping dei tre livelli dell architettura è di tipo uno ad uno sui tre tipi di componenti hardware con l eccezione del livello di controllo che viene in parte mappato anche sui nodi sensori (fig. 4.4). Questi possono infatti eseguire direttamente la verifica delle condizioni sulle misurazioni, effettuando dunque un processamento parziale dei risultati della query. Ciò comporta due vantaggi: ˆ parte del lavoro di processamento viene distribuito nella rete riducendo il carico sul SAP/coordinator rispondendo al requisito non funzionale dell in-network processing (cfr ); ˆ nel caso la misurazione non soddisfi la condizione, il nodo sensore può evitare di inviarla al coordinator in quanto non utile al risultato della query; ciò permette di ridurre il consumo di energia nel nodo che è un altro requisito non funzionale. 4.4 Definizione delle strutture dati Prima di passare alla progettazione dei componenti funzionali del sistema sono state definite le principali strutture dati che questi componenti andranno ad utilizzare. I due principali concetti che dovranno essere rappresentati nel sistema sono quello di database e quello di query. Le varie strutture dati sono state individuate dall analisi di questi concetti Strutture dati relative al DataBase Poiché il sistema dovrà fornire un astrazione della WSN come un database relazionale esso dovrà fornire le strutture dati necessarie alla definizione di un tale database. Le strutture dati individuate sono riportate nel diagramma delle classi in figura 4.5.

50 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 41 Interface :PC 1. Inserimento query 2. Visualizzazione risultati Control :SAP/Coordinator 1. Gestione risorse 2. Diffusione query 3a. Aggregazione query 4. Supporto real time Control :Device 3b. Verifica condizioni Sensing 1. Acquisizione misure Figura 4.4: Mappatura delle funzionalità sui componenti hardware

51 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 42 Figura 4.5: Strutture dati relative al concetto di database Classe TableSchema Logicamente parlando un database relazionale è un insieme di relazioni o tabelle. La classe TableSchema permette di definire la struttura di tali tabelle. Lo schema di una tabella è definibile come una sequenza ordinata di colonne (o attributi) aventi un tipo. L utilizzo di MIRTES prevede che ad ogni grandezza fisica misurabile dalla WSN venga associato uno schema di tabella, il che consiste nella creazione di un oggetto di tipo TableSchema.

52 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 43 Classe Column La classe Column rappresenta il concetto di attributo o colonna di una tabella. Un istanza di Column deve avere un id ed un tipo tra quelli definiti nel sistema. La definizione di uno schema di tabella per un certo sensore prevede l istanziazione di uno o più oggetti di tipo Column. Ad esempio lo schema per definire l accelerazione conterrà tre colonne: Xvalue, Yvalue e Zvalue. A queste va aggiunta la colonna NodeId che dovrà essere presente in ogni tabella. Classe Type Come visto una colonna dovrà avere associato un tipo. Generalmente un database mette a disposizione un insieme ben definito di tipi tra cui scegliere. Tuttavia in MIRTES si vuole lasciare piena libertà all utilizzatore del sistema, di conseguenza non vengono definiti dei tipi base, ma solo una classe da poter istanziare, la classe Type. Per definire un tipo si dovrà creare un istanza di Type indicando un id e la dimensione in byte del tipo. Al tipo potranno poi essere associate delle aggregazioni o delle condizioni. Interfaccia IAggregation Come visto ad un tipo possono essere associate una o più aggregazioni. Anche le aggregazioni possibili, come i tipi, non vengono stabilite a priori da MIRTES, ma anch esse possono essere definite a seconda delle specifiche esigenze. Tuttavia le aggregazioni, a differenza dei tipi, non sono solo strutture dati, ma hanno anche una componente funzionale, che è il metodo di calcolo dell aggregazione. Di conseguenza per le aggregazioni viene definita un interfaccia (IAggregation) e non una classe. IAggregation dichiara il metodo aggregate() che ha il compito di calcolare l aggregazione. L aggiunta di un particolare tipo di aggregazione a MIRTES richiede dunque la definizione di una classe che implementi l interfaccia IAggragation e quindi definisca il metodo aggregate(). Le istanze delle classi dovranno essere dei singleton, in quanto non ha senso avere più istanze dello stesso tipo di aggregazione. Interfaccia ICondition Per le condizioni, analogamente alle aggregazioni, è stata definita l interfaccia ICondition che dichiara il metodo verify(), il quale dovrà restituire vero o falso Strutture dati relative alle query Il sistema dovrà gestire delle interrogazioni sui dati in esso organizzati. Le strutture dati individuate sono riportate in figura 4.6. Come si può notare esse contengono

53 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 44 Figura 4.6: Strutture dati relative al concetto di interrogazione e loro relazioni con le altre strutture dati riferimenti alle classi precedemente individuate, ciò è dovuto al fatto che il concetto di interrogazione è legato a quello di database. Classe Query La classe query rappresenta un interrogazione semplice o aggregata. In MIRTES non sono previste interrogazioni di tipo join o union, ma solo selezioni e proiezioni semplici. Di conseguenza la classe Query contiene il riferimento ad una sola istanza di TableSchema e ad una sequenza ordinata di oggetti di tipo SelectedColumn. È inoltre presente l attributo period che serve a contenere il periodo delle query periodiche. Una query aperiodica avrà zero come valore di period. Classe SelectedColumn La classe SelectedColumn rappresenta un colonna selezionata in una interrogazione. Un oggetto di tipo SelectedColumn deve contenere un riferimento ad un istanza della

54 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 45 classe Column. Inoltre poiché un interrogazione può prevedere condizioni o aggregazioni su una colonna, un oggetto di tipo SelectedColumn potrà contenere un insieme di oggetti di tipo SelectedAggregation e di tipo SelectedCondition. Classe SelectedAggregation La classe SelectedAggregation permette di rappresentare un aggregazione indicata in una query. Essa contiene un riferimento ad un oggetto che implementa l interfaccia IAggregation. Inoltre poiché la query può specificare delle condizioni sul risultato dell aggregazione, un oggetto di tipo SelectedAggregatin potrà contenere un insieme di istanze della classe SelectedCondition. Classe SelectedCondition Come anticipato una interrogazione può contenere specifiche condizioni sui valori di una certa colonna e sui risultati di un aggregazione. La classe SelectedCondition permette di rappresentare tali condizioni. Una SelectedCondition contiene il valore della condizione ed il tipo, ovvero un riferimento ad un oggetto che implementa l interfaccia ICondition. 4.5 Definizione delle componenti software La definizione dei componenti software è stata effettuata analizzando le funzionalità previste per ogni componente hardware Componenti del client PC In figura 4.7 sono riportati i componenti software del client PC. Essi forniscono tutte le funzionalità del livello Interface, ovvero permettono di inviare query al SAP/coordinator e di visualizzarne i risultati. Il componente centrale è QueryManager il cui funzionamento è il seguente: 1 - riceve in ingresso una stringa rappresentante una query SQL; 2 - utilizza il componente Parser per parsarla e verificarne la correttezza sintattica e semantica; 3 - invia la query al SAP/coordinator tramite il componente PCCommLink, che gestisce il link di comunicazione tra PC e SAP/coordinator; 4 - riceve dal PCCommLink il risultato della query;

55 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 46 Figura 4.7: Componenti software del client PC 5 - visualizza il risultato della query tramite il componente ResultVisualizer. Come si può vedere dalla figura il Parser utilizza il componente DBDescriptor, che permette l accesso allo schema del database, necessario per effettuare il controllo sulla correttezza semantica delle query SQL Componenti del coordinator I componenti software del coordinator (fig. 4.8) forniscono le funzionalità del livello Control, ad eccezione della verifica delle condizioni sui valori delle misure, effettuata direttamente dai device. Quando il client PC invia una query al SAP/coordinator, essa viene analizzata dal componente Analyzer che effettua le seguenti operazioni: 1 - individua quali sono i nodi coinvolti dalla richiesta utilizzando il componente RemoteSensorManager; 2 - calcola il tempo di esecuzione della query; 3 - individua il tipo di query e: nel caso di query periodica la invia al componente PeriodicQueryManager;

56 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 47 Figura 4.8: Componenti software del coordinator

57 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA nel caso di query aperiodica la invia al componente TBS. Il RemoteSensorManager contiene le informazioni sui device presenti nella rete e sui sensori in essi installati. In particolare permette di sapere quali sono le grandezze misurabili dalla WSN e quali nodi sono in grado di fornire tali misurazioni. Il componente PeriodicQueryManager gestisce l attivazione periodica delle query. Inoltre tiene traccia dell attuale utilizzazione della rete ed effettua un controllo di schedulabilità sulle nuove richieste periodiche. Il componente TBS gestisce invece le richieste aperiodiche, assegnando ad esse una deadline secondo le modalità previste dal Total Bandwidth Server (cfr. 4.1). Entrambi questi componenti utilizzano poi il componente EDFScheduler per schedulare le query. Esso implementa la schedulazione EDF (cfr. 4.1), ovvero garantisce che in ogni momento la query in esecuzione sia quella con deadline assoluta più imminente, a tal fine implementa anche un meccanismo di preemption tra query. Per eseguire le query l EDFScheduler utilizza il componente RemoteQueryProcessor. Il RemoteQueryProcessor è il componente responsabile per la diffusione dell interrogazione nella WSN, la successiva raccolta dei risultati e il loro processamento (esecuzione di aggregazioni e verifica delle condizioni sui risultati di tali aggregazioni). Il metodo di diffusione della query e raccolta delle risposte è quello descritto in 4.1. A tal fine il RemoteQueryProcessor utilizza le funzionalità dello standard IEEE messe a disposizione dalla libreria µwireless. Infine il componente CoordinatorCommLink viene utilizzato sempre dal Remote- QueryProcessor per inviare il risultato delle query al client PC Componenti dei device Ogni device avrà i componenti software mostrati in figura 4.9. Essi forniscono le funzionalità del livello Sensing e la verifica di condizioni sulle misure che invece appartiene al livello Control. Il componente principale è il LocalQueryProcessor che quando riceve una query dal SAP/Coordinator svolge le seguenti operazioni: 1 - ottiene le misurazioni richieste nella query utilizzando il componente LocalSensorManager; 2 - verifica le eventuali condizioni su tali misure; 3 - se le condizioni sono soddisfatte invia le misurazioni al SAP/coordinator tramite il componente µwireless. Il LocalSensorManager è il componente che effettivamente si occupa di effettuare la lettura dei sensori, secondo una delle due modalità descritte in

58 CAPITOLO 4. PROGETTAZIONE DEL SISTEMA 49 Figura 4.9: Componenti software del device