Aplicație software în LabVIEW pentru diagnoza autovehiculelor [620811]

1
Universitatea “Politehnica” din București
Facultatea de Electronică, Telecomunicații și Tehnologia
Informației

Aplicație software în LabVIEW pentru diagnoza autovehiculelor

Proiect de diplomă
prezentat ca cerintă parțială pentru obținerea titlului de Inginer
în domeniul Electronică si Telecomunicații programul de
studii de licență Electronică Aplicată

2017

Conducător științific: Absolvent: [anonimizat]. Lucian Andrei PERIȘOARĂ Ion GURAN

2

3

4

5

6

7
Table of Contents
Introducere ………………………….. ………………………….. ………………………….. ………………………….. …… 15
Capitolul 1. Introducerea conceptului de „diagnoză auto” ………………………….. ………………………….. …… 17
1.1Autovehiculul în ziua de azi și nevoia de diagnoză ………………………….. ………………………….. …….. 17
1.2 Prezentare generală autovehicul ………………………….. ………………………….. ………………………….. .. 17
1.3Calculatoare de bord actuale ………………………….. ………………………….. ………………………….. ……… 20
1.3.1 Unitatea Electronică de Control (ECU) ………………………….. ………………………….. ………………. 20
1.3.2 Parametrii controlați de ECU ………………………….. ………………………….. ………………………….. .. 22
CAPITOLUL 2. Protocoale de comunicație pentru diagnoză ………………………….. ………………………….. 25
2.1 Standardele OBD( On -board diagnostics) ………………………….. ………………………….. ……………………. 25
2.1.1 OBD -I ………………………….. ………………………….. ………………………….. ………………………….. ………. 25
2.1.2 OBD -1.5 ………………………….. ………………………….. ………………………….. ………………………….. ….. 26
2.1.3 OBD -II ………………………….. ………………………….. ………………………….. ………………………….. ……… 26
2.1.4 EOBD și EOBD -II ………………………….. ………………………….. ………………………….. ……………………. 26

8

Cuprins 2

9

LISTA TABELELOR

10

11

LISTA FIGURILOR

12

13

LISTA ACRONIMELOR

14

15

INTRODUCERE

Tema acestui proiect este proiectarea și realizarea în LabView a unei aplicații software de
diagnoză pentru autovehicule, pentru a monitoriza diverși parametrii precum:
• Viteza
• Turație motor
• Nivel combustibil din rezervor
• Temperatură lichid răcire
• Consumul instantaneu de combustibil
• Tensiunea bateriei
• Indicator MIL, etc.
Obiectivele acestui proiect sunt următoarele:
• Realizarea părții hardware a proiectului care conține un cablu OBD -CAN, o i nterfață
CAN -USB NI 8473 și laptopul pe care rulează aplicația software . De asemenea, se
dorește testarea și a unei platforme CompactDAQ NI cDAQ -9171 cu interfața CAN NI –
9862.
• Dezvolta rea unei aplicații software, în LabVIEW utilizând toolboxul Automotive
Diagnostic Command Set (ADCS) care va permite comunicarea cu unitățile de control

16
electronice ale autovehiculului, afișarea numerică și grafică, în timp real, a parametrilor
de funcționare ai autovehiculului, și opțional transmiterea de comenzi AT și afișar ea
răspunsurilor, precum și afișarea și ștergerea codurilor de defect.
Motivarea alegerii acestei teme constă în faptul că electronica a devenit esențială în industria
automobilelor, aceasta îmbunătățind atât siguranța cât si co mfortul celor aflați în mașină . Astfel,
cu ajutorul unor senzori ș i traductoare, se pot monitoriza în timp real parametrii unui autovehicul
prevenind defectarea critică a automobilelor și evitarea unor dezastre. Ca și funcționalitate,
partea electronică de pe un automobil constă în citirea parametrilor de la senzori, urmată de
transmiterea și prelucrarea acestor parametrii de unitatea centrală de comandă(ECU) .
În continuare, citirea datelor de la ECU se face cu ajutorul standardului OBD -II ( On Board
Diagnostics version 2), care p resupune prezența unei interfețe OBD -II pe autovehicul. În Europa,
acest standard se numește EOBD ( European On Board Diagnostics).

17

Capitolul 1 . Introducerea conceptului de „diagnoză
auto”
1.1 Autovehiculul în ziua de azi și nevoia de diagnoză
În zilele noastre, oamenii au devenit dependeți de autovehicule, deoarece acestea le permit
deplasare rapidă dintr -un loc în altul. Pentru majoritatea oamenilor, autovehiculul reprezintă
principalul mod de deplasare, totodată fiind ș i cel mai utilizat. Astfel, dependența de automobile
face ca defectarea acestora să aibă efecte nefaste asupra bunului mers al lucrurilor.
Prin diagnoză auto întelegem un echipament hardware pe care rulează un soft capabil să
identifice defecte sau să mon itorizeze anumite componente cu scopul de a prelungi durata de
viață a autovehiculului.

1.2 Prezentare generală autovehicul
Parțile principale ale unui autovehicul sunt următoarele:
• Motor
• Șasiu
• Caroserie

18

Fig 1. 1
A. Motorul este responabil pentru punerea în mișcare a autovehiculului. Acesta transformă
energia (chimică sau electrică) în energie mecanică.
La rândul său, motorul este alcătuit din :
▪ mecanismul motor
▪ instalații auxiliare : distribuția
▪ instalația de pornire
▪ instalația de alimentare
▪ instalația de aprindere
▪ instalația de ungere

1. Instalația de ungere
Uleiul stă în baia de ulei. Acesta este tras cu ajutorul pompei de ulei, trecut prin filtrul de ulei, și
împins prin galeriile de ulei ale motorului.

2. Instalația de răcire
Arderile din motor generează cantități uriașe de căldură. Această căldură poate afecta motorul.
De aceea motoarele au un sistem de răcire. Cea mai folosită metodă constă în circularea unui
lichid (de răcire) prin blocul motor și chiul asă. Cel mai indicat este ca temperatura motorului să
rămâna constanta pe durata de funcționare. Pompa de apă ajută lichidul de răcire să curgă prin
instalație, unde acesta preia căldura de la motor, în final ajungând în radiator, unde cu ajutorul
unui ven tilator lichidul este, din nou, răcit.

19

3. Instalația de alimentare (sistemul aer -carburant)
Această instalație livrează combustibilul către un dispozitiv ce controlează cantitatea ce va
ajunge la motor. Colectează și curăță aerul. Livrează aerul către cil indri. Schimbă raportul aer –
combustibil, funcție de nevoile motorului. Pompa de alimentare livrează din rezervor
combustibil. Filtrul de combustibil și filtrul de aer curăță de impurități carburantul și aerul
exterior.

4. Sistemul de control al emisie
Există mai multe metode de control al poluării:
– PVC (positive crankcase ventilation) – reduce emisiile de hidrocarburi prin preluarea vaporilor
de ulei și carburant prin arderea în cilindri.
– Evaporative emission control system – preia vaporii de combus tibil și -i duce în camera de
ardere.
– Exhaust gas recirculation – EGR – introduce gazele rezultate la ardere în aerul aspirat pentru a
reduce temperatura lor și a reduce probabilitatea de a crea NO.
– Convertor analitic – covertește hidrocarburile, CO și NO în apă.
– Air injection system – reduce hidrocarburile prin combustia controlată a acestora în fluxul de
evacuare.

5. Sistemele electric și electronic
a. Sistemul de aprindere
La un motor pe benzină, bujiile aprind amestecul aer -carburant. O bobină de aprindere generează
electricitatea necesară creării scânteii. Un senzor urmărește arborele cotit și dă informații despre
poziția lui unui modul de control, care comandă bobina. Distribuitor dirijează informația, pentru
ca bujiile să fie activate în mod c orect.

b. Sistemul de pornire și încărcare
Atunci c ând cheia este rotită în poziția de pornire, este transmisă o cantitate mică de curent de la
baterie la un releu (selenoid) . La momentul potrivit, pentru fiecare piston se asigură scânteia de
aprindere de la bujie (în cazul motorului pe be nzină), care aprinde amestecul.
Rotirea volantului arborelui cotit cere multă energie. Reîncărcarea bateriei se face cu ajutorul
unui alternator.

20

c. Controlul electronic al motorului
Are loc o monitorizare continuă a mo torului. Trei tipuri de componente: senzori de intrare, un
computer și dispozitive de ieșire. Computerul dirijează dispozitivele de ieșire pentru a opera
modificările necesare și a asigura funcționarea optimă a motorului.

d. Sistemul de diagnosticare
On-board diagnostic – OOB II. Acesta monitorizează funcționarea mașinii și semnalează
problemele apărute.

B. Șasiul
Șasiul este compus din: transmisie , sistemele de conducere , componentele de susținere și
propulsie , instalații auxiliare

C. Caroseria
Caroseria are rolul de a purta marfa și pasagerii. [1]
1.3 Calculatoare de bord actuale

