Aplicație pentru gestionarea testelor automate Coordonator Absolvent Sl.Dr.Ing. Mihnea MOISESCU Diana NIȚULESCU 2017 2 Cuprins 1. Introducere… [613028]

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

LUCRARE DE DISERTAȚIE

Aplicație pentru gestionarea testelor automate

Coordonator Absolvent: [anonimizat].Dr.Ing. Mihnea MOISESCU Diana NIȚULESCU

2017

2
Cuprins

1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. ………… 4
2. Descrierea procesului de testare ………………………….. ………………………….. ………………………….. ………… 6
3. Tehnologii existente ………………………….. ………………………….. ………………………….. ………………………… 7
3.1. Re țeaua CAN ………………………….. ………………………….. ………………………….. ………………………….. ….. 7
3.2. Rețeaua LIN ………………………….. ………………………….. ………………………….. ………………………….. ……. 8
3.3. DDT2000 ………………………….. ………………………….. ………………………….. ………………………….. ……….. 9
3.4. CANoe ………………………….. ………………………….. ………………………….. ………………………….. …………. 10
3.5. Vector CANdb+ + ………………………….. ………………………….. ………………………….. ……………………….. 12
3.6. CAPL ………………………….. ………………………….. ………………………….. ………………………….. …………… 12
3.7. Test Report ………………………….. ………………………….. ………………………….. ………………………….. ……. 14
3.8. Baze de date ………………………….. ………………………….. ………………………….. ………………………….. ….. 16
4. Formularea problemei ………………………….. ………………………….. ………………………….. ……………………. 18
5. Soluția propusă ………………………….. ………………………….. ………………………….. ………………………….. …. 19
5.1. Mentenanța predictivă ………………………….. ………………………….. ………………………….. …………………. 27
6. Concluzii ………………………….. ………………………….. ………………………….. ………………………….. …………. 28
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …………….. 29

3
Listă de Figuri:

Figure 1 – Exemplu de rețea CAN [1] ………………………….. ………………………….. ……………………….. 7
Figure 2 – Comunicație LIN [2] ………………………….. ………………………….. ………………………….. …… 9
Figure 3 -DDT2000 ………………………….. ………………………….. ………………………….. ………………….. 10
Figure 4 – Interfață CANoe ………………………….. ………………………….. ………………………….. ……….. 11
Figure 5 – Raport de test CANoe ………………………….. ………………………….. ………………………….. .. 12
Figure 6 – Exemplu de cod al unui test automat ………………………….. ………………………….. ……….. 13
Figure 7 – Exemplu de test report ( .html) ………………………….. ………………………….. ……………….. 14
Figure 8 – Formular cautare fisiere in baza de date ………………………….. ………………………….. …… 21
Figure 9 – Dropdown list pentru alegerea arhitecturii pentru USM ………………………….. ………….. 22
Figure 10 – Dropdown list pentru alegerea functiei pentru USM ………………………….. …………….. 23

4
1. Introducere
Mașina modernă a fost descoperită încă din anul 1886 de către inventatorul german Karl Benz.
Până în secolul al XX -lea mașina nu a fost acceptată, făcând ca Ford Motor Company să vândă
primele automobile masei de oameni din Statele Unite ale Americii prin T Model 1908. Acolo,
mașinile au fost adoptate mult mai repede, oamenilor surâzundu -le ideea de a înlocui trăsurile cu
ceva mai comod și rapid, dar mai costisitor.
Producătorii de automobile au investit în noi tehnologii, de la geamuri electrice, încălzir e în
scaune, cutie de viteze automată pâna la pilot automat și parcare asistată. Dacă înainte o mașină
era pur mecanică și nu avea de -a face cu un calculator integrat, cu un software, acum s -a ajuns la
o legătură mult prea strânsă între partea mecanică, el ectrică și electronică. Majoritatea problemelor
care apar la o mașină pot fi în ziua de azi foarte ușor idenfiticate prin testele automate, care au la
bază informatica și programarea.
Fiecare func ție indeplinită de mașină este în zilele noastre, controlată de un calculator. Acest
fapt face ca arhitectura unei mașini să integreze multe calculatoare pentru ca mașina să
indeplinească toate funcțiile cerute. Pentru același tip de calculator pot exista mai multe versiuni
hardware, iar pentru fiecare versiune har dware sunt dezvoltate mai multe versiuni software.
Software -ul calculatoarelor integrate pe automobile trebuie testat înainte ca aceste calculatoare
să fie integrate pe noile modele de automobile ce urmează a fi v ândute. Testarea fiecărei versiuni
softwar e presupune verificarea tuturor cerințelor funcționale și realizarea unei sinteze pentru
eventualele erori care apar în timpul testării.
Inițial testarea software era făcută manual, dar și acest domeniu a evoluat și cu ajutorul unor
tool-uri testarea softw are se poate face și automat pentru testarea marii majorități a funcțiilor
calculatoarelor integrate pe automobile . Astfel, odată cu trecerea de la testarea manuală la testarea
automată timpul dedicat testării a fost micșora t.
Aplicația pe care am ales să o dezvolt are ca scop gestionarea testelor automate și a rapoartelor
de test rezultate în urma rulării testelor.
Lucrarea este alcătuită din șase capitole la care se adaugă și lista de referințe bibliografice. În
primul capitol sunt prezentate considerent e generale despre automobile.

