CUPRINS

1. Introducere
1.1 1.2 1.3
1.4

Industria automobilelor Utilizarea electronicii n industria auto Nout i n domeniu 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 3.2 3.3 Arhitectura aplica iei Tehnologii de implementare folosite 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

1.1 Industria automobilelor

n anul 2009 au fost produse la nivel mondial mai mult de 60 de milioane de autovehicule, incluznd automobile i autoutilitare. Datorit acestor vnzri, industria auto este cel mai important sector al economiei cu cele mai mari venituri. n anul 2007 au fost vndute la nivel mondial un numr 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. Pieele din America de Nord i Japonia au stagnat, n timp ce alte piee ca cele din America de Sud i unele pri din Asia au crescut puternic. Din cele mai importante piee, China, Rusia, Brazilia i India au cunoscut cele mai mari creteri; China devenind att cel mai mare productor de automobile, ct i cea mai mare pia dup masiva cretere din 2009. n primele 5 luni din 2010, numrul total de automobile vndute a fost de 7.61 milioane n China (4.62 milioane n SUA) i numrul total de vnzri ateptate este n jur de 17 milioane (13.65 milioane n 2009), adic aproape dublu dect piaa din SUA. Aproape 250 milioane de autovehicule sunt utilizate n Statele Unite. La nivel global erau n jur de 806 milioane de maini i camioane uoare n anul 2007, consumnd 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 soluiile implementate sunt datorate noilor module de control electronic (ECM), fcnd 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 proiectanii le doresc pentru implementarea n sistemele curente i viitoare. Este tot mai pregnant competiia legat de consumul energetic redus, constrngerile legate de spaiul ocupat, conectivitatea ECM pentru posibilitatea de diagnosticare a sistemului, n timp ce costurile trebuie meninute ct mai reduse. Dup cum numrul 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 rspunde acestei cerine energetice poate fi creterea dimensiunilor bateriei. ns, bateriile de dimensiuni mai mari nu sunt o afacere ntr-un domeniu n care spaiul este limitat, iar masa este critic pentru a asigura un minim de consum de carburant. O opiune mai bun este concentrarea asupra cerinelor de consum energetic ale ECM-urilor care opereaz atunci cnd contactul este n stare off. Cu mai multe sarcini de putere prezente atunci cnd nu exist

contact, OEM-urile auto restrng disponibilul energetic la mai puin de 1mA pe ECM. O familie de microcontrolere cu management energetic este un element cheie pentru proiectanii de sisteme embedded n acest mediu, n care o mare valoare este pus pe operaii eficiente energetic fr sacrificarea performanelor. Microcontrolerele cu management energetic ofer proiectantului memorie flash pe cip, o eficien bun a sistemului, o robustee crescut cu minimizarea costurilor i spaiului de plac, prin eliminarea componentelor externe. Designerii au la dispoziie o mai mare versatilitate prin posibilitatea de a comuta ntre diverse moduri de management energetic, care ncorporeaz rutine de economisire de energie n aplicaiile software. Tehnologia nanoWatt ce caracterizeaz microcontrolerele Microchip Technology PIC ofer o bun gestionare energetic pe ntreaga lor gam de frecvene de operare. Aceste caracteristici au fost dezvoltate pentru a le furniza proiectanilor opiuni tehnice fezabile i economice pentru provocrile 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, chiptuning pentru a mari performantele masinii prin rescrierea softului computerului auto. Cnd apare o eroare si masina nu mai vrea sa porneasca de pe loc, vinovat e computerul auto. Cnd 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 dirijri electronice, care este folosit n locurile unde ceva anume trebuie controlat comandat. Modulul de control electronic este folosit n sectorul auto n multe aplicaii
5

electronice, precum i pentru controlul electronic la dirijarea de maini, instalaii industriale i multe alte procedee tehnice. Aceste modulele fac parte din
ncorporate. sistemele

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 rnd 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, reglnd 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 dect 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 dect ceea ce a fost programat sa faca: adica sa calculeze niste valori pe baza datelor primite de la senzori Ce se intmpla 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 pna 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 dect 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 diferii senzori sunt contradictorii, caz n care ECU consider c cel puin unul din aceti 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 dect 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 nti 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, cnd 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 att din usa soferului ct 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 rndul lor furnizau aceste subansamble mai multor producatori, utiliznd 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 ntmpla mai departe cu datele furnizate de modulele lor, iar pe constructorii de autoturisme nu i mai intereseaza modul de functionare al subansamblului atta timp ct el furnizeaza datele de care are nevoie. Dupa cum am mentionat anterior modulele electronice de control al module electonice sunt folosite pentru reglarea aprinderii i la Aproximativ de la mijlocul
intern, anilor 90 motoarelor,

au

fost utilizate n primul rnd pentru reglarea aprinderii acestora. Din anul 1987 aceste
motoarele diesel.

sistemele de reglare mecanice la

motoarele cu combustie

au fost aproape complet nlocuite de ctre modulele de control electronice.

Modulele de control ECU din componena autovehiculelor includ n afara sistemului de aprindere, printre altele i: sistemul de pornire, de anti-blocare al frnelor (ABS), de climatizare, de
11

control airbag, controlul de distan, etc. Uniti de control vizibile sunt pe tahometru, n forma lui nou mpreun cu turometru i diverse alte indicatoare. Senzori cum ar fi, nivelul termen lung.
combustibilului

rezervor,

presiunea

