Are you basing your diagnostic conclusions on statistics or data?

Sept. 29, 2017
I recently heard two men whom I respect very much jokingly refer to technicians who were using a new diagnostic method I’d never heard of before – Statistical Diagnostics. The term references what seems to be an increasingly common trend, and a great topic for this month’s Tech Corner!

Recently, I took part in a Roundtable discussion covering a variety of industry issues. During that discussion, I heard two men whom I respect very much jokingly refer to technicians who were using a new diagnostic method I’d never heard of before – Statistical Diagnostics. The term references what seems to be an increasingly common trend, and a great topic for this month’s Tech Corner!

Multiplied Experience

It was a common practice in nearly every shop I’ve worked in to lean on your fellow techs for opinions and advice when faced with a repair challenge that was getting the best of you. With the birth of the Internet, the ability to interact with technicians from around the world was also born – iATN (the International Automotive Technicians Network) is example.

(Image courtesy of Mitchell 1) Recently I had to solve a P2111 intermittent on my father’s Ford Escape. The peak failure of the throttle body at 60,000 miles reported in SureTrack was a great piece of information that helped me find the problem quickly. But I still verified with testing that the part had died.

As an early subscriber to iATN, there were a few features that I found extremely helpful. One was the variety of forums I could access and learn from. There were, and are, some talented technicians there that don’t mind helping those who truly want to grow. Another was the Tech Help feature that allowed me to share the steps I’d taken in a particular “hard case” with others via email. This was exactly like asking the tech in the next bay for his help, only the techs that answered my requests were scattered around the country. Invariably, I learned from the advice and help I received and eventually triumphed over the problem I originally sought help on. Better yet, I learned new skill sets that I could apply to the next one I ran into.

Another valued feature is the Fix database hosted in iATN. This was the accumulated results of every Tech Help message ever sent or answered. Perhaps the problem I was facing had already been faced, and beaten, by another tech? If so, this was the first place to go see. As these data files grew (currently the Fix database alone has over 250,000 records and nearly 2 million related replies to search), pattern failures began to appear. These were the “silver bullets” many of us began to rely on in an effort to save diagnostic time. Time we were often not getting paid for.

And there, my friends, is where, I think, the seeds of Statistical Diagnostics were planted – a growing online log of repair histories by year, make and model coupled with an uncertain method for being paid to accurately diagnose the problem.

Today’s Reality?

How do you get paid for your diagnostic time? How does your shop establish its diagnostic fees? That’s been a big issue for many for a long time. When I was still full time in the bay, I would typically be credited no more than an hour for a “routine” diagnosis. Anything over that was on me unless I could successfully argue that the problem was not “routine”.

And then there were the many times I spent more time than allowed figuring out a problem, only to finally find it and think to myself that I should have found it much faster. It was a fault in my process that added to the clock time spent. Is it fair to charge the customer for that extra time?

But now we have a number of databases, some like iATN and Identifix, and others like Mitchell 1’s SureTrack, that promise to reduce our diagnostic times to a more manageable level. You’ve heard many of our contributors, including yours truly, recommending that you do a search of related issues using these resources.

And you’ve also heard us say that you should test and verify that the problem you are diagnosing meets the criteria for the “silver bullets” you may have found checking those resources. And that’s where the current trend starts drifting off to the left.

We used to call it “shotgunning” parts at a problem. Another common term was firing the “parts cannon” at the car to see what eventually fixed it. But there is one important difference that distinguishes the Statistical Diagnostic method from “shotgunning” – the user relies on the statistical evidence at hand to decide what part gets replaced first. If there are 279 cases of a failed ignition coil, for example, as the most reported repair for a misfire and there are only 126 cases of a failed injector being the issue, the accomplished Statistical Diagnostician will order the coil.

But without testing either component to verify the problem first.

Professional?

Is this a professional way to fix a car? Arguably, it’s an efficient way. After all, if the fix works then the only time spent “diagnosing” was the time it took to look up the code or the symptom. You still flag the hour, right?

If the statistical fix doesn’t fix the issue, then you’re only out a few minutes plus the time installing the part and you can move on to the second most likely problem based on the stats. Or, oh my God, you could actually decide to test something to see what the real cause is!

In my mind, the use of the information as a resource to my diagnostic process is a legitimate one. I have, and do, use the statistical averages to help me make that final decision on whether or not to “pull the trigger” on an expensive part or repair. But to rely on it alone – especially if you are one of those few shops that lets the customer pay for your mistakes – then it’s not only unprofessional, it’s unethical, maybe even a tad illegal.

A TPMS Tale

Next on the table for this month is a story about a TPMS malfunction that no Statistical Diagnostics” would have solved.

My wife’s pride and joy. Her pristine care of her car also makes her a demanding customer. Guess I’m lucky to be her mechanic!

