OBDII: PAST, PRESENT & FUTURE

TECHNOLOGY >> AUTO TECHNOLOGY >>   OBDII: PAST, PRESENT & FUTURE






OBDII: PAST, PRESENT & FUTURE

autotap.com

DIAGNOSING THE BATTERY, CHARGING & IGNITION SYSTEM
CATALYTIC CONVERTERS & O2 SENSORS
DIAGNOSING FUEL DELIVERY PROBLEMS
Diagnosing Misfires

OBDII Scantool for PDA

OBDII Scantool for windows

OBDII Scantool

OBDII different from all the self-diagnostic systems that proceeded it is that OBDII is strictly emissions oriented. In other words, it will illuminate the Malfunction Indicator La

All 1996 and newer model year passenger cars and light trucks are OBDII-equipped, but the first applications were actually introduced back in '94 on a limited number of vehicle models.

What makes OBDII different from all the self-diagnostic systems that proceeded it is that OBDII is strictly emissions oriented. In other words, it will illuminate the Malfunction Indicator Lamp (MIL) anytime a vehicle's emissions exceed 1.5 times the federal test procedure (FTP) standards for that model year of vehicle. That includes anytime random misfires cause an overall rise in HC emissions, anytime the operating efficiency of the catalytic converter drops below a certain threshold, anytime the system detects air leakage in the sealed fuel system, anytime a fault in the EGR system causes NOX emissions to go up, or anytime a key sensor or other emission control device fails. In other words, the MIL light may come on even though the vehicle seems to be running normally and there are no real driveability problems.

The main purpose of the MIL lamp on an OBDII-equipped vehicle, therefore, is to alert you when your vehicle is polluting so you'll get their emission problems fixed. But as we all know, its easy to ignore warning lamps- until steam is belching from under the hood or the engine is making horrible noises. That's why regulators want to incorporate OBDII into existing and enhanced vehicle emissions inspection programs. If the MIL lamp is found to be on when a vehicle is tested, it doesn't pass even if its tailpipe emissions are within acceptable limits.

WHY OBDII?
The problem with most vehicle inspection programs is that they were developed back in the 1980s to identify "gross polluters." The tests were designed primarily to measure idle emissions on carbureted engines (which are dirtiest at idle), and to check for only two pollutants: unburned hydrocarbons (HC) and carbon monoxide (CO). The pass/fail cut points that were established for the various model years were also made rather lenient to minimize the number of failures. Consequently, a lot of late model vehicles that shouldn't be passing an emissions test are getting through anyway.

Efforts to upgrade vehicle inspection programs to the new I/M 240 standards have stalled because of a lack of public and political support. The I/M 240 program would have required "loaded-mode" emissions testing on a dyno while the vehicle was driven at various speeds following a carefully prescribed driving trace. While this was going on, the tailpipe gases would be analyzed to check not only for total emissions. The total emissions for the entire 240-second driving cycle would then be averaged for a composite emission score that determines whether or not the vehicle passed the test. Also included would be an evaporative purge flow test to measure the flow rate of the canister purge valve, and an engine off pressure test of the evaporative emission control system to check the fuel tank, lines and cap for leaks.

The I/M 240 program was to have been required in most areas of the country that don't meet national ambient air quality (NAAQ) standards. But after the program faltered in Maine, most states balked and only Colorado went ahead with the program. The cost and complexity of the I/M 240 program combined with less than enthusiastic public acceptance doomed it from the start. So it's now up to the individual states to come up with alternative plans for improving their air quality. An important element in many of those plans is OBDII.

A SHORT HISTORY WITH FAR REACHING IMPLICATIONS
The origins of OBDII actually date back to 1982 in California, when the California Air Resources Board (ARB) began developing regulations that would require all vehicles sold in that state starting in 1988 to have an onboard diagnostic system to detect emission failures. The original onboard diagnostic system (which has since become known as OBDI) was relatively simple and only monitored the oxygen sensor, EGR system, fuel delivery system and engine control module.

