Cursul care închide seria: cum devine un nod embedded, cu senzorii, sursa de energie și modul de consum discutate în cursurile anterioare, parte dintr-un sistem distribuit real. Parcurgem arhitectura pe niveluri a unui sistem IoT (dispozitiv, edge, cloud), topologiile de rețea și compromisurile lor, tehnologiile de comunicație de la BLE la LoRaWAN, protocoalele de nivel aplicație (MQTT, CoAP), și, la final, managementul și securitatea unei flote de dispozitive pe întregul ei ciclu de viață.
1Obiectul și structura cursului6 min
Internet of Things (IoT) descrie integrarea obiectelor fizice, senzorilor, actuatoarelor și sistemelor embedded în infrastructuri de comunicație și servicii digitale. Spre deosebire de o rețea informatică tradițională, unde datele sunt introduse în principal de utilizatori, un sistem IoT colectează automat și continuu informații despre obiecte și procese reale.
mediu fizic → senzori → procesare → rețea → aplicație →
actuatoare- Un nod senzorial (Curs 10) alternează între sleep și stări active, cu factorul de activitate D = T_activ/T_ciclu
- Comunicarea radio e, de regulă, cea mai costisitoare operație energetic (Cursul 04)
Rezultate ale învățării
- Să descrieți arhitectura pe niveluri a unui sistem IoT (dispozitiv, edge, cloud)
- Să alegeți o topologie de rețea (stea, arbore, mesh) pe baza cerințelor aplicației
- Să comparați tehnologiile de comunicație IoT pe baza rază/rată/consum
- Să distingeți modelul MQTT (publish/subscribe) de modelul CoAP (bazat pe resurse)
- Să calculați bugetul energetic al unei transmisii radio, inclusiv retransmisiile
- Să descrieți ciclul de viață al unui dispozitiv IoT și cerințele de securitate asociate
2De la sistem embedded la nod IoT8 min
Un sistem embedded tradițional execută o funcție bine definită și poate funcționa complet izolat - un controler de temperatură, un modul de comandă pentru un motor. Prin adăugarea conectivității, sistemul poate transmite măsurători, primi configurații, raporta erori, coopera cu alte dispozitive și fi actualizat de la distanță.
sistem embedded + identitate + conectivitate + servicii = nod IoT. Un termostat local
măsoară temperatura și comandă încălzirea; un termostat IoT poate suplimentar primi programări de
la distanță, transmite istoricul consumului și participa la optimizarea energetică a unei clădiri
întregi. Conectivitatea introduce însă responsabilități noi: protejarea comunicațiilor, gestionarea
erorilor de rețea, sincronizarea datelor, actualizarea firmware-ului și administrarea identității
dispozitivului.Senzorii transformă mărimi fizice în date digitale; actuatoarele realizează procesul invers.
Pentru o mărime fizică x(t), achiziția generează eșantioane x[k] = x(kT_s). Datele pot
fi filtrate local, z[k] = F(x[k], x[k-1], ...), iar rezultatul poate genera o comandă
u[k] = G(z[k], r[k]).
umiditate sol → decizie → deschidere electrovalvă. Decizia poate fi luată direct de
nod, de un gateway local, de o aplicație edge sau de un serviciu cloud - locul în care e executată
decizia influențează direct latența, consumul energetic, dependența de rețea și confidențialitatea
datelor, exact temele care revin în toate secțiunile următoare ale acestui curs.
Pentru a participa la un ecosistem IoT, dispozitivul trebuie integrat într-un serviciu care permite cel puțin: identificarea dispozitivului, colectarea sau modificarea unor date, comunicarea printr-o rețea, procesarea informațiilor și administrarea pe durata exploatării.
3Caracteristicile și cerințele sistemelor IoT10 min
Sistemele IoT combină dispozitive cu resurse limitate, rețele eterogene și servicii distribuite. O arhitectură trebuie să funcționeze nu doar pentru un prototip cu câteva noduri, ci în condițiile reale de exploatare: pierderi de pachete, întreruperi ale alimentării, dispozitive neactualizate, defectarea gateway-urilor, creșterea numărului de noduri.
Scalabilitate
N_mesaje = N·f_m.
Cu lungimea medie L_m per mesaj: D = N·f_m·L_m - fără să includă antetele,
confirmările sau retransmisiile, care măresc semnificativ valoarea reală.Energie, latență și fiabilitate
E_mesaj = E_trezire + E_procesare + E_TX + E_confirmareL_total = L_nod + L_acces + L_rețea + L_procesare + L_actuareInteligență locală și autonomie
Procesarea locală reduce volumul de date transmis și scade latența - în loc să transmită toate eșantioanele, nodul poate trimite doar valori medii, minime, maxime, evenimente sau rezultate ale unei clasificări.
E_procesare + E_mesaj_redus < E_mesaj_complet - dacă
procesarea locală e mai ieftină energetic decât transmiterea integrală a datelor, merită
aplicată.Autonomia funcțională presupune și capacitatea de a continua serviciile esențiale în absența conexiunii la cloud - nodul sau gateway-ul poate stoca temporar măsurătorile, aplica reguli locale și retransmite datele după restabilirea conexiunii.
4Arhitectura unui sistem IoT10 min
Un model practic pentru arhitectura IoT include patru niveluri: dispozitive și procese fizice, comunicație, edge și gateway, servicii și aplicații - un model de organizare a responsabilităților, nu un standard unic universal.
| Nivel | Rol |
|---|---|
| Dispozitive | senzori, actuatoare, microcontrolere, surse de alimentare |
| Comunicație | transportul datelor: tehnologii locale, LPWAN, celular, cablat |
| Edge/Gateway | filtrare, agregare, conversie protocoale, decizie locală |
| Cloud | stocare pe termen lung, analiză la scară mare, managementul flotei |
Fluxul ascendent transportă datele: senzor → nod → gateway → serviciu →
aplicație. Fluxul descendent transportă configurații, praguri, comenzi, actualizări
și confirmări - împreună formează bucla de control măsurare → decizie → comandă →
proces.
Un actuator nu trebuie să accepte automat orice mesaj primit din rețea. Pentru fiecare mesaj sunt importante: sursa, destinația, momentul producerii, versiunea formatului, autenticitatea și validitatea valorii - o comandă nevalidată e o poartă deschisă pentru manipulare accidentală sau intenționată a procesului fizic.
Rolul gateway-ului
Gateway-ul conectează rețeaua locală de dispozitive la infrastructura IP sau cloud: conversia protocoalelor, agregarea mesajelor, stocarea temporară, autentificarea nodurilor, terminarea conexiunilor securizate și gestionarea actualizărilor. Nu e obligatoriu în toate sistemele - un dispozitiv Wi-Fi sau celular poate comunica direct cu cloud-ul - dar devine util atunci când nodurile folosesc protocoale locale, au resurse limitate sau trebuie să funcționeze în absența Internetului.
5Noduri senzoriale inteligente10 min
Nodul senzorial e interfața directă dintre sistemul IoT și mediul fizic. Componentele principale sunt similare indiferent de aplicație: senzori și circuite de condiționare, convertor analog-digital, microcontroler, memorie, transceiver, circuit de management energetic.
achiziție → validare → procesare → formatare → transmisieValidarea poate detecta valori în afara domeniului, erori de comunicație cu senzorul, date incomplete sau variații fizic imposibile. Un mesaj util nu conține doar valoarea măsurată - de regulă include identificatorul nodului, marca temporală, unitatea de măsură, starea bateriei și numărul secvenței.
Un nod poate transmite temperatura numai dacă variația depășește un prag:
|T[k] - T_transmis| ≥ ΔT_min, cu o transmisie periodică de confirmare pentru a evita o
perioadă foarte lungă fără mesaje. Strategia reduce traficul, dar trebuie proiectată astfel încât
aplicația să poată distinge o valoare constantă reală de un nod defect care nu mai transmite
deloc.
Funcționare ciclică
D = T_activ / T_ciclu; E_ciclu = Σ Pᵢtᵢ (exact
formula folosită pentru profilul de consum din Cursul 10).E_economie = E_comunicație_evitată - E_procesare_locală. Procesarea locală e
avantajoasă energetic doar dacă E_economie > 0. Dacă un accelerometru generează
1000 de eșantioane pe secundă, transmiterea completă poate fi costisitoare - nodul poate calcula
local un indicator (valoarea RMS, componente spectrale) și transmite doar rezultatul, cu condiția
ca energia de procesare locală să fie mai mică decât energia economisită la transmisie.6Topologii și organizarea rețelelor IoT10 min
Topologia descrie modul în care dispozitivele sunt conectate logic și traseele prin care circulă informațiile - influențează consumul, latența, toleranța la defecte și capacitatea de a integra noduri noi. Trebuie diferențiată de tehnologia de comunicație: o rețea bazată pe IEEE 802.15.4 poate fi organizată în stea, arbore sau mesh, în funcție de protocolul utilizat.
| Topologie | Principiu | Avantaj | Limitare |
|---|---|---|---|
| Punct-la-punct | legătură directă între două dispozitive | simplitate, latență redusă | nu scalează la multe noduri |
| Stea | toate nodurile comunică cu un centru | consum redus la noduri, administrare simplă | dependență de elementul central |
| Arbore | organizare ierarhică, agregare pe niveluri | scalabilitate | defectarea unui nod intermediar izolează ramura |
| Mesh | fiecare nod poate comunica cu mai mulți vecini | trasee alternative, toleranță la defecte | complexitate, trafic de rutare, consum crescut la retransmisie |
În topologia stea, nodurile periferice nu retransmit mesajele altor dispozitive - pot rămâne majoritatea timpului în moduri de consum redus, motiv pentru care e frecventă în Wi-Fi, BLE cu dispozitiv central, LoRaWAN și rețele celulare IoT.
P_livrare = Π pᵢ, i=1..H. Cu
aceeași probabilitate p pe fiecare legătură: P_livrare = p^H.Un mesaj trebuie să parcurgă 4 salturi într-o rețea mesh, fiecare legătură având probabilitate de succes p = 0,95. Care e probabilitatea de livrare end-to-end?
Vezi rezolvarea
P_livrare = 0,95⁴ ≈ 0,815
Deși fiecare legătură individuală e fiabilă la 95%, probabilitatea de livrare pe întregul traseu scade la ~81,5% - introducerea mai multor salturi nu garantează automat o fiabilitate mai mare; traseele alternative și retransmisiile, gestionate de protocolul de rutare, sunt ce recuperează efectiv fiabilitatea, nu numărul brut de salturi.
Energia unui nod cu funcție de rutare: E_nod = E_propriu + E_recepție + E_retransmisie -
nodurile amplasate aproape de gateway pot retransmite o parte importantă din traficul rețelei și se
pot descărca mai repede decât nodurile periferice, o asimetrie importantă de anticipat la
proiectare.
7Tehnologii de comunicație pentru IoT10 min
Tehnologia de comunicație trebuie aleasă pe baza aplicației, nu doar pe baza razei maxime declarate - parametrii reali depind de frecvență, putere de emisie, antenă, obstacole și interferențe.
P_R = P_T + G_T + G_R - L_cale - L_suplimentară [dB]. Legătura e
posibilă dacă puterea recepționată depășește sensibilitatea receptorului cu o marjă suficientă.| Tehnologie | Acoperire | Caracteristică dominantă | Aplicații |
|---|---|---|---|
| BLE | locală | consum redus, integrare mobilă | wearables, senzori personali |
| Wi-Fi | locală | rată mare de transfer | multimedia, echipamente alimentate |
| Zigbee / Thread | locală, stea sau mesh | rețele distribuite de putere redusă | clădiri, automatizări |
| LoRaWAN | extinsă, prin gateway-uri | mesaje mici și rare | agricultură, Smart City |
| NB-IoT | extinsă, prin operator | trafic redus, acoperire celulară | contorizare, monitorizare |
| LTE-M | extinsă, prin operator | mobilitate, latență mai redusă | logistică, dispozitive mobile |
IEEE 802.15.4 definește doar nivelul fizic și accesul la mediu - Zigbee, Thread și 6LoWPAN adaugă funcții de rețea și aplicație deasupra lui. Thread e orientat spre IPv6 (participă la o rețea IP printr-un border router); Matter e un protocol de aplicație pentru interoperabilitate, care poate rula peste Thread, Wi-Fi sau Ethernet - nu e o tehnologie radio nouă.
E_livrare ≈ E_încercare / p_s, unde p_s e probabilitatea de succes a unei încercări.
Dacă legătura radio e slabă, numărul de retransmisii crește, iar energia medie per livrare poate
depăși semnificativ energia unei singure transmisii ideale - o tehnologie „eficientă" pe hârtie
poate deveni costisitoare într-un mediu cu propagare dificilă.Selecția tehnologiei trebuie să parcurgă: distanța și mediul de propagare, dimensiunea și frecvența mesajelor, latența acceptabilă, sursa de alimentare, infrastructura disponibilă, bugetul de legătură și energie, și restricțiile de spectru și securitate - în această ordine, nu pornind de la o tehnologie preferată dinainte.
8Protocoale și stive software IoT10 min
Tehnologia radio stabilește cum sunt transmiși biții; pentru un sistem IoT complet sunt necesare protocoale suplimentare pentru adresare, rutare, transport, securitate și schimbul informațiilor între aplicații - o stivă stratificată: fizic/acces la mediu, rețea/adaptare, transport, securitate, aplicație.
IPv6 și 6LoWPAN
IPv6 utilizează adrese pe 128 de biți (N_IPv6 = 2¹²⁸), dar în rețele cu cadre mici
transmiterea antetelor IPv6 complete produce overhead semnificativ. 6LoWPAN introduce un
nivel de adaptare: comprimarea antetelor, fragmentarea și reasamblarea pentru cadre reduse.
Un pachet IP de 300 bytes trebuie fragmentat în cadre cu sarcină utilă maximă 80 bytes. Câte fragmente minime sunt necesare?
Vezi rezolvarea
N_F = ⌈300/80⌉ = ⌈3,75⌉ = 4 fragmente
Pierderea unui singur fragment poate impune retransmiterea unei părți sau a întregului pachet, în funcție de protocol - motiv pentru care mesajele IoT trebuie păstrate cât mai compacte, reducând direct numărul de fragmente necesare.
MQTT - publish/subscribe
MQTT e bazat pe un broker intermediar: un publisher publică mesaje pe un topic, iar orice subscriber abonat la acel topic le primește, fără ca producătorul să cunoască direct destinatarii.
// un nod publica pe:
agricultura/zona1/nod12/temperatura
// o aplicatie se aboneaza la:
agricultura/zona1/+/temperaturaCoAP - model bazat pe resurse
CoAP (Constrained Application Protocol) e apropiat conceptual de REST, cu operații GET, POST,
PUT, DELETE asupra unor resurse adresate prin URI (coap://nod12.local/senzori/temperatura).
Un nod care transmite periodic măsurători către mai multe aplicații se potrivește cu modelul MQTT (distribuire prin broker). Un sistem în care un controler citește direct starea unui actuator și îi modifică configurația se potrivește mai bine cu CoAP (acces direct la o resursă). Alegerea corectă pornește de la fluxul de interacțiune al aplicației.
Indiferent de protocol, un mesaj util trebuie să specifice identificatorul mărimii, valoarea, unitatea de măsură, marca temporală și versiunea formatului - interoperabilitatea reală necesită compatibilitate la mai multe niveluri simultan: conectivitate, protocol, structura mesajelor, și semnificația datelor.
9Edge, gateway și infrastructuri cloud8 min
Procesarea unui sistem IoT poate fi distribuită între noduri, gateway-uri, servere edge și infrastructuri cloud - nu toate datele trebuie transmise către cloud. Alegerea locului de procesare depinde de latența maximă admisă, volumul datelor, conectivitatea disponibilă, confidențialitatea și costul comunicației.
| Nivel | Funcții tipice |
|---|---|
| Dispozitiv | filtrare simplă, detecție de prag, control imediat - latență minimă |
| Gateway/Edge | agregare, corelare locală, conversie protocoale, stocare temporară - context local |
| Cloud | stocare istorică, analiză globală, raportare, managementul flotei - scalabilitate |
L_total = L_dispozitiv + L_acces + L_gateway + L_transport + L_serviciu - dacă
latența sau indisponibilitatea rețelei poate produce o stare periculoasă, decizia trebuie
păstrată local, indiferent cât de atractivă pare centralizarea în cloud pentru analiză.
Agregare și funcționare offline
În loc să transmită toate eșantioanele, gateway-ul poate agrega: media, minimul, maximul,
abaterea standard, numărul de evenimente sau doar valorile care depășesc un prag -
x̄ = (1/N)Σxᵢ.
C_buffer ≥ R_D · T_offline, unde R_D e rata de generare a
datelor, iar T_offline durata maximă estimată a întreruperii conexiunii.După restabilirea comunicației, mesajele trebuie retransmise fără pierderea ordinii și fără duplicări necontrolate - marca temporală, numărul de secvență și indicatorul de retransmisie fiind esențiale pentru ca aplicația să reconstruiască corect istoricul.
10Managementul dispozitivelor IoT8 min
Administrarea unei flote IoT include toate operațiile de la fabricarea dispozitivului până la retragerea din exploatare.
fabricare → înrolare → configurare → exploatare → actualizare →
retragere, cu cicluri repetate între exploatare și actualizare.Înrolarea atribuie dispozitivului o identitate verificabilă - chei simetrice, perechi asimetrice, certificate digitale sau identitate stocată într-un element securizat. Fiecare dispozitiv trebuie să aibă o identitate unică: folosirea aceleiași chei pentru o întreagă familie de produse multiplică drastic impactul compromiterii unui singur exemplar.
În timpul exploatării trebuie monitorizate versiunea firmware-ului, nivelul bateriei, calitatea comunicației, resetările și erorile senzorilor - un mesaj de diagnostic tipic conține exact aceste câmpuri, similar cu mesajele de măsurare, dar orientate spre starea internă a dispozitivului, nu spre datele aplicației.
Actualizarea firmware-ului (OTA)
Actualizarea over-the-air permite remedierea vulnerabilităților fără acces fizic la dispozitiv: descărcarea imaginii, verificarea autenticității și integrității, instalarea, repornirea, confirmarea funcționării.
O imagine firmware de 512 KB trebuie transmisă în blocuri de 4 KB. Câte blocuri minime sunt necesare?
Vezi rezolvarea
N_B = ⌈512/4⌉ = 128 blocuri
Actualizarea trebuie să tolereze întreruperea alimentării și pierderea conexiunii - de aceea sunt folosite frecvent două partiții firmware, o imagine de rezervă, confirmare după pornire și revenire automată la versiunea anterioară dacă noua imagine nu confirmă funcționarea corectă.
La retragerea dispozitivului trebuie revocate identitățile și șterse cheile și datele sensibile - un pas frecvent omis, dar la fel de important ca înrolarea inițială.
11Securitatea sistemelor IoT8 min
Securitatea IoT trebuie proiectată pentru întregul sistem și întregul ciclu de viață - protejarea exclusivă a comunicației nu e suficientă dacă firmware-ul poate fi modificat sau dacă toate dispozitivele folosesc aceeași cheie.
Un atacator poate acționa asupra dispozitivului, legăturii radio, gateway-ului, serviciilor cloud, aplicației utilizator sau procesului de actualizare - amenințările includ interceptarea, modificarea mesajelor, retransmiterea unor mesaje vechi (replay), impersonarea unui nod și instalarea unui firmware malițios.
ROM de încredere → bootloader → firmware → aplicație, fiecare
etapă verificând semnătura sau valoarea criptografică a etapei următoare - exact mecanismul
discutat pentru bitstream-uri FPGA în Cursul 09, aplicat aici firmware-ului unui nod IoT.Valid = SemnăturăCorectă ∧ VersiunePermisă ∧
PlatformăCompatibilă - verificarea integrității printr-un hash neprotejat nu e suficientă,
pentru că un atacator poate modifica atât imaginea, cât și hash-ul asociat.Principiul privilegiului minim se aplică și aici: un nod care publică temperatura nu trebuie să poată modifica configurația altor dispozitive sau administra brokerul - fiecare componentă primește numai drepturile strict necesare funcției sale.
12Aplicații IoT reprezentative4 min
Domeniile reprezentative pentru IoT includ automatizări industriale și mentenanță predictivă, agricultură inteligentă și monitorizarea mediului, infrastructuri urbane (Smart City), clădiri inteligente, sănătate digitală și management energetic.
Fiecare domeniu combină diferit conceptele acestui curs: agricultura tipic combină LoRaWAN (acoperire extinsă, mesaje rare) cu procesare edge locală și funcționare offline tolerantă la întreruperi de conectivitate; automatizările industriale combină adesea rețele mesh locale cu gateway-uri care agregă și transmit doar evenimente relevante; clădirile inteligente folosesc frecvent Zigbee sau Thread pentru densitatea mare de noduri pe suprafață mică.
13Erori frecvente5 min
- „O rețea mesh e mai fiabilă decât o rețea stea, pentru că are mai multe trasee." Nu automat - fiabilitatea unui traseu cu H salturi e P_livrare = p^H, care scade cu numărul de salturi dacă nu există retransmisii sau trasee alternative gestionate activ. Evaluați fiabilitatea reală a protocolului de rutare, nu presupuneți că mai multe trasee înseamnă automat mai multă fiabilitate.
- „MQTT și CoAP sunt interschimbabile, alegerea depinde doar de dimensiunea mesajului." Fals - alegerea depinde de arhitectura de interacțiune: distribuire prin broker (MQTT) vs. acces direct la o resursă (CoAP), un criteriu structural, nu doar de eficiență. Analizați fluxul real de interacțiune al aplicației înainte de a alege protocolul.
- „Criptarea comunicației e suficientă pentru un sistem IoT sigur." Nu - securitatea trebuie acoperi întregul ciclu de viață: Secure Boot, actualizări semnate, identități unice per dispozitiv și principiul privilegiului minim, nu doar canalul de comunicație. Construiți modelul de amenințări pentru întregul lanț (dispozitiv → rețea → gateway → cloud → aplicație), nu doar pentru transportul datelor.
14Rezumat și glosar5 min
Un sistem IoT extinde un nod embedded printr-o identitate, conectivitate și servicii - dar această extindere aduce compromisuri explicite între latență, energie, fiabilitate și scalabilitate, care trebuie evaluate simultan, nu izolat. Arhitectura pe niveluri (dispozitiv, edge, cloud) permite distribuirea inteligentă a procesării, iar alegerea locului corect depinde de cât de critică și de sensibilă temporal e o decizie. Topologia de rețea (stea, arbore, mesh) și tehnologia de comunicație (BLE, Zigbee, LoRaWAN, celular) trebuie alese pornind de la cerințele reale ale aplicației - rază, rată, energie, infrastructură disponibilă - nu de la popularitatea unei tehnologii. MQTT și CoAP acoperă modele diferite de interacțiune (publish/subscribe, respectiv acces la resurse), iar 6LoWPAN adaptează IPv6 la rețele cu resurse limitate. Managementul unei flote IoT acoperă întregul ciclu de viață - înrolare, configurare, actualizare OTA, retragere - iar securitatea trebuie proiectată pentru acest ciclu complet, nu doar pentru canalul de comunicație.
15Întrebări de verificare6 min
- Ce transformă un sistem embedded izolat într-un nod IoT?
- De ce o funcție critică, cu cerințe stricte de latență, nu ar trebui transferată exclusiv în cloud?
- Care e diferența dintre topologia stea și topologia mesh, din perspectiva fiabilității?
- De ce numărul de salturi într-o rețea mesh nu garantează automat fiabilitate mai mare?
- Care e diferența structurală dintre modelul MQTT și modelul CoAP?
- Ce rol are 6LoWPAN într-o rețea IEEE 802.15.4?
- Enumerați etapele ciclului de viață al unui dispozitiv IoT.
- De ce un hash neprotejat nu e suficient pentru validarea unei actualizări firmware?
16Încheierea seriei2 min
Acesta a fost ultimul curs al seriei Sisteme Încorporate. Cele unsprezece cursuri au parcurs drumul complet - de la arhitectura unui procesor și consumul lui energetic, prin sincronizare și sisteme de operare de timp real, accelerare hardware și recoltarea energiei din mediu, până la integrarea unui nod într-o rețea IoT completă, cu managementul și securitatea ei.
Conceptele din acest curs - topologii, MQTT, gateway și managementul dispozitivelor - devin cod și măsurători reale în Laboratorul 04, unde construiți un nod IoT complet, de la senzor la panou de comandă.