Aplica ție web pentru vizualizarea si gestionarea dispozitivelor de tip IoT (Internet of Things) Coordonator Absolvent Prof.dr.ing. Dorin Carstoiu… [630240]

Departamentul Automatică și Informatică Industrială
Facultatea Automatică și Calculatoare
Universitatea POLITEHNICA din București

LUCRARE DE DIPLOMĂ

Aplica ție web pentru vizualizarea si gestionarea
dispozitivelor de tip IoT (Internet of Things)

Coordonator Absolvent: [anonimizat].dr.ing. Dorin Carstoiu Munteanu Darius -Ioan

2020

1 Cuprins

1. Introducere ………………………………………………………………………………………… 2
1.1. Motive …………………………………………………………………………………………. 2
1.2. Alcătuirea lucrării …………………………………………………………………….. … 2
2. Prezentarea temei alese ……………………………………………………………………….. 3
2.1. Internet of Things (IoT) ……………………………………………………………….. 3
2.1.1. Istoria IoT ………………………………………………………………………… …. 4
2.1.2. Arhitectura unei rețele IoT ………………………………………………….. … 5
2.2. Avantajele IoT …………………………………………………………………………….. 6
2.3. Dezavantajele IoT ………………………………………………………………………… 7
2.4. Utilizări ale IoT ……………………………………………………………………………. 9
3. Descrierea problemei abordate și a metodei de rezolvare propuse …………… 13
3.1. Problema ide ntificată …………………………………………………………………. 13
3.2. Soluția propusă ………………………………………………………………………….. 13
3.3. Aplicații similare ……………………………….. ………. ……………………………… 14
4. Documentație tehnică …………………………………………………… …………………… 15
4.1. Componenta software ………………………………………………………………… 15
4.1.1. Tehnologii folosite ……………………………………………………………… 18
4.1.2. Arhitectura software …………………………………………………………. … 25
4.1.3. Front end ………………………………………………………………………….. .. 28
4.1.4. Back end …………………………………………………………………………… . 34
4.2. Componenta hardware ………………………………………………………………. 4 6
4.2.1. Componente folosite ………………………………………………………….. .. 46
4.2.2. Prima metodă abordată …………………………………………………….. … 49
4.2.3. A do ua metodă abordată ……………………………………………………. … 50
4.2.4. Programarea circuitului ……………………………………………………. …. 52
5. Concluzii ………………………………………………………………………………………….. 54
5.1. Viitoare îmbunătățiri …………………………………………………………………. 55
Bibliografie …………………………………………………………………………………………. 56

2 1. Introducere

Aplicația propusă, pe care am ales s -o denumesc simplu , IoT Lab , este o platformă web
avansată, al cărui scop principal este vizualizarea și gestionarea dispozitivelor de tip Int ernet of
Things (IoT). Aceasta permite unui utilizator să își înregistreze în aplicație dispozitivele
inteligente pentru o mai bună gestiune a acestora. Mai mult decât atât, îi permite să -și
înregistreze dispozitivele în funcție de clădirea în care se află acestea, utilizatorul putând, spre
exemplu, să urmărească prin intermediul aplicației d ispozitivele pe care le are la birou, dar și
pe cele de acasă.

1.1. Motive

Într-o lume în continuă schimbare, un domeniu care se dezvoltă în mod constant este
Internet of Things . Zilnic apar noi dispozitive inteligente , capabile să se conecteze la internet,
fie că vorbim despre televizoare, frigidere, stații meteo sau diferite electrocasnice .

Problema cu astfel de dispozitive este faptul că sunt din ce în ce mai multe, iar cantitatea
de informații înregistrate și transmise de acestea crește în mod constant. Lipsa unei modalități
de vizualizare și gestionare a tuturor acestor informații provoacă o foarte mare bătaie de cap
utilizatorilor, negând însuși scopul principal al acestora – să ușureze viața oamenilor.

Aplicația propusă rezolvă aceasta prob lemă prin crearea unei platforme simple și
intuitive, prin intermediul căreia utilizatorii își pot gestiona cu ușurință dispozitivele inteligente,
indiferent de numărul acestora.

1.2. Alcătuirea lucrării

Pe lângă prezenta documentație, al cărui scop este prez entarea cercetării domeniului și
problemei identificate, aceasta este însoțită și de componenta practică a lucrării. Aceasta este
alcătuită din aplicația propriu zisă, cât și de o componentă hardware, dezvoltată special pentru
a demonstra capabilitățile aplicație i web .

Strict pentru prezentarea aplicației, am ales dezvoltarea unui dispozitiv IoT menit pentru
a fi folosit cu orice tip de frigider. Acesta este capabil să înregistreze detalii relevante pentru
utilizator, cum ar fi temperatura, nivelul de umid itate, dacă lumina este aprinsă sau dacă ușa
frigiderului este deschisă. Dispozitivul este conectat la aplicație prin intermediul internetului,
iar informațiile înregistrate sunt trimise în timp real către aplicație.

După cum am specificat, platforma prez entată poate fi folosită pentru orice tip de
dispozitiv IoT. Dispozitivul pentru frigidere pe care am ales să îl dezvolt este doar un exemplu,
nicidecum o limitare.

3 2. Prezentarea temei alese

2.1. Internet of Things (IoT)

Internet of Things reprezintă o rețea de dispo zitive care se conectează la Internet pe baza
protocoalelor stipulate de echipamentele de detectare a informațiilor pentru a comunica și
pentru a obține informații despre poziționare, urmărire, monitorizare și administrare. Scopul
IoT este de a permite dispozitivelor să fie conectate oricând, oriunde, cu orice și oricine
utilizează în mod ideal orice cale / rețea și orice serviciu [1].

Internet of Things este aici pentru a schimb a lumea așa cum o cunoaștem. Mașini
inteligente, case inteligente, orașe inteligente, tot ceea ce ne înconjoară poate fi transformat
într-un dispozitiv inteligent cu ajutorul Internet of Things. Cu toate că IoT este capabil să aducă
următorul mare boom pe piața muncii , suntem încă departe de momentul în care acesta va fi
perfect integrat în majoritatea industriilor. În ultimii ani au fost făcute multe progrese în acest
sens, iar tehnologia a devenit mult mai accesibilă pentru utilizatorul de rând. Cu pași î nceți, dar
siguri, ne îndreptăm către o lume în care majoritatea obiectlor din jurul nostru vor putea fi
considerate „smart” [2].

Fig. 2.1 Exemplu de sistem IoT [1]

Denumirea de Internet of Things se traduce în limba română drept Internetul Lucrurilor .
Prin termenul „things” (lucuri) înțelegem o rețea de obiecte fizice și face referire la dispozitivele
de toate tipurile, care pot aparține oricărui domeniu sau industrie, capabile să se conecteze la
Internet. În ziua de astăzi internetul nu este doar o rețea de calculatoare, ci a devenit o rețea de
dispozitive de toate tipurile și dimensiunile, vehicule, smartphone -uri, electrocasnice, jucării,
camere video, instrumente medicale și sisteme industriale, clădiri, toate conectate, toate
transmițând informații despre propria stare, comunicând și partajând toate acestea prin
intermediul protocoalelor standard de internet.

Internetul și aplicațiile sale au devenit un aspect important al s tilului de viață uman de
astăzi. Principala metodă de comunicare pe internet este om -om. Cu toate acestea, internetul va
deveni în curând Internetul lucrurilor. În ultimii ani, această interacțiune om -om s -a extins mai
întâi la om -lucru, iar mai apoi la lu cru-lucru. Conceptele IoT, deși există de ani buni pe piață,
sunt încă în faza inițială a implementării comerciale [1].

4
Fig. 2.2 Creșterea numărului de dispozitive conectate, în raport cu populația [3]

2.1.1. Istoria IoT

Unul dintre primele exemple cu aplicabilitate reală a IoT a fost un aparat frigorific Coca –
Cola la începutul anilor 80, situat în Universitatea Carneige Melon din Pittsburgh,
Pennsylvania. Un student la universitate, Dan Nichols, era foarte obosit de drumul relativ lung
de la biroul său până la aparatul frigorif ic, mai ales că de fiecare dată când își dorea un suc rece,
bătea tot drumul doar pentru a găsi frigiderul gol. Curând, Nichols și câțiva prieteni au dezvoltat
un sistem pentru conectarea la frigider prin APRANET – un precursor la internetul de astăzi –
care le-a permis să verifice de la distanță starea aparatului înainte de a face călătoria.

Cu toate acestea, de abia în anul 1999, numele „IoT” a fost creat, iar responsabil pentru
acesta este un tip pe nume Kevin Ashton, co -fondator al grupului de cercetar e Auto -ID Labs ,
din cadrul Institutului Tehnologic din Massachusetts. „ Internet of Things ” a fost titlul unei
prezentări pe care Ashton a făcut -o pentru compania Procter & Gamble, în timp ce lucra acolo
ca brand manager. Ashton fusese repartizat să ajute l a lansarea unei linii de produse cosmetice,
dar era îngrijorat că de fiecare dată când intra în magazinul său local, o anumită nuanță de ruj
maroniu părea întotdeauna epuizată. El s-a consultat cu oamenii responsabili ai lanțului de
aprovizionare P&G, care i-au spus că în depozit erau disponibile o mulțime de rujuri în acea
culoare. Acest lucru nu a fost suficient de bun – Ashton a vrut să știe unde se afla rujul său, ce
i se întâmpla și de ce magazinul nu l -a putut ține pe stoc.

Aproximativ în ace eași per ioadă au fost dezvoltate etichete de identificare a frecvenței
radio (RFID). Astfel de etichete au fost încorporate cu mici cipuri activate radio, care puteau
transfera câțiva biți de date fără fir. În cadrul prezentării sale , denumită „Internet of Things” ,
Ashton a propus cum pot fi utilizate aceste etichete RFID pe produsele P&G, permițând
identificarea și urmărirea unor obiecte specifice de -a lungul lanțului de aprovizionare, ceea ce
înseamnă că localizarea stocului ar putea fi mai bună și mai ușor de mo nitorizat. Știind că
„Internetul” – un cuvânt ce încă impresiona investitorii la vremea respectivă – îi va încânta pe
directorii care vor participa , Ashton a lucrat la un titlu al prezentării care să conțină acest
termen.

Ulterior, Ashton a oferit sute de prezentări liderilor corporati ști despre potențialul
tehnologiei RFID – mai exact, modul în care fiecare cip RFID a putut comunica cu aparatele
printr -o rețea wireless. Până în 2003, Auto -ID Center avea 103 sponsori, numeroase filiale din
întreaga lume și angajamente față de standard ul calității , astfel încât orice dispozitiv inteligent
să poată comunica cu rețelele furnizori lor și comercianți lor cu amănuntul. De -a lungul timpului,

5 piața s -a dezvoltat, s -au făcut investiții, iar cipurile s -au îmbunătățit și au devenit din ce în ce
mai bune și din ce în ce mai ieftine [4].

2.1.2. Arhitectura unei rețele IoT

Așa cum este prezentat în [5], în esență, structura unei rețele IoT este comp usă din
numeroase elemente: senzori, protocoale, elemente de acționare , servicii cloud și straturi.
Având în vedere complexitatea sa, există trei straturi ale unei arhitecturii IoT. Aceste straturi
au fost alese astfel încât să includă toate aceste diferit e tipuri de componente într -o rețea
sofisticată și unificată . Acestea sunt:

A. Strat ul de percepție

Stratul de percepție este cunoscut și sub denumirea de stratul de „senzori” în IoT. Acest
strat detectează, colectează și prelucrează informații și apoi le transmite stratului de legătură.
Acest strat realizează, de asemenea, colaborarea cu nodul IoT în re țelele locale și pe distanțe
scurte.

B. Stratul de legătură

Stratul de legătură al IoT servește funcției de rutare și transmitere a datelor către diferite
hub-uri și dispozitive IoT de pe Internet.

C. Stratul aplicației

Stratul aplicației garantează au tenticitatea, integritatea și confidențialitatea datelor. În
acest strat, scopul IoT de creare a unui mediu inteligent este atins.

Fig. 2. 3 Cele trei straturi ale unei arhitecturi IoT [6]

6 2.2. Avantajele IoT

Automat izare și control

Datorită obiectelor fizice conectate și controlate digital cu infrastructura wireless, există
o cantitate mare de automatizare și control în funcționare. Dispozitivele sunt capabile să
comunice între ele , transmițând informații ce pot fi prelucrate de sisteme inteligente, luarea de
decizii făcându -se fără intervenția omului.

Informați i

Este evident că a avea mai multe informații ajută la luarea de decizii mai bune. Indiferent
dacă este vorba despre decizii de zi cu zi , cum ar fi să știi exact ce îți lipsește acasă și trebuie
să cumperi la magazin sau dacă angajații din compania ta au destule consumabile disponibile ,
informația înseamnă putere , iar IoT oferă oportunitatea obținerii unei cantități masive de
informații.

Monitor izare

Unul d intre cele mai evident e avantaj e ale IoT este monitorizarea. Cunoașterea cantității
exacte a alimentelor sau a calității aerului din cas ă, poate oferi un set de informații suplimentar ,
care nu ar fi putut fi disponibil anterior cu ușurință. De exemplu, ști ind că nu mai este lapte în
frigider sau că imprimanta a rămas fără cerneală, cu ajutorul IoT poți scuti un drum în plus până
la magazin. Mai mult de at ât, monitorizarea datei de expir are a produselor din casă poate oferi
un plus de siguranță.

Timp

Așa c um am indicat în exemplele anterioare, cantitatea de timp economisită datorită IoT
este impresionantă . Și în viața modernă de astăzi știm cu toții că timpul este cea mai importantă
resursă. Interacțiunea dintre aparate oferă o eficiență mai bună, prin urmare, rezultate precise
pot fi obținute rapid. Acest lucru duce la economisirea de timpul prețios. Astfel, în loc să repete
aceleași sarcini în fiecare zi, oamenilor le este permis să facă alte munci creative.

Economisirea de b ani

Poate unul dintre c ele mai mar i avantaj e ale IoT este economisirea de bani. Dacă prețul
echipamentului de etichetare și monitorizare este sesizabil mai mic decât suma de bani
economisită prin acest sistem , atunci Internet of Things va fi adoptat la scară largă . În mod
fundamen tal, IoT se dovedește a fi foarte util oamenilor în rutinele lor zilnice, făcând ca
aparatele să comunice între ele într-o manieră eficientă, astfel economisind și conservând
energia și costurile.

Utilizarea optimă a energiei și resurselor poate fi obțin ută prin adoptarea acestei
tehnologii și prin menținerea dispozitivelor sub supraveghere. Putem fi avertizați în caz de
posibile blocaje, defecțiuni și daune aduse sistemului.

Automatizarea sarcinilor zilnice

IoT permite automatiza rea și control area sarcinil or care sunt efectuate zilnic, evitând
intervenția umană. Comunicarea între dispozitive contribuie la menținerea transparenței
proceselor. De asemenea, conduce la uniformitate în sarcini și permite menține rea calității

7 serviciilor. De asemenea, în ca z de urgență, se pot lua rapid decizii de ameliorare a situației ,
dispozitivele fiind capabile să semnaleze imediat orice problemă apărută.

O calitate mai bună a vieții

Toate aplicațiile acestei tehnologii culminează cu un confort sporit, comoditate și un
management mai bun al dispozitivelor din jurul nostru , îmbunătățind astfel calitatea vieții [7].

