Sunteți pe pagina 1din 52

CUPRINS

1. Introducere
1.1 Industria automobilelor
1.2 Utilizarea electronicii în industria auto
1.3 Noutăț i în domeniu
1.4 Interfeț e de diagnoză auto

2. Monitorizarea parametrilor automobilului


2.1 Aplicaț ii existente pe piaț ă
2.2 Protocolul OBD II
2.3 Circuitul integrat ELM 327
3. Descrierea aplicaț iei
3.1 Arhitectura aplicaț iei
3.2 Tehnologii de implementare folosite
3.3 Modulul de monitorizare
4. Bibliografie
1. INTRODUCERE

1.1 Industria automobilelor


1.2 Utilizarea electronicii în industria auto
1.3 Interfeț e de diagnoză auto

2
1.1 Industria automobilelor

În anul 2009 au fost produse la nivel mondial mai mult de 60 de milioane de


autovehicule, incluzând automobile şi autoutilitare. Datorită acestor vânzări, industria
auto este cel mai important sector al economiei cu cele mai mari venituri.
În anul 2007 au fost vândute la nivel mondial un număr de 79.9 milioane de
automobile noi: 22.9 milioane în Europa, 21.4 milioane în Asia-Pacific, 19.4 milioane
în SUA şi Canada, 4.4 milioane în America Latină, 2.4 milioane în Orientul Mijlociu şi
1.4 milioane în Africa. Pieţele din America de Nord şi Japonia au stagnat, în timp ce
alte pieţe ca cele din America de Sud şi unele părţi din Asia au crescut puternic. Din
cele mai importante pieţe, China, Rusia, Brazilia şi India au cunoscut cele mai mari
creşteri; China devenind atât cel mai mare producător de automobile, cât şi cea mai
mare piaţă după masiva creştere din 2009. În primele 5 luni din 2010, numărul total de
automobile vândute a fost de 7.61 milioane în China (4.62 milioane în SUA) şi
numărul total de vânzări aşteptate este în jur de 17 milioane (13.65 milioane în 2009),
adică aproape dublu decât piaţa din SUA.
Aproape 250 milioane de autovehicule sunt utilizate în Statele Unite. La nivel
global erau în jur de 806 milioane de maşini şi camioane uşoare în anul 2007,
consumând aproximativ 982 miliarde de litrii de combustibil anual. Aceste date cresc
însă rapid, în special în China.
OEM(original Equipment Manufacturer)-urile din industria auto lucrează în mod
continuu la dezvoltarea de vehicule mai sigure, mai inteligente şi mai eficiente din
punct de vedere energetic. Multe dintre soluţiile implementate sunt datorate noilor
module de control electronic (ECM), făcând ca electronica să fie sectorul cu
dezvoltarea cea mai rapidă din cadrul elementelor auto. Microcontrolerele cu memorie
3
flash, înalt integrate, ce dispun de management energetic, se află la baza ECM-urilor, şi

sunt elemente cheie ale sistemelor embedded pe care proiectanţii le doresc pentru
implementarea în sistemele curente şi viitoare. Este tot mai pregnantă competiţia legată
de consumul energetic redus, constrângerile legate de spaţiul ocupat, conectivitatea
ECM pentru posibilitatea de diagnosticare a sistemului, în timp ce costurile trebuie
menţinute cât mai reduse. După cum numărul de ECM-uri continuă să crească,
disponibilul energetic necesar al vehiculului este sub o presiune din ce în ce mai mare.
Unele vehicule de înaltă clasă dispun de peste 80 de ECM-uri, ceea ce înseamnă sarcini
de curent foarte ridicate. O cale de a răspunde acestei cerinţe energetice poate fi
creşterea dimensiunilor bateriei. Însă, bateriile de dimensiuni mai mari nu sunt o
afacere într-un domeniu în care spaţiul este limitat, iar masa este critică pentru a
asigura un minim de consum de carburant. O opţiune mai bună este concentrarea
asupra cerinţelor de consum energetic ale ECM-urilor care operează atunci când
contactul este în stare off. Cu mai multe sarcini de putere prezente atunci când nu există

4
contact, OEM-urile auto restrâng disponibilul energetic la mai puţin de 1mA pe ECM.
O familie de microcontrolere cu management energetic este un element cheie pentru
proiectanţii de sisteme embedded în acest mediu, în care o mare valoare este pusă pe
operaţii eficiente energetic fără sacrificarea performanţelor.
Microcontrolerele cu management energetic oferă proiectantului memorie flash
pe cip, o eficienţă bună a sistemului, o robusteţe crescută cu minimizarea costurilor şi
spaţiului de placă, prin eliminarea componentelor externe. Designerii au la dispoziţie o
mai mare versatilitate prin posibilitatea de a comuta între diverse moduri de
management energetic, care încorporează rutine de economisire de energie în aplicaţiile
software. Tehnologia nanoWatt ce caracterizează microcontrolerele Microchip
Technology PICŽ oferă o bună gestionare energetică pe întreaga lor gamă de frecvenţe
de operare. Aceste caracteristici au fost dezvoltate pentru a le furniza proiectanţilor
opţiuni tehnice fezabile şi economice pentru provocările complexe asociate cu operarea
sigură de joasă putere.

1.2 Utilizarea electronicii în industria auto

Toata lumea vorbeste despre computerul auto. Se fac remapari, resoftari, chip-
tuning pentru a mari performantele masinii prin rescrierea softului computerului auto.
Când apare o eroare si masina nu mai vrea sa porneasca de pe loc, vinovat e
computerul auto. Când se defecteaza un senzor, computerul auto ne semnaleaza
defectul si ne trimite la mecanic fara sa ne acorde nici cea mai mica sansa de a rezolva
problema "în fata blocului"...

1.2.1 Calculator de bord sau ECU

(Electronic control unit, „Unitate de control electronic”) este un modul pentru comenzi
sau dirijări electronice, care este folosit în locurile unde ceva anume trebuie controlat
comandat. Modulul de control electronic este folosit în sectorul auto în multe aplicaţii

5
electronice, precum şi pentru controlul electronic la dirijarea de maşini, instalaţii
industriale şi multe alte procedee tehnice. Aceste modulele fac parte din sistemele

încorporate.

Ce se ascunde de fapt sub denumirile de "Computer


auto", ECU sau "Modul de comanda"? Ce face de fapt
acest computer auto si cum functioneaza el?
Sub denumirea generica de computer auto se ascunde
de fapt un numar mai mic sau mai mare de microprocesoare care au functii dedicate si
care controleaza functionarea diferitelor componente ale masinii. Exista
microprocesoare care monitorizeaza aprinderea motorului, altele care se ocupa de
functionarea airbag-urilor, altele de modulul de aer conditionat, de sistemele de
siguranta ABS sau ESP, chiar si de deschiderea sau închiderea geamurilor. Toate aceste
microprocesoare sunt, asa cum le spune si numele, niste calculatoare în miniatura care
ruleaza în memoria lor niste programe, primesc în permanenta date de la componentele
masinii si prin prelucrarea acestor date de catre programul din memorie, furnizeaza la
randul lor niste date de iesire, care se concretizeaza în comenzi transmise catre diferite
dispozitive ale masinii.
Pe buna dreptate ne putem întreba cum de au reusit în trecut masinile sa
functioneze foarte bine si fara aceste microprocesoare? Simplu. Motoarele erau simple,
electronica aproape inexistenta si metodele de protectie a pasagerilor mult mai
rudimentare. Pe masura ce au început sa apara elemente de comfort si siguranta tot mai
avansate, norme de poluare mai stricte si dorinta de a face economie de materiale,
constructorii auto au început sa apeleze la beneficiile aduse de utilizarea
microprocesoarelor si a metodelor de comunicatie moderne.
Practic s-a trecut la utilizarea microprocesoarelor din mai multe motive:
* pentru a simplifica procesul de construire a masinii
* pentru a reduce emisiile poluante ale motorului si a consumului de carburanti
* pentru a reduce cantitatea de cabluri necesare functionarii masinii
* pentru a îmbunatati metodele de diagnosticare a defectiunilor

6
* pentru a putea aduce noi facilitati fara a face modificari majore la designul si
componentele deja existente într-o masina
* nu în ultimul rând pentru cresterea sigurantei pasagerilor
Vom vedea în continuare cum au fost implementate fiecare din aceste masuri cu
ajutorul microprocesoarelor din autoturisme.

1.2.2 ECU - Engine Control Unit

ECU (îl mai gasiti si sub denumirea de UCM - Unitate de Control a Motorului)
este de obicei cel mai puternic microprocesor dintre toate care exista în masina pentru
ca este pus la treaba cel mai mult. Practic acesta are de facut milioane de calcule pe
secunda trebuind sa analizeze datele oferite de zecile de senzori amplasati prin toata
masina si apoi sa decida asupra celor mai bune valori care sa le transmita motorului
pentru ca acesta sa functioneze cu consum minim de carburant si sa polueze cat mai
putin mediul inconjurator.

