Documente Academic
Documente Profesional
Documente Cultură
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
1.1 Industria automobilelor
sunt elemente cheie ale sistemelor embedded pe care proiectanţii le doresc pentru
implementarea în sistemele curente şi viitoare. Este tot mai pregnantă competiţia legată
de consumul energetic redus, constrângerile legate de spaţiul ocupat, conectivitatea
ECM pentru posibilitatea de diagnosticare a sistemului, în timp ce costurile trebuie
menţinute cât mai reduse. După cum numărul de ECM-uri continuă să crească,
disponibilul energetic necesar al vehiculului este sub o presiune din ce în ce mai mare.
Unele vehicule de înaltă clasă dispun de peste 80 de ECM-uri, ceea ce înseamnă sarcini
de curent foarte ridicate. O cale de a răspunde acestei cerinţe energetice poate fi
creşterea dimensiunilor bateriei. Însă, bateriile de dimensiuni mai mari nu sunt o
afacere într-un domeniu în care spaţiul este limitat, iar masa este critică pentru a
asigura un minim de consum de carburant. O opţiune mai bună este concentrarea
asupra cerinţelor de consum energetic ale ECM-urilor care operează atunci când
contactul este în stare off. Cu mai multe sarcini de putere prezente atunci când nu există
4
contact, OEM-urile auto restrâng disponibilul energetic la mai puţin de 1mA pe ECM.
O familie de microcontrolere cu management energetic este un element cheie pentru
proiectanţii de sisteme embedded în acest mediu, în care o mare valoare este pusă pe
operaţii eficiente energetic fără sacrificarea performanţelor.
Microcontrolerele cu management energetic oferă proiectantului memorie flash
pe cip, o eficienţă bună a sistemului, o robusteţe crescută cu minimizarea costurilor şi
spaţiului de placă, prin eliminarea componentelor externe. Designerii au la dispoziţie o
mai mare versatilitate prin posibilitatea de a comuta între diverse moduri de
management energetic, care încorporează rutine de economisire de energie în aplicaţiile
software. Tehnologia nanoWatt ce caracterizează microcontrolerele Microchip
Technology PICŽ oferă o bună gestionare energetică pe întreaga lor gamă de frecvenţe
de operare. Aceste caracteristici au fost dezvoltate pentru a le furniza proiectanţilor
opţiuni tehnice fezabile şi economice pentru provocările complexe asociate cu operarea
sigură de joasă putere.
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"...
(Electronic control unit, „Unitate de control electronic”) este un modul pentru comenzi
sau dirijări electronice, care este folosit în locurile unde ceva anume trebuie controlat
comandat. Modulul de control electronic este folosit în sectorul auto în multe aplicaţii
5
electronice, precum şi pentru controlul electronic la dirijarea de maşini, instalaţii
industriale şi multe alte procedee tehnice. Aceste modulele fac parte din sistemele
încorporate.
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.
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.
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
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.
11
control airbag, controlul de distanţă, etc.
Unităţi de control vizibile sunt pe tahometru, în forma lui nouă împreună cu turometru
şi diverse alte indicatoare. Senzori cum ar fi, nivelul combustibilului în rezervor, presiunea
uleiului pot dispune de propriul modul electronic care sunt, printre altele, memorate pe
termen lung.
12
vehiculului. Acesta pot fi legate de aparate de diagnosticare sau cu calculatoare
personale, notebook, avînd o interfaţă corespunzătoare prin care poate să comunice. În
principal sunt căutate şi identificate greşelile pe care modulul electronic a înregistrat la
propriile teste sau la sensorii de legătură. Astfel în atelierle de reparaţii, cu astfel de
mesaje la defecţiuni, se poate evita timp de lucru îndelungat. Adesea sunt utilizate
protocoalele de diagnostic KWP2000 sau UDS, care acesta este specivicat în ISO 14229-1.
În vederea creşterii complexităţii şi solicitării la software, precum şi comunicarea între
ECU-uri, sistemul OSEK-VDX, bazînd pe sistemul de comunicare RTOS. O altă măsură în
vederea creşterii de standardizare a comunicării ECU-urilor. este AUTOSAR.
Între timp, într-un automobil sunt amplasate mai mult de zece module electronice. Unele
automobilele moderne de lux, au instalate chiar peste 70 de module electronice. Gama
de microcipuri variază de la 8- la 32-bit de calculator.
13
1.3 Noutăț i pe piaț a auto - Michelin Active Wheel
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.
15
cu automobilele compacte. Automobilul are două portbagaje, poate acoperi
distanţe mari (între 150 şi 400 km în funcţie de sursa de energie) şi dispune de
mai mult spaţiu pentru echipamentele de comunicaţie.
Motoarele au o eficienţă de 90%, comparativ cu 20%, valoarea caracteristică
motoarelor covenţionale la deplasarea în oraş. Heuliez a reconceput complet
şasiul. Datorită designului său, automobilul este mult mai uşor şi, implicit,
consumul de energie mai redus.
În plus, emisiile de CO2 „well-to-wheel" (de la sursa de combustibil la
vehicul) sunt mai mici de 15 gram per kilometru atunci când WILL foloseşte
energia rezultată din surse hidroelectrice, fotovoltaice, eoliene sau alte surse
ecologice.
Peugeot BB1
`Acest vehicul este prevăzut
cu roata motorizată
Michelin pe axul din spate (foto),
spaţiul interior mărindu-se astfel
în mod semnificativ.
În conformitate cu normele
privind vehiculele pe patru roţi,
capacitatea este mai mică de 15
kW (20 CP) sau 7,6 kW, ceea ce
reprezintă o capacitate optimă
dacă se are în vedere greutatea şi
faptul că automobilul a fost conceput pentru uz citadin.
Astfel, demarajul se face cu uşurinţă (0 până la 30 km/h în 2,8 secunde) iar
acceleraţia permite vehiculului să ajungă de la o viteză de 30 km/h la o viteză de 60
km/h în doar 4 secunde. Bateriile litiu-ion permit deplasarea pe o distanţă de 120 km.
16
1.4 Interfeţe de diagnoză auto
Interfeţele de diagnoză auto sunt utilizate pentru determinarea stării tehnice a
automobilului. Aceste sisteme de diagnoză pot fi utilizate pentru diagnosticarea
autovehiculului, monitorizarea în timp real a unor senzori, etc., atât de tehnicieni în
service-uri specializate, cât şi de proprietarii maşinilor. În ziua de astăzi automobilele
reprezintă zeci de computer interconectate cu zeci sau sute de senzori şi mecanisme
ultrasofisticate care au nevoie să funcţioneze impecabil. Ai becuri martor aprinse pe
bord deşi maşina pare să meargă normal? Vrei să modifici parametrii maşinii sau să
vezi şi să ştergi coduri de eroare, defecţiuni, resetezi intervale de service, să verifici un
automobil înainte de cumpărare? Poţi face toate astea fără ajutorul unui specialist prin
utilizarea interfeţei de diagnoză disponibilă (OBD II).
În continuare vom prezenta mai multe interfeţe de diagnoză disponibile pentru
diverşi producători de automobile:
ELM327
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
17
modelele OPEL (1995-2007):
1. Motor
2. Transmisie
3. Airbag
4. ABS
5. ESP
6. Suspensie adaptivă
7. Keyless Go
8. Climatronic
9. Scaune electrice
18
1. Presiune turbo
2. Încărcare alternator
3. Temperatura apă
4. Temperatură ulei
5. Parametrii injectoare
6. Tensiuni şi alte valori, etc.
MONITORIZAREA AUTO
19
2.1 Aplicaț ii existente
20
software-ul dezvoltat de diverși există și aplicații proprietar, care sunt dezvoltate de
către producătorii de mașini sau de către asociați ai acestora. În mod normal o
aplicație venită de la producătorul mașinii oferă access total la absolute toate modulele
electronice ale automobilului. Dezavantajul pentru acest gen de aplicații este ca nu
funcționează pentru alte mărci de autovehicule și software-ul este mult mai costisitor,
de aici a apărut necesitatea dezvoltării de software independent de producător. Software
care să permită diagnosticarea indifferent de producătorul mașinii. Într-o oarecare
măsură s-a reușit implementarea aplicațiilor dar acestea nu pot oferii funcționalitate
completă datorită faptului că fiecare producător pe lângă codurile de eroare standard și
pe lângă identificatorii de parametrii (PID – parameter identifier) standard au definit
coduri și identificatori specifici fiecărui constructor în parte, este astfel posibil ca un
cod de eroare să semnifice un anumit lucru pentru un autovehicul Opel, iar pentru un
automobile marca BMW să reprezinte cu totul altceva. În general software-ul proprietar
este folosit numai de către service-urile reprezentante ale constructorului, costurile
ridicate de procurare și de întreținere îi determină pe mulți să caute alte soluții. După
studiile facute pe piață am putea sa clasificăm acest gen de software în următoarele
categorii:
1. Software Profesional Proprietar – oferit de către constructorul de mașini sau
de parteneri ai acestora (Fiecare producător important de mașini pune la
dispoziție un astfel de software)
2. Software Profesional cu posibilitate de diagnosticare și monitorizare pe
modulul de motor
3. Software de diagnoză și monitorizare pentru hobby-sti.
De asemenea în ultimul timp au început să apară versiuni de software implementate
pentru dispozitive mobile, care combină utilitățile de diagnosticare și monitorizare a
motorului cu posibilitățile de folosire a modulelor GPS și chiar telefonie mobilă, în
acest fel se folosește același dispozitiv pentru mai multe scopuri care aparent nu au nici
o legătură. Posibilitatea utilizării acestui gen de software a apărut odată cu creșterea
puterii de calcul ce poate fi integrată pe cm pătrat.
Mai jos sunt câteva capturi de ecran cu diverse aplicații de diagnoză și monitorizare
21
ProScan de la ScanTools
auto.
22
Rev App, de la DevToaster, care după cum se vede în imagini rulează pe dispozitive
iPhone.
23
2.2 Standardul ODB II
Sistemele OBD (On Board Diagnostic) sunt prezente pe toate autovehiculele produse în
prezent. Pe la sfârsitul anilor ’70 începutul anilor ’80 constructorii de mașini au început
să utilizeze module electronice pentru a controla diverse funcționalități ale motorului
pentru a se putea încadra în normele de poluare impuse de organizațiile de protecție a
mediului. De-a lungul timpului, numărul de funcționalități implementate cu ajutorul
electronicii a crescut și astfel sistemele de diagnosticare au devenit din ce în ce mai
complexe. OBD II, este un standard introdul la mijlocul anilor 90, și furnizează un
control aproape total asupra parametrilor motorului și de asemenea monitorizează părți
ale șasiului și diverse accessorii, ca de altfel și rețeaua de control pentru sistemul de
diagnosticare al mașinii.
Cum a apărut OBD II?
Pentru a combate problemele generate de smog, în L.A., autoritățile statului California
au început să impună sisteme de control al emisiilor de dioxid de cabon în 1966, în
1968 aceste măsuri au fost extinse la nivelul SUA. În 1970 congresul, a aprobat înfi-
ințarea EPA (Environmental Protection Agency), care avea să impună normele de polu-
are pentru autovehiculele care urmau a fi produse. Pentru a îndeplini aceste norme con-
structorii au fost nevoiți să apeleze la sisteme electronice pentru a controla cantitatea
de combustibil care este consumată cât și pentru controlul aprinderii. La început erau
câteva standarde și fiecare producător avea propriile sisteme și parametrii. În 1988, So-
cietatea Inginerilor din domeniul Auto (SAE – Society of Automotive Engineers) a sta-
bilit un conector standard pentru interfața de diagnosticare și a stabilit un set de
parametrii utilizați pentru diagnosticare și monitorizare. EPA a adaptat mai apoi mai
toate standardele pornind de la recomandările și programele de diagnosticare ale SAE.
Așadar OBD II este un set extins de standarde dezvoltat de SAE și adoptat de EPA pen-
tru implementare în anul 1996. Așadar toate autovehiculele produse începând cu anul
1996 au standardul OBD II implementat. OBD II, nu este doar o interfață de
diagnosticare, ci poate face mult mai multe lucruri.
24
- Autovehiculele care sunt echipate cu OBD-II au cel puțin 2 senzori de
oxigen, majoritatea cu senzori încălziți.
25
Parametrii citiți în prezent au asociat fiecare câte un identificator, în funcție de
acest identificator computer-ul care controlează motorul știe ce valori să trimită în mo-
mentul în care este interogat, și cum să codeze informația. În mod normal pentru a pri-
mi informații de la modulele electronice care echipează autovehiculele este nevoie de
un dispozitiv hardware special care să fie capabil să trimită și să primească date uti-
lizând rețeaua internă de comunicare a autovehiculului. Există mai multe protocoale
de intercomunicare între modulele autovehiculelor și anume: CAN, VPW, PWM,
ISO, KWP. Începând cu anul 2008, toți producătorii sunt obligați să folosescă proto-
colul CAN pentru intercomunicarea între modulele care echipează autovehiculele.
Acest lucru va duce pe viitor la o simplificare a modulelor de diagnosticare și monitor-
izare și va permite creșterea vitezei de achiziție a informațiilor, din moment ce dispoz -
itivul hardware de achiziție nu va trebui să “cunoasca”, decât un singur protocol.
În prezent standardul OBD II presupune existența unui număr de 10 moduri de lucru
descrise în standardul SAE J1979 .
26
Producătorii de autovehicule nu sunt obligați să implementeze toate aceste moduri, și
fiecare producător poate defini moduri suplimentare, moduri mai mari ca număr de
identificare decât 9. Exemplu modul 22 este definit de Ford/GM pentru obținerea de
alte informații decât cele prevăzute în standard, modul 21 este definit pentru Toyota.
În tabelul următor se prezintă o parte din identificatori de parametrii utilizați pentru
obținerea informațiilor de monitorizare a motorului, după cum se poate observa o
parte din parametrii sunt codați pe biți. Aceștia se decodează după cum urmează:
Mod 1 – PID 0x01 – O cerere de acest gen returnează 4 octeți, bitul 8 al primului octet
(A7) indică dacă martorul MIL este aprins sau nu, biții A6…A0 indică numărul co-
durilor de eroare. Octeții 2, 3, 4 dau informații despre prezența și efectuarea anumitor
teste incorporate în modulele instalate.
27
Încărcarea calculată a mo-
0x01 0x04 1 torului 0 100 % A*100/255
Temperatura lichidului de ră-
0x01 0x05 1 cire -40 215 ºC A-40
reducerea % de combustibil (-100) 99.22
0x01 0x06 1 pe termen scurt - BANK 1 Rich Lean % (A-128)*100/128
reducerea % de combustibil (-100) 99.22
0x01 0x07 1 pe termen lung - BANK 1 Rich Lean % (A-128)*100/128
reducerea % de combustibil (-100) 99.22
0x01 0x08 1 pe termen scurt - BANK 2 Rich Lean % (A-128)*100/128
reducerea % de combustibil (-100) 99.22
0x01 0x09 1 pe termen lung - BANK 2 Rich Lean % (A-128)*100/128
28
A2 – funcționare în buclă deschisă datorită încărcării motorului sau oprire
alimentare datorită rulării în frână de motor
A3 – funcționare în buclă deschisă datorită defecțiunilor sistemului de gestiune
A4 – funcționare în buclă închisă, folosind cel puțin un senzor de oxygen dar,
există o problemă în sistemul de răspuns
A5-A7 – întotdeauna 0.
Acest circuit poate avea diverse utilizări pentru cititoare de erori, instrumente pentru
scanare, dar și în scopuri didactice.
În figura următoare se poate vedea diagrama bloc a acestui circuit:
29
Diagrama Block ELM 327
30
Schemă de montaj ELM 327
31
3. DESCRIEREA APLICAȚ IEI
32
3.1 Arhitectura aplicaț iei
Aplicația este structurată în așa fel încât să fie flexibilă, în momentul în care
vine vorba de o dezvoltare și actualizare ulterioară. Această flexibilitate este obținută
33
Application GUI
prin realizarea unei cuplări slabe între module, modulele fiind cuplate într-o arhitectură
multinivel. Se pot adauga noi module prin simpla implementare a unor interfețe, și
actualizarea unui fișier de configurație fără a mai fi nevoie de alte modificări în codul
de bază al aplicației. De asemenea arhitectura multinivel permite separarea
funcționalităților ajungându-se în acest fel, ca depanarea erorilor și problemelor care
Communica
tion Layer
Business Logic
AQU
pot apărea la un moment dat să fie ușor de realizat. Un alt avantaj al acestei abordări,
+(Core)
este reprezentat de faptul că se poate realiza o testare modulară și se pot realiza unități
de test automatizate pentru fiecare modul în parte, timpul alocat testării putând fii
diminuat cu 60 – 70%.
Un alt lucru important care s-a urmărit în momentul în care această aplicație a fost
proiectată, a fost separarea funcționalității de bază, față deData Access
interfa Layer
ța grafică, în felul
acesta interfața grafică poate fi înlocuită în orice moment fără a fi nevoie să se rescrie
funcționalitatea de logică a aplicației (modulul de conectare la interfața auto, modulul
de citire a informațiilor de OBD
la interfa ța auto), astfel interfața grafică poate fi actualizată
II Hardware
foarte ușor la noile tehnologii Diagnosis
de afșare grafică.
interface
Modulul de acces la interfața serială poate fi inlocuit foarte ușorSQL
în cazul
LITE în care se
dorește utilizarea altei interfețe de comunicare (se doreste utilizarea unei interfețe
USB, Ethernet, etc.), singurul lucru care ar trebui schimbat în acest caz este
implementarea modului de comunicare pentru protocolul dorit și actualizarea în
modulul de bază pentru a folosi noul modul de comunicare, specificându-se modulul de
comunicare ce va fi folosit, fără a mai fi nevoie de alte modificări în codul de bază
pentru a face aplicația funcțională.
Logger
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 Graphical User Interface) sau Interfața Grafică de prezentare a
aplicației.
Scopul principal al acestei componente este de a prezenta utilizatorului într-un mod cât
mai prietenos și mai ușor de analizat informațiile puse la dispoziție de sistemul de
management al motorului, aici includem parametrii obținuți în timpul funcționării cât
și informații memorate pentru analiză în memoria internă a ECU. (Unitatea de control
a motorului). Pentru a realiza o interfață care să fie cât mai ușor de folosit, este nevoie
de ca aceasta să fie împărțită pe funcționalități. În primă fază aplicația poate să fie
folosită în două scopuri:
− Diagnosticarea problemelor apărute la motor
− Monitorizarea parametrilor de funcționare a motorului
Dacă se dorește integrarea de noi funcționalități (modul de navigare GPS, modul de
Rapoarte etc.), acestea se pot integra cu aplicația prin implementarea unui nou modul
și actualizareaADT GUI
unui fișier de configurare. Modulele noi care se implementează trebuie
să respecte un anumit șablon pentru a putea fi integrate, această restricție este impusă
Plugin Selector (Menu) – GUI Element
de generalitatea modulelor care pot fi integrate cu aplicația. Aceste module pot
totodată să folosească din funcționalitatea de bază implementată pentru diagnosticare
Plugin Manager
și monitorizare.
În continuare aceste module pentru interfața grafică o să le numim plugin-uri.
Plugin-urile pot fi adaugate sau scoase din interfața grafică prin simpla editare a
fișierului de configurare, așadar aplicația se poate personaliza foarte ușor.
În figura
PLUGIN IFaceurmătoare se poate observa ționează
modalitatea în care interacPLUGIN
PLUGIN IFace IFaceinterfața
Business Logic 36
Vezi doc. Arh.
generală
3.1.2 Business Logic – Core
Logica de funcționalitate
Acest nivel implementează logica după care se realizează achiziția de date, și este
folosit atât la implementarea achiziției de informații pentru diagnosticarea
defecțiunilor cât și pentru achiziția de date în vederea monitorizării parametrilor de
funcționare. Modulul implementat pentru acest nivel se folosește de nivelul de
comunicare pentru a obține informații de la interfața hardware. În momentul în care
au fost obținute informațiile dorite de la interfața hardware acestea trebuie decodate
pentru a putea interpreta in mod corect datele primite, iar acest lucru este realizat în
acest nivel. În momentul în care informațiile sunt transmise în nivelurile superioare
acestea sunt puse într-un format corespunzător necesităților. Spre exemplu interfața
grafică, pentru a afișa numărul de rotații pe minut are nevoie de un numar intreg, dar
interfața hardware trimite aceste informațiile sub forma unui șir de caractere ASCII in
format hexazecimal, așadar pentru a putea utiliza informația primită este nevoie ca
aceasta să fie interpretată și adusă în formatul corespunzător. În acest context, având în
vedere faptul că fiecare parametru citit Business Logic
are o interpretare diferită a
Sensor Manager
informațiilor pe care le transmite este
ISensorSignal
nevoie să se implementeze efectiv,
BaseSensor
codul pentru decodificarea
informațiilor corespunzătoare fiecărui
paramteru în parte. În acest sens a fost
creată ierarhia de de clase alăturată.
S1 Imp S2 Imp Sn Imp
37
3.1.3. HW Communication Layer
1. Trimitere mesaje
2. Primire mesaje
3. Determinarea erorilor care apar la comunicare
4. Configurare
5. Initializare conexiune
6. Inchidere conexiune
La nivelul implementării au fost considerate mai multe modalități prin care se poate
realiza parametrizarea funcțiilor de trimitere/primire de mesaje. După cum se poate
observa în secvența următoare de cod, primirea de mesaje se poate realiza prin citirea
de pe interfață a datelor până la primirea unui anumit caracter. Acestă abordare este
utilă în cazul dispozitivului de diagnoză auto ELM 327, pentru că toate mesajele de
răspuns la interogările venite din partea utilizatorului se termină cu '>', și de cele mai
multe ori pentru a putea interpreta informația de la dispozitiv este necesar întreg
38
răspunsul, așadar este necesar să se aștepte până când se primește semnul care
marchează sfârșitul răspunsului.
class IGenericCommunication
{
public:
virtual ~IGenericCommunication(){};
};
3.1.4 Logger
39
Modulul de monitorizare a execuției
Această componentă este necesară pentru a putea monitoriza erorile care pot apărea în
momentul în care aplicația este folosită de utilizatori ce pot genera scenarii de utilizare
care nu au fost luate în calcul în momentul în care a fost proiectată aplicația.
Componenta este de fapt un modul care pune la dispoziție celorlalte module ale
aplicației o interfață abstractizată pentru a marca execuția unor blocuri de cod.
Marcare blocurilor de cod permite crearea unei urme de execuție care poate fi analizată
pentru a reproduce pașii prin care a trecut utilizatorul înainte de obține anumite erori
sau înainte de a ajunge la un comportament neașteptat din partea aplicației. Nu este de
dorit întotdeauna ca acest sistem de monitorizare să fie activat, acest lucru fiind datorat
impactului pe care îl poate avea asupra performanței aplicației. Având în vedere faptul
că de cele mai multe ori, pentru stoca informația din aceste sisteme de monitorizare, se
folosește harddisk-ul care are un timp de răspuns relativ mare comparativ cu memoria
internă și viteza de execuție a procesorului folosirea sistemelor de monitorizare reduce
în mod vizibil viteza de execuție, lucru care de cele mai multe ori, în aplicațiile în care
timul de execuție este critic, nu este acceptabil. Există totuși o soluție și pentru aceste
aplicații și anume folosirea unor cozi de mesaje care să fie descărcate mai apoi pe
hard-disk folosind un fir de execuție separat. Avantajul în acest caz este faptul ca
timpul de execuție al codului aplicației este influențat nesemnificativ, dar apare
dezavantajul că este posibil ca în momentul apare o eroare care sa genereze închiderea
forțată a aplicației anumiți pași de execuție sa nu fie scriși pe suportul de stocare. Un
astfel de sistem de logare, care permite folosirea multithreading este log4cxx, care are
deasemenea implementări pentru mai multe platforme de dezvoltare, cum ar fi Java
(log4j), Microsoft .NET (log4net). În aplicația noastră nu am folosit un sistem deja
implementat, ci am implementat unul nou deoarece necesităție aplicației referitor la un
astfel de sistem sunt minime, de aceea nu se justifică introducerea unui sistem complex
cum este log4cxx numai pentru acest lucru. De aceeea am implementat un modul
simplu care realizează operații de bază pentru scrierea de pe hdd.
40
3.2 Tehnologiile folosite pentru dezvoltarea
aplicaț iei.
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.
41
• Mac OS X – Qt pentru Apple Mac OS X. Suport pentru aplicațiile peste API-urile
Cocoa.
• Windows – Qt pentru Microsoft Windows
42
3.2.1 Interfaț a grafică
Qt-ul a fost dezvoltat în primă fază pentru a oferi dezvoltatorilor de software un
mod comun de creare a interfețelor grafice care să se integreze cu sistemul gazdă pe
care rulează aplicația. Din această cauză în momentul în care se rulează o aplicație Qt
aceasta va avea comportamentul și asemănarea standard întâlnite pe sistemul de
operare gazdă. Desigur se pot realiza și interfețe grafice personalizate dacă cei care
dezvoltă software-ul doresc acest lucru. În ultimele versiuni s-a Style Sheet-ul, un meta
limbaj care oferă o flexibilitate deosebită atunci când vine vorba de personalizarea
elementelor care alcătuiesc interfața grafică. Avantajul folosirii acestui framework în
momentul în care se dorește o personalizare a interfețelor grafice, este acela ca
optimizează viteza de execuție și consumul de memorie.
44
3.3.1 Descriere generală, justificare
class IADTPlugin
{
3.3.2 Detalii implemetare modul de monitorizare
public:
virtual void SetCoreObject(ADTCore* pCore) = 0;
Detalii de integrare cu aplicaț ia principală
Pentru a putea realiza
virtualintegrarea cu aplicația principală
QIcon GetPluginIcon() = 0; este nevoie de implementarea
interfeței IADTPlugin, și actualizarea fișierului de configurare pentru aplicație. Acest
virtual QString GetPluginName() = 0;
mod facil de integrare este datorat în primul rând arhitecturi interfeței grafice care a
șa fel încât
fost gandită în avirtual să poată
QString = 0; ță, fără modificări ulterioare
fi extinsă în permanen
GetVersionString()
virtual ~IADTPlugin(){}
};
46
După cum se poate observa plugin-ul trebuie să pună la dispoziție metode pentru
a putea seta interfața către modulul care încorporează funcționalitatea principală.
Funcționalitatea principală se referă la funcționalitatea folosită pentru a accesa datele
primite de la dispozitivul de achiziție. Este nevoie de un nivel intermediar între datele
brute primite de la dispozitivul hardware interfața grafică, datorită faptului că datele
primite nu se află într-un format care să permită o interpretare facilă. Rolul nivelului
intermediar este de a comunica prin intermediul dispozitivului hardware de achiziție,
cu ECU (Engine Control Unit) și a prelua informațiile pe care să le ofere nivelelor
superioare în formatul dorit, mai pe scurt acest nivel are rolul unui translator, care
permite comunicarea între utilizator și modulul de control electronic al motorului.
Modul
Achizitie de date
și traducere Modul
Achizitie de date
și traducere
47
Parametrii monitorizați de aplicație se rezumă la valori numerice, așadar nu este
o problemă dacă pornim de la premisa că toți parametrii pot fi caracterizați prin valori
numerice reale. Acest lucru este foarte important în structurarea generală a ierarhiei de
clase utilizată pentru accesarea valorilor citite de la senzori. Având în vedere că
protocolul de comunicare între modulul software de achiziție și dispozitivul hardware
este relativ simplu și există o similiaritate pentru achiziția pe diferiții senzori, o sa
avem o parte de cod comună pentru toate clasele care se ocupă de interpretarea datelor
primite de la ECU. Transpus în programarea orientată pe obiecte, acest lucru este
echivalent cu implementarea unei clase de bază care implementeze funcționalitatea
comună și mai apoi derivarea claselor care se ocupă de interpretarea rezultatelor din
această clasă. Pentru a vă crea o imagine clară a acestui aspect se poate analiza
diagrama UML care urmează:
48
Metoda care se ocupă efectiv de achiziția datelor este GetSensorData, care
49
filtrează informația primită de la dispozitivul hardware, elimină informațiile care nu
sunt necesare, transformă informația din format ASCII în format binar și returnează
rezultatul la adresa de memorie specificată. Pentru a accesa dispozitivul hardware se
folosește o interfață serială emulată, deoarece conectarea dispozitivului la PC se
realizează prin intermediul USB. Se realizează de fapt un „bridge” soft între interfața
serială și interfața USB. Dispozitivul hardware de achiziție are în componență un
circuit integrat FTDI care face conversia de la USB → UART RS-232 (procesorul
dispozitivului de achiziție primește comenzi prin intermediul interfeței seriale).
Producatorul acestui chip pune la dispoziție driver-ul pentru crearea unui port serial
irtual, lucru care îi scutește pe cei care scriu aplicațiile de necesitatea scrierii de drivere
pentru comunicarea prin USB și același timp asigură compatibilitatea cu vechile
aplicații care foloseau interfața serială pentru comunicarea cu dispozitivele hardware.
Așadar la nivel de aplicație interfața de comunicarea se vede ca o interfața serială
obișnuită.
FTDI
50
care să furnizeze informațiile într-un mod rapid și eventual asincron. În acest sens este
nevoie de memorarea temporară a datelor primite de la autovehicul, și interpolarea
acestora pentru obținerea de aproximări. Astfel există un fir de execuție separat care
interoghează ECU în vederea primirii informațiilor dorite, iar în momentul în care
aceste informații sunt primite sunt puse într-o zonă de memorie comună care va fi
utilizată apoi în momentul în care modulul de monitorizare este solicitat pentru a
furniza anumite informații. Acest lucru ne asigură de faptul că nu se ajunge la situații
în care să fie probleme cu blocarea interfeței din cauza faptului că modulul electronic
întârzie în livrarea informației dorite, făcând mai puțin vizibil efectul pe care îl are
comunicația lentă între dispozitivul electronic și soft.
BIBLIOGRAFIE
51
1. www.scantool.net
2. www.wikipedia.org
3. www.obd-codes.com
52