Dispozitiv Electronic de Diagnoza Pentru Automobile

Politehnica

Dispozitiv Electronic de Diagnoza Pentru Automobile

Byadmin ianuarie 1, 2024

PROIECT DE DIPLOMĂ

Dispozitiv electronic de diagnoză pentru automobile

CUPRINS:

LISTĂ DE FIGURI

LISTĂ DE TABELE

PREFAȚĂ

CAPITOLUL 1. INTRODUCERE

1.1. Scopul proiectului

1.2. Avantajele sistemului

1.3. Prezentare generală

1.3.1. Moduri de funcționare

1.3.2. Design exterior

1.4. Aplicația dedicată terminalelor mobile

CAPITOLUL 2. PROTOCOLUL ODB-II

2.1. OBD-II informații generale

2.2. Standardele OBD-II

2.2.1. Standardul ISO 9141-2

2.2.2. Standardul SAE J1939

2.2.3. Alte standarde

2.3. OBD-II pinout

2.4. Moduri de funcționare

2.5. DTC-urile protocolului OBD-II

2.6. PID-urile protocolului OBD-II

CAPITOLUL 3. ARHITECTURA HARDWARE A SISTEMULUI

3.1. Interpretorul ODB-II (microcontroller ELM327)

3.1.1. Caracteristicile structurale și funcționale ale ELM327

3.1.2. Schema bloc a microcontroller-ului

3.2. Controlul afișajului și al alarmei (microcontroller ATMega32)

3.2.1. Caracteristicile structurale și funcționale ale ATMega32

3.2.2. UART (Universal Asynchronous Receiver and Transmitter)

3.3. Interfața RS-232

3.4. Comunicația Bluetooth

3.5. Prezentarea mediului de dezvoltare

3.5.1. Atmel Studio 6.1

3.5.2. Design Spark PCB

3.5.3. Eclipse

CAPITOLUL 4. PREZENTAREA DISPOZITIVULUI PROIECTAT

4.1. Schema bloc de principiu a sistemului

4.1.1. Schema bloc a sistemului OnRoad Diagnostic

4.2. Structura dispozitivului

4.2.1. Modulul de alimentare

4.2.2. Modulul de achiziție

4.2.3. Modulul de interpretare OBD-II (ELM327)

4.2.4. Modulul de control și afișaj

4.2.5. Modulul de comunicație RS-232

4.2.6. Modulul Bluetooth

4.2.7. Modulul de interfață cu utilizatorul

4.3. Proiectarea cablajului imprimat (PCB)

4.3.1. Cablajul imprimat al dispozitivului

4.3.2. Cablajul imprimat al modulului de control

4.4. Software-ul dispozitivului

4.4.1. Inițializarea comunicației UART

4.4.2. Transmisia de caractere respectiv șiruri de caractere prin UART

4.4.3. Recepția de caractere și șiruri de caractere prin UART

4.4.4. Citirea și stocarea datelor unui parametru cerut

4.5. Programarea microcontroller-ului

CAPITOLUL 5. CONCLUZII ȘI CONTRIBUȚII PERSONALE

5.1. Concluzii

5.2. Avantaje

5.3. Contribuții personale

5.4. Dezvoltări ulterioare

BIBLIOGRAFIE

ANEXE

DECLARAȚIE PRIVIND ORIGINALITATEA LUCRĂRII DE DIPLOMĂ

LISTĂ DE FIGURI

Figura 1.1. Imagine frontală a aparatului OnRoad Diagnostic – pagina 15

Figura 1.2. Imagine de sus a aparatului OnRoad Diagnostic – pagina 15

Figura 1.3. Imagine posterioară a aparatului OnRoad Diagnostic– pagina 16

Figura 1.4. Meniul principal al aplicației – pagina 17

Figura 1.5. Lista codurilor de eroare – pagina 17

Figura 1.6. Interfața grafică „Despre” – pagina 18

Figura 2.1. Conectorul ODB-II amplasat în automobile – pagina 19

Figura 2.2. Configurația pinilor pentru standardul ISO 9141-2 – pagina 21

Figura 2.3. Comunicația în cadrul standardului ISO 9141-2 – pagina 21

Figura 2.4.1. Nivelele logice pentru transmisie ale legăturii K – pagina 21

Figura 2.4.2. Nivelele logice pentru recepție ale legăturii K – pagina 22

Figura 2.5. Configurația pinilor pentru standardul SAE J1939 – pagina 22

Figura 2.6. Structura mesajului pentru standardul SAE J1939 – pagina 23

Figura 2.7. Legatura fizică – nivele de semnal – pagina 23

Figura 2.8. Legatura de date – nivele de semnal – pagina 24

Figura 2.9. Modelul OSI al standardului SAE-J1939 – pagina 24

Figura 2.10. Structura conectorului OBD-II amplasat în automobil – pagina 26

Figura 2.11. Structura unui DTC – pagina 27

Figura 3.1. Schema bloc ELM327 – pagina 30

Figura 3.2. Structura unui conector DB9-M – pagina 32

Figura 3.3. Nivelul de semnal – RS-232 – pagina 32

Figura 3.4. Interfața grafică a mediului de dezvoltare (IDE) Atmel Studio – pagina 34

Figura 3.5. Interfața grafică a programului Design Spark 5.1 – pagina 35

Figura 3.6. Interfața grafică a editorului PCB din suita Design Spark 5.1 – pagina 35

Figura 3.7. Interfața grafică a mediului de dezvoltare (IDE) Eclipse – pagina 36

Figura 4.1. Schema de principiu a dispozitivului OnRoad Diagnostic – pagina 37

Figura 4.2. Schema bloc a dispozitivului OnRoad Diagnostic – pagina 38

Figura 4.3. Imagine virtuală a PCB-ului integrat – pagina 39

Figura 4.4. Sursa de alimentare de 5V – pagina 40

Figura 4.5. Sursa de alimentare de 3.3V – pagina 40

Figura 4.6. Circuitul de achiziție de date pentru standardul SAE J1939 – pagina 41

Figura 4.7. Circuit tipic pentru achiziția de date pentru standardul ISO 9141-2 – pagina 42

Figura 4.8. Modulul de achiziție – pagina 43

Figura 4.9. Modulul de control și afișaj – pagina 44

Figura 4.10. Modulul de comunicație RS-232 – pagina 45

Figura 4.11. Modulul bluetooth – pagina 46

Figura 4.12. Modulul bluetooth RN-42 – pagina 46

Figura 4.13. Imagine virtuală a modulului de interfațare cu utilizatorul – pagina 47

Figura 4.14. Modulul de interfață cu utilizatorul – pagina 47

Figura 4.15. PCB-ul sistemului OnRoad Diagnostic – pagina 48

Figura 4.16. PCB-ul modulului de interfață cu utilizatorul – pagina 49

Figura 4.17. Structura registrului UCSRB – pagina 50

Figura 4.18. Structura registrului UCSRC – pagina 50

Figura 4.19. Structura registrului UCSRA – pagina 52

Figura 4.20. Conectorul ICSP10-pin – pagina 54

Figura 4.21. Programatorul DIAMEX-PROG-S – pagina 54

LISTĂ DE TABELE

Tabel 2.1. Configurația pinilor pentru standardele folosite – pagina 26

Tabel 2.2. Modurile de funcționare – pagina 27

Tabel 2.3. PID-urile semnificative – pagina 28

Tabel 3.1. Configurația pinilor pentru conectorul DB9 – pagina 32

Tabel 3.2. Influența baud rate-ului asupra distanței de transmisie – pagina 32

Tabel 3.3. Rata de transfer maximă pentru comunicația bluetooth – pagina 33

Tabel 4.1. Nivele de tensiune pentru circuitul integrat Max3232 – pagina 45

Tabel 4.2. Configurația biților UCSZ1 și UCSZ0 – pagina 51

PREFAȚĂ

"Mașina a devenit …un articol de îmbrăcăminte fără de care ne simțim nesiguri, dezgoliți și incompleți."
Marshall McLuhan

Nevoia de a ne deplasa rapid, de a transporta pe distanțe mari obiecte cu o greutate însemnată s-a dovedit a fi o problema a cărei rezolvare a venit abia în anul 1878 când inginerul german Karl Benz a prezentat pentru prima dată un automobil propulsat de un motor cu combustie internă.

Propunerea sa considerată fantezistă la momentul respectiv a devenit astăzi, la aproape un secol și jumătate, un element banal al vieții cotidiene conform studiului realizat de către compania americană constructoare de automobile Daimler AG din care reiese că în anul 2011 numărul de automobile la nivel global ajunsese la 974 milioane cu un număr de 48 de milioane de unități produse anual.

Această statistică este completată însă și de un bilanț tragic. La nivel global, în fiecare an un număr de aproximativ 1.3 milioane de persoane își pierd viața în accidente rutiere și peste 50 de milioane sunt răniți.

S-a constatat că un număr important al accidentelor rutiere, produse pe șoselele din toată lumea, au fost cauzate de funcționarea necorespunzătoare a sistemelor ce intră în componența unui autoturism.

CAPITOLUL 1. INTRODUCERE

1.1. Scopul proiectului

Acest proiect de diplomă are ca principal scop proiectarea și implementarea unui sistem electronic de diagnoză adresat autoturismelor prin care să se poată interoga unitatea electronică de control (ECU – Engine Control Unit) a acestora cu privire la o serie de parametri de real interes pentru orice șofer indiferent de cunoștințele tehnice de care dispune.

Sistemul va fi interconectat cu autoturismul conform celor două standarde ale protocolului OBD-II, utilizate pe scară largă preponderent de producători din Europa și Asia, ISO 9141-2 respectiv SAE J1939.

Citirea și stocarea datelor se va putea realiza prin trei metode: prin intermediul unei aplicații complexe ce va rula pe un notebook, prin afișarea informațiilor pe ecranul LCD încorporat în sistem sau cu ajutorul unei aplicații dedicate smartphone-urilor sau tabletelor corelată cu sistemul de diagnoză prin intermediul unei comunicații bluetooth.

1.2. Avantajele sistemului

Principalul atu al OnRoad Diagnostic este mobilitatea, materializată printr-o structură compactă, independentă energetic și două moduri de interschimbare a informațiilor cu un sistem de calcul extern.

Un alt beneficiu al utilizării acestui dispozitiv este și adaptarea la nevoile tuturor tipurilor de utilizatori, atât amatorilor cât și persoanelor avizate în domeniu, prin posibilitatea alegerii din meniul dispozitivului a opțiunii „Informații de bază” respectiv a opțiunii „Informații avansate”.

