59
Ch8Expert System Dr. Bernard Chen Ph.D. University of Central Arkansas Spring 2011

Ch8Expert System Dr. Bernard Chen Ph.D. University of Central Arkansas Spring 2011

Embed Size (px)

Citation preview

Ch8Expert System

Dr. Bernard Chen Ph.D.University of Central Arkansas

Spring 2011

Outline

Expert System introduction Rule-Based Expert System

Goal Driven Approach Data Driven Approach

Model-Based Expert System

Expert System Introduction Human experts are able to perform at a

successful level because they know a lot about their areas of expertise

An Expert System use knowledge specific to a problem domain to provide “expert quality” performance in that application area

As with skilled humans, expert systems tend to be specialists, focusing on a narrow set of problems

Expert System Introduction Because of their heuristic,

knowledge intensive nature, expert systems generally: Support inspection of their reasoning

processes Allow easy modification in adding and

deleting skills from knowledge base Reason heuristically, using knowledge

to get useful solutions

Expert System Introduction Expert systems are built to solve a wide

range of problems in domain such as medicine, math, engineering, chemistry, geology, computer science, business, low, defense and education

These programs address a variety of problems, the following list is a summary of general expert system problem categories:

Expert System Introduction Interpretation --- forming high-level

conclusions from collections of raw data

Prediction --- projecting probable consequences of given situations

Diagnosis --- determining the cause of malfunctions based on observable symptoms

Expert System Introduction Design --- finding a configuration of

system components that meets performance goals while satisfying a set of design constrains

Planning --- devising a sequence of actions that will achieve a set of goals given starting conditions and runtime constrains

The Design of Rule-Based Expert System

• architecture of a typical expert system for a particular problem domain.

The Design of Rule-Based Expert System The hear of the expert system is the

knowledge base, which contains the knowledge of a particular application domain

In a rule-based expert system, this knowledge is most often represented in the form of if…then…

In the figure, the knowledge base contains both general and case-specific information

The Design of Rule-Based Expert System The inference engine applies the knowledge to

the solution of actual problems

It is important to maintain this separation of the knowledge and inference engine because:

Makes it possible to represent knowledge in a more natural fashion

Expert system builder can focus on capturing and organizing problem-solving knowledge than the details of code implementation

Allow change to be made easily Allows the same control and interface software to be

used in different systems

Selecting a problem Expert System involve a considerable

investment of money and human effort Researchers have developed guidelines

to determine whether a problem is appropriate for expert system solution:

The need for the solution justifies the cost and efforts of building an expert system

Human expertise is not available in all situation where it is needed

Selecting a problem The problem domain is well

structured and does not require common sense reasoning

The problem may not be solved using traditional computing methods

Cooperative and articulate experts exist

The problem is proper size and scope

NASA Example NASA has supported its presence in space

by developing a fleet of intelligent space probes that autonomously explore the solar system

To achieve success through years in the harsh conditions of space travel, a craft needs to be able to radically reconfigure its control regime in response to failures and then plan around these failures during it remaining flight

NASA Example Finally, NASA expects that the set of

potential failure scenarios and possible responses will be much too large to use software that supports preflight enumeration of all contingencies

Livingstone is an implemented kernel for a model-based reactive self-configuring autonomous system

NASA Example A long-held vision of model-based reasoning

has been to use a single centralized model to support a variety of engineering tasks

The tasks include keeping-track of developing plans Confirming hardware modes Reconfiguring hardware Detecting anomalies Diagnosis Fault recovery

NASA Example

NASA Example

It consist of a helium tank Regulators Propellant tanks A pair of main engine Latch valves Pyro valves

NASA Example The helium tank pressurizes the two propellant tanks,

with the regulators acting to reduce the high helium pressure

When propellant path to a main engine are open, the pressurized tank forces fuel and oxidizer into the main engine to produce thrust

The pyro valve is to isolate parts of the main engine subsystem until they are needed, or to permanently isolate failed components

The latch valve are controlled using valve drivers and the accelerometer

NASA Example

Thrust can be provided by either of the main engines and there are a number of ways of opening propellant paths to either main engine

NASA Example Suppose the main engine subsystem has been

