IT16503 – Computational Intelligence SVCE - IT

UNIT IV
EXPERT SYSTEMS
Syllabus
Expert systems – Architecture of expert systems, Roles of expert systems – Knowledge Acquisition – Meta
knowledge, Heuristics. Typical expert systems – MYCIN, DART, XOON, Expert systems shells.
Lecture Notes
1.1Expert Systems (ES)
● Expert systems are knowledge based programs which provide expert quality solutions to the problems
in specific domain of applications.
● The core components of expert system are
− knowledge base and
− navigational capability (inference engine)
● Generally its knowledge is extracted from human experts in the domain of application by knowledge
Engineer.
− Often based on useful thumb rules and experience rather than absolute certainties.
● A process of gathering knowledge from domain expert and codifying it according to the formalism is
called knowledge engineering.

Characteristics of Expert Systems

 High performance
 Understandable
 Reliable
 Highly responsive
Expert systems can be distinguished from conventional computer systems in that:
1. They simulate human reasoning about the problem domain, rather than simulating the domain itself.
2. They perform reasoning over representations of human knowledge, in addition to doing numerical
calculations or data retrieval. They have corresponding distinct modules referred to as the inference engine
and the knowledge base.
3. Problems tend to be solved using heuristics (rules of thumb) or approximate methods or probabilistic
methods which, unlike algorithmic solutions, are not guaranteed to result in a correct or optimal solution.
4. They usually have to provide explanations and justifications of their solutions or recommendations in order
to convince the user that their reasoning is correct.
Note that the term Intelligent Knowledge Based System (IKBS) is sometimes used as a synonym for
Expert System.

Capabilities of Expert Systems

The expert systems are capable of −
 Advising
 Instructing and assisting human in decision making
 Demonstrating
 Deriving a solution
 Diagnosing
 Explaining
 Interpreting input
 Predicting results
 Justifying the conclusion
 Suggesting alternative options to a problem

1
IT16503 – Computational Intelligence SVCE - IT
They are incapable of −
 Substituting human decision makers
 Possessing human capabilities
 Producing accurate output for inadequate knowledge base
 Refining their own knowledge

Typical Tasks for Expert Systems

There are no fundamental limits on what problem domains an expert system can be built to deal with. Some
typical existing expert system tasks include:
1. The interpretation of data
Such as sonar data or geophysical measurements
2. Diagnosis of malfunctions
Such as equipment faults or human diseases
3. Structural analysis or configuration of complex objects
Such as chemical compounds or computer systems
4. Planning sequences of actions
Such as might be performed by robots
5. Predicting the future
However, these days, ―conventional‖ computer systems can also do some of these things

1.2 Expert System Architecture

The process of building expert systems is often called knowledge engineering. The knowledge engineer is
involved with all components of an expert system:
2
IT16503 – Computational Intelligence SVCE - IT

Building expert systems is generally an iterative process. The components and their interaction will be refined
over the course of numerous meetings of the knowledge engineer with the experts and users. We shall look in
turn at the various components.

Components of Expert Systems

The components of ES include −
 Knowledge Base
 Inference Engine
 User Interface
Let us see them one by one briefly −

1.2.1 Knowledge Acquisition

The knowledge acquisition component allows the expert to enter their knowledge or expertise into the
expert system, and to refine it later as and when required.
● Sources of Knowledge for ES
− text books, reports, case studies,
− empirical data and

3
IT16503 – Computational Intelligence SVCE - IT
− domain expert experience.
● Updation of Knowledge can be done using knowledge acquisition module of the system.
− insertion,
− deletion and
− updation of existing knowledge
The success of any expert system majorly depends on the quality, completeness, and accuracy of the
information stored in the knowledge base.
The knowledge base is formed by readings from various experts, scholars, and the Knowledge
Engineers. The knowledge engineer is a person with the qualities of empathy, quick learning, and case
analyzing skills.
He acquires information from subject expert by recording, interviewing, and observing him at work,
etc. He then categorizes and organizes the information in a meaningful way, in the form of IF-THEN-ELSE
rules, to be used by interference machine. The knowledge engineer also monitors the development of the ES.
Historically, the knowledge engineer played a major role in this process, but automated systems that
allow the expert to interact directly with the system are becoming increasingly common.
The knowledge acquisition process is usually comprised of three principal stages:
1. Knowledge elicitation is the interaction between the expert and the knowledge engineer/program to elicit
the expert knowledge in some systematic way.
2. The knowledge thus obtained is usually stored in some form of human friendly intermediate representation.
3. The intermediate representation of the knowledge is then compiled into an executable form (e.g. production
rules) that the inference engine can process.
In practice, much iteration through these three stages is usually required!

