Sl.Dr.Ing. Mihnea MOISESCU Diana NIȚULESCU 2017 2 Cuprins Listă de Figuri ………………………….. …………………………….. [613027]

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

Listă de Figuri ………………………….. ………………………….. ………………………….. ………………………….. …….. 3
1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. …… 4
2. Descrierea procesului de testare ………………………….. ………………………….. ………………………….. ….. 6
3. Tehnologii existente ………………………….. ………………………….. ………………………….. …………………… 8
3.1. Rețeaua CAN ………………………….. ………………………….. ………………………….. …………………………. 8
3.2. Rețeaua LIN ………………………….. ………………………….. ………………………….. ………………………… 11
3.3. DDT2000 ………………………….. ………………………….. ………………………….. ………………………….. … 13
3.4. CANoe ………………………….. ………………………….. ………………………….. ………………………….. ……. 14
3.5. Vector CANdb++ ………………………….. ………………………….. ………………………….. …………………. 16
3.6. CAPL ………………………….. ………………………….. ………………………….. ………………………….. ……… 17
3.7. Test Report ………………………….. ………………………….. ………………………….. ………………………….. 18
3.8. Baze de date ………………………….. ………………………….. ………………………….. …………………………. 21
4. Formularea problemei ………………………….. ………………………….. ………………………….. ………………. 25
5. Soluția propusă ………………………….. ………………………….. ………………………….. ……………………….. 27
5.1. Tabelele bazei de date a aplicației ………………………….. ………………………….. ……………………. 27
5.2. Descrierea interfeței aplicației ………………………….. ………………………….. …………………………. 28
6. Dezvoltări ulterioare ale aplicației ………………………….. ………………………….. ………………………….. … 38
6.1. Mentenanța predictivă ………………………….. ………………………….. ………………………….. …………… 38
6.2. Taxonomie ………………………….. ………………………….. ………………………….. ………………………….. . 38
7. Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ……. 40
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………. 41

3
Listă de Figuri

Figure 1 – Exemplu de rețea CAN [1] ………………………….. ………………………….. ………………………….. …. 9
Figure 2 – Componentele unui frame trasmis pe CAN ………………………….. ………………………….. …….. 10
Figure 3 – Comunicație LIN [2] ………………………….. ………………………….. ………………………….. ……….. 12
Figure 4 -DDT2000 ………………………….. ………………………….. ………………………….. ………………………… 14
Figure 5 – Interfață CANoe ………………………….. ………………………….. ………………………….. ……………… 15
Figure 6 – Raport de test CANoe ………………………….. ………………………….. ………………………….. ……… 16
Figure 7 – Baza de semnale CAN ………………………….. ………………………….. ………………………….. ……… 17
Figure 8 – Exemplu de cod al unui test automat ………………………….. ………………………….. ………………. 18
Figure 9 – Exemplu de test report ( .html) ………………………….. ………………………….. ………………………. 19
Figure 10 – Formular căutare fișiere în baza de dat e ………………………….. ………………………….. ………… 29
Figure 11 – Dropdown list pentru alegerea arhitecturii pentru USM ………………………….. ………………. 30
Figure 12 – Dropdown list pentru alegerea funcției pentru USM ………………………….. …………………… 31
Figure 13 – Formulare adăugare informații în BD ………………………….. ………………………….. …………… 32
Figure 14 – Formular comparare rapoarte de test ………………………….. ………………………….. …………….. 34
Figure 15 – Secțiune de cod a raportului (.xml) ………………………….. ………………………….. ………………. 36

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 software
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 aj utorul unor tool –
uri testarea software 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ș orat.
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 șapte capitole la care se adaugă și lista de figuri și lista de referințe
bibliografice. În primul capitol sunt prezentate considerente generale despre automobile.

5
Al doilea capitol prezintă pe scurt arhitectura electronică a automobilelor și modurile de testare ale
calculatoarelor integrate în arhitectura au tomobilului.
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 ECU -urilor .
În cel de -al patrulea capitol este formulat ă motivația pentru dezvoltarea aplicației.
Al cincelea capitol prezintă soluția aleasă. În acest capitol este descrisă aplicația dezvoltată.
Cel de -al șaselea capitol prezintă câteva posibilități de dezvoltare ulterioară a aplicației.
În ultimul capitol su nt 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 componentele mecanice acționate electric (motor, cutie de viteze, stergator,
etc) o rețea CAN la care sunt conectate maxim 16 calculatoare. Fiecare calculator este res ponsabil
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, pli erea 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 aprindere
a high beam (fază lungă), calculatorul EMM trebuie să cunoască starea motorului, iar acest semnal
este transmis de la calculatorul BCM (Body Control Modu le).
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 specificat care este comportamentul normal.
Pe baza acestor caiete de sarcini sunt efectuate mai apoi teste pentru a vedea exact dacă calculatorul
testat funcționea ză 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) [9] reprezintă testarea modelului Matlab Simulink al
calculato rului testat. Modelul ce trebuie testat este adăugat în rețea alături de celelalte 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 echipa de modelizare.
Testarea HIL (Hardware In the Loop) [8] reprezintă testarea 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

