DSPLabs Technical Reportdsplabs.cs.upt.ro/grants/melissevs/pdfs/DSPL-TR.2009.1.pdf · finalizare,...

Digital Signal Processing Laboratories in Timisoara

Department of Computer and Software Engineering POLITEHNICA University of Timisoara 2, Vasile Parvan Blvd., 300223 – Timisoara, Romania Tel: + 40 256 403271, Fax: + 40 256 403214 Http://dsplabs.cs.upt.ro/

DSPLabs

Technical Report

DSPL-TR.2009.1 Title Dezvoltarea unui model pentru reprezentarea

solutiilor de comunicatie in cadrul retelei de senzori Authors Bogdan Stratulat, Mihai V. Micea

Language Romanian

Project ID MELISSEVS

Project Title Model for rEpresentation of coLlaborative robotic and Intelligent Sensor Systems in EnVironment exploration and Supervision applications

Project Type Grant PNCDI II - "IDEAS" Program, Code "ID-22"

Activity ID 1.1

Year 2009



2 DSPLabs Technical Report, DSPL-TR.2009.1

Cuprins

1 Introducere 3

2 Modelul pentru reprezentarea solutiilor de comunicatie 5 2.1 Modelul A.......................................................................................................... 5 2.2 Modelul B.......................................................................................................... 7 2.3 Modelul C........................................................................................................ 12

3 Concluzii 21

Referinte bibliografice 22



DSPLabs Technical Report, DSPL-TR.2009.1 3

1 Introducere

Scopul principal al proiectului MELISSEVS este conceperea si implementarea unei platforme-sistem complexe (hardware, software, metodologii si protocoale specifice) destinate studiului teoretic si aplicativ al mediilor colaborative de microsisteme timp-real autonome cu inteligenta incorporata, precum si utilizarea acesteia in dezvoltarea aplicatiilor de anvergura, cu impact direct asupra societatii informationale moderne, introducerii tehnologiilor de ultima ora in industrie si protectia mediului. Proiectul se concentreaza asupra aspectelor de proiectare, dezvoltare si implementare a modelului de platforma-sistem precum si testarea functionala a acesteia. Modulul WIT (Wireless Intelligent Terminal) a fost proiectat pe baza principiului de modularitate cu un maximum de flexibilitate la nivelul suportului hardware. Un modul de tip WIT este alcatuit din mai multe placi (submodule) care pot fi conectate la nivel fizic formand un singur bloc (vezi Fig. 1). De asemenea, se asigura si o conexiune la nivelul transferului de informatii intre aceste componente avand ca suport fizic magistrala si protocolul SPI. Fiecare din modulele care formeaza un terminal WIT are o arhitectura proprie dispunand de resurse specifice la nivel hardware si software. Resursele de care dispune fiecare modul sunt specifice operatiilor pentru care modulul a fost proiectat. In varianta minimala, modulul WIT dispune de trei submodule:

Placa de baza: dispune de cele mai multe resurse de procesare si memorie, avand rolul de coordonare a celorlaltor module din sistem. Pe placa de baza ruleaza principalele componente software ale WIT cu rol de supervizare, planificare si prelucrare de date.

Modulul de comunicatie: dispune de o interfata de comunicatie wireless si are rolul de a asigura transmisia de date intre terminalul WIT si reteaua din care acesta face parte. Pe acest modul vor rula componentele software care implementeaza serviciul de comunicatie (pe acest modul se va implementa stiva de protocoale de comunicatie).

Placa de alimentare: contine circuistica necesara asigurarii tensiunilor de alimentare necesare fiecarui modul la parametri necesari unei functionari optime. Pe langa cele mentionate mai sus placa de alimentare mai are si rolul de supervizor al consumului de energie precum si al nivelului de incarcare al acumulatorilor. Toate informatiile legate de sursa de energie a sistemului sunt raportate periodic sau la cerere de catre placa de alimentare catre placa de baza pentru luarea deciziilor corespunzatoare legate de politica de eficientizare a consumului de energie.




BaseProcessing

Module

Support andOperation

Module

PerceptionModule

CommunicationModule

WIT

BaseProcessing

Module

Support andOperation

Module

PerceptionModule

CommunicationModule

WIT

Fig. 1. Modulul WIT.

Sistemul MELISSEVS este gandit ca o platforma formata dintr-o colectie de sisteme WIT cu posibilitate de comunicare wireless, multi-hop, intr-o maniera specifica retelelor de senzori. Acest fapt confera o importanta majora modulului de comunicatie acesta fiind utilizat pe langa transferul datelor si la alte operatiuni cum ar fi sincronizarea nodurilor sau localizarea acestora pe baza puterii semnalului receptionat (RSSI) sau a determinarii conectivitatii cu noduri a caror pozitie este cunoscuta. Nivelul superior de abstractizare a modelului MELISSEVS este reprezentat de entitatea BRAIN (Background Robotic Activity Induction Node), implementata cu ajutorul unui calculator gazda (PC) cu conectivitate sporita pentru comunicatii, pe care ruleaza un sistem de pachete software specializate. La nivelul perceptiei si operarii, sistemul MELISSEVS interactioneaza cu mediul inconjurator prin intermediul microsistemelor autonome cu inteligenta incorporata, denumite WIT (Wireless Intelligent Terminal). Elementele WIT pot avea functii de perceptie (senzori inteligenti), de operare/actionare (mini-roboti autonomi), sau combinate. Nivelul superior de abstractizare, entitatea BRAIN, este situata pe un calculator PC extrem de performant. Nivelul BRAIN supravegheaza toate entitatile WIT, este responsabil, totodata, si pentru interfata cu utilizatorul; este punctul de intrare pentru oricare informatie a utilizatorului. Entitatea BRAIN este conectata la reteaua de WIT-uri printr-un dispozitiv de tip gateway/punct de acces, care este de fapt un simplu dispozitiv WIT cu capacitati de conectare la un PC (Ethernet incorporate, embedded Ethernet).