5
Al doilea capitol prezintă pe scurt arhitectura electronică a automobilelor și modurile de testare
ale calculatoarelor integrate în arhitectura automobilului.
Cel de -al treilea capitol descrie tehnologiile existente. În acest capitol este descris modul de
funcționare al rețelelor CAN și LIN, dar și programele folosite în domeniu pentru testarea
calculatoarelor.
În cel de -al patrulea capitol este formulată motivația pentru dezvoltarea aplicației.
Al cincelea capitol prezintă so luția aleasă. În acest capitol este descrisă aplicația ce urmează a
fi dezvoltată.
În ultimul capitol sunt subliniate concluziile privind lucrarea prezentată .

6
2. Descrierea procesului de testare
Pentru a putea înțelege modul de realizare a testelor automate, trebuie să cunoștem arhitectura
electro ică a automobilului.
În funcție de marcă și de model, arhitrectura electronică a automobilului este diferită. Aceasta
cuprinde, pe langă toate componente le mecanice acționate electric (motor, cutie de viteze,
stergator, etc) o rețea CAN la care sunt conectate maxim 16 calculatoare. Fiecare calculator este
responsabil pentru o anumită funcție sau pentru o serie de funcții pe care trebuie să le îndeplinească
automobilul. De exemplu calculatorul EMM (Energy Management Module) controlează
aprinderea luminilor de pe mașină, modul de acționare al ștergătoarelor, plierea oglinzilor, etc. .
Deși fiecărui calculator îi este atribuită o funcție sau o serie de funcții , ele nu sunt independente.
Pentru a putea decide care este comanda ce trebuie transmisă la un moment dat, un calculator
primește informații și de la alte calculatoare, în funcție de ce informații îi sunt necesare. De
exemplu, pentru a da comanda de aprind ere a high beam (fază lungă), calculatorul EMM trebuie
să cunoască starea motorului, iar acest semnal este transmis de la calculatorul BCM (Body Control
Module).
Pentru fiecare dintre calculatoarele automobilului, în funcț ie de arhitectură, este scris câ te un
caiet de sarcini pentru fiecare funcție a calculatorului respectiv. Caietul de sarcini cuprinde
descrierea funcției analizate și este alcă tuit dintr -o serie de cerințe. Fiecare cerință este de tipul
“dacă….atunci… ”. Pentru fiecare cerință este specific at care este comportamentul normal.
Pe baza acestor caiete de sarcini sunt efectuate mai apoi teste pentru a vedea exact dacă
calculatorul testat funcționează conform specificațiilor sau nu.
În funcție de momentul în care este testat un anumit calculator, există două tipuri de testare:
testare MIL și testare HIL.
Testarea MIL (Model In the Loop) reprezintă testarea modelului Matlab Simulink al
calculatorului testat. Modelul ce trebuie testat este adăugat în rețea alături de cel elalte modele ale
calculatoarelor care comunică cu cel testat. Urmărind caietul de sarcini este testat comportamentul
modelului și în cazul unor anomalii, acestea sunt semnalate către e chipa de modelizare.
Testarea HIL (Hardware In the Loop) reprezintă tes tarea unui calculator î ntr-un mediu cât mai
apropiat de cel real. Testarea HIL se realizează pe bancuri de simulare în care celelalte calculatoare
de la care calculatorul testat primește semnale sunt simulate cu ajutorul modelelor Matlab ale
acestora, iar tot ce ține de calculatorul testat se regăsește fizic în banc ul de test . Pentru a putea
urmări comportamentul real al compomentelor controlate de un calculator, aceste componente
trebuie să se afle fizic în banc (faruri, motorașul care controlează ștergăto arele, claxonul, etc.).
Există și componente care nu se regăsesc fizic în banc din diferite motive, dar acestea sunt înlocuite
cu un consumator care să simuleze comportamentul real al componentei (rezistență, diodă, releu,
etc.). Pentru testarea HIL este n evoie de calculatorul testat, nu mai este suficient modelul Matlab
al acestuia.

7

3. Tehnologii existente
În acest capitol vor fi prezentate principalele co ncepte și tool -urile folosite în testarea
automată .
3.1. Re țeaua CAN
CAN (Controller Area Network) este un protocol de comunica ție de tip magistrală (bus).
Datorită performanțelor și a costurilor reduse, rețeaua CAN este utilizată pe scară largă în industria
automobilelor. Calculatoarele automobilului (BCM, EMM, ESP, ABS, etc.) comunică între ele cu
ajutorul rețelei CAN, schimbând continuu informații.
Unul dintre marile avantaje ale protocolului CAN este comunicația de tip serial care se
realizează în timp real. Acest lucru este vital în cazul automobilelor, unde calculatoarele trebuie să
decidă rapid și să poată transmite imediat informațiile.
Utilizarea rețelei CAN la automobile are numeroase avantaje , printre care: facilitează
partajarea de parametrii între calculatoarele din rețea; mărește securitatea rețelei; facilitează
diagnosticarea; reduce costul total al sistemului prin reducerea numărului de conectori și fire.
În funcție de viteza de transfer a datelor, reț eaua CAN este de două feluri:
 CAN HS (High Speed) – viteză mare
 CAN LS (Low Speed) – viteză mică
