Kostenloses ToolUDS

UDS-Nachrichten-Decoder

UDS-Bytes aus einem Trace einfügen und sehen, was sie bedeuten: Service, Sub-Funktion, Session, DIDs, Routine Identifier, SecurityAccess-Level oder NRC, nach ISO 14229-1.

Aktualisiert 7. Oktober 2026Diese Seite als Markdown

Kurz gesagt

Dieser Decoder zerlegt einen UDS-Request oder eine Antwort aus rohen Hex-Bytes. Er erkennt den Service Identifier, unterscheidet Request, positive Antwort (SID + 0x40) und negative Antwort (0x7F), dekodiert Sub-Funktionen inklusive suppressPosRspMsgIndication-Bit, benennt Diagnose-Sessions, löst Standard-Data-Identifier für ReadDataByIdentifier und WriteDataByIdentifier auf, zeigt Routine Identifier für RoutineControl und Seed- oder Key-Level für SecurityAccess.

UDS-Bytes

Bytes der Anwendungsschicht ohne ISO-TP-Header. Hex, Leerzeichen optional.

Beispiele

Dekodiert

Request

5 Bytes

Service: 0x22 ReadDataByIdentifier
Data Identifier: 0xF190 VINDataIdentifier 0xF186 ActiveDiagnosticSessionDataIdentifier

So funktioniert es

Der Decoder wendet die Regeln der ISO 14229-1 auf die eingefügten Bytes an. Das erste Byte ist der Service Identifier; ist es 0x7F, ist die Nachricht eine negative Antwort und die nächsten zwei Bytes sind abgelehnter Service und Code. Ist es ein Request-SID plus 0x40, ist es eine positive Antwort. Bei Services mit Sub-Funktion wird das zweite Byte in Suppress-Bit und Sub-Funktionswert zerlegt und benannt, wo die Norm es definiert: Sessions bei 0x10, Reset-Typen bei 0x11, Routinenaktionen bei 0x31 und Seed- oder Key-Level bei 0x27 (ungerade Level fordern einen Seed an, gerade senden den Key zum vorangegangenen Seed).

Dann werden Identifier aufgelöst: Zwei-Byte-DIDs bei 0x22, 0x2A, 0x2E, 0x2F und 0x24 gegen die Standardbereiche aus ISO 14229-1 Anhang C und Zwei-Byte-RIDs bei 0x31. Was übrig bleibt, wird als Daten gezeigt.

So liest du das Ergebnis

Nutze es beim Lesen von Traces von Hand: Aus einer Zeile im CAN-Log wird “SecurityAccess requestSeed Level 1” statt “27 01”. Achte auf das Suppress-Bit bei anderen Requests als TesterPresent; es wird manchmal genutzt, um Aktivität vor einem Diagnose-Logger zu verstecken. Bei positiven Antworten vergleichst du die zurückgegebene Sub-Funktion mit dem Request: Ein Steuergerät, das auf 10 03 mit 50 03 antwortet, bestätigt die Extended Session, und die vier Bytes danach sind die P2- und P2*-Server-Timings.

Grenzen

Das Tool dekodiert eine Nachricht, keine Konversation, und es kennt dein Steuergerät nicht. Herstellerspezifische Services (0xBA bis 0xBE, 0xC0 bis 0xC7 und andere), Hersteller-DIDs und Routine Identifier brauchen die ODX- oder CDD-Beschreibung, um Namen zu bekommen. AutoST lädt diese Dateien und nutzt sie für die Benennung und für die DID- und Routinen-Scans.

FAQ

Häufig gestellte Fragen

Wie unterscheidet das Tool Request und Antwort?

Eine positive Antwort nutzt den Service Identifier des Requests plus 0x40: aus 0x22 wird 0x62, aus 0x27 wird 0x67. Eine negative Antwort beginnt immer mit 0x7F. Alles andere gilt als Request. Bytes, die gleichzeitig gültiger Request- und Antwort-SID sind, gibt es in ISO 14229-1 nicht, die Regel ist also eindeutig.

Was ist das Suppress-Bit?

Bit 7 des Sub-Funktions-Bytes (0x80). Ist es gesetzt, sagt der Tester dem Steuergerät, keine positive Antwort zu senden, nur negative. 3E 80 ist das übliche TesterPresent: die Session am Leben halten, ohne den Bus mit Antworten zu fluten.

Warum zeigt der Decoder bei einer positiven 0x22-Antwort nur die erste DID?

Eine positive ReadDataByIdentifier-Antwort enthält DID, Daten, DID, Daten und so weiter, aber die Datenlängen kennt man nur aus der ODX- oder CDD-Beschreibung des Steuergeräts. Ohne sie ist nur die erste DID eindeutig. AutoST nutzt die ODX- oder CDD-Datei, um den Rest zu zerlegen.

Quellen

ISO 14229-1:2020 Unified diagnostic services (UDS), Teil 1: Anwendungsschicht

Passende Seiten

← Kostenlose Tools