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