Realizarea Unui Program de Comunicatie pe Interfata Can Prin Protocolul J1939, Folosind Dispozitivul Ni Pci 6602

Cuprins

Capitolul 1

Introducere

1.1. Scopul și obiectivele lucrării

1.2. Generalități

Capitolul 2

Mediul LabVIEW

2.1. Introducere în mediul LabVIEW

2.2. Controlul instrumentelor de măsură

2.3. Managementul proiectelor mari în LabVIEW

Capitolul 3

Interfața CAN

3.1. Introducere

3.2. Structura mesajelor

3.3. Managementul erorilor

3.4. Standardul SAE J1939

3.5. Transmiterea mesajelor

Capitolul 4

Receptia si prelucrarea mesajelor CAN

4.1. Panoul frontal a functiei de receptie si prelucrare a mesajelor

4.2. Diagrama bloc a functiei de receptie si prelucrare a mesajelor

Capitolul 5

Transmisia mesajelor CAN

5.1. Panoul frontal al functiei de transmisie a mesajelor CAN

5.2. Diagrama bloc de transmisie a mesajelor ciclice

5.3. Diagrama bloc de transmisie a sirului de mesaje CAN

Capitolul 6

Stocarea mesajelor CAN in fisiere de tip text

6.1. Panoul frontal al functiei de stocare a datelor

6.2. Diagrama bloc a functiei de stocare a datelor

Capitolul 7

Concluzii

7.1. Concluzii generale

7.2. Contribuțiile personale

Capitolul 1

Introducere

_____________________________________________________________________________

1.1. Scopul și obiectivele lucrării

1.2. Generalități

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

1.1. Scopul și obiectivele lucrării

Scopul prezentei lucrări îl reprezintă realizarea unui program de comunicatie pe interfața CAN prin protocolul J1939, folosind dispozitivul NI PCI-6602.

Lucrarea de față are ca și aplicație principală monitorizarea comunicației pe magistrala CAN. Mărimile de intrare (datele achiziționate) sunt mesajele recepționate, acestea fiind prelucrate pentru a putea fi afișate în formatul standard. Aceste mesaje pot fi stocate local într-un fișier de date.

Obiectivele lucrării sunt următoarele:

realizarea unui program de receptie a mesajelor CAN;

realizarea unor programe de transmisie a mesajelor CAN;

realizarea unui program de prelucrare și salvare a datelor într-un fișier.

realizarea unui program de monitorizare în timp real a mesajelor vehiculate pe interfața CAN.

Toate aceste programe menționate mai sus vor fi realizate folosind mediul de dezvoltare LabVIEW de la National Instruments.

1.2. Generalități

Monitorizarea datelor poate fi privită ca o activitate experimentală de tip informatic al cărui scop este obținerea unor informații cu privire la proprietățile unui obiect sau sistem și redarea lor într-o formă potrivită pentru observator. Procesul se realizează pe baza unei metode de prelucrare conform standardului J1939 folosind mijloace special destinate acestui scop.

În contextul dezvoltării actuale a electronicii, majoritatea ramurilor producției industriale sunt influențate de doi factori dinamizatori: adoptarea de noi tehnologii și organizarea fabricației în jurul unităților flexibile, automatizate.

Creșterea complexității autoturismelor, a impus adoptarea și folosirea unor standarde care sunt respectate de majoritatea producătorilor. Astfel a luat naștere și standardul J1939 referitor la rețeaua CAN [4].

Verificarea funcționării corecte a unui ECU (nod) dintr-un autovehicul reprezintă un proces de o complexitate ridicată datorită numărului foarte mare de variabile și situații posibile ce trebuie avute în vedere pentru o testare adecvată, atât pe termen scurt cât și pe o perioadă mai lungă.

Scopul prezentei lucrări este acela de a oferi o posibilitate de monitorizare în timp real a comunicației pe magistrala CAN și de verificare, în cazul transmiterii de mesaje, a reacției diferitelor ECU-uri, în funcție de comanda sau informația primită.

Capitolul 2

Conceptul de testare software

____________________________________________________________________________

2.1. Principii de testare

2.2. Nivele de testare

2.3. Modalitati de execuție a testelor

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Testarea este procesul condus în timpul dezvoltării unui produs pentru a obține informații calitative referitoare la produsul dezvoltat. Procesul de testare în domeniul IT , deși folosit de la începuturile dezvoltării software, realizat de către dezvoltatori, a început să capete nuanța în perspectiva creșterii complexității aplicațiilor dezvoltate, și a necesitații creșterii calitativi produselor prezente pe piața.

Testarea software realizează procesul de verificare a corectitudinii funcționarii produs software prin furnizarea de date de intrare și analiza datelor de ieșire comparativ cu funcționarea dorită.

Scopul testării software-ului este de a detecta erori ale acestuia, permițându-se astfel remedierea acestora. Analiza funcționarii unui sistem, prin metode exhaustive este nefezabila rezultând astfel că , testarea nu poate garanta funcționarea software-ului dezvoltat decât pentru anumite condiții specifice.

Procesul de verificare și validare a unui produs prezintă una din problemele fundamentale cu care se confruntă testarea, imposibilitatea de a analiza toate cazurile posibile în funcționare. Implementarea unui bloc decizional ar necesita pentru procesul de testare două variante posibile, iar prin intercalarea acestor blocuri numărul de cazuri rezultate crește aproape exponențial cu numărul de blocuri decizionale intercalate. Aceasta înseamnă că numărul de erori într-un software poate fi foarte mare și defectele care apar rar, sunt greu de găsit la testare.

Conducerea activităților de testare a unui sistem software necesită o atentă planificare și analiză a aspectelor funcționale și nefuncționale ale produsului rezultat. Pentru asigurarea calității testării apriori testării efective sunt necesare crearea unui plan de testare și eventual a unei strategii de testare conforme cu cerințele de funcționare impuse programului.

Un plan de testare documentează strategia care va fi utilizată pentru a verifica și a se asigura că un produs sau un sistem îndeplinește specificațiile de proiectare și alte cerințe. Un plan de testare este, de obicei, pregătit de către sau cu o contribuție semnificativă de la inginerii de test.

Conceptul de sStrategie de testare este utilizat de obicei în companii ce dezvoltă produse software de dimensiuni mari. O strategie de testare este un plan care descrie obiectivul și porțiunea testare a ciclului de dezvoltare software. Acesta este creat pentru a informa managerii de proiect, testerii si, iar dezvoltatorii despre unele aspecte cheie ale procesului de testare. Aceasta include obiectivul de testare, metodele de testare a unor funcții noi, timpul total și resursele necesare pentru proiect, precum mediul de testare.

