Interfata de Analiza Si Diagnosticare Evenimente In Timp Real

Interfață de analiză și diagnosticare evenimente în timp real

Proiect de diplomă

Cuprins

Lista Figurilor

Lista Tabelelor

Lista Acronimelor

Introducere

1 Aspecte generale privind autovehiculele și a sitemului de diagnoză

1.1 Noțiuni introductive

1.2 Necesitatea apariției protocoalelor de communicații pe autovehicule

1.3 Scurt istoric al evoluției autovehiculelor și al sistemelor electronice

1.4 Sistemul electronic al autovehicului

2 Prezentare generală a componentelor care compun întreg sistemul de diagnoză

2.1 Prezentare OBDII

2.2 Rețeaua CAN

2.3 Prezentare ELM327

2.3.1 Schema circuitului

2.3.2 Legătura PC – ECU

2.4 Prezentare Matlab

3 Prezentarea aplicației

3.1 Prezentarea interfeței și a modului de interconectare între module

3.2 Implementare

3.2.1 Serviciul #01- Cererea datelor curente de diagnosticare ale sistemului de propulsie

3.2.2 Serviciul#02 – Cerere pentru date stop cadru pentru trenul de rulare

3.2.3 Serviciul#03 – Diagnoza codurilor de eroare stocate în memoria ECU

3.2.4 Serviciul#04- Ștergerea/Resetarea codurilor de eroare

3.2.5 Serviciul #05 – Cerere de monitorizare a senzorilor de oxigen

3.2.6 Serviciul #06 – Cerere a rezultatelor testelor de monitorizare pentru sisteme specifice

3.2.7 Serviciul #07 – Cerere a codurilor de eroare ce nu au fost memorate

3.2.8 Serviciul #08 – Cerere pentru controlul sau modificarea anumitor parametrii ai componentelor

3.2.9 Serviciul #09- Cerere informații generale privind vehiculul

3.2.10 Comunicația cu autovehiculul

4 Recomandări privind utilizarea aplicației

5 Concluzii

6 Bibliografie

Anexa1

Anexa2

Anexa3

Lista Figurilor

Figura 1.1[4] Exemple componente electronice: a) senzor de turație, b) unitate electronică de comandă 18

Figura 1.2[5] a) Comunicație K-Line b) Comunicație CAN 18

Figura 1.3[3] Grafic evoluția sistemelor electronice în domeniul auto 19

Figura 1.4[9] Componente electrice și electronice într-un automobil 20

Figura 1.5[7] Domeniul de temperatură pentru anumite componente ale autovehivulului 21

Figura 2.1[13] Formatul unui mesaj cadru definit de protocolul CAN 24

Figura 2.2[13] Modul de transmitere a mesajelor prin rețeaua CAN și prioritizarea acestora 25

Figura 2.3[13] Prezentare CAN HighSpeed și CAN LowSpeed 26

Figura 2.4[14] Diagrama bloc a integratului ELM327 26

Figura 2.5[14] Schema de montaj a integratului ELM327 27

Figura 3.1Interfața programului ”Unealtă de analiză și diagnosticare” 31

Figura 3.2 Diagrama de conectare a modulelor 32

Figura 3.3[17] Exemplu de mesaj pentru Serviciul #01 34

Figura 3.4 Interfața pentru Servciul#01 34

Figura 3.5 Interfața pentru Serviciul#01 PID-ul 01 36

Figura 3.6 Exemplu interfață Serviciul#02 37

Figura 3.7[18] Modul de interpretare al erorilor 37

Figura 3.8 Interfața Serviciului#03 38

Figura 3.9 Exemple ale interfeței pentru Serviciul#06 40

Figura 3.11 Interfața pentru Serviciul#07 41

Figura 3.10[16] Modul de interpretare a unui de cod de eroare 41

Figura 3.12 Interfață VIN 42

Figura 3.13 Interfața pentru citirea ID-ului Calibrării și pentru citirea Numărului de Verificare al Calibrării 44

Figura 4.1 Mod de utilizare interfață – 1 46

Figura 4.2 Mod de utilizare interfață – 2 46

Figura 4.3 Mod de utilizare interfață – 3 47

Lista Tabelelor

Tabelul 2.1[19] Exemplu de parametrii și ID-urile lor 23

Tabelul 2.2[13] Conținutul fiecărui câmp al unui mesaj cadru definit de protocolul CAN 24

Tabelul 2.3[9] Formatul pinilor pentru mufa RS232 29

Tabelul 2.4[9] Formatul pinilor pentru mufa OBD II 29

Tabelul 3.1[16] Exemplu răspuns pentru Serviciul#02 36

Tabelul 3.2[16] Exemplu de răspuns pentru Serviciu#03 38

Tabelul 3.3[16] Exemplu de răspuns pentru Serviciul#06 39

Tabelul 3.4[16] Exemplu răspuns provenit de la ECU privind VIN 42

Tabelul 3.5[16] Exemplu răspuns provenit de la ECU privind ID-ul Calibrării 43

Lista Acronimelor

ABS = Anti-Lock Braking System

CAN = Controller Area Network

CO2 = dioxid de carbon

COM = communication port

CP = Cai Putere

CRC = cod cu redundanță ciclică

CSMA/CD = Carrier Sense Multiple Access / Collision Detection

CVN = Calibration Verification Number

DTC = Data Trouble Code

ECU = engine control unit

ESP = Electronic Stability Control

IPT = In-use Performance Tracking

IUPT = In-use Performance Tracking

KWP = Keyword Protocol

LSFT = low speed fault tolerant transceiver

MIL = Malfunction indicator light

NDBA = Non-Destructive Bitwise Arbitration

NOR = număr octeți returnați

NOx = Azotati

OBDII = On Board Diagnostic ( Diagnostic On – Board )

PC = Personal Computer

RS-232 = reprezinta un standard in comunicatia seriala a datelor

SAE = Society of Automotive Engineers

STP = Shielded Twisted Pair

SW = Single Wire

UTP = Unshielded Twisted Pair

VIN = Vehicle Identification Number

Introducere

Toate autovehiculele fabricate în ziua de astăzi pun la dispoziție, prin lege, o interfață prin care să se poată efectua o citire a datelor existente în soft-ul automobilului. “ Interfața de analiză și diagnosticare a evenimentelor ” reprezintă o unealtă software cu ajutorul căreia orice PC sau laptop se poate transforma într-un sistem sofisticat de diagnosticare auto. [1]

Automobilul modern reprezintă produsul a mai multor direcții de inginerie îmbinate armonios. Dintre acestea un loc din ce în ce mai important îl reprezintă electronica, acest domeniu fiind într-o continuă expansiune pe piața mondială. Prin acest domeniu s-a reușit rezolvarea unei mari probleme, aceea a reducerii poluării mediului înconjurător datorat emisiilor de NOx si CO2, rezultate prin arderea combustibilului, provenit de la numărul din ce în ce mai mare de autovehicule produse la nivel mondial.

Tema prezentată în continuare a fost aleasă în urma finalizării unui stagiu în cadrul companiei Renault Technologie Roumanie. Acest produs este deja existent pe piață dar s-a dorit obținerea unei alte unelte care să corespundă cerințelor companiei adică să fie ușor de folosit și cu costuri de realizare cât mai mici.

Pentru a înțelege cum funcționează aceasta, mi-am propus să vă prezint în continuare modul de transmitere al infomației provenite de la ECU, prin mesageria de tip CAN sau K-Line, prin mufa OBDII și apoi cum este interpretată de către softul prezentat în lucrare.

Unealta de analiză și diagnosticare execută o multitudine de funcții privind analiza și diagnosticarea autovehicului : se pot citi date provenite de la un autovehicul, ca de exemplu câte rotații execută motorul într-un minut, viteza autovehiculului, temperatura lichidului de răcire, valori ale unor senzori prezenți pe autovehicul sau se mai poate face o diagnoză a codurilor de eroare, după care ștergerea erorilor în cazul în care acestea există, toate acestea făcându-se în timp real.

Aceasta are la bază un microcontroler ELM327, care respectă anumite standarde și care crează o legătura între portul OBDII al autovehicului și standardul de comunicație RS-232 al PC-ului sau al laptop-ului. Denumirea termenului OBD provine din lumea autovehiculelor și semnifică capacitatea de autodiagnosticare a acestora, iar în caz de eroare aprinderea martorului din bord.

