In this chapter, we will introduce case-based expert systems, an example of the Artificial Intelligence branch of our Autonomous Learning taxonomy. There are two broad classes of expert systems, rule-based and case-based. Rule-based systems have a set of rules that are applied to come to a decision; they are just a more organized way of writing decision statements in computer code. These systems provide a way of automating the process when decision-making involves hundreds or thousands of rules. Case-based systems decide by example, that is, a set of predefined cases.
Learning in the context of an expert system depends strongly on the configuration of the expert system. There are three primary methods, which vary in the level of autonomy of learning and the average generalization of the new knowledge of the system.
The least autonomous method of learning is the introduction of new rule sets in simple rule-based expert systems. Learning of this sort can be highly tailored and focused, but is done entirely at the behest of external teachers. In general, quite specific rule-based systems with extremely general rules tend to have issues with edge cases that require exceptions to their rules. Thus, this type of learning, although easy to manage and implement, is neither autonomous nor generalizable.
The second method is fact-gathering. The expert system makes decisions based on the known cause and effect relationships, along with an evolving model of the world; learning, then is broken up into two sub-pieces. Learning new cause and effect system rules is very similar to the type of learning described above, requiring external instruction, but can be more generalizable (as it is combined with more general world knowledge than a simple rule-based system might have). Learning new facts, however, can be very autonomous and involves the refinement of the expert system’s model of reality by increasing the amount of information that can be taken advantage of by the automated reasoning systems.
The third method is fully autonomous-based reasoning, where actions and their consequences are observed, leading to inferences about what prior and action combinations lead to what results. For instance, if two similar actions result in positive results, then those priors, which are the same in both cases, can begin to be inferred as necessary preconditions for a positive result from that action. As additional actions are seen, these inferences can be refined and confidence can increase in the predictions made.
The three methods are listed in increasing difficulty of implementation. Adding rules to a rule-based expert system is quite straightforward, although rule dependencies and priorities can become complicated. Fact-based knowledge expansion in automated reasoning systems is also fairly straightforward, once suitably generic sensing systems for handling incoming data are set up. The third method is by far the most difficult; however, rule-based systems can incorporate this type of learning. In addition, more general pattern recognition algorithms can be applied to training data (including on-line, unsupervised training data) to perform this function, learning to recognize, e.g., with a neural network, patterns of conditions that would lead to positive or negative results from a given candidate action. The system can then check possible actions against these learned classification systems to gauge the potential outcome of the candidate actions.
In this chapter, we will explore case-based reasoning systems. This is a collection of cases with their states and values given by strings. We do not address the problem of having databases with thousands of cases. The code we present would be too slow. We will not deal with a system that autonomously learns. However, the code in this chapter can be made to learn by feeding back the results of new cases into the case-based system.
14.1 Building Expert Systems
14.1.1 Problem
We want a tool to build a case-based expert system. Our tool needs to work for small sets of cases.
14.1.2 Solution
Build a function, BuildExpertSystem, that accepts parameter pairs to create the case-based expert system.
14.1.3 How It Works
The knowledge base consists of states, values, and production rules. There are four parts of a new case: the case name, the states and values, and the outcome. A state can have multiple values.
The state catalog is a list of all of the information that will be available to the reasoning system. It is formatted as states and state values. Only string values are permitted. Cell arrays store all the data.
The default catalog is shown below for reaction wheel control system. The cell array of acceptable or possible values for each state follows the state definition:
Our database of cases is designed to detect failures. We have three things to check to see if the wheel is working. If the wheel is turning and power is on and there is a torque command, then it is working. The wheel can be turning without a torque command or with the power off because it would just be spinning down from prior commands. If the wheel is not turning, the possibilities are that there is no torque command or that the power is off.
14.2 Running an Expert System
14.2.1 Problem
We want to create a case-based expert system and run it.
14.2.2 Solution
Build an expert system engine that implements a case-based reasoning system. It should be designed to handle small numbers of cases and be capable of updating the case database.
14.2.3 How It Works
Once you have defined a few cases from your state catalog, you can test the system. The function CBREngine implements the case-based reasoning engine. The idea is to pass it a case, newCase, and see if it matches any existing cases stored in the system data structure. For our problem we think that we have all the cases necessary to detect any failure. We do string matching with a built-in function using strcmpi. We then find the first value that matches.
The algorithm finds the total fraction of the cases that match to determine if the example matches the stored cases. The engine is matching values for states in the new case against values for states in the case database. It weights the results by the number of states. If the new case has more states than an existing case, it biases the result by the number of states in the database case divided by the number of states in the new case. If more than one case matches the new case and the outcomes for the matching cases are different, the outcome is declared “ambiguous”. If they are the same, it gives the new case that outcome. The case names make it easier to understand the results. We use strcmpi to make string matches case insensitive.
The demo script, ExpertSystemDemo, is quite simple. The first part builds the system. The remaining code runs some cases. ’id’ denotes the index of the following data in its cell array. For example, the first three entries are for the catalog and they are items 1 through 3. The next three are for cases and they are items 1 through 4. As BuildExpertSystem goes through the list of parameter pairs, it uses the last id as the index for subsequent parameter pairs.
As you can see, we match two cases, but because their outcome is the same the wheel is declared working. The wheel power ambiguous is called that because the power could be on or off, hence ambiguous. We could add this new case to the database using BuildExpertSystem.
We used fprintf in the script to print the following results into the command window.
This example is for a very small case-based expert system with a binary outcome. Multiple outcomes can be handled without any changes to the code. However, the matching process is slow, as it cycles through all the cases. A more robust system, handling thousands of cases, would need some kind of decision tree to cull the cases tested. For example, suppose we had several different components that we were testing. For example, with a landing gear we need to know that the tire is not flat, the brakes are working, the gear is deployed, and the gear is locked. If the gear is not deployed, we no longer have to test the brakes or the tires or that the gear is locked.
14.3 Summary
Chapter Code Listing
File | Description |
|---|---|
BuildExpertSystem | Function to build a case-based expert system database. |
CBREngine | Case-based reasoning engine. |
ExpertSystemDemo | Expert system demonstration. |