Procesul de testare nu se rezumă la descoperirea erorilor ci se continuă prin sistematizarea acestora pentru oferirea informaților necesare remedierii acestora.

2.1 Principii de testare

Metodele consacrate de testare se separă în următoarele categorii [www3] :

Metoda „Black Box”

Metoda „White Box”

Metoda „Grey Box”

Metoda “Black box” tratează testarea software-ului ca o "cutie neagră", fără nici o cunoștință despre implementarea internă. Această metodă permite testarea unei funcționalități în funcție de cerințele aplicabile. Sarcina tester-ului este de a introduce datele de intrare și de a observa datele de ieșire. Acest nivel de testare de obicei necesită furnizarea de cazuri de testare tester-ului, care apoi, verifică faptul că pentru o anumită intrare, valoarea de ieșire (saău comportament), fie "este" sau "nu este" identică cu valoarea așteptată specificată în cazul de testare. În cazul acestei metode de testare tester-ul nu are nici o tangență cu codul software-ului, iar percepția acestuia este simplă – un cod trebuie să aibă erori. Folosind principiul, "Cereți și veți primi," cei care se ocupă cu testarea descoperă defecte în locul în care programatorii nu găsesc. Dar, pe de altă parte, metoda a fost declarată a fi "ca o plimbare într-un labirint pe întuneric, fără o lanternă," pentru că tester-ul nu știe modul în care software-ul a fost construit. De aceea, există două situații: când sunt scrise multe cazuri de test pentru a verifica ceva care poate fi testat de un singur studiu de caz, și / sau când unele părți nu sunt testate deloc.

Metoda “cutie-albă” , în contrast cu “Black box” care este o metodă funcțională, este o metodă structurală, în cadrul căreia tester-ul are acces la structura internă a codului. Principalul scop al acesteia este mărirea performanței aplicației și a lizibilității codului prin eliminarea problemelor de genul zone de date comune, bucle complicate, număr mare de linii de cod.

Metoda “cutie gri” (Grey-box) este de fapt o combinație a metodelor “White box” și “Black box” prezentate anterior, mai exact, presupune acces la structura internă a software-ului în scopul de a concepe cazuri de testare cât mai complexe, însă testarea propriu-zisă se face la nivel de utilizator (nivel “Black box”).

2.2 Nivele de testare

In procesul de testare pot fi identificate mai multe nivele de testare precum testare modulară, teste de integrare, teste de sistem, teste de acceptanțtăa.

Testarea modularăa implică cercetarea funcționalității corecte a diverselor module software ce urmează a fi integrate in produsul software final. Testarea modularăa este realizatăa de obicei de către echipa de dezvoltatori , fiind responsabilitatea acestora de a se asigura că a subsistemul ce urmează a fi integrat este funcțional.

Testele de integrare verificăa compatibilitatea intrărilor si a ieșirilor unui modul ce urmează a fi integrat in sistemul software cu mărimile interne ale sistemului ce ii vor fi transmise, respectiv sunt așteptate a fi recepționate.

Testarea sistemului este realizată după efectuarea testelor de modul, respectiv de integrare si are rolul de a analiza funcționarea programului ca sistem de sine statator. In acest stadiu al testării poate fi evaluata de asemenea si calitatea produsului rezultat fiind partea procesului de testare ce poate investiga comportarea de facto a sistemului comparativ cu cerințele impuse acestuia.

2.3 Modalități de execuție a testelor

Testele de acceptanțtă testele efectuate de client t și reprezintă validarea finală a produsului dezvoltat.

Domeniul tehnic al testării software poate fi divizat în 2 categorii, după modul de execuție a testelor, testare manuală și testare automată.

2.3.1 Testare manuală

Testarea manuală este cel mai la îndemână procedeu de utilizat în cazul în care se dorește verificarea și validarea unui program. Pentru a putea aplica teste manuale singurele precondiții necesare îndeplinirii sarcinii sunt cunoașterea cerințelor legate de software-ul testat și eventual un tool specializat pentru a putea transmite și recepționa informații de programul testat. Din acest motiv testarea mauala a fost și încă mai este în unele subdomenii ale testării software principala unealtă în validarea unui produs. Testarea manuală poate fi folosită cu relativ succes în cazul aplicatiiilor de dimensiune redusă și pentru testele de „explorare”. În cazul aplicațiilor la scară largă utilizarea testării manuale implică respectarea unei metodologii meticuloase, pentru a se putea asigura calitatea testării, ce implică realizarea unui plan de testare detaliat, calculul resurselor necesare, și a timpului necesar a fi alocat.

2.3.1 Testare automată

Testarea automată reprezintă utilizarea de programe specilizate pentru a controla executarea de teste capabile să realizeze comparația dintre rezultatele obținute și rezultatele așteptate. Principalul avantaj al abordării testelor automate îl reprezintă repetabilitatea testelor, precum și a vitezei mai mari de execuție a acestora datorită utilizării puterii de calcul a computerelor. Frecvent, automatizarea testării implică automatizarea un proces manual deja în vigoare, care utilizează un proces de testare formalizate. Utilizarea testării automate în testarea programelor în timp real se impune ca o necesitate datorită falidarea unui produs. Testarea manuală poate fi folosită cu relativ succes în cazul aplicatiiilor de dimensiune redusă și pentru testele de „explorare”. În cazul aplicațiilor la scară largă utilizarea testării manuale implică respectarea unei metodologii meticuloase, pentru a se putea asigura calitatea testării, ce implică realizarea unui plan de testare detaliat, calculul resurselor necesare, și a timpului necesar a fi alocat.

2.3.1 Testare automată

Testarea automată reprezintă utilizarea de programe specilizate pentru a controla executarea de teste capabile să realizeze comparația dintre rezultatele obținute și rezultatele așteptate. Principalul avantaj al abordării testelor automate îl reprezintă repetabilitatea testelor, precum și a vitezei mai mari de execuție a acestora datorită utilizării puterii de calcul a computerelor. Frecvent, automatizarea testării implică automatizarea un proces manual deja în vigoare, care utilizează un proces de testare formalizate. Utilizarea testării automate în testarea programelor în timp real se impune ca o necesitate datorită frecvenței ridicate de prelucrare a datelor și constrângerilor de timp.

