Gary Stamberger – Training Director
MagnaFlow Exhaust Products
During this past year we have discussed many different topics. Misfire Diagnostics, Fuel Trim, and Converter Application to name a few. Through all of the articles the one common thread has been On-Board Diagnostics, commonly referred to as OBD. Although we have taken the time to explain how changes in this technology have affected the exhaust industry, we need to dedicate time and print to the discussion of OBD in its entirety.
Just like the early Personal Computers or PC's, the addition of computer technology to the automobile was simple and uncomplicated, at least in today's standards. The goal was to gain better control over the amount of fuel being consumed by the engine under various conditions. As early as 1980, systems such as GM's "assembly line diagnostic link" (ALDL) were implemented to allow for testing of the Engine Control Module (ECM) on the assembly line. These were proprietary and not originally intended for use outside of the factory. However, it soon became common knowledge in the repair community that the technician could acquire codes by jumping two pins in the ALDL and reading the "blinking sequence" of the Malfunction Indicator Light (MIL). This same procedure would continue to be applied on many vehicle makes and models over the following years, however there was no standardization of what components were being monitored or how the information was being reported.
By the end of the 1980's, technology had led to faster communication protocols and scan tools were giving technicians the ability to not only retrieve defined Diagnostic Trouble Codes (DTC) but also live data known as 'data stream' that greatly aided the diagnostic process. During this same time period and as a direct result of the 1990 Amendments to the Clean Air Act, standards were being developed that would greatly affect the industry as a whole. The Society of Automotive Engineers (SAE) and the International Standards Organization (ISO) had already been pushing for a standardized data link connector and set of test signals. All this, along with the push for more stringent tail pipe emissions came to fruition in 1996 with the implementation of OBD II (OBD generation two).
For the technician, the OBD system is a window into the entire vehicle and all its sub-systems. For our purposes we will focus on Engine Management, but it is important to realize that so many of the vehicle functions are interrelated and the communication between all of the modules (computers) on the car is continuous. We will look at Codes, Freeze Frame, Data Stream, and Monitors along with their function, benefits and liabilities.
Diagnostic Trouble Codes
When the Powertrain Control Module (PCM) senses a fault in a system or component, it alerts the driver by illuminating the MIL and setting or recording a code. This information can be retrieved from the PCM with a scan tool connected to the Data Link Connector (DLC). At this point the most important thing to remember is that this is not the end of the diagnostic process, only the beginning. Many techs mistakenly believe that replacing a component identified in a trouble code is all that is needed to repair the vehicle. The PCM doesn't know WHY there is a problem, it just relays that the signal from a particular component wasn't what it expected. There are any number of factors that can lead to an apparent failure and if the tech does not eliminate all the possibilities, the chances of getting that car back in his bay for the same fault is a good bet indeed. Knowing what can cause a sensor to "miss-report" goes a long way in aiding the technician towards asuccessful repair. Skills such as reading wiring diagrams, Flow charts, and information acquisition can be learned and applied on a daily basis.
OBD II introduced a standard for code display that gives us some very useful information right away. For example, a P0420 code would break down like this:
P = Powertrain
0 = Generic code
4 = Emissions
20 = Catalyst Efficiency Bank One
Each code is more defined than its OBD I predecessor and there can now be many codes for the same component describing a specific fault. For example, prior to OBD II the average system could display about 3 codes for Oxygen sensor failure. Now we could get upwards of 36 or more fault codes for an O2 sensor that would more closely define what the fault was. It is important to also realize that there are different types of codes available but first we must understand the criteria the PCM uses to display a fault.
There are generally two different types of codes we are concerned with, Type 'A" and Type 'B'. Type 'A' codes illuminate the MIL immediately upon detection of a fault. Type 'B' codes occur only when the PCM detects a fault in two consecutive drive cycles. The PCM will turn the MIL on and set a code. A drive cycle consists of starting the vehicle and driving it until it acquires Closed Loop operation and all necessary criteria are met. At this point the PCM will continue to monitor the system and if NO FAULTS are found in three consecutive drive cycles it will turn the light off and store the code in history. There is a third scenario where the PCM may detect a Type 'B' fault on one drive cycle but not in a second consecutive one. In this case it can set a Pending code but not illuminate the MIL.
All these scenarios create a situation where the Tech must dig a little deeper to get all the information they need to move forward. When checking for codes its important look at Current Codes (light on now), History Codes (Light was on) and Pending Codes (light was never on).
In the coming months we will dig deeper into OBD to learn exactly what information is at our fingertips to help us get these vehicles repaired correctly the "first time".
Cleaning up the environment...one converter at a time