Interfațarea cu sistemul de calcul se realizează prin două metode diferite: prin comunicație bluetooth sau prin intermediul interfeței seriale RS-232.

OnRoad Diagnostic nu necesită supraveghere permanentă, utilizatorul fiind avertizat printr-un semnal sonor de înaltă frecvență la apariția eventualelor defecțiuni ce pot avea loc într-unul din compartimentele funcționale ale autovehiculului.

Controlul asupra dispozitivului se realizează cu ajutorul modulului de control poziționat ergonomic în partea frontală a aparatului.

Datorită încorporării în sistem a microcontroller-ului specializat ELM327, care realizează protocolul OBD-II necesar comunicării cu autovehiculului, OnRoad Diagnostic poate fi asociat cu aplicații software utilizate pe scară largă precum: Scanmaster ELM, ScanTool sau MoDiag.

1.3. Prezentare generală

Sistemul OnRoad Diagnostic este un dispozitiv electronic, mobil, ce încorporează standardele propuse de protocolul OBD-II, capabil să realizeze diagnoza unui autoturism și teste simple de performanță prin comunicarea cu unitatea electronică de control a acestuia denumită și Engine Control Unit (ECU).

OnRoad Diagnostic este compatibil cu toate automobilele (turisme și autocamioane) produse începând cu anul 1996 până în prezent ce au implementate standardele OBD-II, ISO 9141-2 specific producătorilor europeni și SAE J1939 folosit preponderent de către producătorii asiatici. Acesta este capabil să detecteze automat tipul de standard folosit de producătorul autoturismului fără a necesita intervenția unui factor uman avizat.

Interconectarea dispozitivului cu autoturismului se realizează prin intermediul conectorului cu 16 pini, definit de standardul SAE J1962, amplasat în habitaclu, sub coloana de direcție a autovehiculului.

Procedura de citire a datelor de la autoturism este inițiată odată cu pornirea motorului și se va continua până la întreruperea alimentării (deconectarea dispozitivului de la portul OBD-II al automobilului).

Folosind o serie de identificatoare numite Parameter IDs (PID), OnRoad Diagnostic poate să citească informațiile furnizate de ECU, să detecteze și ulterior reparației să șteargă orice eroare semnalată de către unitatea de control a autoturismului și să informeze utilizatorul despre cauza acesteia.

Energia electrică necesară este furnizată de către acumulatorul de 12V al autovehiculului (24V pentru autocamioane și vehicule utilitare), dispozitivul integrând două surse de alimentare ce stabilizează tensiunea la valorile de 5V respectiv 3.3V eliminând astfel necesitatea existenței unei surse externe (USB sau baterie).

Din punct de vedere software, dispozitivul OnRoad Diagnostic este compatibil cu toate sistemele de calcul ce folosesc sistemele de operare Windows sau Linux respectiv cu orice terminal mobil (smartphone sau tableta) cu sistem de operare Android (începând cu versiunea 4.2).

1.3.1. Moduri de funcționare

Sistemul OnRoad Diagnostic oferă utilizatorului patru moduri de funcționare: modul „CALCULATOR”, modul „MOBIL”, modul „DISPOZITIV” și respectiv modul „AUTO”, ce pot fi selectate din meniul principal au MoDiag.

1.3. Prezentare generală

Sistemul OnRoad Diagnostic este un dispozitiv electronic, mobil, ce încorporează standardele propuse de protocolul OBD-II, capabil să realizeze diagnoza unui autoturism și teste simple de performanță prin comunicarea cu unitatea electronică de control a acestuia denumită și Engine Control Unit (ECU).

OnRoad Diagnostic este compatibil cu toate automobilele (turisme și autocamioane) produse începând cu anul 1996 până în prezent ce au implementate standardele OBD-II, ISO 9141-2 specific producătorilor europeni și SAE J1939 folosit preponderent de către producătorii asiatici. Acesta este capabil să detecteze automat tipul de standard folosit de producătorul autoturismului fără a necesita intervenția unui factor uman avizat.

Interconectarea dispozitivului cu autoturismului se realizează prin intermediul conectorului cu 16 pini, definit de standardul SAE J1962, amplasat în habitaclu, sub coloana de direcție a autovehiculului.

Procedura de citire a datelor de la autoturism este inițiată odată cu pornirea motorului și se va continua până la întreruperea alimentării (deconectarea dispozitivului de la portul OBD-II al automobilului).

Folosind o serie de identificatoare numite Parameter IDs (PID), OnRoad Diagnostic poate să citească informațiile furnizate de ECU, să detecteze și ulterior reparației să șteargă orice eroare semnalată de către unitatea de control a autoturismului și să informeze utilizatorul despre cauza acesteia.

Energia electrică necesară este furnizată de către acumulatorul de 12V al autovehiculului (24V pentru autocamioane și vehicule utilitare), dispozitivul integrând două surse de alimentare ce stabilizează tensiunea la valorile de 5V respectiv 3.3V eliminând astfel necesitatea existenței unei surse externe (USB sau baterie).

Din punct de vedere software, dispozitivul OnRoad Diagnostic este compatibil cu toate sistemele de calcul ce folosesc sistemele de operare Windows sau Linux respectiv cu orice terminal mobil (smartphone sau tableta) cu sistem de operare Android (începând cu versiunea 4.2).

1.3.1. Moduri de funcționare

Sistemul OnRoad Diagnostic oferă utilizatorului patru moduri de funcționare: modul „CALCULATOR”, modul „MOBIL”, modul „DISPOZITIV” și respectiv modul „AUTO”, ce pot fi selectate din meniul principal afișat pe ecranul LCD al aparatului odată cu pornirea acestuia și care permit realizarea a diferite operații de diagnosticare și monitorizare pe baza datelor provenite de la autoturism.

Fiecare dintre aceste patru moduri se adresează unui anumit tip de utilizator și oferă informații variate specifice modului de analiză selectat.

Modul CALCULATOR

Acest mod de funcționare presupune interconectarea dispozitivului cu sistemul de calcul prin intermediul unei comunicații bluetooth sau cu ajutorul interfeței seriale RS-232.

Datele provenite de la autoturism vor fi analizate și prelucrate de către o aplicație software ce va rula pe o mașina de calcul (notebook) compatibilă cu sistemele de operare Windows și Linux.

Acest mod de funcționare furnizează o analiză complexă și completă a autovehiculului oferind utilizatorului accesul la o gama largă de senzori și module precum:

Sonda lambda,

Contact pedală de frână,

Senzor de temperatură al motorului (ECT),

Senzor presiune aer admisie (MAP),

Raportul aer-combustibil,

Sistemul de recirculare a vaporilor de benzină (EVAP),

Eficiența catalizatorului,

Sistemul de corecție al injecției de combustibil,

Sistemul de recirculare a gazelor din evacuare (EGR),

Nivelul de corecție pentru fiecare dintre injectoare,

Senzor de uzură al sistemului de frânare,

Senzor poziție vibrochen (CMP),

Senzor poziție arbore cu came (CKP),

Senzor temperatură aer admisie (IAT),

Senzor de detonație,

Senzor de temperatură din galeria de admisie,

Senzor masă aer admisie (MAF),

Senzor presiune atmosferică (BARO),

Senzor de temperatură al turbosuflantei,

Modulul de control,

Modulul de confort,

Sistemul de aer condiționat (AC),

Presiunea din sistemul de injecție,

Viteza de deplasare,

Detecția rateurilor de combustie,

Termostatul circuitului de răcire,

Supapa de control a turației de ralanti (ISC),

Sistemul de recirculare al gazelor pe carter (PCV)

Numărul de rotații pe minut executate de motor.

Selectarea opțiunii „CALCULATOR” va determina afișarea pe ecranul LCD încorporat în dispozitiv a mesajului „Mod CALCULATOR ACTIV!”.

Acest mesaj este menit să informeze utilizatorul despre modul curent de funcționare și va persista până la părăsirea acestuia.

Ieșirea din acest mod de funcționare se va realiza prin apăsarea tastei „IEȘIRE” amplasată în partea frontală a dispozitivului.

Modul DISPOZITIV

Acest mod de funcționare este cel care îi conferă dispozitivului caracterul mobil, el devenind autonom eliminând necesitatea unui sistem de calcul adiacent pentru procesarea și afișarea informației.

Alegerea acestui mod de funcționare va determina afișarea pe ecranul LCD a unui meniu care oferă utilizatorului posibilitatea de a alege între patru opțiuni: „Informații de bază”, „Informații avansate”, „Economic” și „Sport”, fiecare dintre ele având o funcție și adresabilitate diferită.

Prima dintre cele patru opțiuni disponibile oferă informații despre temperatura ambientală, viteză de deplasare, tipul de combustibil, raportul combustibilului, presiunea atmosferică, timpul scurs de la pornirea motorului și numărul de kilometri parcurși de la aprinderea martorului „MIL” (Malfunction indicator lamp).

Această opțiune este dedicată îndeosebi utilizatorilor obișnuiți, neavizați, care doresc acces la informațiile generale despre funcționarea propriului autovehicul și care nu dispun de afișoare sau indicatoare dedicate acestei funcții.

Opțiunea „Informații avansate” are o altă adresabilitate față de cea „Informații de bază”. Aceasta vine în sprijinul utilizatorilor avizați (mecanici auto, ingineri sau tehnicieni), care necesită informații specifice precum: presiunea combustibilului din rampa de injecție, presiunea aerului din admisie, temperatura lichidului de răcire, tensiunea acumulatorului în sarcină și la ralanti, temperatura uleiului, raportul oxigen/combustibil determinat în galeria de evacuare, eroarea EGR (exhaust gas recirculation), temperatura catalizatorului, presiunea combustibilului și tensiunea de alimentare a modulului de control.

Opțiunea „Economic” este destinată șoferilor începători dar și șoferilor cu experiență ce doresc să își însușească un stil de condus economic și benefic autoturismului. Această opțiune oferă utilizatorului recomandări ale treptei de viteză optime în funcție de viteza de deplasare, numărul de rotații pe minut executate de motor și de numărul de rapoarte de transmisie ale cutiei de viteze. Aceste recomandări sunt optimizate pentru un consum redus și o exploatare corespunzătoare a motorului și a sistemului de admisie.

Opțiunea „Sport” pune la dispoziție informații în timp real legate de performanțele atinse de autoturism și este adresată persoanelor avizate care doresc informații detaliate despre performanțele autovehiculului în timp real.