Testarea automată este tehnica de testare a programelor utilizând programe, mai degrabă decât de oameni. Un program de testare este scris pentru a testa programul software. Programele de testare pot fi scrise de la zero, sau pot fi scrise folosind un cadru generic de testare automatizată care poate fi achiziționat de la un furnizor terț. Testarea automată poate fi folosită pentru a automatiza sarcini repetitive și consumatoare de timp, precum aceea de a urma pașii unui caz de utilizare și raportarea rezultatelor.

Testarea automată poate reduce sau elimina costurile de testare reale. Un computer poate urma o secvență de pași predefinițti mai repede decât o persoană, și poate rula teste peste noapte testele, prezentând rezultatele a doua zi. Partea negativă a testării automate o reprezintă înlocuirea costurilor efective de testare cu costurile de dezvoltare a testelor automate precum și a interpretării rezultatelor. Din punct de vedere cost-beneficiu, testarea automată devine rentabilă în cazul în care aceleași teste pot fi refolosite, cum ar fi pentru testele de regresie, și atunci când rezultatele pot fi interpretate rapid. În cazul în care reutilizarea viitoare ale software-ului de testare este puțin probabilă, atunci o abordare manuală este preferabilă.

Capitolul 3

Mediul LabVIEW

____________________________________________________________________________

3.1. Introducere în mediul LabVIEW

3.2. Controlul instrumentelor de măsură

3.3. Managementul proiectelor mari în LabVIEW

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

3.1. Introducere în mediul LabVIEW

Limbajul LabVIEW (Laboratory Virtual Instrument Engineering Workbench) [6] a apărut în anul 1994 și este în prezent unul dintre cele mai puternice medii de programare grafică. LabVIEW este utilizat pentru achiziția semnalelor, analiza măsurărilor și prezentarea datelor, oferind flexibilitatea limbajelor de programare tradiționale și în același timp o interfață utilizator prietenoasă.

Caracteristica principală a programului LabVIEW este aceea că utilizează, pentru dezvoltarea aplicațiilor, simboluri intuitive de panouri frontale și scheme bloc. Utilizatorul dezvoltă aplicația soft prin construcția ierarhizată de instrumente virtuale (VI-uri). Un instrument virtual este un pachet de programe grafice care arată și acționează ca un instrument.

Panoul frontal (cu butoane, comutatoare, cadrane de instrumente) înfățișează intrările, ieșirile și constituie interfața uzuală pentru operații interactive. În spatele panoului este o diagramă-bloc, care reprezintă programul executabil.

LabVIEW este un sistem ierarhizat, datorită faptului că un instrument virtual poate fi reprezentat sub formă de simbol grafic și utilizat în schema bloc la construcția unui alt instrument virtual.

3.2. Controlul instrumentelor de măsură

LabVIEW oferă o interfațare facilă cu orice hardware de măsurare. Astfel se pot achiziționa semnale de la o varietate de echipamente. Datorită posibilității de comunicare cu toate dispozitivele de măsurare, folosind mediul LabVIEW se pot crea noi aplicații fără a se pierde investiția hardware existentă.

Se pot achiziționa date de la instrumente GPIB, seriale, Ethernet, PXI și VXI, folosind driverele incluse. Există posibilitatea comunicării cu mii de instrumente aparținând a sute de producători, folosind driverele de comunicație LabVIEW. Programul oferă performanță și portabilitate ridicate.

Driverele de comunicație simplifică controlul instrumentelor și timpul de dezvolatare a noi aplicații, eliminând necesitatea de a învăța protocoale de programare pentru fiecare instrument în parte. Multe drivere folosesc Visual Instrument Software Architecture (VISA) pentru a comunica cu o gamă de magistrale de comunicație, cum ar fi GPIB sau serial, folosind același cod LabVIEW. Indiferent pe ce tip de magistrală este instrumentul, driverele VISA preiau controlul protocoalelor de comunicație respective.

Controlul instrumentelor fizice cu LabVIEW este proiectat cu simboluri grafice de blocuri, ce pot fi combinate pe ecran, pentru a construi soft-ul unui instrument virtual (VI). Cu LabVIEW, controlul instrumentelor automate este la fel de simplu și intuitiv ca și manevrarea panourilor instrumentelor fizice.

VI-ul are în componență module reutilizabile, ale căror panouri frontale pot fi intuitiv utilizate. În plus, fiecare VI poate fi introdus într-o simplă formă grafică (icon) și combinată grafic cu un alt icon, pentru a construi un VI de nivel superior.

3.3. Managementul proiectelor mari în LabVIEW

Pe lângă cele menționate mai sus, LabVIEW oferă și posibilitatea comunicării cu alte medii de programare (MATLAB, Simulink, Mathcad). Astfel, problemele complexe se pot rezolva mai ușor într-o manieră elegantă.

Problemele ce apar în proiectele mari [2], realizate în LabVIEW, se abordează în principiu din două perspective:

din perspectiva de sus în jos (top-down), în care se definesc caracteristicile generale și specificațiile proiectului;

din perspectiva de jos în sus (bottom-up), în care se trece la realizarea subinstrumentelor virtuale și ulterior la asamblarea acestora în vederea obținerii proiectului complet.

Modularizarea permite realizarea, testarea și combinarea ulterioară a subinstrumentelor virtuale. Astfel, eventualele erori se pot identifica încă din faza de început a proiectării.

Un alt avantaj al utilizării subinstrumentelor virtuale este faptul că viitoarele îmbunătățiri sau modificări ale programului vor fi mai ușor de realizat. Prin urmare, modificările și adăugirile ulterioare nu necesită modificarea întregului program.

Capitolul 4

Interfața CAN

_____________________________________________________________________________

4.1. Introducere

4.2. Structura mesajelor

4.3. Managementul erorilor

4.4. Standardul J1939

4.5. Transmiterea mesajelor

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

4.1. Introducere

Bosch a dezvoltat Controller Area Network (CAN) ca magistrală pentru dispozitivele electronice aflate în interiorul autovehiculelor. Înainte de apariția rețelei CAN producătorii de autovehicule foloseau conexiuni „point-to-point” pentru a interconecta componentele electronice aflate în interiorul unui autovehicul. Rețeaua CAN prezintă o serie de avantaje cum ar fi costul redus, o structură mai ușoară și ușurință în configurare. Magistrala CAN a fost adoptată foarte repede de producătorii de autovehicule, iar în anul 1993 devenind standard internațional prin ISO 11898. CAN-ul dispune de mai multe straturi fizice ce pot fi utilizate pentru constuirea rețelei. Aceste straturi fizice clasifică anumite aspecte ale rețelei de CAN, cum ar fi nivelurile, sistemele de semnalizare, impedanțele prin cablu, ratele baud maxime.

