Computersind.EngngVol.29, No. 1-4,pp. 14%151,1995
Copyright© 1995ElsevierScienceLtd Printedin GreatBritain.All rightsreserved 0360-8352/95 $9.50+ 0.00
Pergamon 0360-8352(95)00062-3
A KNOWLEDGE-BASED SYSTEM FOR FAULT DIAGNOSIS AND MAINTENANCE OF ADVANCED AUTOMATED SYSTEMS t Sanjiv A. Patel a, Ali K. Kamrani, Ph.D. b, Elsayed Orady, Ph.D. b aManufacturing Systems Engineering Program blndustrial & Manufacturing Systems Engineering Department The University of Michigan-Dearborn Dearborn, MI 48128
ABSTRACT A knowledge-based system for diagnosis & maintenance of robotic systems has been designed which may also serve as a training tool for maintenance personnel. The system uses a Group Technology (GT) approach for fault classification and analysis. A simple user interface leads the user through a consultation phase in order to arrive at a diagnosis. It then recommends corrective actions and a simple test procedure to verify that the robot will perform satisfactorily after the repairs. INTRODUCTION As we are reaching the 21st century, the importance of robots in manufacturing sector is increasing. They are replacing humans where the operations are repetitive, such as in machine loading and unloading, or when there is a risk involved to the operator, such as in the welding or spray-painting operations. As the functional demand on robots increases, the complexity of the hardware also increases. Today's robots are equipped with complex sensors such as machine vision, tactile sensors, force sensors, etc. The hardwares and softwares associated with today's robots are also becoming more robust. But due to the increased complexity, it becomes difficult to correctly diagnose the failure of robotic systems, especially for a non-expert. The maintenance expert develops a heuristic diagnostic knowledge about the system by working with it over the years. Based on his/her past experience s/he develops a system of hunches which he unconsciously applies to solve the problem. This knowledge is usually highly unstructured. A knowledge engineer may work in close relation to the maintenance expert, conduct a series of interviews, or observe the expert how s/he solves the problem, and then represent the expert's diagnostic knowledge in a highly structured format using one of the representation techniques of Artificial Intelligence, such as frames, symbols, or production rules. Most of the diagnostic systems use production rules to represent the expertise in the form of "IF premise, THEN conclusion." MYCIN was the first seminal production rule based expert system which was used to diagnose the blood diseases caused by bacterial infection (Shortliffe76). Since MYCIN many diagnostic rule based systems have been developed (Genesereth82, Nilson84, Milacic87, Piety89. and Visinsky93). These systems usually focused on a narrow domain of diagnosis only. Very few diagnostic systems have been developed that address the actual need of the industry: integration of diagnosis & maintenance. The proposed system, ROBODOC, the diagnosis and maintenance consultant for industrial robots, is being developed with an intention of integrating the two. In addition, the structure of ROBODOC will permit it to be a generalized diagnostic system, and also to be interfaced to a maintenance management system. Such a system when interfaced to a robotic system on-line, will perform the tasks of on-line monitoring, diagnosis, maintenance, and management of maintenance (such as scheduling resources and planning for preventive maintenance). 1 This researchis funded by ResearchExcellence& EconomicDevelopmentFoundation(REEDF),Stateof Michigan. 147
148
17th International Conferenceon Computersand Industrial Engineering
ARTIFICIAL INTELLIGENCE & EXPERT SYSTEMS Artificial Intelligence (AI) is the study of computations that make it possible to perceive, reason, and act (Winston92). Expert System is one of the branches of AI. Expert Systems (ES) are programs that use human-like reasoning process, rather than conventional computational techniques to solve problems. An ES differs from conventional programs in that in ES there is a clear separation of knowledge into knowledge about the domain, meta knowledge (knowledge about the domain specific knowledge), and knowledge of how to use that knowledge in the current situation; where as in conventional programs the knowledge about the problem, and how to solve the problem is intermixed (Duda81). Hence, it becomes very difficult to change a conventional program, where as with ES, the program does not need to be updated with the change in system status, but only the knowledge base need to be updated, either by adding or removing the rules from it. An expert system has basically two parts : 1. Knowledge base (KB), and 2. Shell. The knowledge base typically contains several IF...THEN rules. Each rule specifies what to do, or what conclusion to draw, under a set of well-defined circumstances. The shell acts as a "receptacle" for the KB, and contains inference engine, user interface, explanation facility, knowledge acquisition facility, and working memory. Expert system shells are available from many vendors. To apply these shells to a particular problem, the developer simply has to add the domain specific knowledge in the form of rules and data. ROBODOC: THE DIAGNOSIS & MAINTENANCE CONSULTANT ROBODOC, the diagnosis & maintenance consultant for industrial robots, is a knowledge-based system being developed with an aim of developing a generalized diagnostic system, not specific to a particular piece of equipment. It will also verify the suitability of Group Technology (GT) approach for symptom and fault classification. Some of the long term objectives are to interface the system to a maintenance planning system, and to generate the knowledge-base for a Design for Service Expert System. Figure 1 illustrates the overview of the structure of the proposed intelligent diagnostic system. Figure 2 illustrate the impact of the current research on the way the diagnosis and maintenance has been traditionally done. In the present method, all the information from the sensors, controllers, display terminals, reports, etc. is provided to the user, or the expert, and s/he must analyze this information, compare the information with the previous experience, make inference about the fault, collect evidence to strengthen the preliminary inference, make a final diagnosis, schedule the resources, and carry out the actual repair work. Since a fault is usually hidden by the symptoms of other faults occurring simultaneously; for a non-expert it is difficult to arrive at a correct diagnosis. Usually an expert is either not available, or busy handling other tasks. Hence, if the diagnosis part is carried out by an intelligent system, which will also provide implementable recommendations, the task of the user is simplified. In many cases, the user will be able to correct the fault without the help of the maintenance expert. Patel & Kamrani have discussed a set of specifications which a diagnostic ES should ideally possess (Pate195a). Specifications for ROBODOC are outlined in Table 1 with comments on how each specification will be achieved (Pate195b). ROBODOC
- DESIGN
&
IMPLEMENTATION APPROACHES
The approaches taken in the design of ROBODOC can be divided into the following three categories:
17th International Conference on Computers and Industrial Engineering
149
......................................................
....................................j...............INTERFACE ............ Derived
EXPLANATION~ st~'sY3.~
USERINTERFACE
~/~ INFERENCI~ENGINE I P~'~i'= [ Reasoning i RulesofInferlm~
~'~ Knowledge DOMAINEXPERT[ ~..~ ~w,~
KNOWLEDGEBASE; Facts StaticParts
Rules Rules for Diqlmxtis
Cht~ficati~l Pules
Maintemnce Precedurm
Functionel Fltilul~ CriticalFailu~
F(~eactits~ ~'~Advice
TestPmcedu~
CalasU'oplli¢Failure
WORKING MEMORY
I i ProblemDmcriPtion
]
StruetundModels
I BettaviorelModels
I Manipulator I Controller I End-effe~or
[ I M°torFltilure I I ~,~F,il~
I
Figure 1 - STRUCTURE OF ROBODOC • ROBODOC Peripheral
[
Print: 1. Work Order, 2. Repmr Procedure, & 3. Test Pm~dure
?
Schedule resources ]
x~ [ performac~al repel
No
Make diagnosis & make maintenance recommndn.
q"
Consultation with L, ROBODOC ix
l] [1
Alarm "l"Chang(,"of behavior ~ Display Monitor System Malfunction
I1
Figure 2 - PROPOSED OFF-LINE DIAGNOSIS & MAINTENANCE SYSTEM Structure: The ROBODOC is a decision tree based system, which uses the shallow knowledge of the maintenance expert in the form oflF...THEN rules. The system itself does not use any IF...THEN rules, but instead uses FPTs to generate the decision tree. It has also the knowledge about the structure and behavior of the robotic system, and how the different components interact. This knowledge is acquired through dissection of the robotic system and simulation of various combination of faults and observing the behavior of the system. Search Strategy: The diagnostic part of the ES will require breadth-first search strategy, whereby it allows the user to select more than one options from the menu. This facilitates quick location and narrowing down of the search space for the problem at hand. Once a diagnosis is reached, the maintenance instructions to carry out the repairs and/or to avoid similar kind of failures in the future are provided using the depth-first search strategy. Inferencing Mechanism: ROBODOC uses forward chaining as the principal inferencing. But in cases where it can not converge to a particular solution, it will try to match the present failed situation to the
150
17th International Conference on Computers and Industrial Engineering
one from the database that most closely matches, and will base its hypothesis about the fault. Then it will ask the user a further set of questions to strengthen its belief in the hypothesis. If the user response weakens the hypothesis, the next best match is taken as a hypothesis, and is tested against the user inputs. The hypothesis testing requires backward chaining inferencing mechanism. Table
SYSTEM SPECIFICATIONS Identify abnormal conditions Avoid false alarms Provide DOC" for diagnosis Conclusions ranked by DOC" Handling of insufficient data
Handling of uncertain (unknown) situations
Generality Modification of the knowledge-base Self-testing Explanation of diagnosis reached Implementable maintenance recommendations User Interface
I
1 -
R O B O D O C SPECIFICATIONS ROBODOC COMMENT
L E V E L OF P E R F O R M A N C E Not required of an off-line diagnostic system such as ROBODOC. Not required of an off-line diagnostic system such as ROBODOC. It will be included as a part of the heuristic. It will be included as a part of the heuristic. The system will ask the user to provide the data. If data is not available, the system will not disintegrate; and will try to provide conclusion based on the available information. The heuristics of the program will take care of this situation. In the case of the non-convergence, the system should match the failure scenario to the one that most closely matches from the stored scenarios in the knowledge-base, and thus will try to reach to a solution to the problem. ADAPTABILITY Generality is one of the main objectives of the system. It is easy to modify the knowledge-base, without the need for an expert programmer. O T H E R FEATURES Not required of an off-line diagnostic system such as ROBODOC. This feature is to be included in the next version of the DCLASS software. The system will provide maintenance recommendations as and when necessary. The present interface is menu-driven, and easy to use. The next version of the DCLASS software will be window based and very easy to use. It is not the objective of the current research.
Maintenance Planning & Control Recommendations to improve It is not the objective of the current research. the design * Degree of Confidence
DCLASS: A GROUP T E C H N O L O G Y A P P R O A C H F O R DECISION C L A S S I F I C A T I O N DCLASS is selected as an ES development tool. The following is a list of DCLASS characteristics: a) It supports both breadth-first & depth-first search strategies. It supports forward chaining as principal inferencing mechanism. b) It uses Group Technology approach to classification of faults and symptoms. c) It provides easy interface to external databases and programs. d) It has I/O capabilities. Depending on a particular input, either from the user or from the e) sensors, it can fire a certain output. It has explanation capabilities. It can provide situation based instructions, and also has the f) capability to show how the diagnosis was reached.
17th InternationalConferenceon Computersand IndustrialEngineering
g) h) i) J)
151
It has report generation capabilities. It can print out diagnostic reports, repair guidelines, or maintenance work orders. It comes with full documentation of all the software modules. It is easy to learn and use. It is a commercial product with low cost and good vendor support.
THE G E N E R A L I Z E D SYSTEM
To make ROBODOC a generalized system, capable to diagnose malfunctions of any automated equipment, similarities and differences between different automated equipments have to be identified. By breaking down the automated system into its structural and functional elements, one can explore the similarities and differences. Once a diagnostic system is built for one system, it can be easily expanded into a generalized diagnostic system by incorporating the differences. For example, one of the functional elements that are common to both the systems is a servo motor, and a common FPT for both the systems can be developed. The knowledge-base will be divided into modules that are common to all the systems, and also in individual system specific modules. This will simplify the task of incorporating another automated system for inclusion in the diagnostic ES. CONCLUSION A successful implementation of ROBODOC will prove the feasibility and effectiveness of GT approach in the development of a diagnostic ES. The diagnosis will be more efficient, consistent, methodical, and faster than by a human expert. It will analyze data that far exceed the human's capability to comprehend, both in time and quantity context. It will be possible for a less qualified maintenance worker to carry out repairs with the aid of ROBODOC. It can also serve as an excellent training tool. Once captured, the knowledge will be permanent. The expertise will always be available. Moreover, it will be easy to distribute the expertise. ROBODOC can also be used to develop a system for design for maintenance, i.e. to consider aspects of design which make maintenance easy, and also to develop an ES for design for endurance, i.e. to consider aspects of design which make the equipment more durable. BIBLIOGRAPHY Duda, R. O., "Knowledge-Based Expert Systems Come of Age", Byte, Vol. 6, No. 9, Sept. 81, pp. 238281. Genesereth, M. R., "Diagnosis Using Hierarchical Design Methods", Proceedings of AAA1, August 1982, pp. 178183. Milacic, V. R. and Majstorovic, V. D., "EXMAS - Knowledge-Based System for Maintenance of Complex Mechanical Systems," Robotics and Computer Integrated Manufacturing, vol. 3, No. 2, pp. 187-193, 1987. Nilson, N.; "DELTA-CATS-l",. The AI Report, Vol. 1, No. l, 1984. Patel, Sanjiv and Kamrani, Ali, "Knowledge-Based System for Diagnosis of Industrial Robots," to be presented at IPC'95, Detroit, MI, May 9, 1995. Patel, Sanjiv and Kamrani, Ali, "A Survey of Expert System Technology in Diagnosis and Maintenance," accepted and under revision for Engineering Design and Automation, 1995. Piety, Ken, and Corley, James E., "Development of an Expert System to Diagnose Machinery Vibration Problems", Proceedings of the First International Machinery Monitoring & Diagnostics Conference, Las Vegas, Nevada, 1989, pp. 523-527. Shortliffe, Edward H., MYCIN: Computer-BasedMedical Consultations, Elsevier, NY, 1976, Visinsky, M. L., Walker, I. D., and Cavallaro, J. R., "Robotics and Remote Systems in Hazardous Environments", Edited by Jamshidi, M., and Eicker, P. J., Prentice Hall, Englewood Cliffs, NJ, pp. 53-73, 1993. Winston, Patrick Henry, Artificial Intelligence, Third Edition, Addison-Wesley, 1992.