uleiului pot dispune de propriul modul electronic care sunt, printre altele, memorate pe

1.2.4 Funcionarea modulelor electronice

Modulele electronice lucreaz dup principiul IPO, (n Output, introducere-prelucrare-debitare). Pentru Input-Processvaloriilor sunt

englez

nregistrarea

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 msurat cu valoare prevzut n ECU nu se potrivesc, modulul electronic reglementeaz valoarea prin proces fizic, astfel nct valorile reale msurate 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
computer englez

Embedded system,

sistem ncorporat),

care const dintr-un

separat, sub forma unui sistem ncorporat.

Mrimea acestui computer variaz n funcie de complexitatea sarcinilor sale. n mod semnificativ acesta variaz de la un circuit integrat cu un microprocesor (cu memorie RAM i ROM) pn la sisteme multifuncionale cu un sistem de producie grafic. De obicei
programarea

este realizat prin utilizarea ROM (n

englez

Read Only
programului

Memory, Memorie doar citibila) . Unele sisteme ns permit actualizarea din ECU, prin reprogramarea a memoriei flash la atelierele de specialitate.

Aparatele schimb informaiile cu privire la condiiile de funcionare i alte date relevante ale vehiculului, prin diferite sisteme de interfee (CAN, LIN, MOST, FlexRay). n afara acestora, prin aceste interfee se pot face legtura la
OBD

respectiv diagnosticarea
12

vehiculului. Acesta pot fi legate de aparate de diagnosticare sau cu calculatoare personale,

notebook,

avnd o interfa corespunztoare prin care poate s comunice. n

principal sunt cutate i identificate greelile pe care modulul electronic a nregistrat la propriile teste sau la sensorii de legtur. Astfel n atelierle de reparaii, cu astfel de mesaje la defeciuni, se poate evita timp de lucru ndelungat. Adesea sunt utilizate protocoalele de diagnostic ECU-uri, sistemul ntre timp, ntr-un
KWP2000

sau

UDS,

care acesta este specivicat n

RTOS.

ISO

14229-1.

n vederea creterii complexitii i solicitrii la software, precum i comunicarea ntre

OSEK-VDX,

baznd pe sistemul de comunicare

O alt msur n

vederea creterii de standardizare a comunicrii ECU-urilor. este AUTOSAR.

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 adevrat revoluie. Prin integrarea tuturor componentelor eseniale n roat, acest produs inovator elimin necesitatea unui motor montat sub capota din fa sau din spate, a sistemului tradiional 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 soluie integrat. Michelin Active Wheel este o roat inteligent care propulseaz electric automobilul i care asigur totodat funciile de suspensie i frnare, oferind o manevrabilitate excelent i un confort optim. Cum funcioneaz?

14

Pentru prima dat, roata include nu doar discul de frn, ci i motorul electric de acionare i sistemul de suspensie. n funcie de puterea pe care a fost conceput s o produc, vehiculul poate fi echipat cu patru motoare (cte unul n fiecare roat) sau cu dou motoare (n roile din fa, de exemplu). n acest fel, Michelin Active Wheel permite constructorilor de automobile s continue s conceap vehicule cu traciune pe dou roi sau cu traciune 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 situaie, aceste surse de putere asigur dou beneficii importante: sunt ecologice i asigur o funcionare uniform. Vehiculele echipate cu Michelin Active Wheel nu emit gaze cu efect de ser. Dinamica este susinut i de sistemul de suspensie care stabilete noi standarde din punct de vedere al aderenei i al confortului. Cu Michelin Active Wheel, suspensia vehiculului nu mai este mecanic ci electric. Acest sistem unic asigur un timp rapid de rspuns - doar 0,003 secunde. Toate micrile 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, diferenial sau amortizoare. Astfel, vehiculul devine mult mai uor i mai eficient din punct de vedere energetic. Michelin Active Wheel reprezint o adevrat inovaie tehnologic prin care se ofer o soluie eficient problemelor actuale privind transportul rutier. La evenimentul Michelin Challenge Bibendum 2010 desfurat n acest an n Brazilia la Rio de Janeiro au fost prezentate dou autoturisme dotate cu aceast roat revoluionar: Heuliez Will i Peugeot BB1. WILL are o lungime de 3,70 m, este prevzut cu cinci locuri i este comparabil
15

cu automobilele compacte. Automobilul are dou portbagaje, poate acoperi distane mari (ntre 150 i 400 km n funcie de sursa de energie) i dispune de mai mult spaiu pentru echipamentele de comunicaie. Motoarele au o eficien de 90%, comparativ cu 20%, valoarea caracteristic motoarelor covenionale la deplasarea n ora. Heuliez a reconceput complet asiul. Datorit designului su, automobilul este mult mai uor 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 cnd WILL folosete energia rezultat din surse hidroelectrice, fotovoltaice, eoliene sau alte surse ecologice.