În figură este prezentată schema electrică generală de conectare a dispozitivelor electronice la rețeaua CAN. Terminalele au rolul de a suprima reflexia semnalului CAN. Mgistrala CAN este compusă din 2 fire notate CAN_H(High) și CAN_L(Low) după nivelul de tensiune față de masă. În cazul în care driverele de magistrală ale tuturor nodurilor din rețea sunt oprite, nivelul de tensiune pe magistrală este dat de terminale și rezistențele interne ale receptoarelor de semnal conectate la rețeaua CAN [4].

Figura 4.1.1 Schema electrică generală a unei rețele CAN

Din punct de vedere electric transmiterea biților se realizează prin utilizarea a 2 niveluri de tensiune. În funcție de nivelul de tensiune, semnalele electrice transmise pe magistrală se împart în semnale dominante și semnale recesive. Deoarece rețeaua CAN nu dispune de un circuit specializat care să supervizeze transmiterea mesajelor pe magistrală, teoretic 2 noduri ar putea porni simultan transmisia unui mesaj. Arbitrarea se realizează prin stabilirea priorității mesajelor, astfel primul nod care tranmite un semnal dominant în timp ce pe magistrală se află un semnal recesiv este considerat ca nod prioritar și își va continua transmisia în timp ce nodul ce a transmis semnalul recesiv va înceta transmisia.

Figura 4.1.2 Reprezentarea fizică a biților pe magistrala CAN

4.2. Structura mesajelor

Magistrala CAN nu dispune de o metodă de a selecta noduri din rețea pentru transmisia sau recepția informației. Fiecare nod prezent în rețea recepționează orice mesaj prezent pe magistrală și decide intern dacă acest mesaj i se adresează sau nu. Transmiterea informației se face prin mesaje cu o lungime maximă limitată. Când magistrala se află repaus (nici un mesaj nu este transmis) orice nod poate începe o nouă transmisie de date. Accesul la magistrală a două sau mai multe noduri simultan se soluționează prin implementarea sistemului de priorități. Orice tip de mesaj transmis pe magistrală are alocat un identificator. Acest identificator stabilește prioritatea mesajului în comparație cu mesajele concurente prezente în rețea. Prioritatea este dată de numărul de biți dominanți prezenți în identificator (biți setați pe valoarea 0). Practic identificatorul cu valoare mai mică va fi prioritar. Există 2 tipuri de identificatoare de mesaj in protocolul CAN, identificatorul standard de 11 biți și identificatorul extins de 29 de biți.

Figura 4.2.1 Format cadru CAN Standard

Figura 4.2.2 Format Cadru Extins

SOF (start-of-frame) bit: indică începerea transmisiei unui mesaj, fiind setat pe valoarea 0 (bit dominant)

Câmp Arbitrare: constă din identificatorul mesajului, indicând prioritatea mesajului. În cazul formatului cadru standard identificatorul mesajului este format din 11 biți, iar în cazul formatului cadru extins câmpul arbitrare conține 18 biți suplimentari numiți extensie de identificator.

: bit folosit în cazul formatului cadru CAN extins, înlocuind bitul RTR în cazul formatului cadru CAN standard.

RTR: bit indicator.

DLC (data length code): indică numărul de octeți de date transmis.

Data Field (câmp de date): conține între 0 și 8 biți de date.

Un mesaj complet are următorul format:

Figura 4.2.3 Structura unui mesaj complet

/IDLE – linia de date este în repaus.

SOF – indică începerea transmisiei unui mesaj.

ID – identificatorul mesajului (poate fi standard sau extins).

Control – conține o extensie a identificatorului, biți rezervați, DLC.

Data – conține între 0 și 8 biți de date.

– verificarea ciclică a redundanței.

– confirmarea faptului că mesajul a fost recepționat.

EOF – indică sfârșitul mesajului și este format din 7 biți recesivi.

– “spațiu” între mesaje, câmp format din 3 biți recesivi.

/IDLE – magistrala este pregătită pentru transmisia unui nou mesaj.

4.3. Managementul erorilor

In cadrul interfeței CAN au fost implementate diverse metode de detecție si prevenire a erorilor. Avariile care pot apărea într-o magistrală CAN pot fi clasificate în următoarele categorii:

Avarii globale – avarii care conduc la defecțtiuni majore ale sistemului de comunicație (scurtcircuite, întreruperi ale liniei, noduri care transmit permanent).

Avarii locale – se referă strict la defecțiunile unui nod sau defecțiunile unor componente dintr-un nod.

Avarii temporare – defecțiuni care afectează rețeaua o perioadă limitată de timp.

Avarii permanente – defecțiuni care afecteaza permanent rețeaua, acestea fiind ireversibile.

Erorile care apar în mesajele transmise pe magistrala CAN sunt:

Erori de bit – bitul recepționat este diferit de cel transmis.

Erori intercalare biți – detecția a mai mult de cinci biți cu polaritate egala. Intercalarea de biți este o tehnică utilizată in comunicațiile de date care constă în inserarea unor biți suplimentari în fluxul de biți de transmis. În mesajele transmise pe magistrala CAN această tehnica este folosită in cazul în care apare o secvența formată din mai mult de cinci biți cu aceeași polaritate. Scopul folosirii tehnicii de intercalare este de asemenea sincronizarea.

Erori – codul recepționat nu corespunde cu cel calculat.

Erori de confirmare – nodul care a făcut transmisia nu a recepționat bitul de confirmare (dominant) de la nodul destinație.

Erori de format – unul din câmpurile care alcătuiesc mesajul conține un număr diferit de biți față de numărul standard.

Mecanismul de control al erorilor este folosit pentru anularea mesajelor eronate de către nodurile din rețea și pentru a deconecta de la rețea anumite noduri, în cazul în care acestea detectează sau generează prea multe erori. Acest aspect este monitorizat cu ajutorul a două contoare, unul pentru erorile detectate la recepție, REC (receive error counter), și unul pentru erorile detectate la transmisie, (transmit error counter).

Un nod dintr-o rețea CAN poate funcționa în trei stări diferite. Starea activa este starea în care rețeaua generează câte un indicator activ pentru fiecare eroare detectată. Există și starea pasivă care se caracterizează prin faptul că este generat câte un indiccator pasiv pentru fiecare eroare descoperită. Ultima stare în care se poate afla o rețea CAN este cea în care unul din noduri este automat deconectat de la magistrală pentru ca au fost detectate prea multe erori.