My wife owns a 2014 Scion tC that she is lovingly protective of. It looks as good today as the day it left the showroom and she has added some TRD touches to it that always gets heads turning wherever she goes. Her protective attitude bleeds over to her attitude towards her mechanic – me – whenever any little thing goes awry.

Today, it was the return of the TPMS warning light. No big deal, right? The steady light had always pointed the finger at a punctured tire and I suspected nothing less this time. I used my Bartec USA tool to engage all four sensors to check the reported tire pressures and found them all to be well above the threshold that would turn on the light. Typically, TPMS warning indicators won’t illuminate unless the tire has lost roughly 20% of its cold fill.

I checked the sensors’ reported readings with my TPMS tool. Cold spec for the car is 33 front/30 rear. These numbers are a little off but not enough to turn on the light, right?
ID1 and 2 are the front tires, and ID3 is a rear. Notice the difference in the Low Threshold pressure PIDS; 26. 1 and 26. 82 for the front versus 28. 64 for the rear. Why would the rear, with a lower cold pressure spec., have a higher threshold?

Okay, the tires were still a bit warm from her short drive home. Let’s get it in the air and inspect the tires more closely. I cleaned and marked a starting point on each and slowly rotated them by hand, looking for any signs of foreign objects that shouldn’t be there. Nothing!

If the tires aren’t low, then it must be a system problem. Let’s check for codes. Nothing there either.

I let the car sit for a few hours and went back to check the pressures again. No real difference found, but the two front tires were a little low from the 33 psi specified on the sticker. I aired them all up, verified the pressures with both a digital tire gauge and the TPMS tool, and told my wife I’d do a little digging.

The Next Day

I started my research with a general search on Mitchell 1. Statistically, there was no problem that came up that even came close to my problem so I guess the Statistical Diagnostic method wasn’t going to be much help on this one!

On to research system operation. Like many systems, the TPMS sensors transmit their information to the TPMS receiver, which then sends the information to the TPMS control module. The TPMS module will send the command to the Instrument Cluster module to turn the TPMS light on (when a tire is low) or to flash the light (when a system error is detected).

I could see by the scan data that all sensors were reading the same as I had seen on the TPMS tool. There was, however, no PID for the command to turn the TPMS warning indicator on. I could, though, turn the light on or off at will using the bidirectional controls I had for the cluster. What did that tell me so far?

First, I didn’t suspect data corruption or misreporting. No, the TPMS ECU was seeing the truth. The fact that I could control the light at the cluster told me that the cluster wasn’t the culprit either. For some reason, the TPMS ECU was commanding the light on when it shouldn’t be.

My first thought was that the sensor data on the scan tool wasn’t matching up with the TPMS tool. This verified that the wheels were where I thought they were.
Take a look at the difference in Low Threshold values after the relearn. Now that makes more sense!

Taking a closer look at the data, I noticed the PIDS for each wheel called “Initial Threshold of Low Pressure”. That had to be the number the ECU was looking for to command the light on, and while none of the measures pressures were below those numbers, I did notice that the PIDS associated with ID1 and ID2 were lower than the ones for ID3 and ID4. Then it dawned on me. Where the sensors on the scan tool representing the same locations as they were on the TPMS tool?

Comparing IDs from the scan tool and the TPMS tool, I could confirm that the current IDs were, indeed, the same. ID 1 and 2 were the two front wheels, and ID 3 and 4 were the two rear wheels. Cold tire pressures respectively are 33 psi and 30 psi. See where I’m going with this?

When the tires are rotated, the system needs to be reinitialized. That is, relearned as to what the right pressure for that new position is. As you can see, the lower thresholds for ID1 and 2 indicate that they were originally calibrated for the rear while ID3 and 4 were for the front. The failure limits were less than 10% of the cold tire pressure spec!

I looked up the relearn procedure and rechecked. Now the low pressure thresholds looked more reasonable – and the light was off.

And to think I almost pulled the trigger on the TPMS ECU??

Sponsored Recommendations

Best Body Shop and the 360-Degree-Concept

Spanesi ‘360-Degree-Concept’ Enables Kansas Body Shop to Complete High-Quality Repairs

ADAS Applications: What They Are & What They Do

Learn how ADAS utilizes sensors such as radar, sonar, lidar and cameras to perceive the world around the vehicle, and either provide critical information to the driver or take...

Banking on Bigger Profits with a Heavy-Duty Truck Paint Booth

The addition of a heavy-duty paint booth for oversized trucks & vehicles can open the door to new or expanded service opportunities.

Boosting Your Shop's Bottom Line with an Extended Height Paint Booths

Discover how the investment in an extended-height paint booth is a game-changer for most collision shops with this Free Guide.