What a fault code really says
A diagnostic trouble code is a module’s report of a condition it detected, recorded against criteria set by its software. P0118, for example, is commonly defined as “engine coolant temperature sensor circuit high”. That description includes the sensor, its connector, its wiring, the module’s reference supply and the module’s input circuit. The code points to an area for investigation, not to a single part.
The first character identifies the system family: P for powertrain, B for body, C for chassis and U for network communication. Generic codes are standardised under SAE J2012 and ISO 15031-6, while manufacturers add their own. Freeze-frame data, a snapshot of conditions when the code set, is often as valuable as the code itself.
An evidence-first sequence
1. Confirm the complaint
Reproduce the symptom or define exactly when it happens: temperature, speed, load, weather. A fault you cannot observe is difficult to prove fixed.
2. Check the foundation
Battery state of charge, charging voltage and main grounds affect every module. Low voltage can create a cascade of unrelated-looking codes, particularly network codes.
3. Gather stored information
Read codes from all modules, not just the engine. Record freeze-frame data before clearing anything. Look for patterns: a shared supply, a shared ground or a shared network.
4. Compare live data with reality
Does the reported coolant temperature match a cold engine’s actual temperature? Do both pedal signals track together? Live data shows what the module believes.
5. Measure the circuit
Using the wiring diagram, test reference, signal and ground at the component and at the module. Voltage drop under load finds resistance that a simple continuity test misses.
6. Repair, then verify
After the repair, clear codes, repeat the original conditions and confirm the module completes its self-tests. The verification is part of the diagnosis.
Symptom and evidence table
| Symptom | Systems involved | Useful evidence | Common trap |
|---|---|---|---|
| Battery flat after parking | Constant feeds, modules that fail to sleep | Parasitic current after modules sleep | Measuring before modules have gone to sleep |
| Multiple U-codes | Network wiring, gateway, module supplies | Bus resistance, module power and ground | Replacing the first module named |
| Dim or flickering lamps | Charging system, feeds, grounds | Voltage at lamp under load | Assuming the bulb is weak |
| Fan never switches on | Sensor, module, relay, fuse, motor | Live temperature data, relay command, load voltage | Fitting a new relay first |
| Sensor code returns after replacement | Reference supply, connector, harness | Values at the module pin, pin fit | Buying a second sensor |
Tools and what each reveals
Module view
Codes, freeze frames, live data and actuator tests. Deeper functions use protocols such as UDS (ISO 14229) over CAN (ISO 15765).
Circuit view
Voltage, resistance and voltage drop. A high-impedance digital meter is safe for most module circuits.
Time view
Shows how signals change over milliseconds, revealing dropouts, noise and pulse shapes a meter averages away.
Intermittent faults
A fault that comes and goes is usually linked to movement, heat or moisture. Watching live data while gently flexing a harness, warming a connector or checking after rain can catch it in the act. Recording graphs on a scan tool or scope during a road test, with a passenger operating the equipment, preserves the evidence safely.