Utilizatorul are acces la parametri precum: cuplul dezvoltat de motor în orice moment al exploatării, viteza de deplasare a autovehiculului, numărul de rotații pe minut al motorului, volumul de aer din admisie MAF (mass air flow sensor), nivelul de sarcină al autovehiculului și poziția clapetei de accelerație.

Revenirea la meniul principal se face prin apăsarea tastei „IEȘIRE” ce se află pe panoul de control.

Modul AUTO

În modul de funcționare „AUTO” sistemul monitorizează eventualele coduri de eroare numite și Diagnostic Trouble Code (DTC) pe care ECU le poate genera dacă apare o defecțiune. În cazul detectării unui astfel de cod de eroare, pe ecranul LCD al dispozitivului va fi afișat mesajul „Probleme detectate!” urmat de codurile alfanumerice de identificare ale acestora concomitent cu generarea unui semnal acustic de frecvență înaltă care are rolul să atragă atenția utilizatorul cu privire la problema apărută. Procedura de detectare a erorilor este încheiată cu eliminarea acestora din memoria ECU după care procesul poate fi reluat pentru a se verifica succesul operației precedente.

În cazul în care dispozitivul nu interceptează niciun cod de eroare, sistemul va afișa la finalul operației mesajul „Nicio problemă detectată” pentru a marca funcționarea corectă a autovehiculului. Reluarea procesului de căutare al erorilor se face prin apăsarea tastei „OK” amplasată pe panoul de control.

Pentru a spori siguranța șoferilor, modul „AUTO” poate fi utilizat și în timpul deplasării, oferind o monitorizare completă, în timp real, fără a necesita reducerea atenției alocate traficului.

Părăsirea modului „AUTO” se face cu ajutorul tastei „IEȘIRE” care va determina revenirea la meniul de start.

Modul MOBIL

În acest mod de funcționare dispozitivul OnRoad Diagnostic interoperează cu un smartphone sau tabletă, ce utilizează sistemul de operare Android, prin intermediul comunicației bluetooth și al aplicației dedicate terminalelor mobile.

Sistemul execută un proces de scanare continuă la un interval definit de 2 secunde, a autovehiculului pentru detectarea oricărei erori ce poate apărea în timpul exploatării, iar rezultatul scanării va fi trimis către terminalul mobil asociat dispozitivului.

În cazul în care este interceptat un cod de eroare, acesta va fi afișat pe ecran sub forma unor secvențe alfanumerice, iar în caz contrar, funcționarea corectă a vehiculului va fi marcată de afișarea codului „00”.

Alegerea acestui mod de funcționare va fi semnalată prin afișarea pe ecranul dispozitivului a mesajului „Mod MOBIL ACTIV”, mesaj ce va persista pe toată durata funcționarii dispozitivului în modul curent.

Alegerea unui alt mod de funcționare se va putea face din meniul principal, accesibil prin intermediul butonului „IEȘIRE”.

1.3.2. Design exterior

În partea frontală a aparatului se află amplasat un ecran LCD cu o matrice de afișare de 16 linii și 4 coloane (16×4) ce permite utilizatorului o vizualizare a meniului principal dar și a

parametrilor de funcționare sau codurilor erorilor apărute.

Pentru a facilita interacțiunea dintre dispozitiv și utilizator, pe consola centrală se află modulul de control alcătuit din patru butoane specifice a patru funcții: navigare stânga, navigare dreapta, „OK” și „IEȘIRE” ce îi permit utilizatorului parcurgerea facilă a meniului intuitiv al aparatului.

Figura 1.1. Imagine frontală a aparatului OnRoad Diagnostic

În partea superioară a aparatului se află cinci led-uri ce au rolul de martori ai funcționării corecte a acestuia. Led-ul de culoare roșie semnifică alimentarea corespunzătoare a dispozitivului. Celelalte patru led-uri, de culoare verde, semnalizează comunicarea atât între sistemul OnRoad Diagnostic și unitatea electronică de control a autovehiculului dar și între dispozitiv și sistemul de calcul asociat.

Figura 1.2. Imagine de sus a aparatului OnRoad Diagnostic

În partea posterioară a dispozitivului OnRoad Diagnostic se află localizat conectorul specific interfeței RS-232 (conectorul DB9-F) prin care se realizează conexiunea cu sistemul de calcul.

Figura 1.3. Imagine posterioară a aparatului OnRoad Diagnostic

Interconectarea cu autoturismul se realizează prin intermediul conectorului OBD-II amplasat în habitaclu, la o distanță definită de standard de maximum 0.61 metri față de coloana de direcție a acestuia.

Lungimea cablului este de 30 cm, ceea ce permite amplasarea într-un loc confortabil și ușor de accesat de către șofer chiar și în timpul mersului fără a necesita reducerea atenției de la carosabil.

1.4. Aplicația dedicată terminalelor mobile

Aplicația OnRoad Diagnostic destinată terminalelor mobile lucrează în strânsă corelație cu dispozitivul omonim cu scopul a accentua caracterul mobil al acestuia.

Pentru o funcționare corectă este necesar ca dispozitivul să fie setat în modul „MOBIL” și să existe o conexiune bluetooth între smartphone sau tabletă și sistemul de diagnoză.

Această aplicație este compatibilă cu toate dispozitivele mobile ce au instalat sistemul de operare Android versiunea 4.2.2 sau o versiune ulterioară.

Aplicația introduce o interfață grafică simplă și intuitivă care constă în patru opțiuni: „Start diagnoză”, „Lista codurilor de eroare”, „Despre” și „Ieșire”.

Prin apăsarea butonului „Start diagnoză” se va începe procedura de căutare a dispozitivului OnRoad Diagnostic. După selectarea din lista ce va apărea pe ecranul terminalului mobil a dispozitivului, aplicația va stabili legătura cu sistemul de diagnoză. După stabilirea acestei legături, sistemul poate începe procedura de detectare a erorilor iar rezultatul va fi trimis către sistemul de calcul mobil unde va fi afișat sub forma unor coduri alfanumerice ce conțin informații despre compartimentul în care a fost semnalată problema, tipul de eroare și codul de identificare al acesteia. În cazul în care nu este identificată nicio problemă, pe ecranul terminalului mobil va apărea mesajul „00” .

Figura 1.4. Meniul principal al aplicației

Posibilele probleme semnalate de ECU pot fi decodate cu ajutorul unei liste ce cuprinde cele mai des întâlnite coduri de eroare implementată în aplicație. Aceasta este accesibilă prin apăsarea butonului „Lista codurilor de eroare” din meniul principal al aplicației.

Figura 1.5. Lista codurilor de eroare

Opțiunea „Despre” oferă o descriere succintă a aplicației, informații despre versiunea curentă și modificările față de versiunea precedentă.

Butonul „Ieșire” închide aplicația pentru a reduce consumul de baterie și resurse al terminalului mobil.

Figura 1.6. Interfața grafică „Despre”

CAPITOLUL 2. PROTOCOLUL ODB-II

2.1. OBD-II informații generale

OBD sau On Board Diagnostic reprezintă capacitatea unui automobil de a executa un set de proceduri și algoritmi ce au scopul de a diagnostica și monitoriza sistemele integrate într-un automobil și de a raporta eventualele nereguli apărute.

În anul 1988 SAE (Society of Automotive Engineers) a încurajat producătorii de automobile să implementeze sisteme capabile să detecteze nereguli ale componentelor care au impact asupra emisiilor de CO2. Această primă generație a sistemului de autodiagnoză poartă numele de OBD-I și permitea monitorizarea unei serii restrânse de parametri. Identificarea unei erori avea ca și consecință aprinderea unui indicator luminos plasat în bordul mașinii denumit și MIL (Malfunction Indicator Lamp) sau „Check Engine”, fără a oferi însă prea multe informații despre problema care a generat aprinderea indicatorului [1].

Neimpunând și o standardizare a protocolului de comunicație și a interfațării cu sistemul de diagnoză, OBD-I nu a avut efectul scontat [15].

Neregulile primei generații de sisteme de diagnoză la bord au fost remediate în anul 1994 când CARB (California Air Resources Board) a impus un nou set de reglementări ce vor fi cunoscute ca și OBD-II, acestea urmând a fi impuse producătorilor americani începând cu anul 1996 urmând ca Uniunea Europeană să introducă un set similar de reglementări, denumite EOBD, în anul 2001 pentru automobilele cu motorizare benzină și în 2004 pentru automobilele echipate cu motoare diesel.

Apariția OBD-II a însemnat o standardizare atât la nivel hardware cât și la nivel software.

A fost impus un anumit tip de conector, universal, un protocol unic de comunicație și o structură standard a mesajelor schimbate între automobil și sistemul de diagnosticare.

Cantitatea de informație oferită de ODB-II este semnificativ mai mare datorită extinderii listei de parametri monitorizați (DTC- Diagnostic Trouble Codes).

Figura 2.1. Conectorul ODB-II amplasat în automobile

Sursa: www.doetone.com

Următoarea generație de diagnoză la bord, denumită și OBD-III se află în curs de standardizare la Comitetul de Inspecție și Mentenanță pentru automobile al statului California (IMRC) și promite implementarea unui sistem de transmisie radio a datelor preluate de la modulele și senzorii autoturismului împreună cu numărul de identificare denumit VIN (Vehicle Identification Number) către autoritatea locală competentă (în România, RAR- Registrul Auto Român) prin care se dorește detectarea timpurie a problemelor de natură mecanică sau electrică a automobilelor monitorizate reducând astfel numărul de accidente cauzate de defecțiuni tehnice, reducerea poluării prin identificarea autovehiculelor care nu corespund normelor, limitarea posibilităților de alterare sau modificare a parametrilor de funcționare a autovehiculului și sancționarea nerespectării perioadelor de inspecție tehnică periodică.

Transmisia de date în OBD-III se va putea realiza prin intermediul infrastructurii telecomunicațiilor mobile, prin amplasarea unor echipamente speciale de-a lungul principalelor rute sau cu ajutorul comunicației prin satelit.

Protocolul OBD-III definește în plus fată de generațiile anterioare ale diagnozei la bord un număr de trei noi tehnologii:

Data Communications Network,

Remote OBD Link,

Data Management System.

2.2. Standardele OBD-II

2.2.1. Standardul ISO 9141-2

ISO 9141-2 reprezintă un subset de reguli ale standardului ISO 9141 și definește cerințele necesare realizării unei legături electrice între autoturism și sistemul de testare și monitorizare.