Trecerea unui nod dintr-o stare în alta se face în funcție de valorile contoarelor REC și . Un nod se află în starea activă atât timp cât și contorul REC și contorul au valorile mai mici decât 127. Trecerea în starea pasivă se face când valoarea oricărui dintre cele două contoare (sau amândouă) depășește 127. Nodul este deconectat de la magistrală în cazul în care contorul are valoarea mai mare de 255. În această situație, pentru a reveni in starea activă trebuie făcută o reinițializare a rețelei, ambele contoare primind valoarea 0.

Fiecare nod care detectează o eroare (locală sau globală) trimite un indicator în rețea pentru a informa și celelalte noduri despre eroare (se poate spune că în acest fel eroarea devine globală). Indicatorul de eroare este format din 6 biți dominanți in cazul unui nod aflat în stare activă, sau 6 biți recesivi, dacă nodul este în stare pasivă.

Celelalte noduri pot interpreta acest indicator ca și o eroare, trimițând la rândul lor un indicator pe magistrală. După recepționarea sau transmiterea unui indicator de eroare, mesajul în cadrul căruia a fost detectată eroarea este ignorat. În acest moment, nodul care a transmis mesajul va mai încerca să îl transmită din nou.

Există câteva condiții speciale ale erorilor:

Bit dominant în câmpul EOF: când un nod detectează un bit dominant în câmpul EOF acesta va transmite un indicator de eroare către celelalte noduri.

Mesaj valid pentru transmițător: un mesaj este considerat valid de către nodul care face transmisia dacă nu apare nicio eroare pâna la sfârșitul câmpului EOF.

Mesaj valid pentru nodul receptor: un mesaj este considerat valid de către nodul care face recepția dacă nu apare nicio eroare pâna la penultimul bit al câmpului EOF.

Dublarea unui mesaj: această situație este întâlnită atunci când nodul care face transmisia consideră ultimul bit din EOF ca fiind dominant. În acest moment transmițătorul vede mesajul eronat, și îl va mai trimite încă odată, iar receptorul, care nu mai verifică ultimul bit din EOF, va primi de două ori acelasi mesaj, acesta fiind considerat corect de fiecare dată.

4.4 Standardul J1939

Standardul J1939, [3], este o rețea de comunicație de mare viteză concepută pentru a gestiona comunicația în timp real între ECU-uri (Electronic Control Units). A fost dezvoltat pornind de la modelul , (Open System Interconnect) publicat de ISO (International Organization for Standardization) în anul 1984, ce definește modelul arhitecturii de comunicație între mașini de calcul. Standardul definește arhitectura de comunicație ca fiind divizată în șapte straturi prezentate în imaginea de mai jos:

Figura 4.4.1 Modelul arhitecturii de comunicație

Stratul fizic – se referă la caracteristicile mecanice, electrice, funcționale și procedurale ale suportului fizic.

Stratul Legături de date – asigură transferul de informații în stratul fizic. Trimite blocuri de date care au ca scop sincronizarea, controlul erorilor și a fluxului.

Stratul rețea – face legătura între straturile superioare și transmiterea fizică a datelor. De asemenea, gestionează conexiunile.

Stratul transport – realizează transferul de date între punctele finale. Este responsabil și cu segmentarea respectiv reasamblarea mesajelor lungi.

Stratul sesiune – oferă structura de control pentru dialogul dintre aplicații.

Stratul prezentare

Stratul aplicație – oferă acces utilizatorilor la mediul .

În cadrul standardului J1939 mesajele sunt clasificate după numărul de octeți de date și după tipul de informație transmis într-un grup, denumit ParametruGrup. În definirea unui ParametruGrup nu se consideră adresa ECU-ului emițător sau destinatar astfel încât orice ECU din rețea este capabil să transmită un anumit ParametruGrup. Fiecărui ParametruGrup i se alocă un număr unic pentru a putea fi interpretat de ECU-ul destinatar, denumit ParametruGrupNumar (PGN). În prezent există cinci tipuri de mesaje suportate. Aceste tipuri sunt: Comenzi, Cereri, Emisiuni / Răspuns, recunoașterea și funcții Grup. Tipul de mesaj este recunoscut după PGN-ul alocat. Standardul J1939 precizează definirea unui identificator unic pentru fiecare mesaj, identificator ce specifică, NumarParametruGrup, emițătorul, destinatarul, prioritatea și tipul mesajului. Identificatorul de mesaj este format din 29 biți și este denumit “format cadru extins”, fiind poziționat la începutul mesajului înaintea biților de date. Formatul identificatorului extins este prezentat în imaginea de mai jos:

Figura 4.4.2 Formatul identificatorului extins

Identificatorul mesajului CAN este format din [4]:

3 biți pentru Prioritate, care ia valori în intervalul 0-7, 0 însemnând prioritatea cea mai mare.

1 bit pentru PaginaDateExtinsă, care este tot timpul setat pe valoarea zero.

8 biți pentru PDU (Protocol Data Unit) Format. Acest câmp poate fi, în funcție de formatul PDU, adresa unei destinații sau o extensie de grup. În cazul în care valoarea câmpului PDU format este mai mică de 240,domeniul specific este un PDU adresa de destinație. În cazul în care valoarea câmpului este cuprinsă între 240 și 255, domeniul specific PDU conține o extensie Grup.

8 biți pentru adresa sursă care reprezintă indentificatorul nodului care a transmis mesajul.

4.5. Transmiterea mesajelor

Există două metode de transmitere a mesajelor pe o magistrală de tip CAN. Prima se referă la mesajele care conțin maxim 8 octeți de date (câmpul Data) iar a doua pentru mesaje mai lungi de 8 octeți.

Transmiterea mesajelor a căror câmp de date este mai mare de 8 octeți, se face prin divizarea mesajului în mai multe mesaje format cadru și se poate realiza în 2 moduri în funcție de destinația mesajului. Astfel dacă PDU Specific desemnează identificatorul unui ECU conectat la rețeaua CAN, transmiterea mesajului se realizează printr-o conexiune de tipul „Request to Send”, iar în cazul în care mesajul nu are o destinație specifică, fiind un mesaj global, transmiterea acestuia este realizată printr-o conexiune de tip BAM (Broadcast Announce Message).

