A diagnostic strategy for driveability

Kiran Dhaliwal starts the last level of her apprenticeship at Ridgeline Auto Service in Calgary with a new kind of job ticket. Until now most of her work has started with a code, a noise or a part that had obviously failed. Marty Kowalchuk hands her a repair order for Erik and Anna Lindqvist's 2017 minivan that says only: "Engine surges at idle, worse when warm. No warning lights. Started after we had a new battery put in at another shop." There is no code to look up and nothing broken to point at. "This is the course where you stop being a parts fitter and become a diagnostician," Marty tells her. "Driveability means how the engine behaves while someone drives: starts, idles, accelerates, cruises and stops. Most driveability jobs are won or lost before you pick up a tool, by how you think."

This course builds on everything Kiran learned about engines, electrical systems, fuel, ignition and emissions in earlier courses, and adds the tools and habits of an engine performance technician: a written strategy, service information and known problems, scan tool data and graphs, the lab scope and its probes, pressure transducers, intermittent faults and module programming. This first lesson sets out the strategy that every other lesson uses. It ends with the minivan's surge traced to its cause, and with a plan that the course finishes in Lesson 11.

Why driveability needs a strategy

A modern engine is controlled by dozens of sensors, actuators and software routines that all influence each other. A single fault can produce many symptoms, and one symptom can come from many faults. A surge at idle, for example, might be caused by a vacuum leak, a dirty throttle body, a sticking purge valve, a weak ignition coil, a skewed coolant temperature sensor, a fuel pressure problem, a software fault or a module that has lost what it learned. A technician who guesses will replace parts in order of how often they fail, and the customer pays for every wrong guess. A technician with a strategy narrows the possibilities with cheap, fast checks first and proves the cause before anything is replaced.

Ridgeline sells diagnosis as a separate line on the repair order, at a fixed first hour with the customer's approval before more time is spent. Bev Ostrowski, the owner, explains why she insists on it: "If we give diagnosis away, we are tempted to rush it and sell parts instead. If we charge for it honestly and do it well, the repair is right the first time and the customer comes back." Simone Tremblay, the service advisor, writes the approval and the customer's exact words on the order, because the exact words are the first piece of evidence.

The eight steps

Marty's strategy has eight steps, printed on a laminated card above every bench at Ridgeline. They are not original to him; most training organizations teach a version of the same sequence. What matters is that they are followed in order and that each step is written down.

• Verify the complaint. Experience the symptom yourself, under the conditions the customer describes, and decide whether it is a fault or normal operation.
• Gather information. Interview the customer, read the vehicle's history, and check service information, technical service bulletins and recalls.
• Check the basics. Look, listen and smell; check fluid levels, battery state, connectors, hoses and anything recently worked on.
• Scan the vehicle. Read codes in every module, freeze frame data, readiness status and the data that relates to the symptom.
• Form a theory and plan tests. List the possible causes, rank them, and decide which test would separate them fastest.
• Test and isolate. Run the tests, compare results with known-good values, and narrow down to one cause that explains every symptom.
• Repair. Fix the cause, not just the part that showed the symptom, and fix anything that caused the part to fail.
• Verify the repair. Repeat the conditions that caused the complaint, check data and codes again, and document the complaint, cause and correction.

Two loops in the chart matter as much as the steps. If a test result does not support the theory, the technician goes back and forms a new one instead of forcing the result to fit. If the verification shows the symptom is still there, the job is not finished, no matter how many parts were replaced. Marty calls these the honesty loops.

Step 1: verify the complaint

Verification is often skipped because the customer has already described the problem. But a description is not a measurement. Customers use words like "hesitate", "stumble", "surge", "miss" and "buck" to mean different things, and they often describe a symptom that is normal for the vehicle, such as an idle speed that rises when the air conditioning compressor engages or a stop-start system shutting the engine off at a light. Kiran has to feel the symptom herself and, if possible, record data while it happens.

The road test is planned. Kiran checks the repair order for the conditions: engine warm, idling, after a drive. She drives the minivan for twenty minutes with a scan tool recording, then lets it idle in park and in drive, with and without the air conditioning and the headlamps on. After the engine reaches full temperature, the idle speed starts to rise and fall in a slow, regular rhythm, from about 600 to about 900 rpm, roughly every four seconds. She notes it on the order in plain words: "Verified: warm idle hunts 600 to 900 rpm, period about 4 s, in park and drive, no codes."

Some symptoms cannot be verified on the first visit. Lesson 10 deals with intermittent faults. For those, the strategy is the same, but verification may mean leaving a data recorder in the vehicle, asking the customer to note conditions, or reproducing the conditions in the bay with heat, cold, moisture or vibration.

Step 2: gather information

Information comes from three places: the customer, the vehicle's history and the manufacturer. A good interview asks when the symptom happens, how often, whether it is getting worse, and what changed before it started. Kiran calls Anna Lindqvist, who adds a detail that was not on the order: the surge started the day the battery was replaced, about a month ago, at a parts store that installed it in their parking lot. Ridgeline's records show the minivan's timing chain was replaced here two years ago and its injectors and EVAP hose more recently, with no driveability complaints since.