ISO 9141-2 este un standard similar RS-232, folosit îndeosebi de către producătorii europeni și asiatici și este adresat exclusiv sistemelor de control ce folosesc o sursă de alimentare de 12V, cu alte cuvinte este un standard definit special pentru autoturisme. Acesta folosește o magistrală serială asincronă cu o rată de transfer de 10.4Kb/s pentru transmisia de date și o rată de transfer de 5b/s pentru inițializarea legăturii între sisteme. Din punct de vedere fizic, comunicația propriu-zisă este realizată cu ajutorul a două linii de legătură, linia L respectiv linia K, fără a fi nevoie de semnale de handshake [3].

Linia K este o linie bidirecțională și este folosită pentru a inițializa comunicația serială între dispozitiv și unitatea electronică de control, iar linia L este o linie unidirecțională prin intermediul căreia se realizează schimbul de informații între cele două sisteme.

Standardul ISO 9141-2 folosește pinul 7 al conectorului OBD-II pentru linia K și pinul 15 pentru linia L [5].

Figura 2.2. Configurația pinilor pentru standardul ISO 9141-2

Asupra datelor de pe linia L se aplică o codare NRZ (Non Return to Zero) ce are ca scop imunizarea transmisiei la perturbațiile cauzate de mediu sau de circuitele electronice.

Spre deosebire de alte standarde ale protocolului OBD-II, ISO 9141-2 nu definește nicio metodă de arbitrare.

bidirecțională

linia K

unidirecțională

linia L

Figura 2.3. Comunicația în cadrul standardului ISO 9141-2

Deoarece standardul ISO 9141-2 este adresat exclusiv autoturismelor, nivelele logice sunt raportate la tensiunea de 12V asigurată de acumulator.

Figura 2.4.1. Nivelele logice pentru transmisie ale legăturii K[5]

Figura 2.4.2. Nivelele logice pentru recepție ale legăturii K[5]

2.2.2. Standardul SAE J1939

Standardul SAE J1939 a fost dezvoltat de firma Bosch și este folosit de către mai mulți producători, pentru autoturisme, dar și pentru vehicule utilitare și autocamioane echipate cu motoare diesel. Acesta împrumută nivelul fizic al protocolului CAN2.0B ce permite rate de transfer între 250 KB/s și 500 KB/s și a fost impus tuturor automobilelor sau vehiculelor utilitare produse sau importate în SUA.

Moștenirea CAN2.0B reiese și din faptul că standardul SAE J1939 definește o metodă de arbitrare la nivel de mesaj, iar transmisia de date se realizează diferențial prin intermediul a două linii de legătură: CAN-Low respectiv CAN-High.

Linia CAN-Low este asociată pin-ului 6 iar linia CAN-High este asociată pin-ului 14.

Figura 2.5. Configurația pinilor pentru standardul SAE J1939

Structura mesajului standardului SAE J1939 este formată dintr-un identificator alcătuit din 29 de biți și un corp al mesajului format din 8 byte (64 de biți) în care se află stocată informația returnată de ECU [5].

Figura 2.6. Structura mesajului pentru standardul SAE J1939

Identificatorul conține câmpul Parameter Group Number (PGN) definit de protocolul de nivel aplicație SAE J1939/71 și care este folosit pentru a face o diferență între tipurile de mesaje trimise. Sunt definite două astfel de tipuri de mesaje:

Global PGN, mesaje trimise către toate dispozitivele ce partajează magistrala CAN la un moment dat,

Specific PGN, mesaje trimise către un anumit dispozitiv.

Cei 8 byte care intră în componența corpului mesajului se numesc Parameter Group (PG) și conțin răspunsul mai multor PID-uri asociate aceluiași tip de parametru.

Standardul SAE J1939 impune două tipuri de PG care folosesc protocoale de transport specifice fiecărei grupe de parametri:

PG.CM, este o grupă de parametri folosită pentru managementul conexiunii (protocol de transport TP.CM),

PG.DT, este o grupă de parametri folosită pentru transmisia de date (protocol de transport TP.DT) [5].

Figura 2.7. Legatura fizică – nivele de semnal

Figura 2.8. Legatura de date – nivele de semnal

Standardul J1939 respectă modelul OSI și definește șapte protocoale specifice celor șapte nivele ale acestui tip de arhitectură.

J1939/71&73

J1939/6x

J1939/5x

J1939/4x

J1939/31

J1939/21

J1939/11

magistrala CAN

Figura 2.9. Modelul OSI al standardului SAE-J1939

2.2.3. Alte standarde

SAE J1850 VPW

Este un standard folosit preponderent de către producătorul american de automobile General Motors, ce permite o rată de transfer între 10.4kb/s și 41.6Kb/s.

SAE J850 VPW definește o metodă de arbitrare multi-master CSMA/NDA (Carrier Sense Multiple Access with Non-Destructive Arbitration).

Nivele de tensiune specifice sunt cuprinse între +7V pentru starea logică “high” și 0V pentru starea logică “low” cu un punct de decizie la +3.5V.

Lungimea mesajului este limitată la 12 byte în care este inclus și câmpul specific sumei de control CRC.

SAE J1850PWM

Este folosit îndeosebi de către concernul Ford și permite o rată de transfer de 41.6Kb/s .

Nivelele de tensiune sunt : +5V pentru starea logică “high” și 0V pentru starea logică “low”.

Arbitrarea se realizează, la nivel de mesaj, asemenea standardului SAE J1850 VPW prin CSMA/NDA.

ISO 14230 KWP2000 (Keyword Protocol 2000)

Este un standard bazat pe ISO 9141-2 de la care împrumută în întregime nivelul fizic al acestuia, necesitând astfel cele două linii de comunicare: L pentru transmisia de informații și K pentru stabilirea comunicării. Rata de transfer este cuprinsă între 1.2KB/s și 10.4KB/s.

Lungimea mesajului definită de standardul ISO 14230 KWP2000 este de 255 byte în care este cuprinsă și suma de control asociată mesajului.

SAE J2411

Standardul J2411 este implementat în noile autoturisme ale concernului American General Motors. Scopul acestui standard este acela de a fi folosit în aplicațiile în care nu este necesară o viteză de transmisie mare. Astfel, s-a recurs la utilizarea unui singur canal fizic de comunicație (un singur fir), obținându-se viteze de transfer nominale de 33Kb/s sau 83Kb/s în modul de diagnoză.

ISO 15765

Dezvoltat de către firma germană Bosch ca un înlocuitor al protocolului CAN, acest standard a fost aplicat nu numai în industria automobilelor ci și în aeronautică, în industria maritimă sau în echipamente medicale.

Deși folosește același tip de conector, pinout-ul diferă, excepție făcând pinul 5 (GND) și pinul 16 (Vbat) [16].

2.3. OBD-II pinout

Conectorul OBD-II este universal pentru toate tipurile de automobile. Acesta este alcătuit din 16 pini amplasați pe 2 rânduri.

Standardul SAE J1962 impune amplasarea acestuia în habitaclu, la o distanță maximă de 0.61m de coloana de direcție pentru a putea fi accesat ușor din poziția șoferului .

Figura 2.10. Structura conectorului OBD-II amplasat în automobil

Sursa: e-automobile.ro

Tabel 2.1. Configurația pinilor pentru standardele folosite[10]

*pinii ai căror funcție nu este specificată de către standardul SAE pot fi folosiți de producători fără a avea vreo constrângere.

2.4. Moduri de funcționare

Comunicația între autoturism și sistemul de diagnoză se realizează prin utilizarea mai multor moduri de funcționare. Fiecare dintre aceste servicii corespunde unui anumit tip de analiză si nu este necesar ca un constructor să le implementeze pe toate în automobilele pe care pe produce [14].

Protocolul OBD-II definește un număr de 10 astfel de moduri de funcționare care oferă diferite servicii de diagnoză și monitorizare pe care le voi descrie succint în tabelul 2.2.

Tabel 2.2. Modurile de funcționare

2.5. DTC-urile protocolului OBD-II

Protocolul OBD-II definește o listă cu aproximativ 17.000 de coduri de eroare numite DTC sau Diagnostic Trouble Codes generate de unitatea electronică de control, ECU, atunci când se sesizează o funcționare necorespunzătoare a unui ansamblu. Fiecare dintre aceste erori este însoțită de o descriere a defectului și locația componentei vizate.

Codurile de eroare sunt definite de protocolul OBD-II ca o secvență alfanumerică ce conține informații despre compartimentul în care s-a produs defectul și tipul acestuia urmată de un cod de identificare al erorii format din trei cifre [9].

Figura 2.11. Structura unui DTC

2.6. PID-urile protocolului OBD-II

Interogarea nominală a parametrilor de interes este realizată prin intermediul unor identificatori numiți Parameter ID’s (sau PID). Aceste PID-uri sunt valori hexazecimale care identifică în mod unic diferiți senzori ai autoturismului. În funcție de PID-ul ales unitatea de control va returna un număr variabil de octeți care vor conține informația cerută transformată într-o formă ușor de interpretat cu ajutorul formulelor de determinare predefinite.

Protocolul OBD-II definește cele zece moduri de funcționare prezentate anterior. Fiecare din aceste moduri de funcționare implementează o listă de PID-uri specifică. Voi menționa în tabelul 2.3 lista celor mai importante identificatoare folosite uzual [8].

Tabel 2.3. PID-urile semnificative

CAPITOLUL 3.

ARHITECTURA HARDWARE A SISTEMULUI

3.1. Interpretorul ODB-II (microcontroller ELM327)

ELM327 este un microcontroller specializat produs de către firma canadiană ELM Electronics cu scopul de a realiza legătura între un sistem de calcul și unitatea de control a automobilelor, ECU.

Din punct de vedere structural, ELM327 este realizat pe baza unui nucleu de PIC 18F2480 al celor de la Microchip Technology și implementează toate protocoalele OBD-II uzuale:

SAE-J1850 VPW (10.4 kbaud),

SAE-J1850 PWM (41.6 kbaud),

ISO 9141-2 (5 baud init, 10.4 kbaud),

ISO 14230-4 KWP (5 baud init, 10.4 kbaud),

ISO 14230-4 KWP (fast init, 10.4 kbaud),

ISO 15765-4 CAN (11 bit ID, 500 kbaud),

ISO 15765-4 CAN (29 bit ID, 500 kbaud),

ISO 15765-4 CAN (11 bit ID, 250 kbaud),

ISO 15765-4 CAN (29 bit ID, 250 kbaud).

3.1.1. Caracteristicile structurale și funcționale ale ELM327

Microcontroller-ul ELM327 oferă:

