PC Troubleshooting Expert

PROJECT REPORT

SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE AWARD OF THE DEGREE MASTER OF COMPUTER APPLICATIONS
BY

Deepak. P

Project Guide: Dr. Priya Chandran

DEPARTMENT OF COMPUTER ENGINEERING

NATIONAL INSTITUTE OF TECHNOLOGY CALICUT

NIT CAMPUS P.O, KOZHIKODE 673601, KERALA

APRIL - 2005

National Institute of Technology Calicut

Department of Computer Engineering CERTIFICATE

This is to certify that the work reported in this project report entitled PC Troubleshooting Expert is a bonafide record of the work done by Deepak. P, a student in the Department of Computer Engineering, National Institute of Technology Calicut from December 2004 to April 2005 in partial fulfillment for the award of the degree of Master of Computer Applications of the National Institute of Technology Calicut.

Guide:

Dr. Priya Chandran Asst. Professor Dept. of Computer Engineering NIT, Calicut

Head of the Department: Dr. V.K Govindan Professor Dept. of Computer Engineering NIT, Calicut

ACKNOWLEDGEMENT

First of all I would like to thank my guide Dr. Priya Chandran, Asst.Professor and our project coordinator, Dr.Vineeth Kumar P, Asst.Professor, Department of Computer Engineering, National Institute of Technology, Calicut, for there guidance and support through out my project work.

I would also like to thank Dr. V.K Govindan, Head of the Department, Department of Computer Engineering, National Institute of Technology, Calicut, for all the help he has extended to me.

ABSTRACT
An expert system for personal computer troubleshooting, developed as part of MCA 6th semester Course project work, National Institute of Technology, Calicut, is presented. It is implemented on a personal computer. The proposed system includes many characteristics of an expert system because it can be expanded easily by adding new information to its knowledge base or by changing its existing information. The basic idea behind this expert system is to provide a non-expert with the necessary information and interaction in order to troubleshoot a personal computer hardware problem in a very userfriendly environment. This also aims to take advantage of the users experience to expand and modify the knowledge base of the expert system.

CONTENTS
INTRODUCTION ---------------------------------------------------------------------------------1 SYSTEM ANALYSIS-----------------------------------------------------------------------------1 2.1 Introduction-------------------------------------------------------------------------------------2 2.2 Problem Specification-------------------------------------------------------------------------2 2.3 System Requirements------------------------------------------------------------------------- 2 2.3.1 Functional Requirements------------------------------------------------------------ 2 2.3.2 Non-Functional Requirements-------------------------------------------------------3 2.3.3 External Interface Requirements----------------------------------------------------3 3 SYSTEM DESIGN---------------------------------------------------------------------------------4 3.1 purpose and scope--------------------------------------------------------------------------- 4 3.2 Definition and acronyms------------------------------------------------------------------- 4 3.3 Design overview-----------------------------------------------------------------------------5 3.3.1 System Overview----------------------------------------------------------------------5 3.3.2 Assumptions and Dependencies-----------------------------------------------------5 3.3.3 Design issues---------------------------------------------------------------------------5 3.3.3.1. Designing and developing of expert system ------------------------------5 3.3.3.2. Structure diagram of PC Troubleshooting Expert------------------------6 3.3.3.3. Development Diagram of PC Troubleshooting Expert------------------7 3.3.3.4. Features of PC Troubleshooting Expert----------------------------------- 9 3.3.3.5. Design issues related to Knowledge Base---------------------------------11 3.3.3.6. Design issues related to Inference Engine--------------------------------14 3.3.3.6.1. Forward Chaining------------------------------------------------16 3.3.3.6.2. Backward Chaining----------------------------------------------17 3.3.3.6.3. How to choose? --------------------------------------------------18 3.3.3.7. Design issues related to Explanation Subsystem------------------------ 18 3.3.3.7.1. Answering WHY? ---------------------------------------------- 18 3.3.3.7.2. Asking questions-------------------------------------------------19 3.4 Detailed System Design---------------------------------------------------------------------20 3.4.1 Data Flow Diagram (Level 1) ------------------------------------------------------20 3.4.2 Data Flow Diagram (Level 2) ------------------------------------------------------21 3.4.3 Data Flow Diagram (Level 3) ------------------------------------------------------22 4 IMPLEMENTATION----------------------------------------------------------------------------- 15 4.1 Introduction-----------------------------------------------------------------------------------15 4.2 Development tools used-------------------------------------------------------------------- 15 4.3 Implementation Issues---------------------------------------------------------------------- 24 4.3.1. Chapter 1(Knowledge Base) ------------------------------------------------------- 25 4.3.2 Chapter 2(Inference Engine and Explanation Subsystem) ----------------------30 5 SYSTEM TESTING-------------------------------------------------------------------------------- 34 5.1 Introduction------------------------------------------------------------------------------------34 5.2 Testing Methods------------------------------------------------------------------------------ 35 6 CONCLUSION------------------------------------------------------------------------------------- 37 7 APPENDIX------------------------------------------------------------------------------------------38 8 REFERENCES--------------------------------------------------------------------------------------39 1 2

1. INTRODUCTION