The manufacturer's information comes from service information and technical service bulletins, which Lesson 2 covers in detail. Kiran searches by the vehicle identification number for the symptom, the engine and the model year. She finds a bulletin that describes exactly this symptom: an idle that hunts after the battery has been disconnected, because the engine control module has lost its learned idle airflow values and the original software relearns them too slowly. The bulletin calls for an idle relearn procedure with a scan tool and, if the hunt returns, a software update for the engine control module.

A bulletin is a strong lead, not a diagnosis. It tells Kiran what the manufacturer has seen on many vehicles, but her minivan could have a different fault that happens to produce the same symptom. She writes the bulletin number on the order and keeps going.

Step 3: check the basics

Basic checks are fast and catch a surprising share of faults. For a driveability complaint, Kiran's list is: battery voltage and connections, engine oil level and condition, coolant level, the air filter and intake duct, visible vacuum hoses, the throttle body, recent repairs, aftermarket accessories and anything loose, wet, chafed or corroded. The battery is new and reads 12.6 volts at rest and 14.2 volts running. The intake duct is fitted correctly. But when she looks at the battery, she sees that the parts store did not refit the plastic hold-down; the battery shifts when she pushes it. That is not the cause of the surge, but it goes on the order as a safety item.

Basic checks also include listening. With the engine idling and hunting, Kiran listens around the intake with a length of hose for the hiss of a vacuum leak and hears none. She wipes the throttle bore with a clean rag: lightly coated, normal for the mileage. Nothing obvious explains the symptom.

Step 4: scan the vehicle

A full scan reads every module, not just the engine controller, because a fault in another module, such as a transmission, brake or body module, can affect how the engine runs. The minivan has no codes in any module and no pending codes. Freeze frame data is empty because no code has set. Readiness monitors are all complete, which means the vehicle has driven enough since the battery change for the monitors to run.

The data stream is where Kiran finds something. While the idle hunts, the commanded throttle opening swings in time with the engine speed, from about 2.0 to 4.5 percent, while the idle airflow learned value, a parameter the bulletin mentions, reads zero, its default. The short-term fuel trim moves a few percent with each swing, which is expected when the airflow changes, and the long-term trims are close to zero. Spark timing swings too, as the module uses it to catch the falling speed. The engine control module is chasing its own target: it opens the throttle too far, the speed overshoots, it closes the throttle too far, the speed undershoots, and the cycle repeats.

Step 5: form a theory and plan tests

Marty asks Kiran to write her list of possible causes and rank them before testing anything. She uses a simple table: each possible cause, the symptoms it would explain, the symptoms it would not explain, how likely it is, and how quick it is to test. Writing it down prevents the most common mistake in diagnosis, which is to fall in love with the first idea.

# Rank possible causes: fit with the evidence, then likelihood, then time to test
evidence = {"hunts only warm": True, "started after battery change": True, "no codes": True,
            "fuel trims near zero": True, "learned idle value at default": True}
causes = [
    # name, which evidence items it explains, likelihood 1-5, minutes to test
    ("lost idle learning (bulletin)", ["hunts only warm", "started after battery change", "no codes", "fuel trims near zero", "learned idle value at default"], 4, 15),
    ("vacuum leak", ["hunts only warm", "no codes"], 3, 20),
    ("dirty throttle body", ["hunts only warm", "no codes", "fuel trims near zero"], 3, 25),
    ("sticking purge valve", ["hunts only warm", "no codes"], 2, 15),
    ("skewed coolant sensor", ["hunts only warm", "no codes"], 2, 10),
]
rows = []
for name, explains, likely, minutes in causes:
    fit = sum(1 for e in explains if evidence.get(e)) / len(evidence)
    score = fit * 10 + likely - minutes / 20
    rows.append((score, name, fit, likely, minutes))
for score, name, fit, likely, minutes in sorted(rows, reverse=True):
    print(f"{name:<32} explains {fit:4.0%} of the evidence, likelihood {likely}, test {minutes:2} min, score {score:4.1f}")

lost idle learning (bulletin)    explains 100% of the evidence, likelihood 4, test 15 min, score 13.2
dirty throttle body              explains  60% of the evidence, likelihood 3, test 25 min, score  7.8
vacuum leak                      explains  40% of the evidence, likelihood 3, test 20 min, score  6.0
skewed coolant sensor            explains  40% of the evidence, likelihood 2, test 10 min, score  5.5
sticking purge valve             explains  40% of the evidence, likelihood 2, test 15 min, score  5.2

The table puts the lost idle learning first, because it is the only cause that explains every piece of evidence, including the timing and the default learned value. A vacuum leak would usually raise the long-term fuel trims; a dirty throttle body would usually leave a learned value well away from its default as the module compensates; a skewed coolant sensor would show a temperature that disagreed with reality. The theory is only a theory until a test supports it, so Kiran plans two quick tests that would prove it wrong if it is wrong: compare the coolant temperature reading with an infrared thermometer at the thermostat housing, and briefly pinch the purge line to see whether the hunt changes.

