Information Overload

Information is a good thing. It can be more effective than any tool in the light-duty technician's toolbox. But when a technician has too much information, it can become a bad thing, leading to confusion, hasty decisions and wasted time.

OBD (on-board diagnostics) II is a case in point, according to Mike Fahrion, director of engineering for Ottowa, IL-based B&B Electronics, maker of AutoTap diagnostic tools. Fahrion sees more and more OBD II vehicles finding their way into fleets these days, and technicians are not always trained to make sense of the onslaught of diagnostic information that is available.

"With all the outstanding diesel pickup trucks out there today on heavy duty chassis that have migrated to OBD II, with the PowerStroke and Duramax engines, and the Sprinter Vans that are under the OBD II flag, they're finding their way into all kinds of delivery fleets," he says. "Suddenly the maintenance folks are dealing with a lot more light-duty, OBD II stuff than they used to."

Jorge Menchu, president of Fresno, CA-based Automotive Electronics Services, Inc., agrees: "The bottom line," he says, "is that there's a tremendous amount of information, and it's absolutely overwhelming."

FLYING BLIND?

At first glance, it doesn't make sense that a system that has been used with great success to make diagnostics simpler could actually be creating more complexity. But a lot depends on the diagnostic tool being used, the amount of technical documentation available, and the experience of the technician.

"In theory, (OBD II) gives you a code and a short description, and if you have the right technical data you can go back and that'll launch you into a troubleshooting tree in your documentation," says Fahrion. "Maybe a lot of these guys don't have that to start with if they've got a real mixed fleet and they've got five of these and two of those and twelve of these. They're probably not going to be going off and getting training from GM or (any other OEM), so I don't know if they have access to all the data. They might be flying blind.

"Usually the first reaction you see, whether it's a do-it-yourselfer or a pro, is parts swapping," he says. "They don't know what the heck to do, but they know they have to do something. So much time and money gets spent that way."

FOUR DIGITS

One reason OBD II seems to get more complicated is that it is infinitely expandable. But so far, at least, every code follows a basic pattern.

"Usually you start out with a 'P,' so that tells you it's a powertrain code," Fahrion explains. "It could be powertrain, it could be body or chassis, or in an unusual case it could be 'U' for network. Then you've got your four digits after that. In theory, when you put all that together, you've got three one-line code descriptions that should give you some pretty good pointers towards what's going on.

"The first digit is the important one: if it's a zero, it means it's a generic code, and if it's not a zero that means it's a manufacturer's enhanced, or proprietary, code," he says. A generic 'P-zero' code, for example, points to an emissions-related problem, indicating that the engine is running in a way that could potentially affect emissions.

"That (generic code) can be a sign of trouble, but not necessarily," Fahrion explains. "Usually, the proprietary codes are there to supplement the generic codes. So, for example, if you have a misfire going on in a General Motors vehicle, you'll get a P code, maybe a P0300, which means you have a general misfire problem. But, when you go read the scans with the appropriate scan tool, it might also give you a second code that might pin it down to the exact cylinder. It might read 1304, for example, and that would mean that it's cylinder four that's misfiring. So the enhanced code is designed to give you more granularity than what the EPA decided the generic codes would be."

To Fahrion, that's the real power of OBD II information. "If you can diagnose a misfire—which is usually a sporadic event that happens under certain load conditions and other variables—this gives the technician a lot of guidance," he says. "It says, 'Look, this is the cylinder,' and from there all you have to do is decide whether it's a mechanical problem, like a loss of compression, or a fuel problem or a spark problem."

Fahrion explains that the third digit points the technician to the circuit or system of the vehicle that's involved. A '1' or '2' both point to fuel and air-metering-related problems. A '3' points to an ignition system problem, '4' points to auxiliary emissions, '5' to speed and idle control, '6' to computer output, and '7' and '8' to the transmission. The last two digits refer to the specific fault, with a total 99 combinations. "Once you boil it down to those basics," he says, "it takes a lot of the mystery out of it."