configured to provide thrust from the left engine by opening the latch valves leading to it

And suppose this engine fails (overheating), so that is fails to provide the required thrust

To ensure that the desire thrust is provided, the spacecraft must be transitioned to a new configuration in which thrust is now provided by the main engine on the right side

Selecting a problem The primary people involved in building an

expert system are the knowledge engineer, domain expert, and end user

The domain expert is primarily responsible for spelling out skills to knowledge engineer

It is often useful for knowledge engineer to be a novice in the problem domain

Exploratory development cycle

Exploratory development cycle It is also understood that the prototype

may be thrown away if it becomes to cumbersome or if the designers decide to change their basic approach to the problem

Another major feature of expert system is that the program need never be considered “finished”

Outline

Expert System introduction Rule-Based Expert System

Goal Driven Approach Data Driven Approach

Model-Based Expert System

Strategies for state space search In data driven search, also called forward

chaining, the problem solver begins with the given facts of the problem and set of legal moves for changing state

This process continues until (we hope!!) it generates a path that satisfies the goal condition

“tic-tac-toe” state space graph

Strategies for state space search An alternative approach (Goal Driven) is start with the

goal that we want to solve See what rules can generate this goal and determine

what conditions must be true to use them These conditions become the new goals Working backward through successive subgoals until

(we hope again!) it work back to

Rule-Based Expert System Rule based expert system represent

problem-solving knowledge as if…then…

It is one of the oldest techniques for representing domain knowledge in an expert system

It is also one of the most natural and widely used in practical and experimental expert system

Rule-Based Expert System In a goal-driven expert system, the

goal expression is initially placed in working memory

The system matches rule conclusions with the goal, selecting one rule and placing its premises in the working memory

This corresponds to a decomposition of the problems’ goal into simpler subgoals

The process continues in the next iteration of the production system, with these premises becoming the new goals to match

A unreal Expert System Example Rule 1: if

the engine is getting gas, andthe engine will turn over,thenthe problem is spark plugs.

Rule 2: ifthe engine does not turn over, andthe lights do not come onthenthe problem is battery or cables.

Rule 3: ifthe engine does not turn over, andthe lights do come onthen the problem is the starter motor.

Rule 4: ifthere is gas in the fuel tank, andthere is gas in the carburetorthenthe engine is getting gas.

The production system at the start of a consultation in the car diagnostic example.

The production system at the start of a consultation in the car diagnostic example.

Three rules match with this expression in working memory: rule 1, 2, and 3

If we resolve conflicts in favor of the lowest-numbered rule, then rule 1 will fire

This cause X to be bound to the value spark plugs and the premises of rule 1 to be placed in the working memory

The production system after Rule 1 has fired.

The production system after Rule 1 has fired. Note that there are two premises to rule

1, both of which must be satisfied to prove the conclusion true

So now we need to find out whether The engine is getting gas, and The engine will turn over

We may then fire rule 4 for whether “The engine is getting gas”

The system after Rule 4 has fired. Note the stack-based approach to goal reduction.

The and/or graph searched in the car diagnosis example, with the conclusion of Rule 4 matching the first premise of Rule 1.

Explanation and Transparency in Goal-Driven Reasoning The following dialogue begins with the

computer asking the user about the goals present in the working memory: Gas in fuel tank?YES Gas in carburetor?YES Engine will turn over?WHY

Explanation and Transparency in Goal-Driven Reasoning In general, the two questions answered by

rule-based expert system are WHY? and HOW?

WHY means “why did you ask for that information”

The answer is the current rule that the production system is attempting to fire

HOW means “How did you get the result” The answer is the sequence of rules that were used

to conclude a goal

Explanation and Transparency in Goal-Driven Reasoning The following dialogue begins with the computer asking the user about

the goals present in the working memory: Gas in fuel tank?YES Gas in carburetor?YES Engine will turn over?WHY

It has been established that:1. The engine is getting gas, 2. The engine will turn over, (we need to know)So that we can make the conclusion that “Then the problem is the spark plugs.” 

