Proiect tehnici de Rutare în Reţelele de Senzori Wireless

2.2 Sisteme de operare şi medii de execuţie

Sarcinile convenţionale ale unui SO sunt controlul şi protecţia resurselor şi managementul alocării acestora utilizatorilor, precum şi suport pentru execuţia mai multor procese în paralel şi comunicarea între procese concurente.

Un SO proiectat pentru o WSN trebuie să suporte nevoile specifice ale unui astfel de sistem integrat: execuţie eficientă energetic, ce necesită management energetic (suport pentru DVS –Dynamic Voltage Scaling). Componentele externe (senzorii, modemul radio, etc.) trebuie tratate eficient şi cu uşurinţă, în particular informaţiile asincrone.

Există trei moduri de elaborare a modelului de programare, pentru a rezolva problema concurenţei proceselor:

Programarea secvenţială: un sistem secvenţial preia procesele într-o manieră neadecvată pentru un sistem de senzori: interoghează senzorul pentru a decide dacă sunt disponibile date, procesează datele imediat, interoghează transceiverul pentru a decide dacă un pachet e disponibil, procesează pachetul şamd. Astfel de proces prezintă riscul de a permite pierderii de date cât timp alt pachet este procesat sau pierderii de pachete, când se procesează datele de la senzor. Acest risc devine semnificativ când procesarea de date este laborioasă, sau numărul de pachete primit este mare. În concluzie, modelul secvenţial de programare nu este convenabil.

Programarea pe procese: majoritatea SO de uz general utilizează acest tip de programare pentru a oferi o execuţie aparent paralelă a unui număr oarecare de procese distincte, prin salvarea acestora în memorie (nu se potriveşte cu memoria foarte limitată a unui nod). Aplicarea acestei tehnici pe un nod de senzor prezintă anumite inconcordanţe: maparea funcţiilor individuale de protocol sau de nivel cu un proces va produce o cantitate mare de date suplimentare la schimbarea de la un proces la altul. Problema devine severă dacă sistemul necesită execuţia de multe instrucţiuni de dimensiuni reduse comparativ cu suplimentul impus, iar acesta este cazul reţelelor de senzori. În concluzie, nici acest mod de programare nu oferă o soluţie optimă.

Programarea bazată pe evenimente: având în vedere că modalităţile consacrate de programare eşuează în cazul reţelelor de senzori, trebuie să ne imaginăm o metodă care să fie conformă cu natura reactivă a reţelelor de senzori şi să o înglobeze în designul SO. În general, sistemul aşteaptă apariţia unui eveniment, cum ar fi apariţia de date la senzor, primirea unui pachet, expirarea unui contor. Un astfel de eveniment este tratat de o secvenţă scurtă de instrucţiuni, care stochează numai informaţia despre apariţia evenimentului şi informaţia necesară (de exemplu valoarea înregistrată de senzor). Procesarea informaţiei priomite nu este efectuată de rutinele de tratare a evenimentului, ci separat, decuplat de secvenţa reală de evenimente.

O rutină de tratare a evenimentelor poate întrerupe procesarea oricărui cod normal, şi fiind simplă şi scurtă, poate rula în orice circumstanţă fără să deranjeze codul principal. Rutinele de tratare nu se pot întrerupe unele pe celelalte (din cauza complexităţii tratării stivei), ci sunt executate secvenţial, în ordinea primirii.

Ca o consecinţă, programarea bazată pe evenimente distinge între două contexte diferite: rutinele de tratare a evenimentelor, care au prioritate maximă de execuţie şi procesarea codului normal, care este declanşată de rutinele de tratare.

Acest model de programare este comparabil în unele nivele cu formalisme utilizate în proiectarea protocoalelor şi în programarea paralelă. Oferă avantaje considerabile (în referinţele [17], Li compară performanţa unei astfel de metode, implementate în TinyOS descris pe larg în [18] cu programarea bazată pe procese, pe acelaşi sistem, şi descoperă o performanţă îmbunătăţită cu un factor de 8 şi un consum de energie redus cu un factor de 12).

Figurile de mai jos reflectă modul de funcţionare ale acestor paradigme de programare:

Fig. 4 Modelul de programare secvenţial

Fig. 5 Modelul de programare bazat pe procese

Fig. 6 Modelul de programare bazat pe evenimente

SO TinyOS şi limbajul de programare nesC adresează programarea bazată pe evenimente. TinyOS suportă evenimentele introducând conceptul de componente. Acestea conţin informaţiile necasare de stare în cadre, codul program pentru instrucţiuni şi rutine pentru evenimente şi comenzi. Evenimentele şi comenzile sunt schimbate între componente. Componentele se orgaizează ierarhic, de la cele de nivel scăzut (apropiat de planul fizic),până la cele de nivel înalt (nivelul aplicaţie). Evenimentele originează în nivelul fizic şi sunt transmise spre procesare nivelelor superioare.

Procesarea efectivă se produce în instrucţiuni. Acestea trebuie să aibă o finalitate, dar pot fi întrerupte de rutinele de tratare. Avantajul este dat de lipsa necesităţii pentru managementul stivei, precum şi de independenână la cele de nivel înalt (nivelul aplicaţie). Evenimentele originează în nivelul fizic şi sunt transmise spre procesare nivelelor superioare.

Procesarea efectivă se produce în instrucţiuni. Acestea trebuie să aibă o finalitate, dar pot fi întrerupte de rutinele de tratare. Avantajul este dat de lipsa necesităţii pentru managementul stivei, precum şi de independenţa relativă a instrucţiunilor.

Arbitrarea între instrucţiuni – mai multe evenimente pot genera mai multe instrucţiuni în aşteptare spre a fi executate – este realizată de un programator FIFO ce închide nodul când nici o instrucţiune nu este lansată în execuţie sau în aşteptare.

Peste sistemul de operare TinyOS au fost dezvoltate o gamă vastă de extensii, protocoale şi aplicaţii. Alte exemple de medii de execuţie pentru WSN sunt: Contiki – vezi [19], care a fost portat pe numeroase platforme şi implementează o stiva TCP/IP redusă, ecos – vezi [20] şi Mantis – vezi [21]