Ce rol are de fapt acest ECU?


Rolul sau este de a comanda cantitatea de combustibil care intra în
camerele de ardere, momentul cel mai bun în care sa aiba loc aprinderea
amestecului combustibil si toate acestea in functie de viteza, temperatura
motorului si a mediului ambiant, de cantitatea de si din aerul aspirat de
motor.

Practic, ECU primeste aceste date de la senzorii


amplasati în motor si le foloseste ca parametri în
ecuatiile pe care le are de rezolvat pentru a produce
alte date de iesire care vor comanda mecanismele de
control ale motorului: injectoare, pompe, bujii.
ECU functioneaza ca un sistem de reglaj cu circuit închis (closed-loop control),
ceea ce înseamna ca el regleaza valorile parametrilor de iesire în functie de valorile

7
parametrilor de intrare. Cu alte cuvinte, el primeste date de la senzorii care
monitorizeaza cantitatea de oxigen din gazele de ardere, viteza autoturismului,
temperatura motorului si alte valori pe care le analizeaza, si in functie de aceste valori
trimite comenzi catre injectoare si prelungeste sau micsoreaza timpul cat acestea raman
deschise, reglând în acest fel cantitatea si calitatea amestecului combustibil precum si
momentul arderii.
ECU este ca un un mini-calculator care functioneaza foarte eficient. Practic
acesta are o viteza mult mai mica decât calculatorul pe care îl folositi in acest moment
pentru a cititi aceste informatii, are la dispozitie o memorie mult mai mica si cu toate
acestea îsi face treaba foarte bine. Pentru ca soft-ul pe care îl ruleaza el nu este
Windows, Linux sau Mac OS. Este un cod masina optimizat care nu stie sa faca altceva
decât ceea ce a fost programat sa faca: adica sa calculeze niste valori pe baza datelor
primite de la senzori
Ce se intâmpla atunci cand se defecteaza unul din senzorii care îi transmit
informatii?
ECU este proiectat sa functioneze în toate conditiile de lucru. Inginerii care
proiecteaza aceste unitati de control au luat în calcul si variata în care unul sau mai
multi senzori se defecteaza. În aceste conditii ECU nu se opreste din functionare ci
trece în modul Safe (sau LIMP cum mai este denumit în alte cazuri), ceea ce inseamna
ca ECU nu mai tine cont de toate datele furnizate de senzori si trimite comenzile catre
motor pe baza unor date prestabilite pe care le are inregistrate în memorie. Practic în
memoria sa exista un tabel de valori care a fost conceput de ingineri pentru a asigura
buna functionare a motorului pâna ce proprietarul remediaza problemele aparute la
senzorii defecti. Este de la sine înteles faptul ca în aceste conditii consumul de
carburant nu mai este optim ci mai mare decât cel pe care l-ar fi realizat ECU în
conditii de functionare normala. Exista cazuri în care nu se defecteaza nici un senzor
însă valorile transmise de catre acesta nu se încadreaza în limitele acceptate de ECU,
sau valorile primite de la diferiţi senzori sunt contradictorii, caz în care ECU consideră
că cel puţin unul din aceşti senzori este defect şi nu mai ia în considerare valorile
transmise ci le preia din tabelele din memorie.

8
Componentele ECU
ECU este un dispozitiv destul de complex. Acesta trebuie sa stie sa lucreze cu
toate celelalte componente ale motorului. De aceea, exista tot felul de dispozitive
ajutatoare care convertesc semnalele primite si trimise de ECU diverselor componente
cu care acesta comunica

Convertoare analogice-digitale (A-D):


ECU lucreaza cu date in format digital. De cele mai multe ori, valorile transmise
de catre senzori sunt niste valori de tensiune care se încadreaza între anumite limite.
Aceste valori trebuie convertite în format digital, pe un anumit numar de biti, si cu
aceste transformari se ocupa convertorul analog-digital.

Convertoare digital-analogice (D-A):


Tot pe principiul convertorului A-D de mai sus, uneori ECU trebuie sa ofere
comenzi diferitelor componente pe care le controleaza, sub forma de curent electric cu
o anumita tensiune. Cum datele pe care le prelucreaza el sunt in format digital, acestea
trebuie convertite în valori analogice, iar de acest lucru se ocupa aceste convertoare
Digital-Analigice.

1.2.3 Controlul digital al unor echipamente de putere

De multe ori, ECU trebuie sa comande pornirea sau oprirea unor subansamble
care folosesc o putere mult mai mare decât cea cu care lucreaza el. De aceea, anumite
comenzi trebuie sa fie transformate din valorile digitale 0 si 1 (care pot fi considerate
echivalente cu starile oprit si pornit ale unui dispozitiv) în comenzi de oprire si pornire
a unor relee care mai departe comanda echipamentele cu pricina.
Ajustarea valorilor:
De multe ori, valorile transmise de catre senzori nu pot fi procesate de
convertoarele analogice-digitale si au nevoie de o ajustare inainte de procesare. De
9
exemplu, unii senzori pot oferi valori în domeniul de tensiuni: 0 - 1.1 volti, valori care
nu pot fi prelucrate de catre convertorul analogic-digital care stie sa lucreze cu valori
cuprinse între alte limite. De aceea, aceste valori trebuie mai întâi ajustate pentru a
ajunge la intervalul de valori cu care lucreaza convertorul A-D sau D-A.
Chip-uri de comunicatie:
Acestea se ocupa cu transmiterea si receptionarea datelor prin magistrala de
comunicatii. Toate dispozitivele microprocesoare comunica folosind aceeasi magistrala
de date, prezentata în paragraful urmator.
Mai putine cabluri în autovehicul
Unul dintre avantajele aduse de utilizarea microprocesoarelor auto este si
reducerea numarului de cabluri electrice necesare bunei functionari a sistemelor
electrice si electronice ale masinii.
În trecut, când nu se utilizau aceste microprocesoare, pentru a face legatura
dintre un panou de comanda si elementul comandat de acesta era nevoie de unul sau
mai multe cabluri care sa faca legatura directa între acestea. Ne putem imagina acest
lucru daca ne gandim la o masina moderna care permite deschiderea si închiderea
geamurilor atât din usa soferului cât si din usa respectivului geam. Aceasta ar fi
însemnat ca sa existe legaturi directe între butoanele din usa soferului cu fiecare din
geamurile comandate. Pe acest principiu, adunate toate aceste cabluri si conectori
duceau uneori la zeci de kilograme în plus si sute de metri de cabluri, mai ales la
masinile mai sofisticate.
Rezolvarea a venit odata cu utilizarea microprocesoarelor si introducerea
sistemelor de transmisie a datelor printr-o magistrala de date seriala. Aceasta înseamna
ca toate datele sunt transmise prin aceleasi fire electrice însa exista un protocol de
control al datelor numit multiplexare care stie sa faca distinctie între aceste date si sa le
dirijeze catre modulele de control de care apartin.
Utilizarea sistemului centralizat de comunicatie în cadrul vehiculului ofera multe
beneficii, unele dintre acestea fiind abia descoperite si exploatate:
* un numar redus de cabluri si cablaje care duce în final la costuri de fabricatie
mult reduse, greutate mai mica, cresterea fiabilitatii, usureaza depanarea si instalarea

10
* toate datele furnizate de senzori (viteza, temperatura, etc. ) sunt disponibile
tuturor dispozitivelor conectate la reteaua de date din autovehicul

* ofera flexibilitate mult mai mare producatorilor deoarece multe dotari optionale
se pot adauga doar prin actualizarea soft-ului sau prin adaugarea unor module
separate

Desi acest sistem de comunicatie a fost disponibil de mai mult timp, nu s-a
folosit imediat pentru ca cei mai mari fabricanti din Statele Unite erau bine integrati pe
verticala, si nu erau legati prea mult de furnizorii de subansamble externi. Lucrurile au
stat însa diferit în Europa unde constructorii auto apelau la multi producatori de
subansamble, iar acestia la rândul lor furnizau aceste subansamble mai multor
producatori, utilizând specificatii diferite pentru aceleasi componente. De aceea în
Europa acest sistem a prins mai repede, fiind apoi adoptat din ce în ce mai mult si in
SUA.
Protocoalele standardizate permit modulelor furnizate de diferiti producatori sa
se interconecteze mult mai usor între ele, într-un fel de arhitectura deschisa. Aceasta
permite utilizarea unor testere standardizate si aduce economii importante din productia
la scara mare a acestor componente. Practic, pe furnizorii acestor componente nu îi mai
intereseaza ce se întâmpla mai departe cu datele furnizate de modulele lor, iar pe
constructorii de autoturisme nu îi mai intereseaza modul de functionare al
subansamblului atâta timp cât el furnizeaza datele de care are nevoie.
Dupa cum am mentionat anterior modulele electronice de control al motoarelor, au
fost utilizate în primul rând pentru reglarea aprinderii acestora. Din anul 1987 aceste
module electonice sunt folosite 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 ECU 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