2.3. Dezavantajele IoT

Fig. 2.4 Impedimentele IoT

Compatibilitate

În prezent, nu există un standard internațional de compatibilitate pentru echipamentele
și dispozitivele de tip IoT. Totuși, acesta este cel mai ușor de depășit impediment. Companiile
producătoare ale acestor echipamente trebuie doar să se pună de acord în privința unui standard,
cum ar fi Bluetooth, USB, NFC etc. Nu este nevoie de nimic nou sau inovativ, pe piață deja
există numeroase tehnologii de comunicare suficient de avansate.

Problema nu se oprește aici. Întrucât dispozitivele de la diverși producăt ori vor fi
interconectate, pot apărea probleme asociere, chiar dacă se folosește același standard . În ziua
de astăzi majoritatea dispozitivelor inteligente din jurul nostru sunt compatibile cu tehnologia
Bluetooth și încă există probleme de compatibilitate între acestea ! Sau mai există cazuri în care
producători aleg să restricționeze compatibilitatea conectării doar la produsele fabricate de ei.
Astfel de p robleme de compatibilitate pot duce la achiziționarea de aparate de la un anumit
producător, ceea ce va duce la crearea unui monopol său pe piață.

8 Complexitate

IoT este o rețea diversă și complexă. Orice defecțiune sau eroare de tip software sau
hardware va avea consecințe grave. Chiar și întreruperea curentului electric poate provoca
multe inconveniente.

Ca în cazul oricărui sistem cu un grad ridicat de complex itate, există multe variabile
care pot provoca o problemă. În cazul Inte rnet of Things , problemele și erorile pot apărea dintr –
o sumedenie de motive . De exemplu, să spunem că în cadrul unei locuințe, atât soțul, cât și
soția, primesc o notificare prin care sunt informați că nu mai este lapte acasă. Ambii se vor opri
la un maga zin în drum spre casă și vor cumpăr a lapte. Drept urmare va fi achiziționată o
cantitate dublă de lapte față de cât era nevoie. Sau poate că o eroare software determină
trimiterea în mod automat a unei comenzi pentru un cartuș de cerneală nou pentru imprim antă
la fiecare oră timp de câteva zile, deși era nevoie de o singură comandă.

Confidențialitate / securitate

Odată cu transmiterea tuturor acestor date pe internet , riscul de a pierde
confidențialitatea crește. De exemplu, cât de bine vor fi criptate și păstrate datele transmise ?
Cu siguranță nimeni nu își dorește ca un necunoscut, care de multe ori poate fi rău intenționat,
să afle date sensibile precum situația financiară sau date bancare.

Siguranță

Rețele IoT pot reprezenta o țintă foarte atractivă pentru hackeri. Securizarea acestor
rețele este complicată și greu de făcut, având în vedere multitudinea de dispozitive conectate.
Întrucât toate aparatele de uz casnic, utilajele industriale, serviciile din sector ul public, precum
furnizarea apei sau transportul în comun, precum și multe alte dispozitive sunt conectate la
Internet, există foarte multe informații disponibile online. Aceste informații sunt predispuse la
atacuri cibernetice.

Un astfel de atac lansat la nivelul unui întreg oraș va avea consecințe dezastruoase. Fie
hackeri ar pune mâna pe informațiile confidențiale ale unui număr foarte mare de oameni, fie
întreaga infrastructură a orașului ar putea fi complet blocată până la plata unei sume foarte mar e
de bani către cei care au inițiat atacul.

Mai există posibilitatea ca un magazin să livreaz e automat un produs echivalent față de
produsul cerut, dar utilizatorul să fie alergic la acesta. Sau poate livra o aromă care nu este pe
placul acestuia sau un p rodus expirat. Drept urmare, siguranța este în cele din urmă în mâinile
consumatorului , acesta fiind singurul capabil să facă orice tip de verificare finală înainte de a
folosi un anumit produs.

Dispariția anumitor locuri de muncă

Acesta este un subiect intens discutat, mai ales în ultimii ani. Faptul că avansarea și
dezvoltarea tehnologiei va face ca multe dintre activitățile de zi să fie automatizate, înseamnă
că multe dintre activitățile ce sunt realizate cu ajutorul oamenilor vor fi înlocuite de proce se
automate realizate de roboți sau sisteme de inteligente, cum ar fi IoT. Astfel, toate acele poziții
care necesitau resursă umană vor dispărea, iar cea mai apăsătoare întrebare este ce vor face toți
acei oameni care vor rămâne fără loc de muncă.

9 Deși automatizarea proceselor va economisi resurse masive de bani, creșterea
numărului persoanelor fără loc de muncă va avea un efect negativ asupra economiei și va afecta
în cele din urmă și companiile care au implementat astfel de practici.

Tehnologia preia controlul vieții

Ca în cazul oricărei tehnologii, dar mai ales în cazul celor care au un impact direct în
viața de zi cu zi, există o reticență în ceea ce privește nivelul de control pe care îl au acestea
asupra noastră. Inevitabil v iața noastră va fi controlată tot mai mult de tehnologie și ne va face
din ce în ce mai dependenți de ea. Tânăra generație este deja dependentă de tehnologie pentru
orice lucru mic. Va trebui să decidem cât din viața noastră de zi cu zi suntem dispuși să
automatizăm și cât de mult ne dorim să ne lăsăm controlați de tehnologia din jurul nostru [7].

2.4. Utilizări ale tehnologiei IoT

Fig. 2.5 Aplica ții ale tehnologiei IoT [8]

Locuințe / clădiri inteligente

Dotarea clădirilor cu tehnologii de tip IoT poate ajuta atât la reducerea consumului de
utilități asociate clădiri i (electricitate, apă), cât și la îmbunătățirea nivelului de satisfacție al
locatarilor , fie că sunt angajați într-o clădir e de birouri sau chiriași într-o locuință . Impactul este
atât în termeni economici (cheltuieli operaționale reduse), cât și în cele sociale (reducerea
producerii de carbon asociate clădirilor, care sunt un ele dintre cele mai dăunătoare tipuri de
emisi i de gaze cu efect de seră).

În ace st caz un rol cheie îl joacă senzorii, care sunt utilizați atât pentru a monitoriza
consumul de resurse, cât și pentru a detecta în mod continuu nevoile utilizatorilor actuali. Un
astfel de sistem integrează o serie de subsisteme diferite și, prin urmare, necesită un nivel ridicat
de standardizare pentru a asigura interoperabilitatea. De asemenea, un astfel de sistem trebuie
să fie capabil să verifice că deciziile luate cu privire la resursele pe care le gestionează (de
exemplu, aprinderea / oprirea iluminatului, încălzirea, răcirea etc.) corespund nevoilor și
așteptărilor utilizatorilor, care la rândul lor sunt strict legate de activitățile pe care aceștia le
întreprind și / sau intenționează să le întreprindă.

10 Orașe inteligente

Termenul „Orașe inteligente” este folosit pentru a denumi ecosistemul care apare prin
implementarea infrastructurii avansate de comunicare și a serviciilor noi pe scenarii la nivelul
unui întreg oraș. Cu ajutorul serviciilor avansate, este posibil să se op timizeze utilizarea
infrastructurilor orașului fizic (de exemplu, rețelele rutiere, rețeaua electrică etc.) ,
îmbunătățindu -se astfel calitatea vieții pentru cetățenii săi. Tehnologiile IoT pot avea o serie de
aplicații diverse în cazul orașelor inteligente . Ca studiu de caz, tehnologiile IoT pot fi utilizate
pentru a furniza sisteme avansate de control al traficului. Prin IoT va fi posibil ă monitorizarea
traficul auto în orașele mari sau pe autostrăzi și implementarea servicii lor care oferă sfaturi de
rutar e a traficului pentru a evita congestia. În această perspectivă, mașinile vor fi înțelese ca
reprezentând „obiecte inteligente”. În plus, sistemul de dispozitive de parcare inteligent, bazat
pe tehnologii RFID și senzor i, poate permite monitorizarea spații lor de parcare disponibile și
oferă șoferilor sfaturi de parcare automatizate, îmbunătățind astfel mobilitatea în mediul urban.

Mai mult, senzorii pot monitoriza fluxul de vehicule pe autostrăzi și pot prelua
informații generale, cum ar fi viteza medie și numărul de mașini. Senzorii ar putea detecta
nivelul de poluare al aerului, preluând informații de spre smog, cum ar fi nivelul de dioxid de
carbon, PM10, etc. și ar putea furniza aceste informații agențiilor de sănătate. În plus senzorii
ar putea fi folos iți într -un cadru criminalistic, prin detectarea încălcări i legii și prin transmiterea
datelor relevante către agențiile de aplicare a legii, pentru a identifica infractorul sau pentru a
stoca informații relevante în cazul unui accident, astfel încât să se determine cauzele exacte ale
producerii accidentului [10].

Monitorizarea mediului

Tehnologia IoT poate fi aplicată în cu succes pentru monitorizare a mediului. În acest
caz, un rol cheie îl joacă capacitatea de a sesiza, într -un mod cât mai eficient și centralizat ,
fenomene și procese naturale (temperatură, vânt, precipitații, adâncimea unui râu), precum și
de integrarea și distribuirea perfectă a acestor date în aplicații la nivel global. Prelucrarea
informațiilor în timp real, împreună cu capacitatea unui număr mare de dispozitive de a
comunica între ele, oferă o platformă solidă pentru detectarea și monitorizarea anomaliilor care
pot duce la periclit area vieții umane și animale. Desfășurarea vastă a dispozitivelor
miniaturizate poate să permită accesul în zone critice, prin care prezența operatorilor umani ar
putea să nu reprezinte o opțiune viabilă (de exemplu, în zone vulcanice, abisuri oceanice, zo ne
îndepărtate), de unde informațiile obținute pot fi comunicate către un punct de control extern
pentru a detecta condiții ano rmale. În această perspectivă, tehnologiile IoT pot permite
dezvoltarea unei noi generații de sisteme de monitorizare și asistenț ă decizională, oferind o
granularitate sporită și soluții în timp real pentru astfel de probleme .

Un alt caz în care capacitatea de detectare a dispozitivelor IoT susține siguranța
mediului este reprezentată de detectarea incendiilor. Atunci când o suită de senzori detectează
prezența posibilă a focului (prin intermediul, de exemplu, a senzorilor de temperatură), o alarmă
este trimisă direct la secția de pompieri într -un timp foarte scurt (exploatând caracteristicile
avansate de comunicare ale platformei I oT), împreună cu alți parametri care sunt utili în luarea
deciziilor și oprirea cât mai rapidă a incendiului , cum ar fi descrierea zonei supuse focului,
prezența posibilă a oamenilor, a materialelor inflamabile etc. În mod cert, răspunsul rapid va
rezulta în salvarea de vieții umane, atenuarea daunelor aduse proprietății sau vegetației și, în
general, reducerea nivelului de stricăciuni .

Multe alte scenarii legate de protecția civilă pot profita de sistemele IoT ( dezastre
naturale cum ar fi cutremurul, tsu nami etc.), întrucât capacitatea de a accesa o multitudine de

11 informații despre mediu în timp real pe zone de mari dimensiuni permite adoptarea de strategii
eficiente de coordonare între echipele de intervenție .

Sănătate

Tehnologiile de tip IoT pot avea o serie de aplicații în sectorul de sănătate . Pe de o parte,
ele pot fi utilizate pentru a îmbunătăți soluțiile de viață asistată actuale. Pacienții vor purta
continuu cu ei senzori medicali pentru monitorizarea parametrilor precum temperatura
corpului, te nsiunea arterială, activitatea cerebrală, respirație. Alți senzori, care pot fi purtați
(cum ar fi accelerom etru sau giroscop) sau fi cși (de proximitate) vor fi utilizați pentru a aduna
date necesare pentru monitoriza rea activitățile pacientului în medi ul lui de viață. Informațiile
vor fi colectate local și transmise către centre medic ale, care vor putea efectua o monitorizare
la distanță avansată și vor fi capabile să acționeze rapid la nevoie. Interconectarea unor astfel
de senzori ar putea oferi o imagine cuprinzătoare a parametrilor de sănătate, declanșând astfel
o intervenție a personalului medical la detectarea condițiilor care pot duce la deteriorarea
sănătății, realizând astfel îngrijiri preventive.

Un alt sector relevant de aplicații se refer ă la soluții personalizate de îngrijire a sănătății
și bunăstare. Utilizarea senzorilor purtabili, împreună cu aplicații adecvate care rulează pe
dispozitive personale, le permite oamenilor să își urmărească activitățile zilnice (pași parcurși,
calorii ars e, exerciții efectuate etc.), oferind sugestii pentru îmbunătățirea stilului lor de viață și
prevenirea apariției problemelor de sănăt ate.

Afaceri inteligente

Conform [9], putem descrie tehnologia RFID astfel: „RFID este prescurtarea termenului
englez Radio -Frequency Identification (Identificare prin frecvență radio). Este o metodă de
identificare automată care se bazează pe stocarea și regăsirea datelor fără atingere, la distanță,
prin unde radio, folosind dispozitiv e numite etichete RFID (engleză: RFID tag) și transpondere
RFID. Tehnologia necesită o cooperare a unui aparat cititor de RFID cu eticheta RFID.

O etichetă RFID este un obiect mic sau foarte mic (chiar sub 1 mm x 1 mm) care poate
fi aplicat sau încorporat în principiu în orice produs sau obiect, dar și în corpul animalelor sau
persoanelor, cu scopul de identificare și urmărire, folosind undele radio. Unele etichete pot fi
citite de la mulți metri depărtare, chiar mult peste 50 m, iar eticheta se poate afla și în afara
razei de vedere a cititorului de RFID.

Cele mai multe etichete RFID conțin cel puțin două părți:
• un circuit integrat (cip) pentru stocarea și prelucrarea de informații, modulare și
demodulare a unui semnal de radio (RF), și alte funcții de sp ecialitate;
• antenă pentru recepționarea și transmiterea de semnale radio.”

Tehnologiile RFID sunt deja utilizate în multe sectoare și industrii pentru gestionarea
stocurilor, pe întregul lanț de furnizare și livrare. Aceasta se bazează pe capacitatea
tehnologiilor RFID de a identifica și de a oferi suport pentru urmărirea mărfurilor. În acest
moment, însă, aplicațiile RFID sunt construite într -o manieră destul de ad -hoc și sunt doar
parțial integrate în sistemele de gestionare a aprovizionării.

RFID sunt utilizate în mod obișnuit pentru a monitoriza și gestiona mișcarea produselor
printr -un lanț de aprovizionare . De obicei , etichetele RFID sunt atașate direct la articole (sau la
containerele care le transportă), în timp ce cititorii sunt așezați în întreag a instalație pentru a fi
monitorizați. Tehnologiile IoT pot oferi o flexibilitate sporită în ceea ce privește pozițiile

12 cititorilor, oferind în același timp o interoperabilitate perfectă între aplicațiile bazate pe RFID
utilizate de diferiți furnizori care se ocupă de produs pe parcursul diferitelor faze ale ciclului
său de viață.

În aplicațiile de vânzare cu amănuntul, tehnologiile IoT pot fi utilizate pentru a
monitoriza disponibilitatea produsului în timp real și pentru a menține un inventar exact al
stocurilor. De asemenea, pot juca un rol în sprijinul consumatorilor , prin care aceștia pot prelua
automat toate datele despre produsele cumpărate. De asemenea, tehnologiile de identificare pot
ajuta la limitarea furturilor și în combaterea contrafacerii, of erind produselor un identificator
unic, inclusiv o descriere completă și demnă de încredere a bunului respectiv .

