GlossaryDiagnosticsUDS

DTC (Diagnostic Trouble Code)

A DTC is a fault code an ECU stores when it detects a problem. The 3-byte UDS format, the status byte, how 0x19 and 0x14 read and clear them, and their role in fuzzing.

Updated October 7, 2026This page as Markdown

In short

A DTC (diagnostic trouble code) is a fault code an ECU stores in its fault memory when a monitored condition fails, for example a sensor out of range or a lost CAN message. In UDS a DTC is three bytes plus a status byte that says whether the fault is active, pending or confirmed. Testers read DTCs with ReadDTCInformation (0x19) and clear them with ClearDiagnosticInformation (0x14). In security testing, new DTCs are a signal that a test input reached and disturbed the ECU.

What is a DTC?

A DTC is a code that identifies a fault an ECU has detected. Each ECU runs monitors on its inputs, outputs and communication: is the sensor voltage in range, did the expected CAN message arrive, did the actuator respond? When a monitor fails, the ECU sets a DTC with a status and often stores snapshot data (freeze frame) and extended data such as an occurrence counter.

In UDS a DTC is a 3-byte value, followed by a 1-byte status. The eight status bits are, from bit 0: testFailed, testFailedThisOperationCycle, pendingDTC, confirmedDTC, testNotCompletedSinceLastClear, testFailedSinceLastClear, testNotCompletedThisOperationCycle and warningIndicatorRequested. A request 19 02 08 asks for all DTCs with confirmedDTC set; the answer is 59 02, the status availability mask and then one 4-byte record per DTC.

Where is it defined?

ISO 14229-1 defines the UDS DTC format, the status byte and the services around it: ClearDiagnosticInformation (0x14), ReadDTCInformation (0x19) with its many sub-functions, and ControlDTCSetting (0x85), which stops DTC recording during flashing. SAE J2012 defines the readable notation with a letter for the system (P, C, B, U) and the code meanings for emissions-related faults.

What it means in practice

For a workshop, DTCs are the start of every repair. For a security tester they serve two purposes. First as an attack surface: ClearDiagnosticInformation and ControlDTCSetting are often reachable in sessions where they should not be, and an attacker who can clear fault memory or switch off DTC recording can hide what was done. We regularly see 14 FF FF FF accepted in default session without any SecurityAccess.

Second as a sensor. During fuzzing an ECU may reset or run into a watchdog and answer normally 300 ms later. The reset itself is easy to miss, but it often leaves a DTC for an internal error, a supply event or a lost communication. Reading the DTC count before and after each test step catches faults that liveness checks alone do not see.

How AutoST tests it

The AutoST fuzzing engine has an optional DTC monitor. It reads the DTC count during the run and flags any change as a finding, with the payload that preceded it, in addition to the TesterPresent liveness check and timeout detection. The enumeration engine probes 0x14, 0x19 and 0x85 in every session like every other service.

Common misunderstandings

No DTC does not mean no problem: an ECU can crash and restart without a monitor that records it. And a cleared fault memory is not proof that nothing happened, only that someone was allowed to clear it.

FAQ

Frequently asked questions

What does a DTC like P0301 mean in UDS bytes?

P0301 is the SAE J2012 notation. The first two bytes of the UDS DTC encode it (here 0x03 0x01, with the top two bits 00 for P), and the third byte is the failure type byte, which refines the fault. The status byte follows as a fourth byte in every response record.

Should clearing DTCs require SecurityAccess?

Clearing fault memory removes evidence of faults and of attacks, so it should at least need the extended session and often a SecurityAccess level. An ECU that clears all DTCs in the default session without any check makes it easy to hide traces.

Why would a security tester watch DTCs?

Because a reset or a watchdog event during fuzzing often leaves a DTC behind even when the ECU answers normally again. A rising DTC count between iterations shows that a payload caused an internal fault.

Sources

← Glossary