MONITORIZARE DE LA DISTANT A A TEMPERATURII FOLOSIND TEHNOLOGII WEB PROIECT DE DIPLOMĂ Autor: Szilá rd Mate Conducător științific : SI.Dr.Ing. Mihai… [626307]

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
2017

MONITORIZARE DE LA DISTANT A A
TEMPERATURII FOLOSIND TEHNOLOGII WEB

PROIECT DE DIPLOMĂ

Autor: Szilá rd Mate

Conducător științific : SI.Dr.Ing. Mihai Hulea

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE

DECAN
Prof.dr.ing. Liviu MICLEA Vizat,

DIRECTOR DEPARTAMENT AUTOMATICĂ
Prof.dr.ing. Honoriu VĂLEAN

Autor : Szilárd Mate

MONITORIZARE DE LA DISTANTĂ A TEMPERATURII FOLOSIND
TEHNOLOGII WEB

1. Enunțul temei: Înregistrarea unor parametri din mediul înconjurător utilizând
tehnologii web.
2. Conținutul proiectului: Introducere, Studiu Bibliografic, Analiză, Proiectare,
Implementare și Testare, Concluzii

3. Locul documentației: Universitatea Tehnică din Cluj -Napoca extensia Satu -Mare

4. Consultant : SI.Dr.Ing Mihai Hulea

5. Data emiterii temei: 11.11.2016

6. Data predării: 11.07.2017

Semnătura autorului

Semnătura c onducător ului științific

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE

Declarație pe proprie răspundere privind
autenticitatea proiectului de diplomă

Subsemnatul(a) Szilá rd Mate ,
legitimat(ă) cu CI seria SX nr. 302362 , CNP [anonimizat] ,
autorul lucrării:
MONITORIZARE DE L A DISTANȚ Ă A TEMPERATURII FOLOSIND TEHNOLOGII WEB

elaborată în vederea susținerii examenului de finalizare a studiilor de licență
la Facultatea de Automatică și Calculatoare ,
specializarea Automatică și Informatică Aplicată (la Satu Mare) ,
din cadrul Universității Tehnice din Cluj -Napoca,
sesiunea Iulie 2017 a anului universitar 2016 -2017 ,
declar pe proprie răspundere că această lucrare este rezultatul propriei activități
intelectuale, pe baza cercetărilor mele și pe baza informațiilor obținut e din surse care au
fost citate în textul lucrării și în bibliografie.
Declar, că această lucrare nu conține porțiuni plagiate, iar sursele bibliografice au
fost folosite cu respectarea legislației române și a convențiilor internaționale privind
drepturile de autor.
Declar de asemenea, că această lucrare nu a mai fost prezentată în fața unei alte
comisii de examen de licență.
In cazul constatării ulterioare a unor declarații false, voi suporta sancțiunile
administra tive respectiv anularea examenului de licență .

Data Szilárd Mate
11.07.2017
(semnătura)

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
SINTEZA
proiectului de diplomă cu titlul:
MONITORIZARE DE LA DISTANTĂ A TEMPERATURII FOLOSIND
TEHNOLOGII WEB

Autor: Szilárd Mate
Conducător științific: SI.Dr.I ng Mihai Hulea

1. Cerințele temei:
Implementarea unei aplicații care permite captarea unor parametrii din mediul
înconjurător și înregistrarea acestora într -o bază de date. În final afișând datele
înregistrate într -o pagină web.
2. Soluții alese:
Utilizarea tehnologiilor web pentru a connec ta aplicații sine stătătoare, astfel rezul tând o
aplicație completă.
3. Rezultate obținute:
S-a opținut o aplicație ce permite înregistrarea temperaturii și umidității din mediul
înconjurător într-o bază de date, iar în final afișând datele culese prin intermediul uni
server Java într-o pagină web , sub forma unui grafic.
4. Testări și verificări:
Aplicația fost testată prin urmărirea datelor înregistrate de către microcontroller până la
afișarea lor în interfața vizuală.
5. Contribuții personale:
Implementarea aplicației de pe microcontroller, aplicați a de server Java, interfața vizuală
(pagina web).
6. Surse de documentare:
Cărți legate de limbajele de programare C și Java; documentație online legată de biblioteca
Angular.
Semnătura autorului
Semnătura conducătorului științific

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE

1
Cuprins
1 INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. 3
1.1 CONTEXT GENERAL ………………………….. ………………………….. ………………………….. …………………….. 3
1.2 OBIECTIVE ………………………….. ………………………….. ………………………….. ………………………….. …… 4
1.3 SPECIFICAȚII ………………………….. ………………………….. ………………………….. ………………………….. … 5
2 STUDIU BIBLIOGRAFIC ………………………….. ………………………….. ………………………….. ……………….. 6
2.1 C ………………………….. ………………………….. ………………………….. ………………………….. ……………… 6
2.1.1 Introducere în C ………………………….. ………………………….. ………………………….. …………………. 6
2.1.2 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. . 6
2.2 JAVA ………………………….. ………………………….. ………………………….. ………………………….. …………. 7
2.2.1 Introducere în Java ………………………….. ………………………….. ………………………….. …………….. 7
2.2.2 Thread ………………………….. ………………………….. ………………………….. ………………………….. .. 10
2.2.3 Socket ………………………….. ………………………….. ………………………….. ………………………….. … 10
2.2.4 Concluzii ………………………….. ………………………….. ………………………….. …………………………. 11
2.3 ANGULAR ………………………….. ………………………….. ………………………….. ………………………….. ….. 12
2.3.1 Introducere în Java Script ………………………….. ………………………….. ………………………….. ….. 12
2.3.2 Angular ………………………….. ………………………….. ………………………….. ………………………….. 12
2.3.2.1 Legare a Datelor ………………………….. ………………………….. ………………………….. ………………………. 12
2.3.2.2 Controller ………………………….. ………………………….. ………………………….. ………………………….. ….. 13
2.4 CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. … 14
3 ANALIZĂ ………………………….. ………………………….. ………………………….. ………………………….. ……. 15
3.1 COMPONENTELE HARDWARE ALESE ………………………….. ………………………….. ………………………….. … 15
3.1.1 Micro Controllorul ………………………….. ………………………….. ………………………….. ……………. 15
3.1.2 Accesorii pentru micro controllor ………………………….. ………………………….. ……………………. 16
3.1.3 Router Wireless ………………………….. ………………………….. ………………………….. ……………….. 17
3.1.4 Unitate centrală ………………………….. ………………………….. ………………………….. ………………. 17
3.2 APLICAȚIILE SOFTWARE ALESE ………………………….. ………………………….. ………………………….. ……….. 17
3.2.1 Ardruino IDE ………………………….. ………………………….. ………………………….. ……………………. 17
3.2.2 Medi ul de dezvoltare Eclipse ………………………….. ………………………….. …………………………. 18
3.2.3 Mediul de dezvoltare Webstorm ………………………….. ………………………….. …………………….. 19
3.2.4 Aplicația pentru Baza de Date ………………………….. ………………………….. ……………………….. 19
3.3 CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. … 20
4 PROIECTARE ………………………….. ………………………….. ………………………….. ………………………….. . 21
4.1 DISPOZITIVUL ………………………….. ………………………….. ………………………….. ………………………….. 21
4.2 COLECTORUL DE DATE ………………………….. ………………………….. ………………………….. ……………….. 21
4.3 BAZA DE DATE MYSQL ………………………….. ………………………….. ………………………….. ……………… 21
4.4 BACK END JAVA ………………………….. ………………………….. ………………………….. ………………………. 23
4.5 PAGINA WEB ………………………….. ………………………….. ………………………….. ………………………….. 25
5 IMPLEMENTARE ȘI TESTARE ………………………….. ………………………….. ………………………….. ……… 26
5.1 ETAPA 1 ………………………….. ………………………….. ………………………….. ………………………….. …… 26
5.2 ETAPA 2 ………………………….. ………………………….. ………………………….. ………………………….. …… 27
5.3 ETAPA 3 ………………………….. ………………………….. ………………………….. ………………………….. …… 30
5.4 ETAPA 4 ………………………….. ………………………….. ………………………….. ………………………….. …… 36
5.5 TESTAREA APLICAȚIEI ………………………….. ………………………….. ………………………….. ………………… 39

Introducere
2 6 CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. …. 40
6.1 REZULTATE OBȚINUTE ………………………….. ………………………….. ………………………….. ………………… 40
6.2 DIRECȚII DE DEZVOLTAR E ………………………….. ………………………….. ………………………….. …………….. 40
7 BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. …………………………. 42