PC Troubleshooting Expert is a full- featured stand alone software application. The term stand alone means that the software can be installed anywhere without any difficulty. There is no need of network for using this software. The system is based on the concepts of Expert System which comes under the area of Artificial Intelligence. It has got very user friendly interface where user is required to press only 3 keys (y, n and w). The next section gives a detailed description about System analysis done for this project. That gives a view about the various requirements for this project, followed by system design section. That gives a view about the design methods accepted for this project. The chapter implementation gives a view about the implementation techniques adopted for this project. Since we (I and Vishal Kumar) have done this project as a group, we have divided this implementation into two sections. I have done the section on the implementation of the knowledge Base. Vishal has done the section for implementing the Inference Engine and Explana tion Subsystem of PC troubleshooting Expert.

2. SYSTEM ANALYSIS

2.1 Introduction
Analysis is a detailed study of the various operations performed by a system and their relationships within and outside the system. This section studies the system to be developed in detail. A proper analysis helps to design our problem properly with the functional requirements, input and output.

2.2 Problem Definition:

The goal of PC Troubleshooting Expert is to help users troubleshoot and solve their commonly occurring computer (hardware as well as software) problems.

Input: A number of problem categories will be presented before the users to select their choices. Output: A description of what the problem the user is having. The current thinking about what the problem the user is having and what the problem might be. PC Troubleshooting Expert is designed to help computer users who face computer related problems in their daily life. The system focuses on commonly occurring problems. Its promises to incorporate both hardware as well as software related problems.

2.3 System Requirements

2.3.1 Functional Requirements

1) Adding new conditions as well rules based on these condition. 2) Save user response into internal fact database for inferencing. 3) Provide explanation facility to the user. 4) Explanation system provides explanation in well formatted manner. 5) Interface component provides an interface for the user to interact with the system. 6) Provides meaningful suggestion for the diagnosed problem. 7) Uses backward chaining mechanism for getting the meaningful information out the knowledgebase. 8) Keep track of inference procedure so that can be used for explanation subsystem.

2.3.2 Non-Functional Requirements

2.3.2.1 System-Related Non-Functional Requirements

1 Hardware requirements The minimum requirements will be as follows 64 MB RAM Processor with speed 500MHz

2 Software requirements Windows OS (Windows 95/98/NT/2000/XP)

3 Modifiability and extensibility

Addition of further functionalities is possible. Since the software is delivered along with source code, it is easily modifiable. New rules can be added into the existing knowledge base.

Portability The system will run on Windows platforms.

2.3.3 External Interface Requirements

1 User Interfaces The user interface is a window which takes the user response from the keyboard.

3. SYSTEM DESIGN
3.1 Purpose and scope of the document
This section outlines the expected contents of the system. The deliverable document from the System Design process will include a set of technical specifications that will be used to generate (build) and implement the new system. The System Design Document must be complete and in sufficient detail to allow a technical resource unfamiliar with the project to be able to construct the system based solely on this document and materials referenced herein.

3.2 Definitions and acronyms

AI- Artificial Intelligence ES- Expert System KB- Knowledge Base IE- Inference Engine UI- User Interface.

3.3 Design Overview

3.3.1 System Overview PC troubleshooting Expert is designed to help users solving their computer related problems. The system asks questions and makes inferences from those to diagnose the actual problem and it finally suggests the appropriate solution to that problem. Users: Anyone who uses computers.

3.3.2 Assumptions and dependencies

1. The user has basic knowledge of computer terminologies. 2. The user has windows environment.

3.3.3 Design issues

3.3.3.1. Designing and developing of expert system From the studies, there are several procedures involved in designing and developing cycle of PC Troubleshooting expert system.

1. Studying and identifying computer problem and solution 2. Knowledge acquisition and document structuring. 3. Selection of Development tool 4. Development of Rapid prototype. 5. Refinement and generalization. 6. Maintenance and updating.

3.3.3.2 Structure diagram of PC Troubleshooting Expert

User Interface PC Troubleshooting Knowledge Base

User

PC Troubleshooting Inference Engine

Explanation Subsystem

Language/Shell Environment Figure 1 The structural diagram of PC Troubleshooting Expert is shown above (Figure 1). The various system components have different roles to perform. The major components are----Knowledge base -- A declarative representation of the expertise, often framed in IF THEN rules. Knowledge base may also constitute the working storage section which contains the data which is specific to a problems being solved. Inference engine -- The code at the core of the system which derives recommendations from the rules and facts information stored in the knowledge base User Interface The code that controls the dialog between the user and the system. Explanation Subsystem A structural component of the expert system which provides explanation to the user queries. User The individual who will be consulting with the system to get advice which would

have been provided by the expert. Shell the software which contains the user interface, a format for declarative knowledge in the knowledge base, and an inference engine. Shells can also be custom developed for particular applications. 3.3.3.3. Development Diagram of PC Troubleshooting Expert Problem Identification

Problem statement and description

No Can Expert System be justified? Yes No Can Domain Experts be identified and utilized Yes Establish plans for implementation monitoring and maintenance Prototype development Use alternative approach to knowledge acquisition Use another approach

Knowledge acquisition

Knowledge representation

Prototype validation

Prototype development complete? Yes Implementation

No

Figure 2 The development diagram (figure 2) for the system shows the general procedure adopted for building expert systems. The first step is the problem identification in which the expert system will be focusing on. A domain in which expert knowledge can be applied for solving or arriving at decisions is selected. The PC troubleshooting expert system is a diagnostic system, which uses expert knowledge about commonly occurring hardware and software problems to suggest the solution to the user. The problem statement and description is specified so as to make it clear. The expert systems are made use of in areas where the advise and work of experts in a particular domain are hard to get and expensive also. Moreover, the knowledge about the domain should be represented in the required format, which enables decision making and problem solving. If this is not possible, then some other options for building systems have to be considered. Once the decision for developing an expert system is made, the knowledge acquisition process starts. The required knowledge has to be obtained from a domain expert in most of the cases. Domain expert is the individual or individuals who currently are experts solving the problems the system is intended to solve. In case the help of domain experts are not got, then other options of obtaining knowledge like text books, internet repository etc. have to be considered. The next step is the development of a prototype. Rapid prototyping is largely followed for developing expert systems. The strategy is more dependable since much

flexible and powerful system can be built over time. Along with this, the task of knowledge acquisition and representation of knowledge in the proper format is started. This should be done in such a way that decisions or inferences can be obtained from such knowledge representation. The prototype is validated to check whether it conforms to the requirements. If the prototype is complete in all respects, including user friendliness, responsiveness in real time applications, compactness, rich and exhaustive knowledge base etc, then the next stage of implementation starts. Plans for implementation monitoring, maintenance are established.

3.3.3.4. Features of PC Troubleshooting Expert

PC Troubleshooting Expert

Provides information about the problem area anytime Asks the area where user is having problem. Can abandon the hypothesis and chose new ones based on the answers given by the users to its question

Can tell users why it needs the answer to a particular question.

Presents the solution together with a summary of the reasons it has for reaching those conditions

Looks for inconsistencies in the users answers, points them out and allows the user to change both new and the old.

Figure 3

Features diagram (Figure 3) of PC Troubleshooting Expert is given above. The features diagram, as the name implies shows the features present in the expert system. The expert system developed is used for giving suggestions regarding commonly occurring hardware and software problems. So the system is developed in such a way that it asks the user response in each step before progressing to new steps. So it finds out from the user, the problem area the user is in.

The expert system has a simple user interface. The system has explanation capability for Why. The explanation is presented in a user understandable way. From the system, the user knows about the problem area. Another important feature is the backtracking feature. If the user feels he is not in correct problem area, the system provides backtracking to some other relevant area according to the rules written for it.

The system also looks for inconsistencies in user response. It does this by making user of an internal stack for saving the user response. There can be positive and negative conditions that are to be satisfied for a rule to fire. If the positive conditions are already asked, the user need not answer those questions again. Again inconsistencies do not arise from the user since the system does not ask negative conditions for a positive condition already answered.

10

3.3.3.5 Design issues related to Knowledge Base

Expert systems are AI programs that achieve expert- level competence in solving problems in task areas by bringing to bear a body of knowledge about specific tasks. These programs' knowledge base contains the knowledge used by human experts. Every expert system consists of two principal parts: the knowledge base; and the inference engine. The knowledge base contains the factual knowledge of the domain in which the expert system is deve loped.

Knowledge based Techniques

Concentrate on making use of all available knowledge. Goal is to emulate the reasoning of an expert. System takes the role of an expert.

Knowledge representation formalizes and organizes the knowledge. It is a sort of data structure in which the knowledge can be stored. Developing an expert system involves tasks such as acquiring knowledge from an acknowledged domain expert, documenting it and organizing it, generating knowledge net to check the relationships between different knowledge sources, checking for consistency in the knowledge and finally transforming the knowledge net into a computer program using appropriate tools. Such a program, called an expert system, is a formal system for storing facts and their relationships and the strategies for using them. In general, an expert system has knowledge about physical objects, relationships among them, events, relationships among events, and relationships between objects and events. In addition, required types of search mechanisms must be represented to drive the system. Depending on the type of problems, other types of knowledge, such as time relationships, uncertainty levels of facts and assertions, performance levels, different

11

situations, assumptions, justifications, knowledge about knowledge, additional explanations on facts and relationships etc., have to be represented. It points to the fact that formalization of knowledge and problem-solving strategies forms a major part in expert systems development. The same piece of knowledge can be represented using more than one formal scheme, but with varying degrees of difficulty. The difficulty is not in the representation of the knowledge, but in its usage. The decision on selection of a scheme primarily depends on the type of application being built. Also, different knowledge representation schemes can be adopted for developing one application. The knowledge engineer has to decide which

portion of the knowledge should be represented in what form, depending on the nature of the knowledge and the efficiency of its use. The most common methods of knowledge representation are Predicate logic Production rules Frames (objects) and semantic networks Conventional programs

Procedural programs Engineering problem solving involves numerical computations, in addition to inference using knowledge. In a real- life expert system, the system has to perform numerical computations at different stages of the solution process. The amount of computations may be very small in some cases and quite large in many cases. Based on the values inferred, a detailed analysis of the artifact may have to be carried out to evaluate the correctness of the parameters arrived at. The quantitative knowledge required for such computations can be represented as functions/programs written in high- level programming languages such as C. An expert system should be able to call these programs as and when required during problem solving. Hence, they also form part of the knowledge base of the expert system. Most expert system development shells provide facilities to represent knowledge in the three forms. Viz., rules, frames and functions in procedural languages. The predicate logic form of knowledge representation is the natural form in Prolog. Prolog provides predicate logic based representation with backtracking inference, which is inadequate for developing large expert systems for practical application.

12

An expert system should be able to call these programs as and when required during problem solving. Hence, they also form part of the knowledge base of the expert system.

Production rules Production rules are simple but powerful forms of knowledge representation providing the flexibility of combining declarative and procedural representation for using them in a unified form. A production rule has a set of antecedents and asset of consequents. The antecedents specify a set of conditions and the consequents a set of actions. Typically a knowledge base will consist of a large number of rules. Logically the rules can be grouped into different rule bases. It is a common practice in the development of expert systems to logically divide the rules into smaller rule bases and to control from a higher- level rule base, which has knowledge about the different rule bases in the knowledge base. If there are more than one rule bases, each of them should have separate contexts. The higher- level rule base having meta rules will control the overall inference process and will have a global context. The inference engine of the expert system shell should properly handle different contexts for proper solution of the problem.

The representation followed in the development of the proposed system is the production rule, or simply rule. A rule consists of an IF part and a THEN part. The IF part lists a set of conditions in some logical combination. The piece of knowledge represented by the production rule is relevant to the line of reasoning being developed if the IF part of the rule is satisfied, consequently, the THEN part can be concluded, or its problem-solving action taken. The power of an expert system lies in its store of knowledge about the task domain-the more knowledge a system is give, the more powerful it becomes. Knowledge acquisition is the task of endowing expert systems with knowledge.

The domain of the "PC Troubleshooting Expert" is the troubleshooting of commonly occurring PC problems. The domain knowledge includes information about hardware and software problems. More precisely, the hardware problems include system component

13

problems, booting problems and problems associated with POST (power on self test). The software problems include general problems related to OS crashes, and error messages. The knowledge acquisition is being done mainly from textbooks, and Internet resources and interviews with experts in troubleshooting commonly occurring hardware and software problems. The problem-solving model, or paradigm, organizes and controls the steps taken to solve the problem. One common but powerful paradigm involved chaining of IF-THEN rules to form a line of reasoning. In our system, which is a diagnostic one, chaining starts from a set of conditions and moves toward some conclusion or recommendation about the problem the user is having. The chaining method will be implemented in the inference engine module and this makes use of the knowledge in the knowledge base to form a line of reasoning. Explanation module takes care of explanations given to the user. Explanations will be generated by tracing the line of reasoning used by the inference engine.

3.3.3.6 Design issues related to Inference Engine

1. General problem-solving knowledge or methods 2. Interpreter analyzes and processes the rules 3. Scheduler determines which rule to look at next 4. The search portion of a rule-based system 5. Takes advantage of heuristic information 6. Otherwise, the time to solve a problem could become prohibitively long 7. This problem is called the combinatorial explosion 8. Expert-system shell provides customizable inference engine The real forte of expert systems is their capacity to make inferences or the drawing of conclusions from premises (Figure 4). This is precisely what makes an expert system intelligent. Even when it is possible to represent domain knowledge as rules, a human expert would not only have to know how to apply these rules but in which order they should be applied to solve a particular problem. Similarly, a computer expert system would need to

14

decide which, and in what order, the rules should be selected for evaluation. To do this, an expert system uses an inference engine. This is a program that interprets the rules in the knowledge base in order to draw conclusions. Two alternative strategies are available: backward chaining and forward chaining . A particular inference engine may adopt either or both.

Figure 4 A backward chaining inference engine is 'goal-orientated' in the sense that it tries to prove a goal or rule conclusion by confirming the truth of all of its premises. Thus, to prove the conclusion of the rule above, PC Troubleshooting Expert is a diagnostic Expert system which is supposed to work backward by attempting to prove each premise., These premises may themselves be conclusions of other rules, in which case PC Troubleshooting Expert would then try to confirm the premises of whatever rule it is the conclusion of, or the values of these premises may be data supplied by the user. In this way, a chain of inference steps will lead to a value for the goal being found. By contrast, a forward chaining inference engine starts from the other end. It examines the current state of the knowledge base and, finds those rules whose premises can be satisfied from known given data, and adds the conclusions of those rules to the knowledge base. It then re-examines the complete knowledge base and repeats the process, which can now progress further since new

15

information has been added. Both the backward and forward inference process will consist of a chain of steps that can be traced by the expert system. This enables expert systems to explain their reasoning processes. 3.3.3.6.1. Forward Chaining : 1. Forward chaining (Figure 5) is a data driven reasoning. The reasoning starts from a known data and proceeds forward with that data .Each time only the topmost rule is executed. When fired the rule adds a new fact into the database .Any rule can be executed only once. The match- fire cycle stops when no further rule can be fired. 2. Forward chaining is a technique for gathering information and then inferring from it whatever can be inferred. 3. However, in forward chaining, many rules may be executed that have nothing to do with the established goal. 4. Therefore, if our goal is to infer only one particular fact, then forward chaining technique wont be efficient.