Knowledge Elicitation
The knowledge elicitation process itself usually consists of several stages:
1. Find as much as possible about the problem and domain from books, manuals, etc. In particular, become
familiar with any specialist terminology and jargon.
2. Try to characterize the types of reasoning and problem solving tasks that the system will be required to
perform.
3. Find an expert (or set of experts) that is willing to collaborate on the project. Sometimes experts are
frightened of being replaced by a computer system!
4. Interview the expert (usually many times during the course of building the system). Find out how they
solve the problems your system will be expected to solve. Have them check and refine your intermediate
knowledge representation.
This is a time intensive process, and automated knowledge elicitation and machine learning techniques are
increasingly common modern alternatives.

Knowledge Base
It contains domain-specific and high-quality knowledge. Knowledge is required to exhibit intelligence. The
success of any ES majorly depends upon the collection of highly accurate and precise knowledge.
 KB consists of knowledge about problem domain in the form of static and dynamic databases.
 Static knowledge consists of
− rules and facts which is complied as a part of the system and does not change during execution
of the system.
 Dynamic knowledge consists of facts related to a particular consultation of the system.
− At the beginning of the consultation, the dynamic knowledge base often called working
memory is empty.

4
IT16503 – Computational Intelligence SVCE - IT
− As a consultation progresses, dynamic knowledge base grows and is used along with static
knowledge in decision making.
 Working memory is deleted at the end of consultation of the system.

Components of Knowledge Base

The knowledge base of an ES is a store of both, factual and heuristic knowledge.
 Factual Knowledge − It is the information widely accepted by the Knowledge Engineers and scholars
in the task domain.
 Heuristic Knowledge − It is about practice, accurate judgement, one’s ability of evaluation, and
guessing.
Knowledge representation
It is the method used to organize and formalize the knowledge in the knowledge base. It is in the form of IF-
THEN-ELSE rules.

Inference Engine
 It consists of inference mechanism and control strategy.
 Inference means search through knowledge base and derive new knowledge.
 It involve formal reasoning involving matching and unification similar to the one performed by human
expert to solve problems in a specific area of knowledge.
 Inference operates by using modus ponen rule.
Use of efficient procedures and rules by the Inference Engine is essential in deducting a correct, flawless
solution.
In case of knowledge-based ES, the Inference Engine acquires and manipulates the knowledge from the
knowledge base to arrive at a particular solution.
In case of rule based ES, it −
 Applies rules repeatedly to the facts, which are obtained from earlier rule application.
 Adds new knowledge into the knowledge base if required.
 Resolves rules conflict when multiple rules are applicable to a particular case.
 Control strategy determines the order in which rules are applied.
 There are mainly two types of control mechanism viz., forward chaining and backward chaining.

User Interface
User interface provides interaction between user of the ES and the ES itself. It is generally Natural Language
Processing so as to be used by the user who is well-versed in the task domain. The user of the ES need not be
necessarily an expert in Artificial Intelligence.
It explains how the ES has arrived at a particular recommendation. The explanation may appear in the
following forms −
 Natural language displayed on screen.
 Verbal narrations in natural language.
 Listing of rule numbers displayed on the screen.
The user interface makes it easy to trace the credibility of the deductions.
Requirements of Efficient ES User Interface
 It should help users to accomplish their goals in shortest possible way.
 It should be designed to work for user’s existing or desired work practices.
 Its technology should be adaptable to user’s requirements; not the other way round.
 It should make efficient use of user input.

5
IT16503 – Computational Intelligence SVCE - IT
1.2.2 Phases in building Expert System
There are different interdependent and overlapping phases in building an expert system as follows:
● Identification Phase:
− Knowledge engineer finds out important features of the problem with the help of domain
expert (human).
− He tries to determine the type and scope of the problem, the kind of resources required, goal
and objective of the ES.
● Conceptualization Phase:
− In this phase, knowledge engineer and domain expert decide the concepts, relations and control
mechanism needed to describe a problem solving.
● Formalization Phase:
− It involves expressing the key concepts and relations in some framework supported by ES
building tools.
− Formalized knowledge consists of data structures, inference rules, control strategies and
languages for implementation.
● Implementation Phase:
− During this phase, formalized knowledge is converted to working computer program initially
called prototype of the whole system.
● Testing Phase:
− It involves evaluating the performance and utility of prototype systems and revising it if need
be. Domain expert evaluates the prototype system and his feedback help knowledge engineer
to revise it.