Introducere
3
1 Introducere
1.1 Context general
Această lucrare are ca scop realizarea unei apli cații ce permite monitorizarea ș i
înregistrarea unor parametr i din mediul înconjurător cum ar fi , de exemplu , temperatura,
umiditatea, luminozitate etc. Aceste date trebuie înregis trate într -un mediu de stoc are cu
caracter permanent, ca în ori ce moment de timp toate datele î nregistrate sa fie accesibile
si prezentate unui operator uman sub forma unor grafice , tabele sau alte moduri de afișare
ce permit o analiză uș oară si eficientă.
Există diferite soluții pentru un asemenea sistem , dar, în cazul nostru , o să apelăm
la tehnologii web , deoarece aceasta oferă avantaje distincte față de celelalte metode de
comunicare .
Pentru comparatie o sa luam standardul RS -232 [1, p. 1] rasp ândit în industrie.
Această metoda de co municare este una foarte simpla, ieftin de implementat, robustă si
foarte bine testată de -a lungul anilor. Dar , ca orice altă soluție are niște limitări , cum ar fi
faptul că acest standard are nevoie de conectori speciali de 25 , respectiv 9 pini [1, p. 3] ce
nu se regăsește în calculatoarele uzuale folosite de către utilizatori în domenii diferite de
industrie (contabilitate, agricultură) . O altă problemă ar fi faptul că emițătorul si
receptorul trebuie conectați fizic cu cablaj ce restrictionează posibilitățile de poziționare
a dispozitivului . În cazul în care avem mai multe dispozitive care monitorizează mediul
înconjurător , atunci devine d ificil conectarea acestora deorac e există posibilitatea ca la
conectare să se co necteze greșit dispozitivele.
Spre deosebire , tehnologiile web permint o im plementare mai ieftină si redusă în
complexitate , deoarece acestea sunt răspândite și utilizate în orice dispozitiv uzual
întâmpinat , cum ar fi telefoane, leptopuri, calculatoare personale etc. Un alt avantaj major
este posibilitatea de a elimina cablajel e, astfel folosind tehnologii fără fir specific fa miliei
802.11 c are cuprinde standardele 802.11a, 802.11b, 802.11g iar poartă numele uzual de
„Wi-Fi” [2, p. 3] . Dacă conectarea dispozitivelor se realizează fară fir , atunci acestea pot fi
pozitionate în zone mai greu accesibile . Desigur , trebuie ținut cont de factorii ce
influențeaza comportamentul undelor radio detaliate în [2, pp. 15 -24].
Comunicarea este doar o parte din problemă. O al tă problemă este constituită din
mediul de stocare a datelor. Există posib ilitatea de a stoca informația î ntr-un fișier pe un
calculator, dar aceasta nu ar fi optimă și din , acest motiv , o să se folosească o bază de date ,
deoarece aceasta oferă avantaje majore. Una dintre aceste avantaje este str ucturarea
ușouară a informației î n tabele , astfel având o reprezentare clară și lizibilă pentru un
operator uman. Un alt avantaj este faptul că baza de date se poate afla la o locație complet
diferită , iar, în cazul unui incendiu sau la apariția altor accidente neprevăzute date le
înregistrate sunt în siguranț ă. Folosind limbajul SQL (Str uctured Query Language) putem

Introducere
4 să accesăm doar informații specifice , astfel lăsând baza de date să lucreze pentru găsirea
informației.
Odată ce am stocat informația , trebuie să avem un mod de a prelucra datele
înregistrate. Pentru aceasta o să se folosească un limbaj avansat de programare Java.
Pornind de la citatul „Like any human language, Java provides a way to express concepts.
If successful , this medium of expres sion will be significantly easier and more flexible than
the alternatives as problemes grow larger and more complex.” [3, p. 27] . S-a ales acest
limbaj , deoarece este un limbaj flexibil și ușor de adaptat pentru orice situatie. Fiind
utilizat pentru diverse aplicații , inclusiv în rețelistică , aceasta oferă un su port foarte bun
pentru comunicații prin rețea.
Odată ce am proces at informația , ea va fi trimi să și afișată într -o pagină web. S -a ales
pagina web , doarece este o formă versatilă , ușor adaptabilă pentru orice scop. Are un
avantaj major , comparat cu aplicatiile tradiționale și anume sunt vizualizabile de pe orice
dispozitiv ce are un browser instala t, de exemplu: telefoane, tablete, calculatoare.
Am ales această lucrare , deoarece , după realizarea ei, se va putea folosi în diferite
domenii si aplicații , unde pot fi monitorizați parametri diferiți din mediul înconjur ător,
iar din analiza acest or parame tri este posibilă tragerea unor concluzii din care să rezulte
o înbunătă țire.
1.2 Obiective
Pentru această lucrare avem următoarele obiective:
• Crearea unei aplicatii pentru un microcontroller , care este capabil să citeasca
temperatura , respectiv umiditatea mediului înconjurător, după care aceste
citiri să fie transmi se la o aplicatie Java prin protocolul TCP/IP [2, pp. 33 -34]
(Transmission Control Protocol , Internet Protocol ) folosind metode de
comun icare fară fir.
• Crearea unei aplicatii Java c are este capabil ă de a recepționa și interpreta
mesajul primit de la microcontroller , urmând ca datele să fie înregistrate
într-o bază de date.
• Crearea baze i de date relation ale, care are o structură clară și uș or de
urmărit.
• Crearea serve rului (back -end) care este capabil de a accesa și proces a datele
stoc ate î n baza de d ate, iar î ntr-un final trimiterea datelor procesate la o
pagină web (front -end) .
• Crearea de pagini web , astfel încât să aibă o reprezentare a datelor procesate
foarte clară și ușor interptretabilă pentru un operator uman .

Introd ucere
5 1.3 Specificații
Pentru acest proiect avem impuse urmatoarele specificatii:
• Comuncarea între micro controller și aplicatia java trebuie să se realiz eze
folosind tehnologii web far ă fir (Wi -Fi).
• Microc ontroll erele trebuie să fie ușor adaptat e pentru diferiți senzori ce
măsoară parametri diferiți.
• Aplicația de Back End trebuie să fie capabil ă să gestioneze diferite mesaje
primite de către un micro controller și să fie capabil ă de a crea tabele
corespunzătoare .
• Aplicatia Java trebuie s ă receptio neze date de la mai multe micro controllere
difierite și să insereze datele în tabelele corespunzatoare în baza de date.
• Aplicația web trebuie să fie accesibilă de pe dispozitive mobile , prin urmare
aceast a presupune ca pagina să fie compatibilă cu mai multe browsere.
• Serverul trebuie să proceseze cerințele de la client într -un timp util sub
200ms.

Studiu bibliografic
6
2 Studiu bibliografic
2.1 C
2.1.1 Introducere în C
Limbajul procedural C este unul foarte răspândit ș i utilizat în multe domenii , inclusiv
în industrie , unde este folosit în special pentru programarea sistemelor embeded.
Acest limbaj este următoarea iterație a limbajul „B” , care a fost dezvoltat de către
Ken Thompson în 1970 pentru sistemul de operare UNIX [4]. Spre deosebire de
precursorul lui , apar unele îmbunătațiri , cum ar fi tipuri de date (caractere, într egi,
numere cu virgulă flotantă etc.), expresi ile formate din operatori ș i operanzi, iar poate cea
mai semnificativă pointeri [4]. Pointerii ne permit să accesăm direct memoria sistemului ,
astfel este posibilă obț inerea unei aritmetici de adre sarea memoriei independente de
sistem [4].
Orice cod scris în limbajul C trebuie compilat, convertit într -un alt format
interpretabil de către sistemul pe care este intenționat să ruleze. În cazul sistemelor de
operare Windows se generează un executabil.
Avantaje:
a) Codul compila t se poate rula fără alte extra operații.
b) Limbajul fiind puternic tipizat la momentul execuției se cunosc toate tipurile
de date , rezultând o rulare mai rapidă .
c) Avem acces „low level” [4] la memoria sistemului , astfel putem să îl
gestionăm mai efici ent.
d) Codul sursă se poate împărți pe funcții, proceduri ; fiind ușor interpretabil
pentru un operator uman.
Dezavantaje:
a) Codul sursă trebuie recompilat dacă se schimbă platforma . Exemplu de la
Windows la Linux.
b) Gestionarea greșită a memoriei poate să ducă l a poluarea acestuia când
spațiul alocat nu este eliberat după utilizare .
2.1.2 Concluzii
Putem să deducem că limbajul C este ideal pentru sisteme pe microchip deoarece
este una simplă , nu necesită foarte multă memorie și a fost bine testată de -a lungul anilor.
Faptul că codul C este compilat direct în limbaj de asamblare aceasta oferă performanțe
ridicate , deoarece se poate lansa direct în execuție fără a fi nec esar interpretarea codului
ca în cazul limbajului Java.

Studiu bibliografic
7
2.2 Java
2.2.1 Introducere în Java
Java este un liba j de programare orientat pe obiecte cu similarități între C, C++ dar
cu diferite implementări pentru soluții [5].
Pornind de la citatul „Object -oriented programing appeals at multiple levels. For
managers, it promises faster an d cheaper development and maintenence. For analyst and
designers, the modeling process becomes simpler and produces a clear and manegeable
design.” [3] putem concluziona că acest limbajd orientat pe obiecte ne permite modelarea
mai ușoară și eficientă a situațiilor reale , astfel reducând costul și timpul necesar pentru
dezvoltarea aplicației, iar rezultatul obținut va fi unul clar și ușor de întreținut.
Limbajul este puternic tipizat ca și C, dar , find un limbaj orientat pe obiecte , oferă o
flexibilitate ridicată cea ce priveste tipuri le de date , deoarece putem să declarăm propriile
noastre tipuri cu ușurință , lucru ce este mai dificil în C.
Fiind un limbaj „high -level” [5] developeri i nu trebuie să -și facă griji de gestionarea
memoriei s au alocarea resurselor hardware , aceastea f iind gestionat de către Mașina
Virtuală Java.
Spre deosebire de C , unde codul este compilat și executat . Codul Java este compilat
în byte code , iar la rulare mașina virtuală interpretează codul compilat , dupa care alocă
resursele necesare pentru rularea acestuia ilustrat în Figura 2.1.