Figure 5

Given some facts, work forward through inference net. Discovers what conclusions can be derived from data. If more than one rule matches
o o

may fire all rules and simulate parallel machine may select only one rule

16

loop match rules if no rule matched then stop resolve conflicts act end loop

3.3.3.6.2. Backward chaining : 1. Backward chaining (Figure 6) is a goal driven reasoning .In backward chaining , an expert system has the goal ( a hypothetical solution)and the inference engine attempts to find the evidence to prove this .First the knowledgebase is searched to find rules that might have the desired solution .Such rules must have the goal in their THEN (action) parts. If such a rule is found and its IF (condition) part matches data in the database, then the rule is fired then rule is fired and goal is proved .However, this is rarely the case.

2. Thus the inference puts aside the rule it is working with (the rule is said to stack ) and sets up a new goal, a sub goal ,to prove the IF part of this rule .Then the knowledge base is searched again for rules that can prove the sub goal. The inference engine repeats the process of stacking the rules until no rules are found in the knowledge base to prove the current sub goal.

17

Figure 6 3.3.3.6.3. How to choose?? If the Expert System needs to gather some information and then tries to infer from it whatever can be inferred, choose the forward reasoning. However Expert System begins with hypothetical solution and then attempts to find facts to prove it choose the backward chaining inference engine.

3.3.3.7. Design issues related to Explanation Subsystem

Expert systems seek to make problem solving knowledge explicit. The knowledge applied to a problem must be available to the user. The system must be able to explain how it arrived to a conclusion and why it is performing some computation.

It may also be required answer what if questions

18

3.3.3.7.1. Answering WHY?

Figure 7

To answer why a computation is being performed, the system must state its current goal. (Figure 7)

The system may ask the user if fact 3 is true because it is trying to determine if decision 1 should be made.

3.3.3.7.2 Asking Questions:-

Figure 8

The order in which questions are asked is important. Some questions can quickly eliminate unnecessary computation (and further questions). (Figure 8)

19

3.4 Detailed System Design

3.4.1 Data Flow diagram (Level 1)

D1

Rule base Obtain

D2

Fact base Save

1.1 Inference Engine Make inference

User Interface

Displays Uses User 1.2 Explanation Subsystem Explain

Figure 9

20

3.4.2. Data Flow diagra m (Level 2)

D1

Rule base Obtain

1.1 Inference Engine Make inference

D1

Rule base

Obtain

1.1.2 Examine goal

1.1.3 Give suggestion

1.1.4 Match rule (goal)

Yes 1.1.6 Stop checking No

1.1.5 Check condition

1.1.7 D1 Rule base Obtain Ask user

D2

Fact base

Save

1.1.8 Process Answer

1.2 Explanation Subsystem Explain

Figure 10

21

3.4.3. Data Flow diagram (Level 3)

Obtain D2 Fact base 1.2 Explanation Subsystem Explain User Interface

1.2.1

Query Ask User

1.2.3

Display Key error

No

1.2.2

Read Key read W

1.2.5

Display 1.2.4 Examine goal

Show condition 1.2.6 Display Display Rule

1.2.7 Report Generate Report Obtain D2 Fact base D2 Obtain Fact base

Figure 11

22

4. IMPLEMENTATION
4.1 Introduction
The implementation phase translates a detailed design representation of the problem into programming language realization. The following section describes the software used for development, coding standards and the practical issues involved in implementing the software.

4.2 Development Tool(s) used

Visual Prolog 5.2 Personal Edition Prolog is a programming language for symbolic, non- numeric computation. It is especially well suited for solving problems that involve objects and relations between objects. Prolog programming consists of defining relations and querying about relations. A relation can be specified by facts, or by stating rules about the relation. In Prolog, to establish whether an object satisfies a query is often a complicated process that involves logical inference, exploring among alternatives and possibly backtracking. All this is done automatically by the Prolog system and is, in principle, hidden from the user. A Prolog program consists of clauses. Questions to the system consist of one or more goals. Prolog accepts questions as goals that are to be satisfied. An answer to a question can be either positive or negative, depending on whether the corresponding goal can be satisfied or not. In the case of a positive answer we say that the corresponding goal was satisfiable and that the goal succeeded. Otherwise the goal was unsatisfiable and it failed. Various implementations of Prolog use different syntactic conventions. However, most of them now largely comply with the ISO international standard for Prolog ISO/IEC 13211-1. The syntax of Visual Prolog is designed to express knowledge about properties and relationships. Visual Prolog is a typed Prolog compiler; you declare the types of the objects that each predicate applies to. The type declarations allow Visual Prolog programs to be compiled right down to native machine code, giving execution speeds similar to those of compiled C and Pascal. Generally, a Visual Prolog program includes four basic program sections. These are the clauses section, the predicates section, the domains section, and the goal section. The 23

