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

LUCRARE DE DIPLOMĂ

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

Coordonator Absolvent: [anonimizat].dr.ing. [anonimizat]

2020

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 identificată …………………………………………………………………. 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 ………………………………………………………………. 46

4.2.1. Componente folosite ……………………………………………………………. 46

4.2.2. Prima metodă abordată ……………………………………………………….. 49

4.2.3. A doua metodă abordată ………………………………………………………. 50

4.2.4. Programarea circuitului ……………………………………………………….. 52

5. Concluzii ………………………………………………………………………………………….. 54

5.1. Viitoare îmbunătățiri …………………………………………………………………. 55

Bibliografie …………………………………………………………………………………………. 56

[anonimizat] s-o [anonimizat], este o [anonimizat] (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 dispozitivele pe care le are la birou, dar și pe cele de acasă.

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 problemă 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.

Alcătuirea lucrării

Pe lângă prezenta documentație, al cărui scop este prezentarea 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ției 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 umiditate, 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 prezentată 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.

Prezentarea temei alese

2.1. Internet of Things (IoT)

Internet of Things reprezintă o rețea de dispozitive 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 schimba 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 stilului 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 lucru-lucru. Conceptele IoT, deși există de ani buni pe piață, sunt încă în faza inițială a implementării comerciale [1].

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

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 frigorific, 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 cercetare 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 la 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 aceeași perioadă 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 monitorizat. Ș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 standardul calității, astfel încât orice dispozitiv inteligent să poată comunica cu rețelele furnizorilor și comercianților cu amănuntul. De-a lungul timpului, 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].

Arhitectura unei rețele IoT

Așa cum este prezentat în [5], în esență, structura unei rețele IoT este compusă 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 diferite tipuri de componente într-o rețea sofisticată și unificată. Acestea sunt:

A. Stratul 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ă autenticitatea, 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]

2.2. Avantajele IoT

Automatizare ș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ții

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.

Monitorizare

Unul dintre cele mai evidente avantaje 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, știind 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 expirare a produselor din casă poate oferi un plus de siguranță.

Timp

Așa cum 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 bani

Poate unul dintre cele mai mari avantaje 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 fundamental, 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ținută 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 automatizarea și controlarea sarcinilor 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ținerea calității serviciilor. De asemenea, în caz 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ători 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 probleme 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ță.

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 complexitate, există multe variabile care pot provoca o problemă. În cazul Internet 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 magazin în drum spre casă și vor cumpăra 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 imprimantă 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 sectorul 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 mare de bani către cei care au inițiat atacul.

Mai există posibilitatea ca un magazin să livreaze 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 produs 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 procese 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ă.

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 viaț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ădirii (electricitate, apă), cât și la îmbunătățirea nivelului de satisfacție al locatarilor, fie că sunt angajați într-o clădire 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 unele dintre cele mai dăunătoare tipuri de emisii de gaze cu efect de seră).

În acest 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ă.

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 optimizeze 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 serviciilor care oferă sfaturi de rutare 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 senzori, poate permite monitorizarea spațiilor 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 despre 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 folosiți într-un cadru criminalistic, prin detectarea încălcării 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 monitorizarea 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 periclitarea 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, zone îndepărtate), de unde informațiile obținute pot fi comunicate către un punct de control extern pentru a detecta condiții anormale. Î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 IoT), î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, tsunami etc.), întrucât capacitatea de a accesa o multitudine de 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, tensiunea arterială, activitatea cerebrală, respirație. Alți senzori, care pot fi purtați (cum ar fi accelerometru sau giroscop) sau ficși (de proximitate) vor fi utilizați pentru a aduna date necesare pentru monitorizarea activitățile pacientului în mediul lui de viață. Informațiile vor fi colectate local și transmise către centre medicale, 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 arse, exerciții efectuate etc.), oferind sugestii pentru îmbunătățirea stilului lor de viață și prevenirea apariției problemelor de sănătate.

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 dispozitive 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 specialitate;

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 întreaga instalație pentru a fi monitorizați. Tehnologiile IoT pot oferi o flexibilitate sporită în ceea ce privește pozițiile 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, oferind 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, calitatea 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 ieftine ș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 monitorizează comportamentul oamenilor pot fi folosiți pentru a determina prezența persoanelor care întreprind acțiuni ce par a fi suspecte. 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 oferi 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 utilizatorilor 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 aplicabilitatea al Internet of Things este extrem de larg. Cu toate acestea, aplicațiile care sunt construite pe baza IoT pot fi în mod constant îmbunătățite, 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, industriile din sfera tehnologiei informației și a comunicațiilor împreună cu organismele legislative adoptă o serie de inițiative pentru a stabili orientarea procesului 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].

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 consumatorii 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 asamblare 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 dispozitive. 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 internetului. 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 toate 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 frigider, 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 internetului toate aceste informații la aplicația web, de unde utilizatorul le poate vedea în timp real.

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]

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 stocurile.

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 acestea sunt fără stare proprie și separă preocupările clientului și serverului. În cele ce urmează vom analiza ce înseamnă acești termeni și de ce sunt caracteristici benefice pentru serviciile de pe Web [13].