1.3.1 Unitatea Electronică de Control (ECU)
Unita tea electronică de control este definită ca fiind un sistem încapsulat care controlează unul
sau mai multe subsisteme ale unui vehicul. Toate aceste sisteme formează computerul de bord.
Modulul de control electronic este folosit în sectorul auto în multe aplicații electronice, precum
și pentru controlul electronic. Aceste module fac parte din sistemele încorporate.
Modulele electronice de control al motoarelor au fost utilizate, în primul rând, pentru reglarea
aprinderii acestora. Din anul 1987, aceste module electronice sunt fo losite pentru reglarea
aprinderii și la motoarele diesel. Aproximativ de la mijlocul anilor 90 sistemele de reglare
mecanice la motoarele cu combustie internă au fost aproape complet înlocuite de către modulele
de control electronice. Modulele de control E CU din componența autovehiculelor includ în afara
sistemului de aprindere, printre altele, și: sistemul de pornire, de anti -blocare al frânelor (ABS),
de climatizare, de control airbag, controlul de distanță, etc.
Modulele electronice lucrează după princip iul „IPO”, (în engleză Input -Process -Output,
„introducere -prelucrare -debitare”). Pentru înregistrarea valorilor, sunt disponibili senzorii care
stabilesc o caracteristică fizică, cum ar fi viteza, presiunea, temperatura, etc. Această valoare este

21
comparată sau calculată cu o valoare memorată în ECU. În cazul în care valoarea măsurată cu
valoare prevăzută în ECU nu se potrivesc, modulul electronic reglementează valoarea prin
proces fizic, astfel încât valorile reale măsurate să corespundă cu dimensiunile nom inale
programate în ECU.
În timp ce î n anii din urmă aprinderile electronice erau construite din circuite electronice
analogice, ECU -urile de azi sunt de obicei înzestrate cu un „sistem cu propria inteligență” (în
engleză Embedded system, sistem încorporat ), care constă dintr -un computer separat, sub forma
unui sistem încorporat.
Mărimea acestui computer variază în funcție de complexitatea sarcinilor sale. În mod
semnificativ, acesta variază de la un circuit integrat cu un microprocesor (cu memorie RAM și
ROM) până la sisteme multifuncționale cu un sistem de producție grafică.
De obicei, programarea este realizată prin utilizarea memoriei ROM (în engleză Read Only
Memory, „Memorie doar citibilă”) . Unele sisteme, însă, permit actualizarea programului din
ECU , prin reprogramarea memoriei flash la atelierele de specialitate.
Unități de control vizibile sunt pe tahometru, în forma lui nouă, împreună cu turometru și diverse
alte indicatoare. Senzorii, cum ar fi nivelul combustibilului în rezervor, presiunea uleiu lui pot
dispune de propriul modul electronic care sunt, printre altele, memorate pe termen lung.
Aparatele schimbă informațiile cu privire la condițiile de funcționare și alte date relevante ale
vehiculului, prin diferite sisteme de interfețe (K -Line,CAN, LIN, MOST, FlexRay). În afara
acestora, prin aceste interfețe se poate face legătura la OBD, respectiv diagnosticarea
vehiculului. Acestea pot fi legate de aparate de diagnosticare sau cu calculatoare personale,
notebook, având o interfață corespunzătoare prin care poate să comunice. În principal, sunt
căutate și identificate greșelile pe care modulul electronic le -a înregistrat la propriile teste sau la
senzorii de legătură. Astfel, în atelierele de reparații, cu astfel de mesaje la defecțiuni, se poate
evita un timp de lucru îndelungat.
Principalele tipuri de UEC:
a) Unitatea de Control a Motorului (ECU)
b) Unitatea de Control a Transmisiei (TCU)
c) Unitatea Electronica Generală(GEU)
d) Unitatea de Control a Frânei (BCU)
e) Unitatea Centrală de Sincronizare(CTU)
f) Unitatea de Control a Suspensiei (SCU)








22
1.3.2 Parametrii controlați de ECU

Unitatea de control a motorului controlează o serie de actuatori din interiorul
motorului care asigura funcționarea la performanța optimă a motorului . Parametrii controlați
de ECU sunt:
❖ Controlul amestecului de combustibil
La motoarele pe injecție unitatea de control a motorului va determina cantitatea de
combustibil necesară, luând în calcul mai mulți parametrii. Atunci când pedala de accelerație
este apasată, o cantitate mai mare de aer va pătrunde în motor, iar ECU va injecta mai mult
combustibil. În cazul în care motorul este rece,cantitatea de combustibilul inserat este mai mare.
❖ Controlul vitezei de mers în gol
Majoritatea motoare lor au un dispozitiv de control al vitezi de mers în gol incorporat în
ECU. Rotațiile motorului sunt monitorizate de către senzorul arborelui cotit. Acesta joacă un
rol important în injecția de combustibil și timpii scânteilor. Viteza de mers în gol este
controlată de un senzor de accelerație sau de un motor cu pas. Motoarele de început bazate pe
carburator foloseau un senzor de accelerație acționat cu ajutorul unui motor bidirecțional.
Pentru a funcționa corect, dispozitivul de control al mersului în gol t rebuie să poată anticipa
sarcina motorului. Sarcina motorului la relanti se poate schimba dacă sunt activate sistemul de
servo -direcție, sistemul de servo -frână, sau apariția de consumatori noi în sistemul electric. De
asemenea, aceasta poate varia și în f uncție de temperatura motorului. Un sistem de control al
accelerației poate fi utilizat la controlul vitezei de relanti, în implementarea funcțiilor de pilot
automat sau limitarea vitezei constructive.
Scopul reglării relantiului este de a obține un regim stabil de funcționare gestionând
cantitatea de aer aspirată. Reglarea relantiului nu poate fi făcută decât dacă calculatorul are
informația “picior ridicat”.
Regimul de consemn relanti este determinat în funcție de:
➢Temperatura lichidului de răcire a motorului
➢Funcția climatizare și puterea absorbită
➢Presinea din circuitul hidraulic al direcției asistate
➢Încărcarea bateriei
➢Debitul de aer este controlat prin:
• Poziția voletului corpului clapetă
• Printr -o derivație a acestuia
Reglarea relantiului prin rotația clapetei de acclerație
Corecția regimului de relanti se face grație comenzii primite de către clapeta motorizată.
Reglarea deschiderii clapetei permite reglarea cantității de aer absorbită de motor.
Reglarea relantiului prin derivație
Sistemel e care permit acest lucru sunt de două tipuri:
➢Motor pas cu pas
➢Electrovane cu una sau două înfășurări.
Controlul electronic al valvelor

23
Au fost create și testate motoare experimentale ce nu conțin arborele cotit, dar care dețin
controlul admisiei și a l deschiderii valvelor de evacuare. Aceste motoare pot fi pornite și
utilizate fără ajutorul unui starter, ci doar echipate cu un sistem electronic de aprindere și
injecție. “Startul static” poate oferi o reducere a emisiilor de gaze și eficiență asemenea
motoarelor hibride, însă fără un starter complex ce duce la creșterea prețului
autoturismului. [3]

❖ Controlul timpilor de aprindere
Pentru a fi inițiată aprinderea combustibilului în camera de ardere este nevoie de o
scânteie. Unitatea de control a motoru lui poate ajusta timpul exact al scânteii și poate genera o
putere mai bună. Dacă se detectează rateuri in arderea combustibilului, caz distructiv pentru
motor, ECU va întârzia timpii viitori de aprindere. A doua și cea mai comună sursă de rateuri
constă î n funcționarea motorului într -o gamă de rotații prea mică pentru sarcina din momentul
respectiv. În acest caz rateurile apar atunci când pistonul nu este capabil să coboare în același
timp cu detonarea. Acest caz apare in special la mașinile dotate cu cuti e manuală de viteze. La
mașinile cu cutie automată reglarea turațiilor se face de către ECU care va folosi o treaptă
inferioară.

24

25
CAPITOLUL 2. Protocoale de comunicație pentru
diagnoză
În zilele noastre, numeroși producători de autovehicule folosesc protocoale de comunicație
diferite, atunci când se dorește testarea autovehiculului cu o diagnoză auto. În mare parte,
multitudinea de protocoale de comunicație folosite pentru diagnosticare este dată de intere sul
fiecărui producător auto, de a menține costurile cât mai mici și de a sili proprietarii de
automobile să apeleze la reprezentața auto, atunci când vor sa diagnosticheze automobilul .

2.1 Standardele OBD ( On -board diagnostics)
OBD este un termen din domeniul auto care se referă la capacitatea de autodiagnosticare și de
raportare a stării curente a unui autovehicul. Cu ajutorul sistemelor OBD, proprietarul sau
mecanicul auto pot afla starea diferitelor subsisteme ale vehiculului. Cantitatea de informație de
diagnosticare prin OBD a crescut extrem de mult de la apariția primei versiuni OBD, în anul
1980, și până în prezent. Primele versiuni generau aprinderea unor leduri dacă unu subsistem
funcționa defectuos, dar nu furniza nicio informație cu privire la natura problemelor.
Implementările moderne ale OBD utilizează un port standardizat de comunicații digitale pentru a
furniza date în timp real, dar și o serie standardizată de coduri de diagnosticare a defecțiunilor
sau coduri de er oare (DTC), care permit identificarea și remedierea rapidă a defecțiunilor unui
vehiculului.

