Technikerarbeit 2005/2006 OBD2 - Diagnosegerät

Transcription

Technikerarbeit 2005/2006
OBD2 - Diagnosegerät
Von:
Dominik Beutner
Untere Weinhalde 5
78333 Stockach
Betreuer:
Herr Sperling
Fachschule für Technik
FTED2
Dokumentation V1.0
Inhaltsverzeichnis:
1. Eidesstattliche Erklärung ................................................................... 3
2. Einführung
2.1
2.2
2.3
2.4
Projektidee ................................................................................... 4
Hintergrundwissen zu OBD2........................................................ 4
Projektbeschreibung .................................................................... 9
Umsetzung................................................................................. 10
3. Hardware
3.1 Blockschaltbild........................................................................... 14
3.2 Modifikation des ELEKTOR OBD2/Diagnoseinterface .............. 16
3.3 Schaltpläne ................................................................................ 19
3.4 Spannungsversorgung ............................................................. 21
3.4 LPC 932 ................................................................................... 22
3.5 LC-Display ................................................................................. 25
3.6 Bedientasten ............................................................................. 25
3.7 Serielle Schnittstelle .................................................................. 26
3.8 Umschaltung vom Interface zum LPC / PC ............................... 28
3.9 Stücklisten ................................................................................. 29
3.10 Layouts...................................................................................... 31
4. Senden und Empfangen über das Interface
4.1 Aufbau einer Nachricht .............................................................. 34
4.2 Fehlerdiagnose .......................................................................... 39
5. Software
5.1
5.2
5.3
5.4
Programmstruktur ..................................................................... 41
Headerfiles ................................................................................ 42
Interrupts ................................................................................... 43
Funktionen................................................................................. 43
6. Bedienung des Diagnosegerätes
6.1 Übersicht der Bedienelemente .................................................. 55
6.2 Diagnosefunktionen ................................................................... 56
6.3 Wartungshinweise ..................................................................... 59
.
7. Anhang
7.1 Informationsquellen ................................................................... 59
7.2 Zeitaufwand ............................................................................... 60
7.3 Fazit .......................................................................................... 60
Technikerarbeit 2005/2006 Dominik Beutner
-2-
Dokumentation V1.0
1. Eidesstattliche Erklärung
Hiermit versichere ich, Dominik Beutner, dass die Technikerarbeit
„OBD2 Diagnosegerät“ von mir und ohne unerlaubte Hilfe geplant, entwickelt, und
hergestellt wurde. Textstellen aus Veröffentlichungen wurden mit einem Quellverweis
kenntlich gemacht.
Stockach, den 22.04.2006
Unterschrift:…………………………….
D.Beutner
-3-
Dokumentation V1.0
2. Einführung
2.1
Projektidee
Schon recht früh um genau zu sein im ersten Schuljahr machten uns unsere Lehrer
Herren Sperling und Herr Gross darauf aufmerksam, frühzeitig mit der anstehenden
Technikerarbeit zu beginnen, um später im zweiten Schuljahr genug Spielraum für
die Prüfungen zu haben.
Die ersten Schwierigkeiten fingen schon bei der Ideenfindung an.
Ich wollte ein Projekt durchziehen dass einerseits einem zukünftigen Techniker
gerecht wird, anderseits sollte es auch in einem bewältigbaren Rahmen bleiben.
Dieses abzuschätzen war gar nicht so einfach. Ich wälzte diverse Elektronikkataloge
und machte mir bei der täglichen Autofahrt zur Schule Gedanken, welches Thema
ich aufgreifen könnte. Mir kamen einige Ideen, von einer universellen Fernbedienung
im Rc5 Format bis hin zu einem Netzgerät welches sich mit einem PC fernsteuern
lässt, jedes der Themen schien interessant zu sein. Dann bin ich beim durchstöbern
der bekannten Elektronikzeitschrift „ELEKTOR“, auf einen noch interessanteren
Artikel gestoßen.
Dabei handelt es sich um ein OBD2/Diagnoseinterface mit welchem man mithilfe
eines Pc’s über die Serielle Schnittstelle, Fahrzeugdaten wie Sensorwerte und
eventuelle Fehler aus einem Kraftfahrzeug auslesen kann.
Die Idee für mein Projekt wurde geboren. Ich stellte mir als Aufgabe, ein handliches
autonomes Diagnosegerät mit µ-Controller, anstatt des unhandlichen PC’s zu
realisieren.
2.2
Hintergrundwissen zu OBD2
Ende der achtziger Jahre beschloss der US Bundesstaat Kalifornien schärfere
Emmisionswert- Richtlinien einzuführen, um die Schadstoffbelastungen der großen
Ballungszentren in den Griff zu bekommen. Dazu sollten die Fahrzeuge alle
Emmisionsrelevanten Funktionsgruppen selbst überwachen können. Abweichungen
wie z.B. defekte Lamdasonden, (die eine Veränderung des Abgasgemisches zur
Folge hätten) werden von den Steuergerät/en (ECU) im Fahrzeug erkannt,
gespeichert, und dem Fahrer durch eine gelbe Motorstörungslampe (MIL) Bild 2.1 im
Schalttafeleinsatz angezeigt.
Bild 2.1 MIL
Um die Fehlerursache für den Defekt zu erfahren kann man bei einigen älteren
Fahrzeugen im Diagnosestecker 2 Pins miteinander verbinden, danach blinkt die
MIL, mehrmals in einem bestimmten Rhythmus. Der passende Fehlercode und die
Beschreibung dazu, kann man den Herstellerunterlagen oder dem
Fahrzeughandbuch entnehmen. Das Beispiel bezieht sich auf den Opel Kadett E
BJ 1991 mit dem ich das auch praktisch testen konnte. Nachteilig dabei ist, dass
-4-
Dokumentation V1.0
jeder Fahrzeughersteller sein eigenes Süppchen kochte, und die Diagnose für den
„kleinen Privatmann“ nicht immer so einfach, bei jedem Fahrzeug anwendbar ist. Die
Folge davon, man musste den Fehler durch eine Werkstatt auslesen und beheben
lassen.
Dieses System der frühen Onboard-Diagnostik wurde wegen der immer noch zu
hohen Umweltverschmutzungen und ständig zunehmender Elektronik im KFZ
nachgebessert.
1996 war es so weit, ein neuer Diagnosestandard wurde Pflicht für alle neu
zugelassenen Fahrzeuge in den USA. Spätestens jetzt konnte man nicht mehr so
einfach, wie im Bsp. mit nur einer Verbindungsbrücke im Diagnosestecker sich den
Fehler als Blinkcode anzeigen lassen. Es wurden jedoch Normen erlassen, die es
externen Diagnosegeräten (Offboard-Diagnose) ermöglichen, an alle wichtigen
abgasrelevanten Fahrzeuginformationen wie Sensordaten und im Fehlerfall,
abgespeicherte Fehler über den Diagnosestecker im Fahrzeug auszulesen.
Die OnBoard Diagnose der 2ten Generation, kurz OBD2 wurde geboren.
Die Norm SAE J1979 beschreibt z.B. wie externe Diagnosegeräte Sensorwerte und
den Fehlerspeicher der ECU(s) auslesen und bei Wunsch rücksetzen können.
Für die in Europa zugelassenen PKW’s übernahm man diese Regelung und
verfasste eine Norm, ISO 15031-5 gleichbedeutend der SAE J1979. PKW’s mit
Ottomotor müssen seit 2001 OBD2 kompatibel sein, PKW’s mit Dieselmotor erst ab
2003. Häufig findet man auch andere Abkürzungen die aber dennoch die gleiche
Bedeutung haben. Folgende Bezeichnungen sind zulässig:
OBD2
EOBD
JOBD
On Board Diagnose der 2ten Generation. (verwenden
überwiegend Amerikanischen Fahrzeughersteller)
European On Board Diagnose (wie der Name schon sagt wird er
überwiegend von Europäischen Fahrzeugherstellern verwendet
Japan On Board Diagnose
Für die oben genannten Einführungsjahre gibt es jedoch Ausnahmen.
So können einige Fahrzeuge die nach 1996 in Amerika hergestellt wurden (einige
Opels, bekanntlich von GM), aber in Europa schon vor 2001 zugelassen wurden
OBD2 fähig sein.
Wenn im Fahrzeugschein mindestens Schadstoffklasse 3 und EOBD vermerkt sind
kann man sicher sein, dass das Fahrzeug OBD2 kompatibel ist.
Zur Diagnose stehen 9 so genannte Generic Modi zur Verfügung.
Mode
1
2
3
4
5
6
7
8
9
Bedeutung
zeigt die aktuellen Daten/Sensorwerte
zeigt die freeze Frame Daten
Zeigt gesetzte Fehlercodes
Löscht Fehlercodes und gespeicherte Werte
zeigt Selbsttest-Resultate der Lambdasonden
Selbsttest-Resultate nicht kontinuierlich überwachter Systeme
Fehlercodes kontinuierlich überwachter Systeme
spezieller Kontrollmodus
Fahrzeuginformationen wie z.B. VIN (Fahrzeug SN..)
Tabelle 2.1 Generic Modi
-5-
Dokumentation V1.0
Einige dieser Modi verwenden zusätzlich so genannte PID’s
(ParameterInDentification) Sie verkörpern die einzelnen Sensoren, die bei Bedarf
ausgelesen werden können.
PID
0
1
2
3
4
5
6
07
08
09
0A
0B
0C
0D
0E
0F
10
Bezeichnung
Min
Max
Umrechnung
unterstützte PIDs, Bereich
01 - 20
4 Bytes Bit-codiert
MIL-Status, Anzahl
Fehlercodes,
Überwachungsstatus
Fehlercode, der Freeze
Frame Daten gesetzt hat
Status Einspritzsystem
berechneter Lastwert
MotorKühlwassertemperatur
Kurzzeit Einspritztrimm
Bank 1
Langzeit Einspritztrimm
Bank 1
Bank 2
Langzeit Einspritztrimm
Bank 2
Kraftstoffdruck
4 Bytes, Bit-codiert
2 Byte
2 Bytes, Bit-codiert
0%
offener,
geschlossener Loop
etc.
100% 100/255 %
-40 °C
+215 °C
1 °C mit -40 °C Offset
-100 % (mager)
+99,22 % (fett)
100/128 %
-100 % (mager)
+99,22 % (fett)
100/128 %
-100 % (mager)
+99,22 % (fett)
100/128 %
-100 % (mager)
0 kPa
+99,22 % (fett)
765 kPa
100/128 %
3 kPa pro Bit
0 kPa (absolut)
0 min-1
0 km/h
-64 °
-40 °C
0 g/s
255 kPa (absolut)
16383,75 min-1
255 km/h
63,5 °
+215 °C
655,35 g/s
11
12
13
Absolutdruck Einlaßkanal
Motor-Umdrehungen
Geschwindigkeit
Zündvoreilung
Einlaß-Lufttemperatur
Luftdurchfluß
Absolute
Drosselklappenstellung
Zusatzluftstatus
Einbauort Lambdasonden
0V
1,275 V
0,005 V
14
Ausgangsspannung
Lambdasonde Bank 1,
Sensor 1
Bank 1, Sensor 1
-100 % (mager)
+99,22 % (fett)
100/128 %
0V
1,275 V
0,005 V
15
Ausgangsspannung
Lambdasonde Bank 1,
Sensor 2
Bank 1, Sensor 2
-100 % (mager)
+99,22 % (fett)
100/128 %
0V
1,275 V
0,005 V
16
Ausgangsspannung
Lambdasonde Bank 1,
Sensor 3
Bank 1, Sensor 3
-100 % (mager)
+99,22 % (fett)
100/128 %
0%
1 kPa pro Bit
0,25 U/min pro Bit
1 km/h pro Bit
0,5 ° mit 0 ° bei 128
1 °C mit -4 0 °C Offset
0,01 g/s
100% 100/255 %
Bit-codiert
Bit-codiert
-6-
Dokumentation V1.0
0V
1,275 V
0,005 V
17
Ausgangsspannung
Lambdasonde Bank 1,
Sensor 4
Bank 1, Sensor 4
-100 % (mager)
+99,22 % (fett)
100/128 %
0V
1,275 V
0,005 V
18
Ausgangsspannung
Lambdasonde Bank 2,
Sensor 1
Bank 2, Sensor 1
-100 % (mager)
+99,22 % (fett)
100/128 %
0V
1,275 V
0,005 V
19
Ausgangsspannung
Lambdasonde Bank 2,
Sensor 2
Bank 2, Sensor 2
-100 % (mager)
+99,22 % (fett)
100/128 %
0V
1,275 V
0,005 V
1A
Ausgangsspannung
Lambdasonde Bank 2,
Sensor 3
Bank 2, Sensor 3
-100 % (mager)
+99,22 % (fett)
100/128 %
0V
1,275 V
0,005 V
1B
Ausgangsspannung
Lambdasonde Bank 2,
Sensor 4
Bank 2, Sensor 4
1C
1D
1E
1F
20
OBD Kompatibilität
Einbauorte
Lambdasonden
Status Hilfseingang
Power Take Off (PTO)
Status
Zeit seit Motorstart
unterstützte PIDs, Bereich
21 - 40
-100 % (mager) +99,22 % (fett)
100/128 %
1 Byte, Hexwert: 04=OBD1, 01=OBD2(CARB), 06=EOBD,
05=kein OBD etc.
Bit-codiert, nur wenn PID 13 nicht vorhanden
Bit-codiert
0 Sek.
Bit-codiert
65.535 Sek.
2 Byte, 1 Sek./Bit
Tabelle 2.2 PID’s von 0 – 20h
Aus Gründen der Platzeinsparung ist die Tabelle nur bis PID 20 dargestellt. Die
Norm enthält noch weitere PID’s bis 4Fh.
Da diese Tabelle allgemein gültig für alle OBD2 kompatiblen Fahrzeuge verfasst
worden ist, wird nicht jeder PID von jedem Fahrzeug unterstützt. So werden in einem
Fahrzeug mit Dieselmotor andere Sensoren als in einem Fahrzeug mit Otto Motor
verbaut. Daher ließ man als erstes den PID 0 aus. Dieser repräsentiert alle
vorhandenen PID’s von 1 – 20h. In PID 20 stehen wiederum die unterstützten PID’s
von 21 – 40h. Wenn uns z.B. die Fahrzeuggeschwindigkeit interessiert, geschieht
dies über Mode 1 (für die Echtzeitdaten) und dem PID 0d für die Geschwindigkeit.
Falls während der Autofahrt oder zumindest bei laufendem Motor ein Fehler erkannt
wird, werden ein oder mehrere Fehlercodes erzeugt, die wir dann mit dem Mode 3
abfragen können. Wenn wir nach einer Reparatur den Fehlerspeicher und somit die
MIL zurücksetzen möchten, erfolgt dies über Mode 4.
Diese 9 Generic Modi bilden die gemeinsame Grundlage für alle OBD2 kompatiblen
Fahrzeuge.
-7-
Dokumentation V1.0
Das Protokoll mit dem die Daten übermittelt werden Ist jedoch Fahrzeug abhängig.
Dies kommt daher, das bis zur Einführung jeder Fahrzeug-Konzern für seine BordElektronik eigene Standards verwendete.
Man einigte sich auf vier unterschiedliche Übertragungsprotokolle, wovon eines für
die OBD2 konformen Daten verwenden muss.
Als Anhaltswert kann man sagen, das amerikanische Fahrzeuge meistens das J1850
VPW und J1850 PWM Protokoll nutzen. asiatische und europäische Fahrzeuge
meist das ISO 9141-2 und KWP 2000. Das ISO 15765 (CAN) Protokoll wird
momentan noch sehr wenig verwendet, soll jedoch ab 2008 bei allen Fahrzeugen,
wahrscheinlich wegen der höheren Übertragungsraten zur Pflicht werden.
In Bild 2.3 sehen sie den Diagnosestecker der bei jedem Fahrzeug welches den
OBD2 Standard unterstützt gleich auszusehen hat. Des Weiteren wurde festgelegt
dass er sich maximal einen Meter entfernt vom Fahrersitz befinden darf. Die Norm
SAE-J1962 beschreibt diese Regelungen.
Bild 2.3 OBD2 Stecker
In der Tabelle 2.1 sehen sie einen Überblick über die Protokolle und die Pins die zur
Datenübertragung genutzt werden. Pins die in der Tabelle nicht aufgeführt wurden,
sind für herstellerspezifische Anwendungen reserviert.
OBD2 Protokoll
ISO 9141-2
Protokollvarianten
KW 0808
KW 9494
ISO 14230-4
KWP2000 fast init
KWP2000 slow init
SAE J1850
PWM
SAE J1850
VPW
ISO 15765-4 (CAN Bus) CAN 11 ident 250 KB
CAN 11 ident 500 KB
CAN 29 ident 250 KB
CAN 29 ident 500 KB
UB 12
Volt
16
16
16
16
16
16
16
16
16
16
GND
4+5
4+5
4+5
4+5
4+5
4+5
4+5
4+5
4+5
4+5
Tabelle 2.3 Steckerbelegung nach Protokoll
Signal
7 + *15
7 + *15
7
7
2 + 10
2
6 + 14
6 + 14
6 + 14
6 + 14
* im Text erläutert
In der Tabelle sehen wir, dass es bei einigen Protokollen unterschiedliche Varianten
gibt.
Bei dem ISO 9142-2 Protokoll handelt es sich um ein serielles Protokoll (nicht zu
verwechseln mit RS232). Die eigentliche Kommunikation findet auf Pin 7 (K-Line)
statt. Bei den meisten neueren Fahrzeugen wird die Initialisierung auch über Pin 7
-8-
Dokumentation V1.0
eingeleitet, Somit entfällt Pin 15. Diagnosegeräte sollten wegen der Kompatibilität zu
beiden Typen Pin 7 und 15 unterstützen.
Bei Verwendung eines der ISO 9141-2 oder der ISO 14230-4 Protokolle spricht man
gewöhnlich auch von K-Line Diagnose, da die ganze Kommunikation über nur eine
Leitung (K-Line) abläuft.
In den folgenden Kapiteln wurden öfters die genormten Abkürzungen bzw. manche
technische Begriffe, die ich aus den Datenblättern so übernommen habe, verwendet.
Einige wichtige Abkürzungen bzw. Begriffe wurden in der Tabelle 2.4
zusammengefasst.
Abkürzung Englisch
Beschreibung
DTC
ECU
MIL
Fahrzeugfehler
allg. Begriff für ein Steuergerät
Fehlerlampe (Motorleuchte)
OBD2
PID
-------------
diagnostic trouble code
elektronic controll unit
malfunction indicator lamp
on-board diagnostics (2nd
generation)
parameter indentification
Frame
Request
Response
message
Onboarddiagnose der 2ten Generation
Funktionale OBD2-Adressierung
Datenrahmen (Datagramm)
Anforderung
Antwort
Nachricht
Tabelle 2.4 Abkürzungen / Begriffe
2.3
Projektbeschreibung
Mein Projekt basiert auf der OBD2/Interfaceschaltung die Im Juli 2005 in der
Zeitschrift ELEKTOR erschienen ist. Das Interface arbeitet als Gateway zwischen
dem Fahrzeugdiagnosestecker und der seriellen RS232 Verbindung zu der
Applikation (meine Technikerarbeit). (Auf die Funktion des ELEKTOR/Interfaces
werde ich später noch genauer eingehen). Meine Aufgabe bestand nun darin, ein
handliches autonomes Diagnosegerät zu entwickeln, welches über das
ELEKTOR/Interface mit dem Kraftfahrzeug kommunizieren kann.
Um das Messgerät Bedienerfreundlich zu gestallten, habe ich dem Diagnosegerät
ein LC-Display mit 4x20 Zeilen gegönnt. Die Menüführung wurde mit 4 Tastern sowie
einem weiteren Taster für den Reset realisiert.
Das Diagnosegerät wurde mit folgenden Features ausgestattet:
- Diagnose an allen Fahrzeugen die das OBD2 kompatible ISO 9141-2
Protokoll unterstützen (meist europäische Fahrzeuge).
- Bedienerfreundliche Menüführung mit Tastern und LCD
- Optional kann über eine separate RS232 Buchse ein PC oder Notebook
angeschlossen werden, mit welchem man die Fahrzeugdaten visualisieren
kann. Die dazu benötigte Software wie z.B. Scanmaster von WGSoft, wird
im Internet kostenlos, zum Download bereitgestellt.
- Bei Auftreten eines Fehlers im KFZ, kann die Anzahl der Fehler sowie der
-9-
Dokumentation V1.0
genormte Fehlercode mit einer Kurzbeschreibung, und die ECU welche den
Fehler bemerkt hatte, auf dem Display dargestellt werden.
- Nach der Reparatur oder wenn der defekte Sensor ausgewechselt wurde
kann auf Wunsch das Diagnosegerät den Fehlerspeicher der ECU löschen,
und damit erlischt dann auch die MIL in der Instrumententafel.
- Ein weiterer Menüpunkt „Sensordaten“ stellt Werte wie Drehzahl,
Geschwindigkeit, Zündzeitpunkt, Drosselklappenstellung usw. in Echtzeit
Auf dem LC-Display dar.
- Der Benutzer hat die Möglichkeit mit einem Menüpunkt „Beschleunigung“
die Beschleunigungswerte seines Fahrzeuges zu messen so z.B.: die
benötigte Zeit von 0….100 KMH.
2.4 Umsetzung
Als erstes musste ich mir überlegen welche Aufgaben seitens der Hardware und der
Software auf mich zukamen.
Man muss bedenken, zu dem damaligen Zeitpunkt hatte ich zwar elektrotechnische
Kenntnisse, aber das Thema Fahrzeugdiagnose war Neuland für mich.
Da mein Auto ein VW Golf IV BJ 2001 (welches auch mein Testfahrzeug war) für den
täglichen Weg zur Arbeit benötigt wurde, konnte ich mir keinen Ausfall der
Boardelektronik, was meistens auch sehr teuer werden würde, leisten.
Dies war der ausschlaggebende Grund warum das OBD2 ELEKTOR-Interface mit
verwendet wurde. Ich musste mir über die Schnittstellenpegel am Fahrzeug, die im
Übrigen auch genormt sind, keine Gedanken mehr machen, da dieses von dem
Interface übernommen wird. Die Daten zum Fahrzeug, und die zur Seriellen
Schnittstelle werden in dem Interface zwischengepuffert und mit der entsprechenden
Baudrate wieder ausgegeben.
Ich besorgte mir das Interface welches als Bausatz verkauft wurde. Nach dem
bestücken war es endlich soweit. Ich lud mir von der Firma WGSOFT das
Diagnoseprogramm Scanmaster runter, ging mit dem Interface und einem Notebook
an mein Fahrzeug, und steckte den OBD2 Stecker in die vorgesehene
Diagnosebuchse. Nach Öffnen von Scanmaster führte das Programm automatische
Abfragen an das Interface und Fahrzeug durch. Seriennummer, verwendetes
Protokoll und andere Randinfos wurden dargestellt. Beim durchklicken der
verschiedenen Reiter welche im Übrigen auch die Mode verkörpern, kam ich zu dem
Menüpunkt Sensordaten, dort konnte man auf Anhieb verschiedene Sensorwerte
des Fahrzeuges sehen, welches sehr interessant anzusehen war.
Da der Golf (dank der jährlichen Wartung) keine Fehler aufwies, und ich dennoch
einen Fehler auslesen wollte, habe ich nachgeholfen. Nach dem öffnen der
Motorhaube und genauerem hinsehen, konnte man viele Steckverbindungen am
Motor an denen diverse Sensoren oder Stellglieder hingen feststellen. Ich entschloss
mich den Stecker zu einem Aktivkohlefilter welcher über einen Schlauch mit dem
Tank verbunden war zu entfernen. Dieser wurde nicht unbedingt für die
lebenswichtigen Aufgaben im Motormanagement benötigt.
- 10 -
Dokumentation V1.0
Bild 2.5 Fehlergenerierung
Damit das Steuergerät den Fehler erkennen konnte, musste der Motor für einen
kurzen Augenblick gestartet werden.
Wenn die ECU an dem der Sensor angeschlossen ist, den Fehler bemerkt, schaltet
sie zu einem die MIL an (ist auch hier der Fall) des Weiteren wird um Motorschäden
zu vermeiden in ein so genanntes Notprogramm gesprungen.
Dazu verändert das Motormanagement das Kennfeld für die Einspritzventile und
anderen Stellglieder. Das geht aber immer zulasten der Motorleistung und eines
erhöhten Spritverbrauchs. Natürlich wird der Motor abgeschaltet, wenn zu viele
Fehler erkannt werden, die genaue Anzahl kenne ich aber nicht. Mit dem Reiter für
„DTC’s“ konnte man folgenden Fehler erkennen.
Bild 2.6 DTC
- 11 -
Dokumentation V1.0
Die Fehlerbeschreibung bedeutet sehr grob übersetzt: „Verdunstungs-Emissionen
Kontrollsystem Durchspül-Kontrollventil Schaltkreis Fehlfunktion“.
(Zum Glück wusste ich noch welchen Sensorstecker ich gezogen hatte).
Nach der „Reparatur“ des Fehlers (Stecker wieder verbunden) konnte ich mit dem
Button für Clear, den Fehlerspeicher der ECU wieder rücksetzen.
Nachdem die Funktionalitäten des Programms ausgetestet waren, besorgte ich mir
genauere Informationen über das Interface und wie der Datenaustausch an der
seriellen Schnittstelle am Interface ablaufen sollte.
Es gab ein Datenblatt über das Herzstück, ein vorprogrammierter µ-Controller der
Firma Özen-Elektronik welcher aber leider sehr spartanisch beschrieben war.
Die Mode und das OBD2 Datagramm (OBD2 Frame), welches ja allgemein gültig für
OBD2 kompatible Fahrzeuge ist, wurden unter anderem in der ISO 15031-5 definiert.
Also suchte ich im Internet nach einem Link wo ich diese Norm herbekommen
könnte, letztendlich wurde ich jedes Mal Zur Homepage von SAE oder dem ISO
Institut in der Schweiz verwiesen, und da zahlte man für die Norm 236 Franken.
Der Grund dafür: die Normen die OBD2 beschreiben, sind kein „open System“ Jeder
der die Normen z.B. durch das Internet veröffentlicht, macht sich dadurch strafbar.
Normalerweise kauft man als Hersteller oder als Programmierer von
Diagnosegeräten die entsprechenden Normen und arbeitet sie Stück für Stück ab.
Mir war das, wenn man noch die weiteren Kosten für mein Projekt beachtet, einfach
zu teuer.
Eine andere Möglichkeit die ich auch nutze, bestand darin, nach Bauteilen und
Komponenten die in der Fahrzeugindustrie oder bei anderen Diagnosegeräten
eingesetzt wurden zu suchen, darin ist zwar nicht die Norm enthalten aber meistens
kann man der Funktionsbeschreibung zu dem Bauteil einiges an Informationen oder
sogar einen teilweisen Auszug der Norm abgewinnen.
Einige sehr hilfreiche Informationen die ich für mein Projekt nutzen konnte, habe ich
dem Datenblatt des ELM 323 von der Firma Elmelectronics entnehmen können. Des
Weiteren suchte ich in diversen Foren nach konkreten Informationen zur
Fahrzeugdiagnose mit OBD2, dort galt es aber auch den Weizen von der Spreu zu
trennen.
Als nächstes begab ich mich wieder mit dem Notebook und dem Interface ins Auto.
Mit Hilfe des „Sniffer Programms Portmon habe ich einige Datagramme an der
seriellen Schnittstelle aufzeichnen können.
In Verbindung der einzelnen Informationen, aus den Foren, der Datenblätter, und
des Logfiles von Portmoon versuchte ich den Datagrammaufbau zu entschlüsseln.
Anfangs überlas ich einige Stellen oder nahm sie seitens des Verständnisses einfach
nicht war, doch als später das Programm geschrieben wurde, stieß ich automatisch
auf diese Lücken und konnte sie durch wiederholtes Lesen der Datenblätter und
Notizen machen schließen.
In der Schule verwendeten wir ein Experimentierboard der Firma Keil mit LPC
Bondout. Dieses System war mit seinem vielen Features wie geschaffen für mein
Projekt. Der Testaufbau bestand im Wesentlichen darin, dass ich das ELEKTOR
Interface an die serielle Schnittstelle des Entwicklungsboard’s angeschlossen habe.
LC-Display, und Taster waren auf dem Board schon integriert. Nun konnte ich
Funktionen schreiben, und diese dann direkt im LPC-Bondout emulieren.
Es war geschafft, der erste Kontakt mit dem Fahrzeug wurde hergestellt. Anfangs
lies ich mir die empfangenen Daten als Hexazahlen auf dem LC-Display darstellen,
somit konnte das Datenpacket besser untersucht werden.
Das Programm und die Anzahl der Funktionen wuchsen Schritt für Schritt, wegen der
besseren Übersichtlichkeit entschied ich mich alle Funktionen in C zu schreiben.
- 12 -
Dokumentation V1.0
Wichtig dabei war, dass die 8K Programmspeichergrenze des LPC932 im Auge
behalten werden musste, somit musste besonders wert auf codesparende
Programmierung gelegt werden.
Parallel zu den Funktionen vergrößerte sich auch der Versuchsaufbau.
Ein 4 x 20 Zeiliges Display kam zum Einsatz, damit das Benutzermenü sauber
dargestellt werden konnte. Des Weiteren passte ich auch das ELEKTOR Interface
meinen Bedürfnissen an. Nachteilig war z.B. das es keine Software mäßige Reset
Möglichkeit für das Interface gab, So musste jedes mal nachdem der Schlüssel für
die Zündung umgedreht wurde, der Diagnosestecker vom Fahrzeug getrennt und
wieder neu eingesteckt werden, damit das ELEKTOR Interface sich neu
Initialisieren konnte. Bei einigen Fahrzeugen klappte die Verbindung nicht auf
Anhieb, somit musste der Vorgang wiederholt werden. Im ELEKTOR Forum sah ich
das dieses „Komfortproblem“ auch andere Nutzer betraf. Die Lösung war nahe. Der
verwendete µ-Controller auf dem ELEKTOR Interface wird durch einen Kondensator
nach anlegen der Betriebsspannung, praktisch in dem Moment wo er mit der
Diagnosebuchse verbunden wird für ca. 200ms auf UB 5volt gehalten. Nach der
Aufladung des Kondensators sinkt das Potenzial auf ca. 0Volt am Reset Pin des µControllers. Ich entfernte diesen Kondensator und verband den Resetpin mit einem
freien Port am LPC 932, jetzt konnte das Interface softwaretechnisch nach belieben
resetet werden. Weitere Beschreibungen und Umbau-Maßnahmen finden sie in dem
Kapitel Hardware 3.2.
Nachdem alle Funktionen geschrieben und getestet wurden, zeichnete ich die
Schaltpläne in Target V11.
Die Frontplatine ätzte ich selber, die Motherboardplatine auf dem auch der LPC 932
sein Platz einnimmt, ließ ich extern, von der Firma Fischer Elektronik anfertigen. So
konnte ich mir die undankbare Mühe die doppelseitig beschichtete Platine, zu ätzen
und zu bohren sparen. Ein wichtiger Vorteil bestand darin, dass die Wände der
Durchkontaktierungen mit Zinn ausgefüllt wurden, die Stabilität der größeren
Baugruppen auf der Platine nahm zu.
Nach dem das Bestücken der Platinen, und der Umbau des ELEKTOR Interfaces
beendet waren, musste noch das Kunstoffhandgehäuse angepasst werden.
Die nächsten Wochen wurden benötigt um das Feintuning am Programm
vorzunehmen. Außerdem testete ich das Diagnosegerät an weiteren Fahrzeugen.
Die Anfertigung der Dokumentation erfolgte am Ende des Projektes
- 13 -
Dokumentation V1.0
3. Hardware
3.1
Blockschaltbild
Bild 3.1 Blockschaltbild
- 14 -
Dokumentation V1.0
In Bild 3.1 sehen sie den internen Aufbau und die Anordnung der drei Platinen, von
der Unterseite her gesehen.
Die beiden 10-Poligen Flachbandleitungen für den PC (rechte Leitung) sowie den
Diagnoseanschluss (linke Leitung) führen zu den beiden Sub-D Steckern, die an der
unteren Gehäusehalbschale (nicht abgebildet) befestigt sind.
Bild 3.2 interner Aufbau
- 15 -
Dokumentation V1.0
Um die Übersichtlichkeit der folgenden Schaltpläne etwas besser zu gestallten,
wurden die Bauteile der Platinen unterschiedlich nummeriert.
Interface Platine Mainboard
Frontplatine
Bauteilindex größer 0 und kleiner 100
Das Mainboard bildet die Grundplatine. Auf ihr sind das Diagnoseinterface sowie die
Frontplatine eingesteckt.
3.2
Modifikation des ELEKTOR OBD2/Diagnoseinterface
Bild 3.4 Original Schaltplan ELEKTOR Interface
Da das ELEKTOR Interface von mir zugekauft wurde und als solches schon
funktioniert, gehe ich lediglich auf die für das Verständnis notwendigen
Funktionsgruppen ein. Dem Datenblatt des µC T89C51 welcher von der Firma
- 16 -
Dokumentation V1.0
Özen-Elektronik programmiert, und zu OE90C2600 umgetauft wurde, konnte ich
keine genauen Informationen über den Ablauf des Programms entnehmen.
Durch die Anwendung heraus, konnten jedoch die meisten Funktionen geklärt
werden.
Die betreffenden Bauteile der Umbaumassnahmen (blau eingerahmt Abschnitt A)
entfielen z.T., oder fanden auf der Mainboard / Frontplatine ihren Platz ein.
Nach anlegen der Betriebsspannung an K2 Pin 9, beziehen die Spannungsregler IC5
und IC6 ihre Versorgungsspannung von 12 Volt aus dem KFZ Boardnetz.
Das Herzstück der T89C51 (IC1) wird an dem Reseteingang durch die Kombination
von C7 und dem Resetbaustein ZSH 560C für ca. 200ms auf UB von 5Volt gehalten.
Mit der Entladung von C7 nähert sich der high aktive Reseteingang ca. 0 Volt.
Durch die feste Verdrahtung ist ein manueller Reset nur durch erneutes einstecken
des Diagnosesteckers möglich. Bei der Abänderung, wurde der Reset Pin des
OE90C2600 mit den freien Pin 6 von K1 verbunden.
Nach dem Reset startet der T89C51 automatisch die Protokollsuche. Dazu versucht
er nacheinander über die Funktionsgruppen Abschnitt B bis E auf die ECU im
Fahrzeug zuzugreifen.
Bei den CAN Protokollen (ISO 15765-4) findet der Datenaustausch über Abschnitt B
statt. Bei Verwendung des SAE J1850 PWM Protokoll wird Abschnitt C genutzt.
Bei einer der K-Line Protokolle (ISO 9141-2 / ISO 14230-4) findet der
Datenaustausch über Abschnitt D statt, Das SAE J1850 VPW nutzt den Abschnitt E.
Nachdem ein gültiges Protokoll gefunden wurde wird der Pin 6 von dem µ-C auf low
gesetzt und die Status LED D1 beginnt zu leuchten.
Bei der Modifikation wurde der Pin mit K1 Pin 8 verbunden. So habe ich ein
Kontrollsignal, welches mir mitteilt, wenn das Protokoll sprich eine ECU gefunden
wurde. Die zugehörige LED fand ihren Platz auf der Frontplatine ein.
Bild 3.5 abgespeckte Eingangsbeschaltung des OE90C2600 (IC1)
- 17 -
Dokumentation V1.0
Der Anschlusspin für die Kommunikations- LED D2 wird direkt mit dem Pin 4 von K1
verbunden. Die LED’s entfallen zwar auf der Interface Platine, werden aber auf der
Frontplatine zur anzeige wieder eingesetzt.
In die Ausgänge des OE90C2600 darf ein Strom von max. 5mA fließen. Durch die
Verwendung von low current LED’s kann ein separater Treiber entfallen.
Das Interface stellt mit dem Festspannungsregler LM 7805 eine Spannung von 5Volt
zur Verfügung. Da die gleiche Spannung auch für anderen Platinen benötigt wird,
Lag es nahe sie an einen freien Pin, dem Pin1 zu legen. Durch die erhöhte
Mehrbelastung musste jedoch der LM7805 mit einem zusätzlichen Kühlkörper
gekühlt werden. Dadurch dass einige Bauteile auf dem Interface eingespart werden
konnten, fand sich jedoch genug Platz um den Kühlkörper mit etwas Silikon isoliert
an der Platine zu befestigen.
Der T89C51 sendet nach erfolgter Initialisierung alle 3 Sekunden, automatisch eine
„keep alive“ message an das Fahrzeug. Dies ist lediglich ein Mode 1 Pid 0 Befehl um
den ECU’s mitzuteilen das wir mit Ihr noch verbunden sind. Bei Ausfall solch einer
Nachricht würden wir von der ECU automatisch abgemeldet werden. Danach
müssten wir das Interface erneut reseten. Wenn wir nun das Interface während dem
Betrieb reseten, oder bei der original Schaltung, Stecker raus, Stecker rein, kann es
oft vorkommen, das das Interface bei der erneuten Protokollsuche nicht fündig wird.
Somit konnten dann auch keine Fahrzeugdaten mehr ausgelesen werden. Mit einem
erneuten Reset wurde dann wieder ein Protokoll gefunden.
Die Ursache liegt, denke ich darin, dass der Initalisierungsvorgang (Protokollsuche)
mit einer niedrigeren Baudrate (Bei ISO 9141-2 mit 5 Bd) erfolgt. Wenn der Vorgang
abgeschlossen ist, schaltet zur eigentlichen Datenübertragung das Interface auf 10,4
kB um. Danach wird alle 3 Sekunden an die ECU die keep alive message
versendet. Wenn wir nun, kurz nach dem die keep alive message versendet wurde
das Interface reseten, beginnt sofort die Initalisierung mit 5Bd, und das Obwohl die
ECU noch auf Anfragen mit 10,4 kB wartet. Es musste dann „nur“ noch dafür gesorgt
werden das Interface nach einem Reset mindestens 3 Sekunden wartet, bis die
Initialisierung eingeleitet wird.
Für die Original Schaltung ist IC4, ein Max 232 Vorgesehen, der die TTL Pegel von
Pin 13 und 14 vom OE90C2600 in RS 232 Pegel für K1 wandelt.
Anstelle des PC’s ist in meiner Schaltung der LPC932 (auf dem Mainboard) mit K1
verbunden. Dieser arbeitet mit TTL kompatiblen Signalpegeln somit kann der MAX
an dieser Stelle entfallen.
Bild 3.6 Modifiziertes Interface BS und LS
- 18 -
Dokumentation V1.0
3.3
Schaltpläne
Bild 3.7 Modifizierter Schaltplan Interface Platine
- 19 -
Dokumentation V1.0
Bild 3.8 Schaltplan Mainboard
- 20 -
Dokumentation V1.0
Bild 3.9 Schaltplan Frontplatine
3.4
Spannungsversorgung
Die Betriebsspannung für das komplette Diagnosegerät wird aus der
Fahrzeugspannung gewonnen. Über das OBD2 Adapterkabel Bild 3.10
Bild 3.10 OBD2 – Sub-D Verbindungsleitung
- 21 -
Dokumentation V1.0
werden die 12 Volt über den Pin 9 der Sub-D Buchse, 1 zu 1 an das Mainboard K105
weitergeleitet. Um einen geeigneten Wert für die Sicherung F101 zu bekommen,
habe ich den Strom zwischen Pin 1 und 2 des Sicherungs-Sockels gemessen. Er
betrug nach der Initalisierungsphase ca.110 mA. Um einen kleinen Spielraum zu
haben, entschloss ich mich für eine 200 mA mittelträge Schmelz-Sicherung. Die LED
D201 auf der Frontplatine dient als Betriebsspannungsanzeige.
Das Interface wird über Pin 9 des K104 auf dem Mainboard gespeist. Das Interface
wandelt die 12V über den internen Spannungswandler auf 5Volt und stellt diese
dann am Pin 1 des K103 wieder zur Verfügung.
Der Spannungswandler IC 101 stellt die Versorgungsspannung von 3,3 Volt für den
LPC 932 bereit.
Die 100nF Stützkondensatoren C101…C104 kompensieren kurze Spitzenströme.
Sie versorgen dann in diesem Augenblick die Baugruppen mit Spannung.
3.4
LPC932
Der LPC 932 ist ein moderner µC von der Firma Phillips, auf der Basis des
berühmten 8051. Er unterstützt den gleichen Befehlssatz und bietet des Weiteren
sinnvolle Features für Platz-Sparende mobile Applikationen. Er besitzt einen internen
Programmspeicher von 8k, sowie einen internen Datenspeicher von insgesamt
768Byte.
- 22 -
Dokumentation V1.0
Bild 3.11 Blockschaltbild LPC 932
Um die externe Beschaltung so gering wie möglich zu halten, bietet er außerdem die
Möglichkeit, den internen RC Oszillator von 7,3728MHZ zu verwenden. Anfangs für
den Versuchsaufbau nutzte ich auch diesen. Später kam bei mir der Wunsch noch
auf, einen Beschleunigungsmesser softwaretechnisch zu realisieren. Das Problem
lag darin, das eine genaue Zeitmessung benötigt wurde, die Auflösung sollte
Idealerweise 100 ms betragen. Mit dem internen Oszillator waren bei einer
gemessenen Zeit von 30 Sekunden und der Toleranz von + - 2,5 % eine Streuung
von 29,25 bis 30,75 Sekunden möglich. Dies war einfach zu viel, so habe ich um
den Aufwand so gering wie möglich zu halten, einen externen Quarz Q101 mit der
gleichen Frequenz an den Pin 9 und 8 am LPC angeschlossen. Mit den beiden
Kondensatoren C105 und C106 hält er die Frequenz sehr stabil.
Die Ports des LPC unterstützen 4 verschiedene Betriebsarten. Davon werden
verwendet:
Quasi-Bidirektional:
Die Ports können als Ein und Ausgang benutzt werden. Bei einer logischen 1 dürfen
max. – 20µA dem Portpin entnommen werden. Bei einer logischen 0 max. 3,2 mA in
den Portpin hinein fliesen.
Input-Only:
Dieses ist nach dem Einschalten die Default Einstellung. Die Ports können nicht auf
0 oder 1 gesetzt werden, lediglich der anliegende logische Zustand kann abgefragt
werden.
- 23 -
Dokumentation V1.0
Open-Drain:
In dieser Betriebsart schaltet ein interner Transistor den Port gegen Masse.
Schaltungstechnisch muss zusätzlich ein externer Widerstand oder Verbraucher
zwischen den Portpin und der UB geschalten werden.
Ausschließlich beim Port P1.2 (Trigger) wird diese Betriebsart benutzt.
An den Triggerpin kann optional an ein externer Datenschreiber oder ein Oszilloskop
angeschlossen werden.
Der LPC arbeitet mit einer Betriebsspannung von 3,3 Volt, es ist jedoch zulässig
5Volt an fast alle Eingänge anzulegen.
Die Widerstandsnetzwerke RN101 - RN103 sind parallel zu den Pins geschaltet und
ziehen die Ausgänge bei einer logischen 1 auf ein Potenzial von 5Volt. Somit ist die
TTL Kompatibilität zu den anderen Baugruppen gewährleistet.
Portbelegung am LPC 932
Port
Beschreibung
Bedientasten
P0.0
P0.1
P0.2
P0.3
P1.5
Taste up (aufwärts)
Taste down (abwärts)
Taste m (Menü)
Taste <OK>
Reset
LC-Display
P2.0
P2.1
P2.2
P2.4
P2.5
P2.6
P2.7
Display_E
Display_RW
Display_RS
D4
D5
D6
D7
Sonstige
P0.4
P1.0
P1.1
P1.2
P1.4
P1.6
P1.7
Abfrage des Protokollstatus
TX (seriell)
RX (seriell)
Triggerpin für externe Geräte
Reset für Interface
TX (seriell) für Max 232
RX (seriell) für Max 232
Tabelle 3.1
- 24 -
Dokumentation V1.0
3.5
LC-Display
Bild 3.12 Beschaltung am LC-Display
Für das LC-Display wurde der komplette Port 2 benutzt.
Mit dem Potentiometer R101 lässt sich der Kontrast des Displays stufenlos
einstellen. Die Hintergrundbeleuchtung wird separat über Pin 15 gespeist. Die LED
Spannung darf zwischen 3,0 und 3,6 Volt liegen -> typ. 3,3Volt.
Dabei darf ein Strom von max. 30mA fließen -> typ. 15mA, er variiert je nach
Umgebungstemperatur. Der zugehörige Vorwiderstand R102 errechnet sich dann
folgendermaßen:
RV = 5Volt - 3,3Volt / 15mA = 110 Ohm -> gewählter Wert 100 Ohm
3.6
Bedientasten
Auch relativ simple Bauteile wie die Taster mussten richtig ausgewählt werden.
Dadurch dass das verwendete Handgehäuse schon eine Aussparung für eine
Folientastatur hatte, wollte ich auch solch eine verwenden. Die diversen
Elektronikversandhäuser besaßen verschiedene Varianten in ihrem Sortiment.
Entweder waren zu viele, oder zu wenig Tasten auf der Folie, oder die Beschriftung
harmonierte einfach nicht mit der Menüführung.
- 25 -
Dokumentation V1.0
Da das Diagnosegerät in seinem späteren Einsatz möglicherweise in einer Werkstatt
eingesetzt wird, mussten die Tasten resistent gegen „Schmierfinger“ sein. Ein kurzer
Tastenhub sowie eine flache Bauart waren auch empfehlenswert. Die verwendeten
Kurzhub-Tasten erfüllten all diese Bedingungen.
Der Reseteingang Port 1.5 des LPC ist low aktiv, d.h. er wird nach einer negativen
Flanke rückgesetzt.
Die anderen vier Tasten für die Menüführung, ebenfalls low aktiv, wurden an den
P0.0 – P0.3 angeschlossen. Bild 4.4 zeigt das prinzipielle Anschlussschema eines
Tasters.
Bild 3.13 Anschlussschema eines Tasters
Im Ruhezustand wird der Portpin durch einen hochohmigen Widerstand auf logisch 1
gehalten. Beim betätigen der Taste wird das Potenzial am Portpin auf 0V gezogen.
3.7
Serielle Schnittstelle
Die serielle Schnittstelle überträgt Daten nacheinander (seriell) über die
Empfangsleitung RX bzw. die Sendeleitung TX.
Es gibt eine Vielzahl unterschiedlicher Normen die die Serielle Schnittstelle
beschreiben. Die Kommunikation mit dem OBD2-Interface erfolgt nach der RS232
Norm. Bei der Asynchronen Datenübertragung gibt es kein separates Taktsignal
welches zur Synchronisation benutzt wird.
Um das TTL Signal im PC oder eines µC an die Pegel auf der RS232 Datenleitung
anzupassen werden UART (Universal Asynchronus Receiver and Transmitter)
Bausteine wie der MAX 232 eingesetzt.
Bild 3.14 MAX 232
- 26 -
Dokumentation V1.0
Eine logische 1 am TTL Ausgang wird durch den Pegelwandler zu einer negativen
Spannung, die zwischen -3 und -12V betragen darf, umgesetzt.
Eine logische 0 wird dem entsprechend zu einer Spannung von +3… +12 Volt
umgesetzt.
Der Max besitzt eine interne Spannungspumpe. Diese wird dazu benötigt, um mit der
Betriebsspannung von nur 5Volt, die Pegel für die RS232 Schnittstellenleitung zur
Verfügung zu stellen.
Wie funktioniert nun das senden eines Zeichens? Dazu müssen auf beiden Seiten
der Übertragungsstrecke die gleichen Vereinbarungen getroffen werden.
Bild 3.15 Ausschnitt der Com-Eigenschaften am PC
Die Bitrate entscheidet darüber wie viel Bits pro Sekunde übertragen werden.
Bei 9600 Bit/s beträgt die Bitzeit 104µs. Die Anzahl der Datenbits entscheidet
darüber, wie viel Nutzdaten wir pro Datagramm versenden. Üblicherweise werden 8
Bits = 1Byte übertragen. Das Paritätsbit kann bei kritischen Daten mit übertragen
werden. Da es aber keine 100% Fehlererkennung bei Übertragungsfehlern zulässt,
verzichtet man zugunsten der Geschwindigkeit gerne darauf. Mit der Flusssteuerung
können sich DEE und DTE über Betriebs und Sendebereitschaft verabreden.
Das gängigste Format, welches auch das Interface benutzt ist das 8N1. Es bedeutet
8 Datenbits, keine Parität und ein Stoppbit.
Bild 3.16 Übertragung eines Bytes Quelle TA. J.Schell
Im Ruhezustand beträgt die Spannung am TTL Ausgang 5Volt.
Der Empfänger tastet die Leitung mit einem Vielfachen der Bitzeit ab. Der Sender
beginnt mit der Übertragung und legt dazu den Ausgang auf 0Volt.
Der Empfänger startet nun eine interne Zeitzählung und tastet in der Bitmitte dreimal
die Leitung ab. Davon müssen mindestens 2 Proben 0 sein.
104µs später also bei der nächsten Bitmitte wird wieder die Leitung dreimal
abgetastet, und die Mehrheit der Proben entscheidet, welcher logische Zustand
ausgewertet wird. Nach dem achten Datenbit, setzt der Sender die Datenleitung mit
einer positiven Flanke wieder in den Ruhezustand zurück.
- 27 -
Dokumentation V1.0
3.8
Umschaltung vom Interface zum LPC / PC
Die Möglichkeit optional einen PC an das Diagnosegerät anzuschließen, brachte die
Schwierigkeit der Umschaltung, von dem Interface zum LPC / PC mit sich.
Die einfachste aber auch uneleganteste Möglichkeit wäre, die zwei Datenleitungen
RX und TX des Interfaces über ein 2 x UM Relais jeweils an den Max 232 oder den
seriellen Ein/Ausgängen des LPC zu leiten.
Die nächst bessere Möglichkeit bestand nun darin, anstelle des Relais die
Umschaltung mit Gattern der 74xx Baureihe zu lösen.
Dazu wären dann, ein freier Pin als Umschaltsignal am LPC, 4 x UND, 1 x ODER,
und 2 x NICHT Gatter notwendig.
Zum Glück hatte ich, damals im Sommer 2005 noch genug Zeit bis zur Abgabe des
Projektes. So konnte ich mir zwischendurch ein paar Tage Freizeit gönnen.
Ausgerechnet beim „Nichtstun“ kam mir die scheinbar einfache Idee, die
Umschaltung alleine durch den LPC zu realisieren.
Bild 3.18 Prinzip der Umschaltung
Die RX und TX Leitung des Interfaces sind fest an P1.0 und P1.1 des LPC
angeschlossen. Im autonomen Betrieb verhält sich die Schaltung als wenn der
MAX232 nicht angeschlossen wäre. Wenn die Datenauswertung jedoch mit dem PC
erfolgen soll, wird Programmtechnisch Port 1.0 an den P1.6 und der P1.7 an den
Port 1.1 geschalten. Dies ist nur möglich da in dieser Zeit der LPC keine andere
Aufgabe als das kontinuierliche durchschalten der Ports übernehmen muss.
- 28 -
Dokumentation V1.0
3.9
Stücklisten
Stückliste für das Mainboard
Position
Widerstände:
RN101,RN102,RN103
R101
R102
R103,R104
R105
R106
Kondensatoren:
C101…C104
C105,C106
C107...C110
Halbleiter:
IC101
IC102
IC103
Außerdem:
Q101
LCD101
Frontrahmen für LCD
K101
K102,K105
K103
K104
K106
F101
Sockel für F101
Sockel für IC102
Sockel für IC103
Platine
Preis /
Stück
Wert
Lieferant
47k R-Netzwerk
10k Poti
100
1k5
4k7
1k
0,12 €
0,21 €
0,09 €
0,09 €
0,09 €
0,09 €
LPC 932 PLLC28
MAX 232 DIL16
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Conrad
Herr
Sperling
Reichelt
Quarz 7,3728MHZ
LCD204B BL 4x20
LCD FRONT 9
16 Pol DIL
10 Pol Wannenst.
D-SUB 10Pol male
D-SUB 10Pol female
Lötnagel
0,2A mittelträge
Printausführung
PLCC28
16 Pol DIL
doppelseitig
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Reichelt
Fischer
0,49 €
34,50 €
7,10 €
0,18 €
0,07 €
0,17 €
0,17 €
0,03 €
0,34 €
0,28 €
0,32 €
0,18 €
51,45 €
100n
33n
10µ/35V stehend
L4931 3,3v
Gesamtkosten
0,12 €
0,11 €
0,14 €
1,19 €
gesponsert
0,40 €
99,22 €
Stückliste für die Frontplatine
Position
Wert
Halbleiter:
D201
LED rt 2mA
D202
LED gn 2mA
D203
LED ge 2mA
Außerdem:
S201…S205
Taster rt
Befestigungssatzt für Taster
K201
DIL 16
Gesamtkosten
Lieferant Preis / Stück
Reichelt
Reichelt
Reichelt
0,09 €
0,09 €
0,09 €
Reichelt
Reichelt
Reichelt
1,65 €
0,30 €
0,18 €
10,20 €
- 29 -
Dokumentation V1.0
Stückliste für das Interface
Wurde als kompletter Bausatz
zugekauft
Position
Widerstände:
R1,R2
R3,R4
R5,R9,R15,R16,R21,R25
R6...R8,R10,R11,R14,R17,R22,R23
R12,R13
R18
R19
R20
R24
Kondensatoren:
C5,C6
C8,C9,C10,C13...C15
C11,C12
Halbleiter:
D3
D4,D5
T1,T5
T2...T4
IC1 (programmiert von ELEKTOR)
Typenbezeichnung: OE90C2600
IC2
IC3
IC5
IC6
Außerdem:
K1
K2
JP1
X1
PLCC-Fassung, 28-polig für IC1
OBD2 Verbindungskabel zum KFZ
Platine
Wert
Lieferant
1k
100
4k7
10k
510
1k1
3k9
3k
1
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
27p
100 n
560 p
ELEKTOR
ELEKTOR
ELEKTOR
1N4001
1N4148
2N3906
2N3904
T89C51
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
LM339, DIL14
PCA82C251, DIL8
LM7805C, TO220
LM7808C, TO220
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
9-polig Sub-D (weiblich),gerade
9-polig Sub-D (männlich),gerade
2-polige Pfosten-Stiftleiste
Quarz 16 MHz
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
ELEKTOR
EPS 050092-72
EPS 050092-1
Gesamtkosten
83,50 €
Gesamtkosten der drei Platinen
+ Kunststoffhandgehäuse
192,92€
25,00€
Endpreis
217,92€
- 30 -
Dokumentation V1.0
3.10 Layouts
Mainboard Bestückungsseite
Mainboard Layer oben
- 31 -
Dokumentation V1.0
Mainboard Layer unten
Frontplatine Bestückungsseite
- 32 -
Dokumentation V1.0
Frontplatine Layer unten
- 33 -
Dokumentation V1.0
4. Senden und Empfangen über das Interface
4.1
Aufbau einer Nachricht
Das Interface ist der Slave und der LPC (Anwender) stellt den Master dar.
Die serielle Kommunikation erfolgt halbduplex.
Die ECU im Fahrzeug wird von sich aus nie Daten zum Interface senden bevor man
sie zuvor nicht dazu aufgefordert hatte. So zu sagen sendet man eine Anfrage
(Request message) und bekommt dann die Daten mit einer Response message vom
Fahrzeug über das Interface zurück. Die Nummerierung der Commands erfolgt
dezimal. Alle anderen Werte (auch im Frame sind hexadezimal)
Da das Interface die gemeinsame Schnittstelle darstellt, muss alls erstes der
OE90C2600 angesprochen werden. Dies geschieht mit einem Command. Die kpl.
Command Liste kann dem Datenblatt OE90C2600 entnommen werden. Dargestellt
habe ich nur die Commands die für mein Projekt von Bedeutung waren.
Tabelle 4.1 Command 02 für die Generic Modi
Tabelle 4.2 Command 05 für das gefundene Protokoll nach der Initialisierung
Tabelle 4.3 Command 06 für die ID. Nr.
- 34 -
Dokumentation V1.0
Bsp.: Nachdem über die Status LED vom Interface über Port 0.4 (LED) eine
erfolgreiche Initialisierung bestätigt wurde, liest der LPC als erstes die Chip ID. vom
OE90C2600 aus. So zusagen ist dann die erste Kommunikation mit dem Interface
erfolgreich verlaufen.
Die empfangenen Bytes werden vom LPC in ein globales Array geschrieben und
können anschließend von jeder Funktion ausgelesen werden. Bsp.:
Request Response
6
6
0Ah
28h
Beschreibung
1. Command senden
2. Positiver Resp.
3. Chip ID
4. 2600 (dezimal)
Tabelle 4.4
Jetzt wird das gefundene Protokoll abgefragt Bsp.:
Request Response
5
5
00h
01h
Beschreibung
1. Command senden
2. Positiver Resp.
3. ISO 9141-2
4. kw 0808
Tabelle 4.5
Über Command 02 können wir direkte Anfragen an die ECU’s senden
Der genormte Frame für das ISO 9141-2 sieht folgendermaßen aus:
Request (Anfrage)
Header
Typ
68h
Ziel
Adresse
6Ah
Sender
Adresse
F1h
Datenfeld
CRC
1 .... 7
Bytes
Checksumme
Tabelle 4.6
Response (Antwort)
Typ
Header
Ziel
Adresse
48h
6Bh
Datenfeld
Sender 1 .... 7
Adresse Bytes
ECU
Adr.
CRC
Checksumme
Tabelle 4.7
Es wird von links nach rechts gesendet/empfangen! d.h. als erstes kommt das Typ.
Byte.
Das Typenfeld enthält Informationen über die Priorität und ob es sich um eine
Physikalische Adressierung oder um eine Funktionale Adressierung handelt.
Die Ziel Adresse ist die Adresse an die das Frame gesendet werden soll.
- 35 -
Dokumentation V1.0
Die Sender Adresse enthält wie der Name schon sagt die Adresse des Senders.
Im Datenfeld übergibt man bei der Anfrage den Mode und je nach Mode den PID, bei
der Antwort steht dann im Datenfeld das Echo vom Mode + 40h danach der PID
(wenn vorhanden) und dann kommen die eigentlichen Daten. Für Mode 3 und 7 die
Fehlercodes und für Mode 1 die Daten der PID’s (siehe PID Tabelle 2.2 auf Seite 7).
Das Datenfeld kann je nach Mode und PID 1 – 7 Bytes lang sein.
Die Checksumme wird aus den gesendeten Bytes berechnet.
Bei meinem Projekt wurden ausschließlich die generic Modi verwendet.
Sie verwenden eine funktionelle Adressierung. Dabei wird nicht die einzelne ECU im
Fahrzeug angesprochen, sondern es wird nach einem Verwendungszweck
adressiert. Alle ECU’s die sich dann angesprochen fühlen d.h. diejenigen die den
angeforderten Mode bzw. PID unterstützen, prüfen ob gerade die Datenleitung (KLine) belegt ist und antworten dann jeweils in einem separaten Frame nacheinander.
In der Tabelle 4.8 sind die Adressen der Steuergeräte aufgelistet.
Adresse
(Physikalisch)
10-17F
18-1F
20-27
28-2F
30-37
38-3F
40-57
58-5F
60-6F
70-7F
80-8F
90-97
98-9F
0A-BF
C0-C7
C8
C9
CA
CB
CC-CF
D0-EF
F0-FD
Art des Steuergerätes (ECU)
Motor-Steuergeräte
Getriebe-Steuergeräte
Hersteller-spezifische Erweiterung für
Fahrwerk
Bremsen-Steuergeräte
Lenkungs-Steuergeräte
Federungs-Steueräte
Hersteller-spezifische Erweiterung für
Karosserie
Gurtanschnall-Systeme
Fahrer-Informationssysteme
Beleuchtung
Unterhaltung/Audio
Persönliche Kommunikation
Klima-Automatik
Komfort (Türen, Sitze, Fenster etc.)
Sicherheits-Systeme
Zubehör-Anschluß-Dienste
Wechselspannungswandler
Wechsel-/Gleichspannungswandler
Energiespeicher-Management
reserviert für künftige Erweiterungen
reserviert für Hersteller-spezifische
Aufgaben
externe Tester / Diagnose-Geräte
Tabelle 4.8
Das Interface besitzt die Möglichkeit bei einer Anfrage die Header und die
Checksumme selbst zu generieren. Aus Komfort Gründen habe ich diese Art der
Anfrage ausgewählt. Somit braucht bei der Anfrage anstatt des kompletten Frames
nur der Command 02 für die generic Modi, danach der Mode und je nach Mode der
PID gesendet werden.
Bsp.: Es soll Mode1 PID 0 (für alle unterstützten PID’s von 1 – 20h) abgefragt
werden.
- 36 -
Dokumentation V1.0
Die Anfrage lautet:
Request Response
Beschreibung
2
1. Command senden
2. Positiver Resp.
3. sende Mode
4. sende PID
6
01h
00h
Tabelle 4.9
Die Antwort sieht dann folgender maßen aus:
Response (Antwort)
vom Interface
generiert
Header
Länge der
Echo vom folgenden
Command Bytes
Typ
Ziel
ECU
Mode +
Adresse Adresse 40h
PID unterstützte Pid’s
Ech von
o
0 - 20h
2
48h
6Bh
0h
0Ah
Datenfeld
F1
41h
CRC
BE 3E A8
Checksumme
11 B9
Tabelle 4.10
Als erstes empfangen wir das Echo des Command, danach die Länge der folgenden
Bytes, diese beiden Bytes werden vom Interface erzeugt. Jetzt kommt der
eigentliche Frame vom Fahrzeug. Die beiden ersten Headerbytes sehen bei jeder
Response message gleich aus. Die Ziel Adresse ist keine Physikalische Adresse
sondern eine Funktionelle! Im dritten Headerbyte sehen wir das nur eine ECU
(F1 = Motorsteuergerät) geantwortet hat.
Darauf folgt das Echo vom Mode + 40h und dann das Echo des angefragten PID.
Jeder der nachfolgenden 4 Bytes enthält die Info für 8 PID’s
BE
3E
A8
11
enthält die Pid’s von 01 – 8h
(unterstützte PID’s aus dem Golf)
Ein Byte enthält 8 Bit, das MSB enthält den ersten PID, das LSB den letzten PID.
Unten sehen sie ein Bsp. Für das erste Byte BE
MSB
BEh
PID Nr.
=
LSB
1
0
1
PID 1 PID 2 PID 3
unterstützt? OK
X
OK
1
1
1
1
0
PID 4
PID 5
PID 6
PID 7
PID 8
OK
OK
OK
OK
X
Tabelle 4.11
- 37 -
Dokumentation V1.0
Analog zu diesem Beispiel werden die 3 weiteren Bytes ausgewertet.
Die Anwender Software sollte dann bevor sie irgendeinen Sensorwert abfragt und
auf dem Bildschirm darstellt, mit z.B. einer UND Maskierung prüfen, ob das
entsprechende Bit für den PID (der ja die vorhandenen Sensoren verkörpert) auf 1
gesetzt ist. Wollen wir z.B. die aktuelle Geschwindigkeit auslesen, dann schauen wir
in der PID Tabelle nach, welcher PID die Geschwindigkeit darstellt, dann überprüfen
wir im zweiten Byte (3Eh) ob das Bit für den PID 0dh gesetzt ist.
Da es auf 1 gesetzt ist können wir nun die entsprechende Anfrage an das Interface
senden.
Request Response
2
6
01h
0dh
Beschreibung
1. Command senden
2. Positiver Resp.
3. sende Mode
4. sende PID
Tabelle 4.12 Anfrage Geschwindigkeit
Die Antwort sieht dann folgender maßen aus:
Response (Antwort)
vom Interface
generiert
Header
Länge
der
Echo vom folgenden
Ziel
ECU
Command Bytes
Typ Adresse Adresse
2
07h
48h 6Bh
F1
Datenfeld
Mode +
40h
41h
CRC
Geschwindigkeit
PID 1 Byte siehe
CheckEcho PID Tabelle
summe
0dh 0h
11h
Tabelle 4.13
Laut PID Tabelle wird die Geschwindigkeit in 1 Byte dargestellt. Eine Umrechnung ist
bei diesem PID nicht notwendig. Wir können also Geschwindigkeiten von 0 – 255
KMH auslesen.
In unserem Beispiel steht das Fahrzeug gerade, da ja 0h.
Wollen wir weitere Sensorwerte abfragen geschieht dies nach dem gleichen
Schema.
- 38 -
Dokumentation V1.0
4.2
Fehlerdiagnose
Als erstes prüft man ob der Fehlerspeicher der ECU Fehler abgespeichert hatte, und
wenn ja wie viele Fehler wurden abgespeichert.
Diese Information steckt in Mode 1 PID 1.
Eine Antwort könnte folgender maßen aussehen:
Response (Antwort)
vom Interface generiert
Echo vom Länge der
folgenden
Command Bytes
2 0Ah
Header
Ziel
Typ
Datenfeld
ECU
Adresse Adresse
6Bh
F1
48h
CRC
Check-
Mode +
40h
PID
Echo
41h
01h
82h 07h
summe
E5h E5h 58h
Tabelle 4.14
Die wichtige Information für uns steht nach dem PID, also der Wert 82h.
Dieses Byte enthält im MSB ein Statusbit (ob die MIL gesetzt ist). In den übrigen 7
Bit steckt die Information der Fehleranzahl.
Um dies zu verdeutlichen betrachten wir das Byte als Binärwert.
MSB
82h
=
1
LSB
0
0
MIL
0
0
0
1
0
Anzahl Fehler
Tabelle 4.15
Die MIL in der Armaturen Tafel leuchtet, und es sind 2 Fehler abgespeichert.
Für alle Neugierigen die es interessiert welche ECU die Fehler gespeichert hatte,
brauchen dazu nur das dritte Byte im Header anschauen, und der Tabelle 5 die Art
des Steuergerätes entnehmen. Diese Information wird auch bei meinem
Diagnosegerät ausgegeben.
Die zugehörigen Fehlercodes können wir dem Mode 3 entnehmen, dieser benötigt
keine PID’s.
Die Antwort sieht dann folgendermaßen aus:
Response (Antwort)
vom Interface generiert
Echo vom Länge der
folgenden
Command Bytes
2 0Ah
Header
Ziel
Typ
48h
Datenfeld
CRC
Check-
Mode+40h Fehlercodes max. 3 / je 2 Byte
43h
04h 07h 04h 03h 0h 0h
summe
58h
ECU
Adresse Adresse
6Bh
F1
Tabelle 4.16
Das Datenfeld enthält bei Mode 3 immer 7 Byte
Nach dem Mode Echo folgen 6 Byte, jeder Fehlercode enthält 2 Byte und muss
dadurch paarweise entschlüsselt werden.
- 39 -
Dokumentation V1.0
In unserem Bsp. haben wir 2 Fehler (je 2 Byte). Um die Länge von 7 Byte für das
Datenfeld einzuhalten müssen die restlichen Bytes mit 0 aufgefüllt sein. Ein
Fehlercodepaar aus Nullen bedeutet: kein Fehler für diese Paar).
Das high nibble vom HB also die 0 von 04h wird nun durch 2 Ziffern ersetzt.
high nibble Ersatz
Bedeutung
(HB)
0
P0
Antrieb Codes - SAE definiert
1
P1
Antrieb Codes - Hersteller definiert
2
P2
Antrieb Codes - SAE definiert
3
P3
Antrieb Codes - unverbindlich definiert
4
C0
Chassis Codes - SAE definiert
5
C1
Chassis Codes - Hersteller definiert
6
C2
Chassis Codes - Hersteller definiert
7
C3
Chassis Codes - reserviert für Zukunft
8
B0
Karosserie Codes - SAE definiert
9
B1
Karosserie Codes - Hersteller definiert
A
B2
Karosserie Codes - Hersteller definiert
B
B3
Karosserie Codes - reserviert für Zukunft
C
U0
Netzwerk Codes - SAE definiert
D
U1
Netzwerk Codes - Hersteller definiert
E
U2
Netzwerk Codes - Hersteller definiert
F
U3
Netwerk Codes - reserviert für Zukunft
Tabelle 4.17
Für unser Bsp. 0407h bedeutet das, das wir die 0 durch P0 ersetzen müssen.
Nun werden das low nibble vom HB und das kpl. LB also 407h an die beiden Ziffern
angehängt.
Der kpl. Fehlercode lautet nun P0407. Zu jedem Fehlercode gibt es im Internet
genug Informationsmaterial, die ganze Palette darzustellen würde denn Rahmen der
Dokumentation sprengen. Für unser Bsp. lautet die Fehlerbeschreibung:
„P0407 Abgas-Rückführ-System (EGR) Sensor B Schaltkreis zu niedrig“.
Ich denke dass für die Reparatur des Fehlers Ein Handbuch des Fahrzeuges oder
eine solide Kraftfahrzeugmechaniker Ausbildung von Vorteil wäre.
Nach der Fehlerbehebung werden wir feststellen dass die MIL in der Armaturen Tafel
nicht erlischt und der Fehlerspeicher immer noch zwei Fehler anzeigt. Der Grund
dafür liegt darin, das Die ECU auch sporadische Fehler erkennen muss und
abspeichert. Sie kann ja nicht wissen, ob der Fehler wirklich behoben ist oder nur
sporadisch auftaucht.
Mit Mode 7 werden nur die Fehler ausgegeben die aktuell vorhanden sind. Die
Auswertung erfolgt analog zu Mode 3.
Um die MIL auszuschalten und den Fehlerspeicher der ECU zu löschen, senden wir
nach dem Command 2 für das Interface den Mode 4 ohne PID.
Als Antwort bekommen wir im Datenfeld nur das Echo zu Mode 4, also 44h.
- 40 -
Dokumentation V1.0
5. Software
5.1
Programmstruktur
Während der Testphase wurden die einzelnen Funktionen fortlaufend programmiert.
Später als die Anzahl der Funktionen zunahm, segmentierte ich die Funktionen nach
Verwendungszweck. Die Übersichtlichkeit nahm dadurch (hoffentlich auch für
Außenstehende) zu. Die Software wurde mit Keil µ-Vision 3 erstellt.
Bild 5.1
- 41 -
Dokumentation V1.0
5.2
Headerfiles
Die Header sollen die Schreibarbeit der einzelnen Funktionen reduzieren, je nach
Bedarf können sie in die gewünschte Funktion implementiert werden. Eine
Anpassung an andere Prozessortypen wird dadurch erleichtert.
stdlpc932.h
Die Header werden von mehreren Funktionen genutzt, wenn eine Funktion eine
andere aufruft, die das gleiche File schon eingebunden hatte, kann es zu Problemen
wie auch bei mir, zu Warnungsmeldungen beim kompilieren kommen.
Der Steuerparameter „ifndef“ fragt nun ab, ob dieses Headerfile schon einmal
eingebunden wurde. Wenn dies schon geschehen ist springt er ans Ende des Files.
Der Steuerparameter „pragma OT()“ optimiert beim kompilieren den Quelltext. Je
nach Übergabewert 1-9 wird auf Geschwindigkeit oder Codeeinsparung optimiert.
Mit dem Übergabewert 9 reduzierte sich der Quelltext nochmals um 67 Byte.
definitionen.h
In diesem File wurde jedem Portpin ein Name zugewiesen. So kann im
Programmtext anstatt P0.3 der Name OK (für die Taste OK) verwendet werden.
Die Anschlussbelegung der Ports kann dem Kapitel Hardware entnommen werden.
Konstante Werte die bei Bedarf verändert werden, wurden ebenfalls mit einem
Namen definiert.
globale_variablen.h
Variablen, auf die von mehreren Funktionen aus zugegriffen wird, werden in diesem
File global (für alle Funktionen) implementiert. Die Funktion globale_variablen.c
initalisiert die Variablen einmal mit einem festen Wert.
funktionen.h
Genau wie die Variablen, sind alle Funktionen in einem Header geschrieben. Es
muss bei Bedarf jetzt nur einmal funktionen.h inkludiert werden.
- 42 -
Dokumentation V1.0
5.3
Interruptus
Bei Auftreten eines Interruptus wird der aktuelle Programmablauf unterbrochen und
es wird in die Interrupt Service Routine (ISR) gesprungen. Nach Abarbeitung der ISR
erfolgt der Rückssprung an der zuvor gestoppten Programmstelle.
Eine Vergabe von Interruptprioritäten war für mein Projekt nicht notwendig.
taste_m
Bei betätigen der Taste <m> soll ein Rücksprung ins vorherige Menü signalisiert
werden. Es setzt ein globales Flag auf 0. Dieses wird dann in der jeweiligen Funktion
ausgewertet.
rtc
Nach Überlauf der RTC (100ms) wird eine globale Variable inkrementiert nach jedem
10 ten Einsprung (1s) wird eine zweite Variable für die Sekunden inkrementiert und
die Variable für die Zehntel Sekunden wird rückgesetzt.
seriell
Der Einsprung erfolgt jedes Mal wenn ein Byte versendet oder empfangen wurde.
Die ISR setzt das Sende und Empfangsflag zurück und prüft ob beim Empfang ein
Framing Error, Break dedekt, d.h. wenn mehr als 11 aufeinander folgende 0
empfangen wurden (z.B. bei einem Leitungsschluss) oder wenn der Empfangspuffer
von einem neuen Wert überschrieben wurde eingetreten ist.
Bei einer dieser Fehler wird ein globales Flag gesetzt.
5.4
Funktionen
Die einzelnen Funktionen werden in diesem Kapitel fortlaufend, mit Hilfe von
Struktogrammen beschrieben. Die Reihenfolge habe ich so ausgewählt dass der
Trend von den „Hilfsfunktionen“ zu den „Hauptfunktionen“ verläuft.
zeit( unsigned int Zeit in ms)
Die Funktion bekommt die Wartezeit in ms übergeben.
Die innere Schleife wird benötigt da sonst zu große Werte übergeben werden
müssten.
- 43 -
Dokumentation V1.0
initalisierung ()
Hier werden alle notwendigen Einstellungen für den LPC gesetzt
Es wird ein Resetimpuls von 5 Sekunden Dauer für das Interface erzeugt. Somit
beginnt das Interface auch nach einem Reset erst nach dieser Zeit mit der
Initialisierung (Protokollsuche).
- 44 -
Dokumentation V1.0
Lcdtreiber (Assembler)
Der Treiber für das LC-Display wurde freundlicherweise von Herrn Sperling zur
Verfügung gestellt. Der Treiber beinhaltet mehrere C kompatible Unterprogramme
die nach Bedarf aus den Funktionen aufgerufen werden.
Folgende Unterprogramme habe ich für mein Projekt verwendet:
init_display():
Initialisiert das Display, wird auch zum löschen des
Display Inhaltes verwendet.
printchar(char):
stellt den übergebenen Character-Wert als ASCI Zeichen
auf dem Display dar.
moveto(char,char): positioniert den Cursor an die Übergebene (Zeile/Spalte).
printhex(char):
stellt den Übergebenen Character-Wert als Hex Zahl
auf dem Display dar.
char putchar (char)
Das Display ist kompatibel zu dem Standart ASCI Code, bei der Verwendung der
Funktion printf() werden Sonderzeichen wie z.B. „ä“ oder „ü“ als Character-Wert im
Erweiterten ASCI Code Format übergeben. Auf dem Display erscheint dann alles,
nur nicht das gewünschte Zeichen. Ein Blick ins Datenblatt ließ erkennen, dass die
Sonderzeichen zwar ausgegeben werden können, dazu muss dann aber ein anderer
Wert als der im erweiterten ASCI Code übergeben werden. Mit dieser geänderten
Version wird jetzt wie gewohnt das Sonderzeichen 1 zu 1 ausgegeben. Ich habe nur
die Sonderzeichen verändert die auch in meinem Projekt verwendet wurden, je nach
Bedarf kann die Liste analog dazu erweitert werden. Mit dem Zeichen § wird
automatisch in die dritte Zeile gesprungen, so kann ein Fehlermeldungstext auch
mehr als 20 Buchstaben aufweisen ohne dazu die Funktion moveto benutzen zu
müssen.
.
- 45 -
Dokumentation V1.0
geraete_fehler (unsigned char Fehlercode)
Die Idee zu dieser Funktion entstand am Ende des Projektes. Trotz der einfachen
Menüführung stieg mit der Anzahl der Funktionen auch die Wahrscheinlichkeit, dass
sich das Gerät durch einen Bedienfehler oder sogar bei einem Defekt an irgendeiner
Stelle im Programm aufhängen könnte. Um die Fehlersuche zu erleichtern werden
an kritischen Programmpunkten wo z.B. auf externe Ereignisse wie das Interruptflag
RI beim Empfang gewartet wird, bei überschreiten eines Zeitlimits ein Fehlercode
Als Übergabewert an die Funktion geraete_fehler übergeben. Dieser wird dann auf
dem Display als „Error + den Fehlercode“ ausgegeben. Anschließend verweilt das
Programm in einer Dauerschleife. Vielleicht kann man das als eine Art
OnBoardDiagnose im Diagnosegerät bezeichnen.
Error
Ursache
Fehlerbeschreibung
1
Das Interface hatte sich nach dem Start
innerhalb 30 nicht initialisieren können > die Status LED bleibt dunkel
Prüfen ob Zündung am Auto eingeschaltet ist!
Wenn das ohne Erfolg bleibt wurde keine OBD2
kompatible ECU im Fahrzeug gefunden
2
Die Chip Indent Nr. vom
OE90C2600 im Interface ist ungültig
Falscher Controller im Interface
oder er ist defekt und antwortet falsch
3
kein OBD2 Protokoll gefunden
Das Interface hatte keines der
OBD2 gültigen Protokolle finden können
Protokoll nicht freigegeben
Es ist nur das ISO 9141-2 freigegeben Mit der
Taste <u> kann nach der Anzeige
"Verbindungsprotokoll" dennoch fortgefahren
werden
Falscher Command Response
der LPC hatte einen falschen
Command Response vom Interface empfangen > wahrscheinlich ist der LPC932 oder der
OE90C2600 auf der IF- Platine defekt
4
5
6
Datenlänge = 0
7
kein Zeichen empfangen
Das Interface hatte keine Daten vom Fahrzeug
bekommen wahrscheinlich wurde die Zündung
ausgeschalten
Jedes empfangene Byte zum LPC bekommt
ein Timeout von 1 Sekunde
8
Beim Empfang eines Bytes wurde im
LPC das
Flag für Framing Error, Break dedect,
oder Overrun Error gesetzt
Die Leitung RX P1.1 zwischen LPC und Interface
prüfen evt. Liegt ein Kurzschluss vor
- 46 -
Dokumentation V1.0
char eingabe ()
Die Funktion eingabe wertet die Tasten <u> <l> <OK> aus. Wenn keine Taste
gedrückt wurde, gibt sie als Übergabewert <n> für nichts zurück.
seriellrx ()
Die Funktion wird aufgerufen wenn ein Byte über die serielle Schnittstelle empfangen
werden soll.
- 47 -
Dokumentation V1.0
kommunikation (char Command, char Mode, char PID)
Dieser Funktion muss nur ein Command, ein Mode, und ein PID übergeben werden
Sie sendet dann die Anfrage an das Interface und speichert anschließend das
empfangene Frame in ein globales Array zur Weiterverarbeitung ab.
Für Commands die kein Mode bzw. für Modes die kein PID benötigen wird als
Übergabewert eine 0 übergeben.
- 48 -
Dokumentation V1.0
beschleunigung ()
Die Funktion stellt ein Untermenü vom Hauptmenü dar. Der Benutzer wird über ein
Menü dazu aufgefordert, eine Start und eine Stopp Geschwindigkeit einzustellen.
Nun wird kontinuierlich die aktuelle Geschwindigkeit abgefragt wenn die
Startgeschwindigkeit überschritten ist, wird eine Variable für die Zehntel Sekunden
und eine Variable für die Sekunden mit Hilfe der RTC hoch gezählt. Nach Erreichen
der End-Geschwindigkeit wird die benötigte Zeit ausgegeben.
- 49 -
Dokumentation V1.0
printwert (char Formatparameter)
Einige Sensorwerte wie z.B. die Kühlwasser / Öl Temperatur müssen bevor sie auf
dem Display ausgegeben werden, erst umgerechnet werden.
Bsp.: die Kühlwassertemperatur PID 05h kann zwischen -40° und +215° liegen.
1 Byte kann aber nur die werte 0 - 255 enthalten. Also muss der Ausgabefunktion
der Wert - 40 übergeben werden. Zur Code Einsparung habe ich beispielsweise
anstatt Wert x 100/128 die Umrechnung mit Wert x 25/32 gemacht.
Bei der Ausgabe eines Sensorwertes wird außerdem auf die Positionseinhaltung der
Tausender, Hunderter, Zehner und Einer geachtet. Bei schnellen Potenzwechseln
wie z.B. bei der Drehzahl wäre es sonst für den Betrachter unmöglich die Zahl
abzulesen.
Folgende 6 Übergabewerte werden akzeptiert und ausgegeben:
1 = 0 – 255
4 = - 64 - +64
2 = 0 - 100%
5 = -40 - +215
3 = -100% - +100% mit Vorzeichen
6 = 0 - 16556
- 50 -
Dokumentation V1.0
sensorwerte ()
Die Funktion stellt ein Untermenü des Hauptmenüs dar.
Sie gibt acht aktuelle Sensorwerte auf dem Display aus. Vor jeder Ausgabe wird mit
einer UND Maske geprüft ob der jeweilige PID auch gesetzt ist d.h. ob er unterstützt
wird. Falls das PID nicht gesetzt ist wird er auch nicht dargestellt.
- 51 -
Dokumentation V1.0
fehlerdiagnose ()
In diesem Menüpunkt wird mit Mode 1 PID 1 geprüft ob die MIL in der Armaturentafel
leuchtet und wie Fehler abgespeichert sind. Das wird dann wiederum auf dem LCD
ausgegeben. Der Benutzer kann zwischen den Menüpunkten aktuelle Fehler (Mode
7) und den gespeicherten Fehlern (Mode 3) auswählen. Zusätzlich gibt es noch ein
Menüpunkt Fehler löschen, bei dem der Benutzer den Fehlerspeicher rücksetzen
kann (Mode 4)
- 52 -
Dokumentation V1.0
fehlercode ()
Diese Funktion liest sämtliche Fehlercodes aus, jeder Fehlercode bekommt zur
Informationsdarstellung die kpl. vier Zeilen des LCD zur Verfügung gestellt. Mit den
beiden Tastern <u> und <l> kann der Benutzer durch die Fehlercodes des kpl.
Antwortframe scrollen, Fehlercodepaare die den Wert <00> <00> enthalten, werden
übersprungen.
- 53 -
Dokumentation V1.0
haupt()
Sie gibt das gefundene Protokoll aus, prüft den Chip ID des Interface und speichert
die unterstützten PID’s in ein globales Array ab. Außerdem stellt sie ein
Auswahlmenü für die PC / µC Bedienung sowie das Hauptmenü für die weiteren
Menü Punkte dar.
- 54 -
Dokumentation V1.0
6. Bedienung des Diagnosegerätes
6.1 Übersicht der Bedienelemente
Bild 6.1 Übersicht
- 55 -
Dokumentation V1.0
6.2
Diagnosefunktionen
Anmeldevorgang
Nach dem Start versucht das Diagnosegerät einen Verbindungsaufbau zum KFZ
herzustellen
Bild 6.2
Nach erfolgter Anmeldung kann der Benutzer jetzt wählen ob er die Diagnose mit
einem PC über die RS232 Schnittstelle oder lieber mit dem µController gesteuerten
Diagnosegerät durchführen möchte.
Bild 6.3
Ist eine Diagnose mit dem PC erwünscht kann der Benutzer nach dem bestätigen,
den PC mit der Sub-D-Buchse auf der Stirnseite des Diagnosegerätes verbinden.
Die mitgelieferte (1:1) RS232 Verbindungsleitung kann als Verbindungsleitung zum
PC sowie als Verlängerungsleitung für den OBD2 Anschluss verwendet werden. Das
ermöglicht ein arbeiten im Motorraum.
Die Software für den Pc wie z.B. Scanmaster wird im Internet kostenlos zur
Verfügung gestellt. Auf die Bedienung der jeweiligen Software gehe ich hier nicht ein.
Bild 6.4
Wurde der Reiter µC ausgewählt und bestätigt, so wird jetzt für ca. 5 Sekunden das
Verbindungsprotokoll angezeigt. Das Diagnosegerät ist nur für das ISO 9141-2
Protokoll freigegeben. Sollte ein anderes Protokoll angezeigt werden wird auf dem
Display „Nicht freigegeben“ erscheinen. Der Benutzer hat jetzt die Möglichkeit, durch
längeres drücken der Scrolltaste <nach oben>, die Diagnose dennoch fortzusetzen.
Für die meisten anderen Protokolle werden sie keine Veränderungen feststellen.
Beim KWP 2000 und dem CAN Protokoll kann es jedoch vorkommen ,dass der ein
oder andere Wert im Menü nicht richtig dargestellt wird.
Bild 6.5
- 56 -
Dokumentation V1.0
Hauptmenü
Der Benutzer kommt jetzt zum Hauptmenü. Durch scrollen und anschließendem
bestätigen kann in eines der Untermenüs gesprungen werden. Das Hauptmenü ist
immer Ausgangspunkt der Untermenüs.
Bild 6.6
Menüpunkt „Fehler Diagnose“
In der ersten Zeile wird angezeigt ob die MIL (Motorstörungslampe) in der Armaturen
Tafel leuchten sollte. Auch wenn sie nicht leuchtet ist es möglich das Fehler
vorhanden sind. Der Untermenüpunkt „aktuelle Fehler“ zeigt alle Fehler an die aktuell
vorhanden sind. Der Menüpunkt gespeicherte Fehler zeigt alle aufgetretenen Fehler
seit der letzten Fehlerlöschung an. Es werden sporadische sowie aktuelle Fehler in
diesem Menüpunkt angezeigt.
Bild 6.7
Die Fehlercodes der beiden Menüpunkte werden nach dem gleichen Schema
dargestellt. Sind mit dem jeweiligen Untermenüpunkt keine Fehler auffindbar,
bekommt der Benutzer eine Meldung „Keine“ angezeigt. Nach ca. 3 Sekunden erfolgt
automatisch ein Rücksprung ins Menü. Wenn Fehler vorhanden sind wird jeder
Fehler in einem separaten Fenster angezeigt. Mit den Scroll Tasten kann nun durch
die ganze Liste der Fehler gescrollt werden. In der ersten Zeile wird das Steuergerät
dargestellt welche den Fehler gefunden hatte.
Die zweite Zeile stellt den genormten OBD2 Fehlercode dar. In der dritten und
vierten Zeile wird für einige Fehlercodes eine kurze Fehlerbeschreibung
ausgegeben, falls die Info „Fehlerbeschreibung siehe Handbuch“ ausgegeben wird
können sie im Internet z.B. bei google die Beschreibung zu dem Fehlercode (in der
zweiten Zeile) finden.
Bild 6.8
Mit der Taste <m> kehren sie nun zurück zum Menüpunkt Fehlerdiagnose.
Mit dem bestätigen des Untermenüpunkt „Alle Fehler löschen“ bekommen sie zur
Sicherheit nochmals eine Auswahl dargestellt. Mit der Taste <m> kehren sie wieder,
wie gewohnt zurück ins Menü. Mit betätigen von <OK> setzen sie den
Fehlerspeicher sämtlicher OBD2 kompatiblen Steuergeräte im Fahrzeug zurück. Des
Weiteren werden die Onboard Logfiles verschiedener Sensoren wie z.B. der
- 57 -
Dokumentation V1.0
Lambdasonde zurückgesetzt (gelöscht). Bei einem neuen Motorstart werden diese
dann wieder neu geschrieben.
Bild 6.9
Wenn sie bestätigt haben, bekommen sie Nochmals eine Meldung ob die FehlerLöschung erfolgreich getätigt wurde.
Zu beachten ist, dass die Steuergeräte erst im Betriebszustand der Sensoren d.h.
während der Fahrt prüfen können, ob der Sensor oder das Stellglied richtig arbeitet.
Führen sie also eine Testfahrt durch, und lesen anschließend den Fehlerspeicher
nochmals aus.
Menüpunkt „Sensordaten“
In diesem Menüpunkt werden die Echtzeitdaten von max. acht Sensoren
ausgegeben. Es wird dargestellt der Lastwert des Motors, die Öl / Kühlwasser
Temperatur, die Drehzahl des Motors, die Geschwindigkeit, der Zündwinkel, die
Drosselklappenstellung, der Einspritzdruck und die Einspritzmenge.
Für ausführliche Informationen über die Bedeutung der einzelnen Werte, bitte ich Sie
in entsprechender Fachliteratur nachzuschlagen.
.
Bild 6.10
Menüpunkt „Beschleunigung“
Hier wird der Benutzer aufgefordert durch scrollen, eine Startgeschwindigkeit
auszuwählen. Nach dem bestätigen wird wiederum durch scrollen eine EndGeschwindigkeit ausgewählt. Jetzt sollte das Fahrzeug in die Ausgangslage
gebracht werden. Wurde z.B. als Startgeschwindigkeit 0 KMH und als Endgeschwindigkeit 100 KMH ausgewählt, wartet das Diagnosegerät nun darauf, dass
der Fahrer mit dem Sprint beginnt. Nach dem überschreiten von 100 KMH wird auf
dem Display die benötigte Zeit und die Start / End-Geschwindigkeit dargestellt.
Bild 6.11
- 58 -
Dokumentation V1.0
6.2
Wartungshinweise
Sollte während dem Betrieb eine Meldung mit einem „Error + Fehlercode“
erscheinen,
Bild 6.12
dann prüfen sie bitte ob die Zündung eingeschalten ist. Danach starten sie das
Programm neu, mit Hilfe der Taste Reset.
Wenn der „Error“ nicht verschwinden sollte, senden sie bitte an die oben genannte
Adresse eine E-Mail.
Bitte verwechseln sie diesen Meldungstyp nicht mit den OBD2-Fehlercodes im KFZ.
Er weißt ausschließlich auf einen Bedienungs- oder Geräte Fehler hin.
Wartungs- oder Kalibrier Maßnahmen sind für das Gerät nicht erforderlich.
Die Versorgungsspannung wird aus der Diagnosebuchse vom Fahrzeug
bereitgestellt. Bei Spannungsspitzen kann es vorkommen dass die
Schmelzsicherung im Diagnosegerät ausgetauscht werden muss. Der innere Aufbau
des Gerätes gleicht einer Sandwichbauweise. Das Mainboard wird zwischen den
beiden Gehäusehalbschalen fixiert. Beim Zusammenbau müssen sie evt. Mit einer
Hand die obere Gehäuseschale seitlich leicht zusammen drücken, um das
Mainboard in den Führungsbolzen arretieren zu können.
7. Anhang
7.1
Informationsquellen
Bücher:
Michael Baldischweiler
C51 Teil 1 & 2
Zeitschriften:
ELEKTOR 10 & 11/2002 Fahrzeugdiagnose mit ELM
ELEKTOR 7/2005
Ausgabe der verwendeten
Interface Schaltung
Internet:
www.obd-2.de
Infos über OBD2, PID/Mode Tabelle
www.ozenelektronik.com Datenblätter & Komponenten für
OBD2
www.elmelectronics.com Datenblätter
www.troublecodes.net
Fehlercodebeschreibung
www.wgsoft.de
Anwendersoftware für den PC
- 59 -
Dokumentation V1.0
7.2
Zeitaufwand
Stundenverteilung TA D.Beutner OBD2-Diagnosegerät
Software
Hardware
80
120
Dokumentation
40
Feintuning und Tests
70
50
Informationsbeschaffung
& Auswertung
Bild 7.1
7.3
Fazit
Nun ist es so weit, nach 10 Monaten ist das Projekt „OBD2 Diagnosegerät“ beendet
worden. Alle Punkte des Pflichtenheftes wurden ohne Abweichungen erfüllt.
Obwohl ich einige schöne Sommertage und Wochenenden an meinem Computer
oder in meinem zweiten Arbeitsplatz, dem Auto verbrachte, fand ich bis auf wenige
Momente die Arbeit und das direkte Testen am Fahrzeug sehr spannend.
Mögliche Erweiterungen für zukünftige Technikerarbeiten wären z.B. das Einbinden
weiterer Protokolle, oder/und die Auswertung weiterer Mode. Selbst der Einbau als
Bordcomputer im Fahrzeug wäre möglich.
Bedanken möchte ich mich bei meinen Lehrern Herr Sperling und Herr Gross für die
Unterstützung bei technischen Fragen, sowie bei Herrn Karrer für die Material und
Messgeräte Versorgung.
Zuletzt möchte ich Tanja Glatt und Dennis Auer für die Erstellung der FrontplattenFolie danken.
- 60 -

Technikerarbeit 2005/2006 OBD2 - Diagnosegerät

Transcription

Similar documents

060132-1-D RFID-Leser

7. Schnittstellen-Technik, Interfaces

Bedienungsanleitung

Rechenschaltungen bauen: ein Praktikumsgang in Informationstech

CarCode Müller ElmCan OBD2/EOBD Interface

µC gesteuertes RFID Zeiterfassungsterminal, Hartmann, Marc

WGSoft.de - Automotive Diagnostic Software (OBD, OBD

hohenheimer mitteilungen - Staatsschule für Gartenbau und die

Eigenbau-Gehäuse

Anleitung AGV 2055