Sistemele de operare pentru rețeaua de senzori (menționat și WSN) sunt sisteme de operare încorporate în senzori în rețea (în majoritate rețele fără fir ). Un senzor de rețea (găsit în publicațiile științifice sub termenul englezesc mote ) este un set de elemente electronice de dimensiuni reduse, compus în esență dintr-un detector , un microcontroler , o baterie , un transceiver și o antenă .
Un senzor îndeplinește trei funcții: captarea datelor, prelucrarea acestora și trimiterea informațiilor referitoare la date către managerul de rețea. Datele sunt cantități fizice ale mediului în care este situat senzorul. Avantajul configurației rețelei este de a captura o cantitate mare de date pentru a alimenta o aplicație. Aplicația reacționează în funcție de datele trimise de senzori și informează despre o schimbare de stare a mediului monitorizat. Un senzor are o durată de viață limitată de bateria sa. Rețeaua de senzori trebuie să fie rezistentă pentru a compensa sfârșitul duratei de viață a fiecărui senzor.
Sistemele de operare pentru senzorii în rețea sunt special concepute pentru a optimiza utilizarea resurselor hardware limitate la dispoziția lor: memorie RAM mică , viteză redusă de procesare a procesorului și energie electrică redusă. Există multe sisteme de operare specializate, printre care: Contiki , ERIKA Enterprise , Nano-RK , TinyOS , MantisOS, RETOS, Senses, Cormos , LiteOS, NanoQplus.
Senzorul este partea hardware pe care trebuie să o gestioneze sistemul de operare . Un senzor , sau nod, este alcătuit din mai multe elemente sau module, fiecare corespunzând unei sarcini particulare de achiziție, procesare, stocare sau transmitere a datelor. De asemenea, include o sursă de energie.
Componentele senzorului sunt după cum urmează:
un detector Detectorul este elementul care surprinde magnitudinea fizică a mediului în care senzorul a fost amplasat. un convertor analogic digital Convertorul analogic transformă semnalul primit într-un semnal digital, compatibil cu microcontrolerul. un microcontroler Microcontrolerul prelucrează datele primite de la convertorul analog-digital și transmite datele privind sarcina utilă către transceiver. de memorie Două tipuri de memorie coexistă într-un senzor. Memoria cu acces aleatoriu ( RAM sau SRAM ) permite funcționarea aplicației. Memoria numai în citire (în principal memoria flash ) stochează sistemul de operare și datele procesate de senzor.Dimensiunea tipică a memoriei RAM este de ordinul a 128 KB , în timp ce dimensiunea memoriei flash ajunge la câțiva MB.
un emițător radio Transceiver îndeplinește 2 funcții: transmiterea semnalelor (transmițător) și semnale care primesc (receptor).O listă neexhaustivă a echipamentelor utilizate ca senzori poate fi găsită pe pagina Lista nodurilor senzorului fără fir .
Sistemul de operare este un manager de resurse pentru sisteme complexe. Într - un sistem tipic, aceste resurse includ unul sau mai multe procesoare (sau CPU ), memorie cu acces aleator , numai pentru citire de memorie , un planificator (sau în limba engleză temporizator ), stocare discuri , utilizator interfețe , cum ar fi mouse - ul , tastatura , etc imprimante și display - uri și una sau mai multe interfețe de rețea . Rolul sistemului de operare este de a gestiona alocarea resurselor procesorului pentru executarea proceselor , maximizând utilizarea generală a procesorului , optimizând în același timp interactivitatea acestor resurse către utilizatori într-un mod ordonat și controlat.
O rețea de senzori constă dintr-un număr mare de noduri mici alimentate de o baterie. Acestea sunt limitate de capacitatea bateriei, puterea procesorului și capacitatea de comunicare. Rolul sistemului de operare al senzorului de rețea este de a fi interfața dintre resursele hardware limitate și aplicațiile distribuite . Acesta trebuie să ofere o varietate de servicii de bază de sistem, cum ar fi gestionarea alocării resurselor pe diferite dispozitive hardware, întreruperea gestionării sarcinilor și programării, gestionarea rețelei de asistență. Scopul este de a facilita programarea aplicațiilor, dar și de a optimiza utilizarea resurselor.
Sistemele de operare pentru rețeaua de senzori fără fir, cum ar fi TinyOS , Contiki , SOS, MantisOS, Nano-RK, sunt proiectate pentru a îndeplini aceste cerințe. Posibilitățile hardware ale senzorilor sunt limitate în ceea ce privește memoria, puterea de calcul și autonomia energetică (baterie). Sistemele de operare trebuie să aibă o „mică amprentă de memorie” pentru a fi încorporate în memoria flash a senzorilor. În ciuda acestor limitări hardware, senzorii trebuie să integreze funcționalitățile de bază ale unui sistem de operare, cum ar fi:
De asemenea, trebuie să gestioneze caracteristicile specifice ale sistemelor de operare pentru senzorii de rețea:
Protocolul µIPv6 ajută la reducerea consumului de energie în procesul de rutare în comparație cu protocolul IPv4 .
Aici prezentăm o clasificare a conceptelor importante în proiectarea unui sistem de operare pentru senzori în rețea, dintre care detaliem mai jos subiectele referitoare la arhitectură, modelul de execuție, programarea, programarea și întreținerea.
Organizarea unui sistem de operare constituie structura sa. Arhitectura unui sistem de operare influențează dimensiunea nucleului, precum și modul în care serviciile sunt furnizate programelor de aplicații. Potrivit lui Muhammad Omer Farooq și Thomas Kunz, există patru tipuri cunoscute de arhitecturi ale sistemului de operare : arhitectura monolitică, arhitectura microkernel, arhitectura stratificată și arhitectura mașinilor virtuale.
MonoliticO arhitectură monolitică nu are o structură așa cum este descrisă în principiile arhitecturale. Serviciile furnizate de sistemul de operare sunt implementate separat și fiecare serviciu oferă o interfață pentru alte servicii. Acest tip de arhitectură permite gruparea tuturor serviciilor necesare pentru a forma o singură imagine de sistem. Aceasta are ca rezultat o amprentă de memorie redusă a sistemului de operare. Un avantaj al arhitecturii monolitice este că costurile de interacțiune ale modulului sunt scăzute. Pe de altă parte, sistemul este dificil de înțeles și de modificat, nesigur și greu de întreținut. Dezavantajele miezurilor monolitice le fac sărace candidați pentru proiectarea sistemelor de operare contemporane ale senzorilor.
Micro CoreÎntr-o arhitectură micro-kernel, nucleul oferă minimul necesar pentru a menține sistemul în funcțiune. Dimensiunea nucleului este considerabil redusă. Majoritatea funcționalităților sistemului de operare sunt furnizate prin intermediul serverelor la nivel de utilizator, cum ar fi serverul de fișiere, serverul de memorie, serverul de timp etc. Dacă un server cade, întregul sistem nu încetează să funcționeze. Arhitectura micro-kernel oferă o mai bună fiabilitate, ușurință de extindere și personalizare. Dezavantajul major al unui microkernel este performanța sa slabă datorită frecvenței înainte și înapoi între nucleu și utilizator. Cu toate acestea, datorită dimensiunilor mici ale nucleului său, acest tip de arhitectură este favorizat de multe sisteme de operare la bord.
Modular sau componentÎntr-o arhitectură modulară (sau stratificată), sistemul de operare implementează servicii sub formă de straturi. Avantajele acestei arhitecturi sunt portabilitatea, simplitatea structurală și fiabilitatea. Pe de altă parte, această arhitectură nu este foarte flexibilă.
Mașină virtualăPrincipiul unei mașini virtuale este de a integra sistemul de operare în aplicația utilizatorului. O mașină virtuală are toate caracteristicile hardware necesare. Principalul avantaj este portabilitatea sa, dar principalul dezavantaj este de obicei o performanță slabă a sistemului.
Modelul de programare acceptat de un sistem de operare are un impact semnificativ asupra dezvoltării aplicațiilor.
Bazat pe evenimente Modelul evenimentului acordă prioritate evenimentelor. Un eveniment previne resursele până când este finalizat. Apariția unui eveniment prin natură este asincronă. Sarcinile de gestionare de zi cu zi pot fi întrerupte de apariția unui eveniment, dar nu invers. Multi Thread ( pe bază de fire ) Un fir este un element de bază al calculului. Are propria sa stare. Modelul multi-thread oferă flexibilitate în scrierea aplicațiilor. O aplicație constă în executarea unui set de fire . Sarcinile atribuite rețelei sau planificatorului sunt, de asemenea, fire. Când se execută un fir, celelalte sunt blocate. Nucleul gestionează un tabel de fire cu reguli de prioritate și un sistem round robin. Hibrid Un sistem hibrid beneficiază de avantajele celor două modele anterioare. Firele sunt sincronizate în timp ce evenimentele au loc asincron.Reprogramarea este capacitatea unui sistem de a putea evolua. Permite actualizarea dinamică a software-ului care rulează pe nodurile senzorilor. Aceasta este o caracteristică importantă datorită inaccesibilității fizice a senzorilor și a numărului mare de senzori pe care rețeaua îl poate constitui. Acest lucru se poate face la diferite niveluri ale sistemului de operare. Reprogramarea poate avea loc la nivelul aplicației, la nivelul modulului (sau componentei) și la nivelul instrucțiunii (sau variabilei). O reprogramare consumă resurse de rețea, proporțional cu nivelul la care se află. Este astfel posibil să adăugați, să modificați sau să ștergeți un modul, o componentă sau o aplicație a sistemului de operare. Datele sunt trimise prin frecvența radio și sunt direcționate prin protocoale de rețea, de la nod la nod la senzori, această operațiune este evident costisitoare în energie și este rolul protocolului de rețea să optimizeze acest consum de energie. După primirea codului la noduri, este necesar fie să adăugați, fie să actualizați software-ul curent care rulează. Acest lucru necesită un mecanism de gestionare a memoriei. Pentru a actualiza senzorii, sistemul trebuie să aloce dinamic memoria pentru a facilita încărcarea componentelor software în timpul rulării.
Programarea determină ordinea în care sarcinile sunt executate pe un procesor. În sistemele computerizate tradiționale, obiectivul unui planificator este de a minimiza latența, de a optimiza utilizarea lățimii de bandă și a resurselor și de a asigura corectitudinea. Alegerea unui algoritm de planificare adecvat pentru rețelele de senzori depinde, în general, de natura aplicației. Pentru aplicațiile cu cerințe în timp real, ar trebui utilizat un algoritm de planificare în timp real. Pentru alte aplicații, sunt suficienți algoritmi de planificare non-timp real. Senzorii de rețea sunt utilizați atât în medii în timp real, cât și non-în timp real. Sistemul de operare al senzorului de rețea trebuie să furnizeze algoritmi de planificare care să îndeplinească cerințele aplicației. În plus, algoritmul de planificare are un impact asupra gestionării memoriei și a eficienței consumului de energie. Există două categorii de planificare a sarcinilor:
Acest mod de operare permite îndeplinirea cerințelor în timp real pentru monitorizarea periodică a mediului. Permite efectuarea sarcinilor din mers.
Programarea sarcinilor în modul eveniment este potrivită pentru evenimente asincrone .
Algoritmi de programareNodurile sunt prin definiție alimentate de o baterie. Gestionarea energiei este un factor important în proiectarea unui sistem de operare al senzorului de rețea. Conform Wei Dong, tehnicile actuale de economisire a energiei pe noduri pot fi diferențiate între gestionarea energiei microcontrolerelor și gestionarea energiei perifericelor.
Microcontrolerele sunt de obicei o colecție de componente cu putere redusă care mențin diferite periferice active . Klues oferă ICEM pentru a gestiona simultan controlul accesului și gestionarea energiei driverelor de dispozitiv: fiecare microcontroler are o funcție de așteptare care calculează starea minimă de putere necesară pentru a menține sursele de întrerupere și perifericele active ale circuitului integrat . Sistemul de operare calculează pur și simplu puterea necesară prin gestionarea unui bit specific. Calculul stării de somn permite, de asemenea, unui pilot să specifice o stare minimă de somn garantată.
Gestionarea energiei dispozitivelor necesită cunoașterea tiparului de utilizare a aplicației. Fiecare dispozitiv este oprit individual când nu este utilizat. În timp ce pentru dispozitivele dedicate este destul de simplu să se controleze stările de alimentare de către aplicații, pentru dispozitivele virtualizate și partajate este responsabilitatea sistemului de operare să gestioneze alimentarea pentru întregul sistem. ICEM valorifică concurența intrare-ieșire a aplicației și oferă un mecanism de blocare a puterii pentru a minimiza automat consumul de energie în absența informațiilor suplimentare despre o aplicație. Dintre dispozitivele nod, transceptorul consumă cea mai mare energie. Protocolul Media Access Control este cel mai relevant pentru gestionarea consumului de energie al dispozitivelor radio. Protocolul MAC și stratul de rețea trebuie optimizate astfel încât energia utilizată să fie utilizată direct pentru traficul generat și nu pentru întregul timp de lucru. Alte proprietăți importante sunt adaptabilitatea la topologia rețelei, în raport cu numărul de noduri și densitate. Mai multe protocoale derivate din protocolul MAC, cum ar fi (S-MAC, B-MAC, X-MAC), permit stocarea, rutare sau diseminarea datelor. Aceste protocoale se comportă ca arhitecturi de sistem cu niveluri, iar împrăștierea aleatorie a nodurilor nu este o problemă.
Cu o sursă de energie finită, nu toți parametrii de performanță pot fi optimizați simultan. De exemplu, utilizarea unei baterii de capacitate mai bună implică un cost suplimentar, ciclul de funcționare scăzut are ca rezultat o degradare a fiabilității, utilizarea unei puteri mai mari a transceiver-urilor este redusă. Rezultă un consum mai mare și, invers, reducerea puterii duce la utilizarea unui număr mai mare de senzori.
O tehnică alternativă a fost aplicată în încercarea de a rezolva problema timpului de funcționare finit al unui nod, și anume utilizarea „ recoltării energiei” ( Energy Harvesting ). Recuperarea energiei se bazează pe valorificarea energiei din mediu sau din alte surse de energie (de exemplu, căldura corpului) care este transformată în energie electrică pentru alimentarea nodului. În cel mai bun caz, este posibil să aveți un bilanț energetic pozitiv în favoarea nodului, care se traduce printr-o durată de viață teoretic nelimitată.
Alte sisteme de operare:
t-Kernel, DCOS, MagnetOS, kOS, SenOS, VMSTAR, OSSTAR, Nano-QPlus, CORMOS, MagnetOS, kOS, T2O stare de artă din mai 2010 enumeră principalele sisteme de operare pentru senzorii conectați în rețea și descrie soluțiile oferite de fiecare pentru optimizarea gestionării energiei senzorilor. De asemenea, se întocmește o clasificare a diferitelor sisteme de operare. Articolul din 2007 completează articolul din 2010 descriind alte sisteme de operare care au căzut în uz, dar interesante pentru strategiile utilizate pentru optimizarea consumului de energie al senzorilor. În cele din urmă, alte două articole, din 2010 și 2011, fac bilanțul versiunilor recente ale acestor sisteme. Aceste articole evidențiază cinci sisteme de operare - TinyOs, Contiki, Mantis, Nano-RK și LiteOS - pe care vom explica mai detaliat strategiile dezvoltate. Tipul de arhitectură utilizat pentru sistemele de operare, fie că este nucleu monolitic, micro-nucleu, modular sau virtual, are un impact direct asupra dimensiunii nucleului, a amprentei sale de memorie. Arhitectura monolitică face posibilă reducerea acestei amprente în detrimentul ușurinței de utilizare. Arhitectura mașinii virtuale permite portabilitatea simplificată a sistemului de operare, făcându-l mai flexibil pe diferiți senzori, dar în detrimentul performanței. Arhitectura modulară, pe de altă parte, permite ușurința în utilizare și înțelegere, dar flexibilitatea suferă. Comparativ cu sistemele monolitice, microcernelurile satisfac o nevoie de modularitate, flexibilitate și securitate (Liedtke, 1996). Performanța mecanismelor de comunicare între servere se află în centrul proiectării tuturor microcernelurilor. Dezavantajul major constă în faptul că orice mecanism de reconfigurare dinamică trebuie să fie inclus de către proiectant pe lângă aceste servicii. Sisteme pentru rețele de senzori Apărând recent (Hill și colab., 2000), nodurile rețelelor de senzori au particularitatea de a fi sisteme foarte constrânse în resurse, care necesită sisteme de operare ușoare și eficiente. Datorită naturii desfășurării lor, care este adesea dificil de accesat fizic, reconfigurarea dinamică a sistemelor de operare este esențială, cu toate acestea puțini dintre ei au această capacitate. În cea mai mare parte, aceste sisteme raportează periodic evenimentele senzorilor, fiind în așteptare de cele mai multe ori. Prin urmare, mecanismele de actualizare sunt adesea limitate la rescrierea imaginii sistemului și repornirea sistemului (cu o posibilă pierdere a stării), cum ar fi Mantis (Bhatti și colab., 2005). Deoarece senzorii comunică între ei în cadrul rețelei, este important ca sistemele de operare să ofere o interfață de programare bazându-se în mod eficient pe protocolul de comunicație. Planificatorul are un rol important, deoarece trebuie să optimizeze utilizarea memoriei pentru a avea un randament optim de energie.
TinyOS (Hill și colab., 2000) a fost unul dintre primele sisteme de operare concepute pentru rețelele de senzori. Sistemele componente TinyOS sunt construite à la carte, în limbajul nesC . (Gay și colab., 2003). TinyOS este un sistem de evenimente. Nu este reconfigurabil, cu toate acestea există mai multe abordări pentru a permite reconfigurarea aplicațiilor. XNP (Jeong și colab., 2003) vă permite să descărcați și să reinstalați o nouă imagine de sistem efectuând o repornire. FlexCup (Marron et al., 2006) permite reconfigurarea dinamică la scara aplicației. Mecanismul FlexCip se bazează pe metadatele generate în timpul compilării sistemului, ceea ce permite unui linker de la bord să modifice sistemul în timpul rulării. Această abordare necesită partiționarea unei aplicații în mai multe componente, fiecare într-un segment de memorie separat. FlexCup permite minimizarea consumului de energie al senzorilor pe care este modificat sistemul.
TinyOS este un sistem de operare integrat, modular. Această platformă software deschisă, precum și o serie de instrumente, dezvoltate inițial de Universitatea din Berkeley, sunt îmbogățite de o multitudine de utilizatori. Într-adevăr, TinyOS este cel mai răspândit sistem de operare pentru rețelele de senzori fără fir. TinyOS are o amprentă de memorie 4KB. Biblioteca de componente TinyOS include protocoale de rețea, aplicații de servicii distribuite, drivere de senzori și instrumente de achiziție de date. Constrângerea energetică datorată autonomiei senzorilor implică utilizarea unei puteri de calcul reduse care are ca rezultat dezvoltarea unui software constrâns de capacitatea memoriei și de viteza de execuție. Utilizarea limbajului nesC face posibilă optimizarea codului și astfel reducerea utilizării RAM. Tendința actuală este de a proiecta rețele de senzori, în care fiecare nod trebuie să aibă o autonomie de câteva zile sau câțiva ani. Principalele sisteme încorporate candidate pentru utilizarea de către senzori sunt TinyOS și Contiki. Primul este dezvoltat în comun de Universitatea Berkeley și compania Intel și a fost anterior cel mai utilizat în domeniul sistemelor micro-încorporate. Cu toate acestea, suferă de câteva defecte, dintre care unele sunt rezolvate de Contiki. De exemplu, nu acceptă încărcarea modulară a pieselor software, care necesită trimiterea codului binar complet în timpul unei actualizări de la distanță. Acest mod de funcționare nu este lipsit de consecințe: energia fiind limitată pe un senzor fără fir, consumul de energie este proporțional cu volumul de cod descărcat. Maté (Levis & Culler, 2002) este o mașină virtuală construită cu TinyOS. Aplicațiile Mate sunt construite cu un set mic de instrucțiuni ale mașinii virtuale, rezultând aplicații foarte compacte. Sistemul permite doar o actualizare a aplicațiilor mașinii virtuale. În acest fel, abordarea Mate optimizează utilizarea celei mai critice resurse. Consumul de energie al interfeței radio. Pe de altă parte, datorită abordării mașinii virtuale, Maté are un impact asupra performanței unui sistem.
ArhitecturăTinyOS se încadrează în categoria arhitecturilor monolitice. TinyOS folosește modelul componentelor conform cerințelor unei aplicații, un set de componente software care pot fi ambalate într-un singur executabil pe un senzor. Diferitele componente sunt compilate împreună cu planificatorul pentru a executa cod portabil și reutilizabil, fără a pierde performanța la rulare, deoarece aplicația monolitică este modelul care utilizează la maximum resursele disponibile. O componentă este un element constitutiv de bază al unei aplicații nesC . Există două tipuri de componente: module și configurații
O interfață definește într-un mod abstract interacțiunile dintre două componente . Interfețele sunt bidirecționale, ele specifică un set de funcții care trebuie implementate de componentele care furnizează interfața (comenzi) și un set de funcții care trebuie implementate de componentele utilizatorului ale interfeței (evenimente). Comenzile efectuează de obicei apeluri de sus în jos (de la componentele aplicației la componente mai apropiate de hardware), în timp ce evenimentele deplasează semnale de jos în sus. Un modul este o componentă care implementează una sau mai multe interfețe și poate utiliza una sau mai multe interfețe. Componentele sunt implementate declarând sarcini, comenzi sau evenimente. Comenzile și evenimentele sunt mecanisme de comunicare între componente. O comandă este o cerere de a efectua un anumit serviciu, în timp ce evenimentul marchează sfârșitul serviciului. TinyOS oferă o stivă de partajare unică. Nu există nicio separare între spațiul kernel și spațiul utilizatorului. Figura 2 descrie arhitectura TinyOS.
Model de programareDezvoltarea aplicațiilor bazate strict pe modelul de programare bazat pe evenimente nu a permis apariția Multithreating pe primele versiuni ale TinyOS. Începând cu versiunea 2.1 TinyOS acceptă multithreading. Subprocesele sunt denumite fire TinyOS TOS. În [6], autorii au subliniat o problemă: ținând cont de constrângerile de resurse ale senzorilor, un sistem de operare bazat pe evenimente generează o concurență mai mare (două procese care doresc să acceseze aceleași date). Cu toate acestea, multitaskingul preventiv oferă un model de paradigmă de programare intuitivă (stilul fundamental al programării computerizate). Setul de filetare TOS oferă un model de programare a filetării cuplat cu eficiența unui kernel condus de evenimente. Firele TOS sunt compatibile cu codul TinyOS existent. TOS Threads folosește o abordare cooperativă multitasking , adică fiecare proces trebuie să permită în mod explicit să ruleze o altă sarcină și se bazează pe aplicațiile TOS pentru a crește eficiența procesorului. Acest lucru adaugă o povară suplimentară pentru programatorul care trebuie să se ocupe de competiție . Firele de aplicații din TinyOS pot preveni alte niveluri de fire de aplicație, dar nu pot întrerupe sau opri sarcinile planificate în desfășurare. Un fir de kernel cu prioritate ridicată este destinat executării programatorului TinyOS. Pentru comunicarea între firele de aplicații și kernel, TinyOS 2.1 oferă o interfață. Când un program de aplicație efectuează un apel de sistem, acesta nu este executat direct de cod. Mai degrabă, afișează un mesaj către firul nucleului atunci când postează o sarcină. Apoi, firul de nucleu execută sau oprește un proces programat care rulează. Acest mecanism asigură faptul că numai nucleul execută direct codul TinyOS. Apelurile de sistem, cum ar fi „creați, distrugeți, întrerupeți, reluați și uniți” sunt furnizate de biblioteca de filetare TOS.
Biblioteca TinyOS include protocoale de rețea, servicii de distribuție, drivere pentru senzori și instrumente de achiziție de date. TinyOS este scris în cea mai mare parte în C, dar puteți crea cu ușurință aplicații personalizate în limbaje C, NesC și Java.
Contiki (Dunkels și colab., 2004; Dunkels și colab., 2006) este un sistem configurabil modular pentru rețelele de senzori. Contiki este organizat în module, o arhitectură plană. Un nucleu nereconfigurabil face posibilă descărcarea modulelor de aplicație sau subsistem, care constituie apoi unitatea de reconfigurare din Contiki. Un model de execuție bazat pe evenimente permite implementarea eficientă a unei stări stabile pentru module.
Contiki este un sistem de operare conceput pentru a ocupa cât mai puțin spațiu posibil, cu o amprentă mică de memorie. Pentru aceasta, codul este scris în C. Astfel, sistemul complet ar trebui să poată rula fără probleme cu 2 kb RAM și 40 kb ROM. Contiki are un management de programare paralel sub formă de "proto-thread-uri", care sunt procese ușoare dezvoltate special pentru ocazie, așa cum µIPv6 permite să fie compatibil cu IPV6.
În Contiki există o bibliotecă specifică MEMB () conținută în nucleu pentru a gestiona memoria prin bloc și reorganiza spațiul de memorie liber, această gestionare dinamică permite optimizarea consumului de energie. Contiki oferă o implementare RPL, numită ContikiRPL, care utilizează IPv6 utilizând protocolul de rutare RPL, care crește durata de viață a bateriei senzorilor și permite funcționarea pe legături wireless de mică putere și pe legături de pierdere de energie în linie.
Potrivit site-ului oficial, Mantis OS este un sistem de operare multithread dezvoltat în C, un limbaj ales pentru eficiența și portabilitatea sa. Mantis are un mediu de dezvoltare Linux și Windows. Poate fi implementat pe multe platforme, cum ar fi MICA2, MICAz și TELOS. Amprenta sa de memorie este mică: 500 de octeți în RAM și 14 kb în flash. Mantis, apărut în 2005, a fost proiectat de Universitatea din Colorado cu scopul de a oferi un sistem de operare multi-threading. Este un sistem modular al cărui nucleu acceptă, de asemenea, I / O sincronă și un set de primitive simultane. Economisirea de energie este realizată de Mantis printr-o funcție de somn care inactivează senzorul atunci când toate firele active sunt terminate. Mantis este un sistem dinamic, modificările aplicației pot fi făcute în timpul funcționării. Mantis aduce compatibilitate cu modelul de evenimente TinyOS prin TinyMOS (MOS este contracția MantisOS), cu care este echipat nucleul său. La fel ca majoritatea sistemelor de operare pentru senzori, Mantis are o stivă de rețea, grupată în stratul COMM. Comunicarea se bazează pe principiul mesajelor ponderate Active Message (AM). Stratul COMM are protocol MAC, ceea ce face rețeaua compatibilă cu multe dispozitive, gestionarea bufferului de pachete și funcții de sincronizare. În ceea ce privește depanarea la distanță, Mantis implementează NodeMD, un sistem de implementare și notificare a defectelor.
MantisOS este alcătuit din 4 straturi:
Nano-RK este un sistem de operare în timp real multitasking preventiv pentru senzori din rețea. Suportă rețea multi-hop. Are o amprentă mică de memorie, Nano-RK folosește 2kb de RAM și 18kb de ROM. Nano-RK oferă API-uri pentru gestionarea energiei senzorilor, inclusiv următoarele funcții:
LiteOS oferă un mediu asemănător UNIX , potrivit pentru senzorii din rețea. LiteOS are un sistem de comandă a modului terminal de la distanță și un sistem de gestionare a fișierelor similar cu comenzile unix pentru gestionarea senzorilor. Kernel-ul suportă încărcarea dinamică și multitasking-ul aplicațiilor. Un limbaj de programare orientat spre obiecte C ++ este disponibil pentru a dezvolta programe și a permite implementarea lor pe senzori. LiteOS versiunea 1.0 acceptă platforma Crossbow IRIS. De asemenea, oferă un mecanism de virtualizare a puterii și un sistem de depanare la distanță. LiteOS are o amprentă mică de memorie și poate funcționa cu 128KB de memorie flash și 4KB de memorie RAM. LiteOS funcționează, de asemenea, în cadrul RISC-V , în special, cu ajutorul kiturilor de dezvoltare Huawei care se compilează cu GCC .
Sistemele sunt clasificate în funcție de următoarele caracteristici:
Într-un sistem static programatorul trebuie să aloce toate resursele la momentul proiectării. Pe de altă parte, într-un sistem dinamic programatorul alocă resursele în timpul execuției. Sistemele dinamice sunt mai flexibile și sunt mai potrivite pentru medii în schimbare dinamică. Cu toate acestea, acestea nu sunt fiabile și o aplicație buggy poate provoca cu ușurință blocarea sistemului.
Un sistem „condus de evenimente” este inactiv și reacționează la sosirea unui eveniment. Un sistem „Multi-Thread” este un sistem care efectuează sarcini în paralel.
Un sistem este monolitic atunci când sistemul de operare și aplicația sunt compilate ca un singur bloc. În schimb, un sistem este modular dacă aplicația este separată de sistemul de operare. În acest caz, sistemul de operare este conținut într-un nucleu .
Prin proiectare, un senzor are un strat de aplicație de rețea . TCP / IP este standardul. protocoale de rețea utilizate: µIP, µIPv6, RIME Embedded Systems / Atmel AVR / Sisteme de operare și manageri de sarcini , Mesaj activ, Arhitectură cu trei straturi.
Senzorul poate fi echipat cu o sincronizare de referință în funcție de necesitățile aplicației.
Sistemul de operare poate fi codat în diferite limbi: nesC , LiteC ++ , C , C ++ , java
Senzorul poate fi reprogramat de la distanță, în funcție de evoluția aplicației.
Senzorul trebuie să poată fi analizat de la distanță sau cel puțin să poată trimite informații despre starea sa către managerul de rețea.
TinyOS | Contiki | SOS | Mantis | Nano-RK | RETOS | LiteOS | |
---|---|---|---|---|---|---|---|
Publicare (an) | ASPLOS (2000) | EmNets (2004) | MobiSys (2005) | MONET (2005) | RTSS (2005) | IPSN (2007) | IPSN (2008) |
Static / Dinamic | Static | Dinamic | Dinamic | Dinamic | Static | Dinamic | Dinamic |
Eveniment / Subiect | Eveniment și fir (TinyThread, TOSThreads) | Evenimente și fire și fire prototice | Eveniment | Subiect și eveniment (TinyMOS) | Fir | Fir | Subiect și eveniment (prin apel invers) |
Monolitic / Modular | Monolitic | Modular | Modular | Modular | Monolitic | Modular | Modular |
Reţea | Mesaj activ | uIP, uIPv6, Rime | Mesaj | "com" | Priză | Arhitectură în trei straturi | Asistat prin fișiere |
Suport în timp real | Nu | Nu | Nu | Nu | da | POSIX 103.1b | Nu |
Programarea limbajului | nesC | VS | VS | VS | VS | VS | LiteC ++ |
Sistemul de fișiere | Nivel unic (numai & .x) (ELF, Matchbox) | Cafea | Nu | nu (planificat pentru versiunea 1.1) | Nu | Ierarhic ca Unix) | |
Reinstalați | da (Deluge, FlexCup) | da | da (Modular) | nu (planificat pentru versiunea 1.1) | Nu | da | da |
Depanare la distanță | da (clarvăzător) | Nu | Nu | da (NodeMD) | Nu | Nu | da (DT) |
S-au făcut deja multe cercetări privind sistemele de operare ale senzorilor de rețea și acest domeniu de cercetare rămâne activ. Din punct de vedere istoric, acesta este un domeniu relativ nou de cercetare, nevoile aplicațiilor WSN cresc și nu au fost explorate toate posibilitățile domeniului aplicației pentru WSN. În plus, evoluția hardware va duce la noi clase de senzori cu capacități de comunicare îmbunătățite, platforme de senzori (memorie, stocare, putere procesor etc.). Pe baza acestor informații, este posibil să se identifice următoarele linii de cercetare pentru a obține un sistem de operare modern și modern al rețelei de senzori.
Suportă aplicații în timp real Există multe domenii de aplicații pentru WSN care necesită în timp real, de exemplu, în automatizarea industrială, controlul proceselor chimice și procesarea datelor multimedia și de transmisie. Planificatoarele unor sisteme de operare au fost proiectate pentru a sprijini operațiuni în timp real atât în software, cât și în hardware, dar efortul este departe de a fi finalizat. În viitor, este necesar să se furnizeze algoritmi care să poată satisface nevoile ambelor tipuri de timp real, software și hardware. În plus, odată cu apariția WMSN, este necesară o nouă stivă de protocol de rețea, aceasta va permite implementarea protocoalelor și va sprijini servicii diferențiate. Gestionați o memorie auxiliară Aplicațiile necesită din ce în ce mai multă memorie. De exemplu, o aplicație tipică de bază de date necesită memorie auxiliară la bord cu noduri de senzor. În prezent, puține sisteme de operare oferă un manager de fișiere pentru a gestiona memoria auxiliară. Suportă memoria virtuală Un nod senzor este foarte limitat în RAM și aplicațiile necesită din ce în ce mai mult. Prin urmare, este necesar să se studieze conceptele de memorie virtuală în sistemul de operare pentru senzorii din rețea. Va fi necesar să inventăm tehnici de gestionare a memoriei virtuale care să fie eficiente în consumul de energie și memorie. Gestionați și securizați memoria S-a făcut puțină lucrare în gestionarea memoriei pentru sistemele de operare WSN. Motivul principal este că s-a presupus că o singură aplicație rulează pe un sistem de operare WSN. În multe sisteme de operare contemporane, precum TinyOS și Contiki, aplicația și nucleul se compilează împreună, împărtășind astfel același spațiu de adrese. Acest lucru poate fi problematic, deci un sistem de operare precum LiteOS oferă spații de adrese separate pentru diferite aplicații și nucleu. Astfel de tehnici trebuie să se maturizeze pentru a susține o multitudine de aplicații simultane pe nodurile senzorilor. Suportă mai multe aplicații Sistemul de operare recent pentru WSNS a fost dezvoltat luând în considerare faptul că o singură aplicație va rula pe senzor. Dar odată cu dezvoltarea de noi zone de aplicare a rețelelor de senzori, această ipoteză de bază este pusă la îndoială. De exemplu, în cazul WMSN, în care senzorii sunt echipați cu senzori de voce (microfoane), senzori video precum camere (camere) și senzori scalari. De acolo, pe un singur nod senzor, este posibil să aveți o aplicație care utilizează senzorul video, adică, înregistrarea videoclipului, efectuarea procesării imaginii pe acesta și trimiterea videoclipului comprimat la stație. De asemenea, putem avea și alte aplicații care folosesc senzori de voce și senzori scalari. Prin urmare, sistemul de operare trebuie să satisfacă mai multe aplicații în același timp. Gestionați o stivă robustă de protocol de comunicație O linie de cercetare care proiectează și implementează un protocol cu straturi încrucișate adecvat pentru rețelele de senzori. Proiectarea protocolului trebuie să ia în considerare constrângerile nodurilor senzorilor, precum și noile domenii de aplicare emergente pentru rețelele de senzori. A securiza Implementarea WSNS pe câmpul de luptă necesită caracteristici de securitate riguroase, astfel încât sistemul de operare pentru WSN ar trebui să ofere mecanisme pentru ca un utilizator al stației de bază să autentifice nodurile valide din rețea. De asemenea, în caz de solicitări sau actualizări, nodurile trebuie să poată autentifica originea acestuia. Gestionați un sistem de gestionare a datelor Un nod senzor trebuie să poată stoca date și să înțeleagă limbajul interogării . Este necesar un efort de cercetare pentru a proiecta un sistem de gestionare a datelor pentru nodurile senzorilor. Localizați și susțineți API-urile de sincronizare a ceasului Pentru a răspunde sincronizării orelor specifice aplicației, este nevoie să se concentreze pe sistemul de operare să ofere dezvoltatorilor API-uri adecvate pentru a-și proiecta propriul protocol. API pentru procesarea semnalului și a imaginii În domeniul procesării imaginilor, aplicațiile care apar necesită ca sistemul de operare să ofere un set bogat de API de bază pentru procesarea imaginilor și a imaginilor sau a semnalului pentru a facilita munca dezvoltatorului.Clasificarea aplicațiilor depinde de scopul pentru care sunt utilizați senzorii din rețea. Potrivit lui Adi Mallikarjuna, acestea pot fi clasificate în următoarele categorii: (i) Control, (ii) Detecție / Clasificare / Screening și (iii) Direcție. Aceste aplicații sunt utilizate în diferite domenii, cum ar fi:
De mediu Acest domeniu de aplicații ( Observatorul de mediu ) poate fi împărțit între operațiuni de control intern și extern .Diferitele categorii de aplicații utilizate în diferitele domenii menționate mai sus prezintă o mulțime de caracteristici. Acestea indică, de asemenea, ce tipuri de programe de bază de bază ar fi necesare pentru a satisface aceste caracteristici. Caracteristicile sau nevoile importante ale acestor aplicații sunt rezumate mai jos:
Aceste caracteristici ale aplicației sunt evaluate în funcție de categoriile de aplicații din tabelul următor. (x) indică nu este necesar și (v) indică necesar. Tabelul arată, de asemenea, sistemul de operare care poate fi utilizat în fiecare categorie de aplicații.
Categorii | Timp real | Reprogramare | Managementul consumului de energie | Adaptabilitate | Sisteme de operare adecvate |
---|---|---|---|---|---|
De mediu | |||||
Interior | X | X | X | X | Toate sistemele de operare |
In afara | X | v | v | v | SOS, Contiki, MantisOS, SenOS, DCOS, Nano-RK, t-kernel |
Sănătate | v | X | X | X | PEEROS, Nano-RK, DCOS, CORMOS |
Armată | v | v | v | v | Nano-RK, DCOS |
Industrie | v | v | v | v | Nano-RK, DCOS |
Funcțiile prezentate în tabelul rezumat influențează funcționalitatea sistemului de operare. Arhitectura și gestionarea memoriei sistemului de operare permit funcția de reprogramare. Modelul de execuție și mecanismul de planificare permit garantarea proprietății în timp real.
În majoritatea platformelor hardware, transmisia radio este sursa principală de consum de energie, iar activitatea radio este în mare măsură controlată de stratul MAC. În ceea ce privește protocolul MAC, principalele surse de pierdere de energie sunt coliziunile, ascultarea inactivă pentru a primi date posibile, ascultarea adică primirea de date destinate altor noduri, controlul overhead-ului și supra-emiterea adică transmiterea unui mesaj atunci când destinatarul nu este pregătit . Deci, pentru a economisi cel mai bine energia bateriei într-un senzor, emițătoarele radio ar trebui să fie oprite cât mai mult posibil. Cu toate acestea, acest lucru ar putea pune problema sincronizării senzorilor și distribuția perioadelor de veghe. Astfel, stratul MAC ar trebui să permită senzorilor să aibă perioade de somn destul de lungi, dar fără a perturba comunicațiile. Protocoalele de rutare pentru rutarea datelor au un impact asupra consumului de energie al senzorilor, de unde și importanța stabilirii algoritmilor pentru optimizarea consumului de energie al senzorilor atunci când transmit date sau rămân în aer. Ascultarea rețelei. Senzorii comunică între ei pas cu pas pentru a retransmite informațiile către stația de bază a mediului monitorizat. Pentru aceasta, senzorii se pun inactivi ascultând vecinătatea lor, adică rămân ascultând pentru a primi trafic fără a trimite niciunul și asta uneori pe o perioadă lungă de timp înainte ca un eveniment să fie detectat de senzor. S-MAC rezolvă această risipă de energie. În plus, face posibilă limitarea coliziunilor în rețea și, astfel, reducerea re-transmisiilor consumatoare de energie. S-MAC folosește un model periodic de ascultare și somn. Astfel, senzorii sunt în repaus pentru o anumită perioadă de timp, dacă nu apare niciun caz de detectare. Având în vedere că rata de date în această perioadă este foarte mică, nu este nevoie să rămâneți la curent cu nodurile tot timpul. S-MAC realizează astfel economii de energie de aproape 50%. DSMAC (S-MAC dinamic) este o altă variantă a S-MAC. Acest protocol adaugă un ciclu de activitate dinamic la S-MAC, ceea ce reduce latența în aplicațiile critice. De exemplu, un nod își poate dubla ciclul de funcționare dacă nivelul bateriei este peste un anumit prag. DSMAC generează o latență mai mică decât S-MAC cu un consum mediu mai bun de energie pe pachet.
Axa de cercetare a noilor sisteme de operare pentru senzori este orientată spre optimizarea protocoalelor de rutare, o caracteristică inclusă în nucleul sistemelor de operare.
O altă linie de cercetare constă în introducerea protocoalelor de comunicație cu funcții GPS, precum protocolul ZigBee , în nucleul sistemelor de operare .
Rețelele de senzori multimedia fără fir extinde capacitățile multimedia ale senzorilor din rețea, oferind aplicații în domeniul mediului, militar, sănătate și industrial cu aplicații multimedia precum video sau sunet.