ClearDiagnosticInformation (0x14) - UDS Diagnostics

0x14 ClearDiagnosticInformation Service

0x14 Request/Response

  Request:
  ┌──────┬─────────────────────────────────────────────────┐
  │ 0x14 │ GroupOfDTC (3 bytes)                           │
  │      │ 0xFFFFFF = all DTCs / specific DTC ID          │
  └──────┴─────────────────────────────────────────────────┘

  Positive response:
  ┌──────┐
  │ 0x54 │  (no additional data)
  └──────┘

  Actions on ClearDTC (ISO 14229 Annex D):
  ├── Status byte bits 1, 2, 3, 5, 7 cleared to 0
  ├── Bit 0 (testFailed): set to current monitor result (not cleared to 0!)
  ├── Bits 4, 6: set to 1 (monitor not run since clear)
  ├── Freeze frame / snapshot records deleted from DEM storage
  ├── Extended data records (occurrence counter etc.) reset
  └── Aging counter reset

  Permanent DTC: NOT cleared by 0x14; must pass 3 OBD drive cycles first
  NRC 0x22: conditions not correct (vehicle not stationary; engine running)

DTC Group Identifiers

Group	3-byte identifier	Clears
All DTCs	0xFF 0xFF 0xFF	Every DTC in DEM regardless of type
Emission-related	0xFF 0xFF 0x33	Only OBD powertrain DTCs (P0xxx, P2xxx)
Body	0xFF 0xFF 0x01	Body domain DTCs (B-codes)
Chassis	0xFF 0xFF 0x02	Chassis domain (C-codes)
Network	0xFF 0xFF 0x03	Network/communication (U-codes)
Specific DTC	0x01 0x23 0x45	Only that single DTC (if ECU supports individual clear)

Permanent DTCs: OBD-II Compliance

💡 What are Permanent DTCs?

EPA regulations (40 CFR Part 86) and SAE J1979 require that emission-related DTCs that caused the MIL to illuminate be stored in a non-volatile permanent memory bank separate from the normal DTC storage. These permanent DTCs survive: ClearDiagnosticInformation (0x14), ECU reset, battery disconnect, and NvM clear. They can only be erased by the ECU itself after confirming the fault is healed across 3 consecutive passing OBD drive cycles. A workshop tool that clears DTCs and passes the MIL inspection check without verifying permanent DTCs are cleared is committing an inspection violation.

Conditions Under Which Clear May Be Rejected

Condition	NRC	Reason
Vehicle speed > 0	0x22 (conditionsNotCorrect)	OEM policy: no clear while driving
Engine running during clear	0x22	Some OEMs require ignition-on/engine-off
Reprogramming in progress	0x22	DEM busy with programming
Wrong session	0x25	0x14 requires Extended Diagnostic Session minimum
Wrong security	0x33	Some OEMs require Security Level 1 for ClearDTC

Summary

ClearDiagnosticInformation does not reset bit 0 (testFailed) — it reflects the current monitor result. If the fault is still active when the clear command is received, bit 0 immediately re-sets, and if the fault persists for two more cycles, bit 3 (confirmed) will set again without any tester interaction. Permanent DTCs are the most frequently misunderstood DTC concept: they are invisible to the 0x14 clear command by design, and they will fail an OBD readiness inspection until the ECU's own self-healing verification completes.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.