13
69 Intelligent Manufacturing Systems IMS'89 DESIS An Expert System Shell for Technical Diagnosis A. Storr and H. Wiedmann lnstitut fiir Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen, Universitiit Stuttgart, Seidenstr. 36, 7000 Stuttgart 1, FRG At our institute an expert system shell is developed for the diagnosis of technical equipment. Thereby the requirements of construction work and maintenance of the knowledge base are especially considered. This concerns the systematical and mod- ular representation of the empirical diagnostic knowledge as well as the deep functional knowledge. The work explores special methods of technical diagnosis which can be imple- mented as inference strategies instead of controlling the system behaviour by some strategic knowledge in the knowledge base. The invocation of these methods is controlled by the system itself. The work investigates how knowledge can efficiently be represented and administrated in an object oriented language. Another point of main effort of the work is the exploration of the utilization of special techniques in a powerful object ori- ented language for programming. Keywords: Model based expert systems, Knowledge types, Knowledge representation, Inference strategies, Simulation of behaviour, Forward chaining, Back- ward chaining, Object oriented programming. Alfred Storr was born in 1934 and studied mechanical engineering at the University of Stuttgart. After having finished his studies, he became a sci- entific engineer at the Institute of Machine Tools, University of Stutt- gart. In 1964 he started to work as chief engineer at the Institute for Con- trol Technics of Machine Tools and Production Equipment, University of Stuttgart. In 1974 followed his nomination as a professor. Elsevier Computers in Industry 15 (1990) 69-81 1. Introduction A growing number of expert systems are being set up for the diagnosis of technical equipment. There are various reasons for this, for example, the short model changing time and the diversity of the variant of machine tools which, in their struc- ture and function are increasingly more com- plicated. The advantage of the setup of the expert sys- tems lies in the easier maintenance and the infe- rior modification expense on further development of machines as opposed to conventional pro- grammed diagnostic software, thus with expert systems the diagnostic knowledge will be stored separately from the program control structure in a knowledge base. Expert systems increase the pro- ductivity of the service personnel, as they are relieved or even replaced of easy routine tasks and assist by more complicated trouble shooting so that the machine tools availability is increased. An increase in availability cannot be attained to the same degree through additional supervisory means as extensive sensory analysis and control software where the sensory analysis is likewise prone to failure. That is the more sensors con- tained in a machine to supervise, the more fre- quently a standstill due to breakdown occurs in the supervisory parts. H. Wiedmann was born in 1956 and studied computer science at the Uni- versity of Stuttgart. Since 1985 he has been working as a scientific collabora- tor at the Institute for Control Tech- nics of Machine Tools and Production Equipment, University of Stuttgart, in the field of knowledge based diagnosis of machine tools. 0166-3615/90 - Elsevier Science Publishers B.V.90/$03.50 © 19

DESIS—an expert system shell for technical diagnosis

  • Upload
    a-storr

  • View
    215

  • Download
    0

Embed Size (px)

Citation preview

Page 1: DESIS—an expert system shell for technical diagnosis

69

Intelligent Manufacturing Systems IMS'89

DESIS An Expert System Shell for Technical Diagnosis

A. Storr and H. W i e d m a n n lnstitut fiir Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen, Universitiit Stuttgart, Seidenstr. 36, 7000 Stuttgart 1, FRG

At our institute an expert system shell is developed for the diagnosis of technical equipment. Thereby the requirements of construction work and maintenance of the knowledge base are especially considered. This concerns the systematical and mod- ular representation of the empirical diagnostic knowledge as well as the deep functional knowledge. The work explores special methods of technical diagnosis which can be imple- mented as inference strategies instead of controlling the system behaviour by some strategic knowledge in the knowledge base. The invocation of these methods is controlled by the system itself. The work investigates how knowledge can efficiently be represented and administrated in an object oriented language. Another point of main effort of the work is the exploration of the utilization of special techniques in a powerful object ori- ented language for programming.

Keywords: Model based expert systems, Knowledge types, Knowledge representation, Inference strategies, Simulation of behaviour, Forward chaining, Back- ward chaining, Object oriented programming.

Alfred Storr was born in 1934 and studied mechanical engineering at the University of Stuttgart. After having finished his studies, he became a sci- entific engineer at the Institute of Machine Tools, University of Stutt- gart. In 1964 he started to work as chief engineer at the Institute for Con- trol Technics of Machine Tools and Production Equipment, University of Stuttgart. In 1974 followed his nomination as a professor.

Elsevier Computers in Industry 15 (1990) 69-81

1. Introduction

A growing number of expert systems are being set up for the diagnosis of technical equipment. There are various reasons for this, for example, the short model changing time and the diversity of the variant of machine tools which, in their struc- ture and function are increasingly more com- plicated.

The advantage of the setup of the expert sys- tems lies in the easier maintenance and the infe- rior modification expense on further development of machines as opposed to conventional pro- grammed diagnostic software, thus with expert systems the diagnostic knowledge will be stored separately from the program control structure in a knowledge base. Expert systems increase the pro- ductivity of the service personnel, as they are relieved or even replaced of easy routine tasks and assist by more complicated trouble shooting so that the machine tools availability is increased.

An increase in availability cannot be attained to the same degree through additional supervisory means as extensive sensory analysis and control software where the sensory analysis is likewise prone to failure. That is the more sensors con- tained in a machine to supervise, the more fre- quently a standstill due to breakdown occurs in the supervisory parts.

H. Wiedmann was born in 1956 and studied computer science at the Uni- versity of Stuttgart. Since 1985 he has been working as a scientific collabora- tor at the Institute for Control Tech- nics of Machine Tools and Production Equipment, University of Stuttgart, in the field of knowledge based diagnosis of machine tools.

0166-3615/90 - Elsevier Science Publishers B.V.90/$03.50 © 19

Page 2: DESIS—an expert system shell for technical diagnosis

70 Intelligent Manufacturing Systems--lMS'89 Computers m lndzzs'tO:

2. State of Research

In the development of knowledge processing systems an increasing specialization in the direc- tion of application can be recognized. At the be- ginning there was the idea of a "General Problem Solver" which, with few generally valid conclusion principles should solve all problems with corre- sponding knowledge representation (coding). The ability to handle this form of systems was very bad as the knowledge couldn't be represented in a problem adapted form. These systems lacked in knowledge-processing control strategies which im- plement specific procedures for the solution of problems from different application fields (diag- nosis, interpretation, configuration, construction, etc.). Because of this the system behaviour was not transparent for the user. To overcome this prob- lem systems were developed whose control strate- gies were adjusted to specific domains of prob- lems. At the moment these so-called systems of the first generation (or shallow expert systems, because of their, mostly unstructured-stored expe- rience knowledge) are being replaced by systems of the second generation (deep or model-based expert systems with knowledge about the structure and function of the diagnostic object). Still more, they possess application-specific control strategies and knowledge representation forms. This devel-

opment can be made more understandable with the help of a classification of the knowledge in these systems. Thus a classification based upon the type of knowledge will be given from the application field. This classification carries-on in- fluencing the grouping of the knowledge represen- tation form.

The knowledge can be classified into descriptive and strategic knowledge, The descriptive knowl- edge describes the properties and relations of the diagnosis object whereas the strategic knowledge describes the procedure in an inference process (control strategy) and should be incorporated as an algorithm in the inference engine.

The descriptive knowledge can be classified into knowledge types (see Fig. 1). The arrangement of a system concerning this classification will be in- fluenced by the application field. For example in technical systems the functional relationships are very well understood and can therefore be repre- sented as a model in the knowledge base whereas, in the medical area more empirical knowledge (statistical knowledge, case data knowledge, as- sociative knowledge [1]) must be used.

Shallow expert systems work with empirical knowledge and model based systems use causal knowledge. Model based systems with exclusive causal knowledge can localize known and fre- quently appearing faults less efficiently than sys-

~ Knowledge Type / / / / / / / / / / / / ~

Statistical

Knowledge

'c

Functional

~. Knowledge Source ~/. Structure Possibility'//~/~/~Candidale of Fault Criterion~

I Fault ] !Relative Frequency of

Statistics | , Reasons for Faults for the

j i observed Symptomatology

Case Data ' Case Daia " Siruciuring Of - ! Similarity Measure for

Knowledge Collection : Symptoms for Case Comparison with known i

Distinction Cases '

,, i . . Experience of some ! Structuring of Fault Subjective Certainty of J Associative i

. . . . . Diagnosis Expert Candidates (Hypotheses) Reasons for the observed I~nowleoge

. . . . . . . . and Djagnostic_ Rutes ......... =S~'mPlomatology

Construction Structured Model of the Dia- / Discrepancy between the

Knowledge : Documents gnosis Object corresponding / expected and the . . L L , = . . . . . its Structure and Behaviour l observedBehaviour

Fig. 1. Types of descriptive knowledge for diagnosis.

Page 3: DESIS—an expert system shell for technical diagnosis

Computers in lndustry A. Storr, H. Wiedmann / Expert System Shell 71

tems which exploit additional empirical knowl- edge.

The descriptive knowledge therefore also de- termines the structuring possibilities of the knowl- edge and thereby possible knowledge representa- tion forms (see Fig. 1). For diagnosis expert sys- tems, rules, frames and semantic nets are the most important knowledge representation forms [2]. From the insight that all of the descriptive knowl- edge types described above in the field of techni- cal diagnosis are relevant, all must also be repre- sentable. This evidence is nowadays generally accepted but none of the existing systems use all of the knowledge types.

The strategic knowledge can be further classi- fied into: - general inference principles (e.g. modus ponens),

which are relevant for all of the application fields (domains);

- domain specific procedures (e.g. differential di- agnostic in diagnosis field, see Fig. 2, [3]); and

- problem specific procedures (e.g. examination of an hydraulic pump or rotary current motor), which are only relevant to subdomains or specific elements of an application field.

The General Problem Solver possessed only gen- eral inference principles. Shallow expert systems work additionally with a domain-specific proce- dure which, in the model based systems through a further restriction of the application field (e.g.

diagnosis of digital electronic circuits [4] or analog electronic circuits [5]) are even more specialized. In this manner these systems are no longer usable in the whole field of machine tool diagnosis but only in subdomains. As a consequence no expert systems or shells exist which are optimally suited to the diagnosis of technical equipment. In the following, requirements of the technical diagnostic will be set up on expert system shells.

3. Requirements on an Expert System Shell for the Technical Diagnosis

The diagnosis of a machine tool with the help of an expert system does not only raise require- ments on the functionality of the expert system shell but also on the representation of the knowl- edge in the system. This should be clearly arranged and self-documentating to enable an easy mainte- nance and service of the system.

3.1. Requirements of the Knowledge Representation

Many shortcomings of the expert system shells of the first generation rely on a too little problem-adapted knowledge representation. These systems were developed in the software laborato- ries of AI researchers and much effort was laid upon a theoretically well based representation for-

Strategy

Establish Refine

Hypothesize- And- Test

Differential Diagnostic

Structure of Hypotheses

"9 " ' ~''.

II

Procedure

step by step localization ot the fault by refinement of the hypothesis (fault suspicion)

direct generation of a suspicion with following inspection

comparison of concurrent diagnoses and selection of the best (usually in combination with Establish Refine or Hypothesize-And-Test)

Fig. 2. Control strategies for the processing of structured associative diagnosis knowledge.

Page 4: DESIS—an expert system shell for technical diagnosis

72 Intelligent Manufacturing Systems--IMS'89 Computers in Indtz~w'~

malism whereas the pragmatical requirements of a particular application field were not sufficiently taken into consideration in these systems. The diagnosis experts had to translate their knowledge into a form, in which it could be represented and processed in the system. Instead of thinking and structuring hard- and software components, func- tions and signal flows they had to operate with rules, frames and semantic nets. As a consequence a knowledge engineer was required. He had to acquire the knowledge from the diagnosis experts and transform it into a system representable form. The knowledge engineer was usually not an expert in the field of diagnosis. This, inevitably led to many misunderstandings between the knowledge engineer and the diagnosis expert. Thereby the maintainability of the system was impaired. To overcome these difficulties the construction of the system and the service of the knowledge base must be done by the diagnosis expert. He must there- fore be able to represent the knowledge in a problem adapted form so that it is approachable for him. However, the knowledge should be repre- sented for processing in the system in another form for reasons of efficiency. Hence there exists two different views of the knowledge representa- tion (see Fig. 3) i.e. the application view for the diagnosis expert and the representation view for the inference system. The transformation between

/

Re~esentation view Rules Semantic Nets

I Frames Relations I ~ Lists Objects

Fig. 3. Views on the knowledge representation.

the views must be accomplished by the acquisition component. In the following the requirements on the knowledge base structure should be regarded more precisely from the application view.

3.1.1. Structuring the Empirical Knowledge Based upon the requirement for systems that

work with empirical knowledge as well as causal knowledge (see Section 2) one can derive the re- quired contents of a knowledge base. For the causal trouble shooting, a model of the diagnosis object consisting of its components, its connec- tions and junctions (structure) and a description of its behaviour is needed, The empirical knowl- edge should support the causal trouble shooting and serve for a rapid diagnosis of known faults. The appearance form of the faults is described by its symptoms. A structured representation of com- ponents, functions and symptoms (modules) can therefore serve as a framework for the representa- tion of the empirical and also of the causal knowl- edge [6]. For this the components and functions must be ordered hierarchically. Then the levels of the hierarchy correspond to different levels of abstraction with subcomponents and subfunctions of the superior modules. Also the symptoms should be structured hierarchically through a differentia- tion of rough and fine symptoms (see Fig. 4). The associative knowledge of experience of the expert diagnostician consists of attachments of symptoms and causes. The symptoms can be faulty compo- nents or indirect disturbed functions and the at- tachment can be made by suspicion references from symptom modules to function and compo- nent modules (see Fig. 4). Suspicion references correspond to a hypothesis formation, i.e., at the formation of a suspicion the suspected component or function must be checked. The modules should contain the knowledge needed to check the corre- sponding component or function, e.g. the knowl- edge to perform the test. This knowledge can be represented inside the modules in variables which describe the state of a module and experience rules which draw conclusions from the module state. Because of the different representation forms of the knowledge (rules, modules) the knowledge representation is called hybrid. As a failure of a function (e.g. tool change) mostly has its cause in a faulty component, suspicion references from function modules to component modules are also needed.

Page 5: DESIS—an expert system shell for technical diagnosis

Computers in Industry A. Storr, H. Wiedmann / Expert System Shell 73

Besides the suspicion references, the symptom modules must contain knowledge for the inquiry of symptoms, statistical knowledge and case data knowledge (connection to a case data base).

3.1.2. Structuring the Causal Knowledge The model in the knowledge base is used for

the imitation of the structure and behaviour, re- spectively misbehaviour of the diagnosis object and therefore must consist of components and functions. The knowledge about components and functions can be classified relative to its character- istics (see Fig. 5). Using the model of a component one can e.g. compute the values which must ap- pear at its outputs with the values at its inputs. If the actual output values are distinct from the ones computed in the simulation of the behaviour then a disturbance or a fault of the corresponding component exists. To localize the fault step by step the model must be represented in distinct levels of abstraction the same as with the em- pirical knowledge described above. For the con- struction of the model the modules which contain the empirical knowledge concerning components and functions (see Fig. 4) must be extended with the object and operating characteristics behaviour and connections respectively connected loads (see Fig. 5) and the possibility to represent the external junctions between the components, respectively the functions. This yields a three-part structuring of the knowledge base consisting of component,

function and symptom modules, which hierarchi- cally structuring can directly be derived from the diagnosis object.

3.2. Requirements on the Functionality of the In- ference Engine

Because of the different proceedings at the di- agnosis with empirical and causal knowledge and the benefits of modularly constructed software, two inference systems for the processing of the different knowledge types are demanded. As the two proceedings should complete one another, interfaces and possible interactions between the two systems must be regarded.

To come nearer to the proceeding of a human expert (and this is a requirement for the accep- tance of expert systems) the system should start with processing the empirical knowledge. Already known cases of faults can be detected in this manner with much less effort as by causal trouble shooting.

3.2.1. Empirical Inference The symptom-oriented beginning of a diagnosis

has to start with a symptom inquiry upon which it is possible to carry out a refinement of the symp- tomatic and ask for further symptoms. This pro- ceeding is supported by the structuring of the symptom modules in the knowledge base which consist of rough and fine symptoms (see Fig. 4).

I RootModule ]

o . o I - " ~ -2 o e , ,

Structure References • ., , -- ~ Suspicion Reference

Fig. 4. Module structure of the knowledge base.

Page 6: DESIS—an expert system shell for technical diagnosis

74 Intelligent Manufacturing Systems--IMS'89 ( " o m p u t e r s in Industry,

Descriptive Knowledge Strategic Knowledge

Object Characteristics Operation Characteristics Diagnosis Characteristics

- Behaviour - Behaviour

(function) (malfunction, correct function)

- Connect ions - Connected Loads

(inputs, outputs, supply, (inputs, outputs, supply, e.g. its

and its structure) nominal values and actual values)

- Properties - Properties

(intrinsic values, e.g (failure frequency,

capacity, tolerances) inspection cost) . . . . . . .

- Diagnosis Stralegy

* inspection sequence of

connect ions,

* inspect ion method for

electrical, optical,

mechanical, ... parts,

* empirical, causal inspect ion

methods

* carrying out of tests

Fig. 5. Characteristics of components and functions.

Thereby the processing of the symptom modules can be performed like the processing of all mod- ules. After asking the user for facts (held in local variables of modules) the experience rules of a module can be processed. With these rules, con- clusions can be drawn from facts, e.g. new facts can be derived or other modules can be marked for examination (activated). The activation of modules can be achieved by utilizing the suspicion references. Proceeding from the symptom modules there must be activated function modules or com- ponent modules after a sufficient refinement of the symptoms. The generation of the suspicion must be performed with the empirical knowledge (case data, statistical and associative knowledge). With this proceeding a local and module-oriented rule processing in forward-chaining manner en- sures a simple control of the system behaviour by the knowledge engineer. As the knowledge is not fully modularizable experience rules exist which rely on facts stored in other modules and rules which conclude faults in components which are represented by other modules. Because of this the rules must also be processable in a rule-orientated (global) backward-chaining fashion.

3.2.2. Model Based Inference This part of the inference uses the description

of the behaviour and structure of the components

and functions in the model to recognize malfunc- tions. This is enabled by the detection of dis- crepancies between the observed behaviour and the expected behaoiour resulting from a simulation. Components and functions can be handled alike as they operate alike and therefore can also be represented alike. Functions are described sep- erate from components because the attachment from functions to components can span different dependencies from 'one to one' over 'one to many' and 'many to one' to 'many to many'.

By the localization of faults the manifold prob- lem-specific procedures (see Section 2) of the tech- nical diagnostic are relevant to serve as control and steering mechanisms for the inference system. The central strategies are the functional module inspection and the signal way examination. At the functional module inspection, first the supply of a component , respectively function, must be checked. If this is okay then all output and input values must be determined. With the internal functions which describe how the output values of a connection depend upon some input values the correct function or malfunction of the module can be argued.

The signal way examination starts with the de- tection of a value which does not correspond to a value gained by simulation at the model. If this is a signal value which was modified by several

Page 7: DESIS—an expert system shell for technical diagnosis

Computers in Industry A. Storr, H. Wiedmann / Expert System Shell 75

components or functions then its way back to its origin can be followed until a modUle is found at which output the signal value does not correspond with the mapping of the input values (see Fig. 6).

3.2.3. Interactions and Interfaces between the In- ference Systems

The human expert who is about to find a fault in a machine tool first obtains a general view of the state of the machine by regarding the symp- toms of the fault. With the help of his experiences he is able to suppose or exclude earlier appearing faults. After he has roughly surrounded the fault he tries to determine the cause of the fault more precisely by a detailed inspection. The observa- tions he has thereby made can change or refine his general view about the fault. That will lead his further search for more detailed information (see Fig. 7). To imitate this behaviour by an expert system the switch over of the two inference sys- tems should happen automatically [7]. The criteria hereby is the state of the diagnosis which results in the actual state of the knowledge base. The knowl- edge base is modified by the processing steps of the inference systems which partly access the same knowledge elements. So the knowledge base pro- vides interfaces between the inference systems through which data can be exchanged and, as a consequence, through which the interactions of the inference systems can be controlled.

The interfaces are formed by

- the hypotheses (activated component respec- tively function modules);

- t h e structuring of component and function modules; and

- the input and output variables of component and function modules.

An inspection of a suspected module (hypothesis) with the empirical knowledge inside that module breaks off if all of the empirical knowledge is processed. If the hypothesis that this is the trou- ble-causing module however could not be sup- posed nor excluded then the suspicion remains and the module should be inspected functionally using causal methods (see above). If the module is not represented at this level of abstraction then its submodules in the next deeper level should be regarded and inspected (again starting with processing the empirical knowledge). The submod- ules can be found by utilizing the module struc- ture. The input and output variables of a module are used in a causal inspection and moreover to reason with experience rules. Because of this the simulation on the model can be invoked whenever an input or output variable is assigned a value by an experience rule or by user input. At the detec- tion of discrepancies between the simulated and the observed values the signal way examination can be invoked for example (see Fig. 6).

Furthermore the described interfaces and the superimposition of parts of the empirical knowl- edge and the model supports keeping the different

Ill

[ ' Comp°:ent t

01o = f o1(t lO)

C°mp°nent 0 ~ 1 ~ 2 C°mp°nent ] J

012 113

I 11 '" Input 1 of Component Aj 0 lk '" Oulput 1 of Component Ak I mr, "'" Internal Function for Output n ol Component m

Component I o . ~) A3 lO

013

0 10 <>f01 (I lo) :> Signal Way Examination at Next Deeper Representalion Level: 013 =f31 (113);113 =012;012<>f21 (112) .>FaultyCompenent A 2

Fig. 6. Fault detection through signal way examination.

Page 8: DESIS—an expert system shell for technical diagnosis

76 Intelligent Manufacturing Systems--IMS'89 ('ornputers in lndustrv

3n uni ts~ - / A General View ",, ~ • " ~....~ /~ state of paJ symptoms X ~ / navigates the search for '~ ~ ......

Detailed Information ,,, S ,= fault localization// signal ways

indications \ \ / ~ hardware propertiE

~ds of o p e r a t i o ~ A Delailed Inspection cerre¢ .... functions / x

the GeneraIView / " - componen uration ~ " " \ / .

- \

Fig. 7. Control of diagnosis through different levels of view.

knowledge types consistent (e.g. identical facts and identically named elements in the model and in the experience rules).

4. Consequences for the Realization

Because of the required structuring of a knowl- edge base from the application view (see Section 3.1.) and the requirement of an easy way to trans- fer the application view into the representation view the internal representation in the system should also be hybrid. That is frames are more suited for the representation of modules whereas the best representation means for experience rules, which must be processed using the strategies of backward-chaining as well as forward-chaining, are production rules.

These are requirements for the implementation language which should offer data structures with which the needed representation form can be real- ized most naturally. Other requirements concern the aspect of implementation, This means a simple and efficient possibility of dynamic knowledge base management (high functionality of the pro- gramming language) and a comfortable develop- ment environment. As logic oriented languages (a typical exponent is PROLOG) do not offer the required sophisticated functionality for an easy implementation, as function oriented languages (a

typical exponent is LISP) do not offer the required data structures and as programs written in proce- dural languages (a typical exponent is PASCAL) are difficult to modify and offer no proper means for symbolic data processing an object oriented lan- guage should be used for implementation.

For the use of expert systems in the domain of machine construction other requirements for the implementation language must be added: - the ability of integrating and coupling the sys-

tem with programs written in conventional lan- guages;

- the system must be runnable on multi-purpose computers;

- a good portability; and - short response times. Because of these marginal conditions for the reali- zation of the expert system shell DESIS the object oriented language c o o t (C-based Object Oriented Language) was chosen, which fulfills all of the requirements above [8].

4.1. Requirements on an Object Oriented Language for Knowledge Representation

Object oriented languages are conceptually basically differentiated from the customary con- ventional languages (e.g. FORXRAN or PASCAL), but can be well contrasted with one another [8-11]. The following concepts of the object oriented pro-

Page 9: DESIS—an expert system shell for technical diagnosis

Computers in lndustry A. Storr, H. Wiedmann / Expert System Shell 77

gramming correspond roughly to the represented constructions in conventional languages: Object - - Program Module Method - - Procedure Slot Definition - - Data Declaration Slot Value - - Data All actions in an object oriented system depend upon the exchange of messages between hierarchi- cal or networkstyle structured objects. The mes- sages cause the invocation of methods in the ob- jects that receive the messages (this corresponds to procedure calls). Thereby the methods will be executed in the context of the receiver object and perform condition changes of this object (change of slot values). Methods can be inherited from other objects in case the receiver object of the message does not own it. The kind of realization should be made dependant upon the processing efficiency if the application has no further require- ments on the implementation. With the represen- tation of a causal model of technical equipment the possibilities of a direct and an indirect repre- sentation exist (see Fig. 8).

With a direct representation e.g. component connections and properties (object characteristics, see Fig. 5) can be represented as slot definitions [8]. The names of the connections and the func-

tion names correspond then to the slot names. The problem thereby is that every fact that represents a connection has many particularities (question text, help text, minimal value, maximal value, etc.). They must then be stored in a list as a single slot value. In this manner the access to the indi- vidual particularities will be troublesome. Besides, all variables which serve for another purpose (sig- nal inputs, supply inputs, outputs, etc.) must be identified so that their purpose is recognizable, as they are all represented in an object as slot defini- tions.

With an indirect representation form the con- nections e.g. can be represented as objects and their particularities can be represented as slot val- ues. The individual particularities of all variables representing connections are then accessable through their particularity name (the slot name) and the objects (connections) are all constructed the same and through messages directly addressa- ble. Thereby the inference in an object-oriented message passing system is easy and modular to construct. This affects not only the message ex- change for the activation of methods, but also the possibility of inheritance out of the characteristic classes (see Fig. 5). The division of the classes determines the environment from which the char-

~ i ~ ~ R e p r e s e n t a t i o n j r,,nowleage ~ c:h,l= /

- a t ' ° u t - - - - ~ / ' !

Component / Function !

Behaviour

"C Connections

L)

2 Properties • ~ E3

(D

Behaviour O3

~ Connected Loads

L L c~ 2 Properties

D i a g n o S i s

Chorac Diagnosis Strategy r a i l ; t i c s

Direct

Objects

Methods, Tables, Lists

I ~lotdeiinitions- . . . .

I Slotdefinitions I . . . . . .

Indirect

Objects

Methods, Tables, Lists

Objects i I

Slotvalues I

Slotvalues Slotvalues

Slotvalues Slotvalues

Slotvalues Slotvalues

Interited Interited

Fig. 8. Knowledge representa t ion means in an object -or iented language.

Page 10: DESIS—an expert system shell for technical diagnosis

78 Intelligent Manufacturing Systems--IMS'89 Computers in lndust O"

/

/ SubparI 1

Part

\ A

defect [

faultless

i, / /

, / Subpart 1

T Part [

\

\T SubpaH 2 1

Fig. 9. Structures for inheritance of operation characteristics.

acteristics can be inherited. Thus inheritance of characteristics from objects of the model is possi- ble at: - operation characteristics: within the model of a

diagnosis object; - object characteristics: from library objects out-

side of the module; - diagnosis characteristics: from system objects in

the inference engine. For the component respectively function modules of the application view, an internal structure (rep- resentation view) of the knowledge base can be committed with these inheritance relationships: - inheritance of operation characteristics

- behaviour: direct inheritance corresponding to the structure of the hierarchy (see Fig. 9);

- connected loads: identity of variables (e.g. inputs of superior and inferior components);

-p rope r t i e s : calculating function (e.g. calcu- late the failure certainty of superior compo- nents by the failure certainty of its subcom- ponents);

- inheritance of object characteristics - behaviour: direct inheritance or instantiation

(see Fig. 10); - connections; - properties: instantiation or copy;

- inheritance of diagnosis characteristics (see Fig. 11) - diagnosis strategy: direct inheritance from

system objects. By the outlined structuring of the knowledge base in the representation view hints are given for the

realization of the inference in an object oriented language.

4.2. Realization of Shell Functions in an Object Oriented Language

The following contemplation is oriented on the possibilities of COOL [8] which is the language in which DESIS is implemented.

With the realization of expert system shells a distinction must be made between system utiliz- able techniques and application utilizable tech- niques for programming. Utilizable for the appli- cation is e.g. the inheritance of operation char- acteristics and object characteristics as they" are outlined in Section 4.1. whereas the inheritance of diagnosis characteristics is utilized by the in- ference system. In Fig. 11 e.g. the examination of

Library [ ~:/, Knowledge ,

/~/ ./>

Knowledge Base I

Fig. 10. Structures for inheritance of object characteristics.

Page 11: DESIS—an expert system shell for technical diagnosis

Computers in Industry A. Storr, H. Wiedmann / Expert System Shell 79

E 09

U3

09 u c 09 L

09 o3 ©

Ck~

09 E~

1D 09

© c

"M

Causal Inference , ~ g b j e c t s contain methods with special diagnostic strategies

E l e c t r i c _ O p t i c

Inherit link

DirectCu~ ~urrent .__. Motor _ J I Alternate Motor ]

l Machine Tool] \ ...,

1 1 Ll~r°cess ~ ~ Coupling

_ I Optical Coup~ling

Fig. 11. Structures for inheritance of diagnosis characteristics.

the modules Optical Coupling respectively Motor can be achieved by sending the messages "Optical Coupling examine" respectively "Motor examine" to the objects which represent those modules. The object Optical Coupling inherits the method "ex- amine" from the system object Optic, whereas the object Motor inherits two "examine" methods, one from the object Electric and another from the object Mechanic. A backtracking mechanism of the implementation language takes care of the processing of both examining methods for the object Motor in case the execution of the first applied method fails to reach the desired diagnosis aim.

By utifization of inheritance and in addition of data driven programming the signal way examina- tion and the propagation of correct signal values can be realized. With data driven programming the assignment of a slot value causes the invoca- tion of a coupled procedure (demon). This has to be specified only once at the definition of the slot and can be inherited by all descendant objects. With that the fact objects form an active interface between the two inference systems. The switch over between the systems is controlled through this interface, i.e. by the assignment of slot values.

In AI languages programs are handled like data. Thereby programs are able to modify them- selves which can be utilized very sensibly for the programming of expert systems. As an example the inference control should be regarded.

As in the beginning of a consultation only empirical knowledge is employed and the error which should be detected can perhaps be found without the help of model based inferences, the methods therefore must not be contained from the beginning in the expert system. The advantage will avoid the overhead resulting from swapping of the unneeded methods and method parts. In need these methods must be incorporated in the in- ference engine which can be realized for example with the following part of a procedure:

if model based inference methods are needed

then incorporate these methods into the sys- tem and modify this method, e.g. remove this if statement

This method modifies itself after the incorporation of the model based methods, so that the compari- son in the now unneeded if statement need not be executed anymore.

The ability of self modification can be used in

Page 12: DESIS—an expert system shell for technical diagnosis

80 Intelligent Manufacturing Systems--IMS'89

connection with the information hiding principle also for the control of options. For the test of the system behaviour the knowledge engineer needs a trace function e.g., which traces the performed conclusions of the system for him. Therefore he can list the trace in different levels of detail on an ASCII screen or send it embedded in telegrams to a window surface on a bi tmap screen. Before each output of trace it must be checked if the trace is switched on or off, which trace level (many / f ew trace information) is switched on and how the output should happen (with or without telegrams). All comparison statements can disappear when the preparation of the trace takes place as follow- ing. An output instruction for a trace information in the inference procedures always cause the pass- ing of a message to the object which owns or inherits the method for outputting the trace. This method will be erased by switching off the trace. When the trace is switched on the method will be incorporated into the system and with the switch over of the trace the method will be modified. No comparisons as described above are needed any- more and this will result in a faster execution of the software. For an outside standing observer of that scene the object determines self-sufficiently how it reacts to the message for outputting a trace information and therefore this technique is called information hiding.

(il omputers in lndusOT

Other possibilities for the application of these techniques are represented in Fig. 12.

5. The Expert System Shell DESIS

DESIS was developed under consideration of the requirements presented above. Further re- quirements for the development were a high de- gree of portabili ty and a high processing speed. Both criteria were fulfilled with the implementa- tion language COOL [8]. COOt runs on most com- puters under the U N I X operating system, under V A X / V M S and also, with limitations under MS- DOS. The average response time doesn't exceed a few seconds and is almost independant of the size of the knowledge base. Neither COOL nor DESIS limit the possible size of a knowledge base and with a neat structuring as described above even large knowledge bases (500 modules, 1000 rules) can be handled easily in respect to their mainte- nance and service.

6. Concluding remarks

Since the appearance of problem-solving pro- grams based on AI techniques a still more stronger specialization of these systems concerning the ap-

. . . . . . . . . . . . . . . . . sYste~m Profitabl; . . . . . . . . . [ ApplicalionProlitable !

- context dependant inference | - inheritance of operation characteristics Inheritance | ' ri i s (inheritance of diagnosis characteristics) { - inheritance of object characte st c

. . . . . . . . . . . . . i p~ttte;n matci ing and p;o;essing -ve;s;on management ofthe knowledge

Self-Modificatien - inference control base

. . . . . . . . - system configuration/adaption l - -

Informalion Hiding

Demons

- processing of options (switching on/off traces or the

explanation facility)

- inference switching

- propagation of signals

- signal way examination

- representation of internal functions of

components

. . . . . . J

- coupling of facts

- qualifying quantitative values ! I

. . . . . !

Fig. 12. Examples for system and application profitable techniques of object-oriented programming.

Page 13: DESIS—an expert system shell for technical diagnosis

Computers in Industry A. Storr, H. Wiedmann / Expert System Shell 81

plications domain has taken place. The last step of

ths evolution unt i l now are multi-level expert sys-

tems which work with different types of knowl-

edge but do not yet incorporate all of them. More- over they use problem-solving strategies and knowledge representat ion forms which are not suf-

ficiently adapted to the t rouble-shooting in the

field of mechanical engineering. For the research

of this problematic nature the expert system shell DESIS was developed at the Ins t i tu t ftir

Steuerungstechnik in Stuttgart.

References

[l] F. Puppe, "Diagnostik-Expertensysteme", Informatik Spektrum, Vol. 10, No. 6, 1987, pp. 293-308.

[2] D.E. Altenkriager, Wissensdarstellung fiir Expertensvsteme, Reihe Informatik, Band 57, BI-Wissensschaftsverlag, Ztirich, 1987.

[3] F. Puppe, "Expertensysteme', Informatik Spektrum, Vol. 9, No. 1, 1986, pp. 1-13.

[4] R. Davis, "Diagnostic reasoning based on structure and behaviour", Artif Intell., Vol. 24, Nos. 1-3, 1984, pp. 347-410.

[5] J. Kriz and H. Sugaya, "Knowledge based testing and diagnosis of analog circuit boards", 1EEE, Vol. 16, 1986, pp. 378-383.

[6] A. Storr and M. H~irdtner, "Strukturierung von Wissens- basen fiir die Diagnose an Fertigungseinrichtungen", Kiinstliche lntelligenz in der Fertigungstechnik, Hanser, Miinchen-Wien, 1989.

[7] A. Storr and H. Wiedmann, "Funktionen einer Exper- tensystemshell fiJr technische Diagnosesysteme", Kiinstliche Intelligenz in der Fertigungstechnik, Hanser, Mtinchen-Wien, 1989.

[8] K. Hanakata, COOL Reference Manual, in preparation. [9] M. Stefik and D.G. Bobrow, "Object oriented program-

ruing: themes and variations", AI Mag., Vol. 6, No. 4, 1985, pp. 40-62.

[10] D. Thomas, "Whats in an object?", Byte Vol. 14, No. 3, 1989, pp. 231-240.

[11] P. Wegner, "Learning the language", Byte, Vol. 14, No. 3, 1989, pp. 245-253.