Studiu bibliografic
8
Figura 2.1 Progre sia codului sursă până la execuție
Acest lucru oferă un avantaj major , deoarece același cod scris pe o platforă este
intercompatib il cu o altă platformă fără să fie necesar recompilarea acestuia. Este destul
ca Mașina V irtuală Java să fie adaptată pentru platforma respectivă. Astfel , din punctul de
vedere al unui developer , nu este nici o diferență dac ă acest cod a fost scris sub platforma
Windows sau Linux.
Un alt aspect diferit față de alte limbaje de progr amare este structurarea codului –
sursă. Spre deosebire de C , unde codul se scri e într -un fișier; în Java codul -sursă se scrie
în clase , iar aceste clase sunt plasate în pac hete (package) diferite ce perm it organizarea
codului într-un mod clar și transparent ilustrat în Figura 2.2.

Studiu bibliografic
9
Figura 2.2 Organizarea pachetelor
La rândul lor clasele sunt foarte importante deoarece acestea conțin descrierea unui
obiect. O exemplificare ar fi modelarea unei surse de lumină [3, p. 44] prezentat în Figura
2.3.

Figura 2.3 Modelarea surse i de lumină
Dupa cum este ilustrat , numele tipului este „Light” și are urmatoarele metode (funcții) , ce
corespund interacțiunilor posibile asupra acestui obiect: on(), off(), brighten(), dim(). În
clasa „Light” am definit obiectul , dar, ca să îl putem folosi , este necesar ă crearea acestuia

Studiu bibliografic
10 folosind un constructor . Constructorul este o metodă mai specială , aceasta în fiecare caz
poartă numele tipului . În exemplul [3, p. 44] prezentat mai jos este exemplificat ă crearea
unui obiect no u folosind cuvântul cheie „new”, apelarea unei metode caracteristice
obiectului respectiv .
Light lt=new Light();
lt.on();
2.2.2 Thread
Pornind de la citatul „Objects provide a way to divide a pr ogram up into independent
sections.” [3, p. 599] . Programarea orientată pe obiecte ne permit e divizarea problemei
pe mai multe sarcini secundare , care pot să ruleze simultan astfel crescând semnificativ
viteza de execuție . Aceste sarcini secundare se numesc threaduri.
Conform [3, p. 599] fiecare thread rulează individual și are acces la proccesor doar
pentru el. Trebuie să facem diferența între un proces și un thread. Un proce s este un
program sine stătător cu propria sa zonă de memorie. Un sistem de operare avansat poate
să ruleze mai multe procese în același timp alocând periodic cicluri de tact fiecărui proces.
Un thread este doar o singură buclă dintrun process, rezultă deci că un proce s poate să
aibă mai multe threaduri.
Desigur trebuie să avem g rijă cum gestionăm threadurile , deoarece nu ficecare
aplicație benfeiciează sau este capabil ă să exploateze mai multe threaduri. În primul rând ,
trebuie sa ne gândim la limitările fizice. Un procesor cu un singur nucleu nu este capabil
să exploateze în întregime beneficiul oferit de mai multe threaduri deoarece ele vor
concura pentru acces la procesor. Chiar dacă avem mai multe nuclee , trebuie să avem grijă
de problemele de concure nță. Spre deosebire de un proce s (program) threadurile au
alocate ace eași zonă de memorie ca și procesul din care fac parte. Există posibilitatea ca
două threaduri să acceseze aceași ad resă de memorie în același timp astf el depinzând de
situație sar putea să avem date corupte .

2.2.3 Socket
Conform [3, p. 658] putem să considerăm socketurile ca o abstracție folosită pentru
a reprezenta terminale le unei conexiuni între două mașini. Pentru fiecare conexiune
există un cablu imaginar ce leagă așa -zisele capete, dar n u se cunoaște modul și ruta prin
care sunt legate aceste terminale sau cu numele lor comun calculatoare.
În Java este posibil crearea unui ServerSocket [3, p. 659] care poate să aștepte
pentru conexiuni. În momentul când un client se coneactează la socketul de tip server
atunci comunicarea bidirecțională devine posibilă.
Pentru a realiza o c onexiune este necesar ca server -socketul să aibă definit un port
iar clientul să cunoască atât adresa ip cât și portul acestuia.

Studiu bibliografic
11 2.2.4 Concluzii
Avantaje:
a) Modelarea ușoară a situațiilor reale .
b) Aplicații compatibile cu mai multe platforme .
c) Obiectele create pot fi reutilizate .
d) Permite rulearea a mai multor subaplicații cu ajutorul threadurilor .
e) Socketurile oferă o comunicare robustă dar sigură .
f) Support nativ pentru parsarea de XML ( Extensible Markup Language ).
g) Compilatorul Java obligă dezvoltatorul uman să trateze eventualele erori.
Dezavantaje:
a) Pentru a rula aplicații Java este nevoie de JRE (Java Runtime Envoirment) .
b) Pentru rularea aplicațiilor Java sunt necesare mai multe resure comparat cu
un program scris in C.
c) Threadurile dacă nu sunt gestionate corespubzător atunci pot cauza
probleme de concurență.
Putem să concluzionăm că Java este un limbaj optim de programare ce permite să
neglijăm unele aspectele hardware cum ar fi gestinoarea memoriei iar în același timp să
reducem complexitatea problemelor folosind metodele puse la dispoziția noastră.

Studiu bibliografic
12
2.3 Angular
2.3.1 Introducere în Java Script
Conform [6, p. 2] Java scriptul sau după numele original „LiveScript” [6, p. 2] este
un limbaj de programare dinamic ce necesită puține resurse. Din acest motiv a fost
integra t în browserele web , astfel oferă un caracter mai dinamic paginilor web .
Oferă următoarele avantaje:
a) Mai puțină interacțiune cu serverul : Există posibilitatea de a valida
datele înainte ca acestea să fie trimise, astfel reducând traficul de
internet.
b) Rezultate instantante: Utilizatorii nu trebuie să aștepte ca o pagină să se
reîncarce în cazul în care au uitat să introducă ceva.
c) Interactivitate marită: Există posibilitatea de a crea interfețe care
reacționează la inputurile utilizatorilor.
d) Interfețe bogate : Utilizând JavaScript se pot include funcționalități ca și
drag and drop, sau slideuri.
Desigur acest limbaj are și limitările sale:
a) Din motive de securitate nu este permisă citirea și scriera în fișiere.
b) Nu avem support pentru a hosta o aplicație sau pa gină web.
c) Nu este capabil de multithreading.

2.3.2 Angular
Angular este o extensie a JavaScriptului care conform documentației [7] permite
extinderea codului HTML (Hyper Text Markup Language) și comportamentul aplicației ,
încât aceasta să fie mai bine structurată. Legarea datelor și injectarea de pendențelor
elimină foarte multe operații ce pot cauza erori dacă nu sunt implementate correct,
mărind claritatea codului. Toate acestea se înt âmplă în interiorul browserului.
Pentru a explica conceptele noi aduse de Angular o să folosim figuri preluate din
documentatia online [7].
2.3.2.1 Legarea Datelor
Angular implementeaza un concept numit „data -binding” [7], care permite
realizarea legăturii dintre model și view interfața grafică a aplicației.

Studiu bibliografic
13
Figura 2.4 Legarea datelor [7]

În figura de mai sus este prezentat grafic cum modelul, adică reprezentarea internă
a datelor , este legat de către un view, în acest caz de un element de tip „ input” plasată
într-o pagină HTML.
2.3.2.2 Controller
Desigur doar legarea datelor nu oferă nici un avantaj față de o pagină statică și din
acest motiv se introduce ș i un controller. Acest controller permite manipularea datelor
stocate în model iar în final aceasta atrage modificări la view prezentat în figura de mai
jos.

Figura 2.5 Model -View -Controller [7]

Studiu bibliografic
14 Folosind un controller putem să aplicăm unele conversii ca transformarea dintre
millimetri în centimetrii sau alte operații aritmetice simple , cum ar fi calculul unei arii.
Astfel reducem dependența noastră de un server și putem să reduc em traficul de internet.
Nu trebuie să ne bazăm în întregime pe acest concept , deoarece din cauza faptului
că această bibliotecă are la bază java script, suferă de limitările acestuia. Există
posibilitatea ca u n volum exagerat de mare de date să cauzeze probleme chiar și pentru
cel mai bine optimizat algoritm de calcul.
2.4 Concluzii
Putem să tragem concluzia că această bibliotecă oferă avantaje enorme în a crearea
pagini lor web interactive . Implementarea conceptului de model -view -controller
compensează pe ntru limitările java scriptului; reduc ând timpul de dezvoltare necesar , ce
permit e procesarea datelor într -o manieră transparentă și ușor de urmă rit.