2.1.1 OBD -I
A fost un standard apă rut în anul 1991 în California, dar nu era un standard acceptat în toată
S.U.A. . Scopul reglementării OBD -I a fost acela de a încuraja producătorii de automobile să
conceapă sisteme fiabile de control al emisiilor care rămân ef iciente pe toată durata de viața a
vehiculului. Codurile de diagnosticare a erorilor ( Diagnostic Trouble Codes -DTC) ale
vehiculelor OBD -I pot fi găsite de obicei fără un "instrument de scanare" scump . Fiecare
producător a folosit propriul conector de legătură pentru diagnosticare ( Diagnostic Link
Connector -DLC) , iar locația și procedura de citire a codurilorde eroare erau, de asemenea
personalizate.

26
2.1.2 OBD -1.5

OBD 1.5 se referă la o implementare parțială a OBD -II pe care General Motors (GM) o folosea
pentru unele vehicule în 1994 și 1995. GM nu a folosit termenul OBD 1.5 în docu mentația
pentru aceste vehicule.În manualul de service, autovehiculele au pur și simplu o secțiune OBD și
una OBD -II. De asemnea, Mitsubishi a mai folosit OBD -1.5 pe o serie de mașini din anii `95,
`97.

2.1.3 OBD -II

OBD-II este o îmbunătățire față de OBD -I atât în ceea ce privește capacitatea, cât și
standardizarea. Sta ndardul OBD -II specifică tipul de conector de diagnosticare și identificarea
acestuia, protocoalele electrice de semnalizare disp onibile și formatul mesajului . În conector,
există un pin care furnizează energie pentru instrumentul de scanare de la bateria vehiculului,
ceea ce elimină necesitatea conectării uneia dintre uneltele de scanare la o sursă de alimentare
separată. Cu toate acestea, unii tehnici eni ar putea conecta instrumentul de scanare la o sursă de
alimentare auxiliară pentru a proteja datele , în cazul în care un vehicul suferă o pierdere de
energie electrică din cauza unei defecțiuni . În cele din urmă, standardul OBD -II furnizează o listă
a DTC -urilor standardizate. Ca urmare a acestei standardizări, un singur dispozitiv poate interoga
computere le de bord pentru acești parametri în orice vehicul. Standardizarea OBD -II a
determinat simplificarea diagnosticului echipamentelor din ce în ce mai complicate pentru emisii
și, deși numai codurile și datele referitoare la emisii trebuie transmise în confo rmitate cu
legislația SUA, majoritatea producătorilor au făcut acest conector principal pentru conexiunea de
date prin care sunt diagnosticate și reprogramate toate sistemele . Codurile de diagno sticare a
defectelor OBD -II au 4 cifre, precedate de o literă: P pentru motor și transmisie (motor), B
pentru caroserie, C pentru șasiu și U pentru rețea. Producătorii pot adăuga, de asemenea,
parametri personalizați de date pentru implementarea OBD -II specifică, inclusiv cereri de dat e în
timp real, precum și coduri de eroare. [4]

2.1.4 EOBD și EOBD -II

Condițiile EOBD (European on -board diagnostic) sunt echivalentele europene ale sistemului
OBD -II și se aplică tuturor autoturismelor din categoria M1 (cu cel mult 8 locuri de pasager i și o
greutate totală a vehiculului de 2500 kg sau mai puțin) Statele membre ale UE din 1 ianuarie
2001 pentru autovehiculele cu benzină și începând cu 1 ianuarie 2004 pentru autovehiculele
diesel .

27
Pentru modelele nou introduse, datele de reglementare au fost aplicate cu un an mai devreme – 1
ianuarie 2000 pentru benzină și 1 ianuarie 2003 pentru motorină.
Pentru autoturismele cu o greutate medie a vehiculului mai mare de 2500 kg și pentru vehiculele
utilitare ușoare, datele de reglementare aplicate începâ nd cu 1 ianuarie 2002 pentru modelele pe
benzină și 1 ianua rie 2007 pentru modelele diesel.
Implementarea tehnică a EOBD este, în esență, aceeași ca și OBD -II, având același conector de
legătură diagnostic SAE J1962 și protocoale de semnal utilizate.
În ca zul standardelor de emisie Euro V și Euro VI, pragurile de emisie ale EOBD vor fi mai mici
decât cele anterioare Euro III și IV.
În cazul "EOBD2" este vorba mai mult de marketing. Este utilizat de anumiți producători de
vehicule pentru a se referi la cara cteristicile specifice producătorului care nu fac parte din
standardul OBD sau EOBD. În acest caz, "E" înseamnă Enhanced .
2.1.5 Conectorul de diagnosticare OBD -II

Conform SAE J1962 , sunt prevăzute două interfețe hardware standardizate, numite tip A și tip B .
Cele doua interfețe sunt conectori mamă cu 16 pini (2×8), în formă de D, iar ambele au o
canelură între cele două rânduri de știfturi. Interfața de tip B are canelura întreruptă în mijloc,
astfel încât să nu puteți conecta un conector de tip A la o priză de tip B. Cu toate a cestea, puteți
cupla un adaptor de tip B tată într-o priză de tip A mamă.

Fig.2.1 Conector mamă tip A Fig. 2.2 Conector mamă tip B
Cone ctorul de tip A este utilizat pentru vehicule care utilizează tensiune de alimentare de 12V, în
timp ce tipul B este utilizat pentru autovehiculele de 24V și este necesar să se marcheze partea
din față a zonei în formă de D, cu o culoarea albastră.

28

Fig. 2.3 Conectorul OBD

Tabel. 6 Atribuirea pinilor pentru diferite protocoale de comuncație

În continuare, voi p rezenta principalele standarde d e comunicație utilizate:

2.2 Protoco lul de comunicație SAE J1850
Acest protocol a apărut în anul 1994 și are două abordări diferențiale. Protocolul SAE J1850
PWM folosește modulațiea în impulsuri și este utilizat Ford Motors . Protocolul SAE J1850 VPW
folosește modulația cu puls variabil, acest protocol fiind utilizat de mai multe companii: General
Motors, Chrysl er, Harley Davidson și Toyota .
2.2.1 Forma mesajului
▪ SOF – Start of frame
▪ Header -ul: Conține octeții identificatori, biții de prioritate, informații despre lungime, 1
bit pentru modul adresei, 2 biți pentru tipul mesajului, 2 octeți adiționali, adresa fizică, 1
octet pentru adresa destinației și un octet pentru adresa sursă

29
▪ Octe ții de date
▪ CRC – Cyclical Redundancy Check (Cod detector de eroare )
▪ EOD – End of Data
▪ EOF – End of Frame [5] [7]

Fig. 2.4

2.2.3 Stările magistralei
▪ magistrala alternează între starea activă și cea pasivă pentru fiecare bit in
parte
▪ stare high( în 1) a magistralei este dominantă
▪ simboluri dominante:
a.Magistrala activă: pulsurile înalte le domină pe cele joase
b. Magistrala pasi vă: predomină pulsațiile joase [8]

2.2.4 Protocolul SAE J1850 PWM
▪ Tensiunea de alimentare de 5V
▪ Pinul 2: Magistrala +
▪ Pinul 10: Magistrala –
▪ Codarea biților: PWM(pulse width modulation)

30
▪ Rata de biți: 41.6 kbit/s
▪ Sarcina utilă: 0 -8 biți
▪ Mesajul are lungimea restricționată la 12 octeți, inclusiv CRC [8]

Fig. 2.5 Distribuirea pinilor la protocolul SAE J1850 PWM

2.2.5 Protocolul SAE J1859 VPW
▪ Folosește modulația cu puls variabil
▪ Viteză de transfer a datelor de 10,4 kbit/s
▪ Pin 2: Bus +
▪ Tensiunea maximă este de +7 V
▪ Utilizează CSMA/NDA [8]

Fig. 2.6 Distribuirea pinilor la protocolul SAE J1850 VPW

31
2.3 Protocolul ISO 9141 -2
Acest protocol a fost folosit pentru prima dată de către Chrysler pe automobilele care erau
exportate în Europa și Asia. Este folosită o conexiune serială asincronă cu o rată de 10.4 kBaud.
Comunicația este bidirecțională, ceea ce face ca timpul de transfer al datelor să fie mai mare, dar
faptul că avem o singur ă linie simplifică foarte mult partea hardware.
Caracteristici:
▪ Pin 7: linia de comunicare la ECU – linia K
▪ Pin 15: linia de activare a ECU – linia L
▪ Receptor/T ransmițător asincron universal UART
▪ Lungimea mesajului este de 12 octeți [8]

