The proliferation of electronically controlled systems in today’s cars and trucks has greatly complicated the task of diagnosing the source of a malfunction. True, most control modules monitor their inputs and outputs for fault conditions and report these as fault codes. The problem is the inability of these modules to distinguish between a fault in a sensor or somewhere in the wiring harness or in the controller itself. Often, the task is left to the technician to troubleshoot the offending connector.
What Does a Technician Need?
It is likely that the source of the poor gas mileage and sluggish performance that prompted you to bring your car in for service was a broken or loose connector on one of the many sensors or actuators that control your car’s engine. To find that connector, a technician must use various on-board and off-board diagnostic tools, test meters, and multiple types of service information.
The first step may be to interrogate the engine’s control module for fault information that will direct him to the circuit in question. Most technicians will be equipped with a serial communications tool that connects to the diagnostic link and allows the retrieval of fault information when troubleshooting.
The fault reports from the on-board diagnostics often indicate the circuit and fault condition. For example, engine coolant sensor—short to ground.
Once a suspect circuit is identified, a logical troubleshooting process begins to isolate the cause of the short circuit. The actual circuit may consist of several feet of wire with multiple connectors located in various accessible and some not-so-accessible places in the car.
The lucky technician will have some kind of diagnostic guidance instructing him to perform certain tests that will help narrow down the possibilities most efficiently. Without this, he will have to rely on his troubleshooting savvy, using wiring diagrams and other service information that may be available.
The tests will involve measuring voltage, current, and resistance; applying stimulus to the circuit; and reading the effect through the control unit’s serial interface. Typically, the technician will need service manuals to locate the various connectors on the vehicle and at least a DMM, test lamp, and serial communications tool to do the job.
Repairing the fault once it has been isolated requires the technician to turn to another set of tools. To find the part needed for the repair, he must search on a microfiche or in an electronic parts catalog. He will need to consult the service manuals again to find the adjustment and replacement procedure and then use the serial communications tool to verify the repair and erase the fault code.
What Comes Into Play?
Delivering accurate and up-to-date service information to the technician is an enormous job. It involves authoring, presenting, and revising large amounts of information, and the typical word processor-based desktop publishing systems are not up to the task. Many companies have adopted a structured information environment based on the Standard Generalized Markup Language (SGML) to address this issue. SGML separates the format of the information from the content, allowing the same information to be presented in multiple formats, such as paper and electronic book. SGML imparts a structure to the information content that supports quick reference to specific areas of information. A structured information environment also improves the efficiency of the authoring process by reusing once-authored information and permitting the authors to focus on creating the content, not format.
SGML also is nonproprietary and supports the open interchange of information. For example, the SAE standard J2008 is based on SGML as the mechanism for the open exchange of emissions-related service information for passenger cars.
SGML’s complex features make it very powerful, but this complexity has limited the development of tools, especially for use on the internet. The HyperText Markup Language (HTML) has found much more acceptance on the web because of its relative simplicity. But HTML’s simplicity makes it unsuitable for complex information environments. The emergence of the Extensible Markup Language (EML) promises a technological solution to this dilemma, deploying large and complex documents via intranets and the internet.
Artificial intelligence technologies are commonly used to provide diagnostic guidance. These technologies can address the huge back-office issues of developing and refining diagnostics to enable technicians to be more efficient.
They also can help determine the front-office issue of what level of technician is needed to troubleshoot today’s cars. All the technologies described here offer ways to put the expert’s knowledge in the hands of any technician.
Case-Based Reasoning
Case-based reasoning (CBR) technology stores, retrieves, and adapts past cases to solve current problems. The user describes the situation, and the CBR software retrieves the case that comes closest to that description from the case base. Then, the user is prompted to collect more information that is used to adapt the solution of the retrieved case to the current problem.
As more problems are solved using CBR, the available case history becomes richer. This allows the case base to improve, resulting in more accurate retrievals.
Fixed decision trees guide the technician down the most efficient path through a troubleshooting procedure. One method captures the logic of a decision tree in an executable program. Each leaf on the decision tree is presented as a screen describing the tests necessary at that point of the procedure.
If, for example, it is necessary to ascertain the voltage level at a certain node in the circuit, the screen will give the instructions and highlight on a drawing where to make the measurement. The value of the measurement then will be interpreted, and the program will branch accordingly through the decision tree.
The decision-tree program is written using a graphical tree-drawing tool (Figure 1). The author builds a tree by selecting functions from a palette and dropping them in the appropriate place in the decision flow. In this way, it is possible for an experienced diagnostic engineer to capture the most efficient diagnostic strategy and communicate it to the technician.
Model-Based Reasoning
An emerging technology in the field of diagnostics is model-based reasoning (MBR). In MBR, the operation of the system to be diagnosed is modeled in software. This model can be used to predict how the system will behave in normal functioning modes and when faults are present.
A reasoning engine can be used with the model to recommend tests that determine which faults are responsible for the faulty condition seen on the system being diagnosed. This technology is finding practical application today as modeling software and computing power become more available. It also is being driven forward by activities like those of the European Union’s Vehicle Model-Based Diagnostics consortium.
What Is Needed to Integrate all This?
It is easy to see how this collection of tools and information sources and the expectations on the technician to use them effectively can quickly get out of hand. The array of technologies used to ease the burden on the technician actually can compound the problem. The technician may be expected to learn two or three different software packages and how to operate several different electronic tools. As a result, a big issue in the automotive service industry today is training—and then retaining—technicians.
Ideally, the technician would have access to diagnostics, parts, and service information through one easy-to-learn-and-use interface. The information would be delivered in a context-sensitive manner, making it even easier to quickly find and use. Measurements and serial communications would be automated or made through the same user interface. The last piece of this puzzle is a delivery tool matched to all aspects of the job: environment, target user, and necessary resources.
Accomplishing this relies on providing a framework that links information of various data types according to an underlying content model. The content model breaks the information down into systems, subsystems, and components of the vehicle. This structure, supported by technologies like SGML, allows the framework to filter and display only the information relevant to the job at hand.
The user interface of this framework is optimized for use in the service environment by using an icon-based, folder-tab presentation. Each folder contains information of different types; for example, parts, service bulletins, and diagnostics. A folder also could have the graphical user interface for an instrument or communications tool. The advantages: Each folder presents only information relevant to the current system selection, and the user sees the same graphical user interface for all data types and tools.
Even a spotless service bay is a rough place for the computers needed to deliver diagnostics and service information. Shock and vibration, caustic fluids, and dust all team up to shorten the life of any PC, keyboard, mouse, or display that enters that domain.
One approach to this problem is a purpose-designed service tool (Figure 2). This tool provides the computing resources needed to benefit from the information and many diagnostic technologies available. A touch screen is used as the pointing device because of its intuitive use and its inherent ruggedness. By avoiding the use of a mouse and a keyboard, the self-contained service tool is packaged in a shock- and chemical-resistant housing. The integration of a measurement subsystem and a serial communications link complete the tool.
Conclusion
The convergence of technologies and standards is making it possible to develop cost-effective service tools that can improve the efficiency of technicians servicing today’s complex equipment and vehicles. Basing the hardware and software components of these tools on industry standards and open technologies allows them to keep pace with developments, protecting both the back-office and front-office investments in these advanced diagnostic solutions.
About the Author
Harry Watt is a business development manager for the Advanced Diagnostic Solutions Group at GenRad with 15 years of experience in the test industry. After receiving a bachelor’s degree in electrical engineering technology from Buffalo State College at the University of New York, Mr. Watt held positions at Schlumberger and Agfa. GenRad, 7 Technology Park Dr., Westford, MA 01886-0033, (978) 589 7716.
Copyright 1999 Nelson Publishing Inc.
May 1999