Analiză
15 3 Analiză
Pentru a realiza acest proi ect este necesar să dispunem atât de câteva componente
hardware , cât și niște componente software.
• Pentru par tea fizică a proiectul este necesar să avem un dispozitiv capabil să
înregistreze temperatura și să trimită înregistrările prin Wi -Fi.
Un calculator u zual ce dispune de un procesor, ram, placă de rețea și cel puțin
un mediu de stocare destul de mare , aceasta f iind capabil să stocheze toate
aplicațiile, baza de date dedicata pentru înregistări.
• Pentru partea de software o să avem nevoie de trei medii de dezvoltare
distincte , care , la rândul lor , se specializează pentru urmă toarele nevoi:
programare micro controller, dezvoltare aplicații Java, dezvoltare a interfeței
vizuale prezentate în pagina web.
Mai este necesar ă utilizarea unei aplicatii specializate pentru menținerea
bazei de date.
3.1 Componentele hardware alese
Pornind de la nivelul cel mai de jos , s-au ales următoarele componente pentru a
realiza dispozitivul:
3.1.1 Micro Controllorul
Atmega328P -PU este micro controllerul ales , deoarece conform fișei tehnice [6]
aceasta est e capabil să opereze la tensiuni de la 1,8V până la 5,5V astfel existând
posibilitatea de a fi alimentat de la o baterie externă.
Folosind trei baterii tipice Varta AAA [7] legate în serie obținem o tensiune de
alimentare de 4.5V cu o capacitate de 3600 mAh.
Conform figurii 34 -2 „Atmega328P: Active Supply Current vs Frequency (1MHz –
20MHz)” [6, p. 404] putem să citim că la tensiunea de alimentare de 4.5V și la frecventa
maxima a integratului de 20MHz consumul de curr ent este de 10mA.
Din aceste date putem sa deducem aproximativ cât timp este posibil să opereze
micro controllorul la capacitate maximă făcând abstracție de alți consumatori ce trebuie
alimentați ca și traductorii, emițătorul sau rezistența internă a bater iei.
𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑎𝑡𝑒𝑎 𝑏𝑎𝑡𝑒𝑟𝑖𝑖𝑙𝑜𝑟
𝐶𝑜𝑛𝑠𝑢𝑚 𝑀𝑖𝑐𝑟𝑜 𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑜𝑟=3600 𝑚𝐴ℎ
10𝑚𝐴=360ℎ
Desigur există diferite moduri de a mări timpul de operare dacă punem
microcontrollorul într -un mod de hibernare între citiri, sau să reducem frecvența
procesorului . Metodele menționate ar permit e conservarea energiei.
Un alt avantaj oferit de către acest micro controller sunt cei 6 pini analogici și 14 pini
digitali dintre care 6 suportă și PWM (Pulse Width Modulation). Astfel există posibilit atea
de a expanda cu mai mulți senzori atât digitali cât și analogici. Datorită acestei versatilități
putem masura o gamă largă de parametri.

Analiză
16 3.1.2 Accesorii pentru micro controllor
Un micro controllor nu ne este de niciun folos dacă nu îl putem programa. Pentr u a
realiza acest lucru , o să se folosească o placă de dezvolter Ardruino Uno ce conține atât
integratele spcializate , cât și aplicația soft necesară pentru programarea acestuia. Un alt
avantaj oferit de această placă de dezvoltare es te accesul ușurat la p ini
microcontrolle rului , astfel nu este nec esar cositorirea legăturilor. În figura de mai jos este
prezentat placa de dezvoltare împreună cu microcontrollorul.

Figura 3.1 Ardruino Uno [10]
Un alt avantaj oferit de către aceasta placă este faptul că funcționalitatea acestuia
poate fi extinsă cu alte plăci compatibile. În cazul nostru avem la dispoziție o placă
dedicată pentru comunicare fără fir prezentată în figura de mai jos.

Figura 3.2 Wi-Fi Shield [11]

Analiză
17 Placa prez entată ușurează procesul de dezvoltare , deoarece este capabil să se
conecteze la orice Router Wi reless disponibil pe piață. Un alt avantaj su nt bibliotecile
oferite ce permit recucerea complexității codului , astfel reducând timpul necesar pentru
depanare și dezvoltare.
Pentru a masura temperatura și umiditatea o să se folosească senzorul DHT11 care
conform specificațiilor tehnice [12] este capabil să măsoare temperatura în gama 0 -50 C°
cu o eroare de ±2 C° iar umiditatea în gama 20 -90 % cu o eroare de ±5% . Acest senzor nu
este destul de precis pentru uz în indu strie sau pentru cercetări științifice , dar este destul
pentru a fi folosit întro încăpere închisă cum ar fi o cameră de apartament .
3.1.3 Router Wi reless
Deoarece placa de extensie wire less prezentat în capitolul anterior este capabil să
se conec teze la orice router wire less uz ual s -a ales unul rudi mentar cu marka „Tenda”
care este compatibil cu standardul 802.11 la o frecvență d e 2.4 GHz .
3.1.4 Unitate centrală
Pentru unitatea centrală care va fi responsabilă cu rularea tuturor aplicațiilor
software pentru care s-a ales un calculator uzu al cu componentel e tipice proce sor cu
patru nuclee , memorie amplă de 8 GB , hard -disk cu o capacitate de stocare de 1TB și
dispune de o placă de rețea . Într -un final dispunem de t oate perifericele necesare pentru
operarea acestuia .
3.2 Aplicațiile software alese
3.2.1 Ardruino IDE
Pentru programarea micro controllorului s -a ales aplicația oferită de prducătorii
plăcii de dezvoltare Ardruino Uno adică Ardruino IDE (Integrated Development
Enviorment) versinuea 1.0.3 , prezentat în Figura 4 .3 care ne permite compilarea și
încărcarea codului sursă scris în limbajul de programare C .

Figura 3.3 Mediul de dezvoltare Arduino IDE

Analiză
18 Dispunem de funcționalități de bază cum ar fi colorarea textului , verificare pentru
erori de compilare și dispune de o aplicție numită „Serial Monitor” ce permite
monitorizarea porturilor seriale prezentat în Figura 4.4 . Această funcționalitate ne
permite monitorizarea și depanarea programului inscripționat pe micro controllor prin
utilizarea unor mesaje de tip text .

Figura 3.4 Serial Monitor
3.2.2 Mediul de dezvoltare Eclipse
Pentru dezvoltarea aplicației Java s -a optat pentru mediul de dezvoltare „Eclipse
Neon” versiunea 4.6.1 prezentat în Figura 4.5 . Acest mediu conț ine toate uneltele
necesare pentru a scrie cod sursă în limbajul de programare Java.

Figura 3.5 Mediul de dezvoltare Eclipse Neon
Este important de menționat faptul că acest mediu de dezvoltare nu conține mașina
virtuală java și nu este capabil să ruleze cod Java. Pentru a remedia această problemă

Analiză
19 trebuie descărcat separat JDK 1.8 (Java Development Kit) care conține mașina virtuală ș i
are niște funcțio nalități spciale pentru develope ri cum ar fi lansare în mod de depanare.
3.2.3 Mediul de dezvoltare Webstorm
Pentru dezvoltarea pagini web, interfața vizuală a proiectului s -a optat pentru
programul „WebStrom” versiunea 2017.1.4 care oferă sup port excelent pentru integrarea
codului HTML cu JavaScript prezentat în figura de mai jos.

Figura 3.6 Mediul de dezvoltare WebStorm
Utilizând acest mediu de dezvoltare beneficiăm de niște funcționalități ce ușurează
dezvoltarea aplicației. Una dintre ele ar fi integrarea excelentă a codului HTML cu
JavaScriptul sau faptul că această aplicație hostează pagina web în rețeaua locală , fiind
accesibilă la toate dispozitivele conectate la rețeaua locală.
Doar acea stă aplicație nu este suficientă pentru dezvoltare , pentru a testa și dezvolta
o pagină web trebuie să dispunem de un browser web care este capabil de un mod de
depanare cum ar fi „Google Chrome”. Apăsând tasta „F12” dispunem de consola
browserului și de alte scule ce pot ajuta la depanarea interfeței vizuale.
3.2.4 Aplicația pentru Baz a de Date
Pentru a întreține baza de date , o să utilizăm o aplicația „XAMPP” versiunea 3.2.2
prezentat în Figura 4.7 . Acest program permite rularea unei baze de date MySQL,
rezolvând toate problemele ce țin de stocarea datelor. Folosind un limbaj avansat de
programare ca de exemplu Java ajunge să trimitem doar instrucțiuni SQL (Structured
Query Language) ce sunt niște instrucțiuni formulate sub formă de te tip String (șir de
carac tere).