2 Modelul pentru reprezentarea solutiilor de comunicatie

Modelul propus ca si solutie de comunicatie este format dintr-o entitate BRAIN si n entitati WIT. Comunicatia la nivel BRAIN – WIT precum si WIT – WIT este de tip wireless. S-a optat pentru folosirea protocolului de comunicatie IEEE 802.15.4 (Zigbee) datorita avantajelor sale, printre care :

costul redus al echipamentelor de comunicatie folosite

consum de energie redus

folosirea unor benzi de radio ce nu necesita licentiere

crearea de retele flexibile si extensibile Elementul aparte al modelului propus, il reprezinta BRAIN, care intr-o prima faza a fost considerat ca fiind un calculator gazda, ce stocheaza informatia primita de la entitatile WIT si caruia ulterior i s-a mai adaugat un modul software de gestionare si statistica a datelor existente in propria baza de date. Acest modul incorporeaza si interfata cu utilizatorul si va fi prezentat in subsectiunile ce urmeaza. Pentru dezvoltarea unui model de comunicatie cat mai adecvat sistemului MELISSEVS, s-au creat treptat trei modele, denumite A, B si C si care vor fi prezentare in cele ce urmeaza. Modelul A reprezinta cel mai simplu model de comunicatie folosit pentru sistemul MELISSEVS. Dupa indeplinirea obiectivelor modelului A, pe baza cunostiintelor si rezultatelor obtinute, a fost dezvoltat modelul B, ce adauga elemente noi modelului deja existent. Modelul C reprezinta cel mai complex model pentru reprezentarea solutiilor de comunicatie.

2.1 Modelul A

Modelul A, reprezentat in Fig. 2, se compune din:

Elementul BRAIN, ce reprezinta o varianta intermediara a modelului propus spre finalizare, ce nu contine partea de interfata cu utilizatorul si nici modulul de stocare a datelor primite;

Elementele WIT, in numar de 4 sau 5, se afla si ele intr-un stadiu intermediar si, in ceea ce priveste modulul de comunicatie, sunt formate dintr-o interfata wireless bazata pe protocolul IEEE 802.15.4 (Zigbee) si o componenta software care are rolul de a genera anumite pachete de date, cu rol de testare a comunicatiei existente.




Fig. 2. Modelul A pentru reprezentarea solutiilor de comunicatie.

Pentru acest model de comunicatie s-a pus accentul pe sincronizarea in timp a unei astfel de retele de senzori bazate pe protocolul Precision Time Protocol conform cu standardul IEEE 1588 [1] − [4]. Dupa un studiu atent al protocoalelor de sincronizare existente, a fost ales protocolul de sincronizare Precision Time Protocol datorita performantelor superioare in ceea ce priveste acuratetea sincronizarii unei retele. Au fost simulate si testate doua abordari diferite de implementare a protocolului Precision Time Protocol pentru retele multi-hop, folosind mediul oferit de OMNeT++ [5]: o varianta ce utilizeaza noduri intermediare cu "boundary clock", respectiv cea care utilizeaza noduri intermediare cu "transparent clock". A fost realizata o comparatie a valorilor obtinute pentru ambele cazuri. Trebuie precizat faptul ca in aceasta etapa s-a urmarit sincronizarea pentru o retea statica, urmand ca in etapele urmatoare sa se urmareasca si dezvoltarea unui protocol de sincronizare si pentru o retea cu caracter dinamic. O retea statica presupune faptul ca pe parcursul comunicatiei nu vor interveni modificari in ceea ce priveste topologia existenta atat in ceea ce priveste pozitia acestora, cat si din punct de vedere al rolului de slave si/sau master, relativ la celelalte noduri ale retelei. Acest fapt inseamna ca s-a implementat protocolul conform descrierii sale existente in standardul propus, fara realizarea unor modificari care sa transforme protocolul existent intr-unul specializat pentru tipul de retea utilizat in cadrul proiectului.




2.2 Modelul B

In a doua etapa de dezvoltare, s-a plecat de la Modelul A, si s-au adaugat un protocol de routare a elementelor WIT, o serie de modificari in structura modulului de comunicatie. De asemenea, pentru elementul BRAIN a fost dezvoltata o interfata cu utilizatorul, precum si un modul, cONDEsCEND (Organize aNd view Data collEcted by the CEntral NoDe), ce are rolul de evaluare a datelor prelevate de la elementele WIT. Elementele WIT din Modelul B, contin la nivelul modulului de comunicatie, pe langa interfata wireless bazata pe protocolul IEEE 802.15.4 (Zigbee), o componenta senzoriala, cu rol de prelevare a diferitelor date provenite din mediul inconjurator. Datele sunt prelevate la intervale predeterminate sau variabile de timp. Senzorii nu detin parametri de control sau alarme, ci inregistreaza si transmit informatiile. Odata cu folosirea senzorilor, procesarea integrata si comunicatia fara fir devin omniprezente, si sunt necesare modalitati noi de conectare, organizare, interogare si programare a acestora. Pentru a pune la punct un sistem de monitorizare a unui mediu este necesara stabilirea unei zone de lucru si a unor parametri de control. Zona de lucru va stabili pozitia senzorilor, iar parametrii de control vor reprezenta date de intrare pentru aplicatia client ce ruleaza pe nodul BRAIN al modelului. Este necesar ca o astfel de aplicatie sa furnizeze date corecte, in formatul dorit de catre utilizator. Modulul cONDEsCEND reprezinta o solutie pentru organizarea, stocarea si vizualizarea datelor prelevate de catre BRAIN si se concentreaza pe senzorii elementelor WIT. Agregarile de date pot fi utile si in stabilirea unor sabloane temporale si spatiale. In aplicatiile de monitorizare a temperaturilor de exemplu, hartile termice sunt esentiale [6], [7]. Pe baza unor seturi de astfel de sabloane, agregate in timp, se pot stabili eventuale dereglari de temperatura, semnificative pe termen lung, si care nu au fost considerate importante pe termen scurt. Aceste aplicatii pot fi folosite si in realizarea unor predictii. Desigur, va fi nevoie de stabilirea unor seturi de date de catre utilizator, studierea diagramelor si alegerea scenariului care produce rezultatul optim, dintre acestea. Ca si exemplu practic, sa consideram amplasarea de senzori pe suprafata unei gradini zoologice. Pe harta deja existenta (delimitata pe zone geografice) se pot stabili locatii initiale pentru senzori, care vor putea fi apoi imbunatatite prin crearea si vizualizarea unei diagrame geometrice. O astfel de aplicatie se mai poate utiliza si in testarea unor echipamente instalate in medii industriale unde de multe ori temperaturile trebuie pastrate cu strictete.




