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.1Arhitectura aplicației
3.2Tehnologii de implementare folosite
3.3Modulul 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
flash, înalt integrate, ce dispun de management energetic, se află la baza ECM-urilor, şi
3
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ă contact,
OEM-urile auto restrâng disponibilul energetic la mai puţin de 1mA pe ECM. O familie
4
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
electronice, precum şi pentru controlul electronic la dirijarea de maşini, instalaţii
5
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
11
(ABS), de climatizare, de 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,
12
FlexRay). În afara acestora, prin aceste interfeţe se pot face legătura la OBD respectiv
diagnosticarea 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
15
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
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).
17
OPEL
OP-COM este o interfata de diagnoza care ofera urmatoarele functii pentru
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
18
Se poate realiza citirea codurilor de eroare, ştergerea acestora şi vizualizarea
parametrilor live:
1. Presiune turbo
2. Încărcare alternator
3. Temperatura apă
4. Temperatură ulei
5. Parametrii injectoare
6. Tensiuni şi alte valori, etc.
19
MONITORIZAREA AUTO
2.1 Aplicații existente
2.2 Protocolul OBD II
2.3 Circuitul integrat ELM327
20
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ă
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
21
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
auto.
22
ProScan de la ScanTools
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
23
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ă.
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
24
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.
- 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ă.
25
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.
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
primi 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 dispozi-
tivul 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
26
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)
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 incompletLipsa scânteii B0 B4Sistem de alimentare cu combustibil B1 B5Componente B2 B6Rezervat B3 B7Catalizator C0 D0Catalizator încălzit C1 D1Sistem de evacuare C2 D2Sistem de aer secundar C3 D3Compresor aer condiționat C4 D4Senzor de oxygen C5 D5Încălzitor senzor de oxygen C6 D6Sistem EGR C7 D7
27
Nota: se noteaza cu A, B, C, D cei 4 octeți primiți de la ECU.
Mod PIDNBR* Descriere
Val Min
Val Max UM
Formula de in-terpretare
0x01 0x00 4 parametrii suportați N/A N/A N/A
dacă bit-ul x este setat (0<=x<=32 ) atunci parametrul cu numărul x este suportat
0x01 0x01 4
starea sistemului de la ultima stergere a codurilor de eroare, include MIL și numărul codurilor de erorare
Codare pe biți. Vezi descriere în afara tabelului.
0x01 0x02 8
valorile parametrilor la mo-mentul în care a fost detec-tată o anumită eroare
0x01 0x03 2Starea sistemului de com-bustibil
Codat pe biți. Vezi de-scrierea din afara tabelului
0x01 0x04 1Încărcarea calculată a mo-torului 0 100 % A*100/255
0x01 0x05 1Temperatura lichidului de ră-cire -40 215 ºC A-40
0x01 0x06 1reducerea % de combustibil pe termen scurt - BANK 1
(-100) Rich
99.22 Lean % (A-128)*100/128
0x01 0x07 1reducerea % de combustibil pe termen lung - BANK 1
(-100) Rich
99.22 Lean % (A-128)*100/128
0x01 0x08 1reducerea % de combustibil pe termen scurt - BANK 2
(-100) Rich
99.22 Lean % (A-128)*100/128
0x01 0x09 1reducerea % de combustibil pe termen lung - BANK 2
(-100) Rich
99.22 Lean % (A-128)*100/128
0x01 0x0A 1 presiunea combustibilului 0 765 kPa A*3
0x01 0x0B 1presiunea absoluta în galeria de admisie 0 255 kPa A
0x01 0x0C 2 turația motorului 016.383,75 rot/min ((A*256)+B)/4
0x01 0x0D 1 viteza autovehiculului 0 255 km/h A
0x01 0x0E 1 avansul scânteii -64 63.5
º relativ la cilin-drul 1 A/2 – 64
0x01 0x0F 1temperatura aerului pe gale-ria de admisie -40 215 ºC A-40
0x01 0x10 2
masa fluxului de aer care trece la un moment dat prin galeria de admisie 0
655.35 g/s ((A*256) + B)/100
0x01 0x11 1 poziția clapetei de admisie 0 100 % A*100/255
* NBR = numar bytes returnat
28
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.
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
29
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:
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
Diagrama Block ELM 327
31
Schemă de montaj ELM 327
32
Necesar componente electronice
3. DESCRIEREA APLICAȚIEI
3.1 Arhitectura aplicației
3.2 Tehnologii de implementare
3.3 Module implementate – modul monitorizare
3.1 Arhitectura aplicației
33
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ă 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
pot apărea la un moment dat să fie ușor de realizat. Un alt avantaj al acestei abordări,
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ță de interfaț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 la interfața auto), astfel interfața grafică poate fi actualizată
foarte ușor la noile tehnologii de afșare grafică.
Modulul de acces la interfața serială poate fi inlocuit foarte ușor în cazul î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ă.
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.
35
Application GUIApplication GUI
AQU
Com
munication
Layer
Business Logic
+(Core)
Business Logic
+(Core)
Data Access LayerData Access Layer
OBD II Hardware Diagnosis interface
OBD II Hardware Diagnosis interface
SQL LITE
Logger
3.1.1 Application GUI
(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
actualizarea 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ă de
generalitatea modulelor care pot fi integrate cu aplicația. Aceste module pot totodată să
folosească din funcționalitatea de bază implementată pentru diagnosticare ș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 următoare se poate observa modalitatea în care interacționează interfața
grafică principală cu plugin-urile.
36
37
Plugin Selector (Menu) – GUI Element
ADT GUI
Plugin Manager
PLUGIN IFace
GUI Elements
Plugin BLogic
PLUGIN IFace
GUI Elements
Plugin BLogic
PLUGIN IFace
GUI Elements
Plugin BLogic...
Business Logic
Vezi doc. Arh. generală
Business Logic
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 are o
interpretare diferită a informațiilor pe
care le transmite este nevoie să se
implementeze efectiv, codul pentru
decodificarea informațiilor
corespunzătoare fiecărui paramteru în
parte. În acest sens a fost creată
ierarhia de de clase alăturată.
38
Business Logic
Sensor Manager
S1 Imp
S2 Imp
Sn Imp
ISensorSignal
S1 Imp
BaseSensor
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
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.
39
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(){};
};
40
3.1.4 Logger
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
41
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.
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.
42
Sistemele de operare pe care este suportat oficial sunt:
Linux/X11 – Qt pentru X Window System (Unix / Linux)
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
43
librarii de grafica 3D bazate pe OpenGL.
clase template
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
44
3.2.3. Fire de execuție
Qt pune la dispoziție de asemenea și funcționalitate pentru managementul firelor de
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.
45
3.3 Modulul de monitorizare a parametrilor motorului
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
46
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
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
3.3.2 Detalii implemetare modul de monitorizare
47
class IADTPlugin
{
public:
virtual void SetCoreObject(ADTCore* pCore) = 0;
virtual QIcon GetPluginIcon() = 0;
virtual QString GetPluginName() = 0;
virtual QString GetVersionString() = 0;
virtual QWidget* GetWidget() = 0;
virtual ~IADTPlugin(){}
};
Detalii de integrare cu aplicația principală
Pentru a putea realiza integrarea cu aplicația principală este nevoie de implementarea
interfeței IADTPlugin, și actualizarea fișierului de configurare pentru aplicație. Acest
mod facil de integrare este datorat în primul rând arhitecturi interfeței grafice care a
fost gandită în așa fel încât să poată fi extinsă în permanență, fără modificări ulterioare
sau cu modificări minore.
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
48
permite comunicarea între utilizator și modulul de control electronic al motorului.
Detalii de implementare a modulului de achiziție
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ă:
49
ModulAchizitie de date
și traducere ModulAchizitie de date
și traducere
M e t o d a c a r e s e o c u p ă e f e c t i v d e a c h i z i ț i a d a t e l o r e s t e
informația primită de la dispozitivul hardware, elimină informațiile care nu sunt
50
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ă.
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 care să
furnizeze informațiile într-un mod rapid și eventual asincron. În acest sens este nevoie
51
Virtual COM Port(FTDI driver)
ELM 327 Chip
FTDI
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ă
52
BIBLIOGRAFIE
1. www.scantool.net 2. www.wikipedia.org 3. www.obd-codes.com
53
Top Related