OBDI was a step in the right direction, but lacked any requirement for standardization between different makes and models of vehicles. You still had to have different adapters to work on different vehicles, and some systems could only be accessed with costly "dealer" scan tools. So when ARB set about to develop standards for the current OBDII system, standardization was a priority: a standardized 16-pin data link connector (DLC) with specific pins assigned specific functions, standardized electronic protocols, standardized diagnostic trouble codes (DTCs), and standardized terminology.

Another limitation of OBDI was that it couldn't detect certain kinds of problems such as a dead catalytic converter or one that had been removed. Nor could it detect ignition misfires or evaporative emission problems. Furthermore, OBDI systems would only illuminate the MIL light after a failure had occurred. It had no way of monitoring progressive deterioration of emissions-related components. So it became apparent that a more sophisticated system would be required. The California Air Resources Board eventually developed standards for the next generation OBD system, which were proposed in 1989 and became known as OBDII. The new standards required a phase-in starting in 1994. The auto makers were given until the 1996 model year to complete the phase-in for their California vehicles.

Similar standards were incorporated into the federal Clean Air Act in 1990 which also required all 49-state vehicles to be OBDII equipped by 1996 -- with one loophole. The OBDII systems would not have to be fully compliant until 1999. So some 1996 OBDII systems may lack one of the features normally required to meet the OBDII specs, such as the evaporative emissions purge test.

EARLY OBDII APPLICATIONS
1994 vehicles equipped with the early OBD II systems include Buick Regal 3800 V6, Corvette, Lexus ES3000, Toyota Camry (1MZ-FE 3.0L V6) and T100 pickup (3RZ-FE 2.7L four), Ford Thunderbird & Cougar 4.6L V8, and Mustang 3.8L V6. 1995 vehicles with OBDII include Chevy/GMC S, T-Series pickups, Blazer and Jimmy 4.3L V6, Ford Contour & Mercury Mystique 2.0L four & 2.6L V6, Chrysler Neon, Cirrus and Dodge Stratus, Eagle Talon 2.0L DOHC (nonturbo), and Nissan Maxima and 240 SX.

Not all of these early applications are fully OBDII compliant, but do include the major diagnostic features of the current system.

OBDII HARDWARE UPGRADES
Don't think for a moment that OBDII is just a fancier version of self-diagnostic software. It's that and much, much more. OBDII-equipped vehicles typically have:

* Twice the number of oxygen sensors as non-OBDII vehicles (most of which are heated O2 sensors). The additional O2 sensors are located downstream of the catalytic converter.

* More powerful powertrain control modules, with either 16-bit (Chrysler) or 32-bit (Ford & GM) processors to handle up to 15,000 new calibration constants that were added by OBDII.

* Electronically Erasable Programmable Read Only Memory (EEPROM) chips that allows the PCM to be reprogrammed with revised or updated software changes using a terminal link or external computer.

* A modified evaporative emission control systems with a diagnostic switch for purge testing, or an enhanced EVAP system with a vent solenoid, fuel tank pressure sensor and diagnostic test fitting.

* More EGR systems with a linear EGR valve that is electronically operated and has a pintle position sensor.

* SSequential fuel injection rather than multiport or throttle body injection. Both a MAP sensor and MAF sensor for monitoring engine load and airflow.

TOOLING UP FOR OBDII
To work on your OBDII-equipped vehicle, you'll need an OBDII scan tool such as AutoTap for PC or Palm PDA.

THAT PESKY MIL LAMP
Most technicians are pretty familiar with the operation of the "Check Engine" or "Malfunction Indicator Lamp" (MIL) on late model vehicles. But on OBDII-equipped vehicles, it may seem like the MIL lamp has a mind of its own.