Datele sunt stocate intr-o baza de date de tip SQL si sunt organizate in doua tabele: un tabel care contine detalii despre senzori si un tabel care contine datele prelevate de acesti senzori. Interogarile catre baza de date, si maparea in obiecte se fac prin platforma LINQ. Se pot genera grafice pentru informatiile prelevate de fiecare senzor intr-o perioada de timp selectata. Utilizatorul poate vizualiza astfel eventuale modificari bruste ale unor valori, la anumite locatii, in functie de pozitia senzorului in retea. Modulul cONDEsCEND este realizat cu ajutorul limbajului de programare C# si a IDE-ului Visual Studio 2008 Express Edition, produs de Microsoft. Pentru a rula aplicatia este nevoie de .NET Framework 3.5. Interogarile catre baza de date sunt implementate cu ajutorul componentei LINQ (Language Integrated Query), parte integranta a platformei .NET 3.5. Microsoft a ales limbajul C# pentru dezvoltarea unor extensii care sa usureze folosirea LINQ. Modulul cONDEsCEND al Modelului B este compus la randul sau din:

modulul de acces la baza de date,

modulul de generare a graficelor. Utilizatorul final poate sa vizualizeze datele prelevate de senzori in doua moduri: sub forma de tabel sau sub forma de grafic. Aplicatia pune la dispozitie mai multe filtre pentru date ce pot fi selectate de catre utilizator, precum si optiuni cu modul de afisare dorit. S-au implementat filtre pentru senzori, perioade si pentru tipul de date dorit. Exista trei optiuni pentru vizualizarea graficelor: grafic cu axe pentru vizualizarea datelor prelevate de un singur nod intr-o anumita perioada, grafic cu axe pentru analiza comparativa a datelor prelevate de mai multi senzori in aceeasi perioada, grafic generat dinamic in scopul observarii datelor prelevate de un anumit senzor in timp real. Pentru gasirea celei mai bune solutii de rutare a Modelului B folosind sistemul MELISSEVS, s-a trecut la studierea a trei protocoalele de rutare: AODV, DSR, DYMO. De remarcat este faptul ca aceste protocoale sunt create pentru a fi folosite de catre standardul IEEE 802.11. Faptul ca sistemul MELISSEVS foloseste standardul IEEE 802.15.4 nu a reprezentat un impediment pentru protocoalele AODV si DYMO, deoarece acestea sunt operabile si pe acest standard. Pe de alta parte, protocolul DSR nu a fost transpus in standardul folosit de sistemul MELISSEVS, dar acest lucru a fost realizat in Modelul B de comunicatie. Fig. 3 reprezinta grafic clasificarea solutiilor de routare in functie de standardul folosit. Linia continua simbolizeaza descendenta directa iar cea punctata reprezinta descendenta logica. Punctul forte al protocolului AODV [8] este faptul ca rutele sunt determinate doar cand este nevoie sa se transmita informatie de la sursa catre destinatie. Cand sursa are de transmis catre o destinatie inca necunoscuta, atunci emite un mesaj de Route Request (RREQ) pentru acea destinatie. La fiecare nod intermediar, cand un mesaj RREQ este receptionat se creaza o ruta catre detinatie.




Daca nodul receptor nu a mai receptionat RREQ, nu este nodul destinatie si nu are ruta curenta spre destinatie atunci acest nod retransmite acest mesaj de RREQ. Daca nodul este nodul destinatie sau dispune de o ruta curenta spre destinatie atunci genereaza un mesaj de Route Reply (RREP). Acest tip de mesaj este transmis din nod in nod pana la sursa, astfel fiecare nod intermediar creeaza o ruta spre destinatie. Cand nodul sursa receptioneaza mesajul de RREP, retine ruta spre destinatie si poate incepe sa trimita date. Daca sunt primite mai multe mesaje de tip RREP de catre sursa, atunci este aleasa ruta cu numarul cel mai mic de noduri intermediare.

IEEE

802.15.4

Protocoale de rutare ad hoc

Bazate pe tabele de rutare Bazate pe iniţierea rutelor de către sursă la cerere

DSDV WRP

CGSR

DSR LMR ABR

TORA SSR

AODV

DYMO

AODVjr. AODVbis LoWPAN-AODV LOAD

TinyAODV NST-AODV

IEEE

802.11

Fig. 3. Clasificarea protocoalelor de rutare wireless.