Analiză
20
Figura 3.7 Aplicația XAMPP
3.3 Concluzii
Toate aceste componente pot să realizeze sarcini diferite și sunt capabile să
funcționeze independent. O dată ce le conectăm și aceștia comunică între ele , putem să
obținem o aplicație funcțională. Exista diferite metode de a realiza conexiunea , dar
tehnolo giile web ne permit transmiterea datelor fără a fi neccesar a daptoare speciale.
Astfel existând posibilitatea de a transmite date de la un microcontroller simplu la un
program avansat ce poate să interpreteze aceste date și să le transmită mai departe
folosind tot tehnologii web la o interfață visuală.

Proiectare
21 4 Proiectare
Prin utilizarea atât a componetelor fizice cât și a medilor de programare aflate la
dispoziția noastră o să se realizeze aplicația conform diagramei prezentate în Figura 5.1 .

Figura 4.1 Schema bloc
4.1 Dispozitivul
Va conține ansamblul de părți microcontroller , placa de dezvoltare ardruino uno, Wi –
Fi Shield ul cu toate conexiunile realizate. Aceasta va fi conectat ă printr -un cablu USB
(Universal Serial Bus) la unitate realizând alimentare a și posibilitatea de depanarea a
acestuia. Odată alimentat dispozitivul se va conecta automat la routerul wi reless și va
începe să transmită citiri către Collectorul de Date. Pentru a transmite datele , a fost ales
formatul XML , deoarece aceasta ne permite organizarea ierarhică a datelor. Un alt avantaj
major ar fi că este ușor interpretabil pentru oameni , ne permite vizualizarea datelor
primite fără să se execute operații complexe de transformare a datelor. Ca o ultimă
mențiune , Java oferă biblioteci bine testate pentru prelucrarea informației primite sub
forma unui XML.
4.2 Colectorul de Date
O clasă dedicată Java care are un singur scop. Acceptarea conexiuni i dintre unul sau
mai multe microcontrollere , să interpreteze informația primită sub forma unui mesaj
XML , iar în final să insereze datele interpretate în tabele corespunzătoare din baza de
date. Aceasta va exstinde clasa Thread și va rula independent de serverul care deservește
pagina web.
4.3 Baza de Date MySQL
Mediul de stocare cu ca racter permanent a datelor. Ace sta va fi unul relațional în care
tabela principală va conține to ate dispozitivele prezentat în F igura 5.2. Pentru fiecare
dispozitiv va exista o tabelă proprie , iar numele tabelei o să coincidă cu numele
dispozitivului. Astfel putem să ținem tabele individuale și distincte pentru fiecare
dispozitiv.

Proiectare
22
Figura 4.2 Structura tabelei p rincipale
În această tabelă o să se stocheze datele referitoare la toate dispozitivele actuale.
• Coloana Id va fi cheia primară și aceasta va fi creat ă de către baza de date.
• Coloana Ip va conține adresa I p versiunea 4 a dispozitiv ului actual.
• Numele dispozitivului fa fi stocat în coloana DeviceName aceasta fiind folosit
pentru a referi celelalte tabele.
• Battery Status este un câmp folosit pentr u a stoca starea bateriei care
alimentează microcontrolle rul, dar , fiindcă în cazul actu al nu este necesar
monitorizara acestui aspect , ea va fi configurat să fie Null.
În acest caz particular pentru reprezenta rea dispozitiv ului o să se folosească structura de
tabel prezentată în figura de mai jos.

Figura 4.3 Tabelă dispozitiv
• Coloana Id este cheia primară și are un rol foarte important ce va fi detaliat
în capitolul de Implementare.
• Temp respectiv Hum sunt coloanele ce vor conține înr egistrările primite de
la microcontrolle r. Temperatura va fi stocată în celsius iar umiditatea în
procent e.
• Coloana InsertionTime reprezintă data inserări i în baza de date. Deoarece
un microcontrolle r nu este foarte precis în măsurarea timpului , s-a optat ca
timpul înregistrării să fie considerat m omentul în care s -au ins erat datele în
baza de date. Unul dintre avantaje ar fi că sistemul de operare tot timpul
menține timpul sincronizat și mută autom at ceasul cu o oră mai în față, lucru
ce ar putea fi uitat de către operatori umani .
S-a optat pentru această structură , deoarece ficare dispozitiv poate măs ura
parametri diferiți al mediului înconjurător , astfel , dacă reușim să realizăm o aplicație
inteligentă , aceasta poate să cr eeze tabele specifice pentru fiecare dispozitiv în parte.

Proiectare
23 4.4 Back End Java
Aceasta este una dintre cele mai complexe părți ale aplicației , deoarec e trebuie să
realiz eze diferite sarcini importante.
Principalul rol pe care îl are serverul este de a deservi o pagină web , el fiind capabil
să proceseze toate requesturile primite prin p rotocolul HTTP. După ce a primit și a
interpretat requestul aceasta , trebuie să formuleze un răspuns în formatul JSON (Java
Script Object Notation) și să îl trimită către pagina web.
Pentru aplicația currentă s -au impus următoarele funcționalități de bază :
• Să transmită ultima înregistrare realizată pentru dispozitivul selectat.
• Să calculeze media de temperatură, umiditate pe o perioadă de timp setată
din interfața viz uală .
• Să prelucreze informația astfel încât aceasta să se ploteze pe un grafic.
• Să trasnmită toate datele din grafic sub formă tabelară pentru o
previzualizare mai detaliată.
Ca să realizăm fu ncționalitățile menționate , aplicația trebuie să aibă capabil itatea de
a se conecta la baza de date și de a accesa toate înregistările. Pentru a reduce numă rul de
queryuri o să se impementeze un cache care o să stoc heze to ate înregistrările aflate în
baza de date. Aceasta ne oferă un avantaj major deoarece memoria sistemului este una
foarte rapidă iar când trebuie executate calcule cum ar fi media aritmetică sau comparații
atunci nu mai trebuie să așteptăm după baza de date , deoarece avem deja majoritatea
informației la îndemână .
Pentru a reprezenta informația în memoria sistemului , o să se utilizeze obiectul
ReadingEntry ce va conține o înregistr are, structura detaliată va fi prezentat ă la capitolul
următor. În principiu o să se folosească următoarele tipuri pentru reprezentarea datelor:
• int pentru Id ace sta are un rol important în ce privește updatarea cacheului;
va fi detaliat în capitolul următ or.
• float pentru a repreze nta atât temperatura cât și umiditatea.
• Date pentru a reprezenta data înregistrării.
Din moment ce persităm datele și în memoria sistemului se pune problema consumului
de memorie . Pentru a calcula acest consum o să ne referim la t abelul aflat în [3, p. 74]
pentru a vedea câți biți sunt necesari pentru fiecare tip. Pentru a reprezenta un număr
de tip int avem nevoie de 32 biți iar pentru reprezentarea unei număr cu virgulă flotantă
sunt necesar tot de 32 biți. Obiectul de tip Date stochează timpul într-o variabilă de tip
long ce necesită 64 de biți. Astfel costul total al fiecărei înregistrări este de 160 de biți
care se reduc la 20 byte. Dacă înregistrăm date odată la 5 minute , conform calculelor
prezentate mai jos , într-un an s -ar expanda cacheul cu aprox imativ 2,1MB pentru fiecare
dispozitiv .

Proiectare
24
Un an conține aprox imativ 8760 de ore astfel rezultă:

8760 h∗12 î𝑛𝑟𝑒𝑔𝑖𝑠𝑡𝑟 ă𝑟𝑖
ℎ=105120 î𝑛𝑟𝑒𝑔𝑖𝑠𝑡𝑟 ă𝑟𝑖
105120 î𝑟𝑒𝑔𝑖𝑠𝑡𝑟 ă𝑟𝑖∗20𝐵=2102400 B
2102400 𝐵=2.1024 𝑀𝐵

Proiectare
25 4.5 Pagina Web
Componenta vizibilă aplicației ne permite vizualizarea datelor într -un format ușor
interpretabil pentru un operator uman. Pentru a realiza această etapă este necesar o
pagină web a l cărui conținut se reânprospătează automat într -un interval de timp
prestabilit. Penru a satisaface necesitățile de bază interfața vizuală , trebuie dă dispună de
următoarele funcționalități:
• Posibilitatea de a selecta între dispozitive
• Afișarea ultimei în registrări și timpul înregistrării pentru dispozitivul
selectat.
• Afișarea minimelor, maximelor și mediile de umiditate, temperatură.
• Afișarea unui grafic al cărui conținut permite filtrarea după timpul
înregistrării.
• Afișarea uni ta bel generat dinamic ce c onține datele detaliate de pe grafic.
• Conținutul paginii web trebuie să fie reîmprospătat fără a reî ncărca pagina.
Pentru a satisface ultima condiție , o să fie utilizat JavaScript , mai spcific b iblioteca
Angular ce ea ce ne permite definirea uni model iar p rin updatarea datelor stocate în
model prin inte rmediul controllerului se realizează updatarea viewului în mod automat.
Astfel printr -un simplu request HTTP putem să reî mprospătăm datele fără a reîncărca
pagina web.
În scopul simplifică rii interfeței vizua le, atât temperatura cât și umiditatea vor fi
plotate pe același grafic . Astfel toate datele sun plotate în aceași zonă reducând
considerabil spațiul necesar. Un alt aspect important de considerat ar fi redimensionarea
graficului, deoarece această interfață vizuală ar trebui să funcționeze atât pe calculatoare
conveționale cât și pe dispozitive mobile ce au mărimea ecranului redus.
Pornind de la Figura 5.4 putem să evidențiăm interacțiunile posibile în tre
utilizator și inerfața vizuală. La prima încărcare a paginii trebuie selectat un dispozitiv.
Fără un dispozitiv selectat restul funcționalităților nu sunt disponibile.

