CSCI 222 Project 2 Documentation

Automotive Starting Diagnostic Application

Written by John Kimpel

Introduction:

Have you ever walked out to your car in the morning to drive into work only to turn the key and determine that your car won’t start? What could be wrong? You may ask yourself; did I leave the lights on? This program is designed to help determine just what may be wrong with you vehicle by asking the user some simple questions, and then recommends a part to replace in order to correct the problem.

This system was designed to trouble shoot problems that are fairly simple, this may be debatable based on a users previous car maintance experience. It also should only diagnose problems that a user could fix in there garage at home, with a few tools that may be purchased at any local store.

This document contains much of the same information in it that the lab write-up for my first project contained. This is due to the fact that I did my second project on the same topic as I did my first project. This resulted in a similar solution space but a different implementation of how to arrive at that solution.

Background and References:

The solutions for this expert system are based wholly on my knowledge and experience of automotive systems. I have spent a considerable amount of time trouble shooting and repairing vehicles.

This program was heavily influenced by my first project for the class, which was the same type of system, but written in clips. The fact that I was now trying to transfer one system into a different type of architecture not only made the second project easier, but also threw a lot of problems in the works for me.

The basic items needed in order to get a vehicle to start are a combustion camber, some sort of mechanism to turn the engine, air and fuel to burn, and something to ignite the air fuel mixture. All of my solutions in this program deal with how these elements come together in order to make a vehicle start. As stated earlier I mainly deal with items that are easily repaired in a home garage. This resulted in many problems lumping under taking your car to a mechanic. Below is an introduction to the basic systems that I have addressed in my program.

Battery: This is the part of a vehicle that stores the power that is required to turn the engine and create a spark.

Battery Cables: This is a set of wires that carry the power from the battery to the starter and the rest of the engine. These cables usually fail due to corrosion, which interferes with the energy flow from the battery.

Starter: This is a mechanical device, an electric motor, that uses power from the battery to rotate the engine.

Coil: An electronic component that takes the twelve volts coming from the battery and converts it to a much larger voltage.

Coil Wire: A wire which caries the voltage from the coil to the distribution or computer controlled ignition points, which then distribute the pulse to the correct spark plug wire.

Spark Plug Wires: A set of wires that caries the electronic pulse from the distributor or ignition points to the appropriate spark plug.

Spark Plugs: A set of electronic components constructed of insulators and conductors. These spark plugs create a short between a spark point and a conductor. This short creates a spark that ignites the air fuel mixture.

Fuel: Also refered to as gasoline (petrol to our friends across the Atlantic). If you don’t know what this is give up now.

Fuel Lines: Tubes usually metal that carry fuel from the fuel tank to the engine.

Fuel Filter: A filtering device located somewhere between the fuel tank and engine. Used to eliminate impurities from the fuel.

Fuel Pump: A motor, electric in most newer vehicles, that pressurizes the fuel system this is what moves fuel from the gas tank to the engine.

Other Peoples Work:

As a reference I looked at an example program that was on the class web site called auto2_clp. Unfortunately I was unable to find it again on the web site at a later date. This system must have used some programming in LISP because clips did not like a lot of the functions he tried to use. His system did give me some ideas, but was more focused on an engine running incorrectly instead of it not starting. I alos used my first project as a reference.

What I did:

I began developing my project for lab two by trying to break all of my problems down into categories. I came up with five categories; they are Fuel, Power, Shop, Spark, and Starter. My idea was to use the power of the matcher to ask some basic questions and therefore determine which category to look into. A big problem I had was the fact that I was trying to do the same idea as I did for the first lab consequently I found myself working in terms of true and false. In my clips program I went down through things one at a time and eventually if nothing else matched I defaulted to take your car to the shop. I had some trouble after I made shop one of the categories deciding how I wanted to default it if nothing else seemed very likely. I didn’t want to make shop have to high of a priority, even if everything seemed to point that way, because it could turn out that if the user actually went into the battery field, for instance, they might actually find there problem that was manifesting itself as something else. For example one of the big things I look at is if the headlights turn on. If they don’t it is pretty likely that it is a power problem, but if they do, and fuel and starter and everything else checks out, I might say shop because I set the priority for shop to high when it didn’t look like anything else was the problem. The trouble is that it could turn out that it was a battery problem. The battery may have had enough juice to turn the lights on but not turn the starter at a fast enough speed to cause the engine to start. For this reason I decided to make the shop category neutral even when everything else didn’t seem to have a problem. The result of this is so as long as something even slightly matched I would try it before sending the user to the shop.

After I got the categories entered it was fairly easy to start asking technical questions to determine the problem. Once the questions dealing with that category were asked it was a simple matter of matching the answers the user gave with what I suspected the problem was. My big problem was with the unsure responses. In most cases I treated unsure responses as a worst-case scenario.

Solution:

The solution to this system is for the most part stated above. I created categories, which then would allow me to reduce the number of questions the user should have to answer in the worst-case scenario. For example, in my clips program for the first project, the user would have to go through questions dealing with electrical systems and the ignition system before it ever started asking the user questions about the fuel system. In project two by developing categories it allowed me to ask a few general questions and then allowing me to focus on a specific problem area.

Sample Run:

An Example of a run that produces an error:

I don’t feel this is too much of an error, but it appears to be the only error I could find, because if nothing else matches down inside any of the categories it defaults to take your car to the shop, which I don’t feel is an error, just a catchall. The error displayed in the below run isn’t a real error but here is what it is. If when the first question comes up and they answer unsure it exits just like they said yes. The first question is “does your car start?” If they say yes then this program is of no help to the user since its focus is only on why a car won’t start. In the example below the user indicated they were unsure if their engine started. At this point the program exits with no further questions because my feeling is if the user isn’t smart enough to figure out if there engine has started or not, they don’t deserve to use this program. In the future this situation could be changed to indicate take your car to the shop.

Limitations:

This program has many limitations that are forced upon it by the complexity of the modern internal combustion engine and the systems that go into helping it operate. The size of an expert system to accurately diagnose all the different problems that can occur in an engine would be huge. I focused primarily on those problems that can be fixed in a home garage and are easy to diagnose. Everything else I lumped under the “shop” category. The biggest limitation to this system is the users understanding of the components that go into the modern automobile. If the user is unsure of how to check the components that they are asked about, it is going to be very difficult to get an accurate solution.

Goodness:

I feel this program is good and can diagnose a large amount of the problems that cause an engine not to start. One complaint I have is that it doesn’t, or at least I couldn’t figure out how to, make the program display a message stating this is your problem. All the user gets is a tree that has how each node matched. I feel this is a disadvantage of the system. Between my two projects went I would feel more comfortable relying on the results from Project 1 rather than this project, because there is a lot more complexity to this system that I didn’t have to worry about in the first one. The more complexity in a system, as a rule of thumb, the more possibility of an error occurring that wasn’t expected. I also spent a considerable more amount of time debugging the first project than this one. That doesn’t mean that this system is bad, I actually felt like I did a very good job on it.

Improvements that could be made:

The two big improvements that could be made to this system would be to determine which category should be searched with fewer questions. I felt having to ask 5 or 6 questions to determine which category to look in was a little too many. I would also try to make them more systematic questions rather than measurement type questions.

The next big improvement that could be made would be to extend the type of problems that this system could diagnose. It could even be expanded to not just diagnose why a car is not starting but maybe why it is running poorly also.

Explicit description of Knowledge Representation and Control Methodology:

I previously explained this in my what I did section but here is a review. I took my solution space and broke it into five categories. These categories are Power, Ignition, Fuel, Starter, and Shop. Each of these diagnoses problems associated with them. For example the Power category diagnoses problems such as bad battery, and faulty battery cables. The Ignition category troubleshoots problems such as faulty coil, and bad spark plug wires. The program starts out by asking the user if their car starts. Of coarse if they say yes it exits because they are beyond the scope of this system. If the user indicates no in asks a few questions to determine which category is the best to explore. These questions include but are no limited to; “Do the headlights turn on?” and “Does the engine turn over?” Once it has the answers to the basic question it uses a table matcher to determine the relevance of the categories that it wants to look into and begins with the categories that are a match. Once it gets inside a category, the program starts asking the user questions that relate directly to the program diagnosing the problem. Each solution inside a category uses a table matcher to diagnose the problem from among the available solutions. For the Battery solution I tried something a little different with building a solution tree with sub nodes, similar to the bad fuel example given in the lectures, but it appeared to be a little unnecessary for what I was trying to accomplish. Upon browsing each category that even slightly matched if none had a solution that matched, the program defaults with a neutral to the shop category, which indicates, take your vehicle to the shop because this program was unable to determine a solution.

Scalability:

I see my project as very scalable, in the sense that it would be very easy to add more categories without affecting how any other category was implemented. Lets say for instance I wanted to add a category dealing with the air intake system. First thing I would have to do is make another category for it under the main category of car won’t start. Once the category is created I would just have to edit the table matcher and maybe add some more questions to the database, which are both easy. Once that is done I could do anything inside the category that I wanted and it would not affect anything outside of the category one bit. It is very similar to object oriented programming. Each node in the tree is like a class, and I would be willing to bet, that is how the underlying small talk architecture treats them. Each sub tree of a tree is probably inherited from the parent’s tree. What I was trying to get to is, that since it is object oriented what changes you make in one object should not directly affect the other objects.

My Methodology:

What I really liked about my methodology is that I was able to break the solution space into categories. I actually did this in a round about way for my clips program also, but Visual Works lended itself to it more readily. I also really liked the fact that Visual Works provides a more visual interface to the problem. Getting away from the command line type of interface seems to fit in more with the trend in industry to convert to visual systems.

What else I would have done:

Given more time I think I would have added more categories to my solution space. The more you can branch in a system such as this the faster you should be able to reach a solution. I also could have tried to break my categories into higher categories for the same reason. For instance I could have broken it into maybe mechanical problems and electrical problems. In this case starter, fuel and maybe air intake, if I added it, could be under a mechanical category and Power and Ignition could fall under the electrical category. I also know I would have spent a lot more time debugging this system if I had more time. I got my back against a wall on this project and had to cut back on my testing time. If I had a vast amount of more time I think it would be really interesting to make this system not just diagnose why a car won’t start but expand it to be a system to diagnose all sorts of different problems. In which case I could take my main node and make it a sub node of another major node that would incorporate it into a much larger expert system.