Pe masura ce data este transmisa de la sursa spre destinatie, fiecare nod isi actualizeaza timer-ul asociat rutei care este retinuta intr-un table de rutare. Daca un nod nu este utilizat pentru o anumita perioada de timp atunci el devine candidat la stergere din tabela de rutare. Daca in timp ce se transmit date se detecteaza ca ruta s-a intrerupt, atunci se transmite un mesaj din nod in nod spre sursa de tip Error (RERR). In timpul propagarii acestui mesaj fiecare nod intermediar ce primeste acest mesaj invalideaza aceasta ruta. Cand RERR ajunge la nodul sursa, invalideaza ruta si daca este necesar, reinitiaza procesul de redescoperire a rutei (vezi Fig. 4).




Fig. 4. Schimbul de mesaje al protocolului AODV (sursa [8]).

Autoconfigurarea si autoorganizarea retelei fara necesitatea unei infrastructuri sau a administrarii, face ca protocolul DSR sa fie o optiune reala pentru retelele adhoc mobile wireless multi-hop. Protocolul este compus din doua mecanisme de Route Discovery si Route Maintenance care lucreaza impreuna ca sa permita nodurilor sa descopere si sa mentina posibelel rute de la sursa spre destinatii arbitrare in retelel ad hoc. Aceste doua mecanisme evita necesitatea ca informatiile despre rute sa fie tot timpul actualizate in nodurile intermediare in timp ce datele parcurg ruta de la sursa spre destinatie. Route Discovery este mecanismul prin care un nod S care vrea sa transmita un pachet spre un nod D, obtine o ruta spre D. Acest mecanism este folosit doar inca S incearca sa transmita un pachet spre D dar ruta este inca necunoscuta [9] (vezi Fig. 5).

Fig. 5. Descoperirea rutei: A – nod sursa, E – nod destinatie (sursa [9]).

Route Maintenance este mecanismul prin care un nod S este capabil sa detecteze, in timp ce foloseste o ruta spre nodul D, daca topologia retelei s-a schimbat in asa fel incat ruta curenta spre nodul D nu mai poate fi folosita din cauza unei legaturi intrerupte. Cand mecanismul de mentenanta a rutei identifica aceasta ruta intrerupta, nodul S poate folosi alta ruta spre D sau poate declansa mecanismul de descoperire a rutei. Mecanismul de mentenanta este folosit doar cand nodul S trimite pachete spre nodul destinatie D [9] (vezi Fig. 6).




Fig. 6. Mentenata rutei: nodul C nu poate retransmite de la A spre nodul E prin intermediul

nodului D (sursa [9]).

Cel mai recent protocol de rutare reactiv (on-demand) este DYMO; acest protocol fiind intr-o continua dezvoltare in cadrul grupului MANET apartinand IETF (Internet Engineering Task Force). DYMO este proiectat avand la baza experienta acumulata de-a lungul dezvoltarii protocoalelor de rutare deja existente, in special protocolul AODV [10]. Acest protocol de rutare este proiectat astfel incat, pe langa informatiile despre nodul destinatie, un nod va retine informatii despre toate nodurile intermediare a rutelor nou descoperite. Diferenta majora intre DYMO si AODV este ca ultimul genereaza intrari in tabela de rutare pentru nodul destinatie si pentru nodul urmator, pe cand DYMO stocheaza rute pentru fiecare nod intermediar. Acest aspect este evidentiat in Fig. 7, in cazul protocolului AODV, nodul A “stie” doar ruta spre B si D dupa ce RREQ este satisfacut, spre deosebire de protoculul DYMO in care nodul A “stie” si ruta spre nodul C [10].

Fig. 7. Diseminarea informatiei in AODV si DYMO.

Proiectarea si implementarea unui protocol de rutare este un proces complex ce presupune si o faza preliminara de simulare. Dupa acesta faza, in care implementarea se dovedeste a fi una matura, se incearca evaluarea comportarii protocolului intr-un mediu real. Cele trei protocoale prezentate anterior, AODV, DSR si DYMO au fost simulate pe diferite tipologii de retele de tipul Modelului A si B, folosind-se un framework caracteristic, ce se bazeaza pe definirea unui nou modul numit MRouting care comunica la nivelul retetea (Network Layer) prin intermediul IP. In acest modul denumit MRouting, se poat integra modular oricare din cele trei protocoale, astfel se poate simula aceeasi retea cu fiecare protocol in parte si se pot face evaluari cantitative si calitative ale comportamentului retelei. Pentru platforma sistemului MELISSEVS, proiectarea unui protocol hibrid tine cont de cerintele de mobilitate si autoconfigurare a topologiei retelei ce vor aparea la




urmatoarele modele pentru reprezentarea solutiilor de comunicatie, cerinte care pot fi satisfacute de caracterul dinamic de autoconfigurare a protocolului DSR. Cu toate acestea, trebuie mentionat faptul ca si caracteristicile de descoperire a rutei cu memorarea posibilelor cai ce pot fi satisfacute de particularitatile protocolul AODV sau DYMO, pot fi considerate solutii probabile de routare.

2.3 Modelul C

Cel mai complex model pentru reprezentarea solutiilor de comunicatie, denumit si Modelul C, este dezvotat din primele 2 modele prezentate anterior, la care s-au mai adus imbunatatiri in ceea ce priveste structura sa generala, precum si a elementelor componente WIT si BRAIN. Referitor la structura sa generala, s-a stabilit plasarea elementelor WIT pe nivele de comunicatie, pentru realizarea unor reguli de comunicare din punct de vedere al sincronizarii, rutarii si localizarii. Astfel daca la modele anterioare, pozitia elementelor WIT era statica, in ceea ce priveste Modelul C, acestea sunt dinamice, adica permite schimbari in topologia retelei in urma deplasarii unora dintre noduri, sau in urma aparitiei de noduri noi, respectiv a disparitiei unor noduri existente in retea. De asemenea, nodurile se pot muta de pe un nivel pe altul sau in cadrul aceluiasi nivel. Practic topologia propusa devine flexibila si complexa, si tine cont in fiecare moment de pozitia trecuta si actuala a fiecarui WIT. Acest lucru a dus la aprofundarea si extinderea anumitor protocoale ce au fost dezvoltate in modelele anterioare.