clauses section is the heart of a Visual Prolog program; this is where the facts and rules that Visual Prolog will operate on when trying to satisfy the program's goal. The predicates section is where predicates and the domains (types) of the arguments to predicates are declared. The domains section is where any domains used in the program that aren't Visual Prolog's standard domains are declared The goal section is where the starting goal for a Visual Prolog program is put. The visual Prolog environment offers a platform for developing stand-alone as well as web based applications. For developing web based applications, ESTA component that comes along with Visual Prolog (Commercial Edition) is used. Visual Prolog can be used to develop custom applications. The software can be used to develop graphical user interfaces according to the application being developed. Another mode in Visual Prolog is a window mode called Easy Win. This mode can be used to develop simple user interfaces. This does not support menus, options or buttons. Programming can be done so as to get user response as required by the program.

4.3. Implementation issues

4.3.1. Chapter 1 (Knowledge base Implementation issues):The main issues related in the implementation of PC Troubleshooting Expert as the knowledge base part is concerned will be [i] Represent the domain knowledge internally [ii] Search procedures for working with the internally stored knowledge [iii] Inference mechanisms for deducing solutions to problems from stored knowledge.

The major concerns deal with how to represent the facts and rules within the Knowledge base to: [i] Provide a format compatible with the computers. [ii] Maintain as close as possible a correspondence between this format and the actual facts and rules (the rules as seen by the domain expert). [iii] Establish a representation that can be easily addressed, retrieved, modified and updated.

24

The most popular mode of knowledge representation within expert systems is the mode obtained through the use of rules, or rule based systems. We have selected this approach to knowledge representation for a number of reasons, including their popularity and widespread use. Rules also represent a particularly natural mode of knowledge representation. Consequently, the time required to learn how to develop rule bases is minimized. It also takes less time to learn how to use and implement rule-based expert systems. Rule bases can be relatively easily modified. In particular, additions,

deletions and revisions to rule bases are relatively straightforward processes in the case of well designed rule bases. Validation of the content of rule-based systems i.e. the determination of the completeness and consistency of the representations is a relatively simple process. The representation of knowledge is important for credibility and acceptance by the user. The questions asked and the rules examined should be in the same sequence as used by the human expert. The granularity and structure of the concepts, including how the concepts relate into a logical flow, are coordinated in making recommendations. During implementation phase, the formalized knowledge is mapped or coded into the framework of the development tool to build a working prototype. The contents of knowledge structures, inference rules and control strategies established are organized into suitable format. Modifications to the knowledge base over time are also anticipated. The knowledge base is also documented as it is coded. The potential for later misunderstanding and confusion is thus minimized wherever possible. The end-user should understand the questions posed to them by the program, so the question statements are made simple enough for that. Furthermore, explanations given to the user as the output is also simple and to the point so that the user can effectively use the program output to troubleshoot the problem. Commonly occurring hardware and software problems have been formulated as the knowledge base. The hardware problems contain instances of CPU, RAM, CD/DVD, hard disk drives, controllers, video, sound and printer. Knowledge about the booting problems is also coded to the knowledge base. These are selected since; the normal user runs into problems with the hardware components. And for the commonly occurring software

25

problems, there are instances of UNIX problems and problems on windows run time errors. The knowledge base has 300 rules and over 400 conditions. The rules are added using a rule predicate. The predicate has arguments two strings and a list of conditions. Also included is an integer to keep track of the rule number. The strings include the main goal and the sub goal to be satisfied. A goal is said to be satisfied if the conditions are met. So for the main goal to be true, each of the condition in the list has to be satisfied. After the main goal is evaluated, the sub goal may be evaluated and this process will eventually lead to a solution when no more rules based on the sub goals are framed. Another predicate used for the implementation is the condition predicate. This takes as input a condition string. The condition string is also asked to the user through the user interface when the program is run. Also a condition number is associated with each of the condition strings. The condition number is given as one argument to the rule predicate according to the need to fire a rule. Apart from these, the program also maintains an internal fact database. The fact database contains yes and no lists in the program memory. So if a condition is satisfied, then the condition number is added to the yes list to make sure that it is satisfied and a rule arising out of that condition will be fired. In case if the program gets a negative response from the user for a particular condition, then that condition number is added to the no fact base. For rules depending on the negative conditions, the no base is checked and if the condition number is present, that means the condition is satisfied. Then the rule to be fired is selected from the rule base. Rules are formulated in such a manner that that all conditions are taken into consideration and all possible control flow is anticipated.

26

Example Flow chart for Network hardware diagnostics

27

The material depicting knowledge may be in diagrammatic form as given above or in textual form. The next step is to identify conditions from the text in such a manner that the conditions chosen will finally lead the user to some solution. So that concern is there for framing rules in which some of the conditions need to be satisfied.

e.g. Some cond itions framed from the flowchart above condition(1049, "Have network problems?"). condition(1050, "PC sees other n/w units"). condition(1051, "new hub is added to LAN"). condition(1052, "Random problems"). condition(1053, "Link light is lit in hub"). condition(1054, "user has copied n/w configuration").

condition(1079, "not Have network problems?"). condition(1080, "not PC sees other n/w units"). condition(1081, "not new hub is added to LAN"). condition(1082, "not Random problems").