“Interfața de analiză și diagnosticare” este compatibilă cu două din mesageriile existente în lumea automobilelor având protocoalele de comunicație CAN si K-Line, aceasta fiind conform standardelor ISO 15765-4 și ISO 14230-4, iar partea software a fost realizată cu ajutorul mediului de dezvoltare pentru calcul numeric și analiză statistică Matlab.

În dezvoltarea aplicației principala mea contribuție o reprezintă partea software, aceasta fiind 100% contribuția studentului, iar partea hardware a fost realizată cu ajutorul coordonatorului temei de stagiu.

Aspecte generale privind autovehiculele și sistemului de diagnoză

Noțiuni introductive

”Vehicul, (din fr. véhicule, lat. vehiculum), este un sistem mecanic construit pentru a se putea deplasa pe o cale de comunicație cu sau fără mijloace de autopropulsare, prin rulare, alunecare sau plutire și utilizat pentru transportul de persoane sau bunuri ori pentru efectuarea de servicii sau lucrări.” [8]

”Autovehicul este un vehicul echipat cu motor cu scopul scopul deplasării pe drum”[7], din această categorie facând parte și troleibuzele și tractoarele rutiere. Nu sunt considerate autovehiculele mopedele, vehiculele care se deplasează pe șine, aici putând fi incluse toate vehiculele care se deplasează ocazional pe drumurile publice

”Autoturism sau mai familiar mașină, este un autovehicul cu 4 ( rar cu 3 sau 6 roti ) acționat de un motor cu ardere interna, cu aburi, cu electricitate sau aer comprimat. Are scaune pentru conducator și pentru cel puțin un pasager.”[7]

Automobilele sunt de obicei construite pentru a călătorii pe drumurile publice, dar există unele, mai ales vehicule utilitare, care permit călătorii în afara drumurilor ( off-road ). Drumurile și autostrăzile sunt folosite în comun cu alte vehicule, cum sunt motocicletele și tractoarele.[7]

Necesitatea apariției protocoalelor de comunicații pe autovehicule

Nevoia simplificării modului de condus și de sporire a singuranței șoferului în timp ce acesta se află la volan au determinat nevoia adăugarii pe autovehicul a unor funcționalități de natură electronică pentru a facilita implementarea acestora. Dezvoltarea electronicii pe autovehicule a avut un succes foarte mare de la sfarșitul anilor ’90 până în prezent, aceasta reprezentând aproape 25% din totalul componentelor automobilului.

Majoritatea componentelor electronice prezente pe autovehicul sunt reprezentate de către senzori și actuatori. Exemple de astfel de componente sunt : senzori de turație, senzori de temperatură, actuatori precum clapeta de la admisie, o mare diversitate de unități electronice de comandă care monitorizează și controlează toate funcționalitățile de care acel autovehicul dispune (ECU, unitatea de comandă a airbag-urilor, calculatorul pentru habitaclu, unitatea de comandă pentru ABS, ESP, etc.).

Figura 1.1[4] Exemple componente electronice: a) senzor de turație, b) unitate electronică de comandă

Din punct de vedere al protocoalelor întalnim mai multe tipuri cum ar fi :

protocolul CAN s-a bucurat de success încă de la apariția sa în 1980, în prezent fiind cel mai utilizat în industria automobilelor deoarece are o magistrală pentru transmiterea datelor și una pentru recepția acestora. ( Figura1.2 a) )

lin ( local interconnect network ) a fost dezvoltat de o serie de mari producători în industria auto, scopul fiind obținerea unui protocol foarte ieftin, simplu și de viteză mai mică pentru o serie de functionalități cu o importanță scăzută

K – Line sau KWP2000 este un protocol care suportă viteze de ordinul Kb și este folosit pentru autovehiculele low cost deoarece transmisia si recepția se efectuează pe aceeași magistrală ( Figura 1.2 b) ) de unde rezultă și un cost mai mic.

FlexRay – acesta este un protocol de comunicație foarte stabil, tolerant la erori și cu viteză mare de transport de până la 10Mbit/s.

Figura 1.2[5] a) Comunicație K-Line b) Comunicație CAN

Scurt istoric al evoluției autovehiculelor și al sistemelor electronice

Primul proiect care ilustra un autovehicul a aparținut celui mai de seamă reprezentant al perioadei renașcentiste, Leonardo da Vinci, acesta având ca metodă de propulsie un motor oralogic ( cu ajutorul unui arc special ). Proiectul nu a fost finalizat niciodată.

Prima realizare concretă a unui vehicul autopropulsat a aparținut lui Joseph Cugnot în anul 1770, el construind un triciclu care era acționat de un motor cu aburi.

La 26 ianuarie 1886 a avut loc inaugurarea primului vehicul acționat de un motor cu ardere internă. Motorul avea 0,88 CP, un singur cilindru, iar răcirea era realizată cu ajutorul apei. Puțin mai târziu in aceeași perioadă a apărut și primul motor electric datorită dezvoltării domeniului electrotehnicii.

“In decursul ultimilor 150 de ani cercetările și relizarea automobilelor s-au dezvoltat pe mai multe direcții. :

Creșterea puteriri în industria auto, scopul fiind obținerea unui protocol foarte ieftin, simplu și de viteză mai mică pentru o serie de functionalități cu o importanță scăzută

K – Line sau KWP2000 este un protocol care suportă viteze de ordinul Kb și este folosit pentru autovehiculele low cost deoarece transmisia si recepția se efectuează pe aceeași magistrală ( Figura 1.2 b) ) de unde rezultă și un cost mai mic.

FlexRay – acesta este un protocol de comunicație foarte stabil, tolerant la erori și cu viteză mare de transport de până la 10Mbit/s.

Figura 1.2[5] a) Comunicație K-Line b) Comunicație CAN

Scurt istoric al evoluției autovehiculelor și al sistemelor electronice

Primul proiect care ilustra un autovehicul a aparținut celui mai de seamă reprezentant al perioadei renașcentiste, Leonardo da Vinci, acesta având ca metodă de propulsie un motor oralogic ( cu ajutorul unui arc special ). Proiectul nu a fost finalizat niciodată.

Prima realizare concretă a unui vehicul autopropulsat a aparținut lui Joseph Cugnot în anul 1770, el construind un triciclu care era acționat de un motor cu aburi.

La 26 ianuarie 1886 a avut loc inaugurarea primului vehicul acționat de un motor cu ardere internă. Motorul avea 0,88 CP, un singur cilindru, iar răcirea era realizată cu ajutorul apei. Puțin mai târziu in aceeași perioadă a apărut și primul motor electric datorită dezvoltării domeniului electrotehnicii.

“In decursul ultimilor 150 de ani cercetările și relizarea automobilelor s-au dezvoltat pe mai multe direcții. :

Creșterea puterii motorului ;

Reducerea consumului de combustibil ;

Introducerea unor sisteme de semnalizare în trafic tot mai complexe;

Creșterea confortului pasagerilor;

Creșterea securității pasagerilor în cazul accidentelor;”[7]

Figura 1.3[3] Grafic evoluția sistemelor electronice în domeniul auto

“Se poate observa o creștere exponențială a numărului de componente electronice adăugate pe un autoturism din anul 1970. Până în acest an evoluția a fost destul de înceată deoarece nu existau materiale seminconductoare. Fiecărei litere din Figura1.3 îi corespunde o anumită evoluție cum ar fi :

semnalizare optică, acustică, radio, demaror, dinam;

aprindere tranzistorizată, alternator;

controlul vitezei de croazieră, injecția electronică de combustibil, controlul electronic al transmisiilor automate;

calculator de bord, indicator interval service, ABS, telefonie mobilă;

cheie electronică, sisteme integrate de control al motorului și al transmisiei, instrumente de bord electronice, suspensie adaptivă, diagnoza senzorilor de impact, sisteme de protecție antifurt;

imobilizator electronic, senzor de impact zonal;

multiplexare, diagnoză, sistem de navigare;

senzori de impact lateral, senzor de măsura a presiunii din pneuri;

sistem de acces în automobil bazat pe perimetru, detectarea prezentei ocupanților automobilului, detectarea și prevenirea răsturnării automobilului;

ESP;

sisteme X-by-wire (sistem de frânare și direcție electronică); “ Sursa[3]