Fig. 2.7 Utilizarea p inilor la protocolul ISO 9141 -2 [8], [9]
2.4 Protocolul ISO 14230 (KWP2000 )
ISO 14230, cunoscut mai ales sub denumirea de KWP2000 este standardul care ne interesează
cel mai mult în lucrarea de față fiind și standarul care sta la baza celor mai multe ECU -uri
folosite la automobilele din familia Renault -Dacia -Nissan .
Caracteristici:
▪ Nivelul fizic este identic cu cel al ISO 9141 -2
▪ Pin 7: linia K
▪ Schimbul de date se face cu rată de la 1,2 la 10,4 kBaud
▪ Pin 15: linia L
▪ Mesajul poate avea ma xim 255 octeți

32
2.5 Protocolul CAN
Interfața CAN(Controller Area Network) este un standard robust pentru magistrale de vehicule
proiectat pentru a permite microcontrolerelor și dispozitivelor să comunice între ele în aplicații
fără un computer gazdă. Este un protocol bazat pe mesaje, proiectat inițial pentru cablarea
electrică multiplex în interiorul autovehiculelor, dar este, de asemenea, utilizat în multe alte
contexte .
Este cel mai utilizat mijloc pentru transferul datelor în industria auto (în special la interfețele de
diagnoză și între calculatoarele autovehiculului).
Automobilul modern poate avea până la 70 de unități electronice de comandă (EC U) pentru
diverse subsisteme. [6] De obicei, cel mai mare procesor este unitatea de control a motorului.
Altele sunt utilizate pentru : transmisie, airbag -uri, antiblocare frâne / ABS, cruise control,
servodirectie, sist eme audio, geamuri electrice, uș i, reglarea oglinzilor, baterii ș i sisteme de
reincarcare pentru autoturisme hibride / electrice etc. Unele dintr e acestea for meaza subsisteme
independente, dar comunicarea între ele este esențială. Un subsistem poate avea nevoie să
controleze servomotoarele sau să primească feedback de la senzori. Standardul CAN a fost
conceput pentru a completa această necesitate. Un avantaj cheie este că interconectarea între
diferite sisteme ale vehiculelor poate permite implementarea unei game largi de caracteristici de
siguranță, economie și confort utilizând doar software -ul – funcționalitate care ar adăuga costuri
și complexit ate dacă astfel de caracteristici ar fi realizate filar. Exemple incluse:
▪ Pornirea / oprirea automată: Diferitele intrări ale senzorilor din jurul vehiculului (senzori
de viteză, unghi de direcție, climatizare pornit / oprit, temperatura motorului) sunt
colectate prin magistrala CAN pentru a determina dacă motorul poate fi oprit atunci când
este staționar pentru o economie de combustibil îmbunătățită și emisiilor.
▪ Frâne electrice de parca re: funcționalitatea are la bază senzorul de înclinare al
autovehiculului (utilizat și de alarmă antifurt) și senzorii de viteză a drumului (folosiți și
de sistemul ABS, controlul motorului și controlul tracțiunii) prin magistra la CAN pentru
a determina dacă maș ina este oprit ă pe o înclinație. În mod similar, intrările senzorilor
centurii de siguranță (parte a comenzilor airbagurilor) sunt alimentate de la magistrala
CAN pentru a determina dacă centurile de siguranță sunt fixate, astfel încât frâna de
mână se va elibera automa t la deplasare.
▪ Sistemele de asistență la parcare: atunci când șoferul este angrenat în poziția inversă,
unitatea de comandă a transmisiei poate trimite un semnal prin magistrala CAN pentru a
activa atât sistemul de senzori de parcare, cât și modulul de co mandă a ușii pentru
oglinda laterală a pasagerului față pentru a se înclina în jos, făcând vizibilă bordura . De
asemenea, magistrala CAN primește intrări de la senzorul de ploaie pentru a declanșa
ștergătorul parbrizului din spate atunci când este cazul .
▪ Sistemele de asistență automată a benzii de circulație / de evitare a coliziunilor: intrările
senzorilor de parcare sunt de asemenea utilizate de magistrala CAN pentru a alimenta
datele de proximitate în afara sistemelor de asistență a șoferului, cum ar fi avertizarea de

33
plecare a benzilor de circulație și, mai recent, aceste semnale se deplasează prin
magistr ala CAN pentru a acționa frâna p rin sârmă în sistemele active de evitare a
coliziunilor. [10]

2.5.1 Transmiterea datelor prin CAN

Transmisia de date CAN utilizează o metodă de arbitrare bitrate fără pierderi de rezoluție a
conflictelor. Această metodă de arbitraj impune ca toate nodurile din rețeaua CAN să fie
sincronizate pentru a eșantiona fiecare bit din rețeaua CAN în același timp. Acest a este
motivul pentru care unele persoane afirmă ca este o metodă sincronă . Din păcate, termenul
sincron este imprecis, deoarece datele sunt transmise fără un semnal de ceas într -un format
asincron.
Specificațiile CAN utilizează termenii "biți dominanți" și " biți recesivi" unde dominantă este
logică 0 (activată în mod ON de o tensiune de către emițător) și recesivă este logică 1 (pasiv
returnată la o tensiune de că tre un rezistor). Starea OFF este reprezentată de nivelul recesiv
(Logical 1). Dacă un nod transmite un bit dominant și un alt nod transmite un bit recesiv,
atunci există o coliziune și bitul dominant "câștigă". Aceasta înseamnă că nu există o
întârziere a mesajului cu prioritate mai mare, iar nodul care transmite mesajul cu prioritate
inferioară încearcă au tomat să retransmită ceasuri de șase biți după sfârșitul mesajului
dominant. Acest lucru face ca protocolul CAN să fie foarte potrivit în sistem de comunicații
prioritar e în timp real.
Tensiunile exacte pentru o valoare logică 0 sau 1 depind de stratul fiz ic utilizat, dar principiul
de bază al CAN este ca fiecare nod să asculte datele din r ețeaua CAN, inclusiv nodul de
transmisie propriu -zis. Dacă o logic ă 1 este transmisă de către toate nodurile de transmisie în
același timp, atunci o logică 1 este văzută de toate nodurile, incluzând atât nodul (nodurile)
de transmisie și nodul de recepție. Dacă o logic ă 0 este transmisă de către toate nodurile de
transmisie în același timp, atunci o logică 0 este văzută de toate nodurile. Dacă o logică 0
este transmisă de unul sau mai multe noduri și o logică 1 este transmisă de unul sau mai
multe noduri, atunci o logică 0 este văzută de către toate nodurile incluzând nodul (nodurile)
care transmit semnalul logic 1. Când un nod transmite o logică 1, dar vede o logică 0, își dă
seama că există o dispută și se oprește din transmitere. Prin utilizarea acestui proces, orice
nod care transmite o logică 1 atunci când un alt nod transmite un logic 0 "abandonează" sau
pierde arbitrajul. Un nod care pierde arbitraj re -cedează mesajul pentru transmisia ulterioară,
iar fluxul de biți din cadrul CAN continuă fără eroare, până când un singur nod este lăsat să
transmită. Aceasta înseamnă că nodul care transmite primul 1 pierde arbitrajul. Deoarece
identificatorul de biți 11 (sau 29 pentru CAN 2.0B) este transmis de toate nodurile la

34
începutul cadrului CAN, nodul cu cel mai mic identificator transmite mai multe zerouri la
începutul cadrului și acesta este nodul care câștigă sau are cea mai mare prioritate.

2.5.2 Protocolul ISO 15765 -2
Este un standard internațional pentru transmiterea pachetelor de date pe magistrala CAN.
Protocolul permite transportul mesajelor care depășesc sarcina utilă maximă de 8 octeți a
cadrelor CAN. ISO -TP( Transport Layer from OSI Model) segmentează mesajele ma i lungi
în mai multe cadre, adăugând metadate care permit interpretarea cadrelor individuale și
reasamblarea într -un pachet de mesaje complet de către destinatar. Acesta poate transporta
până la 4095 octeți de încărcătură utilă pe pachet de mesaje. [11]
Caracteristici:
▪ Pin 6: CAN – H
▪ Pin 14: CAN – L
▪ Viteză de transfer a datelor de 250 kBit/s sau de 500 kBit/s [8]

Fig. 2.8 Utilizarea pinilor la protocolul ISO 15765 -2

35

Capitolul 3. Soluții National Instruments pentru diagnoză
auto prin CAN

Eficiența comunicării prin interfața CAN i -a făcut pe cei de la National Instruments (NI) să
realizeze numeroase echipamente hardware și soluții software pentru dezvoltarea acestui tip de
comunicare. Aceștia oferă interfețe CAN pentru platforme precum: Peripheral Component
Interconnect -PCI, PCI Extensions for Instrumentation -PXI, Universal serial bus -USB, Personal
Computer Memory Card Internațional Associat ion-PCMCIA, NI CompactRIO și NI
CompactDAQ.
3.1 Interfața NI -XNET CAN