Mai mult, senzorii și tehnologiile specifice bio -senzor în combinație cu tehnologia
RFID pot permite controlarea proceselor de producție, cali tatea produsului final și posibila
prelungire a duratei de valabilitate a produsului, în industria alimentară. De exemplu,
dispozitivele RFID pot fi utilizate pentru a identifica și urmări produsul, în timp ce bio -senzorii
pot monitoriza parametrii precum temperatura și compoziția bacteriană pentru a garanta cea
mai bună calitatea a produsului final.

Securitate și supraveghere

Supravegherea securității a devenit o necesitate pentru clădirile de birouri , centrele
comerciale, fabrici, parcări și multe alte locuri publice. Scenariile de securitate a propriei
locuințe se confruntă și cu ameninț ări similare, deși la o scară mai mică . Tehnologiile
compatibile cu IoT pot fi utilizate pentru a îmbunătăți performanța soluțiilor actuale, oferind
alternative mai ieft ine și mai puțin invazive la desfășurarea pe scară largă a activităților uzuale ,
păstrând în același timp confidențialitatea utilizatorilor. Senzorii ambianți pot fi folosiți pentru
a monitoriza prezența substanțelor chimice periculoase. Senzorii care moni torizează
comportamentul oamenilor pot fi folosiți pentru a determina prezența persoanelor care
întreprind acțiuni ce par a fi suspect e. Prin urmare, pot fi create sisteme eficiente de avertizare
timpurie. Identificarea personală prin RFID sau tehnologii similare este de asemenea o opțiune.

Cu toate acestea, în multe țări, asociațiile de locatari protestează cu fermitate împotriva
încălcării vieții private care ar putea rezulta din adoptarea pe scară largă a unei astfel de
tehnologii. Atunci când sunt utilizate împreună cu sisteme de control al accesului bazate pe
roluri, tehnologiile IoT pot ofer i un nivel ridicat de flexibilitate, putând face față politicilor de
acces (de exemplu, la diferite zone ale clădirilor) care se pot schimba în timp din cauza
modificărilor logistice și / sau modificări ale rolului utilizatorului și / sau în funcție de
informațiile contextuale (de exemplu, unele zone nu sunt accesibile într -o anumită zi din cauza
lucrărilor de renovare în curs). De asemenea, pe această piață, avantajele sunt în ceea ce privește
funcționalitatea îmbunătățită, o creștere a satisfacției utiliz atorilor prin reducerea utilizării
camerelor de luat vederi , costuri operaționale reduse și flexibilitate crescută într -un mediu în
continuă schimbare.

În mod clar domeniul de aplic abilitatea al Internet of Things este extrem de larg. Cu
toate acestea, ap licațiile care sunt construite pe baza IoT pot fi în mod constant îmbunătăți te,
crescând astfel competitivitatea soluțiilor disponibile. Prin urmare, adoptarea IoT va fi puternic
determinată de nevoile pieței și de dinamica acesteia . În același timp, indus triile din sfera
tehnologi ei informației și a comunicațiilor împreună cu organismele legislative adoptă o serie
de inițiative pentru a stabili orienta rea procesul ui de dezvoltare a IoT cu scopul de a maximiza
valoarea sa socio -economică, reducând în acelaș i timp amenințările legate de confidențialitatea
datelor [10].

13 3. Descrierea problemei abordate și a metodei de
rezolvare propuse

3.1. Problema identificată

Scopul tehnologiei Internet of Things este foarte simplu – aceasta dorește simplificarea
vieții utilizatorilor săi. Aceștia sunt consumatori i uzuali, care folosesc această tehnologie acasă
sau la birou pentru a reduce din activitățile zilnice repetitive și plictisitoare precum reținerea
datei de expirare a produselor alimentare din casă sau verificarea nivelului de cerneală din
imprimantă.

În același timp tehnologiile IoT pot fi folosite și în majoritatea industriilor pentru
eficientizarea proceselor și urmărirea produselor pe linia de asambl are sau în circuitul acestora
de la furnizor până la consumatorul final.

Pe scurt, oricare ar fi utilizatorul, acesta optează să folosească IoT ca să își ușureze viața.
Problema apare în momentul în care un utilizator deține mai multe astfel de dispoziti ve. Fiecare
dispozitiv IoT, indiferent de scopul pentru care este folosit, va avea aceeași activitate principală.
Acesta va înregistra o serie de informații, de diferite tipuri, informații pe care le va transmite
către utilizator, prin intermediul internet ului. Utilizatorul este nevoit să verifice aceste
informații în mod regulat, accesând fiecare dispozitiv în parte.

Este destul de clar că verificarea separată a fiecărui dispozitiv este o activitate redundantă
și repetitivă care contrazice însuși scopul tehnologiei IoT – eliminarea acestor tipuri de activități
în vederea simplificării vieții utilizatorului.

3.2. Soluția propusă

Soluția propusă este o platformă web menită să vină în ajutorul utilizatorilor sub forma
unei aplicații care să centralizeze to ate informațiile monitorizate de dispozitivele IoT deținute.
Aplicația monitorizează toate dispozitivele înregistrate în aceasta, scopul ei fiind să ofere o
punct unic de unde utilizatorul poate accesa toate dispozitivele sale, fără a mai fi nevoie să le
verifice separat.

Pentru a demonstra capabilitățile aplicației web, aceasta este însoțită de o componenta
hardware – un dispozitiv inteligent alcătuit dintr -o plăcuță de dezvoltare cu microcontroler și o
serie de senzori. Întrucât crearea unui sistem care să simuleze nenumă ratele tipuri de dispozitive
IoT este imposibilă, am ales dezvoltarea a ceva specific – un dispozitiv inteligent pentru
frigidere.

Dispozitivul dezvoltat este un sistem simplu și eficient, care poate fi folosit cu ușurință
în conjuncție cu orice tip de fr igider, indiferent de tipul sau vechimea acestuia. Este vorba
despre un ansamblu de senzori care măsoară temperatura, nivelul de umiditate, dacă lumina
este aprinsă sau dacă ușa frigiderului este deschisă. Dispozitivul transmite prin intermediul
internetul ui toate aceste informații la aplicația web, de unde utilizatorul le poate vedea în timp
real.

14 3.3. Aplicații similare

LG InstaView ThinQ

Frigiderele inteligente LG au în componență un display încorporat care vă permite să
comandați produse alimentare, să redați muzică și multe altele. InstaView ThinQ are un ecran
tactil mare în cadranul său din dreapta sus. De asemenea, are camere în interiorul frigiderului
care vă vor permite să vedeți ce este în interior fără a deschide frigiderul și puteți obține idei de
rețete sau puteți căuta vremea. Cea mai importantă caracteristică este că aplicația ThinQ face
posibilă ajustarea temperaturii și primirea notificărilor dacă ușa este lăsată deschisă [11].

Fig. 3.1 LG InstaView ThinQ [11]

Samsung Family Hub

Frigiderele inteligente Samsung au ajuns la a treia generație în acest an. Acestea au un
ecran tactil mare prin care puteți face o serie de lucruri: căutați rețete, scrieți notițe și trimiteți –
le telefoanelor membrilor familiei, controlați dispozitivele inteligente de acasă și creați căutări
folosind asistentul virtual Bixby, ascultați muzică și comandați produse alimentare [11].

Fig. 3.2 Samsung Family Hub [11]

15 4. Documenta ție tehnică

4.1. Componenta software

Pentru partea de implementare software a componentei practice a prezentei lucrări de
licență, am ales o aplicație de tip web, împărțită în partea client (front end) și partea ce rulează
pe server (back end). Conform [12], putem descrie aplicațiile web astfel:

Aplicațiile web se referă la aplicațiile accesate prin browser -ul web printr -o rețea și
dezvoltate folosind limbi de programare și tehnologii suportate de browser (de exemplu,
HTML, CSS, JavaScript). Pentru execuție, aplicațiile web depind de browser -ele web și includ
multe aplicații familiare, cum ar fi vânzările cu amănuntul online, licitațiile online și webmail.

Aplicațiile web sunt necesare în domeniul interacțiunii business -to-business prin
internet , de exemplu, pentru companiile care operează la nivel global, care își externalizează
proiectele. Adoptarea unei infrastructuri de aplicații web poate simplifica și îmnunătăți procese
vitale în funcționarea companiilor, precum transferul de fonduri și actualizări ale informațiilor
privind prețurile și stocur ile.

Ca și structură, o aplicație web se împarte în două componente principale: front end
(cunoscută și sub denumirea de client -side) și back end (cunoscută și sub denumirea de server
side).

Arhitectura REST

REST, sau REpresentational State Transfer, este un stil arhitectural pentru furnizarea de
standarde între sistemele de computer de pe web, facilitând comunicarea sistemelor între ele.
Sistemele compatibile REST, adesea numite sisteme RESTful, sunt caracterizate prin modul în
care a cestea sunt fără stare proprie și separă preocupările clientului și serverului. În cele ce
urmează v om analiza ce înseamnă acești termeni și de ce sunt caracteristici benefice pentru
serviciile de pe Web [13].

Separarea cli entului și serverului

În stilul arhitectural REST, implementarea clientului și implementarea serverului se pot
face independent, fără ca fiecare să știe despre celălalt. Acest lucru înseamnă că tot codul din
partea clientului poate fi schimbat în orice mo ment fără a afecta funcționarea serverului, iar
codul din partea serverului poate fi schimbat fără a afecta funcționarea clientului.

Atâta timp cât fiecare parte știe ce format al mesajelor să fie trimise celeilalte, acestea
pot fi păstrate modulare și se parate. Separarea preocupărilor interfeței de utilizator de
problemele de stocare a datelor, îmbunătățim flexibilitatea interfeței pe platforme și
îmbunătățim scalabilitatea prin simplificarea componentelor serverului. În plus, separarea
permite fiecărei c omponente capacitatea de a evolua independent.

Folosind o interfață REST, clienți diferiți ating aceleași endpoint -uri REST, execută
aceleași acțiuni și primesc aceleași răspunsuri.

16 Stare

Sistemele care urmează paradigma REST sunt lipsite de sta re, ceea ce înseamnă că
serverul nu trebuie să știe nimic despre starea în care se află clientul și invers. În acest fel, atât
serverul cât și clientul pot înțelege orice mesaj primit, chiar și fără a vedea mesaje anterioare.
Această constrângere a lipsei de stare este aplicată prin utilizarea resurselor, mai degrabă decât
prin comenzi. Resursele sunt substantivele Web -ului – ele descriu orice obiect, document sau
lucru pe care s -ar putea să aveți nevoie pentru a stoca sau a trimite la alte servicii.

Deoarec e sistemele REST interacționează prin operații standard cu resurse, nu se
bazează pe implementarea interfețelor . Aceste constrângeri ajută aplicațiile RESTful să obțină
fiabilitate, performanță rapidă și scalabilitate, componente care pot fi gestionate, ac tualizate și
reutilizate fără a afecta sistemul în ansamblu, chiar și în timpul funcționării sistemului.

Comunicarea între client și server

În arhitectura REST, clienții trimit cereri de preluare sau modificare a resurselor, iar
serverele trimit răspunsu ri la aceste solicitări. Să aruncăm o privire la modalitățile standard de
a face solicitări și de a trimite răspunsuri.

REST necesită ca un client să facă o solicitare către server pentru a prelua sau modifica
date de pe server. O solicitare constă în gen eral din:
• un verb HTTP, care definește ce fel de operație trebuie efectuată ;
• un antet, care permite clientului să transmită informații despre cerere ;
• o cale către o resursă ;
• un corp de mesaje opțional care conține date .

Verbe HTTP

Există 4 verbe HTTP de bază pe care le folosim în cereri pentru a interacționa cu
resursele dintr -un sistem REST:
• GET – preia o resursă specifică (după ID) sau o colecție de resurse ;
• POST – creează o nouă resursă ;
• PUT – actualizați o resursă specifică (după ID);
• DELETE – eliminați o resursă specifică prin ID [13].

Prin ID înțelegem caracteristica unică prin care se identifică orice resursă. Acesta poate
fi un număr, o literă, un cuvânt etc. Important este ca în cadrul aplicației să fie unică.

Front end

Componenta front end a unei aplicații reprezintă p artea unui site web cu care utilizatorul
interacționează în mod direct. Mai este denumită „partea clientului” (client -side) a aplicației.
Include tot ceea ce utilizatorii experimentează direct: culori și stiluri de text, imagini, grafice și
tabele, butoane, culori și meniu l de navigare. HTML, CSS și Javascript sunt tehnologiile
utilizate pentru dezvoltarea front end. Structura, designul, comportamentul și conținutul a tot
ceea ce se vede pe ecranul browser -ului atunci când site -urile web, aplicațiile web sau aplicațiile
mobil e sunt deschise, sunt implementate de dezvoltatorii front -end.

Sensibilitatea și performanța sunt două obiective principale ale front end-ului.
Dezvoltatorul trebuie să se asigure că site -ul este receptiv, adică apare corect pe dispozitive de

17 toate dimens iunile, nicio parte a site -ului nu trebuie să se comporte anormal indiferent de
dimensiunea ecranului. , fie că accesăm site -ul web pe desktop, telefon sau tabletă.

La baza dezvoltării front end stau trei tehnologii consacrate în industrie:

HTML – înseamn ă Hyper Text Markup Language. Este utilizat pentru a proiecta
porțiunea frontală a paginilor web folosind un limbaj de marcare. HTML este combinația dintre
limbajul hipertext și marcaj. Hipertextul definește legătura dintre paginile web. Limbajul de
marcar e este utilizat pentru a defini documentația text în cadrul fiecărei etichete componente,
care definește structura paginilor web.

CSS: Cascading Style Sheets , denumit simplu CSS este un limbaj conceput simplu,
menit să simplifice procesul de prezentare a paginilor web. CSS permite să aplicarea de stiluri
pe paginile web. Mai important, CSS permite ca acest lucru să fie complet independent de
HTML -ul care formează fiecare pagină web.

JavaScript : Acesta este un limbaj faimos de scripting, folosit pentru a c rea magia prin
care un site web static și plictisotor devine dinamic și interactiv. Este utilizat pentru a îmbunătăți
funcționalitatea unui site web pentru a rula jocuri și software bazat pe web [14].

Back end

Componenta back -end este partea care rulează pe serverul site -ului web. Stochează și
aranjează date și, de asemenea, se asigură că totul din partea clientului site -ului web
funcționează bine. Este partea site -ului web pe care nu o poți vedea sau interacțio na cu aceasta .
Este partea software care nu intră în contact direct cu utilizatorii. Componentele și
caracteristicile dezvoltate de dezvoltatorii back end sunt accesate indirect de utilizatori printr –
o aplicație front -end. Activități, cum ar fi scrierea AP I-urilor (Application Programming
Interface ), crearea bibliotecilor și lucrul cu componentele sistemului fără interfețe de utilizator
sau chiar sisteme de programare științifică, sunt de asemenea incluse în back end.

Față de front end , unde lucrurile sunt destul de simple, pe partea de back end găsim o
sumedie de limbaje de programare, fiecare cu avantaje si dezavantaje. Dintre acestea le amintim
pe următoarele:

PHP : este un limbaj de scripting pentru serverul, conceput special pentru dezvoltarea
web. Acesta este un instrument puternic pentru crearea de pagini web dinamice și interactive .

