In past issues we’ve given you an overview of how OBD II works. Now, we expand on that and provide some practical procedures

Although it’s hard to believe at this high-tech juncture, there was, of course, a time of NOBDAA — No On Board Diagnostics At All. “Back in the day” diagnosis was accomplished by visual inspection, measurement and disassembly 100% of the time. Pressure from California and the EPA starting in the late ‘70s gave us OBD I, a system that illuminated a Malfunction Indicator Lamp (MIL) when a fault was present and turned off the light when the fault went away. There was no provision for any performance monitoring – a continuous monitoring of all Powertrain Control Module (PCM — commonly referred to as an ECU for Electronic Control Module in Subaru vehicles) inputs and outputs – and no PCM directed testing sequence, or active means to check component failure. It was designed only to alert the driver in the case of a hard fault, more a fault monitoring and reporting system than anything else. Additionally, code retrieval and data gathering wasn’t standardized and specific first generation scan tools were required for specific cars; even the location and style of access connector varied from car line to car line.

The 1996 Watershed

It didn’t take long for the California Air Resources Board (CARB) and the EPA to recognize that emissions improvement with that system was minimal at best, and would over time fail to meet clean air objectives. In addition to the “black electrical tape over the light” repairs of that era, car owners were reluctant to show up voluntarily to pay to fix what they perceived to be the annoyance of a simple warning light unless there was an irritating symptom attached to MIL illumination. Frustrated with the lack of air quality improvement, the CARB and the EPA, along with the Society of Automotive Engineers (SAE) and other interested parties, worked on the language, legislation and standardization that eventually become law in the Clean Air Act of 1990, which mandated that a new system, On Board Diagnostic System II (OBD II) be in place and operational on all cars sold in the United States in the 1996 model year (Subaru beat this by a year).

OBD II is radically different from its predecessor in a variety of ways. First, a host of standards were developed by SAE and adopted by manufacturers covering such things as protocols, information, terminology, generic and enhanced scan tool applications, security and languages. But more important to a technician, OBD II began using the PCM not only to continuously monitor inputs and outputs, but also to initiate intrusive (detectable by the driver under certain conditions during the test) and non-intrusive tests to determine degradation of system performance. Suddenly, a whole series of fault codes often numbering in the several hundreds were available to help pinpoint upcoming and developing failures.

These PCM-ordered diagnostic tests or “monitors” run on the evaporative emission system, the fuel trim system, the catalyst, the EGR, the air injection system (if so equipped), the oxygen sensors, and oxygen sensor heaters, and includes a comprehensive component monitor as well as a continuous misfire monitor. Monitors will only run after the PCM determines that specific vehicle preconditioning events have been completed to place the system in an optimum test posture prior to initiating the test sequence. This is done to assure repeatability and to prevent spurious Check Engine Lights.

Cracking the Codes

SAE standard J2012 defines Diagnostic Trouble Code (DTC) types and definitions. The five-digit alpha-numeric DTC can be deciphered as follows: The first position is a letter that designates which controller is reporting, or which controller has a problem. Body is “B,” chassis is “C,” powertrain is “P” and “U” is network (a holdover from UART, for Universal Asynchronous Receive and Transmit – a communications protocol).

The first number position can be a “0” for an SAE or generic code, or a “1” or “2” for a manufacturer-specific code. This provision is there in case a manufacturer decides to offer more functionality than required by law, a feature taken advantage of by virtually all carmakers. It’s important to note that manufacturer-specific codes often will not be read by generic scan tools. By law, only SAE-defined codes must be reported to non-manufacturer scan tools, although most will detect at least some of the non-required codes. The next digit indicates which vehicle system or sub-group is reporting. For example, P0100 is air metering and fuel system, P0200 is fuel system (injector only), P0300 is ignition or misfire, P0400 is emission control system, P0500 is idle speed control or vehicle speed sensor, P0600 is computer output circuit (such as a relay or solenoid), and P0700 pertains to transaxle or transmission faults. The final two digits are the specific fault designation for that code.

It’s important to note that for some monitors to run, you must have fuel levels and charging system voltages within certain parameters, and in some cases a whole series of events must occur or be maintained for a specified period of time prior to the PCM authorizing test initiation. It’s equally important to know that not every code sets on a single trip or event. Some require multiple failures on consecutive trips to set. I mention this because it’s important to know not only what OBD II can do for you, but also to you during your test process! Some of the most painful lessons a tech might learn can occur because of assumptions made about sequencing, test initiation and vehicle preconditioning.

When the MIL Comes On

A successful repair begins at the service write-up session with just a bit of customer education, and a careful use of words. We prefer to never use the terms “diagnose” or “diagnostics” when discussing the problem with the customer. These terms might best describe what we’re doing, but they sound too clinical to most customers, and since they’re used in the medical field their use conveys a contextual meaning of “very expensive”, immediately putting you and the customer at odds. We’ve found that the words “testing”, “tests,” “inspection,” “evaluation,” or “evaluate” are less confrontational to the customer, and we try to use those words exclusively. For example, we might say, “We’ll need to perform some preliminary inspections to properly evaluate your concern today. I’ll have the technician road test your car to confirm the condition, and he’ll then run tests to determine the reason the light came on.”

