| |
|
The Age of Intelligent Machines: An Expert System for Automotive Diagnosis
Jeff Pepper is product marketing manager of the diagnostics division of the Carnegie Group. His current research interests include all aspects of knowledge-base design, construction, validation, and maintenance. He has published several articles on building expert systems and integrating them into service organizations. He has also taught computer programming at Carnegie Mellon University.
From Ray Kurzweil's revolutionary book The Age of Intelligent Machines, published in 1990.
Big changes are coming to the world of automobile repair. In the Ford dealership of the not too distant future, mechanics will be tracking down and fixing problems in your car with the help of a powerful AI diagnostic tool called SBDS, under development by a joint project team at Ford Motor Company, the Carnegie Group, and Hewlett Packard. SBDS, the Service Bay Diagnostic System, will revolutionize the way cars are fixed. When it is completed in the next year or two, SBDS's knowledge base will contain the expertise of Ford's top diagnosticians, and it will make their diagnostic skills available to mechanics in every Ford dealership in North America. This "expert in a box" will guide a human technician through the entire service process, from the initial customer interview at the service desk to the diagnosis and repair of the car in the garage.
Imagine how this expert system will affect the way your car is serviced. When you first walk up to the service desk, a service writer interviews you to find out the details of your car's problem. But most of the questions he asks are suggested by SBDS, which is trying to gather important information from you before you leave the dealership. The questions are tailored to your particular situation and depend on your car, your complaints, your car's repair history, and Ford's knowledge about possible problems with cars similar to yours.
After the interview SBDS prints a repair order, and your car is taken to the shop. There a technician begins his diagnosis. In early versions of the system, the technician will use a computer terminal and a touch screen to communicate with the computer. But in one future scenario we are working on, there is no terminal at all. Instead, the technician dons a headset with a built-in microphone and begins the diagnosis by simply saying, "Let's go" to the expert system. In this vision of the future, SBDS requests information and provides instructions by generating synthesized speech and sending it into the technician's headset. This speech is provided in the technician's preferred language and at a level of detail appropriate to his education and depth of experience. The technician responds to test requests by saying the result (such as "Pass" or "Twelve volts") into the microphone.
Whenever possible, SBDS avoids asking the technician to perform physical tests. Instead, it goes directly to the car for the information, using a specially designed Portable Vehicle Analyzer connected to the on-board computer that controls much of the operation of Ford cars. Raw data such as voltages and vacuum-pressure readings are processed by the vehicle analyzer and passed back to the expert system to help guide the diagnosis. If the technician does not understand why SBDS asks for a test or makes a certain conclusion, he can respond by asking "Why?" The expert system responds to this request by describing, in ordinary spoken language, the reasoning that led to the test request or conclusion. The technician can ask "How?" to listen to an explanation of how to perform a repair, or say "Show me" to trigger the display of a schematic or animated illustration on a nearby TV monitor.
SBDS does not rigidly control the session. It simply suggests tests and asks questions according to its knowledge of the problem and what it needs in order to proceed with its diagnostic strategy. Yet the technician can override this line of reasoning if he notices something unusual about the car or feels that the program is ignoring a likely cause for the failure. Whenever the technician volunteers new information, SBDS responds immediately. It interrupts its diagnosis, draws whatever conclusions it can from the new information, and refocuses its strategy to take advantage of what it has learned. Thus, the technician can let SBDS control the diagnostic session completely, or he can use it as an expert advisor, depending on his skill level and how he wants to use the system.
SBDS is part of a major effort by Ford Motor Company to introduce artificial intelligence into the design, manufacture, and service of their products. It is the cornerstone of Ford's commitment to bring AI into the automotive world. With an expected installed base of over 5,000 dealerships throughout North America, SBDS may become the largest application of artificial intelligence in the world.
Ford asked the Carnegie Group to help them develop the expert-system component of SBDS, because they recognized that the complexity of today's cars is rapidly exceeding the capability of human mechanics to fix them. Today's technicians are generally unable to tell what is wrong with a car just by listening to it, because a maze of electronics controls virtually every aspect of the performance of a car. The traditional methods for diagnosis, such as listening to the engine, adjusting engine controls and observing response, are rapidly losing their usefulness. Many mechanics, overwhelmed by the electronics of the car, are forced into a swap and test strategy, simply replacing a suspected component and checking afterwards to see if the problem went away. Although there are a few experts who can reliably diagnose failures in today's electronics-laden vehicles, they are a very scarce and expensive resource.
In trying to overcome this expertise bottleneck, our development team at Carnegie used existing techniques for AI-based diagnosis and modified them to deal with the very large, unstructured domain of automobile repair. We soon learned that expert automobile diagnosis is a very complex task. Skilled auto mechanics, we discovered, rely on several different kinds of knowledge about the domain and use several completely different reasoning techniques during the course of a diagnosis. Our task was to design a knowledge-base structure that would be rich enough to hold all the kinds of knowledge that human experts bring to bear on the problem but simple enough that it could be built and maintained by non-AI experts.
All human diagnosticians, whether they work in automotive repair or medicine, have certain characteristics in common. Both groups have an internal mental model of the task domain. This model is a body of knowledge about the parts of the mechanism or organism they are trying to fix and about how those parts fit together. This model is closely tied to two additional knowledge sources: the expert's formal understanding of the laws of the domain (such as electrical theory) and a large loosely structured body of knowledge consisting of common sense and experience gained simply by living in the world. Taken together, these three knowledge sources are very powerful and enable human beings to solve new problems by reasoning them through. This process is called causal reasoning or reasoning from first principles.
We discovered an interesting fact about causal reasoning: experts rarely solve problems this way. They only perform causal reasoning when absolutely necessary, such as when confronted with a new situation. Most of the time experts work from a different representation, a much simpler model derived from the original causal model but much easier to work with. This second model, called a troubleshooting or weak causal model, consists of failures and their relationship to each other. The troubleshooting model retains most of the diagnostic power of the original causal model but does not require such difficult reasoning.
The knowledge base of SBDS is built using a modified troubleshooting model. It was written using a tool kit for expert-system development called Knowledge Craft, and it consists of thousands of chunks of information called schemata. There is one schema for each known way that the vehicle can fail. These modes of failure are connected to each other by predefined relations such as due to and always leads to, which enables a knowledge engineer to represent the fact, for example, that an empty gas tank always leads to a no-start. Taken together, these relationships among failures form a richly interconnected hierarchy ranging from visible, identifiable customer concerns at the highest level down to specific component failures at the lowest level. The treelike structure of the failure-mode network is augmented with large amounts of supporting information that assist the expert system in diagnosis and repair. Each failure module has links to the failures that it can cause, failures that are possible causes for it, and many other kinds of schemata. These include test procedures that can confirm or reject the hypothesis that the failure actually occurred, repair procedures that can fix it if it does occur, documentation that describes how to fix it, and guidelines on how to proceed if the repair fails.
This knowledge-base design is sufficient to describe the common ways in which cars fail. But just like human experts, it needs a way to modify its behavior when confronted with exceptions and unusual conditions. To replicate this important aspect of problem solving, we added the ability to attach exception rules to the failure schemata. These rules modify the knowledge base to handle special conditions. For example, a rule might say that if the car has a very high odometer reading, then there is a higher likelihood that clogged fuel injectors will cause stalling. This rule doesn't actually conclude anything, it simply modifies the knowledge base so that the reasoning strategy can reach a correct conclusion faster in this case.
In the world of automotive diagnosis, knowledge is constantly changing. A technical-service bulletin may be issued from the manufacturer, or mechanics in the field may discover a new kind of problem, a new diagnostic, or a new repair procedure. The traditional way to handle this was to mail technical-service bulletins to dealerships. These bulletins would be posted on bulletin boards and discussed among the technicians. But with SBDS, knowledge engineers at Ford simply insert the new information into the knowledge base. This makes the new information available not just for reference but to actually improve the reasoning strategy. SBDS gets smarter with every new chunk of knowledge.
The actual reasoning about repairs is done by a program called the Diagnostic Interpreter. This interpreter is completely separate from the knowledge base and knows nothing about cars or any other object. Yet it knows a great deal about how to do machine diagnosis. In some ways the interpreter is like a detective who is suddenly asked to fix a broken water heater. He doesn't know anything about water heaters, but knows a great deal about deductive-reasoning techniques. If we give him a manual that describes the water heater, he can apply his reasoning skills to this new domain. In much the same way, an expert system makes a strict separation between "pure" knowledge in the knowledge base and the procedural information in the diagnostic interpreter. This makes it much easier to create and update the knowledge base and makes it
Supplied by Jeff Pepper
A typical knowledge base for Ford's Service Bay Diagnostic System showing failures, the relations among them, and two rules that can modify the knowledge base. Arrows indicate a "due to" relation between two failures.
Courtesy of the Carnegie Group
A typical display from the expert portion of Ford's Service Bay Diagnostic System.
possible to reuse the SBDS diagnostic interpreter for different makes and models of cars by simply replacing appropriate portions of the knowledge base.
The diagnostic interpreter doesn't know anything except how to reason, and it can apply its different reasoning strategies to the contents of any knowledge base. It knows how to reason by process of elimination, how to modify its behavior to make best use of unexpected or volunteered information, and so on. It also knows how to use all the various tricks of the trade contained in the knowledge base, such as recognizing a failure from a certain combination of symptoms. And it knows how to perform backward chaining, or goal-driven reasoning, the inference method that forms the backbone of this and many other expert systems.
After SBDS reaches a conclusion, another difficult task remains: it must make sure that the conclusion is correct and that the recommended repair actually fixes the car. This validation process or repair strategy is much more difficult than it might seem. Many factors complicate the picture: A single customer concern may have several co-occurring causes, so finding one cause doesn't solve the customer's problem. The diagnosis may lead to the conclusion that a part is bad, but that part may not have anything to do with the customer's original problem. The technician might be unable or unwilling to perform the suggested repair, and another must be substituted. There may be a likelihood for certain repairs to cause other things to break, and these other, secondary problems need to be investigated if the repair fails to fix the car. These are problems that human experts intuitively know how to handle. But they must be studied, formalized, and converted into computer software in order for SBDS to solve them. As we built SBDS, we found that the task of verifying a repair is just as difficult as the original diagnosis, and much less understood. The repair-strategy component of SBDS is perhaps the first large-scale attempt to intelligently verify the correctness of computer-assisted diagnosis and repair.
As of this writing, SBDS is undergoing testing in Ford garages, and results have been very encouraging. We know now that the program performs as expected, that it can accurately and efficiently guide a human user to the correct diagnosis of a vehicle fault. But in looking back on what we've done, two questions remain: Did we accurately replicate the expert's mental map when we built the SBDS knowledge base? And is the program intelligent? The answer to the first question is no, and is likely to remain no for expert systems in the near future. We know that a human expert's understanding is rooted in real-world experience. A human understands that an empty gas tank prevents a car from starting, just like our expert system does. But his understanding is based on observations that he makes in terms of his commonsense understanding of how the world works. Our expert system has no substratum of experience in which to root its knowledge. It doesn't know why an empty gas tank prevents a car from starting, it doesn't really know what gas is, or even what a car is. When confronted with situations outside its limited knowledge base, like a car with two gas tanks, it can't be of much help. The best it can do is to recognize the situation as being outside its domain and gracefully admit that it doesn't know what to do.
As to the second question, Raymond Kurzweil has devoted much of this book to pointing out that the question Is it intelligent? is meaningless unless we first clearly define what we mean by intelligence. If we are concerned merely with the ability to perform symbolic reasoning, then of course SBDS is intelligent, because it is extremely adept at manipulating its own knowledge structures. But at a deeper level, the answers become more elusive.
Probably the best contribution I can make to this discussion is to digress a little and take you to the Carnegie Museum of Natural History. We go inside the museum, and we see an exhibit of the evolution of the horse. Over there is a row of horse skeletons ranging from the small doglike creatures of the ice ages to the modern thoroughbred racehorse. The small creature there on the far left doesn't look much like a horse at all. It is Eohippus, the "dawn horse." It was evolution's first experiment with this type of animal, and it was successful enough to survive and provide the seeds of evolution that have led to the magnificent creatures we know as horses today.
Perhaps SBDS and other similar systems are the dawn horses of intelligent machines. Although they are primitive in comparison to their human counterparts, they contain the seeds of intelligence. They are useful enough to ensure that they will spawn future generations, and their descendants will improve and deepen their methods of reasoning, perception, and understanding. Natural selection and strong evolutionary pressures will encourage this growth, one experiment giving way to another, until they evolve into the racehorses of AI, a future generation of truly intelligent machines.
| | Join the discussion about this article on Mind·X!
Photo by Patrick Terry
Jeff Pepper is product marketing manager of the diagnostics division of the Carnegie Group. His current research interests include all aspects of knowledge-base design, construction, validation, and maintenance. He has published several articles on building expert systems and integrating them into service organizations. He has also taught computer programming at Carnegie Mellon University.
| |