C#: este un limbaj de programare cu scop general, multi -paradigmă, care cuprinde
programare cu scop lexic, imperativ, declarativ, funcțional, generi c, și orientată pe obiect e. A
fost dezvoltat în jurul anului 2000 de Microsoft ca parte a inițiativei sale .NET și ulterior aprobat
ca standard internațional.

Java : este unul dintre cele mai populare și utilizate pe scară largă limbaj e de
programare . Este foarte ușor de scala t. Componentele Java sunt ușor disponibile.

Node.js : este un mediu de rulare de tip open -source și și disponibil pentru platforme
multipl e, folosit pentru executarea codului JavaScript în afara unui browser. Trebuie aminti t că
Node .js nu este un limbaj de programare. Majoritatea oamenilor sunt confuzi și înțeleg că este
un limbaj de programare. De multe ori folosim Node.js pentru a construi servicii de tip back –
end, cum ar fi API -uri, aplicații web sau aplicații mobile . Este utilizat î n producție de companii
mari precum Paypal, Uber, Netflix, Wallmart și altele [14].

18 4.1.1. Tehnologii folosite

Angular

Angular este o platformă și un framework pentru construirea aplicațiilor front end cu o
singură pagină utilizând HTML și TypeScript. TypeScript este un limbaj de programare open
source dezvoltat și menținut de Microsoft. Este un superset sintactic al limbajului JavaScript și
asigură un sistem de tipuri opțional. Angular i mplementează funcționalități de bază și opționale
ca un set de biblioteci TypeScript care pot fi importate în aplicații.

Arhitectura unei aplicații Angular se bazează pe anumite concepte fundamentale.
Blocurile de bază sunt NgMo dules, care oferă un context de compilare pentru componente.
NgModules colectează codul aferent în seturi funcționale; o aplicație Angular este definită de
un set de NgModule. O aplicație are întotdeauna cel puțin un modul rădăcină care permite
bootstrappi ng-ul (proces ul de încărcare a software -ului de bază în memoria unui computer ) și,
de obicei, are multe alte funcții.

Componentele definesc vizualizările, care sunt seturi de elemente de ecran pe care
Angular le poate alege și modifica în funcție de logica și datele programului. Componentele
folosesc servicii, care oferă funcționalități specifice care nu sunt legate direct de vizualizări.
Furnizorii de servicii pot fi injectați în componente ca dependențe, ceea ce determină codul să
fie modular, reuti lizabil și eficient.

Atât componentele, cât și serviciile sunt pur și simplu clase, cu decoratori care
marchează tipul lor și oferă metadate care informează Angular cum să le folosească. Metadata
pentru o clasă de componente o asociază cu un șablon care d efinește o vizualizare. Un șablon
combină HTML -ul obișnuit cu directivele Angular și marcarea obligatorie care permite Angular
să modifice HTML înainte de a -l afișa . De asemenea, m etadatele pentru o clasă de servicii
furnizează informațiile de care are nev oie Angular pentru a le pune la dispoziția componentelor
prin injecția de dependență (DI) [15].

.NET Core

.NET Core este o platformă de dezvoltare open -source, cu scop general. Cu ajutorul
acesteia pot fi create aplicații .NET Core pentru Windows, macOS și Linux pentru procesoare
x64, x86, ARM32 și ARM64 folosind mai multe limbaje de programare. Principalul limbaj de
programare folosit pentru .NET Core este C#, descris în subcapi tolul anterior [16].

.NET Core este format din următoarele componente :

• .NET Core runtime, care oferă un sistem de tip, încărcarea de asamblare, un colector de
gunoi și alte servicii de bază. Bibliotecile din cadrul .NET C ore oferă tipuri de date
primitive, tipuri de compoziție de aplicații și utilități fundamentale;
• ASP.NET Core runtime, care oferă un cadru pentru crearea de aplicații moderne, bazate pe
cloud, conectate la internet, precum aplicații web, aplicații IoT și b ack end -uri mobile;
• .NET Core SDK și compilatoare de limbaje precum Roslyn și F # , care permit
programatorilor să dezvolte aplicații în .NET Core;
• Comanda dotnet , care este utilizată pentru a lansa aplicații .NET Core și comenzi CLI.
Selectează și găzduieș te timpul de rulare, furnizează o politică de încărcare a ansamblului
și lansează aplicații și instrumente [17].

19 Pentru dezvoltarea de aplicații web, cum este cazul prezentului proiect, folosim
framework -ul ASP.NET Core. Ac esta este conceput pentru a permite evoluția rapidă a
componentelor, a API -urilor, a compilatoarelor și a limbajelor, în timp ce oferă o platformă
stabilă și universal acceptată pentru a menține funcționarea aplicațiilor.

Mai multe versiuni de ASP.NET Cor e pot exista în același timp pe același server. În
sensul că o aplicație poate adopta cea mai recentă versiune, în timp ce alte aplicații continuă să
ruleze pe versiunea în care au fost testate. Aplicațiile ASP.NET Core pot fi dezvoltate și rulate
pe macOS , Windows, Linux și Docker [18].

Deși există pe piață o sumedenie de tehnologii ce pot fi folosite pentru componenta back
end a aplicației, în urma unei analize amănunțite am concluzionat că ASP.NET Core este cea
mai bună variantă. Milioane de dezvoltatori folosesc sau au folosit ASP.NET Core pentru a -și
dezvolta aplicațiile, întrucât acesta oferă următoarele avantaje:
• un cadru unificat pentru construirea componentelor UI și a API -urilor web;
• arhitectură orientată către testabilitate ;
• posibilitatea de a dezvolta și rula pe Windows, macOS și Linux ;
• open -source și orientat către comunitate ;
• integrarea cadrelor moderne, a clienților și a fluxurilor de lucru pentru dezvoltare ;
• un sistem de configurare bazat pe mediul înconjurător ;
• dependecy injection (i njecție de dependență ) încorporat [19].

Entity Framework Core

Maparea relațional ă de obiecte ( object -relational mapping) în știința calculatoarelor este
o tehnică de programare pentru convertirea datelor între sisteme incompatibile folosind limbaje
de programare orientate pe obiecte. Aceasta creează, de fapt, o „bază de date de obiecte
virtuale” care poate fi folosită din limbajul de programare , creând astfel o legătură între datele
brute stocate în baza de date și modelele (clasele) existe în aplicație [20].

Entity Framework Core este un cadru ORM open -source pentru aplicațiile .NET
acceptate de Microsoft. Permite dezvoltatorilor să lucreze cu date folosind obiecte din clase
specifice domeniului, fără a se concentra pe tabelele și coloanele bazei de date unde sunt stocate
aceste date. Cu Entity Framework Core , dezvoltatorii pot lucra la un nivel mai înalt de
abstractizare atunci când se ocupă de date și pot crea și menține aplicații orientate către date cu
mai puțin cod în comparație cu aplicațiile tradiționale [21].

Fig. 4.1. Aplicabilitatea Entity Framework Core [21]

20 După cum se poate observa în figura de mai sus , Entity Framework Core s e încadrează
între entitățile de business (clase le de domeniu) și baza de date. Salvează datele stocate în
modelele de date din aplicație și, de asemenea, preia date din baza de date și le transformă
automat în obiecte .

Am ales folosirea acestui framework întrucât simplifică foarte mult lucrul cu baza de date
și scutește foarte mult timp. Printre capabilitățile Entity Framework Core amintim:
• cross -platform: Entity Framework Core este un framework disponibil pe mai multe
platforme, care poate fi rulat pe Wi ndows, Linux și Mac;
• modelare: Entity Framework (Entity Framework) Core creează un model de date bazat pe
entități) cu proprietăți get / set pentru diferite tipuri de date. Acesta folosește acest model
pentru a interoga sau pentru a salva datele entității în baza de date;
• interogare: Entity Framework ne permite să utilizăm interogări LINQ ( Language Integrated
Query ) pentru a prelua date din baza de date. Furnizorul de baze de date va traduce aceste
interogări LINQ în limbajul de interogare specific bazei de date (de ex. SQL pentru o bază
de date relațională). Entity Framework Core ne permite, de asemenea, să executăm
interogări SQL brute direct în baza de date;
• urmărirea modificărilor: Entity Framework Core ține evidența modificărilor apărute la
instanțele e ntităților (valorile proprietății) care trebuie trimise la baza de date;
• salvare: Entity Framework Core execută comenzi INSERT, UPDATE și DELETE în baza
de date pe baza modificărilor apărute la entități, atunci când se apelează metoda
SaveChanges() . Entity Framework Core oferă de asemenea metoda SaveChangesAsync()
asincronă;
• concurență: Entity Framework Core utilizează în mod implicit Optimistic Concurrency
pentru a proteja modificările de suprascriere efectuate de un alt utilizator față de momentul
când da tele au fost preluate din baza de date;
• tranzacții: Entity Framework Core efectuează gestionarea automată a tranzacțiilor în timp
ce interoghează sau salvează date. De asemenea, oferă opțiuni pentru a personaliza
gestionarea tranzacțiilor;
• cache: Entity Fr amework Core include primul nivel de memorie în cache încorporat. Deci,
interogarea repetată va returna datele din memoria cache în loc să suprasolicite baza de date;
• convenții încorporate: Entity Framework Core respectă convențiile pentru modelul de
progr amare a configurației și include un set de reguli implicite care configurează automat
modelul Entity Framework;
• configurații: Entity Framework Core ne permite să configuram modelul Entity Framework
folosind atribute de adnotare a datelor sau API -ul FluentA PI pentru a suprascrie convențiile
implicite;
• migrații: Entity Framework Core oferă un set de comenzi de migrare care pot fi executate
din NuGet Package Manager Console sau pe interfața liniei de comandă pentru a crea sau
gestiona schema bazei de date subi acente [21].

Transact -SQL

SQL – Structured Query Language, înseamnă limbaj de interogare structurat. SQL este
utilizat pentru a comunica cu o bază de date. Conform ANSI (American National Standards
Institute), este limbajul standard pentru sistemele relaționale de gestionare a bazelor de date.
Instrucțiunile SQL sunt utilizate pentru a efectua sarcini precum actualizarea datelor dintr -o
bază de date sau pentru a prelua date dintr -o bază de date. Unele sisteme comune de gestionare
a bazelor de date relaționale care folosesc SQL sunt: Oracle, Sybase, Microsoft SQL Server,
Access, Ingres etc.

21 Standardul SQL a trecut printr -o serie de schimbări de -a lungul anilor, care au adăugat
o mulțime de noi funcționalități standardului, precum suport pentru XML, declanșatoare,
compatibilitatea cu expresiile regulate , interogăr i recursive, secvențe standardizate și multe
altele.

Limbajul SQL se bazează pe mai multe elemente. Pentru comoditatea dezvoltatorilor
SQL, toate comenzile de limbă necesare în sistemele de gestionare a bazelor de date
corespunzătoare sunt de obicei execu tate printr -o interfață de linie de comandă SQL (CLI).
Aceste comenzi pot fi grupate în următoarele zone:
• Clauze – clauzele sunt componente ale enunțurilor și întrebărilor;
• Expresii – expresiile pot produce valori scalare sau tabele, care constau din coloa ne și
rânduri de date;
• Predicate – ele specifică condiții, care sunt utilizate pentru a limita efectele
instrucțiunilor și întrebărilor sau pentru a schimba fluxul de program;
• Interogări – o interogare preia datele, pe baza unui criteriu dat;
• Declarații – utilizând declarații utilizatorul poate controla tranzacțiile, fluxul de
programe, conexiunile, sesiunile sau diagnosticul. În sistemele de baze de date
instrucțiunile SQL sunt utilizate pentru trimiterea de întrebări de la un program client l a
un server unde sunt stocate bazele de date. Ca răspuns, serverul procesează
instrucțiunile SQL și revine la programul client. Acest lucru permite utilizatorilor să
execute o gamă largă de operații rapide de manipulare a datelor de la intrări simple de
date la interogări mai complexe [22].

T-SQL (Transact -SQL) este un set de extensii de programare de la Sybase și Microsoft
care adaugă mai multe caracteristici la limbajul structurat de interogare (SQL), inclusiv
controlul tr anzacțiilor, excepția și tratarea erorilor, procesarea rândurilor și variabilele
declarate.

Toate aplicațiile care comunică cu SQL Server o fac trimițând declarații T -SQL către
server. Întrebările T -SQL includ instrucțiunea SELECT, selectarea coloanelor, etichetarea
coloanelor de ieșire, restricționarea rândurilor și modificarea unei condiții de căutare.

Identificatorii T -SQL, între timp, sunt folosiți în toate bazele de date, servere și obiecte
ale bazei de date din SQL Server. Acestea includ următoarele tabele, constrângeri, proceduri
stocate, vizualizări, coloane și tipuri de date. Identificatorii T -SQL trebuie să aibă fiecare un
nume unic, sunt alocați atunci când un obiect este creat și sunt folosiți pentru a identifica un
obiect.

Există trei diferen țe principale între SQL și T -SQL:
1. În timp ce T -SQL este o extensie la SQL, SQL este un limbaj de programare;
2. T-SQL conține programare procedurală și variabilă locală, în timp ce SQL nu;
3. T-SQL este proprietar (deținut de Microsoft), în timp ce SQL este open -source [23].

SQL Server

Microsoft SQL Server este un sistem relațional de gestionare a bazelor de date dezvoltat
de Microsoft. Ca server de baze de date, este un produs software cu funcția principală de stocare
și preluar e a datelor, așa cum este solicitat de alte aplicații software – care pot rula fie pe același
computer sau pe un alt computer de pe o rețea (inclusiv pe Internet). Microsoft comercializează
cel puțin o duzină de ediții diferite de Microsoft SQL Server, des tinate unor audiențe diferite și
pentru sarcini de lucru, de la mici aplicații cu o singură mașină până la aplicații mari care se
desfășoară pe Internet, cu mulți utilizatori concomitenți.

22 Microsoft SQL Server permite, de asemenea, să fie definite și utili zate tipuri de
compozite (UDT) definite de utilizator. De asemenea, face ca statisticile serverului să fie
disponibile sub formă de tabele și vizualizări virtuale (numite Dynamic Management Views
sau DMVs). Pe lângă tabele, o bază de date poate conține și alte obiecte, inclusiv vizualizări,
proceduri stocate, indexuri și constrângeri, împreună cu un jurnal de tranzacții. O bază de date
SQL Server poate conține maximum 231 de obiecte și poate cuprinde mai multe fișiere la nivel
de sistem de operare cu o dime nsiune maximă de fișier de 260 de octeți (1 exabyte).

Datele din baza de date sunt stocate în fișiere de date primare cu o extensie .mdf.
Fișierele de date secundare, identificate cu o extensie .ndf, sunt utilizate pentru a permite
răspândirea datelor dintr -o singură bază de date pe mai multe fișiere și, opțional, pe mai multe
sisteme de fișiere. Fișierele jurnal sunt identificate cu extensia .ldf.

Pentru stocarea fizică a unei tabele, rândurile acesteia sunt împărțite într -o serie de
partiții (numerotate de la 1 la n). Dimensiunea partiției este definită de utilizator; implicit, toate
rândurile sunt într -o singură partiție. Un tabel este împărțit în mai multe partiții pentru a
răspândi o bază de date într -un cluster. Rândurile din fiec are partiție sunt stocate fie în tr-un
arbore de tip B, fie în tr-o structur ă de tip heap. Dacă tabelul are un indice asociat, grupat pentru
a permite recuperarea rapidă a rândurilor, rândurile sunt stocate în ordine în funcție de valorile
lor de index, un a rbore de tip B furnizând indexul.

