OBD-II
OBD-II has been around since the mid-90s. Among other things, these standards require that the OEMs provide all the tools and resources needed to correct emissions-related concerns to the automotive aftermarket and consumer. Essentially, that is anything that illuminates the CEL.
One requirement of OBD-II is that the ECM must be able to test itself, as well as all the sensors and actuators connected to it. It does this in three basic ways. First, it tests the integrity of the electrical component and its relevant circuit. Second, it will test the accuracy of all the sensor inputs. Does the data sent by a sensor to the ECM agree with what other sensors are telling the computer? This is called a rationality test. Third, it will test all the actuators to see if they can function properly. It does this by operating a component when it isn’t normally being used. It then looks for information from different sensors to determine whether the action it commanded was carried out.
When a test or series of tests fails more than once, the ECM will record the fault as a diagnostic trouble code (DTC) and turn on the CEL.
OBD-II also provides a standardized protocol to allow aftermarket diagnostic scan tools to communicate with the ECM.
There are additional advantages to using a generic OBD-II scan tool. One is that the data displayed on a generic tool must be exactly what the sensors are reporting to the ECM. Scan tools that offer enhanced (or OEM-specific) modes may display substituted values in the live data stream. Another advantage is the 10 different options available, and I’ll go more deeply into these in a moment. I can use these to gather the data I need to identify and correct the cause of the DTC.