Fig. 8. Modelul C pentru reprezentarea solutiilor de comunicatie.




Protocolul de sincronizare propus anterior, se referea strict la o structura statica, ceea ce inseamna ca pe parcursul comunicatiei nu vor interveni modificari in ceea ce priveste topologia existenta atat in ceea ce priveste pozitia elementelor WIT, cat si din punct de vedere al rolului de slave si/sau master, relativ la celelalte elemente WIT ale retelei. Acest fapt inseamna ca s-a implementat protocolul conform descrierii sale existente in standardul IEEE 1588 propus, fara realizarea unor modificari care sa transforme protocolul existent intr-unul specializat pentru tipul de retea utilizat in cadrul proiectului. In acest sens, a fost necesara o propunere de imbogatire a standardului pentru ca acesta sa fie aplicabil pe medii colaborative robotizate, sau pe retele dinamice de senzori wireless in general. Astfel, s-a propus in realizarea unui protocol cu caracter dinamic, adica a unui protocol de sincronizare care ia in considerare problemele specifice care apar in cazul retelelor dinamice de senzori inteligenti. Problemele abordate in dezvoltarea noului protocol sunt:

autentificarea unui nou element WIT aparut in retea: poate fi vorba si de un WIT vechi, dar care se reactiveaza sau reintra in raza de actiune a retelei

disparitia unui element WIT denumit end-device: problema este mai simpla pentru ca nu implica un numar de noduri care raman fara master. Acest nod end-device este de fapt ultimul nod de pe un anumit nivel ce nu este master pentru nici un alt nod aflat pe un nivel inferior.

disparitia unui nod WIT master – reprezinta un caz mai complex deoarece trebuie tratata si problema determinarii unui master nou pentru slave-ii corespunzatori.

O prima problema care se pune in cazul Modelului C este tratarea aparitiei unui nou WIT in retea. Avand in vedere protocolul PTP, pentru ca noul element WIT sa se poata preta la sincronizarea propusa, trebuie sa se conecteze la retea astfel incat sa existe un nod WIT master cu care sa poata comunica prin pachetele de sincronizare specifice protocolului, sau eventual sa comunice direct cu elementul BRAIN. Felul in care ar trebui tratata adaugarea unui nou element WIT la retea in perspectiva utilizarii protocolului de sincronizare PTP este descris cu pasii urmatori:

Noul element WIT aparut trebuie in primul rand sa trimita un pachet de autentificare la retea. Astfel toate elementele WIT aflate in raza sa de actiune vor primi pachetul, dar numai cele care au si rol de master il vor interpreta, un end device simplu urmand sa ignore pachetul.

Cand un element WIT ce indeplineste si functia de master (sau elementul BRAIN) primeste un pachet de autentificare de la un nod nou, raspunde cu un pachet de confirmare a autentificarii. E posibil ca elementul WIT cel nou sa primeasca mai multe confirmari, din partea mai multor elemente WIT – master daca e in raza de actiune a acestora, dar il va lua in considerare doar pe primul.

Daca nu primeste raspuns la expirarea timer-ului timer_register, va intra in starea idle pentru un timp predefinit, dupa care se va reactiva si va reincepe procesul de gasire a unui nou element ce ii va deveni master.




Elementul WIT ce a cerut conectarea la retea raspunde mesajului de confirmare sosit de la primul master, acceptand sa devina slave al elementului respectiv.

Celelalte elementele WIT master, nemaiprimind nici un mesaj dupa un timp t, renunta la a mai stabili contact cu noul nod.

Elementul master introduce noul nod in vectorul sau de slave si raspunde din nou cu un mesaj spunand ca este noul master al nodului nou venit.

Daca elementul nou venit nu primeste acest ultim mesaj si timer-ul timer_register nu a expirat, va retrimite primul pachet de autentificare incercand sa caute un alt master si se reia tot procesul.

Astfel, se impune adaugarea unor noi tipuri de pachete definite pentru comunicarea dintre nodurile master si nodurile slave corespunzatoare acestora. Schema logica a algoritmului de adaugare a unui nou element WIT din punct de vedere al sincronizarii este prezentata in Fig. 9. In cazul disparitiei unui element WIT din cadrul retelei, din diferite motive (intreruperea alimentarii cu curent a nodului, deplasarea intr-o arie de unde semnalul nu mai e receptionat, erori hardware, etc) s-a dezvoltat un algoritm de refacere a topologiei retelei. Daca elementul disparut este un end device, problema este mai simpla pentru ca nu implica un numar de elemente din cadrul retelei care raman fara master. Practic elementele WIT master trimit cate un pachet de verificare, catre elementele WIT slave ale sale, care au datoria sa raspunda cu pachete DREQ. Elementele WIT master contin o lista cu elementele slave proprii pe care o vor putea verifica descoperindu-se astfel daca ua primit raspuns de la toate elementele slave proprii. Daca master-ul nu primeste raspuns de la un nod intr-un interval de timp, va scoate nodul considerat disparut din vectorul de slave. Un caz mai complex de disparitie de nod il reprezinta situatia in care dispare un element WIT - intermediar. Daca elementul WIT disparut indeplinea si functia de master, inseamna ca un numar de noduri erau conectate la el si au ramas fara master. Nodurile slave ale elementului WIT iesit din retea, observand ca nu au primit nici un mesaj SYNC dupa expirarea unui timer, vor incerca sa stabileasca un contact cu master-ul lor folosind chiar un mesaj predefinit deja in protocolul PTP, si anume DREQ. Daca nu primeste raspunsul asteptat, un element WIT slave va considera master-ul disparut si va sterge adresa acestuia din memorie. In continuare, incepand cu primul pas, fiecare element WIT slave orfan va relua algoritmul de autentificare la retea prezentat mai sus. Elementele WIT care gasesc master se vor conecta la retea, si vor putea deveni master la randul lor. In cazul in care unele elemente WIT nu reusesc sa isi gaseasca master, acestea se vor conecta la nodurile slave care au reusit sa isi gaseasca master. Daca un element WIT nu reuseste sa isi gaseasca master nici printre elementele WIT slave conectate la retea, poate intra in stare de idle si sa reincerce dupa un interval de timp, sperand in recuperarea master-ului vechi sau in aparitia unui master nou.




