Misleading fault codes

Why does the fault code that names a sensor so often lead to a sensor that turns out to be working perfectly?

Plug in a reader, get a code, and the code appears to name a part. So the part is replaced — and a fortnight later the same code returns, the owner out the cost of a component that was never faulty.

The tempting conclusion is that the diagnostics are badly made. Before accepting it, ask a narrower question: what could the control unit possibly have observed, and what is it entitled to conclude from that? Perhaps the code is not wrong at all, and is answering a different question from the one we read it as answering.

What does an engine control unit actually have? Voltages on wires, and a model of what those voltages ought to be. Nothing else. It has never seen a valve, a hose or a catalyst.

That gives it two quite different kinds of test, and confusing them is where most of the trouble begins.

The first kind is a circuit test. If a line that should sit between, say, half a volt and four and a half volts reads zero or sits at the reference voltage, no plausible physical condition explains it — the wire is open, shorted or unpowered. Codes of that family, worded as circuit low, circuit high or no signal, really do implicate the named component or its wiring. They are comparatively honest.

The second kind is a rationality or plausibility test, and it is a different animal. Here every signal is in range and the unit is comparing accounts: does reported airflow square with throttle angle and engine speed, does the coolant sensor warm at the rate a running engine should, does the mixture the exhaust sensor reports match the fuelling commanded. When two accounts disagree, the unit knows only that something in the loop is wrong. It must still write a code, and codes are named after signals — so it names the reporter.

Take the familiar lean-mixture code. The exhaust oxygen sensor says the mixture is lean and the unit has already added fuel to its limit trying to correct it. The sensor is very probably telling the exact truth: the mixture is lean. That can come from unmetered air entering after the airflow meter, an airflow meter reading low, weak fuel pressure, an injector delivering short, or an exhaust leak drawing air past the sensor. Nothing in the reading distinguishes them, and the code cannot name a cause it has no instrument for.

Or the catalyst-efficiency code, which is inferred rather than measured: the unit watches the sensor before the catalyst switching busily and the one behind it staying calm, and reads the difference as the catalyst doing its job. A tired rear sensor that has begun to switch along with the front one produces exactly the pattern of a dead catalyst, and so does an exhaust leak in the wrong place.

Now the general shape. Any disagreement between a measurement and a model has at least three candidate homes: the instrument, the path between the instrument and the reader, and the world genuinely being what the instrument says. Codes are written from inside the unit, where those three are indistinguishable. The middle one deserves particular respect, because a corroded earth or a high-resistance connector offsets every sensor that shares it — producing several codes at once, which a hurried reading takes for several faults and a careful one takes for a single fault.

Why does the trade nonetheless fit parts? Partly language, a code worded around a sensor's name inviting it; partly economics, the sensor being cheap and occasionally the fault, so the guess sometimes pays; and partly the reinforcement of a code that clears after the repair, which proves only that the memory was erased.

This is where the workshop practice that looks like fussiness earns its keep. Reading the freeze-frame conditions captured when the code set, then watching live data and comparing the suspect sensor against a second one and against a plausible value, is the only way to separate the three candidates: it introduces evidence the control unit never had.

The misconception to dissolve is that a code is a diagnosis. It is an observation, made by an instrument with a fixed vocabulary, and its vocabulary is a list of components rather than a list of causes.

That reframing carries a second point, because it cuts against the modern hope for diagnostics. A skilled technician's advantage has always come from a baseline built by long exposure to healthy machines. On-board diagnostics look like that baseline supplied ready-made, and in one sense they are: the model of expected behaviour is genuinely encoded. But it arrives already attributed, and the attribution is exactly the part a technician should be forming for themselves. So the characteristic error moves: it is no longer failing to notice the symptom, but closing the question early because something authoritative-looking has already named a part.

Here is the test that would decide it. If codes name the observer rather than the cause, the rate at which replacing the named component actually cures the fault should be markedly lower for plausibility codes than for hard circuit-continuity codes, because only the latter has evidence pointing at the component — and workshops hold that data in their comeback records. Find the two classes cured at the same rate by fitting the named part, and this explanation is doing no work: a parts-swapping habit unrelated to how codes are generated would be the real story.

• How an experienced technician builds a baseline from healthy machines, and why that perception arrives before the reasoning does.
• Why a single poor earth produces a scatter of unrelated-looking codes, and how to spot the pattern.

Every term the collection defines is gathered in the glossary.