Diagnose allgemein
Diagnose ist bei den heutigen Fahrzeugen das A und O. kaum ein Vehikel kommt mehr ohne Elektronik zurecht
OBD
On Board Diagnostic System: eine Einrichtung, die eine auftretene Fehlfunktion der Motorsteuerung, insbesondere der Gemischbildung dem Fahrer anzeigt und ihn zum Werkstattbesuch veranlaßt. Zugang für die Fahrzeugdiagnose über OBD-2 ist die 16polige OBD-2 Diagnosebuchse im Fahrzeug.
UDS
Unified Diagnostic Services, ISO-Standard 14229-1 ist aus der Zusammenführung der ISO-Standards 14230-3 (KWP 2000) und 15765-3 (Diagnostics on CAN) sowie der General Motors Spezifikation GMLAN entstanden.
Neben standardisierten Kommunikationsprotokollen (ISO 14230 KWP2000 oder ISO 15765 Diagnostics on CAN) ist die Standardisierung der Beschreibung der Steuergeräte- Diagnoseschnittstelle mit ihren Diensten besonders wichtig.
Fahrzeuge mit bis zu 70 Steuergeräten, die sich auf mehrere Bussysteme unterschiedlichster Übertragungsphysik (z. B. K-Leitung, CAN High- und Low2ttuning_speed, LIN, FlexRay, MOST,...) verteilen, sind heute keine Seltenheit mehr. Die permanente Steigerung der Systemkomplexität und die große Vielzahl unterschiedlichster Diagnoseaufgaben (siehe Bild 1) haben mittlerweile zu einem erheblichen Kostenanstieg geführt. Es versteht sich von selbst, dass die Industrie versucht, gegen diese Kosten anzugehen. Als ein geeignetes Mittel hat sie die Standardisierung von nicht wettbewerbsrelevanten Diagnoseelementen für sich entdeckt.
In einem ersten Schritt wurden die Diagnoseprotokolle standardisiert, von denen in der Vergangenheit jeder Fahrzeughersteller mindestens eines entwickelt hat. Im Wesentlichen haben sich aber KWP 2000 (auf der K-Leitung) bzw. Diagnostics on CAN durchgesetzt. In naher Zukunft werden sie (neben anderen Protokollen) vom Gesetzgeber für den Zugriff auf abgasrelevante Informationen verlangt, z. B. für EOBD -Tester.
Ein weiterer Schritt zur Standardisierung von Diagnoseaktivitäten wird in der ASAM MCDArbeitsgruppe des ASAM e. V. vollzogen. Die Idee dabei ist, dass nicht nur die Übertragung der Daten vom ECU zu einem Testsystem, sondern auch der Zugriff auf Steuergeräteinformationen sowie der Austausch von Informationen zwischen den Prozesspartnern standardisiert wird. Prozesspartner können hier die Steuergeräte- und Fahrzeughersteller sowie deren verschiedene Fachabteilungen oder Unternehmensbereiche sein.
Für die verschiedenen Anwendungslösungen der Kommunikation zur Diagnoseschnittstelle in Fahrzeugen ist es wichtig, den Zugriff auf die Steuergeräte unabhängig vom jeweiligen Steuergerätebzw. Softwareversionsstand zu gestalten. Anwendungslösungen in Entwicklung, Versuch, Produktion und Kundendienst sollten nicht jedes mal komplett durchgetestet werden müssen (= einmalige Verifikation der Steuergerätekommunikation, vielfacher Einsatz).
Zunächst legt der Hersteller das Diagnoseprotokoll fest. In vielen Fällen wird ein bereits standartisiertes Protokoll gewählt. Ein Beispiel für ein solches Protokoll stehl UDS dar. Dieses Protokoll kann an die einzelnen Bedürfnisse des Kunden angepasst werden. Möglich sind zum Beispiel die unternehmensweite Adressvergabe für Steuergeräte. Die unternehmensweite Spezifikation dient als Referenz für die steuergerätespezifischen Lastenhefte. In diesen Lastenheften werden werden die steuergerätespezifischen Anpassungen vorgenommen. Für ein Motorsteuergerät kann dies ein Diagnosedienst zum Auslesen der Motordrehzahl sein. Anschließend wird das Lastenheft an den Steuergerätelieferanten übergeben.
Da es sich bei ODX um ein XML-basierendes Datenformat handelt, kann der Steuergerätelieferant die Daten ohne weitere Anpassungen und dem damit verbundenen Aufwand direkt weiter verwenden. Zusätzlich können die XML-Daten in unterschiedliche, druckbare Formate umgewandelt werden. Der Steuergerätelieferant ergänzt während der Entwicklung das ODX-Lastenheft und um Informationen, die in seinen Know-How-Bereich fallen. Typischerweise sind das Umrechnungsmethoden und Tabellen, die etwa von Sensoren, AD-Wandlern und speziellen ECU-Implementierungen abhängen.
Die In diesem bisherigen Prozessverlauf entstandene ODX-Datenbank dient schon während der Entwicklung als Eingangsformat für Testsysteme des Steuergerätelieferanten. Nach Abschluss der Testaufgaben übergibt der Lieferant eine vollständige und elektronische Steuergerätebeschreibung in XML. Diese Beschreibung dient gleichzeitig zur Abnahme des Steuergeräts durch das Testsystem des OEM. Durch die elektronische Übergabe sind die ODX-Daten jetzt genauso abnahmerelevant wie das Steuergerät selbst. Die Daten werden in der Folge in den Versuch, die Produktion und den Servicebereich eingespeist. Somit wird durch die Verwendung einer einheitlichen Datenbasis über die gesamt Prozesskette (Single-Source-Prinzip) die Diagnosefähigkeit eines Steuergeräts deutlich verbessert.
ODX-Dateninhalte
(Open Diagnostic Data Exchange)
ODX (Open Diagnostic Data Exchange, ODX-Standard (ASAM MCD-2D v2.0)) steht für einen formalen Beschreibungsstandard, der alle Informationen (Anforderung bzw. Dokumentation), die in der Fahrzeug- bzw. Steuergerätediagnose relevant sind, für Bedatung des Werkstatttesters bzw. für Software-Konfiguration zur Verfügung stellt.
In nahezu allen modernen PKW und LKW werden heute elektronische Steuerungen verbaut, die mehrere Kilobyte oder auch Megabyte an Software enthalten. Über eine spezielle Datenschnittstelle, die sogenannte Diagnoseschnittstelle, kann ein Fahrzeug-externer Werkstatt-Tester an das Netzwerk dieser Steuergeräte angeschlossen werden. Der Tester tauscht mit den Steuergeräten Informationen aus und verwendet dazu Botschaften-orientierte Protokolle. Diese Protokolle sind meist standardisiert (KWP2000 nach ISO14230, UDS nach ISO14229)
ODX beschreibt nun, wie die Botschaften dieser Kommunikations-Protokolle aufgebaut sind. Dabei wird beschrieben, wie die Sende- und Empfangsbotschaften aus einzelnen Bits oder Bytes zusammengesetzt werden, wie die Botschaften in einzelne Signale und Werte zerlegt werden und wie diese Werte aus der binären Darstellung in einen lesbaren Text oder eine physikalische Größe (Zahl mit entsprechender Einheit) umgewandelt wird.
ODX verwendet für die Beschreibung der Diagnosedaten XML, ein vom W3C Konsortium standardisiertes Format für strukturierte Informationen.
ODX wurde entwickelt von einer Arbeitsgruppe der ASAM e.V. (Association for Standardisation of Automation- and Measuring Systems) und im Mai 2004 erstmal publiziert.
Die Dateninhalte von ODX lassen sich in fünf Gruppen einteilen:
1. Diagnose (DiagLayerStructure)
2. Flashdaten (Flash)
3. Fahrzeugtopologie (Vehicle Information)
4. Kommunikationsparameter (ComParameter)
5. Steuergeräteübergreifende Abläufe (MultipleECUJobs)
Die Diagnose enthält Diagnoseprotokoll- und Steuergerätebeschreibungen. Dazu gehören Diagnosedienste und komplexere Diagnoseabläufe (Jobs, FlashJobs usw).
Der Bereich Flashdaten enthält neben den eigentliche Daten, die in ein Steuergerät geladen werden können, eine strukturierte Festlegung der physikalischen und logischen Speicherarchitektur. Es sind sowohl die Speicheradressen der einzelnen Flashbereiche als auch die Aufteilung der Code- und Datensegmente auf diesen Bereich beschrieben.
Fahrzeugtopologie trägt zum Ziel, aus der Gesamtbeschreibung aller Steuergeräte die Fahzeugvarianten zu bilden. Eine Fahrzeugvariante besteht aus Merkmalen wie etwa Dieselmotor, keine Klimaanlage, usw. Hierbei müssen die einzelnen Steuergeräte nicht erneut beschrieben werden.
Kommunikationsparameter erlauben eine strukturierte Beschreibung von für die Kommunkation verwendeten Parametern. Hierbei wird jedoch zwischen ASAM standartisierten und OEM-spezifischen Parametern unterschieden. Dies erlaubt eine Toolunabhängige Verwendung der ODX-Daten.
Steuergeräteübergreifende Abläufe: Durch die zunehmende Vernetzung von Steuergeräten wird die Überprüfbarkeit des sich ergebenden Systems und seiner Untersysteme immer komplizierter. Nur durch steuergeräteübergreifende Diagnoseabläufe können diese Systeme überprüft werden. Von besondere Bedeutung ist die für aktive und passive Sicherheitssysteme im Fahrzeug.