Explanation and Transparency in Goal-Driven ReasoningGas in fuel tank?YesGas in carburetor?YesEngine will turn over?Why It has been established that:1. The engine is getting gas, 2. The engine will turn over,Then the problem is the spark plugs. How the engine is getting gas This follows from rule 4:ifgas in fuel tank, andgas in carburetorthenengine is getting gas.gas in fuel tank was given by the usergas in carburetor was given by the user

Outline

Expert System introduction Rule-Based Expert System

Goal Driven Approach Data Driven Approach

Model-Based Expert System

Data-Driven Reasoning The previous example exhibits goal-

driven search. The search was also depth-first search

Breadth-first search is more common in Data Driven reasoning

The algorithm for this category is simple: compare the contents of working memory with the conditions of each rule in the rule base according to the order of the rules

Data-Driven Reasoning

If a piece of information that makes up the premise of a rule is not the conclusion of some other rule,

then that fact will be deemed “askable”

For example: the engine is getting gas is not askable in the premise of rule 1

A unreal Expert System Example Rule 1: if

(not askable) the engine is getting gas, andthe engine will turn over,thenthe problem is spark plugs.

Rule 2: ifthe engine does not turn over, andthe lights do not come onthenthe problem is battery or cables.

Rule 3: ifthe engine does not turn over, andthe lights do come onthen the problem is the starter motor.

Rule 4: ifthere is gas in the fuel tank, andthere is gas in the carburetorthenthe engine is getting gas.

Data-Driven Reasoning

Data-Driven Reasoning The premise, the engine is getting gas

is NOT askable, so rule 1 fails and continue to rule 2

The engine does not turn over is askable

Suppose the answer to this query is false, so “the engine will turn over” is placed in working memory

The production system after evaluating the first premise of Rule 2, which then fails.

The production system after evaluating the first premise of Rule 2, which then fails.

Rule 2 fails, since the first of two AND premises is false, we move to rule 3

Where rule 3 also fails

So finally, we move to rule 4

The data-driven production system after considering Rule 4, beginning its second pass through the rules.

The data-driven production system after considering Rule 4, beginning its second pass through the rules.

At this point, all the rules have been considered

With the new contents of working memory, we consider the rules in order for the second round

Outline

Expert System introduction Rule-Based Expert System

Goal Driven Approach Data Driven Approach

Model-Based Expert System

Model-Based Expert System Human expertise is an extremely complex

combination of: Theoretical knowledge Experienced based problem solving heuristics Example of past problems and their solutions Interpretive skills

Through years of experience, human expert develop very powerful rules for dealing with commonly encountered situations

These rules are often highly “complied”

Model-Based Expert System In a rule-based expert system example for

semiconductor failure analysis, a descriptive approach might base on:

Discoloration of components (burned-out) History of faults in similar devices Observation of component by electron microscope

However, approaches that use rules to link observations and diagnosis do not offer the benefits of a deeper analysis of device’s structure and function

Model-Based Expert System A more robust, deeply explanatory

approach would begin with a detailed model of the physical structure of the circuit and equations describing the expected behavior of each component and their interactions.

A knowledge based reasoner whose analysis is founded directly on the specification and functionality of a physical system is called a MODEL-BASED System

Model-Based Expert System The model based system tells its user what

to expect, and when observations differ from these expectations, it will lead to identification of faults

Qualitative model-based reasoning includes: A description of each component in the device A description of the devices’ internal structure Observation of the devices’ actual performance

Model-Based Expert System Example

The expected output value are given in () and the actual outputs in [ ]

Model-Based Expert System Example

At F, we have a conflict

We check the dependencies at this point and determined ADD1, MULT1 and MULT2 are involved

One of these three devices must have a fault, so we have three hypotheses to consider: Either the adder behavior is bad or one of its two inputs was incorrect

Model-Based Expert System Example

Assuming ADD1 and one of its input X is correct (6)

Another input Y must be (4)

Continue this reasoning, Y can not be MULT2 since G is correct

We are left with the hypotheses that the fault lies in either MULT1 or ADD1

Model-Based Expert System Example

Finally, we should note that in the example, there was assumed to be a single faulty device.

The world is not always this perfect Many other possible problems may

occur: Wire is broken Faulty connection to the multiplier