Twenty years ago, only the franchised and specialist garages possessed fault code readers and instruments that could communicate with a vehicle’s ECU. These code readers/scan-ners were typically made by [or licensed to] the vehicle manufacturers. They were not cheap and vehicle owners were forced to always use franchised or specialist garages for work that required any ‘digital diagnostics’.
What made the playing field far fairer was of course standardisation – driven by the US and initially focusing on emission control and engine management. Unfortunately (and paradoxically) there was no one standard to begin with and manufacturers adopted their own take on OBD.
The US government stepped in and OBD II became a federal requirement for all cars manufactured after 1996. The European equivalent (EOBD) came into force later. EOBD applies to every newly released petrol model built after 1st January 2000 and every petrol vehicle manufactured after 1st January 2001. For diesels the dates are 1st January 2004 and (supposedly) 1st January this year.With EOBD, fault codes may not appear immediately and tend to be registered after six starts or a few miles of travel, which can make fault finding extremely laborious. Further, the standard fault codes were generic and the user of an EOBD-compliant code reader did not have access to man-ufacturer-specific codes.
Accordingly, when EOBD emerged as standard it was generally perceived as ‘only a step in the right direction’. For example, for a time it represented the only method of dig-itally diagnosing Japanese vehicles.
Improving on EOBD is EOBD 2 (where the ‘E’ is now taken to mean ‘Enhanced’ rather than ‘European’). EOBD 2 provides access to a wider range of fault codes and facilitates views of live data and components /sensors.
The so-called ‘block exemption ruling’ of last year forced vehicle manufacturers to make available (for a price) the details of manufacturer-specific codes. This enabled some independent code reader manufact-urers to build tailored products and enter an otherwise closed market. But even then, the code reader manufacturers were dependent on the quantity and quality of information supplied by the vehicle manufacturers.
The alternative to being dependent on the vehicle manufacturers was, and still is, ‘reverse engineering’ the manufacturers’ code readers. This process typically involves analysing the data stream between the vehicle and code reader in order to work out which instructions coerce vehicles into revealing their stored and live data.
So, the current situation is this: the market is rich with a variety of code readers and scanners, all affording varying levels of access to a car’s ECU, and £100 will buy you a basic tool capable of displaying EOBD fault codes.
Read the symptoms
Clearly, the mass adoption of code readers is not a bad thing. However, irrespective of the age, type and pedigree of a code reader, it is all too easy to become complacent and to accept the fault codes as Gospel.A code reader only relays what the vehicle’s ECU ‘thinks’ is wrong with a vehicle, and the ECU is only as good as its software.
Seldom does a fault code indicate the categorical failure of a sensor or its wiring. Most of the time, the codes are referring to the failure of a system (of which the sensor is part). Accordingly, a code reader is only ever conveying the symptom and not the cause of a problem.
It is therefore necessary to interpret many of the codes displayed on a code reader and decide if further checks can be done to narrow down the problem. And of the many fault codes that frequently warrant further investigation most pertain to the engine – with the (likely) faults affecting the way the engine starts and/or runs.
For example, if an ECU reports a rich-mixture signal from a Lambda sensor then either the mixture is genuinely rich (say from high fuel pressure – just one of many causes) or the sensor is faulty. Note: it is possible for an engine to run rich yet for a fully functional Lambda sensor to report a weak mixture.
Assuming that there are no other fault codes (which could indicate that another sensor has failed – such as a temperature sensor) then the technician has only limited information with which to make a diagnosis. On many occasions, the conclusion drawn would be that the Lambda sensor is not operating correctly and the sensor would be replaced.
However, conducting an exhaust gas analysis would have provided a much clearer picture as to what is really causing the problem.
If the injection system or the Lambda sensor is to blame then a 4 gas analyser would show high CO, high HC and no O2. However, if all was well with the sensor and the injection system then the gas analyser may show a high O2 level, indicating an exhaust leak before the Lambda sensor. Such a pre-sensor leak would allow air into the exhaust and it would fool the sensor into returning a signal for a weak mixture. Acting on this information the ECU would enrich the mixture.
Unfortunately, gas analysis is not per-formed as often as it used to be and is regarded as ‘just part of the MOT’. It is seldom used to complement fault codes: and one could argue that it is an over-reliance on being able to use fault codes (alone) to diagnose automotive problems that has relegated gas analysers (and oscilloscopes and multi-meters) to ‘last resort’ instruments.Increasingly, technicians act on the ‘clues’ (and that’s all they are) from code readers, without conducting further investigations, and embark on a time-consuming trial-and-error process of swapping components.
In-line, digital code readers provide an extremely useful and powerful interface with vehicles. They have not replaced the more traditional ‘analogue’ solutions. They are a complement. And on a general note, there are no substitutes for rational fault-finding procedures, experience and training.
Don’t shoot the messenger
Most people come to expect great things from technology and rightly so. But in this day and age it is easy to understand ‘what’ a piece of equipment does without bothering with the ‘how’ or ‘why’, and a little knowledge…
This expectation makes life hard for code readers. Unlike no other tool in the workshop it can be criticised for not finding anything wrong with a vehicle that is clearly malfunctioning.
Fairer criticism should be directed towards the vehicle for not ‘telling all’.