Aceste interfețe sunt concepute pentru aplicațiile care necesită manipulare în timp real la o viteză
foarte mare, cum ar fi monitorizarea unor conexiuni, controlul automatizărilor și multe altele.
Interfeț ele NI -XNET combină CAN, LIN, FlexRay cu API NI -XNET, pentru a citi și scrie cadr e
și semnale LIN și CAN.
NI-XNET are la bază dispozitivul DMA, care reduce latența semnalului, acest lucru fiind o
vulnerabilitate pentru CAN -urile care se bazau pe PC.
PCI-ul convențional (PCI este un acronim provenind de la Peripheral Component Intercon nect) ,
este o magistrală pentru atașarea componentelor hardware din alcătuirea unui calculator , fiind o
parte din standardul PCI Local Bus. Aceste dispozitive pot fi sub forma unui card de expansiune
care se insereaza într -un slot sau poate fi un circuit i ntegrat montat direct pe placă. În ultimul
timp, PCI -ul convențional a fost schimbat cu PCI -X și PCI -Epress.

Tipuri de PCI:
PCI 8512 cu un port – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza maximă | minimă : 1 Mbits / s | 40 kbits / s

36
✓ Aparat de emisie -recepție: Philips TJA104 1
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz Fig 3.1. PCI 8512, 1 port
✓ Lungime X Lățime : 20.7 X 11.18 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [12]
PCI 8512 cu 2 porturi – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 2
✓ Stratul fizic : de mare viteza
✓ Viteza maximă | minimă : 1 Mbits / s | 40 kbits / s
✓ Aparat de emisie -recepție: Philips TJA104
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime X Lățime: 20.7 X 11.18 cm
✓ Conector intrare -ieșire: 9 pini Fig. 3 .2. PCI 8512, 2 porturi
✓ Temperatura de oper are: 0 °C – 55 °C [12]
PCI 8511 cu un port – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza maxima : 125 kbits / s
✓ Viteza minima : 40 kbits / s
✓ Aparat de emisie -recepție: Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime X Lățime: 20.7 X 11.18 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [13] Fig. 3.3 PCI 8511, 1 port
PCI 8511 cu 2 porturi – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows

37
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza maximă | minimă : 125 kbits / s | 40 kbits / s
✓ Aparat de emisie -recepție: Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime: 20.7 x 11.18 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [13] Fig. 3 .4. PCI 8511, 2 porturi
PCI 8513 cu 1 port – considerații tehnice :
✓ Face parte di n familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza maximă | minimă : 1 Mbits / s | 33.333 kbits / s
✓ Aparat de emisie -recepție: Philips AU5790 , Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime : 20.7 cm x 11.18 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [14] Fig. 3 .5 PCI 8513, 1 port
PCI 8513 cu 2 porturi – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 2
✓ Stratul fizic : de mare viteza
✓ Viteza maximă | minimă : 1 Mbits / s | 33.333 kbits / s
✓ Aparat de emisie -recepție: Philips AU5790 , Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime : 20.7 cm x 11.18 cm
✓ Conector intrare -ieșire: 9 pini Fig. 3.6 PCI 8513, 2 porturi

38
✓ Temperatura de operare: 0 °C – 55 °C [14]

3.2 Module PXI (PCI Extensions for Instrumentation)
PXI-8512 cu 1 port – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza maximă | minimă : 1 Mbits / s | 40 kbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz Fig. 3.7 PXI 8512, 1 port
✓ Conectorrare -ieșire: 9 pini
✓ Lungime x Lățime : 20.7 cm x 11.18 cm
✓ Temperatura de operare: 0 °C – 55 °C [15]

PXI-8512 cu 2 porturi – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 2
✓ Stratul fizic : de mare viteza
✓ Viteza maximă | minimă : 1 Mbits / s | 3 kbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips TJA1041,
Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime : 20.7 cm x 11.18 cm Fig. 3 .8 PXI 8512, 2 porturi
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [15]

39
NI PXI -8511 cu 1 port – considerații tehnice :
✓ Face parte din famil ia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mica viteza
✓ Viteza maximă | minimă : 125 kbits / s | 40 kbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime : 20.7 cm x 11.18 cm
✓ Conector intrare -ieșire: 9 pini Fig.3.9 PXI 8511, 1 port
✓ Temperatura de operare: 0 °C – 55 °C [16]
NI PXI -8511 cu 2 porturi – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 2
✓ Stratul fizic : de mica viteza
✓ Viteza maximă | minimă : 125 kbits / s | 40 kbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Phili ps TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime : 20.7 cm x 11.18 cm
✓ Conector intrare -ieșire: 9 pini Fig. 3 .10 PXI 8511, 2 porturi
✓ Temperatura de operare: 0 °C – 55 °C [16]
NI PXI -8513 cu 1 port – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza/mica viteza cu toleranta
✓ Viteza maximă | minimă : 125 kbits / s | 40 kbits / s

40
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime : 20.7 cm x 11.18 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [17]

Fig. 3.11 PXI 8513, 1 port
NI PXI-8513 cu 2 porturi – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 Vrms
✓ Curentul nominal : 640 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza/mica viteza cu toleranta
✓ Viteza maximă | minimă : 1 Mbits / s | 33.333 kbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 1 MHz,10 MHz,20 MHz
✓ Lungime x Lățime : 20.7 cm x 11.18 cm
✓ Conector intrare -ieșire: 9 pini Fig. 3 .12 PXI 8513, 2 porturi
✓ Temperatura de operare: 0 °C – 55 °C [17]
NI PXI -8510 cu 2 porturi – considerații tehnice :
✓ Face parte din familia CAN/LIN
✓ Sistem de operare : Windows/Sistem de operare timp
real
✓ Numarul de porturi : 2
✓ Sincronizare Hardware : da

Fig. 3.13 PXI 8510, 2 porturi

41

NI PXI -8510 cu 6 porturi – considerații tehnice :
✓ Face parte din familia CAN/LIN
✓ Sistem de operare : Windows/Sistem de operare timp real
✓ Numarul de porturi : 6
✓ Sincronizare Hardware : da

Fig. 3 .14 PXI 8510, 6 porturi

3.3 Module CAN pentru platformă CompactDAQ (Data Acquisition)
NI CompactDAQ este un sist em modular care poate achiziționa de date și pe care le poate
transmite prin USB, Ethernet și Wi -Fi. De asemenea, aceasta platformă oferă măsurători
electrice și ale senzorilor în diferite locuri precum: bancul de lucru, în teren sau pe linia de
producție. Puteți combina aceste măsurători mixte cu comunicații , tip CAN, în aceeași platformă
hardware pentru a permite un sistem flexibil, care poate fi modif icat pentru a satisface nevoile
specifice ale proiectului. Modulele NI 986x CAN sunt reprezentate de 1 -port de mare viteză/FD
și interfețe NI -Xnet CAN, de mica viteza, care sunt programate cu un nivel superior NI-XNET
API. Aceste modul e sunt dotate cu un API comun, care este utilizat pentru alți factori de f ormă
ce lucrează cu hardware -ul NI-XNET, inclusiv PCI, PXI, NI CompactDAQ, și CompactRIO. Ca
parte a platformei NI -XNET, interfețele 986x NI funcționează bine pentru aplicații care n ecesită
manipulare de mare viteză a sute de cadre și semnale CAN.

3.4 Module CAN pentru platformă CompactRIO
NI CompactRIO este un controler programabil folosit pentru achiziția de date, având o
performanță ridicată la un preț de achiziție mic. Acest controler se alimentează folosind
tehnologia reconfigurabilă a porților programabile în câmp de matrice (FPGA). Pentru
comunicare sunt folosite module CAN . În funcție de viteza dorită putem alege interfața CAN a
NI 9853 (viteză redusă) sau NI -XNET cu inter fețele 986x, pentru o viteză mare .

42
3.5 Module CAN USB
Aceste module prezintă interfețe USB de mare viteză, care se conectează la PC. De exemplu,
interfețele NI USB -847x au o largă aplicabilitate, în special în monitorizarea rețelelor de la
bordul autov ehiculelor. De asemnea, interfețele NI USB -986x reprezintă o variantă și mai rapidă,
dar mai ales o variantă cu o sincronizare mult mai bună, deoarece aceste interfețe se bazează pe
produse NI -XNET care sunt ideale pentru comunicarea CAN.
Tipuri de USB:
NI USB -9862 XNET cu 1 port viteza mare – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza minimă | maximă : 40 kbits / s | 4 Mbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 20 MHz
✓ Lungime x Lățime : 13.1 x 8.86 cm
✓ Conector intrare -ieșire: 9 pini Fig. 3 .15 USB -9862 XNET, 1 port
✓ Temperatura de operare: 0 °C – 55 °C
NI USB -9862 XNET cu 1 port viteza mica – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Numarul de porturi : 1
✓ Stratul fizic : de mica viteza
✓ Viteza minimă | maximă : 40 kbits / s | 125 k bits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 20 MHz
✓ Lungime x Lățime : 13.1 x 8.86 cm
✓ Conector intrare -ieșire: 9 pini Fig. 3.16 USB -9862 XNET, 1 port
✓ Temperatura de operare: 0 °C – 55 °C

43

NI USB -8473 cu 1 port viteza mare – considerații tehnice :

✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 VDC
✓ Curentul nominal : 250 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza minimă | maximă : 40 kbits / s | 1 Mbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 20 MHz
✓ Lungime x Lățime: 7.87 x 6.35 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C Fig. 3.17 USB-8473, 1 port
NI USB -8473 cu 1 port viteza mare cu sincronizare – cons iderații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 VDC
✓ Curentul nominal : 250 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mare viteza
✓ Viteza minimă | maximă : 40 kbits / s | 1 Mbits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 1,10,20 MHz
✓ Lungime x Lățime: 7.87 x 7.11 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [18] Fig. 3.18 USB -8473, 1 port
NI USB -8472 cu 1 port viteza mica – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows

44
✓ Tensiunea nominala : 5 VDC
✓ Curentul nominal : 250 mA
✓ Numarul de porturi : 1
✓ Strat ul fizic : de mica viteza
✓ Viteza minimă | maximă : 5 kbits / s | 125 k bits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecvente de sincronizare: 20 MHz
✓ Lungime x Lățime: 7.87 x 6.35 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C

Fig 3.19 USB -8472, 1 port
NI USB -8472s cu 1 port viteza mica cu sincronizare – considerații tehnice :
✓ Face parte din familia CAN
✓ Sistem de operare : Windows
✓ Tensiunea nominala : 5 VDC
✓ Curentul nominal : 250 mA
✓ Numarul de porturi : 1
✓ Stratul fizic : de mica viteza
✓ Viteza minimă | maximă : 5 kbits / s | 125 k bits / s
✓ Aparat de emisie -recepție: Philips AU5790, Philips
TJA1041, Philips TJA1054A
✓ Frecven țe de sincronizare: 1,10,20 MHz
✓ Lungime x Lățime: 7.87 x 7.11 cm
✓ Conector intrare -ieșire: 9 pini
✓ Temperatura de operare: 0 °C – 55 °C [19] Fig. 3.20 USB-8472s, 1 port

45
Capitolul 4 . Implementarea hardware a sistemului
4.1 Obiective proiectului
Realizarea în LabView a unei aplicații software de diagnoză pentru autovehicule, pentru a
monito riza diverși parametrii precum: v iteza , turație motor , nivel combustibil din rezervor ,
temperatură lichid răcire , consumul instantaneu de combustibil , tensiunea bateriei , indicator
MIL, etc.
Realizarea proiectului constă în două etape principale:
• partea hardware a proiectului conține un cablu OBD -CAN, o i nterfață CAN -USB NI
8473 și laptopul pe care rulează aplicația software .
• Partea software constă în d ezvolta rea unei aplicații software, în LabVIEW utilizând
toolboxul Automotive Diagnostic Command Set (ADCS) care va permite comunicarea cu
unitățile de control electronice ale autovehiculului, afișarea numerică și grafică, în timp
real, a parametrilor de funcționare ai autovehiculului, și opțional transmiterea de comenzi
AT și afișarea răspunsurilor, precum și afișarea și ștergerea codurilor de defect.

46
4.2 Schema bloc a sistemului

Fig. 4.1 Schema bloc a sistemului

Este nevoie de 3 lucruri pentru a face acest proiect funcț ional .
A. Un calculator/laptop pe care să ruleze programul LabVIEW
B. O interfată de comunicație cu cablurile aferente
C. Un autovehicul care sa aibă mufa OBD c e dispune de pinii pentru CAN
Funcționarea sistemului:
ECU va transmite către portul OBD o serie de semnale care corespund diferiților parametrii . Cu
ajutorul interfeței CAN, aceste semnale sunt preluate de la mufa OBD și transmise către laptop
unde cu ajutorul mediului de dezvoltare LabView vom decodifica semnalele și vom afișa
parametrii pe care dorim să îi m onitorizăm.

47

4.3 Prezentarea componentelor hardware

4.3.1 . Specificațiile necesare calculatorului/laptopului pentru rularea
programului LabVIEW

Tabel 4.1 Specificațiile necesare rulării pe Windows a programului LabVIEW
Windows Specificații PC Run-Time Engine
Procesor Pentium 4M sau versiuni ulterioare (32 –
biți)
Pentium 4 G1 sau versiuni ulterioare (64 –
biți) Pentium 4M/Celeron 866 MHz sau
versiuni ulterioare (32 -biți)
Pentium 4 G1 sau versiuni
ulterioare (64 -bit)

RAM 1 GB 256 MB
Rezoluție ecran 1024 x 768 pixels 1024 x 768 pixels
Sistem operare Windows 10/8.1/8/7 SP1 (32 și 64 -biți)
Windows Server 2012 R2 (64 -biți)
Windows Server 2008 R2 SP1 (64 -biți) Windows 10/8.1/8/7 SP1 (32 și 64 –
biți)
Windows Server 2012 R2 (64 -biți)
Windows Server 20 08 R2 SP1 (64 –
biți)
Spațiu liber 5GB (sunt incluse driverele necesare de
la
NI Device Drivers ) 620 MB

Tabel 4.2 Specificațiile necesare rulării pe Mac OS x a programului LabVIEW
Mac OS x Specificații PC Run-Time Engine
Procesor Procesor Intel Procesor Intel
RAM 2 GB 256 MB
Rezoluție ecran 1024 x 768 pixels 1024 x 768 pixels
Sistem operare OS X 10.11 or 10.12 OS X 10.11 or 10.12
Spațiu liber 1.4 GB necesari pentru instalarea
completă (excluzând driverele) 257 MB

48
Tabel 4.3 Specificațiile necesare rulării pe Linux a programului LabVIEW
Linux Specificații PC Run-Time Engine
Procesor
Pentium 4M sau versiuni ulterioare (32 –
biți)

Pentium 4 G1 sau versiuni ulterioare (64 –
biți)
RAM 1 GB
Rezoluție ecran 1024 x 768 pixels 1024 x 768 pixels
Sistem operare Red Hat Enterprise Linux Desktop +
Workstation 6.5 sau ulterior, open SUSE
LEAP 42.1, open SUSE Leap 42.2,
Scientific Linux 6.5 sau ulterior, CentOS
7
Spațiu liber 1.1 G B necesari pentru instalarea comple
tă 108 MB (32-bit)

98 MB (64 -bit)
[20]

4.3.2 . Interfața utilizată
Aplicația realizată permite utilizarea mai multor interfețe precum NI -XNET sau NI -CAN. La fel
ca și mediul de dezvoltare, cele două interfețe sunt realizate de către firma Nationa Instruments.
În cazul de față i nterfața utilizată este NI -XNET care este alcătuită din următoarele componente
hardware:
• Modul NI 9862 din seria XNET (1 port CAN, 1 Mbps, transceiver Philips TJA1041,
sincronizare la 20 MHz)
• Șasiu NI cDAQ -9171 din seria CompactDAQ (1 slot)
• Cablu diagnoză auto NI CAN OBD -II

A. Modulul NI 9862

NI-9862 este o interfață CAN care se folosește în aplicații de dezvoltare împreună cu driverul
NI-XNET. Având o rată de date cu viteză mare, aceasta se folosește în aplicații care necesită
manipularea în timp real , precum: monitorizarea magistralelor de date, simularea hardware -in-
the-loop, diagnoza auto și multe altele.

49

Fig. 4.2 Modulul NI 9862

Cablajul interf eței NI 9862

Pentru conectarea la magistrala CAN, este folosit un conector D -Sub cu 9 pini tată . Doi dintre
pini sunt pentru CAN_H, respectiv CAN_L, pini la care se conectează magistrala CAN. Alți doi
pini comuni (COM) care sunt conectați intern și servesc ca referință pentru CAN_H și CAN_L.
De asemenea, exista si un pin opțional SHLD care are rolul de imbunătățire a integrității
semnalului, crescând astfel performanța în mediile zgomotoase.

50
Tabelul 4.4 Asignarea pinilor la interfața NI 9862

Topologia magistrala CAN

O magistrală CAN este alcătuită din două sau mai multe noduri CAN cablate împreună. PIN-
urile CAN_H și CAN_L ale fiecărui nod sunt conectate la cablul principal CAN printr -o
conexiune s curtă cunoscută sub numele de "Stub." Perec hea de fire de semnal, CAN_H și
CAN_L, constituie o linie de transmisie. Dacă linia de transmisie nu este terminată, f iecare
schimbare a semnalului de pe magistrală provoacă reflexii care ar putea provoca e rori de
comunicare. Deoarece magistra la este un bidirecțională, rezultă că ambele capete ale cablului
trebuie să fie conectate. Cu toate acestea, acest lucru nu implcă faptul că fiecare nod al
magistralei trebuie să aibă o rezistență ca și terminație, ci doar cele două noduri corespunzătoare
extremităților.

51

Fig. 4.3 Magistrala CAN cu multiple noduri și rezistențe terminale corespunzătoare

Legătura interfeței NI 9862 cu magistrala CAN se face prin conectarea portului interfeței în orice
locație a magistralei. Numărul maxim de noduri depinde de caracteristica electrică a nodorilor
rețelei. Dacă toate nodurile îndeplinesc cerințele ISO 11898, se pot conecta până la 30 de noduri
pe o magistrală.
NI 9862 are un port CAN complet echipat, care este izolat de celelalte module din sistem. Portul
are un controler Bosh DCAN care este compatibil atât cu idendificatori de 11 biți, cât si de 29
biți. De asemenea, portul are și un receptor NXP TJA1041AT de mare viteză, suportând pâna la
1Mbps.