Datorită anumitor componente s-a reusit o reducere a consumului de carburant cu 30% între un autovehicul cu părți electronice și unul fără aceste componente pe partea de injecție. Astăzi nicio mașina nu mai este produsă fără a avea în componență un calculator central ECU și o multitudine de senzori pentru a oferi o mai bună prestație a autovehiculului și de a încerca reducerea pe cât posibilă a emisiilor.

Sistemul electronic al autovehicului

Figura 1.4[9] Componente electrice și electronice într-un automobil

Un automobil produs astăzi, din clasa medie, cuprinde aproximativ 70-80 de motorașe și un număr asemănător de senzori și sisteme senzoriale (Figura 1.4). Un exemplu al evoluției electronicii pe autovehicul îl constituie diferența majoră dintre o mașina de mare succes a companiei Volkswagen, din anii 1960 care avea o putere maximă consumată de 136 W, 150 m de cabluri electrice și circa 80 de contacte electrice și aceeași mașină dar generație a anilor 2000, care are un consum de 2100 W, 1500 m de cabluri și 1200 contacte electrice.

Sistemele electronice destinate electronicii auto trebuie să functioneze în condiții extreme pentru a putea asigura o transversabilitate a aceluiași autovehicul pentru toate condițiile meteo și de drum din fiecare țară precum :

cele de temperatură (Figura1.4.2)

de vibrații

de umiditate

vapori și jeturi de solvenți organici

Prezentare generală a componentelor care compun întreg sistemul de diagnoză

Prezentare OBDII

OBDII sau diagnosticare on-board este un termen, așa cum spuneam mai sus în această lucrare, care se referă la capacitatea unui autovehicul de autodiagnosticare și de a raporta conducatorului prin intermediul unor anumiți martori dacă este vreo problemă cu sistemul. Acest standard ușurează munca celui care va dori sa repare defecțiunea apărută. O neregularitate a funcționării sau defectarea anumitor componente poate conduce la o creștere drastică a emisiilor de poluanți.

OBDII este construit urmărind documente standardizate SAE precum :

J1962 – Definește conexiunea fizică a conectorilor

J1978 – Definește operațiile minime care trebuiesc îndeplinite de către o unealtă de diagnosticare

J1979 – Definește standardul pentru serviciile de diagnosticare

J2012 – Definește standardul pentru codurile de eroare

Unealta de analiză și diagnosticare a fost implementată conform standardelor ISO 14230-4 și ISO 15765-4 și poate diagnostica 8 servicii din cele 10 prezentate în standarde :

Serviciul $01 – Cererea datelor de diagnosticare ale sistemului de propulsie curente

Serviciul $02 – Cerere pentru date stop cadru ale trenului de rulare

Serviciul $03 – Cerere pentru codurile de diagnoză al erorilor

Serviciul $04 – Ștergere / Resetare a erorilor

Serviciul $06 – Cerere a rezultatelor testelor de monitorizare in bord

Serviciul $07 – Cerere a codurilor de erori ce au fost detectate în timpul sau la finalul ciclului de condus

Serviciul $09 – Cerere informații vehicul (VIN, CalibrationID, CVN, IPT)

Producătorii de autovehicule nu sunt obligați să implementeze toate aceste servicii, aceștia putând defini și alte servicii pentru obținerea altor informații decât cele prevăzute în standard. Spre exemplu producătorii de autovehicule Ford și Renault folosesc serviciul #22 pentru diagnoza altor infomații.

În tabelul următor este prezentat modul în care sunt identificați anumiți parametrii, care este dimensiunea lor, aceasta putând fi cuprinsă între 1 și 4 octeți :

Tabelul 2.1[19] Exemplu de parametrii și ID-urile lor

Citirea parametrilor se face astfel : se transmite o cerere către calculatorul autovehiculului (EX : 010D – cerere pentru viteza autovehiculului), iar un exemplu de răspuns poate fi 410D4F unde 41 reprezintă răspunsul primit de la autovehicul (01+40), 0D reprezintă parametrul cerut, iar 4F reprezintă valoarea parametrului care semnifică 79Km/h.

Rețeaua CAN

Magistrala CAN este o magistrală serializată folosită îndeosebi în industria auto, care asigură comunicarea între microcontrolerele prezente pe mașină fără a exista un calculator gazdă care să organizeze toate mesajele.

CAN Bus a fost dezvoltată inițial de către firma Bosch, în anul 1983, ca un proiect intern pentru a crea o rețea în interiorul unui vehicul. Prima versiune a fost CAN1.2 și a fost industrializată în anul 1986.

Arhitectura CAN se poate defini pe mai multe nivele:

Nivelul fizic – acesta se ocupă de transmiterea biților printr-un canal de comunicație. Proiectarea trebuie să garanteze că atunci când este transmis un bit de 1 la recepție să avem un bit de 1 și nu 0. [10]

Nivelul de transfer : asigură legatura între nivelul fizic și acel obiect. Acesta trasmite/recepționează date de la nivelul superior (obiect), descompune datele și le transmite spre următorul nivel și verifică dacă datele sosesc corect la celălalt capăt

Nivelul obiect : aici se filtrează și manipulează informația

Nivelul aplicație

Protocolul CAN este optimizat pentru mesaje scurte și utilizează CSMA/CD cu metode arbitrare de acces NDBA. Șirul de biți transmiși este sincronizat începând cu bitul de start, iar arbitrajul se face în urmatorul mesaj identificator, unde 0 logic este dominant față de 1 logic.[6]

Figura 2.1[13] Formatul unui mesaj cadru definit de protocolul CAN

Tabelul 2.2[13] Conținutul fiecărui câmp al unui mesaj cadru definit de protocolul CAN

Corectitudinea datelor transmise este asigurată de câmpul CRC care reprezintă o sumă de control a întregii celule pentru detectarea erorilor. Polinomul generator este de forma (+)(+)(+)(+)(+)(+)(+)1.[12]

Mesajele transmise de calculatoarele unui autovehicul sunt prioritizate pe rețeaua CAN în funcție de ID-ul pe care îl au, prioritar fiind mesajul care are ID-ul cel mai mic. Cele mai prioritare mesaje sunt cele provenite la mecanismele de siguranță ale mașinii cum ar fi airbag sau sistemul de frânare.

Figura 2.2[13] Modul de transmitere a mesajelor prin rețeaua CAN și prioritizarea acestora

Unul din motivele pentru care rețeaua CAN este folosită în lumea autovehiculelor este acela că viteza de transfer pe rețea este destul de semnificativă. De exemplu pentru aproximativ 25m de cablu viteza ajunge la 1Mbps, iar pentru 1000m este de 50Kbps. De regulă pentru un autovehicul viteza datelor este de 500Kbps care înseamnă aproximativ 100m de cablu. Comunicația se poate face printr-un singur fir sau prin 2 fire, acestea putând fi STP sau UTP.

În figura următoare este prezentat modul în care se împarte magistrala CAN.

Figura 2.3[13] Prezentare CAN HighSpeed și CAN LowSpeed

Prezentare ELM327

Unealta de analiză și diagnosticare folosește pentru achiziția datelor un circuit integrat ELM327. Acesta poate fi privit ca o punte între interfața OBD II și interfața RS232 a calculatoarelor.

Ca principale caracteristici putem enumera :

Design CMOS de mică putere

Căutare automată a protocoalelor folosite de autovehicul

Rată de transfer până la 500 Kbps

Este complet configurabil, datorită faptului că acesta dispune de propriul set de comenzi

Pentru a folosi corect acest integrat trebuiesc făcute câteva setări înainte, cum ar fi setarea de către utilizator a portului ‘COM’ utilizat și de alegerea frecvenței de lucru corespunzătoare. Aceasta poate avea valoarea de 9600 daca pinul 6 are valoarea de 0V sau poate avea valoarea de 38400. Dacă portul ‘COM’ nu este setat corespunzător nu se vor putea trimite și nici recepționa date. Dacă rata de transfer nu este cea corespunzătore, mesajul recepționat de la ELM327 va fi deformat și va conduce la o interpretare greșită de către ‘Unealta de analiză și diagnosticare’

În figura urmatoare se poate vedea diagrama bloc a circuitului :

Schema circuitului

Acest circuit se bazează pe un dispozitiv PIC 18F2480 produs de către Microchip

Legătura PC – ECU

a) RS232

Tabelul 2.3[9] Formatul pinilor pentru mufa RS232