Figura 4.4 Diagrama use case

Implementare și Testare
26 5 Implem entare și Testare
Implementarea s -a realizat pe etape distincte. Fiecare etapă a fost testată individual
iar după ce se constatat că aceasta operează î n parametri normali a fost integrată în
aplicație. Odată integrat ă aplicația a fost testată și depanată.
5.1 Etapa 1
Deoarece era clar de la î nceput că toate datele primite de la microcontroller vor fi
stocate într -o bază de date, primul pas a fost realizarea unui con ector ce permite
comunicarea cu baza de date fără a fi necesar compunerea SQL queryului de fiecare dată
când sunt necesar e citirea sau scrierea în baza de date . În Figura 6.1 sunt prezentate
metodele conectorului .

Figura 5.1 Connector bază de date
În momentul de față sunt implementate numai metodele strict necesare aplicației
curente , aceasta fiind ușor expandabilă pentru orice eventualitate în viitor.
Pentru a realiza o conexiune se cre ează un obiect nou de tip DataBaseLink , iar în
constructurul metodei trebuie să spcificăm trei parametri importanți:
• Adresa bazei de date.
• Numele utili zatorului .
• Parola atașată utilizatorului.
După ce am stabilit o conexiune , avem acces la metodele prezentate în Figura 6.1.
Odată ce am finalizat toate operațiile , se apelează metoda termianteConnection() pentru
a închide conexiunea.
Pentru a testa această componentă a fost creat ă o clasă de test e în care fie care
metodă a fost apelată individual și depanat. Schimbările s -au urmărit atât în consola
sistemului cât și în baza de date accesând pagina http://localhost /phpmyadmin/ ce este
hostat de către programul XAMPP și permite gestionarea bazei de date utilizând o
interfață vizuală.

Implementare și Testare
27 5.2 Etapa 2
În această etapă a fost realizat ă aplicația de pe micro controlle r, transmisia datelor,
structura bazei de date.
Primul pas în realizara acestei etape a fost testarea componentelor hardware prin
încărcarea unor programe de test , ca să neasigurăm că fiecare componentă funcționează.
Cu ajutorul utilităților oferite de mediul de dezvoltare Ardruino acest pas a fost realizat
fără prob leme.
Următoarea provocare a fost dezvoltarea unu i mod de comunicare între
microcontrolle r și aplicația de captare care poartă numele de DataCollector. Aici au fost
explorate diferite metode de comunicare inclusiv HTTP dar cea mai fiabilă și eficentă s -a
dovedit a fi cea prin Socket. Un dezavantaj oferit de către aceasta ar fi faptul că micro
controllorul trebuie să cunoască adresa receptorului.
Pentru datele trimise de la micro controll er către Data Collector s -a optat să fie în
format XML din cauza următoarelor motive:
• Organizarea datelor într -un mod ierarhic
• Este ușor interpretabil pentru oameni
• Putem să atașăm informații adiționale ce ar putea ajuta la crearea în mod
dinamic a tabelelor din baza de date.
• Java dispune de biblioteci specializate în p relucrarea XMLurilor.
În Figura 6.2 este prezentat un șablon de mesaj care în momentul trimiterii datelor
este completat și trimis către aplicația receptoare.

Figura 5.2 Șablon Mesaj XML
Toată informa ția este cuprins ă de către tagul „message”. Informația trimisă înapoi
către collectorul de date se împarte în două categorii
• Informații referitoare la dispozitiv
• Informații referitoare la citirile realizate.
Informațiile legate de dispozitiv care sunt cuprinse de tagul „dev -info” momentan
conține d oar adresa sa de Ip versiunea 4; dacă ar fi fost implementat și starea bateriei ,
atunci aceasta ar fi intrat în această categorie.

Implementare și Testare
28 Informațiile citite din mediul înconjurător sunt cuprinse de către tagul „readings” în
cazul aplicației curente temperatura și umiditatea.
Receptorul de date DataCollector are ca scop stabilirea unui ServerSocket pe un
port disponibil și să aștepte conexiuni de la dispozitive. În Figura 5.3 este prezentat
structura acestei clase.

Figura 5.3 Diagrama de clase pentru DataCollector

Această clasă extinde clasa Thread ; suprascriind metoda run , putem să executăm
acest subprogram independent de restul aplicației. Acesta oferă un avantaj major ,
deoarece acest lucru permite distribuirea aplicației pe mai multe unități conectate la
rețeaua locală. În cazul în care o unitate se defectează , atunci nu pică toată aplicația ,
aceasta fiind utilizabilă într -o anumită măsură.
După ce sa creat ServerSocket ul la portul setat programul așteaptă conexiune de la
un dispozitiv extern. Odată ce un dispozitiv s -a conectat și a trimis mes ajul, se execută pași
următori:
• Se salvează mesajul primit într -o variabilă după care se logează în
consoloa sistemului.
• Mesajul este convertit într -un obiect de tip Map , unde numele tagului
constituie cheia primară , iar valoarea se citește din XML.
• Pasul final îl constituie inserarea în baza de date.
Pentru testarea acestei etape s -a urmărit fluxul de date. Prima oară s -au verifica t
mesajele logate de către micro controllor Figura 5.4, după care a fost verificat mesajul
logat în consola eclipsului Figura 5.5 . Dacă aceste date corespund , atunci înseamnă că
mesajul a fost transmins cu succes. Un ultim pas constă în verificarea dacă a fost efectuat ă
corect înregistrarea în baza de date Figura 5 .6.

Implementare și Testare
29
Figura 5.4 Serial Monitor

Figura 5.5 Consola Eclipse

Figura 5.6 XAMPP Table View

Implementare și Testare
30 5.3 Etapa 3
Această este etapa în carea se realizează serverul Jetty care constituie cea mai
complexă parte a aplicației, deoarece toate operațiunile de manipulare a informației sunt
realizate în această fază.
Pentru a gestiona informația în mod eficient , datele trebuie reprezentate în memoria
sistemului într -o manieră ce permite un acces rapid dar în același timp să fie ușor de
urmărit. Din fericire , programarea orientată pe obiecte a permis realizarea modelul ui
prezentat în Figura 5. 7.

Figura 5.7 Diagrama de clase pentru Reprezentarea Datelor
Pornind de la nivelul inferior în ReadingEntry este reprezentat un rând din tabela
de citiri din baza de date. Ace sta este adapt at pentru acest caz particular.
Dispunem de o singură metodă ce permite convertirea datelor întrun vector
rerezentat în JSON (Java Script Object Notation).
Obiectul EntryTable realizează reprezentarea tabelului din baza de date și este
compus din mai multe obiecte de tip ReadingEntry . În afară de lista ce conține toate
înregistrările , avem primit iva tableName în care este stocat numele tabelei care este
reprezentat în baza de date. Obiectul lastRow conține ultima înregistrare din baza de date
și este folosit pentru a avea acces la ultimul element al listei fără a fi necesar iterarea prin
listă.
Metodele prezente au scopul de a returna informația cerută :
• getRows () returnează toate înregistrările stocate în lista rows .

Implementare și Testare
31 • getStatisticsMap (Date, Date) returnează un Map ce conține statistici cum ar
fi min, max, media aritmetică . Are doi paramteri de tip date care spc ifică
intervalul de timp în care să se calculeze statisticile. Dacă acești parametri
sunt Null , atunci în mod implicit calculează statistici le pentru fiecare
înregistrare din list a rows .
• filterEntriesByDate (Date,Date) funcționează similar ca și metoda
getStatisticsMap() doar diferența fiind faptul că aceasta returnează o listă cu
înregistrări care au fost înregistrate în intervalul de timp pre cizat.
În final obiectul Device reprezintă colecția tuturor datelor necesare pentru a
reprezenta un ui dispozitiv fizic în memoria sitemului . Această clasă conține o singură
metodă ce ne permite reprezentarea obiectului current în format JSON.
Acum că s -a rezolvat problema de reprezntare a datelor urmează rezolvarea
problemei de stocare și actualizare a datelor, lucru ce necesită un modul dedicat pentru
gestiona rea reprezentării locale a înregistrărilor. Acest modul se va numi DataHandler și
responsabilita tea sa principală este de a furniza informație aplicației în așa fel , încât
aceasta să fie actuală.