CAN HS poate avea viteza de transfer a datelor de 125, 250, 500 sau 1000 kb/sec. Rețeaua
CAN HS cu viteza de transfer a datelor de 500 kb /sec este cea utilizat ă frecvent în industria
automobilelor.
CAN LS are viteza de transfer între 40 și 125 kb/s. Rețeaua CAN LS are avantajul că este
tolerantă la erori (fault tolerant). În cazul în care unul din cele două fire este întrerupt comunicația
se realizează pe un sin gur fir.

Figure 1 – Exemplu de rețea CAN [1]

8
Nivelul fizic al protocolului CAN
La nivel fizic, rețeaua CAN este formată dintr -o magistrală alcătuită din două fire torsadate și
calculatoarele conectate la rețea. Fiecare calculator conține un circuit intregrat de emisie -recepție
CAN, numit CAN transceiver. Cele două fire care alcătuiesc magistrala sunt torsadate pent ru a
elimina perturbațiile electromagnetice care ar putea aparea în rețea.
Lungimea maximă a magistralei este de 250 m pentru rețeaua CAN HS și de 50 m pentru
rețeaua CAN LS. Numărul maxim de calculatoare ce pot fi conectate la rețeaua CAN variază în
funcț ie de viteza cu care trebuie transmiși parametrii, dar și în funcție de numărul acestora. Dacă
este utilizată o rețea CAN HS cu o viteză de 500 kb/ sec, numărul maxim de calculatoare ce pot fi
conectate la rețea este de 16.
Figura 1 reprezintă un exemplu de rețea CAN alcătuită din două sub -rețele : rețeaua CAN
motor și rețeaua CAN vehicul. Acest mod de dispunere al rețelei este foarte des utilizat în industria
automobilelor. Cele două sub -rețele CAN sunt conectate printr -un “gateway ” reprezentat de
calculato rul BCM (Body Control Modul). În cazul în care una dintre cele două sub -rețele se
defectează, cealaltă sub -rețea nu va fi afectată.

3.2. Rețeaua LIN
Rețeaua LIN este o rețea de tip single -master / multiple -slave cu o confugurație flexibilă.
Lungimea mesajelor transmise sau recepționate este variabilă: 2, 4 sau 8 octeți. Rețeaua LIN nu
are nevoie de quartz, are avantajul că se auto -sincronizează. În cazul apariției unui defect la unul
din nodurile re țelei, acesta poate fi ușor identificat.
Costurile pentru implementarea unei rețele LIN sunt scăzute, iar viteza maximă a rețelei este
de 20 kb /sec.
Informația pe magistrală este transmisă în format fix de lungime variabilă. Fiecare frame de
mesaj este co mpus din 2, 4 sau 8 octeți de date și 3 octeți de control și siguranță. Traficul pe
magistrală este controlat de un singur master. Fiecare mesaj începe cu un semnal de pauză și este
urmat de un câmp de sincronizare și de unul de identificare, toți trimiși de master. Slave -ul trimite
înapoi câmpul de date și cel de control. O comunicare slave -la-slave poate fi determinată de un ID
de mesaj similar dat de master.

9

Figure 2 – Comunicație LIN [2]

În rețeaua LIN un nod nu folosește informația despre configurația sistemului, exceptând nodul
de master. Nodurile pot fi adăugate la rețea fără a fi necesare schimbări hardware sau software în
celelalte noduri slave. Conținutul unui mesaj este dat de ID. Acesta nu indică d estinația mesajului
ci semnificația datelor.

3.3. DDT2000
Programul de diagnoză folosit în industria automobilelor este DDT2000. Acest program este
folosit pentru a depista erorile apărute în rețea, dar și pentru a configura diferiți parametrii.
Pentru a putea folosi acest program, calculatorul pe care rulează DDT2000 trebuie să fie
conectat la rețeaua CAN printr -o priza de diagnoză [3].
În cazul în care este testat un singur calculator al automobilului, în interfața programului
DDT2000 va fi încărcat num ai fișierul .xml al calculatorului testat. Fișierul .xml conține informații
despre calibrările și configurările diferiților parametrii ai calculatorului respectiv. La aceste
informații nu au acces decât cei care dezvoltă și testează aceste calculatoare. În cazul diagnozei
realizate la un service auto, sunt vizibile numai anumite informații.
Pentru diagnoza în cazul testării unui calculator nu este suficientă numai alegerea fișierului
.xml, trebuie selectat și tipul de rețea CAN pe care comunică respectivul calculator. Așa cum se
poate observa în figura 3, în programul de diagnoză DDT2000 a fost încărcat fișierul .xml al
calculatorului USM (Underhood Switch Module) și a fost aleasă o rețea CAN cu o viteză de
500kb/ sec.

10

Figure 3 -DDT2000