1.2.3 Roles in Expert System Development

Three fundamental roles in building expert systems are:
1. Expert - Successful ES systems depend on the experience and application of knowledge that the
people can bring to it during its development. Large systems generally require multiple experts.
2. Knowledge engineer - The knowledge engineer has a dual task. This person should be able to elicit
knowledge from the expert, gradually gaining an understanding of an area of expertise.
Intelligence, tact, empathy, and proficiency in specific techniques of knowledge acquisition are all required
of a knowledge engineer. Knowledge-acquisition techniques include conducting interviews with varying
degrees of structure, protocol analysis, observation of experts at work, and analysis of cases.
On the other hand, the knowledge engineer must also select a tool appropriate for the project and use it to
represent the knowledge with the application of the knowledge acquisition facility.

6
IT16503 – Computational Intelligence SVCE - IT
3. User - A system developed by an end user with a simple shell, is built rather quickly an
inexpensively. Larger systems are built in an organized development effort. A prototype-oriented iterative
development strategy is commonly used. ESs lends themselves particularly well to prototyping.

1.2.4 Typical Expert System

1. A problem-domain-specific knowledge base that stores the encoded knowledge to support one problem
domain such as diagnosing why a car won't start. In a rule-based expert system, the knowledge base includes
the if-then rules and additional specifications that control the course of the interview.

2. An inference engine a set of rules for making deductions from the data and that implements the reasoning
mechanism and controls the interview process. The inference engine might be generalized so that the same
software is able to process many different knowledge bases.
3. The user interface requests information from the user and outputs intermediate and final results. In some
expert systems, input is acquired from additional sources such as data bases and sensors.
An expert system shell consists of a generalized inference engine and user interface designed to work
with a knowledge base provided in a specified format. A shell often includes tools that help with the design,
development and testing of the knowledge base. With the shell approach, expert systems representing many
different problem domains may be developed and delivered with the same software environment. .
There are special high level languages used to program expert systems egg PROLOG The user
interacts with the system through a user interface which may use menus, natural language or any other style of
interaction). Then an inference engine is used to reason with both the expert knowledge (extracted from our
friendly expert) and data specific to the particular problem being solved.
The expert knowledge will typically be in the form of a set of IF-THEN rules. The case specific data
includes both data provided by the user and partial conclusions (along with certainty measures) based on this
data. In a simple forward chaining rule-based system the case specific data will be the elements in working
memory.

Development of Expert Systems: General Steps

The process of ES development is iterative. Steps in developing the ES include −
Identify Problem Domain
 The problem must be suitable for an expert system to solve it.
 Find the experts in task domain for the ES project.
 Establish cost-effectiveness of the system.
Design the System
 Identify the ES Technology
 Know and establish the degree of integration with the other systems and databases.
 Realize how the concepts can represent the domain knowledge best.
Develop the Prototype
From Knowledge Base: The knowledge engineer works to −
 Acquire domain knowledge from the expert.
 Represent it in the form of If-THEN-ELSE rules.
Test and Refine the Prototype
 The knowledge engineer uses sample cases to test the prototype for any deficiencies in performance.

7
IT16503 – Computational Intelligence SVCE - IT
 End users test the prototypes of the ES.
Develop and Complete the ES
 Test and ensure the interaction of the ES with all elements of its environment, including end users,
databases, and other information systems.
 Document the ES project well.
 Train the user to use ES.
Maintain the ES
 Keep the knowledge base up-to-date by regular review and update.
 Cater for new interfaces with other information systems, as those systems evolve.

1.2.5 Expert Systems shells

Initially each expert system is build from scratch (LISP). Systems are constructed as a set of
declarative representations (mostly rules) combined with an interpreter for those representations.
It helps to separate the interpreter from domain-specific knowledge and to create a system that could
be used construct new expert system by adding new knowledge corresponding to the new problem domain.
The resulting interpreters are called shells. Example of shells is EMYCIN (for Empty MYCIN derived from
MYCIN).