Datele se află în nodul frunzelor arborelui , iar alte noduri stochează valorile indexului
pentru datele frunzelor accesibile din nodurile respective. Dacă indexul nu este grupat, rândurile
nu sunt sortate în funcție de t astele indexului. O vizualizare indexată are aceeași structură de
stocare ca o tabelă indexată. Un tabel fără un indice grupat este stocat într -o structură de
comandă neordonată. Cu toate acestea, tabelul poate avea indici neaglomerați pentru a permite
recuperarea rapidă a rândurilor. În unele situații, structura de montaj are avantaje de
performanță față de structura grupată. Atât structurile de tip heap , cât și arborii de tip B pot
cuprinde mai multe unități de alocare [24].

Git

O componentă a managementului configurației software, controlului versiunilor
(version control ), cunoscută și sub denumirea de control de revizuire sau control sursă, este
gestionarea modificărilor la documente, programe de calculator, site -uri web mari și alte
colecții de informații. Modificările sunt de obicei identificate printr -un număr sau cod de literă,
denumite „număr de revizuire”, „nivel de revizuire” sau pur și simplu „revizuire”. De exemplu,
un set inițial de fișiere este „revizuirea 1”. Când se face prima modificare, setul rezultat este
„revizuirea 2” și așa mai departe. Fiecare revizuire este asociată cu o oră de timp și persoana
care efectuează schimbarea. Revizuirile pot fi comparate, restaurate și cu unele tipuri de fișiere,
combinate .

De departe cel mai utilizat sistem de control al versiunilor moderne din lume este Git.
Git este un proiect open -source matur, menținut activ, dezvoltat inițial în 2005 de Linus
Torvalds, celebrul creator al kernel -ului sistemului de operare Linux. Un n umăr uluitor de
proiecte software se bazează pe Git pentru controlul versiunilor, inclusiv proiecte comerciale,
precum și open source. Dezvoltatorii care au lucrat cu Git sunt bine reprezentați în grupul de
talente de dezvoltare software disponibile și fun cționează bine pe o gamă largă de sisteme de
operare și IDE (Integrated Development Environments).

Având o arhitectură distribuită, Git este un exemplu de DVCS (sistemul de control al
versiunilor distribuite). În loc să dispui de un singur loc pentru isto ria versiunilor complete a

23 software -ului, așa cum este obișnuit în sistemele de control al versiunilor populare, cum ar fi
CVS sau Subversion (cunoscut și sub numele de SVN), în Git, fiecare copie de lucru a
dezvoltatorului este de asemenea un depozit. car e poate conține istoricul complet al tuturor
modificărilor. Pe lângă distribuirea sa, Git a fost proiectat având în vedere performanță,
securitate și flexibilitate [25].

Cu toate că există multe sisteme de control al mersiu nilor, Git este cea mai bună alegere
pentru majoritatea echipelor software de astăzi. Deși fiecare echipă este diferită și ar trebui să
facă propria analiză, iată principalele motive pentru care controlul versiunilor cu Git este
preferat față de alternativ e:
• Git are funcționalitatea, performanța, securitatea și flexibilitatea de care au nevoie
majoritatea echipelor și dezvoltatorilor individuali. Aceste atribute ale lui Git sunt
detaliate mai sus. În comparație cot la cot cu majoritatea celorlalte alternati ve, multe
echipe consideră că Git este foarte favorabil;
• Git este cel mai adoptat instrument de acest gen. Acest lucru face ca Git să fie atractiv
din următoarele motive. La Atlassian, aproape tot codul sursă al proiectului nostru este
gestionat în Git;
• Numărul mare de dezvoltatori au deja experiență Git și o proporție semnificativă de
absolvenți de facultate poate avea experiență doar cu Git. În timp ce unele organizații
pot avea nevoie să urce pe curba de învățare atunci când migrează către Git dintr -un alt
sistem de control al versiunilor, mulți dintre dezvoltatorii lor existenți și viitori nu
trebuie să fie instruiți pe Git;
• Git este un proiect open source foarte bine susținut, cu peste un deceniu de administrare
solidă. Responsabilii proiectului au arăt at o judecată echilibrată și o abordare matură
pentru a răspunde nevoilor pe termen lung ale utilizatorilor săi, cu versiuni periodice
care îmbunătățesc capacitatea de utilizare și funcționalitate. Calitatea software -ului
open source este ușor verificată ș i nenumărate companii se bazează foarte mult pe
această calitate [26].

Azure

Azure este o platformă profesională de servicii în cloud , oferită de Microsoft. Datorită
funcționalităților avansate, prin aceasta se pot porni mașini virtuale, baze de date SQL, se pot
crea crea copii de rezervă pentru resursele existente și multe altele, fără a exista teama de
defecțiuni sau de învechirea echipamentelor și a programelor informatice [27]. Din cadrul
acestei suite de servicii am folosit următoarele:

Azure DevOps – este o platformă software ca serviciu (SaaS) de la Microsoft care
furnizează o serie de instrumente DevOps end -to-end pentru dezvoltarea și implementarea
software -ului. De asemenea, se integrează cu majoritatea instrumentelor de pe piață ș i este o
opțiune excelentă pentru orchestrarea unei serii de servicii de tip DevOps.

Azure DevOps cuprinde o serie de servicii care acoperă întregul ciclu de viață al
dezvoltării. La momentul scrierei acestei lucrări acestea sunt:

• Panouri Azure: instrum ent de planificare Agile, urmărirea task -urilor, vizualizare și
raportare;
• Azure Pipelines: un serviciu cloud care poate fi utiliza t pentru a construi și testa automat
proiectul de cod și pentru a -l pune la dispoziția altor utilizatori. Funcționează cu apr oape
orice limb aj de programare sau tip de proiect [28];
• Azure Repos: furnizează depozite private de Git găzduite pe cloud;

24 • Azure Artifacts: oferă gestionarea integrată a pachetelor cu suport pentru pachete
Maven, npm, Pytho n și NuGet din surse publice sau private;
• Planuri de testare Azure: oferă o soluție de testare integrată planificată și exploratorie.

Azure DevOps poate fi, de asemenea, utilizat pentru a orchestra instrumente terțe [29].

Azure Portal – Microsoft Azure, deține a doua cea mai mare cotă de piață în domeniul
Cloud Computing, după Amazon Web Services. Meritul pentru acest succes merge și la ușurința
cu care Microsoft Azure poate fi accesat pentru a efectua operațiuni în cloud. Portalul Azure
(Azure Portal) , după cum sugerează și numele, este un singur portal sau o singură intersecție
care permite accesarea și gestionarea tuturor aplicațiil or într-un singur loc. Permite construi rea,
gestiona rea și să monitor izarea a tot, de la ap licații web simple la aplicații cloud complexe într –
o singură consolă unificată [30].

Mai jos sunt câteva dintre caracteristicile funcționalităților oferite de Azure Portal:
• Un punct unic de management – este un hub unic care permite accesa rea de servicii
precum Cloud Computing , bază de date, stocare, aplicații web, mașini virtuale etc. De
asemenea, utilizarea Portalului Azure asigură o flexibilitate ridicată când vine vorba de
explorarea funcțiilor grafice ale Azure;
• Experiență personalizată – administrarea aplicațiilor se potrivește stilului de lucru al
utilizatorului, fiind un lucru excelent pentru orice individ sau afacere. Portalul Azure
oferă Panouri de bord care permit fixarea aplicațiilor necesare pentru a putea fi
monitorizate și accesate oricând. Această caracteristică asigură satisfacerea și
gestionarea corectă a nevoilor;
• Securitate – securitatea este o prioritate de top atunci când vine vorba de Cloud
Computing. Portalul Azure contribuie la această cauză asigurând un control complet
asupra celor care accesează serviciile. Acest lucru se realizează prin acordarea de
controale de acces pe bază de rol și abonament la nivel individual și de grup ;
• Amalgamarea serviciilor pentru experiență puternică – Microsoft Azure oferă mii de
servicii atât open source, cât și cele care aparțin suitei software Microsoft. Acum, Azure
facilitează integrarea cu toate aceste servicii, care se pot combina pentru a produce un
efect unificat deosebit ;
• Mai multă vizibilitate – una dintre c ele mai bune caracteristici ale Microsoft Azure este
că permite urmărirea atât costuril or actuale cât și viitoare [30].

25 4.1.2. Arhitectura software

Fig. 4.2 Arhitectura aplicației

Evoluția tehnologiilor a schimbat modul în care construim arhitectura aplicațiilor.
Serviciile de tip Docker, Cloud și orchestrare de container e ne-au adus capacitatea de a dezvolta
soluții distribuite, mai scalabile și mai fiabile [31]. Prinzâ nd foarte mult teren în ultimii ani,
microserviciile sunt o tendință accelerată în zile le noastre . Într -adevăr, abordarea bazată pe
microservicii oferă beneficii tangibile, inclusiv o creștere a scalabilității, fle xibilitate, agilitate
și alte avantaje semnificative. Netflix, Google, Amazon și alți lideri tehnologici au trecut cu
succes de la arhitectura monolitică la microservicii. Între timp, multe companii consideră
urmarea acest ui trend ca fiind cel mai eficient mod de creștere a afacerilor.

26 Arhitectura monolit

Fig. 4.3 Arhitectura monolit [32]

Pe de altă parte , abordarea monolitică este un model implicit pentru crearea unei
aplicații software. Totuși, tendința sa se reduc e, deoarece construirea unei aplicații monolitice
prezintă o serie de provocări asociate cu gestionarea unei baze de cod imense, adoptarea de noi
tehnologii, scalarea, implementarea, introducerea de noi modificări și altele.

Arhitectura monolitică este co nsiderată un mod tradițional de construire a aplicațiilor.
O aplicație monolitică este construită ca o unitate unică și indivizibilă. De obicei, o astfel de
soluție cuprinde o interfață de utilizator din partea clientului, o aplicație a serverului și o baz ă
de date. Este unificat și toate funcțiile sunt gestionate și servite într -un singur loc. În mod
normal, aplicațiile monolitice au o bază de cod mare și nu au modularitate. Dacă dezvoltatorii
doresc să actualizeze sau să schimbe ceva, ei accesează aceeași bază de cod. Deci, fac schimbări
în întregul ansamblu simultan.

Caracteristici ale arhitecturii monolit:
• rezolvare de bug -uri și testare mai ușoară – spre deosebire de arhitectura pe
microservicii, aplicațiile monolitice sunt mult mai ușor de depanat și testat. Întrucât o
aplicație monolitică este o singură unitate indivizibilă, se poate rula testarea end -to-end
mult mai rapid;
• simplu de implementat – un alt avantaj asociat cu simplitatea aplicațiilor monolitice este
implementarea mai ușoară. Când vine v orba de aplicații monolitice, nu trebuie
gestionate multe implementări – doar un fișier sau director;
• simplu de dezvoltat – atât timp cât abordarea monolitică este un mod standard de
construire a aplicațiilor, orice echipă de inginerie are cunoștințele și capacitățile
potrivite pentru a dezvolta o aplicație monolitică;
• înțelegere – când o aplicație monolitică se mărește, devine prea complicat de înțeles. De
asemenea, un sistem complex de coduri dintr -o singură aplicație este greu de gestionat;
• modificări – este mai greu să implementați modificări într -o aplicație atât de mare și
complexă, cu cuplaj foarte strâns. Orice schimbare de cod afectează întregul sistem,
astfel încât acesta trebuie să fie coordonat minuțios. Acest lucru face ca procesul de
dezvoltare generală să fie mult mai lung;
• scalabilitate – nu se pot scala componentele în mod independent, doar întreaga aplicație.;

27 • bariere tehnologice noi – este extrem de problematic să aplici o nouă tehnologie într -o
aplicație monolitică, deoarece atunci întreaga aplicație trebuie rescrisă [32].

Arhitectura bazată pe microservicii

Fig. 4.4 Arhitectura pe microservi cii [32]

În timp ce o aplicație monolitică este o singură unitate unificată, o arhitectură pe
microservicii descompun e aplicația într-o colecție de unități independente mai mici. Aceste
unități efectuează fiecare proces solicita t ca un serviciu separat. Deci toate s erviciile au propria
logică și baza de date și îndeplinesc funcțiile specifice.

Într-o arhitectură pe microservicii, întreaga funcționalitate este împărțită în module care
pot fi implementate independent, care comunică între ele prin metode definite numi te API
(interf ețe de programare a aplicațiilor). Fiecare serviciu acoperă propriul său domeniu de
aplicare și poate fi actualizat, implementat și scalat independent.

Caracteristici ale arhitecturii bazate pe microservicii:
• componente independente – în pri mul rând, toate serviciile pot fi implementate și
actualizate independent, ceea ce conferă o mai mare flexibilitate. În al doilea rând, o
eroare dintr -un microserviciu are un impact doar asupra unui anumit serviciu și nu
influențează întreaga aplicație. De asemenea, este mult mai ușor de adăugat funcții noi
la o aplicație pe microservicii decât la una monolitică;
• înțelegere mai ușoară – fiind împărțită în componente mai mici și mai simple, o aplicație
pe microservicii este mai ușor de înțeles și de gestiona t;
• o scalabilitate mai bună – un alt avantaj al abordării pe microservicii este că fiecare
element poate fi scalat independent. Deci, întregul proces este mai eficient din punct de
vedere al costurilor și al timpului decât în cazul monolitelor atunci câ nd întreaga
aplicație trebuie să fie scalată chiar dacă nu este nevoie de ea. În plus, fiecare aplicție
monolit are limite în ceea ce privește scalabilitatea, deci cu cât apar mai mulți utilizatori,
cu atât apar și mai multe probleme cu monolitul. Prin urm are, multe companii ajung să –
și reconstruiască arhitecturile monolitice;
• flexibilitate în alegerea tehnologiei. Echipele de inginerie nu sunt limitate de tehnologia
aleasă de la început. Sunt liberi să aplice diverse tehnologii și cadre pentru fiecare
microserviciu;

28 • nivelul mai ridicat de agilitate – orice defecțiune dintr -o aplicație pe microservicii
afectează doar un anumit serviciu și nu întreaga soluție. Deci toate modificările și
experimentele sunt puse în aplicare cu riscuri mai mici și cu mai puține erori;
• un plus de complexitate – întrucât o arhitectură pe microservicii este un sistem distribuit,
trebuie alese și configurate conexiunile dintre toate modulele și bazele de date. De
asemenea, atât timp cât o astfel de aplicație include servicii independ ente, toate trebuie
să fie implementate independent;
• distribuția sistemului – arhitectura pe microservicii este un sistem complex de multiple
module și baze de date, astfel încât toate conexiunile trebuie gestionate cu atenție;
• testare – o multitudine de c omponente care pot fi implementate independent fac mult
mai dificilă testarea unei soluții bazate pe microservicii [32].

Pentru o cât mai bună aliniere cu standardele actuale, dar având în vedere și avantajele
și dezavantajele fiecărei abordări, implementarea aplicației s -a făcut utilizând arhitectura bazată
pe microservicii.

4.1.3. Front end

Pentru partea de frontend a aplicației am folosit Angular. Ca prim pas pentru începutul
proiectului în Angular am creat arhitectura proiectului. În primul rând, am executat comanda
ng new <Frontend_IoT> și după aceea am ales versiunea de Angular. Un alt lucru important
în crearea arhitecturii este alegerea SCSS ca limbaj de styling implicit în componente. În al
doilea rând, am creat un modul de distribuire pentru cele mai utilizate componente pentru
eficiență și structură.

În figura următoare se pot vedea componentele exacte din m odulul partajat: Layout,
Alert, Progress Spinner:

Fig. 4.5 Module Angular

29 În plus , am creat modulele de care aveam nevoie în proiectul meu. În Figura 4.6 se pot
vedea modulul numit authentication care are 5 componente pentru înregistrare, autentificare,
eroare, parola uitată și resetare parolă.

Fig. 4.6 Modul autentificare

Celelalte două module sunt cele pentru clădiri și dispozitive. În figurile 4 .7 și 4.8 se
poate vedea că modulul clădirilor este împărțit în clădiri – tablou de bord și clădiri – detalii și,
de asemenea, modulul dispozitive are o componentă numită detalii dispozitiv.

Fig. 4.7 Modul clădiri

30
Fig. 4.8 Modul dispozitive

Pentru o mai bună înțelegere a componentei front end și cum funcționează aceasta în
relația cu utilizatorul, în cele ce urmează voi prezenta câteva capturi de ecran cu aplicația.

Pagina de autentificare

Utilizatorul trebuie să introducă datele de autentificare în câmpurile de utilizator și
parolă, iar după ce apasă butonul LOGIN este conectat la platformă.

Fig. 4.9 Pagina de autentificare

Panou de vizualizare al clădirilor

După ce s -a autentificat cu succes, prima pagină afișată utilizatorului este cea cu toate
clădirile pe care acesta le are arondate.

31
Fig. 4.10 Pagina de vizualizare a clădirilor

Utilizatorul poată face clic pe oricare dintre chenarele care conțin o clădire a tabloului
de bord pentru a vedea frigiderele din interiorul clădirii respectiv e. Când face clic pe oricare
dintre acestea, utilizatorul este redirecționat către tabloul de bord al frigiderelor din clădirea
respectivă.

De asemenea, fiecare chenar conține următoarele informații despre clădiri:
• numele clădirii;
• adresa clădirii;
• numărul de frigidere;
• starea generală (cu valorile OK, ATENȚIE, EROARE).

32 Panou de vizualizare a frigiderelor dintr -o clădire

După ce a selectat o clădire din panoul de vizualizare, utilizatorul este redirecționat
către o pagină asemăn ătoare cu cea precedentă, diferența fiind că în aceasta chenarele conțin
informații despre frigiderele din clădire.

Fig. 4.11 Pagina de vizualizare a frigiderelor

Fiecare chenar conține următoarele informații despre frigider:
• numele frigiderului;
• temperatura;
• nivelul de umiditate;
• starea de lumină;
• starea ușii.

Pagina cu detalii despre un anumit frigider

Dacă u tilizatorul dorește să vadă câteva detalii despre frigider, astfel încât să poată
avea o imagine de ansamblu , acesta poate f ace clic pe oricare dintre chenare și va fi
redirecționat către pagina din Figura 4.12 . Utilizatorul poate derula în jos pentru a vedea mai
multe detalii despre frigider și poate vedea grafice pentru temperatură, umiditate și, de
asemenea, lumină.

33
Fig. 4 .12 Pagina cu detalii despre frigider

Pagina pentru lipsă frigidere

În cazul în care nu există niciun frigider într -o anumită clădire, utilizatorul este
redirecționat către următoarea pagină:

Fig. 4.13 Pagină lipsă frigidere

34 4.1.4. Back end

Pe partea de back end a aplicației, avem trei microservicii, cu roluri bine definite, astfel
încât să fie respectate principiile arhitecturii bazate pe microservicii. Acestea au fost alese în
așa manieră încât să satisfacă nevoile principale ale aplicației , să respecte principiul de
modularitate și să permită o scalabilitate cât mai eficientă a aplicației, indiferent de numărul de
utilizatori concomitenți.

Întrucât deși avem trei microservicii diferite, care primesc date diferite, la adrese total
diferite , avem o singură aplicație, iar aceasta trebuie să aibă un punct unic de intrare, care va fi
accesat de front end -ul aplicației. Cum am prezentat anterior, una dintre filozofiile principale
ale stilului arhitectural REST este faptul că front end -ul și back end-ul sunt tratate ca două
componente complet separate. Astfel, front end -ul nu are cunoștință de detaliile de
implementare din zona serverului și implicit nu știe detaliile implementării arhitecturii bazate
pe microservicii.

Pentru a rezolva această p roblemă, avem nevoie de un microserviciu separat, al cărui
unic scop este preluarea fiecărei cereri efectuate de client și rutarea acesteia către microserviciul
care se ocupă cu acel tip de cerere. După ce serverul a procesat cererea și a oferit un răspuns
către aceasta, răspunsul respectiv este preluat și direcționat înapoi către clientul care a făcut
cererea. În termeni de specialitate, un serviciu care implementează un astfel de principiu poartă
denumirea de gateway .

În cele ce urmează vom elabora o pr ezentare detaliată asupra fiecărui microserviciu în
parte. Pentru a păstra lucrurile cât mai concise și organizate, ne vom concentra pe informațiile
de intrare și cele de ieșire, analizând scopul fiecărui endpoint, modul în care prelucrează datele
și comun icarea cu baza de date.

Users service

După cum spune și numele, acest microserviciu se concentrează pe interacțiunea dintre
utilizatori și aplicație, fiind responsabil atât pentru autentificarea și autorizarea utilizatorilor,
câr și pentru tot ce înseam nă administrarea acestora.

La nivelul superior al serviciul avem la bază trei controllere, împărțite astfel:

1. Account controller

Acesta este responsabil de una dintre cele mai importante funcționalități ale aplicației
și anume autentificarea utilizatori lor. Fiind o aplicație web, este nevoie de un nivel de siguranță
cât mai ridicat, întrucât acestea reprezintă ținta preferată a hackerilor. Aplicația fiind disponibilă
pe internet, oricine poate avea acces la ea și astfel persoane rău intenționate pot forț a accesul la
aceasta.

Din fericire, ASP.NET Core vine în ajutorul dezvoltatorilor cu o serie de biblioteci și
mecanisme menite să facă securizarea aplicației la nivel de autentificare mult mai ușoară. În
continuare, o dată cu discuția purtată la nivelul e ndpoint -urilor aplicației, vom evidenția
totodată măsurile de securitate folosite și cum prin acestea ne asigurăm că atât utilizatorii
aplicației cât și datele stocate în baza de date folosită de aceasta sunt în siguranță.

35
Fig. 4. 13 Endpoint -uri Account controller

Înregistrarea unui utilizator nou

Primul pas atunci când avem contact cu o noua aplicație este, firește, înregistrarea. În
cazul aplicației noastre, acest lucru se face prin accesarea endpoint -ului de tip POST
/api/identity/Account/Re gister .

Pentru a se înregistra, un utilizator trebuie să furnizeze următoarele date:
– prenume;
– nume
– titlu;
– nume utilizator;
– email;
– parolă.

Toate aceste date sunt mai întâi validate, astfel încât să nu existe câmpuri goale sau nule.
Mai apoi se verifică în baza de date dacă deja exista numele de utilizator sau email -ul. Întrucât
aceste două variabile trebuie să fie unice, în cazul în care oricare dintre ele există deja, procesul
de înregistrare se oprește, iar aplicația returnează un mesaj de ate nționare.

O dată validate datele, parola aleasă trece printr -un proces de verificare suplimentar.
Aceasta trebuie să îndeplinească câteva criterii, din considerente de securitate. Acestea sunt:
– lungime minimă de 8 caractere;
– să conțină atât litere mici, c ât și litere mari;
– să conțină cel puțin o cifră;
– să nu conțină spații libere;
– să conțină cel puțin un caracter special.

Dacă parola aleasă de utilizator îndeplinește criteriile specificate, atunci aceasta este
criptată folosind algoritmul de criptare SHA -512. Am putea stoca parolele propriu zise în baza
de date, dar asta ar crea o gravă problemă de securitate. Orice persoan ă care obține acces la
baza de date ar afla parolele tuturor utilizatorilor. Algoritmul SHA -512 este unul dintre cele

36 mai sigure din lume, fiind practic imposibil de descifrat. Este nevoie să schimbăm un singur
caracter dintr -o parolă, iar rezultatul va f i total diferit.

Pentru a oferi un nivel de protecție, în baza de date stocăm și o cheie aferente fiecărei
parole criptate. Această cheie este unică și este generată o dată cu parola. Folosim această cheie
pentru a ne asigura că doi utilizatori care își aleg întâmplător aceeași parolă, au în baza de date
parole criptate care arată total diferit.

După ce parola a fost criptată, toate detaliile despre utilizator sunt salvate în baza de
date, iar utilizatorul a fost creat cu succes. De asemenea, după ce uti lizatorul a fost creat, un
email de confirmare va fi trimis la adresa de email specificată. Pentru a finaliza crearea contului
și verificarea adresei de email, utilizatorul trebuie să acceseze link -ul primit în email.

Fig. 4. 14 Exemplu de utilizator sal vat în baza de date

Autentificare

După înregistrare, un utilizator se autentifică în aplicație folosind endpoint -ul de tip
POST /api/identity/Account/ Login . Sunt necesare următoarele date:
– email sau nume utilizator;
– parolă.

Procesul de autentificare es te simplu. Se caută în baza de date utilizatorul cu numele de
utilizator sau email -ul specificat, iar dacă este găsit se folosește cheia din baza de date pentru a
cripta parolă introdusă de utilizator. Daca aceasta este identică cu cea din baza de date,
verificare a avut loc cu succes, iar răspunsul primit conține datele despre utilizator și un jeton
de tip JWT.

JWT (JSON Web Token) este un standard pe Internet pentru crearea de date cu
semnătură opțională și / sau criptare opțională . Jetoanele sunt semna te fie folosind un secret
privat, fie o cheie publică / privată. În cazul nostru, secretul este o secvență de caractere salvată
pe server. Serverul generează un jeton unic, pe baza informațiilor despre utilizator. Acest jeton
este salvat de către front end și va fi folosit pentru autorizare, astfel încât să nu fie nevoie de
autentificare pentru fiecare cerere făcută. Token -ul conține toate datele despre utilizator și este
valabil timp de 7 zile. După expirarea acestuia, utilizatorul va trebuie să se autenti fice din nou.

Front end -ul salvează acest jeton în memoria cache a browser -ului web. Folosirea unui
alt browser va determina, firește, o noua autentificare.

Administrarea parolei

Există trei endpoint -uri responsabile de administrarea parolei. Toate trei sunt accesate
în cazul în utilizatorul dorește să își schimbe parola, fie din considerente cunoscute de el, fie
fiindcă a uitat -o și nu își mai poate accesa contul.

În cazul în care utilizatorul dorește să își schimbe parola, fără ca să o fi uitat, poate
oricând accesa endpoint -ul /api/identity/Account/ Password , care necesită următoarele
informații:
– ID-ul utilizatorului;
– parola curentă ;

37 – noua parolă;
– confirmarea parolei.

Mai întâi se verifică daca utilizatorul este autentificat. Doar un utilizator autentificat
poate accesa acest endpoint. Mai apoi se verifică dacă ID-ul pentru care s -a făcut cererea de
schimbare a parolei este același cu ID-ul utilizatorului care a făcut c ererea. Dacă toate aceste
cerințe sunt îndeplinite, se verifică, la fel ca și la autentificare, dacă parola curentă introdusă de
utilizator este aceeași cu cea din baza de date.

În continuare, se validează noua parola, care trebuie să îndeplinească toate criteriile de
securitate descrise la procesul de înregistrare și să fie la fel ca și câmpul în care utilizatorul a
confirmat parola. Parola este schimbată, iar utilizatorul trebuie să se autentifice din nou.

În cazul în care utilizatorul și -a uitat parola , este clar că acesta nu și -o va putea schimba
folosind endpoint -ul prezentat mai sus. În acest caz va fi nevoit să își reseteze parola, folosind
endpoint -ul /api/identity/Account/ Password/Reset/{email} , unde câmpul email este email -ul
utilizatorului care și-a uitat parola. Nu este nevoie de alte informații, iar utilizatorul nu trebuie
să fie autentificat pentru a putea accesa endpoint -ul.

O dată făcută cererea de resetare a parolei, este verificat în baza de date dacă există
utilizatorul cu email -ul speci ficat. Dacă acesta există, se creează un jeton pe baza ID-ului
utilizatorului din baza de date. Pentru a ne asigura că acest jeton este imposibil de replicat,
jetonul este creat folosind același algoritm de criptare ca în cazul parolei, SHA -512. Tot ca și
în cazul parolei, în baza de date sunt stocate atât jetonul cât și cheia cu care a fost criptat jetonul.

Pe lângă jeton și cheia folosită la criptare, în baza de date sunt stocate și ID-ul
utilizatorului pentru care a fost creat jetonul, data de expirare a jetonului și dacă jetonul a mai
fost folosit sau nu.

La adresa de email specificată este trimis un email de resetare a parolei.

Fig. 4. 15 Email pentru resetarea parolei

38 O dată accesat link -ul din email -ul pentru resetarea parolei, este apelat endpoint -ul
/api/identity/Account/ Password/Reset/{email}/{token} . Email -ul este cel specificat de
utilizator, iar token -ul este jetonul trimis pe email. Următoarele câmpuri sunt de asemenea
necesare:
– parola;
– confirmar ea parolei.

Utilizatorul este identificat în baza de date pe baza email -ului. Dacă acesta a fost găsit,
jetonul este criptat folosind cheia stocată în baza de date, iar dacă rezultatul coincide cu cel din
baza de date, se trece la următorul pas. Pentru o siguranță sporită, jetonul trebuie să mai treacă
prin două verificări. În primul rând, orice jeton de schimbare a parolei este valabil doar o zi din
momentul în care a fost creat. O dată depășită această dată, jetonul devine invalid. În al doilea
rând, un jeton poate fi folosit o singură dată.

Dacă jetonul trimis de utilizator este valid, parola este schimbată cu cea specificată de
utilizator.

Endpoint -ul de tip GET /api/identity/Account/ sendConfirmationEmail este folosit
pentru a trimite un email de c onfirmare a contului. După cum am specificat, la înregistrare un
astfel de email este trimis automat. În cazul în care utilizatorul nu a primit email -ul sau la
pierdut, poate oricând cere altul folosind acest endpoint.

Fig. 4. 16 Email de confirmare prim it la crearea unui cont

După cum se poate vedea în figura 4.16, utilizatorul trebuie să acceseze link -ul din email
pentru confirmarea contului. Link -ul din email duce către endpoint -ul
/api/identity/Account/ Confirm/{guid} , unde guid este chiar ID-ul utilizatorului din baza de
date.

2. Role controller

Sistemul de autorizare al utilizatorilor aplicației este bazat pe roluri. Astfel, fiecare
utilizator are acces la anumite resurse doar dacă rolul sau rolurile pe care le are posedă drepturi

39 de acces la acea resursă. De exemplu, doar un utilizator ce posedă titlul de Administrator are
dreptul să vadă toate rolurile existe pe platformă.

Fig. 4. 17 Endpoint -uri Role controller