Acest program ne permite să identificăm cu exactitate semnalele cu probleme. Prin apăsarea
pe triunghiul roșu din partea stângă a interfeței programul realizează identificarea tuturor erorilor.
Fiecare eroare indică numele semnalului pentru care a apărut eroarea și un cod scris în
hexazecimal. Cu ajutorul codului erorii poate fi identificată cauza problemei: open circuit, short
circuit to ground, mesaj netransmis, etc.
Pentru a modifica configurația unui parametru, în interfața programului DDT200 0 trebuie să
selectăm, din partea stangă a ecanului, butonul care ilustrează un monitor. De exemplu, în cazul
calculatorului EMM, funcția care controlează luminile are o configurație care specifică dacă
luminile de poziții sunt controlate sau nu în PWM. As tfel, în funcție de ce caracteristici ale
calculatorului sunt testate, aceasta configurație poate fi modificată. De asemenea, cu ajutorul
DDT2000 putem avea acces la calibrările calculatoarelor. Valorile calibrărilor nu pot fi modificate,
pot fi doar citit e. În general calibrările definesc timpii în care calculatorul trebuie să raspundă la
anumite comenzi.

3.4. CANoe
Programul CANoe este utilizat pentru a urmări evoluția diferitelor semnale în cadrul testelor
efectuate pentru validarea unui calculator. Cu ajutorul acestui program este realizată arhitectura
rețelei CAN pentru testarea HI L a calculatorului vizat. O altă funcție a acestui program este aceea
de vizualizare în timp real a evoliției unor semnale. Pot fi selectate mai multe semnale din baza de
semnale CAN și pot fi vizualizate simultan. Faptul că mai multe semnale pot fi vizualizate simultan

11
facilitează măsurarea între momentul în care un semnal își schimbă starea si momentul în care un
altul iși modifică de asemenea starea ca urmare a modificării primului semnal. Aceste măsurători
sunt foarte importante în timpul efectuării t estelor și trebuie să fie realiz ate foarte precis.
Pentru a facilita efectuarea testelor manuale, în acest program pot fi create niște interfețe. În
aceste interfețe pot fi int egrate anumite semnale a căror stare este modificată mai des în timpul
testării. Un exemplu de astfel de interfețe poate fi observat în figura 4. De exemplu, cu ajutorul
slide -bar-ului din partea dreaptă poate fi modificată starea mașinii din “Sleeping” în “Engine
Running ”.

Figure 4 – Interfață CANoe

Tot cu ajutorul acestui program pot fi rulate secvențele testelor automate. În timpul rulării
testelor automate, fiecare punct în care este verificată starea unui semnal este trecut într -un raport.
Dacă rezultatul obținut în urma verificării semnalului este rezultatul dorit, în raportul de test acel
pas va fi marcat cu verde și cu mesajul “Pass”. În caz contrar în raport pasul respectiv va fi marcat
cu roșu și cu mesajul “Fail”. Datele ce vor fi memorate și în raportul de test pot fi urmărite și în
figura 5 în raportul afișat în timp real în timpul rulării testului.

12

Figure 5 – Raport de test CANoe

3.5. Vector CANdb++
Acest program este folosit pentru a crea, modifica sau vizualiza baza de semnale CAN a unui
anumit calculator. Semnalele sunt grupate în mesaje, în funcție de calculatorul care le transmite.
De exemplu în mesageria pentru calculatorul EMM pachetele de mesaje sunt transmise de
calculatorul BCM, EMM, HFM, etc. În cadrul unui mesaj semnalele sunt aranjate în funcție de
adresa care le este atribuită în cadrul mesajului. Semnalele sunt caracterizate de adresa de început
din cadrul mesajului și de lungime . Se cunoaște exact de către ce calculator este transmis un semnal
și de către ce calculator este recepționat semnalul respectiv. În funcție de tipul semnalului, în baza
de date pot fi vizualizate și valorile pe care le poate lua semnalul. De exemplu pent ru un semnal
care face referire la Ignition și este reprezentat pe un bit, acesta va avea două stări posibile : Ignition
requested și Ignition Not requested.

3.6. CAPL
Testele automate rulate în programul CANoe sunt scrise în programul CAPL într -un limbaj
foarte asemănător cu c++. Testele, fie ele automate sau manuale sunt realizate folosind aceleași

13
semnale și același caiet de sarcini. Pentru fiecare cerință din caietul de sarcini este scris câte un
test automat. Testarea unor cerințe poate fi acoperită prin testarea unei cerințe mai complexe, iar
acest lucru este notat în antetul din raportul de test . Pentru testarea unei cerințe sunt scrise mai
multe scenarii de test. Aceste scenarii sunt reprezentate de scenariile de funcționare normală și de
cele de funcționare anormală. O anumită cerintă trebuie testată în toate combinațiile de valori pe
care le p ot lua semnalele implicate în cerința respectivă pentru a evita primirea unui raspuns
presupus “corect”.

Figure 6 – Exemplu de cod al unui test automat

În exemplul din figura 6 este ilustrat o parte din codul pentru testarea un ei cerințe pentru
funcția calculatorului USM ce controlea ză ventilația (Fan). Funcția “putvalue ” este funcția ce
permite modificarea valorii unui semnal. Cu ajutorul funcției “ TestStep ” sunt semnalate mesajele
ce vor apărea în raportul de test. Funcția “TestStepPass” marchează cu verde și cu pass un anumit
mesaj scris în corpul funcției. Funcția “TestStepFail” marchează cu roșu și cu fail un anumit mesaj
scris în corpul funcției.