On '96 General Motors J-, N- and H-body cars, several rental fleets have encountered problems with the MIL lamp coming on because motorists and fleet personnel haven't been using the correct refueling procedure when filling the fuel tank with gas. On these cars, the OBDII system applies vacuum to the evaporative emissions control system to check for air leakage. If the gas cap isn't tight or the tank is filled while the key is on or the engine is idling, it can trigger a false P0440 code causing the MIL light to come on. GM has not issued a technical service bulletin on the problem, but is advising its dealers and fleet customers to reflash the EEPROM with revised OBDII programming that waits to check the evaporative emissions system until the vehicle is in motion.

Bad gas has also been causing some false MIL lights. When the vehicle is diagnosed, the technician finds a P0300 random misfire code which would normally be set by a lean misfire condition due to a vacuum leak, low fuel pressure, dirty injectors, etc., or an ignition problem such as fouled plugs, bad plug wires, weak coil, etc. The OBDII self-diagnostics tracks misfires by individual cylinder, and considers up to a 2% misfire rate as normal. But water in the gas or variations in the additive package in reformulated gasoline in some areas of the country can increase the misfire rate to the point where it triggers a code.

To minimize the occurrence of false MIL lamps, the OBDII system is programmed so that the MIL lamp only comes on if a certain kind of fault has been detected twice under the same driving conditions. With other faults (those that typically cause an immediate and significant jump in emissions), the MIL light comes on after only a single occurrence. So to correctly diagnose a problem, it's important to know what type of code you're dealing with.

Type A diagnostic trouble codes are the most serious and will trigger the MIL lamp with only one occurrence. When a Type A code is set, the OBDII system also stores a history code, failure record and freeze frame data to help you diagnose the problem.

Type B codes are less serious emission problems and must occur at least once on two consecutive trips before the MIL lamp will come on. If a fault occurs on one trip but doesn't happen again on the next trip, the code won't "mature" and the light will remain off. When the conditions are met to turn on the MIL lamp, a history code, failure record and freeze frame data are stored the same as with Type A codes.

A drive cycle or trip, by the way, is not just an ignition cycle, but a warm-up cycle. It is defined as starting the engine and driving the vehicle long enough to raise the coolant temperature at least 40 degrees F (if the startup temperature is less than 160 degrees F).

Once a Type A or B code has been set, the MIL will come on and remain on until the component that failed passes a self-test on three consecutive trips. And if the fault involved something like a P0300 random misfire or a fuel balance problem, the light won't go out until the system passes a self-test under similar operating conditions (within 375 rpm and 10% of load) that originally caused it to fail. That's why the MIL lamp won't go out until the emissions problem has been repaired. Clearing the codes with your AutoTap scan tool or disconnecting the powertrain control module's power supply won't prevent the lamp from coming back on if the problem hasn't been fixed. It may take one or more driving cycles to reset the code, but sooner or later the MIL lamp will go back on if the problem is still there.

Likewise, the MIL won't necessarily go on if you intentionally disconnect a sensor. It depends on the priority ranking of the sensor (how it affects emissions), and how many driving cycles it takes for the OBDII diagnostics to pick up the fault and set a code.

As for Type C and D codes, these are non-emissions related. Type C codes can cause the MIL lamp to come on (or illuminate another warning lamp), but Type D codes do not cause the MIL lamp to come on.

RUNNING AN OBDII DRIVE CYCLE
Suppose you've "fixed" an emissions problem on your OBDII-equipped vehicle. How can you check your work? By performing what's called an "OBDII drive cycle." The purpose of the OBDII drive cycle is to run all of the onboard diagnostics. The drive cycle shold be performed after you've erased any trouble codes from the PCM's memory, or after the battery has been disconnected. Running through the drive cycle sets all the system status "flags" so that subsequent faults can be detected.

The OBDII drive cycle begins with a cold start (coolant temperature below 122 degrees F and the coolant and air temperature sensors within 11 degrees of one another).

NOTE: The ignition key must not be on prior to the cold start otherwise the heated oxygen sensor diagnostic may not run.

