.com
OUTSMARTING TODAY'S SMART CARSWhen computerized engine controls were introduced, it ushered in the era of the "smart" car. The engineers who designed these vehicles realized that some type of self-diagnostic capability would be necessary to troubleshoot all the electronics. With fuel management, spark timing, emissions control and other powertrain functions interwoven electronically, pinpointing faults is nearly impossible without some type of help. Thus onboard diagnostics was born, and with it a whole new way to outsmart today's smart cars.
The basic idea behind onboard self-diagnostics is fairly simple. The vehicle's computer (or computers in applications where there are separate control modules for the transmission, antilock brake system, climate control system, etc.) monitors the constant flow of inputs from its various sensors. These inputs are necessary to carry out the computer's control functions, so the computer makes sure that (1) it is receiving data from its various inputs, (2) that the data it does receive is within acceptable norms or limits, (3) that the data received from any given sensor agrees with that from other sensors where a direct relationship exists, and (4) that its commands are being carried out via various feedback mechanisms.
As long as there as everything works as intended, the smart car runs great. But when a fault arises such as loss of input from a vital sensor, input data that doesn't make sense (out of range or doesn't match inputs from other sensors), or loss of a return signal from an actuator, it triggers the self-diagnostics to react.
What happens next depends on the nature of the problem, the diagnostic capabilities of the system, the smart system that's involved (powertrain control module, ABS module, body control module, air bag system, or climate control system) and the vehicle application. In most cases where input from a key sensor circuit is lost or out of range, the computer generates and/or stores a fault code.
If a fault is within the engine or electronic transmission control system, the powertrain control module (PCM) will illuminates the "Malfunction Indicator Lamp" or MIL (which is the new "generic" term for the Check Engine or Power Loss warning light). If the sensor's input is essential for continued engine operation, the computer may go into a "limp-in" or "fail-safe" mode where artificial data is substituted for the missing sensor data to keep the engine running. The engine may not run properly but it will at least run.
For example, say the computer loses the signal from the throttle position sensor (TPS) or manifold absolute pressure (MAP) sensor. Without this data, the computer has no way of knowing if the engine is under load or not (a condition which typically requires a somewhat richer fuel mixture and changes in spark timing). So to compensate, the computer may substitute bogus data until the problem can be fixed. The engine, meanwhile, may hesitate under sudden acceleration or lack power under load but it will continue to run.
Loss of input from either the coolant sensor or oxygen sensor will cause most systems to revert to an open loop mode of operation. In open loop, the fuel mixture will be fixed (unchanging) and will be richer than normal, causing an increase in emissions and reduced fuel economy. As before, the engine will continue to run but won't perform as well as it should. If the distributor reference signal or crankshaft sensor signal is lost, however, there's no way for the system to substitute data for the missing information. The distributor reference signal or crankshaft sensor signal (on engines with distributorless ignition systems) are absolutely essential for switching the ignition coil on and off (ignition firing), and injector pulsing on most applications with multiport fuel injection. Without the key rpm signal, the engine won't start or run.
Sometimes a fault occurs when the data from a particular sensor is outside the normal range of values or it doesn't change or react appropriately in response to other changes that are occurring. The oxygen sensor, for example, should normally produce a signal that fluctuates between 0.1 and 0.9 volts. If the computer suddenly sees a signal outside this range, it will interpret it as a fault. Likewise, if the oxygen sensor signal fails to change and remains fixed at a constant high or low voltage when the engine is at normal operating temperature (low "cross counts"), the computer will set a code.
The exact conditions under which a fault code might be set are spelled out in many shop manuals. Referring to this information may help you better understand why a particular code might have been set and what might have caused it. That's the essence of how self-diagnostics works. There's no magic or hocus pocus involved. The computer simply monitors the incoming data, compares the data to a list of "acceptable" values and conditions under which the data is supposed to change, and if things don't match up it logs a fault code or fault message that corresponds to the problem.
RETRIEVING CODES
Some fault codes are "hard" codes, meaning the computer stores a numeric code in its memory that corresponds to the problem. Most hard codes will cause the MIL or other warning lamp to come on and remain on, but some types of problems may only cause the lamp to come on while the problem is actually occurring. It depends on the application and how the self-diagnostics of the system are programmed. In instances where there is an intermittent problem and the lamp goes out, a code will remain in memory for later retrieval. But on many applications, the code will be erased if the problem doesn't reoccur within 50 ignition cycles. On others, though, the code will remain in the computer's memory indefinitely until it is erased with a scan tool or by disconnecting the computer's power supply (which doesn't work if the computer has a nonvolatile memory).
Fault codes or messages can be read by putting the vehicle's computer into a special diagnostic mode. The exact procedure varies from application to application, but as a rule it involves grounding or jumping terminals on the system's diagnostic connector, hooking up a scan tool, analyzer or analog voltmeter to the diagnostic connector, or on certain Buick and Corvette applications pressing certain buttons on the vehicle's automatic climate control panel or driver information center to read out codes. On many import applications, codes are displayed by colored LED lights on the control module itself. Always refer to a shop manual if you're not familiar with the exact procedure that's required for the vehicle you're servicing.
Once the system is in the diagnostic mode, stored codes can be retrieved, various tests can be performed (including dynamic tests and actuator tests depending on the application), and live sensor data can be read provided the system provides serial data information and you have the proper scan tool.
Stored codes are usually displayed in numeric sequence. On many vehicles, the fault codes are proceeded by an "indicator" code that tells you to get ready because the system is going to read out any fault codes that are present or stored in memory. The fault codes may then be followed by a second indicator code that tells you "end of message." The codes may then repeat for a fixed number of times or continuously depending on the application.
On vehicles that provide "manual" code retrieval, the check engine, power loss or malfunction indicator warning light on the instrument panel may be used to display "flash" codes. With this method, the light blinks on and off in a series of flashes when the system is in the diagnostic mode. You decipher the code by counting flashes. But to interpret what the numbers mean, you have to refer to a service manual.
On older Fords, early Toyota Cressidas and Supras, an analog voltmeter can be used to manually read codes. When the voltmeter's leads are connected to certain terminals on the diagnostic connector and the system is put into the diagnostic mode, the needle on the voltmeter jumps as the codes feed out. By counting the sweeps of the meter needle, you read the codes.
READING CODES & LIVE DATA
Reading numbers on a digital display on a scan tool or analyzer is much easier than trying to count flashes of light or sweeps of a voltmeter needle. You're less apt to make a mistake, and you're usually able to extract more useful information from the system.
On vehicles that provide live serial data through the diagnostic connector (most GM, newer Ford & Chrysler, all Lexus, Geo Metro & Spectrum, most Mazda, Mitsubishi, Hyundai and Chrysler imports, and some Isuzu, Nissan, Subaru, Suzuki & Toyota), a scan tool lets you peer into the inner workings of the system. In addition to retrieving fault codes, you can read various live sensor inputs to determine whether or not a sensor is responding correctly in a given situation. Some applications (Chrysler, for example) also allow you to perform various actuator tests to see if the injectors, canister purge solenoid and other relays are responding to computer commands.
Most older import applications as well as older Fords and Chryslers, however, do not provide live serial data through the diagnostic connector. Even so, there are aftermarket scan tools and analyzers available that can be plugged directly into the computer's harness to tap the flow of data within the system.
UNDERSTANDING FAULT CODES
The most important thing to remember about fault codes is that codes by themselves are NOT the final diagnosis. They are only a starting point to begin further diagnosis. In other words, codes only tell you where to start, not what to replace. When you find a fault code using either a manual retrieval procedure or electronically with a scan tool or analyzer, therefore, do not replace anything until you've done further testing to determine what's actually causing the problem. The only thing the code tells you is that something abnormal has occurred in a particular circuit. So until you do additional testing, there's no way to know for sure which component is bad.
To isolate a fault you must usually proceed through a detailed step-by-step diagnostic procedure using a digital multimeter and a service manual as your guide. Some diagnostic charts can be quite lengthy and involved, but all of the steps are usually necessary to rule out all other possibilities and arrive at the correct conclusion. Skipping steps to save time or failing to perform the required tests correctly won't help you nail down the problem. If anything, shortcuts will lead you astray and you'll end up replacing the wrong part -- which puts you right back where you started because you failed to fix the problem.
Isolating faults is usually the most time-consuming part of the job. Is it the sensor, a bad wiring connector, a wiring open or short, or a problem within the computer itself? You have no way of knowing until you start performing the various tests. By a process of elimination, you should be able to narrow down the list of possibilities until you arrive at some sort of conclusion. This is supposed to eliminate much of the guesswork and trial-and-error diagnosis that runs up unnecessary repair bills -- in theory, that is. The catch is fault codes don't always reveal the true nature of a problem. And there are all kinds of problems that are beyond the detection capabilities of most onboard self-diagnostic systems (problems in the secondary side of the ignition system or mechanical problems, for example, like loss of compression or a bad timing chain).
SEEING SENSOR PROBLEMS
One of the best tools for outsmarting today's smart cars is an oscilloscope or a scan tool with scope capabilities. Sometimes you'll encounter a problem but won't find a fault code. Intermittent problems can sometimes happen in such a way that the glitch fails to set a code. So for situations like these, it helps if you can display sensor outputs directly as traces on a screen. You can then "see" what's going on and compare known good traces to the sensor in question.
Displaying several related sensor traces simultaneously is a fast way to detect problems that would be difficult if not impossible to detect reading digital information alone. For example, finding a momentary glitch in a throttle position sensor, or a damaged sensor ring for a wheel speed sensor. The more sophisticated scopes will even do a complete "sweep" of the system and red flag any sensors that are out of their normal ranges. But a red flag doesn't always indicate there's a problem with a sensor. A sensor may be giving a "borderline" reading that's a little too high or too low compared to the norm, yet cause no noticeable emissions or driveability problem. In such cases you have to use a certain amount of judgment to decide whether or not an "apparent" problem is in fact a real problem that requires further investigation.
USING A SENSOR SIMULATOR
Another useful tool that can speed up the diagnostic process whether or not you have a fault code is a "sensor simulator" tool or an analyzer with this kind of software capability. . A sensor simulator can simulate various voltage, frequency and resistance inputs to help you determine if a problem is in a sensor, the sensor's wiring circuit or the control module. If substituting a simulated signal for the real thing either at the sensor connector or through a breakout box solves the problem, it tells you the wiring and module are okay and that the problem is in the sensor. If there's no change in performance or operation with a simulated signal, on the other hand, it tells you the signal is not getting through to the computer (a wiring problem requiring further continuity checks) or that the signal is not being processed correctly (a bad control module).
For example, let's say an engine is running rich, the "Check Engine" light is on and there's a fault code for the O2 sensor. Is the O2 sensor bad or is it something else? To find out, disconnect the O2 sensor, set the sensor simulator to produce an O2 sensor signal (which you can vary from a fixed lean reading to a rich signal), connect the test leads to the O2 sensor's wiring connector, start the engine and see what happens. If there's no change in the fuel mixture when you switch the input signal back and forth from lean to rich, the problem isn't a bad O2 sensor. It's in the wiring or PCM.
A sensor simulator can also be used to alter the operation of a computerized engine control system when performing other diagnostic tests. By simulating a hot or cold input signal from the coolant sensor, you can change the operation of the computer from closed loop to open loop. This type of substitution may be helpful when performing a power balance test on some vehicles. Running in open loop prevents the computer from changing the idle speed when cylinders are deactivated. Some other uses of this type of diagnostic tool include:
* Simulating a throttle position (TPS) sensor signal to vary the idle fuel mixture (changes the duration of the injector pulses).
* Simulating a barometric pressure sensor or MAP sensor signal to switch the fuel mixture and timing between "high altitude" and "normal" settings.
* Simulating a manifold absolute pressure (MAP) sensor signal to check for changes in ignition timing and fuel enrichment.
* Simulating a mass airflow (MAF) sensor signal to monitor changes in fuel enrichment.
FAULT OR NO FAULT? Great as onboard self-diagnostics are, sometimes they're not much help. An intermittent warning light is one such problem that can drive you nuts. With some onboard self-diagnostic programs, certain intermittent faults cause the warning light to come on only when the problem is occurring. The rest of the time, the light remains off. That doesn't mean the smart car has fixed itself. The problem is still there -- so check for codes even if there's no light.
Sometimes you'll find an intermittent warning light but no code. Is there a problem or isn't there? One way to find out is to test drive the vehicle with a portable "flight recorder" device attached to the onboard electronics. The recorder captures the live data stream information so a "snap shot" of the data can be recorded when the problem occurs. By analyzing the data later, you may then be able to determine if indeed there's a problem. But this technique only works on vehicles that provide access to the data stream. And it only works if somebody presses the record button to capture a window of data when the problem occurs. One of the limitations of flight recorders is that they don't read data continuously but rather take samples of data every little bit. If a momentary glitch occurs between data samples, the recorder may not catch it. That's why some technicians prefer to display and watch live sensor data on a scope so they can see intermittent problems that don't show up well on most scan tools or flight recorders.
Intermittent faults are the worst to nail down because the pass/fail tests that are part of most diagnostic procedures may not catch an intermittent problem if the problem isn't acting up when a particular test is performed. Consequently, you continue along the wrong path and end up making the wrong diagnosis and replacing the wrong part. Or you reach the end of the diagnostic tree (and your rope) only to find yourself no closer to solving the problem than when you started. Everything apparently checks out okay but the problem is still there. Now what?
The only way to find an intermittent fault is to try to duplicate the operating conditions that are present when the fault occurs. Heat, cold, vibration and moisture are four variables that may play a role in causing an intermittent fault. Anything that causes a momentary short or open in a circuit will cause a change in the circuit's voltage. A loose wiring connector that breaks contact momentarily when it gets hot, wet or vibrates is a classic cause of many intermittent faults. Test driving a vehicle until the fault appears is one way to get an intermittent fault to repeat. But test driving can eat up a lot of time. And there's no guarantee the fault will reoccur. Nor is there any guarantee that a flight recorder will catch it either. A better approach might be to try duplicating in the service bay what happens during a test drive. Start the engine and allow it to reach normal operating temperature. With a scan tool or computerized analyzer connected to the vehicle, see if you can create a momentary glitch by wiggling, blowing hot air, spraying water, etc. on the suspected wiring connectors or components. Sometimes this approach works and sometimes it doesn't.
FALSE CODES "False" codes are another glitch that can sometimes create ghosts in a smart car. A voltage spike or transient electrical surge may trigger a code for a problem that doesn't exist. An arcing plug wire, an open diode, electromagnetic interference from a spark plug wire that's routed too near a sensor circuit, etc., may all be potential causes of false codes. On older GM C3 systems, for example, arcing between the ignition coil and ground or at the spark plug wires can sometimes cause an intermittent Check Engine light but no trouble code. So can an open diode across the air conditioner compressor clutch, intermittent shorts or grounds in the wiring harness (grounding terminals A and U or applying battery voltage to terminals C and R).
False codes can also be triggered while performing certain test procedures or making repairs. Sometimes you'll find old codes that have been left in memory from a previous problem that has since been repaired (a good reason for always erasing codes after repairs have been completed).
The only way to be really sure whether or not there is a real problem is to
(1) read and record all stored codes, then
(2) erase them with a scan tool or by removing the module's fuse, and
(3) test drive the vehicle or run a self-test (Ford) to see if the same code or codes reappear.
Don't disconnect the battery to erase stored codes because you'll also erase all the settings in the electronic radio and climate control system. Also do not disconnect anything electrical when the key is on or while the motor is running. Doing so may create a voltage spike that could damage sensitive electronic components. For some kinds of false code problems, a manufacturer may issue a Technical Service Bulletin (TSB) describing the nature of the problem and how to fix it. In some cases the cure may involve rerouting wiring or replacing a component with a new or revised part. So the only way to outsmart these kinds of problems is to have access to the factory TSBs, which you can get from All-Data, Chilton or Mitchell.