Or at least it should. Unfortunately, OBD II information overload remains a problem for some technicians.

OVERWHELMED

"It's a grand search for information, and putting pieces together," says Menchu. "You get a little data here, a little data there. You use the scan tool to get a feel for the system and make a conclusion, and then you try to confirm it and make a decision on it, that's absolutely overwhelming."

Menchu, who pioneered the automotive lab scope and now conducts diagnostics seminars around the country, feels that technicians can always work smarter, no matter what diagnostic tool they use: "You can have all the information in the world, but if you don't have a good personal foundation, it's not going to do you any good."

"If you look at this from the technician's perspective, what's key in the utilization of that OBD II information is to really understand what the intent of that information is," echoes Diego Borrega, director of product engineering for Networkcar. "All those OBD codes come as a function of these tests being run."

TECHNICIAN TRAP

"One of the things I see as a trap is, there are a few problems that technicians immediately associate with a certain code," says Borrega. "Say you have a 1999 Chevy pickup with an eight-cylinder engine. The technician knows from experience that every time he sees a P0004 code on that truck, it means this particular sensor needs to be replaced. Now, that's a connection they've made in their heads, but that's not necessarily the significance of that code. The significance of that code is that a certain test has been run, and a certain value is out of specification. So, from a technician's perspective, the information is most valuable when they understand how that information came to be.

"So, one of the pitfalls is to think that, just because you recognize the code, you know exactly what's wrong with the vehicle," he says. "You still have to understand the diagnostic trees, and understand how those codes came to be and the fact that there was a particular test run behind that code. That's why it would be a mistake to look at the most common fault codes and decide that it means this particular component is failing most often. All of these data are meant to help, but you need to understand the context of that code in order to be able to extract useful information from it.

"In general, you can't really tell what's broken by one code," he stresses. "One code tells you that a certain parameter is out of spec'. For example, a catalyst code says that one of the monitors inside the vehicle to test the catalytic system has found a certain voltage out of spec'. Does that mean the sensor's broken? It could just mean that the sensor that's detecting that voltage is broken. It could mean there's a broken wire. Or it could mean that the vehicle is truly polluting."

PC-BASED

AutoTap, the diagnostic tool offered by Fahrion's company, is popular among do-it-yourselfers, but it also appeals to technicians. Because it's a PC-based tool, Fahrion explains, it can manage information in a way that helps the technician be more productive.

"A hand-held scanner is going to look like a volt-meter, and it's going to have a one to four-line display on it, and a handful of buttons," he says. "You point and shoot, plug it in and it tells you what the code is. The more money you spend on the scanner, the more buttons you can manipulate to get you real-time data."

A PC-based scan tool, according to Fahrion, allows the technician to take advantage of the bigger screen and the user interface of the PC. "Say, if you're looking at an O2 sensor—a real common problem on any vehicle would be code that tells you the vehicle is either running too rich or too lean—the very first thing you want to do is decide whether it's a failed oxygen sensor that's giving you a bad message," he says. "All an oxygen sensor does is flip back and forth between a one and a zero, and it has to do that pretty quickly. If you try to look at that with a hand-held tool, you can't make anything of it, because there's no fixed voltage value you can look at. If you can graph it on your PC—you just click on a parameter and tell it to graph it—a sine wave comes up on your screen and you can see whether that's a good sensor. So that graphing capability is something you get on a PC-based tool.

"The other thing is the ability to embed a lot more help into the product," he explains. "We can put pages of help data right into the basic operations. How does this sensor work? What does this trouble code mean? Well, here's a paragraph instead of the line of text that you'd get on a hand-held.

"That's the whole direction we're going with our next generation AutoTap, which addresses some of what I believe your fleet guy is saying: they're overwhelmed with data," he says. "If they had a scan tool that walked them through a test, we can address that feeling of hopelessness, that you're overwhelmed with information and you don't know what to do with it."