Fig. 4.4 Prezentare hardware generală a NI 9862

52
Specificații NI 9862

• Transceiver: NXP TJA1041AT
• Baud rate: max 1Mbps
• Tensiunile pe liniile CAN_H și CAN_L: -27 până la 40 VDC
• Tensiunea de alimentare (Vsup) :+9 până la 30 VDC
• Puterea consumată de la șasiu: 1W (modul activ)
• Puterea disipată (la 70 ℃): 1.25W (modul activ)
• Greutate: aprox. 144g
[21]
B. Șasiul NI cDAQ -9171

cDAQ‑9171 este un șasiu CompactDAQ USB alimentat de la magistrală creat pentru sisteme de
masurare care folosesc senzori mici și portabili. Acest șasiu a împrumutat de la USB simplitatea
plug-and-play. Un rol important al cDAQ‑9171 este acela de a controla sincronizarea și
transferul de date î ntre modulele I/O din seria C și un host extern. De asemenea, CDAQ -9171 are
patru timere de 32 de biți care pot fi accesate prin intermediul unui modul digital instalat, cu
temporizare digitală, pentru aplicații care implică codificatoare de cadre, PWM, nu mărarea
evenimentel or, generarea impulsurilor și a perioade lor sau d e măsurare a frecvenței. [22]

Fig. 4.5 Șasiul NI cDAQ‑9171

53
C. Cablu diagnoză auto NI CAN OBD -II

Cablul conectează toate interfețele CAN de mare viteză cu un vehicul dotat cu mufa OBD II ,
care are pe conectorul de diagnosticare din habitaclu, protocolul CAN. Acest cablul are rolul de a
transporta datele către interfața CAN, aceasta comunicând cu PC -ul.
De reținut că nu toate vehiculele compatibile cu caracteristica OBD -II CAN pot fi conectate la
conectorii lor de diagnosticare. Vehiculele vândute în Statele Unite după modelul anului 2008
trebui e să aibă CAN, unele autovehicule poseda conectorul OBD -II după 2003. V ehiculele mai
vechi nu au, în general, CAN. În mod tipic, dacă pinii vehiculului pentru CAN sunt populați în
conectorul de diagnosticare (CAN_H – Pin 6 și CAN_L – Pin 14), vehiculul utilizează CAN
pentru comunicațiile sale de diagnosticare. [23]

54

55
Capitolul 5. Implementarea software

5.1 Mediul de dezvoltare LabVIEW
LabVIEW este un mediu de programare grafic bazat pe nucleul de limbaj G
(limbaj grafic), destinat în special construirii de aplicații pentru controlul și achiziția de
date, analiza acestora și prezentarea rezultatelor. Menționam câteva dintre cele mai
importante caracteristici ale acestui mediu:
• rezolvă automat majoritatea problemelor legate de gestionarea resurselor hardware și
comunicația cu sistemul de operare, iar în acest fel utilizatorul se poate concentra
asupra problemei concrete pe care o are de rezolvat și nu asupra funcționării
calculatorului. Ca de exemplu, aproape toate nodurile (funcțiile), precum și graficele,
sunt polimorfice, ad ică se adaptează la orice tip de date, fie că sunt valori reale
simple sau structuri de date;
• limbajul grafic este mult mai compact, diagrama conținută într -o fereastră conține
mai multă informație decât un text și este mai ușor de citit și de înțeles, iar
desenarea unei diagrame este mai rapidă decât scrierea unui text echivalent;
• în limbajul grafic paralelismul este natural, astfel încât scrierea de programe care
efectuează procesarea paralelă a datelor este la fel de simplă ca și pentru
procesarea sec vențială;
• permite lucrul în rețea, pe mai multe calculatoare, prin intermediul TCP/IP și
UDP, dispunând de numeroase funcții pentru lucrul în rețele locale (de arie mare)
sau prin Internet;
• conține multe aplicații prefabricate, din diverse domenii, împreu nă cu codul G
corespunzător, care pot fi folosite direct, pot fi luate ca exemple didactice de
programare sau pot fi modificate de utilizator pentru a satisface cât mai bine
necesitățile concrete de lucru.
Toate soluțiile LabVIEW lucrează implicit în regi m multithreading, fără a
necesita o programare suplimentară. În acest fel, se poate reduce semnificativ timpul
necesar punerii la punct a aplicațiilor.
Aplicațiile (programele) realizate în LabVIEW poartă denumirea de Instrumente
Virtuale (în engleză, Virt ual Instruments, prescurtat VI). Denumirea provine de la faptul
că, în primele sale versiuni, LabVIEW a fost strict dedicat pentru realizarea unor
programe de monitorizare a proceselor. Programele respective înlocuiau o serie de
aparate și instrumente elec tronice – de unde și motto -ul corporației Național Instruments:
The software îs the instrument – primind astfel denumirea de Instrumente Virtuale.

56

Ferestrele principale ale aplicației:

Mediul de dezvoltare are dou ă ferestre principale: Front Panel și Diagrama Bloc.
Fig. 5 .1. Panoul și diagrama din LabVIEW.

Panoul (Front Panel) reprezintă interfața grafică cu utilizatorul, fereastra pe care
utilizatorul o va vedea atunci când va accesa aplicația realizată. Prin intermediul elementelor de
pe panou, aplicația primește datele de intrare și afișează apoi datele de ieșire ce au rezultat în
urma rulării .
Diagrama (Block Diagram) este fereastra în care programatorul descrie algoritmul după
care aplicația va efect ua calculele și raționamentele necesare pentru prelucrarea informațiilor. În
majoritateacazurilor, după ce programatorul a realizat o aplicație și a livrat -o unui utilizator,
acesta din urmă nu mai are acces la diagramă . [25]

57
5.2 Toolbox -ul Automotive Diagnostic Command Set

Acest toolbox a fost conceput pentru a ajuta la proiectarea aplica țiilor de diagnosticare automată
pentru producțiile unităților de comandă (ECU), care utilizează protocoale precum: Keyword
Protocol 2000, Diagnostics over IP și Diagnostics on CAN . Setul de aplicații al acestei biblioteci
permite citirea parametrilor, accesarea codurilor de diagnosticare a erorilor (DTC -uri) și inițierea
modurilor de testare/diagnosticare a ECU.

Fig. 5.2 Toolbox -ul ADCS în paleta de funcții a programului LabVIEW

58

Fig. 5.3 Structura Automotive Diagnostic Command Set

Setul de comandă pentru diagnosticarea automobilelor este structurat în trei straturi de
funcționalitate:
• stratul superior implementează trei seturi de s ervicii de diagnosticare pentru
protocoalele de diagnosticare KWP2000, UDS (DiagOnCAN) și OBD (On-Board Diagnostics)
• cel de -al doilea strat implementează rutine gener ale care implică deschiderea și înc hiderea
conexiunilor de comunicație de diagnosticare, conectar ea și d econectarea la / de la un ECU și
executarea unui serviciu de diagnosticare l a nivel de bit . Ultima rutină este cea pe care stratul
superior o folosește foarte mult.
• cel de -al treilea strat implementează protocoalele de transport necesare pentru d iagnosticare a
ECU -lui. Cel de -al doilea strat folosește acestea r utine pentru a comunica cu un ECU.

59
Toate cele trei straturi de top se pot implementa în LabVIEW. Protocoalele de transport
execută apoi operațiile CAN / LIN Read / WritePrintr -un DLL specializat pentru raționalizarea
fluxului de date CAN / LIN, în special în situații de încărcare mai ridicată. În continuare vor fi
prezentate VI-urile din LabVIEW pentru ADCS, folosite în aplicație :

Tabelul 5.1 VI -urile utilizate în aplicația software
Funcție Scop
Close Diagnostic.vi Închide o sesiune de diagnosticare
OBD Clear Emission Related Diagnostic
Information.vi Golește emisiile legate de codurile de diagnosticare a
erorilor(DTC) în ECU
OBD Request Current Powertrain Diagnostic
Data.vi Citește anumite date din ECU
OBD Request Supported PIDs.vi Execută OBD Request Current Powertrain Diagnostic
Data pentru a detecta ce PID -uri pot fi recepționate de la
ECU
OBD Request Vehicle Information.vi Citește informații de la ECU precum VIN -ul
Open Diagnostic.vi Deschide o sesiune de diagnosticare pe un port CAN,
dar comunicarea cu ECU încă nu începe

• Close Diagnostic.vi – Închide sesiunea de diagnosticare specificată de diag ref , iar
comunicarea cu ECU este oprită

Fig. 5.4 VI-ul Close Diagnostic.vi

Intrare

diag ref in specifică sesiunea de diagnosticare obținută de la OpenDiagnostic.vi și este
conectată prin intermediul VI -urilor ulterioare.

error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment) , iar valoarea 0 în seamnă

60
succes .
source identifică VI -ul unde a avut loc eroarea.

Ieșirea

error out descrie condițiile erorii. Dacă error in a indicat o eroare, error out va conține
aceiași informație, altfel error out va descrie statusul VI -ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 în seamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