Convertoare analog-digitale de 10 și 11 biți,

Încorporează interfețele UART, SPI și I2,

Oferă suport pentru protocolul CAN 2.0B,

Generatoare PWM,

Rata de transfer a mesajelor de până la 1Mbps,

Două buffer-e de recepție dedicate,

Trei buffer-e pentru transmisie cu priorități diferite,

Metode avansate de control al erorilor.

3.1.2. Schema bloc a microcontroller-ului

Figura 3.1. Schema bloc ELM327

Sursa: foaia de catalog a microcontroller-ului ELM327, pag 1/82

3.2. Controlul afișajului și al alarmei (microcontroller ATMega32)

3.2.1. Caracteristicile structurale și funcționale ale ATMega32

Elementul central al modulului de afișare și semnalizare al defecțiunilor este microcontroller-ul ATMega32. Acesta este un microcontroller pe 8 biți ce încorporează o memorie EEPROM de 1024Bytes pentru firmware-ul sistemului.

Din punct de vedere structural, sistemul embedded al celor de la Atmel furnizează următoarele funcționalități:

Circuite Timer/Counter de 8biți sau 16 biți,

Generatoare PWM,

2 KB memorie SRAM,

32KB memorie de program flash,

Capabilitate de programare ICSP (In-circuit Serial Programming),

Convertoare analog –digitale de 8 sau 10 biți,

Interfață UART și I2C(TWI),

Putere de procesare de până la 16 MIPS pentru un tact extern de 16MHz,

Tensiunea nominală de operare a microcontroller-ului este încadrată în intervalul

4.5 – 5.5V.

3.2.2. UART (Universal Asynchronous Receiver and Transmitter)

UART-ul este o componentă a comunicației seriale în care traficul de date de face bit cu bit. Deoarece transmisia și recepția sunt asincrone este necesar ca cele două dispozitive care comunică să cunoască parametri de timp și structura cuvintelor. Fiecărui cuvânt i se adaugă un bit de start pentru sincronizarea receptorului.

Caracteristici principale ale comunicației UART:

Comunicație full-duplex cu registre separate pentru transmisie și recepție,

Posibilitatea de alegere între o comunicație asincronă și o comunicație sincronă,

Dimensiuni variabile pentru cadrele de date (5,6,7,8 sau 9 biți și 1 sau 2 biți de stop),

Metode de detecție a erorilor ce apar în cadrele de date,

Filtre pentru limitarea zgomotului, filtre pentru eliminarea falsă a bitului de start, filtre trece jos,

Dublarea vitezei de comunicare în mod asincron prin înjumătățirea divizorului de ceas (U2X=1).

3.3. Interfața RS-232

Standardul RS-232 definește o comunicație serială între două dispozitive electronice: un modem (DCE – data circuit terminating equipment) și un echipament terminal (DTE – data terminal equipment ) din punct de vedere al [13]:

Structurii mecanice a interfeței,

Constrângerilor de timp,

Caracteristicilor electrice ale semnalelor,

Tipurilor de semnale de protocol și funcțiile acestora.

Din punct de vedere mecanic, standardul RS-232 propune un conector DB9 cu un număr de 9 pini.

Tabel 3.1. Configurația pinilor pentru conectorul DB9

Figura 3.2. Structura unui conector DB9-M