Endpoint -urile din Role controller implementează toate cele patru verbe HTTP – GET,
POST, PUT, DELETE, folosite pentru vizualizarea, crearea, modificarea și ștergerea de roluri
din baza de date. De asemenea, GET este implementat de două opri: o dată pentru a vedea un
anumit rol pe baza ID-ului acestuia și o dată pentru a vedea toate rolurile.

Accesul la endpoint -urile din Role contro ller este restricționat, doar utilizatorii ce detin
rolul de Administrator au dreptul să le acceseze, din considerente de securitate.

3. User controller

Acest controller este folosit pentru tot ce ține de administrarea utilizatorilor și nu are
legătură cu c ontul acestora.

Fig 4.1 8 Endpoint -uri User controller

40 Ca și în cazul endpoint -urilor din Role controller, cele din User controller
implementează toate cele patru verbe HTTP, plus un GET pentru toți utilizatorii din baza de
date, dar cu următoarele res tricții:
• un utilizator poate vedea / modifica/ șterge informații doar despre el;
• singurii utilizatori care pot executa orice fel de operații pe informațiile altor utilizatori
sunt doar cei ce au rolul de Administrator.

Logistics service

Acest serviciu de ocupă de gestionarea a tot ce înseamnă elemente de natură logistică
din aplicația noastră. În principal, acestea sunt clădirile gestionate în cadrul aplicației și
dispozitivele de tip IoT care se află în acestea. În același timp, acest serviciu gestionează și
funcțiile aplicației care sunt strâns legate de clădiri și dispozitive.

Astfel, la nivel de controllere, avem trei, pe care le vom prezenta după cum urmează:

1. Buildings controller

Acest controller se ocupă de gestionarea și întreținerea c lădirilor înregistrate în aplicație,
plus adăugarea de noi clădiri sau ștergerea acestora.

Fig. 4.1 9 Endpoint -uri Buildings controller

Endpoint -urile implementează toate cele patru funcții HTTP, cu condiția că un utilizator
poate opera modificări doar asupra propriilor clădiri. În plus, pentru vizualizarea clădirilor
avem trei funcții GET, după cum urmneză:
• /api/Logistics/Buildings/all – aduce to ate clădirile existente în baza de date, pentru toți
utilizatorii înregistrați;
• /api/Logistics/Buildings – este endpoint -ul apelat de un utilizator pentru a vedea toate
clădirile care îi aparțin acestuia; ID-ul pe baza căruia sunt găsite clădirile nu trebu ie
specificat, acesta este extras automat din jetonul de autentificare al utilizatorului;
• /api/Logistics/Buildings/{ ID} – face același lucru ca endpoint -ul anterior, doar că
acesta cere în mod explicit specificarea ID-ului utilizatorului.

Pe lângă endponit -urile care lucrează în mod direct cu clădirile, mai avem, de asemenea,
două endpoint -uri specializate, cu următoarele roluri:

41 • /api/Logistics/Buildings/NumberOfBuildings/{userId} – folosit pentru a afișa
numărul total de clădiri alocate un ui utilizator, pe baza ID-ului acestuia;
• /api/Logistics/Buildings/BuildingStatus/{buildingId} – acesta este folosit pentru a
afișa statusul general al unei clădiri după cum urmează:
dacă toate dispozitivele din clădire au statusul OK, statusul clădirii va fi OK;
dacă există cel puțin un dispozitiv cu statusul ATTENTION , atunci statusul clădirii
va fi ATTENTION ;
dacă există cel puțin un dispozitiv cu statusul ERROR , atunci statusul clădirii va fi
ERROR .

2. Device controller

Acest controller este folosit pentr u gestion area tuturor datel or legate de dispozitivele
aflate în clădirile arondate utilizatorului .

Fig. 4.2 0 Endpoint -uri Device controller

După cum ne -am obișnuit, există endpoint -uri care implementează toate cele patru verbe
HTPP, pentru vizualizarea , adăugarea, modificarea și ștergerea informațiilor despre dispozitive
(GET, POST, PUT, DELETE).

Pentru vizualizarea dispozitivelor (GET) avem la dispoziție următoarele variante:
• /api/Logistics/Device/all – acest endpoint este folosit pentru vizualizarea tuturor
dispozitivelor care aparțin unui utilizator, folosind ID-ul acestuia, extras din jetonul de
autentificare;
• /api/Logistics/Device/building/{buildingId} – este folosit pentru afișarea tuturor
dispozitivelor aflate în tr-o anumită clădire, pe baza ID-ului acesteia;
• /api/Logistics/Device/{ ID} – apelând acest endpoint putem afla informațiile despre un
singur dispozitiv, în funcție de ID-ul specificat.

Pe lângă informațiile propriu zise ale dispozitivelor, mai avem nevoie și de anumite
informații specifice, fie pentru a seta anumiți parametri, fie pentru a le afișa utilizatorului în
aplicație. Endpoint -urile care realizează acestea sunt:
• /api/Logistics/D evice/NumberOfDevicesPerUser/{userId} – folosind ID-ul
specificat, pentru fiecare clădire care aparține utilizatorului sunt numărate dispozitivele

42 din acestea, iar la final este afișat numărul total de dispozitive aflate în clădirile alocate
utilizatorului respectiv;
• /api/Logistics/Device/NumberOfDevicesPerBuilding/{buildingId} – spre deosebire
de endpoint -ul anterior, acesta numără dispozitivele aflate într -o singură clădire, pe baza
ID-ului specificat;
• /api/Logistics/Device/SetDeviceStatus/{deviceId}/{sta tus} – acest endpoint este
apelat de către serviciul de Sensors și este folosit pentru a seta statusul unui anumit
dispozitiv astfel:
0 – pentru statusul OK;
1 – pentru statusul ATTENTION ;
2 – pentru statusul ERROR .
• /api/Logistics/Device/GetDeviceStatus/{d eviceId} – pentru a putea vizualiza statusul
oricărui dispozitiv în aplicație, pe baza ID-ului acestuia, folosim acest endpoint.

3. File controller

Există posibilitatea încărcării de fișiere în aplicația web, iar gestionarea acestor fișiere
se face cu ajuto rul acestui controller. Există nenumărate motive pentru includerea unei astfel
de facilități într -o aplicație web, dar motivul principal pentru care am implementat această
funcționalitate este pentru a oferi utilizatorului opțiunea de a încărca sau descărc a fișiere/ schițe/
poze pentru clădirile și dispozitivele din aplicație.

Toate fișierele încărcate sunt stocate în serviciul cloud Azure Blob Storage. Conform
[33], Azure Blob Storage este o soluție de stocare a obiectelor în cloud. Blob Storage permite
stoca rea unei cantit ăți masiv e de date nestructurate. Datele nestructurate nu trebuie să fie din
modelul specific de date. Azure Blob Storage a fost proiectat pentru a satisface nevoile specifice
ale unui anumit utilizator, p entru date nestructurate, cum ar fi audio, video, imagini, etc .
Obiectele care sunt stocate în Blob Storage nu au neapărat o extensie.

Fig. 4. 21 Endpoint -uri File controller

Endpoint -ul de tip POST api/logistics/File/{fileType}/{ ID} este folosit încărcarea
fișierelor. „ fileType ” este folosit pentru a specifica dacă fișierul aparține unei clădiri sau unui
dispozitiv, iar „ ID” este ID-ul respectivei clădiri/ dispozitiv. De asemenea, în corpul cereri este
atașat fișierul propriu zis. Ac est fișier este preluat, este transformat în șir de octeți și încărcat în
Blob Storage astfel:
1. Se identifică extensia fișierului și este creat un nume format din numele fișierului și
extensia;
2. Se realizează conexiunea la clientul de Blob Storage pe baza in formațiilor de
autentificare stocate pe server;
3. Din clientul de Blob Storage se selectează container -ul „logisticsuploads”;

43 4. Se verifică dacă numele fișierului există deja în cotainer, iar dacă există la finalul
numelui se mai adaugă o cifră; dacă cifra de ja există, aceasta se incrementează;
5. După ce încărcarea a fost efectuată cu succes, pentru a ține evidența fișierelor, în baza
de date sunt stocate numele fișierului, adresa din Blob Storage către acesta și ID-ul
clădirii/ dispozitivului căruia îi aparține .

În cazul în care un utilizator dorește descărcarea unui anumit fișier din aplicație, acest
lucru este posibil cu ajutorul endpoint -ului de tip GET /api/logistics/File/{ ID}. Acesta
funcționează astfel:
1. Pe baza ID-ului specificat, este căutată înregistrar ea fișierului din baza de date;
2. Folosind ID-ul utilizatorului extras din jetonul de autentificare, se verifică dacă fișierul
solicitat pentru descărcare aparține utilizatorului respectiv;
3. Folosind datele de autentificare de pe server se realizează conexiun ea la Blob Storage;
4. Se preia din Blob Storage șirul de octeți al fișierului folosind adresa acestuia din baza
de date;
5. Șirul de octeți este transformat într -un fișier de tipul specificat în Blob Storage;
6. Acest fișier este trimis ca răspuns către client, cu numele din baza de date plus extensia
specificată în Blob Storage.

Dacă un utilizator dorește ștergerea unui anumit fișier, acest lucru este foarte simplu, nu
este nevoie decât de apelarea endpoint -ului de tip DELETE /api/logistics/File/{ ID}. Pe baza
ID-ului se efectuează următoarele:
1. Se verifică dacă utilizatorul are dreptul de a șterge fișierul specificat;
2. Se identifică în baza de date înregistrarea cu informațiile despre fișier;
3. Folosind adresa din baza de date fișierul este șters din Blob Storage;
4. Înregistrarea fișierului este ștearsă din baza de date.

Sensors service

Sensors service este microserviciul care se ocupă de tot ce are legătură cu datele
înregistrate de senzorii di spozitivelor inteligente din aplicație. Dispozitivele propriu zise sunt
gestionate de Logistics service, prezentat anterior, dar dat fiind faptul că senzorii acestor
dispozitive înregistrează o sumedenie de valori, iar aceste valori sunt trimise în mod con stant
către aplicație, am ales crearea unui microserviciu separat, care să se ocupe exclusiv cu
gestionarea acestor valori.

În cadrul acestui microserviciu avem un singur controller, specializat pe gestionarea
valorile recepționate de la senzori, pe care l-am denumit Adapter controller.

Fig. 4. 22 Endpoint -uri Adapter controller

44 Primele două endpoint -uri, cele de tip GET, sunt folosite de aplicație, pentru a extrage
din baza de date valorile înregistrate de senzori, pentru a -i fi afișate utilizatorului în aplicația
web.

Endpoint -ul /api/sensors/Adapter/{deviceId} afișează doar setul de valori care a fost
cel mai recent înregistrat. În baza de date, pe lângă valorile de la senzori, este stocată și data și
ora la care au fost înregistrate valorile respective.

Fig. 4. 23 Valori înregistrate de senzori, stocate în b aza de date

Endpoint -ul /api/sensors/Adapter/AllRecords/{deviceId} afișează toate valorile
înregistrate vreodată de senzori, așa cum se găsesc ele în baza de date. La fel ca și precedentul
endpoint, identificarea setului de valori se face pe baza ID-ului dispozitivului.

Înainte ca un dispozitiv să poată trimite datele de la senzori către baza de date, acesta
trebuie înregistrat în aplicație. Acest lucru se face accesând endpoint -ul de tip POST
/api/sensors/Adapter/RegisterDevice , care primește următoarele date:
– ID-ul utilizatorului căruia îi aparține dispozitivul;
– ID-ul dispozitivului (este de preferat ca acesta să fie numărul serial al dispozitivului
fizic);
– numele dispozitivului, ales de utilizator.

O dată înregistrat dispozitivul, acesta va trimite date către aplicație folosind endpoint –
ul /api/sensors/Adapter/Insert DeviceData , care primește următoarele valori:
– ID-ul dispozitivului;
– temperatura, în grade Celsius;
– nivelul de umiditate, exprimat în procente;
– valoarea brută înregistrată de fotorezistor – în funcție de aceasta se va stabili dacă
lumina este sau nu stinsă;
– o valoare care indică dacă ușa este deschisă sau nu:
o 0 – ușa este deschisă;
o 1 – ușa este închisă.
– data și ora la care s -a făcut înregistrarea – acest câmp este opțional, în cazul în care nu
este precizată data și ora, aceasta este determinată automat de a plicație, la momentul
înregistrării în baza de date.

Pentru a schimba statusul dispozitivului, folosind endpoint -ul din Logistics service,
prezentat anterior, trebuie îndeplinite următoarele condiții:
1. Schimbare statusului în ATTENTION se face când:
a. Temperatura depășește valoarea de 8 grade Celsius;
b. Umiditatea depășește valoarea de 90% ;
c. Ușa apare ca fiind deschisă pentr u mai mult de 60 de secunde.

2. Schimbarea statusului în ERROR se face când:
a. Temperatura depășește valoarea de 13 grade Celsius;
b. Umidita tea depășește valoarea de 95%;
c. Nu este detectată lumină, deși ușa apare ca fiind deschisă;
d. Este detectată l umină deși ușa pare a fi închisă .

45 În cazul în care, din diferite motive, dorim ștergerea tuturor datelor din baza de date
pentru un anumit dispozitiv , o puteam face folosind ID-ul acestuia, apelând endpoint -ul de tip
DELETE /api/sensors/Adapter/DeleteAllRecords/{deviceId} .

Mai mult decât atât, dacă se dorește ștergerea dispozitivului în sine din baza de date,
putem apela endpoint -ul de tip DELETE /api/sensors/Adapter/DeleteDevice/{deviceId} .

Gateway service

După cum am precizat deja, scopul acestui microserviciu este să ruteze cererile vine de
la front end, către microserviciul responsabil de procesarea acestora. Toate cererile făcute de
front end sunt transmise la adresa web a gateway -ului, adresele către celelalte microservicii nu
sunt expuse, accesarea acestora făcându -se strict prin intermediul gateway -ului.

Această rutare se face astfel:
• fiecare adresă ce conține /api/logistics/{everything} va fi redirecționată către
microserviciul Logistics;
• fiecare adresă ce conține /api/ identity /{everything} va fi redirecționată către
microserviciul Identity;
• fiecare adresă ce conține /api/ sensors /{everything} va fi redirecționată către
microserviciul Sensors;
• {everything} reprezintă toate detaliile care vor fi transmise mai departe către
microserviciul indicat.

Fig. 4. 24 Configurarea gateway -ului

46 4.2. Componenta hardware

4.2.1. Componente folosite

NodeMCU WiFi E SP8266

ESP8266 NodeMCU este o placă de dezvoltare Wi-FI bazată pe ESP8266, cu un circuit
integrat care conține module GPIO, PWM, IIC și ADC. Este programat cu ajutorul Arduino
IDE și folosind sintaxă Arduino pentru controlul hardware -ului. Este excelent pentru aplicațiile
IoT datorită compatibilității sale cu diferitele conexiuni la rețea.

Fig. 4. 25 ESP8266 NodeMCU [34]

Arduino Uno

Arduino Uno este o placă cu microcontrole r integrat bazată pe ATmega328P. Are 14
pini de intrare / ieșire digitali, 6 intrări analogice, un rezonator ceramic de 16 MHz, o conexiune
USB, o mufă de alimentare, un antet ICSP și un buton de resetare. De asemenea, are tot ce este
necesar pentru a spri jini microcontrolerul . Trebuie conectată pur și simplu la un computer cu
un cablu USB sau alimentată cu un adaptor AC -DC sau o baterie [35].

