OBD导读 → MOTOR → 2008 | 2007 | 2006
Datastream In-Depth Analysis
By Sam Bell | August 2008
We began this two-part article with a discussion of preliminary OBD II datastream analysis, conducted with the engine off. We’re going deeper this time, to explain the value of datastream information collected with the engine running.
Last month’s installment on datastream analysis focused on the value of freeze frame data, Mode 5 and Mode 6 data and KOEO (key on, engine off) datastream. This month’s discussion picks up where we left off, with KOER (key on, engine running) analysis. So go ahead, start the engine!
I recommend that KOER data collection always start in the generic, or global OBD II interface. Why? Because generic datastream PID values are never substitutes for actual sensor readings. For example, you can disconnect the MAP sensor connector on a Chrysler product and drive it around while monitoring datastream in the enhanced (manufacturer-specific) interface. (Try this yourself; don’t just take my word for it.) You’ll see the MAP PID change along with the TPS sensor reading and rpm, showing a range of values that reflect likely MAP readings for each condition, moment by moment. These are substituted values. If you looked at the MAP voltage PID, however, it would show an unchanging reference voltage. In the enhanced interface, substitutions can and do occur. But in the generic interface, substituted values are never allowed. You would see MAP shown at a constant pressure equal to something a bit higher than BARO. The generic interface allows calculated values, but never substituted values.
So, what are we looking for, now that we’ve finally started the engine? The specific answer, of course, will depend largely on the details of the customer complaint and/or DTC(s) that are stored. We might, for example, be focusing on fuel trim numbers (and trends) if our code suggests an underlying air/fuel metering problem. We might be looking most closely at engine coolant temperature, and time-until-warm measurements when that seems warranted. Perhaps our problem lies in the evap area, or involves EGR flow. But ultimately, it doesn’t matter what the specific issue is; we’ll have to focus in on the systemic interactions that determine the overall characteristics of a particular data set.
Here’s a concrete example to illustrate what I mean. The vehicle in question is a 1999 Chevy Venture minivan with the 3.4L V6. There was a DTC P0171 (Exhaust Too Lean, Bank 1) in memory with an active MIL. The sum of Short Term and Long Term Fuel Trims in freeze frame was in excess of 50%. Fuel pressure and volume had been verified as within specification.
When evaluating a fuel trim trouble code, one of the first steps must always be to verify that the oxygen sensor (on which the DTC is based) is functioning correctly. During the test drive, I observed the O2 sensor switching rich, but not as often as would be expected if the very large fuel trim corrections shown were actually effective. Indeed, on the face of it, datastream seemed to confirm the DTC. Longtime readers, however, can probably anticipate what my next tests were: I checked the actual lambda value of the exhaust gases. Then I looked for a dynamic response as I artificially enriched the system with a blast of propane, then enleaned it by disconnecting a major vacuum hose. (See “What Goes In�Harnessing Lambda as a Diagnostic Tool” in the September 2005 issue of Motor. Search the index at www.motormagazine.com for all Motor magazine articles mentioned.) Having found the idle lambda at a ridiculously low value of .85 (indicating a mixture with 15% more fuel than needed), I was not surprised to see that the O2 sensor didn’t register a rich condition until the engine was very nearly flooded with propane. When I removed the purge hose, engine rpm climbed and the engine smoothed out, while lambda marched toward the stoichiometric ideal value of 1.00. Once the faulty O2 sensor was replaced, all aspects of driveability improved, and the minivan returned to its previous fuel consumption levels.
Dynamic tests verify DTC accuracy. In some instances, we may be able to utilize bidirectional controls embedded within our scan tool packages to actuate various components. In other cases, we may need to improvise, using signal simulators, power probes, jumpers, propane or just good, old-fashioned test driving as required to initiate change within the system we’re working on. (I’m not saying that it will always be as easy as it was with the Venture. You and I know there will be problems that don’t set DTCs, problems that do set DTCs that have no apparent connection to the actual root fault and, of course, problems that set appropriate codes yet are still really hard to diagnose.)
Floodlights and Spotlights
One of the most powerful features of most scan tools is, as nearly as I can tell, one of the least used. This is the so-called flight recorder, data logger or movie mode. By whatever name it’s known, this is an analytical tool of considerable value.
Chart on page 38 Data collection and analysis might yield some helpful information, if you can find the wheat within the chaff. This is only a small portion of a larger data set with 100 values per PID.
Take a look at the portion of saved scan data portrayed in the chart on page 38. As you see, any value in that information is well hidden. This might be termed a “floodlight” view, showing too many values for too many parameters. But look at the “spotlight” view above, where I’ve selected and graphed a few of the same PID values. This was a vehicle where there was no DTC stored in memory. By including both upstream O2 sensors, I have provided myself a cross-check, as there is less likelihood of both being bad. Similarly, MAF and rpm track nicely with one another, again providing a good cross-check. The data values at the cursor (the vertical line at frame 2) are called out at the left side of each PID’s plot. The upstream O2 sensors are switching nicely at 2000 rpm (as shown at frame 251), but the graphic interface reveals an obvious problem at higher speeds as the O2 sensors flat-line lean. A new fuel pump restored the missing performance.
Graphical representations of scan data “movies” can speed analysis. As an added bonus, using your scanner’s flight recorder mode allows you to concentrate on your driving. The data set here clearly points to a lack of adequate fuel volume. This graphical representation is derived from the exact same movie capture seen in the chart on the previous page.
Slow Motion and High Speed
Moviemakers speed up or slow down the action on the screen by shooting at different numbers of frames per second. When film shot at 20 frames per second is played back at 60 frames per second, the action seems to be occurring at three times the speed. Just as a 56k dial-up modem is slower than a DSL Internet connection, scan data transfer rates also vary according to the interface used. Generic communication modes often travel at a crawl, especially in comparison to CAN speeds. If you’re stuck with a generic interface, you can often accomplish more by looking at less.
The key here is PID selection. Choose the smallest number of PIDs that will give you the information you actually need. Three or four are usually sufficient. This is your version of the filmmaker’s high-speed action trick, as you get more updates per unit time the fewer PIDs you select. With several hundred possible PIDs from which to choose, it’s just too easy to miss an intermittent data glitch, or to drown in a sea of too much information (see “Live Data vs. ‘Live Data’” on page 44).
Live Data vs. ‘Live Data’
Intermittent interruptions of sensor data can cause tricky driveability problems. Some glitches may set a DTC while others may not. While viewing datastream may reveal an intermittent sensor problem, it should not be relied upon to do so. The issue, once again, is in the data rate. Even a moderately fast interface, say the 41.6 kbps (kilobytes per second) J-1850 PWM used on many Ford products, can easily miss a several-millisecond dropout if it’s not that particular PID’s turn in the datastream. Where symptoms or DTCs point toward an intermittent sensor glitch, you’re probably better off breaking out your scope or graphing multimeter.
Most Motor readers are familiar with the ways in which some of the major OEMs have organized data PIDs for display in their enhanced scan tool interfaces. Groupings such as Misfire, Driveability, Emissions, Accessories and the like are good examples of the types of data sets you may want to construct while analyzing different sorts of problems. Tracking down a nasty intermittent problem? Don’t hesitate to pare down the OEM groupings even further to speed data updates.
Code-Setting Criteria and Operating Conditions
If we’re trying to resolve a MIL-on complaint, it’s critical that we first review both the exact code-setting criteria and the operating conditions as revealed in our previously recorded freeze frame data. We’ll need to drive in such a way as to complete a good “trip” so the affected monitors can run to completion. (For a more detailed discussion of OBD II trips and monitors, see “Monitors 1.01″ on page 40.) If we fail to meet the conditions under which the self-test (monitor) will run, we cannot hope to make progress. Using the previously recorded freeze frame parameters gives us a good general idea of the operating conditions required. Merely duplicating speed, load, temperature and other basic characteristics may not be enough. This is why we need to review and understand the details of the code-setting criteria and the monitor’s self-test strategy. For example, some monitors cannot run until others have already reached completion. A typical example would be a catalytic converter monitor that is suspended until the oxygen sensor monitors have run and passed.
MONITOR 1.01
Most MOTOR readers have at least a passing familiarity with the concept of OBD II monitor completion status. Even so, a brief refresher may be in order. OBD II monitors are simply formalized sets of self-tests all related to a particular system or component.
Continuous monitors.
With a few very rare exceptions (mostly for 1998 and earlier models), the so-called continuous monitors always show up as “complete,” “done” or “ready.” Take this status report with a grain of salt. Unplug the IAT sensor, start the engine and check that the “Comprehensive Component Monitor” readiness status shows complete. Is the MIL on? Are there any pending codes? How long would you have to let the vehicle idle before it will trip the MIL and show a P0113 (IAT Sensor Circuit Voltage High) DTC?
As it turns out, depending on the specific make, model and powertrain package, there are several specific criteria that must be met before the code will set. In one instance, the PCM must detect a VSS signal of 35 mph or more and an ECT value of 140°F or more, the calculated IAT must be less than 38°Fand all of these conditions must be met for at least 180 seconds of continuous duration, during which no other engine DTCs are set—all while MAF is less than 12 grams per second. (This particular example, incidentally, is a two-trip code. Some other manufacturers may make this and other DTCs under the component monitor’s jurisdiction into one- or twotrip codes, sometimes with even more complicated entry criteria.)
Continuous monitors include the comprehensive component monitor, the fuel monitor and the misfire monitor. Each monitor runs continuously when conditions are appropriate, but not during all actual driving. For example, the misfire monitor is often suspended during 4WD operation, since feedback through the axles over rough roads might cause uneven disruption of the CKP signals, which could otherwise be misidentified as misfires. Similarly, extremely low fuel tank levels may suspend both misfire and fuel system monitors to avoid setting a DTC for running out of gas.
Noncontinuous monitors.
As I pointed out last month, it’s important to note the readiness status of the other, noncontinuous monitors as well. These are the monitors whose status will change to “incomplete,” “not ready” or “not done” when the codes are cleared. If a vehicle arrives at your shop showing one or more incomplete monitors, it’s likely that someone has already cleared the codes beforeit got to you. (There are a few vehicles—for example, some 1996 Subarus—which may reset monitor status to incomplete at every key-off, or other vehicles which may have certain monitors which cannot be made to run to completion in normal driving, such as the evap monitor on some Toyota Paseos.) If a vehicle shows up with incomplete monitors, however, you should certainly document that fact on your work order and be sure to advise the customer that there’s a very real possibility that one or more other codes may recur after the current repair has been completed. For more on this subject, see my article “How Not to Get MILStoned” in the April 2004 issue of MOTOR.
More importantly, for our present purposes, the existence of incomplete monitors means that you may not be getting the whole picture as to what ails the vehicle you’re looking at. Keep an open mind, remembering that there may be other, as yet unknown issues hidden behind that incomplete monitor, and try not to rush your diagnosis. As mentioned in last month’s installment, there may be some valuable data accessible via Mode 6 even if the monitor is not complete, but there is a very real possibility that Mode 6 data for any incomplete monitor may turn out to be unreliable. And, of course, don’t overlook any pending DTCs. Remember, these do not illuminate the MIL, so you must seek them out on your own.
Some trouble codes, or even pending codes, suspend multiple monitors. Other vehicle faults may then go undetected until all monitors can run again. A P0500 (VSS Malfunction) in a Corolla, for example, will effectively suspend even the misfire monitor.
The net result is that we may have to clear the current DTCs and extinguish the MIL before our test drive can bear fruit. (But again, please be sure to read and record all the freeze frame data, the status of all monitors, the list of both current and pending DTCs and any available Mode 6 data before clearing the MIL (see “Lights Out?” on page 42).
Lights Out?
It seems like a no-brainer: When you’re done with all your diagnostic tests and you’ve made the necessary repairs, you should turn off the MIL, right? That’s what your customer probably expects, and as we all know, meeting customer expectations is an important part of running a successful business.
But there are often times when you should leave the MIL on. If your area uses an OBD II “plug & play” emissions test, the regulations usually require that no more than one monitor can be incomplete as of the time of testing for model year 2001 and newer vehicles, with no more than two incomplete monitors for 1996 to 2000 models. In some areas, retest eligibility requires that the converter monitor must show “complete” before a retest is valid.
If an emissions test or retest is looming in your customer’s future, you and he must work out the pros and cons of clearing the codes and resetting the monitors to “incomplete.” If you clear the codes, the monitors will reset as well. This will require that someone will have to drive a sufficient number of monitors to completion before a retest will be valid. If local weather conditions, for example, will prevent the monitors from running in a timely way, your customer might be better off if you leave the MIL on. Then your customer would have to drive only those portions of the drive trace needed to run the monitor under which the current DTC set.
For example, if you’re in the frigid climes of an upper Midwestern winter and a customer’s vehicle failed an emissions test because of a faulty O2 sensor heater, you’ll both be ahead if you don’t clear the code, letting it expire naturally as the heater monitor runs successfully to completion on the next two trips. This will avoid the necessity of rerunning all the rest of the monitors. Of course, if the vehicle failed the evap monitor, you’ll be better off clearing the code, because prolonged subfreezing temperatures may make running that particular monitor successfully virtually impossible for weeks at a time.
We’ll need to drive long enough to let the monitors in question reach completion. In some cases, this may require an extended period of time. Many Ford products, for example, normally require a minimum of a six-hour cold-soak before the evap monitor can run, although there may be ways to force this issue in some instances. Many Chrysler oxygen sensor monitors run only after engine shut-down (with key off), so that no amount of driving will ever bring them to completion. Certain monitors, and apparently even certain scan tools, may require a key-off sequence before the monitor status will update from incomplete to complete. Motor offers an excellent resource to help you understand these details-the OBD II Drive Cycle CD Version 7.0, available from your local Motor Distributor (1–800–4A-MOTOR).
In some cases, local weather conditions may make monitor completion seem impossible until a later date, usually because of ambient temperature requirements, although sometimes as a result of road conditions. In most cases, however, it will still be possible to complete the monitor by running the vehicle on a lift or dynamometer. This option may occasionally result in setting, say, an ABS code, but most monitors can be run to completion swiftly and successfully on a lift. This option may also offer a safer, faster alternative to actual driving, as trees and telephone poles are less likely to jump in front of a vehicle on a stationary lift.
Conclusions
Proper in-depth datastream analysis can often light the way toward correct diagnosis of driveability concerns. Recording all available DTCs, pending DTCs, freeze frame data and Mode 5 and Mode 6 results before clearing any DTCs is essential. Specific setting criteria for each DTC are manufacturer-determined, regardless of whether the code assigned is generic or manufacturer-specific. Freeze frame data sets can be used to recreate the operating conditions under which a previous failure occurred and can help illuminate the conditions under which certain self-tests are conducted. Mode 5 and Mode 6 test results can help in analyzing the type and extent of certain failures. KOEO datastream analysis can sometimes reveal sensor faults or rationality concerns that might otherwise be overlooked.
Looking at KOEO and KOER datastream on a regular basis makes known-good values familiar. Once you know the correct values, the conditions accompanying problems identified by freeze frame are easier to spot. KOER data can highlight current problems, especially when used in conjunction with graphical scanner interfaces. Generic data PIDs cannot include substituted values, and so may point up faults easily overlooked in more enhanced interfaces. Careful selection of custom-grouped PIDs can provide faster scanner update rates.
Pick your tools wisely. To verify hard faults, monitor datastream as you run actuator tests. Look for any mismatch between the command sent to a component and its actual response. For intermittent problems, record and graph data. In tough cases, test circuits with your scope or meter to verify actual voltage for comparison to specs.
Used properly, these techniques will help you arrive quickly and confidently at an accurate diagnosis of the root cause of most driveability complaints.
所有MOTOR的文章都可以在MOTOR官网下载得到.