Conexiunea „Request to send” pentru transmiterea mesajelor multi-cadru este folosită pentru a transmite date unui ECU specific aflat în rețea. Mesajul transmis nu este global fiind destinat unui singur ECU desemnat de câmpul PDU specific din identificatorul mesajului. Inititerea unei conexiuni „Request to Send” se realizează prin transmiterea unui mesaj „cerere aprobare transmisie”, „TP.CM_RTS”, („TransportProtocol.ConexionMode_RequestToSend”) de către ECU-ul sursa către ECU-ul destinație.

ECU-ul destinație va transmite un mesaj „aprobare transmisie”, „TP.CM_” (ClearToSend), ECU-ului sursă prin care își anunța disponibilitatea recepționării mesajului multi-cadru. După transmiterea mesajului aprobare transmisie, ECU-ul sursă începe transmiterea mesajelor cadru CAN, al căror câmp de date conține 8 octeți, către ECU-ul destinație. Mesajele cadru ce conțin pachetele de date sunt notate TP.DT, (TransportProtocol.DataTransfer). Mesajul de aprobare a transmisiei este transmis periodic de către ECU-ul destinație cât timp conexiunea este activă pentru a confirma primirea și interpretarea corectă a mesajelor transmise de către ECU-ul sursă. Încheierea conexiunii dintre ECU-ul sursă și ECU-ul destinație se realizează prin transmiterea mesajului de confirmare de primire, TP.CM_EndOfMsgACK, transmis de ECU-ul destinație către ECU-ul sursă.

În următoarea figură este prezentată o diagrama a conexiunii „Request to Send”.

Figura 4.5.1 Diagrama conexiunii „Request to Send”

Transmiterea mesajelor multi-cadru globale, al căror identificator are un PDU specific ce desemnează o extensie de grup se realizează printr-o conexiune de tip BAM, „Broadcast Announce Message”. Fiind o transmisie globală ea se adresează tuturor ECU-urilor prezente în rețeaua CAN. Începerea transmisiei datelor este anunțată printr-un mesaj de avertizare adresat tuturor nodurilor (ECU-urilor) aflate în rețea prin care acestea sunt înștiințate că urmează recepționarea unui mesaj de mari dimensiuni pe rețeaua CAN. Mesajul transmis conține numărul de octeți din care format mesajul multi-cadru, precum și Numărul Parametrului de Grup, fiind notat TP.BAM. Acest mesaj anunț nu trebuie sa primească nici un răspuns din partea nodurilor receptoare. Transmiterea efectivă a datelor se realizează prin mesaje cadru CAN, al căror identificator determină Numărul Parametrului de Grup, notat TP.DT.În următoarea figură este prezentată o diagrama a conexiunii „Broadcast Announce Message”.

Figura 4.5.2 Diagrama conexiunii „Broadcast Announce Message”Capitolul 5

Prezentarea instrumentului de bord

_____________________________________________________________________________

5.1. Prezentarea instrumentului de bord

5.2. Arhitectura hardware

5.3. Caracteristici mecanice

5.4. Arhitectura software

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

În acest capitol este prezentat instrumentul de bord folosit pentru exemplificarea funcționalității aplicației dezvoltate. În continuare dispozitivul ales va fi denumit WT (numele intern al proiectului). Alegerea instrumentului prezentat în continuare a fost făcută luând în considerare următoarele criterii :

Respectarea constrângerilor de confidențialitate

Caracteristicilor hardware și software ale dispozitivului

În interiorul unui vehicul instrumentul de bord este una dintre cele mai importante compnente electronice, scopul principal al aceștia este de a realiza interfață cu utilizatorul. Instrumentul de bord este însărcinat cu afișarea informațiilor relevante pentru șofer. În industria autovehiculelor comerciale instrumentul de bord are o semnificație amplificată fata de alte ramuri ale industriei auto, datorită sistemelor auxiliare conectate a căror activitate și parametrii de funcționare pot fi inspectați de către șofer prin utilizarea acestuia.

5.1 Prezentarea instrumentului de bord

În figura 5.1.1 este prezentată partea frontală a instrumentului de bord , iar tabelul 5.1.1 conține componentele ce constituie interfață cu utilizatorul [2.].

Figura 5.1.1 Panoul frontal al instrumentului de bord

Tabelul 5.1.1 Componentele Panoului frontal

Ecranul central are rolul de a afișa informații suplimentare referitoare la stare vehiculului. Cu ajutorul acetuia vor fi afișate informații referitoare la:

Parametrii de funcționare ai autovehiculului

Mesaje de avertizare

Rezultatele testării efectuate de către ECU-uri la pronire

Listarea erorilor apărute

Distanța parcursă, consumul mediu de combustibil, viteza medie de rulare

Presiunea atmosferică

Afișarea gradului de uzare a frânelor

Parametrii motorului, treapta de viteză

Afișajul pe ecran este realizat cu ajutorul microcontrolerului dedicat FPT-208P-M06. Acesta dispune de SDRAM încorporat, și nu are nevoie de o memorie RAM video externă. Memoria rezervată aplicației este o memorie flash (4MB) iar memoria de lucru este o memorie de tip SRAM (512KB).
Controlerul grafic dispune de o interfață MCU 16/32 biți cu suport DMA și întreruperi. Acesta poate susține o frecvență internă de până la 64MHz. Alte caracteristici principale ale microcontrolerului includ suport de desen 2D și funcții bitmap (linii, poligon și zone dreptunghiulare), afișaj digital de până la 24 de biți RGB, rezoluție de afișare de până la 800 x RGB x 480, 4 straturi vizibile la în același timp și culoare de fundal cu spurapunere grafică .

Caracteristicile fizice ale ecranului central sunt prezentate în tabelul de mai jos:

Tabelul 5.1.2 Caracteristici Ecran central

5.2 Arhitectura Hardware

În tabelul 5.2.1 sunt prezentate principalele caracteristici hardware și electrice ale instrumentului de bord. În figura 5.2.1 este prezentată schema bloc a circuitului electric.

Tablul 5.2.1 Caracteristici Hardware ale instrumentului de bord

Figura 4.2.1 Schema bloc a circuitului

Interfața CAN (Controller Area Network ) este implementată conform standardului ISO 11898. Interfețele CAN prezintă capabilități de întrerupere pentru microcontroler. Pentru rezistența terminală s-a folosit un rezistor de 120 Ohm.

Instrumentul de bord este realizat cu un microcontroler RSC cu magistrală de 32 de biți. Microcontrolerul dispune de o memorie externă Flash încorporată,în care sunt stocate Sistemul de oprare și aplicația dezvoltat și memorie internă RAM. De asemena sunt prevăzute capabilități de extindere a memoriei Flash, prin atașarea de memorii externe. Frecvența de funcționare a microcontrolerului este de 100MHz, acesta dispunând de arhitectură Harvard ce permite accesul simultan la instrucțiuni și date. Alte caracteristici includ includ funcții de protecție a memoriei, funcționare timp-real.

