- UDS (Unified Diagnostic Services, ISO 14229) ist das Diagnoseprotokoll moderner Steuergeräte.
- Der Service 0x22 ReadDataByIdentifier liest gezielt einzelne Datenwerte über zweibyte lange Identifier (DID) aus.
- Anders als generisches OBD2 erreicht UDS den vollen herstellerdefinierten Datenumfang eines Steuergeräts.
- Über Identifier lassen sich Messwerte, Teilenummern, Softwarestände und Codierdaten präzise abfragen.
- Herstellertiefe Diagnose arbeitet durchgängig mit UDS, weil generisches OBD2 nur einen Bruchteil sichtbar macht.
Vom Fehlercode zum echten Messwert
OBD2 zeigt einen Fehlercode an. UDS zeigt, was im Steuergerät wirklich vorgeht. Dieser Unterschied entscheidet darüber, ob eine Diagnose eine fundierte Vermutung bleibt oder ein belastbarer Befund wird.
Was UDS ist und warum es OBD2 ergänzt
Unified Diagnostic Services, kurz UDS, ist in der Norm ISO 14229 festgelegt. Es definiert eine Sprache, in der ein Diagnosegerät mit einem Steuergerät 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 für die gesetzliche Abgasüberwachung geschaffen. Es kennt einen festen, herstellerunabhängigen Satz an Parametern. Das reicht für eine Hauptuntersuchung und für einfache Motorfehlercodes, deckt aber nur einen kleinen Ausschnitt der Fahrzeugelektronik ab. UDS hingegen erreicht jedes Steuergerät im Fahrzeug und dessen vollen, vom Hersteller definierten Datenumfang.
Der Service 0x22 ReadDataByIdentifier im Detail
Der Service 0x22 trägt den Namen ReadDataByIdentifier. Sein Prinzip ist denkbar klar: Das Diagnosegerät sendet eine Anfrage, die den Service-Code 0x22 und einen zweibyte langen Data Identifier (DID) enthält. Das Steuergerät 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 für die Fahrgestellnummer reserviert. Andere Identifier liefern die Teilenummer des Steuergeräts, den Softwarestand, einen Sensorrohwert oder einen Codierdatensatz. Ein Teil der Identifier ist genormt, der große Rest ist herstellerspezifisch. Genau diese herstellerspezifischen Identifier machen die Tiefe aus: Über sie liefert das Steuergerät Anpassungswerte, Lernwerte der Adaption und interne Betriebszustände, die ein generisches Gerät nicht kennt.
Wie das Steuergerät antwortet und absichert
Antwortet das Steuergerät 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 schreibgeschützte Daten gibt das Steuergerät erst frei, wenn sich das Diagnosegerät über 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 oberflächlichen 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 Steuergerät beantwortet sie dann in einer Antwortbotschaft. In der Praxis begrenzen die Hersteller diese Sammelabfrage häufig.
Die positive Antwort beginnt mit 0x62 (das ist 0x22 plus 0x40, der genormte Offset für positive Antworten), gefolgt vom wiederholten Identifier und den eigentlichen Datenbytes. Die Länge 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 über die Buslänge einer einzelnen Botschaft hinaus, wird sie über die Transportschicht (ISO-TP nach ISO 15765-2) in mehrere Frames segmentiert und beim Empfänger wieder zusammengesetzt. Genau diese Segmentierung ist der Grund, warum ein Diagnosegerät auch große Datensätze wie komplette Codierblöcke über 0x22 zuverlässig 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 überein, zeigt sich das im Datenwert über 0x22, lange bevor ein Fehlercode gesetzt wird. So entstehen Befunde statt Vermutungen.
UDS ist auch die Grundlage von Codierung und Programmierung. Bevor ein Steuergerät neu codiert wird, liest man über 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 größere Gefüge aus CAN und DoIP eingebettet ist, beschreibt unser Beitrag zur Tiefendiagnose über CAN, DoIP und UDS.
Damit UDS-Anfragen das Steuergerät überhaupt erreichen, muss die physische Schnittstelle stimmen. Welche Pins der OBD2-Buchse die Diagnosekommunikation führen, erklären wir im Beitrag zur OBD2-Pin-Belegung nach SAE J1962. Der grundlegende Unterschied zwischen einfachem Auslesen und Codierung gegenüber generischem OBD wird durch das Verständnis von 0x22 erst nachvollziehbar.
Genormte und herstellerspezifische Identifier
Der Wertebereich der Data Identifier ist nach ISO 14229 in Blöcke gegliedert. Ein Teil ist fest genormt und über alle Hersteller hinweg gleich belegt – darunter F190 für die Fahrgestellnummer, weitere Identifier für Hardware- und Softwareversionen, Teilenummern oder den ECU-Hersteller. Diese genormten Werte erleichtern eine herstellerübergreifende Grunddiagnose, weil ihre Bedeutung dokumentiert und stabil ist.
Der weitaus größere Teil des DID-Bereichs ist jedoch herstellerspezifisch. Hier hinterlegt jeder Hersteller die Identifier für Sensorrohwerte, Lernwerte der Adaption, Betriebszähler und interne Zustände nach eigener Systematik. Welcher DID welchen Messwert liefert, ist nur über die jeweilige Herstellerdokumentation und die passende Diagnosesoftware verlässlich bekannt. Genau an dieser Stelle trennt sich die oberflächliche Diagnose von der herstellertiefen: Ein universelles Auslesegerät kennt die genormten DIDs, aber selten die herstellerspezifischen, die für die eigentliche Fehlersuche entscheidend sind.
Was das für die Praxis bedeutet
Für die Werkstattarbeit heißt das: Die Qualität einer Diagnose hängt nicht nur am Protokoll, sondern am Zugang zu den richtigen Identifiern und ihrer korrekten Interpretation. Ein Sensorrohwert ist nur dann aussagekräftig, 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 Steuergerät 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. Über den Service 0x22 erfassen wir die tatsächlichen Zustände eines Steuergeräts, vergleichen Rohwerte mit Sollvorgaben und dokumentieren das Ergebnis nachvollziehbar. Diese Präzision ist die Grundlage dafür, dass eine Reparatur die Ursache trifft und nicht nur ein Symptom verdeckt. Genau darin liegt der Wert herstellertiefer Diagnose: Sie schützt 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