e.g. Some rules framed from the flowchart given above. rule(1199, "U r in network Troubleshooting area", "PC tracks other n/w units", [1049]). rule(1200, "PC tracks other n/w units", "confirm Random problems", [1050]). rule(1201, "PC tracks other n/w units", "examine hub", [1080]). rule(1202, "confirm Random problems", "check cable", [1052]). rule(1203, "examine hub", "user please check crossover port wiring.", [1051]). rule(1204, "examine hub", "view link light ", [1081]).

rule(1205, "view link light", "check n/w configuration", [1053]). rule(1206, "check n/w configuration", "Reboot: improper s/w configuration or bad n/w adaptor", [1054]).

28

4.3.2. Chapter 2 (Inference Engine and Explanation Subsystem implementation issues):--

Implemented using Visual Prolog 5.2 Personal Edition. Using Prologs backward chaining inference engine facility. Since PC Troubleshooting Expert is a diagnostic system; it has implemented using backward chaining inference mechanism.

The data structure used is list. The conditions required by a rule to fire are kept in the list. Another important feature which has been used during implementation is cut feature of Prolog. Prolog has a built- in backtracking mechanism which is not suitable for every case. In case of PC Troubleshooting Expert predicates are mutually exclusive and there in no need to check other if one is true. Hence the cut denoted by ! has been used throughout the program to reduce the unnecessary checking done by Prolog. This hasnt affected the output but certainly reduced the time complexity of the program. Main predicates used for implementation of PC Troubleshooting Expert: ---nondeterm examine( ) The execution of inference engine starts with goal section of the program (this is the way Prolog programs execute).The keyword nondeterm is used because more than 1 answers may be possible for that particular question. The predicate examine ( ) examines the goal by searching it in rules which are present in knowledge base. rule( ) This predicates is used for checking the rule which are present in knowledge base. check( ) This predicate is used for checking the various conditions required by rule to be true.

29

There are 5 different check predicates with different arguments. Two of them deal with the condition which have already been answered and are in facts database at present. These predicates check the truth or fallacy of conditions by simply checking the Yes/No status in the fact database. Next two check predicates deal with negatively formulated conditions. The logic behind formulating the negative condition is pretty straightforward. This has been done to overcome the problem of inconsistencies of user answers/responses. User is been asked only the positively formulated condition and the check predicate automatically saves the yes/No information for the corresponding negatively formulated condition. The last check predicate comes into play when the condition hasnt been answered. Then it calls another predicate askUser( ) ,which asks user that condition. askUser( ) This predicate is used to ask the condition to the user. Then it calls another predicate called processAnswer( ).The predicate askUser( ) is a hull and the predicate processAnswer( ) is the core part. processAnswer( ) This predicates does the processing on the user response. Processing includes the saving of user responses into the internal database. The Prolog function assert is used to save into the facts database. If user response is Y then the corresponding condition no. is saved into the YES fact database whereas when the user response in N then the corresponding condition no. is saved into the NO fact database. When user response is W then processAnswer( ) does the explanation job and finally if user response is other than Y, N and W then it generates error message for the user. showRule( )

30

This predicate is the part of Explanation Subsystem. It displays the rule when user response is W. It tells user that which rule requires the condition which has been asked to the user. showCondition( ) This predicate is user for displaying the condition(s) required for a rule to fire. The predicate also uses some string manipulation functions like concat, str_int etc for displaying the result in a well formatted manner. report( ) This predicate is used for generating a report for the rules which have been fired by that time. Its displays the detailed information how those rules have been fired, by mentioning/displaying conditions required by them to fire. Following is one of the predicates from the source code which gives the clear idea about how the predicates and clauses have been written for PC Troubleshooting Expert:-% Answering user 'why' questions and displaying them good formated processAnswer(HistoryTree, RuleNum, Text, CondNum, 'w') :!, write("Why\n"), rule(RuleNum, StartGoal, SubGoal, _), !, subCat(StartGoal, Subgoal, String1), concat("I am trying to prove that ", String1, String2), concat(String2, "\nBy using rule number ", String3), 31

str_int(RuleNumAsString, RuleNum), % Convert integer to string. concat(String3, RuleNumAsString, Answer1), showRule(RuleNum, String4), concat(Answer1, String4, Answer2), report(HistoryTree, Output), concat(Answer2, Output, Answer3), write(Answer3), nl, askUser(HistoryTree, RuleNum, CondNum, Text).

Above predicate has been written for the Explanation subsystem which uses string manipulation functions of Prolog to display the explanation in a well formatted manner. Other predicates /clauses have been written in similar manner .The above code is the implementation in Visual Prolog 5.2 which is not compatible with other versions of Prolog.

32

5. SYTEM TESTING 5.1 Introduction

