While nothing can beat the genuine Subaru Select Monitor for troubleshooting subtleties, many independents have had enough success with aftermarket enhanced OBD II scan tools to make that investment largely unnecessary.

We vividly remember resistance to OBD II on the part of some highly-skilled automotive diagnosticians back in the early ‘90s. They scoffed at the whole concept, saying that late-model proprietary, make-specific, non-standardized data streams provided much more information than the standardized OBD II version would, and that such standardization amounted to a step backwards.

Well, we believe that was just a symptom of an unwillingness to change or learn something new because, as most of us working technicians have found, OBD II has been an extremely helpful troubleshooting aid. No, it won’t give you everything you can get from a factory-designated scan tool, such as  the excellent Subaru Select Monitor, but its capabilities will allow you to zero in on a very high percentage of the driveability and emissions problems you are apt to encounter, and the tests it performs on the whole engine management system are downright amazing.

In conversations with numerous independent Subaru specialists around the country, we’ve found that some have indeed invested in the Select Monitor and are very happy with it, but that others seem to be doing fine with an aftermarket scan tool. This last group has most certainly made the effort to learn how to get the most out of OBD II.

Regardless of your opinion of OBD II, like the whole emissions control effort that has driven the development of new automotive technology over the last four decades (see sidebar), it is an immutable fact of life, so you’d better be sure you understand it.

Early glitches

True, early OBD II systems had some problems. For example, the ‘95 and ‘96 Legacy, Impreza and SVX versions may exhibit a “not ready” condition during a state I/M program inspection because they reset their readiness code at each engine shut-down event, with the result that they might be rejected and in effect fail the exam even though no problem exists. Actually, however, when this system detects a malfunction, it stores the proper DTC (Diagnostic Trouble Code) and illuminates the MIL (Malfunction Indicator Lamp) just as it should regardless of the readiness status, so it meets the I/M emissions standard. SOA got this situation straightened out by informing the EPA, which then issued modified I/M guidelines, and also sent out a bulletin explaining the situation. Later models retain the results of their monitors, so this was no longer an issue.

Also, it was often impractical to do what was necessary to get the monitors to run — you could spend lots of valuable working time driving around trying to establish the Enabling Conditions. But around the turn of the century, the software improved dramatically, and the process along with it.

Modus operandi

Before you can put OBD II’s troubleshooting capabilities to use, you need a clear idea of how it works. Doesn’t it seem almost like science fiction that the engine management system can do comprehensive tests on its own job performance, warn you when there’s a problem, plus guide you in the right direction to fix itself? But it’s not far-fetched at all. It’s been on our roads for a decade.

It’s an understatement to say that OBD II’s operations are complex, so managing them properly requires sophisticated logic inside the ECM. The software that puts all that computer power to work can be compared to a traffic cop at the intersection of all the information coming into the ECM. It must efficiently coordinate the operation of the emissions-related components and determine whether or not the diagnostic systems are working okay. It decides which tests and functions happen when.

To put it another way, the diagnostic executive or task manager organizes and prioritizes the diagnostic procedures. Its job includes determining if the conditions necessary for the tests are present, recording the results, MIL illumination, DTCs and freeze-frame data storage.

There are times when tests can’t be run for various reasons. If it’s because another test is in progress, this is referred to as a “conflict.” If it’s because another test has failed, it’s called “pending” — it postpones the monitor PENDING resolution of the original problem. If it’s because the software has set a fault that may cause a failure of the test, it’s called “suspended.”

Action plan

We’d better take a look at the big picture of OBD II’s logic. What actions is it intended to take when it detects a problem? 

To boil it down to essentials, it will illuminate the MIL if a system or component fails or deteriorates to the point where emissions could rise to one and one-half times the Federal Test Procedure standards.

From an emissions standpoint, a misfire is about the most dangerous malfunction that can occur in a vehicle. Not only does it pump raw hydrocarbons out of the dead cylinder, but this extra fuel can cause the reaction inside the catalyst to become so hot that the cat either loses its ability to do its job, or actually melts down, perhaps clogging the exhaust system. 