Instrumentul de bord dispune de o memorie EEPROM pentru stocarea datelor de configurare, a parametrilor și a datelor referitoare la producător.Memoria EEPROM este controlată de microcontroler.

Pentru redarea sunetelor este prevăzut un circuit integrat de amplificare și un difuzor.Toate suntele generate sunt controlate de microcontroler.

5.3 Caracteristici mecanice

În tabelul 5.3.1 sunt prezentate caracteristicile fizice ale instrumentului de bord.

Tabelul 5.3.1 Caracteristici mecanice

5.4 Arhitectura Software

Dezvoltarea aplicației se realizează prin crearea de module software, divizate după funcționalități. În figura 5.4.1 sunt prezentate componentele software integrate, și modul de interacțiune al acestora.

Figura 5.4.1 Modelul de dezvoltare software

Aplicația software a instrumentului de bord include următoarele componente:

Încărcare memorie Flash

Sistem de operare

Platforma client

Platforma grafică

Aplicație

Memoria nevolatilă (ROM Read Only Memory) a dispozitivului este divizată în secțiuni corespunzătoare cu tipul de date stocate:

Parametrii corespunzători Interfetei om-mașină (HumanMachineInterface)

Date limbaj (șiruri de caractere, texte eroare)

Date aplicație

Date informații sistem

Capitolul 6

Recepția și prelucrarea mesajelor CAN

_____________________________________________________________________________

6.1. Panoul frontal al funcției de recepție și prelucrare a mesajelor

6.2 Diagrama bloc a funcției de recepție și prelucrare a mesajelor

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

6.1. Panoul frontal al funcției de recepție și prelucrare a mesajelor

Figura 6.1.1 Panoul frontal al funcției de recepție

Mesajele recepționate și cele transmise sunt afișate de către program cu ajutorul unui tabel, fiecare celulă a acestuia reprezentând un șir.

Coloanele acestui indicator sunt:

Message ID: în aceasta coloană va fi afișat identificatorul mesajului.

DLC (DataLengthCode): indică lungimea mesajului.

Data: în acest câmp sunt afișate datele (octeții) transmise în mesaj.

Time Stamp: indică ora la care a fost recepționat sau transmis mesajul.

# Total: în cazul mesajelor ciclice, cu același idendtificator, vor fi afișate doar odată; această coloană va afișa de câte ori a fost recepționat sau transmis un astfel de mesaj.

Cycle Time: unele mesaje sunt transmise în mod regulat pe magistrală la anumite intervale de timp (ms). Acest câmp indică la ce interval se repetă aceste semnale (în cazul mesajelor ciclice).

Dt Min: perioada cu care sunt trimise mesajele ciclice nu este fixă, aceasta putând oscila ușor. În această coloană este afișată valoarea minimă.

Dt Max: valoarea maximă a perioadei mesajelor ciclice.

Cu ajutorul listei Update Rate se poate selecta la ce intervale de timp se reîmprospătează monitorul din program. Valorile dintre care se poate alege sunt 100ms, 500ms și 1000ms.

Butonul Clear Monitor are ca scop „golirea” tabelului. Acesta va începe să afișeze din nou odată cu recepționarea primului mesaj.

Indicatorul Bus Load afișează procentul de„ocupare” al magistralei.

6.2. Diagrama bloc a funcției de recepție și prelucrare a mesajelor

Figura 6.2.1 Diagrama bloc a funcției de recepție și prelucrare a mesajelor

Figura 6.2.2 Funcția care stabilește rata de împrospătare

Recepția și prelucrarea mesajelor se face cu ajutorul unei bucle de tip while. Această buclă este temporizată cu ajutorul structurii case care stabilește rata de împrospătare.

Figura 6.2.3 Funcția de calcul a ratei de ocupare a magistralei

Rata de ocupare a magistralei este calculată în funcție de numărul mesajelor de la intrare și viteza de comunicație selectată (Baud Rate).

Figura 6.2.4 Funcția de prelucrare a mesajelor

Mesajele primite vin sub formă de șir, și conțin informații precum: ora la care au fost recepționate (TimeStamp), identificatorul mesajului (ArbitrationId) care va trebui prelucrat, lungimea mesajului (DataLength) și informația utilă (Data).

Se verifică dacă identificatorul mesajului este standard sau extins. În cazul în care identificatorul este extins, acesta este adus la formatul standard, el având altă formă, specifică pentru a putea fi prelucrat de programul LabVIEW.

Datele sunt prelucrate și împărțite astfel încât să poate fi afișate corect în coloanele tabelului din panoul frontal.

Figura 6.2.5 Funcții de prelucrare și afișare a mesajelor

Pentru fiecare mesaj recepționat sau transmis se verifică dacă acesta mai este deja afișat în panoul frontal. Acest lucru este făcut cu ajutorul identificatorului, care este comparat cu identificatoarele mesajelor afișate până în momentul respectiv. Dacă un mesaj cu același identificator există deja atunci este incrementată valoarea din coloana # Total, iar mesajul nu va mai fi afișat încă odată. În caz contrar, mesajul va fi afișat pe o nouă linie în tabel.

Figura 6.2.6 Funcțiile de calcul a lui dt Min și dt Max

Valorile coloanelor dt Min și dt Max, sunt calculate cu o frecvență determinată de rata de reîmprospatare selectată, pentru fiecare mesaj. Noile valori sunt comparate cu minimul respectiv cu maximul din momentul respectiv. Perioada cu care sunt recepționate sau transmise mesajele ciclice se determină cu ajutorul câmpului TimeStamp.

Capitolul 7

Transmisia mesajelor CAN

_____________________________________________________________________________

7.1. Panoul frontal al funcției de transmisie a mesajelor CAN

7.2. Diagrama bloc de transmisie a mesajelor ciclice

7.3. Diagrama bloc de transmisie a șirului de mesaje CAN

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

7.1. Panoul frontal al funcției de transmisie a mesajelor CAN

Figura 7.1.1 Panoul frontal al funcției de transmisie

Programul oferă două posibilități de transmitere a mesajelor pe magistrala CAN. Prima metodă, “Custom CAN Messages”, oferă utilizatorului posibilitatea de a transmite un șir de mesaje diferite, fiecare la un moment diferit, prestabilit, sau unul după altul. Fiecare octet al unui mesaj poate fi configurat manual.

