Académique Documents
Professionnel Documents
Culture Documents
Relatori: Controrelatore:
Prof. Stefano Chessa Prof. Vincenzo Ambriola
Ing. Claudio Borean
Candidato:
Alessandro Belleggia
GRAZIE!
3
6.3.4. ServerThread...........................................................................................93
6.3.5. Node .......................................................................................................96
7. Riferimenti ...........................................................................................................97
4
Indice delle figure
Figura 1 Logo ZigBee .................................................................................................12
Figura 2 Certificazioni ZigBee ....................................................................................13
Figura 3 Routing reattivo in una rete mesh ..................................................................16
Figura 4 Confronto tra lo stack ZigBee e lo stack Bluetooth ........................................17
Figura 5 Collocazione degli standard wireless in base a distanza e capacità tramissiva 18
Figura 6 Ambiti applicativi di ZigBee .........................................................................21
Figura 7 Home Automation .........................................................................................21
Figura 8 Industrial plant monitoring ............................................................................22
Figura 9 ZigBee stack..................................................................................................24
Figura 10 Tipologie di rete ..........................................................................................27
Figura 11 Tipologie di routing .....................................................................................28
Figura 12 Indirizzamento diretto..................................................................................32
Figura 13 Indirizzamento indiretto...............................................................................33
Figura 14 Rapporto tra ZigBee Cluster Library ZigBee Profile ....................................34
Figura 15 Schema di un cluster ....................................................................................37
Figura 16 Trasmissione dati.........................................................................................41
Figura 17 Tipi di una primitiva ....................................................................................41
Figura 18 Pacchetto APS e ZCL ..................................................................................43
Figura 19 Formato del comando "Read attributes" .......................................................43
Figura 20 Zig Bee Home Gateway...............................................................................46
Figura 21 Composizione tipica di una casa ..................................................................52
Figura 22 Frammento del foglio di calcolo ..................................................................53
Figura 23 Frammento con i risultati ottenuti ................................................................55
Figura 24 Visualizzazione del foglio di calcolo ottenuta nascondendo alcune colonne .57
Figura 25 Risultati .......................................................................................................58
Figura 26 Architettura di sistema .................................................................................60
Figura 27 Gateway stack .............................................................................................62
Figura 28 Diagrammi di flusso relativi alla Device Discovery .....................................69
Figura 29 Diagrammi di flusso relativi alla Service Discovery.....................................70
Figura 30 Dongle USB - ZigBee fornito da Integration................................................71
Figura 31 Interfaccia grafica ........................................................................................73
Figura 32 Architettura applicativa ...............................................................................74
Figura 33 Rappresetazione a oggetti ............................................................................76
Figura 34 Schema riassuntivo ......................................................................................80
Figura 35 Finestra del browser ....................................................................................82
Figura 36 Memorizzazione dei dati..............................................................................84
Figura 37 Documento XML ........................................................................................85
Figura 38 Gruppo del progetto WSN-C .......................................................................88
Figura 39 Due tipi di driver .........................................................................................89
Figura 40 Nodo BM MOD 01......................................................................................90
Figura 41 Scheda di prova BM ....................................................................................91
5
Indice delle tabelle
Tabella 1 Caratteristiche di ZigBee contro quelle di Bluetooth ....................................19
Tabella 2 Home Controls Stack Profile ........................................................................29
Tabella 3 Dispositivi previsti in Home Automation Profile ..........................................36
Tabella 4 Cluster supportati da On/Off Switch.............................................................37
Tabella 5 Cluster supportati da On/Off Light ...............................................................38
Tabella 6 Attributi del server del cluster On/Off ..........................................................38
Tabella 7 Comandi ricevuti dal server del cluster On/Off.............................................39
Tabella 8 Elenco dei comandi ZCL generici ................................................................44
Tabella 9 Cluster supportati da Remote control ...........................................................47
Tabella 10 Dispositivi interfacciabili con un Remote control .......................................49
Tabella 11 Node descriptor..........................................................................................64
Tabella 12 Power descriptor ........................................................................................64
Tabella 13 Simple descriptor .......................................................................................65
6
1. Introduzione
Il presente elaborato espone l’esperienza di tesi che ha avuto luogo a Torino da luglio a
dicembre 2006 presso un’importante azienda operante nel settore delle
telecomunicazioni. Quest’ultima indirizza importanti investimenti nella ricerca e
sviluppo e dedica particolare interesse alle Wireless Sensor Networks (in italiano “reti
di sensori senza fili”). Una WSN è un sistema complesso che nasce dalla cooperazione
tra diversi oggetti elementari, detti nodo sensore. Un nodo sensore è dispositivo
elettronico in grado di svolgere in modo autonomo un certo insieme di operazioni più o
meno complesse, di interagire con l'ambiente circostante e di cooperare con gli altri
nodi per mezzo di opportune interfacce di comunicazione senza fili. Tali nodi sono
equipaggiati di sensori (temperatura, umidità, accelerazione, presenza, ecc.) o attuatori
(interruttori, potenziometri, motori, ecc.), o di entrambe se necessario, e di una
interfaccia radio. I nodi sensori monitorano l'occorrenza di determinati eventi di
interesse nell'ambiente e comunicano queste informazioni, tramite gli altri nodi, al sink
(scarico o pozzo). I sink hanno il compito di raccogliere le informazioni, processarle e,
se opportuno, ritrasmetterle verso altre reti, svolgendo in tal caso il ruolo di gateway. Le
reti di sensori nascono per esigenze militari quando, durante la guerra fredda, furono
utilizzate per la prima volta dalla difesa americana per monitorare gli spostamenti dei
sottomarini sovietici [SOSUS]. Le moderne ricerche condotte sulle reti di sensori senza
fili iniziarono nel 1980 con le DNS (reti di sensori distribuiti) progettate dall'agenzia
governativa del Dipartimento della Difesa degli Stati Uniti, DARPA (Defence
Advanced Research Projects Agency). Al di là degli scopi militari, le WSN possono
essere utilizzate per monitorare aree a rischio (ad esempio rivelare tempestivamente
incendi boschivi), controllare impianti industriali e non ultimo per realizzare
un’interazione tra ambiente e persona, facendo in modo che l’ambiente reagisca e si
adattati alla presenza e alle esigenze dell’utente in modo automatico. Scenari futuristici,
inoltre, prevedono l'utilizzo delle WSN in ambito medico, attraverso l'impianto
nell'organismo di minuscoli nodi sensore in grado di monitorare i parametri vitali della
persona e somministrare la terapia farmacologica in modo autonomo, quando
necessario. Importanti progetti sono stati portati avanti da numerosi istituti universitari
di tutto il mondo e questo rende abbondante la letteratura in questo settore.
L’eterogeneità e la limitatezza delle risorse dei nodi sensori, in termini di energia,
7
potenza di calcolo e memoria, richiedono una progettazione accurata della struttura e
dei protocolli di gestione della WSN in relazione all'applicazione specifica da
realizzare. Il risultato è lo sviluppo di soluzioni precisamente disegnate per
l’applicazione per cui il sistema è concepito e difficilmente adattabili a scenari operativi
diversi. Queste caratteristiche ostacolano l’abbattimento dei tempi e dei costi di
sviluppo di nuove applicazioni per WSN, rallentando di conseguenza la crescita del
settore in ambito aziendale. Al fine di superare queste difficoltà oggettive, nel dicembre
2004, dopo due anni di lavoro, la ZigBee Alliance, una associazione di oltre un
centinaio di aziende, ha immesso sul mercato la prima una soluzione completa per reti
di sensori. Gli investitori nutrono la speranza che, sulla base dello standard ZigBee,
dispositivi di produttori diversi possano integrarsi tra loro in modo spontaneo in modo
da gettare le basi affinché questa tecnologia diventi pervasiva. In un futuro non troppo
lontano sarà possibile acquistare dei dispositivi con il marchio ZigBee direttamente dai
fornitori di materiale elettrico e attivare un sistema di monitoraggio e controllo senza
dover subire una fase di progettazione e senza dover prevedere l'installazione di cavi e
centraline di controllo all'interno dei muri o sotto i pavimenti flottanti. Se si pensa ad
apparecchi ambientali come per esempio le luci, gli interruttori, i telecomandi, i sensori
di presenza, le serrande automatiche, gli impianti di riscaldamento e raffreddamento, i
sensori di temperatura, i sistemi antintrusione, ecc. si comprende quanto le Wireless
Sensor Netwoks possano rivelarsi utili per tutto il mondo domestico, commerciale e
industriale, attualmente privo della possibilità di controllare in maniera così granulare le
infrastrutture basilari della propria realtà.
8
1.1. Scenario e obbiettivi
Il mercato delle reti di sensori presenta possibili interessi per l’operatore di
telecomunicazioni. Nell’ottica accennata nel precedente paragrafo, l’operatore confida
sulla possibilità di fornire l’accesso a tali reti. L’idea di business si fonda sul fatto che
uno sviluppatore di applicazioni per WSN, piuttosto che creare la propria applicazione
di controllo ex novo, si affidi alla piattaforma di servizio fornita dall’operatore di
telecomunicazioni per creare la propria piattaforma applicativa. Parte imprescindibile di
tale architettura è il gateway il quale permette all’operatore di interagire con la rete di
sensori necessariamente basata sullo standard ZigBee. Molteplici sono gli apparati a cui
è possibile affidare il compito di veicolare il traffico proveniente dalla WSN verso la
piattaforma di servizio e viceversa. In ambito domestico sono già presenti dispositivi
come il modem ADSL, il videotelefono o il set top box (il cosiddetto decoder per la
televisione via internet), tutti con capacità IP, ai quali non risulta difficile aggiungere la
funzionalità di accesso alle reti ZigBee. In questa maniera un utente domestico ha
l’opportunità di acquistare, anche in tempi diversi, i dispositivi marchiati ZigBee di
qualsiasi produttore, di installarli in casa, in alcuni casi senza l’intervento di un tecnico
specializzato, e di gestire la propria rete di sensori scegliendo la piattaforma applicativa
che meglio soddisfi le proprie esigenze. Questo utente apprezzerà particolarmente
scoprire che il suo videotelefono ha il marchio ZigBee e che quindi può svolgere la
funzione di gateway senza introdurre ulteriore dispositivo in casa. È in questa visione
che aderire ad uno standard comune diviene, per l’operatore, fondamentale. Nell’ultimo
anno i produttori di apparati conformi a ZigBee hanno sostanzialmente fatto esperienza
con la tecnologia: da queste esperienze sono nati alcuni miglioramenti di ZigBee che
sono stati integrati nella nuova versione delle specifiche. Quest’ultima differisce dalla
precedente per l’introduzione dei profili applicativi, per ognuno dei quali sono elencati i
dispositivi appartenenti e i messaggi che tali dispositivi si scambiano tra loro per
realizzare l’applicazione. La vasta copertura di ogni profilo assicura che nessuna
applicazione debba essere sviluppata ricorrendo solo a messaggi di tipo proprietario. Il
secondo capitolo sviluppa dettagliatamente lo standard ZigBee.
9
1.2. Riassunto
10
dispositivi dovuta allo standard. Le due principali macro che il gateway fornisce sono
Device discovery (ricerca dei nodi) e Service discovery (ricerca dei sevizi) e tali
funzionalità sono state proposte al ZigBee Gateway Working Group (il gruppo interno a
ZigBee che si occupa di standardizzare il gateway). L’output delle macro precedenti è
restituito alla piattaforma di servizio mediante l’uso di un formalismo chiamato REST
(REpresentational State Transfer) che usa HTTP come trasporto dei dati e XML per la
loro rappresentazione. Il gatway permette anche alla piattaforma di servizio di interagire
con ogni singolo nodo mediante un formalismo tuttora in fase di definizione.
L’applicazione è stata sviluppata utilizzando Visual Studio .NET 2003 ed è stata scritta
in C++ in quanto la libreria di interfacciamento con il dispositivo ZigBee (un dongle
USB fornito da Integration) è strettamente legata a questo ambiente.
11
2. Standard ZigBee
ZigBee è il nome di un’alleanza commerciale nata per sviluppare prodotti affidabili, di
basso costo, con basso consumo energetico, senza fili, basati su di un standard aperto e
globale per il monitoraggio e il controllo di ambienti.
Questo è il marchio tratto dal sito [ZigBee.org]: è evidente la volontà di creare uno
standard davvero efficace. Nelle applicazioni di monitoraggio e controllo sussiste la
possibilità di avere migliaia di dispositivi in uno spazio relativamente piccolo e ciò
rende necessaria l’adozione di un mezzo trasmissivo senza fili e di una alimentazione
tramite batteria. Altresì necessario è ridurre il consumo di energia per garantire un
autonomia apprezzabile. Non per ultimo occorre assicurare un basso costo del
ricetrasmettitore. Per soddisfare queste premesse lo standard ZigBee si basa sullo
standard IEEE 802.15.4 per implementare gli strati più bassi della sua pila protocollare.
Anche se spesso si tende a confondere ZigBee con IEEE 802.15.4 è bene iniziare la
descrizione introducendo una immagine che esponga i criteri di certificazione della
ZigBee Alliance. Il programma di certificazione ha lo scopo di classificare i prodotti in
base al grado di conformità allo standard ZigBee in modo da fornire chiarezza agli
utenti e al mercato. Esistono due diversi tipi di certificazione:
12
Figura 2 Certificazioni ZigBee
ZigBee Manufacturer Specific Profile Test Program, questo test dimostra che il
prodotto opera in un sistema chiuso ma è capace di coesistere con altri prodotti
ZigBee,
Public Profile Test Program, questo test dimostra che il prodotto assicura
l’interoperabilità con altri prodotti ZigBee.
13
usare dei profili privati, chiamati Manufacturer Specific Application Profiles, per
confezionare l’applicazione secondo le proprie necessità.
Riassumendo la ZigBee Alliance fornisce gli alti livelli della pila protocollare, i profili
applicativi, i test di conformità e di certificazione e il marchio.
2.1. Descrizione
Questo paragrafo affronta in maniera generale lo standard ZigBee e cerca di fornire una
visione globale per evitare di appesantire la descrizione con le specifiche tecniche.
2.1.1. Caratteristiche
ZigBee permette di produrre dispositivi a basso costo grazie alla semplicità del
protocollo da implementare che richiede limitate risorse hardware. In particolare è
possibile scegliere il tipo di nodo in base al ruolo che esso avrà nella rete. Nel paragrafo
successivo verrà introdotta la distinzione tra FFD (Full Function Device) e RFD
(Reduced Function Device).
ZigBee opera su frequenze libere della banda UHF (868 e 915 MHz) e ISM (2.4 GHz),
con velocità di trasmissione dati che arrivano al massimo a 250 kbit/s. Il raggio di
azione non supera le decine di metri su single-hop, ma si estende a chilometri se si
sfrutta il multi-hop, cioè la possibilità di far transitare l’informazione da un nodo
all’altro fino al nodo destinazione, che, non trovandosi nel raggio d’azione del nodo
sorgente, non può essere raggiunto direttamente.
14
il loro ruolo all’interno della rete stessa, e pervasive, con un numero di nodi molto
elevato (nominalmente fino a 65536). Sono previste diverse tipologie di reti che non si
limitano a semplici configurazioni a stella (star), ma supportano anche reti magliate
(mesh) e reti a tipologia mista (cluster tree). Queste tre tipologie di rete verranno
esaminate nei prossimi paragrafi.
ZigBee supporta l’utilizzo della tipologia di rete mesh che permette di massimizzare
l’affidabilità complessiva della rete, garantendo la possibilità di distribuire
l’informazione su percorsi diversi. L’instradamento dei messaggi è sempre possibile
anche quando la topologia della rete cambia a causa della perdita di un nodo. Questa
caratteristica deriva dalla capacità delle reti ad-hoc di essere auto configurabili. Le
quattro immagini sottostanti della figura 3 rappresentano in sequenza cosa accade
quando dei nodi scompaiono dalla rete.
Dal punto di vista della sicurezza la protezione dei dati è garantita da algoritmi di
crittografia avanzati (AES a 128 bit) e da meccanismi di integrità e autenticazione per
proteggere il tutto da eventuali attacchi provenienti da dispositivi non autorizzati che
tentano di accedere alla rete o al contenuto informativo trasmesso. E’ definito anche un
concetto di Trust Center, per la gestione centralizzata della sicurezza, a livello di
politiche e aggiornamento delle chiavi crittografiche.
15
Figura 3 Routing reattivo in una rete mesh
16
unire più piconet, creando una scatternet, ad esempio creando una gerarchia di master o
facendo condividere a due o più masters uno stesso slave. Tali soluzioni sono
sconsigliate per l’elevata latenza di trasmissione. In confronto Zigbee prevede la
possibilità di connettere al più 65536 nodi attraverso un unico coordinatore di rete
utilizzando la modalità di indirizzamento ridotta.
ZigBee, d’altra parte, è ottimizzato per connettere un elevato numero di dispositivi che
comunicano sporadicamente tra di loro e che per le loro comunicazioni non necessitano
di banda elevata (ZigBee offre 250 Kbit/s, mentre Bluetooth arriva ad 1 Mbit/s). Inoltre,
le modeste prestazioni richieste ad una rete ZigBee permettono di avere una logica di
elaborazione meno costosa di Bluetooth.
17
Figura 5 Collocazione degli standard wireless in base a distanza e capacità
tramissiva
Per quanto riguarda i tempi, Bluetooth impiega 3 s per unirsi alla rete, 20 s per il
riconoscimento di tutti i dispositivi, ma soli 2 ms per accedere al canale. ZigBee
garantisce tempi di risveglio e di enumerazione dei dispositivi in rete di circa 30 ms,
contro tempi di accesso al canale di 15 ms. La latenza impiegata da Bluetooth lo rende
inaccettabile per applicazioni di monitoraggio o attuazione.
Di seguito viene riportata una tabella in cui sono riassunte le caratteristiche dei due
standard a confronto.
18
Frequency 868 MHz (in Europa) 2.4 GHz
915 MHz (in America)
2.4 GHz (worldwide)
Range 10-100 m 10 m
19
Tra le periferiche per PC, come mouse e tastiere, Bluetooth ha scarso successo a causa
dei suoi elevati costi e complessità e Zigbee può essere considerato come un potenziale
concorrente perché è più economico e prolunga la durata delle batterie.
Per questi motivi, Bluetooth e ZigBee sono da considerarsi come due tecnologie
complementari, concepite per ambiti applicativi diversi.
2.1.3. Applicazioni
Il campo di applicazione è vastissimo sia in ambito “indoor” che “outdoor” e va dalla
domotica all’automazione industriale, dall'elettronica di consumo al Machine to
Machine (M2M), fino alle reti di sensori per il monitoraggio dell’ambiente. Nella figura
6 sono indicate le principali aree applicative, tra cui particolarmente interessanti sono
anche gli utilizzi nel settore dell’health-care per la teleassistenza ed il monitoraggio dei
pazienti in ambito bio-medicale, ma in generale per applicazioni in cui i sensori ZigBee
sono pensati per migliorare la qualità della vita di ciascun individuo.
20
Figura 6 Ambiti applicativi di ZigBee
21
In ambito Commercial building automation valgono circa le stesse idee che valgono
per l’home automation ma si immagina che questo settore sia quello che più di tutti
possa trarre benefici in termini non solo di possibilità di controllo dettagliato dei vari
sistemi ma soprattutto in ottica di risparmio energetico: basti pensare al risparmio in
termini di denaro dovuto alla capacità di controllore i sistemi di illuminazione, di
riscaldamento e condizionamento in base alla presenza fisica. Da non trascurare poi
l’opportunità di controllare gli accessi, i sistemi di sicurezza (antintrusione, antincendio,
ecc.).
Per non trascurare il motivo per cui sono nate le WSN, ZigBee prevede il profilo
applicativo Wireless sensor applications con il quale dettare le specifiche per il
monitoraggio ambientale, come boschi, aree agricole e urbane, o di strutture artificiali
come ponti, dighe, gallerie, edifici e monumenti artistici.
22
Il profilo applicativo Telecom Applications coprirà la necessità degli operatori di
telecomunicazioni di offrire nuovi servizi a valore a aggiunto (i cosiddetti Value Added
Service) basati su reti ZigBee. Casi d’uso che coinvolgono i terminali mobili possono
essere il controllo e il monitoraggio remoto della casa, la consegna di messaggi relativi
al contesto in cui ci si trova l’utente (sia di carattere informativo sia pubblicitario),
l’introduzione di nuove forme di pagamento elettronico, l’integrazione dei dispositivi
mobili con infrastrutture dedicate alla salute (trattate poche righe più avanti) e lo
sviluppo di nuovi giochi multiplayer.
In futuro sarà possibile monitorare le funzioni vitali del corpo umano come l’attività
cardiaca o respiratoria mediante sensori sia per scopi terapeutici (monitoraggio dei
pazienti sia in ospedale sia in casa) sia per scopi sportivi (monitoraggio delle prestazioni
di un atleta): a tale fine ZigBee prevede uno specifico profilo chiamato Personal/home
health care.
23
2.2. ZigBee 2004
Questo paragrafo è destinato a scendere maggiormente nel dettaglio dello standard. A
questo scopo si introduce direttamente l’immagine seguente che illustra la pila
protocollare ZigBee. I successivi sottoparagrafi analizzano i rispettivi livelli
concentrando l’attenzione sugli aspetti che hanno maggiore attinenza al lavoro di tesi
descritto nei capitoli 3 e 4.
24
802.15.4, infatti supporta data rate compresi tra 20 e 250 kbps in funzione di quale delle
tre differenti radio frequenze viene usata al livello PHY (868 MHz, 915 MHz o 2.4
GHz). Il livello fisico si occupa di attivare o disattivare il ricetrasmettitore, di
selezionare e controllare il canale, di trasmettere e ricevere i pacchetti di informazione
attraverso il mezzo fisico (l’hardware). Il livello datalink si occupa di generare i segnali
di sincronizzazione (beacons) se il dispositivo è coordinatore (più avanti è presente una
descrizione dei tipi di dispositivi previsti dallo standard), di gestire la connessione o
disconnessione alla rete, di eseguire l’algoritmo CSMA/CA per evitare le collisioni tra
dispositivi che vogliono accedere al canale nello stesso momento e di fornire bassa
latenza alle applicazioni che lo richiedono tramite l’uso dei GTS, ovvero degli slot
temporali ad accesso prioritario.
Una LR-WPAN può includere due diversi tipi di dispositivi: FFD (Full Function
Device) e RFD (Reduced Function Device). I dispositivi FFD implementano l’insieme
completo delle primitive del livello MAC, mentre gli RFD ne implementano solo una
versione ridotta, pensata per svolgere compiti elementari in modo da limitare le risorse
hardware necessarie. Un dispositivo FFD può dialogare con dispositivi di entrambe le
categorie, mentre un RFD può comunicare solo con un FFD. Una rete LR-WPAN
prevede la connessione sullo stesso canale fisico di almeno due dispositivi di cui almeno
uno deve essere un FFD per svolgere il compito di coordinatore della rete stessa. Un
dispositivo può eleggersi coordinatore semplicemente per essere il primo a comunicare
su un canale. E’ possibile anche che possano coesistere reti indipendenti nella stessa
regione di spazio operanti sullo stesso canale fisico. Allo scopo di evitare conflitti con
reti già precedentemente stabilite il coordinatore sceglie un identificatore di rete (PAN-
ID) grazie al quale è possibile gestire la comunicazione sia all’interno della stessa PAN,
sia tra PAN diverse. Ogni dispositivo interno alla rete possiede un indirizzo esteso a 64
bit detto “indirizzo MAC”.
25
La modalità di formazione di una PAN rientra nel livello di rete (network layer)
previsto da ZigBee, per questo motivo si introduce il paragrafo successivo.
ZigBee supporta topologie di reti a stella, ad albero e a maglia. Le reti a stella sono
controllate dal coordinatore e non prevedono la presenza di router. Le reti ad albero,
dette anche cluster tree, hanno una struttura gerarchica con alla radice il coordinatore e
si avvalgono degli ZR per estendere la copertura attraverso l’instradamento multi-hop.
Le reti mesh sono organizzate in maniera decentralizzata: ogni ZigBee Router è
connesso ad uno o più ZigBee Routers o ZigBee End Devices.
26
Figura 10 Tipologie di rete
Le reti di tipo mesh non usano modalità di sincronizzazione (“non beacon mode”) che
garantisce alta dinamicità della rete e capacità di riassetto della topologia in tempi
contenuti. Le reti cluster tree invece adottano la modalità “beacon mode” e risultano più
efficienti dal punto di vista energetico. Tipicamente i router di una rete mesh devono
essere alimentati costantemente e sono in grado di memorizzare i pacchetti destinati ai
ZED a loro associati finché questi ultimi non si “svegliano”.
Mesh routing
Tree routing
Il principale beneficio del tree routing e la sua semplicità e il suo limitato uso di risorse.
Un router che usa questo algoritmo può svolgere la sua funzione semplicemente
guardando l’indirizzo di destinazione e scegliere se il successivo hop del pacchetto è
suo padre o uno dei suoi figli senza avere bisogno di memorizzare alcuna informazione.
Come conseguenza anche un router può essere implementato a basso costo e
mantenendo la conformità a ZigBee.
28
degli Stack Profiles è, al solito, garantire l’interoperabilità tra dispositivi che aderiscono
allo stesso profilo. La tabella 2 che segue è stata presa dalla specifica ZigBee
[ZBSpec04] ed elenca i valori del Home Controls Stack Profile limitatamente al livello
network.
Per concludere, questi punti riassumono i concetti base del livello network:
Sono previsti tre tipi di dispositivi logici, ZigBee Coordinator, ZigBee Router e
ZigBee End Device.
29
Sono previsti degli Stack Profile che configurano la rete agendo su alcune
variabili.
L’Application Support Sublayer è uno strato del livello applicativo che fornisce
principalmente due servizi: il trasporto dei messaggi applicativi tra due o più dispositivi,
attraverso l’interfaccia APS Data Entity, e la gestione del binding e di alcuni parametri
del livello APS stresso, tramite l’interfaccia APS Management Entity. La prima
interfaccia è disponibile sia agli Application Object, sia al ZigBee Device Object,
mentre la seconda è utilizzabile solo dallo ZDO.
Gli Application Object si trovano alla posizione più alta della pila protocollare e sono
definiti dai produttori per implementare la propria applicazione. Ogni Application
Object è identificato tramite un indice, endpoint, che va da 1 a 240, usato
dall’Application Support Sublayer per la consegna di messaggi. Gli endpoint 0 e 255
vengono usati rispettivamente per indirizzare il ZDO e per la funzionalità di broadcast,
cioè per recapitare un messaggio a tutti gli Application Objects.
30
2.2.4. Comunicazione tra le applicazioni
Come descritto precedentemente, l’Application Support Sublayer fornisce il supporto
per far comunicare gli Application Object. In particolare, esso definisce la struttura di
comunicazione usata dalle applicazioni introducendo i concetti di Application Profile e
di Cluster.
Un Application Profile descrive una collezione di dispositivi impiegati per una specifica
applicazione ed espone lo schema di scambio di messaggi tra questi dispositivi. I
dispositivi che appartengono ad un Application Profile comunicano tra di loro per
mezzo dei Clusters. Un Cluster specifica l’insieme degli attributi e dei comandi
disponibili di un determinato dispositivo che lo implementa. Essi sono di ingresso (in)
se il dispositivo offre la funzionalità, di uscita (out) se il dispositivo può disporre della
funazionalità. Ogni Application Profile è identificato da un id e ogni cluster è
identificato da un id all’interno di un determinato Application Profile. La ZigBee
Alliance prevede l’esistenza di profili applicativi pubblici, cioè quelli rilasciati dallo
standard, e di profili privati, cioè quelli sviluppati dai produttori (si veda l’introduzione
di questo capitolo riguardo ai vari tipi di certificazione). Per esempio, nel profilo
applicativo Home Control Lighting esistono una serie di dispositivi di cui è determinato
il formato dei messaggi attraverso la specifica dei Clusters.
In figura è riportata una possibile conformazione di una primitiva rete: sono presenti
due dispositivi sui quali sono alloggiati diversi Application Object. Il primo device
contiene due interruttori, il secondo contiene quattro lampade e le frecce che collegano i
rispettivi Application Object rappresentano il canale di comunicazione (di cui l’origine
è il cluter out e la fine della freccia è il cluster in).
31
Figura 12 Indirizzamento diretto
ZigBee risolve questi problemi introducendo l’indirizzamento indiretto per mezzo del
Binding. Il Binding consiste nel creare un collegamento logico tra un Application
Object e un altro Application Object grazie all’uso del concetto di cluster. In pratica
esiste una tabella di binding, residente nello ZigBee Coordinator, che tiene traccia delle
relazioni tra un cluster out di un AO e un cluster in di uno più AOs. La figura
rappresenta questa situazione: l’interruttore 1 invia il messaggio al coordinatore
specificano l’identificativo del profilo applicativo (profileID), l’identificativo del cluster
(clusterID), il suo indirizzo (sourceAddr) e il suo endpoint (sourceEP). Il coordinatore
accede alla binding table usando queste informazioni e ne trae gli indirizzi e gli
endpoints di destinazione che usa per spedire i messaggi (oppure il messaggio se il
destinatario è unico).
32
Figura 13 Indirizzamento indiretto
33
2.3. ZigBee 2006
I dispositivi prodotti in conformità alla prima versione della specifica ZigBee sono
serviti sostanzialmente per fare esperienza con la tecnologia. Come esposto nel
precedente paragrafo, la versione 1.0 ha stabilito la struttura della pila protocollare e ha
delineato i principi di comunicazione dei moduli applicativi. Gli sviluppatori hanno
dovuto creare i propri profili applicativi privati in quanto l’unico profilo pubblico
presente al momento del rilascio della prima versione era Home Control Lighting che
riuniva alcuni dispositivi per l’illuminazione. Gli sforzi dell’alleanza sono proseguiti per
fornire le specifiche per altri profili applicativi (di cui è gia stata data una descrizione
nel paragrafo 2.1.3). Come scritto poche righe più in alto in questo capitolo, un
Application Profile è sostanzialmente un documento che presenta l’insieme e la
descrizione dei dispositivi relativi ad un certo ambito applicativo. Per ogni dispositivo
esso elenca e dettaglia i Cluster implementati dal device. I progettisti si sono accorti ben
presto che molti cluster sono affini a vari Application Profile ed hanno deciso di
raggrupparli sotto il nome ZigBee Cluster Library. Questa è la sostanziale novità che ha
portato, il 1 dicembre 2006, alla ratifica della nuova specifica “ZigBee 2006”
[ZBSpec06] che sostituisce la precedente (disponibile sul sito della ZigBee Alliance
[ZigBee.org]). Questa specifica ha assunto in via informale l’appellativo “ZigBee ver.
1.1” durante la progettazione ed ora viene denominata ufficialmente “Enhanced
ZigBee”.
34
ecc.) e specificano per ogni cluster gli attributi, i comandi supportati e una descrizione
operativa. Gli Application Profiles (detti anche ZigBee Profiles) sono costruiti facendo
riferimento alle ZigBee Cluster Library: un profilo descrive i dispositivi di sua
competenza limitandosi ad elencare, per ciascuno di essi, i cluster implementati dal lato
server (precedentemente chiamati cluster in) e i cluster implementati dal lato client
(precedentemente chiamati cluster out).
La seguente tabella elenca alcuni i dispositivi finora previsti dal profilo Home
Automation.
Device Device ID
35
Reserved 0x0108 - 0x1FF
Shade 0x0200
Closures
Shade Controller 0x0201
Thermostat 0x0301
Pump 0x0303
HVAC
Zone 0x0402
36
Figura 15 Schema di un cluster
Le due tabelle sottostanti sono tratte dal documento “Home Automation Profile
Specification” e servono a mostrare quali cluster i dispositivi in considerazione devono
implementare per essere conformi allo standard.
37
Tabella 5 Cluster supportati da On/Off Light
38
Tabella 7 Comandi ricevuti dal server del cluster On/Off
Lo standard ZigBee stabilisce anche che alcuni server debbano poter notificare il valore
degli attributi, ad intervalli di tempo regolari, ad un altro dispositivo della rete: questo
servizio è noto sotto il nome di Attribute reporting. Il server del cluster On/Off dispone
dell’attributo OnOff che assume il significato di acceso quando è 1 e di spento quando è
0. Tale valore potrebbe essere notificato tramite il comando “Report Attribute” (di cui si
discuterà più avanti) a chi ne ha fa richiesta.
Quanto detto nel capitolo 2.2.4 non è più vero: l’identificativo associato ai cluster non
dipende dal profilo applicativo di appartenenza. Il clusterID ora identifica un cluster
globalmente e per garantire un quantitativo sufficiente di identificativi la nuova
specifica prevede che questo numero sia rappresentato su 16 bit invece che su 8 bit
come era nella specifica 2004. Questo rappresenta il vero limite alla retrocompatibilità
tra le due versioni in quanto modifica il formato dei messaggi applicativi.
L’esperienza maturata ha fatto anche rendere conto ai progettisti che non c’è nessun
motivo per cui l’Home Controls Stack Profile non possa essere adatto anche ad altri
contesti. Per questo motivo hanno deciso di mantenere nella nuova specifica 2006 solo
questo profilo chiamandolo semplicemente “ZigBee Stack Profile” eliminando
“Building Automation” e “Plant Control” che saranno inclusi in uno stack profile
dedicato.
39
nodo, tale livello si occupa di consegnarlo agli Application Object registrati a quel
preciso gruppo o altrimenti scartato.
L’uso dei gruppi è congeniale all’impiego delle scene: le scene consistono nel
memorizzare tutti gli attributi di tutti i cluster di tutti gli AO facenti parte di uno
specifico gruppo. L’uso delle scene rende possibile compiere numerose azioni con un
solo comando utente. Un esempio di destinazione ambientato in casa è quello di
configurare i dispositivi per la notte: chiusura delle serrande, impostazione del sistema
antintrusione con esclusione della camera da letto, spegnimento di tutte le luci, ecc.
Per completezza è bene aggiungere che la ZigBee Alliance sta lavorando ad un’altra
specifica (versione “professional”) che affiancherà nel 2007 la versione in esame per
coprire mercati industriali. Tale versione sarà orientata a più grandi e sofisticate reti e
supporterà un metodo di indirizzamento casuale con risoluzione dei conflitti e quindi un
diverso algoritmo di routing che comporterà la mancata compatibilità con la versione
2006 a livello di rete [Gilles Thonet]. È stato infatti riscontrato che l’algoritmo
presentato precedentemente soffre di instabilità al crescere delle dimensioni della rete
limitando di fatto il numero teorico di 65 mila nodi [EETimes].
40
Figura 16 Trasmissione dati
Tale schema di trasmissione dei messaggi (usato anche negli altri livelli dello stack)
prevede in totale quattro primitive: request, indication, response e confirm. In generale,
un certo livello dello stack esegue una primitiva del livello inferiore con tipo request. Il
livello inferiore elabora la richiesta e la invia al corrispondente livello del nodo
destinatario. Sul nodo destinatario, il livello interessato dalla ricezione provvede ad
inoltrare la primitiva con tipo indication al livello superiore. Quest’ultimo produce la
risposta e chiama la primitiva del livello inferiore con tipo response. Il livello inferiore
del nodo destinatario si occupa di far arrivare la risposta al livello corrispondente del
nodo mittente ed sul nodo mittente la primitiva conclude il suo cammino tornando al
livello superiore con tipo confirm. A questo schema generale sono consentite due
eccezioni: la prima si ha quando la primitiva non coinvolge altri nodi e quindi si
esaurisce con una request e una confirm; la seconda si ha quando, come nel caso
precedente, il livello superiore non genera una risposta ed è sufficiente un riscontro di
avvenuta ricezione (acknowledgement) per generare la primitiva con tipo confirm.
request
indication
response
confirm
41
APSDE-DATA.request { APSDE-DATA.indication {
DstAddrMode, DstAddrMode,
DstAddress, DstAddress,
DstEndpoint, DstEndpoint,
ProfileId, SrcAddrMode,
ClusterId, SrcAddress,
SrcEndpoint, SrcEndpoint,
asduLength, ProfileId,
asdu, ClusterId,
TxOptions, asduLength,
RadiusCounter asdu,
} WasBroadcast,
SecurityStatus
}
Il parametro “asdu” contiene il payload e l’acronimo sta per APS Data Unit. Un altro
parametro di interesse è il campo DstAddrMode che specifica il tipo di indirizzamento.
La specifica 2006 prevede, in aggiunta al metodo diretto e indiretto, anche
l’indirizzamento di gruppo: se questo parametro riporta il valore 0x01 allora il
parametro DstAddr contiene i 16 bit dell’identificativo del gruppo che verrà usato nella
maniera vista precedentemente. Altro parametro da specificare con la richiesta è
ClusterId: si tratta dell’identificatore del cluster usato dall’APS del nodo sorgente solo
nel caso di indirizzamento indiretto (per accedere alla tabella di binding), e
indubbiamente trasmesso all’APS del nodo di destinazione che eseguirà la primitiva
APSDE-DATA.indication.
Si coglie l’occasione per una breve digressione sul parametro DstAddrMode: tale
parametro è stato aggiunto anche alle primitive APSME-BIND.request e
APSMEUNBIND.request (e alle relative confirm) usate dallo ZDO per gestire, oltre alla
tabella di binding, anche la tabella dei gruppi.
42
2 1 1 4 0/16 8 8 Variable
Transaction
Frame Manufacturer Manufacturer Command Frame
Direction Res sequence
type specific code identifier payload
number
ZCL
ZCL header
payload
APS
APS header
payload
Il primo campo del pacchetto ZCL distingue il tipo di comando: questo può essere di
due tipi, o generico di tutti i cluster, oppure specifico di un certo cluster. I comandi del
primo tipo servono ad interagire con gli attributi dei cluster nei modi concessi. Ad
esempio il cluster On/Off ha la variabile booleana di sola lettura OnOff il cui valore può
essere letto attraverso il comando generico “Read attributes”, che permette anche la
richiesta di più di un attributo dello steso cluster. Segue l’immagine del formato del
payload di tale comando.
43
Il server del cluster On/Off che riceve il precedente messaggio provvede a restituire il
valore richiesto mediante il comando generico “Read attributes response”. Lo standard
ZigBee fornisce la descrizione del payload di tutti i comandi generici riportati nella
figura che segue. Quest’ultima riporta anche il rispettivo identificativo del comando
generico da inserire nel campo “Command identifier” nell’intestazione del pacchetto
ZCL.
44
impostare il server per la notifica degli attributi, per i quali tale servizio è previsto,
specificando l’intervallo di tempo tra una notifica e la successiva. Il server provvede poi
a recapitare le notifiche generando un pacchetto ZCL contenente il comando “Report
attribute”.
I comandi del secondo tipo sono invece specifici del cluster a cui appartengono. Nel
precedente paragrafo è stata mostrata la tabella dei comandi del cluster On/Off: On, Off
e Toggle hanno associato un identificativo che va inserito nello stesso campo
dell’intestazione ZCL, cioè “Command identifier”, a cui è stato fatto riferimento poche
righe sopra parlando dei comandi generici,
Riepilogando, per questo lavoro di tesi sono stati presi in esame le seguenti sezioni
ZigBee inerenti le ZigBee Cluster Library:
“ZCL Functional Domain: General”, sezione che descrive l’insieme dei cluster
sufficientemente generali da appartenere a diversi contesti funzionali.
“ZCL Functional Domain: Lighting”, sezione che descrive l’insieme dei cluster
idonei a gestire funzionalità caratteristiche della luce come saturazione e colore.
“ZCL Functional Domain: HVAC”, sezione che descrive l’insieme dei cluster
dedicati al riscaldamento, ventilazione e climatizzazione di luoghi chiusi
(HVAC sta per Heating, Ventilation and Air Conditioning).
“ZCL Functional Domain: Closures”, sezione che descrive l’insieme dei cluster
destinati a controllare tipicamente dispositivi come serrande e imposte.
“ZCL Functional Domain: Security and Safety”, sezione che descrive l’insieme
dei cluster rivolti a funzioni proprie degli allarmi antiintrusione.
45
3.
assicurando il trasporto su rete IP dei dati della rete di sensori che verranno
elaborati da applicativi di terze parti sviluppati in maniera verticale,
Queste due strade corrispondono a due diverse strategie di business: la prima si basata
sul traffico, la seconda sul servizio. Per comprendere meglio le potenzialità offerte dalla
prima strategia, è stata compiuta un’analisi del traffico veicolato dal gateway preso in
riferimento.
46
3.1. Scenario di monitoraggio remoto
Il profilo “Home Automation” esaminato nel precedente capitolo è il primo profilo
applicativo sviluppato dalla ZigBee Alliance ed ha lo scopo di standardizzare i
dispositivi dell’ambito residenziale. Nella tabella 3 sono elencati tutti i dispositivi finora
supportati dal profilo, raggruppati in cinque categorie: Generic, Lighting, Closures,
HVAC e Intruder Alarm System. Il gateway deve poter interagire con il maggior
numero possibile di dispositivi di una casa. Al fine di questa analisi il concetto di
gateway è stato considerato a livello applicativo come un dispositivo ZigBee
equivalente agli altri, astraendo da come avviene la connessione con il mondo IP. Per
rimanere comunque aderenti allo standard si è cercato il dispositivo più vicino alle
funzionalità di gateway: dall’elenco precedente è stato scelto il “Remote control”. La
figura sottostante è tratta dal documento di Home Automation Profile e mostra i cluster
implementati da tale dispositivo.
47
La specifica riporta che il Remote control è un dispositivo capace di controllare e
monitorare gli altri dispositivi come ad esempio accendere e spegnere una luce, leggere
la temperatura o impostare un termostato.
Cluster
Pump Configuration and Control
supported
by RC On/Off Switch Configuration
Temperature Measurement
Illuminance Measurement
at client
side
Shade Configuration
Level Control
Color Control
Identify
Groups
On/Off
Scenes
Basic
Device
On/Off Switch x
Level Control x
Switch
On/Off Output x x x
Level x x x x
Controllable
Output
Mains Power x x x
Outlet
On/Off Light x x x
Dimmable Light x x x x
Color Dimmable x x x x x
Light
48
On/Off Light x
Switch
Dimmer Switch x
Color Dimmer x
Switch
Light Sensor x
Occupancy
Sensor
Shade x x x x x
Heating/Cooling x x x x
Unit
Thermostat x x
Temperature x
Sensor
Pump x x x x x x
Pressure Sensor
Flow Sensor
IAS Control and x x
Indicating
Equipment (CIE)
Tabella 10 Dispositivi interfacciabili con un Remote control
Per avere una chiave di lettura della tabella occorre esaminare uno per uno i cluster in
colonna:
Level Control, questo cluster permette di impostare dei valori: con esso è
possibile configurare una intensità di luce di una “Dimmable light” o la potenza
del sopra citato “Level Controllable Output” ma anche di scegliere il grado di
chiusura di una serranda (“Shade”).
50
“Thermostat”, questo dispositivo serve ad impostare la temperatura desiderata di
un “Heating/Cooling Unit” ma il Remote control il relativo cluster non può
essere comandata.
51
1 Heating/Cooling Unit: la casa prevede certamente una unità di riscaldamento
e/o climatizzazione.
52
3.2. Modello di traffico
Come discusso nel secondo capitolo, i messaggi ZCL si dividono in comandi generici e
comandi specifici. Per comodità chiameremo la seconda tipologia con il termine azioni.
Per quanto riguarda invece i comandi generici è necessario considerare che i comandi
come la lettura o la scrittura difficilmente verranno utilizzati in maniera programmata
perché in tal caso, cioè quando c’è il bisogno di avere notifica ad intervalli dei tempo
regolari, si preferisce usare il meccanismo dell’Attribute reporting.
Per stimare il traffico è necessario analizzare il formato del pacchetto di ogni comando
ZCL. Infatti il payload del pacchetto ZCL varia di comando in comando. Occorre altresì
definire quante volte in un arco temporale ogni pacchetto transita dal gateway. Per
organizzare queste informazioni si è reso necessario il ricorso ad un foglio di calcolo.
Per completezza nel foglio di calcolo sono inclusi anche i dispositivi in precedenza
scartati allo scopo di prevedere anche quelli per ora non supportati (ad esempio un
termostato).
53
La prima colonna contiene i dispositivi, la seconda i cluster lato server implementati del
dispositivo e la terza le operazioni supportate dal cluster. Per ogni operazione, le
successive tre colonne esprimono in ordine la dimensione in bit dell’intestazione, del
payload e del totale del pacchetto. Le prime sei colonne fanno riferimento a dati
oggettivi ricavati dalle specifiche. Le colonne successive invece sono frutto delle ipotesi
descritte in precedenza. La settima colonna infatti riporta le quantità dei dispositivi
presenti nella casa di riferimento. A seguire sono presenti quattro gruppi di tre colonne
ciascuno. Ogni gruppo rappresenta una fascia di sei ore della giornata. Si è pensato di
dividere le ventiquattro ore in fasce di sei ore per studiare anche le potenziali
concentrazioni di traffico. Di ogni fascia, la prima colonna riporta il numero di volte
nelle sei ore che un dispositivo invia (o riceve) il comando ZCL in riga che coinvolge il
gateway: ad esempio il valore 1 indica che transita un solo pacchetto in sei ore. Si
rimandano alcune considerazioni fatte per la stima di tali valori ad una successiva
descrizione. La seconda e la terza colonna del gruppo contengono rispettivamente il
numero di pacchetti e il numero di bit complessivi trasmessi nell’intera fascia oraria da
tutti i dispositivi del tipo in riga. La prima si ottiene moltiplicando la prima colonna per
la colonna del numero di dispositivi presenti e la terza moltiplicano la seconda colonna
con la colonna della dimensione del pacchetto. Eseguendo la sommatoria di ciascuna
terza colonna, si ottiene il totale per fascia di bit inviati e ricevuti dal gateway.
Eseguendo invece la sommatoria di ciascuna seconda colonna si ottiene il totale sempre
per fascia di pacchetti trasmessi. Nel prossimo paragrafo si precisa il significato dei
risultati ottenuti. In figura 23 è mostrata la porzione di foglio di calcolo dei risultati
ottenuti.
54
Figura 23 Frammento con i risultati ottenuti
L’utente potrebbe volere accendere e spegnere le luci della casa in modo da simulare la
propria presenza (cosa poco intelligente ma comunque possibile); potrebbe dovere
accendere l’impianto dell’acquario (o del terrario) in un momento della giornata in cui è
assente prendendosi cura dei suoi amici animali senza tornare a casa; riuscirebbe a
chiudere le serrande prima dell’arrivo di un temporale; sarebbe in grado di accendere
l’impianto di irrigazione la sera prima di rientrare a casa. Un utente difficilmente esegue
queste operazioni tutti i giorni ma in ogni modo disporrebbe dei mezzi per farlo. Nel
compilare il foglio di calcolo si è tenuto conto, in un certo senso, del caso peggiore.
55
della temperatura o della luminosità. L’utente ha la possibilità di visualizzare tali dati
delle diverse zone della casa mediante i relativi sensori. Questa informazione è
campionata dal modello una volta ogni ora ovvero sei volte per fascia temporale. I
dispositivi “Output” potrebbero inviare il loro stato, vale a dire se forniscono o meno
alimentazione all’apparecchio al quale sono collegati, ogni ora in modo da generare un
allarme nel caso che, ad esempio, il congelatore rischi di scongelarsi. A scopo di
statistica invece le lampade possono essere programmate in modo da inviare il loro stato
ogni trenta minuti e da questa statistica poi scegliere la tariffa elettrica più conveniente.
Tutte queste informazioni apparentemente di scarso valore potrebbero rivelarsi utili in
futuro per creare ad esempio offerte commerciali aderenti all’utenza.
56
Figura 24 Visualizzazione del foglio di calcolo ottenuta nascondendo alcune
colonne
57
3.3. Risultati e conclusioni
Assumendo gli usi tipici di monitoraggio e di controllo remoto dei dispositivi presenti
in un’abitazione e ponderando svariate ipotesi è stato elaborato un modello dal quale si
ottengono dei valori di traffico assoluti sia in termini di byte sia in termini di pacchetti.
Questi risultati sono mostrati nella figura 22 e il grafico successivo esprime al meglio il
fenomeno: come era immaginabile, la quantità di dati che interessano il mondo esterno
è di modesta entità e si attesta intorno ai 1200 byte per tutte le fasce temporali
considerate. Anche il numero di messaggi raggiunto, circa 200, corrisponde al basso
traffico.
Figura 25 Risultati
In questo caso entrambe i valori sono bassi e non generano un traffico sulla rete IP tale
da poter spingere l’operatore di telecomunicazioni ad orientare il business su tale
traffico. La scelta più interessante diventa quella di offrire un piattaforma di servizi
sulla quale gli sviluppatori di applicazioni possano costruire la propria applicazione.
Tale struttura ha senso proprio grazie all’uso dello standard ZigBee.
Infatti tale analisi è attinente solo al profilo Home Automation ed al caso d’uso preso in
esame. Per profili come Wireless Sensor Application, Commercial Building
Automation o Industrial Plant Monitoring i risultati potrebbero essere molto diversi a
causa del diverso peso che avrà l’Attribute reporting.
59
4. Gateway Reference Implementation
Questo capitolo descrive la parte principale del lavoro di tesi: lo sviluppo di un gateway
per reti di sensori ZigBee. L’applicazione realizzata in realtà è un prototipo utile ad
esplorare da un punto di vista pratico le caratteristiche di un gateway.
WSN-C
Service
Platform
Internet
Gateway
Abstraction
Layer
La figura riportata illustra l’architettura del sistema: in alto si trovano gli utenti che
utilizzano dei servizi sviluppati dallo stesso operatore di telecomunicazioni o da terze
parti; tali servizi sono retti dalla piattaforma di servizio, la quale offre un’interfaccia
pubblica con lo scopo di astrarre il più possibile la rete di sensori; la WSN-C si serve di
60
un livello di astrazione chiamato Gateway Abstraction Layer (GAL), presente nel
gateway, che le consente di configurare, controllare e comandare la rete di sensori.
Il compito del gateway, infatti, è di semplificare l’accesso alle risorse della rete di
sensori unificando le numerose primitive ZigBee in più semplici funzionalità di alto
livello. Il Gateway Abstraction Layer offre alla piattaforma di servizio l’accesso alle
funzionalità del gateway. Si distinguono tre diversi gruppi di funzioni denominati
“Management and Commissioning”, “Service discovery” e “Service interface”. Fanno
parte del primo gruppo le funzioni relative sia alla gestione del tipo e della topologia
della rete, sia alla gestione dell’energia, della localizzazione e della sicurezza dei nodi.
Le funzioni appartenenti al secondo gruppo sono necessarie per scoprire quali sono i
servizi offerti dai nodi e dalla rete nel suo complesso, mentre al terzo gruppo
afferiscono le funzioni relative ai singoli servizi applicativi dei nodi.
Come già accennato nel paragrafo 1.1, l’operatore dispone di terminali come il modem
ADSL, il videotelefono o il set top box ai quali poter aggiungere un modulo ZigBee, per
interagire con la rete di sensori, e la logica del gateway, affinché possano esporre le
suddette funzionalità alla piattaforma sfruttando la già presente connettività IP.
Il gateway è composto, oltre che dal Gateway Abstraction Layer, anche dal Gateway
Device Object che rappresenta la logica vera e propria, vale a dire l’implementazione
della macchina a stati che gestisce le richieste pervenute al GAL.
REST è la tecnologia usata per l’interfaccia tra il GAL e la piattaforma WSN-C è di cui
si tratterà nel paragrafo 4.3.4.
Per quanto concerne invece l’interfaccia con la rete di sensori occorre specificare che il
gateway è in realtà un’applicazione ZigBee come, ad esempio, di un “On/Off Switch” e
in quanto tale utilizza un nodo fisico per l’acquisizione un indirizzo di rete (short
address). Essendo un Application Object, ciò di cui dispone quindi è la ZigBee Device
Object Public Interface e la Application Support Sublayer Data Entity Interface. A
differenza di un dispositivo ZigBee comune, il gateway ha maggiori risorse
computazionali che gli permettono di sostenere la superiore complessità applicativa ed è
in grado di remotizzare alcune funzionalità attraverso l’utilizzo della rete dell’operatore.
61
servizi, di interagire con la WSN. Occorre precisare che la piattaforma di servizi è
capace di gestire molteplici gateway mediante l’uso di identificativi (ad esempio
indirizzo IP del gateway).
62
4.1. Gateway Abstraction Layer
Questo paragrafo tratta nei particolari le funzionalità implementate dal prototipo
sviluppato. Il GAL ha lo scopo di mascherare la complessità legata allo standard ZigBee
permettendo allo sviluppatore di creare i servizi svincolandosi dai problemi di
implementazione dei livelli più bassi. Occorre notare che questa architettura di sistema
permette interfacciarsi con reti diverse da ZigBee (ad esempio TinyOS), semplicemente
implementando un gateway adatto a tale proposito che esponga il GAL. Tuttavia,
prediligendo la soluzione standard, la progettazione del GAL trae ispirazione da ZigBee
e per questo motivo nei paragrafi a venire si fa riferimento alle strutture dati dello
standard.
Campo Descrizione
Logical type Tipo logico del nodo (Coordinator, Router, End device)
MAC capability flags Impostazioni del livello IEEE 802.15.4 MAC come il
tipo di dispositivo (FFD, RFD), l’alimentazione (da rete
elettrica o da batteria), il risparmio energetico (nei
periodi di inattività), il supporto alla trasmissione
cifrata
63
Manufacturer code Codice del produttore fornito dalla ZigBee Alliance
Campo Descrizione
Current power mode Indica se il ricevitore del nodo è sempre attivo oppure è spento
solo nei periodi di inattività, oppure si attiva periodicamente
oppure si attiva su intervento dell’utente
Current power source Indica quale tra le fonti di alimentazione disponibili è in uso
Current power source Indica il livello di energia della fonte di alimentazione in uso
level (critico, 33%, 66%, 100%)
Quelle sullo stato di carica delle batterie dei nodi sono informazioni utili ad
implementare, sulla piattaforma di servizio, applicazioni indirizzate alla sostituzione
preventiva delle batterie per assicurare all’utente una efficace manutenzione. estensioni
future del dimostratore potrebbero coinvolgere questa classe di funzionalità al fine di
includere la configurazione delle applicazioni, la localizzazione dei nodi, la gestione
della sicurezza e l’Over the Air Programming (OTA) che consente la programmazione
dei nodi senza rimuoverli dalla loro sede.
64
remoto e per ognuno, l’identificativo del profilo applicativo, l’identificativo del
dispositivo applicativo e la lista dei cluster implementati. Le informazioni di un
Application object sono contenute in un Simple Descriptor esaminato nella tabelle
sottostante.
Campo Descrizione
Application input cluster list Lista degli identificativi dei cluster di input
implementati
Application output cluster list Lista degli identificativi dei cluster di output
implementati
65
Interface APSDE-DATA.indication. Questa è già stata illustrata nel paragrafo 2.3.1.
Nei prossimi sviluppi questa parte sarà punto focale per l’interazione tra piattaforma e
servizi.
66
4.2. Gateway Device Object
Il GDO aggrega le primitive ZigBee allo scopo di eseguire le funzionalità offerte dal
Gateway Abstraction Layer. Al suo interno risiede la logica di interazione con una rete
ZigBee che viene mascherata alla piattaforma di servizio semplificando l’utilizzo delle
risorse di una WSN. Di seguito sono esposte le primitive accennate nel precedente
paragrafo con la definizione degli automi a stati finiti e la descrizione delle primitive
dello stack ZigBee utilizzate. Il GDO mantiene le informazioni ricevute dalla rete di
sensori in una struttura chiamata GW Information Base che verrà presentata nel
paragrafo 4.3.5.
Per eseguire questa primitiva il GDO si serve di alcune primitive ZigBee della ZDO
Public Interface:
67
IEEE_addr_req, questo comando serve a conoscere l’indirizzo IEEE di un nodo
di cui si conosce l’indirizzo di rete; tale comando genera un messaggio unicast
avente come destinatario il nodo con l’indirizzo di rete specificato; se la
richiesta è di tipo esteso e il nodo destinatario è un coordinatore o un router,
allora il comando di risposta IEEE_addr_conf contiene, oltre al indirizzo IEEE,
anche la lista degli indirizzi di rete dei dispositivi ad esso associati.
68
I seguenti diagrammi di flusso rappresentano una astrazione di quanto appena espresso.
Node_Desc_req (son)
Node_Desc_conf
Power_Desc_req (son)
fill GW information base
Power_Desc_conf
Per eseguire questa primitiva il GDO si serve di alcune primitive ZigBee della ZDO
Public Interface:
69
Active_ep_req, questo comando serve a scoprire quali sono gli Endpoint attivi di
un nodo. La risposta Active_ep_conf contiene la lista di tali identificativi.
In generale la ricezione delle confirm è totalmente asincrona perciò dopo aver inviato
una serie request, l’ordine delle risposte è totalmente imprevedibile: per riconoscere la
provenienza ogni confirm riporta i dati identificativi del mittente.
70
4.3. Applicazione
Questo paragrafo illustra i punti chiave dell’architettura del programma sviluppato. Il
testbed, anche detto ambiente di prova, è costituito da due personal computer (di cui
uno usato anche per lo sviluppo), due dongle USB forniti dalla Integration [Integration]
e un nodo ZigBee fornito dalla BM Group Spa [BM]. Il gateway è realizzato dalla
coppia PC (munito di interfaccia di rete) e dongle USB mentre la rete di sensori è
rappresentata dal secondo PC unito al secondo dongle e dal nodo di BM. A corredo dei
dongle USB di Integration viene fornita una buona documentazione e degli esempi
applicativi. L’approccio iniziale con questo prodotto si è svolto analizzando il più
comune degli esempi presenti, l’interruttore e la lampada. L’implementazione è partita
dalla modifica di tale applicazione e, dopo aver assunto la conoscenza sufficiente, si è
proceduto allo sviluppo del dimostratore di gateway. L’ambiente di sviluppo usato è
Visual C++ del pacchetto Microsoft Visual Studio 2003. La scelta di tale software è
stata obbligata dal fatto che il driver del dongle USB, e la relativa manualistica, è stato
implementato singolarmente per MS Windows.
71
gateway ossia quella esporre le funzionalità definite mediante il Gateway Device
Object.
La figura seguente mostra la schermata dalla quale è possibile eseguire le due discovery
descritte nel paragrafo precedente. Ad ogni discovery è associato un bottone con il
relativo nome. Il risultato di queste operazioni è presentato nel riquadro centrale che ha
la proprietà di organizzare il contenuto ad albero. L’albero risultante è in realtà l’albero
di joining: conoscere questa struttura è molto utile da punto di vista implementativo ma
poco rilevante ai fini della piattaforma di servizio. Per come è sviluppata l’applicazione,
il risultato della Device Discovery produce un messaggio recante l’esito della stessa
mentre quello della Service Discovery popola il suddetto albero. Questa scelta è stata
indotta dal fatto che l’albero ha la capacità di offrire una visione d’insieme che
altrimenti andrebbe persa: la prima funzionalità infatti fornisce solo informazioni sui
nodi e sulla loro relazione mentre la seconda funzionalità fornisce solo i servizi residenti
sui vari nodi. Fornire due risultati diversi avrebbe significato minore leggibilità e
ridondanza delle informazioni (cosa trascurabile dal punto di vista della piattaforma di
servizio).
72
(Fig. A) (Fig. B)
Dalla figura 31/A è possibile notare che la prima riga di questo riquadro rappresenta la
radice dell’albero e riporta l’indirizzo di rete e l’indirizzo MAC del nodo coordinatore.
Le righe successive, ottenute espandendo la radice, sono in ordine “Node Descriptor”,
“Power Descrptor”, “Endpoint” e “Sons”. Espandendo i primi due elementi si ottengono
le informazioni contenute nei relativi descrittori. Espandendo i secondi due elementi
invece si entra a conoscenza rispettivamente degli Application Object presenti sul nodo,
rappresentati dal valore dell’endpoint, e dei nodi associati, a partire dai quali tale
struttura si ripete. La figura 31/B esemplifica il caso in cui ci siano un nodo
coordinatore e due suoi figli.
Occorre notare che questa interfaccia grafica è utile ai fini di test o debug e non deve
essere ritenuta indispensabile per l’integrazione con la piattaforma di servizi. Sviluppi
futuri di questa applicazione permetterebbero ad esempio ad un tecnico esperto di
interagire direttamente con la rete di sensori per verificare dei malfunzionamenti.
73
4.3.2. Architettura applicativa
L’architettura che questo paragrafo descrive è rappresentata dalla figura seguente.
Il box di colore azzurro rappresenta il driver fornito insieme al dongle di Integration che
permette all’applicazione di accedere alle funzioni ZigBee del dongle. In realtà tale
libreria contiene gli strati alti dello stack ZigBee mentre l’hardware contenuto nel
dongle si occupa principalmente delle funzioni radio. Come visibile nell’immagine la
DLL (Dynamic Link Library) offre le primitive principali per interagire con lo stack
ZigBee: la primitiva più importante è ZBDLLSend() perchè permette di chiamare le
funzioni della APS e della ZDO mediante un protocollo seriale opportunamente
documentato.
Per facilitare le chiamate di tali primitive ZigBee la stessa Integration fornisce anche
l’interfaccia “ZigBee Common Interfaces” raffigurata nel box di colore verde. Questa
interfaccia raccoglie tutte le primitive ZigBee (occupandosi cioè di comporre il
74
messaggio seriale in osservanza della specifica) e gestisce anche quali messaggi
provenienti provenienti dai livelli inferiori della pila protocollare debbano essere
consegnati all’applicazione. Ad esempio con tale chiamata
ZBIFSubscribe(AF_DIRECT_INDICATION) si specifica che ogni qualvolta arrivi
all’APS un messaggio di tipo diretto proveniente da un altro Application Object, esso
venga recapitato all’applicazione. Partendo dal livello più basso: la DLL recapita tutti i
messaggi provenienti dal basso alla ZigBee Common Interfaces chiamando la funzione
ZigBeeReceiveData(): quest’ultima è definita nell’interfaccia ma è utilizzabile dalla
DLL perché il suo puntatore viene passato alla DLL durante la fase di start. La funzione
ZigBeeReceiveData() controlla il tipo di messaggio e, se l’applicazione ha sottoscritto la
relativa ricezione, effettua la consegna al livello superiore con un messaggio di
windows generato con la primitiva PostMessage() appartenete alle MFC (Microsoft
Foundation Classes).
L’applicazione è identificata dal box rosso: essa utilizza la ZigBee Common Interfaces
per configurare il nodo, inviare richieste alla ZDO e all’APS e ricevere le risposte o i
messaggi applicativi. Come già scritto le risposte e i messaggi applicativi pervengono
mediante la coda dei messaggi di windows e la cui ricezione avviene, alla stregua di un
evento, con una chiamata di una funzione definita nell’applicazione. Per ogni tipo di
messaggio al quale l’applicazione ha sottoscritto la ricezione esiste una funzione che
gestisce il messaggio arrivato. Quest’ultimo si presenta in forma seriale e quindi
comporta un lavoro di estrazione delle informazioni (“unmarshaling”) che nel verso
opposto è eseguito dalla ZigBee Common Interfaces (“marshaling”). Per questo motivo
i due box, rosso e verde, presentano una diversa, ma complementare, sagoma.
4.3.3. Implementazione
Quanto descritto nel capitolo precedente assume maggiore dettaglio osservando lo
schema riportato di seguito.
75
Figura 33 Rappresetazione a oggetti
76
Se tutto è eseguito regolarmente l’applicazione provvede a far partire il thread per
l’interazione con la piattaforma. Dopo questa fase il gateway è pronto a ricevere sia le
richieste provenienti dall’interfaccia grafica sia quelle dalla piattaforma di servizio.
Si lascia al paragrafo relativo la descrizione della classe Node mentre occorre precisare
il significato delle frecce contenute nel disegno precedente: la freccia che parte dalla
DLL e arriva in corrispondenza della funzione ZigBeeReceiveData(…) è tratteggiata per
rimarcare che questa è una vera e propria chiamata di funzione diversamente dalle
frecce non tratteggiate che indicano l’inserzione o l’estrazione di messaggi dalla coda di
Windows.
La descrizione prosegue con l’analisi di cosa accade quando perviene una richiesta di
Device Discovery e di Service Discovery dall’interfaccia. Al momento della pressione
di uno dei due pulsanti il sistema provvede ad invocare il metodo appropriato,
“OnBnClickedDeviceDiscovery” oppure “OnBnClickedServiceDiscovery”, le cui
implementazioni sono fornite in appendice B. Questi due metodi realizzano quanto
espresso dal relativo diagramma di flusso delle figure 28 e 29.
In questi diagrammi sono stati tralasciati i meccanismi rivolti alla gestione degli errori. I
messaggi di richiesta inviati delle due discovery possono infatti essere persi per vari
motivi (ad esempio, il nodo di destinazione non è più attivo oppure il segnale è
disturbato da interferenze). A questo scopo lo stack ZigBee prevede che a seguito di una
request fallita venga comunque generata una confirm recante l’insuccesso: questa viene
prodotta solo dopo l’attesa di un periodo determinato. Questo garantisce che ad ogni
request sicuramente corrisponde una confirm. Sfruttando questa deduzione si può
determinare la conclusione di una discovery semplicemente controllando che il numero
di request inviate sia pari al numero di confirm ricevute. Questa soluzione risulta
efficiente in quanto le discovery impiegano un tempo proporzionale alla grandezza della
rete. Nel codice questo meccanismo è implementato mediante una variabile
(count_expected_confirm) che viene incrementata ogniqualvolta una request viene
inviata e decrementata quando una confirm viene ricevuta. Per considerare la discovery
terminata occorre controllare ad intervalli regolari che tale contatore sia zero. A tal fine
viene impostato un timer con scadenza di un secondo scaduto il quale si effettua il test:
se la variabile di cui sopra è zero, la discovery è terminata, altrimenti il timer riparte. Le
MFC forniscono la possibilità di settare un timer che, allo scadere, inserisce un
messaggio nella coda dell’applicazione. Quando l’applicazione processa questo
77
messaggio esegue il metodo OnTimer la cui implementazione è definita in CGALDlg.
A ogni timer è associato un numero che identifica l’evento: al numero 1 è associata la
terminazione della Device Discovery, al numero 2 la terminazione della Service
Discovery. Per affermare la correttezza dell’implementazione occorre fare due
commenti:
Affinché una discovery abbia successo deve accadere che tutti messaggi di risposta,
ovvero le confirm, abbiano esito positivo. Allo stato di sviluppo attuale, basta che una
confirm abbia esito negativo per compromettere l’intera discovery. Una estensione
futura del prototipo in esame dovrà certamente garantire una maggiore robustezza: a tal
fine basterebbe prevedere la replica dell’invio del messaggio di richiesta fallito.
Purtroppo lo stack utilizzato non fornisce la possibilità di identificare il messaggio perso
(come accade per i messaggi con esito positivo) altrimenti tale gestione risulterebbe
semplificata. Essendo questo un prototipo si è pensato di rilasciare le specifiche di
robustezza per poi riprendere la risoluzione del problema durante lo sviluppo della
applicazione finale, operando per risolvere le eventuali limitazioni dello stack
utilizzato.
Quanto appena descritto ha avuto influenza sulle scelte implementative adottate durante
lo sviluppo del thread destinato ad accogliere le richieste provenienti dalla piattaforma.
Sebbene il paragrafo 4.3.4 si occupi di trattare l’interazione tra GAL e WSN-C occorre
anticipare per maggiore chiarezza in questo paragrafo alcuni dettagli implementativi. Il
thread all’avvio apre un server socket TCP sul quale rimane in ascolto. Per ogni
connessione accettata si occupa di ricevere il messaggio ed effettuare il parsing della
richiesta. Il parsing serve ad isolare le parti del messaggio al fine di carpirne il
significato. In questa versione prototipale sono disponibili alla piattaforma solo due
78
funzionalità: “discovery” e “notification”. La prima è il risultato dell’unione delle due
discovery: tale accorpamento è stato fatto per semplificare l’interazione tra piattaforma
e gateway essendo unico il risultato prodotto. La seconda, non presente nell’interfaccia
grafica, è una parziale l’implementazione della classe di funzionalità denominata
Service Interface (vedi paragrafo 4.1.3): con questa richiesta la piattaforma riceve i
messaggi applicativi provenienti dalla rete di sensori.
Come già accennato, una richiesta di tipo “notification” ha lo scopo di far fluire tutti i
messaggi della rete di sensori destinati al gateway alla piattaforma. Questa situazione
avrà luogo quando la piattaforma sarà in grado di inviare, usando il gateway, dei
messaggi ai singoli device. Per ora, questa caratteristica è stata sviluppata per
supportare un’applicazione proprietaria oggetto di un’altra attività. Per rendere
comprensibile il tipico caso d’uso bisogna immaginare che la piattaforma, dopo aver
fatto una Device Discovery ed una Service Discovery, sia interessata ad un particolare
servizio di un device nella rete. Essa dunque potrebbe dover inviare dei messaggi
applicativi per impostare, ad esempio, un Attribute reporting. In questo caso la lettura
periodica del valore raggiunge la piattaforma attraverso un canale attivato da questa
funzionalità. L’implementazione attuale usa lo stesso client socket utilizzato per inviare
la richiesta come canale sul quale trasmettere tali messaggi.
79
Per riassumere, esistono due flussi di controllo, l’applicazione principale e il thread:
l’applicazione reagisce agli eventi provenienti sia dall’interfaccia grafica sia dal thread
mentre quest’ultimo reagisce solamente alle richieste provenienti dalla piattaforma.
Piattaforma
TCP/IP
GAL Interfaccia
(thread) Grafica
Windows Messaging
Stack ZigBee
80
REST essendo uno stile architetturale non forza l’uso di un particolare protocollo di
trasporto. Anche se attualmente il protocollo maggiormente utilizzato per i sistemi
aderenti a REST è HTTP, sono stati implementati con successo sistemi che fanno uso di
protocolli alternativi. L’Hyper Text Transfer Protocol, altrimenti detto HTTP è un
protocollo client-server generico, senza memoria di stato (stateless) e non-orientato alla
connessione (connection-less) utilizzato non solo per lo scambio di documenti
ipertestuali, ma per una moltitudine di applicazioni che variano dallo streaming
audio/video al trasporto di altri protocolli. Un metodo HTTP è un’operazione ben
definita su una risorsa. Il più importante metodo di HTTP è GET, che richiede una
risorsa ad un server. Questo è il metodo più frequente, ed è quello che viene attivato
facendo click su un link ipertestuale di un documento HTML, o specificando un URL
nell’apposito campo di un browser.
è senza stato e ciò implica che ogni richiesta del client al server deve contenere
tutte le informazioni necessarie senza ricorrere alla conservazione di uno stato
sul server,
81
è possibile introdurre proxy server, cache server e gateway in modo da
assicurare prestazioni, sicurezza, ecc.
82
4.3.5. Gateway Information Base
Questo paragrafo descrive le scelte implementative riguardanti la struttura dati per la
memorizzazione delle informazioni della rete di sensori. L’oggetto fondamentale di una
rete è il nodo. Un nodo è identificato da un indirizzo di rete e da un indirizzo MAC e
contiene:
83
rete (in formato esadecimale) mentre la freccia esprime relazione padre-figlio da cui
deriva la struttura ad albero. In basso si trova il vettore di puntatori illustrati dalle frecce
tratteggiate che partono dalla locazione corrispondente all’indirizzo di rete e puntano al
relativo oggetto “Node”.
ServiceReq viene usato per cominciare una Service Discovery (vedi il primo
diagramma di flusso della figura 29),
Questi metodi sfruttano l’albero richiamando annidatamente loro stessi sui nodi figli. In
pratica chiamando, ad esempio, XMLWrite sulla radice viene creato l’albero del
documento XML. Riassuendo questo metodo esegue i seguenti passi:
84
prosegue aggiungendo le informazioni del Power descriptor,
a questo punto chima il medesimo metodo su ognuno dei figli del oggetto
“Node” di appartenenza,
85
5. Conclusioni
Le reti di sensori senza fili rappresentano uno degli argomenti più interessanti e
promettenti nell’attuale panorama scientifico internazionale. I possibili campi di
applicazione sono molto vasti e ancora largamente inesplorati. La commercializzazione
dei primi prodotti ha contribuito a portare queste tematiche al di fuori dei limitati
confini dei laboratori di ricerca universitari, stimolando l’interesse di piccole e grandi
aziende che vedono nelle WSN sia uno strumento per migliorare la produttività delle
proprie imprese che una possibilità di espandere l’attività su un nuovo mercato. A tal
proposito è nato lo standard ZigBee: una tecnologia che permette la creazione di reti
senza fili di oggetti intelligenti adatti ad attivare una moltitudine di servizi innovativi
che spaziano dall’automazione domestica al monitoraggio ambientale. Grazie
all’integrazione di questa tecnologia in terminali fissi, o anche mobili, che si
configurano come gateway connettendo il mondo delle reti di sensori alle reti di
distribuzione tradizionali dell’operatore, l’informazione si arricchisce e diventa
pervasiva ed accessibile ovunque. Il concetto di “pervasive computing” presuppone che
la tecnologia impiegata sia totalmente trasparente all’utente in modo che venga
percepita in maniera naturale. Nel 1991 Mark Weiser, capoufficio del dipartimento
tecnologico del Centro di Ricerca di Palo Alto (PARC) della Xerox, scriveva: “Le
tecnologie più profonde sono quelle che scompaiono, che saranno nascoste nella
fabbrica della vita giornaliera finché sarà indistinguibile dalla vita stessa […] Le
macchine entreranno nell’ambiente umano senza che l’uomo si sforzi più di entrare in
quello delle macchine, l’uso del computer dovrà essere ristoratore quanto una
passeggiata nei boschi”. La comunità scientifica dell’epoca considerò la visione di
Weiser basata su un’idea inconsistente e quasi fantascientifica. A distanza di qualche
decennio Weiser è considerato il precursore del modello di interazione tecnologica alla
base del “pervasive computing”.
86
5.1. Obiettivi raggiunti e futuri
Con questi presupposti, lo sviluppo di un gateway per reti di sensori ZigBee, oggetto di
questa tesi, costituisce il primo passo verso lo sviluppo di applicazioni e servizi a valore
aggiunto (VAS). Come visto nel capitolo 3, l’operatore di telecomunicazioni intende
costruire una piattaforma di middleware sulla quale, sia esso stesso che terzi, possano
sviluppare le applicazioni per wireless sensor network senza dover conoscere i dettagli
implementativi di tali reti. Il prototipo descritto nel capitolo 4 è servito per iniziare a
familiarizzare con lo standard ZigBee e iniziare ad individuare le prime macro
funzionalità che un gateway deve fornire. L’intero sviluppo è stato eseguito puntando il
più possibile all’implementazione finale, ovvero quella riguardante un dispositivo come
un modem o un videotelefono da poi commercializzare. Quanto prima infatti l’operatore
intende effettuare il porting di tale applicazione su un sistema operativo embedded. Tale
migrazione dovrà richiedere delle modifiche: il fatto di essere stati vincolati
all’ambiente MS Windows costringerà a rivedere alcune parti del codice pur
mantenendo valida l’ossatura dell’applicazione e le strutture dati. Di altrettanto interesse
sarà l’integrazione con la piattaforma che comporterà sicuramente la messa a punto
delle funzionalità esposte dal GAL, delle strutture dati XML restituite dal gateway e del
meccanismo di interazione REST.
87
5.2. Esperienza
L’avventura intrapresa presso i laboratori di Torino è stata una esperienza formativa
senza pari. Mi ha permesso di entrare in contatto con una realtà aziendale di alto livello
dove conta l’obiettivo ma contano anche le relazioni interpersonali. In tutte le persone
che ho incontrato non sono mai mancate cortesia e disponibilità. L’uso del “tu” ha
ulteriormente accresciuto il senso di fiducia mettendomi da subito a mio agio. La
presenza di numerosi altri tesisti ha reso poi la permanenza molto più coinvolgente: mi
ha permesso il confronto con ragazzi, sia stranieri che italiani, con i quali è rimasta una
grande amicizia. La crescita professionale unita a quella umana ha reso questa
esperienza un ottimo ricordo.
88
6. Appendice
6.1. Dongle Integration
Lo stick di figura 30 fornisce un interfaccia conforme a 802.15.4 che può essere
facilmente collegata ad un computer. Il dongle fornisce anche una completa
compatibilità con lo standard ZigBee per mezzo dei driver inclusi. Esso è un semplice
metodo per integrare 802.15.4 o ZigBee in un computer, in un gateway o in un
dispositivo bridge. Utilizzando tale soluzione gli sviluppatori di software possono
evitare di scrivere un driver USB o di essere esperti di sviluppo di tecnologie wireless.
Integration offre loro la possibità di ridurre i costi di ricerca e sviluppo , di ridurre il
time-to-market e minimizzare i rischi di sviluppo. Sono disponibili a scelta due driver: il
primo fornisce accesso diretto all’interfaccia 802.15.4, il secondo alle interfacce
AF/ZDO di ZigBee.
89
6.2. Nodo BM
BM MOD 01 è uno dei più piccoli, più economici e più performanti moduli ZigBee
attualmente disponibile sul mercato, membro di una famiglia di moduli caratterizzati da
una elevata flessibilità.
Questo nodo è stato utilizzato in accoppiata con la scheda della fotografia della figura
41.
90
Figura 41 Scheda di prova BM
Questa scheda di prova fornisce diverse interfacce come RS232 e USB. Essa può essere
alimentata usando un alimentatore da rete esterno o tramite la connessione USB.
91
6.3. Esempi di codice
6.3.1. OnBnClickedDeviceDiscovery
void CGALDlg::OnBnClickedDeviceDiscovery()
{
if (DiscoveryRunning == false) {
DiscoveryRunning = true;
m_Status.SetWindowText("Node discovery started");
//if a discovery has been already made the data structures must be
cleaned up
if (array_node[0]!=NULL){
delete array_node[0];
ZeroMemory(array_node,sizeof(array_node));
}
DiscoveryFailed=false;
array_node[0] = new Node(0);
hZigBee->ZDO_IEEE_ADDR_request(0, 1, 0, 0);
count_expected_confirm++;
Sleep(WAITMSECOND);
hZigBee->ZDO_NODE_DESC_request(0);
count_expected_confirm++;
Sleep(WAITMSECOND);
hZigBee->ZDO_POWER_DESC_request(0);
count_expected_confirm++;
my_timer = SetTimer(1, DISCOVERYTIMER, (TIMERPROC) NULL);
//set node discovery timer number 1 for discovery called from button
if ( my_timer == NULL ) ::MessageBox( m_hWnd, "Error creating
device discovery timer", "GAL", MB_ICONSTOP | MB_OK );
}
else ::MessageBox( m_hWnd, "A discovery is running", "GAL",
MB_ICONSTOP | MB_OK );
}
6.3.2. OnBnClickedServiceDiscovery
void CGALDlg::OnBnClickedServiceDiscovery()
{
if (DiscoveryRunning == false) {
DiscoveryRunning = true;
m_Status.SetWindowText("Service discovery started");
if (array_node[0]==NULL) return;
array_node[0]->ServiceReq(hZigBee, &count_expected_confirm);
my_timer = SetTimer(2, DISCOVERYTIMER, (TIMERPROC) NULL); //set
service discovery timer number 2 for discovery called from button
if ( my_timer == NULL ) ::MessageBox( m_hWnd, "Error creating
service discovery timer", "GAL", MB_ICONSTOP | MB_OK );
}
else ::MessageBox( m_hWnd, "A discovery is running", "GAL",
MB_ICONSTOP | MB_OK );
}
92
LRESULT CGALDlg::Discovery( WPARAM wParam, LPARAM lParam)
{
CString XMLString;
if(DiscoveryRunning==false){
DiscoveryRunning=true;
reply_skt = (SOCKET) lParam;
m_Status.SetWindowText("Discovery called from socket");
if (array_node[0]!=NULL){
delete array_node[0]; //if a discovery has been already made the
data structures must be cleaned up
ZeroMemory(array_node,sizeof(array_node));
}
DiscoveryFailed=false;
array_node[0] = new Node(0);
hZigBee->ZDO_IEEE_ADDR_request(0, 1, 0, 0);
count_expected_confirm++;
Sleep(WAITMSECOND);
hZigBee->ZDO_NODE_DESC_request(0);
count_expected_confirm++;
Sleep(WAITMSECOND);
hZigBee->ZDO_POWER_DESC_request(0);
count_expected_confirm++;
my_timer = SetTimer(3, DISCOVERYTIMER, (TIMERPROC) NULL);
if ( my_timer == NULL ) ::MessageBox( m_hWnd, "Error creating
device discovery timer", "GAL", MB_ICONSTOP | MB_OK );
}
else
{
XMLString = "<error>Discovery is running</error>";
/*send( (SOCKET) lParam, XMLString.GetBuffer(),
XMLString.GetLength(), 0 );
closesocket((SOCKET) lParam);
TRACE("connection closed\n");*/
MySend((SOCKET) lParam, XMLString);
}
return 0;
}
6.3.4. ServerThread
WORD wVersionRequested;
WSADATA wsaData;
int err;
wVersionRequested = MAKEWORD( 2, 2 );
err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 )
{
TRACE( "Error at socket(): %ld\n", WSAGetLastError() );
::MessageBox( mainWnd, "Error could not find a usable WinSock DLL",
"GAL", MB_ICONSTOP | MB_OK );
return FALSE;
}
/* Confirm that the WinSock DLL supports 2.2.*/
/* Note that if the DLL supports versions greater */
/* than 2.2 in addition to 2.2, it will still return */
93
/* 2.2 in wVersion since that is the version we */
/* requested. */
if ( LOBYTE( wsaData.wVersion ) != 2 ||
HIBYTE( wsaData.wVersion ) != 2 )
{
TRACE( "Error at socket(): %ld\n", WSAGetLastError() );
::MessageBox( mainWnd, "Error could not find a usable WinSock DLL",
"GAL", MB_ICONSTOP | MB_OK );
WSACleanup( );
return FALSE;
}
/* The WinSock DLL is acceptable. Proceed. */
sockaddr_in sin;
memset( &sin, 0, sizeof sin );
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = INADDR_ANY;
sin.sin_port = htons( server_port );
if ( bind( server_socket, (SOCKADDR*) &sin, sizeof(sin) ) ==
SOCKET_ERROR )
{
TRACE( "Error at socket(): %ld\n", WSAGetLastError() );
::MessageBox( mainWnd, "Error bind failed", "GAL", MB_ICONSTOP |
MB_OK );
closesocket(server_socket);
WSACleanup();
return FALSE;
}
TRACE("Server started at port 5001\n");
/* Server started */
94
thread_on=true;
while (thread_on)
{
client_socket = accept( server_socket, NULL, NULL);
if (client_socket != INVALID_SOCKET )
{
m_strRecv = ""; //reset the string for a new receive
do{
nRead = recv(client_socket,buff,1,0);
switch (nRead)
{
case 0:
break;
case SOCKET_ERROR:
last_err = WSAGetLastError();
TRACE( "Error at socket(): %ld\n", last_err );
::MessageBox( mainWnd, "Error receive failed", "GAL",
MB_ICONSTOP | MB_OK );
break;
default:
buff[nRead] = 0; //terminate the string
CString szTemp(buff);
ioctlsocket(client_socket, FIONREAD, &num_data_pending);
if (num_data_pending==0) nRead=0;
m_strRecv += szTemp;
}
}while(nRead>0);
//http message received
TRACE("HTTP message received %s---\n", m_strRecv.GetBuffer());
curPos= 0;
resToken= m_strRecv.Tokenize(" /?=&",curPos); //first token
if (resToken == "GET") {
resToken = m_strRecv.Tokenize(" /?=&",curPos); //second token
TRACE("macro: %s\n", resToken);
/* The case statement is not applicable to CString!!! this is a
trick for more readable code */
if (resToken == "discovery"){
::PostMessage( mainWnd, WM_USER+DISCOVERY, (WPARAM)
sizeof(client_socket), (LPARAM) client_socket);
goto exit_case;
}
if (resToken == "nodeservice"){
resToken= m_strRecv.Tokenize(" /?=&",curPos);
if(resToken == "node"){
resToken= m_strRecv.Tokenize(" /?=&",curPos);
nodeservice_param * par = new nodeservice_param;
par->reply_socket = client_socket;
par->node = atoi(resToken.GetBuffer());
::PostMessage( mainWnd, WM_USER+NODESERVICE, (WPARAM)
sizeof(par), (LPARAM) par);
goto exit_case;
}
else goto default_case;
}
if (resToken == "notification"){
::PostMessage( mainWnd, WM_USER+NOTIFICATION, (WPARAM)
sizeof(client_socket), (LPARAM) client_socket);
goto exit_case;
}
95
default_case: TRACE("Wrong GAL request\n");
XMLString = "<error>Wrong GAL request</error>";
/*send( client_socket, XMLString.GetBuffer(),
XMLString.GetLength(), 0 );
closesocket(client_socket);
TRACE("connection closed\n");*/
MySend(client_socket, XMLString);
exit_case: TRACE("");
}
else //if first token is not "GET"
{
TRACE("Wrong HTTP request\n");
XMLString = "<error>Wrong HTTP request</error>";
/*send( client_socket, XMLString.GetBuffer(),
XMLString.GetLength(), 0 );
closesocket(client_socket);
TRACE("connection closed\n");*/
}
}
else // if client_socket is invalid
{
if (thread_on==true) ::MessageBox( mainWnd, "Error invalid
accepted socket", "GAL", MB_ICONSTOP | MB_OK );
}
} //close bracket of while(thread_on)
TRACE("Thread exit--------------------------------------------------
\n");
WSACleanup();
return TRUE;
}
6.3.5. Node
class Node{
char chIEEE[24];
unsigned char ieee_addr[8];
char chNWK[5];
unsigned short nwk_addr;
std::list<SimpleDescriptor *>::iterator iteSD;
std::list<Node *>::iterator iteN;
HTREEITEM tmp; //
public:
Node(unsigned short nwk_addr_par);
~Node();
NodeDescriptor node_desc;
PowerDescriptor power_desc;
std::list <SimpleDescriptor *> simple_desc;
std::list <Node *> Sons;
void set_ieee_addr(unsigned char * ptr_ieee);
char * get_ieee_addr();
char * get_nwk_addr();
void XMLWrite(std::ostream * XMLstream);
void ServiceReq(CZigBeeIf * hZB, int * count);
void BuildTreeCtrl(CTreeCtrl * ntc, HTREEITEM ti_parent);
};
96
7. Riferimenti
97