Shells − A shell is nothing but an expert system without knowledge base. A shell provides the
developers with knowledge acquisition, inference engine, user interface, and explanation facility.
For example, few shells are given below −
 Java Expert System Shell (JESS) that provides fully developed Java API for creating an expert
system.
 Vidwan, a shell developed at the National Centre for Software Technology, Mumbai in 1993. It
enables knowledge encoding in the form of IF-THEN rules.
Shells provide greater flexibility in representing knowledge and in reasoning than MYCIN. They support
rules, frames, truth maintenance systems and a variety of other reasoning mechanisms.
Early expert system shells provide mechanisms for knowledge representation, reasoning and
explanation. Later these tools provide knowledge acquisition. Still expert system shells need to integrate with
other programs easily. Expert systems cannot operate in a vacuum. The shells must provide an easy-to-use
interface between an expert system written with the shell and programming environment.

Expert System Technology

There are several levels of ES technologies available. Expert systems technologies include −
 Expert System Development Environment − The ES development environment includes hardware
and tools. They are −
o Workstations, minicomputers, mainframes.

8
IT16503 – Computational Intelligence SVCE - IT
o High level Symbolic Programming Languages such as LISt Programming (LISP) and
PROgrammation en LOGique (PROLOG).
o Large databases.
 Tools − They reduce the effort and cost involved in developing an expert system to large extent.
o Powerful editors and debugging tools with multi-windows.
o They provide rapid prototyping
o Have Inbuilt definitions of model, knowledge representation, and inference design.
 Shells − A shell is nothing but an expert system without knowledge base. A shell provides the
developers with knowledge acquisition, inference engine, user interface, and explanation facility. For
example, few shells are given below −
o Java Expert System Shell (JESS) that provides fully developed Java API for creating an expert
system.
o Vidwan, a shell developed at the National Centre for Software Technology, Mumbai in 1993. It
enables knowledge encoding in the form of IF-THEN rules.

Expert Systems Limitations

No technology can offer easy and complete solution. Large systems are costly, require significant
development time, and computer resources. ESs have their limitations which include −
 Limitations of the technology
 Difficult knowledge acquisition
 ES are difficult to maintain
 High development costs

Applications of Expert System

The following table shows where ES can be applied.
Application
Design Domain
Medical Domain
Monitoring Systems
Process Control Systems
Knowledge Domain
Finance/Commerce
Description
Camera lens design, automobile design.
Diagnosis Systems to deduce cause of disease from observed data,
conduction medical operations on humans.
Comparing data continuously with observed system or with prescribed
behavior such as leakage monitoring in long petroleum pipeline.
Controlling a physical process based on monitoring.
Finding out faults in vehicles, computers.
Detection of possible fraud, suspicious transactions, stock market trading,
Airline scheduling, cargo scheduling.

Benefits of Expert Systems

 Availability − They are easily available due to mass production of software.
 Less Production Cost − Production cost is reasonable. This makes them affordable.
 Speed − They offer great speed. They reduce the amount of work an individual puts in.
 Less Error Rate − Error rate is low as compared to human errors.
 Reducing Risk − They can work in the environment dangerous to humans.
 Steady response − They work steadily without getting motional, tensed or fatigued.

9
IT16503 – Computational Intelligence SVCE - IT
1.3 MYCIN
For diagnosing and treating patients with infectious blood diseases doctors have some difficulties
• Time Consuming
• Misuse and overuse of antibiotics
• Shortage of expertise
We need a System to help physicians
• An expert was required to solve the problem.
• Experts on the problem were scarce or unavailable because of time constraints.
• Immediate expertise was needed in a possibly life treating situation.
• Time constraints required decisions to be made with limited or inexact information
• The computer solution needed to be accommodating to the user, who may have limited experience
with computers.
• Existing solutions may be irrational in cases where drug recommendations were inappropriate for the
problem.
• Remembering the appropriateness and possible contradictions of a large number of drugs was a
challenge for the physician.

MYCIN was an early expert system that used artificial intelligence to identify bacteria causing severe
infections, such as bacteremia and meningitis, and to recommend antibiotics, with the dosage adjusted for
patient’s body weight — the name derived from the antibiotics themselves, as many antibiotics have the suffix
―-mycin‖. The Mycin system was also used for the diagnosis of blood clotting diseases.
MYCIN was developed over five or six years in the early 1970s at Stanford University. It was written
in Lisp as the doctoral dissertation of Edward Shortliffe under the direction of Bruce G. Buchanan, Stanley N.
Cohen and others. It arose in the laboratory that had created the earlier Dendral expert system.
MYCIN was never actually used in practice but research indicated that it proposed an acceptable
therapy in about 69% of cases, which was better than the performance of infectious disease experts who were
judged using the same criteria.