7
la care calculatorul testa t 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
compone nte trebuie să se afle fizic în banc (faruri, motorașul care controlează ștergătoarele, 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 nevoie de calculatorul testat, nu mai este suficient modelul Matlab
al acestuia.

8
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 este un standard de comunicație serială definită de Organizația Internațională de
Standardizare (ISO) . A fost dezvoltată inițial pentru industria automobilelor pentru a înlocui cablajul
complex cu o magistrală cu două fire. Specificațiile solicită o imunitate ridicată la interferențe electrice
și capacitatea de auto -diagnosticare și reparare a erorilor de date. Aceste caracteristici au dus la
popularitatea CAN într -o varietate de industrii, inclusiv a utomatizarea clădirilor, domeniul medicale
și de producție.
Protocolul de comunicații CAN [11] descrie modul în care informațiile sunt transmise între
dispozitive într -o rețea și sunt conforme cu modelul Open Systems Interconnection (OSI) definit în
terme ni de straturi. Comunicarea efectivă între dispozitivele conectate de mediul fizic este definită de
stratul fizic al modelului. Arhitectura ISO 11898 definește cele mai joase două straturi ale modelului
OSI / ISO cu șapte straturi.
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 a re numeroase avantaje , printre care: facilit area partaj ării de
parametrii între calculatoarele din rețea; măr irea securit ății rețelei; f acilit area diagnostic ării; reduce rea
costul ui 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 tran sfer a datelor de 500 kb /sec este cea utilizată frecvent în industria automobilelor.

9
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 singur fir.

Figure 1 – Exemplu de rețea CAN [1]
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 pentru a elimina
perturbațiile electromagnetice care ar putea aparea în rețea.
Lungimea maximă a magistr alei 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
calculatorul BCM (Body Control Modul). În cazul în care una dintre cele două sub -rețele se def ectează,
cealaltă sub -rețea nu va fi afectată.
Accesul la magistrala CAN se face în momentul în care unul din calculaoarele conectate trimite un
mesaj și are loc întâmplător. Dacă două noduri încearcă să ocupe simultan magistrala, accesul este
implementat printr -o arbitrare nondestructivă.
Un frame trimis pe magistrala CAN este format ca în figura de mai jos, iar semnificația câmpurilor
din figură este:

10
 SOF – bitul unic dominant de pornire a cadrului (SOF) marchează începutul unui mesaj și este
folosit pentru sincronizarea nodurile pe o magistrală după ce aceasta a fost inactiv ă.
 Identificator – Identificatorul standard CAN pe 11 biți stabilește prioritatea mesajului. Cu cât
este mai mică valoarea binară, cu atât este mai mare prioritatea.
 RTR – Bitul un ic de transmisie la distanță (RTR) este dominant atunci când informațiile sunt
necesare de la un alt nod. Toate nodurile primesc cererea, dar identificatorul determină nodul
specificat. Datele de răspuns sunt, de asemenea, primite de către toate nodurile ș i utilizate de orice nod
interesat. În acest fel, toate datele folosit e într-un sistem sunt uniform e.
 IDE – Un bit de extindere a unui singur identificator unic (IDE) înseamnă că se transmite un
identificator standard CAN fără extensie.
 r0 – Bit rezervat
 DLC – Codul de lungime a datelor , pe 4 biți (DLC) conține numărul de octeți de date transmise
 Date – pot fi transmise până la 64 de biți de date
 CRC – Verificarea de redundanță ciclică (CRC) pe 16 biți (15 biți plus delimitator) conține
suma de verificare (numărul de biți transmiși) a datelor anterioare pentru detectarea erorilor.
 ACK – Fiecare nod care recepționează un mesaj precis suprascrie acest bit recesiv din mesajul
inițial cu un bit dominat, indicând faptul că un mesaj fără erori a fost trimis. Dac ă un nod recepționat
detectează o eroare și lasă acest bit recesiv, acesta respinge mesajul, iar nodul de trimitere re trimite
mesajul după reluare. În acest fel, fiecare nod recunoaște (ACK) integritatea datelor sale. ACK este
reprezentat pe 2 biți, unul e ste bitul de confirmare, iar al doilea este un delimiter.
 EOF – acest câmp are 7 biți (EOF), care marchează sfârș itul unui cadru CAN (mesaj)
 IFS – Acest spațiu de interfațare pe 7 biți (IFS) conține timpul necesar pentru a muta un cadru
corect recepționat la poziția sa corectă într -o zonă tampon de mesaje.

Figure 2 – Componentele unui frame trasmis pe CAN
Alocarea priorității mesajelor din identificator este o caracteristică a magistralei CAN, care o face
deosebit de atractivă pentru utilizare într -un mediu de control în timp real. Cu cât este mai mic numărul
identificatorului mesajului binar, cu atât mai m are este prioritatea acestuia. Un identificator constând

11
în întregime din zerouri este mesajul cu cea mai mare prioritate într -o rețea. Prin urmare, dacă două
noduri încep să transmită simultan, nodul care trimite un ultim bit de identificare ca fiind zero
(dominant), în timp ce celelalte noduri trimit unu (recesiv) păstrează controlul asupra magistralei CAN
și continuă să -și finalizeze mesajul. Un bit dominant suprascrie întotdeauna un bit recesiv pe o
magistrală CAN.
Robustețea magistralei CAN se datoreaz ă parțial procedurilor abundente de verificare a erorilor.
Protocolul CAN include cinci metode de verificare a erorilor: trei la nivelul mesajului și două la nivelul
de biți. Dacă un mesaj nu trece testul niciuneia dintre aceste metode de detectare a erori lor, acesta nu
este acceptat și un cadru de eroare este generat de la nodul de primire. Aceasta forțează nodul de
transmisie să retransmită mesajul până când acesta este recepționat corect. Cu toate acestea, dacă un
nod defect blochează o magistrală prin r epetarea continuă a unei erori, capacitatea sa de transmisie
este eliminată de controlorul său după ce se atinge o limită de eroare.
Magistrala CAN este ideală pentru aplicații care necesită un număr mare de mesaje scurte, cu o
fiabilitate ridicată în medi i de operare robuste. Deoarece CAN este bazat pe mesaj și nu este bazat pe
adresă, este deosebit de potrivit atunci când sunt necesare date de la mai mult de o locație, iar
consistența datelor la nivel de sistem este obligatorie.
Determinarea defecțiunilor este, de asemenea, un beneficiu major al magistralei CAN. Nodurile
defectuoase sunt abandonate automat din magistrală, ceea ce împiedică un singur nod să deterioreze o
întreagă rețea și asigură că lățimea de bandă este întotdeauna disponibilă pentru trans miterea mesajelor
critice. Această limitare a erorilor permite, de asemenea, adăugarea de noduri la o magistrală în timp
ce sistemul este în funcțiune.
Multe caracteristici ale transmițătorilor TI CAN le fac ideale pentru numeroasele aplicații robuste
la care se adaptează protocolul CAN. Printre aplicațiile care găsesc soluții cu magistrala CAN se
numără automobile, camioane, motociclete, trenuri de zăpadă, autobuze, avioane, agricultură,
construcții, minerit și vehicule marine.

3.2. Rețeaua LIN
Rețeaua LIN [1] este o rețea de tip single -master / multiple -slave cu o conf igurație flexibilă.
Lungimea mesajelor transmise sau recepționate este variabilă: 2, 4 sau 8 octeți. Rețeaua LIN nu are

12
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 compus 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. Numai unitate a de tip master este capabil să inițieze o comunicare. Un
cadru LIN este alcătuit dintr -un antet și o parte de răspuns. Pentru a iniția o comunicare cu un slave,
master -ul trimite partea antetului. Dacă master -ul dorește să trimită date către slave, master -ul este
responsabil cu trimiterea părții de răspuns. Dacă master -ul cere date de la slave, slave -ul trimite partea
de răspuns.

Figure 3 – Comunicație LIN [14 ]
Comunicarea directă între unitățile de tip slave nu este posibilă. Dar, deoarece toate nodurile
ascultă întotdeauna master -ul, o cerere de master poate fi utilizată pentru a trata comunicațiile slave –
to-slave.
Fiecare mesaj începe cu un semnal de pauză și este urmat de un câmp de sincronizare și de unul
de identificare, to ate trimise 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.
Î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

13
noduri slave. Conținutul unui mesaj este dat de ID. A cesta nu indică destinația mesajului ci
semnificația datelor.
Protocolul LIN este orientat pe obiect și nu orientat pe adresă. Antetul conține identificatorul care
identifică cadrul LIN și datele pe care le conține. Diferite noduri pot primi aceleași date cadru. Partea
de răspuns constă în principal din datele de lungime selectabilă (1 până la 8 octeți). Datele sunt
securizate de un frame de control de 8 biți.
Master -ul trimite periodic aceeași secvență de cadre LIN. La fiecare secvență, ma sterul și s lave-
urile actualizează datele pe care le trimit și le primesc. Secvența trimisă de master se poate schimba în
funcție de evenimentele care apar . Pentru a obține un nivel bun de securitate, există mecanisme diferite ,
cum ar fi biții de paritate pe identificator sau suma de control pe octeții de date.
Pentru a obține un consum foarte redus de energie, master -ul poate trimite un cadru de adormire
a rețelei. Orice nod poate intra în modul de alimentare redusă. Pentru a trezi rețeaua, orice nod poate
trimite un așa -zis semnal de trezire .

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 pro gram, calculatorul pe care rulează DDT2000 trebuie să fie conectat
la rețeaua CAN printr -o priza de diagnoză [ 2].
În cazul în care este testat un singur calculator al automobilului, în interfața programului DDT2000
va fi încărcat numai 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.

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

Figure 4 -DDT2000

Pentru a modifica configurația unui parametru, în interfața programului DDT2000 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. Astfel, î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 citite. În general
calibrările definesc timpii în care calculatorul trebuie să raspundă la anumite comenzi.

3.4. CANoe
Programul CANoe este ut ilizat pentru a urmări evoluția diferitelor semnale în cadrul testelor
efectuate pentru validarea unui calculator [3]. Cu ajutorul acestui program este realizată arhitectura
rețelei CAN pentru testarea HI L a calculatorului vizat. O altă funcție a acestui p rogram este aceea de

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

Figure 5 – Interfață CANoe
Pentru a facilita efectuarea testelor manuale, în acest program pot fi create niște interfețe. În aceste
interfețe pot fi integrate 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”.
Tot cu ajutorul acestui program pot fi rulate secvențele testelor automate [4]. Î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.

16

Figure 6 – 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 d e 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 pentru un semnal care face referire la Ignition și
este reprezentat pe un bit, acesta va avea două stări posibile : Ignitio n requested și Ignition Not
requested.

17

Figure 7 – Baza de semnale CAN

3.6. CAPL
Testele automate rulate în programul CANoe sunt scrise în programul CAPL [5] într-un limbaj
foarte asemănător cu c++. Testele, fie ele automate sau manuale sunt realizate folosind aceleași
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 poat e 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 [6]. Aceste scenarii sunt reprezentate de scenariile de funcționare norm ală și de cele de
funcționare anormală. O anumită cerintă trebuie testată în toate combinațiile de valori pe care le pot
lua semnalele implicate în cerința respectivă pentru a evita primirea unui raspuns presupus “corect”.

18

Figure 8 – Exemplu de cod al unui test automat

În exemplul din figura 8 este ilustrat o parte din codul pentru testarea unei cerințe pentru funcția
calculatorului USM ce controlea ză ventilația (Fan). Funcția “putvalue ” este funcția ce permite
modificarea valor ii 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.

3.7. Test Report
Raportul de test este foarte important în procesul de validare 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 fost într -adevăr realizat și sa rezultatele sunt cele consemnate. Astfel, testele automate aduc un plus
validării HIL, pentru că la fiecare r ulare de test este creat un raport în care este sintetizat
comportamentul în timpul testului al calculatoarelor testate.

19
Î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 9 – Exemplu de test report ( .html)
În figura 9 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 scurtă 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 p as al
testului. Raportul prezentat în figura 9 este raportul obținut în urma validării funcției de Autofolding.

20
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 file="" />
<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 timestamp=" 26.46" level="0" type="user" ident="Do:"
result="na"> I_TAIL_LAMP_SW = 1</tes tstep>
<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" ident="Check #1 –
1" result="na">Unfolding output is active</teststep>
<teststep time stamp=" 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>
<teststep timestamp=" 27.72" level="0" type="user" ident="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 ve rdictul 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.

21
3.8. Baze de date
O bază de date este o colecție de date și are scopul de a prelucra datele . Este o colecția de scheme,
tabele, interogări, rapoarte, ecrane și alte obiecte. Datele sunt de obicei organizate pentru a modela
aspecte ale realității într -un mod care să susțină procese care necesită informații, cum ar fi modelarea
disponibilității camerelor în hoteluri , într-un mod care să susțină găsirea unui hot el cu posturi vacante.
Prelucrarea datelor se referă la operațiile de interogare , ștergere, actualizare și introducere a datelor .
Un sistem de gestionare a bazelor de date (DBMS) [10] este o aplicație software care
interacționează cu utilizatorul, alte ap licații și baza de date în sine pentru a capta și analiza date. Un
DBMS cu scop general este conceput pentru a permite definirea, crearea, interogarea, actualizarea și
administrarea bazelor de date. Sistemele DBMS cunoscute includ MySQL, PostgreSQL, MongoD B,
MariaDB, Microsoft SQL Server, Oracle, Sybase, SAP HANA, MemSQL și IBM DB2. O bază de
date nu este, în general, portabilă între diferite DBMS -uri, dar DBMS poate interopera utilizând
standarde precum SQL și ODBC sau JDBC pentru a permite unei singure ap licații să lucreze cu mai
multe DBMS. Sistemele de gestionare a bazelor de date sunt adesea clasificate în funcție de modelul
de bază de date pe care îl susțin. Cele mai populare sisteme de baze de date din anii 1980 au susținut
modelul relațional așa cum este reprezentat de limbajul SQL. Uneori, un DBMS este denumit în mod
liber o "bază de date".
Formal, o "bază de date" se referă la un set de date corelate și la modul în care este organizată.
Accesul la aceste date este, de obicei, furnizat de un "sistem de gestionare a bazelor de date" (DBMS)
format dintr -un set integrat de software care permite utilizatorilor să interacționeze cu una sau mai
multe baze de date și oferă acces la toate datele conținute în baza de date . DBMS oferă diferite funcții
care perm it intrarea, stocarea și recuperarea unor cantități mari de informații și oferă modalități de
gestionare a modului în care sunt organizate aceste informații.
Din cauza relației apropiate dintre ei, termenul de "bază de date" este adesea folosit ocazional
pentru a se referi atât la o bază de date, cât și la DBMS -ul utiliz at pentru manipularea acesteia.
În afara tehnologiei informației profesionale, termenul de bază de date este adesea folosit pentru a
se referi la orice colecție de date conexe (cum ar fi o f oaie de calcul sau un index de carte).
DBMS -urile existente oferă diverse funcții care permit gestionarea unei baze de date și a datelor
sale care pot fi clasificate în patru grupuri funcționale principale:

22
 Definirea datelor – Crearea, modificarea și elim inarea definițiilor care definesc organizarea
datelor.
 Actualizare – introducerea, modificare a și ștergerea datelor reale.
 Recuperare – Furnizarea de informații într -o formă direct utilizabilă sau pentru prelucrare
ulterioară prin alte aplicații. Datele pr eluate pot fi puse la dispoziție într -o formă care este în esență
aceeași cu cea stocată în baza de date sau într -o formă nouă obținută prin modificarea sau combinarea
datelo r existente din baza de date .
 Administrare – Înregistrarea și monitorizarea utili zatorilor, consolidarea securității datelor,
monitorizarea performanței, menținerea integrității datelor, gestionarea controlului concurenței și
recuperarea informațiilor corupte de un eveniment, cum ar fi un eșec sistem neașteptat.
Atât o bază de date cât și DBMS -ul acesteia sunt conforme cu principiile unui anumit model de
bază de date . "Sistemul de baze de date" se referă în mod colectiv la modelul bazei de date, la sistemul
de gestionare a bazelor de date și la baza de date.
Din punct de vedere fizic, serverele de baze de date sunt computere dedicate care dețin bazele de
date actuale și execută numai DBMS și software -ul conex. Serverele de baze de date sunt, de obicei,
computere multiprocesor, cu memorie generoasă și matrice de discuri RAID utilizate p entru stocarea
stabilă. RAID se utilizează pentru recuperarea datelor în cazul în care oricare dintre discuri eșuează.
Acceleratoarele de baze de date hardware, conectate la unul sau mai multe servere printr -un canal de
mare viteză, sunt de asemenea utiliz ate în medii de procesare a tranzacțiilor cu volum mare. DBMS –
urile se găsesc în centrul majorității aplicațiilor bazei de date. DBMS -urile pot fi construite în jurul
unui nucleu personalizat de multitasking cu suport încorporat în rețea, dar DBMS -urile mo derne se
bazează de obicei pe un sistem de operare standard p entru a furniza aceste funcții.
Bazele de date și DBMS -urile pot fi clasificate în funcție de modelele de baze de date pe care le
suportă (cum ar fi relațional sau XML), tipul (tipurile) computerului pe care le rulează (de la un server
de server la un telefon mobil), limbajele de interogare utilizate pentru a accesa baza de date (cum ar fi
SQL sau XQuery) și ingineria lor internă, care afectează performanța, scalabilitatea, reziliența și
securitatea.
Un sistem de gestionare a bazelor de date oferă trei modalit ăți vizuali zare a bazei de date:
 Nivelul extern definește modul în care fiecare grup de utilizatori finali vede organizarea datelor
în baza de date. O bază de date unică poate avea un număr nelimitat de vizualizări la nivel extern.

23
 Nivelul conceptual unifică diferitele viziuni externe într -o viziune globală . Oferă sinteza tuturor
vederilor externe. Este în afara domeniului de aplicare al diferiților utilizatori finali de baze de date și
este mai degrabă de interes pentru dezvoltatorii de aplicații de baze de date și administratorii de baze
de date.
 Nivelul intern (sau nivelul fizic) reprezintă organizarea internă a datelor în interiorul unui
DBMS. Este preocupat de costuri, performanță, scalabilitate și alte chestiuni operaționale. Se ocupă
cu aspectul de stocare a datelor, utilizând structuri de stocare, cum ar fi inde cși, pentru a îmbunătăți
performanța. Ocazional stochează date despre vizualizări individuale (vederi materializate), calculate
din date generice, dacă există o justificare a performanței pentru o astfel de redundanță. Aceasta
echilibrează toate cerințele de performanță ale viziun ilor externe, eventual conflictuale, în încercarea
de a optimiza performanța generală în toate activitățile.
Arhitectura bazei de date pe trei nivele se referă la conceptul de independență a datelor, care a fost
una dintre principalele forțe motrice iniția le ale modelului relațional. Ideea este că schimbările
efectuate la un anumit nivel nu afectează punctul de vedere la un nivel superior. De exemplu,
modificările la nivel intern nu afectează programele de aplicații scrise utilizând interfețe la nivel
conce ptual, ceea ce reduce impactul modificărilor fizice pentru a îmbunătăți performanța.
Viziunea conceptuală oferă un nivel de indirecție între interior și exterior. Pe de o parte, oferă o
vizualizare comună a bazei de date, independentă de diferitele structu ri de vizualizare externe, iar pe
de altă parte, abstract izează detalii despre modul în care datele sunt stocate sau gestionate (nivel
intern).
Securitatea bazelor de date se ocupă de toate aspectele legate de protejarea conținutului bazei de
date, a prop rietarilor și a utilizatorilor săi. Controlul accesului la baze de date se referă la controlul
asupra cine (unei persoane sau a unui anumit program de calculator) li se permite să acceseze ce
informații din baza de date.
Acest lucru poate fi gestionat dir ect în mod individual sau prin alocarea de persoane și privilegii
grupurilor sau prin alocarea unor roluri unor persoane și grupuri cărora li se acordă apoi drepturi.
Siguranța datelor împiedică utilizatorii neautorizați să vizualizeze sau să actualizeze b aza de date.
Folosind parolele, utilizatorii au acces la întreaga bază de date sau subseturi ale acestuia numite
"subscheme".
Cateva dintre avantajele oferite de bazele de date sunt:

24
 Reducerea redundanței datelor ;
 Reducerea erorilor de actualizare și creșterea coerenței ;
 Integritate mai mare a datelor și independență față de programele de aplicații ;
 Îmbunătățirea accesului la date pentru utilizator i prin utilizarea limbajului gazdă și de
interogare ;
 Securitate îmbunătățită a datelor ;
 Reducerea costur ilor de introducere, stocare și recuperare a datelor ;
 Dezvoltarea facilitată a noului program de aplicații ;
 Controlul centralizat al datelor, existând posibilitatea de a desemna o persoană ca re să fie
responsabilă de administrarea bazei de date ;
 Viteză mare de căutare și actualizare a informațiilor ;
 Volumul ocupat de sistemele de baze de date este mult ma i redus decât documetele in format
fizic ;
 Flexibilitatea − oferă posibilitatea modificării structurii bazei de date fără a fi necesară
modif icarea programelor de aplicație ;
 Redundanță scăzută a datelor memorate − se obține prin partajarea datelor între mai mulți
utilizatori și aplicații ;
 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 date și a aplicațiilor la modificări ale sistemului hardware
utilizat.
Pe langă avantaje, bazele de date au și o serie de dezavantaje:
o Sistemele de baze de date sunt complexe, dificile și consumatoare de timp pentru a fi
proiectate ;
o Costuri substanțiale de pornire hardware și software ;
o Deteriorarea bazei de date afectează toate programele de aplicații ;
o Costuri suplimentare în mutarea dintr -un sistem bazat pe fiși ere la un sistem de baze de date.

25
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 vali dare.
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 trebuie 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.
De fiecare dat ă cand se dorește compar area rezultalelor a două versiuni software, cele două
rapoarte ce trebuie comparate sunt, înt r-un prim pas, căutate pe spațiile de stocare a rezultatelor
validării. Apoi sunt deschise și comparate vizual, mai întai la nivelul de "Test overview ". În secțiunea
de "Test overview " sunt identificate ușor testele pentru care au apărut erori, acestea fiind marcate cu
roșu. Astfel dacă la o primă analiză sunt găsite diferențe între cele două rapoarte, se trece la pasul
următor.
În general sunt comparat e rezultatele validării curente cu rezultatele unei versiuni anterioare de
software, de obicei versiunea precedentă. Diferențele dintre cele două rapoarte sunt analizate si
catalogate astfel :

26
 Eroare nou ă – unul din testele care avea pentru versiunea prece denta un verdict favorabil (pass)
are erori pentru versiunea curenta;
 Eroare persistentă – testul care are erori pentru ambele versiuni și nu îndeplinește cerința
funcțională descrisă în caietul de sarcini ;
 Eroare corectată – unul din testele care avea pentru versiunea precedenta un verdict nefavorabil
(fail) primește un verdict favorabil (pass) pentru versiunea curentă, ceea ce înseamnă că eroarea
din soft+ul precedent a fost corectată.
În cazul erorilor corectate se anunță ca soft -ul nou a corectat problemele respective.
În cazul erorilor persistente se trece și la analizarea amănunțită a raportului de test, pentru a
identifica exact la ce pas al testului a apărut eroarea și pentru a stabili dacă este aceeași eroare care a
apărut și pe versiunea precedentă. La finalul analizei se trimite un raport din care reiese că soft-ul nou
nu a corectat erorile respective și se așteaptă o nouă versiune pentru rezolvarea acestor erori.
Pentru erorile noi apărute în cadrul validării unu i software se face o analiză amanunțită a raportului
de test și se identifică pașii de test care nu au fost respectați. După ce este analizat raportul de test, se
face o validare manuală a cerinței care a provocat eroarea în testul automat. Dacă nici la te starea
manuală rezultatul nu este unul favorabil (pass), se trimite un raport care documentează eroarea și
atestă că soft-ul nou are erori ce nu au apărut în veriunile anterioare.
Tot acest proces de comparare a rezultatelor este mare consumator de timp și îngreunează procesul
de validare.
Pentru a simplifica modul de comparare a rapoartelor ș i pentru a îmbunătății timpul de validare,
soluția ar fi ca această comparație să fie făcu tă automat , prin intermediul unei aplicații.

27
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 decât cele obținute pentru aceleași
teste pe o alta versiune de soft ware.
De asemenea apl icaț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 informaț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
– data la care a fost rulat testul

28
Î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 date 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 interogată baza
de date pentru a obține diverse informații, de exemplu ce versiuni de soft au fost testate ultima dată,
care este verdictul anumitor functii validate, etc. . Într-un alt ecran poate fi facută o comparatie între

29
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 10 – 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/ 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 –

30
ul este folosit pe arhitecturile T4 sau T4VS, iar BCM este calculatorul principal și se reg ăsește în toate
arhitecturile.

Figure 11 – 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ți nem
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
indeplinite 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 fi observat ă lista func țiilor
calculatorului USM.

31

Figure 12 – 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 pent ru 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 me sajul “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.

32
Un alt ecran al aplicației permite utilizatorului să insereze în baza de date noi informații, cum ar
fi un raport de test, un nou ECU, un software, un caiet de sarcini sau un test automat.

Figure 13 – Formulare adăugare informații în BD
Ș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 utilizatorului 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 aces t câmp este stabilit în care din tabelele

33
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ăugare a unui nou raport de test, trebuie completate câmpurile ECU, Funcție, Software, Nume test
automat, Nume raport, Data, Locatie fisier, iar celelalte câmpuri nu vor fi luate în considerare.
După completarea tuturor informațiilor necesare, pentru a completa o peraț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 apăsa butonul “ Anulează ”.
Codul folosit pentru î nregistrarea in baza de date a unui alt calculator (ECU) este prezentat mai
jos. După cum poate fi observat și în cod, se stabilește o conexiune cu baza de date și folosind datele
completate în formular, se face INSERT în baza de date.
<?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 (numeEC U, 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($conn);
}

$conn->close();
?>

Similar cu codul de mai sus sunt scrise toate celelalte porțiuni de cod utilizate pentru adăugarea
în baza de date a unui test report, a unui caiet de sarcini sau a unui test automat.

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

Figure 14 – Formular comparare rapoarte de test
Pentru a realiza comparația între rapoartele de test a dou ă versiuni soft -uri, utilizatorul aplicației
trebuie să răaspundă la o serie de întrebări în completarea formularului, și anume : “Care este numele
funcției pentru care va fi făcută comparația? ” , “Cărui ECU îi aparține această funcție? ”, “C are este
arhitectura pentru care a fost testată funcția? ”, “Pentru ce tip de proiect a fost făcut ă validare? ”,
“Care sunt versiunile software ale caror rezultate vor fi comparate? ”. Până la un anumit punct

35
criteriile de selecție a rapoartelor sunt comune. Nu pot fi comparate rapoartele a două funcții diferite,
rapoartele a două calculatoare diferite chiar dacă arhitectura și numele funcției ar fi același pentru
cele două calculatoare sau rapoartele pentru două arhitecturi diferite, dar pentru același ECU și
aceeași funcție . Chiar dacă aparent am putea face aceste comparații, ele nu sunt posibile deoarece
caietele de sarcini diferă pentru aceeași funcție de la o arhitectură la alta, de la un ECU la altul sau
chiar între proiecte.
Primul câmp al formularului, “ECU ”, este de tip drop -down list și este folosit pentru a selecta
numele ECU -ului pentru care se dorește sa fie făcută comparația. Poate fi ales oricari dintre
calculatoarele înregistrate în tabela Softtware din baza de date (de exemplu EMM, BCM, USM, etc.).
Câm pul “Arhitectură ” este de tip drop -down list și permite alegerea arhitecturii pentru ECU -ul
selectat la primul pas. Anumite versiuni de Software ale unor arhitecturi sau calculatoare diferite, pot
avea același nume, iar pentru a evita orice confuzie trebui e specificate clar, atât numele ECU -ului,
cât și numele arhitecturii.
De asemenea, câmpul “ Proiect ”, de tip drop-down list, reprezintă încă un criteriu de selecție a
rapoartelor ce urmează a fi comparate. Cu ajutorul acestui câmp se precizează dacă rapoartele căutate
corespund validării software pentru un proiect “Nissan ” sau pentru un proiect “Renault ”.
Următorul pas constă în selectarea numelui funcției pentru care se face comparația. Câmpul
“Funcția ” de tip drop -down list afișează o listă cu toate funcțiile despre care apar informații în baza
de date.
Deoarece în baza de date este salvat un singur test report pentru o anumită funcție la finalul
valiării unei versiuni de soft, iar pentru a face o comparație avem nevoie de cel puțin două rapoarte
de test , rezultă că trebuie specficate două versiuni software. Astfel cu ajutorul celor două câmpuri
“Sotware1 ” și “Software2” vor fi selectate cele două versiuni ale căror rapoarte vor fi comparate.
Cele două câmpuri sunt de tip drop-down list și afișează toate versiunile de soft testate, care au
salvate în baza de date
La sfarșitul formularului apar patru butoan e. Prin apăsarea butonului “Test Report SW -1” va fi
deschis raportul de test corespunzător versiuni selectate în câmpul “Sotware1 ”. Astfel utilizatorul are
posibilitatea de a ajunge ușor, printr -un singur click, la acest raport, fără să fie nevoit să caute în
calculator locația raportului. Printr -o singură interogare a bazei de date, raportul este căutat și

36
deschis. Similar, prin apăsarea butonului “Test Report SW -2” va fi deschis raportul de test
corespunzător versiuni selectate în câmpul “Sotware2 ”.
Prin apăsarea butonului “Anuleaza ” se revine la prima pagină a aplicației, iar compararea
rapoartelor este abandonată. Butonul “Compara” este utilizat pentru a face comparația între cele două
rapoarte selectate. După apăsarea butonului “Compara”, dacă toate datele au fost completate corect și
cele două rapoarte la care se face referire sunt găsite în baza de date, se așteaptă un timp pentru ca
rezultatele din cele două rapoarte să fie comparate și la final este afișat un tabel cu rezultatul
comparării.
Compa rarea celor două rapoarte de test se face analizând linie cu linie fisierul .xml al raportului
de test. În primul raport, cel aferent SW -1 sunt identificate numele test elor executate prin cautarea la
începutul fiecărui rând a cuvantului c are se află între cuvintele cheie „<test>” și „</test>”. După
identificarea listei cu testele rulate pentru validarea funcției, sunt cautate tot în varianta .xml a
raportului rezultatele fiecărui test.
Căutarea verdictului pentru fiecare test se face cautând randurile care încep cu cuvântul cheie
„<verdict”, iar în cadrul acestor rânduri verdictul este precizat imediat după cuvântul cheie „result =”.

Figure 15 – Secțiune de cod a raportului (.xml)
După ce sunt identificate testele și verdictele acestora pentru primul raport, sunt căutate în cel
de-al doilea raport verdictele pentru testele identificate în primul raport. Odată ce lista cu rezultate

37
este completă se afișează un tabel care conține doar tes tele care au erori în amble rapoarte și testele
care au rezultate diferite pentru cele doua versiuni software comparate (cele fără eroare în soft -ul
precedent, dar cu eroari în testarea curentă și cele cu erori în soft -ul precedent, dar cu fără erori în
testarea curentă). Astfel sunt identificate în mod automat cele trei categorii de erori amintite în
capitolul precedent:
– Eroare nou ă
– Eroare persistentă
– Eroare corectată

38
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 [7]. Aceste fapte pot include următoa rele elemente:
 Starea dispozitivului în timp real: Cum este partea care lucreaza acum?
 Istoric al dispozitivului : Care a fost starea dispozitivului î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 în service sau când a fost înlocuit?
 Programele de mentenanță : Ce face ca producătorul sa fie recomandat?
 Desfășurare inspecție: Ce observă inspectorii la verificarea dispozitivelor ?
Toate acest e date sunt lipsite de sens dacă nu se face o analiză.
Pentru mentenan ța predictiv ă [12], se ca ută modalit ăți de utilizare a echipamentelor și mediului
în care acestea opereaz ă și mai apoi informa ția este corelat ă ținând cont de orice eroare a unui senzor
al echipamentului. Aceste modele și corela țiile lor sunt folosite la crearea unui model predictiv care
este folosit pentru a evalua noile date ale sensorului.
Pentru a îmbunătății performanțele aplicației, poate fi dezvoltat ulterior un algoritm de mentenanță
predictivă. Cu ajutorul acestuia vor putea fi prevăzute defect ările anumitor senzori folosi ți pentru
validare, dar și degradarea versiunilor de software pentru o anumită funcție.

6.2. Taxonomie
Taxonomia este practica și știința clasificării. Cuvântul este, de asemenea, utilizat ca un
substantiv numărabil : o taxonomie, sau schema taxonomică, este o clasificare specială. Inițial,
taxonomia s -a referit numai la clasificarea organismelor sau la o clasificare specială a organismelor
[13]. Într -un sens mai larg și mai general, se poate referi la o clasificare a lucrurilor sau conceptelor,
precum și la principiile care stau la baza unei astfel de clasificări.

39
Multe taxonomii au o structură ierarhică , dar aceasta nu este o cerință. Taxonomia folosește unități
taxonomice, cunoscute sub denumirea de taxoni (taxon singular).
Taxonomiile de testare software
Mai multe taxonomii au fost propuse în cercetarea testării software -ului pentru a clasifica tehnici ,
instrumente, concepte și artefacte. Următoarele su nt câteva exemple de taxonomii:
 Taxonomi a tehnicilor de testare bazate pe modele ;
 Taxonomia instrumentelor de analiză a codurilor statice.

40
7. Concluzii
În acest ultim capitol sunt prezentate concluziile proiectului de diserta ție reliefând problemele
întâmpinate pe parcursul dezvoltării aplicației, posibi le îmbunătățiri ce pot fi aduse , dar și avantajele
aduse de utilizarea aplicației dezvoltate .
Pe parcur sul dezvoltării aplicației am întâmpinat o serie de probleme. Pentru a putea dezvolta un
algoritm pentru compararea rapoartelor de test , a fost necesară o bază de date care să conțină o serie
tabele pentru a putea indexa documentele necesare comparării . După definirea și popularea bazelor de
date, un alt pas important a fost definirea ecranelor aplicației și a modului de conumicare cu baza de
date. Am întampinat dificultăți la stabilirea conexiunii între aplicație și serverul bazei de date.
Pentru a compara într-un mod cât mai eficient rapoartele de test, a fost nevoie să analizez cu atenție
rapoartele create de programul de testare CANoe, atât în format .xml, cât și în format .html. Astfel am
descoperit că este mult mai simplu să folosesc pentru comparare f ormatul .xml al rapoartelor, deoarece
cu ajutorul unor cuvinte cheie informațiile căutate (numele testelor executate și verdictul acestora)
poate fi găsit mult mai rapid decât în formatul .html al rapoartelor.
Pentru a îmbunătății performanțele aplicației s-ar putea folosi mentenanța predictivă, dar și
taxonomia. Cu ajutorul mentenanței predictive pot fi extrași niște indicatori pentru starea testelor și a
echipamentelor folosite. Taxonomia poate fi folosită pentru a clasifica rapoartele de test si celelalt e
documente din baza de date după alte criterii, cum ar fi cele mai recente teste sau funcțiile cu cele mai
bune rezultate.
Avantajele aduse de implementarea aplicației sunt reprezentate în principal de micșora rea timpul
total de testare a unui nou software pentru unul dint re calculatoare le automobilului. De asemenea, toate
testele automate și toate rapoartele de test pot fi interogate mult mai ușor fiind indexate în baz a de date
a aplicației. Un alt avantaj este r eprezentat de facilitarea comparării rapoartelor de test între diverse
versiuni software.

41
Bibliografie

[1] Aaron Philippe Toll , Local Interconnect Network, Ceed Publishing, 2012
[2] SCURT MANUAL DE UTILIZARE A DDT 2000 – https://ro.scribd.com/doc/64957965/Ddt2000 –
Logan -Manual -Incepatori -Simplu -Si-La-Obiect
[3] CANoe – http://vector.com/portal/medien/cmc/manuals/CANoe75_Manual_EN.pdf
[4] Design of an In-Vehicle Network, Gateway and its Diagnostics Using Vector CANoe –
http://www.sapub.org/global/showpaperpdf.aspx?doi=10.5923/j.ajsp.20110102.07
[5] Programing with CAPL –
http://vector.com/portal/medien/vector_cantech/faq/ProgrammingWithCAPL.pdf
[6] CAPL Function Reference Manual –
http://vector.com/portal/medien/vector_cantech/faq/CAPLFunctionReferenceManual.pdf
[7] IBM Predictive Maintenance and Quality 2.0 Technical Overview
http://www.redbooks.ibm.com/redpapers/pdfs/redp5035.pdf
[8] Martin Schlager , Hardware -in-the-Loop Simulation, Omniscriptum Gmbh & Company Kg., 2008
[9] Young Jae Kim , Integrated Modeling and Hardware -in-the-loop, 2008
[10] IBM Corporation. "IBM Information Management System (IMS) 13 Transaction and Database
Servers delivers high performance and low total cost of ownership". Retrieved Feb 20, 2014.
[11] Texas Instruments. “Introduction to the Controller Area Network (CAN)”. May 2016
(http://www.ti.com/lit/an/sloa101b/sloa101b.pdf )
[12] Mobley R. Keith, An introduction to predictive maintenance, Second edition, 2008
(https://tpm4u.files.wordpress.com/2008/02/an -introduction -to-predictive -maintenance.pdf )
[13] De Andrew P. Sage,William B. Rouse, Handbook of Systems Eng ineering and Management,
chapter „ TOWARD A COMPREHENSIVE FRAMEWORK FOR THE IMPLEMENTATION
OFSYSTEMS ENGINEERING MANAGEMENT: THE FOURDIMENSIONAL“DIAMOND
TAXONOMY ””, 2008

42
[14] Microcontroller Division Applications , LIN (LOCAL INTERCONNECT NETWORK)
SOLUTIONS
(http://www.st.com/content/ccc/resource/technical/document/ap plication_note/10/30/18/b5/90/bc/4c/
73/CD00004273.pdf/files/CD00004273.pdf/jcr:content/translations/en.CD00004273.pdf )