14
3.7. Test Report
Raportul de test este foarte important în procesul de val idare automată HIL. În raport sunt
sintetizate rezultatele testului. În cazul testării HIL manuale, nu există posibilitatea creării unui
astfel de raport. Rezultatele testării manuale sunt consemnate într -un fișier, fără să existe o dovadă
ca testul a fos t într -adevăr realizat și sa rezultatele sunt cele consemnate. Astfel, testele automate
aduc un plus validării HIL, pentru că la fiecare rulare de test este creat un raport în care este
sintetizat comportamentul în timpul testului al calculatoarelor testat e.
În timpul rulării unui test, informatiile ce vor aparea în raportul final sunt memorate într -un
raport în format .xml. La sfârșitul testului automat, raportul este convertit din format .xml în format
.html , iar amblele variante de raport sunt salvate.

Figure 7 – Exemplu de test report ( .html)

15
În figura 7 poate fi observat antetul unui raport de test în format .html. Antetul unui raport
cuprinde :
– numele functiei testate ;
– partea de informatii generale în care este trecută o s curtă descriere despre functia
testată, date despre persoana care a rulat testul, dar și informații despre programul in
care a fost rulat testul, locația și numele configurației în care a fost rulat testul, locația
și numele testului automat ;
Partea cea mai amplă și cea mai detaliată a raportului este cea în care este descris fiecare
pas al testului. Raportul prezentat în figura 7 este raportul obținut în urma validării funcției de
Autofolding. Așa cum poate fi observat, testul automat testează 9 cerințe funcționale ș i toate
cerințele au îndeplinite cu succes (feedback -ul pentru fiecare caz testat este “ pass”).
Fragment de cod dint -un test report în format .xml :
<testcase starttime="2016 -05-09 17:08.08" timestamp=" 25.46">
<testlogfile f ile="" />
<teststep timestamp="25.46"level="0" type="user"
ident="Do:"result="na">Vehicle in BatTempoLevel</teststep>
<teststep timestamp=" 26.46" level="0" type="user" ident="Do:"
result="na"> I_POSITION_0_SW = 0</teststep>
<teststep ti mestamp=" 26.46" level="0" type="user" ident="Do:"
result="na"> I_TAIL_LAMP_SW = 1</teststep>
<teststep timestamp=" 27.36" level="0" type="user" ident="Do:"
result="na">Lock the vehicle</teststep>
<teststep timestamp=" 27.46" level="0" type= "user" ident="Do:"
result="na">Unlock the vehicle</teststep>
<teststep timestamp=" 27.46" level="0" type="user" ident="Wait:"
result="na">Wait to see the unfolding of the mirrors</teststep>
<teststep timestamp=" 27.72" level="0" type="user" i dent="Check
#1-1" result="na">Unfolding output is active</teststep>
<teststep timestamp=" 27.72" level="0" type="user" ident="PASS:"
result="pass">O_LS_HS_WIPING_EXT::Cur = 0.924000,
swcEMM_AutoFolding_Vbx_UnFolding = 1.000000</teststep>
<teststep timestamp=" 27.72" level="0" type="user" ident="Check
#1-2" result="na">&lt;ERROR in testStep&gt; Wrong type character?
Format: Time is shorter than 200ms + 100ms from CF + 5%</teststep>

16
<teststep timestamp=" 27.72" level="0" type="user" i dent="PASS:
" result="pass">Ok, time is 154.000000</teststep>
<verdict time="2016 -05-09 17:08.12" timestamp=" 29.12"
endtime="2016 -05-09 17:08.12" endtimestamp=" 29.12" result="pass" />
<title>TC_RQT_MIRRORS_FOLDING_50</title>
</testcase>
Pentru că raportul de test este scris în format .xml sau .html, informațiile despre verdictul unei
cerințe funcționale vor putea fi extrase ușor. Se poate observa în fragmentul de cod extras din
raport ca la sfarșitul unui ”testcase” apare o linie care î ncepe cu comanda “ verdict ”, linie la
sfârșitul căreia este scris verdictul (“pass” sau “fail”). Linia urm ătoare identifică numele
“testcase ”-ului executat.

3.8. Baze de date
O bază de date este o colecție de date centralizate, c reată și menținută computerizat și are
scopul de a prelucra datelor în contextul unui set de aplicații. Prelucrarea datelor se referă la
operațiile de interogare , ștergere, actualizare și introducere a datelor .
Orice bază de date are următoarele proprietăți implicite:
 Baza de date este o colecție logică coerentă de date ce are cel puțin un înțeles
 Baza de date este destinată, construită și populată de date despre un domeniu bine precizat.
Ea are un grup de utilizatori și se adresează unui anumit grup de aplicații
 O bază de date reprezintă câteva aspecte ale lumii reale creând orizontul propriu.
Schimbările orizontului sunt reflectate în baza de date .
Câteva dintre avantajele oferite sunt:
 Controlul centralizat al datelor, putând fi desemnată o persoană ca responsabil cu
administrarea bazei de date
 Viteză mare de regăsire și actualizare a informațiilor
 Sunt compacte: volumul ocupat de sistemele de baze de date este mult mai redus decât
documetele scrise