Figura 5.8 Diagrama de clase pentru DataHandler
În Figura 5.8 este reprezentat ă relația dintre reprezentarea internă și clasa
DataHandler. Ca ace st modul să î și realizeze rolul, trebuie să furnizeze informații către
lumea externă lucru ce este realizat cu ajutorul metodelor:
• getSpecificDevice()
• getAllDevices()
• getAllDevicesMap()

Implementare și Testare
32 La inițializarea obiectului de tip DataHandler se realizează o conexiune către baza
de date și în acel moment se extrag toate informațiile referitoare la dispozitive iar în final
se inițializează reprezentarea internă cu datele extrase .
În momentul în care cer em informații în mod automat se execută un query î n baza
de date care verifică dacă au apărut înregistrări noi. Pentru a realiza acest lucru se
folosește Id ul ultimei înregistrări , dacă există în baza de date un Id numeric mai mare
decât Id ul ultimei înr egistrări ; stocate local , atunci acest lucru înseamnă că au apărut
înregistări noi în baza de date. Fiecare înregistrare nouă este extrasă și inserată la locul
lui corespunzător în structura de date.
Odată ce reprezentarea internă a fost reî mprospătat ă urmează operațiile de căutare
în care sunt identificate înregistrările ce corespund criteriilor de căutare. În final
înregistrările identificate sunt returnate. Până la apelul următor a metodelor specificate
anterior nu se întâmplă nici o modificare în repre zentarea interă a informației.
Putem să concluzionăm că acest modul are un rol important în gestionarea
informați ei fără a fi necesar supra încărcarea bazei de date. Odată ce baza de date se
populează , tranzacțiile care trebuie să returneze toate informați ile pot să crească în timp.
Acest lucru asigură ca informația stocată local este tot timpul sincronizat cu baza de date
astfel reducând timpul necesar realizării tranzacțiilor.
Un lucru important de menționat este faptul că această metodă de gestionare nu
suportă operațiile de ștergere a înregistrărilor. Odată ce informațiile mediului
înconjurător au fost înregistrate , acestea persistă permanent în baza de date. Singurul
mod prin care se poate realiz a golirea tabelelor este prin oprirea aplicației și golirea
manuală a tabelelor utilizând facilitățile furnizate de către aplicația ce hostează baza de
date XAMPP. După ce s -au golit tabelele respective se repornește aplicația de back end.
Acum , că a fost realizat ă gesti onarea înregistrărilor , este timpul să ne ocupăm de
ultimul aspect al acestei etape , care este transformarea informației într -o formă
interpretabilă pentru interfața vizuală .
Serverul a fost realizat utilizând biblioteci oferite d e către Jetti , care este dezvoltată
de către compania Eclipse . Datorită acestei biblioteci putem să eliminăm problemele
legate de comunicare și să focusăm la gestionarea informației.
Prezentat în Figura 5. 9 este evidențiat strucutra finală a aplicației de back end . Aici
se pot evindenția două clase importante:
• JettyWebServer
• RequestProcessor
JettyWebServer extinde clasa thread permițând execuția sa independen t de
subprogramul DataCollector. Datorită acestui fapt este posibil ă distribuția aplicației pe
mai multe unități diferite. Rolul acestei clase este stric t recepționarea de requesturi și
trimitera răspunsului. Un avantaj oferit de către această bibliotecă este faptul că pentru
fiecare request se crează un thread nou de execuție ce elimină problema cozilor de
așteptare. În mod natural trebuie să gestionăm informațiile stocate intern cu o atenție
sporită pentru a elimina eventualele probleme de concurență.

Implementare și Testare
33
Figura 5.9 Diagrama de C lase pentru Server
RequestPro cessor are rolul de a interpreta cerințele clientului, să proceseze datele
conform cerințelor clientului iar în final să formuleze și să trimită un răspuns. După ce s –
a procesat requestul și se cunosc parametri acestuia , RequestProcessorul cere de la
DataHandler informațiile necesare , după care compune răspunsul în format JSON.
Sa decis ca requestul primit de către client să aibă următoarea structură:
𝒓𝒆𝒒𝒖𝒆𝒔𝒕𝑭𝒐𝒓𝑫𝒂𝒕𝒂𝑻𝒚𝒑𝒆 &&𝒑𝒂𝒓𝒂𝒎 1&&𝒑𝒂𝒓𝒂𝒎 2&&..&&𝒑𝒂𝒓𝒂𝒎 𝒏
𝑹𝒆𝒒𝒖𝒆𝒔𝒕𝑭𝒐𝒓𝑫𝒂𝒕𝒂𝑻𝒚𝒑𝒆 indică ce tip de date este cerut de către client astfel back –
endul știe ce metode să apleze pentru procesarea informației . Aplicația supportă
următoarele tipuri prezentate mai jos:
1. allDev acesta nu are paramet ri și returnează numele tuturor dispozitiv elor
înregistrate în prezent. Răspunsul JSON este prezentat în Figura 5.10.

Figura 5.10 Răspuns la allDev

Impleme ntare și Testare
34 2. deviceStatistics acesta are un singur parametru „ deviceName ” care reprezintă
numele dispozitivului pentru care să se calculeze statisticile. Răspuns prezentat în
Figura 5.11 conține minimul ,maximul și media aritmetică a înregistrărilor.

Figura 5.11 Răspunsul la deviceStatistics
3. chartData are trei parametri: „deviceName ”, „fromDate ”, „toDate”. Ca și în cazul
precedent , deviceName specifică numele dispozitivului pentru care să se genereze
informațiile necesare pentru trasarea graficului iar restul parametrilor reprezintă
intervalul de timp ; în cazul în care se omit ultimi doi parametri , implicit se cre ează
graficul pe întreaga durată a rulării aplicației . Răspunsul generat este prezentat în
Figura 5.12.

Figura 5.12 Răspuns la chartData
4. deviceTable este ultimul ti p de request disponibil iar ace sta dispune de ace iași
parametri ca și chartData , singura diferență fiind că ace sta conține informații detaliate
referito are la graficul a fișat anterior. Răspunsul generat este afișat în Figura 5.13.

Implementare și Testare
35
Figura 5.13 Răspuns la deviceTable

Testarea acestei etape a fost de cea mai lungă durată. Inițial a fost testat ă
funcționalitatea DataHandlerului prin logarea informației primite în consola sistemului.
Pentru aceasta a fost necesar ă o bază de data separată , cu puține înregistrări , ca să fie
posibilă verificarea corectitudinii datelor extrase. După ce ne -am asigurat că această
componentă funcționează , s-a trecut la cuplarea etapelor anterioare și testar ea pe o bază
de date ce este reî mprospătat cu înregistrări noi.
După depanarea problemelor apărute și asig urarea bunei funcționări a
Data Handlerului s -a trecut la test area serverului. Aici a fost urmărit dacă răspunsul primit
nu are erori de sintaxă , gen lipsa unor semne de punctuație . Deoarece încă nu era
disponibil ă interfața vizuală , requesturile au fost introduse direct în bara de adresă a
browseului web astfel perm ițând previzualizarea răspunsului prezentat în Figura 5.14.

Figura 5.14 Previzualizare Răspuns JSON
Desigur în mod normal un JSON poate să conțină foarte multe informații rezul tând
că depanarea erorilor să devină dificilă. Din fericire pagina https://jsonlint.com a permis
depanarea fiș ierelor mai mari astfel închei nd această etapă.

Implementare și Testare
36 5.4 Etapa 4
Ultima etapă din acest proiect care este una semnificativă , deoarece aceasta
reprezintă principalul mod de interacțiune a utilizatorului cu aplicația.
Ca și un prim pas s -au dezvoltat individual componentele detaliate la capitolul
anterior utilizând noul server dezvoltat la etapa precedentă. Utilizând biblioteca Angular
și protocolul HTTP, comunicare a între server și pagina web s -a realizat rapid. Un avantaj
enorm oferit de către Java Script este supportul integrat pentru date de tip JSON, astfel
eliminând necesitatea de a parsa informația primită de la server.
Utilizarea serverului recent dez voltat a permis testarea extensivă a acestuia și
adaptarea informației trimise în așa fel , încât aceasta să curespundă necesitășilor.
Prima componentă ce a fost dezvoltată era cea responsabilă pentru trasarea
graficului. Ace asta era cea mai importantă , deoarece permite vizualizarea unei cantități
enorme de informații într -un spațiu foarte mic. Din fericire și alți dezvoltatori s -au lovit
de acestă problemă și a u pus la dispoziție o biblioteca cu numele HighCharts ce permite
trasarea graficelor.
Înainte de a fi utilizat aceasta necesită configurarea parametrilor prezentate în
Figura 5.15.

Figura 5.15 Configurare Grafic
Un Punct de interes reprezintă atributul „data”. Odată ce facem un request la server
pentru datele legate de grafic , o să primim un răspuns prezentat în Figura 5.12 din care
preluăm informațiile din câmpul „data” și îl transmitem parametrului local. Odată ce a fost
reazlizat tra snferul , graficul se re înprospătează aut omat fără a fi necesar re încărcarea
pagini web.

Figura 5.16 Exemplu de grafic trasat

Implementare și Testare
37 Următoare componentă dezvoltată a fost tabelul generat în mod dinamic. Pentru a
realiza această componentă , era necesar să cunoaștem capul de tabel și datele ce sunt
prezente în tabel. Utilizând directiva ng-repeat a fost atins scopul generării tabelului în
mod dinamic prezentat în Figura 5.17.

Figura 5.17 Secvență de cod p entru generare a tabel ului
Prima oară se generează antetul tabelului dup ă care aceasta este populată cu
înregistrări. În momentul în care apare o înregistrare nouă , aceasta este adăugată la
capătul tabelului fără a fi reîm prospăt ată pagina .
Ultimele componente dezvoltate au fost afișarea statisticilor și afișarea ultimei
înregistrări , câmpuri ce sunt actualizate în același timp.
Odată ce s -au dezvoltat componentele individuale , a urmat integrarea lor în tr-o
singură pagină ș i corelarea lor în așa fel încât ele să funcționeze fluent. Pentru a simplifica
interfața s -a optat pentru ascundera informațiilor utilizând directiva ng-hide și o
variabilă ce reține stare a în mod implicit setat să ascundă conținutul paginii . Când pagina
este deschisă pentru prima oară , utilizatorul nu este copleșit de volumul enorm de date
afișat e prezentat în Figura 5.18 . Interacționând cu butoanele curespunzătoare ,
utilizatorul poate afișa sau ascunde informația dorită prezentat ă în Figura 5.19 . Singura
componentă ce este permanent vizibil ă este graficul care sumarizează toate înregistrările.

Implementare și Testare
38
Figura 5.18 Interfața m inimalistă

Figura 5.19 Interfața expandată
Pentru a testa această etapă prima oară au fost transmise date din baza de dat e
statică și au fost comparate datele stocate în baza de date cu cele expuse pe intarfața
vizuală. Odată ce ne -am asiguarat că datele prezentate sunt corecte , au fost testate și
restul funcționalităților , cum ar fi ascundearea datelor. În acest ultim pas s-au facut
adjustări la animații ca ele să fie mai fluente.

Implementare și Testare
39 5.5 Testarea Aplicației
Pentru a testa aplicația asamblată , au fost pornit e și conectate component ele
individuale: microcontrollorul, receptorul de date, serverul Java iar în final pagina web. A
fost urmărit fluxul de date de la microcontroller până la interfața vizuală utilizând
metodele utilizate la testarea etapelor individuale. Pentru a urmări eror ile apărute pe
interfața vizuală a fost utilizat consola browserului.
Deoarece interfața vizuală trebuie să fie capabilă să prezinte date de la mai multe
dispozitive a fost creat ă o clasă specială în mediul Java ce permite simularea unui
dispozitiv. Astefe l eliminând necesitate de a mai construi un dispozitiv nou , ce necesită
timp și alte resurse. Această clasă generează în mod aleator înregistrări într -o plajă
definită și le inserează în baza de date.
Pe termen scurt a fost constatat că nu sunt erorori și din acest motiv a fost rulat un
experiment pe o durată mai mare pentru a vedea dacă apar erori în timpul execuției.
Erorile apărute au fost remediate , după care a fost repornit experimentul , până când am
reușit să opținem o execuție fără erori.

Concluzii
40 6 Concluzii
6.1 Rezultate obținute
Scoplu principal a l acestei aplicații a fost de a implementa o modalitate de a
monitoriza și stoca unele aspecte ale mediului înconjurător, lucru ce a fost realizat
datorită tehnologiilor web ce au permis interconectarea diferi telor componente astefel
realizând o aplicație completă.
Informația captată din mediul încon jurător de microcontroller este trimis către o
aplicație java de sine stătăto are ce permite inserarea acestuia într -o bază de date.
Informația stocată este accesată de către un sever v scris în Java care efecteuează operații
de prelucrare a datelor bazat pe cerințele clientului. Datele prelucrate sunt afișate
clientului astfel încât ele să fie ușor vizualizabile.
6.2 Direcții de dezvoltare
O înbunătățiere ar fi optimizar ea codului de pe microcontroller încât acesta să nu
opereze non stop. Când a transmis datele microcontrollorul să se pu nă într -o stare de
hibernare, după o perioadă de timp presetată , ace sta trebuia să se repornească , să se
conecteze la reț ea, să trimită d atele. Astfel permițând conservarea energiei.
Dacă microcontrolle rul se plasează într -un mediu unde lumina solară este
abundentă , ar fi posibil ă utilizarea celulelor fotovoltaice pentru mărirea timpului de
operare , singurul dezavantaj fiind necesitatea circuitelor specializate pentru încărcare și
descărcare a elementelor ce înmagazinează energie.
Această aplicație are la bază comunicarea prin tehnologii web , dar există
posibilitatea defectării unui element , ca de ex emplu routerul wi reless. În vederea reținerii
informației , în cazul în care dizpozitivul a eșuat în trimiterea datelor acesta trebuie să le
stoceze intern înt r-o listă FIFO (First In First Out) și să le trimită în momentul în care
conexiunea este restabili tă.
O înbunătățire majoră în vederea ușurării utilizării ar fi de a se implementa o
interfață ce permite interacționare și confi gurarea unor parametri în microcontroller,
precum adresa ip și portul receptorului astfel eliminând necesitatea reprogramării
acestuia.
Din motivul de a ușura dezvoltarea tuturor componentelor (baza de date, serverul,
pagina web) sunt prezente local pe o singură unitate și din acest motiv toate adresele au
fost setate pe cea locală de 127.0.0.1. Ar trebui să se implementeze un mod de a configura
aceste adrese , permițând distribuirea aplicației pe mai multe unități.
Un alt loc unde ar trebui rea lizate înbunătățiri ar fi modul de afișare a datelor. În
implementarea actuală , dacă nu specificăm constrângeri de timp , atu nci toate
înregistrările prezente în baza de date sunt trimise către pagina web. Cât timp nu sunt
multe înregistrări , aces tea nu reprezintă probleme , dar ar trebui implementat un algoritm

Concluzii
41 de calcul ce permite reducerea volumui de date transmis e dar, în același timp , menți nând
corectitudinea datelor reprezentate. O astfe l de posibilitate ar fi calculul unor medii pe
perio ade determinate și trasarea acestor medii pe grafic.
Încă o inbunătățire majoră ar fi extinderea capabilităților de filt rare după parametri
specifici. D e exemplu , să existe capabilitatea de a filtra după mai mulți parametri care sunt
specifici dispozitivului respectiv. Dacă un dispozitiv monitorizează temperatura și
umiditatea, să se returneze toate înregistrările care au avut o temperatură mai mare de
30C° și umiditatea mai mică decât 60%.
Ca și o ultimă funcționalitate a interfeței grafice ar fi conversia unităților de măsură ,
de exemplu : din celsius în kelvin sau fahrenheit . Aceasta ar putea să fie configurat ă în așa
fel, încăt să utilizeze setările regionale ale sistemului de operare.
O ultimă componentă ce s -ar putea include este un buton de feedback ce permite
înregistrarea părerilor utilizatorului , astfel permițând înbunătățirea aplicației.
Ca și un ultim pas, ar fi dezlipirea componentelor din mediile lor de dezvoltare și să
se cre eze un fișier executabil ce ar simplifica procesul de instalare . Iar în cazul pagin i web
acesta să fie integrat și hostat de către serverul de back -end Java .

Bibliografie
42 7 Bibliografie

[1] Dallas Semiconductor, „Fundamentals of RS -232 Serial
Communications,” vol. Application Note 83, pp. 1,3.
[2] E. A. Corinna, F. Rob, B. Sebastian, D. Laura, E. -P. Alberto, B. Louse, F.
Carlo, F. Jim, H. Ian, J. Kyle, K. Tomas, K. Gina, M. Adam, N. Juergen, P. Ermanno,
R. Frédéric și Z. Marco, Wireless Networking in the Developing World,
December 2007.
[3] B. Ec kel, Thinking in Java, New Jersey: Prentience Hall PTR, 1998, pp.
44,74,599, 658.
[4] B. W. Keringham și D. M. Ritchie, The C Programing Language, 2nd ed.,
New Jersey: Prentice Hall, 1989, p. 1.
[5] J. Gosling, B. Joy, G. Steele, G. Bracha și A. Buckley, The Java® Language
Specification, Java SE 8 Edition ed., 13 -02-2015, pp. 1 -5.
[6] Tutorials Point, Java Script, 2015, p. 2.
[7] AngularJS, „AngularJs,” [Interactiv]. Available:
https://docs.angularjs.org/guide/introduction. [Accesat 27 06 2017 ].
[8] Atmel, ATmega328/P Data Sheet, 2016.
[9] Varta Microbattery GmBH, LR 03/AAA, Ellwangen/Jagst, 2013 -05-17.
[10] Ardruino, [Interactiv]. Available: https://store.arduino.cc/arduino -uno –
rev3. [Accesat 30 06 2017].
[11] [Interactiv]. Available :
https://www.arduino.cc/en/Main/ArduinoWiFiShield. [Accesat 30 06 2017].
[12] D-Robotics UK, DHT11 Humidity & Temperature Sensor, 2010.

Bibliografie
43