- UDS (Unified Diagnostic Services, ISO 14229) ist das Diagnoseprotokoll moderner Steuergeraete.
- Der Service 0x22 ReadDataByIdentifier liest gezielt einzelne Datenwerte ueber zweibyte lange Identifier (DID) aus.
- Anders als generisches OBD2 erreicht UDS den vollen herstellerdefinierten Datenumfang eines Steuergeraets.
- Ueber Identifier lassen sich Messwerte, Teilenummern, Softwarestaende und Codierdaten praezise abfragen.
- Herstellertiefe Diagnose arbeitet durchgaengig mit UDS, weil generisches OBD2 nur einen Bruchteil sichtbar macht.
Vom Fehlercode zum echten Messwert
OBD2 zeigt einen Fehlercode an. UDS zeigt, was im Steuergeraet wirklich vorgeht. Dieser Unterschied entscheidet darueber, ob eine Diagnose eine fundierte Vermutung bleibt oder ein belastbarer Befund wird.
Was UDS ist und warum es OBD2 ergaenzt
Unified Diagnostic Services, kurz UDS, ist in der Norm ISO 14229 festgelegt. Es definiert eine Sprache, in der ein Diagnosegeraet mit einem Steuergeraet kommuniziert. UDS umfasst zahlreiche Dienste, jeder durch einen sogenannten Service Identifier (SID) gekennzeichnet. Es gibt Dienste zum Auslesen von Fehlerspeichern, zum Steuern von Aktoren, zum Programmieren und eben zum Lesen von Daten.
Generisches OBD2 nach ISO 15031 wurde fuer die gesetzliche Abgasueberwachung geschaffen. Es kennt einen festen, herstellerunabhaengigen Satz an Parametern. Das reicht fuer eine Hauptuntersuchung und fuer einfache Motorfehlercodes, deckt aber nur einen kleinen Ausschnitt der Fahrzeugelektronik ab. UDS hingegen erreicht jedes Steuergeraet im Fahrzeug und dessen vollen, vom Hersteller definierten Datenumfang.
Der Service 0x22 ReadDataByIdentifier im Detail
Der Service 0x22 traegt den Namen ReadDataByIdentifier. Sein Prinzip ist denkbar klar: Das Diagnosegeraet sendet eine Anfrage, die den Service-Code 0x22 und einen zweibyte langen Data Identifier (DID) enthaelt. Das Steuergeraet antwortet mit dem positiven Response-Code 0x62, dem wiederholten Identifier und dem eigentlichen Datenwert.
Ein Beispiel verdeutlicht den Ablauf:
- Anfrage:
22 F1 90– lese den Datensatz mit dem Identifier F190. - Antwort:
62 F1 90gefolgt von den Datenbytes der angefragten Information.
Der Identifier F190 ist nach ISO 14229 fuer die Fahrgestellnummer reserviert. Andere Identifier liefern die Teilenummer des Steuergeraets, den Softwarestand, einen Sensorrohwert oder einen Codierdatensatz. Ein Teil der Identifier ist genormt, der grosse Rest ist herstellerspezifisch. Genau diese herstellerspezifischen Identifier machen die Tiefe aus: Ueber sie liefert das Steuergeraet Anpassungswerte, Lernwerte der Adaption und interne Betriebszustaende, die ein generisches Geraet nicht kennt.
Wie das Steuergeraet antwortet und absichert
Antwortet das Steuergeraet nicht mit 0x62, sondern mit dem negativen Response-Service 0x7F, liegt ein definierter Grund vor. Der mitgesendete Negative Response Code benennt ihn, etwa requestOutOfRange bei einem unbekannten Identifier oder securityAccessDenied, wenn der angefragte Datensatz erst nach einer Freischaltung lesbar ist.
Dieser Schutzmechanismus ist wichtig: Sicherheitsrelevante oder schreibgeschuetzte Daten gibt das Steuergeraet erst frei, wenn sich das Diagnosegeraet ueber den Service 0x27 SecurityAccess authentifiziert hat. Eine geordnete Diagnosesitzung beginnt deshalb meist mit dem Service 0x10 DiagnosticSessionControl, der die passende Sitzungsebene aktiviert. Erst danach liefern viele Identifier ihre Werte. Wer hier ohne den richtigen Zugang arbeitet, sieht nur die oberflaechlichen Daten.
Für Techniker: Aufbau einer 0x22-Anfrage und der Antwort
Eine 0x22-Anfrage ist denkbar kompakt aufgebaut: Auf das Service-Byte 0x22 folgen ein oder mehrere zweibyte lange Data Identifier. Theoretisch lassen sich in einer Anfrage mehrere DIDs hintereinander anfordern; das Steuergeraet beantwortet sie dann in einer Antwortbotschaft. In der Praxis begrenzen die Hersteller diese Sammelabfrage haeufig.
Die positive Antwort beginnt mit 0x62 (das ist 0x22 plus 0x40, der genormte Offset fuer positive Antworten), gefolgt vom wiederholten Identifier und den eigentlichen Datenbytes. Die Laenge und Interpretation dieser Datenbytes ist je DID festgelegt – ein Temperaturwert kann ein Byte mit einem Offset belegen, eine Teilenummer mehrere ASCII-Zeichen, ein Codierdatensatz einen ganzen Block. Reicht die Antwort ueber die Buslaenge einer einzelnen Botschaft hinaus, wird sie ueber die Transportschicht (ISO-TP nach ISO 15765-2) in mehrere Frames segmentiert und beim Empfaenger wieder zusammengesetzt. Genau diese Segmentierung ist der Grund, warum ein Diagnosegeraet auch grosse Datensaetze wie komplette Codierbloecke ueber 0x22 zuverlaessig auslesen kann.
Warum herstellertiefe Diagnose auf 0x22 aufbaut
Die Diagnose komplexer Fehler beginnt fast immer mit dem Lesen der richtigen Identifier. Stimmt ein Sensorrohwert nicht mit dem physikalischen Zustand ueberein, zeigt sich das im Datenwert ueber 0x22, lange bevor ein Fehlercode gesetzt wird. So entstehen Befunde statt Vermutungen.
UDS ist auch die Grundlage von Codierung und Programmierung. Bevor ein Steuergeraet neu codiert wird, liest man ueber 0x22 den aktuellen Codierdatensatz aus. Den Unterschied zwischen Codierung und ECU-Programmierung beleuchten wir gesondert, ebenso die SCN- und SVM-Codierung mit Herstellerdiagnose. Wie UDS in das groessere Gefuege aus CAN und DoIP eingebettet ist, beschreibt unser Beitrag zur Tiefendiagnose ueber CAN, DoIP und UDS.
Damit UDS-Anfragen das Steuergeraet ueberhaupt erreichen, muss die physische Schnittstelle stimmen. Welche Pins der OBD2-Buchse die Diagnosekommunikation fuehren, erklaeren wir im Beitrag zur OBD2-Pin-Belegung nach SAE J1962. Der grundlegende Unterschied zwischen einfachem Auslesen und Codierung gegenueber generischem OBD wird durch das Verstaendnis von 0x22 erst nachvollziehbar.
Genormte und herstellerspezifische Identifier
Der Wertebereich der Data Identifier ist nach ISO 14229 in Bloecke gegliedert. Ein Teil ist fest genormt und ueber alle Hersteller hinweg gleich belegt – darunter F190 fuer die Fahrgestellnummer, weitere Identifier fuer Hardware- und Softwareversionen, Teilenummern oder den ECU-Hersteller. Diese genormten Werte erleichtern eine herstelleruebergreifende Grunddiagnose, weil ihre Bedeutung dokumentiert und stabil ist.
Der weitaus groessere Teil des DID-Bereichs ist jedoch herstellerspezifisch. Hier hinterlegt jeder Hersteller die Identifier fuer Sensorrohwerte, Lernwerte der Adaption, Betriebszaehler und interne Zustaende nach eigener Systematik. Welcher DID welchen Messwert liefert, ist nur ueber die jeweilige Herstellerdokumentation und die passende Diagnosesoftware verlaesslich bekannt. Genau an dieser Stelle trennt sich die oberflaechliche Diagnose von der herstellertiefen: Ein universelles Auslesegeraet kennt die genormten DIDs, aber selten die herstellerspezifischen, die fuer die eigentliche Fehlersuche entscheidend sind.
Was das fuer die Praxis bedeutet
Fuer die Werkstattarbeit heisst das: Die Qualitaet einer Diagnose haengt nicht nur am Protokoll, sondern am Zugang zu den richtigen Identifiern und ihrer korrekten Interpretation. Ein Sensorrohwert ist nur dann aussagekraeftig, wenn wir wissen, wie er skaliert ist und welcher Sollbereich gilt. Mit der herstellergerechten Software und dem Wissen um die hinterlegten DIDs vergleichen wir gemessene Rohwerte mit den Vorgaben und erkennen Abweichungen, lange bevor das Steuergeraet einen Fehlercode setzt. So wird aus dem schlichten Auslesen eines Codes eine belastbare Systemanalyse.
Unser Anspruch an die Diagnose
Wir lesen nicht nur Fehlercodes, sondern die Datenwerte dahinter. Ueber den Service 0x22 erfassen wir die tatsaechlichen Zustaende eines Steuergeraets, vergleichen Rohwerte mit Sollvorgaben und dokumentieren das Ergebnis nachvollziehbar. Diese Praezision ist die Grundlage dafuer, dass eine Reparatur die Ursache trifft und nicht nur ein Symptom verdeckt. Genau darin liegt der Wert herstellertiefer Diagnose: Sie schuetzt die Substanz des Fahrzeugs und Ihre Investition.
KFZ Dietrich Meckelstraße 8, 37181 Hardegsen Telefon: 05505 5236 Öffnungszeiten: Mo–Fr 07:30–16:30 Uhr