How to Understand Trouble Codes

OBD I (On Board Diagnostics Generation One)

This was the first type of Check Engine Light trouble code setting system. Up until 1988, most codes would generally disappear when the engine or key was turned off. The trouble code would not "set" in the memory of the Engine Control Module (ECM). In 1988, the more capable 32-bit processor system was starting to be introduced into automotive engine management computers. This allowed for a more comprehensive "on board" or "self-diagnosing" system, as well as the ability for trouble codes to be set in the memory.

As the engine management systems used more sensors and actuators, it became necessary to create additional monitoring methods. The sensors had to be grouped into systems and sub-systems to accurately keep track of their behavior. The more complex actuators displayed vastly different failure profiles than the sensors. The engine computer began to monitor itself to ensure that it was receiving proper voltages and grounds, and that the on-off switching parts of the computer (drivers) were not being overly taxed by a worn or shorting actuator.

It became clear that types of fault or code setting conditions existed. Some faults were "hard" faults, which meant that they were always present. Then, there were "intermittent" faults, which meant that the code set only under certain conditions, such as temperature range, vehicle speed, vehicle load, and vehicle time of operation, among others. With the newly capable engine computer and the OBD I system, a code set under intermittent conditions would stay in the diagnostic memory of the vehicle, making it possible for a technician to diagnose and repair the problem, even if the fault was not occurring at the present time.

When a fault occurred, it was now possible to employ a backup program or "limp home" mode in the engine management system. This allows the computer to employ a decreased capability program to help the vehicle get home, so the vehicle operator is not left stranded on a road way.

The introduction of the OBD system also meant that the transmission was now being included in the emissions system. Either the engine computer or, in some cases, an additional dedicated transmission module, was now linked to the primary engine control module. This meant that the OBD I system software had to track the proper operation of two multi-dimensional components that needed to work in harmony. The EPA found that a poorly functioning transmission could cause the engine to consume excessive fuel or cause excessive NOx pollution from the engine due to improper torque load. OBD I was a breakthrough in the management of these conditions since it had the capability to manage more than one computer.

However, as time passed, it became clear that OBD I was still too limited in its scope of managing the on board vehicle diagnostics. OBD I mainly concerns itself with sensors and actuators going out of range or into complete failure. By the early to mid 1990s, the sensors and devices grew to the point where system and sub-system monitors had to be created that ran only once a day or once every time the vehicle was stone-cold started. Even the time required to warm up the vehicle became scrutinized and fault codes were implemented to notify the driver if the vehicle was warming up improperly. The EPA found that most of the air pollution caused by vehicles occurs during the warm up cycle of operation. The faster a vehicle warms up, the cleaner it runs.

By the mid 1990s, some of the more complex or luxury class vehicles used dozens of sensors and actuators deployed in the transmission and the engine. By the early 1990s, the automatic transmission was an integral part of the emissions system. The EPA found that poorly functioning transmissions caused vehicles to consume more fuel and produce very high levels of NOx (a toxic gas) if the proper gear ratio could not be achieved. Computer networks began to control the transmission and engine systems with safety systems such as anti-lock brake systems (ABS), supplemental restraint systems (airbags), and traction control for safer driving on snowy/icy roads. The computer networks allowed for all of these systems to be synchronized with each other. If there was a fault in the engine management or transmission system, the other safety systems could be disabled and a warning light illuminated to warn the vehicle operator that one (or more) safety systems were disabled.

Another key limitation of OBD I—vehicle wear—became clear in the 1990s. The EPA found that as a vehicle was used over time, the various engine management systems did not accurately account for the mechanical degradation of the engine and its internal components. Though a sensor or device still worked properly, it could be operating at the limit of its range. Major fuel system sensors and devices, such as oxygen sensors and fuel injectors, were at their functional limit, yet still had not set any codes. This meant that under certain operating conditions, the vehicle was polluting the air and not setting a Check Engine Light code.

It also became clear that one of the major pollution issues—engine misfires—was caused either by ignition component wear, mechanical wear, or fuel system problems. Misfires cause raw HCs or raw gasoline to be released in the air. Under OBD I, an engine could have severe misfires and be in a "gross polluting" operational condition, but not be operating on all cylinders and not be setting a Check Engine Light code. The EPA mandated a reliable solution to this unacceptable operating condition—the "engine misfire" monitoring system—which led to OBD II (On Board Diagnostics Generation Two).

                                                                                     Next: A History of OBD II Trouble Codes >>



0 User Comments

Sign in to comment