Fig. 9. Schema logica a algoritmului de adaugare a unui nou element WIT din punct de

vedere al sincronizarii.

Protocolul de localizare a fost realizat folosind mediul de dezvoltare Keil uVision V3.9. S-a urmarit ca sistemul sa fie independent de repere fixe prestabilite. Sistemul de localizare trebuie sa fie rapid, eficient si fara mari pierderi de energie. De asemenea pe parcursul proiectului s-a urmarit ca sistemul final sa ajunga la un cost cat mai mic.




Pornind de la faptul ca sistemul este destinat elementelor WIT dinamice s-a stabilit ca este foarte important sa se foloseasca estimarea locului unde acestea ar putea sa ajunga. In functie de tipul rotilor, motoarelor si chiar si a suprafetei, valoarea de aproximare creste sau scade. In cadrul acestui sistem de localizare acuratetea acestei deplasari nu este foarte importanta. Sistemul de localizare se ocupa cu corectia acestei erori. Corectia se realizeaza prin recalcularea pozitiei elementului WIT fata de alte doua elemente care au la un moment dat rolul de referinte, referinte ale caror pozitii sunt cunoscute. Aceasta recalculare a pozitiei se realizeaza pe baza a doua semnale: semnalul radio si semnalul de ultrasunete si de faptul ca semnalul radio este de 106 ori mai rapid decat semnalul de ultrasunete. Fiecare WIT al Modelului C este echipat si cu un dispozitiv hardware care contine o antena radio si doi transductori: unul de receptie si unul de transmisie a ultrasunetelor. S-a stabilit ca elementele WIT detin o zona de raza 2 m denumita MyHome. In timpul deplasarii, WIT-ul isi muta si zona de acoperire. Cu alte cuvinte el nu este dependent de zona initiala in care s-a aflat. Pentru ca acesta sa poata fi localizat este necesar ca in zona MyHome sa fie prezente cel putin inca 2 elementele WIT (pozitia acestora fiind cunoscuta). Zona MyArea reprezinta o extensie a zonei MyHome, cu raza 4 m. Daca elementul WIT necesita o localizare si nu are repere in zona MyHome atunci el ar putea sa foloseasca repere si din MyArea cu conditia ca distanta dintre repere sa fie mai mare de 4 m. Trebuie mentionat ca si pozitia de start are asociata o zona MyHome si una MyArea. Aceasta corespunde coordonatorului de sistem. Din punct de vedere al structurii elementului BRAIN, Modelul C aduce imbunatatiri ce tin de modulul cONDEsCEND. Astfel pe langa datele prelevate de fiecare senzor intr-o perioada de timp selectata, ce pot fi vizualizate, s-a dezvoltat partea grafica astfel incat este posibila preluarea de date statistice, sub forma unor diagrame. Utilizatorul are posibilitatea de selectie a WIT-urilor de care este interesat (de exemplu dintr-o zona in care a observat nereguli) si a-si crea o imagine compusa a comportamentului. Concret, se pot crea statistici grafice cu valori minime, medii si maxime inregistrate de senzorii selectati in perioada dorita. Cea mai uzuala vizualizare a unor date prelevate de la elementele WIT, este prin intermediul hartilor caracteristice (de exemplu pentru temperatura, crearea de harti termice) asemanatoare cu cele de la prognoza meteo. In realizarea ei se foloseste insa un gradient de nuante de gri care aproximeaza valori aflate in imediata apropiere a unei valori inregistrate. Acestea sunt apoi suprascrise cu culori RGB, din ce in ce mai reci, cu cat valorile (nivelele de gri) scad. Generarea hartilor termice de exemplu, se face in doua etape. In prima etapa se creaza o masca cu intensitati. Aceasta masca este de fapt o imagine cu nuante de gri




(256 de nuante) care este utilizata pentru a marca intensitatea fiecarui pixel din imaginea finala. Fiecare nuanta din spectrul de la alb la negru are ca si corespondent o culoare din paleta de culori (Fig. 10 si Fig. 11). De remarcat faptul ca astfel de harti se pot crea pentru diferite tipuri de caracteristici existente in cadrul retelei noastre, cum ar fi harti hidrotermice, acustice, vizual-luminoase, etc.

Fig. 10. Paleta de culori.

Fig. 11. Masca cu intensitati (stanga) si harta termica rezultata (dreapta).