11
control airbag, controlul de distanţă, etc.
Unităţi de control vizibile sunt pe tahometru, în forma lui nouă împreună cu turometru
şi diverse alte indicatoare. Senzori cum ar fi, nivelul combustibilului în rezervor, presiunea
uleiului pot dispune de propriul modul electronic care sunt, printre altele, memorate pe
termen lung.

1.2.4 Funcţionarea modulelor electronice

Modulele electronice lucrează după principiul „IPO”, (în engleză Input-Process-


Output, „introducere-prelucrare-debitare”). Pentru înregistrarea valoriilor sunt
disponibili senzorii care stabilesc o caracteristică fizică, cum ar fi viteza, presiunea, temperatura,

etc. Această valoare este 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 nominale programate în ECU.
În timp ce cu anii din urmă aprinderiile 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 ROM (în engleză Read Only
Memory, „Memorie doar citibila”) . Unele sisteme însă permit actualizarea programului

din ECU, prin reprogramarea a memoriei flash la atelierele de specialitate.


Aparatele schimbă informaţiile cu privire la condiţiile de funcţionare şi alte date
relevante ale vehiculului, prin diferite sisteme de interfeţe (CAN, LIN, MOST, FlexRay). În afara
acestora, prin aceste interfeţe se pot face legătura la OBD respectiv diagnosticarea

12
vehiculului. Acesta 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 a înregistrat la
propriile teste sau la sensorii de legătură. Astfel în atelierle de reparaţii, cu astfel de
mesaje la defecţiuni, se poate evita timp de lucru îndelungat. Adesea sunt utilizate
protocoalele de diagnostic KWP2000 sau UDS, care acesta este specivicat în ISO 14229-1.
În vederea creşterii complexităţii şi solicitării la software, precum şi comunicarea între
ECU-uri, sistemul OSEK-VDX, bazînd pe sistemul de comunicare RTOS. O altă măsură în
vederea creşterii de standardizare a comunicării ECU-urilor. este AUTOSAR.
Între timp, într-un automobil sunt amplasate mai mult de zece module electronice. Unele
automobilele moderne de lux, au instalate chiar peste 70 de module electronice. Gama
de microcipuri variază de la 8- la 32-bit de calculator.

13
1.3 Noutăț i pe piaț a auto - Michelin Active Wheel

În 2008, odată cu prezentarea conceptuluiActive Wheel pentru automobilele


prototip,Michelin a creat o adevărată revoluţie. Prin integrarea tuturor
componentelor esenţiale în roată, acest produs inovator elimină necesitatea unui
motor montat sub capota din faţă sau din spate, a sistemului tradiţional de
suspensie, a componentelor de transmisie şi a cutiei de viteze.
Rezultatul îl constituie o serie întreagă de avantaje pentru automobilele care
acum pot fi echipate cu această soluţie integrată. Michelin Active Wheel este o
roată inteligentă care propulsează electric automobilul şi care asigură totodată
funcţiile de suspensie şi frânare, oferind o manevrabilitate excelentă şi un confort
optim.

Cum funcţionează?

14
Pentru prima dată, roata include nu doar discul de frână, ci şi motorul
electric de acţionare şi sistemul de suspensie.
În funcţie de puterea pe care a fost conceput să o producă, vehiculul poate fi
echipat cu patru motoare (câte unul în fiecare roată) sau cu două motoare (în
roţile din faţă, de exemplu). În acest fel, Michelin Active Wheel permite
constructorilor de automobile să continue să conceapă vehicule cu tracţiune pe
două roţi sau cu tracţiune integrală.
Cu Michelin Active Wheel, sursa de energie este exclusiv electrică. Sursa de
energie poate fi o baterie litiu-ion sau un alt tip de baterie, o celulă de
combustibil şi /sau un condensator. Indiferent de situaţie, aceste surse de putere
asigură două beneficii importante: sunt ecologice şi asigură o funcţionare
uniformă. Vehiculele echipate cu Michelin Active Wheel nu emit gaze cu efect
de seră.
Dinamica este susţinută şi de sistemul de suspensie care stabileşte noi standarde
din punct de vedere al aderenţei şi al confortului. Cu Michelin Active Wheel,
suspensia vehiculului nu mai este mecanică ci electrică. Acest sistem unic asigură
un timp rapid de răspuns - doar 0,003 secunde. Toate mişcările de înclinare şi
rotire sunt corectate automat.

Michelin Active Wheel simplifică procesul de concepere a vehiculului, deoarece


componentele mecanice nu mai sunt folosite. Vehiculele echipate cu Michelin
Active Wheel nu mai au nevoie de cutie de viteze, de ambreiaj, arbore de
transmisie, diferenţial sau amortizoare. Astfel, vehiculul devine mult mai uşor şi
mai eficient din punct de vedere energetic. Michelin Active Wheel reprezintă o
adevărată inovaţie tehnologică prin care se oferă o soluţie eficientă problemelor
actuale privind transportul rutier.
La evenimentul Michelin Challenge Bibendum 2010 desfăşurat în acest an
în Brazilia la Rio de Janeiro au fost prezentate două autoturisme dotate cu
această roată revoluţionară: Heuliez Will şi Peugeot BB1.
WILL are o lungime de 3,70 m, este prevăzut cu cinci locuri şi este comparabil