17
 Flexibilitatea ce constă în posibilitatea modificării structurii bazei de date fără a fi necesară
modificarea programelor de aplicație
 Redundanță scăzută a datelor memorate, care se obține prin partajarea datelor între mai
mulți utilizatori și aplicații. În sistemele de baze de date, mai multe aplicații pot folosi
 date comune, memorate o singură dată. D e exemplu, o aplicație pentru gestionarea
personalului dintr -o universitate și o aplicație pentru gestionarea rezultatelor la examene din
aceeași universi tate care folosește o singură bază de date, pot folosi aceleași informații referitoare
la structurarea facultăților.
 Posibilitatea introducerii standardelor privind modul de stocare a datelor, ceea ce permite
interschimbarea datelor între organizații
 Menținerea integrității datelor prin politica de securitate (drepturi de acces diferențiate în
funcție de rolul utilizatorilor), prin gestionarea tranzacțiilor și prin refacerea datelor în caz de
funcționare defectuoasă a diferitelor componente hardware sau s oftware.
 Independența datelor față de suportul hardware utilizat. Sistemul de gestiunea a bazelor de
date oferă o vizualizare a datelor, care nu se modifică atunci când se schimbă suportul de memorare
fizic, ceea ce asigură imunitatea structurii bazei de d ate și a aplicațiilor la modificări ale sistemului
hardware utilizat.

18
4. Formularea problemei
În contextul actual, industria automobilel or este în continuă dezvoltare, iar fiecare modificare
a functiilor existente sau adăugarea unor functionalităț i noi trebuie să fie validată înainte de a fi
integrată pe calculatoarele automobilelor de serie. Fiecare schimbare, fie ea de arhitectură,
schimbare hardware a unor componente sau modificare a unor software -uri, duce la un flux mare
de validare.
Pentru a putea ține pasul cu modificarile care apar , validarea trebuie să fie făcută cât mai
eficient (într -un timp cât mai scurt și cât mai corect). Validarea se realizează î n mai multe etape.
Într-o prim ă etapă componentele sunt evaluate de c ătre furnizori, iar mai apoi, dup ă ce trec o serie
de teste sunt trimise ma i departe. ECU -urile sunt recepț ionate și testate mai apoi pe bancuri de test
special dezvoltate pentru fiecare tip de ECU, dar și intersistem pe platformele de integrare
electrice.
Pentru fiecare soft nou , trebuie verificat ă fiecare funcție a calcu latorului în cauză, iar rezultatul
obținut este comparat cu rezultatele obținute pentru soft -urile anterioare. În cazul în care noul soft
are anumite probleme care nu au ap ărut până în acel moment, noua eroarea t rebuie s emnalată și
trebuie corectată p rintr-o versiune ulterioar ă de soft. Dacă noul soft testat are mai puține erori dec ât
cele anterioare, rezultă că noul soft a r eușit sa corecteze acele erori, iar compararea rezultatelor va
spune exact care sunt bug -urile care au fost eliminate.
În acest moment comparațiile între rapoartele de test ale soft-urile mai vechi și soft -ului nou
testat sunt realizate manual. Acest pas este mare consumator de timp.
Pentru a nu mai pierde timp cu com parația manuală a rezultatelor si pentru a îmbunătății
timpul de validare, soluția ar fi ca această comparație să fie făcută automat .

19
5. Soluția propusă
Soluția propusă constă în realizarea unei aplicații care să gestioneze testele automate și
rapoartele de test rezultate în urma rulării testelor.
Cu ajutorul aplicației, la testarea unui nou software pentru un anumit calculator, putem afla
mult mai rapid dacă rezultatele obținute pentru noul soft sunt mai bune de cât cele obținute pentru
aceleași teste pe o alta versiune de soft ware.
De asemenea aplicația va putea prezice pe baza rapoartelor anterioare ce rezultate vor fi
obținute pentru noul software ce urmeaz ă să fie validat .
Aplicația conține:
 o bază de date ;
 o interfață în care pot fi comp arate diferite rapoarte de test;
 algoritmi de clasificare.

5.1. Tabelele bazei de date a aplicației
Baza de date are mai multe tabele. În unul din tabelele bazei de date sunt indexate rap oartele
de test. Un alt tabel conține info rmații despre toate versiunile de soft testate. Un alt tabel conține
informații despre secvențele de test . Un tabel pentru indexarea tuturor fișierele caietelor de sarcini .
Toate tabelele bazei de date sunt referențiate între ele. De exemplu în tabelul cu rapoartele de test,
câmpul folosit pentru identificarea softului testat este o referință către un câmp din tabela cu
versiunile de software.
În tabela TestReport sunt definite următoarele câmpuri :
– index
– nume raport
– nume functie testata
– soft
– nume test automat
– verdict test

20
– data la care a fost rulat testul
În tabela Software sunt definite următoarele câmpuri :
– index
– nume calculator
– arhitectură
– nume software
– data lansării
În tabela AutomaticTests sunt definite următoarele câmpuri :
– index
– nume test
– nume functie testate
– nume caiet de sarcini
– data crearii
În tabela CaietDeSarcini sunt definite următoarele câmpuri :
– index
– nume
– functie descrisă
– versiune
După definirea tabelelor din baza de da te, baza de da te a fost populată cu rezultatele ultimelor
versiuni de software validate, pentru fiecar e dintre calculatoarele testate (rapoarte, planuri de test,
specificații).