FLOW OF INFORMATION

In his seminars, Menchu takes a systems approach. It's not enough to have a scan tool that can understand what the vehicle is reporting; the technician also needs to consider the variety of computers in the vehicle, and how those computers communicate and report information over the data bus.

"A common question I hear involves a car with four doors," Menchu says. "Each door has a computer in it that's connected to the bus. If one computer on one door goes out, it kills the signal, and it kills the bus. So you have to go check each one individually; you have to disconnect each one until the bus comes back up, and then you know which one's bad."

To Menchu, this scenario represents the ultimate problem in diagnostics, and it also points to the ultimate key: flow of information.

"You have to find out what's involved, who the players are, what are the conditions, and what's the flow of information?" he explains. "So you have to check all the players, see that they're operating under the right conditions, and trace the flow of information and find out where it's not correct. And then, on top of that, you need to have the skills and the tools to monitor it all and put it all together.

"Engineers often use a functional diagram to show a complex system. When you're diagnosing something and trying to figure out this complex problem, if you draw out your own functional diagram, based on your understanding, you can immediately tell where you are," Menchu says. "You're starting to visualize the flow of information and who the players are."

PUTTING IT ALL TOGETHER

According to Menchu, the confusion that some technicians might experience with OBD II codes is not the real issue.

"The real problem is the complexity," he insists. "It's massive amounts of complexity, and there's only one way to deal with it: that's to have lots of experience, and lots of information, and to have good tools that are meant for the job. If you have the wrong scan tool, there are certain things you can't do, and certain cars you can't fix.

"So the real question is, how do we teach technicians to deal with the complexity?" he says.

Menchu's recommendation to fleet maintenance managers is to get the technicians talking with the service manager, so they can learn from each others' perpectives. Together, he suggests, they must:

#1: Learn to identify the fundamental problems and issues;

#2: Once a week, get together with everybody in the shop and talk about it, 'Here's the problem I had, here's the information I gathered, here's how I found the answer,' whether it was going to the IETN, or calling up another technician, or they just stumbled onto it—and then analyze things together as a group.

"One of the things I see in the industry is that we get so caught up in the immediate need that we forget the big picture," says Menchu. "For a technican to be successful right now, he needs to fix the car. But you have to step back and look at the big picture of your career. You're always going to have that question mark of finding information and being able to absorb it. But at some point, you have to start focusing on yourself."

That's where experience comes in.

EXPERIENCE COUNTS

"The truly advanced diagnostic technician doesn't need to be told what to do with the information, but those guys are so rare," says B&B's Fahrion. "You're very lucky if you have one good one per shop.

"Ideally in the shop you have one guy who's really your diagnostics guy, and everyone else will turn the wrenches and replace the parts that that guy tells them to," he says. "If you want to maximize that guy's time, before the vehicle ever reached him, some entry-level tech could go through with a guided scan tool, and get his codes all printed out, and he's gone through any sensor tests related to those codes, which should only take a minute or two, and now we know, there are ten primary OBD II sensors on this vehicle, and we've verified that every one of them is good, and we've done that with virtually no skill sets. So, that's how you make your skilled guy a lot more productive."

OBD III?

What about productivity in the future?

While some experts consider OBD III a "myth" that's never going to happen, Borrega claims that Networkcar's wireless system is "already OBD III."

The company has a pilot program with the California Air Resources Board (CARB) that is modeled after OBD III. "A logical extension of OBD is to ask, 'Why do I have to physically be there and plug the scan tool in? Why can't I receive the information from the vehicle over the air?'" he reasons. "After all, most new vehicles already have a modem in them, connected to the diagnostic bus."

Whether that leads to greater productivity or more overload, only time will tell. The real trick, both now and in the future, is to understand where the information came from, what it means, and how it can make your technicians more effective.

Loading