Laurentiu.nicola Tsr [619665]

UNIVERSITATEA POLITEHNICA TIMIȘOARA

FACULTATEA DE ELECTROTEHNICA SI
ELECTROENERGETICA

TESTAREA FUNCȚIONALĂ A
INSTRUMENTULUI DE BORD
UTILIZÂND FRAME GRABBER

Conducător științific:
Conf. dr. ing. Argeseanu Alin
Masterand: [anonimizat]
2018

2
CUPRINS

CAP 1. INTRODUCERE ………………………….. ………………………….. ………………………….. …… 3
CAP 1.1. Generalități ………………………….. ………………………….. ………………………….. …….. 3
CAP 2.2. Motivația alegerii temei ………………………….. ………………………….. ………………… 3
CAP 2. TESTAREA DE TIP SOFTWARE ………………………….. ………………………….. ………. 4
CAP 3. ECHIPAMENT HARDWARE ………………………….. ………………………….. ……………. 6
CAP 3.1. Instrument de bord (Device Under Test) ………………………….. ……………………… 6
CAP 3.2. Sursă de tensiune: Rohde&Schwarz® HMC804 ………………………….. …………… 7
CAP 3.3. Interfață CAN ………………………….. ………………………….. ………………………….. …. 8
CAP 3. 4. Frame grabber ………………………….. ………………………….. ………………………….. …. 9
CAP 3.5. RS -Box & Test Box ………………………….. ………………………….. ……………………. 10
CAP 4. ELEMENTE SOFTWARE ………………………….. ………………………….. ……………….. 11
CAP 4.1. CANoe ………………………….. ………………………….. ………………………….. …………. 11
CAP 4.2. Mediul de programare CAPL ………………………….. ………………………….. ………. 13
CAP 4.3. United Test Automation System (uTAS) ………………………….. …………………… 14
CAP 5. TESTAREA FUNCȚIONALITĂȚII ………………………….. ………………………….. …… 16
CAP 5.1. Prezentarea funcționalității ………………………….. ………………………….. ………….. 16
CAP 5.2. Prezentarea soluției pentru o testare eficientă ………………………….. …………….. 22
CAP 5.2.1. Crearea SSTS -ului (Software System Test Specification) ………………….. 22
CAP 5.2.2. Crearea imaginilor de referință și a măștii folosite și testarea acestora …. 26
CAP 5.2.3. Prezentarea setup -ului necesar execuției testelor ………………………….. ….. 27
CAP 5.2.4. Metodă alternativă de testare fără frame -grabber ………………………….. ….. 27
CAP 6. CONCLUZII ………………………….. ………………………….. ………………………….. ……….. 29
CAP 7. BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ….. 30

3
CAP 1. INTRODUCER E

CAP 1.1. Generalități

Industria automotive se bucură de o continuă creștere, lucru ce face dezvoltarea
echipamentelor să fie din ce în ce mai complexe. Industria automotive este prezentă peste tot pe
mapamond , iar procesul de dezvoltare este similar în toate mariile companii producătoare.
Dezvoltarea unui produs software presupune mai multe etape : analiza de cerințe,
dezvoltarea modulelor, integrarea mod ulelor, testarea sistemului, etc. . Indiferent de ciclul de
dezvoltare al produsului ( Waterfall, Agile, V -cycle, etc.), produsul va trece printr -o etapa
validare, etapă în care se va verifica că produsul îndeplinește toate specificațiile cerute . Această
etapă este una din cele mai importante si complexe, deoarece produsul este validat atât la nivel
de modul , cât și la nivel de sistem, urmărindu -se mai ales interacțiunea dintre module.
Pentru a facilita această etapă, a fost nevoie de o continuă dezvoltare a echipamentelor
hardware, cât și software care să permită o testare într -un mediu cât mai aproape de cel real al
produsului final. Această dezvoltare s -a realizat în scopul reducerii costurilor, dar mai ales pentru
reducerea riscurilor, astfel încât să fie simulate datele de intrare și să permită verificarea datelor
de ieșire pentru a fi în conformitate cu specificațiile impuse.
Industria automotive fiind într -o permanen tă dezvoltare, sunt necesari timpi cât mai mici în
dezvoltare, astfel, la momentul lans ării, produsul final să fie de actualitate . Testarea sistemelor s –
a realizat în două moduri: testare manuală și testare automată. Datorită dezvolatării tehnologice,
testarea automată prezintă un avantaj important, datorită timpilor favorabili. Cele două tipuri de
testare vor fi folosite în paralel, deoarece testarea automată nu permite testarea unui produs în
întregime.
CAP 2.2. Motivația alegerii temei

Deoarece în ultima perioadă am început să fac parte din Continental Automotive România
în cadrul departamentului de I ID – Interior Instruments Development, și totodată înglobând
pasiunea pentru automotive, alegerea acestei teme a fost una naturală.
În cadrul acestei lucrări, voi face o prezentare a testării de tip automată a funcționalității de
recunoaștere a semnelor de circulație afișate pe display -ul unui intrument de bord al unui
automobil FORD Fiesta

4

Figure 1- Modelul în V CAP 2. TESTAREA DE TIP S OFTWARE