As soon as the engine starts, idle the engine in drive for two and a half minutes with the A/C and rear defrost on. OBDII checks oxygen sensor heater circuits, air pump and EVAP purge.
Turn the A/C and rear defrost off, and accelerate to 55 mph at half throttle. OBDII checks for ignition misfire, fuel trim and canister purge.
Hold at a steady state speed of 55 mph for three minutes. OBDII monitors EGR, air pump, O2 sensors and canister purge.
Decelerate (coast down) to 20 mph without braking or depressing the clutch. OBDII checks EGR and purge functions.
Accelerate back to 55 to 60 mph at throttle. OBDII checks misfire, fuel trim and purge again.
Hold at a steady speed of 55 to 60 mph for five minutes. OBDII monitors catalytic converter efficiency, misfire, EGR, fuel trim, oxygen sensors and purge functions.
Decelerate (coast down) to a stop without braking. OBDII makes a final check of EGR and canister purge.
BEYOND OBDII
OBDII is a very sophisticated and capable system for detecting emissions problems. But when it comes to getting motorists to fix emission problems, it's no more effective than OBDI. Unless there's some means of enforcement, such as checking the MIL light during a mandatory inspection, OBDII is just another idiot light.

Currently under consideration are plans for OBDIII, which would take OBDII a step further by adding telemetry. Using miniature radio transponder technology similar to that which is already being used for automatic electronic toll collection systems, an OBDIII-equipped vehicle would be able to report emissions problems directly to a regulatory agency. The transponder would communicate the vehicle VIN number and any diagnostic codes that were present. The system could be set up to automatically report an emissions problem via a cellular or satellite link the instant the MIL light comes on, or to answer a query from a cellular, satellite or roadside signal as to its current emissions performance status.

What makes this approach so attractive to regulators is its effectiveness and cost savings. Under the current system, the entire vehicle fleet in an area or state has to be inspected once every year or two to identify the 30% or so vehicles that have emissions problems. With remote monitoring via the onboard telemetry on an OBDIII-equipped vehicle, the need for periodic inspections could be eliminated because only those vehicles that reported problems would have to be tested.

On one hand, OBDIII with its telemetry reporting of emission problems would save consumers the inconvenience and cost of having to subject their vehicle to an annual or biennial emissions test. As long as their vehicle reported no emission problems, there'd be no need to test it. On the other hand, should an emissions problem be detected, it would be much harder to avoid having it fixed-which is the goal of all clean air programs anyway. By zeroing in on the vehicles that are actually causing the most pollution, significant gains could be made in improving our nation's air quality. But as it is now, polluters may escape detection and repair for up to two years in areas that have biennial inspections. And in areas that have no inspection programs, there's no way to identify such vehicles. OBDIII would change all that.

The specter of having Big Brother in every engine compartment and driving a vehicle that rats on itself anytime it pollutes is not one that would appeal to many motorists. So the merits of OBDIII would have to be sold to the public based on its cost savings, convenience and ability to make a real difference in air quality. Even so, any serious attempt to require OBDIII in the year 2000 or beyond will run afoul of Fourth Amendment issues over rights of privacy and protection from government search and seizure. Does the government have the right to snoop under your hood anytime it chooses to do so, or to monitor the whereabouts of your vehicle? These issues will have to be debated and resolved before OBDIII stands a chance of being accepted. Given the current political climate, such drastic changes seem unlikely.

Another change that might come with OBDIII would be even closer scrutiny of vehicle emissions. The misfire detection algorithms currently required by OBDII only watch for misfires during driving conditions that occur during the federal driving cycle, which covers idle to 55 mph and moderate acceleration. It does not monitor misfires during wide open throttle acceleration. Full range misfire detection will be required for 1997 models. OBDIII could go even further by requiring "fly-by-wire" throttle controls to reduce the possibility of misfires on the coming generation of low emission and ultra low emission vehicles. So until OBDIII winds its way through the regulatory process, all we have to worry about is diagnosing and repairing OBDII-equipped vehicles and all the non-OBD vehicles that came before them.

http://www.autotap.com/articles/OBDII_Past_Present_Future.html



blog comments powered by Disqus