Arduino Uno este unul dintre cele mai utilizate tipuri de Arduino dintre toate, deși nu a
fost primul lansat. De asemenea, pentru faptul că este atât de popular, este foarte ușor pentru
un începător să înceapă să înțeleagă cum funcționează acesta, doar căutând câteva proiecte pe
Internet.

Fig. 4. 26 Arduino Uno [36]

47 1. Buton Reset : acest buton va reporni orice cod care este încărcat pe placă;
2. AREF : înseamnă Analog Reference (Referință Analogică) și este utilizat pentru a seta o
tensiune de referință externă;
3. Pinul de tensiune negativă (GND) : Arduino are 3 astfel de pini și toți funcționează în același
mod;
4. Intrare / Ieșire digitală : pinii între 0 -13 pot fi folosiți pentru intrare sau ieșire digitală;
5. PWM : pinii cu simbolul (~) se pot comporta ca o ieșire analogică;
6. Conexiune USB : este utilizat pentru alimentarea Arduino și pentru a încărca schițe;
7. TX / RX : este utilizat pentru transmiterea și primirea LED -urilor de indicare a datelor;
8. Microcontroler ATmega : aici sunt stocate programele;
9. Indicator LED de alimentare : LED -ul se aprinde atunci când placa este conectată la o sursă
de alimentare;
10. Regulator de tensiune : acest lucru asigură că placa Arduino primește cantitatea corectă de
tensiune;
11. Mufă de alimentare : alimentează Arduino cu o sursă de alimentare;
12. Pinul 3.3V : acest pin furnizează 3,3 volți de putere;
13. Pin 5V – acest pin furnizează 5 volți de putere;
14. Pini analogici : acest pin poate converti un semnal de la un senzor analogic la unu l digital.

Aceste informații pot fi găsite în referința [36].

Senzor de Temperatură și Umiditate Adafruit SHT31 -D

Acest tip de senzor are o precizie ridicată, ± 2% umiditate relativă și ± 0,3 ° C pentru
temperatură. SHT31 -D are o interfață I2C cu două opțiuni de adresă. Poate fi utilizat cu orice
microcontroler sau microcomputer datorită faptului că este adaptabil la 3V și 5V.

Fig. 4. 27 Adafruit SHT31 -D [37]

Pini de putere:

• Vin:
o pinul electric ;
o 2,5-5 VCC pentru putere;
o pentru un microcontroler 3.3V trebuie conectat la 3.3V.

• GND :
o pin comun pentru putere și, de asemenea, logică .

Pinii logici I2C:

48 • SCL:
o semnal de ceas I2C;
o este conectat la linia de ceas I2C de la microcontroler;
o are rezistență de tragere 10K la Vin.

• SDA :
o semnal de ceas I2C;
o este conectat la linia de ceas I2C de la microcontroler;
o are rezistență de tragere 10K la Vin.

Ceilalți pini:

• Pin ADR :
o pinul de selectare a adreselor I2C .

• RST:
o resetarea acului ;
o trebuie să fie conectat la sol pentru o resetare hardware.

• ALR :
o aceasta este ieșirea de alertă sau întrerupere;
o senzorul poate fi programat pentru a avertiza când s -a întâmplat ceva.

Informațiile pentru senzorul SHT31 -D de temperatură și umiditate au fost inspirate de
referință [37].

Senzor de obstacole cu infraroșu E18-D80NK

Acest tip de senzor este foarte ieftin și are o distanță mai mare de detectare decât alți
senzori de acest fel. De asemenea, este posibil ă reglarea distanț ei și acesta este singurul lucru
care a trebuit reglat pentru a asigura precizia în cadru l acestui proiect.

Fig. 4. 28 Senzor infraroșu E18-D80NK

Configurația pinilor a fost, de asemenea, foarte simplă, deoarece aceștia sunt conectați
după cum urmează:
– firul roșu la 5V;
– firul verde la GND;

49 – firul galben la ieșirea digitală [38].

Fotorezistor

Acest senzor este un fotoresistor care detectează lumina prin dioada sensibilă la lumină
din interiorul acestuia. Aceasta este foarte sensibilă la modificările intensită ții luminii. Din acest
motiv, acest senzor este foarte utilizat în proiecte care trebuie să măsoare intensitatea luminii.

Fig. 4.2 9 Fotorezistor [39]

4.2.2. Prima metodă abordată

Inițial, a m ales transmiterea datel or prin comunicare în serie între Arduino Uno și
NodeMCU folosind pinii 5, 6 și, de asemenea, D5, D6 ca în imaginea de mai jos:

Fig. 4. 30 Conexiune între NodeMCU și Arduino

50
Fig. 4. 31 Conexiune între NodeMCU și Arduino

Am creat un cont pe platforma http://shiftr.io/ , un namespace și am configurat
conexiunea la placa NodeMCU folosind un ID de client generat la întâmplare și am publicat în
acele subiecte valorile pentru fiecare senzor. Deși Arduino Uno înregistrează datele în mod
corespunzător, iar NodeMCU este capabil să trimită date către platforma web, cele două
eșuează să comunice între ele . Din păcate, nu am reușit să rezolv această problemă, deși codul
este pus în aplicare corect urmâ nd exemple le exact ca în referinț a [40].

4.2.3. A doua metodă abordată

Am decis să folosesc doar placa NodeMCU Wifi ESP8266 , care are o singură intrare
analogică. Inițial am crezut că ar putea fi o problemă la început din moment ce folosim trei
senzori : temperatur ă și umiditate, proximitate și lumin ă, dar din fericire, senzorii de proximitate
și lumină sunt digitali, așa că am continuat să folosesc doar NodeMCU.

Am conectat pl ăcuța NodeMCU la două breadboard -uri și după ac eea am adăugat cei
trei senzori: temperatură și umiditate SHT31 -D, senzor de obstacole cu infraroșu și
fotorezistorul .

După ce am realizat toate conexiunile, circuitul arată astfel :

51
Fig. 4. 32 NodeMCU conectat la senzori

Firele conectate pot fi văzute în Figura 4.32, dar mult mai bine în Figura 4.33. Este, de
asemenea, un circuit simplu de realizat odată ce am decis să nu folosesc Arduino Uno, ci doar
NodeMCU. Putem vedea că am conectat pinii de ceas I2C SCL și SDA de la senzoru l SHT31 –
D la D1, respectiv D2 (SCL și SDA) de pe NodeMCU.

Fig. 4. 33 Schemă circuit

Schema din Figura 4. 33 a fost realizată folosind Fritzing [41].

52 4.2.4. Programarea circuitului

Partea cea mai importantă a proiectului este trimiterea datel or de la acești trei senzori
către platforma web IoT. Toate acestea vor fi posibile prin programarea NodeMCU în Arduino
IDE pentru a face solicitări de tip HTTP POST.

HTTP POST este utilizat pentru a trimite date către un server spec ificat. În cazul nostru
solicitarea HTTP POST se face folosind un obiect JSON.

Pentru a mă conecta la o rețea WiFi de la NodeMCU ESP8266 WiFi am instalat
biblioteca ESP8266 WiFi și, de asemenea, biblioteca ESP8266HTTPClient, astfel încât să pot
trimite so licitări HTTP. Ultima bibliotecă instalată a fost biblioteca ArduinoJson care m -a ajutat
la codificarea mesajelor JSON. În imaginea de mai jos, veți vedea toate importurile de care are
nevoie codul ce rulează pe NodeMCU :

Fig. 4. 34 Biblioteci folosite de NodeMCU

Pentru a începe procesul de trimitere a obiectului JSON prin solicitarea de tip POST,
am creat mai întâi un obiect al clasei StaticJsonBuffer pentru codarea mesajelor. Mai mult, am
descoperit că o dimensiune de 300 de octe ți este mai mult decât suficientă pentru ceea ce voiam
să trimit.

Fig. 4. 35 Declarare buffer JSON

După crearea obiectului de tip StaticJsonBuffer, generez un vector pentru fiecare senzor
pe care l -am conectat la NodeMCU cu același nume ca în baza de da te.

Fig. 4. 36 Crearea vectorilor cu date de la senzori

Următoarea etapă constă în crearea clientului HTTP care va trimite solicitarea de tip
POST către aplicația web, la adresa specificată în cod.

53 Pentru a se realiza cu succes solicitarea, trebuie de finite următoarele headere:
• Content -Type : application/json – acest header semnalează că mesajul transmis este
codificat sub forma unui JSON;
• ApiKey : v5yXxY!HY -&g,]2^; -YLh1$6eQRgtj – această cheie trebuie folosită de
toate dispozitivele care vor să se cone cteze la aplicație. din motive de siguranță (pentru
a nu permite dispozitivelor neautorizate accesul).

Fig. 4. 37 Modalitatea de comunicare între dispozitive și aplicație

Dacă totul este în regulă și trimiterea s -a efectuat cu succes, serverul răspunde cu un
HTTP status code 200, după cum se poate vedea în figura 4. 38:

Fig. 4. 38 Răspunsul serverului

Datele trimise de la senzori sunt înregistrate în baza de date, de unde sunt mai apoi
preluate de aplicație și afișate utilizatorului în interfața web:

Fig. 4. 39 Datele de la senzori, afișate în aplicație

54 5. Concluzii

Concluzii

5.1. Viitoare îmbunătățiri

Per total am reușit să implementez la nivelul aplicației tot ce mi -am propus, iar scopurile
inițiale au fost atinse. Cu toate acestea, nu înseamnă că viitoare îmbunătățiri nu pot fi aduse. În
primul rând există o serie de funcționalități pe care deși le -am implementat la nivel de back
end, în front end încă nu au fost dezvoltate.

Prima astfel de funcționalitate este cea de înregistrare – nu există pagină dedicată unde
utilizatorul poate intra să se înregistreze. El trebuie să facă acest lucru folosind interfața
Swagger UI din back end. Tot folosind Swagger UI se accesează și endpoint -urile pentru
schimbare și resetare par olă. Pentru cele din urmă am reușit să fac designul, pe viitor fiind
necesară doar crearea paginilor web în front end.

De asemenea, există o serie de modificări și optimizări pe care le consider necesare pe
viitor. În primul rând, aplicația este dezvoltată pe baza de microservicii, după cum am prezentat.
În momentul de față, fiecare astfel de microserviciu rulează independ ent într -un Web App pe
Azure. Acest lucru este neeficient și prezintă costuri ridicate. Soluția pentru aceste probleme
este folosirea de containere de tip Docker.

Cu ajutorul Docker va fi posibilă

Bibliografie

55
[1] https://internetofthingsagenda.techtarget.com/definition/Internet -of-Things -IoT
[2] https://www.edureka .co/blog/what -is-iot/
[3] A state of the art review on the Internet of Things (IoT), Suresh, P., Daniel, J. V.,
Parthasarathy, V., & Aswathy, R. H. (2014)
https://ieeexplore.ieee.org/abs tract/document/7043637 Accesat: 2020.
[4] History of IoT: What It Is, How It Works, Where It’s Come From, and Where It’s Going
https://itchronicles.com/iot/history -of-iot-what -it-is-how-it-works -where -its-come -from -and-
where -its-going/ Accesat: 2020.
[5] Advances in Computer Science and Information Engineering, David Jin, Sally Lin, 2012
[6] R. Mahmoud, T. Yousuf, F. Aloul and I. Zual kernan, "Internet of things (IoT) security:
Current status, challenges and prospective measures," (2015 )
https://ieeexplore.ieee.org/document/7412116
[7] The advantages and disadvantages of Internet Of Things (IoT)
https://www.linkedin.com/pulse/advantages -disadvantages -internet -things -iot-tommy -quek/
Accesat: 2020.
[8] Real World IoT Applications in Different Domains
https://www.edureka.co/blog/iot -applications/ Accesat: 2020.
[9] https://ro.wikipedia.org/wiki/RF ID
[10] Miorandi, D., Sicari, S., De Pellegrini, F., & Chlamtac, I. (2012). Internet of things: Vision,
applications and research challenges. Ad Hoc Networks
https://ww w.sciencedirect.com/science/article/abs/pii/S1570870512000674 Accesat: 2020.
[11] https://www.tomsguide.com/us/what -is-a-smart -refrigerator,review -6307.html
[12] Al-Fedaghi, Sabah. (2011). Developing Web Applications. International Journal of
Software Engineering and Its Applications
https://www.researchgate.net/ publication/228849246_Developing_Web_Applications
Accesat: 2020.
[13] What is REST?
https://www.codecademy.com/articles/what -is-rest Accesat: 2020.
[14] https://www.geeksforgeeks.org/frontend -vs-backend/
[15] https://angular.io/guide/architecture
[16] https://docs.microsoft.com/en -us/dotnet/core/introduction
[17] https://docs.microsoft.com/en -us/dotnet/core/about
[18] https://dotnet.microsoft.com/learn/aspnet/what -is-aspnet -core
[19] https://docs.microsoft.com/en -us/aspnet/core/introduction -to-aspnet –
core?view=aspnetcore -3.1
[20] https://en.wikipedia.org/wiki/Object -relational_mapping
[21] https://www.entityframeworktutorial.net/what -is-entityframework.aspx
[22] Almeida, Fernando. (2016). Practical SQL Guide for Relational Databases
https://www.researchgate.net/publication/319852714_Practical_SQL_Guide_for_Relational_
Databases Accesat: 2020.
[23] https: //searchsqlserver.techtarget.com/definition/T -SQL
[24] https://en.wikipedia.org/wiki/Microsoft_SQL_Server
[25] What is Git?
https://www.atlassian.com/git/tutorials/what -is-git

56 [26] Scott Chacon, Ben Straub (2012). Pro Git book 2nd Edition, Creative Commons
Attribution Non Commercial Share Alike 3.0 license
https://git -scm.com/bo ok/en/v2 Accesat: 2020.
[27] https://www.senetic.ro/azure/
[28] https://docs.microsoft.com/en -us/azure/devops/pipelines/get -started/what -is-azure –
pipelines?view=azure -devops
[29] https://www.devopsgroup.com/insights/resources/tutorials/all/what -is-azure -devops/
[30] https://medium.com/edureka/azure -portal -all-you-need-to-know -about -the-azure –
console -8ade1effa474
[31] https://dev.to/alex_barashkov/micro services -vs-monolith -architecture -4l1m
[32] Microservices vs Monolith: which architecture is the best choice for your business?
https://www.n -ix.co m/microservices -vs-monolith -which -architecture -best-choice -your-
business/
[33] https://www.serverless360.com/blog/azure -blob-storage -vs-file-storage
[34] https://www.emag.ro/modul -nodemcu -lua-wifi-v3-ch340 -cl334/pd/DMJ66JBBM/ –
product -gallery
[35] https://st ore.arduino.cc/arduino -uno-rev3
[36] https://www.makerspaces.com/arduino -uno-tutorial -beginners/
[37] Adafruit SHT31 -D Temperature & Humidity Sensor Breakout
https://cdn -learn.adafruit.com/downloads/pdf/adafruit -sht31 -d-temperature -and-humidity –
sensor -breakout.pdf Accesat: 2020.
[38] https://www.rhydolabz.com/documents/27/E18 -D80NK.pdf
[39] https://www.emag.ro/fo torezistor -5528 -ldr-set-5-bucati -98/pd/D3CQ35BBM/ – product –
gallery
[40] https://www.youtube.com/watch?v=A6HL5ImjDDA&feature=youtu.be
[41] https://fritzing.org/home/