# DTC (Diagnostic Trouble Code, Fehlercode)

> Ein DTC (Diagnostic Trouble Code) ist ein Fehlercode, den ein Steuergerät im Fehlerspeicher ablegt, wenn eine überwachte Bedingung verletzt ist, etwa ein Sensor außerhalb des Bereichs oder eine ausbleibende CAN-Nachricht. In UDS ist ein DTC drei Bytes lang, dazu kommt ein Status-Byte, das sagt, ob der Fehler aktiv, vorläufig oder bestätigt ist. Gelesen wird mit ReadDTCInformation (0x19), gelöscht mit ClearDiagnosticInformation (0x14). Im Security-Test zeigen neue DTCs, dass eine Testeingabe das Steuergerät erreicht und gestört hat.

Ein DTC ist ein Fehlercode, den ein Steuergerät bei einem erkannten Problem speichert. Das 3-Byte-Format in UDS, das Status-Byte, 0x19, 0x14 und die Rolle beim Fuzzing.

Source: https://auto-st.com/de/glossar/dtc · Updated: 2026-10-07

## Was ist ein DTC?

Ein DTC ist ein Code, der einen vom Steuergerät erkannten Fehler bezeichnet. Jedes Steuergerät überwacht seine Eingänge, Ausgänge und Kommunikation: Liegt die Sensorspannung im Bereich, kam die erwartete CAN-Nachricht an, hat der Aktor reagiert? Schlägt eine Überwachung fehl, setzt das Steuergerät einen DTC mit Status und speichert oft Umgebungsdaten (Freeze Frame) und erweiterte Daten wie einen Häufigkeitszähler.

In UDS ist ein DTC ein 3-Byte-Wert, gefolgt von einem 1-Byte-Status. Die acht Status-Bits sind, ab Bit 0: testFailed, testFailedThisOperationCycle, pendingDTC, confirmedDTC, testNotCompletedSinceLastClear, testFailedSinceLastClear, testNotCompletedThisOperationCycle und warningIndicatorRequested. Ein Request `19 02 08` fragt nach allen DTCs mit gesetztem confirmedDTC; die Antwort ist `59 02`, die Status Availability Mask und dann ein 4-Byte-Datensatz pro DTC.

## Wo ist es definiert?

ISO 14229-1 definiert das UDS-DTC-Format, das Status-Byte und die Services drumherum: ClearDiagnosticInformation (`0x14`), ReadDTCInformation (`0x19`) mit seinen vielen Sub-Funktionen und ControlDTCSetting (`0x85`), das die DTC-Erfassung beim Flashen anhält. SAE J2012 definiert die lesbare Schreibweise mit einem Buchstaben für das System (P, C, B, U) und die Bedeutung der Codes für abgasrelevante Fehler.

## Was es in der Praxis bedeutet

Für die Werkstatt sind DTCs der Anfang jeder Reparatur. Für einen Security-Tester haben sie zwei Rollen. Erstens als Angriffsfläche: ClearDiagnosticInformation und ControlDTCSetting sind oft in Sessions erreichbar, in denen sie nichts zu suchen haben, und ein Angreifer, der den Fehlerspeicher löschen oder die DTC-Erfassung abschalten kann, kann verbergen, was passiert ist. Wir sehen regelmäßig, dass `14 FF FF FF` in der Default Session ohne SecurityAccess angenommen wird.

Zweitens als Sensor. Beim Fuzzing kann ein Steuergerät neu starten oder in einen Watchdog laufen und 300 ms später wieder normal antworten. Den Reset selbst übersieht man leicht, aber er hinterlässt oft einen DTC für einen internen Fehler, ein Versorgungsereignis oder eine verlorene Kommunikation. Wer die DTC-Anzahl vor und nach jedem Testschritt liest, findet Fehler, die ein reiner Liveness-Check nicht sieht.

## Wie AutoST es testet

Die Fuzzing-Engine von AutoST hat einen optionalen DTC-Monitor. Er liest während des Laufs die DTC-Anzahl und meldet jede Änderung als Finding, mit der Payload davor, zusätzlich zum TesterPresent-Liveness-Check und zur Timeout-Erkennung. Die Enumerations-Engine prüft `0x14`, `0x19` und `0x85` in jeder Session wie jeden anderen Service.

## Häufige Missverständnisse

Kein DTC heißt nicht kein Problem: Ein Steuergerät kann abstürzen und neu starten, ohne dass eine Überwachung das festhält. Und ein leerer Fehlerspeicher beweist nicht, dass nichts passiert ist, nur dass jemand ihn löschen durfte.

## FAQ

**Was bedeutet ein DTC wie P0301 in UDS-Bytes?**

P0301 ist die Schreibweise nach SAE J2012. Die ersten beiden Bytes des UDS-DTC codieren ihn (hier 0x03 0x01, die obersten zwei Bits 00 stehen für P), das dritte Byte ist das Failure Type Byte, das den Fehler genauer beschreibt. Das Status-Byte folgt in jedem Antwort-Datensatz als viertes Byte.

**Sollte das Löschen von DTCs SecurityAccess erfordern?**

Das Löschen des Fehlerspeichers entfernt Spuren von Fehlern und von Angriffen, deshalb sollte es mindestens die Extended Session und oft einen SecurityAccess-Level brauchen. Ein Steuergerät, das in der Default Session ohne jede Prüfung alle DTCs löscht, macht es leicht, Spuren zu verwischen.

**Warum beobachtet ein Security-Tester DTCs?**

Weil ein Reset oder ein Watchdog-Ereignis beim Fuzzing oft einen DTC hinterlässt, auch wenn das Steuergerät danach wieder normal antwortet. Eine steigende DTC-Anzahl zwischen den Iterationen zeigt, dass eine Payload einen internen Fehler ausgelöst hat.

## Sources

- [ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1: Anwendungsschicht (Services 0x14, 0x19, 0x85 und DTC-Status)](https://www.iso.org/standard/72439.html)
- [SAE J2012: Diagnostic Trouble Code Definitions](https://www.sae.org/standards/content/j2012_201612/)

## Related

- [ReadDTCInformation (0x19)](https://auto-st.com/de/glossar/read-dtc-information-0x19)
- [ControlDTCSetting (0x85)](https://auto-st.com/de/glossar/control-dtc-setting-0x85)
- [Fuzzing (Fuzz-Testing)](https://auto-st.com/de/glossar/fuzzing)
- [UDS (Unified Diagnostic Services)](https://auto-st.com/de/glossar/uds)
- [Mach es am Prüfstand kaputt, nicht im Feld.](https://auto-st.com/de/ecu-fuzzing)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/glossar/dtc