Un alt tip de harta, recomandata in realizarea de predictii, are la baza diagrame Voronoi. Pentru generarea lor este utilizat algoritmul lui Steven Fortune. In urma rularii, harta va fi divizata in celule, determinate, fiecare in parte de un anumit senzor. Utilizatorul va putea vedea, miscand cursorul pe harta, care este valoarea temperaturii inregistrata de senzorul determinant al celulei. Aceasta harta foloseste de asemenea culori in functie de temperaturi. Pentru a pastra o gestiune a datelor studiate sau rezultate cu ajutorul aplicatiei, se ofera posibilitatea salvarii hartilor, in format bitmap (*.bmp). In acest fel, pe langa tabele cu date statistice arhivate in mod normal de un administrator al unei astfel de retele, se pot pastra, pe suport digital si interpretari grafice ale acestora. In acest fel, ulterior se pot compara imagini preluate la timpi diferiti si se pot concluziona diverse reguli de schimbare de temperatura. Interfata grafica este proiectata pentru a fi prietenoasa si intuitiva, oferind mai multe cadre de lucru, in functie de nevoile fiecarui utilizator si de datele de care dispune la realizarea unui anume studiu, sau monitorizare.




Hartile termice sunt generate cu ajutorul GDI+ din .NET Framework. GDI/GDI+ ofera suport pentru desenarea de forme geometrice, text si imagini, cu costul sporirii complexitatii [11]. Odata cu introducerea WindowsXP, GDI a fost inlocuit de succesorului sau, subsistemul GDI+, care isi are bazele in C++. Spre deosebire de predecesorul sau, acesta acceseaza in mod direct placa grafica, asigurand accelerarea procesarilor grafice integrate in aplicatie. GDI+ adauga grafice 2D cu efect anti-alias, coordonate in virgula mobila, "gradient shading", administrarea complexa a rutelor, suport intrinsec pentru formate de fisiere grafice moderne precum JPEG si PNG, si suport pentru compozitia de transformari afine 2D. GDI+ utilizeaza valori ARGB (Alpha Red Green Blue) in reprezentarea culorilor. Datorita capacitatilor suplimentare de procesare a textului si independenta de rezolutie, randarea textului se face cu un ordin de magnitudine mai incet decat in GDI [11], [12]. Platforma .NET asigura o biblioteca de clase grafice, denumita GDI+ (Graphical Device Interface Plus). Aceste clase ofera metodele necesare pentru implementarea propriului cod pentru desenarea de grafice [12]. Graficele sunt generate cu ajutorul Windows Presentation Foundation (WPF). Aceasta este o platforma grafica de generatie urmatoare care este inclusa in Microsoft .NET Framework 3.0 si 3.5. WPF permite crearea unor interfete grafice avansate care incorporeaza documente, fisiere media, grafice 2D si 3D, animatii si alte componente web. Construit in platforma .NET 3.0 si 3.5, WPF asigura un mediu pentru dezvoltarea de aplicatii folosind sistemul de operare Windows. Pentru a facilita intelegerea algoritmului lui Steven Fortune, se vor descrie mai intai pe scurt proprietatilor diagramelor Voronoi. Considerand pi si pj doua amplasamente:

Muchia Voronoi (Voronoi edge): Fiecare punct de pe muchia unei diagrame Voronoi este echidistant fata de cei doi vecini cei mai apropiati ai sai pi si pj. Astfel, exista un cerc cu centrul intr-un astfel de punct, astfel incat pi si pj se afla pe acest cerc si nici un alt amplasament nu se afla in interiorul cercului (Fig. 12, stanga).

Varful Voronoi (Voronoi vertex): Punctul in care se intersecteaza trei celule Voronoi V(pi), V(pj) si V(pk) se numeste varf Voronoi si este echidistant fata de cele trei amplasamente pi, pj si pk. Acesta este centrul cercului ce trece prin aceste amplasamente. Cercul nu contine alte amplasamente in interiorul lui (Fig. 12, dreapta).

Rangul: Daca presupunem ca oricare patru amplasamente nu se afla pe circumferinta aceluiasi cerc, toate varfurile Voronoi au rangul trei.

Infasuratoarea convexa: O celula din diagrama Voronoi este nemarginita daca si numai daca amplasamentul corespunzator celulei se afla pe infasuratoarea convexa. Astfel, este usor de a extrage infasuratoarea convexa in timp liniar.

Dimensiunea: Daca n reprezinta numarul de amplasamente, atunci diagrama Voronoi este un graf planar (daca se considera ca toate muchiile nemarginite duc




catre un singur varf, la infinit) cu exact n fete. Conform formulei lui Euler numarul de varfuri Voronoi este cel mult 2n − 5 si numarul de muchii este cel mult 3n − 6.

Fig. 12. Proprietatile diagramelor Voronoi.

Cheia oricarui algoritm de tipul "plane sweep" este abilitatea de a anticipa evenimentele intr-o maniera eficienta. In cadrul generarii unei diagrame Voronoi apar probleme atunci cand trebuie anticipate locul si momentul in care vor aparea evenimentele. Utilizand un algoritm de tipul "plane sweep", in spatele liniei de scanare ("sweep line") diagrama Voronoi este deja construita pe baza amplasamentelor intalnite. Problema apare atunci cand un amplasament, ce se afla inaintea liniei de scanare, poate genera un varf in spatele acesteia. Algoritmul nu poate genera acest varf inainte de a intalni amplasamentul. Dar, atunci cand il intalneste, este deja prea tarziu (Fig. 13). Aceste evenimente care nu se pot anticipa ingreuneaza proiectarea algoritmilor de tipul "plane sweep".

Fig. 13. Evenimente neanticipate.

Steven Fortune a observat ca in loc de a calcula diagrama Voronoi in forma finala cu ajutorul unui algoritm de tipul "plane sweep", ar fi mai bine sa se calculeze o varianta deformata, dar echivalenta din punct de vedere topologic. Aceasta varianta deformata a diagramei se bazeaza pe o transformare care altereaza modul in care sunt calculate distantele in plan. Diagrama ce rezulta din aceasta metoda de calculare are aceeasi structura topologica ca si diagrama Voronoi, dar muchiile sale nu sunt segmente de