Look at how the plan is written. Each test has an expected result if the theory is right and a different result if it is wrong. A test that cannot change her mind is not worth doing. Marty calls this "testing to prove yourself wrong", and it is the habit that separates diagnosis from guessing.

Step 6: test and isolate

The scan tool shows a coolant temperature of 92 °C (198 °F); the infrared thermometer reads 90 °C (194 °F) at the thermostat housing, close enough for a surface reading. Pinching the purge hose changes nothing; the purge valve is commanded off at idle anyway. Neither test contradicts the theory, so Kiran performs the idle relearn from the bulletin: engine warm, all accessories off, transmission in park, scan tool command to reset the learned values, then a timed idle. After the procedure the learned idle value reads a small positive number instead of zero, and the idle settles at 700 rpm.

A good result after a procedure is evidence, not proof. If the cause was something else, the hunt could return. Kiran drives the minivan again, through the same twenty-minute route, and the idle stays steady through two hot restarts. She leaves the minivan overnight and checks again cold in the morning. Steady.

Steps 7 and 8: repair and verify

In this case the repair was a procedure, not a part, and the bulletin warns that the relearn may not last on vehicles with the original software. Kiran checks the engine control module's software calibration number against the bulletin. It is one of the affected versions. The permanent fix is a software update, which Ridgeline can perform but which needs a programming setup and a subscription to the manufacturer's service site. Bev approves it with the Lindqvists for their next visit, in Lesson 11, where Kiran learns how to program modules safely. Today's repair order records the relearn, the battery hold-down and the plan.

Verification ends with documentation. A repair order that says only "performed idle relearn" tells the next technician nothing. Kiran writes three short paragraphs that Marty calls the three Cs: the complaint in the customer's words and as she verified it, the cause and the evidence that proved it, and the correction with the readings afterward.

Diagnostic time and the cost of guessing

Kiran asks Marty whether all this writing slows her down. He answers with arithmetic. A skilled technician who follows a strategy might spend an hour and a half on a job like this one. A technician who guesses might replace a throttle body, a coolant sensor and a purge valve before trying the relearn, spending less time per guess but far more parts and labour in total, and the vehicle comes back. The following code compares two approaches with illustrative numbers.

# Total cost of a strategy versus guessing, with illustrative prices
rate = 165.0          # shop labour rate per hour
strategy = {"diagnosis hours": 1.5, "parts": 0.0, "comebacks": 0}
guesses = [("throttle body", 1.0, 410.0), ("coolant sensor", 0.6, 65.0), ("purge valve", 0.8, 120.0), ("relearn at last", 0.4, 0.0)]
guess_hours = sum(h for _, h, _ in guesses)
guess_parts = sum(p for _, _, p in guesses)
s_total = strategy["diagnosis hours"] * rate + strategy["parts"]
g_total = guess_hours * rate + guess_parts
print(f"strategy: {strategy['diagnosis hours']} h, total {s_total:,.2f} CAD")
print(f"guessing: {guess_hours:.1f} h and {guess_parts:,.2f} CAD of parts, total {g_total:,.2f} CAD")
print(f"guessing costs {g_total - s_total:,.2f} CAD more, and three good parts were thrown away")

strategy: 1.5 h, total 247.50 CAD
guessing: 2.8 h and 595.00 CAD of parts, total 1,057.00 CAD
guessing costs 809.50 CAD more, and three good parts were thrown away

There is another cost that the code does not show. When parts are replaced without a diagnosis, some of them are not covered by warranty if they are returned, the customer loses confidence, and the real cause is still there. Bev's rule is that no part is ordered for a driveability complaint until the technician can say, in one sentence, what test proved that part was the cause.

Thinking habits of a good diagnostician

Marty lists the habits he looks for in the apprentices he trains. The first is knowing what normal looks like. A technician who has looked at many good fuel trims, good waveforms and good pressures recognizes a bad one immediately; one who has not cannot tell. Ridgeline keeps a binder, and now a shared folder, of known-good data and waveforms from vehicles the shop sees often, and every apprentice adds to it.

The second habit is respecting the evidence over the theory. If the data does not fit the idea, the idea is wrong. The third is changing one thing at a time, so that each change shows its effect. The fourth is finding the root cause: a blown fuse, a burnt connector or a failed coil is often the result of something else, and replacing it without finding why it failed guarantees a comeback. The fifth is asking for help early. A second technician's eyes, a call to a technical hotline or a question on a professional forum often saves hours, and Ridgeline's technicians are encouraged to say "I don't know yet" rather than guess.

The last habit is documentation as you go. Kiran keeps a running log in the shop's repair order system: each test, the expected result, the actual result and what it meant. When a job spans several days, or when another technician takes over, the log is the only reliable memory of what was done.