• OBD Clear Emission Related Diagnostic Information.vi – Golește emisiile legate de
codurile de diagnosticare a erorilor(DTC) în ECU

Fig. 5.5 VI -ul OBD Clear Emission Related Diagnostic Information.vi

Intrare

diag ref in specifică sesiunea de diagnosticare obținută de la OpenDiagnostic.vi și este
conectată prin intermediul VI -urilor ulterioare.

error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.

61
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 în seamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

Ieșirea
diag ref out este o copie a diag ref in
success ? indică primirea cu succes a unui mesaj de răspuns pozitiv pentru acest serviciu
de diagnoză.

error out este un cluster care descrie condițiile de eroare care apar, înainte de
executarea VI -ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul nu mărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 înseamnă
succes.
source identifică VI-ul unde a avut loc eroarea.

• OBD Request Current Powertrain Diagnostic Data.vi – Citește anumite date din ECU

Fig. 5.6 VI -ul OBD Request Current Powertrain Diagnostic Data.vi

Intrare

diag ref in specifică sesiunea de diagnosticare obținută de la OpenDiagnostic.vi și este
conectată prin intermediul VI -urilor ulterioare.

62
PID identificatorul parametrului care se dorește a fi citit . Standardul SAE J1979
definește valorile.

error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 în seamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

Ieșirea
diag ref out este o copie a diag ref in
data out returnează înregistrarea de date de la ECU, urmând să se facă interpretarea
acestor date.
success ? indică primirea cu succes a unui mesaj de răspuns pozitiv pentru acest serviciu
de diagnoză.

error out este un cluster care descrie condițiile de eroare care apar, înainte de
executarea VI -ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 înseamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

63
• OBD Request Supported PIDs.vi – detectează ce PID -uri pot fi recepționate de la ECU

Fig. 5.7 VI -ul OBD Request Supported PIDs.vi

Intrare

diag ref in specifică sesiunea de diagnosticare obținută de la OpenDiagnostic.vi și este
conectată prin intermediul VI -urilor ulterioare.

error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 în seamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

Iesirea

diag ref out este o copie a diag ref in
data out returnează înregistrarea de date de la ECU, urmând să se facă interpretarea
acestor date.
error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul număru lui codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 înseamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

64
• OBD Request Vehicle Information.vi – Citește informații de la ECU

Fig. 5.8 VI -ul OBD Request Vehicle Information.vi

Intrare

diag ref in specifică sesiunea de diagnosticare obținută de la OpenDiagnostic.vi și este
conectată prin intermediul VI -urilor ulterioare.
PID identificatorul parametrului care se dorește a fi citit. Standardul SAE J1979
definește valorile.
error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul număru lui codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 înseamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

Ieșirea
diag ref out este o copie a diag ref in
data out returnează înregistrarea de date de la ECU, urmând să se facă interpretarea
acestor date.
success ? indică primirea cu succes a unui mesaj de răspuns pozitiv pentru acest serviciu
de diagnoză.
error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar V I-ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă

65
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 înseamnă
succes.
source identifică VI -ul unde a avut loc eroarea.
items este numarul de elemente de date (nu octeți) pe care acest serviciu le returnează

• Open Diagnostic.vi – Deschide o sesiune de diagnosticare pe un port CAN, dar
comunicarea cu ECU încă nu începe

Fig. 5.9 VI -ul Open Diagnostic.vi

Intrare

CAN interface specifică interfața CAN pe care se află sesiunea de diagnosticare.
baudrate este rata de comunicare a sesiunii de diagnosticare.
transport protocol specifică protocolul de transport pentru transferul mesajelor de
diagnosticare prin rețeaua CAN.
transmit ID este identificatorul CAN pentru trimiterea mesajelor de diagnosticare de la
gazdă către ECU.
receive ID este identificatorul CAN sau mesajul de diagnosticare transmis de la ECU
către gazdă.
error in este un cluster care descrie condițiile de eroare care apar, înainte de executarea
VI-ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă

66
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 înseamnă
succes.
source identifică VI -ul unde a avut loc eroarea.

Iesirea

error out descrie condițiile erorii. Dacă error in a indicat o eroare, error out va conține
aceiași informație, altfel error out va descrie statusul VI -ului.
dacă a apărut o eroare, statusul este TRUE, iar VI -ul nu mai este executat.
code este cel care identifică eroarea cu ajutorul numărului codului erorii
respective. O valoare negativă înseamnă eroare (VI -ul nu a fost executat), o valoare pozitivă
înseamnă avertizare (VI -ul este executat, dar a avut loc un avertisment), iar valoarea 0 înseamnă
succes.
source identifică VI -ul unde a avut loc eroarea.
[24]

67
5.3 Organigrama funcțională a programului implementat

Fig. 5.10 Organigrama aplicației software din LabVIEW

68
După ce am realizat conexiunile hardware ale sistemului, putem începe pornirea aplicației
software. Inițial se setează anumiți parametri i precum: portul CAN, interfața hardware folosită
(NI-CAN sau NI -XNET) , baudrate -ul, protocolul de transport, ID-ul de transmisie, respectiv
recepție. Dacă setarea parametrilor nu este facută în mod corect, va fi generată o eroare care nu
va permite rularea aplicației. După setarea parametrilor, în mod corespunzător, deschidem
sesiunea de diagnosticare , facând interogarea parametrilor acceptați de autovehicul. De
asemenea, dacă există în aplicație există paramet rii care cer date de la ECU, iar ECU acelui
autovehicul nu are acel PID activ, va fi generată o eroare, care va face ca afișarea celorlalți
parametrii să nu mai fie în timp real, ci cu o mică întârziere. Cât timp sesiunea de diagnosticare
este pornită, apl icația va citi date de la ECU, date care vor fi prelucrate, iar apoi afișate în front
panel. După ce am achiziționat informațiile necesare, închidem sesiunea de diagnosticare,
moment în care aplicația nu mai solicită informații de la ECU, deci în front pan el nu vor mai fi
afișate valorile PID -urilor.

5.4 Detalierea anumitor PID -uri din diagrama bloc

A. Temperatura lichidului de răcire

Fig. 5.11 Diagrama bloc a Pid -ului Engine Coolant Temperature

Lege de transformare: A -40

69
B. Numarul de rotații pe minut al motorului

Fig. 5.12 Diagrama bloc a PID -ului Engine RPM

Legea de transformare: (256*A+B)/4

70
Concluzii

➢ Inițial, comunicația trebuia să se facă prin interfața NI CAN, dar din cauza dificultăților
pe care le -am întâmpinat în instalarea driver -ului, a fost nevoie de schimbarea interfeței
cu NI -XNET.
➢ Aplicația poate fi utilizată pentru toate autovehiculele care posedă mufa de diagnoză
OBD II, aceasta fiind obligatorie din anul 2008 pe toate mașinile.
➢ Un alt aspec t care prezintă interes este reprezentat de moficarea dinamicii interfeței în
funcție de condurile PID suportate de autovehicul.

71

Bibliografie

[1] http://www.scientia.ro/tehnologie/constructia -si-functionarea -automobilului/6617 -automobil –
structura -si-parti-componente.html
[2] http://www.cnblogs.com/shangdawei/p/3235907.html
[3] http://en.wikipedia.org/wiki/Engine_control_unit
[4] https://en.wikipedia .org/wiki/On -board_diagnostics
[5] Stone,M, Introduction to SAE1850, In vehicle networks , 2008
[6] Comparison of Event -Triggered and Time -Triggered Concepts with Regard to Distributed
Control Systems A. Albert, Robert Bosch GmbH Embedded World, 2004, Nürnb erg
[7] VAD Pro -901 OBD -II Universal Standards;
[8] http://www.onboarddiagnostics.com/page03.htm
[9] ISO9141 -2 and J1939 Protocols on OBDII , 2002, pp. 1 -40
[10] https://en.wikipedia.org/wiki/CAN_bus
[11] https://en.wikipedia.org/wiki/ISO_15765 -2
[12] http://www.ni.com/ro -ro/support/model.pci -8512.html
[13] http://www.ni.com/ro -ro/support/model.pci -8511.html
[14] http://www.ni.com/ro -ro/support/ model.pci -8513.html
[15] http://www.ni.com/ro -ro/support/model.pxi -8512.html
[16] http://www.ni.com/ro -ro/support/model.pxi -8511.html
[17] http://www.ni. com/ro -ro/support/model.pxi -8513 .html
[18] http://sine.ni.com/nips/cds/view/p/lang/ro/nid/203384
[19] http://sine.ni.com/nips/cds/view/p/lang/ro/nid/203 387

72
[20] http://www.ni.com/white -paper/53740/en/
[21] http://www.ni.com/pdf/manuals/373243c.pdf
[22] http://www.ni.com/pdf/manuals/374037b.pdf
[23] http://sine.ni.com/nips/cds/view/p/lang/ro/nid/211326
[24]http://www.ni.com/pdf/manuals/372139g.pdf
[25] https://biblioteca.regielive.ro/laboratoare/electronica/labview -254344.html

Tabel piduri