dreapta, ci arcuri parabolice. Odata ce aceasta diagrama deformata a fost calculata, este usor de generat varianta corecta a diagramei Voronoi. Algoritmului dezvoltat penrtu modului cONDEsCEND al Modelului C, difera fata de algoritmul Steven Fortune. In loc sa consideram ca diagrama este deformata, putem considera ca algoritmul deformeaza linia de scanare. De fapt, se considera ca doua obiecte sunt responsabile pentru procesul de scanare ("sweep"). In primul rand, o linie orizontala care se misca de sus in jos. In al doilea rand, se utilizeaza o curba x-monotona numita "beach line" (este denumita astfel deoarece seamana cu valurile care se lovesc de plaja). Linia este o curba monotona formata din bucati de arce parabolice. Pe masura ce "sweep line" se deplaseaza in jos, este urmata de linia de delimitare ("beach line") la distanta relativ mica. Functia "beach line" este menita sa previna evenimentele neanticipate pana cand linia de scanare intalneste amplasamentul corespunzator.




3 Concluzii

Modelul propus ca si solutie de comunicatie este format dintr-o entitate BRAIN si n entitati WIT. Comunicatia la nivel BRAIN – WIT precum si WIT – WIT este de tip wireless (IEEE 802.15.4 − Zigbee). Pentru dezvoltarea unui model de comunicatie cat mai adecvat sistemului MELISSEVS, s-au creat treptat trei modele, denumite A, B si C. Modelul A, se compune din elementul BRAIN, ce nu contine partea de interfata cu utilizatorul si nici modulul de stocare a datelor primite, si un numar de 4 sau 5 elemente WIT, aflate intr-un stadiu intermediar, formate dintr-o interfata wireless si o componenta software care are rolul de a genera anumite pachete de date, cu rol de testare a comunicatiei existente. Pentru Modelul B, s-a plecat de la Modelul A, si s-au adaugat un protocol de rutare a elementelor WIT, o serie de modificari in structura modulului de comunicatie. De asemenea, pentru elementul BRAIN a fost dezvoltata o interfata cu utilizatorul, precum si un modul, cONDEsCEND (Organize aNd view Data collEcted by the CEntral NoDe), ce are rolul de evaluare a datelor prelevate de la elementele WIT. Elementele WIT din Modelul B, contin la nivelul modulului de comunicatie, pe langa interfata wireless bazata pe protocolul IEEE 802.15.4 (Zigbee), o componenta senzoriala, cu rol de prelevare a diferitelor date provenite din mediul inconjurator. Datele sunt prelevate la intervale predeterminate sau variabile de timp. Senzorii nu detin parametri de control sau alarme, ci inregistreaza si transmit informatiile. Structura generala a Modelului C, stabileste plasarea elementelor WIT pe nivele de comunicatie, pentru realizarea unor reguli de comunicare din punct de vedere al sincronizarii, rutarii si localizarii. Astfel daca la modele anterioare, pozitia elementelor WIT era statica, in ceea ce priveste Modelul C, acestea sunt dinamice, adica permite schimbari in topologia retelei in urma deplasarii unora dintre noduri, sau in urma aparitiei de noduri noi, respectiv a disparitiei unor noduri existente in retea. De asemenea, nodurile se pot muta de pe un nivel pe altul sau in cadrul aceluiasi nivel. Practic topologia propusa devine flexibila si complexa, si tine cont in fiecare moment de pozitia trecuta si actuala a fiecarui WIT. Acest lucru a dus la aprofundarea si extinderea anumitor protocoale ce au fost dezvoltate in modelele anterioare.




Referinte bibliografice

[1] H. Cho, S. Son, Y. Baek, "Implementation of a Precision Time Protocol over Low Rate Wireless Personal Area Networks", Department of Computer Engineering, Pusan National University, 2008.

[2] H. Weibel, "IEEE 1588 Tutorial", Zurich University of Applied Sciences, 2006. [3] ***, "IEEE 1588 Protocol Overview", 2008. [Online]. Available:

http://www.rtaautomation.com/ieee1588/IEEE_1588_R2.pdf, 2008 [4] J. Eidson, M. Fischer, J. White, "IEEE-1588 Standard for a Precision Clock

Synchronization Protocol for Networked Measurement and Control Systems", 2003.

[5] ***, "OMNeT++", 2008. [Online]. Available: http://www.omnetpp.org. [6] K. Sohraby, D. Minoli, T. Znati, "Wireless Sensor Networks: Technology,

Protocols and Applications", Wiley-Interscience, 2007. [7] F. Zhao, L. J. Guibas, "Wireless Sensor Networks: An Information Processing

Approach", 2004. [8] I. D. Chakeres, E. M. Belding-Royer, "AODV Routing Protocol

Implementation Design", Proceedings of the 24-th International Conference on Distributed Computing Systems, 2004.

[9] D. B. Johnson, D. A. Maltz, J. Broch, "DSR: The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc Networks", Proceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking, Applications, Technologies, Architectures, and Protocols for Computer Communication, 2005.

[10] C. Sommer, I. Dietrich, F. Dressler, "A Simulation Model of DYMO for Ad Hoc Routing in OMNeT++", International Conference on Simulation Tools and Techniques for Commuications, 2008.

[11] M. MacDonald, "Pro WPF Programming in C# 2008", 2-nd Edition, Apress, 2008.

[12] I. Serban, D. Brezoi, T. Radu, A. Ward, "GDI+ Custom Controls with Visual C# 2005", PACKT Publishing, 2006.

Date post:	08-Feb-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

DSPLabs Technical Reportdsplabs.cs.upt.ro/grants/melissevs/pdfs/DSPL-TR.2009.1.pdf · finalizare,...

Documents