1.3.1 MYCIN Architecture

10
IT16503 – Computational Intelligence SVCE - IT
1.3.1.1 Consultation System
 Performs Diagnosis and Therapy Selection
 Control Structure reads Static DB (rules) and read/writes to Dynamic DB (patient, context)
 Linked to Explanations
 Terminal interface to Physician
 User-Friendly Features:
1. Users can request rephrasing of questions
2. Synonym dictionary allows latitude of user responses
3. User typos are automatically fixed
 Questions are asked when more data is needed
1. If data cannot be provided, system ignores relevant rules
Consultation “Control Structure”
 Goal-directed Backward-chaining Depth-first Tree Search
 High-level Algorithm:
1. Determine if Patient has significant infection
2. Determine likely identity of significant organisms
3. Decide which drugs are potentially useful
4. Select best drug or coverage of drugs
1.3.1.2 Static Database
It consists of
 Rules
 Meta-Rules
 Templates
 Rule Properties
 Context Properties
 Fed from Knowledge Acquisition System
Production Rules
 Represent Domain-specific Knowledge
 Over 450 rules in MYCIN
 Premise-Action (If-Then) Form:
<predicate function><object><attrib><value>
 Each rule is completely modular, all relevant context is contained in the rule with explicitly stated
premises
 Not every domain can be represented, requires formalization (EMYCIN)
 Only small number of simultaneous factors (more than 6 was thought to be unwieldy)
 IF-THEN formalism is suitable for Expert Knowledge Acquisition and Explanation sub-systems
Judgmental Knowledge
 Inexact Reasoning with Certainty Factors (CF)
 CF are not Probability!
 Truth of a Hypothesis is measured by a sum of the CFs
1. Premises and Rules added together
2. Positive sum is confirming evidence
3. Negative sum is disconfirming evidence
Sub-goals
 At any given time MYCIN is establishing the value of some parameter by sub-goaling
 Unity Paths: a method to bypass sub-goals by following a path whose certainty is known (CF==1) to
make a definite conclusion
 Won’t search a sub-goal if it can be obtained from a user first (i.e. lab data)

11
IT16503 – Computational Intelligence SVCE - IT
Preview Mechanism
 Interpreter reads rules before invoking them
 Avoids unnecessary deductive work if the sub-goal has already been tested/determined
 Ensures self-referencing sub-goals do not enter recursive infinite loops
Meta-Rules
 Alternative to exhaustive invocation of all rules
 Strategy rules to suggest an approach for a given sub-goal
1. Ordering rules to try first, effectively pruning the search tree
 Creates a search-space with embedded information on which branch is best to take
 High-order Meta-Rules (i.e. Meta-Rules for Meta-Rules)
1. Powerful, but used limitedly in practice
 Impact to the Explanation System:
1. (+) Encode Knowledge formerly in the Control Structure
2. (-) Sometimes create ―murky‖ explanations
Templates
 The Production Rules are all based on Template structures
 This aids Knowledge-base expansion, because the system can ―understand‖ its own representations
 Templates are updated by the system when a new rule is entered

1.3.1.3 Dynamic Database

 Patient Data
 Laboratory Data
 Context Tree
 Built by Consultation System
 Used by Explanation System
Therapy Selection
 Plan-Generate-and-Test Process
 Therapy List Creation
1. Set of specific rules recommend treatments based on the probability (not CF) of organism
sensitivity
2. Probabilities based on laboratory data
3. One therapy rule for every organism
 Assigning Item Numbers
1. Only hypothesis with organisms deemed ―significantly likely‖ (CF) are considered
2. Then the most likely (CF) identity of the organisms themselves are determined and assigned an
Item Number
3. Each item is assigned a probability of likelihood and probability of sensitivity to drug
 Final Selection based on:

1. Sensitivity
2. Contraindication Screening
3. Using the minimal number of drugs and maximizing the coverage of organisms
 Experts can ask for alternate treatments
1. Therapy selection is repeated with previously recommended drugs removed from the list

1.3.1.4 Explanation System

 Provides reasoning why a conclusion has been made, or why a question is being asked
 Q-A Module

12
IT16503 – Computational Intelligence SVCE - IT
 Reasoning Status Checker
 Uses a trace of the Production Rules for a basis, and the Context Tree, to provide context
1. Ignores Definitional Rules (CF == 1)
 Two Modules
1. Q-A Module
2. Reasoning Status Checker
Q-A Module
 Symbolic Production Rules are readable
 Each <predicate function> has an associated translation pattern:
GRID (THE (2) ASSOCIATED WITH (1) IS KNOWN)
VAL (((2 1)))
PORTAL (THE PORTAL OF ENTRY OF *)
PATH-FLORA (LIST OF LIKELY PATHOGENS)
 i.e. (GRID (VAL CNTXT PORTAL) PATH-FLORA) becomes:
―The list of likely pathogens associated with the portal of entry of the organism is known.‖
Reasoning Status Checker
 Explanation is a tree traversal of the traced rules:
1. WHY – moves up the tree
2. HOW – moves down (possibly to untried areas)
 Question is rephrased, and the rule being applied is explained with the translation patterns

1.3.1.5 Knowledge Acquisition System

 Extends Static DB via Dialogue with Experts
 Dialogue Driven by System
 Requires minimal training for Experts
 Allows for Incremental Competence, NOT an All-or-Nothing model
 IF-THEN Symbolic logic was found to be easy for experts to learn, and required little training by the
MYCIN team
 When faced with a rule, the expert must either except it or be forced to update it using the education
process
Education Process
1. Bug is uncovered, usually by Explanation process
2. Add/Modify rules using subset of English by experts
3. Integrating new knowledge into KB
 Found to be difficult in practice, requires detection of contradictions, and complex concepts
become difficult to express
Results
 Never implemented for routine clinical use
 Shown to be competent by panels of experts, even in cases where experts themselves disagreed on
conclusions
 Key Contributions:
 Reuse of Production Rules (explanation, knowledge acquisition models)
 Meta-Level Knowledge Use

Other MYCINs
 EMYCIN
◦ Empty MYCIN
◦ Large Amount of LISP Code

13
IT16503 – Computational Intelligence SVCE - IT
 TMYCIN
◦ Tiny EMYCIN
◦ Only some features of EMYCIN
 PUFF
◦ Based on EMYCIN
◦ Has knowledge of lung diseases
 NEOMYCIN
◦ Base on MYCIN
◦ For teaching, in the laboratories
◦
1.4 DART (Diagnostic Assistance Reference Tool )
DART is a joint project of the Stanford University and IBM that explores the application of artificial
intelligence techniques to the diagnosis of computer faults. It assists a technician in finding the faults in a
computer system. (hardware and software)
DART uses a device-independent language for describing devices and device-independent inference
procedure for diagnosis.
The primary goal of the DART Project is to develop programs that capture the special design
knowledge and diagnostic abilities of these experts and to make them available to field engineers. The
practical goal is the construction of an automated diagnostician capable of pin pointing the functional units
responsible for observed malfunctions in arbitrary system configurations.
– It is an Artificial intelligence Program based on decision support system.
– Used by the U.S military to optimize and schedule the transportation of supplies or personnel and solve
other logistical problems.
– It uses intelligent agents to aid decision support systems located at U.S transportation and European
Commands.
– DART integrates a set of intelligent agents and database management systems to give planners the ability
to rapidly evaluate plans for logical feasibility.
– Automatic evaluation.
– Decreases cost.
– Decreases time.

IMPACT
 Solved logistical nightmares.
 Saved military millions of dollars.
 Helped in obstacles.
 Improves upon existing upon existing plans made by U.S military
 Logistical solution surprised military planners.
 DARTs success led to the development of other military planning agents such as
 RDA-Resource Description and Access system
 DRPI-Knowledge-Based Planning and Scheduling Initiative-successor

MAIN PURPOSE:
 Fault Diagnosis in Hardware.
TECHNIQUE:
-First Principle which means Using the information related to Design of the Hardware Tested which uses
results of the tests and identifies plausible malfunctioning elements.

14
IT16503 – Computational Intelligence SVCE - IT
ADVANTAGE:
 DaRT provides tools to help you fix a problem as soon as the cause is determined. For example, you
can use the tools in DaRT to disable a faulty device driver, remove hotfixes, restore deleted files, and
scan the computer for malware even when you cannot or should not start the installed Windows
operating system.