So, the instant the management software detects a misfire, it doesn’t just switch the MIL on, it flashes it once per second. The flashing stops only when the vehicle is being operated outside of the load and speed modes that could damage the cat. Even then, the MIL stays on steadily.

In fact, misfire is considered so important that the software not only turns on the MIL when it detects this problem, but actually stops injecting fuel into the misfiring cylinder. Also, a DTC associated with misfire will overwrite the freeze frame data from all other DTCs.

For most other tests, the OBD II management software won’t turn the MIL on until it sees two failures. That way, there won’t be numerous erroneous, hence motorist-irritating, warnings.

We mentioned Enabling Criteria above. These are the operating conditions that must be fulfilled before the self-diagnostic tests can begin. To use the EGR monitor as an example, the ECM checks the EGR solenoid every time the ignition is turned on, but won’t run the flow test until:

• The engine has been running for at least 190 seconds.
• The EGR solenoid is energized.
• Coolant temperature has reached at least 158 deg. F.
• Engine speed is between 2,000 and 2,600 rpm.
• Injection pulse width is 4.1 to 6.92 milliseconds.
• Throttle angle is between 5.76 and 24.96 degrees.
• Throttle angle fluctuation is less than one degree during 100 milliseconds of operation.
• Barometric pressure is greater than 507 mm Hg.

Also, there can be no failures present in the sensors for air flow, crank angle, cam angle, throttle position, coolant temperature, and the EGR solenoid.

Enabling Criteria are not usually published in the service manual, however. What you might find instead is the Confirmation Driving Pattern, which is a description of the exact way the car must be driven to meet the criteria. No, this can’t be done on a lift, and would also be difficult to achieve on a dynamometer. Note that operating the car from a fresh start so that it matches the Confirmation Driving Pattern, thus meeting the Enabling Criteria, is known as a “trip.”

Practical points

It would be possible to write dozens, maybe hundreds, of pages of description of how OBD II does its job and how to use it to its utmost. We haven’t got that liberty in a magazine — you’ll have to refer to the service manuals Subaru makes available on http://techinfo.subaru.com. But we can offer several practical points to keep in mind:

• While DTCs aren’t perfect, they’re definitely the first thing to check into when you’re presented with a driveability problem, a failed emissions test, or, of course, an illuminated MIL because they’re so easy to access. Don’t, however, let them short-circuit your basic visual inspection: Are any wires damaged or connectors loose or corroded? Is there coolant in the oil, or visa versa? Is the duct between the MAF and the throttle body perforated? Is the cooling system in good shape? How’s that compression?
• If you don’t bother to use the misfire monitor, you’re missing out on a good bet. This is one of our favorite features of OBD II because you can look at the misfire counts by cylinder, thus zeroing in on the problem wire, plug, etc. You can also clear the code, spray water or a special secondary ignition solution on the wires and cap, and see what you get. Typically, most cylinders will be okay, but one or two will show misfire counts. Pull the plug and test the wire. This is even better than using a traditional ignition oscilloscope, and it takes no set-up at all.
• We’ve observed that techs often don’t take advantage of freeze-frame data. That is, the information recorded about operating conditions at the moment a DTC is set, such things as vehicle speed, rpm, coolant temperature, and MAP value, long- and short-term fuel trim, etc. That’s unfortunate because an abnormal number here can help point you in the right troubleshooting direction.
• Since Subaru has garnered a high-performance image and almost a cult following, lots of people have taken to adding modifications that purport to enhance power output. But some of these hot-rod changes, such as free-flow air cleaners and mufflers, can throw OBD II a curve, causing MIL illumination and DTCs. So, make looking for the presence of these mods one of the first steps in troubleshooting. If they put the engine management system into limited operating strategy, performance may actually be decreased instead of enhanced. So, recommend or install only Subaru-approved performance parts.
• The best advice we can give you on how to get the most out of OBD II is to spend some time investigating the capabilities of your scan tool on cars that don’t currently have any problems. Browse the various menus, make random choices, note readings, etc. until you’re comfortable with the whole operation and have a good idea of what normal looks like.