Peugeot BB1
`Acest cu roata vehicul este prevzut motorizat

Michelin pe axul din spate (foto), spaiul interior mrindu-se astfel n n conformitate mod semnificativ. cu normele

privind vehiculele pe patru roi, 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 uurin (0 pn la 30 km/h n 2,8 secunde) iar acceleraia 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 Interfee de diagnoz auto

Interfeele de diagnoz auto sunt utilizate pentru determinarea strii tehnice a automobilului. Aceste sisteme de diagnoz pot fi utilizate pentru diagnosticarea autovehiculului, monitorizarea n timp real a unor senzori, etc., att de tehnicieni n service-uri specializate, ct i de proprietarii mainilor. n ziua de astzi automobilele reprezint zeci de computer interconectate cu zeci sau sute de senzori i mecanisme ultrasofisticate care au nevoie s funcioneze impecabil. Ai becuri martor aprinse pe bord dei maina pare s mearg normal? Vrei s modifici parametrii mainii sau s vezi i s tergi coduri de eroare, defeciuni, resetezi intervale de service, s verifici un automobil nainte de cumprare? Poi face toate astea fr ajutorul unui specialist prin utilizarea interfeei de diagnoz disponibil (OBD II). n continuare vom prezenta mai multe interfee de diagnoz disponibile pentru diveri productori de automobile: ELM327 ELM327 este ultima versiune a interfetei ELM. Suporta toate protocoalele OBDII (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 interfee de diagnoz auto, n continuare vom sublinia utilitatea acestora. Aceste sisteme v vor ajuta s salvai timp i s ctigai 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. ncrcare 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 aplicaii n acest domeniu, o parte din aceste aplicaii fiind oferite n mod gratuit fie cu toat funcionalitatea dezvoltat pn n prezent fie cu funcionalitate parial. Produsele care ofer funcionalitate parial de obicei fac acest lucru pentru promovare. Pe lng
20

software-ul dezvoltat de diveri exist i aplicaii proprietar, care sunt dezvoltate de ctre productorii de maini sau de ctre asociai ai acestora. n mod normal o aplicaie venit de la productorul mainii ofer access total la absolute toate modulele electronice ale automobilului. Dezavantajul pentru acest gen de aplicaii este ca nu funcioneaz pentru alte mrci de autovehicule i software-ul este mult mai costisitor, de aici a aprut necesitatea dezvoltrii de software independent de productor. Software care s permit diagnosticarea indifferent de productorul mainii. ntr-o oarecare msur s-a reuit implementarea aplicaiilor dar acestea nu pot oferii funcionalitate complet datorit faptului c fiecare productor pe lng codurile de eroare standard i pe lng identificatorii de parametrii (PID parameter identifier) standard au definit coduri i identificatori specifici fiecrui 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 ctre service-urile reprezentante ale constructorului, costurile ridicate de procurare i de ntreinere i determin pe muli s caute alte soluii. Dup studiile facute pe pia am putea sa clasificm acest gen de software n urmtoarele categorii: 1. Software Profesional Proprietar oferit de ctre constructorul de maini sau de parteneri ai acestora (Fiecare productor important de maini pune la dispoziie 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 utilitile de diagnosticare i monitorizare a motorului cu posibilitile de folosire a modulelor GPS i chiar telefonie mobil, n acest fel se folosete acelai dispozitiv pentru mai multe scopuri care aparent nu au nici o legtur. Posibilitatea utilizrii acestui gen de software a aprut odat cu creterea puterii de calcul ce poate fi integrat pe cm ptrat. Mai jos sunt cteva capturi de ecran cu diverse aplicaii 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 aplicaie complet din punctul de vedere al componentelor incluse este DashDAQ, care este disponibil att n versiune pentru PC dar i ca versiune instalat pe un dispozitiv mobil. Acest aplicaie folosete un dispozitiv hardware de achiziie special gndit pentru a permite actualizarea parametrilor n timp real observndu-se un timp de rspuns foarte bun. Aceast aplicaie pune la dispozitie support pentru: diagnosticare probleme motor, urmrire parametrii motor, crearea unui jurnal de monitorizare, diverse teste pentru a determina timpul de acceleraie, timpul de franare, monitorizare consum de combustibil, urmrirea nivelului de ncrcare al bateriilor pentru autovehicule hibride. Pe lng toate aceste informaii tehice aplicaia ofer i support pentru modul GPS incorporat n dispozitivul DashDaq i ofer support multimedia pentru filme i muzic. Toate aceste aplicaii au un punct comun i anume interfaa prin care se conecteaz la autovehicul i care trebuie s resprecte standardul impus de OBD II, despre care voi prezenta cteva amnunte 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 sfrsitul anilor 70 nceputul anilor 80 constructorii de maini au nceput s utilizeze module electronice pentru a controla diverse funcionaliti ale motorului pentru a se putea ncadra n normele de poluare impuse de organizaiile de protecie a mediului. De-a lungul timpului, numrul de funcionaliti 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 pri ale asiului i diverse accessorii, ca de altfel i reeaua de control pentru sistemul de diagnosticare al mainii.

Cum a aprut OBD II?

Pentru a combate problemele generate de smog, n L.A., autoritile statului California au nceput s impun sisteme de control al emisiilor de dioxid de cabon n 1966, n 1968 aceste msuri au fost extinse la nivelul SUA. n 1970 congresul, a aprobat nfiinarea EPA (Environmental Protection Agency), care avea s impun normele de poluare pentru autovehiculele care urmau a fi produse. Pentru a ndeplini aceste norme constructorii au fost nevoii s apeleze la sisteme electronice pentru a controla cantitatea de combustibil care este consumat ct i pentru controlul aprinderii. La nceput erau cteva standarde i fiecare productor avea propriile sisteme i parametrii. n 1988, Societatea Inginerilor din domeniul Auto (SAE Society of Automotive Engineers) a stabilit un conector standard pentru interfaa de diagnosticare i a stabilit un set de parametrii utilizai pentru diagnosticare i monitorizare. EPA a adaptat mai apoi mai toate standardele pornind de la recomandrile i programele de diagnosticare ale SAE. Aadar OBD II este un set extins de standarde dezvoltat de SAE i adoptat de EPA pentru implementare n anul 1996. Aadar toate autovehiculele produse ncepnd 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 puin 2 senzori de oxigen, majoritatea cu senzori nclzii.

Modulele de control al traciunii, cu procesoare fie pe 16 (Chrysler) fie pe 32 biti(Ford & GM), sunt capabile s gestioneze peste 15000 de constante noi, adugate de OBD II.

Module cu memorie EEPROM care permit reprogramarea PCM urilor (Program Controlled Module), cu versiuni de software mbuntite.

Injecia de combustibil se face secvenial i nu multi-punct sau prin carburator. Exist senzori pentru msurarea presiunii pe galeria de admisie(MAP) i pentru msurarea cantitii de aer care este folosit de motor n timpul funcionrii (MAF), aceti senzori putnd fi utilizai pentru a determina ncrcarea motorului.

OBD II este un sistem foarte sofisticat i capabil, n ceea ce privete detectarea emisiilor. Dar n momentul n care se pune problema identificrii problemei de ctre mecanici, acesta nu este mai eficient dect OBD I. n prezent se lucreaz la OBD III, care ar trebui s duc OBD II la nivelul urmtor, prin adugarea telemetriei. Folosind un transmitor radio, un autovehicul echipat cu OBD III va fi capabil s raporteze problemele legate de emisii direct ctre un punct tehnic sau o agenie specializat. Sistemul va comunica numrul 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 legturi prin satelit, sau pentru a rspunde la interogri de pe telefonul mobil, dispozitive amplasate pe marginea drumului etc. De ce este lucru intersant pentru autoritile de control, pentru c este eficient i are costuri reduse comparative cu metodele actuale care presupun deplasarea autovehiculelor ctre puncte de control n care inspecia se face n mod manual, iar numrul de verificri care se poate face n fiecare an este limitat.
25

Parametrii citii n prezent au asociat fiecare cte un identificator, n funcie de acest identificator computer-ul care controleaz motorul tie ce valori s trimit n momentul n care este interogat, i cum s codeze informaia. n mod normal pentru a primi informaii de la modulele electronice care echipeaz autovehiculele este nevoie de un dispozitiv hardware special care s fie capabil s trimit i s primeasc date utiliznd reeaua intern de comunicare a autovehiculului. Exist mai multe protocoale de intercomunicare ntre modulele autovehiculelor i anume:
CAN,

VPW, PWM,

ISO, KWP. ncepnd cu anul 2008, toi productorii sunt obligai s folosesc protocolul CAN pentru intercomunicarea ntre modulele care echipeaz autovehiculele. Acest lucru va duce pe viitor la o simplificare a modulelor de diagnosticare i monitorizare i va permite creterea vitezei de achiziie a informaiilor, din moment ce dispoz itivul hardware de achiziie nu va trebui s cunoasca, dect un singur protocol. n prezent standardul OBD II presupune existena unui numr de 10 moduri de lucru descrise n standardul SAE J1979 . 0x01 afiarea datelor curente 0x02 afiarea parametrilor achiziioni n momentul n care care a aprut o anumit defeciune identificat de sistemul de gestiune a motorului. 0x03 afiarea codurilor de diagnosticare pentru defeciunile 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 afiarea codurilor pentru erorile care sunt active n mod curent. 0x08 operaii de control pentru diverse componente/subsisteme 0x09 afiare informaii autovehicul. 0x0A Coduri de eroare permanente (coduri curate)

26

Productorii de autovehicule nu sunt obligai s implementeze toate aceste moduri, i fiecare productor poate defini moduri suplimentare, moduri mai mari ca numr de identificare dect 9. Exemplu modul 22 este definit de Ford/GM pentru obinerea de alte informaii dect cele prevzute n standard, modul 21 este definit pentru Toyota. n tabelul urmtor se prezint o parte din identificatori de parametrii utilizai pentru obinerea informaiilor de monitorizare a motorului, dup cum se poate observa o parte din parametrii sunt codai pe bii. Acetia se decodeaz dup cum urmeaz: Mod 1 PID 0x01 O cerere de acest gen returneaz 4 octei, bitul 8 al primului octet (A7) indic dac martorul MIL este aprins sau nu, biii A6A0 indic numrul codurilor de eroare. Octeii 2, 3, 4 dau informaii despre prezena i efectuarea anumitor teste incorporate n modulele instalate.
Nume test Test disponibil Test incomplet

Lipsa scnteii Sistem de alimentare cu combustibil Componente Rezervat Catalizator Catalizator nclzit Sistem de evacuare Sistem de aer secundar Compresor aer condiionat Senzor de oxygen nclzitor senzor de oxygen Sistem EGR

B0 B1 B2 B3 C0 C1 C2 C3 C4 C5 C6 C7

B4 B5 B6 B7 D0 D1 D2 D3 D4 D5 D6 D7

Nota: se noteaza cu A, B, C, D cei 4 octei primii de la ECU. NBR Mod PID * Descriere Val Min Val Max UM Formula de interpretare
dac bit-ul x este setat (0<=x<=32 ) atunci parametrul cu numrul x este suportat Codare pe bii. Vezi descriere n afara tabelului.

0x01

0x00

parametrii suportai starea sistemului de la ultima stergere a codurilor de eroare, include MIL i numrul codurilor de erorare valorile parametrilor la momentul n care a fost detectat o anumit eroare Starea sistemului de combustibil

N/A

N/A

N/A

0x01

0x01

0x01

0x02

0x01

0x03

Codat pe bii. Vezi descrierea din afara tabelului 27

0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01

0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F

1 1 1 1 1 1 1 1 2 1 1 1

ncrcarea calculat a motorului Temperatura lichidului de rcire reducerea % de combustibil pe termen scurt - BANK 1 reducerea % de combustibil pe termen lung - BANK 1 reducerea % de combustibil pe termen scurt - BANK 2 reducerea % de combustibil pe termen lung - BANK 2 presiunea combustibilului presiunea absoluta n galeria de admisie turaia motorului viteza autovehiculului avansul scnteii temperatura aerului pe galeria de admisie masa fluxului de aer care trece la un moment dat prin galeria de admisie poziia clapetei de admisie

0 -40 (-100) Rich (-100) Rich (-100) Rich (-100) Rich 0 0 0 0 -64 -40

100 215 99.22 Lean 99.22 Lean 99.22 Lean 99.22 Lean 765 255 16.38 3,75 255 63.5 215 655.3 5 100

% C % % % % kPa kPa rot/min km/h relativ la cilindrul 1 C

A*100/255 A-40 (A-128)*100/128 (A-128)*100/128 (A-128)*100/128 (A-128)*100/128 A*3 A ((A*256)+B)/4 A A/2 64 A-40

0x01 0x01

0x10 0x11

2 1

0 0

g/s %

((A*256) + B)/100 A*100/255

* NBR = numar bytes returnat

Pentru decodarea octeilor primii ca rspuns la trimiterea PID-ului 0x03 pentru modul 0x01 se urmrete urmtoarea schem innd cont de faptul c rspunsul este pe 2 octei, 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 funcionare n bucl deschis datorit faptului c motorul nu este nclzit sufficient A1 funcionare n bucl nchis folosind rspunsul senzorilor de oxygen pentru a determina amestecul combustibil/aer.
28

A2 funcionare n bucl deschis datorit ncrcrii motorului sau oprire alimentare datorit rulrii n frn de motor A3 funcionare n bucl deschis datorit defeciunilor sistemului de gestiune A4 funcionare n bucl nchis, folosind cel puin un senzor de oxygen dar, exist o problem n sistemul de rspuns A5-A7 ntotdeauna 0.

2.3 Circuitul integrat ELM 327

Dispozitivul hardware folosit n acest proiect pentru achiziia de date este bazat pe circuitul integrat ELM 327. Acest circuit a fost gndit pentru a se comporta ca un bridge ntre interfaa OBD II a autovehiculului i interfaa RS 232 a calculatoarelor. Caracterisiticile principale ale acestui circuit integrat sunt: 1. Dispune de modul stand by pentru economisirea energiei electrice 2. Baud Rate pn la 500Kbps 3. Detecteaz n mod automat protocolul OBD II, folosit de autovehicul 4. Este complet configurabil, avnd propriul set de comenzi ce permit configurarea dinamic 5. permite monitorizarea acumulatorului Acest circuit poate avea diverse utilizri pentru cititoare de erori, instrumente pentru scanare, dar i n scopuri didactice. n figura urmtoare se poate vedea diagrama bloc a acestui circuit:

29

Diagrama Block ELM 327

Productorul circuitului noteaz faptul c acest circuit se bazeaz pe un dispozitiv PIC 18F2480 produs de ctre Microchip. Aadar este probabil ca toat funcionalitatea acestui circuit sa fie implementat software. Acest lucru crete timpul de procesare a informaiei, din aceast cauz acest circuit nu este potrivit pentru achiziii de date n timp real. Totui avnd n vedere faptul c pentru a realiza un dispozitiv complet funcional este nevoie de foarte puine componente externe pe lng circuitul integrat, uneori este de preferat utilizarea acestui circuit datorit numeroaselor posibiliti de configurare prin intermediul softului. Pentru a evidenia uurina cu care se poate integra acest circuit productorul pune la dispoziie o schem electronic caracteristic. Aceast schem poate fi analizat n imaginea de urmtoare.

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

Aplicaia este structurat n aa fel nct s fie flexibil, n momentul n care vine vorba de o dezvoltare i actualizare ulterioar. Aceast flexibilitate este obinut
33

prin realizarea unei cuplri slabe ntre module, modulele fiind cuplate ntr-o arhitectur multinivel. Se pot adauga noi module prin simpla implementare a unor interfee, i actualizarea unui fiier de configuraie fr a mai fi nevoie de alte modificri n codul de baz al aplicaiei. De asemenea arhitectura multinivel permite separarea funcionalitilor ajungndu-se n acest fel, ca depanarea erorilor i problemelor care pot aprea la un moment dat s fie uor de realizat. Un alt avantaj al acestei abordri,
+(Core)

Application GUI

este reprezentat de faptul c se poate realiza o testare modular i se pot realiza uniti de test automatizate pentru fiecare modul n parte, timpul alocat testrii putnd fii diminuat cu 60 70%. Un alt lucru important care s-a urmrit n momentul n care aceast aplicaie a fost proiectat, a fost separarea funcionalitii de baz, fa deData Access Layer felul interfaa grafic, n acesta interfaa grafic poate fi nlocuit n orice moment fr a fi nevoie s se rescrie funcionalitatea de logic a aplicaiei (modulul de conectare la interfaa auto, modulul de citire a informaiilor de OBD II Hardware la interfaa auto), astfel interfaa grafic poate fi actualizat foarte uor la noile tehnologii Diagnosis grafic. de afare
interface

Modulul de acces la interfaa serial poate fi inlocuit foarte uor n cazul n care se SQL LITE dorete utilizarea altei interfee de comunicare (se doreste utilizarea unei interfee 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, specificndu-se modulul de comunicare ce va fi folosit, fr a mai fi nevoie de alte modificri n codul de baz pentru a face aplicaia funcional.
Logger

Diagrama bloc a structurii generale a aplicaiei

AQU Communica tion Layer

Business Logic

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 aplicaiei.

3.1.1 Application GUI

35

(Application Graphical User Interface) sau Interfaa Grafic de prezentare a aplicaiei. Scopul principal al acestei componente este de a prezenta utilizatorului ntr-un mod ct mai prietenos i mai uor de analizat informaiile puse la dispoziie de sistemul de management al motorului, aici includem parametrii obinui n timpul funcionrii ct i informaii memorate pentru analiz n memoria intern a ECU. (Unitatea de control a motorului). Pentru a realiza o interfa care s fie ct mai uor de folosit, este nevoie de ca aceasta s fie mprit pe funcionaliti. n prim faz aplicaia poate s fie folosit n dou scopuri: Diagnosticarea problemelor aprute la motor Monitorizarea parametrilor de funcionare a motorului Dac se dorete integrarea de noi funcionaliti (modul de navigare GPS, modul de Rapoarte etc.), acestea se pot integra cu aplicaia prin implementarea unui nou modul
ADT GUI i actualizarea unui fiier de configurare. Modulele noi care se implementeaz trebuie

s respecte un anumit ablon pentru a putea fi integrate, aceast restricie este impus
Plugin Selector (Menu) GUI Element de generalitatea modulelor care pot fi integrate cu aplicaia. Aceste module pot

totodat s foloseasc din funcionalitatea de baz implementat pentru diagnosticare i monitorizare.

Plugin Manager

n continuare aceste module pentru interfaa grafic o s le numim plugin-uri. Plugin-urile pot fi adaugate sau scoase din interfaa grafic prin simpla editare a fiierului de configurare, aadar aplicaia se poate personaliza foarte uor. n figura PLUGIN IFaceurmtoare
GUI Elements Plugin BLogic

se poate observa modalitatea n care interacPLUGIN IFace ioneaz interfaa PLUGIN IFace
GUI Elements Plugin BLogic GUI Elements Plugin BLogic

grafic principal cu plugin-urile.

...

Business Logic Vezi doc. Arh. general

36

3.1.2 Business Logic Core Logica de funcionalitate

Acest nivel implementeaz logica dup care se realizeaz achiziia de date, i este folosit att la implementarea achiziiei de informaii pentru diagnosticarea defeciunilor ct i pentru achiziia de date n vederea monitorizrii parametrilor de funcionare. Modulul implementat pentru acest nivel se folosete de nivelul de comunicare pentru a obine informaii de la interfaa hardware. n momentul n care au fost obinute informaiile dorite de la interfaa 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 informaiile sunt transmise n nivelurile superioare acestea sunt puse ntr-un format corespunztor necesitilor. Spre exemplu interfaa grafic, pentru a afia numrul de rotaii pe minut are nevoie de un numar intreg, dar interfaa hardware trimite aceste informaiile sub forma unui ir de caractere ASCII in format hexazecimal, aadar pentru a putea utiliza informaia primit este nevoie ca aceasta s fie interpretat i adus n formatul corespunztor. n acest context, avnd n vedere faptul c fiecare parametru citit are o interpretare diferit a
Sensor Manager ISensorSignal BaseSensor Business Logic

informaiilor pe care le transmite este nevoie s se implementeze efectiv, codul pentru decodificarea informaiilor corespunztoare fiecrui paramteru n parte. n acest sens a fost creat ierarhia de de clase alturat.
S1 Imp S2 Imp

Sn Imp 37

3.1.3. HW Communication Layer Nivelul de comunicare cu dispozitivul hardware.

Nivelul de comunicare cu interfaa harware a fost adaugat la aceast aplicaie pentru a putea abstractiza comunicarea ntre aplicaie i dispozitivul de achiziie. n acest fel n momentul n care se dorete schimbarea interfeei de comunicare software-dispozitiv hardware nu o sa fie nevoie de modificri n nivelurile superioare ala aplicaiei, singurele schimbri care se fac sunt realizate numai la acest nivel. Acest lucru se relizeaz practic prin definirea unor clase (interfee) abstracte care urmeaz a fi implementate la momentul la care se cunoate cu exactitate protocolul folosit pentru comunicare. n cadrul aplicaiei noastre am considerat c modulul de comunicaie trebuie s permit executarea urmtoarelor operaii 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 implementrii au fost considerate mai multe modaliti prin care se poate realiza parametrizarea funciilor de trimitere/primire de mesaje. Dup cum se poate observa n secvena urmtoare de cod, primirea de mesaje se poate realiza prin citirea de pe interfa a datelor pn la primirea unui anumit caracter. Acest abordare este util n cazul dispozitivului de diagnoz auto ELM 327, pentru c toate mesajele de rspuns la interogrile venite din partea utilizatorului se termin cu '>', i de cele mai multe ori pentru a putea interpreta informaia de la dispozitiv este necesar ntreg
38

rspunsul, aadar este necesar s se atepte pn cnd se primete semnul care marcheaz sfritul rspunsului.
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 execuiei

Aceast component este necesar pentru a putea monitoriza erorile care pot aprea n momentul n care aplicaia este folosit de utilizatori ce pot genera scenarii de utilizare care nu au fost luate n calcul n momentul n care a fost proiectat aplicaia. Componenta este de fapt un modul care pune la dispoziie celorlalte module ale aplicaiei o interfa abstractizat pentru a marca execuia unor blocuri de cod. Marcare blocurilor de cod permite crearea unei urme de execuie care poate fi analizat pentru a reproduce paii prin care a trecut utilizatorul nainte de obine anumite erori sau nainte de a ajunge la un comportament neateptat din partea aplicaiei. Nu este de dorit ntotdeauna ca acest sistem de monitorizare s fie activat, acest lucru fiind datorat impactului pe care l poate avea asupra performanei aplicaiei. Avnd n vedere faptul c de cele mai multe ori, pentru stoca informaia din aceste sisteme de monitorizare, se folosete harddisk-ul care are un timp de rspuns relativ mare comparativ cu memoria intern i viteza de execuie a procesorului folosirea sistemelor de monitorizare reduce n mod vizibil viteza de execuie, lucru care de cele mai multe ori, n aplicaiile n care timul de execuie este critic, nu este acceptabil. Exist totui o soluie i pentru aceste aplicaii i anume folosirea unor cozi de mesaje care s fie descrcate mai apoi pe hard-disk folosind un fir de execuie separat. Avantajul n acest caz este faptul ca timpul de execuie al codului aplicaiei este influenat nesemnificativ, dar apare dezavantajul c este posibil ca n momentul apare o eroare care sa genereze nchiderea forat a aplicaiei anumii pai de execuie sa nu fie scrii pe suportul de stocare. Un astfel de sistem de logare, care permite folosirea multithreading este log4cxx, care are deasemenea implementri pentru mai multe platforme de dezvoltare, cum ar fi Java (log4j), Microsoft .NET (log4net). n aplicaia noastr nu am folosit un sistem deja implementat, ci am implementat unul nou deoarece necesitie aplicaiei 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 operaii de baz pentru scrierea de pe hdd.
40

3.2 aplica iei.

Tehnologiile

folosite

pentru

dezvoltarea

Limbajul de programare folosit este C++, n primul rnd datorit flexibilitii pe care o ofer n vederea dezvoltrii ulterioare. S-au dezvoltat anumite librrii 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 aprut diverse restricii asupra limbajelor n care acele librrii ar putea fi utilizate. Pentru a putea extinde funcionalitatea 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 funcionalitatea implementat poate rula pe mai multe sisteme de operare i chiar pe dispozitivele mobile, atta timp ct acestea ndeplinesc cerinele hardware necesare.

Acest framework are o istorie de aproximativ 20 de ani, timp n care au fost aduse mbuntiri permanente, fapt ce ne face s credem c acest framework a ajuns la maturitate i prezint garania stabilitii modulelor n condiiile unei utilizri corecte. Iniial acest framework a fost dezvoltat de firma TrollTech pentru ca mai apoi aceasta s fie preluat n 2008 de productorul 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 liceniere: 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 aplicaiile 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 aplicaiilor 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

dispoziie de framework-ul Qt, pentru a ne putea face o idee despre facilitie pe care le pune la dispoziie, vom prezenta n continuare principalele funcionaliti pe care acesta ncearc s le nglobeze i anume: interfaa utilizator access la baza de date comunicaii de reea procesare XML fire de execuie 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 interfeelor grafice care s se integreze cu sistemul gazd pe care ruleaz aplicaia. Din aceast cauz n momentul n care se ruleaz o aplicaie Qt aceasta va avea comportamentul i asemnarea standard ntlnite pe sistemul de operare gazd. Desigur se pot realiza i interfee 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 cnd vine vorba de personalizarea elementelor care alctuiesc interfaa grafic. Avantajul folosirii acestui framework n momentul n care se dorete o personalizare a interfeelor grafice, este acela ca optimizeaz viteza de execuie i consumul de memorie.

3.2.2 Accesul la baze de date

ncepnd 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, rmne acelai sau modificrile 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 dispoziie de asemenea i funcionalitate pentru managementul firelor de
43

execuie, aceast funcionalitate fiind de asemenea independent de platform. Acest lucru este important deoarece Qt-ul reuete s implementeze managementul firelor de execuie la nivelul aplicaiei, 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 reea. Acest modul pune la dispoziie funcionalitate de nivel nalt pentru comunicaii TCP/IP, UDP, implementeaz protocoale internet de uz comun HTTP, FTP

3.2.5 Clase template

O alt clas de funcionalitai, foarte important, pus la dispoziie de acest framework este reprezentat de clasele de tip template pentru manipularea coleciilor de date, i implementarea de algoritmi optimizai pentru regsirea informaiei. Analiznd caracteristicile de mai sus, ne putem da seama c acest framework este unul complet, oferind funcionalitatea necesar att pentru abordarea proiectelor simple ct i pentru proiectele mai complexe. n acelai timp avnd n vedere faptul c acesta se bazeaz pe C++ i n urma compilrii se obine cod nativ, performanele obinute prin dezvoltarea folosind acest framework sunt n mod clar superioare performanelor care ar putea fi obinute 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 urmririi parametrilor live, ai motorului de ctre 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 modificai. Acest lucru se realizeaz de obicei printr-un proces de chip tunning, iar modulul de monitorizare poate fi utilizat pentru a observa n ce msur parametrii motorului au fost modificai n urma acestui proces, putndu-se ajusta parametrii motorului pn n momentul n care se ajunge la nivelul de performan dorit. Un alt scop pentru care poate fi folosit acest modul este evoluia n timp a semnalelor date de ctre sondele lambda pentru a putea stabili dac acestea

funcioneaz 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 crui intensitate variaz n funcie 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, pn cnd gazele de eapament ating temperaturi de 400-500 OC, sonda este ncalzit de o rezistena din interiorul ei, dupa care cldura i va fi furnizat chiar de temperatura gazelor de eapament. 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 eficienei acestuia. Constructorii recomand verificarea sondei la fiecare 30 000 de kilometri sau la fiecare doi-trei ani de functionare a mainii i schimbarea sondei n cazul cnd apar probleme n funcionarea acesteia.

Instrumentele de urmrire a parametrilor motorului, puse la dispoziie de modulul de monitorizare sunt urmtoarele: Vitezometru - cu afiare clasic (ac indicator) i afiare n format numeric Turometru (numarul de rotaii pe minut pentru motor) afiare clasic (ac indicator) i afiare n format numeric instrument pentru monitorizarea temperaturii n amestecului de rcire instrument pentru monitorizarea masei fluxului de aer pe galeria de admisie intrument pentru monitorizarea presiunii pe galeria de admisie instrument pentru determinarea poziiei pedalei de acceleraie

class IADTPlugin {

3.3.2

Detalii implemetare modul de monitorizare

public:

Detalii de integrare cu aplica ia principal

virtual void SetCoreObject(ADTCore* pCore) = 0;

Pentru a putea realiza integrarea cu aplicaia principal este nevoie de implementarea virtual QIcon GetPluginIcon() = 0; interfeei IADTPlugin, i actualizarea fiierului de configurare pentru aplicaie. Acest mod facil de integrare este datorat n primul rnd arhitecturi interfeei grafice care a fost gandit n avirtual QString GetVersionString() = 0; , fr modificri ulterioare a fel nct s poat fi extins n permanen sau cu modificri minore.
virtual QWidget* GetWidget() = 0; virtual ~IADTPlugin(){} }; 46 virtual QString GetPluginName() = 0;

Dup cum se poate observa plugin-ul trebuie s pun la dispoziie metode pentru a putea seta interfaa ctre modulul care ncorporeaz funcionalitatea principal. Funcionalitatea principal se refer la funcionalitatea folosit pentru a accesa datele primite de la dispozitivul de achiziie. Este nevoie de un nivel intermediar ntre datele brute primite de la dispozitivul hardware interfaa 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 achiziie, cu ECU (Engine Control Unit) i a prelua informaiile 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 monitorizai de aplicaie se rezum la valori numerice, aadar nu este o problem dac pornim de la premisa c toi parametrii pot fi caracterizai prin valori numerice reale. Acest lucru este foarte important n structurarea general a ierarhiei de clase utilizat pentru accesarea valorilor citite de la senzori. Avnd n vedere c protocolul de comunicare ntre modulul software de achiziie i dispozitivul hardware este relativ simplu i exist o similiaritate pentru achiziia pe diferiii 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 funcionalitatea 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 achiziia datelor este GetSensorData, care

49

filtreaz informaia primit de la dispozitivul hardware, elimin informaiile care nu sunt necesare, transform informaia din format ASCII n format binar i returneaz rezultatul la adresa de memorie specificat. Pentru a accesa dispozitivul hardware se folosete o interfa serial emulat, deoarece conectarea dispozitivului la PC se realizeaz prin intermediul USB. Se realizeaz de fapt un bridge soft ntre interfaa serial i interfaa USB. Dispozitivul hardware de achiziie are n componen un circuit integrat FTDI care face conversia de la USB UART RS-232 (procesorul dispozitivului de achiziie primete comenzi prin intermediul interfeei seriale). Producatorul acestui chip pune la dispoziie driver-ul pentru crearea unui port serial irtual, lucru care i scutete pe cei care scriu aplicaiile de necesitatea scrierii de drivere pentru comunicarea prin USB i acelai timp asigur compatibilitatea cu vechile aplicaii care foloseau interfaa serial pentru comunicarea cu dispozitivele hardware. Aadar la nivel de aplicaie interfaa de comunicarea se vede ca o interfaa serial obinuit.
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 funcie de senzorul care a furnizat informaia ctre ECU. Avnd n vedere faptul c timpul de rspuns este relativ mare i depinde de viteza bus-ului intern al autovehiculului este posibil de crearea unui mecanism intern
50

care s furnizeze informaiile 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 obinerea de aproximri. Astfel exist un fir de execuie separat care interogheaz ECU n vederea primirii informaiilor dorite, iar n momentul n care aceste informaii 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 informaii. Acest lucru ne asigur de faptul c nu se ajunge la situaii n care s fie probleme cu blocarea interfeei din cauza faptului c modulul electronic ntrzie n livrarea informaiei dorite, fcnd mai puin vizibil efectul pe care l are comunicaia 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