1.4 XCON: eXpert CONfigurer

XCON/R1 is one of the most cited expert systems. It was developed by DEC (Digital Equipment
Corporation) and was a system that ensured the customer was supplied with all the components and software
that was needed to make up the specified computer system that they had ordered. This is not as easy as it
sounds. Building a bespoke computer system means that every system is different and, as such, needs
different components and software.
R1 was developed by DEC to design and configure VAX computers based on customer specifications for
the computer. The configuration would include the components including number and type of disk drives,
number of power supply units, cables, etc and the configuration would dictate where each of these
components would be housed in the mainframe’s cabinet. The system was first called R1, but once it was
fully tested out, DEC began using it in practice and called the system XCON. As XCON, the system went on
to successfully configure over 80,000 orders in a 6 year period (experts judged its designs to be 95-98%
accurate).
For example, if a customer orders a disc drive then DEC has to ensure that the customer also receives the
disc controller and the relevant cables. As a single system can be built from thousands of separate
components, it was not easy for a human to ensure that the customer had everything he/she needed to build
the system. XCON/R1 was an expert system that did this job automatically. It saved DEC millions of dollars a
year and raised the profile of expert system to a level that had not been seen before.
R1’s rules were largely all design steps. Each one was very primitive. Over time, the number of rules
grew to be around 10,000.
For instance, one rule might say ―if you still need a disk drive and the type of disk drive has been
determined and there is space for a disk drive at location X then position the disk drive at location X.‖ Unlike
MYCIN, R1’s rules used no CFs. This seems reasonable because, unlike a diagnostic situation, a planning
situation should have little or no uncertainty.
R1’s planning process was broken into three phases.
First, given the user’s specifications (order), the specifications had to be complete. R1 would scan the
specification for missing pieces or inconsistencies. If found, some of R1’s rules would fire to fill in the gaps.
Second, R1 would select and configure the various components that would be placed inside the
mainframe cabinet. These would include disk drives, tapes, motherboard(s) and components on the
motherboard(s).
Finally, R1 would configure the wiring of the devices. Within the second phase, steps would also be
ordered so that the most important components were selected first (e.g., CPU, memory) and after all
components were selected, then configuration would take place.
What follows are examples of R1 rules. The first two rules are constraint rules. The last three rules are
configuration rules. Notice how specific each rule is.

• Constraint rules
– if device requires battery then select battery for device
– if select battery for device then pick battery with voltage(battery) = voltage(device)
• Configuration rules
– if we are in the floor plan stage and there is space for a power supply and there is no power
supply available then add a power supply to the order

15
IT16503 – Computational Intelligence SVCE - IT
– if step is configuring, propose alternatives and there is an unconfigured device and no container
was chosen and no other device that can hold it was chosen and selecting a container wasn’t
proposed yet and no problems for selecting containers were identified then propose selecting a
container
– if the step is distributing a massbus device and there is a single port disk drive that has not been
assigned to a massbus and there are no unassigned dual port disk drives and the number of
devices that each massbus should support is known and there is a massbus that has been
assigned at least one disk drive and that should support additional disk drives and the type of
cable needed to connect the disk drive is known, then assign the disk drive to this massbus

Ironically, we tend to think of forward chaining as data driven, used in such problems as diagnosis, whereas
backward chaining is goal driven, used in such problems as planning and design. However, two of the most
influential, early expert systems, had it backward!

PART-A
1. What are the phases in Expert system development?
2. Explain identification phase.
3. Explain conceptualization phase.
4. Explain formalization phase.
5. Explain implementation and testing phases
6. What are the limitations of expert systems?
7. Explain XCON?
8. What are expert systems?
9. What are the most important aspects of expert system?
10. What are the characteristics of expert system?
11. Sketch the general features of expert system?
12. Who are all involved in the expert system building?
13. Explain the role of domain expert?
14. Explain the role of knowledge engineer?
15. What is the use of expert system building tool?
16. Give the structure of an expert system?
17. Explain the knowledge acquisition process?
18. Define MYCIN.
19. Define DART.
20. What is meta knowledge? How meta knowledge is represented in rule based expert systems?

PART – B
1. Explain about knowledge acquisition in expert system
2. Explain with a neat diagram, the architecture of an expert system
3. Explain MYCIN expert system in detail
4. List any six applications of expert systems
5. Explain in detail about DART, XCON.

16