Sursa: (foto preluat de pe http://www.db9-pinout.com)

Lungimea maximă a mediului de transmisie este condiționată de baud rate după cum reiese din tabelul 3.2:

Tabel 3.2. Influența baud rate-ului asupra distanței de transmisie

Figura 3.3. Nivelul de semnal – RS-232

Interfața RS-232 inițiază o comunicație cu tact standard, ceea ce are ca avantaj creșterea distanței de transmisie, însă cu limitarea debitului de informație.

3.4. Comunicația Bluetooth

Bluetooth este o comunicație wireless similară WLAN, de interschimbare de date pe distanță scurtă între două dispozitive care implementează capabilitățile acestei tehnologii, de regulă telefoane mobile sau tablete.

Această tehnologie operează în banda de frecvențe 2.4Ghz – 2.485Ghz (banda UHF).

În cadrul comunicației Bluetooth se folosește o metodă de transmisie radio FHSS cu salt în frecvență și spectru împrăștiat (Frequency hopping spread spectrum). Astfel, datele sunt structurate în pachete ce vor fi trimise pe unul din cele 79 de canale definite. Fiecare dintre aceste canale are o bandă de trecere de 1MHz [13].

Primele versiuni ale tehnologiei implementau modulația GFSK (Gaussian frequency-shift keying) urmând ca la apariția pe piață a versiunii Bluetooth 2.0 aceasta să fie înlocuită cu o modulație 8-DPSK.

Tabel 3.3. Rata de transfer maximă pentru comunicația bluetooth

Comunicația bluetooth este bazată pe un protocol de pachete cu o structură master-slave, unde un master poate să inițieze un transfer către unul sau mai multe dispozitive slave (un număr de maximum 7 astfel de dispozitive). Acest tip de comunicație este una sincronă, iar dispozitivele care iau parte în interschimbarea de date vor avea același semnal de ceas cu cel al dispozitivului care a inițiat transferul (dispozitivul master).

3.5. Prezentarea mediului de dezvoltare

În vederea proiectării și realizării practice a dispozitivului OnRoad Diagnostic am folosit o serie de soluții software precum Atmel Studio 6.1 pentru realizarea firmware-ului, Design Spark 5.1 pentru proiectarea cablajului imprimat și al schemei electrice respectiv mediul de dezvoltare Eclipse pentru realizarea aplicației dedicate sistemului de operare Android.

3.5.1. Atmel Studio 6.1

Atmel Studio 6.1 este o platformă integrată de dezvoltare și depanare pentru microcontroller-e Atmel AVR și Atmel ARM. Oferă o soluție de dezvoltare simplă, gratuită și intuitivă pentru dezvoltarea de aplicații pentru sisteme embedded în limbaje de programare consacrate ca C, C++ și Assembly code.

Atmel Studio 6.1 oferă o librărie extinsă ce conține o colecție de peste 1600 de proiecte și exemple pentru microcontroller-e din clasa AVR și ARM.

Figura 3.4. Interfața grafică a mediului de dezvoltare (IDE) Atmel Studio

3.5.2. Design Spark PCB

Proiectarea hardware a dispozitivului s-a realizat cu ajutorul programului Design Spark. Design Spark este un software gratuit oferit de firma RS Components care pune la dispoziție uneltele necesare realizării schemei electrice și transpunerea acesteia într-un Printed Circuit Board (PCB).

Permite proiectarea unui număr maxim de 20 de layer-e și realizarea footprint-urilor pentru componentele ce nu fac parte din librăria oferită de producător.

Figura 3.5. Interfața grafică a programului Design Spark 5.1

Figura 3.6. Interfața grafică a editorului PCB din suita Design Spark 5.1

3.5.3. Eclipse

Aplicația dedicată sistemului de operare Android pentru conectarea cu dispozitivul OnRoad Diagnostic a fost realizată cu ajutorul software-ului Eclipse și a plugin-ului Android Development Tools (ADT).

Eclipse este un mediu de dezvoltare (IDE) ce permite realizarea aplicațiilor într-un număr mare de limbaje de programare precum: C, C++, JAVA, PHP, Phyton, etc.

Pluginul ADT extinde capabilitățile Eclipse IDE prin care se urmărește ușurarea procesului de dezvoltare al unei aplicații pentru sistemul de operare Android.

Figura 3.7. Interfața grafică a mediului de dezvoltare (IDE) Eclipse

CAPITOLUL 4.

PREZENTAREA DISPOZITIVULUI PROIECTAT

4.1. Schema bloc de principiu a sistemului

Figura 4.1. Schema de principiu a dispozitivului OnRoad Diagnostic

Unitatea electronică de control (ECU) este nucleul autovehiculului și asigură funcționarea corectă a grupului motor-propulsor prin citirea și interpretarea valorilor de la o multitudine de senzori și prin adaptarea în consecință a actuatoarelor (injectoare, supape pneumatice, electrovalve, etc.).

Dispozitivul OnRoad Diagnostic interacționează cu ECU prin intermediul celor două standarde ale protocolului OBD-II, SAE J1939 respectiv ISO 9141-2 și cere informații de la diferiți senzori precum senzorii de turație, de presiune a combustibilului, de nivel al combustibilului, sau de temperatură a lichidului de răcire. Informațiile primite sunt prelucrate și formatate într-un limbaj natural ușor de înțeles pentru utilizatori care apoi sunt afișate fie pe ecranul LCD încorporat în dispozitiv, fie sunt trimise către un sistem de calcul pentru o prelucrare și o expunere mai complexă.

4.1.1. Schema bloc a sistemului OnRoad Diagnostic

Figura 4.2. Schema bloc a dispozitivului OnRoad Diagnostic

Funcția de interconectare cu autoturismul este realizată de microcontroller-ul specializat ELM327 și de către circuitele de achiziție specifice standardelor SAE J1939 și ISO 9141-2. Datele preluate de ELM327 sunt trimise la modulul de control și afișaj prin intermediul UART, unde sunt analizate și prelucrate urmând să fie afișate sau trimise către o aplicație externă printr-o comunicație bluetooth sau cu ajutorul interfeței RS-232 în funcție de opțiunile utilizatorului. Nucleul modulului de control și afișaj este alcătuit dintr-un microcontroller ATMega32.

Interacțiunea între sistemul de diagnoză și utilizator este mediată de către un modul de control care permite comanda întregului sistem.

4.2. Structura dispozitivului

Dispozitivul este alcătuit din șase module diferite interconectate în cadrul aceluiași PCB și un modul de control amplasat în partea superioară a aparatului.

Principalele componente ale acestuia sunt cele două microcontroller-e ELM327 și ATMega32. Primul realizează protocolul OBD-II, iar cel de-al doilea este folosit pentru interfațarea cu factorul uman.

Cele două microcontroller-e comunică prin intermediul interfeței UART cu un baud rate 19200 b/s, iar datagramele sunt structurate în 8 biți de date fără paritate și un singur bit de stop.

Figura 4.3. Imagine virtuală a PCB-ului integrat

4.2.1. Modulul de alimentare

Modulul de alimentare este plasat în partea superioară a plăcii și realizează conversia de tensiune de la 12V (sau 24V în cazul vehiculelor utilitare) provenită de la acumulatorul autoturismului până la 5V tensiunea nominală a microcontroller-elor, respectiv 3.3V tensiunea necesară modulului bluetooth.

Stabilizarea de tensiune la 5V este realizată de circuitul integrat LM317 produs de Național Semiconductors.

Cele două rezistoare R1 și R2 au fost dimensionate conform relației:

(4.1)

*unde 1.25 reprezintă tensiunea de referință iar

(4.2)

(4.3)

Pentru o tensiune de ieșire mai apropiată de 5V (5.04V) am determinat experimental valorile optime ale rezistoarelor care să respecte întru totul relația (4.3):

Figura 4.4. Sursa de alimentare de 5V

Pentru stabilizarea de tensiune la 3.3V am ales soluția propusă de cei de la Texas Instruments, LM1117. Am recurs la această metodă deoarece modulul bluetooth ales nu este tolerant cu o tensiune de 5V.

Figura 4.5. Sursa de alimentare de 3.3V

Configurația aleasă este una specifică unui regulator de tensiune fix pentru o tensiune de ieșire de 3.3V, folosind numai două condensatoare electrolitice de capacitate 10uF care realizează corecția caracteristicii de ieșire.

4.2.2. Modulul de achiziție

Modulul de achiziție constă în două circuite electronice tipice diferite, specifice celor două standarde implementate în cadrul dispozitivului OnRoad Diagnostic: SAE J1939 respectiv ISO 9141-2.

SAE J1939:

MCP2551 este un transceiver CAN de mare viteză (rate de transfer până la 1 Mb/s) și cu o toleranță crescută la erori care permite interfațarea între protocolul CAN și magistrala fizică. Acesta realizează conversia semnalelor digitale generate de controller-ul CAN în semnale potrivite pentru transmisia printr-un mediu fizic.

Standardul ISO 11898 definește o impedanța de linie pentru comunicația CAN egală cu Z=120Ω. Astfel, am ales în consecință o terminație de rețea standard formată dintr-un rezistor (R21) cu o valoare de 120Ω. Totodată, terminația are și rolul de minimizare a reflexiilor apărute pe linie dar și de a proteja circuitele dezvoltate în tehnologie CMOS de starea de nedeterminare.

Figura 4.6. Circuitul de achiziție de date pentru standardul SAE J1939

ISO 9141-2:

Modulul ISO 9141-2 este un circuit tipic, alcătuit în totalitate din componente discrete. Standardul ISO 9141-2 presupune comunicația pe două linii: ISO-L pentru stabilirea comunicației și ISO-K pentru comunicația propriu-zisă.

Figura 4.7. Circuit tipic pentru achiziția de date pentru standardul ISO 9141-2

Atunci când unitatea de control a autoturismului răspunde cererii, semnalul primit va ajunge la pinul 12 (ISO_In) al microcontroller-ului ELM327 cu un nivel scăzut cauzat de trecerea prin divizorul de tensiune realizat cu ajutorul rezistoarelor R10 și R11.

Semnalul de intrare este precedat de un trigger Schmitt implementat în capsula circuitului integrat, care are scopul de a transforma semnalul analogic într-unul digital.

Divizorul de tensiune oferă un prag de creștere (raise) de 7V respectiv un prag de cădere (falling) de 3.5V triggerului Schmitt, fapt ce determină o creștere a imunității la perturbații.

4.2.3. Modulul de interpretare OBD-II (ELM327)

Modulul de interpretare are la bază microcontroller-ul specializat ELM327 care implementează protocolul OBD-II.

Acesta realizează comunicația cu unitatea de control a autovehiculului cu ajutorul modulelor de achiziție prezentate anterior.

Frecvența de ceas a dispozitivului este de 4Mhz, generată de un oscilator extern cu cuarț.

Din pricina faptului că microcontroller-ul ELM327 este realizat în tehnologie semiconductoare (CMOS), este necesară conectarea la un potențial pozitiv (Vdd) sau 0 (GND) a pinilor neutilizați.

Deoarece intrarea Vmeasure (pinul 2) este analogică și permite un nivel maximum de tensiune de 5V, am recurs la o divizare a potențialului de intrare prin intermediul divizorului rezistiv format din R12 și R13, pentru a reduce nivelul de tensiune la o valoare apropiată de 5V, în cazul alimentării modulului cu 24V și o tensiune de 2.5V în cazul în care alimentarea dispozitivului se face de la un acumulator de 12V.

Figura 4.8. Modulul de achiziție

Cele patru led-uri de culoare verde servesc drept martori ai comunicației între microcontroller-ul ELM327 și unitatea de control a autoturismului respectiv, dar și ai comunicației între sistemul de calcul și dispozitivul OnRoad Diagnostic.

4.2.4. Modulul de control și afișaj

Funcția de control a modulului este asigurată de către microcontroller-ul ATMega32. Acesta rulează firmware-ul răspunzător pentru transmisia de comenzi, recepționarea și

procesarea răspunsului generat de către microcontroller-ul ELM327.

Prin intermediul modulului de interfață cu utilizatorul, microcontroller-ul ATMega32 oferă utilizatorului controlul deplin al sistemului și al capabilităților acestuia.

Funcția de afișare este realizată de către un ecran LCD monocrom cu o matrice de 16 coloane și 4 linii (16×4), ce utilizează un controller grafic HD44780.

Deoarece portul C avea un număr suficient de pini liberi, am recurs la conectarea LCD-ului printr-o interfață de 8 biți. Astfel, liniile de date ale LCD-ului (DB0-DB9) au fost conectate în totalitate la portul C al microcontroller-ului ATMega32. Am ales experimental pentru rezistorul R5, o valoare de 4.7KΩ ce determină un contrast suficient al ecranului pentru a fi vizibil.

Sistemul de alarmă implementat în dispozitiv este responsabil de avertizarea șoferilor în legătură cu eventualele probleme detectate.

Figura 4.9. Modulul de control și afișaj

4.2.5. Modulul de comunicație RS-232

Conține un circuit integrat MAX3232CPE+ care are rolul de a realiza conversia din nivel TTL în nivel RS-232 către conectorul DB9-F (conector pentru interfațarea cu PC-ul). Asigură una din metodele de interconectare cu sistemul de calcul.

Figura 4.10. Modulul de comunicație RS-232

Max3232CPE+ este un circuit integrat ce realizează conversia semnalelor primite de la un port serial într-o formă specifică circuitelor digitale Transistor–transistor logic (TTL). Acesta poate să realizeze conversia semnalelor de recepție (RX), de transmisie (TX), dar și a semnalelor de protocol Clear to send (CTS) respectiv Ready to send (RTS).

Tabel 4.1. Nivele de tensiune pentru circuitul integrat Max3232

4.2.6. Modulul Bluetooth

Grupul T4, R26 și R27 legat la RX realizează amplificarea nivelului de 3.3V.

Divizorul de tensiune legat la portul de transmisie al ELM327 are rolul de a reduce nivelul TX de la 5V la aproximativ 3.3V. Pentru un potențial de 3.3V, provenit de la modulul bluetooth tranzistorul este blocat, iar la pinul RX al ELM327 se vor regăsi 5V. Pentru un potențial de 0V tranzistorul este în saturație, iar la RX se vor regăsi 0V.

Figura 4.11. Modulul bluetooth

Pentru a realiza comunicația între sistemul de diagnoză OnRoad Diagnostic și terminalul mobil am ales modulul bluetooth RN-42:

Figura 4.12. Modulul bluetooth RN-42

Sursa:http://www.robofun.ro/bluetooth_arduino?keyword=bluetooth&category_id=0

4.2.7. Modulul de interfață cu utilizatorul

Modulul de interfață cu utilizatorul conține patru butoane ce controlează meniul dispozitivului. Acestea sunt legate prin intermediul unui conector (6 pini) la portul D al microcontroller-ului ATMega32.

Figura 4.13. Imagine virtuală a modulului de interfațare cu utilizatorul

Figura 4.14. Modulul de interfață cu utilizatorul

4.3. Proiectarea cablajului imprimat (PCB)

Pentru proiectarea cablajului imprimat al dispozitivului OnRoad Diagnostic am folosit editorul PCB al programului Design Spark 5.1.

PCB-ul (Printed Circuit Board) a fost realizat pe un sigur strat de cupru, „bottom copper”, cu o dimensiune totală a plăcii de 14cm x 10cm.

Am ales dimensiunile după cum urmează:

Traseele de alimentare și masă între 0.889mm și 1.27mm,

Traseele semnalelor provenite de la circuitele de interfațare cu ECU: 0.889mm,

Traseele asociate circuitului integrat (ELM327), în tehnologie SMT (Surface-mount technology): 0.7mm,

Găurile pentru pinii componentelor THT (Through-hole technology): diametrul interior de 0.9mm și diametrul exterior de 1.8mm.

4.3.1. Cablajul imprimat al dispozitivului

Figura 4.15. PCB-ul sistemului OnRoad Diagnostic

4.3.2. Cablajul imprimat al modulului de control

Figura 4.16. PCB-ul modulului de interfață cu utilizatorul

4.4. Software-ul dispozitivului

4.4.1. Inițializarea comunicației UART

Scopul funcției uart_init() este acela de a stabili baud rate-ul la care va avea loc comunicația între dispozitive dar și de a activa mecanismele de transmisie (TX) respectiv recepție (RX).

void uart_init (unsigned int baudrate_init)

{

UBRRH=(unsigned char)(baudrate_init>>8);

UBRRL=(unsigned char) baudrate_init;

UCSRB|=(1<<TXEN)|(1<<RXEN);

UCSRC|=(1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1);

}

Registrul USART Baud Rate Register (UBRR) este un registru de 16 biți în care este stocată informația despre baud rate. Acesta este structurat în două registre de 8 biți: UBRRH și UBRRL.

Registrul UBRRH conține cel mai semnificativ octet de informație, în timp ce UBRRL conține cei mai puțin semnificativi biți de informație.

Funcția primește ca parametru o valoare întreagă, baudrate_init, care este definită pe baza formulei :

Unde F_CPU reprezintă valoarea frecvenței de ceas a sistemului, iar BAUD este valoarea aleasă a baud rate-ului.

În prezentul proiect am ales frecvența de ceas ca fiind F_CPU=4000000UL(4MHz), iar baud rate-ul de 19200 b/s.

Pentru o simplificare a codului cele două valori au fost definite în header-ul fișierului sursă sub forma:

#define BAUD 19200

#define BAUDRATE ((F_CPU)/(BAUD*16UL)-1)

Prin secvența de cod UCSRB|=(1<<TXEN)|(1<<RXEN) în registrul UART Control and Status Register B (UCSRB) va fi încărcată valoarea 018H (valoare binară = 00011000) prin care se modifică valoarea biților reprezentativi pentru activarea structurii de transmisie TXEN respectiv recepție RXEN.

Figura 4.17. Structura registrului UCSRB

Sursa: Foaia de catalog a microcontroller-ului ATMega32, pag 165/357

Secvența de cod UCSRC|=(1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1) încarcă în registrul UART Control and Status Register C (UCSRC) valoarea 086H (valoare binară =10000110).

Această valoare este obținută prin schimbarea valorii inițiale (0) a biților URSEL, UCSZ0 și UCSZ1.

Figura 4.18. Structura registrului UCSRC

Sursa: Foaia de catalog a microcontroller-ului ATMega32, pag 166/357

Bitul URSEL stabilește ce registru va fi accesat: UCSRC sau URRBH. Deoarece se execută o operație de scriere în registru, valoarea bitului URSEL este 1.

Valorile biților UCSZ1 și UCSZ0 au fost alese în concordanță pentru a defini lungimea cuvântului de date la 8 biți.

Variații ale celor doi biți pot determina diferite lungimi ale cuvintelor:

Tabel 4.2. Configurația biților UCSZ1 și UCSZ0

4.4.2. Transmisia de caractere respectiv șiruri de caractere prin UART

Funcțiile uart_transmit(char send_data) și uart_transmit_string(char *send_string) implementează metodele de transmisie ale unui caracter respectiv ale unui șir de caractere prin intermediul UART.

void uart_transmit (char send_data)

{

while (!( UCSRA & (1<<UDRE)))

{}

UDR = send_data;

}

void uart_transmit_string(char *send_string)

{

while(*send_string)

{

uart_transmit(*send_string++);

}

Se realizează o operație logică ȘI (AND) între registrul UCSRA și 00100000 (UDRE) prin care se determină dacă registrul USART Data Register (UDR) este pregătit pentru a începe transmisia caracterului.

Cât timp rezultatul operației ȘI este diferit de 1, se așteaptă ca flag-ul UDRE să devină 1, iar când acesta își schimbă starea inițială, caracterul este pus în buffer-ul de transmisie UDR.

4.4.3. Recepția de caractere și șiruri de caractere prin UART

unsigned char uart_recieve(void)

{

while(!(UCSRA & (1<<RXC)))

{

}

return UDR;

}

char* uart_recieve_string(char a[])

{

char *ret;

int i=0;

while((a[i++]=uart_recieve())!=0x3E);

a[i]='\0';

ret=a;

return(ret);

}

Funcția uart_recieve() verifică starea flag-ului RXC din registru UCSRA, flag ce indică starea datelor din buffer-ul de recepție.

Figura 4.19. Structura registrului UCSRA

Sursa: Foaia de catalog a microcontroller-ului ATMega32,pag 164/357

Flag-ul RXC are valoarea 1 atunci când există date necitite în buffer-ul de recepție și are valoarea 0 atunci când toate datele recepționate au fost citite.

Funcțiile vor transfera datele din buffer-ul de recepție într-un array atâta timp cât flag-ul RXC are valoarea 1.

Funcția uart_recieve_string(char a[]) definește un șir de caractere (array) în care vor fi puse datele recepționate până la întâlnirea caracterului “>” (cod ascii: 3E) care marchează încheierea răspunsului primit de la microcontroller-ul ELM327. Funcția returnează un pointer care conține adresa șirului de caractere recepționat.

4.4.4. Citirea și stocarea datelor unui parametru cerut

uart_transmit_string("010D\r");

uart_recieve_string(recbuf);

deleteCR(recbuf);

sscanf(recbuf,"%*s %*s %X",&speed);

sprintf(speed_buff,"%d",speed);

Funcția “uart_transmit_string()” trimite către ECU modul de funcționare în care se lucrează “01” și PID-ul corespunzător parametrului viteză de deplasare“0D” urmat de “\r”, carriage return .

După trimiterea acestei secvențe, funcția “uart_recieve_string()” recepționează datele primite de la ECU și le pune în buffer-ul “recbuf” de unde șirul de date este parcurs de funcția “deleteCR()” al cărei scop este acela de a elimina carriage return-ul și caracterul ce marchează finalul răspunsului ( caracterul “>” ).

Răspunsul mașinii la parametrul “0D” este o secvență asemănătoare cu: 41 0D 64, unde primul byte reprezintă modul de funcționare (40 +01) iar cel de-al doilea, parametrul cerut (0D). Ultimul byte reprezintă viteza de deplasare a autovehiculului înregistrată de senzorul aferent exprimată hexazecimal ( 64(hex)= 100 (dec) KM/h ).

Secvența de cod “sscanf(recbuf,"%*s %*s %X",&speed)” tratează primii byte ca string și vor fi ignorați, iar ultimul byte va fi tratat ca hexazecimal și valoarea acestuia va fi salvată în variabila “speed”.

Valoarea zecimală a vitezei va fi copiată într-un buffer pentru a putea fi afișată pe ecranul LCD.

4.5. Programarea microcontroller-ului

Programarea microcontroller-ului ATMega32, responsabil de control și afișaj, este realizată prin intermediul interfeței de programare In Circuit Serial Programming (ICSP).

Figura 4.20. Conectorul ICSP 10-pin

Această interfață de programare folosește o comunicație serială Serial Peripheral Interface (SPI) pentru a transfera firmware-ul către microcontroller prin legarea conectorului ICSP-10 în următoarea configurație:

MISO (SPI Bus Master Input/Slave Output) conectat la pinul 7 (PB6),

MOSI (SPI Bus Master Output/Slave Input) conectat la pinul 6 (PB5) ,

SCK (SPI Bus Serial Clock) conectat la pinul 8 (PB7),

RESET conectat la pinul 9 ().

Pentru programarea dispozitivului ATMega32 am folosit un programator universal pentru toate produsele Atmel numit DIAMEX-PROG-S.

Figura 4.21. Programatorul DIAMEX-PROG-S

Sursa: http://www.heise.de

CAPITOLUL 5.

CONCLUZII ȘI CONTRIBUȚII PERSONALE

5.1. Concluzii

Consider oportună, la începutul capitolului de „Concluzii și contribuții personale”, expunerea limitelor dispozitivului prezentat pe larg în paginile precedente, principalul aspect fiind reprezentat de imposibilitatea modificării parametrilor unității centrale de control (ECU) al autovehiculului. Firmware-ul acesteia este proprietatea de drept a producătorului și orice modificare poate determina probleme de natură legală dar și tehnică în cazul unei intervenții defectuoase.

De asemenea, limitările pot surveni și din pricina diferențelor structurale și funcționale ale autoturismelor pe care dispozitivul poate fi instalat.

Deși limitările dispozitivului nu sunt de neglijat, numărul funcționalităților este superior.

Dintre acestea reamintesc: mobilitate, accesibilitate pentru toate tipurile de utilizatori, compatibilitate cu o gamă largă de autovehicule, comunicație bluetooth și un design ergonomic.

Scopul dispozitivului este acela de a detecta, de a avertiza și elimina erorile apărute în procesul de funcționare al autovehiculului, reducând semnificativ riscul producerii accidentelor cauzate de defecțiuni de natură mecanică sau electronică.

Pe lângă capacitatea de diagnoză, sistemul OnRoad Diagnostic poate reprezenta și un upgrade pentru automobilele “low end” ce nu dispun de un sistem care să furnizeze informații despre consumul de carburant, temperatura ambientală, viteza de deplasare, cuplu dezvoltat de motor, etc.

5.2. Avantaje

Ideea sistemului a luat naștere din dorința de a rezolva o parte din neajunsurile interfețelor de diagnosticare deja existente pe piață.

Pentru a exemplifica acest fapt voi reaminti principalele avantaje:

Implementarea a patru moduri de funcționare: modul CALCULATOR, modul MOBIL, modul DISPOZITIV respectiv modul AUTO,

Creșterea gradului de mobilitate prin implementarea unei comunicații bluetooth,

Dimensiuni reduse,

Accesul direct la parametri de interes,

O interfață intuitivă cu utilizatorul,

Pentru o bună utilizare a sistemului nu sunt necesare cunoștințe avansate de mecanică sau electronică, acesta expunând informațiile într-o manieră ușor de înțeles,

Implementarea unui mecanism de detecție automată a problemelor și informarea utilizatorului cu privire la acestea printr-un semnal sonor,

Eliminarea necesității unei surse de tensiune externe, dispozitivul fiind alimentat de la acumulatorul autoturismului,

Sistemul OnRoad Diagnostic nu necesită un software specializat, deseori greu de înțeles și cu o interfață deloc prietenoasă.

5.3. Contribuții personale

Sintetizând cele expuse în decursul prezentei lucrări de diplomă, enumăr principalele contribuții personale aduse:

Studierea și sintetizarea informațiilor despre protocolul OBD-II și a diferitelor standarde ale acestuia implicate în interconectarea mașină-sistem de calcul,

Studierea modului de funcționare al microcontroller-ului specializat ELM327,

Sintetizarea informațiilor despre metodele de comunicare cu un sistem de calcul implementate în dispozitiv,

Proiectarea schemei electrice structurată în module a dispozitivului OnRoad Diagnostic,

Proiectarea cablajului imprimat în funcție de schema electrică,

Realizarea practică a cablajului imprimat prin metodă Press-And-Peel,

Adaptarea firmware-ului microcontroller-ului specializat ELM327 pentru o mai bună potrivire cu întregul ansamblu,

Realizarea integrală a firmware-ului modului de control și afișaj,

Realizarea practică a sistemului de diagnoză automată OnRoad Diagnostic,

Realizarea aplicației pentru sistemul de operare Android, dedicată comunicației cu dispozitivul OnRoad Diagnostic.

5.4. Dezvoltări ulterioare

Realizarea unei aplicații adresată sistemului de operare Windows, capabilă să efectueze operații complexe pe baza parametrilor obținuți de la autoturism, precum grafice și recomandări ale modificării regimului de mers,

Implementarea unei aplicații dedicată terminalelor mobile (smartphone-urilor sau tabletelor), prin care să existe posibilitatea realizării controlului dispozitivului având în vedere că structura hardware o permite,

Reproiectarea întregului sistem în tehnologie SMT (Surface-mount technology) prin care se urmărește reducerea considerabilă a dimensiunilor,

Implementarea unui mecanism care să permită modificarea parametrilor motorului cu scopul de a îmbunătăți performanțele acestuia,

Asocierea sistemului cu baza de date a Registrului Auto Român (RAR) prin care să se poată realiza programările în vederea reviziilor tehnice anuale în funcție de numărul de kilometri sau gradul de uzură al autovehiculului,

Integrarea în sistemul de navigație al autovehiculului pentru o vizualizare mai facilă a parametrilor.

BIBLIOGRAFIE

Mastakar, Gaurav, Experimental Security Analysis of a Modern Automobile,

University of Washington, 2012.

Publications Office of the European Parliament, “Directive 98/69/EC of the European

Parliament" , 2007.

Volkswagen AG, Volkswagen-Audi OBD-II Readines Code Charts,2013, pp 31-98.

Volkswagen AG, Golf,Jetta,Rabbit service Manual, 2006.

Huang Pan, ISO9141-2 and J1939 Protocols on OBDII, University of Changhua, 2009.

Registrul Federal de Mediu, website accesat în aprilie 2014 la adresa

http://www.epa.gov/fedrgstr/.

Agenția de Protecție a Mediului California, website accesat în februarie 2014 la

adresa http://www.arb.ca.gov.

National OBD Clearinghouse, website accesat în aprilie 2014 la adresa

http://www.obdclearinghouse.com/.

Engine Codes, website accesat în luna ianuarie 2014 la adresa www.engine-odes.com.

Pinout Guide, website accesat în luna martie 2014 la adresa http://pinoutsguide.com.

Mihai Romanca, Curs Sisteme cu calculator integrat anul universitar 2012- 2013.

Mihai Romanca ,Curs Microprocesoare anul universitar 2012-2013.

Petre Ogrutan, Curs Interfețe, Protocoale și Semnalizări anul universitar 2013-2014.

OBD Codes, website accesat în luna aprilie 2014 la adresa http://www.obd-codes.com.

Wilfried Vass, A Comprehensible Guide to J1939,Copperhill Media Corporation,2008.

E-automobile, website accesat în luna aprilie 2014 la adresa http://www.e-automobile.ro.

Volkswagen AG Self-study programme 269, Data transfer on CAN data BUS vol.1.

Volkswagen AG Self-study programme 231, Euro On-Board Diagnostic System.

Volkswagen AG Self-study programme 315, Euro On-Board Diagnostic System.

Outils OBD Facile, website accesat în aprilie 2014 la adresa

http://www.outilsobdfacile.com/obd-mode-pid.php.

United States Enviromental Protection Agency, website accesat în iunie 2014 la adresa

http://www.epa.gov/obd/.

[22] . Itead Studio, Make Arduino Talk With Android by Bluetooth, website accesat în luna

mai 2014 la adresa http://blog.iteadstudio.com/make-arduino-talk-with-android-by-

bluetooth.

[23] . AVR Freaks, website accesat în luna mai 2014 la adresa http://www.avrfreaks.net.

ANEXE

Anexa NR. 1 Codul sursă

Biblioteca de funcții pentru alarmă:

buzzer.h:

#include <avr/io.h>

#include <stdint.h>

#include <avr/interrupt.h>

#include <util/delay.h>

#define BUZZER_PORT PORTD

#define BUZZER_PORT_PIN PIND

#define BUZZER_PORT_BIT PD6

void alarm(void);

buzzer.c

#include <avr/io.h>

#include <stdint.h>

#include <avr/interrupt.h>

#include <util/delay.h>

#include "buzzer.h"

void alarm(void)

{

_delay_ms(500);

BUZZER_PORT |=(1<<PD6);

_delay_ms(500);

BUZZER_PORT &=~(1<<PD6);

_delay_ms(500);

BUZZER_PORT |=(1<<PD6);

_delay_ms(500);

BUZZER_PORT &=~(1<<PD6);

_delay_ms(500);

BUZZER_PORT |=(1<<PD6);

_delay_ms(500);

BUZZER_PORT &=~(1<<PD6);

_delay_ms(500);

}

Biblioteca de funcții pentru butoane:

buttons.h

#include <avr/io.h>

#include <stdint.h>

#include <avr/interrupt.h>

#include <util/delay.h>

#define BUTTON_PORT PORTD

#define BUTTON_LEFT_PIN PIND

#define BUTTON_LEFT_BIT PD2

#define BUTTON_RIGHT_PIN PIND

#define BUTTON_RIGHT_BIT PD3

#define BUTTON_UP_PORT PORTD

#define BUTTON_UP_PIN PIND

#define BUTTON_UP_BIT PD4

#define BUTTON_DOWN_PIN PIND

#define BUTTON_DOWN_BIT PD5

void init_button();

int button_is_pressed_left();

int button_is_pressed_right();

int button_is_pressed_up();

int button_is_pressed_down();

buttons.c

#include <avr/io.h>

#include <stdint.h>

#include <avr/interrupt.h>

#include <util/delay.h>

#include "buttons.h"

void init_button()

{

BUTTON_PORT |= (1<<BUTTON_LEFT_BIT)

|(1<<BUTTON_RIGHT_BIT)

|(1<<BUTTON_UP_BIT)

|(1<<BUTTON_DOWN_BIT);

}

int button_is_pressed_left()

{

if (bit_is_clear(BUTTON_LEFT_PIN, BUTTON_LEFT_BIT))

{

_delay_ms(50);

if (bit_is_clear(BUTTON_LEFT_PIN, BUTTON_LEFT_BIT)) return 1;

}

return 0;

}

int button_is_pressed_right()

{

if (bit_is_clear(BUTTON_RIGHT_PIN, BUTTON_RIGHT_BIT))

{

_delay_ms(50);

if (bit_is_clear(BUTTON_RIGHT_PIN, BUTTON_RIGHT_BIT)) return 1;

}

return 0;

}

int button_is_pressed_up()

{

if (bit_is_clear(BUTTON_UP_PIN, BUTTON_UP_BIT))

{

_delay_ms(50);

if (bit_is_clear(BUTTON_UP_PIN, BUTTON_UP_BIT)) return 1;

}

return 0;

}

int button_is_pressed_down()

{

if (bit_is_clear(BUTTON_DOWN_PIN, BUTTON_DOWN_BIT))

{

_delay_ms(50);

if (bit_is_clear(BUTTON_DOWN_PIN, BUTTON_DOWN_BIT)) return 1;

}

return 0;

}

Biblioteca de funcții pentru afișare pe LCD

lcd.h

#include <avr/io.h>

#include <util/delay.h>

#include <stdio.h>

#include <stdlib.h>

#include <avr/interrupt.h>

#include <math.h>

#define LCD_DATA PORTC

#define ctrl PORTA

#define en PA7

#define rw PA6

#define rs PA5

void LCD_cmd(unsigned char cmd);

void init_LCD(void);

void LCD_write(unsigned char data);

void LCD_write_string(char *data);

char* rx_string(char a);

void LCD_write_string_P(const char *data);

lcd.c

#ifndef F_CPU

#define F_CPU 4000000UL

#endif

#include <avr/io.h>

#include <util/delay.h>

#include <stdio.h>

#include <stdlib.h>

#include <avr/interrupt.h>

#include <math.h>

#include <avr/pgmspace.h>

#include "lcd.h"

void init_LCD(void)

{

_delay_ms(20);

LCD_cmd(0x30);

_delay_ms(5);

LCD_cmd(0x30);

_delay_ms(1);

LCD_cmd(0x30);

_delay_ms(10);

LCD_cmd(0x3C);

_delay_ms(1);

LCD_cmd(0x08);

_delay_ms(1);

LCD_cmd(0x01);

_delay_ms(1);

LCD_cmd(0x06);

_delay_ms(1);

LCD_cmd(0x0C);

}

void LCD_cmd(unsigned char cmd)

{

LCD_DATA=cmd;

ctrl =(0<<rs)|(0<<rw)|(1<<en);

_delay_ms(1);

ctrl =(0<<rs)|(0<<rw)|(0<<en);

_delay_ms(1);

return;

}

void LCD_write(unsigned char data)

{

LCD_DATA= data;

ctrl = (1<<rs)|(0<<rw)|(1<<en);

_delay_ms(1);

ctrl = (1<<rs)|(0<<rw)|(0<<en);

_delay_ms(1);

return ;

}

void LCD_write_string(char *data)

{

int i=0;

while(data[i]!='\0')

{

LCD_write(data[i]);

i++;

}

return;

}

void LCD_write_string_P(const char *data)

{

while ( pgm_read_byte(data) != 0x00)

{

LCD_write ( pgm_read_byte(data) );

data++;

}

Biblioteca de funcții pentru UART

uart.h

#ifndef F_CPU

#define F_CPU 4000000UL

#endif

#include <avr/io.h>

#include <util/delay.h>

#include <stdio.h>

#include <stdlib.h>

#include <avr/interrupt.h>

#include <math.h>

#define BAUD 19200

#define BAUDRATE ((F_CPU)/(BAUD*16UL)-1)

unsigned char dummy;

void uart_init (unsigned int baudrate_init);

void uart_transmit (char send_data);

void uart_transmit_string(char *send_string);

unsigned char uart_recieve();

char* uart_recieve_string(char a[]);

void USART_Flush( void );

void ReadStringData(char *str);

char ReadData( void );

void USART_Flush( void );

uart.c

#ifndef F_CPU

#define F_CPU 4000000UL

#endif

#include <avr/io.h>

#include <util/delay.h>

#include <stdio.h>

#include <stdlib.h>

#include <avr/interrupt.h>

#include <math.h>

#include "uart.h"

void uart_init (unsigned int baudrate_init)

{

UBRRH=(unsigned char)(baudrate_init>>8);

UBRRL=(unsigned char) baudrate_init;

UCSRB|=(1<<TXEN)|(1<<RXEN);

UCSRC|=(1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1);

}

void uart_transmit (char send_data)

{

while (!( UCSRA & (1<<UDRE))){}

UDR = send_data;

}

void uart_transmit_string(char *send_string)

{

while(*send_string)

{

uart_transmit(*send_string++);

}

unsigned char uart_recieve(void)

{

while(!(UCSRA & (1<<RXC)))

{

}

return UDR;

}

char* uart_recieve_string(char a[])

{

char *ret;

int i=0;

while((a[i++]=uart_recieve())!=0x3E);

a[i]='\0';

ret=a;

return(ret);

}

void USART_Flush( void )

{

while ( UCSRA & (1<<RXC) )

{

dummy = UDR;

}

Anexa NR. 2 Schema electrică a dispozitivului

Anexa NR. 3 Lista componentelor

Anexa NR. 4 Poze cu dispozitivul