To best illustrate how the MIL operates to a customer, use the fire alarm and apartment building analogy. We know we have a fire, and we know it’s somewhere in the building, but we don’t know what floor it’s on, or the apartment number in which it’s contained. Go on to explain that extinguishing a fire on the tenth floor, apartment number five doesn’t mean that other fires might not occur later on other floors or in other apartments, or that multiple fires might not have broken out. It’s important to convey the fact that this one single lamp alerts the driver to faults in a number of systems and its job is to monitor thousands of parts. Covering this with the customer helps eliminate misunderstandings later should the MIL come back on a short time later due to a subsequent unrelated failure.

Another analogy that will help customers understand the testing process is that of a ladder. Explain that system testing is similar to climbing a ladder. Each rung must be intact to allow the tech to progress up the ladder, and that broken rungs will need to be replaced as they are encountered. Broken rungs that are bypassed or skipped over may change test results further up the ladder, so skipping past a known fault isn’t a good option.

A technician can never have enough information when chasing intermittent difficulties, so the customer contact person needs to ask the right questions. Subaru has an excellent interview checklist that can be found in the service manual section of the website (http://techinfo.subaru.com) by going to “year/model/service manual/engine/engine diagnosis/check list for interview.” We know some people don’t like structured interview tools, but they sure can help when you’re chasing a difficult problem because they will help you nail down the circumstances under which the fault occurred.

If you doubt the need for such tools, log onto the website and look under OBD information and you’ll see a table listing the system or component under test, the failure codes generated, the malfunction criteria and threshold values that trigger the code. Contained in those same tables is a list of secondary systems and their required status to run the monitor, in addition to the amount of time the fault needs to be present before setting the MIL and the number of consecutive failed drive cycles needed before MIL illumination.

As you can see from the table, not every code sets on the first failed drive cycle, and not every drive cycle meets the criteria needed for running the test, and that’s why it’s critical to capture the kinds of information found on the check list. It records all sorts of data, like fuel brands, weather, temperatures, highway or city, smooth or rough roads, engine temperatures, speeds, driving conditions and the status of various accessories (on or off). It’s well written and in our opinion deserves a place in your customer contact process.

Back in the Bay

Once we’ve got the complaint and customer information captured, the hard work of confirmation, testing and repair begins. Even though the Subaru diagnostic process doesn’t say so, a brief road test will sometimes reveal other symptoms that escaped the customer’s notice, and will confirm MIL illumination.

The MIL comes on any time the OBD II system detects a fault that exists for the required time interval for that code with all enabling criteria met. Some codes set immediately, some codes only require one drive cycle to set, other codes require two consecutive drive cycles to set, while still others set immediately and flash the MIL. If the failure is catalyst damaging, the MIL will flash, alerting the driver to the urgency of the condition.

Once the vehicle performs and passes the monitor for three consecutive trips the MIL is turned off, but a trouble code is stored until the clear memory mode is entered, the battery is disconnected, or the vehicle passes the monitor forty consecutive times. Until the memory is cleared, a failure record containing limited data captured at the time of failure will be retained to aid in diagnosis. Depending on the type of code and failure, the powertrain controller may enter a fail-safe mode, which can affect vehicle operation and generate additional comments about low power or poor performance.

There are a couple of sections in the service information that are invaluable aids to diagnosing the MIL. One regarding failure code detecting criteria can be found at “year/model/service manual/engine/general description/DTC detecting criteria,” and lists the outline of diagnosis, the enable criteria, the driving cycle, the diagnostic method, the DTC clear conditions, the MIL clear conditions, the fail safe provisions and ECM operation at the

time of code set. This is VERY valuable stuff in a quick and easy-to-understand format. The second resource is found at “year/model/service manual/engine/engine diagnostics/drive cycle.” This section will give you the needed information to properly road test the car after repairs to confirm the fix, and it lists the required road test by DTC number. Those of you who have road tested a car for 60, or even100 miles in an attempt to get a monitor to rerun after repair will love this tool.

Once in the bay, use the scan tool to confirm the codes, note and record the failure record for intermittent codes. The basic Subaru diagnostic procedure, found at “year/model/service manual/engine/engine diagnostics/basic diagnostic procedure,” only confirms that the engine will run and that the MIL is on before taking

you directly to the flow chart for that DTC. You will find the DTC trouble charts at “year/model/service manual/engine/engine diagnostics/diagnostic procedure with DTC.” These trouble charts are excellent, with schematics, connector end-view and pin-outs right at the chart.

While there are occasional glitches in the Japanese-to-English translations, they are still outstanding, and follow the familiar “if this, then that” step-by-step walk-through the diagnostic process we’ve become accustomed to using in our shops.

Having the right tools makes all the difference in fixing the car and Subaru has done a commendable job of making the most important tool — comprehensive information — available to every tech working on these tough, dependable cars.

Download PDF