15
cu automobilele compacte. Automobilul are două portbagaje, poate acoperi
distanţe mari (între 150 şi 400 km în funcţie de sursa de energie) şi dispune de
mai mult spaţiu pentru echipamentele de comunicaţie.
Motoarele au o eficienţă de 90%, comparativ cu 20%, valoarea caracteristică
motoarelor covenţionale la deplasarea în oraş. Heuliez a reconceput complet
şasiul. Datorită designului său, automobilul este mult mai uşor şi, implicit,
consumul de energie mai redus.
În plus, emisiile de CO2 „well-to-wheel" (de la sursa de combustibil la
vehicul) sunt mai mici de 15 gram per kilometru atunci când WILL foloseşte
energia rezultată din surse hidroelectrice, fotovoltaice, eoliene sau alte surse
ecologice.
Peugeot BB1
`Acest vehicul este prevăzut
cu roata motorizată
Michelin pe axul din spate (foto),
spaţiul interior mărindu-se astfel
în mod semnificativ.
În conformitate cu normele
privind vehiculele pe patru roţi,
capacitatea este mai mică de 15
kW (20 CP) sau 7,6 kW, ceea ce
reprezintă o capacitate optimă
dacă se are în vedere greutatea şi
faptul că automobilul a fost conceput pentru uz citadin.
Astfel, demarajul se face cu uşurinţă (0 până la 30 km/h în 2,8 secunde) iar
acceleraţia permite vehiculului să ajungă de la o viteză de 30 km/h la o viteză de 60
km/h în doar 4 secunde. Bateriile litiu-ion permit deplasarea pe o distanţă de 120 km.

16
1.4 Interfeţe de diagnoză auto
Interfeţele de diagnoză auto sunt utilizate pentru determinarea stării tehnice a
automobilului. Aceste sisteme de diagnoză pot fi utilizate pentru diagnosticarea
autovehiculului, monitorizarea în timp real a unor senzori, etc., atât de tehnicieni în
service-uri specializate, cât şi de proprietarii maşinilor. În ziua de astăzi automobilele
reprezintă zeci de computer interconectate cu zeci sau sute de senzori şi mecanisme
ultrasofisticate care au nevoie să funcţioneze impecabil. Ai becuri martor aprinse pe
bord deşi maşina pare să meargă normal? Vrei să modifici parametrii maşinii sau să
vezi şi să ştergi coduri de eroare, defecţiuni, resetezi intervale de service, să verifici un
automobil înainte de cumpărare? Poţi face toate astea fără ajutorul unui specialist prin
utilizarea interfeţei de diagnoză disponibilă (OBD II).
În continuare vom prezenta mai multe interfeţe de diagnoză disponibile pentru
diverşi producători de automobile:

ELM327

ELM327 este ultima versiune a interfetei


ELM. Suporta toate protocoalele OBD-
II (ISO15765-4 (CAN), ISO14230-4 (KWP2000),
ISO9141-2, J1850 VPW, J1850 PWM. Conectarea
la laptop se face prin RS323.

Elm 327 poate citi/ sterge coduri de eroare si ofera date in timp real despre
parametrii masiniii cum ar fi: (RPM al Motorului, avansul, temperatura din sistem
racire, viteza vehiculului, consumul instantaneu, debit aer, FRP, FRT, senzor oxigen,
senzorii pedalei de acceleratie, etc).

OPEL

OP-COM este o interfata de diagnoza care ofera urmatoarele functii pentru

17
modelele OPEL (1995-2007):

- Adaptare chei: IMMO I, IMMO II si protocol CAN ( Vectra C, Astra H)


- Citire /stergere coduri eroare
- Realizeaza masuratori de parametrii in timp real.
-Codare injectoare (Multijet)
- Resetare/programare interval de revizii.
- Calibrare unghi volan: Astra-H, Zafira-B, Vectra-C/Signum
- Adapare telecomenizi: Vectra-B, Astra-F, Corsa-C, Meriva, Tigra-B, Zafira,
Astra-G, Omega-B, Astra-H, Zafira-B, Vectra-C/Signum

1.3.1 Diagnoză și monitorizare


Anterior au fost prezentate interfeţe de diagnoză auto, în continuare vom sublinia
utilitatea acestora. Aceste sisteme vă vor ajuta să salvaţi timp şi să câştigaţi bani. Se vor
utiliza pentru diagnosticarea erorilor la

1. Motor
2. Transmisie
3. Airbag
4. ABS
5. ESP
6. Suspensie adaptivă
7. Keyless Go
8. Climatronic
9. Scaune electrice

Se poate realiza citirea codurilor de eroare, ştergerea acestora şi vizualizarea


parametrilor live:

18
1. Presiune turbo
2. Încărcare alternator
3. Temperatura apă
4. Temperatură ulei
5. Parametrii injectoare
6. Tensiuni şi alte valori, etc.

MONITORIZAREA AUTO

19
2.1 Aplicaț ii existente

2.2 Protocolul OBD II

2.3 Circuitul integrat ELM327

2.1 Aplicaț ii existente


În momentul de față au fost dezvoltate o multitudine de aplicații în acest
domeniu, o parte din aceste aplicații fiind oferite în mod gratuit fie cu toată
funcționalitatea dezvoltată până în prezent fie cu funcționalitate parțială. Produsele
care oferă funcționalitate parțială de obicei fac acest lucru pentru promovare. Pe lângă

20
software-ul dezvoltat de diverși există și aplicații proprietar, care sunt dezvoltate de
către producătorii de mașini sau de către asociați ai acestora. În mod normal o
aplicație venită de la producătorul mașinii oferă access total la absolute toate modulele
electronice ale automobilului. Dezavantajul pentru acest gen de aplicații este ca nu
funcționează pentru alte mărci de autovehicule și software-ul este mult mai costisitor,
de aici a apărut necesitatea dezvoltării de software independent de producător. Software
care să permită diagnosticarea indifferent de producătorul mașinii. Într-o oarecare
măsură s-a reușit implementarea aplicațiilor dar acestea nu pot oferii funcționalitate
completă datorită faptului că fiecare producător pe lângă codurile de eroare standard și
pe lângă identificatorii de parametrii (PID – parameter identifier) standard au definit
coduri și identificatori specifici fiecărui constructor în parte, este astfel posibil ca un
cod de eroare să semnifice un anumit lucru pentru un autovehicul Opel, iar pentru un
automobile marca BMW să reprezinte cu totul altceva. În general software-ul proprietar
este folosit numai de către service-urile reprezentante ale constructorului, costurile
ridicate de procurare și de întreținere îi determină pe mulți să caute alte soluții. După
studiile facute pe piață am putea sa clasificăm acest gen de software în următoarele
categorii:
1. Software Profesional Proprietar – oferit de către constructorul de mașini sau
de parteneri ai acestora (Fiecare producător important de mașini pune la
dispoziție un astfel de software)
2. Software Profesional cu posibilitate de diagnosticare și monitorizare pe
modulul de motor
3. Software de diagnoză și monitorizare pentru hobby-sti.
De asemenea în ultimul timp au început să apară versiuni de software implementate
pentru dispozitive mobile, care combină utilitățile de diagnosticare și monitorizare a
motorului cu posibilitățile de folosire a modulelor GPS și chiar telefonie mobilă, în
acest fel se folosește același dispozitiv pentru mai multe scopuri care aparent nu au nici
o legătură. Posibilitatea utilizării acestui gen de software a apărut odată cu creșterea
puterii de calcul ce poate fi integrată pe cm pătrat.
Mai jos sunt câteva capturi de ecran cu diverse aplicații de diagnoză și monitorizare

21

ProScan de la ScanTools
auto.

22
Rev App, de la DevToaster, care după cum se vede în imagini rulează pe dispozitive
iPhone.

O aplicație completă din punctul de vedere al componentelor incluse este DashDAQ,


care este disponibil atât în versiune pentru PC dar și ca versiune instalată pe un
dispozitiv mobil. Acestă aplicație folosește un dispozitiv hardware de achiziție special
gândit pentru a permite actualizarea parametrilor în timp real observându-se un timp de
răspuns foarte bun. Această aplicație pune la dispozitie support pentru: diagnosticare
probleme motor, urmărire parametrii motor, crearea unui jurnal de monitorizare,
diverse teste pentru a determina timpul de accelerație, timpul de franare, monitorizare
consum de combustibil, urmărirea nivelului de încărcare al bateriilor pentru
autovehicule hibride. Pe lângă toate aceste informații tehice aplicația oferă și support
pentru modul GPS incorporat în dispozitivul DashDaq și oferă support multimedia
pentru filme și muzică.
Toate aceste aplicații au un punct comun și anume interfața prin care se conectează la
autovehicul și care trebuie să resprecte standardul impus de OBD II, despre care voi
prezenta câteva amănunte în cele ce urmează.

23
2.2 Standardul ODB II
Sistemele OBD (On Board Diagnostic) sunt prezente pe toate autovehiculele produse în
prezent. Pe la sfârsitul anilor ’70 începutul anilor ’80 constructorii de mașini au început
să utilizeze module electronice pentru a controla diverse funcționalități ale motorului
pentru a se putea încadra în normele de poluare impuse de organizațiile de protecție a
mediului. De-a lungul timpului, numărul de funcționalități implementate cu ajutorul
electronicii a crescut și astfel sistemele de diagnosticare au devenit din ce în ce mai
complexe. OBD II, este un standard introdul la mijlocul anilor 90, și furnizează un
control aproape total asupra parametrilor motorului și de asemenea monitorizează părți
ale șasiului și diverse accessorii, ca de altfel și rețeaua de control pentru sistemul de
diagnosticare al mașinii.
Cum a apărut OBD II?
Pentru a combate problemele generate de smog, în L.A., autoritățile statului California
au început să impună sisteme de control al emisiilor de dioxid de cabon în 1966, în
1968 aceste măsuri au fost extinse la nivelul SUA. În 1970 congresul, a aprobat înfi-
ințarea EPA (Environmental Protection Agency), care avea să impună normele de polu-
are pentru autovehiculele care urmau a fi produse. Pentru a îndeplini aceste norme con-
structorii au fost nevoiți să apeleze la sisteme electronice pentru a controla cantitatea
de combustibil care este consumată cât și pentru controlul aprinderii. La început erau
câteva standarde și fiecare producător avea propriile sisteme și parametrii. În 1988, So-
cietatea Inginerilor din domeniul Auto (SAE – Society of Automotive Engineers) a sta-
bilit un conector standard pentru interfața de diagnosticare și a stabilit un set de
parametrii utilizați pentru diagnosticare și monitorizare. EPA a adaptat mai apoi mai
toate standardele pornind de la recomandările și programele de diagnosticare ale SAE.
Așadar OBD II este un set extins de standarde dezvoltat de SAE și adoptat de EPA pen-
tru implementare în anul 1996. Așadar toate autovehiculele produse începând cu anul
1996 au standardul OBD II implementat. OBD II, nu este doar o interfață de
diagnosticare, ci poate face mult mai multe lucruri.

24
- Autovehiculele care sunt echipate cu OBD-II au cel puțin 2 senzori de
oxigen, majoritatea cu senzori încălziți.

- Modulele de control al tracțiunii, cu procesoare fie pe 16 (Chrysler) fie


pe 32 biti(Ford & GM), sunt capabile să gestioneze peste 15000 de
constante noi, adăugate de OBD II.

- Module cu memorie EEPROM care permit reprogramarea PCM –urilor


(Program Controlled Module), cu versiuni de software îmbunătățite.

- Injecția de combustibil se face secvențial și nu multi-punct sau prin


carburator. Există senzori pentru măsurarea presiunii pe galeria de
admisie(MAP) și pentru măsurarea cantității de aer care este folosită de
motor în timpul funcționării (MAF), acești senzori putând fi utilizați
pentru a determina încărcarea motorului.

OBD II este un sistem foarte sofisticat și capabil, în ceea ce privește detectarea


emisiilor. Dar în momentul în care se pune problema identificării problemei de către
mecanici, acesta nu este mai eficient decât OBD I. În prezent se lucrează la OBD III,
care ar trebui să ducă OBD II la nivelul următor, prin adăugarea telemetriei. Folosind
un transmițător radio, un autovehicul echipat cu OBD III va fi capabil să raporteze
problemele legate de emisii direct către un punct tehnic sau o agenție specializată.
Sistemul va comunica numărul de identificare al autovehiculului (VIN) și codurile de
eroare detectate la momentul respectiv.

Sistemul poate fi setatat pentru a raporta în mod automat problemele de emisii


prin intermediul unei legături prin satelit, sau pentru a răspunde la interogări de pe tele-
fonul mobil, dispozitive amplasate pe marginea drumului etc. De ce este lucru intersant
pentru autoritățile de control, pentru că este eficientă și are costuri reduse comparative
cu metodele actuale care presupun deplasarea autovehiculelor către puncte de control în
care inspecția se face în mod manual, iar numărul de verificări care se poate face în
fiecare an este limitat.

25
Parametrii citiți în prezent au asociat fiecare câte un identificator, în funcție de
acest identificator computer-ul care controlează motorul știe ce valori să trimită în mo-
mentul în care este interogat, și cum să codeze informația. În mod normal pentru a pri-
mi informații de la modulele electronice care echipează autovehiculele este nevoie de
un dispozitiv hardware special care să fie capabil să trimită și să primească date uti-
lizând rețeaua internă de comunicare a autovehiculului. Există mai multe protocoale
de intercomunicare între modulele autovehiculelor și anume: CAN, VPW, PWM,
ISO, KWP. Începând cu anul 2008, toți producătorii sunt obligați să folosescă proto-
colul CAN pentru intercomunicarea între modulele care echipează autovehiculele.
Acest lucru va duce pe viitor la o simplificare a modulelor de diagnosticare și monitor-
izare și va permite creșterea vitezei de achiziție a informațiilor, din moment ce dispoz -
itivul hardware de achiziție nu va trebui să “cunoasca”, decât un singur protocol.
În prezent standardul OBD II presupune existența unui număr de 10 moduri de lucru
descrise în standardul SAE J1979 .

0x01 – afișarea datelor curente


0x02 – afișarea parametrilor achiziționți în momentul în care care a apărut o anumită
defecțiune identificată de sistemul de gestiune a motorului.
0x03 – afișarea codurilor de diagnosticare pentru defecțiunile memorate.
0x04 – stergerea codurilor de eroare și a valorilor memorate
0x05 – Rezultatele de test pentru monitorizarea senzorilor de oxygen (pentru non CAN)

0x06 – Rezultatele de test pentru monitorizarea altor componente (rezultatele de test


pentru senzorii de oxygen în cazul CAN)
0x07 – afișarea codurilor pentru erorile care sunt active în mod curent.
0x08 – operații de control pentru diverse componente/subsisteme
0x09 – afișare informații autovehicul.
0x0A – Coduri de eroare permanente (coduri curățate)

26
Producătorii de autovehicule nu sunt obligați să implementeze toate aceste moduri, și
fiecare producător poate defini moduri suplimentare, moduri mai mari ca număr de
identificare decât 9. Exemplu modul 22 este definit de Ford/GM pentru obținerea de
alte informații decât cele prevăzute în standard, modul 21 este definit pentru Toyota.
În tabelul următor se prezintă o parte din identificatori de parametrii utilizați pentru
obținerea informațiilor de monitorizare a motorului, după cum se poate observa o
parte din parametrii sunt codați pe biți. Aceștia se decodează după cum urmează:
Mod 1 – PID 0x01 – O cerere de acest gen returnează 4 octeți, bitul 8 al primului octet
(A7) indică dacă martorul MIL este aprins sau nu, biții A6…A0 indică numărul co-
durilor de eroare. Octeții 2, 3, 4 dau informații despre prezența și efectuarea anumitor
teste incorporate în modulele instalate.

Nume test Test disponibil Test incomplet


Lipsa scânteii B0 B4
Sistem de alimentare cu combustibil B1 B5
Componente B2 B6
Rezervat B3 B7
Catalizator C0 D0
Catalizator încălzit C1 D1
Sistem de evacuare C2 D2
Sistem de aer secundar C3 D3
Compresor aer condiționat C4 D4
Senzor de oxygen C5 D5
Încălzitor senzor de oxygen C6 D6
Sistem EGR C7 D7

Nota: se noteaza cu A, B, C, D cei 4 octeți primiți de la ECU.

NBR Val Val Formula de in-


Mod PID * Descriere Min Max UM terpretare
dacă bit-ul x este setat
(0<=x<=32 ) atunci
parametrul cu numărul
0x01 0x00 4 parametrii suportați N/A N/A N/A x este suportat
starea sistemului de la ultima
stergere a codurilor de Codare pe biți. Vezi
eroare, include MIL și descriere în afara
0x01 0x01 4 numărul codurilor de erorare tabelului.
valorile parametrilor la mo-
mentul în care a fost detec-
0x01 0x02 8 tată o anumită eroare
Codat pe biți. Vezi de-
Starea sistemului de com- scrierea din afara
0x01 0x03 2 bustibil tabelului

27
Încărcarea calculată a mo-
0x01 0x04 1 torului 0 100 % A*100/255
Temperatura lichidului de ră-
0x01 0x05 1 cire -40 215 ºC A-40
reducerea % de combustibil (-100) 99.22
0x01 0x06 1 pe termen scurt - BANK 1 Rich Lean % (A-128)*100/128
reducerea % de combustibil (-100) 99.22
0x01 0x07 1 pe termen lung - BANK 1 Rich Lean % (A-128)*100/128
reducerea % de combustibil (-100) 99.22
0x01 0x08 1 pe termen scurt - BANK 2 Rich Lean % (A-128)*100/128
reducerea % de combustibil (-100) 99.22
0x01 0x09 1 pe termen lung - BANK 2 Rich Lean % (A-128)*100/128

0x01 0x0A 1 presiunea combustibilului 0 765 kPa A*3


presiunea absoluta în galeria
0x01 0x0B 1 de admisie 0 255 kPa A
16.38
0x01 0x0C 2 turația motorului 0 3,75 rot/min ((A*256)+B)/4

0x01 0x0D 1 viteza autovehiculului 0 255 km/h A


º relativ
la cilin-
0x01 0x0E 1 avansul scânteii -64 63.5 drul 1 A/2 – 64
temperatura aerului pe gale-
0x01 0x0F 1 ria de admisie -40 215 ºC A-40
masa fluxului de aer care
trece la un moment dat prin 655.3
0x01 0x10 2 galeria de admisie 0 5 g/s ((A*256) + B)/100

0x01 0x11 1 poziția clapetei de admisie 0 100 % A*100/255

* NBR = numar bytes returnat

Pentru decodarea octeților primiți ca răspuns la trimiterea PID-ului 0x03 pentru


modul 0x01 se urmărește următoarea schemă ținând cont de faptul că răspunsul este pe
2 octeți, primul octet reprezintă starea sistemului de alimentare primar, iar cel de-al
doilea reprezintă starea sistemului de alimentare secundar în cazul în care acesta există.
Pentru sistemul de alimentare primar se foloseste primul octet primit, fie acesta A,
avem:
A0 – funcționare în buclă deschisă datorită faptului că motorul nu este încălzit
sufficient
A1 – funcționare în buclă închisă folosind răspunsul senzorilor de oxygen pentru
a determina amestecul combustibil/aer.

28
A2 – funcționare în buclă deschisă datorită încărcării motorului sau oprire
alimentare datorită rulării în frână de motor
A3 – funcționare în buclă deschisă datorită defecțiunilor sistemului de gestiune
A4 – funcționare în buclă închisă, folosind cel puțin un senzor de oxygen dar,
există o problemă în sistemul de răspuns
A5-A7 – întotdeauna 0.

2.3 Circuitul integrat ELM 327


Dispozitivul hardware folosit în acest proiect pentru achiziția de date este bazat
pe circuitul integrat ELM 327. Acest circuit a fost gândit pentru a se comporta ca un
“bridge” între interfața OBD II a autovehiculului și interfața RS 232 a calculatoarelor.
Caracterisiticile principale ale acestui circuit integrat sunt:
1. Dispune de modul stand by pentru economisirea energiei electrice
2. Baud Rate până la 500Kbps
3. Detectează în mod automat protocolul OBD II, folosit de autovehicul
4. Este complet configurabil, având propriul set de comenzi ce permit
configurarea dinamică
5. permite monitorizarea acumulatorului

Acest circuit poate avea diverse utilizări pentru cititoare de erori, instrumente pentru
scanare, dar și în scopuri didactice.
În figura următoare se poate vedea diagrama bloc a acestui circuit:

29
Diagrama Block ELM 327

Producătorul circuitului notează faptul că acest circuit se bazează pe un


dispozitiv PIC 18F2480 produs de către Microchip. Așadar este probabil ca toată
funcționalitatea acestui circuit sa fie implementată software. Acest lucru crește timpul
de procesare a informației, din această cauză acest circuit nu este potrivit pentru
achiziții de date în timp real. Totuși având în vedere faptul că pentru a realiza un
dispozitiv complet funcțional este nevoie de foarte puține componente externe pe
lângă circuitul integrat, uneori este de preferat utilizarea acestui circuit datorită
numeroaselor posibilități de configurare prin intermediul softului. Pentru a evidenția
ușurința cu care se poate integra acest circuit producătorul pune la dispoziție o schemă
electronică caracteristică. Această schemă poate fi analizată în imaginea de următoare.

30
Schemă de montaj ELM 327

Necesar componente electronice

31
3. DESCRIEREA APLICAȚ IEI

32
3.1 Arhitectura aplicaț iei

3.2 Tehnologii de implementare

3.3 Module implementate – modul monitorizare

3.1 Arhitectura aplicaț iei

Aplicația este structurată în așa fel încât să fie flexibilă, în momentul în care
vine vorba de o dezvoltare și actualizare ulterioară. Această flexibilitate este obținută

33
Application GUI
prin realizarea unei cuplări slabe între module, modulele fiind cuplate într-o arhitectură
multinivel. Se pot adauga noi module prin simpla implementare a unor interfețe, și
actualizarea unui fișier de configurație fără a mai fi nevoie de alte modificări în codul
de bază al aplicației. De asemenea arhitectura multinivel permite separarea
funcționalităților ajungându-se în acest fel, ca depanarea erorilor și problemelor care

Communica
tion Layer
Business Logic

AQU
pot apărea la un moment dat să fie ușor de realizat. Un alt avantaj al acestei abordări,
+(Core)
este reprezentat de faptul că se poate realiza o testare modulară și se pot realiza unități
de test automatizate pentru fiecare modul în parte, timpul alocat testării putând fii
diminuat cu 60 – 70%.
Un alt lucru important care s-a urmărit în momentul în care această aplicație a fost
proiectată, a fost separarea funcționalității de bază, față deData Access
interfa Layer
ța grafică, în felul
acesta interfața grafică poate fi înlocuită în orice moment fără a fi nevoie să se rescrie
funcționalitatea de logică a aplicației (modulul de conectare la interfața auto, modulul
de citire a informațiilor de OBD
la interfa ța auto), astfel interfața grafică poate fi actualizată
II Hardware
foarte ușor la noile tehnologii Diagnosis
de afșare grafică.
interface
Modulul de acces la interfața serială poate fi inlocuit foarte ușorSQL
în cazul
LITE în care se
dorește utilizarea altei interfețe de comunicare (se doreste utilizarea unei interfețe
USB, Ethernet, etc.), singurul lucru care ar trebui schimbat în acest caz este
implementarea modului de comunicare pentru protocolul dorit și actualizarea în
modulul de bază pentru a folosi noul modul de comunicare, specificându-se modulul de
comunicare ce va fi folosit, fără a mai fi nevoie de alte modificări în codul de bază
pentru a face aplicația funcțională.

Logger

Diagrama bloc a structurii generale a aplicației

34
În cele ce urmează o să încerc să prezint pe scurt fiecare componentă în parte a
diagramei de mai sus și rolul pe care îl are, respectiva componentă, în cadrul aplicației.

3.1.1 Application GUI

35
(Application Graphical User Interface) sau Interfața Grafică de prezentare a
aplicației.
Scopul principal al acestei componente este de a prezenta utilizatorului într-un mod cât
mai prietenos și mai ușor de analizat informațiile puse la dispoziție de sistemul de
management al motorului, aici includem parametrii obținuți în timpul funcționării cât
și informații memorate pentru analiză în memoria internă a ECU. (Unitatea de control
a motorului). Pentru a realiza o interfață care să fie cât mai ușor de folosit, este nevoie
de ca aceasta să fie împărțită pe funcționalități. În primă fază aplicația poate să fie
folosită în două scopuri:
− Diagnosticarea problemelor apărute la motor
− Monitorizarea parametrilor de funcționare a motorului
Dacă se dorește integrarea de noi funcționalități (modul de navigare GPS, modul de
Rapoarte etc.), acestea se pot integra cu aplicația prin implementarea unui nou modul
și actualizareaADT GUI
unui fișier de configurare. Modulele noi care se implementează trebuie
să respecte un anumit șablon pentru a putea fi integrate, această restricție este impusă
Plugin Selector (Menu) – GUI Element
de generalitatea modulelor care pot fi integrate cu aplicația. Aceste module pot
totodată să folosească din funcționalitatea de bază implementată pentru diagnosticare
Plugin Manager
și monitorizare.
În continuare aceste module pentru interfața grafică o să le numim plugin-uri.
Plugin-urile pot fi adaugate sau scoase din interfața grafică prin simpla editare a
fișierului de configurare, așadar aplicația se poate personaliza foarte ușor.
În figura
PLUGIN IFaceurmătoare se poate observa ționează
modalitatea în care interacPLUGIN
PLUGIN IFace IFaceinterfața

grafică principală cu plugin-urile.


GUI Elements GUI Elements GUI Elements

Plugin BLogic Plugin BLogic Plugin BLogic


...

Business Logic 36
Vezi doc. Arh.
generală
3.1.2 Business Logic – Core

Logica de funcționalitate
Acest nivel implementează logica după care se realizează achiziția de date, și este
folosit atât la implementarea achiziției de informații pentru diagnosticarea
defecțiunilor cât și pentru achiziția de date în vederea monitorizării parametrilor de
funcționare. Modulul implementat pentru acest nivel se folosește de nivelul de
comunicare pentru a obține informații de la interfața hardware. În momentul în care
au fost obținute informațiile dorite de la interfața hardware acestea trebuie decodate
pentru a putea interpreta in mod corect datele primite, iar acest lucru este realizat în
acest nivel. În momentul în care informațiile sunt transmise în nivelurile superioare
acestea sunt puse într-un format corespunzător necesităților. Spre exemplu interfața
grafică, pentru a afișa numărul de rotații pe minut are nevoie de un numar intreg, dar
interfața hardware trimite aceste informațiile sub forma unui șir de caractere ASCII in
format hexazecimal, așadar pentru a putea utiliza informația primită este nevoie ca
aceasta să fie interpretată și adusă în formatul corespunzător. În acest context, având în
vedere faptul că fiecare parametru citit Business Logic
are o interpretare diferită a
Sensor Manager
informațiilor pe care le transmite este
ISensorSignal
nevoie să se implementeze efectiv,
BaseSensor
codul pentru decodificarea
informațiilor corespunzătoare fiecărui
paramteru în parte. În acest sens a fost
creată ierarhia de de clase alăturată.
S1 Imp S2 Imp Sn Imp

37
3.1.3. HW Communication Layer

Nivelul de comunicare cu dispozitivul hardware.


Nivelul de comunicare cu interfața harware a fost adaugat la această aplicație pentru a
putea abstractiza comunicarea între aplicație și dispozitivul de achiziție. În acest fel în
momentul în care se dorește schimbarea interfeței de comunicare software-dispozitiv
hardware nu o sa fie nevoie de modificări în nivelurile superioare ala aplicației,
singurele schimbări care se fac sunt realizate numai la acest nivel. Acest lucru se
relizează practic prin definirea unor clase (interfețe) abstracte care urmează a fi
implementate la momentul la care se cunoaște cu exactitate protocolul folosit pentru
comunicare. În cadrul aplicației noastre am considerat că modulul de comunicație
trebuie să permită executarea următoarelor operații de bază:

1. Trimitere mesaje
2. Primire mesaje
3. Determinarea erorilor care apar la comunicare
4. Configurare
5. Initializare conexiune
6. Inchidere conexiune
La nivelul implementării au fost considerate mai multe modalități prin care se poate
realiza parametrizarea funcțiilor de trimitere/primire de mesaje. După cum se poate
observa în secvența următoare de cod, primirea de mesaje se poate realiza prin citirea
de pe interfață a datelor până la primirea unui anumit caracter. Acestă abordare este
utilă în cazul dispozitivului de diagnoză auto ELM 327, pentru că toate mesajele de
răspuns la interogările venite din partea utilizatorului se termină cu '>', și de cele mai
multe ori pentru a putea interpreta informația de la dispozitiv este necesar întreg

38
răspunsul, așadar este necesar să se aștepte până când se primește semnul care
marchează sfârșitul răspunsului.

class IGenericCommunication
{
public:

virtual QString GetCommunicationInterfaceName() = 0;

virtual int SetConfiguration(QString configurationString) = 0;

virtual QString GetConfiguration() = 0;

virtual int Send(const char* bytesToSend, qint64 length, qint64*


actualSent) = 0;

virtual int Send(const QString stringToSend) = 0;

virtual int Receive(char* bufferForStore, qint64 bufferLen, qint64*


actuallyRead, int receiveAll) = 0;

virtual int Receive(QString& receivedString, char endOfBuffer) = 0;

virtual int InitializeCommunication() = 0;

virtual int TerminateCommunication() = 0;

virtual void SetLogger(IGenericLogger* pClassLogger) = 0;

virtual QString GetErrorString() = 0;

virtual int GetErrorCode() = 0;

virtual ~IGenericCommunication(){};
};

3.1.4 Logger

39
Modulul de monitorizare a execuției
Această componentă este necesară pentru a putea monitoriza erorile care pot apărea în
momentul în care aplicația este folosită de utilizatori ce pot genera scenarii de utilizare
care nu au fost luate în calcul în momentul în care a fost proiectată aplicația.
Componenta este de fapt un modul care pune la dispoziție celorlalte module ale
aplicației o interfață abstractizată pentru a marca execuția unor blocuri de cod.
Marcare blocurilor de cod permite crearea unei urme de execuție care poate fi analizată
pentru a reproduce pașii prin care a trecut utilizatorul înainte de obține anumite erori
sau înainte de a ajunge la un comportament neașteptat din partea aplicației. Nu este de
dorit întotdeauna ca acest sistem de monitorizare să fie activat, acest lucru fiind datorat
impactului pe care îl poate avea asupra performanței aplicației. Având în vedere faptul
că de cele mai multe ori, pentru stoca informația din aceste sisteme de monitorizare, se
folosește harddisk-ul care are un timp de răspuns relativ mare comparativ cu memoria
internă și viteza de execuție a procesorului folosirea sistemelor de monitorizare reduce
în mod vizibil viteza de execuție, lucru care de cele mai multe ori, în aplicațiile în care
timul de execuție este critic, nu este acceptabil. Există totuși o soluție și pentru aceste
aplicații și anume folosirea unor cozi de mesaje care să fie descărcate mai apoi pe
hard-disk folosind un fir de execuție separat. Avantajul în acest caz este faptul ca
timpul de execuție al codului aplicației este influențat nesemnificativ, dar apare
dezavantajul că este posibil ca în momentul apare o eroare care sa genereze închiderea
forțată a aplicației anumiți pași de execuție sa nu fie scriși pe suportul de stocare. Un
astfel de sistem de logare, care permite folosirea multithreading este log4cxx, care are
deasemenea implementări pentru mai multe platforme de dezvoltare, cum ar fi Java
(log4j), Microsoft .NET (log4net). În aplicația noastră nu am folosit un sistem deja
implementat, ci am implementat unul nou deoarece necesităție aplicației referitor la un
astfel de sistem sunt minime, de aceea nu se justifică introducerea unui sistem complex
cum este log4cxx numai pentru acest lucru. De aceeea am implementat un modul
simplu care realizează operații de bază pentru scrierea de pe hdd.

40
3.2 Tehnologiile folosite pentru dezvoltarea
aplicaț iei.

Limbajul de programare folosit este C++, în primul rând datorită flexibilității


pe care o oferă în vederea dezvoltării ulterioare. S-au dezvoltat anumite
librării native care la un moment dat pot fi importate în orice alt limbaj de
nivel înalt. Dacă am fi ales un alt limbaj de programare de nivel înalt (Java
sau .Net) ar fi apărut diverse restricții asupra limbajelor în care acele librării
ar putea fi utilizate. Pentru a putea extinde funcționalitatea implementată pe
mai multe platforme de operare am apelat la framework-ul Qt, care este un
framework Open Source și care oferă suport multi-platformă. Practic
funcționalitatea implementată poate rula pe mai multe sisteme de operare și
chiar pe dispozitivele mobile, atâta timp cât acestea îndeplinesc cerințele
hardware necesare.

Acest framework are o istorie de aproximativ 20 de ani, timp în care au fost aduse
îmbunătățiri permanente, fapt ce ne face să credem că acest framework a ajuns la
maturitate și prezintă garanția stabilității modulelor în condițiile unei utilizări corecte.
Inițial acest framework a fost dezvoltat de firma TrollTech pentru ca mai apoi aceasta
să fie preluată în 2008 de producătorul de dispozitive mobile Nokia, care a creat o
divizie specială (Qt Development Frameworks Team) care se ocupă în mod special de
dezvoltarea și promovarea acestui produs. În momentul de față Qt este folosit în 3
variante de licențiere:

− Varianta comercială
− Varianta cu licență LGPL (licență compatibilă LGPL v2.1)
− Varianta cu licență GPL.

Sistemele de operare pe care este suportat oficial sunt:


Linux/X11 – Qt pentru X Window System (Unix / Linux)

41
• Mac OS X – Qt pentru Apple Mac OS X. Suport pentru aplicațiile peste API-urile
Cocoa.
• Windows – Qt pentru Microsoft Windows

• Embedded Linux – Qt platforme încorporate (PDA, Smartphone, etc.)

• Windows CE – Qt pentru Windows CE

• Symbian– Qt pentru Symbian. Qt va înlocui framework-ul Nokia Avkon și va


deveni kitul de dezvoltare UI pentru dezvoltarea aplicațiilor pentru Symbian.
Datorită faptului că frameworkul a devenit open source, comunitatea a inceput sa
dezvolte suport și pentru alte sisteme de operare cum ar fi:
• Qt for OpenSolaris – Qt pentru OpenSolaris

• Qt for Haiku– Qt pentru Haiku OS

• Qt for OS/2– Qt pentru OS/2 eCS platform.

• Qt-iPhone– dezvoltare experimentală Qt pentru iPhone.

• Android-Lighthouse – dezvoltare experimantală Qt pentru Android.


• Qt for Amazon Kindle DX – dezvoltare experimentală pentru Amazon Kindle DX.

În continuare vom prezenta o parte din componentele multi-platformă puse la


dispoziție de framework-ul Qt, pentru a ne putea face o idee despre facilităție pe care
le pune la dispoziție, vom prezenta în continuare principalele funcționalități pe care
acesta încearcă să le înglobeze și anume:
− interfața utilizator
− access la baza de date
− comunicații de rețea
− procesare XML
− fire de execuție
− librarii de grafica 3D bazate pe OpenGL.
− clase template

42
3.2.1 Interfaț a grafică
Qt-ul a fost dezvoltat în primă fază pentru a oferi dezvoltatorilor de software un
mod comun de creare a interfețelor grafice care să se integreze cu sistemul gazdă pe
care rulează aplicația. Din această cauză în momentul în care se rulează o aplicație Qt
aceasta va avea comportamentul și asemănarea standard întâlnite pe sistemul de
operare gazdă. Desigur se pot realiza și interfețe grafice personalizate dacă cei care
dezvoltă software-ul doresc acest lucru. În ultimele versiuni s-a Style Sheet-ul, un meta
limbaj care oferă o flexibilitate deosebită atunci când vine vorba de personalizarea
elementelor care alcătuiesc interfața grafică. Avantajul folosirii acestui framework în
momentul în care se dorește o personalizare a interfețelor grafice, este acela ca
optimizează viteza de execuție și consumul de memorie.

3.2.2 Accesul la baze de date


Începând cu versiunea 3.0 Qt oferă suport multi-platformă și independent de
tehnologia de baze de date folosită. În acest fel, în momentul în care este nevoie de
migrarea de la o tehnologie de baze de date la alta codul scris folosind Qt, rămâne
același sau modificările aduse sunt minore. Acesta este un avantaj major pe care Qt-ul
îl aduce, comparativ cu alte framework-uri gen .NET. În prezent Qt oferă suport
independent de tehnologie pentru majoritatea tehnologiilor de baze de date, importante
cum ar fi:
− Oracle
− MSSQL
− Sybase
− MySQL
− PostgreSQL

3.2.3. Fire de execuț ie


Qt pune la dispoziție de asemenea și funcționalitate pentru managementul firelor de
43
execuție, această funcționalitate fiind de asemenea independentă de platformă. Acest
lucru este important deoarece Qt-ul reușește să implementeze managementul firelor de
execuție la nivelul aplicației, folosind API-urile specifice platformei pe care se
execută codul, spre deosebire de Java, spre exemplu la care managementul se
realizează la nivelul masinii virtuale.

3.2.4. Programare în reț ea


Un alt modul important al acestui framework, este modulul de comunicare în
rețea. Acest modul pune la dispoziție funcționalitate de nivel înalt pentru comunicații
TCP/IP, UDP, implementează protocoale internet de uz comun HTTP, FTP

3.2.5 Clase template


O altă clasă de funcționalitați, foarte importantă, pusă la dispoziție de acest
framework este reprezentată de clasele de tip template pentru manipularea colecțiilor
de date, și implementarea de algoritmi optimizați pentru regăsirea informației.
Analizând caracteristicile de mai sus, ne putem da seama că acest framework este
unul complet, oferind funcționalitatea necesară atât pentru abordarea proiectelor
simple cât și pentru proiectele mai complexe. În același timp având în vedere faptul că
acesta se bazează pe C++ și în urma compilării se obține cod nativ, performanțele
obținute prin dezvoltarea folosind acest framework sunt în mod clar superioare
performanțelor care ar putea fi obținute prin dezvoltarea folosind framework-uri
dezvoltate pentru alte limbaje de programare.

3.3 Modulul de monitorizare a parametrilor motorului

44
3.3.1 Descriere generală, justificare

Nu întotdeauna problemele care apar la motor pot fi detectate de ECU, și ca


urmare acestea nu o sa fie raportate în momentul în care se face diagnoza cu soft
specializat, de aceea este necesară posibilitatea urmăririi parametrilor live, ai motorului
de către mecanic, inginer în vederea stabiliri unui diagnostic corect. O altă utilizare a
acestui modul este dată de necesitatea de monitorizare în momentul în care parametrii
din fabrică sunt modificați. Acest lucru se realizează de obicei printr-un proces de
“chip tunning”, iar modulul de monitorizare poate fi utilizat pentru a observa în ce
măsură parametrii motorului au fost modificați în urma acestui proces, putându-se
ajusta parametrii motorului până în momentul în care se ajunge la nivelul de
performanță dorit. Un alt scop pentru care poate fi folosit acest modul este evoluția în
timp a semnalelor date de către sondele lambda pentru a putea stabili dacă acestea

funcționează la parametrii normali și dacă se emit corect comenzile de formare a


amestecului de combustibil-aer. Controlul defectos al acestui amestec duce la emisii de
45
dioxid de carbon ridicate.
Sonda Lambda este un senzor amplasat pe tubulatura de evacuare și conectat la ECU, care în esență constă într-un
conductor de curent electric a cărui intensitate variază în funcție de cantitatea de oxigen care traversează sonda. În
interiorul acesteia exista un material ceramic poros, din dioxid de zirconiu (ZrO2). Intensitatea curentului prin placa de
zirconiu variaza în functie de numarul de molecule de oxigen care traverseaza materialul ceramic. Deoarece sonda
functioneaza optim doar la temperaturi mari, „la rece”, până când gazele de eșapament ating temperaturi de 400-500 OC,
sonda este încalzită de o rezistența din interiorul ei, dupa care căldura îi va fi furnizată chiar de temperatura gazelor de
eșapament. Autoturismele cu motorizari euro 3 si 4 au chiar 2 sonde, una amplasată înaintea catalizatorului pentru
optimizarea amestecului aer/combustibil, și una după catalizator, pentru verificarea eficienței acestuia. Constructorii
recomandă verificarea sondei la fiecare 30 000 de kilometri sau la fiecare doi-trei ani de functionare a mașinii și
schimbarea sondei în cazul când apar probleme în funcționarea acesteia.

Instrumentele de urmărire a parametrilor motorului, puse la dispoziție de modulul de


monitorizare sunt următoarele:
− Vitezometru - cu afișare clasică (ac indicator) și afișare în format numeric
− Turometru (numarul de rotații pe minut pentru motor) – afișare clasică (ac
indicator) și afișare în format numeric
− instrument pentru monitorizarea temperaturii în amestecului de răcire
− instrument pentru monitorizarea masei fluxului de aer pe galeria de admisie
− intrument pentru monitorizarea presiunii pe galeria de admisie
− instrument pentru determinarea poziției pedalei de accelerație

class IADTPlugin
{
3.3.2 Detalii implemetare modul de monitorizare
public:
virtual void SetCoreObject(ADTCore* pCore) = 0;
Detalii de integrare cu aplicaț ia principală
Pentru a putea realiza
virtualintegrarea cu aplicația principală
QIcon GetPluginIcon() = 0; este nevoie de implementarea
interfeței IADTPlugin, și actualizarea fișierului de configurare pentru aplicație. Acest
virtual QString GetPluginName() = 0;
mod facil de integrare este datorat în primul rând arhitecturi interfeței grafice care a
șa fel încât
fost gandită în avirtual să poată
QString = 0; ță, fără modificări ulterioare
fi extinsă în permanen
GetVersionString()

sau cu modificări minore.


virtual QWidget* GetWidget() = 0;

virtual ~IADTPlugin(){}
};

46
După cum se poate observa plugin-ul trebuie să pună la dispoziție metode pentru
a putea seta interfața către modulul care încorporează funcționalitatea principală.
Funcționalitatea principală se referă la funcționalitatea folosită pentru a accesa datele
primite de la dispozitivul de achiziție. Este nevoie de un nivel intermediar între datele
brute primite de la dispozitivul hardware interfața grafică, datorită faptului că datele
primite nu se află într-un format care să permită o interpretare facilă. Rolul nivelului
intermediar este de a comunica prin intermediul dispozitivului hardware de achiziție,
cu ECU (Engine Control Unit) și a prelua informațiile pe care să le ofere nivelelor
superioare în formatul dorit, mai pe scurt acest nivel are rolul unui translator, care
permite comunicarea între utilizator și modulul de control electronic al motorului.

Modul
Achizitie de date
și traducere Modul
Achizitie de date
și traducere

Detalii de implementare a modulului de achiziț ie

47
Parametrii monitorizați de aplicație se rezumă la valori numerice, așadar nu este
o problemă dacă pornim de la premisa că toți parametrii pot fi caracterizați prin valori
numerice reale. Acest lucru este foarte important în structurarea generală a ierarhiei de
clase utilizată pentru accesarea valorilor citite de la senzori. Având în vedere că
protocolul de comunicare între modulul software de achiziție și dispozitivul hardware
este relativ simplu și există o similiaritate pentru achiziția pe diferiții senzori, o sa
avem o parte de cod comună pentru toate clasele care se ocupă de interpretarea datelor
primite de la ECU. Transpus în programarea orientată pe obiecte, acest lucru este
echivalent cu implementarea unei clase de bază care implementeze funcționalitatea
comună și mai apoi derivarea claselor care se ocupă de interpretarea rezultatelor din
această clasă. Pentru a vă crea o imagine clară a acestui aspect se poate analiza
diagrama UML care urmează:

48
Metoda care se ocupă efectiv de achiziția datelor este GetSensorData, care

49
filtrează informația primită de la dispozitivul hardware, elimină informațiile care nu
sunt necesare, transformă informația din format ASCII în format binar și returnează
rezultatul la adresa de memorie specificată. Pentru a accesa dispozitivul hardware se
folosește o interfață serială emulată, deoarece conectarea dispozitivului la PC se
realizează prin intermediul USB. Se realizează de fapt un „bridge” soft între interfața
serială și interfața USB. Dispozitivul hardware de achiziție are în componență un
circuit integrat FTDI care face conversia de la USB → UART RS-232 (procesorul
dispozitivului de achiziție primește comenzi prin intermediul interfeței seriale).
Producatorul acestui chip pune la dispoziție driver-ul pentru crearea unui port serial
irtual, lucru care îi scutește pe cei care scriu aplicațiile de necesitatea scrierii de drivere
pentru comunicarea prin USB și același timp asigură compatibilitatea cu vechile
aplicații care foloseau interfața serială pentru comunicarea cu dispozitivele hardware.
Așadar la nivel de aplicație interfața de comunicarea se vede ca o interfața serială
obișnuită.

FTDI

ELM 327 Chip


Virtual COM Port
(FTDI driver)

Revenind la partea de cod, după implementarea clasei de bază care se ocupă de


aducerea datelor brute de la Unitatea de control a motorului, este nevoie de
interpretarea datelor pe care le-am primit în funcție de senzorul care a furnizat
informația către ECU.
Având în vedere faptul că timpul de răspuns este relativ mare și depinde de
viteza bus-ului intern al autovehiculului este posibilă de crearea unui mecanism intern

50
care să furnizeze informațiile într-un mod rapid și eventual asincron. În acest sens este
nevoie de memorarea temporară a datelor primite de la autovehicul, și interpolarea
acestora pentru obținerea de aproximări. Astfel există un fir de execuție separat care
interoghează ECU în vederea primirii informațiilor dorite, iar în momentul în care
aceste informații sunt primite sunt puse într-o zonă de memorie comună care va fi
utilizată apoi în momentul în care modulul de monitorizare este solicitat pentru a
furniza anumite informații. Acest lucru ne asigură de faptul că nu se ajunge la situații
în care să fie probleme cu blocarea interfeței din cauza faptului că modulul electronic
întârzie în livrarea informației dorite, făcând mai puțin vizibil efectul pe care îl are
comunicația lentă între dispozitivul electronic și soft.

Detalii despre integrarea modulului de achiziț ie cu modulul de monitorizare


grafică

BIBLIOGRAFIE

51
1. www.scantool.net
2. www.wikipedia.org
3. www.obd-codes.com

52

S-ar putea să vă placă și