A doua metodă, , “Cyclic CAN Messages”, oferă utilizatorului posibilitatea de a transmite mesaje ciclice, având opțiunea de a selecta perioada cu care sunt transmise. Pot fi definite trei astfel de mesaje, pentru fiecare dintre ele putând fi configurate identificatorul, octeții de date, lungimea (DLC) și perioada.

După definirea tuturor atributelor, prin apăsarea butonului Start se începe transmiterea mesajului. Acest lucru trebuie făcut pentru fiecare mesaj în parte dacă se dorește trimiterea a mai multor mesaje ciclice.

7.2. Diagrama bloc de transmisie a mesajelor ciclice

Figura 7.2.1 Funcția de transmisie a mesajelor ciclice

Pentru fiecare din cele trei mesaje ciclice se deschide câte un obiect. Se verifică dacă identificatorul este standard sau extins pentru a putea fi prelucrat în caz de nevoie.

Transmisia se face cu ajutorul unei bucle while care începe să se execute când este apăsat butonul Start. În acest moment se aprinde și LED-ul MSG status, care indică faptul că transmisia este activă.

Structura case de eroare funcționează astfel: dacă nu există erori, aceasta nu influențează funcționarea programului, iar dacă apare o eroare de transmisie, aceasta este ștearsă, se oprește obiectul de transmisie, se resetează și apoi este pornit din nou. Setarile obiectului nu se pierd datorita faptului că este păstrată referinta obiectului.

7.3. Diagrama bloc de transmisie a șirului de mesaje CAN

Figura 7.3.1 Funcția de transmisie a șirului de mesaje

În cazul transmisiei unui șir de mesaje, cu ajutorul unei bucle while, se ia fiecare mesaj în parte și se pregătește pentru transmisie: dacă identificatorul este standard, rămâne nemodificat, iar dacă acesta este extins bitul 30 va fi pus pe valoarea 1.

În momentul apăsării butonului de transmisie, se ia minimul dintre numărul de mesaje definite și “Number to Write”, adică câte mesaje se doresc a fi transmise.

Structura de eroare are aceeași funcționalitate ca și în cazul transmiterii mesajelor ciclice.

Capitolul 8

Stocarea mesajelor CAN în fișiere de tip text

_____________________________________________________________________________

8.1. Panoul frontal al funcției de stocare a datelor

8.2. Diagrama bloc a funcției de prelucrare a datelor

8.3. Diagrama bloc a funcției de stocare a datelor

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

8.1. Panoul frontal al funcției de stocare a datelor

Figura 8.1.1 Panoul frontal al funcției de stocare

Butonul Start logging oferă utilizatorului posibilitatea de a începe stocarea mesajelor din rețeaua CAN într-un fișier de tip text. În momentul acționării acestui buton starea LED-ului va fi activă.

Prin acționarea butonului Stop logging stocarea datelor se va opri, LED-ul va fi stins,

Figura 8.1.2 Stabilirea căii fișierului

Cu ajutorul acestui control se stabilește calea fișierului unde vor fi salvate mesajele. Dacă fișierul nu există, acesta va fi creat.

8.2. Diagrama bloc a funcției de stocare a datelor

Figura 8.2.1 Funcția de stocare a datelor

Se verifică la fiecare 100ms dacă a fost acționat butonul Start logging. În momentul acționării acestuia, se deschide sau se creează fișierul unde urmează să fie stocate datele, se scrie prima linie din fișier, care conține denumirile fiecărei coloane, iar apoi, cu ajutorul unei bucle while, se ia fiecare fișier în parte și se scrie pe câte un rând nou. Se prelucrează câte un fișier la fiecare 50 ms.

Aceste acțiuni au loc cât timp este activă stocarea datelor, adică cât timp nu este apăsat butonul Stop. În momentul opririi întregului program, fișierul va fi închis. Concluzii

Folosind mediul LabVIEW se reduce semnificativ timpul necesar dezvoltării de aplicații pentru măsurarea și prelucrarea semnalelor. Instrumentele virtuale create se pot modifica sau reutiliza cu ușurință în cadrul altor aplicații.

Dispozitivul multifuncțional -6009 de la National Instruments asigură fiabilitate în privința achiziției datelor și este suficient de simplu pentru măsurători rapide, dar destul de capabil pentru multe aplicații complexe de măsurare. Cu sistemul de achiziție NI -6009 se pot măsura semnale cu o frecvență maximă de ordinul kHz-lor dar se pot genera semnale de ordinul Hz-lor (datorită ratei mici de actualizare a tensiunii de ieșire). Pentru partea de transmisie și recepție a datelor funcțiile /IP au un grad mare de abstractizare și prin urmare nu e necesară cunoașterea în detaliu a protocolului ci doar mecanismul de transfer a datelor.

Partea de comandă a sistemului de achiziție NI -6009 poate fi folosită în procesul didactic, în cadrul lucrărilor de laborator aferente disciplinelor „Instrumentație virtuală în ingineria electrică” și „Tehnici de prelucrare a semnalelor”.

Contribuțiile personale sunt următoarele:

realizarea unui program de recepție a mesajelor CAN

realizarea unor programe de transmisie a mesajelor CAN

realizarea unui program de prelucrare și salvare a datelor într-un fișier

realizarea unui program de monitorizare în timp real a mesajelor vehiculate pe interfața CAN.

Bibliografie

[1] C. Șorândaru, Instrumentație virtuală în ingineria electrică, Editura Orizonturi

Universitare, Timisoara, 2003

[2] M. Lascu, Tehnici avansate de programare în LabVIEW, Editura Politehnica, Timișoara, 2007

[3] International – J1939

[4] Continental -“CAN_Training.ppt”, Document Continental Automotive Romania, pentru descrierea protocolului CAN

[5] *** NI-CAN Hardware and Software Manual, National Instruments

[6] Manual de utilizare LabVIEW, National Instruments (http://www.ni.com/pdf/manuals)

Bibliografie

[1] C. Șorândaru, Instrumentație virtuală în ingineria electrică, Editura Orizonturi

Universitare, Timisoara, 2003

[2] M. Lascu, Tehnici avansate de programare în LabVIEW, Editura Politehnica, Timișoara, 2007

[3] International – J1939

[4] Continental -“CAN_Training.ppt”, Document Continental Automotive Romania, pentru descrierea protocolului CAN

[5] *** NI-CAN Hardware and Software Manual, National Instruments

[6] Manual de utilizare LabVIEW, National Instruments (http://www.ni.com/pdf/manuals)