Testing involves considerably more than finding and fixing syntax errors. It covers the verification of individual relationships, validation of program performance and evaluation of the utility of the software package. Testing guides reformulation of concepts, redesign of representations and other refinements. Verification and validation must occur during the entire development process. Verification proves that the models within the program are true relationships. It ensures that the knowledge is accurately mimicked by having the domain expert operate the program for all possible contingencies. An effective validation procedure is critical to the success and acceptance of the program. During validation the following areas are of concern: (1) correctness, consistency and completeness of the rules; (2) ability of the control strategy to consider information in the order that corresponds to the problem solving process; (3) appropriateness of information about how conclusions are reached and why certain information is required; and most critical, (4) agreement of the computer program output with the domain expert's corresponding solutions. How the sequence of questions and output are presented to the end-user may have as much to do with acceptance and use as does the accuracy of the recommendations. The lessons learned from human engineering cannot be ignored if the program is to be successful. Validation is an ongoing process requiring the output recommendations be accurate for a specific user's case. Validation is enhanced by allowing others to review critically and recommend improvements. A formal project evaluation is helpful to establish whether the system meets the intended original goal. The evaluation process focuses on uncovering problems with the credibility, acceptability and utility. This can be determined from the program accuracy that is determined from comparisons with the real- world environment. Included are the understanding and flexibility of the program, ease of use, adaptability of the design and the correctness of solutions.

33

5.2. Process of System Testing

The process of system testing can be classified into 1 Static testing 2 Unit testing 3 Module testing 4 System testing 5 Acceptance testing

Static Testing : Static testing is any testing of a piece of software which can be done without actually executing that piece of software. Structured walkthrough and inspections were carried out as part of static testing Unit testing : This involves testing unit pieces of code as functions, sub-programs, queries etc. This was carried out both during development and testing phase Module testing : A module is a collection of dependent components such as some looser collection of procedures and functions. PC troubleshooting Expert has modules like Inference Engine and Explanation Subsystem which have been tested separately. System testing : The sub-system is integrated to make up the entire system. The testing process is concentrated with finding errors, which result from unanticipated interaction between sub-systems and system components. It is also concerned with validating that the system meets its functional and non- functional requirements. Acceptance testing : This is the final stage in the testing process before the system is accepted for operational use. Testing conducted to enable the user to determine whether to accept a
software product. Normally performed to validate the software meets a set of agreed acceptance criteria. This was carried out through co-operation from the main users of the system. Acceptance

testing may reveal requirements problems where the systems facilities do not really meets the users needs or the system performance is unacceptable.

5.3 Testing Methods Black Box Testing

34

Also known as functional testing. Black-box testing is the testing of a piece of software without regard to its underlying implementation. For example, in a black box test on software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. Specifically, it dictates that test cases for a piece of software are to be generated based solely on an examination of the specification (external description) for that piece of software. The goal of black-box testing is to demonstrate that the software being tested does adhere to its external specification. The advantages of this type of testing include:

The test is unbiased because the designer and the tester are independent of each other. The tester does not need knowledge of any specific programming languages. The test is done from the point of view of the user, not the designer. Test cases can be designed as soon as the specifications are complete.

White Box Testing

Also known as glass box , structural, clear box and open box testing. White-box testing is the testing of the underlying implementation of a piece of software (e.g., source code) without regard to the specification (external description) for that piece of software. The goal of white-box testing of source code is to identify such items as (unintentio nal) infinite loops, paths through the code which should be allowed, but which cannot be executed and dead (unreachable) code. White-box testing was carried out by code walkthroughs. Basic path testing was also carried out, i.e. test-cases were written so that all the control- flow statements were made to execute at least once, tracing a path through the process.

Testing Method Used

We have adopted a testing method, which is a mix of both white box and black box testing. For the units we have adopted white box testing. Then we integrated the units into modules and further into the system. There we adopted black box testing for checking the correctness of the system

35

6. CONCLUSION

PC Troubleshooting Expert is a stand alone Expert System which helps computer users to troubleshoot their commonly occurring computer problems (hardware as well as software). This software interacts with the user and allows them to know the solution to the problem they are having with their computer(s). This software works on a basic assumption that the user is aware of basic computer terminologies and will be able to understand and answer the questions which will be asked to them. We have tested the performance of our system for various different cases of problems like booting problems, CD/DVD related problems, Printer related problems etc and got satisfactory response from the system. PC Troubleshooting Expert is a rule based expert system and its efficiency solely depends on the fact that how much knowledge its having in its knowledge base. The system can be made more and more useful by simply adding new rules and conditions required by those rules.

36

7. APPENDIX

Screen capture of PC Troubleshooting Expert (showing inference)

Screen capture of PC Troubleshooting Expert (showing explanation) 37

8. REFERENCES

[1] Bigelow, Stephen J,

Troubleshooting, Maintaining and Repairing PCs, Millennium Edition. Tata McGraw Hill Publications, 2000 [2] Bratko, Ivan Prolog Programming for Artificial Intelligence, 3rd Edition

Pearson Education, 2004 [3] Merritt, Dennis, Building Expert Systems in Prolog, Springer-Verlag, 1989 [4] Waterman, D.A. A Guide to Expert Systems, Addison-Wesley Publishing Co., Inc., Reading, MA, 1986. [5] Krishnamoorthy, C.S and Rajeev, S, Artificial Intelligence and Expert Systems for Engineers, CRC Press, 1996 [6] Somerville, Ian. Software Engineering . Sixth Edition, Pearson Education Ltd, 2002. [7] http://cipm.ncsu.edu/ent/vetent/expert.html [8] www.homepage.ntlworld.com/peterhi/sie.html [9] www.amzi.com/ExpertSystemsInProlog/xsipfrtop.htm [10] www.es229doo.ee.meemphis.edu/paper/faculty/russonanno/RDFS projects.htm

38