Standardul de comunicație RS232 a apărut încă din anii ’60. Acesta are o rată de transfer de 38,4Kbps. Acesta folosește ca tensiuni de referință un semnal de tip logic high (1 logic) cu tensiuni cuprinse între -3 și -15V (de obicei -12V) și celălalt semnal de referință de tip logic low (0 logic) cu tensiuni cuprinse între +3 si +15V (de obicei +12V).

b)

Tabelul 2.4[9] Formatul pinilor pentru mufa OBD II

Aceasta mufă este din ce mai des întalnită în industria autovehiculelor din 2008 până în prezent, ea fiind standardizată pentru a permite dezvoltarea de echipamente de diagnoză universale. Aceasta face legătura între rețeaua CAN a autovehicului și integratul ELM327.

Prezentare Matlab

Abrevierea MATLAB (Denumirea provine de la matrix laboratory) a fost creată la sfârșitul anilor ' 70 de către Cleve Moler, președintele departamentului de informatică al Universității din New Mexico. MATLAB permite manipularea matricilor (acesta fiind un element de bază pentru acest limbaj), vizualizarea funcțiilor, implementarea algoritmilor, procesare de semnal și de imagini, crearea de interfețe și poate interacționa și cu alte aplicații.[15]

Acest program dispune de aplicații specifice numite toolbox-uri. Acestea sunt asemănătoare unor funcții care extind acest mediu și ajută la rezolvarea unor probleme din domenii variate mult mai ușor. Acestea au extensia .m și pot fi folosite precum funcțiile predefinite.

Un alt pachet adițional este Simulink care oferă posibilitatea de a realiza simulări ale sistemelor dinamice și imbricate utilizând modele matematice, acestea având forma unor diagrame block.

Matlab este un limbaj de programare foarte raspândit în domeniul ingineriei și în mediul universitaților de profil.

Prezentarea aplicației

Prezentarea interfeței și a modului de interconectare între module

Figura 3.1Interfața programului ”Unealtă de analiză și diagnosticare”

Aceasta este interfața programului software ”Unealtă de analiză și diagnosticare”. Aici sunt ilustrate aproape toate serviciile, unele nefiind implementate din motive exemplificate mai jos în Capitolul 3. Acest soft a fost creat respectând standardul ISO 15031-5 al Societății Inginerilor de Automobile (SAE) și a fost dezvoltat folosind ca limbaj de programare Matlab. După cum se poate observa fiecare serviciu este bine delimitat, existând câte un chenar pentru fiecare.

Diagrama UML

În Figura3.2 este prezentat modul logic în care interfața apelează modulele, iar acestea la rândul lor apelează alte module.

Implementare

Serviciul #01- Cererea datelor curente de diagnosticare ale sistemului de propulsie

Descriere funcțională

Scopul acestui serviciu este de a permite accesul valorilor datelor legate de emisiile curente, incluzând input-urile și output-urile analogice, input-urile și output-urile digitale și informații privind starea sistemului. Cererea informației include o valoare a unui parametru de identificare (PID) care indică sistemului în-bord informația specifică care este cerută.

ECU-urile vor răspunde acestui mesaj prin transmiterea ultimei valori a datei cerute care a fost determinată de sistem. Toate valorile returnate pentru citirile senzorilor vor fi citiri actualizate, nu valori substitutive folosite de sistem, datorate anumitor erori ale acelui senzor. [16]

Cu alte cuvinte acest serviciu este utilizat pentru a citi date în timp real privind funcționarea motorului. Viteza de citire va diferi în funcție de protocolul disponibil pe acel autoturism, adică se pot citi până la 9 parametrii pe secundă în cazul protocolului ISO 14230 ( KWP2000 ), iar în cazul protocolului CAN( ISO 15765) vom putea citi până la 50 de parametrii pe secundă.

Exemplu de mesaj

După cum am precizat mai sus în această lucrare, producătorul de autovehicule nu este obligat să implementeze toate serviciile și toți parametrii disponibili în standardul ISO. Pentru aceasta a trebuit să fac o identificare a ceea ce este și ceea ce nu este implementat. În continuare vă voi prezenta modul în care se face indentificarea:

Prima dată trimit un mesaj de interogare către ECU de forma ”010020406080A0”, iar acest cod se traduce astfel: – primii 2 octeți sunt serviciul pe care eu îl cer, iar apoi urmatoarea secvență de octeți mă ajută sa indentific PID-urile disponibile. Standardul în care sunt prezentate PID-urile presupune împarțirea acestora în 6 intervale din 20 in 20hex.

Dupa primirea raspunsului de la ECU care poate fi de forma ”4100BE3EB81120A001C001” ( Interpretare: 41 este raspunsul primit de la ECU 41=01+40; urmatorul 00 ne spune că următorii 8 octeți aparțin PID-urilor de la 0 la 20; apoi octeții 13 și 14 ne spun că din acel loc ne vor fi prezentați PID-urile care fac parte din intervalul 20-40 )

Următorul pas constă în trasformarea celor 8 octeți din fiecare răspuns într-un șir de biți (BE devine 10111110) iar unde avem 1 înseamna că ECU poate afișa o informație privin acel PID, iar 0 presupune ca acel PID nu este implementat.

După identificarea PID-urilor disponibile voi transforma fiecare pozitie a PID-ului într-o formă hexazecimală și voi căuta numele parametrului în fișierul PID_Name.txt pentru a face mai pe înțelesul utilizatorului ce parametru va citi.

Pentru a afla valoarea fiecarui parametru voi interoga pe rând cu PID-ul aferent acestuia. Un exemplu de astfel de interogare: 010C- turații motor, 010A-presiunea combustibilului în rampă, 010D-viteza autovehiculului.

Pasul următor presupune așteptarea unui raspuns provenit de la ECU de forma 410C237A, voi calcula valoarea rotațiilor pe minut după o formula definită de standard. Pentru rotațiile pe minut formule este ((A*256)+B)/4, A și B reprezentând cei 2 octeții din răspuns. În exemplul nostru valoarea va fi: ((35*256)+122)/4 care înseamnă 2270 de rotații pe minut. După calcularea valorii se va afișa pe ecran valoarea acesteia în dreptul PID-ului corespunzător.( Anexa3 )

Figura 3.3[17] Exemplu de mesaj pentru Serviciul #01

Cod + Interfața aferentă

Aceasta este partea din interfață alocată pentru serviciul #01. În partea stângă avem 2 butoane. Primul buton ”Read” este folosit pentru citirea parametrilor pe care ECU le poate afișa, iar mesajul se va afișa în listbox-ul din partea stângă. Apoi prin apăsarea butonului ”Calculate/Read” va calcula valoarea PID-urilor dorite și le va afișa în listbox-ul din partea dreaptă.

În continuare vă voi prezenta codul aferent acestei interfețe:

% – Executes on button press in b1.

function b1_Callback(hObject, eventdata, handles)

S01_PID_Name2

aceasta este funcția asociată butonului ”Read” și apelează funcția S01_PID_Name2 care va completa listbox-ul din partea stangă.

Asemănătoare este și funcția pentru butonul ”Read/Calculate”.

Cod pentru citirea parametrilor – Funcția S01_PID_Name2 ( pentru mai multe detalii asupra codului consultați Anexa 1 ).

pid_inf=serial_f2('01002040')

if strcmp(pid_inf(1:2),'41')

h=waitbar(1/3);

for q=3:10:length(pid_inf)

if(strcmp(pid_inf(1:6),'NODATA')||(strcmp(pid_inf(q:q+1),'AA')))

continue

else

Cell_PID{idx1}=pid_inf(q+2:q+9);

idx1=idx1+1;

end

.

.

for i=1:3

.

.

for j=1:32

if c(j)==1

fid = fopen('PID_Name.txt');%fac citirea parametrilor din PID_Name.txt

tline = fgetl(fid);

while ischar(tline)

if tline(1:2)==dec2hex(j+vector_PID(i),2)

set(handles.list1,'String', strr3);

pid_id(idx3) = {tline(1:2)};

Cod pentru calculul parametrilor – Funcția S01_PID_Value ( Anexa1 )

pid_id = handles.data.pid_id;

list_entries = get(handles.list1,'String');

index_selected = get(handles.list1,'Value');

button_state = get(hObject,'Value');

while(button_state)

for i=1:length(index_selected)