5.2. Descrierea interfeței aplicației
Interfața aplicației are mai multe ecrane. Ecranul principal este un fel de meniu al aplicatiei și
conține mai multe butoane. La apăsarea unuia dintre butoanele din ecranul principal, aplicația
deschide un nou ecran, iar conținutul ecranului deschis este sintetizat în denumirea butonului. Unul
din ecrane este folosit pentru inserarea în baza de date, în oricare din tabele. În alt ecran poate fi

21
interogată baza de date pentru a obține diverse informații, de exemplu ce versiuni de soft au fost
testate ultima dată, care este verdi ctul anumitor functii validate, etc. . Într-un alt ecran poate fi
facută o comparatie între rezultatele a două versiuni software . Așa pot fi detectate rapid care sunt
diferențele între cele două versiuni, pot fi observate probleme ce au fost rezolvate sau noi erori
care au apărut în ultima validare.
Unul dintre ecranele aplicației, poate fi observat in figura de mai jos. Acest ecran este folosit
pentru c ăutarea în baza de date a unui raport, a unui fisier de test sau a unui caiet de sarcini.
Structura acestui ecran este cea a unui formular.

Figure 8 – Formular c ăutare fi șiere în baza de date
Utilizatorul aplicației trebuie s ă selecteze o op țiune pentru fiecare din dropdown list -uri. Pentru
primul dintre ele, denumit “ECU”, utilizatorul trebuie s ă aleag ă un calculotor din lista de
calculatoare validate (USM – UnderhoodSwitchingModule/ EMM EnergyManagementModule/

22
BCM – BodyControlModule). După selectarea tipului de ECU, utilizatorul trebuie s ă selecteze
arhitectura dorita. De exemplu USM -ul este folosit pe arhitecturile C1A, CMF1, CMFB (fig. 9),
în timp ce EMM -ul este folosit pe arhitecturile T4 sau T4VS, iar BCM este calculatorul principal
și se reg ăsește în toate arhitecturile.

Figure 9 – Dropdown list pentru alegerea arhitecturii pentru USM
După alegerea arhitec turi, trebuie selectat proiectul (Rena tul sau Nissan). Exista diferenț e
funcționale între cele dou ă mărci, iar de aceea planurile de test sunt uneori diferite.
Dupa ce este ales proiectul, se trece la alegerea versi unii de software pentru care dorim s ă
obținem informa țiile. Pentru fiecare calculator și pentru fiecare arhitectur ă aferent ă acestora exist ă
un mod specific de denumire a versiunilor.
Următorul pas este reprezentat de alegerea funcției pentru care se dore ște interogarea. Testarea
făcundu -se pentru fiecare func ție în parte, fiecare document (caiete de sarcini, codul testelor
automate, rapoartele) este asociat unei singure func ții. Lista de func ții difer ă de la un ECU la altul.
Func țiile inde plinite de USM și EMM sunt foarte similare, dar exist ă și diferen țe (de exemplu
funcția Gearbox de pe USM nu se regă sește pe EMM). În figura de mai jos poate f i observat ă lista
funcțiilor calculatorului USM.

23

Figure 10 – Dropdown list pentru alegerea func ției pentru USM
La finalul formularului, utilizatorul trebuie s ă aleag ă ce tip de fi șier caut ă. Astfel, se poate
opta pentru c ăutarea caietelor de sarcini (fi șiere .doc sau .pdf) folosite pentru validatea pe versiunea
x, a func ției y pentru ECU -ul z, c ăutarea rapoartelor valid ării (fisiere .xml sau .html) sau a
planurilor de test (fi șiere .can).
După completarea tuturor c âmpurilor, prin ap ăsarea butonului “Cauta”, baza de date este
interogata și se afi șează o list ă cu fi șierele care indeplinesc toate criteriile. Din lista afi șată,
utiliza torul poate selecta unul din fiș iere și îl poate deschide pentru o analiz ă mai am ănunțită. Dacă
în urma interog ării nu este g ăsit niciun fi șier, se afiseaza mesajul “Nu a fost g ăsit niciun fi șier!” și
un buton „Inapoi“ pentru ca utilizatorul s ă poată reveni în ecranul anterior și să modifice criteriile
de căutare.

24
Un alt ecran al aplicației permite utilizatorului să insereze în baza de date noi informații, cum
ar fi raport de test, un nou ECU, software, caiet de sarcini sau test automat.
Codul folosit pentru î nregistrarea in baza de d ate a unui alt calculator (ECU) este prezentat m ai
jos :
<?php
$servername = "localhost";
$username = "root";
$password = "";
$dbname = "ecu";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn ->connect_error) {
die("Connection failed: " . $conn ->connect_error);
}

$numeECU = mysqli_real_escape_string($conn, $_POST['numeECU']);
$data = mysqli_real_escape_string($conn, $_POST['data']);
$descriere = mysqli_real_escape_string($conn, $_POST['descriere']);

// attempt insert query execution
$sql = "INSERT INTO Calculatoare (numeECU, data, descriere) VALUES
('$numeECU', '$data' '$descriere')";
if(mysqli_query($conn, $sql)){
header("Location:ecus.php");
} else{
echo "ERROR: Could not able to execute $sql. " . mysqli_error($con n);
}