Pentru testarea unui produs, în special un produs automotive, se adoptă de la început o
strategie și o metodă de testare. În cele ce urmează vom prezenta pe scurt ciclul V, ciclu folosit la
dezvoltarea instrumentului de bord FORD.
Testarea este u tilizată pentru a semnala prezența defectelor unui program, fără a garanta
absența erorilor. Testarea este procesul de verificare prin execuție a funcționalității și
corectitudinii programului. (LIE, 2017)
Conform ciclului V, i ndustria automotive se structurează pe mai multe nivele:
– Nivel componentă hardware;
– Nivel componentă software;
– Nivel componentă electrică;
– Nivel subsistem;
– Nivel sistem;
Metodele si tehnicile de testare pentru validare sunt:
– Testarea funcțională;
– Testarea non-funcțională;
– Testarea de tip regresie;
– Testarea de tip răspuns la stimuli;
Validarea completă a unui produs se face după testarea produsului la fiecare nivel al
modelului V .

5
Partea din stânga a diagramei reprezintă lanțul de specificare a sistemului, iar cea din
dreapta, reprezintă lanțul de testare. Baza modelului este reprezentată de etapa de implementare.
Liniile verticale reprezintă înlănțuirea etapelor, iar cele orizontal e indică faptul ca o parte din
rezultatele etapei din care pleacă săgeata sunt utilizate în etapa țintă. (LIE, 2017)
Avantejele unui astfel de model este ușurința de utilizare, fiecare fază având lucruri
specifice, controlabile , dar prezintă dezavantajul rigidității, fiind greu de introdus modificări
ulterioare și nu produce prototipuri timpurii.
Testarea se mai poate împărți în două mari metode: metoda cutiei negre ( black box),
metoda cutiei albe ( white box ) și metoda cutiei g ri (grey box). Prin tehnica cutiei negre,
denumită și testarea funționalității unui sistem, cei care testează privesc obiectul de test ca și pe o
cutie neagră neștiind ce se află în interiorul ei. Acest tip de testare se poate aplica la toate nivele
de tes tare ( modul, integrare, sistem, etc. ). Diferența față de metoda cutiei albe, o constă
subiectivitatea cu care cei care testează privesc produsul. În această metoda este controlată și
verificată modificarea datelor în interiorul programului. Ac eastă metodă se poate aplica
deasemenea la nivelul unitate, sistem, dar cel mai des este folosit la nivelul unitate. Metoda cutiei
gri presupune ca testerul să cunoască o parte din codul folosit în interior, dar testarea să o facă la
nivel de utilizator. C unoscând conceptele din spatele produsului, îi pot fi de ajutor testorului să
facă alegeri mai bune cu privire la scenarii de test folosite.
Pe lângă metodele descrise anterior, se vor trece în revistă și următoarele metode folosite în
procesul de testare:
– Unit testing – metodă în care se testează funcțiile sau modulele de cod, de obicei
utilizată de cei care cunosc design -ul intern al aplicației .
– Integration testing – metodă în care se testează combinația diferitelor părți dintr -o
aplicație pentru a vedea dacă funcționează corect .
– System testing – metodă în care se testează toate părțile unui sistem conform
specificațiilor.
– Usability testing – metodă în care se verifică dacă o aplicație este user -friendly cu un
operator uman.
– Testare de scalabilitate – metodă în care se verifică dacă sistemul își atinge limitele sale
tehnologice.

6
Figure 2- Instrument de bord – Variant B479 S2
CAP 3. ECHIPAMENT HARDWARE

Pentru realizarea unor teste, sunt necesare anumite echipamente care să facă posibilă
simularea mediului dorit, care să permită monitorizarea echipam entului sub test și deasemenea
echipamente care să reducă timpul de execuție. În cele ce urmează vor fi descrise succint
echipamentele necesare și folosite pentru testarea de tip funcțională a funcționalității de
recunoaștere a semnelor de circulație afișa te pe un display al instrumentului de bord.

CAP 3.1. Instrument de bord (Device Under Test)

Instrumentul de bord asigură șoferul cu informații utile, legate de: viteza actuală a
autovehiculului, turațiile motorului, temperatura lichidului de răcire, nivelul carburantului în
rezervor și pe lângă acestea multe alte funcții ce diferă de la un producător la altul.
Imag inea de mai sus reprezintă elementele unui instrument de bord, ma i exact instrumentul
unui FORD Fiesta ce a fost lansat în Aprilie 2017. Acesta este varianta cea mai avansată a
instrumentului de bord, având un ecran de 4.2” color, ce va veni montat pe ech iparea mai
scumpă a automobilului. Pe langă acesta, mai există și o va riantă cu un ecran de 2.3” mono crom

7

Figure 3 – FORD Fiesta –exterior & interior (echiparea cea mai ieftină a automobilului – S0) și încă o variantă cu un ecran de 4.2” TFT
mono crom (echiparea medie a automobilului – S1). Pentru pa rtea practică a lucrării a fost folosit
un cluster S2, de pe o mașină FORD Fiesta .

CAP 3.2. Surs ă de tensiune : Rohde&Schwarz ® HMC804

Pentru a putea alimenta instrument ul de bord, vom avea nevoie de o sursă de tensiune care
să furnizeze o tensiune constanta cuprinsă între valorile de 9 -16V, valori pentru care
producătorul garantează o bună funcționare a instrumentului de bord. Însă, pentru a putea efectua
teste de robusteț e sau teste de stres, vom extinde domeniul de tensiune până la 30V. Astfel, în
urma celor menționate, recomandăm o sursă de tensiune care să prezinte următoarele
caracteristici:
Curent ieșire minim 0A
Tensiune ieșire minimă 0V
Curent ieșire maxim 10A
Tensiune ieșire maximă 30V
Număr ieșiri ≥1
Putere maximă/canal: 50W
Având în vedere cele precizate mai sus, s -a optat pentru o sursă de tensiune
Rohde& Schwarz, model HMC8041, ce dispune de un singur canal cu o putere maximă de 100W,
protecție la supratensiune, un ecran QVGA color pentru afișarea informațiilor, și o caracteristică
foarte importantă, un port serial. Acel port serial permite utilizarea surs ei în testele automate,
fără a mai fi necesară intervenția operatorului uman.

8

Figure 5 – VN1610 și asignarea pinilor Figure 4 – Sursă de tensiune Rohde&Schwarz
HMC8041

CAP 3.3. Interfață CAN

CAN (Controller Area Network) reprezintă o tehnologie de comunicație serială folosită în
special în industria automotive la comunicația între diferite ECU (Electronic Control Unit).
Transmisia fizcă într -o rețea CAN se bazează pe transmiterea unor tensiuni diferențiale. Acest
lucru eli mină efectele negative și nedorite ale interferențelor dintre motor, diverse contacte și
sisteme de aprindere. Transmisia CAN constă în două linii: CAN high line și CAN low line.
Torsadarea celor două linii elimină considerabil câmpul magnetic. Limitarea însă apare la
viteza de propagare. Având în vedere viteza limitată de propagare, apare efectul de reflexie ,
fenomen ce crește odată cu creșterea frecvența datelor transmise. Pentru stoparea acestui
fenomen, se folosesc rezistențe la finalul liniei de trans misie.
VN16 10 este o componentă hardware ce asigură legătura dintre PC și instrumentul de
bord. Prin intermediul acestuia se transmit semnale din PC (simulare) spre intrumentul de bord,
și vice -versa. Acesta se conectează la PC printr -un port USB, iar la capătul celălalt este un
conector D -SUB9 cu 2 canale.

9

Figure 6 – CANcable 2Y conectat la un VN1610
Pentru a accesa ambele canale ale VN -ului, este necesar un cablu CANcable 2Y, care
joacă rolul unui splitter. (VECTOR, 2017)

În continuare vom trece în revistă câteva specificații tehnice ale acestei componente
VN1610:
Canale CAN: 2x CAN high -speed 1051cap
CAN: viteză până la 2 Mbit/s
CAN FD: viteză până la 8 Mbit/s
Domeniu temperatură: Operare: -40°C … +70°C
Depozitare: -40°C … +85°C
Dimensiune: 65 mm x 42 mm x 20 mm
Greutate: 80g
Sistem de operare compatibil: Windows 7 SP1 (32 bit / 64 bit)
Windows 8.1 (32 bit / 64 bit)
Windows 10 (64 bit)

CAP 3.4. Frame grabber

Frame Grabber este un dispozitiv hardware ce face conversia de la un cadru video la o
singură digitală ce poate fi prelucrată de un calculator .
Odată cu evoluția echipamentelor, această funcție a devenit accesibilă chiar și la nivelul
calculatoarelor personale, fiind integrată ca și funcție în placa grafică din calculator. De la o
imagine pe o scală de gri (8 biți) până la o imagine de 16.7 milioa ne de culori, pot fi afișate de o

10

Figure 7 – Arhitectura Frame Grabber placă nu prea costisitoare a unui calculator personal cu o rezoluție de până la 1600 x 1200 pixeli.
(Bernd, 2002)
Se vor trece în revistă câteva din specificațiile necesare pentru a putea face testarea
automată:
Interfață conectare DVI-I
Rezoluție 1920 x 1080p
Cameră monocromă ✓
Cameră color ✓
Intrări video minime ✓
Interfață magistrală PCIE x 4
Frame grabber -ul utilizat în cadrul acestui proiect este bazat pe o arhitectură FPGA pentru
achiziții de imagini, și dezvoltat pentru a salva cadre de la un display de pe intrumentul de bord.
Rezoluția maximă suportată de acest sistem variază de la 320×240 la 1920×720.

CAP 3. 5. RS-Box & Test Box

Aceste două elemente sunt componentele ce ne vor ajuta să simulăm anumiți senzori ai
mașinii, anumite intrări respectiv ieșiri ce nu pot fi simulate cu ajutorul aplicației CANoe.
Test Box -ul poate fi reprezentat ca o soluție manuală în care persoana care testează apasă și
comută pe diferite comutatoare, sau o soluție automată, în care aceste operații sunt executate cu
ajutorul unor relee programabile. Acesta diferă de la proiect la proiect, în funcție de nevoile și
necesitățile ce trebui esc acoperite.

11

Figure 8 – Panou control RS -Box RS-box-ul este defapt o cutie cu rezistențe și comutatoare. Această componentă se poate
controla prin portul serial disponibil de către diferite aplicații. Un astfel de panou de control va
arata de forma:

CAP 4 . ELEMENTE SOFTWARE

Elementele software vor contribui la crearea mediului de simulare astfel încăt să transpună
intrumentul de bord în condiții cât mai aproape de cele din mediul real. Pe lângă aceasta, aceste
elemente vo r contribui la partea de rulare a testelor, făcând posibilă rularea automată cu
intervenții minimale din partea utilizatorului.

CAP 4.1. CANoe

Aceasta este o aplicație de dezvoltare și testare concepută de Vector Informatik GmbH.
Aplicația are principala aria de dezvoltare în automotive și în sectorul de dezvoltare al ECU –
urilor pentru analiză, simulare, testare și diagnosticare. Este foarte răspândită și este acceptată de
toți marii producători în dezvoltarea vehiculelor convenționale, sau chiar cele hib ride și electrice.
Simularea și testarea în CANoe se face cu CAPL, un limbaj de programare foarte interactiv.
(WIKIPEDIA, 2011)

12

Figure 9 – Interfață CANoe cu ferestre de control și analiză CANoe oferă posibilitatea interacțiunii cu mai multe tipuri de rețele (rețea CAN, LIN,
Ethernet, etc. ). Aceasta oferă posibilitatea efectuării de măsurători de timpi, oferă posibilitatea
înregistrării mesajelor sistemului și trimiterea lor la un alt utilizator pentru analiză.

Întrucât acest mediu software este unul foarte complex, vom trece în revistă principalele
aspecte care trebuiesc cunoscute pentru a putea face posibilă rularea testelor propuse în această
lucrare.

Avantajul primordial al acestei aplicații est e interfața prietenoasă cu utilizatorul. Acest
lucru duce la timp și efort salvat în timp ce calitate a și dezvoltarea produsului crește.
Interfața cu utilizatorul este reprezentată prin diverse panouri. În majoritatea aplicațiilor, un
panou corespunde unu i singur nod, pentru a ușura claritatea informațiilor. Fiecare panou va
conține controale vizibile, ce vor interacționa cu utilizatorul la anumite evenimente. Spre
exemplu, când utilizatorul va ajusta valoarea unui control, valoarea variabile de mediu defi nită în
baza de date CAPL, se va asocia și o procedură se execută în CAPL, având ca rezultat final un
feedback pe instrumentul de bord.

13
CAP 4.2. Mediul de programare CAPL

Chiar dacă în sinea lui, CAPL nu reprezintă o componentă software, acesta este u n limbaj
de programare (CAN Acces Programming Language), limbaj utilizat exclusiv în aplicațiile
CANoe și CANalyser , și poate fi considerat ca un mediu de programare.
Prezentarea acestui limbaj se face datorită faptului că, aplicația CANoe fără de aplicați i
CAPL, este capabil să execute doar măsurători simpliste, dar folosind și CAPL, se pot crea
analize mult mai complexe și mai eficiente.
CAPL este un limbaj de programare procedural ce are la bază limbajul C. Este un limbaj
bazat pe evenimente și execută o singură procedură de eveniment la un moment dat. Ca și
evenimente se pot considere următoarele: timere, intrări de la tastatură, porturi seriale/paralele,
variabile de mediu pentru CANoe, etc.. Acest mediu permite realizarea unor aplicații ușor de
utiliz at și de înțeles. Aceste aplicații sunt realizate într -un mediu de dezvoltare numit Browser
CAPL, care este o componentă integrată a aplicației CANoe. Browser CAPL este reprezentat
printr -un editor text și un compilator. Pe lângă funcțiile clasice împrumut ate din limbajul C,
CAPL oferă funcții suplimentare ce permit utilizarea acestuia în situații mai complexe. Acestea
au fost împărțite în următoarele categorii:
– Funcții definite de utilizator – această funcție este similară cu o funcți e ce se definește
în limbajul C. Acestea se pot folosi în subrutine definite de utilizator, numite și
proceduri. În CAPL, funcțiile pot avea același nume, dar liste diferite de parametrii.
– Funcții predefinite – aplicațiile CAPL nu conțin biblioteci, funcțiile adaugându -se la
fiecare versiune de CANoe. Categoriile de funcții suportate de CAPL sunt: matematice
pentru fișiere, de tip timer, variabile de mediu, etc..
– Funcții DLL – acestea sunt biblioteci de rutine, încărcate în aplicație la momentul
execuției. Acestea permit efectua rea unor calcule complexe acolo unde funcțiile clasice
nu ne sunt de ajutor.

14

CAP 4.3. United Test Automation System (uTAS)

Acest tool este unul dezvoltat intern în cadrul companiei Continental Automotive
România , iar scopul este cel de rulare automată a fișierelor de tip SSTS (Software System Test
Specification).
După cum am menționat și la începutul acestei lucrări, se urmărește reducerea timpului de
testar e și crearea unui mediu în care influența unui operator uman să se simtă cât mai puțin.
Acest tool oferă aceste condiții . uTAS -ul este un interpretor ce execută instrucțiuni scrise într -un
document Microsoft Excel. Acele instrucțiuni controlează echipament e, simulări și comunică cu
instumentul de bord. uTAS -ul nu ține loc și de simularea CANoe.

Figure 10 – Workflow uTAS

15

Figure 11 – Interfață Automation Centre
uTAS -ul are la bază mediul de programare LabVIEW, care permite interacțiune cu
echipamente de tehnologie NI -VISA, cu driver -ele specifice și lansate de National Instruments.
Acest tool totuși nu necesită instalarea mediile de dezvoltare LabVIEW să fie instalate pe
calculatorul de test, el fiind o aplicație de tip Runtime.
În cadrul interfeței aplicației uTAS, utilizatorul poate să aleagă proiectul și secvența, sa u
secvențele, ce se vor a fi rulate.

16

CAP 5. TESTAREA FUNCȚIONALITĂȚII

CAP 5.1. Prezentarea funcționalității

Funcționalitatea de recunoaștere a semnelor de circulație este un mecanism de determinare
a limitei de viteze reale de pe traseul autovehicului și afișarea acesteia pe intrumentul de bord.
Acest mecanism se bazează pe datele achiziționate de camera din faț ă a mașinii și procesarea
acestora de unitatea de control.
Când această funcționalitate este activă pe autovehicul, informațiile legate de semnele de
circulație vor fi afișate pe intrumentul de bord sub următoarele forme:
– Sub forma a două indicatoare ( pe care le vom numi RTT -uri )
o Fie două limitări de viteză
o Fie o limitare de viteză și o limitare de depășire
o Fie sub o formă actualizată, veche sau nesigură cu grafica dedicată
– Sub forma a două indicatoare cu informații suplimentare afișate în pagina dedic ată ( pe
care le vom numi IOD – information on demand )
o Fie două limitări de viteză
o Fie o limitare de viteză și o limitare de depășire
o Fie sub o formă actualizată, veche sau nesigură cu grafica dedicată
o Fie informații legate de sistemul de recunoaștere a semnelor de circulație.
Această funcționalitate este una complexă cu multe caracteristici, dar în cadrul acestei
lucrări accentul a fost pus pe testarea semnelor afișate pe intrumentul de bord. În acest moment
intervine întrebarea, DE CE? Pentru testarea m anuală a acestor semne, cu toate combinațiile ar
impune un volum foarte mare de ore. După realizarea și implementarea acestei soluții, timpul de
testare s -a redus de la peste 100 de ore la un volum de 8 ore.
În continuare ne vom definii câteva semnale uti lizate în CANoe care ne vor ajuta la
activarea acestor semn e de circulație pe intrumentul de bord. Aceste semnale fiind confidențiale,
se va alege denumiri fictive. În execuția testelor, numele va trebui să coincidă cu cele din
specificațiile clientului pe ntru a putea activa semnele.

17

Figure 13 – Diagramă funcționare TSR

Figure 12 – Reprezentarea funționalității în bord

18

MOD_OPERARE TSR_STATUS1_MSG TSR_OVERTK_MSG TSR_UNITS TSR_RTT
NORMAL
sau
CRANK Limit_Changed(0x1) Overtk_allwd
(0x1) x
LimAllRestr
(0x2) Mph(0x2)

Alte cazuri

LimAllUnkRestr
(0x3) Mph(0x2)

Alte cazuri

LimAllCancel
(0x4) x

LimforTruckRestr
(0x5) Mph(0x2)

Alte cazuri

LimforTruckUnkRestr
(0x6)
Mph(0x2)

Alte cazuri

LimForTruckCancel
(0x7) Mph(0x2)

Alte cazuri

Lipsă semnal x

Alte cazuri x

Table 1 – State Matrix pentru ACTIVE TSR RTT

19

MOD_OPERARE TSR_STATUS1_MSG TSR_OVERTK_MSG 2 TSR_UNITS TSR_ IOD
NORMAL
||
CRANK Limit_Changed(0x1) Overtk_allwd
(0x0) x
LimAllRestr
(0x1) Mph(0x2)

Alte cazuri

LimAllUnkRestr
(0x2) Mph(0x2)

Alte cazuri

LimAllRainRestr
(0x3) Mph(0x2)

Alte cazuri

LimAllSnowRestr
(0x4) Mph(0x2)

Alte cazuri

LimAllTrailerRestr
(0x5) Mph(0x2)

NORMAL
||
CRANK Limit_Changed(0x1) LimAllTrailerRestr
(0x5) Alte cazuri

LimAllTimeRestr
(0x6) Mph(0x2)

Alte cazuri

LimAllCancel
(0x7) x

LimforTruckRestr
(0x8) Mph(0x2)

Alte cazuri

20

LimforTruckUnkRestr
(0x9) Mph(0x2)

Alte cazuri

LimForTruckCancel
(0xA) Mph(0x2)

Alte cazuri

Lipsă semnal x

Alte cazuri x

Table 2 – State Matrix pentru Active TSR IOD

MOD_
OPERARE TSR_STATUS1_MSG TSR_RESTR1 TSR_SUPORT1 TSR_LIM1 TSR_R TT
Normal || Crank x x DoNotShow
(0x0) x

Limit_Changed
(0x1) LimAllRestr(0x1)
LimAllUnkRestr(0x2)
Rain(0x3)
Snow(0x4)
Trailer(0x5)
Time(0x6) ShowPerm
WithSupp
(0x1)
< >
0x00,
0xFB,
0xFC,
0xFD,
0xFE,
0xFF
ShowPerm
WithoutSupp
(0x2)
LimAllRestr(0x1)
LimAllUnkRestr(0x2)
Rain(0x3)
Snow(0x4)
Trailer(0x5)
Time(0x6) ShowPerm
WithSupp
(0x1)
ShowPerm
WithoutSupp
(0x2)
Limit_Outdated
(0x3) LimAllRestr(0x1)
LimAllUnkRestr(0x2)
Rain(0x3)
Snow(0x4)
Trailer(0x5)
Time(0x6) ShowPerm
WithSupp
(0x1)
ShowPerm
WithoutSupp
(0x2)

21
Limit_Changed
(0x1)
x x LimitCancel
(0xFB)
Limit_Reliable
(0x2)
||
Limit_Outdated
(0x3) LimitCancel
(0xFB)

x x x NoLimit
(0xFF)

x x x Lipsă
semnal

Alte cazuri

Table 3 – State Matrix pentru TSR RTT Limit1

În cele ce urmează, se vor prezenta câteva motive pentru care s -a optat pentru o testare
automată a acestei funcționalități. După cum se poate vedea în tabelele de mai sus, au fost
prezentate doar câteva exemple grafice, nu toate combinațiile posibile. Dup ă un calcul estimativ,
s-au obținut minim 1368 de combinații , folosind evident tehnicile de testare (clase de
echivalență, testare pe graniță, etc.). Dacă se ține cont că aceste semne de circulație diferă de la o
zonă geografică la alta, de exemplu, în cad rul unui autovehicul marca FORD, acesta va mai avea
încă alte 2 zone geografice , cu semne de circulație distincte, unde va fi comercializat , ceea ce
rezultă la un total de 4104 combinații posibile. Acest număr de combinații este unul m inim! Dacă
acest lucr u ar fi testat de un operator uman, dacă pentru fiecare combinație s -ar pierde 60 de
secunde, ar rezulta un total de 246240 de secunde, iar transpus în ore, aproximativ 70 de ore.
Pentru cineva care lucrează la o normă de 8ore/zi, ar rezulta la aproape 2 s aptămâni de muncă
plictisitoare și neproductive. Aces t lucru m -a împins în căutarea unei soluții care să scutească
operatorul uman de această muncă plictisitoare. Soluția va fi prezentată în cele ce urmează.

22
CAP 5.2. Prezentarea soluției pentru o testare eficientă

Pentru a putea rula testele în mod manual, trebuie creat un test bench care să ne permită
acest lucru. Acest test bench este format din elementele hardware prezentate în această lucrare.
Dar pe lângă această parte hardware, trebuie creat și un document care să transpună informațiile
primite de la client în informații mai ușor de înțeles, mai structurate și evident, pregătite pentru o
rulare automată.

CAP 5.2.1. Crearea SSTS -ului (Software System Test Specification)

Acest fișier, precum am spus și în rândurile anterioare, transpune specificațiile de la client
în scenarii de test care sunt într -un format care permite o rulare automată. Structura acestuia se
va prezenta succint, punându -se accent doar pe zonele de inter es pentru această lucrare.
Acest tip de fișier este defapt un fișier de tip Microsoft Excel, și conține următoare sheet –
uri:
– History – prezintă informații despre acel fișier, cum ar fi numele fișierului, autorul
fișierului și o caracteristica foarte importantă a acestui tip de fișier, revizia, aceasta
incrementându -se la fiecare modificare adusă fișierului.
– Guidelines – legătur ile către fișierele generale utilizate în crearea acestuia .
– Info – legendă a culorilor folosite în crearea secvențelor de test .
– Scope, Approach, Environment – descrierea documentului, și prezentarea resurselor
necesare pentru a putea testa acel document.
– Help – prezentarea intrucțiunilor de test, sintaxa și exemple de utilizare.
– Test Control – lista tuturor scenarilor de test, precum și prioritatea acestora, variantele
pe care se aplică acel scenariu. Această listă permite controlul testelor ce se doresc a fi
executate printr -o simplă sintaxă : Enable/Skip.
– Report Template – acest sheet este completat în urma testării cu rezultatele obținute,
precum și informațiile legate de mediul de testare: cine a testat, cum a testat, versiunea
de soft utilizată, varianta utilizată, etc..
– Symbols – lista simbolurilor utilizate în automatizarea scenarilor de test. Acest sheet
permite un control mai bun al update -urilor.
– Macro – prezentate macro -urile utilizate și apelate în interiorul scenarilor de test.
– Setup – inițiali zarea pașilor de rulare a testului.

23

Figure 14 – Structură pagină de test – Cleanup – curățarea mediului de lucru după ce un test a fost rulat, pentru a nu intra în
conflict cu alte teste ce urmează a fi rulate.
Acestea nu sunt toate paginile (sheet -urile) din SSTS . Trebuie sa mai existe o pagi nă în
care să fie toate scenariile de test care se fac pe acea funcționalitate. Aceste scenarii pot fi
împărțite în mai multe pagini, în funcție de criterile alese de autor, dar ele trebuiesc poziționate
între Setup și Cleanup și introduse în sheet -ul de T est Control .
Aceste pagini vor avea următoarea structură:
– Test Condition – condiția de rulare a testului respectiv. Acesta poate să ia una din
valorile Enable sau Skip.
– Unique ID – un ident ificator unic pentru test. Acest identificator trebuie să fie unic
pentru tot proiectul.
– Case name – o descriere scurtă a scenariului de test.
– Step Condition – o linie de cod este executată dacă toate condițiile descrise în această
coloană corespunzătoare liniei sunt îndeplinite.
– Command – instrucțiune pentru interpretor. Comenzile sunt descrise în pagina de Help
a fișierului de rulat.
– Parameters – parametrii instrucțiunilor care deasemenea se pot vedea în pagina de Help
a fișierului de rulat.
În cadrul ac estui proiect, s -au creat două pagini, una din ele reprezentând testele ce se vor
executa cu framegrabber -ul (Test_Icons_ -_Automatic) , și în cel de -al doilea fiind teste tot pentru
aceeași funcționalitate, cu diferența că testarea se va face cu ajutorul un ei camere video
(TrafficSigns) . Această automatizare este tot una benefică, dar cu un setup mai puțin pretențios.
Pentru acele teste e necesară doar o cameră de tip webcam și un monitor. În prezenta lucrare, se
va pune accentu pe automati zarea cu frame gra bber datorită complexități mai mari și a unor
rezultate mai optimizate și mai calitative.
Această automatizare cu frame grabber -ul se va prezenta succind, trecând în revistă
porțiunile mai importante din cod.
Pentru acest test a fost creat și o pagină separată (TSR), numită și Parametrization Sheet, în
care au fost evaluate toate combinațiile posible ale semnalelor. Această pagină se va încărca și se
va utiliza ca și o stivă în uTAS, ea servind ca o listă de combinații ale semnalelor.

24
Această stivă este încărcată prin următoarea secvență de cod:
all assign globalID=stackID
all assign globalVariant=stackVariant
all assign globalActivation=stackActivation
all assign globalDeactivation=stackDeactivation
all assign globalRef_Pic=stackRef_Pic
all assign globalMask=stackMask
all assign global_cfgs=stackCfg_macro
all assign global_values=stackCfg_value
all assign globalIcon=stackIcon
Table 4 – Încărcare stivă uTAS
GlobalID, GlobalVariant etc., reprezintă capul de coloană al stivelor. Astfel fiecare coloană
a fost încărcată urmând ca acestea să fie consumate rând pe rând de către aplicația uTAS.
Următoarea etapă este reprezentată de setarea condiților pentru apariți a semnelor de
circulație corespunzătoare tabelelor de referință. După fiecare activare, se va face o captură de
ecran prin următoarea sintaxă:
all,Available call_macro Take_Picture
Table 5 – Apel macro pentru a crea o captură

vision assign globalClusterImage=DwnImage_
vision concatenate_strings globalClusterImage=globalClusterImage,globalRef_Pic,str
vision concatenate_strings globalClusterImage=globalClusterImage,"_",str
vision concatenate_strings globalClusterImage= globalClusterImage,globalTestedVariant,str
vision call_macro CheckWarning_ON_Devfr
vision take_picture global_camera,globalClusterImage,1
Table 6 – Creare captură Frame Grabber
În primele 4 rânduri se va compune numele sub care imaginea va fi salvată, inițial în
memoria temporală a uTAS -ului, iar ulterior salvată și local în f uncție de rezultate pe parcurs. În
ultimele două rânduri se verifică prezența mesajelor (avertismentelor) pe display, iar dacă nu
sunt, se va face o captură ce va fi sub numele obținut anterior.
După ce a fost obținută această imagine de pe display, urmează a fi comparată cu o
imagine de referiță. Această verificare se va face prin următoarea sintaxă:
all,Available call_macro Compare_Picture
Table 7- Apel macro pentru a compara imaginile
vision compare_images tempResult=globalClusterImage,globalRefPicImage,globalMaskImage
vision ifdefine_condition tempResult==0,0,dec,NotEqual
vision ifdefine_condition tempResult==1,0,dec,Equal
Table 8 – Sintaxă comparare imagini
După cum se poate vedea, în prima linie din sintaxa de comparare, sunt apelate 3 imagini
diferite: ClusterImage, reprezentată prin imaginea ce a fost capturată de pe display, RefPicImage,

25
reprezentată prin imaginea de referință, iar MaskImage reprezentând masca sub care se va face
compararea celor două imagini precedente. Acest workflow va fi prezentat în următorul
subcapitol.
După compararea celor două imagini, va trebui să luăm o decizie. Această decizie este
reprezentată prin ultimele două linii de cod. Acele condiții definite în funcție de rezultate, ne vor
ajuta în următoarele decizii:
all, Equal assign tempResult="OK"
all, Equal jump SaveResult
all, NotEqual save_aquired_image globalClusterImage,1
all, NotEqual concatenate_strings tempResult ="=HYPERLINK( \"",globalErrorImage,str
all, NotEqual concatenate_strings tempResult=tempResult," \",\"NOK \")",str
Table 9 – Tabel decizional în funcție de rezultat
Primele două linii, asignează câmpului corespunzător rezultatelor valoarea OK, fără de a
salva imaginea local. În următoarele linii, se observă condiționarea ca rezultatul comparării
anterioare să fie NotEqual, ceea ce duce la salvarea imaginii achiziționa te de pe display. Aceasta
este salvată sub forma unui link, iar în celula corespunzătoare rezultatelor, se va afișa textul
NOK cu link -ul aferent pozei ce a cauzat eroarea.
Salvarea rezultatelor în celula corespunzătoare fiecărei combinații este salvată cu
următoarele linii de cod:
all open_excel_sheet SSTS_FORD_B479_TrafficSigns.xlsm,TSR
all write_excel_cell globalID, globalReport_ResultColumn,tempResult
all close_excel_sheet
vision clear_image_buffer
Table 10 – Sintaxă salvare rezultate
După ce se deschide fișierul și pagina în care se vor salva rezultatele, se va scrie rezultatul
de OK sau NOK (cu link -ul aferent pozei cu eroare) la coordonatele date de ID și
Report_ResultColumn. Mai apoi se vor închide și buffer -ul cu imaginea salvată temporal va fi
eliberat și pregătit pentru o nouă captură.
Această buclă se va repeta atât timp cât vor fi elemente în stivă. După golirea stivei, se va
trece la testul următor.

26

Figure 15 – Imagine de comparat Figure 16 – Imagine de referință
Figure 18 – Mască Figure 17 – Rezultat comparare
CAP 5.2. 2. Crearea imaginilor de referință și a măștii folosite și testarea acestora

Pentru a putea realiza compararea automată în uTAS vom avea nevoie de imagini de
referință. Aces te imagini au fost create într -o aplicație denumită GMT (Generic Modeling Tool),
aplicație ce realizează un model HMI (Human Machine Interface) ce va fi utilizat ca și referință
pentru aceste tipuri de teste.
În continuare, se va crea o mască peste porți unea ce se dorește a fi testată. Această va
trebui să acopere zona pentru afișarea semnelor de circulație. Aceasta va fi de forma:
În urma aplicării măștii peste zona dorită, se poate observa rezultatul din Figure 14. Chiar
dacă cu ochiul liber nu se poate observa diferențe între cele două, în cadrul testului a fost salvată
imaginea de eroare în care se poate observa cum coordonatele cifrei 0 sunt diferite făță de
imaginea de referință. Evident, această analiză a fost făcută luând în calcul și o toleranță în
analiză. Această toleranță este necesară deoarce pot exista mici offset -uri între cele două imagini,
din cauza metodelor de gener are, precum și a erorilor introduse de frame grabber. Aceste
toleranțe sunt impuse de către client.
Această testare s -a dovedit a fi cea mai eficientă din mai multe motive. Chiar dacă scopul
principal al implementării frame grabber -ului în cadrul testării funcționalității a fost de a testa

27

Figure 19 – Test Bench funcționarea corectă în funcție de specificațiile clientului, această testare ne oferă posibilitatea
găsiri erorilor poate mai greu vizibile cu ochiul liber. Acest lucru crește calitatea testării și
totodată și calitatea rezultatelor noastre, lucru dorit și de urmărit în activitatea noastră de zi cu zi.

CAP 5.2. 3. Prezentarea setup -ului necesar execuției testelor

Pentru a putea realiza acest tip de testare, ne vom folosi de echipamentele prezentate în
capitolele anteri oare. În rândurile ce urmează, vom încerca să legăm între ele echipamentele,
astfel încât test bench -ul nostru să fie unul ușor de folosit și care să conțină toate resursele
necesare. Unele dintre echipamente pot fi totuși opționale, ele neavând un rol che ie în cadrul
testării de acest tip. Schema acestui test bench este de forma:

CAP 5.2. 4. Metodă alternativă de testare fără frame -grabber

O altă metodă, nu la fel de eficientă, dar mult mai rapidă decât testarea manuală,
înlocuiește partea de frame grabber cu o cameră de tip webcam. Această soluție este de multe ori
mult mai la îndemână și mult mai ieftină. Nu necesită echipament special, decât o cameră
webcam și un monitor.

28
Metoda presupune pregătirea t estelor de rulat astfel încăt fiecare combinație să fie afișată
pe ecran/monitorul stației de test într -o fereastră. Astfel odată cu poziționarea instrumentului de
bord lângă monitor, cu ajutorul camerei se va face o captură și imaginea va fi salvată local cu
numele corespunzător combinației. După rularea întregii secvențe, operatorul va trebui să se uite
peste imaginile capturate în care să verifice că imaginea de pe instrumentul de bord coincide cu
cea afișată pe ecran. Această metodă nu va surprinde eror ile de offset , nuanță sau aliniere , care
cu ochiul liber nu sunt tocmai vizibile , dar în funcție de cerințele clientului, această metodă poate
fi utilă în anumite cazuri.

29
CAP 6. CONCLUZII

Testarea software reprezintă o investigație empirică realizată cu scopul de a oferi părților
interesate informații referitoare la calitatea produsului sau serviciului supus testării . (Kaner,
November 2006)
În testarea software putem identifica ca și scop principal identificarea erorilor, izolarea și
mai apoi corectarea defectelor ce au produs acea eroare. Unele defecte pot proveni atât din
greșeală în cod, dar și din neclaritățile cerințelor ascunse.
Noi, c a și ingineri de test, în acest proces trebuie să acordăm timp important analizei de
specificații, astfel încât să întelegem funcționalitatea dorită. După ce au fost analizate
specificațiile, trebuiesc gândite scenariile de test, care să aducă produsul de testat în condiții cât
mai aproape de mediul real utilizând echipamentele puse la dispoziției, atât hardware, cât și
software. Odată gândite aceste teste, se poate creea o automatizare a lor astfel încât timpul de
rulare să scadă și totodată calitatea rezu ltatelor să crească.
Această lucrare susține și demonstrează avatajele pe care o automatizare utilizând tehnica
avansată din prezent poate să contribuie la scăderea timpului de execuției, reducerea efortului
necesar obținerii rezultatelor precum și îmbună tățirea calității rezultatelor.
Această metodă de execuție cu frame grabber -ul a fost generalizată și utilizată pe întreg
proiectul, astfel testându -se orice fel de funcționalitate, care conține de la mesaje și text, până la
icon-uri și elemente grafice. Timpul de implementare a fost unul semnificativ, dar cu trecerea
buclelor de testare, acest timp a fost amortizat, astfel în prezent, obținând timpi reduși și calitate
a rezultatelor.

30
CAP 7. BIBLIOGRAFIE

Bernd, J. (2002). Digital Image Processing. Berlin.
Kaner, C. (November 2006). Exploratory Testing. Orlando, FL.
LIE, I. (2017). Testarea echipamentelor electronice pentru electronica aplicata. În L. IOAN.
VECTOR. (2017). VN1600 Interface Family Manual.
WIKIPEDIA. (2011). Preluat de pe https://en.wikipedia.org/wiki/CANoe.