idx(i)=index_selected(i);

pid_id(idx(i))

switch hex2dec(pid_id(idx(i)))

.

.

case 12

pid_inf = serial_f('010c');

pid_values(idx(i))={((hex2dec(pid_inf(5:6))*256)+hex2dec(pid_inf(7:8)))/4};

%pentru mai multe detalii asupra formulelor de calcul consultați punctul [17] din bibliografie

.

.

Serviciul #01 PID 01 – Informații privind existența unor componente și dacă martorul de bord MIL este aprins și câte DTC-uri sunt memorate

Acesta face parte din serviciul #01 dar este puțin mai special deoarece cuprinde o mai mare cantitate de informație decât celelalte PID-uri din acest serviciu și de aceea am ales să îl tratez separat. Rolul acestui PID este de a testa anumite componente și să afișeze la final rezultatul dacă acestea există în dotarea autovehiculului și funcționează corespunzător.

După apăsarea butonului ”Read” se trimite o interogare către ECU de forma ”0101” și se va astepta raspunsul de forma ”4101006E8080” și se va face interpretarea celor 4 octeți și completarea cu informațiile necesare coloanelor din Figura3.2.1.4

Cod: (Anexa1)

pid_inf=serial_f('0101')

if pid_inf(1:4)=='4101'

idx=1;

t=hex2dec(pid_inf(5:12));

c = bitget(uint32(t), 32:-1:1);

y=sprintf('%o',c); %convertesc variabila c intr-o variabilă de tip string

strr{idx}=bin2dec(y(2:8));

set(handles.text22,'String', strr);

.

.

Serviciul#02 – Cerere pentru date stop cadru pentru trenul de rulare

Descriere funcțională

Acest serviciu este utilizat pentru a afișa anumiți parametrii ai motorului înregistrați în momentul în care a apărut un defect. Se face un stop cadru parametrilor setați de fabricant, iar atunci când apare defectul acești parametrii au rolul de a-l ajuta pe cel care efectuează reparația să pună un diagnostic cât mai bun și să rezolve intr-un timp cât mai scurt defectul. Numărul parametrilor înregistrați depinde în cea mai mare parte de performanțele ECU.

Exemplu de mesaj

Pentru a afla toate informațiile puse la dispoziție de către acest serviciu, prima dată se face o interogare de forma ”020200” pentru a identifica ce DTC a cauzat defecțiunea, iar răspunsul va arăta asfel ”4202000130” ultimii 2 octeți putând fi diferiți în funcție de ce defecțiune s-a detectat. În urmatoul pas se poate face o interogare de forma ”020C0005000400”, iar răspunsul va arăta ca cel din Tabelul3.1.

Cod + Interfața aferentă ( Anexa1 )

Serviciul#03 – Diagnoza codurilor de eroare stocate în memoria ECU

Descriere funcțională

Scopul acestui serviciu este să activeze echipamentul de test extern pentru a obține informații asupra DTC-urilor confirmate. Cu acest serviciu se poate diagnostica atât erorile apărute în memoria calculatorului central cât și cele apărute la alte calculatoare prezente pe acel autovehicul.

DTC-urile sunt transmise în serii de cate 2 octeți pentru fiecare DTC. Primul niblu (cel din stânga) indică dacă DTC-ul aparține fie sistemului de propulsie, șasiu, corp sau rețea. Următorul niblu va preciza tipul erorii. Ultimii 3 octeți formează codul erorii care va fi căutat în fișierul DTC.txt și va afișa numele erorii. Exemple de DTC-uri sunt prezentate în Anexa2.

Exemplu de mesaj

Primul pas este de a executa o interogare simplă de forma ”03”, iar noi vom primi un răspuns de forma”43010443”. Pe pozițiile 3 și 4 din șir ni se spune câte DTC-uri sunt stocate iar în continuare vor fi afișate, fiecare cod de eroare având 2 octeți ca și dimensiune.

Menționez că erorile sunt stocate în acest serviciu dupa 3 cicluri de pornire-oprire motor.

Cod + Interfața aferentă ( Anexa1 )

Figura 3.8 Interfața Serviciului#03

Serviciul#04- Ștergerea/Resetarea codurilor de eroare

Descriere funcțională