$conn->close();
?>

Și acest ecran apare ca un formular (figura 11) , iar pentru a adăuga noi informații în baza
de date, utilizatorul trebuie să completeze campurile formularului. Primul câmp al formularului
“Adaugare informații” permite utilizator ului să precizeze ce tip de informație vrea să adauge.
Acest câmp este un câmp de tip drop -down list și lista de opțiuni este formată din: “Software”,
“Test Report”, “Caiet de sarcini”, “Test automat”. În funcție de ceea ce este selectat la acest câmp
este stabilit în care din tabelele din baza de date se va face înregistrarea. Astfel, vor fi completate
doar acele câmpuri ce țin de opțiunea aleasă. Celelalte câmpuri vor fi ignorate, chiar dacă vor fi
completate. De exemplu, dacă se alege adăugarea unui nou raport de test, trebuie completate

25
câmpurile ECU, Funcție, Software, Nume test automat, Nume raport, Data , Locatie fisier , iar
celelalte câmpuri nu vor fi luate în considerare.

Figure 11 – Formulare adăugare informații în BD
După completarea tuturor informațiilor necesare, pentru a completa operațiunea de
adăugare în baza de date, trebuie apăsat butonul “Adauga ” și se va face insert în baza de date.
Pentru a anula adăugarea de informații și a reveni la prima pagina, se poate a păsa butonul
“Anulează ”.

26
Cel de -al treilea formular al aplicației a fost crest pentru a putea compara rapoartele
aceleași funcții ale unui ECU, dar pe versiuni diferite de softeware. În figura 12 pot fi observate
câmpurile acestui formular.

Figure 12 – Formular comparare rapoarte de test

27
6. Dezvoltări ulterioare ale aplicației
6.1. Mentenanța predictivă
Mentenanță predictivă este ceea ce sugerează și numele: mentinerea resursele și dispozitivelor
electronice, mici sau mai mari, în funcție de așteptările bazate pe fapte pentru atunci când acestea
vor eșua sau au nevoie de service. Aceste fapte pot include următoarele elemente:
 Starea dispozitivului în timp real: Cum este partea care lucreaza acum?
 Dispozitiv de date istorice: Cum a partea realizată în trecut?
 Date pentru dispozitive similare: Cum s -au efectuat alte piese similare?
 Inregistrări de întreținere: Când a fost produsul ultima data in service sau sa fie înlocuit?
 Programele de mentenanta: Ce face ca producătorul sa fie recomandat?
 Inregistrare inspectie: Ce observa inspectorii inspecțiilor lor?
 Inregistrare service : Care s unt ingineri și tehnicieni de învățare în timp ce faci munca
lor?
Toate aceste date sunt lipsite de sens, fără o analiză.
Pentru mentenanta predictiva, se ca uta modalitati de utilizare ale echipamentelor si mediului
in care acestea opereaza si mai apoi in formatia este corelata tinand cont de orice eroare a unui
senzor al echipamentului. Aceste modele si corelatiile lor sunt folosite la crearea unui model
predictiv care este folosit pentru a evalua noile date ale sensorului.
Aplicaț ia va folosi conceptul de mentenanța predictivă și se va încerca prevederea defect ării
anumitor senzori folosi ți pentru validare.

28
6. Concluzii
Aplicația va micșora timpul total de testare a unui nou software pentru unul dint re
calculatoarele automobilului. De asemenea, toate testele automate și toate rapoartele de test vor
putea fi interogate mult mai ușor odată ce vor fi indexate în baz a de date a aplicației.
Folosind aplicația vom știi în orice moment al unei validări care sunt funcțiile care nu au fost
încă validate, dar și starea funcțiilor deja validate (pass sau fail).

29
Bibliografie

[1] CAN – www.e -automobile.ro
[2] L IN – http://www.meo.etc.upt.ro/materii/cursuri/ISMT/10.pdf
[3] SCURT MANUAL DE UTILIZARE A DDT 2000 –
https://ro.scribd.com/doc/64957965/Ddt2000 -Logan -Manual -Incepatori -Simplu -Si-La-Obiect
[4] CANoe – http://vector.com/portal/medien/cmc/manuals/CANoe75_Manual_EN.pdf
[5] Design of an In-Vehicle Network (Using LIN, CAN and FlexRay), Gateway and its
Diagnostics Using Vector CANoe –
http://www.sapub.org/global/showpaperpdf.aspx?doi=10.59 23/j.ajsp.20110102.07
[6] Programing with CAPL –
http://vector.com/portal/medien/vector_cantech/faq/ProgrammingWithCAPL.pdf
[7] CAPL Function Reference Manual –
http://vector.com/portal/medien/vector_cantech/faq/CAPLFunctionReferenceManual.pdf
[8] IBM Predictive Maintenance and Quality 2.0 Technical Overview
http://www.redbooks.ibm.com/redpapers/pdfs/redp5035.pdf
[9] HIL – https://en.wikipedia.org/wiki/Hardware -in-the-loop_simulation
[10] MIL – https://de.wikipedia.org/wiki/Model_in_the_Loop