Key takeaways
- DTC logic is structured: detection condition, debounce time, healing condition — nothing is instant.
- Pending, confirmed and permanent codes describe the same fault at different confidence levels.
- Erasing codes without fixing causes just restarts the counter.
Modern ECUs implement sophisticated diagnostic strategies to identify faults and meet OBD requirements.
Diagnostic Flow
Fault Detection → Debounce → Maturation → DTC Storage → MIL
Debounce Logic
- Time-based — fault must persist X seconds
- Counter-based — must occur X times
- Drive-cycle — must appear in multiple drives
DTC Status
- Confirmed — mature fault, MIL on
- Pending — detected but not confirmed
- History — previously active
From Sample to MIL
Diagnostics mature in stages: a monitor samples, a debounce counter filters noise, a persistent result becomes a pending code, confirmation over the calibrated number of cycles stores it — with freeze-frame data of the moment — and emissions-relevant faults finally light the MIL. Healing runs the same path in reverse, which is why lamps go out by themselves after enough clean drive cycles.
Using the Logic
Freeze frames tell you the conditions, not just the code; pending codes tell you what is brewing before the lamp; and readiness monitors tell you what has actually been tested since the last clear. Calibration work that touches monitored systems should always end with a readiness check, because a customer’s inspection failure is a poor place to discover an unfinished monitor.
Why did my fault code come back after clearing?
What is the difference between pending and confirmed DTCs?
Related: on supported vehicles this system is directly addressed by our DTC removal service. See also Typical Sensor Ranges and Limits in the knowledge base.