Separarea clientului ș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 moment 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 separate. 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 componente 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.

Stare

Sistemele care urmează paradigma REST sunt lipsite de stare, 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.

Deoarece 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, actualizate ș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ăspunsuri 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 general 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ă partea 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 meniul 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 mobile 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 toate dimensiunile, 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 marcare 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 crea 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ționa 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 API-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, generic, și orientată pe obiecte. 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ă limbaje de programare. Este foarte ușor de scalat. Componentele Java sunt ușor disponibile.

Node.js: este un mediu de rulare de tip open-source și și disponibil pentru platforme multiple, folosit pentru executarea codului JavaScript în afara unui browser. Trebuie amintit 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].

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 implementează 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 NgModules, 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 bootstrapping-ul (procesul 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, reutilizabil ș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 defineș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, metadatele pentru o clasă de servicii furnizează informațiile de care are nevoie 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 subcapitolul 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 Core 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 back 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].

Pentru dezvoltarea de aplicații web, cum este cazul prezentului proiect, folosim framework-ul ASP.NET Core. Acesta 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 Core 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 (injecț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]

După cum se poate observa în figura de mai sus, Entity Framework Core se încadrează între entitățile de business (clasele 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 Windows, 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 entităț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 datele 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 Framework 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 programare 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 FluentAPI 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 subiacente [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.

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ări 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 executate 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 coloane ș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 la 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 tranzacț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:

În timp ce T-SQL este o extensie la SQL, SQL este un limbaj de programare;

T-SQL conține programare procedurală și variabilă locală, în timp ce SQL nu;

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 preluare 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, destinate 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.

Microsoft SQL Server permite, de asemenea, să fie definite și utilizate 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 dimensiune 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 fiecare partiție sunt stocate fie într-un arbore de tip B, fie într-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 arbore 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 tastele 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 numă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 funcț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 istoria versiunilor complete a 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. care 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 mersiunilor, 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 alternative:

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 alternative, 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ătat 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: instrument de planificare Agile, urmărirea task-urilor, vizualizare și raportare;

Azure Pipelines: un serviciu cloud care poate fi utilizat pentru a construi și testa automat proiectul de cod și pentru a-l pune la dispoziția altor utilizatori. Funcționează cu aproape orice limbaj de programare sau tip de proiect [28];

Azure Repos: furnizează depozite private de Git găzduite pe cloud;

Azure Artifacts: oferă gestionarea integrată a pachetelor cu suport pentru pachete Maven, npm, Python ș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țiilor într-un singur loc. Permite construirea, gestionarea și să monitorizarea a tot, de la aplicaț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 accesarea 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 cele mai bune caracteristici ale Microsoft Azure este că permite urmărirea atât costurilor actuale cât și viitoare [30].

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 containere 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 zilele noastre. Într-adevăr, abordarea bazată pe microservicii oferă beneficii tangibile, inclusiv o creștere a scalabilității, flexibilitate, 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 acestui trend ca fiind cel mai eficient mod de creștere a afacerilor.

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 reduce, 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 considerată 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 vorba 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.;

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 microservicii [32]

În timp ce o aplicație monolitică este o singură unitate unificată, o arhitectură pe microservicii descompune aplicația într-o colecție de unități independente mai mici. Aceste unități efectuează fiecare proces solicitat ca un serviciu separat. Deci toate serviciile 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 numite API (interfeț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 primul 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 gestionat;

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 urmare, 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;

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 independente, 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 componente 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 modulul partajat: Layout, Alert, Progress Spinner:

Fig. 4.5 Module Angular

Î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

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.

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 respective. 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).

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ă utilizatorul dorește să vadă câteva detalii despre frigider, astfel încât să poată avea o imagine de ansamblu, acesta poate face 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ă.

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

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ă problemă, 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 prezentare 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 comunicarea 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 înseamnă administrarea acestora.

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

Account controller

Acesta este responsabil de una dintre cele mai importante funcționalități ale aplicației și anume autentificarea utilizatorilor. 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 endpoint-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ță.

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/Register.

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 atenț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 mai sigure din lume, fiind practic imposibil de descifrat. Este nevoie să schimbăm un singur caracter dintr-o parolă, iar rezultatul va fi 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 utilizatorul 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 salvat î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 este 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 semnate 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 autentifice 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ă;

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 cererea. 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 specificat. 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

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;

confirmarea 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 confirmare 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 primit 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.

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 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 controller este restricționat, doar utilizatorii ce detin rolul de Administrator au dreptul să le acceseze, din considerente de securitate.

User controller

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

Fig 4.18 Endpoint-uri User controller

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 restricț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ă:

Buildings controller

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

Fig. 4.19 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 toate 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 trebuie 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:

/api/Logistics/Buildings/NumberOfBuildings/{userId} – folosit pentru a afișa numărul total de clădiri alocate unui 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.

Device controller

Acest controller este folosit pentru gestionarea tuturor datelor legate de dispozitivele aflate în clădirile arondate utilizatorului.

Fig. 4.20 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 într-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/Device/NumberOfDevicesPerUser/{userId} – folosind ID-ul specificat, pentru fiecare clădire care aparține utilizatorului sunt numărate dispozitivele 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}/{status} – 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/{deviceId} – pentru a putea vizualiza statusul oricărui dispozitiv în aplicație, pe baza ID-ului acestuia, folosim acest endpoint.

File controller

Există posibilitatea încărcării de fișiere în aplicația web, iar gestionarea acestor fișiere se face cu ajutorul 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ărca 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 stocarea unei cantități masive 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, pentru 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. Acest fișier este preluat, este transformat în șir de octeți și încărcat în Blob Storage astfel:

Se identifică extensia fișierului și este creat un nume format din numele fișierului și extensia;

Se realizează conexiunea la clientul de Blob Storage pe baza informațiilor de autentificare stocate pe server;

Din clientul de Blob Storage se selectează container-ul „logisticsuploads”;

Se verifică dacă numele fișierului există deja în cotainer, iar dacă există la finalul numelui se mai adaugă o cifră; dacă cifra deja există, aceasta se incrementează;

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:

Pe baza ID-ului specificat, este căutată înregistrarea fișierului din baza de date;

Folosind ID-ul utilizatorului extras din jetonul de autentificare, se verifică dacă fișierul solicitat pentru descărcare aparține utilizatorului respectiv;

Folosind datele de autentificare de pe server se realizează conexiunea la Blob Storage;

Se preia din Blob Storage șirul de octeți al fișierului folosind adresa acestuia din baza de date;

Șirul de octeți este transformat într-un fișier de tipul specificat în Blob Storage;

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:

Se verifică dacă utilizatorul are dreptul de a șterge fișierul specificat;

Se identifică în baza de date înregistrarea cu informațiile despre fișier;

Folosind adresa din baza de date fișierul este șters din Blob Storage;

Î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 dispozitivelor 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 constant 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

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 baza 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/InsertDeviceData, 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:

0 – ușa este deschisă;

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 aplicaț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:

Schimbare statusului în ATTENTION se face când:

Temperatura depășește valoarea de 8 grade Celsius;

Umiditatea depășește valoarea de 90%;

Ușa apare ca fiind deschisă pentru mai mult de 60 de secunde.

Schimbarea statusului în ERROR se face când:

Temperatura depășește valoarea de 13 grade Celsius;

Umiditatea depășește valoarea de 95%;

Nu este detectată lumină, deși ușa apare ca fiind deschisă;

Este detectată lumină deși ușa pare a fi închisă.

Î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

4.2. Componenta hardware

Componente folosite

NodeMCU WiFi ESP8266

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 microcontroler 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 sprijini 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]

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 unul 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:

pinul electric;

2,5-5 VCC pentru putere;

pentru un microcontroler 3.3V trebuie conectat la 3.3V.

GND:

pin comun pentru putere și, de asemenea, logică.

Pinii logici I2C:

SCL:

semnal de ceas I2C;

este conectat la linia de ceas I2C de la microcontroler;

are rezistență de tragere 10K la Vin.

SDA:

semnal de ceas I2C;

este conectat la linia de ceas I2C de la microcontroler;

are rezistență de tragere 10K la Vin.

Ceilalți pini:

Pin ADR:

pinul de selectare a adreselor I2C.

RST:

resetarea acului;

trebuie să fie conectat la sol pentru o resetare hardware.

ALR:

aceasta este ieșirea de alertă sau întrerupere;

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 cadrul 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;

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.29 Fotorezistor [39]

4.2.2. Prima metodă abordată

Inițial, am ales transmiterea datelor 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

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 exemplele 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ă aceea 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:

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 senzorul 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].

4.2.4. Programarea circuitului

Partea cea mai importantă a proiectului este trimiterea datelor 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 specificat. Î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 solicită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 date.

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.

Pentru a se realiza cu succes solicitarea, trebuie definite 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 conecteze 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

5. Concluzii

Concluzii

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 parolă. 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ă independent î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

[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/abstract/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. Zualkernan, "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/RFID

[10] Miorandi, D., Sicari, S., De Pellegrini, F., & Chlamtac, I. (2012). Internet of things: Vision, applications and research challenges. Ad Hoc Networks

https://www.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

[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/book/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/microservices-vs-monolith-architecture-4l1m

[32] Microservices vs Monolith: which architecture is the best choice for your business?

https://www.n-ix.com/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://store.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/fotorezistor-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/