Acest serviciu este folosit pentru ștergerea/resetarea codurilor de eroare memorate sau în curs de memorare (Serviciul#07) precum și ștergerea informațiilor asociate (Serviciul#02). Acesta rulează doar în anumite condiții și anume că mașina nu trebuie să ruleze. Altfel va apărea un cod de eroare prin care ni se specifică în documentație că motorul trebuie oprit înainte de ștergerea erorilor.

Exemplu de mesaj

Serviciul#04 se va folosi atunci când există coduri de eroare confirmate de către serviviul#03 sau #07 și reparația a fost efectuată, altfel chiar dacă vom șterge erorile, acestea vor reapărea dacă problema mașinii nu s-a rezolvat. Pentru a șterge erorile se transmite octetul ”04” și se așteaptă raspunsul de validare ”44” pentru confirmarea că au fost șterse toate erorile și se va mai face incă o dată citirea de pane cu serviciul#03. Dacă aceste pane nu au dispărut atunci trebuie din nou intervenit asupra problemelor de către mecanic. În caz că răspunsul va fi de forma ”7F0422” asta înseamnă ori că motorul nu este oprit ori că a apărut o problemă în timpul ștergerii defectelor și operațiunea trebuie reluată.

Cod + Interfața aferentă

În interfața programului acest serviciu este reprezentat printr-un singur buton care la apăsare va emite o interogare ca cea exemplificată la punctul 3.2.4.2. Pentru partea de cod, aceasta se va găsi în Anexa1.

Serviciul #05 – Cerere de monitorizare a senzorilor de oxigen

Descriere funcțională

Acest serviciu este utilizat pentru raportarea stării de funcționare a senzorului de oxigen (sonda lambda) sau diagnosticarea deficiențelor amestecului aer-combustibil. Acest serviciu nu este suportat de rețeaua CAN. Funcționalitatea serviciului #05 este implementată în Serviciul #06.

Serviciul #06 – Cererea rezultatelor testelor de monitorizare pentru sisteme specifice

Descriere funcțională

Scopul acestui serviciu este de a permite accesul la rezultatele diagnosticării in-bord și a testelor efectuate asupra componentelor sau sistemelor care sunt monitorizate în mod continuu sau discontinuu, citirea rezultatelor testelor efectuâdu-se asupra diferitelor componente, ce au impact direct asupra emisiilor poluante. Rezultatele cuprind de obicei o valoare minimă, una maximă și nivelul înregistrat în momentul citirii.

Producatorul vehiculului este responsabil de asocierea unor titluri testelor care sunt făcute în exclusivitate pentru acea marcă și sunt în afara celor prezentate în standard. Ultimele valori ale testelor valide (rezultate) sunt reținute, chiar pentru mai multe cicluri de pornire, până când sunt înlocuite cu valori mai recente ale testelor.

Dacă un test nu a fost efectuat complet nici măcar o dată de când s-a efectuat o ștergere/resetare sau de când a fost deconectată bateria, atunci valorile minime și maxime ale acelui parametru vor fi setate la valoarea zero ($0000).

Exemplu de mesaj

Se va face o interogare asemenea serviciului#01 adică se va trimite secvența de octeți ”060020406080A0” și se va aștepta un răspuns care să cuprindă toate cererile. Pasul următor presupune parcurgerea din 9 în 9 octeți a răspunsului și interpretarea conform standardului. Primii 3 octeți din fiecare șir de 9 presupune căutarea informațiilor în fișierele de tip .txt după cum urmează: OBDMID_List.txt, Test_ID.txt, Unit_ID.txt. În primul fișier se găsește numele senzorului testat, în cel de-al doilea se găsește numele testului care a fost efectuat, iar în cel de-al treilea fișier se găsește unitatea de masură pentru testul în cauză.

Cod + Interfața aferentă

Partea de cod se află în Anexa1 deoarece este destul de mare ca număr de linii și menționez că acest serviciu a fost cel mai greu de implementat.

Serviciul #07 – Cerere a codurilor de eroare ce nu au fost memorate

Descriere funcțională

Scopul acestui serviciu este de a permite echipamentului extern de testare să obțină coduri de eroare înainte ca mașina să îndeplineasca ciclul pentru memorarea acestora, erorile fiind obținute în timpul ciclului de condus actual sau al precedentului. Serviciul $07 folosește aceleași DTC-urile ca serviciul#03 dar este independent de acesta. Scopul acestor date este să vină în ajutorul tehnicianului după o reparație de vehicul și după ștergerea informațiilor în urma diagnosticării, prin raportarea rezultatelor testelor după un singur ciclu de condus. Dacă testul a eșuat în timpul ciclului de condus, DTC-ul asociat cu acel test va fi raportat. Rezultatele testelor raportate de către acest serviciu nu indică în mod necesar o defecțiune gravă privind o componentă sau a sistemului, ci poate fi și o mică eroare apărută în timpul rulajului aceasta putând dispărea tot în timpul acelui rulaj. Dacă rezultatele testului indică un eșec după o perioada adițională de condus, atunci MIL-ul va fi iluminat și DTC-ul se va seta și se va raporta prin Serviciul#03, indicând o componentă sau un sistem defect. Acest serviciu poate fi utilizat întotdeauna pentru a cere rezultatele ultimului test, independend de setarea DTC-ului.

În softul prezentat acest serviciu rulează în același timp cu serviciul#03 pentru o diagnosticare mai rapidă și mai eficientă.

Exemplu de mesaj

În primul rând se trasmite către ECU mesajul ”07” și se așteaptă răspunsul care poate fi de forma ”4700” care semnifică inexistența vreunui cod de eroare sau putem recepționa un mesaj de forma ”470204330122”.

Acest exemplu reprezintă un cod de eroare: P0143, iar numele acestuia este ”O2 Sensor Circuit Low Voltage Bank 1 Sensor 3”.

Cod + Interfața aferentă

Figura 3.11 Interfața pentru Serviciul#07

Serviciul #08 – Cerere pentru controlul sau modificarea anumitor parametrii ai componentelor

Descriere funcțională

Acest serviciu presupune modificarea unor parametrii ai componentelor. Acesta poate influența bunul mers al autoturismului sau al componentelor acestuia deoarece dacă modificăm vreun parametru fără să fim autorizați sau fără să cunoaștem ce presupune modificarea adusă de noi atunci există un risc foarte mare de apariție a unei defecțiuni.

Acest serviciu nu a fost implementat.

Serviciul #09- Cerere informații generale privind vehiculul

Descriere funcțională

Scopul acestui serviciu este de a activa echipamentul extern de testare pentru a cere în mod explicit informații specifice vehiculului , precum numărul de verificare al mașinii (VIN) și ID-ul calibrării precum și afișarea IUPT ( acest mod numără de câte ori s-au efectuat anumite condiții cum ar fi câte porniri a efectuat mașina de la ultima rescriere de soft sau câte regenerări privind filtrul de particule s-au efectuat ). O parte din aceste informații pot fi necesare în mod regulat iar altele pot fi raportate ca și dorite într-un format standard dacă este suportat de către producătorul mașinii. În continuare vă voi prezenta fiecare mod în parte cum a fost implementat.

Serviciul#09 PID02 – Cerere VIN

Toate autovehiculele care sunt produse astăzi au un număr unic de identificare înscris pe șasiu, acesta dându-ne cateva informații despre mașină dacă este descifrat conform producătorului.

Acest mod funcționează ca și celelalte. Se transmite interogarea către ECU de forma ”0902”, iar răspunsul ar putea fi ca cel prezentat în tabelul de mai jos Tabelul3.2.9.2. După primirea răspunsului începând cu octetul 4, din octet în octet, se face corelația între valoarea acestuia și valoarea din tabela ASCII asociată.

Interfața acestui mod și codul aferent acestui mod sunt prezentate în urmatoarele linii:

Figura 3.12 Interfață VIN

pid_inf = serial_f2('0902')

if(pid_inf(1:2)=='7F')

set(handles.text13,'String', 'Negative Response! Maybe Serv #0902 is not availble');

else

VIN=[];

for i=7:2:length(pid_inf)

VIN = strcat(VIN,char(hex2dec(pid_inf(i:i+1))));

set(handles.text13,'String', ['VIN: ' VIN]);

end

end

Cerere ID Calibrare

Autovehiculele moderne au o componenta centrală ECU pe care se află instalat un soft și o calibrare. Făcând o mică legatură soft-ul poate fi privit ca sistemul de operare Windows, iar calibrarea este asemenea programelor instalate (Ex: Microsoft Office). De obicei pe parcursul dezvoltării partea care se schimbă cel mai mult este calibrarea, partea soft nesuferind prea multe modificări. În continuare voi prezenta modul prin care se face această cerere.

Primul pas este să trimitem o interogare de forma ”0904” , iar raspunul va fi de forma”490402…” și va avea lungimea de 35 de octeți. Un exemplu este și în Tabelul3.2.9.3. Decodarea mesajului se va face asemănător ca la modul VIN adică se va lua de la octetul 4 și se va asocia cu tabela ASCII fiecare octet.

Cod:

nr=1;

strr{nr}='Calibration IDs : ';

set(handles.list4,'String', strr);

for m=7:32:32*hex2dec(pid_inf(5:6))

VIN=pid_inf(m:m+31);

new_line=[];

for n=1:2:length(VIN)

new_line = strcat(new_line,char(hex2dec(VIN(n:n+1))));

end

Interfața va fi prezentată în următorul subcapitol deoarece aceste 2 moduri ”împart” aceeași parte din interfață.

Numărul de Verificare al Calibrării

Acest mod este asemănător cu cel de dinainte singurul lucru care diferă este modul în care este interpretat mesajul recepționat. Aici se va interoga cu ”0906”, iar răspunsul poate fi de forma ”4906021791BC8216E062BE”. Analiza va incepe tot de la octetul 4, din 4 în 4 octeți, numai că de data aceasta mesajul se va afișa sub forma în care s-a recepționat și nu se va mai face o corespondență cu tabela ASCII. La acest mod mai poate exista un tip de răspuns și acela ”7F0978” care semnifică faptul că serviciul este indisponibil sau a existat o eroare în timpul citirii ceea ce înseamnă că trebuie repetată operația de citire. Interfața acestuia pentru citirea CVN și pentru citirea ID-ului Calibrării se afla în figură

Cod pentru citirea Numărului de Verificare al Calibrării

if pid_inf(1:4)=='7F09'

strr{nr}='Negative Response';

set(handles.list4,'String',strr);

else

for j=7:8:8*hex2dec(pid_inf(5:6))

strr{nr}=pid_inf(j:j+7);

set(handles.list4,'String', strr);

nr=nr+1;

end

end

IUPT

Acest serviciu numără de câte ori s-au executat anumite acțiuni, acesta fiind util pentru a observa dacă anumite funcționalități funcționează corect. Acest mod nu a fost implementat.

Comunicația cu autovehiculul

În continuare am prezentat modul în care se realizează comunicația cu calculatorul central al autovehiculului adică modul prin care informația se transmite de la laptop-mufa RS232-integrat ELM327-Mufa OBD II-ECU și invers.

Dacă introduc în linia de comandă linia ”0100”, ELM327 ar trebui să afișeze mesajul ”SEARCHING”. Prin apariția acestui mesaj de ”întâmpinare” ELM327 caută protocolul disponibil pe acel autovehicul(CAN sau KWP). După terminarea identificării protocolului existent ELM327 ar trebui să afișeze o serie de numere hexazecimale de forma ” 4100BE1FB810” – 41 semnifică răspunsul vehiculului (01+40); 00 apare în răspuns deoarece indică intervalul de PID-uri pe care ne interesează să il citim; BE1FB810 reprezintă valoarea răspunsului interogării transmise de către utilizator și este pe 4 octeți în exemplul prezentat. Dimensiunea răspunsului poate diferi de la un serviciu la altul.

Un alt exemplu este de a vedea propriu-zis ce valoare are un PID în timpul rulajului. Am ales ca exemplu temperatura aerului în admisie. Aceasta are valoarea PID-ului 0F și face parte din Serviciul#01, iar ca mod de interogare pentru aflarea valorii se face astfel; se transmite ”010F” iar răspunsul va fi pe un octet și poate fi de forma ”410F47” care se traduce la fel ca în paragraful anterior numai că va diferi răspunsul deoarece acesta se calculează după o formulă explicată în Anexa3 a acestei lucrări. În cazul nostru temperatura este de 31 de grade Celsius.

Mai jos este afișat codul prin care am rezolvat citirea datelor de la autovehicul:

function serial_out = serial_f(serial_in)

s = serial('COM1');

set(s,'BaudRate',38400,'Terminator',{'CR' 'CR'},'TimerPeriod',1);

fopen(s)

fprintf(s,serial_in) % AT SP 0

pause(0.02)

fscanf(s);

[data_s01,count,msg] = fscanf(s);

data_s01 = strtrim(data_s01);

fclose(instrfindall)

Pe parcursul realizării soft-ului prezentat în această lucrare am intâlnit diverse probleme, una dintre ele fiind la citirea rezultatelor pentru anumite servicii deoarece ELM327 nu mai transmitea informația sub forma unui șir de numere hexazecimale. Aceste probleme au fost intâmpinate spre exemplu la serviciul#09, la serviciul #03 pentru că mesajul recepționat era foarte mare, iar ELM327 afișa răspunsul pe mai multe linii ca în exemplul următor:

>0902

014 //aici imi sunt afișați numarul de octeți pe care îi conține răspunsul

0: 49 02 01 31 44 34

1: 47 50 30 30 52 35 35

2: 42 31 32 33 34 35 36

Datorită acestui tip de răspuns codul prezentat anterior nu reușea sa interpreteze corect răspunsul și prin urmare am introdus câteva linii de cod în plus pentru a reduce impactul asupra bunei funcționări a programului.

if length(a)==3

x=hex2dec(a);

if(mod(x-6,7)~=0)

cicluri_for=(x-6)/7+1;

else

cicluri_for=(x-6)/7;

end

m=fscanf(s,'%s');

a=m(3:14);

for i=1:cicluri_for

b=fscanf(s,'%s');

a=strcat(a,b(3:16));

end

Acum după ce problema a fost rezolvată codul este afișat sub o forma normală: ”4902013144344750303052353542313233343536”.

Recomandări privind utilizarea aplicației

Pentru o mai bună utilizare a programului ”Unealtă de analiză și diagnosticare”, în continuare vă este prezentat modul corespunzător de exploatare a acesteia.

Pași:

Rulați fișierul Scantool_Main

Porniți motorul

Apăsați pe butonul ”Initialization” prezentat în Figura4.1

Figura 4.1 Mod de utilizare interfață – 1

– dacă apare mesajul ”Communication Ready” puteți continua utilizarea oricărui serviciu doriți prin apăsarea unui singur click pe butonul ”Read” al fiecărui serviciu. În caz că mesajul apărut este ”Communication Failed” atunci trebuie încercat din nou deoarece se poate să fi apărut vreo problemă în timpul interogării iar ECU să nu poată să răspundă cerințelor dumneavoastră.

Pentru Serviciul#01: Dacă doriți să citiți valoarea anumitor parametrii, iar după apăsarea butonului ”Read” apar unele locații goale ca în imaginea de mai jos, vă rog să le deselectați înainte de a apăsa pe butonul ”Calculate/Stop”

După apăsarea butonului ”Calculate/Stop” ELM327 va incepe achiziția de date și pentru a opri această achiziție trebuie apăsat din nou pe același buton și se va astepta până ce ultimul PID își va schimba valoarea.

Pentru Serviciul#09(Mod:Citirea Numărului Calibrării): Dacă după apăsarea butonului ”Read” aferent acestui serviciu apare mesajul ”Negative Response”, cum este ilustrat și în Figura4.3, se va proceda astfel: se va aștepta aproximativ 5 secunde după care se va încerca din nou apăsarea butonului ”Initialization” sau butonul ”Read” al Serviciului#09 pentru citirea Numărului Calibrării. Acest mesaj apare datorită unei erori depistate în timpul achiziției acestei informații.

Figura 4.3 Mod de utilizare interfață – 3

Concluzii

Dezvoltarea lumii autovehiculelor nu ar fi posibilă fără prezența Serviciului de diagnosticare. Evoluția domeniului auto constă în evoluția modului de transmitere a mesajelor, tramelor, provenite de la ECU. O evoluție în acest sens ar reprezenta-o îmbunătățirea magistralei CAN, deoarece odată cu mărirea numărului funcționalităților prezente pe autovehicul vom avea nevoie de o bandă mai largă, atât din punct de vedere al vitezei cât și al cantității de informație transmise.

O altă îmbunătățire ar putea veni din partea serviciului de diagnosticare, adică în loc de OBD II să se folosească OBD III, care momentan este în faza de implementare. OBD III presupune transmiterea tuturor informațiilor privind funcționarea autovehiculului prin satelit direct producătorului mașinii sau unor anumite service-uri pentru ca detecția defectelor sau anomaliilor să se efectueze mult mai repede, iar rezolvarea problemelor să se facă cât mai eficient.

Pentru softul prezentat în această lucrare pot spune că se mai pot face aumite evoluții. Una dintre ele fiind implementarea serviciilor #08 si #0908( subcapitolul 3.2.9.5 ) și pe viitor renunțarea la laptop și la partea hardware prezentată în Figura2.8 și transformarea acestora într-o unitate mult mai mică și compactă care să emită informația wireless, iar partea software să fie portată pe platformele mobile pentru a ne putea conecta direct prin bluetooth sau wi-fi.

Bibliografie

[1] http://sourceforge.net/projects/scantool/

[2] http://elmelectronics.com/DSheets/ELM327DS.pdf

[3]http://www.e-automobile.ro/categorie-electronica/11-protocoale-comunicatie-automobile.html

[4] http://e-automobile.ro/categorie-electronica.html?start=10

[5]http://www.freescale.com/files/training_pdf/20451_BUS_COMM_WBT.pdf?lang_cd=en

[6]http://stst.elia.pub.ro/news/RC/Teme_RC_IVA_2012_13/3_NeaguVi_LangaMi_CSMACD%20DQDB.pdf

[7] Alexandru VASILE, Irina Bristena BACÎȘ, Bazele Electronicii Auto, ISBN 978-606-551-007-4, Editura Cavallioti, București 2013

[8] http://ro.wikipedia.org/wiki/Vehicul

[9] www.google.ro/image

[10] Andrew S. Tanenbaum, Rețele de calculatoare, ISBN: 973-97706-3-0

[11] S. Cojocaru,C. Radoi, Șt. Stancescu  "Network parameters optimization in CAN-Network design" , Procedings of the 7th International Conference Communications 2008, Bucharest , June 5-7 ISBN 978-606-521-008-0

[12] http://stst.elia.pub.ro/news/RC/labs/rc2.pdf

[13] Bypass CANalyzer.pdf , ISPAS Gabriel

[14] elmelectronics.com/DSheets/ELM327DS.pdf

[15] http://ro.wikipedia.org/wiki/MATLAB

[16] SAE J1979_AffirmationBallot_APR032007.pdf

[17] http://en.wikipedia.org/wiki/OBD-II_PIDs

[18] http://www.e-automobile.ro/categorie-diagnoza/5-obd-diagnoza-auto.html

[19] vetsoft.googlecode.com/svn-history

Anexa1

În această anexă mi-am propus să vă prezint majoritatea codului:

serial_f2.m Scantool_main.m(61/313 linii)

S01_PID_Name2.m S01_PID_Value.m(50/458)

S02_Freeze_Frame.m S03_and_07_Stored_and_Pending_DTC.m

S06_Request_OBDMID.m(part1) S06_Request_OBDMID.m(part2)

S01_01_Monitor_Status.m

Anexa2

În această anexă vă sunt prezentate câteva coduri de eroare împreună cu semnificația acestora:

P250A – Engine Oil Level Sensor Circuit

P250B – Engine Oil Level Sensor Circuit Range/Performance

P250C – Engine Oil Level Sensor Circuit Low

P250D – Engine Oil Level Sensor Circuit High

P250E – Engine Oil Level Sensor Circuit Intermittent/Erratic

P250F – Engine Oil Level Too Low

P2510 – ECM/PCM Power Relay Sense Circuit Range/Performance

P2511 – ECM/PCM Power Relay Sense Circuit Intermittent

P2512 – Event Data Recorder Request Circuit/ Open

P2513 – Event Data Recorder Request Circuit Low

P2514 – Event Data Recorder Request Circuit High

P2515 – A/C Refrigerant Pressure Sensor “B” Circuit

P2516 – A/C Refrigerant Pressure Sensor “B” Circuit Range/Performance

P2517 – A/C Refrigerant Pressure Sensor “B” Circuit Low

P2518 – A/C Refrigerant Pressure Sensor “B” Circuit High

P2519 – A/C Request “A” Circuit

P251A – PTO Enable Switch Circuit/Open

P251B – PTO Enable Switch Circuit Low

P251C – PTO Enable Switch Circuit High

P251D – PTO Engine Shutdown Circuit/Open

P251E – PTO Engine Shutdown Circuit Low

P251F – PTO Engine Shutdown Circuit High

P2520 – A/C Request “A” Circuit Low

P2521 – A/C Request “A” Circuit High

P2522 – A/C Request “B” Circuit

P2523 – A/C Request “B” Circuit Low

P2524 – A/C Request “B” Circuit High

P2525 – Vacuum Reservoir Pressure Sensor Circuit

P2526 – Vacuum Reservoir Pressure Sensor Circuit Range/Performance

P2527 – Vacuum Reservoir Pressure Sensor Circuit Low

P2528 – Vacuum Reservoir Pressure Sensor Circuit High

P2529 – Vacuum Reservoir Pressure Sensor Circuit Intermittent

P252A – Engine Oil Quality Sensor Circuit

P252B – Engine Oil Quality Sensor Circuit Range/Performance

P252C – Engine Oil Quality Sensor Circuit Low

P252D – Engine Oil Quality Sensor Circuit High

P252E – Engine Oil Quality Circuit Intermittent/Erratic

P252F – Engine Oil Level Too High

P2530 – Ignition Switch Run Position Circuit

P2531 – Ignition Switch Run Position Circuit Low

P2532 – Ignition Switch Run Position Circuit High

P2533 – Ignition Switch Run/Start Position Circuit

P2534 – Ignition Switch Run/Start Position Circuit Low

P2535 – Ignition Switch Run/Start Position Circuit High

P2536 – Ignition Switch Accessory Position Circuit

P2537 – Ignition Switch Accessory Position Circuit Low

P2538 – Ignition Switch Accessory Position Circuit High

P2539 – Low Pressure Fuel System Sensor Circuit

P253A – PTO Sense Circuit/Open

P253B – PTO Sense Circuit Range/Performance

P253C – PTO Sense Circuit Low

P253D – PTO Sense Circuit High

P253E – PTO Sense Circuit Intermittent/Erratic

P253F – Engine Oil Deteriorated

Anexa3

În această anexă vă sunt prezentate câteva formule de calcul pentru valorile PID-urilor, dimensiunea în octeți a răspunsului pentru fiecare PID plus multe alte informații:

Bibliografie

[1] http://sourceforge.net/projects/scantool/

[2] http://elmelectronics.com/DSheets/ELM327DS.pdf

[3]http://www.e-automobile.ro/categorie-electronica/11-protocoale-comunicatie-automobile.html

[4] http://e-automobile.ro/categorie-electronica.html?start=10

[5]http://www.freescale.com/files/training_pdf/20451_BUS_COMM_WBT.pdf?lang_cd=en

[6]http://stst.elia.pub.ro/news/RC/Teme_RC_IVA_2012_13/3_NeaguVi_LangaMi_CSMACD%20DQDB.pdf

[7] Alexandru VASILE, Irina Bristena BACÎȘ, Bazele Electronicii Auto, ISBN 978-606-551-007-4, Editura Cavallioti, București 2013

[8] http://ro.wikipedia.org/wiki/Vehicul

[9] www.google.ro/image

[10] Andrew S. Tanenbaum, Rețele de calculatoare, ISBN: 973-97706-3-0

[11] S. Cojocaru,C. Radoi, Șt. Stancescu  "Network parameters optimization in CAN-Network design" , Procedings of the 7th International Conference Communications 2008, Bucharest , June 5-7 ISBN 978-606-521-008-0

[12] http://stst.elia.pub.ro/news/RC/labs/rc2.pdf

[13] Bypass CANalyzer.pdf , ISPAS Gabriel

[14] elmelectronics.com/DSheets/ELM327DS.pdf

[15] http://ro.wikipedia.org/wiki/MATLAB

[16] SAE J1979_AffirmationBallot_APR032007.pdf

[17] http://en.wikipedia.org/wiki/OBD-II_PIDs

[18] http://www.e-automobile.ro/categorie-diagnoza/5-obd-diagnoza-auto.html

[19] vetsoft.googlecode.com/svn-history

Anexa1

În această anexă mi-am propus să vă prezint majoritatea codului:

serial_f2.m Scantool_main.m(61/313 linii)

S01_PID_Name2.m S01_PID_Value.m(50/458)

S02_Freeze_Frame.m S03_and_07_Stored_and_Pending_DTC.m

S06_Request_OBDMID.m(part1) S06_Request_OBDMID.m(part2)

S01_01_Monitor_Status.m

Anexa2

În această anexă vă sunt prezentate câteva coduri de eroare împreună cu semnificația acestora:

P250A – Engine Oil Level Sensor Circuit

P250B – Engine Oil Level Sensor Circuit Range/Performance

P250C – Engine Oil Level Sensor Circuit Low

P250D – Engine Oil Level Sensor Circuit High

P250E – Engine Oil Level Sensor Circuit Intermittent/Erratic

P250F – Engine Oil Level Too Low

P2510 – ECM/PCM Power Relay Sense Circuit Range/Performance

P2511 – ECM/PCM Power Relay Sense Circuit Intermittent

P2512 – Event Data Recorder Request Circuit/ Open

P2513 – Event Data Recorder Request Circuit Low

P2514 – Event Data Recorder Request Circuit High

P2515 – A/C Refrigerant Pressure Sensor “B” Circuit

P2516 – A/C Refrigerant Pressure Sensor “B” Circuit Range/Performance

P2517 – A/C Refrigerant Pressure Sensor “B” Circuit Low

P2518 – A/C Refrigerant Pressure Sensor “B” Circuit High

P2519 – A/C Request “A” Circuit

P251A – PTO Enable Switch Circuit/Open

P251B – PTO Enable Switch Circuit Low

P251C – PTO Enable Switch Circuit High

P251D – PTO Engine Shutdown Circuit/Open

P251E – PTO Engine Shutdown Circuit Low

P251F – PTO Engine Shutdown Circuit High

P2520 – A/C Request “A” Circuit Low

P2521 – A/C Request “A” Circuit High

P2522 – A/C Request “B” Circuit

P2523 – A/C Request “B” Circuit Low

P2524 – A/C Request “B” Circuit High

P2525 – Vacuum Reservoir Pressure Sensor Circuit

P2526 – Vacuum Reservoir Pressure Sensor Circuit Range/Performance

P2527 – Vacuum Reservoir Pressure Sensor Circuit Low

P2528 – Vacuum Reservoir Pressure Sensor Circuit High

P2529 – Vacuum Reservoir Pressure Sensor Circuit Intermittent

P252A – Engine Oil Quality Sensor Circuit

P252B – Engine Oil Quality Sensor Circuit Range/Performance

P252C – Engine Oil Quality Sensor Circuit Low

P252D – Engine Oil Quality Sensor Circuit High

P252E – Engine Oil Quality Circuit Intermittent/Erratic

P252F – Engine Oil Level Too High

P2530 – Ignition Switch Run Position Circuit

P2531 – Ignition Switch Run Position Circuit Low

P2532 – Ignition Switch Run Position Circuit High

P2533 – Ignition Switch Run/Start Position Circuit

P2534 – Ignition Switch Run/Start Position Circuit Low

P2535 – Ignition Switch Run/Start Position Circuit High

P2536 – Ignition Switch Accessory Position Circuit

P2537 – Ignition Switch Accessory Position Circuit Low

P2538 – Ignition Switch Accessory Position Circuit High

P2539 – Low Pressure Fuel System Sensor Circuit

P253A – PTO Sense Circuit/Open

P253B – PTO Sense Circuit Range/Performance

P253C – PTO Sense Circuit Low

P253D – PTO Sense Circuit High

P253E – PTO Sense Circuit Intermittent/Erratic

P253F – Engine Oil Deteriorated

Anexa3

În această anexă vă sunt prezentate câteva formule de calcul pentru valorile PID-urilor, dimensiunea în octeți a răspunsului pentru fiecare PID plus multe alte informații: