TEHNICI DE TESTARE APLICATE IN DOMENIUL AUTOMOTIVE [303901]
TEHNICI DE TESTARE APLICATE IN DOMENIUL AUTOMOTIVE
LUCRARE DE DISERTAȚIE
Autor: Claudiu-Florin PĂUȘIAN
Conducător științific: Asis.Dr.Ing. Ioan-Valentin Sita
Autor: Claudiu-Florin PĂUȘIAN
Tehnici de testare aplicate în domeniul automotive
Enunțul temei: Lucrarea are ca obiectiv punerea în evidență a metodelor de testare care se utilizează în domeniul automotive și totodată prezentarea unor funcționalități importante și interesante din acest domeniu. S-a pus accent pe 3 funcționalități referitoare la accesul în mașină fără a acționa cheia și la pornirea motorului utilizând Passive Start and Entry
Conținutul proiectului: 1. FUNDAMENTARE TEORETICĂ, 2. IMPLEMENTAREA SOLUȚIEI ADOPTATE, 3. REZULTATE EXPERIMENTALE, 4. CONCLUZII, 5. BIBLIOGRAFIE, 6. ANEXE
Locul documentației: [anonimizat]: Ing. [anonimizat]. [anonimizat]. Maxim Vetoschin
Data emiterii temei: 01.11.2016
Data predării: 11.07.2017
Semnătura autorului
Semnătura conducătorului științific
Declarație pe proprie răspundere privind
autenticitatea lucrării de diplomă
Subsemnatul(a) Claudiu-[anonimizat](ă) cu CI seria SX nr. 420346, CNP [anonimizat],
autorul lucrării:
TEHNICI DE TESTARE APLICATE ÎN DOMENIUL AUTOMOTIVE
elaborată în vederea susținerii examenului de finalizare a [anonimizat], [anonimizat], sesiunea a anului universitar 2016-2017, [anonimizat], [anonimizat], și în bibliografie.
Declar, [anonimizat] a convențiilor internaționale privind drepturile de autor.
Declar, [anonimizat] a mai fost prezentată în fața unei alte comisii de examen de licență.
In cazul constatării ulterioare a [anonimizat], respectiv, anularea examenului de licență.
[anonimizat]
(semnătura)
SINTEZA
lucrării de disertație cu titlul:
Tehnici de testare în domeniul automotive
Autor: Claudiu-Florin PĂUȘIAN
Conducător științific: Asis.Dr.Ing. Ioan-Valentin SITA
1. Cerințele temei: Punerea în evidență a importanței fazei de testare în domeniul automotive.
2. Soluții alese:Testarea sistemului se face la nivel black box iar pentru a testa diferite funcții s-a [anonimizat].
3. Rezultate obținute: [anonimizat].
4. Testări și verificări: Rularea testelor în medii controlate cât mai aproape de mediul real de funcționare.
5. Contribuții personale: Realizarea documentației și implementarea părții practice la locul de muncă. Analiza importanței realizării corecte a testelor asupra unor ansamble de sisteme și subsisteme din domeniul automotive.
6. Surse de documentare: [anonimizat], [anonimizat]e.
Semnătura autorului
Semnătura conducătorului științific
CUPRINS
LISTĂ DE ABREVIERI
ABS = Anti-lock Braking System
APU = Approach Unlock
BCM = Body Control Module
BD = Bază de date
CAN = Controller Area Network
CAPL = CAN Access Programming Language
DTC = Data Trouble Code
ECU = Electronic Control Unit
ESCL = Electrical Steering Column Lock
ID = Identification
HFM = Hands Free Module
LIN = Local Interconnect Network
LF = Low Frequency
MOST – Media Oriented System Transport
PASE = Passive Start and Entry
RFID = Radio Frequency Identification
SDLC = Software/System Development Life Cycle
STLC = Software Test Life Cycle
SUT = Software Under Test
SW = Software
TC = Test Case
TDD = Test Driven Development
TR = Test Report
TS = Test Script
UHF = Ulta High Frequency
WAC = Walk Away Closing
WAL = Walk Away Locking
LISTĂ DE FIGURI
Figura 1. Sisteme de închidere a mașinii
Figura 2. Door Handle și zona WAC
Figura 3. Modalități de deschidere a mașinii bazate pe PASE
Figura 4. Cheie PASE și modul de back up
Figura 5. Zone PASE
Figura 1.1 Body Control Module
Figura 1.2 Eroare, defect, eșec
Figura 1.3 Fluxul procesului de execuție și evaluare a testelor
Figura 1.4 Modelul V
Figura 1.5 Tehnici de testare – clasificare
Figura 1.6 Gray Box
Figura 1.7 Zone LF
Figura 1.8 Sistemul PASE
Figura 1.9 Starea automobilului – cheia în interiorul mașinii
Figura 1.10 Starea automobilului – cheia în afara mașinii
Figura 1.11 Lock by WAC
Figura 1.12 Zone WAC
Figura 1.13 Approach Unlock
Figura 2.1 Procesul de dezvoltare al unui proiect
Figura 2.2 Descrierea aplicației
Figura 2.3 General Settings Tab
Figura 2.4 Walk Away Locking Tab
Figura 2.5 Approach Unlock Tab
Figura 2.6 Manual Test Bench
Figura 2.7 Handfree Module
Figura 2.8 Antene LF
Figura 2.9 Descriere funcției Walk Away Locking
Figura 2.10 Activarea funcției Walk Away Locking
Figura 2.11 Poziționarea cheii în interiorul mașinii
Figura 2.12 Configurare Approach Unlock
Figura 2.13 Test Setup
Figura 2.14 Modulul de test și cazurile de test
Figura 2.15 Inserarea unui modul de test CAPL
Figura 2.16 Editarea unui modul de test CAPL
Figura 2.17 Wake Up Mode – test case
Figura 2.18 Modul Wake Up
Figura 2.19 Modul Sleep
Figura 2.20 Setări – HFM mode
Figura 2.21 Vehicle Speed test case
Figura 2.22 Start Engine
Figura 2.23 ESCL test case
Figura 3.1 Parametrii de diagnoză pentru WAC în momentul deschiderii ușii șoferului
Figura 3.2 Polling în interior și exterior – perioada 300 ms
Figura 3.3 Polling în interior și exterior – perioada 500 ms
Figura 3.4 No request
Figura 3.5 Outside vehicle – zona 2
Figura 3.6 Outside vehicle – zona 3
Figura 3.7 Lock by Walk Request
Figura 3.8 Polling – Lock by Walk Request
Figura 3.9 Citirea parametrilor de diagnoză după Lock by Walk request
Figura 3.10 Approach Unlock– zona 2
Figura 3.11 Citirea parametrilor de diagnoză înainte de Approach Unlock
Figura 3.12 Polling – înainte de Unlock Request
Figura 3.13 Approach Unlock– zona 1
Figura 3.14 Lock Request și Unlock Request
Figura 3.15 Citirea parametrilor de diagnoză după Approach Unlock
Figura 3.16 Polling – dupăUnlock Request
Figura 3.17 HFM Wake Up test case
Figura 3.18 HFM Wake Up Overview
Figura 3.19 Semnalul HFM_Refuse_to_Sleep
Figura 3.20 Raport TS_01
Figura 3.21 Set Vehicle Speed test case
Figura 3.22 Set Vehicle Speed overview
Figura 3.23 Pornirea motorului
Figura 3.24 Semnalul Ignition Request
Figura 3.25 Set Vehicle Speed Panel
Figura 3.26 Citirea vitezei = 30 km/h
Figura 3.27 Citirea vitezei = 0 km/h
Figura 3.28 Raport TS_002
Figura 3.29 Modulul ESCL locked respectiv unlocked
Figura 3.30 TS_03 test case – passed
Figura 3.31 TS_03 overview
Figura 3.32 TS_03 test case – failed
STADIUL ACTUAL
Sistemele de acces au cunoscut o ampla dezvoltare, evoluând de la chei fizice metalice la sisteme complexe formate din cartele și senzori. În prezentarea de mai jos se poate observă evoluția modalității de închidere a mașinii de la utilizarea unei chei fizice simple până la utilizarea unui alt tip de cheie inteligentă, cu ajutorul careia nu trebuie sa intreprindem o altă acțiune în afară de îndepărtarea de autovehicul, cu cheia validă în posesia noastră.
În conformitate cu clasificarea sistemelor de acces prezente în automobilistică există 4 tipuri de sisteme de chei, prezentate în următorul tabel.
Tabel 1. Sisteme de chei
Primul model de chei este cel în care accesul și pornirea mașinii se realizează cu ajutorul cheii fizice clasice, fabricată din metal(Exemplu: Dacia 1310).
Cu ajutorul cheilor de generatia a doua, accesul în mașină se realizează cu ajutorul cheii fizice iar pentru pornirea mașinii se folosește conceptul de transponder (immobilizer). Cheia fizica clasica având integrat un chip RFID în corpul cheii. Pentru pornirea vehiculului cu ajutorul acestui tip de chei, în momentul introducerii cheii în contact, ECU-ul mașinii verifică dacă cheia este criptată si autorizată pentru folosire sau nu. Aceste tipuri de sisteme denumite „immobilizer systems” au fost dezvoltate pentru a preveni copierea cheilor în scopul furtului. Doar cheile care au încorporat un RFID tag și au fost criptate corespunzător pot fi folosite pentru pornirea mașinii. RFID se bazează pe tehnologia LF de la 120 până la 135 KHz. Această tehnologie poate operea în două moduri: pasiv și activ.
A treia generație, în comparație cu cea anterioară, permite accesul remote activ la mașină prin utilizarea butoanelor amplasate pe cheie. Pentru deschiderea automobilului și folosirea unei chei de la distanță este necesară o baterie și o comunicare UHF (315 sau 433 MHz).
Ultima generație de chei implică conceptul de PASE care permite accesul în mașină și pornirea acesteia în modul remote pasiv. Pentru funcționarea corectă a acestui mod, singura condiție este deținerea unei chei valide și criptate corect, de către utilizatorul autovehiculului, fără a fi necesară o interacțiune a acestuia cu autovehiculul. Datorită faptului că utilizatorul nu întreprinde nicio acțiune asupra cheii și nici asupra autovehiculului apare denumirea „Passive Start and Entry”. Mașina se deblocheaza automat în momentul în care cheia validă criptată este detectată în apropierea mașinii iar închiderea se realizează în momentul în care utilizatorul se îndepărtează de mașină. Pentru a fi permis modul remote pasiv se utilizează tehnologia LF prin care se identifică poziția cheii valide criptate, verificandu-se dacă cheia se află în interiorul mașinii sau nu.
Sistemele PASE permit :
Închidere/Deschidere remote utilizând butoanele de pe cheie/card
Închidere/Deschidere utilizând butoanele/senzorii de la mânerele ușilor din față, de la o distanță de aproximativ 1-2 metri
Start by PASE
Închidere/Deschidere utilizând WAC și APU
Din generația PASE face parte funcția denumită Walk Away Locking (WAL) sau Walk Away Closing (WAC) care facilitează acțiunea de închidere a mașinii prin îndepărtarea utilizatorului de aceasta, deținând o cheie/un card criptat. Această tehnologie de acces reprezinta ultimul pas in implementarea actuală a sistemelor de acces.
Funcția WAC este componentă a sistemelor de chei inteligente. Conform unui studiu realizat la o conferinta cu tema sitemelor de tip Walk Away Locking, marea majoritate a utilizatorilor europeni intervievați și-ar dori ca mașina personală să dețină această funcție iar restul ar dori să aibă acces la ea.
Sistemul WAC oferă utilizatorilor cel mai mare grad de confort din punct de vedere al accesului la autovehicul, datorită faptului că utilizatorul nu trebuie sa întreprindă nici o acțiune asupra cheii/cartelei mașinii, daca aceasta prezinta un chip valid și o criptare corectă. Funcția este oferită de Renault, Cadillac, Mercedes, VW si Audi pe o gamă extinsă de modele.
Pentru mașinile de ultimă generație, marca Renault, există 3 modalități de blocare a mașinii, conform fișelor de prezentare ale mărcii :
1. Remote Keyless Entry – utilizând cheia
2. Utilizând Door Handle (Figura 2.a)
3. Remote Keyless Entry – utilizând PASE
Cu ajutorul unei chei inteligente criptate, având toate ușile închise, prin îndepărtarea de autovehicul, la ieșirea din zona de siguranță reprezentată în Figura 2.b). mașina se va închide automat. În momentul închiderii, acest lucru va fi semnalat cu ajutorul unui sunet și cu ajutorul aprinderii luminilor exterioare de doua ori. În cazul în care, în interiorul mașinii sau în zona de siguranță mai există o alta cheie criptată, operațiunea de închidere nu se va realiza.
O altă funcție importanta care face parte din generația PASE este denumită Approach Unlock și permite deblocarea mașinii în momentul apropierii utilizatorului de aceasta.
În Figura 3 sunt prezentate două modalități de deschidere a mașinii. Antenele de exterior trimit semnale LF în mod periodic sau când sunt acționate butoanele de pe mânerele de la ușile din față. Aceste semnale ar putea fi mesaje mai lungi sau mai scurte care conțin identificatorul mașinii. În momentul în care cheia detectează semnalul, trezește microcontroler-ul, demodulează semnalul și îl întrerupe. Cheia răspunde pe canalul UHF, răspuns care este recepționat și verificat de către ECU-ul din mașină. În cazul în care răspunsul e valid mașina este deblocată. În cazul în care se dorește pornirea mașinii este necesară poziționarea cheii în interiorul mașinii, în zona inside prezentată în Figura 5. În această regiune este verificată criptarea cheii, iar dupa verificarea și autentificarea corectitudinii datelor criptate, pornește sau nu mașina.
În modul de back-up, când s-a epuizat bateria de exemplu, utilizatorul poate sa deschidă și să pornească mașina cu ajutorul cheii fizice prezentate in Figura 4. Pentru deschiderea mașinii se utilizează cheia fizică de rezervă, iar pentru pornirea motorului este necesară apropierea acestei chei de transponder.
Figura 4. Cheie PASE și modul de back up
În Figura 5 sunt prezentate zonele acoperite de LF din interiorul și din exteriorul mașinii :
Tabel 2. Controlul accesului PASE [8]
1. FUNDAMENTARE TEORETICĂ
1.1 Introducere
Această lucrare are scopul de a face cititorul să înțeleagă procesul, tehnicile și metodele de testare aplicate unui game largi de produse din industria auto, pentru verificarea și asigurarea funcționării corecte a acestora. Testarea este necesară pentru asigurarea calității și integrității produselor.
Domeniul automotive a cunoscut o dezvoltare foarte mare în ultima perioadă, în momentul actual fiind într-o continuă dezvoltare, astfel încât conducătorii de automobile să aibă posibilitatea să interacționeze cu mașina cât mai ușor posibil și totodată de a avea o siguranță cât mai mare în momentele în care se afla în autovehicul.
Pentru a putea face o demonstrație în acest scop, un prim pas a fost documentarea cu privire la metodele de testare(manuală, semiautomată și automată) iar apoi aplicarea acestora asupra câtorva funcționalități care vor fi prezentate în detaliu în capitolul ”Rezultate Experimentale”.
Pentru faza de testare manuală s-a decis alegerea a două scenarii referitoare la o nouă tehnologie din punct de vedere al accesului în mașină si pornirii acesteia, tehnologie care poartă numele de Passive Start and Entry(PASE). Sistemul PASE se bazează pe chei inteligente criptate prin intermediul cărora se elimină nevoia unui sistem classic electro-mecanic cheie-contact. Astfel se elimina necesitatea folosirii cheii fizice, fiind de ajuns ținerea cheii/cardului în buzunar. În acest mod, mașina se va deschide in momentul în care utilizatorul se apropie de ea, respectiv se va inchide în momentul îndepărtării de aceasta la o distanță de aproximativ 2 metri. Totodată, prin intermediul acestui sistem revoluționar, pornirea mașinii se face printr-o simplă apăsare a butonului de Start, cu condiția existenței cheii criptate în mașină.
Pentru testarea automată a fost nevoie de utilizarea unui soft numit CANoe care permite crearea unor script-uri și rularea acestora generând un raport cu rezultatele obținute. Prin setarea unor variabile prin intermediul unui panou de control, care reprezintă interfața grafică, se poate observa comportamentul echipamentelor utilizate, care simulează componente ale mașinii. Cazurile alese vor fi prezentate în detaliu în capitolul ”Implementare practică”.
Testarea semiautomată îmbină ambele tipuri de testare amintite mai sus. Pentru executarea unui test semiautomat este necesară aplicarea unor setări manuale în completarea rulării automate. Cazurile alese sunt prezentate în detaliu în capitolul ”Implementare practică”.
Echipamentele și baza de date prin intermediul cărora este simulată mașina aparțin companiei Continental Automotive, fiind utilizate în cadrul companiei Arobs Transilvania Software, cu ajutorul cărora am reușit să exemplific conceptele de testare manuală, automată și semiautomată în domeniul automotive.
1.1.1 Introducere în domeniul automotive
Domeniul automotive reprezintă domeniul tehnologic al dispozitivelor electronice utilizate în industria producătoare de mașini, un domeniu în care principalul scop este cel de a oferi utilizatorilor de automobile un grad ridicat de siguranță. Sistemele de control electronic ECU fac parte din categoria dispozitivelor cu o fiabilitate ridicată, fiind necesară o testare strică a fiecărui ECU pentru garantarea securității.
Comunicația dintre ECU-uri se realizează prin cu ajutorul protocoalelor de comunicație. Câteva exemple de protocoale de comunicație utilizate în domeniul automotive sunt : LIN (Local Interconnect Network), CAN (Controller Area Network), Ethernet, MOST (Media Oriented System Transport), FlexRay etc. care sunt descrise în detaliu în sectiunea urmatoare.
În momentul de față, ECU-rile integrate in automobile se dezvoltă din ce în ce mai mult. Pentru automobilele de lux se estimează că sistemele electronice reprezintă aproximativ 23% din costul total al automobilului iar aproximativ 80% din inovațiile aduse în domeniul automotive fac parte din categoria sistemelor electronice. [3]
Dintre ECU-urile prezente în interiorul unei mașini cel mai important este BCM-ul (Body Control Module) care are rolul de a controla toate celelalte ECU-uri. BCM-ul acoperă o gamă largă de facilități cum ar fi confortul, sistemul multimedia, luminile și tehnologiile de acces atât în interiorul cât și în exteriorul mașinii, facilități care pot fi observate în următoarea figură.
1.1.2 Protocoale de comunicație utilizate în domeniul automotive
Protocoalele de comunicație utilizate în industria automotive se clasifică în funcție de viteza de transmitere a datelor. În acest moment se folosește următoarea clasificare a sistemelor de comunicație :
Tabel 1.1 Protocoale de comunicație utilizate în industria automotive
Cele mai importante două protocoale utilizate în domeniul automotive sunt CAN și LIN.
Protocolul CAN (Controller Area Network) are următoarele caracteristici :
Robustețe
Viteză de transmitere a datelor relativ mare.
Utilizare : managementul motorului, transmisiei și al sistemului de frânare clasic.
Protocolul LIN (Local Interconnect Network) are următoatele caracteristici :
protocol simplu
ieftin
viteză mică
Utilizare : controlul sistemului de închidere centralizată, climatizare, oglinzi electrice, etc.
Spre deosebire de CAN, care utilizează două fire pentru comunicație, LIN utilizează un singur fir.
1.2 Testare – noțiuni fundamentale
1.2.1 Scopul și costul testării
Scopul testării este acela de a asigura calitatea unui produs software astfel încât acesta să satisfacă cerințele clienților. Testarea presupune indetificarea problemelor existente într-un produs software pentru a reuși remedierea acestora în faza incipientă a proiectului pentru a reduce costurile.
Procesul de testare este realizat de către o echipă de testare. Din atribuțiile unui tester fac parte următoarele:
Primirea informațiilor legate de test, informații referitoare la detalii privind proiectul, tool-uri folosite etc.
Crearea cazurilor de test (TC) – Un TC reprezintă un scenariu/caz prin care se verifică, cu ajutorul unor condiții inițiale și parametrii bine definiți, funcționarea corectă sau nu a produsului.
Crearea script-urilor (TS) – Un test script reprezintă scrierea setului de instrucțiuni cu ajutorul cărora se realizează testele automate.
Crearea rapoartelor de test (TR) – Un Test Report conține numărul de teste care au trecut sau nu au trecut și totodată precondițiile, condițiile inițiale, rezultatele așteptate și rezultatele primite.
Să raporteze problemele identificate Test Manager-ului.
O parte din cauzele aparitiei erorilor sunt interacțiunea imprevizibilă a componentelor, eroarea umana , complexitatea sistemului, interpretarea greșită a specificațiilor, termenul limită dus la extrem etc. Eroarea este considerată o eroare de programare în cod care duce la un defect, care la rândul lui se manifestă printr-un eșec. Cei doi termeni, eroare si defect, au o cu totul altă
întelegere.
Costul testării ocupă o parte importantă în costul total al aplicațiilor software. Ponderea costului testării din costul proiectului începe de la 30% și poate ajunge chiar și la 50%. Costul testării software include cheltuieli pentru tool-uri dedicate, pentru personal specializat și consumul de resurse.
În procesul de testare se identifică următoarele etape conform :
planificarea procesului de testare
analiza și proiectarea testelor
implementarea testelor
execuția testelor și evaluarea rezultatelor
Cheltuielile totale de testare pot fi calculate ca o sumă a urmatoarelor componente: cheltuieli pentru planificarea testării + cheltuieli pentru analiza și proiectarea testelor + cheltuieli pentru implementarea testelor + cheltuieli pentru execuția și evaluarea testelor. Procentajul fiecărei componente în parte este variabil în funcție de fiecare proiect.
Există trei etape principale în procesul de dezvoltare al unui produs software :
Dezvoltare
Testare
Livrare
Erorile depistate și fixate în faza incipientă de descriere a specificațiilor nu costă practic nimic, datorită identificării rapide, însă erorile depistate după livrarea produsului măresc costul acestora semnificativ. În consecință, cu cât erorile sunt depistate în fazele incipiente ale dezvoltării unui produs, cu atât costul remedierii erorilor va fi unul cat mai mic.
1.2.2 Etapa de planificarea a testelor
Etapa de planificarea a testelor se realizează împreuna cu managementul proiectului în funcție de planificarea întregului proiect.
Pentru această etapă este necesară alocarea de resurse specificându-se clar bugetul și perioada de timp în care se va derula testarea pentru proiect.
Necesitatea etapei de planificare este dată de stabilirea exacta a funcționalităților care trebuie testate și totodată de durata testării acestora.
Planul de test rezultă în urma planificării atente a testelor și reprezintă un document foarte important deoarece, pe baza acestuia se desfășoară întreg procesul de testare. Planul de test cade în responsabilitatea Test Managerului. Este de preferat ca planificarea testării să fie facută în momentul elaborării software-ului.
În planul de testare, sunt trecute următoarele:
responsabilitățile membrilor din echipa de testare
timpul estimate necesar executării tuturor testelor
specificarea mediului în care rulează aplicația
configurarea mediului specific aplicației
echipamentele si resurse necesare
Planul de test trebuie să conțină strategii de testare care se referă la criteriile de acceptare și de finalizare a testării, Entry Criteria(Condiții specifice sau activități în desfășurare care trebuie sa fie prezente înainte de începerea procesului de testare) și Exit Criteria(Condiții specifice sau activități în desfășurare care trebuie prezentate înainte de încheierea unei faze din ciclu de dezvoltare).
Definirea criteriului de intrare se realizează cu ajutorului unui set de teste. Dacă în urma rulării acestora avem un rezultat pozitiv(passed), se poate incepe procesul de testare. În caz contrar, dacă aceste teste sunt failed, se refuză soft-ul deoarece nu are rost continuarea execuției testelor.
Criteriul de ieșire reprezintă condițiile care trebuie îndeplinite pentru a considera procesul de testare complet.
1.2.3 Analiza și crearea testelor
Etapa de analiză are ca scop înțelegerea specificațiilor pe baza cărora are loc etapa de implementare a soft-ului.
După finalizarea analizării specificațiilor se incepe crearea testelor necesare verificării funcționalitaților. Crearea testelor sau test case design se face astfel încât să fie acoperite toate cerințele, existând posibilitatea ca o cerință să nu poată fi acoperita de un singur test dar și cazul în care un test acoperă mai multe cerințe.
Cazurile de test sunt alcătuite din date de intrare în precondiții, setări în partea de procedură și verificări în partea de rezultate așteptate. În general, un caz de test arată asfel :
Precondiții :
{
Precondiția I
Precondiția II
…
}
Procedură :
{
Setare I
Setare II
…
}
Rezultate așteptate :
{
Verificare I
Verificare II
…
}
După crearea testelor acestea se salvează într-o configureție care va putea fi folosită ulterior iar rezultatele intr-o bază de date.
1.2.4 Etapa de implementare a testelor
Etapa de implementare a testelor se referă la crearea scripturilor pentru testarea automată.
Implementarea secvențelor de test se realizează în limbaje specifice mediilor de testare asemănătoare Visual Basic sau se utilizează limbaje de programare evoluate (C++, Java). Prin reutilizare, se pot folosi proceduri de test din proiectele anterioare sau din cadrul aceluiași proiect pentru module ce au părți comune. Prin reutilizarea testelor, cheltuielile din aceasta fază se reduc, însa reutilizarea nu este întotdeauna posibilă.
1.2.4 Execuția și evaluarea testelor
În etapa de execuție și evaluare a testelor din cadrul procesului de testare sunt executate testele manuale și cele automate. În urma execuției testelor se obține un anumit rezultat care urmează să fie comparat cu rezultatul așteptat specificat în scenariul de test. Dacă aceste două rezultate coincid testul este passed, în caz contrar este failed.
În urmatoarea figură este reprezentat procesul de execuție pentru un caz de test. Primul pas este o analiză a scenariului de test și executarea acestuia, execuția putând fi făcută manual sau automat. În urma execuției se obține un rezultat ce urmează sa fie salvat într-o bază de date. În cazul în care testul este failed procesul continuă prin raportarea problemei găsite și analiza acesteia de către echipa de dezvoltare. Dacă se ajunge la concluzia că problema este reală, următorul pas este soluționarea acesteia și totodată retestarea specificației/cerinței pentru asigurarea faptului că problema a fost înlăturată. Acest tip de retestare se numește regression testing. În cazul în care în urma evaluării se ajunge la concluzia că nu există o problem si ca a fost un False Fail, nu se face nicio modificare.
1.3 Modelul V – Noțiuni fundamentale
1.3.1 Schema bloc a modelului V
În figura 1.4 este prezentată schema modelului V :
1.3.2 Nivele de testare
Partea din stânga a modelului V reprezintă partea de development denumită SDLC (Software/System Development Life Cycle), iar partea din dreapta este partea de testare denumită și STLC (Software Test Life Cycle).
În figura prezentată mai sus, se poate observa dispunerea modelului V sub forma:
Software
System
Client
Software Testing
Testarea software se poate face pe 3 nivele:
SW Unit Test
SW Integration Test
SW Requirement Test
Software Unit Test
Acest nivel de testare este bazat pe urmatoarele componente: cerințele componentei, design detaliat și cod.
Obiectele tipice de test sunt: componente, programe, conversii de date/programe de migrație, module de baze de date.
Testarea unităților sau testarea componentelor se face cu scopul de a identifica defecte și verifică funcționarea corectă a modulelelor software, a programelor, a obiectelor, a claselor etc., care pot fi testate separat. Aceasta poate fi făcută izolat de restul sistemului, depinzând de contextul în care se află procesul de dezvoltare.
Testarea componentelor poate include testarea caracteristicilor funcționale și non-funcționale.
În general, testarea componentelor se face cu acces la codul care trebuie testat și cu suportul unui mediu de dezvoltare, cum ar fi un framework de testare unitară sau un tool de debugging. Acest nivel de testare implică comunicare și colaborare cu programatorul care a scris codul. În mod normal defectele sunt fixate în momentul în care sunt descoperite, fără alți pași intermediari și fără implicare la nivel administrativ.
O abordare a testării componentelor este cea în care se pregătesc și se automatizează cazurile de test înainte de codare. Această abordare se numește TDD (Test Driven Development). Ea este iterativă și se bazează pe ciclul de dezvoltare a cazurilor de test, apoi construirea și integrarea bucăților de cod și executarea testelor unitare, corectând orice problemă și incrementându-se până când trec.
b) Software Integration Test
Acest nivel de testare este bazat pe design-ul software și design-ul sistemului, arhitectură, workflow-uri și use case-uri.
Obiectele tipice de test sunt : subsistemele, implementarea bazei de date, infrastructura, interfețele, configurarea sistemului și a datelor.
Nivelul acesta presupune o interfațare a componentelor și interacțiunea cu diferite părți ale sistemului, cum ar fi sistemele de operare sau fișierele.
Testarea de integrare poate avea mai multe nivele:
1. Testarea integrării componentelor care verifică interacțiunea dintre componentele software și are loc după testarea componentelor.
2. Testarea integrării sistemului care verifică interacțiunea dintre diferite sisteme sau dintre hardware și software și poate fi făcută după testarea sistemului.
Cu cât scopul integrării este mai mare, cu atât este mai dificilă izolarea defectelor unei componente specifice sau a unui sistem specific, ceea ce duce la creșterea riscului și la creșterea timpului pentru rezolvarea problemelor. [1]
Strategiile integrărilor sistematice pot fi bazate pe arhitectura sistemului, task-uri funcționale, secvențe de procesare a tranzacțiilor, sau alte aspecte ale sistemului sau ale componentelor. Pentru a ușura izolarea erorilor și pentru detectarea preventivă a defectelor, integrarea ar trebui sa fie incrementală și nu de tip “big-bang”.
Testarea unor caracteristici non-funcționale specifice pot fi incluse de asemenea în testarea de integrare la fel ca și testarea funcțională. [1]
În fiecare etapă a integrării, testerii se concentrează exclusiv pe integrarea propriu-zisă. De exemplu, dacă se integrează două module A și B, centrul de interes este verificarea comunicării dintre module și nu funcționarea individuală a modulelor, deoarece aceasta a fost făcută la nivelul testării unitare. Poate fi folosită abordarea funcțională și cea structurală.
În mod ideal, echipa de testare ar trebui să înțeleagă arhitectura și influența planificării integrării. Dacă testele de integrare sunt planificate înainte de construirea componentelor și a sistemului, acele componente pot fi construite în ordinea cea mai eficientă pentru testare [1].
c) Software Requirement Test
În faza de testare a cerințelor software, software-ul este testat în conformitate cu cerințele funcționale de software. Această fază poate fi pusă în aplicare doar în cazul în care cele două faze anterioare au fost finalizate cu succes.
2. System Testing
Pentru testarea de sistem există 2 nivele :
System Integration Test
System Requirement Test
Acest nivel de testare este bazat pe specificațiile cerințelor sistemului și a software-ului, use case-uri, specificații funcționale și rapoarte cu analizele riscului.
Obiectele tipice de test sunt : manualele sistemului, utilizatorului și a operațiilor și totodată configurarea sistemului și configurarea datelor.
Testarea sistemului are în vedere comportamentul întregului sistem/produs.
În testarea sistemului, mediul de testare ar trebui să corespundă cât mai mult cu target-ul final sau mediului de producție, pentru a minimiza riscurile erorilor datorate neconformității mediului de testare.
Testarea sistemului poate include teste bazate pe riscuri și/sau pe specificațiile cerințelor, procese business, use case-uri, sau alte descrieri de text high-level sau modele comportamentale ale sistemului, interacțiuni cu sisteme de operare, și resurse de sistem. [1]
Testarea sistemului trebuie să verifice cerințele funcționale și non-funcționale ale sistemului și caracteristicile calității datelor. Echipa de test are de-a face de asemenea și cu cerințe incomplete sau care nu sunt bine documentate. Testarea de sistem a cerințelor funcționale începe prin utilizarea adecvată a tehnicilor bazate pe specificații (black-box) pentru aspectele din sistem care trebuie testate. Se pot utiliza tehnici bazate pe structură (white-box) pentru evaluarea rigurozității testării care respectă un element structural, cum ar fi o structură de meniu sau o navigare pe o pagina web.
De obicei, acest tip de testare este efectuat de o echipă de testare independentă [1].
3. Acceptance Testing
Pentru testarea de acceptanță există un singur nivel :
Vehicle Test
Bazele acestui nivel de testare : cerințele utilizatorului, cerințele sistemului, use case-uri, procese business și rapoarte de analize de risc.
Obiectele tipice de test sunt: procese business pe sistemul integrat în totalitate, procese operaționale și de mentenanță, proceduri de utilizator, formulare, rapoarte, date de configurare.
Scopul testării de acceptanță este de a stabili un anumit grad de încredere în sistem, în anumite părți ale sistemului sau în anumite caracteristici non-funcționale ale sistemului. Principalul obiectiv al testării de acceptanță nu este acela de a descoperi defecte.
Testarea de acceptanță poate verifica și demonstra dacă sistemul este pregătit pentru furnizarea acestuia către utilizatori.
Testarea de acceptanță poate sa se desfășoare în mai multe perioade pe parcursul dezvoltarii sistemului:
Un anumit produs software poate fi trecut prin etapa de acceptanță în momentul în care
este integrat.
Testarea de acceptanță a utilității unei componente poate fi făcută în timpul testării unitare.
Testarea de acceptanță a unei noi funcționalități poate fi făcută înainte de testarea sistemului.
Forme uzuale ale testării de acceptanță sunt:
User acceptance testing – se verifică utilizarea sitemului de către utilizatorii business.
Operational testing – testarea de acceptanță făcută de administratorii de sistem.
Contract acceptance testing – se compară criteriile de acceptanță contractate.
Alpha and beta testing – testarea alfa este efectuată la locul unde a fost dezvoltată aplicația însă nu de către echipa care a dezvoltat-o, iar testarea beta este efectuată de clienți sau de potențiali clienți.
1.4 Tehnici de testare
1.4.1 Clasificare
În figura urmatoare este prezentată o clasificare a tehnicilor de testare. După cum se observă în imagine tehnicile de testare se împart în două mari categorii : Black Box și White Box.
1.4.2 Testarea Black Box
Testarea de tip Black Box este o tehnică de testare software care testează funcționalitatea software-ului under test (SUT) fără a ține cont de codul intern al programului, de detalii legate de partea de implementare și nu sunt necesare cunoștințe legate de partea internă a soft-ului. [13]
Tipurile de testare Black Box sunt :
Testare funcțională
Testare non – funcțională
Testare de regresie
Testarea funcțională se bazează pe documente cu specificații funcționale și poate fi utilizată atât pentru testarea manuală cât și pentru testarea automată. În general această metodă este mai accesibilă utilizând testarea manuală.
Pentru aplicarea testării funcționale se urmăresc cinci pași :
1. Crearea cazurilor de test pe baza specificațiilor furnizate
2. Specificațiile sunt considerate input-uri pentru testarea funcțională
3. Verificarea output-urilor pe baza specificațiilor
4. Execuția cazurilor de test
5. Analiza comportamentului inițial și a rezultatelor așteptate
Tipuri de testare funcțională : unit testing, integration testing, system testing, regression testing etc.
Testarea non-funcțională, spre deosebire de testarea funcțională, testează atributele unei componente sau ale unui sistem care nu sunt legate de funcționalitate.
Tipuri de testare funcțională : performance testing, stress testing, security system, load testing etc.
Testarea de regresie presupune retestarea selectivă a unui sistem sau a unei componente pentru a verifica faptul că modificările efectuate în cod nu au cauzat efecte nedorite. Testele de regresie sunt un subset al setului inițial de scenarii de testare, aceste scenarii de testare fiind rulate de multe ori, după orice modificări semnificative, fie de corectare, fie de îmbunătățire, în cadrul codului. [16]
Scopul testelor de regresie este de a verifica faptul că modificările efectuate nu au afectat nicio funcționalitate care anterior funcționa corect.
Testarea Equivalent Partitioning constă în partiționarea cazurilor de test cu scopul de a reduce numărul de scenarii de testare necesar pentru a testa în mod eficient datele de intrare, cele de ieșire, valorile interne și valorile legate de timp. Partiționarea este folosită pentru a crea clase de echivalență, iar prin selectarea unei valori reprezentante de la o partiție, se presupune o acoperire pentru toate elementele din aceeași partiție. [16]
Testarea Boundary Value Analysis este o tehnică de testare care implică determinarea limitelor pentru valorile de input și selectarea valorilor de la limită. [13]
Testarea Decision Table
În tabelul 1.2 sunt prezentate :
Condițiile – care reprezintă diverse condiții de intrare
Acțiunile – acestea se execută depinzând de diversele condiții de intrare
Fiecare regulă definește o combinație unică de condiții
Acțiunile nu depind de ordinea de evaluare a condițiilor ci doar de valorile lor
Acțiunile nu depind de condițiile anterioare de intrare sau de starea sistemului
Tabel 1.2 Tabel de decizii
1.4.3 Testarea White Box
Testarea de tip White Box, spre deosebire de Black Box necesită cunoașterea completă a structurii programului și accesul la codul sursă. Acest tip de testare este utilizat de programatorii care au scris codul.
Testarea White Box se clasifică astfel :
Testarea State Transition Testing utilizează o diagramă de stări și se dorește crearea unui număr de teste astfel încât să fie acoperite toate stările.
Testarea Branch Testing se bazează pe ideea de a crea un număr de teste astfel încât să se ia în considerare toate tranzițiile de la o stare la alta.
Testarea Path Testing are ca scop parcurgerea tuturor căilor posibile de la starea de început până la starea finală.
1.4.4 Testarea Gray Box
Testarea Gray Box este o combinație între cele două tehnici de testare descrise anterior, white box și black box.
Se construiesc test case-urile având acces la sursele programului, după care acestea sunt executate utilizând tehnica Black Box fără să ținem cont de structura internă a programului. Testarea Gray Box nu se folosește în domeniul automotive.
1.5 Testare manuală vs testare automată
Testarea unui produs poate fi efectuată utilizând ambele tehnici de testare: manuală și automată, dar în funcție de tipul de proiect se alege numărul de teste care se automatizează, respectiv care se vor executa manual. Această decizie este responsabilitatea test manager-ului care trebuie să ia în considerare costurile și beneficiile proiectului. Există totodată posibilitatea ca unele teste să fie executate atât manual cât și automat.
Chiar dacă se optează testarea automată pentru unele funcționalități, este recomandat ca scenariile de test să fie executate manual înainte, cu scopul de a înțelege mai bine scenariul de test. În continuare sunt prezentate câteva diferențe principale între testarea manuală și cea automată, conform :
Pentru testarea manuală, echipa de test este compusă din mai mulți testeri, comparativ cu numărul de testeri necesari din echipa de testare automată
Pentru testarea manuală nu sunt necesare cunoștințe de programare în schimb pentru testarea automată sunt o componentă vitală
Timpul de execuție al unui test este mai mare pentru testarea manuală
Pentru testarea manuală se poate aplica metoda Error Guessing care presupune găsirea erorilor pe baza experiențelor anterioare
1.5.1 Testare manuală
Testarea manuală presupune execuția manuală a testelor, conform cazurilor de test create în etapa de test design și compararea rezultatelor așteptate cu rezultatele obținute, cu scopul de a găsi erori în produsul software.
Avantajele testării manuale:
Costuri reduse
Flexibilitate – tester-ul are posibilitatea de a devia de la scenariul de test
Este mai interesantă găsirea erorilor prin execuție manual
Dezavantajele testării manuale:
Scenariile pot deveni repetitive
Unele teste sunt dificil de executat manual
Un test nu poate fi executat în mod repetat
Timpul necesar execuției manuale este mare
1.5.2 Testare automată
Testarea automată presupune crearea unor script-uri utilizând tool-uri speciale pentru testare automată și execuția acestora printr-o simplă rulare.
Avantajele testării automate:
Rularea testelor se face în mod rapid și eficient
Script-urile create pot fi rulate în mod repetat
Testarea automată presupune costuri ridicate pentru tool-urile de automatizare, însă de-a lungul timpului poate fi un cost eficient
Rezultatele obținute pot fi păstrare și analizate de mai multe personae
Dezavantajele testării automate:
Costuri ridicate
Crearea script-urilor necesită timp
Anumite tool-uri de automatizare pot avea limitări
1.5.3 Testare semiautomată
Testarea semiautomată este un tip de testare care implică atât testarea manuală cât și testarea automată. Există cazuri de test care nu pot fi automatizate în totalitate fiind necesară implicarea testării manuale.
1.6 Passive Start and Entry
Passive Start and Entry (PASE) este un concept nou în domeniul automotive și constă în utilizarea unor funcționalități ale mașinii fără a fi nevoie de folosirea unei chei mecanice clasice, fara chip criptat. Acest concept se bazează pe utilizarea antenelor LF (Low Frequency) în interiorul mașinii și a unui modul numit Hands Free Module.
În figura urmatoare sunt prezentate zonele de interior și de exterior acoperite de antene :
Numărul și poziționarea antenelor sunt diferite de la o marcă de automobil la alta.
În continuare vor fi prezentate 3 funcții care se bazează pe acest concept :
Easy PASE
Walk Away Locking
Approach Unlock
1.6.1 Easy PASE
Continental Automotive este unul dintre liderii de pe piață în sisteme de acces hands-free, sistem cunoscut sub numele de PASE. Fiind un sistem standardizat, scalabil și flexibil asigură costurile minime și o perioadă scurtă de dezvoltare.
În Figura 1.8 este prezentat modulul HFM (Hands Free Module), o cheie criptată și butonul de start engine. Utilizatorul mașinii care deține o cheie criptată corect poate porni mașina la o simplă acționare a butonului de start. Condiția pentru îndeplinirea acestei funcții este existența în interiorul mașinii a unei chei care să fie validă și criptată corect.
Avantaje și caracteristici :
Posibilitatea ca autovehiculul să fie închis/deschis automat
Posibilitatea pornirii motorului fără folosirea unei chei clasice
Utilizarea mai ușoară a mașinii
Folosirea conceptului de antene flexibile
Date tehnice :
PASE ECU
4-8 antene care sunt scalabile în conformitate cu OEM (Original Equipment Manufacturer)
1.6.2 Walk Away Locking
Funcția Walk Away Locking (WAL) sau Walk Away Closing (WAC) oferă utilizatorului posibilitatea ca mașina să se închidă automat în momentul în care utilizatorul părăsește mașina, închide ușa și se depărtează deținând o cheie validă. Mașina este închisă automat în momentul în care utilizatorul s-a îndepărtat la o distanță egală cu aproximativ 2 metri.
Două dintre beneficiile utilizării acestei funcții sunt confortul și securitatea.
În continuare este prezentat un scenariu prin care se arată utilizarea funcției WAC :
Motorul este oprit, șoferul și cheia sunt în interiorul mașinii :
2. Șoferul iese din mașină și închide ușa. În acest moment se fac două verificări :
nu există nicio cheie validă în interiorul mașinii
există cel puțin o cheie validă în zona WAC
3. Antenele de exterior continuă să verifice informațiile primite de la cheie.
4. În momentul în care dinstanța dintre șofer, care deține cheia, și mașina depașeste doi metri, mașina se va închide automat.
În Figura 1.12 sunt prezentate zonele funcției WAC :
1.6.3 Approach Unlock
Funcția Approach Unlock este opusă funcției Walk Away Locking. În momentul în care utilizatorul se apropie de mașină având asupra lui o cheie validă, cheia trimite o cerere de deschidere.
În timp ce mașina se află în standby mode, antenele emit frame-uri LF în zona approach unlock, căutând permanent o cheie validă. În momentul în care utilizatorul intră în zona approach unlock, mașina detectează cheia, autentifică cheia și în caz de succes trimite unlock request. [21]
2. IMPLEMENTAREA SOLUȚIEI ADOPTATE
2.1 Descrierea procesului de dezvoltare al unui proiect
Procesul de dezvoltare al unui proiect se realizează în patru pași :
Primul pas în dezvoltarea unui proiect îl reprezintă primirea specificațiilor sau a requirement-urilor de la client pe baza cărora se începe etapa de implementare. Această etapă se realizează de către departamentul de dezvoltare.
Pentru asigurarea calității produsului software este necesară etapa de testare, în urma căreia se validează produsul software și se verifică faptul că cerințele clientului au fost îndeplinite în totalitate. După ce produsul software a fost testat de către o echipă de testare și rezultatele sunt pozitive, acesta poate fi livrat clientului.
2.2 Descrierea aplicației
Scopul acestei lucrări este înțelegerea metodelor de testare și aplicarea acestora asupra unor cazuri de test realizate în urma analizării specificațiilor. Datorită faptului că specificațiile clientului sunt strict confidențiale pentru fiecare proiect, am decis crearea unor specificații fictive care să scoată în evidență 3 funcționalități importante : WAC, APU și ESCL.
În etapa de implementare echipa specializată crează o primă versiune de software. După ce versiunea inițiala de software a fost finalizată are loc încărcarea soft-ului pe modulul care trebuie testat, în cazul acesta modulul HFM.
Aplicația are ca obiectiv demonstrarea celor trei tipuri de testare : manuală, automată și semiautomată utilizând echipamente hardware și o simulare creată cu ajutorul unui tool, numit CANoe, descris la secțiunea 2.3. Scopul este testarea unor funcții din domeniul automotive.
În mod normal, testarea completă a unei funcționalități implică crearea mai multor scenarii pentru acoperirea tuturor specificațiilor, însă această lucrare are ca scop crearea câtorva scenarii pentru a arăta comportamentul de bază al funcționalităților alese.
Pentru testarea manuală s-a ales crearea și executarea de scenarii pentru funcțiile WAC și APU. Scenariile create se referă la o tehnică nouă de acces din domeniul automotive, bazată pe chei inteligente, care realizează închiderea automată în momentul îndepărtării de mașină la o anumită distanță, iar în momentul apropierii de mașină aceasta se va deschide automat.
Pentru testarea automată și semiautomată s-a utilizat tool-ului CANoe Testing Tool descris la secțiune 2.6, și s-a creat un panou cu ajutorul căruia se pot face diferite setări necesare funcționării corecte. Unul dintre scenariile create se referă la starea în care se află modulul HFM, iar un alt scenariu se referă la pornirea motorului și setarea vitezei la 30 km/h din panou. Execuția celui de-al doilea scenariu pune în evidență funcționarea modului de blocare a volanului, ESCL aplicând testarea semiautomată.
2.3 CANoe
Tool-urile CANalyzer și CANoe se bazează pe un limbaj exclusiv de programare numit CAPL (CAN Access Programming Language) asemănător cu limbajul C. Aceste tool-uri sunt dezvoltate de o companie renumita din domeniul de testare al ECU-urilor, VECTOR.
Cu ajutorul acestui tool avem posibilitatea de a simula anumite componente ale mașinii, pe care nu avem cum sa le folosim fizic. Pentru simularea anumitor componente este necesară crearea unei baze de date care conține noduri corespunzătoare fiecărui ECU simulat. Comunicarea între noduri se face prin intermediul protocoalelor CAN sau LIN cu ajutorul mesajelor, mesaje care conțin la rândul lor semnale.
CAPL poate fi utilizat în aplicații :
analiza mesajelor
analiza traficului datelor
crearea modulelor de testare
crearea filtrelor etc.
2.3.1 Crearea unui panou utilizând tool-ul CANoe
Panourile conțin elemente grafice care permit modificarea semnalelor atribuindu-le valorile dorite, astfel încât utilizatorului să ii fie mai ușor să le controleze. Exemple de elemente care pot fi adăugate într-un panou creat cu ajutorul Vector Panel Designer sunt : Button, Combo Box, Check Box, Switch/Indicator, Static Text, Radio Button, Picture Box etc., iar adăugarea elementelor grafice se face foarte ușor, cu drag and drop.
Rezultatele în urma setărilor efectuate pot fi observate în partea de Graphics.
CANoe permite integrarea panourilor create în limbajele de programare Visual Basic 6.0, Visual Basic .NET sau C#.
Panoul creat în cadrul aplicației conține 3 tab-uri :
General Settings
Walk Away Locking
Approach Unlock
Tab-ul General Settings conține setări generale pe care utilizatorul le poate face, cum ar fi setarea vitezei, deschiderea/închiderea ușilor, apăsarea pedalelor și setarea modului în care să se afle modulul HFM.
Tab-ul Walk Away Locking conține zonele funcției WAC :
Inside vehicle
Outside vehicle Z2
Outside vehicle Z3
Tab-ul Approach Unlock conține zonele funcției Approach Unlock :
Approach Unlock
Outsite vehicle
2.4 Diagnoză auto
Cu ajutorul diagnozei auto se pot citi sau se pot configura anumiți parametrii. Prin configurarea parametrilor se pot face setări pentru anumite funcții ale mașinii. Câteva exemple de setări care se pot face prin intermediul diagnozei sunt :
Dezactivarea aerului condiționat
Configurarea volanului pe partea dreaptă
Dezactivarea becului de ceață
Dezactivarea airbag-ului
Cu ajutorul diagnozei se pot citi toate problemele întâmpinate, indiferent dacă acestea sunt pobleme electrice, mecanice sau probleme de comunicare, pe CAN. Partea utilizată pentru găsirea erorilor prin diagnoză se numește DTC (Data Trouble Code).
2.5 Echipamente utilizate în procesul de testare manuală
În continuare sunt prezentate echipamentele necesare pentru testarea manuală.
În figura de mai jos este prezentat manual test bench-ul (MTB) și o sursă de tensiune.
MTB-ul este format din input-uri și output-uri.
Input-urile, notate cu I, pot fi setate prin activarea switch-urilor.
Output-urile, notate cu O, pot fi observate și interpretate prin intermediul led-urilor sau cu ajutorul osciloscopului.
Un exemplu prin care putem observa utilizarea input-urilor și a output-urilor este pornirea motorului. Pentru a porni motorul este necesară activarea unui input numit I START SW.
Dacă sunt îndeplinite condițiile necesare pornirii și anume :
cheia sa fie în interiorul mașinii
pedala de ambreiaj este apăsată
În acel moment se pot observa 3 output-uri ON : O IGN RL2, O PWR IGN și O PWR ACC.
În figura 2.7 este prezentat modulul HFM (Hands Free Module) :
În figura 2.8 sunt prezentate antenele LF utilizate pentru evidențierea funcțiilor de PASE:
2.5.1 Crearea cazurilor de test pentru testare manuală
Pentru testarea manuală au fost create două cazuri de test cu ajutorul cărora să fie evidențiate funcțiile WAC și APU.
În Figura 2.9 este descrisă funcția WAC cu ajutorul unei diagrame. În prima fază, condiția inițială, starea mașinii este : motorul pornit, ușile închise și deblocată. După oprirea motorului, utilizatorul părăsește autovehiculul, iese din mașină și închide ușa (toate ușile autovehiculului trebuie să fie închise pentru a permite blocarea totală a mașinii). După acest pas, începe căutarea cheii în exteriorul mașinii, în zona de siguranță, iar utilizatorul se îndepărtează cu cheia în buzunar. Căutarea continuă până în momentul în care utilizatorul s-a îndepărtat suficient de mașină (aproximativ 2m) și a ieșit din raza zonei de siguranță, moment în care cheia trimite un semnal de închidere.
Pentru activarea funcției Walk Away Locking este necesară setarea manuală a parametrilor de configurare din figura 2.10. Această setare a parametrilor se face cu ajutorul uni tool de diagnoză.
În continuare se va prezenta un scenariu prin care se poate observa comportamentul funcției WAC.
Starea inițială a mașinii este în modul deblocat, cheia se găsește în zona de interior a mașinii iar modulul HFM este în modul Wake Up.
În momentul în care șoferul deschide ușa se începe o verificare și o căutare a cheii atât în interior cât și în exterior, parametrul de diagnoză CURRENT_WAC_STATUS trecând din starea IDLE în starea de TRACKING. După poziționarea în zona Outside vehicle Z2 la pasul 3) din procedură și după închiderea ușii la pasul 4) cheia va trimite lock request automat în momentul în care cheia se află în zona Outside vehicle – Z3. Requirement-ul corespuzător acestui scenariu de test este REQ_01.
REQ_01 La trecerea din zona 2 în zona 3 cheia va trimite lock request.
Pentru a realiza scenariul de test este necesară realizarea a trei etape : precondiții, procedură și rezultate experimentale. În precodiții se specifică setările inițiale, adică starea în care se găsește mașina înainte de execuția pașilor din etapa de procedură.
Scenariul de test prin care se acoperă requirement-ul REQ_01 este TC_01 :
TC_01
Precondiții :
Vehicle State (Unlocked)
Set_PASE_Key_Position (Inside vehicle)
HFM mode (Wake Up)
Procedură și rezultate așteptate:
Pas 1) SET_CAN : DriverDoor (Open)
Pas 2) CHECK_DIAG : CURRENT_WAC_STATUS (TRACKING)
CHECK_DIAG : LOCK_BY_WAC_ALLOWED (FALSE)
CHECK_CAN : HFMRequest (No Request)
Pas 3) Set_PASE_Key_Position (Outside vehicle – Z2)
CHECK_DIAG : LOCK_BY_WAC_ALLOWED (TRUE)
CHECK_CAN : HFMRequest (No Request)
Pas 4) SET_CAN : DriverDoor (Close)
CHECK_DIAG : LOCK_BY_WAC_ALLOWED (TRUE)
Pas 5) Set_PASE_Key_Position (Outside vehicle – Z3)
CHECK_CAN : HFMRequest (Lock Request)
CHECK_DIAG : CURRENT_WAC_STATUS (WAC_ST_IDLE)
Rezultatele așteptate se vor compara cu rezultatele obținute după execuția manuală a testului TC_01, în capitolul „Rezultate Experimentale”.
APU – testare manuală :
În continuare se va prezenta un scenariu prin care se poate observa comportamentul funcției APU.
Pentru activarea funcției Approach Unlock este necesară setarea manuală a parametrilor din imaginea de mai jos. Setarea acestor parametrii se face utilizând un tool de diagnoză.
Inițial mașina este în starea unlocked, cheia se găsește în zona de exterior a mașinii și modulul HFM este în modul Wake Up. În momentul în care șoferul face lock de la cheie începe o căutare a cheii în exterior, parametrul de diagnoză CAD_APRUN_STATUS fiind APRUN_CAD_NC_WAIT_APRUN_OR_DEPARTURE. Requirement-ul corespuzător acestui scenariu de test este REQ_02.
REQ_02 La trecerea din zona 2 în zona 1 cheia va trimite unlock request.
Scenariul de test prin care se acoperă requirement-ul REQ_02 este TC_02 :
TC_02
Precondiții :
Vehicle State (Unlocked)
Set_PASE_Key_Position (Outside Vehicle)
HFM mode (Wake Up)
Procedură și rezultate așteptate :
Pas 1) SET_RKE_Request (Lock)
Pas 2) CHECK_CAN : HFMRequest (Lock Request)
CHECK_DIAG: CAD_APRUN_STATUS (APRUN_CAD_NC_WAIT_APRUN_OR_DEPARTURE)
Pas 3) Set_PASE_Key_Position (Approach Unlock)
Pas 4) CHECK_DIAG: CAD_APRUN_STATUS (APRUN_CAD_IDLE)
CHECK_CAN : HFMRequest (Unlock Request)
Rezultatele așteptate se vor compara cu rezultatele obținute după execuția manuală a testului TC_02, în capitolul „Rezultate Experimentale”.
2.6 CANoe Testing Tool
Pe lângă analiza și simularea diferitelor componente, CANoe este un tool utilizat și pentru testare automată. Modulele de test conțin secvențe de test care pot fi executate, iar în urma execuției se generează un raport care conține detalii referitoare la testul rulat. Rezultatul poate fi passed sau failed. [14]
Figura 2.13 conține setup-ul necesar execuției unui test utilizând tool-ul CANoe. Astfel după crearea unui modul de test și pornirea simulării de CANoe, în urma căreia are loc comunicarea pe CAN prin intermediul mesajelor, se poate executa testul și se pot analiza rezultatele salvate în raport.
În figura 2.14 este prezentat modului de test Test cases Group care conține 3 test cases : HFM Wake Up, Vehicle Speed și ESCL1.
2.6.1 Automatizarea testelor utilizând limbajul de programare CAPL
Automatizarea testelor utilizând limbajul de programare CAPL specific pentru CANoe presupune următorii pași :
inserarea unui modul de test
editarea unui modul de test
compilarea secvenței de test
salvarea testului pentru utilizare ulterioară
rularea testului
salvarea rezultatelor într-un raport
Rularea și rezultatele vor fi descrise în capitolul „Rezultate Experimentale”.
Inserarea unui modul de test se face în următorul mod :
View -> Simulation Setup -> Click dreapta pe bus-ul de comunicație -> Insert CAPL Test Module
Pentru editarea modulului de test, se vor respecta următorii pași :
File -> Test Setup -> Test Environment for Test Modules
Pentru realizarea unei secvențe de test se selectează butonul Edit Button din figura 2.16.
În mod normal, o secvență de test conține urmatoarele componente:
testFunction
testcase
MainTest()
În componenta testFunction se creează și implementează funcțiile care conțin setările corespunzătoare testelor.
Secțiunea testcase conține apelul funcțiilor în care s-au implementat setările și totodată se fac verificările necesare setării corecte.
Funcția MainTest() conține apelul test case-ului.
2.6.2 Crearea cazurilor de test pentru testare automată și semiautomată
HFM modes – testare automată :
Modulul de test TC_03 are ca scop verificarea modurilor în care poate să se găsească modulul HFM. Acest test propune evidențierea testării automate utilizând funcții specifice pentru testare cu ajutorul tool-ului CANoe Testing Tool.
REQ_03 : Verificarea celor 2 moduri ale modulului HFM.
TC_03
Descriere : Setarea modulului HFM în modul Sleep și Wake Up.
Modulul Hands free Module se poate afla în două stări :
Wake up – led-ul corespunzător din figura 2.18 este OFF
Sleep – led-ul corespunzător din figura 2.19 este ON
Pentru a testa cele două moduri este necesară setarea unui parametru de configurare pe valoarea true, setarea fiind făcută cu ajutorul unui tool de diagnoză.
Precondiții : CHECK_CAN : HFMRefuse_to_Sleep (Ready to Sleep)
Procedură și rezultate așteptate :
Pas 1) SET_CAN : HFMMode (OFF)
Pas 2) SET_CAN : HFMModeStatus (3)
Pas 3) Wait (2s)
Pas 4) CHECK_HW : O_SPARE_RL2 (OFF)
CHECK_CAN : HFM_Refuse_to_Sleep (Refuse To Sleep)
Pas 5) SET_CAN : HFMModeStatus (0)
Pas 6) Wait (10s)
Pas 7) CHECK_HW : O_SPARE_RL2 (ON)
CHECK_CAN : HFM_Refuse_to_Sleep (Ready To Sleep)
Automatizarea testului privind starea în care se află modulul HFM presupune setarea a două variabile de tip environment care se pot observa în panoul de mai jos :
În starea inițială se setează switch-ul din imagine pe modul OFF (manual) după care se setează HFM-ul în starea Wake Up State, adică pe valoarea 3. Ca urmare a setării acestei valori pe 3, modulul HFM se va trezi. Aceste rezultate se vor observa în capitolul “Rezultate Experimentale”.
Secvența de test corespunzătoare acestei verificări este urmatoarea:
Modul manual fiind setat prin punerea switch-ului pe OFF, se setează HFM-ul pe valoarea 3, adică Wake Up și se așteaptă 2 secunde. După aceste 2 secunde se face o verificare: recepția semnalului HFM_Refuse_to_Sleep din mesajul recepționat de HFM, al cărui id este 0x303. Această verificare are scopul de a controla daca semnalul s-a setat în mod corect. Dacă răspunsul este pozitiv testul este considerat „passed”, iar în caz contrar „failed”. La finalul testului HFM mode se setează pe valoarea inițială, 1. Această setare este necesară pentru a nu interfera cu următoarele teste ce urmează a fi realizate.
În continuare este descrisă secvența de test utilizată pentru automatizarea testului TC_03 :
TS_03 :
testcase HFMState()
{
Pentru o înțelegere cat mai bună și o exemplificare cât mai clară a descrierii testului și numelui acestuia folosim următoarele două funcții: testCaseDescription() și testCaseTitle().
testCaseDescription("HFM Modes – Wake up and Sleep");
testCaseTitle ("","HFM Modes");
Setarea switch-ului pe poziția OFF se realizează cu funcția HFMMode() :
HFMMode(0);
Setarea valorii 3 pentru modul Wake Up se face apelând funcția HFMModeStatus() :
HFMModeStatus(3);
Se așteaptă 2000 milisecunde (2s) înainte de a se face verificarea recepționării corecte a mesajului utilizând funcția testWaitForTimeout() :
testWaitForTimeout(2000);
Cu ajutorul funcției TestWaitForTextEvent() se verifică recepționarea mesajului 0x303. Dacă mesajul a fost recepționat corect și semnalul HFM_Refuse_to_Sleep are valoarea 1 testul este passed și se apelează funcția testStepPass(). În caz contrar se va apela funcția testStepFail().
if(TestWaitForTextEvent ("HFMWakeUpMode", 2000)>0)
{
testStepPass("","Passed");
}
else
{
testStepFail("","Check FAIL");
}
Pentru setarea valorii 0 pentru modul Sleep apelăm funcția HFMModeStatus() :
HFMModeStatus(0);
Se așteaptă 10000 milisecunde :
testWaitForTimeout(10000);
Se setează switch-ul pe ON apelând funcția HFMMode() :
HFMMode(1);
}
Funcțiile create prin care se setează variabilele de tip environment EnvBCM_WakeUpSleepCommand_MODE_ și EnvBCM_WakeUpSleepCommand_ sunt create în secțiunea testfunction cu ajutorul funcției putValue() :
testfunction HFMMode (int mode)
{
putValue(EnvBCM_WakeUpSleepCommand_MODE_,mode);
}
testfunction HFMModeStatus (int status)
{
putValue(EnvBCM_WakeUpSleepCommand_,status);
}
În secțiunea on message se verifică dacă semnalul HFM_Refuse_to_Sleep din mesajul cu id-ul 0x303 are valoarea 1. Dacă da, se creează un event de tip text prin intermediul căruia se verifică valoarea semnalului în partea de testcase.
onmessage 0x303
{
if(this.HFM_Refuse_to_Sleep==1)
TestSupplyTextEvent ("HFMWakeUpMode");
}
Funcția MainTest() conține apelul testcase-ului HFMState(). Funcțiile testGroupBegin() și testGroupEnd() specifică începutul și sfârșitul execuției testului HFMState(). În acest caz se apelează un singur test, însă există posibilitatea execuției mai multor teste în cadrul unui grup din funcția MainTest().
void MainTest()
{
testGroupBegin("","Testare HFM Mode");
HFMState();
testGroupEnd();
}
Pentru a putea seta EnvBCM_WakeUpSleepCommand_ pe o valoare este necesară setarea variabilei EnvBCM_WakeUpSleepCommand_MODE_ pe valoarea 0, adică trecerea în modul manual.
Compilarea codului se realizează apăsând tasta F9 sau selectând icoana de compilare. Dacă compilarea s-a realizat cu succes se poate trece la următorul pas, rularea testului, care va fi prezentată în capitolul „Rezultate Experimentale”.
Setare Vehicle Speed – testare semiautomată :
Testul TC_04 are ca scop verificarea pornirii motorului de la o simplă apăsare a butonului de start în mod manual și setarea vitezei la 30 km/h în mod automat. Pentru acest test se propune evidențierea testării manuale pentru funcția Easy PASE și totodată a testării automate utilizând funcții specifice pentru testare cu ajutorul tool-ului CANoe Testing Tool.
REQ_03 : Start and stop by PASE
TC_04
Descriere : Start by PASE și setarea vitezei la 30 km/h, apoi setarea vitezei la 0 km/h după un timp de așteptare egal cu 10 secunde.
Precondiții : Vehicle unlocked
Key inside
Clutch pedal pressed at maximum
Press start switch (vezi figura 2.22)
IgnitionRequest = Ignition Requested
Procedură și rezultate așteptate :
Pas 1) SET_CAN : ClutchSwitchPedal (Press at maximum)
SET_HW : START_SW (ON)
WAIT (2s)
Pas 2) CHECK_HW : O_IGN_RL2 (ON)
CHECK_HW : O_PWR_IGN (ON)
CHECK_HW : O_PWR_ACC (ON)
CHECK_CAN : IgnitionRequest (Ignition Requested)
Pas 3) SET_CAN : Vehicle_Speed (30)
Pas 4) CHECK_DIAG : VEHICLE_SPEED (30)
Pas 5) WAIT (10 s)
Pas 6) SET_CAN : Vehicle_Speed (0)
Pas 7) CHECK_DIAG : VEHICLE_SPEED (0)
Pas 8) SET_HW : START_SW (OFF)
Pas 9) CHECK_HW : O_IGN_RL2 (OFF)
CHECK_HW : O_PWR_IGN (OFF)
CHECK_HW : O_PWR_ACC (OFF)
CHECK_CAN : IgnitionRequest (No Ignition Requested)
Secvența de testcase presupune apelarea funcției SetSpeed() și verificarea semnalului Ignition Requested din mesajul cu id-ul 0x303.
Secvența testfunction presupune crearea și implementarea unei funcții SetSpeed() utilizând funcția putValue() care va fi apelată în secvența de testcase.
On message conține mesajul al cărui id este 0x303 și verifică dacă semnalul IgnitionRequest are valoarea egală cu 2 sau egală cu 1. Dacă a fost recepționat mesajul al cărui semnal IgnitionRequest este egal cu 2, se setează un eveniment denumit “IGR” care este verificat în secvența de testcase. Dacă semnalul IgnitionRequest este egal cu 1 se setează un event „IGNR”.
Funcția main conține apelul testcase-ului SetVehicleSpeed().
Compilarea codului se realizează apăsând tasta F9 sau icoana de compilare. Dacă compilarea s-a realizat cu succes se poate trece la următorul pas, rularea testului, care va fi prezentată în capitolul „Rezultate Experimentale”.
Codul corespunzător secvenței de test case TS_04, funcțiilor de test și totodată funcția mainTest() se poate vizualiza în anexă.
ESCL locked/unlocked – testare semiautomată :
Scenariul de test TC_05 are ca scop punerea în evidență a funcționării modulului ESCL prin setarea în mod automat a deschiderii ușii șoferului și pornirea manuală a motorului după închiderea ușii. Pentru acest test se urmarește evidențierea testării manuale pentru funcția Easy PASE și totodată a testării automate utilizând funcții specifice pentru testare cu ajutorul tool-ului CANoe Testing Tool.
REQ_05 : Verificarea stărilor modulului ESCL locked respectiv unlocked.
TC_05
Descriere : ESCL module – locked și unlocked
Acest modul blochează volanul în momentul în care motorul este oprit și șoferul deschide ușa. Blocarea volanului este o metodă antifurt. ESCL este unul dintre cele mai importante module din punct de vedere al securității deoarece trebuie să ne asigurăm că nu se blochează în timpul mersului.
Închiderea, deschiderea ușii șoferului și apăsarea pedalei de ambreiaj la maxim se face în mod automat iar la finalul testului se așteaptă recepționarea mesajului al cărui id este 0x1F6. Acest mesaj se recepționează în momentul în care mașina este în starea “engine running”. În cazul în care mesajul nu se recepționează într-o perioadă de maxim 10 secunde testul va fi failed.
Pentru a fi în starea “engine running” trebuie îndeplinite următoarele condiții :
Poziționarea cheii – inside vehicle
Pedala de ambreiaj – apăsată la maximum
Pornirea mașinii se va face utilizând funcția Easy PASE descrisă în capitolul 2.3.1
Figura 2.23 reprezintă testul ESCL1 din CANoe Testing Tool :
Precondiții : CHECK_HW : ESCL = Unlocked
Procedură și rezultate așteptate :
Pas 1) SET_CAN : DriverDoor (Open)
Pas 2) CHECK_CAN : DriverDoorState (2)
Pas 3) Wait (10s)
Pas 4) CHECK_HW : ESCL (Locked)
Pas 5) SET_CAN : DriverDoor (Close)
Pas 6) CHECK_CAN : DriverDoorState (1)
Pas 7) SET_CAN : ClutchSwitchPedal (Pressed at maximum)
Pas 8) SET_HW : START_SW (ON)
Pas 9) CHECK_HW : ESCL (Unlocked)
Secvența testcase ESCLState() cuprinde setări automate pentru deschiderea ușii șoferului și apăsarea pedalei de ambreiaj la maxim.
Funcțiile create pentru acest caz de test sunt PressClutchPedal() și SetDriverDoor().
Mesajul, al cărui id este 0x350, conține semnalul DriverDoorState. În cazul în care acest semnal s-a recepționat cu succes, în funcție de valoare, 2 sau 1, se va seta un text event care se va verifica în secțiunea testcase.
Mesajul, al cărui id este 0x1F6, conține semnalul EngineStatus_R. Mesajul este recepționat în momentul în care pornim mașina în mod manual. Scopul este ca în momentul pornirii să testăm faptul că modulul ESCL este unlocked.
Funcția MainTest() conține apelarea testcase-ului ESCLState() și timp de 10 secunde trebuie să se recepționeze mesajul cu id-ul 0x1F6, în caz contrar testul este failed. Pentru recepționarea mesajului este necesară acționarea switch-ului din figura 2.22.
Codul corespunzător secvenței de test case TS_05, funcțiilor de test și totodată funcția mainTest() se pot vizualiza în anexă.
3 REZULTATE EXPERIMENTALE
3.1 Rezultate experimentale pentru testarea manuală
WAC – rezultate obținute :
În urma execuției în mod manual a testului TC_01, ce urmărește funcția WAC, se observă transmiterea de către cheie a unui request de lock în momentul în care șoferul închide ușa și se îndepărtează de mașină aproximativ 2 metri.
În momentul în care se deschide ușa șoferului la pasul 1) și cheia este detectată în interiorul mașinii pe diagnoză se verifică parametrul CURRENT_WAC_STATUS care trece din starea IDLE în starea de TRACKING.
Cu ajutorul osciloscopului se observă polling-ul care este atât în interior cât și în exterior. În figura 3.2 și 3.3 se observă că pe canalul 1 s-a efectuat măsurarea perioadei pentru antena de immo iar pe canalul 2 pentru antena de rear.
După o anumită durată de căutare a cheii perioada polling-ului crește de la 300 ms la 500 ms.
Statusul în starea de tracking înseamnă că are loc o căutare a cheii, însă fără a se transmite lock request.
După execuția pasului 3), și anume poziționarea cheii în afara mașinii, dar în zona LF, se observă setarea zonei în panel-ul corespunzător zonei WAC :
După închiderea ușii, la trecerea din zona 2 în 3, se va trimite lock request.
În figura 3.7 este reprezentat cu verde semnalul HFMRequest cu valoare Lock by Walk request, iar cu mov este reprezentat semnalul VechicleState cu valoarea Vehicle Locked. Vizualizarea semnalelor se face în secțiunea de Graphics din CANoe.
După Lock by WAC request polling-ul continuă în exterior :
Verificarea faptului că s-a trimis Lock by Wac request se face și cu ajutorul diagnozei. Astfel parametrul CURRENT_WAC_STATUS va trece din starea de TRACKING în IDLE, iar parametrul LAST_WAC_EXIT_TRIG_S_0 va lua valoarea WAC_EXIT_LOCK_BY_WAC_RF.
APU – rezultate obținute :
În urma execuției în mod manual a testului TC_02 cu privire la corectitudinea funcționării funcției APU, se observă transmiterea de către cheie a unui request de unlock în momentul în care șoferul se apropie de mașină.
În panou, la secțiunea Approach Unlock se observă detectarea cheii în zona 2.
Cu ajutorul diagnozei, în momentul în care se trimite lock request prin apăsarea butonului de la cheie parametrul CAD_APRUN_STATUS va lua valoarea APRUN_CAD_NC_WAIT_APRUN_OR_DEPARTURE.
În momentul în care se trimite lock request de la cheie începe o căutare a cheii în exterior, dar se face o singură căutare și în interior :
La trecerea din zona 2 în zona 1 se va trimit unlock request :
În secțiunea de graphics se pot urmări 3 semnale :
Semnalul verde indică mai întâi request-ul de lock de la butonul de la cheie, iar apoi unlock request-ul trimis în momentul trecerii în zona Approach Unlock
Semnalul alb indică utilizarea cheii, respectiv utilizarea funcției PASE
Semnalul mov indică mai întâi faptul că mașina e locked, iar apoi unlocked
3.2 Rezultate experimentale pentru testarea automată
HFM modes – rezultate obținute :
În urma rulării testcase-ului TC_03 se poate observa, în figura 3.17, la secțiunea Test Cases, rezultatul obținut, iar în figura 3.18 , la secțiunea Test Overview se pot observa detalii din timpul rulării testului. Execuția testului referitor la modurile Wake Up și Sleep în care se poate afla modulul HFM a durat 12.091s, a fost executat o singură dată iar rezultatul este passed.
În secțiunea Graphics se poate observa trecerea semnalului HFM_Refuse_to_Sleep din modul Sleep în modul Wake Up.
În urma rulării testului se generează un raport în care se găsesc informațiile relevante legate de Test Setup, dar și informații legate de execuție. În figura de mai jos se poate observa raportul generat în urma rulării testului TS_03 :
3.3 Rezultate experimentale pentru testarea semiautomată
Setare Vehicle Speed – rezultate obținute :
Rezultatul în urma rulării celui de-al doilea testcase TS_04 se poate observa în figura 3.21 la secțiunea Test Cases, iar în figura 3.22 , la secțiunea Test Overview se pot observa detalii din timpul rulării testului. Execuția testului referitor la pornirea mașinii și setarea vitezei la 30 km/h a durat 11.135s, a fost executat o singură dată și rezultatul este passed.
În momentul în care apăsăm butonul de start pe Manual Test Bench se vor observa 3 output-uri ON iar semnalul IgnitionRequest se setează pe valoarea IgnitionRequested.
În figura 3.24 este reprezentat semnalul Ignition Request :
Setarea vitezei se poate observa în panel, în timpul execuției testului. În figura 3.25 a) viteza a fost setată 30 km/h iar în figura 3.25 b) 0 km/h. În momentul în care setăm viteza egală cu 0 km/h și apăsăm butonul de Start, cele 3 output-uri vor fi OFF.
O altă verificare se poate face utilizând un tool de diagnoză :
În figura de mai jos se pot observa rapoartele generate în urma rulării testului TS_04 :
Rezultatul în urma rulării celui de-al treilea testcase TC_05 se poate observa în figura 3.30 la secțiunea Test Cases, iar în figura 3.31, la secțiunea Test Overview se pot observa detalii din timpul rulării testului. Execuția testului referitor la blocarea și deblocarea volanului a durat 14.298 s, a fost executat o singură dată și rezultatul este passedîn figura 3.30 respectiv failed în figura 3.32.
În momentul în care șoferul deschide ușa are loc blocarea volanului iar modului ESCL – locked este reprezentat în figura 3.29 a). În momentul în care șoferul intră în mașină, închide ușa și pornește motorul se va debloca volanul, iar modulul ESCL – unlocked este reprezentat în figura 3.29 b).
Dacă în mai puțin de 10 secunde are loc pornirea motorului rezultatul testului este passed :
Dacă timp de 10 s nu are loc pornirea motorului rezultatul testului este failed :
Testarea utilizând CANoe permite executarea testului cu ajutorul breakpoint-urilor, proces denumit debugging. În cazul în care un test a picat și dorim să facem debugging trebuie să selectăm modul debugging și să poziționăm breakpoint-uri în test. Pentru a rula pas cu pas se utilizează butonul Step Into.
4. CONCLUZII
Procesul de testare este important pentru asigurarea calității produsul software și trebuie să fie realizat încă din stadiul incipient ale proiectului.
Lucrarea are ca scop documentarea teoretică cu privire la tehnicile și metodele de testare dar totodată aprofundarea cunoștințelor cu privire la câteva funcționalități importante din domeniul automotive. S-a pus accent pe o tehnologie nouă numită Passive Start and Entry, care permite accesul și pornirea motorului în mod pasiv de către utilizatorul autovehicului. Acest mod presupune o singură condiție și anume deținerea unei chei valide de către utilizatorul autovehiculului, fără a fi necesară o acțiune din partea acestuia. Deblocarea mașinii se face automat în momentul în care cheia validă este detectată în apropierea mașinii iar blocarea constituie acțiunea inversă, când utilizatorul se îndepărtează de mașină. Pentru a fi permis modul remote pasiv se utilizează tehnologia LF prin care se identifică poziția cheii valide, adică dacă cheia se află în interiorul sau în exteriorul mașinii.
Partea de implementare practică presupune descrierea procesului de dezvoltare al unui produs software și crearea unor cazuri de test prin care să se pună în evidență comportamentul de bază al funcționalităților alese utilizând diferite metode de testare : manuală, automată și semiautomată. Funcționalitățile alese sunt Lock by Walk, Approach Unlock și Electric Steering Column Lock.
Partea de rezultate experimentale conține rezultatele obținute în urma aplicării metodelor de testare pentru funcționalitățile amintite mai sus. S-a pus accent pe utilizarea testării manuale pentru sistemul de acces dar s-a arătat eficiența testării automate utilizând CANoe Testing Tool. Totodată s-a dorit îmbinarea acestor două tipuri de testare realizându-se astfel testarea semiautomată.
În concluzie lucrarea prezintă concepte utilizate practic în viața de zi cu zi privind domeniul automotive care este în continuă dezvoltare și toți utilizatorii de automobile doresc un confort și o siguranța cât mai ridicată pe parcursul condusului. Pentru a asigura o siguranță cât mai mare este necesar un proces riguros de testare.
5. BIBLIOGRAFIE
[1] Certified Tester, “Foundation Level Syllabus”, 2011
[2] Byte Craft Limited, “First Steps with Embedded Systems”, 2002
[3] Protocoale de comunicație : http://www.e-automobile.ro/categorie-electronica/11-protocoale-comunicatie-automobile.html [05.05.2016]
[4] CANoe Vector, „Programming with CAPL”, 2004
[5] Mircea Vaida, „Software Testing Methodologies”, 2014
[6] Christian Bucanac, “The V-Model”, 1999, University of Karlskrona/Ronneby
[7] Vector Company, “Hardware for ECU Testing”, 2008
[8] Aur´elien Francillon, Boris Danev, Srdjan Capkun, „Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars”, Department of Computer ScienceETH Zurich,
[9] Continental Automotive, „Product Guide”, 2014
[10] Asist. Paul POCATILU, „Costurile testării software”, Catedra de Informatică Economică, A.S.E. București, Revista Informatică Economică, nr. 1 (21)/2002
[11]Walk Away Locking, “Convenience Versus Security”, 2011
[12] Renault Captur , “Driver`s Handbook”
[13] Shivani Acharya, Vidhi Pandya, „Bridge between Black Box and White Box – Gray Box Testing Technique”, International Journal of Electronics and Computer Science Engineering
[14] Stefan Krauss, “Testing with CANoe”, Version 1.1, 2009
[15] Black Box și White Box : http://www.softwaretestingclass.com/functional-testing-vs-non-functional-testing/
[16] Dorothy Graham, Erik van Veenendaal,Isabel Evans, Rex Black, „Foundations Of Software Testing ISTQB Certification”
[17] Tania Martinez, “Body Control Module (BCM)”, 2009
[18] Testare manuală și automată 1 : http://www.base36.com/2013/03/automated-vs-manual-testing-the-pros-and-cons-of-each/ [01.06.2016]
[19] Testare manuală și automată 2 : http://testingbasicinterviewquestions.blogspot.ro/2014/09/manual-testing-vs-automation-testing.html [03.07.2016]
[20] Continental Automotive, „Training Introduction to I & BS Product Software / System Testing”
[21] Continental Automotive, „Body and Security – 4th Generation PASE”
[22] Entry and Exit Criteria in Software Testing : http://www.rishabhsoft.com/blog/entry-and-exit-criteria-in-software-testing
6. ANEXE
/*Test case TC_03:
Descriere : Setarea modurilor Sleep HFM si Wake up HFM.
Conditii initiale : IgnitionRequest = No Ignition Requested
Procedura si rezultate asteptate :
Pas 1) Set : HFMMode = Manual
Pas 2) Set : HFM Value = 3
Pas 3) Check : HFMRefuseToSleep = Refuse to sleep
Pas 4) Wait 3 s
Pas 5) Set : HFM Value = 0
Pas 6) Check : HFMRefuseToSleep = Ready to sleep
*/
testcase HFMState()
{
HFMMode(0);
HFMModeStatus(3);
testWaitForTimeout(2000);
testStep("","Check Event");
if(TestWaitForTextEvent ("HFMWakeUpMode", 2000)>0)
{
testStep("","Check OK");
testStepPass("","A trecut");
}
else
{
testStepFail("","Check FAIL");
}
HFMModeStatus(0);
testWaitForTimeout(10000);
}
testfunction HFMMode (int mode){
putValue(EnvBCM_WakeUpSleepCommand_MODE_,mode);
}
testfunction HFMModeStatus (int status){
putValue(EnvBCM_WakeUpSleepCommand_,status);
}
onmessage 0x303
{
if(this.HFM_Refuse_to_Sleep==1)
TestSupplyTextEvent ("HFMWakeUpMode");
}
void MainTest()
{
testGroupBegin("","Testare HFM Mode");
HFMState();
testGroupEnd();
}
/*Test case TC_04 :
Descriere : Setarea vitezei la 30 km/h si setarea vitezei la 0 km/h dupa 10 secunde.
Conditii initiale : IgnitionRequest = No Ignition Requested
Vehicle unlocked
Procedura si rezultate asteptate :
Pas 1) Set : VehicleSpeed = 30 (km/h)
Pas 2) Wait : 10 s
Pas 3) Check : IgnitionRequest = Ignition Requested
Pas 4) Set : VehicleSpeed = 0 (km/h) and press start switch
Pas 5) Wait : 1 s
Pas 6) Check : IgnitionRequest = No Ignition Requested
*/
testcase SetVehicleSpeed()
{
testCaseDescription("Set Vehicle Speed");
testCaseTitle ("","Vehicle Speed");
SetSpeed(30);
testWaitForTimeout(10000);
testStep("","Check Event");
if(TestWaitForTextEvent ("IGR", 2000)>0)
{
testStep("","Check OK");
testStepPass("","Passed");
}
else
{
testStepFail("","Check FAIL");
}
SetSpeed(0);
if(TestWaitForTextEvent ("IGNR", 2000)>0)
{
testStep("","Check OK");
testStepPass("","Passed");
}
else
{
testStepFail("","Check FAIL");
}
}
onmessage 0x350
{
if(this.DriverDoorState==2)
TestSupplyTextEvent ("DriverDoorOpen");
else
if(this.DriverDoorState==1)
TestSupplyTextEvent ("DriverDoorClose");
}
onmessage 0x1F6
{
if(this.EngineStatus_R==2)
TestSupplyTextEvent ("Engine is running");
}
void MainTest()
{
testGroupBegin("","Testare ESCL");
ESCLState();
if(TestWaitForTextEvent ("Engine is running", 10000)>0)
{
testStep("","Check OK");
testStepPass("","A trecut");
}
else
{
testStepFail("","Check FAIL");
}
testGroupEnd();
}
testfunction SetSpeed (int speed){
putValue(EnvVehicleSpeed_,speed);
}
onmessage 0x303
{
write("IG:%d",this.IgnitionRequest);
if(this.IgnitionRequest==2)
TestSupplyTextEvent ("IGR");
else
if(this.IgnitionRequest==1)
TestSupplyTextEvent ("IGNR");
}
void MainTest()
{
testGroupBegin("","Testare Vehicle Speed");
SetVehicleSpeed();
testGroupEnd();
}
/*Test case TS_05 :
Descriere : Modulul ESCL de ESCL se blocheaza in momentul in care soferul deschide usa
Conditii initiale : IgnitionRequest = No Ignition Requested
Vehicle unlocked
Procedura si rezultate asteptate :
Pas 1) Set : DriverDoor = opened
Pas 2) Wait : 2 s
Pas 3) Check (manual): ESCL = Unlocked
Pas 4) Set : DriverDoor = closed
*/
testcase ESCLState()
{
SetDriverDoor(2);
testWaitForTimeout(10000);
testStep("","Check Event");
if(TestWaitForTextEvent ("DriverDoorOpen", 2000)>0)
{
testStep("","Check OK");
testStepPass("","A trecut");
}
else
{
testStepFail("","Check FAIL");
}
SetDriverDoor(1);
if(TestWaitForTextEvent ("DriverDoorClose", 2000)>0)
{
testStep("","Check OK");
testStepPass("","A trecut");
}
else
{
testStepFail("","Check FAIL");
}
PressClutchPedal(2);
}
testfunction PressClutchPedal (int max){
putValue(EnvClutchSwitchMaximumTravel_,max);
}
testfunction SetDriverDoor (int state){
putValue(EnvDriverDoorState_,state);
}
on message 0x350
{
if(this.DriverDoorState==2)
TestSupplyTextEvent ("DriverDoorOpen");
else
if(this.DriverDoorState==1)
TestSupplyTextEvent ("DriverDoorClose");
}
on message 0x1F6
{
if(this.EngineStatus_R==2)
TestSupplyTextEvent ("Engine is running");
}
void MainTest()
{
testGroupBegin("","Testare ESCL");
ESCLState();
if(TestWaitForTextEvent ("Engine is running", 10000)>0)
{
testStep("","Check OK");
testStepPass("","A trecut");
}
else
{
testStepFail("","Check FAIL");
}
testGroupEnd();
}
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: TEHNICI DE TESTARE APLICATE IN DOMENIUL AUTOMOTIVE [303901] (ID: 303901)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.