Protocolul de Comunicatie Can

Capitolul 1

1.1 Scopul lucrării

Datorită avansării tehnologiei, și mai ales în folosirea electronicii avansate în domeniul automotive, instrumentele folosite în acest domeniu au evoluat și sunt de o complexitate tot mai mare, având funcționalități din ce în ce mai multe. Aceste funcționalități trebuie testate fiecare în parte. Datorită complexității instrumentelor și a funcționalităților lor, acestea necesită instrumente pe măsură, dedicate testării lor.

Lucrarea de față prezintă un modul de testare dedicat informațiilor din meniul intern afișate pe display-ul instrumentelor de bord din autovehicul.

Scopul lucrării constă în realizarea unui modul software prin care să poată fi controlat meniul din interiorul unui cluster (instrument de bord) având utilizare în testarea funcționalității corecte a instrumentului și poate ajuta în realizarea diferitelor teste ce implică funcționalitățile asistenților, fincționalități ce țin de multimedia, de navigație și ale altor diferite funcționalități cu care este echipată mașina, afișabile pe display-ul instrumentului de bord.

Funcționalitatea modulului constă, pe de-o parte, în transmiterea de semnale directe pe CAN către instrumentul de bord, semnale care controlează meniul și de cealaltă parte, în controlul remote a unei simulări CANoe care activează, la rândul ei, semnalele prin care se face lucrul cu meniul instrumentului de bord.

Prin modulul realizat, folosind partea de transmitere de semnale directe pe CAN și neavând la dispoziție o simulare, se pot activa anumite funcționalități ale instrumentului de bord care s-ar putea accesa și activa doar cu ajutorul unei simulări specializate.

Prin urmare, modulul realizat este un instrument binevenit în procesul de testare a instrumentului de bord dedicat funcționalităților ce țin de meniu.

În continuare va fi prezentat tot ce ține de modulul realizat și modalitățile hardware și software prin care se face controlul și comunicația cu instrumentul de bord.

Capitolul 2

Descrierea instrumentelor și echipamentelor utilizate

2.1 Protocolul de comunicație CAN

CAN (Controller Area Network) reprezintă un protocol de comunicație serială de tip magistrală (bus) utilizat pentru sisteme distribuite. Protocolul CAN realizează comunicația în timp real și este folosit pe scară largă, în special în industria automobilelor, dar și în alte industrii precum industria aerospațială, maritimă, echipamente medicale, etc. [24]

Dezvoltarea protocolului CAN a fost inițiată de către compania Bosch GmbH în 1983 iar primul cip controller CAN a fost produs de către Intel și Philips și lansat pe piață in 1987. [19]

CAN este o magistrală de tip multi-master care controlează Unități Electronice de Control, cunoscute sub denumirea de noduri. Protocolul CAN poate fi de două tipuri:

CAN de mare viteză (CAN High), în care toate nodurile sunt interconectate printr-o magistrală liniară din două fire cu rezistența de 120Ω la fiecare din cele două capete. Viteza este între 25kBit/s și 125 kBit/s;

CAN de viteză mică (CAN Low), în care nodurile sunt conectate tip stea printr-o magistrală lineară. Viteza este între 500kBit/s și 1 Mbit/s;[19]

2.1.1 Structura Hardware

Conexiunea magistralei se realizează prin conectoare de tip DB9cu următoarea configurație:

Pin 2: CAN-Low (CAN-);

Pin 3: GND (Ground);

Pin 7: CAN-High (CAN+);

Pin 9: CAN V+ (Power);

Dispozitivele ce comunică prin CAN sunt conectate la rețea prin intermediul unui controller de CAN și un procesor gazdă. Fiecare nod necesită:

Unitate centrală de procesare, care transmite mesaje și descifrează mesajele primite;

Controller de CAN, care la recepționare primește biții și construiește mesajul pe care îl transmite unității centrale de procesare iar la transmisie stochează mesajele pentru a trimite serial pe CAN biții din care sunt compuse;

Transmițător, care la recepționare aduce semnalele de pe magistrală la nivelul la care lucrează controller-ul de CAN și are rol în protecția controller-ului, iar la transmisie convertește mesajul transmis de către controller și-l transmite pe magistrală;[24]

Fig. 2.1 Magistrala CAN

Prin protocolul CAN fiecare nod poate fi emițător sau receptor de mesaje însă nu pot fi două noduri care să transmită sau să recepționeze semnale simultan. Fiecare mesaj este alcătuit în principal dintr-un câmp de arbitrare, unul de control, unul de verificare a ciclicității și unul de final de mesaj. Fiecare mesaj are un identificator (ID) unic înscris în câmpul de arbitrare iar arbitrarea se face în funcție de prioritatea identificatorului, astfel că, atunci când se transmite simultan un mesaj, mesajul cu ID mai mic este prioritar și se va transmite prin magistrală. Nodurile pot să transmită atunci când magistrala este inactivă, starea logică a magistralei este “1”, adică la nivel recesiv. Atunci când un nod transmite “1”, dar observă “0” pe magistrală, acesta pierde arbitrarea. Nodul care a pierdut arbitrarea se retrage și reîncearcă mai târziu. [24]

Magistrala poate fi în două stări distincte:

Stare dominantă (valoare logică “1"), impedanță mică și nivel de tensiune scăzut;

Stare recesivă (valoare logică “0”), impedanță mare și nivel mare de tensiune; [5]

2.1.2Tipuri deCAN

După structura mesajului, protocolul CAN poate fi de două tipuri:

CAN Standard (Versiunea 2.0A), în care identificatorul este pe 11 biți;

CAN Extended (Versiunea 2.0B), în care identificatorul este pe 29 biți.

2.1.2.1Formatul Standard

Formatul mesajului incepe întotdeauna cu SOF (Start Of Frame)- bitul de start.

În formatul standard:

Câmpul de Arbitrare este format din 12 biți: 11 biți ID-ul, care reflectă conținutul și prioritatea mesajului și un bit ce reprezintă RTR (Remote Transmission Request) care este dominant (“0”);

Următorul câmp este Câmpul de Control, format din 6 biți dintre care primul (IDE) specifică formatul mesajului (“0”-Standard , “1”-Extended), al doilea este rezervat (rămâne dominant -“0”) iar restul de 4 biți reprezintă Data Length Code (DLC) care indică numărul de Bytes de date transmise în mesaj;

Urmează Câmpul de Date de lungime definită de DLC (între 0 și 8 Bytes) în care sunt efectiv datele transmise;

Câmpul CRC (Cyclic Redundancy Field) pe 16 biți, care este folosit pentru a detecta posibile erori de transmisie;

Câmpul ACK (Acknowledge) pe 2 biți, prin care nodul care primește mesajul semnalează nodul transmițător printr-un bit dominant dacă a primit mesajul fară eroare și poate să-l accepte sau nu. Al doilea bit este folosit în delimitarea câmpurilor și este întotdeauna recesiv;

Câmpul EOF (End of Frame) este alcătuit din 7 biți recesivi (”1”) care semnalează sfârșitul mesajului; [24]

După terminarea mesajului, magistrala ramâne în stare recesivă pe durata a 3 biți (Intermision);

Fig. 2.2 CAN Standard

2.1.2.2Formatul Extended

Mesajul în formatul Extended are aceeași structură, singura deosebire de cel Standard fiind lungimea Câmpului de Arbitrare, de 32 de biți: 11 biți ID (prima parte a identificatorului), urmat de 2 biți recesivi (SRR- Substitute Remote Request și IDE-Identifier Extension bit), după care vine a doua parte a ID-ului de 18 biți și la final RTR dominant.

Fig. 2.3 CAN Extended

2.2 Structura Hardware a standului de testare

Partea Hardware a standului de testare este formată din mai multe componente, fiecare avand un rol bine stabilit în transmiterea de date pentru realizarea procesului de testare. În figura 2.4 este o reprezentare schematică a componentelor hardware și a transferului de informație între ele.

Fig. 2.4. Structura Hardware a ansamblului de test

Structura Hardware este formata din:

RS BOX, un instrument hardware cu contacte și switch-uri prin care se alimentează clusterul;

Instrumentul de bord (Cluster-ul), care este alimentat prin RS BOX de la sursa de tensiune și primește de la PC, prin CANcase semnal de comandă;

CANcase, dispozitiv hardware prin care se trimit comenzi și se recepționează răspunsuri înspre, respectiv dinspre cluster;

PC, în care se găsesc modulele de test înglobate în platforma uTAS (capitolul 4) și eventual simulările care trimit mesaje către cluster și interpretează răspunsuri de la cluster; [24]

2.3 Simularea CANoe

CANoe este un instrument de dezvoltare și testare produs de către firma Vector Informatik GmbH. Programul este folosit în industria automotive și dezvoltatori de unități electronice de control (ECU) pentru dezvoltare, analiză, simulare, testare, etc. Instrumentul este ideal pentru realizarea simulărilor rețelei de noduri din mașină și a comportamentului acestora în diferite situații. [18]

Pentru partea din modulul realizat care folosește simulare de CANoe, s-a utilizat o simulare dedicată tipului de cluster prezentat, care înglobează toate funcțiile disponibile pe cluster și cu ajutorul căreia se poate comanda instrumentul.

2.4 Platforma LabVIEW

Laboratory Virtual Instrument Engineering Workbench (LabVIEW) este un mediu de programarece folosește conceptul de programare grafică (G programming) care, spre deosebire de mediile de programare clasice (C, C++, C#, Delphi, Pyton, Java, etc) în care programarea se face pe bază de cod scris (text), folosește instrumente virtuale (VI), fire, bucle, și alte elemente de programare pentru a construi codul propriu-zis. În acest mod, programarea devine mai simplă, fără multe reguli de sintaxă și, datorită panoului frontal (interfața cu utilizatorul) foarte “prietenoasă cu utilizatorul”.

LabVIEW este disponibil pe Windows, Macintosh și Linux, iar programele create sunt portabile între platforme, deci se poate crea programul pe Windows și rula pe Linux și reciproc. [16]

2.4.1 Instrumente virtuale (VI)

Limbajele de programare precum C sau BASIC folosesc funcții sau subrutine ca elemente de programare, pe când construirea unui program în LabVIEW se face pe bază de instrumente virtuale (Virtual Instrument- VI). În sine, un program este un VI, deoarece el realizează anumite funcții programatice care pot fi apelate din exterior.

Un VI este compus din trei elemente esențiale: panou frontal, diagramă bloc și icoană. Panoul frontal este folosit pentru a afișa controale și indicatori pentru utilizator iar diagrama bloc conține codul VI-ului. Icoana este o reprezentare vizuală a VI-ului și conține conectori pentru intrări și ieșiri. [25]

VI-urile, îndeplinind și fiind, în sine, niște funcții particulare, pot fi folosite în cadrul altor VI-uri. Astfel, acestea sunt denumite subVI-uri și pot fi folosite în VI-ul principal de ori de câte ori e nevoie de funcțiile ce le îndeplinesc. Asemenea parametrilor unei subrutine, subVI-urile comunică cu alte elemente prin conectorii icoanei ce-i reprezintă. Conectorilor icoanei i se pot atribui controale sau indicatori din panoul frontal, care vor deveni elemente de intrare și ieșire a subVI-ului și valoarea lor va putea fi manipulatată din exteriorul subVI-ului.[11]

Fig. 2.5Icoana modulului cu conectorii proprii

2.4.2 Panoul Frontal

Panoul Frontal al unui VI reprezintă interfața cu utilizatorul. El este alcătuit din controale și indicatori care sunt intrările, respectiv ieșirile VI-ului. Controalele pot reprezenta butoane, câmpuri pentru valori, switch-uri, semnale de la echipamente externe și alte elemente de intrare prin care utilizatorul poate introduce date în program. Indicatoarele reprezintă datele de ieșire în urma rulării programului și pot apărea sub formă de câmpuri de valori, LED-uri, grafice sau diagrame, etc. Controalele și indicatorii se pun pe panoul frontal din paleta de controale (fig. 2.6) cu “drag and drop” și se pot edita în funcție de: poziție, mărime, culoare, valori implicite, afișaj etc. Accesul la paleta de controale se face doar atunci când panoul frontal este activ. [27]

Controalele și indicatorii sunt împărțiți în categorii și subcategorii în funcție de tipul de date ce-l folosesc, în funcție de funcționalitatea lor, etc. În limbaj programatic, acestea sunt defapt terminale prin care se introduc sau se extrag valori ale variabilelor ce le reprezintă.[25]

Fig. 2.6 Paleta de controale

2.4.3Diagrama bloc

Diagrama bloc reprezintă codul sursă, programul propriu-zis, care este alcătuit din VI-uri de nivel scăzut legate între ele prin fire.

Aplicațiile LabVIEW fiind construite prin programare grafică, programarea neavând o ordine fixă- precum programarea prin text, trebuie stabilită o metodă prin care codul sa fie executat în ordinea dorită de programator. Acest lucru se face prin metoda “curgerii” datelor, prin care elementele de program sunt legate între ele prin fire, care stabilesc ordinea executării codului. Deasemenea, atunci când avem blocuri de program independente, acestea se execută în ordinea așezării lor în fereastra de diagramă bloc, și anume, executarea se face de la stânga la dreapta, de sus în jos. [25]

Controalele și indicatorii din panoul frontal au terminale ca și corespontenți în diagrama bloc. Terminalele se pot defini ca surse (intrări) sau destinații (ieșiri) pentru diagrama bloc. Acestea pot fi minimizate prin debifarea proprietății View As Icon (Fig.2.7).[27]

Fig. 2.7 Terminale (View As Icon)

Elementele de program, prin care este construită diagrama bloc se iau din paleta de funcții (Fig.2.8) și sunt împărțite pe categorii și subcategorii în concordanță cu tipul structurii, respectiv funcția pe care o execută.

Fig. 2.8 Paleta de funcții

În program se pot folosi diferite tipuri de date, cele mai utilizate sunt prezentate în figura 2.9. Fiecare tip de dată este reprezentat printr-o culoare specifică. Deasemenea, firele ce leagă nodurile între ele sunt de culoare datei pe care o reprezintă iar grosimea firului este în funcție de cantitatea de date pe care o transmite.

Fig. 2.9 Tipuri de date

Capitolul 3

Descrierea modulului

3.1 Introducere

Datorită nevoii testării funcționalităților și opțiunilor cu care sunt dotate automobilele, producătorii de componente automotive sunt nevoiți să dezvolte și instrumente adecvate de testare a acestor funcționalități. În îndeplinirea acestei nevoi s-a realizat modulul pentru testarea meniului instrumentelor de bord.

Modulul cuprinde mai multe funcționalități, printre care:

Controlare meniu folosind simularea de CANoe;

Controlare meniu direct prin transmitere de mesaje pe CAN;

Control luminozitate cluster;

Cu ajutorul modulului se pot activa sau dezactiva anumite functionalități ale cluster-ului cum ar fi: limba, selecție de opțiune activă pe ecranul principal în momentul testului, mod de afișaj, practic toate opțiunile disponibile pe custer-ul testat.

Modulul realizat, ca orice program realizat în platforma LabVIEW, este alcătuit din două părți principale:

Panoul frontal;

Diagrama bloc;

3.2. Panoul Frontal

Panoul frontal reprezintă interfața cu utilizatorul și prin aceasta utilizatorul controlează programul realizat în diagrama bloc.

Fig. 3.1 Panoul Frontal al programului

Pe panoul frontal se găsesc toate controalele și indicatorii de care utilizatorul are nevoie pentru a comanda programul (codul din diagrama bloc). Astfel că se remarcă patru zone de comandă:

Zona de comandă meniu – aflată în partea dreaptă a panoului frontal, care cuprinde cele 5 butoane de comandă a meniului (“Up”, “Down”, ”Previous”, “Next” și “OK”), fiecare cu funcționalitatea proprie (vezi 3.3.2 și 3.3.3);

Zona de control simulare de CANoe – este zona încadrată în dreptunghiul gri deschis denumită “CANoe Simulation” care înglobează butoanele “Start” și “Stop” prin care se comandă starea simulării de CANoe;

Zona de control luminozitate – reprezintă “slidebar”-ul “Display Dimming”, poziționat în partea stângă jos a panoului frontal, prin care utilizatorul poate modifica luminozitatea display-ului clusterului; Bara de reglaj de luminozitate are și un indicator care afișează în hexazecimal valoarea setată de către utilizator;

Zona de afișaj sau de informare utilizator prezentă în partea dreaptă jos a panoului frontal, este reprezentată de indicatorul “Message” care informează utilizatorul cu privire la starea în care se găsește programul, la bucla în care se găsește programul sau la acțiunea care o face programul la un moment dat.

3.3. Diagrama Bloc

Diagrama bloc reprezintă codul programului. Programul realizat are o structură complexă și se bazează pe mai multe procedee de programare combinate între ele, fiecare descrise în continuare pe baza programului realizat.

3.3.1 Structura Programului pe blocuri

Codul sursă este împărțit pe mai multe blocuri funcționale:

Blocul de inițializări, în care sunt inițializate controalele și indicatorii din panoul frontal (fig 3.2). Inițializările se fac dându-se valori implicite la începutul programului elementelor din panoul frontal sau citindu-se valorile unor parametrii de intrare primiți din exteriorul modulului prin variabile de intrare;

Fig 3.2 Blocul de inițializări

Blocul de evenimente, în care evenimentele generate prin diferite acțiuni pe care utilizatorul le face în panoul frontal, trimite programul să execute cazurile dedicatefiecărui eveniment. Arhitectura blocului de evenimente este prezentată în fig 3.3:

Fig 3.3 Blocul de evenimente

Blocul de execuție cazuri, reprezintă partea principală din program, în care sunt executate evenimentele declanșate iar arhitectura este prezentată în fig 3.4:

Fig. 3.4 Bloc de execuție cazuri

Blocul de finalizare (fig 3.5), în care se face închiderea modulului și eliberarea stivei folosite în procesul“producer-consumer” (3.4.3);

Fig. 3.5 Blocul de finalizare

Blocul de automatizare a modulului (fig. 3.6), prin care se face controlul modulului cu ajutorul secvenței automate (4.2);

Fig. 3.6 Blocul de automatizare

3.3.2 Bucle și structuri

Bucle Repetitive

Bucla “While” (fig. 3.7a), reprezintă o structură repetitivă cu un număr nedefinit de pași, oprirea buclei făcându-se la îndeplinirea unei condiții de oprire. În cazul de față, bucla while este folosită în blocul de automatizare (fig. 3.6), în blocul de execuție cazuri (fig. 3.4) și în blocul de evenimente(fig. 3.3). În program s-a folosit bucla “While” pentru ca programul să poată “aștepta” evenimente introduse de utilizator iar la declanșarea unui eveniment să trimită programul în blocul de execuție cazuri, apoi cazurile transmise prin stivă să poată fi executate în blocul de execuție cazuri. În cazul automatizării, bucla “While” folosește la declanșarea evenimentelor specificate prin secvență.

Fig. 3.7 Bucle repetitive

Bucla “For” (fig. 3.7b), reprezintă o structură repetitivă prin care se execută instrucțiunile descrise în interiorul ei de un anumit număr de ori. Numărul repetărilor se definește în colțul din stânga sus printr-o constantă sau variabilă a cărei valoare este controlată de un control. În cazul unui tablou de elemente, nu este necesară precizarea numărului de pași de execuție, ci acesta se ia automat din numărul de elemente al tabloului.

În cadrul programului principal, bucla “For” este folosită doar în blocul de automatizare, în cadrul extragerii de elemente dintr-un cluster de elemente sub formă de tablou, deci numărul de pași fiind implicit dat de numărul de elemente ale tabloului.

Structuri

Case Structure(fig 3.8) reprezintă o structură de cazuri care sunt definite și stabilite prin valoarea unei variabile, sau, în cazul nostru, de numele unui element din stivă.

Fig. 3.8 Case Structure

Cazul care se execută la un moment dat este dat de numele elementului din stivă. Un caz particular de “Case Structure” este Event Case Structure (fig. 3.9), o structură de cazuri bazate pe evenimente, care comandă o secțiune din program să se execute atunci când este declanșat un anumit eveniment.

Fig. 3.9 Event Case Structure

În cazul de față, “Event Case Structure” este folosită în blocul de evenimente (fig. 3.3) și încarcă în stivă numele cazului aferent evenimentului declanșat, iar în unele cazuri, cum este cel prezentat în figura 3.9, trimite și alte comenzi programului (atribuie valori, execută anumite secvențe de program, setează întărzieri, etc);

O altă structură folosită în program este Flat Sequence (fig. 3.10). Această structură controlează ordinea în care se execută blocurile de instrucțiuni într-un program și se folosește atunci când programatorul dorește executarea unor instrucțiuni într-o anumită ordine stabilită de el. Astfel că, structura este alcătuită din ferestre în care se pun instrucțiunile de executat. Structura constă în faptul că ferestrele se vor executa una după alta de la stânga la dreapta, în ordinea așezării lor și nu va permite programului să treacă la executarea instrucțiunilor din fereastra următoare decât atunci când s-au executat toate instrucțiunile din fereastra curentă.

Fig. 3.10 Flat Sequence

În figura 3.10 este prezentată secțiunea din program ce deschide și pornește simularea de CANoe, care folosește “Flat Sequence” pentru a stabili ordinea exactă a executării instrucțiunilor și care va fi prezentată în detaliu mai târziu.

3.4. Arhitectura programului

Arhitectura programului realizat se bazează pe mai multe metode de programare, combinate între ele, implementabile folosind platforma de programare LabVIEW.

3.4.1 State machine

Acesta este un procedeu de programare folosit în LabVIEW prin care mașina de execuție execută programul trecând dintr-o stare în alta (dintr-un caz în altul) până la cazul final. Acest procedeu este alcătuit dintr-o buclă “While” în interiorul căreia se găsește o structură “Case” care este controlată de o enumerație de stări definită în prealabil (fig. 3.11). [10]

Fig. 3.11 State-machine

Enumerația conține fiecare stare a mașinii, fiecare stare reprezentând câte un caz în structura “Case”. Astfel că, mașina începe execuția instrucțiunilor printr-un caz inițial în care este setată structura “Case”, din care mașina este setată în altă stare, aceasta trecând pe alt caz de instrucțiuni și tot așa până la ultima stare, în care la finalul executării ultimelor instrucțiuni este oprită bucla “While”.

Datorită folosirii combinate a procedeelor de arhitectură a programului, pentru exemplificare concretă și singulară a procedeului mașinii de stare, exemplul din figura 3.11 a fost creat independent de program, însă folosind enumerația de stări a programului principal.

În plus, procedeul “State machine” constă în folosirea regiștrilor de schimb (Shift-Registers) prin care se transmit valorile precedente de la un pas la altul într-o buclă repetitivă.

3.4.2 Programare Event-driven

Programarea condusă de evenimente (fig. 3.12) constă în folosirea unui “Even Case Structure” într-o buclă “While” care rulează încontinuu și așteaptă declanșarea unui eveniment.

Fig. 3.12 Programare Event-driven

Evenimentele se declanșează în funcție de proprietățile butoanelor sau de alte diferite evenimente a căror surse se pot selecta ca în figura 3.13 din tabelul din mijlocul figurii (Event Sources) iar opțiuni de selecție (Events) se găsesc în tabelul din partea dreaptă din figura 3.13:

Fig. 3.13 Opțiuni de evenimente

3.4.3 Producer-Consumer Design

Procedeul “Producer-Consumer” constă în folosirea unor itemi produși într-un anume loc și consumați în alt loc al programului. Acest procedeu folosește stive pentru stocarea itemilor produși (fig. 3.15) și consumarea itemilor se face după regulile stivei.

Fig. 3.15 Producer-Consumer

De obicei acest procedeu se folosește în combinație cu procedeul “Event-Driven”, astfel că structura de evenimente produce itemii și îi încarcă în stivă, iar aceștia sunt consumați în cadrul unei structuri “Case” care execută instrucțiunile corespunzătoare fiecărui item (fig. 3.16).

Fig. 3.16 Producer-Consumer și Event-Driven combinate

3.5 Descrierea Programului

Programul realizat este structurat pe blocuri, așa cum a fost prezentat la punctul 3.3.1. Fiecare bloc cuprinde un număr de instrucțiuni proprii și realizează câte o etapă din program.

3.5.1 Blocul de inițializări

În blocul de inițializări, printre altele, sunt inițializate câteva variabile ce țin de controlul extern al modulului. Prin aceste variabile se controlează modulul din exterior și sunt puse ca și conectori la icoana VI-ului, ce reprezintă modulul. Acestea sunt prezentate în figura 3.17:

Fig. 3.17 Declarare variabile externe

Tot în blocul de inițializări (fig. 3.2) sunt declarate și inițializate și alte controale sau indicatori cum ar fi:

Tab control-ul în care se găsesc toate elementele prin care utilizatorul interacționează cu programul;

Butonul de oprire “stop” care se inițializează cu valoarea false;

Controlului Message i se dă mesajul “Starting…” prin care utilizatorul este informat cu privire la starea în care se găsește programul la un moment dat;

Butoanele din figura 3.18 sunt setate ca fiind accesibile sau neaccesibile prin noduri de proprietate ale butoanelor. Nodurile de proprietate reprezintă proprietăți ale controalelor (în cazul de față, ale butoanelor) care pot fi citite sau setate în funcție de preferințe. [12]

Fig. 3.18 Inițializare accesibilitate butoane

După cum se vede în figura 3.18, la pornirea programului toate butoanele sunt disponibile.

Tot în această etapă se face și verificarea stării simulării de CANoe. Astfel că, dacă aceasta a fost setată de către programator să se deschidă în momentul pornirii modulului, butonul de start_canoe_sim va fi setat ca inaccesibil utilizatorului și butonul de stop_canoe_sim va fi setat ca accesibil iar dacă programatorul a setat ca în momentul pornirii modulului să nu se deschidă simularea de CANoe, butonul de start_canoe_sim va fi accesibil utilizatorului iar butonul de stop_canoe_sim va fi inaccesibil utilizatorului. De fiecare dată la pornirea modulului se face verificarea stării simulării de CANoe prin structura “CASE” din figura 3.19 cu cele două cazuri posibile:

Fig 3.19 Verificarea stării simulării de CANoe

În blocul de inițializări am cuprins și o parte din procedeul “Producer-Consumer”, și anume crearea și popularea stivei cu primul element și producerea primei stări a mașinii de stare pe care o cuprinde programul (fig 3.20).

Fig 3.20 Creare stivă și inițializare “State-Machine”

3.5.2 Blocul de evenimente

Blocul de evenimente încarcă în stivă numele cazului mașinii de stare corespunzător evenimentului declanșat. Astfel că la fiecare eveniment definit, cazul mașinii de stare se schimbă încărcându-se în stivă numele cazului de stare. Cazurile stărilor mașinii se execută în blocul de execuție cazuri prezentat la punctul 3.5.3.

La fiecare declanșare de eveniment, în stivă se încarcă numele cazului de executat iar programul sare în blocul de execuție cazuri la cazul încărcat în stivă executând instrucțiunile aferente cazului.

Blocul de evenimente cu toate evenimentele ce se pot declanșa prin modul este prezentat în figurile 3.21:

Fig 3.21 Blocul cu evenimentele definite în modul

În inițializare s-au făcut accesibile sau inaccesibile unele butoane, deci utilizatorul nu le poate apăsa și nu poate astfel declanșa evenimentele produse prin schimbarea valorii acestor butoane, asta înseamnă că acțiunea evenimentului respectiv este deja activă din anumite considerente și la momentul activării acțiunii s-au făcut accesibile sau inaccesibile anumite butoane ce țineau de acțiunea respectivă. Acest lucru se va întâmpla și pe durata rulării programului (care va fi explicată mai târziu).

Butoanele folosite ca declanșatoare de evenimente suntde tip “switch” (fig. 3.22), adică ele, odată acționate, își păstrează valoarea de după acționare și nu revin singure la valoarea inițială.

Fig. 3.22 Setare tip acționare butoane

Datorită setării butoanelor de tip “switch”, acestea, odată acționate, trebuie să revină la starea inițială. Pentru această acțiune s-a utilizat structura secvențială din figura 3.23, astfel că în prima fereastră se acționează butonul, după care programul așteaptă 100 ms iar apoi i se atribuie butonului valoarea inițială.

Fig. 5.23 Declanșarea evenimentului și

revenirea butonului la starea inițială

Pauza dintre evenimente este setată la 200 ms (fig. 3.23 colțul din strânga sus), pentru a preveni suprapopularea stivei cu evenimente și supraîncărcarea procesorului la lansarea în execuție a mai multor evenimente cu timpi foarte scurți între ele.

Oprirea blocului de evenimente (a buclei “while”) se face prin evenimentul butonului de “stop” sau, butonul nefiind accesibil utilizatorului, acesta poate opri blocul de evenimente pur și simplu prin părăsirea panoului frontal de la X-ul ferestrei, din dreapta sus. Aceste două evenimente duc la oprirea blocului de evenimente și nu numai. Evenimentele sunt prezentate în figura 3.24:

Fig. 3.24 Evenimentele ce opresc bucla blocului de evenimente

Lista cu toate evenimentele disponibile este prezentată în figura 3.25:

Fig. 3.25 Evenimentele accesibile utilizatorului

Evenimentul definit ca“Timeout”(fig. 3.26) este evenimenul prin care nu se execută nicio instrucțiune, programul doar așteaptă declanșarea unui eveniment.

Fig. 3.26 Evenimentul “Timeout”

3.5.3 Blocul de execuție cazuri

Blocul de execuție cazuri reprezintă partea principală a programului în care sunt executate evenimentele lansate de către blocul de evenimente. Astfel că în blocul de evenimente se pune în stivă numele cazului de execuție. Execuția programului se duce la ultimul caz introdus în stivă, din care execută toate instrucțiunile prezente. Cazul în cauză, după terminarea execuției tuturor instrucțiunilor din el, încarcă în stivă un alt caz de execuție, trimițând automat execuția programului în alt caz (astfel se poate crea un șir de execuție caz după caz). Cazul în care este trimis firul de execuție este “Idle” (fig. 3.27), un caz tampon, în care nu se execută nicio instrucțiune (similar cu evenimentul “Timeout”) ci pur și simplu doar se așteaptă lansarea unui nou eveniment și execuția cazului aferent evenimentului.

Fig.3.27 Cazul “Idle”

Singurul lucru care se face în acest caz de execuție este înștiințarea utilizatorului că este în cazul “Idle” și deci, programul așteaptă ca utilizatorul să declanșeze noi evenimente.

Diagrama “Disable” prezentă în figura 3.27 dezactivează execuția uneia sau mai multor instrucțiuni prezente în interiorul ei (în analogie cu comentariile din limbajele de programare convenționale). Am utilizat această metodă, pentru a nu tot trimite programul în mod repetat în cazul ”Idle” și a nu supraîncărca în acest mod procesorul calculatorului degeaba.

Cazurile de execuție din care este compus blocul de cazuri de execuție sunt ilustrate în figura 3.28 și vor fi prezentate în detaliu în continuare.

Fig. 3.28 Cazurile de execuție

Cazul “startup”

Primul caz de execuție în care intră programul este cazul “startup” prezentat în figura 3.29. Lansarea în execuție a acestui caz se face încă din etapa de inițializare a programului. Astfel că, înainte de toate, programul începe prin a executa instrucțiunile din cadrul acestui caz de execuție.

Fig. 3.29 Cazul de execuție “startup”

În acest caz se face deschiderea și pornirea simulării CANoe. În prima fereastră a structurii secvențiale se atribuie valoarea “true” unei variabile de stare a simulării. Valiabila de stare a simulării de CANoe s-a folosit pentru a știi în orice moment al execuției programului starea simulării de CANoe (adică dacă aceasta este pornită sau oprită). Deasemenea, controlul “start_canoe_sim” este setat să fie indisponibil utilizatorului, deoarece în acest pas urmează să se facă pornirea simulării de CANoe și deci nu e nevoie de buton devreme ce deja este lansat în execuție evenimentul definit acelui buton.

În a doua fereastră a structurii secvențiale, se fac indisponibile utilizatorului toate controalele de pe panoul frontal, datorită faptului că programul execută evenimentul în cauză și împiedicând utilizatorul să lanseze alte evenimente în timp ce programul execută evenimentul curent. Tot în această fereastră, utilizatorul este informat de starea de execuție a programului, și anume că acesta face pornirea simulării.

În următoarea fereastră se realizează deschiderea și pornirea propriu-zisă a simulării folosind anumite comenzi definite în subVI-ul “ModuleComm” prin care modulul transmite anumite comenzi programului principal, care pornesc simularea de CANoe.

În fereastra următoare a structurii secvențiale se creează o întărziere care este setată la 7000 ms, așteptare necesară până la deschiderea simulării de către Windows.

În ultima fereastră toate controalele sunt setate ca fiind disponibile utilizatorului, revenind la starea inițială de disponibilitate, pentru ca utilizatorul să poată declanșa un alt eveniment. Singurul control rămas indisponibil este “start_canoe_sim”. Acesta este rămas indisponibil deoarece, la acest pas simularea este deja pornită, nemaifiind necesară declanșarea evenimentului ce duce la pornirea ei.

În acest caz de execuție se setează starea “false” către oprirea buclei blocului de execuție cazuri, pentru ca aceasta să rămână funcțională implicit în toate cazurile dinsponibile. La finalul cazului se populează stiva cu elementul “Idle” care direcționează firul de execuție în cazul “Idle” unde așteaptă un nou eveniment.

Pe parcursul programului cazul “startup” este declanșat și de acționarea butonului “start_canoe_sim” (atunci când simularea s-a oprit în prealabil și deci acesta este accesibil).

Cazul “up”

Cazul de execuție “up” este activ în momentul rulării evenimentului declanșat de acționarea butonului “Up_Button”. Acest eveniment încarcă în stivă numele cazului de execuție “up” iar execuția programului se direcționează în acest caz (fig. 3.30).

Fig.3.30 Cazul de execuție “up”

Cazul se compune dintr-o structură cu două părți: una pentru situația în care simularea de CANoe este pornită iar alta pentru situația în care aceasta este oprită. Distincția între situații se face pe baza controlului “sim_ON”, căruia i se atribuie valoarea “true” în cazul în care se face pornirea simulării și valoarea “false” în cazul opririi acesteia. Programul se comportă diferit în funcție de starea simulării.

În cazul în care simularea este pornită, programul pur și simplu atribuie valori unei variabile din simulare (fig. 3.31).

Fig. 3.31 Controlul variabilei “up” din simulare

Controlul variabilei din simulare s-a făcut folosind subVI-ul “ModuleComm” cu comanda set_env.

Atribuirea valorii variabilei s-a făcut folosind bucla “For”, în nevoia de a atribui o dată valoarea 1 iar apoi valoarea 0 variabilei din simulare (fig. 3.32).

Fig. 3.32 Valorile atribuite variabilei “up” din simulare

În primul caz s-a setat butonul “Up_Button” ca fiind indisponibil utilizatorului pentru ca acesta să nu poată trimite mai multe evenimente la timpi scurți unul după altul până la finalul execuției evenimentului curent, în scopul de a nu supraîncărca rețeaua CAN sau buffer-ul de comenzi al LabVIEW. În același scop este setată o întărziere de 500 ms între cele două repetiții ale buclei “For” (defapt între cele două comenzi trimise). În timpul execuției comenzii date, utilizatorul este înștiințat prin controlul “Message” de faptul că programul trimite comenzi și este în curs de procesare.

În cazul în care simularea este oprită (fig. 3.33), programul pur și simplu trimite mesajele sub formă de bytes pe CAN.

Fig. 3.33 Trimiterea de mesaje sub formă de bytes pe CAN pentru evenimentul “up”

Conținutul mesajelor nu a putut fi afișat datorită caracterului confidențial al mesajelor de CAN și datorită securității informației.

Mesajele s-au trimis secvențial folosind o structură secvențială cu ferestre de execuție. Între mesajele cu un caracter diferit s-au pus întărzieri pentru ca cluster-ul să aibă timp să execute acțiunea declanșată prin mesajul respectiv.

La începutul transmiterii mesajelor, butonul prin care se declanșează evenimentul este făcut inaccesibil utilizatorului pentru a avea timp programul și clusterul sa trimită mesajele, respectiv să execute acțiunile aferente mesajelor, înaintea declanșării altui eveniment, iar la finalul transmiterii mesajelor, acesta este făcut din nou accesibil utilizatorului, utilizatorul având posibilitatea să declanșeze un alt eveniment sau chiar să repete aceeași acțiune.

Cazul “down”

Cazul de execuție “down” este asemănător cazului “up”. Acesta folosește aceleași elemente de programare prezentate și în cazul anterior, singura diferență fiind că acesta execută o altă acțiune (setează altă variabilă din simularea de CANoe și trimite alte mesaje pe CAN) față de cea din cazul anterior. Cazul curent este ilustrat în figura 3.34:

Fig. 3.34 Cazul de execuție “down”

Cazul de execuție “down” se execută atunci când este acționat butonul “Down_Button” și este declanșat evenimentul “Down_Button” din blocul de evenimente.

Și în acest caz se face verificarea stării simulării de CANoe iar dacă aceasta este pornită se execută instrucțiunile de pe cazul “true” (fig. 3.35) din interiorul structurii “down”.

Fig. 3.35 Cazul “true” din interiorul structurii “down”

În acest caz se trimit comenzi pentru controlul simulării, și anume pentru controlul variabilei “EnvDown” din simulare, o dată cu o valoare de activare (valoarea “1”), iar a doua oară cu valoarea de dezactivare (valoarea “0”). Deasemenea, pe parcursul execuției instrucțiunilor butonul “Down_Button” este făcut inaccesibil utilizatorului (la început butonul este făcut inaccesibil utilizatorului iar la finalul execuției este făcut din nou accesibil).

În cazul în care simularea nu este pornită, structura “down” va executa instrucțiunile scrise în cazul “false”(fig. 3.36) în care se transmit pur și simplu pe CAN mesajele de setare meniu în jos.

Fig. 3.36 Cazul “false” din interiorul structurii “down”

După execuția cazului execuția programului este trimisă în “idle”, unde programul “așteaptă” declanșarea următorului eveniment.

Cazul “next”

Structura instrucțiunilor și a cazurilor este identică cu cea a cazurilor anterioare, particularitatea cazului fiind în variabila din simulare care este controlată în acest caz de execuție sau mesajele trimise pe CAN în cazul în care simularea de CANoe nu este pornită.

Structura de instrucțiuni a cazului este prezentată în figura 3.37:

Fig. 3.37 Cazul de execuție “next”

Și în acest caz de execuție se verifică starea simulării de CANoe și în caz că aceasta este pornită se execută instrucțiunile din cazul “true” al structurii “next” ilustrat în figura 3.38:

Fig. 3.38 Cazul “true” din interiorul structurii “next”

Instrucțiunile din acest caz atribuie variabilei “EnvMenuUp” din simulare la primul ciclu al buclei “For” valoarea “1” (activează semnalul) și la a doua rulare valoarea “0” (dezactivează semnalul).

În cazul “false” al structurii “next” se trimit mesajele corespunzătoare trecerii meniului la fereastra de opțiuni următoare (către dreapta). Acest caz este ilustrat în figura 3.39:

Fig. 3.39 Cazul “false” din interiorul structurii “next”

La începutul execuției instrucțiunilor din acest caz, butonul “Next_Button” este făcut inaccesibil utilizatorului pe toată durata execuției acțiunii aferente instrucțiunilor, iar la final acesta este făcut din nou accesibil lansării unui alt eveniment sau repetării aceluiași eveniment.

Cazul “previous”

Asemenea celorlalte trei cazuri prezentate mai sus, și acest caz se bazează pe aceeași arhitectură și compoziție de instrucțiuni, diferind doar variabila controlată în simulare sau mesajele transmise direct pe CAN. Structura cazului este ilustrată in figura 3.40:

Fig. 3.40 Cazul de execuție “previous”

După cum se vede în parea stângă a figurii, alegerea cazului se face după starea controlului “sim_ON”. Astfel că, dacă acesta are valoarea “true” se vor executa instrucțiunile din cazul “true” al structurii “previous” prezentate în figura 3.41:

Fig. 3.41 Cazul “true” din interiorul structurii “previous”

În acest caz, în primul ciclu al buclei “For” se va atribui variabilei din simulare: “EnvMenuDown”valoarea “1” iar în al doilea ciclu al buclei “For” i se va atribui valoarea “0” (pentru activarea și dezactivarea semnalului trimis de către variabilă clusterului).

În cazul “false” se trimit aceleași instrucțiuni ca în cadrul cazurilor de execuție prezentate, însă mesajele transmise diferă. Structura este ilustrată în figura 3.42:

Fig. 3.42 Cazul “false” din interiorul structurii “previous”

În timpul execuției instrucțiunilor din cazul curent butonul “Previous_Button” este făcut inaccesibil utilizatorului până la finalul executării tuturor instrucțiunilor din interiorul cazului.

După execuția cazului curent, programul este trimis în cazul “Idle” unde “așteaptă” declanșarea unui alt eveniment de către utilizator.

Cazul “ok/reset”

În cadrul acestui caz instrucțiunile care se execută duc la activarea opțiunii selectate în cadrul meniului clusterului. Cazul de execuție este ilustrat în figura 3.43:

Fig. 3.43 Cazul de execuție “ok/reset”

Arhitectura cazului este aceeași cu ale celor prezentate mai sus, doar variabila controlată din simulare și mesajele trimise pe CAN sunt diferite.

Cazul de execuție este diferit în funcție de starea simulării de CANoe ca și în cazul celorlalte cazuri de până acum, deci vor fi două opțiuni de seturi de instrucțiuni executabile.

În cazul când simularea este pornită (fig. 3.44) se atribuie pe rând variabilei “EnvOK” valoarea “1” pentru activare și apoi valoarea “0” pentru dezactivare la un timp de 100ms între cele două instrucțiuni.

Fig. 3.44 Cazul “true” din interiorul structurii “ok/reset”

Datorită duratei mai mari de activare a variabilelor din simulare și apoi transmitere a mesajelor pe CAN de către acestea din urmă, în fiecare caz de execuție ce controlează simularea de CANoe s-a introdus un mesaj de informare a utilizatorului prin controlul “Message” cu privire la faptul că programul rulează și deci utilizatorul trebuie doar să aștepte ca instrucțiunile să fie executate ca să poată declanșa alte evenimente (să poată apăsa alte butoane).

Atunci când simularea de CANoe nu este pornită, instrucțiunile din cadrul structurii “ok/reset” ce se execută sunt cele prezente în cazul “false” (fig. 3.45), și anume trimiterea directă de mesaje pe CAN (ca și în cazul structurilor prezentate până acum).

Fig. 3.45 Cazul “false” din interiorul structurii “ok/reset”

Trimiterea directă a mesajelor se face folosind subVI-ul “cef_cmd.vi” cu structura din figura 3.46:

Fig. 3.46 cef_cmd.vi

Mesajele se trimit folosind comanda “write_can_hw” disponibilă în pachetul uTAS (Anexa 1) după sintaxa comenzii. Astfel că prin controlul “list of params” se vor introduce parametrii: numărul canalului pe care vrem să transmitem mesajul, ID-ul mesajului și mesajul efectiv (datele sub formă de bytes).

Cazul “display_dimming”

În acest caz, ilustrat în figura 3.47 se execută instrucțiuni referitoare la setarea luminozității display-ului clusterului și nu numai.

Fig. 3.47 Cazul de execuție “display_dimming”

Acest caz se execută tot în funcție de starea simulării de CANoe. Astfel că dacă simularea este pornită se vor executa instrucțiunile din cazul “true” ilustrat în figura 3.48. Pentru controlul luminozității clusterului este nevoie de controlul și activarea mai multor variabile din simulare. Acestor variabile le e atribuită valoarea dată de utilizator prin controlul “Display_Dimming”.

Fig. 3.48 Cazul “true” din interiorul structurii “display_dimming”

În cazul în care simularea nu este pornită, mesajele se transmit direct pe CAN. Construirea mesajului se face programatic (parțial hardcodat- ilustrat în figura 3.49) și nu total hardcodat ca și până acum. Mesajele au în componență valoarea luminozității setată de către utilizator și structura de bytes e nevoie a fi concatenată cu aceasta pentru a forma mesajul final. Pentru aceasta s-au folosit unelte disponibile în LabVIEW precum: “number to hexadecimal string”, “concatenate strings” și “build array” (în ordine în diagramă de la stânga la dreapta):

Fig. 3.49 Cazul “false” din interiorul structurii “display_dimming”

Cazul “stop_canoe_sim”

În acest caz se realizează efectiv oprirea simulării de CANoe prin trimiterea comenzii de “quit_RBS” prin “ModuleComm”. Acest caz este prezentat în figura 3.50:

Fig. 3.50 Cazul de execuție “stop_canoe_sim”

La începutul execuției se atribuie valoarea “false” controlului “sim_ON” și se pun toate controalele în starea de inaccesibilitate pentru utilizator. Utilizatorul este informat prin controlul “Message” să aștepte până se execută instrucțiunea de oprire a simulării.

Fiind vorba de oprirea unui program și nu numai de transmiterea unor mesaje, acestuia îi ia mai mult timp pentru oprire. Așadar, de când instrucțiunea comandă oprirea simulării și până aceasta se oprește efectiv, programul este setat să aibă o întârziere de 2 secunde, după care controalele panoului frontal vor deveni accesibile utilizatorului, acesta putând declanșa evenimente. În acest moment toate butoanele de pe panoul frontal sunt active mai puțin cel de “stop_canoe_sim”, datorită faptului că deja simularea de CANoe e oprită și nu ar mai avea niciun sens declanșarea acțiunii de oprire a acesteia.

Cazul “exit”

Cazul “exit” duce la oprirea simulării de CANoe în cazul în care aceasta este pornită, la oprirea buclei de automatizare și la oprirea buclei de cazuri de execuție. Acest caz de execuție poate fi executat de două evenimente (fig. 3.24): evenimentul “stop” declanșat de controlul “stop” (care nu e nici vizibil, nici accesibil, deci nu este declanșat niciodată direct de utilizator, decât programatic) și evenimentul “Panel Close?”declanșat în momentul închiderii panoului frontal al programului (apăsarea pe X-ul ferestrei). Cazul curent este ilustrat în figura 3.51 și în cazul în care simularea este pornită execută aceleași instrucțiuni ca și cazul “stop_canoe_sim”.

Fig. 3.51 Cazul de execuție “exit”

Cu privire la erori, programul nu are un mecanism foarte bine pus la punct de tratare a erorilor, ci erorile sunt doar scoase de la VI-uri pentru ca acestea să nu oprească execuția programului prin erori interne de LabVIEW, ci doar să fie arătate programatorului în panoul frontal (utilizatorul nu le poate vedea) prin indicatori, ca acesta să găsească problemele de funcționare în momentul depanării programului. [12]

După cum se vede în figurile de mai sus, toate VI-urile (în special “ModuleComm”) sunt legate prin fire de eroare, având în total 16 indicatoare de eroare. În acest caz, în momentul depanării programului de către programator acesta poate identifica unde a fost eroarea prin verificarea indicatoarelor de erori. Astfel, indicatorul care are valoarea de adevăr “true”, acela a returnat eroarea și VI-ul de care este legat nu poate să execute toate instrucțiunile definite în el.

3.5.4 Blocul de finalizare

Blocul de finalizare (ilustrat în figura 3.5) se execută la finalul programului, după ce s-a executat programul și a trecut și prin cazul de “exit” (care a făcut oprirea tuturor buclelor repetitive) din program. În această etapă a programului stiva creată în etapa de inițializare este rămasă cu elementele ce s-au folosit pe parcursul programului prin procesul de producer-consumer și trebuie eliberată. Așadar se face eliberarea stivei, iar al doilea lucru ce mai este făcut în această etapă reprezintă închiderea propriu-zisă a panoului frontal (și implicit a programului). Aceasta se face printr-un nod de proprietăți cu proprietatea selectată de a închide panoul frontal și prin referință la VI-ul curent se auto-închide.

3.5.5 Blocul de automatizare

Blocul de automatizare (fig. 3.6) este parțial independent de celelalte blocuri ale programului, singura dependință fiind în cazul de execuție “exit” în care este oprită și bucla blocului.

Construcția blocului se face pe arhitectura producer-consumer (3.4.3) folosindu-se de stivă pentru a o încărca cu controalele panoului frontal. Referințele către toate controalele de pe panoul frontal se construiesc cu ajutorul subVI-ului “Get reference to all controls.vi” cu icoana din figura 3.52:

Fig. 3.52 Get reference to all controls.vi

Acesta ia referințele controalelor și le pune într-un tablou de două dimensiuni (una cu referința controlului și cealaltă cu numele controlului). În stivă se încarcă prin secvență (fig. 4.2) numele controlului de controlat cu valoarea acestuia, iar atunci când numele controlului din secvență este egal cu vreun element din tabloul format și parcurs element cu element, blocul atribuie controlului valoarea din secvență sau ia valoarea curentă a elementului și o atribuie variabilei definite în secvență. Atriburea din variabila din secvență se face în cazul de “set” și atribuirea către variabila din secvență se face în cazul de “get”. Cazurile sunt ilustrate în figura 3.53:

Fig. 3.53 Cazurile de “set”și “get”

Capitolul 4

Platforma uTAS și secvența de test

4.1 Platforma uTAS

uTAS (united Test Automated Sequence) este o platformă de testare dezvoltată în mediul LabVIEW în cadrul companiei Continental Automotive care înglobează mai multe metode de testare:

Testare pe bază de module (structură modulară);

Testare pe bază de secvențe de test (structură secvențială);

În primul sens s-a dezvoltat modulul (programul) realizat, care duce la îndeplinirea unei nevoi de testare și anume în testarea funcționalității meniului și setarea de opțiuni din meniu. În testarea altor funcționalități ale clusterului se pot dezvolta alte module dedicate funcționalităților respective.

În al doilea sens, uTAS dispune de comenzi (una dintre ele prezentată în figura 5.46) pe baza cărora se apelează și modulele și anumite funcționalități din ele, dar mai ales pe baza cărora se creează secvențe de test.

4.2 Secvența de test

Secvențele de test sunt alcătuite din cazuri de test pentru testarea diferitelor funcționalități ale clusterului. Acestea sunt dezvoltate în Microsoft Excel după modelul din figura 4.1 unde este ilustrat capul de tabel al secvenței.Acesta este compus din mai multe câmpuri, fiecare definind un parametru al secvenței:

State- în care se definește starea cazului de test astfel că dacă acesta este “Enable” atunci cazul de test se va executa iar dacă acesta este “Skip” cazul respectiv de test nu se va executa;

Unique ID- reprezintă identificatorul cazului de test;

Case name- reprezintă câmpul în care se scriu titlurile cazurilor de test;

Step Conditions- este câmpul unde se scriu condițiile de test în care să se execute o anumită comandă de uTAS;

Command – reprezintă câmpul în care se scriu comenzile de executat;

Parameters- este câmpul în care se scriu parametrii de care are nevoie comanda pentru a fi executată;

Fig. 4.1 Capul de tabel al secvenței de test

Condițiile de execuție a comenzilor se definesc cu ajutorul comenzii “define_condition” iar la finalul execuției lor, aceste condiții trebuie șters din tebelul în care se găsesc toate condițiile definite prin comanda “undefine_condition”. Condiția mereu activă, care este definită în mod implicit este condiția “all”.

În cadrul comenzilor, platforma uTAS dispune de comenzi definite, ca și oricare limbaj de programare, cum ar fi:

Comenzi de definire condiții: “define_condition”, “if_define_condition”, “undefine_condition”, “if_undefine_condition”,etc;

Comenzi de salt: “jump”, “jump_if”, etc

Comenzi de creare bucle: “label”,etc;

Comenzi de control: “call_panel”, ”close_panels”, ”call_macro”, “call_application”, “set_panel_var”, “get_panel_var”, etc;

Comenzi de informare utilizator: “warn_tester”, “__dbgprint”,”ask_tester”, “ask_tester_input”, etc;

Cele mai uzuale comenzi sunt prezentate în Anexa 1.

În cadrul programului realizat, s-a creat o secvență de test automată prezentată în figura 4.2:

Fig. 4.2 Secvența de test automată

Această secvență reprezintă defapt o buclă din secvența principală ce se apelează atunci când este definită condiția “auto_sim”. Această condiție este definită înafara secvenței, într-un fișier de configurare care este apelat prin comanda “call_macro”. Așadar, atunci când este definită condiția “auto_sim”, aceasta definește condiția “sim” care execută comenzile de mai sus iar la finalul execuției șterge condiția “sim” iar bucla se repetă pentru eventuale repetări ale secvenței automate.

Secvența realizată comandă programatic modulul și controalele din modulul realizat, astfel că la începutul secvenței se deschide automat modulul prin comanda “call_panel” după care se realizează controlul fiecărui control după dorința programatorului de secvență.

Comanda “call_panel” are ca parametrii o variabilă la care i se atribuie numele modulului, parametrii de intrare ai modulului și felul în care se face execuția modulului cu secvența (0-asincron, 1-sincron).

După deschiderea modulului, se face comandarea controalelor din modul cu ajutorul comenzilor: “set_panel_var” și “get_panel_var”cu sintaxa din figura 4.3:

Fig. 4.3 “set_panel_var” și “get_panel_var”

, în care primul parametru reprezintă numele blocului de automatizare din modul (fig 3.6), al doilea reprezintă numele controlului comandat iar al treilea reprezintă valoarea ce se atribuie controlului respectiv. Aceste două comenzi se pot utiliza doar în prezența blocului de automatizare din modul. Aceste comenzi controlează variabilele din modul și cu ajutorul lor se face execuția cazului “set” sau “get” din blocul de automatizare din modul (fig. 3.53).

La fiecare pas de execuție, utilizatorul este informat cu privire la ceea ce programul va face la următorul pas pentru ca acesta să știe la ce să fie atent, ca să vadă dacă programul execută corect comenzile descrise și clusterul acționează în consecință.

Între comenzi și pași de execuție este setată câte o întârziere aleasă în funcție de timpul care trebuie așteptat ca să se execute comanda anterioară împreună cu acțiunea clusterului, înainte ca secvența să treacă la execuția comenzii următoare.

Capitolul 5

Utilizarea programului

Programul are o utilizare simplă și intuitivă oricărui utilizator. Fiind neîncărcat de butoane și informații, acesta are un aspect aerisit. Informarea utilizatorului se face prin mesaje scurte și simple. Programul nu permite utilizatorului să greșească, să introducă mai multe informații simultan (aceasta putând provoca supraîncărcarea sau blocarea execuției programului) deoarece butoanele sunt făcute inaccesibile utilizatorului după lansarea unei comenzi până la finalul execuției acesteia. Deasemenea utilizatorul este informat de acest lucru.

Cu privire la starea simulării, atunci când aceasta este pornită, butonul de “Start” al simulării este făcut inaccesibil (ca în figura 5.1), utilizatorul neputând lansa comanda de start simulare devreme ce aceasta este deja pornită.

Fig. 5.1 Start Modul

La fel este și în cazul butonului de “Stop” al simulării (fig. 5.2).

Fig. 5.2Setare opțiune

Acesta este făcut indisponibil în momentul în care este lansată comanda de stop simulare și devine disponibil doar atunci când este acționat butonul de “Start” al simulării. Deci, nu se poate comanda acțiunea de stop a simulării atâta timp cât aceasta nu este pornită.

Privitor la utilizarea butoanelor de control meniu, odată ce oricare dintre ele este acționat, butonul acela va fi indisponibil pentru o foarte scurtă perioadă de timp (aproape inperceptibilă utilizatorului) până se va executa comanda din spatele butonului respectiv și acțiunea precedentă comenzii. La finalul execuției, butonul va fi din nou disponibil utilizatorului (fig. 5.3). Astfel, după acționarea unui buton, doar butonul respectiv va fi făcut indisponibil și apoi înapoi disponibil utilizatorului (acțiuni ce se petrec în maxim o jumătate de secundă), celalalte butoane nefiind afectate, deci comportamentul nu este asemănător ca și în cazul pornirii sau opririi simulării pentru că nici impactul nu este la fel.

Fig. 5.3 Posibilități de acționare a meniului

În momentul pornirii și a opririi simulării panoul frontal devine ca în figura 5.4:

Fig. 5.4 Start/Stop Simulare

Capitolul 6

Concluzii

Programul realizat are aplicație practică în testarea instrumentelor de bord ale automobilelor. Acesta este un modul de testare care împreună cu alte module asemănătoare pot constitui un instrument puternic de testare. Modulul realizat este dedicat testării funcționalităților meniului instrumentelor de bord, cu particularitate în reglajul luminozității instrumentului. Datorită dublei funcționări a modulului, cu ajutorul acestuia se pot seta (activa) anumite funcționalități ale instrumentului de bord și în lipsa unei simulări de CANoe sau a altui instrument mai greu accesibil. Programul creat folosește pentru setarea semnalelor la pornire o simulare CANoe dedicată, însă la fel de bine acesta poate funcționa și în lipsa acesteia (timpii de execuție sunt mult mai buni în lipsa simulării de CANoe).

Programul îmbină mai multe procedee de programare care sunt folosite în combinație astfel încât funcționarea lui să fie sigură și cea dorită. Datorită utilizării platformei LabVIEW și a programării grafice programul se poate depana foarte repede și ușor, deasemenea se pot adăuga elemente noi și opțiuni noi de testare.

Modulul are o utilizare simplă și “prietenoasă” cu utilizatorul, interfața cu utilizatorul fiind intuitivă și aerisită. Deasemenea modulul este protejat împotriva greșelilor utilizatorului sau a supraîncărcării programului prin verificare de stări ale simulării, prin noduri de proprietate (prin care butoanele sunt setate indisponibile utilizatorului imediat după utilizare), prin mesaje de informare către utilizator, etc. Tratarea erorilor se face simplu, prin transmiterea acestora către indicatoarele de eroare, utilizatorul neavând acces la acestea, însă fiind de folos programatorului în momentul apariției vreunei erori și a depanării programului.

Datorită adaptării modulului pentru lucrul cu secvențe de test, acesta poate fi oricând comandat de către o secvență dedicată. În scopul acesta s-a creat secvența de automatizare dedicată modulului și prezentată în lucrare, pentru a demonstra faptul că utilizarea modulului se poate face din mai multe părți și inclusiv automat.

În concluzie, modulul poate fi comandat manual în prezența unei simulări de CANoe, pe care acesta o controlează în funcție de comenzile lansate, sau în absența simulării dedicate, prin trimitere directă pe CAN de mesaje de comandă către cluster. Deasemenea modulul poate fi comandat prin intermediul blocului de automatizare implementat în acesta cu ajutorul secvenței de test automate. Astfel, în funcție de cerințele utilizatorului, acesta poate opta pentru o testare manuală a funcționalităților instrumentului de bord sau pentru o testare automată (cu control automat al modulului).

Programul aduce îmbunătățiri în procesul de testare a instrumentelor de bord tocmai prin modalitățile lui de utilizare (testare manuală sau automată), prin modalitățile lui de comandă a instrumentului de bord (prin intermediul simulării de CANoe sau prin transmiterea de mesaje directe pe CAN), prin structura sa modulară (poate fi extins în funcție de necesități și poate fi folosit în combinație cu alte module pentru testarea altor opțiuni ale instrumentului de bord), etc.

BIBLIOGRAFIE

Mathur Aditya P.; “Foundations of Software Testing: Fundamental Algorithms and Techniques”; Editura Pearson Education, 2008;

Copeland Lee; “A Practitioner’s guide to Software Test Design”; Editura Artech House, 2004;

Farrel-Vinay Peter; “Manage Software Testing”; Editura Auerbach, 2008;

Navet Nicolas; “Automotive Embedded Systems Handbook”; Editura CRC Press, 2009;

Lawrenz Wolfhard; “CAN System Engineering: From Theory to Practical Applications”; Editura Springer, 1997;

Andrew Oram; “Making Software: What Really Works, and Why We Believe It”; Editura O’Reilly, 2011;

Braess Hans-Hermann; “Handbook of Automotive Engineering”; Editura SAE International, 2005;

National Instruments; “LabVIEW Intermediate I – Successful Development Practices”, 2004;

National Instruments; “TestStand I- Introduction Course Manual”, 2004;

National Instruments; “LabVIEW Core 2 Course Manual”, 2010;

National Instruments; “LabVIEW Basics I Course Manual”, 2000;

National Instruments; “LabVIEW Basics II Course Manual”, 2000;

National Instruments; “LabVIEW Tutorial Manual”

Ababei Ștefan, Pavel Daniel;“Achiziția și prelucrarea datelor” ; Editura Alma Mater-Bacău 2012;

Șorândaru Ciprian; “ Instrumentație virtuală în ingineria electrică”; Editura Orizonturi Universitare, Timișoara, 2003;

Travis Jeffrey, Kring Jim; “LabVIEW for Everyone: Graphical Programming Made Easy and Fun, Third Edition”; Publisher: Prentice Hall, 2006;

www.ni.com

http://en.wikipedia.org/wiki/CANoe;

http://en.wikipedia.org/wiki/CAN_bus;

National Instruments; “National Instruments Tutorial – Application Design Patterns : Master/Slave – Dec 13, 2006 – NI-Tutorial-3022-en.pdf” ;

National Instruments; “National Instruments Tutorial – Application Design Patterns : Producer/Consumer , 2012 – NI-Tutorial-3023-en.pdf”;

Analog Guide – Controller Area Network (CAN) Implementation Guide by Dr.Conal Watterson – http://www.analog.com/static/imported-files/application_notes/AN-1123.pdf;

Texas Instruments; “Introduction to the Controller Are Network (CAN) – 2008 – http://www.ti.com/lit/an/sloa101a/sloa101a.pdf” ;

Mihai Bebeșelea Sterp; “Lucrare de Disertație- Modul Interactiv pentru testarea clusterelor folosind Mediul LabVIEW”, 2014;

Rick Bitter, Taqi Mohiuddin, Matt Nawrocki; “LabVIEW- Advanced Porgramming Techniques”; Editura: CRC Press, 2001;

Rick Bitter, Taqi Mohiuddin, Matt Nawrocki; “LabVIEW- Advanced Porgramming Techniques- Second Edition”; Editura: CRC Press, 2007;

Sunya Marinel; “Proiect de Diplomă- Program Pentru Studiul Experimental al MAS în Regim Tranzitoriu Folosind Instrumentația Virtuală”, 2014;

Jon Conway, Steve Watts; “A Software Engineering Approach to LabVIEW”, 2004;

D. Zmaranda, Algoritmi și tehnici de programare – curs, Editura Universitǎții Oradea, 2001, ISBN 973-613-062-2 ;

D. Zmaranda, M.Bonaciu, Algoritmi și tehnici de programare – îndrumǎtor de laborator, partea I, Editura Universitǎții Oradea, 2003, ISBN 973-613-302-8

ANEXE

Anexa 1

O mică parte din comenzile disponibile în platformauTAS folosite și în programul și secvența realizată: