ReadDTCInformation (0x19)

Was ist ReadDTCInformation (0x19)?

ReadDTCInformation liest den Fehlerspeicher eines Steuergeräts. Das Sub-Funktions-Byte wählt den Report-Typ, der entscheidet, was das Steuergerät zurückgibt: eine Anzahl, eine gefilterte DTC-Liste, einen Snapshot (Freeze Frame) oder erweiterte Daten zu einem DTC.

Ein normaler Ablauf:

Richtung	Bytes	Bedeutung
Request	19 02 FF	reportDTCByStatusMask, Maske 0xFF
Positive Antwort	59 02 FF 01 23 45 2F ...	Status-Verfügbarkeitsmaske, dann DTC 0x012345 mit Status 0x2F
Negative Antwort	7F 19 12	subFunctionNotSupported

Weitere typische negative Antworten sind 7F 19 13 (incorrectMessageLengthOrInvalidFormat, fehlende Statusmaske) und 7F 19 31 (requestOutOfRange, unbekannte DTC-Nummer bei einem Snapshot-Request).

Wo ist es definiert?

ISO 14229-1:2020 definiert ReadDTCInformation (0x19) im Stored data transmission functional unit, mit der vollständigen Liste der Report-Typ-Sub-Funktionen, dem drei Byte langen DTC-Format und den acht Status-Bits. Die DTC-Nummerierung und der Bezug zu OBD-Fehlercodes stehen in Begleitnormen, aber der UDS-Service und seine Statusmaske stehen in ISO 14229-1. Der Transport auf CAN ist ISO 15765-2, sodass eine lange DTC-Liste als Mehr-Frame-Nachricht ankommt.

Was es in der Praxis bedeutet

Der Fehlerspeicher wird in fast jeder Diagnosesitzung gelesen, und der Service ist normalerweise in der Default Session verfügbar, weil er nur liest. Bei der Validierung wird geprüft:

• die unterstützten Sub-Funktionen passen zur Spezifikation, und unbekannte geben NRC 0x12;
• ein Request ohne Statusmaske gibt NRC 0x13;
• die Status-Verfügbarkeitsmaske und die Status-Bits pro DTC sind konsistent;
• Snapshot- und Extended-Data-Requests für einen unbekannten DTC geben NRC 0x31;
• das Lesen von DTCs ändert die gespeicherten Fehler nicht.

Beim Security-Testen ist das DTC-Verhalten auch ein Signal. Ein Fuzzing-Lauf, der die DTC-Anzahl springen lässt, hat wahrscheinlich einen Fehlerpfad getroffen, der eine Meldung wert ist, also dient der Service zugleich als Monitor.

Wie AutoST es testet

AutoST liest DTC-Informationen bei der Enumeration, sodass das Ergebnis festhält, ob der Fehlerspeicher lesbar ist und in welcher Session. In der Fuzzing-Engine liest ein optionaler DTC-Count-Monitor 0x19 zwischen den Iterationen und meldet jede Änderung der Fehlercode-Anzahl während eines Laufs, was einen wachsenden Fehlerspeicher in ein Signal dafür verwandelt, dass ein Payload einen Fehlerpfad erreicht hat. Die Änderung wird neben dem exakten Payload festgehalten.