Navigation  without Java Scripts

ADVISOR

A PROLOG IMPLEMENTATION OF AN AUTOMATED NEURAL-NETWORK FOR DIAGNOSIS OF ROTATING MACHINERY

By:

Carsten Andersson
Product Manager
Bruel & Kjaer CMS A/S, Denmark

and

Claus Witfelt
Product Manager
Prolog Development Center A/S, Denmark

ABSTRACT

The condition-based (vibration and process) diagnosis system presented in this paper offers a new approach to expert system design and implementation.

The diagnosis system was implemented entirely by using Prolog which has bindings to an XVT1 library. The very strong features of the Prolog language - dynamic data structures, recursiveness and the ability to compare and match elements of complex data structures has made the implementation of this program possible. The application described, is within the field of machine vibration analysis. However, the principles of the program may also be used for diagnosis systems solving other types of problems.

The paper examines the steps in setting up the system, the daily operation, the workings of the neural network implementation and for each of these steps examples of how Prolog facilitated the implementation. The paper also looks at neural networks and discusses how this important technology is used in the system to address the problems associated with traditional artificial intelligence systems.

Most simple expert systems today are limited by the number of rules in their databases. As the person using the system gains enough experience to make better judgements, the expert system is used less and less. This paper therefore discusses how a user-defined knowledge-base can be used to augment the diagnosis system with the user's own knowledge and experience, continuously improving the breadth and accuracy of the diagnoses.

Background

Advances in asset technology and management allow machines to produce at full capacity for longer periods of time and with less intervention than what was ever thought possible. This has been achieved not only through improvements in machine design but also through the successful implementation of predictive maintenance (PdM) programmes based on vibration and process (condition) measurements.

Today's computerised-PdM systems, can automatically detect machine faults earlier and with greater degree of certainty than ever before. Such systems can scan thousands of measurement points in a plant, detect the smallest change in a machine's condition, and then pre-process, process, and post-process the measurement - all in a fraction of the time that it conventionally used to take! With the obvious enormous amounts of generated data that this entails, a means of effectively optimising and managing this data is certainly needed.

Traditionally, `experts' analyse the data and make the necessary decisions that will initiate the appropriate action. However, experts are not born! They have to be trained and then practise, and in general their years of accumulated expert knowledge is seldom documented. This means that experts are not only an expensive commodity but often in short supply as the demand for specialist decision-making increases with the volume of data produced. Moreover, with the current trend towards downsizing and outsourcing, there are fewer skilled people to use as a resource.

The two figures below shows a popular explanation of the function of a machine monitoring system and a machine diagnosis system.

Fig. 1 The objective of a monitoring system

 

image_b.gif (63825 bytes)
Fig. 2 The objective of a diagnosis system

Introduction

For several years there has been considerable interest in computer-based expert systems that will alleviate the expert availability problem, and tap the experience of top-level vibration analysts to provide first-hand information that is useful to both novices and experienced personnel in detecting and solving machine problems.

Most expert systems in use to date are artificial intelligence (AI) based systems - better known as rule-based expert systems. This type of system has a separate and distinct knowledge-base containing specific information and a finite number of previously established IF-THEN rules (that is, fixed conclusions based on a logical combination of observations) for a well-defined and narrow domain. To output a specific conclusion, the decision-making mechanism (called an inference engine in rule-based systems) looks at the information (or attributes) that is input into the system, and then finds a rule or a logical combination of rules in the knowledge base that matches the input information.

Rule-based systems are around in abundance, largely because the wealth of research and techniques available in this area make them easy to develop and apply efficiently. They are also commercially very popular because they use familiar, logical structures that users can understand and relate to. Rule-based expert systems are especially good for closed-system applications for which inputs are literal and precise, leading to logical outputs.

However, for dynamic applications such as predictive monitoring, rule-based systems fail to measure up to the expectations and needs of the user. This can be mainly attributed to an inherent problem associated with rule-based experts systems - fixed knowledge-bases. They are fixed because of the difficulty and time involved in checking, validating and verifying hundreds of lines of reasoning, each time the system is updated.

Having a fixed finite number of rules then, make rule-based expert systems inherently obsolete for PdM applications. As the person using the system gains enough experience to make better judgements and more reliable diagnoses, the system is used less and less.

One way of getting around this problem is to make large and comprehensive knowledge-bases that will cover all current and future eventualities. However, a specific problem associated with this idea is knowledge-acquisition congestion. Because the procurement of knowledge for the system is still primarily a human intensive activity, the availability of human experts is a major stumbling block in developing large expert systems for PdM and other dynamic applications.

Another problem with rule-based systems is knowledge aquisition, vibration experts generally do not think in terms of rules. Thus the logical, analytical techniques of rule-based systems do not generally imitate the actual reasoning processes of human experts which would ultimately lead to more reliable, heuristic diagnoses.

In the sections that follow, a machine diagnosis system is presented that offers solutions to the practical problems associated with conventional expert systems.

The system is an automatic neural-network based expert system that receives all of its monitoring and measurement information directly from a UNIX-based predictive monitoring system. Where machine vibration is dependant on the operating condition of the machine (for example change in active and reactive power and bearing oil temperature), the diagnosis system will combine process parameter measurements with vibration measurements to provide a more reliable diagnosis.

The paper outlines the operation of the system and for each of the sections describing the program, notes will be given on how Prolog facilitated the implementation.

Setting up the system - a crucial first stage

The key to successful machine monitoring is a meticulous approach to the initial setting up of the monitoring system. This also holds true for expert systems. Just as experienced analysts cannot give an accurate diagnoses without sufficient background knowledge of the machinery, so a machine diagnosis system cannot perform reliably without internal mechanical details of the machine.

A graphical editor has been implemented to allow for easy setup of many different types of machines.

Mechanical setup of a machine

In this example, the diagnosis system's graphical machine editor is used to represent a gas turbine (see figure 3). The entire gas turbine is composed from a library of standard machine-part icons, each with its own set of standard rules attached. These rules automatically provide the system with the standard vibration characteristics of the components. Where a machine component is not available in the icon toolbox , a user-defined icon is used to define the component to the system.

Additional detailed information regarding the number of blades on the turbine stages, , the type of couplings, etc., is also specified via a graphical display. For machines with rolling-element bearings, a bearing database is provided for easy specification.

This graphical approach to machine setup allows an infinite number of machine `models' to be easily created; the level and detail of which can be set by the user.

image_c.gif (32551 bytes)
Fig. 3 The graphical machine display showing the gas turbine, the upper right shows a drawing of the actual gas turbine.

 

Box 1: Prolog Implementation details
Each of the components of the machine drawing has a number of rules and symptoms attached describing the possible faults on that component. The figure below shows the relationship between components, symptoms, rules and faults.

Each component, symptom and rule is implemented as compound objects. New preset compound objects can be defined directly in the diagnosis system to create new symptoms and rules or can be done in an external tool used to defined factory set synptoms and rules.

The compound objects has the following layout:

Metacomponent(ComponentName,ComponentParameterList,Explanation)

ComponentName specifies the name of the component e.g. Turbine Row
ComponentParameterList specifies the which informations the diagnosis system needs to make a diagnosis, e.g. No. of blades on a Turbine Row.
Explanation contains textual information about the component.

Metasymptom(SymptomID,SymptomSetup,SymptomCalculation, Explanation)

SymptomId defined the name of the symptom
SymptomSetup defines the conditions and requirements for calculation the symptom - type of transducer, type of measurement etc. and defined which components this symptom are attached to.
SymptomCalculation specifies the actual calculation of the symptom eg. a sum or a difference between two other symptoms, or values of peaks extracted from frequency spectra.
Explanation contains textual information about the symptom.

metarule(Fault,RuleID,Certainty,ComponentSpecList,RuleConditionList, Explanation)

Fault specifies the the name of the faults diagnosed by the rule
RuleId specifies the name of the rule.
ComponentSpecList specifies which components this rule is valid for.
RuleConditionList specifies a list of rules with symptom limits which will indicate the fault.
Explanation contains textual information about the rule.

Basically the whole diagnosis system is based upon these three compound objects. The role of the graphical machine editor is for each machine picture to store a set of metacomponents with component parameters defined by the user, and metasymptoms and metarules characteristic for the components comprising the machine.

The sections below will show in more detail how the diagnosis system uses these data structures to create a diagnosis.

image_d.gif (9555 bytes)
From the figure above the following information can be extracted:
Several components can be defined
A symptom may be attached to several components (e.g. Sy-1 is attached to Component 1, 2 ....
One symptom can be based on the calculation of other symptoms (e.g. Sy-5 is calculated from Sy-2 and Sy-3.
The same symptom may be used in several rules (e.g. Sy-1 is used in R-2 and R-5)
One Rule may be attached to several components. (e.g. R-4 is attached to both Component 1 and 2.
A Fault is the result of the evaluation of several rules (e.g. Fault 2 is the result of the evaluation of R-5 and R-7.

Assigning symptoms

Once the machine is defined, the next stage in the initial setup is to assign the symptoms that will allow the system to diagnose faults. In vibration monitoring, symptoms would typically be peaks in a vibration spectrum, corresponding to the characteristic frequencies for the machine. During the diagnosis these symptoms are extracted from the vibration spectrum by peak search algorithms.. For example, the amplitude of the running speed (1X); the amplitude at twice the running speed (2X); the increase in amplitude at the blade passing frequency (BLPF), etc.). Another window is now used, this time to assign (connect) the symptoms to a specific monitoring point and measurement setup (see figure 4) defined in the monitoring system.

The assignment procedure automatically selects the most appropriate measurement defined in the monitoring (data aquisition) system for the different types of symptoms by matching the details of the measurement setup with the requirements of the symptoms for the different types of faults.

When making a diagnosis, the system will extract the symptom values from the measurement data, which are recorded and stored by the monitoring system at the selected point on the machine.

image_e.gif (14939 bytes)
Fig. 4 The assignment window showing monitoring points on the left connected to characteristic symptoms on the right.

 

Box2: Prolog Implementation details - Assignment procedure
The problems of the assignment procedure is to ensure that the properties of the selected measurement point in the monitoring system matches the requirements of the symptom in order to make a correct calculation. Only if there is an agreement, an assignment will be made. Each transducer may have up to twelve different measurements. In a recursive loop it is checked which of the measurements are best suited for each symptom.

Each symptom has the following main requirements:

Correct Transducer Type of which around 15 different types are relevant.
E.g. radial accelerometer, axial accelerometer, x accelerometer, y accelerometer, radial displacement transducer, axial displacement transducer.
Correct measurement domain
E.g. acceleration, velocity or displacement
Correct measurement Type of which around 35 different types are relevant.
E.g. Bandpass Measurement, Spectrum Measurement, Phase Measurement, Lowpass etc.
Correct Frequency Range. The frequency range of the measurement must be checked, if it is too large the resolution is too low and the symptom cannot be extracted reliably from the frequency spectrum. If it is too low, some of the components of the symptom may fall out of the frequency range.

The problem of matching the properties of the symptom with those of the measurement system is elegantly solved by using the Prolog unification facilities in a series of clauses where valid combinations of transducer and symptom requirements.

Example:

Here it is checked that the selected transducer type matches the transducer type (e.g. Accelerometer) and the measurement direction and orientation (e.g. radial) as defined in the compound object "measreq" which is a part of the symptom definition. In this short example the bold element is matched against the bold cursive elements. The simple and understandable way of writing these statements made it very easy for a non-programmer with expertise in the measurement system to review the code.

domains
MeasurementRequirements = measreq(SLIST, % Allowed transducertypes
		BOOLEAN, % Acceleration required	BOOLEAN,	% Par_vel 
		BOOLEAN, % Velocity required
		BOOLEAN, % Other
		MeasurementSpec, % Type of measurement
		Direction, % Radial/Axial
		Orientation); % Horizontal/Vertical
predicates
  valid_transducertype(TransducerType, MeasRequirements)
clauses
  valid_transducertype(radial_accelerometer,measreq(Transducertypes,_,_,_,_,_,"radial",_)) :- 
	member("Accelerometer",Transducertypes),!.
  valid_transducertype(axial_accelerometer,measreq(Transducertypes,_,_,_,_,_,"axial",_)) :-
	member("Accelerometer",Transducertypes),!.
  valid_transducertype(radial_displ_transducer,measreq(Transducertypes,_,_,_,_,_,"radial",_)) :- 
	member("Proximity Probe",Transducertypes),!.
  valid_transducertype(x_displ_transducer,measreq(Transducertypes,_,_,_,_,_,"radial","hor")) :- 
	member("Proximity Pair",Transducertypes),!.
  valid_transducertype(y_displ_transducer,measreq(Transducertypes,_,_,_,_,_,"radial","ver")) :- 
	member("Proximity Pair",Transducertypes),!.

Daily Operation

After the initial setup where machine data were entered and the connection between the monitoring system and the diagnosis software was made by the assignment procedure the system is ready for diagnosing faults. As this stage of the process may involve many users with different skills, the actual operation of a diagnosis has been cut down to a simple three mouse-click operation. All of the functions necessary to view, verify, or document a diagnosis are accessed from one screen display (see figure 5). Training in how to use the system for daily operation is therefore kept down to a minimum, and ensures that the operators focuses on what the diagnosis software tells them, rather than bothering about details of how to operate the software in order to get a diagnostic result.

All diagnoses are displayed in a list, each one with an associated certainty level.

The Certainty expresses the level of confidence in the diagnoses. Certainty must not be confused with

probability. If a fault is diagnosed with a certainty of 63% this does NOT mean that the chance (or probability) for having that particular fault is 63%. The number 63% expresses that the symptoms indicating the fault to a degree of 63% matches the 'ideal' symptom values for that fault.

The system is unique here in that it not only shows which faults are most likely (positive levels) but also which faults it not likely to be (negative levels) this is useful for focusing the user's attention away from wasteful paths of analysis.

Another important aspect of the system is that it also demonstrates the integrity and weaknesses of your symptoms. Ideally, the symptoms for a fault are defined such they are `unique' and they cannot be confused with other faults. Unfortunately, this is not always possible, especially in situations where there are several faults present at the same time with similar symptoms. By showing all of the faults simultaneously and by providing a graphical display of the symptoms, the user is able to verify the integrity of the symptoms allocated.

image_f.gif (12426 bytes)
Fig. 5 The diagnosis display

 

Box 3: Prolog Implementation details - The symptom calculation
This box will explain how the symptoms to be used in the diagnosis are calculated. An explanation of how these symptoms are used in the diagnosis is given in section 5.

A bootstrapping technique is used to resolve the dependency and correct sequence of the symptom calculation. The backtracking and recursion facilities of prolog used here, greatly simplifies the job for the programmer of controlling the symptom calculation. Furthermore it simplifies the database structure as no information about the interdependency of symptoms (as explained in Box1) and the sequence of calculation has to be stored in the database.

The sequence of calculating a diagnosis for a machine is as follows:

  1. Find all rules attached to each component of the actual machine configuration (as shown in Fig. 3)
  2. Extract from the rules all symptoms to be calculated
  3. Calculate the symptoms to be used in the diagnosis (the subject of this box)
  4. Make an input vector with all the actual symptom values and a training vector with all the rule limits and do the diagnosis. Refer to section 6.
Before entering the recursive loop where symptoms are calculated, symptoms using the same measurement data are grouped in a list of subgroups in order to avoid extra operations on the measurement database.
SympList = [ [S1, S2, S3], [S4, S5], [S6, S7,S8,S9] ]
Recursive loop 1:
get_symptomgroup is a nondeterministic predicate which under backtracking (*) extracts groups from SympList until a group is found where all symptoms can be calculated, that is, groups where all dependencies for the symptoms can be resolved. There is no requirement to the sequence of the symptoms in the group as the recursive loop will continue until all symptoms has been calculated. calculate _symptoms1 contains another recursive loop to do the actual calculation and keeps returning the remaining symptoms as a group unitil all has been calculated.
Recursive loop 2:
When no total groups can be calculated any more , Prolog backtracks to 2: where the two nondeterministic predicates get_symptomgroup and get_symptom (*) under backtracking extracts the remaining symptoms one by one, to be calculated. If there is symptoms left which cannot be calculated the recursive loop 3: will set the status of these to "unknown"

In the code example shown below all outputparameters are shown as bold text.

% Stop criteria, inputlist is empty, all symptoms has been calculated or set to unknown
calculate_symptoms1([],Values,Values) :- !.
% 1: A whole group can be calculated.
calculate_symptoms(SympList,ValueBuffer,Values) :-
	get_symptomgroup(SympList, SubSympList, SympListRest),
	symptom_group_can_be_calculated(SubSympList,ValueBuffer),
	get_data(SubSympList,MeasurementData),!,
	calculate_symptoms1(SubSympList,MeasurementData,Buffer,
	NewValueBuffer,SubSympRest),
	append(SubSympRest,SympListRest,Rest),
	calculate_symptoms(Rest,NewValueBuffer,Values).
% 2: A whole group could not be calculated, 
calculate_symptoms(SympList,ValueBuffer,Values) :-
	get_symptomgroup(SympList, SubSympList, SympListRest),
	get_symptom(SubSympList,SymptomRef),
	symptom_can_be_calculated(SymptomRef,SubSympList,ValueBuffer),!,
	get_data(SubSymptomList,MeasurementData),
	calculate_symptoms1(SubSympList,MeasurementData,ValueBuffer,
						NewValueBuffer,SubSympRest),
	append(SubSymptomRest,SympListRest,Rest),
	calculate_symptoms(Rest,NewValueBuffer,Values).
% 3: Insert 'unknown' for symptoms which cannot be calculated.
Calculate_symptoms(SympList,ValueBuffer,Values) :-
	get_symptomgroup(SympList, SubSympList, SympListRest),
	unknown_symptoms(SubSympList,ValueBuffer,NewValueBuffer),!,
	calculate_symptoms(SympListRest,NewValueBuffer,Values).

Implementing an Artificial Neural Network

image_g.gif (6638 bytes)
Fig. 6 A neural network

The principles and benefits of ANNs are well known, and commercially available ANN-shells are currently being used in a wide variety of different applications. Basically an ANN is a simplistic emulation of the biological neural network, consisting of artificial neurons (also called neurodes or processing elements) organised into layers.

The input layer distributes the pattern throughout the network, the output layer generates an appropriate response and the middle (hidden) layers acts as a collection of `feature detectors'. Each feature detector neurode looks for a key feature (or features) in the input pattern, and is strongly stimulated (fired) when one is found. The output layer then constructs an appropriate output pattern based on a transfer function of the particular combination of features the middle layers have detected. The number of hidden layers used in the emulation depends on the complexity and accuracy of the network's transfer function.

The presence (or the absence) of key features is indicated by the numeric weight values that are assigned to the neurode input connections. These weights indicate the relative importance of the input connections, provide the ANN with `memory', and thereby allow the network to `learn'. This approach allows ANN-based expert systems to be continuously modified with an updated set of training sample patterns for increased performance, without the need for programming changes or the complex re-construction of rule chains. And after the system has been modified, it can be put immediately into operation. The process of adjusting the factors in the network is called training. The objective of this training is to come to a point where the application of a set of inputs produces a desired set of outputs.

One of the most popular type of commercial ANN-shells, and one of the easiest to implement, is the back propagation ANN. Back propagation uses "Supervised Training" where an input vector is paired with a target vector representing the desired output, together these are called training pairs. Usually a network is trained over a number of such training pairs. An input is applied, the output is compared to the desired, the error is fed back through the network and weights are changed in order to minimize the error. Training vectors are applied sequentially until the error is at an acceptable low level.

Some Other types of ANN’s use "Unsupervised Training" (Self Organization) here the training set consists solely of input vectors. During the training process the network weights are adjusted so that similar inputs produces similar outputs this is accomplished by a training algorithm that extracts statistical regularities from the training set.

A marked disadvantage of back propagation for dynamic applications is the prohibitively large number of training samples required and the subsequently large training times required. For the fault diagnosis of machinery, as well as for many other dynamic applications, the acquisition of many case examples to cover all decision-making eventualities is difficult. Furthermore, when new training samples do become available, the whole training process must be re-started from the beginning.

To avoid the problems associated with commercial shells, a ANN must be developed specifically for machine vibration analysis and diagnosis. Fundamentally, this is a basis-function ANN, widely used in advanced expert system applications due to its flexibility, simplicity, and rapid training. With this type of ANN, the designer has some knowledge of the specific application, and sets up the likely important features as a fixed set of feature detectors in the hidden layer(s). Instead of random weights, basis-function ANNs use fixed weights in the hidden layers (no feedback is used) that sets up a preset bias towards the features deemed important. As the feature detectors are already set, random incoming patterns of symptom values cannot be explicitly categorized as class A or class B, but are instead approximated to either class A or B.

Another advantage of this approach is that because the designer has control over the workings of the hidden layers, the expert system is capable of explaining the reasoning behind its diagnoses. The system is completely open to the user, showing exactly which rules and symptoms were used to diagnose a fault. As commercial shell expert systems have no such control, the reasoning processes used in these systems are never obvious and often obscure.

image_h.gif (3636 bytes)
Fig. 7 Simple example of a basis function implementation. Due to the fixed weightings in the network, diagnostic results follow a normal or Gaussian distribution.

Training the system

A characteristic of Basis-function networks is that the training samples (rules) only need to be expressed as a number of simple statements or facts - not as a long set of chained rules. These facts are based upon a combination of theoretical results, experience and experimental data from case studies, and they are typically expressed as:

IF Acc. > xx m/s2 AND
Temp. > yy deg C THEN
Fault z with Certainty x%

IF Temp. > 400 deg C AND
Press. > 0.9 bar THEN
Fault z with Certainty y%

When a pattern of measured symptom values is presented to the network, a statistical function calculates how close the measured symptom values are to the symptom values used in the training samples, to produce a possible diagnostic outcome (see Fig. 7). In practice, this means that a relatively few number of facts are needed to train the network, with considerably shortened training times.

At least three facts are needed for the network to effectively interpolate between the training sample symptom values and the actual symptom values - a positive affirmative fact; a negative affirmative fact and a non-affirmative (don't know) fact. Essentially a positive affirmative fact states that for a specified symptom value, the network is 80% certain that the specified fault is present. The negative affirmative fact states that for the specified symptom value, the network is 20% certain that the specified fault is not present. The non-affirmative fact states that for a specified symptom value, the network is uncertain (0%) whether the fault is present or not. From experience, these certainty values have been shown to optimize the normalization process, and to thereby increase the speed and efficiency of the network. Using these values also makes the process of defining user facts simple and fast, and contributes to optimizing the diagnostic result.

Before a diagnosis is made, the ANN is trained with all of the facts for a given fault (that is, the ANN's preset bias). In practice, this means that during system operation, input data is evaluated, in a sequential manner, using all of the facts associated with all of the fault types defined in the system. Using The fault "Misalignment" as an example, this follows the procedure:

  1. The amplitude of the symptoms indicating misalignment are extracted from the measured data.
  2. The amplitude of the symptoms are evaluated by the statistical function from all of the facts associated with misalignment.
  3. The network outputs a total evaluated certainty value indicating how close the actual pattern of symptoms are to the ideal pattern of symptoms which indicate misalignment.
  4. Steps 1 to 3 are repeated for all other types of faults.
image_i.gif (4512 bytes)
Fig. 8 A training vector for each type of fault is applied in a sequential manner

As a consequence of this method, the diagnostic result produces a list of certainty values - one for each type of fault detected by the network. Some faults may come out with a very low certainty value (for example 2%) indicating that one or more symptoms associated with the faults have increased slightly. Others may have a high certainty value (for example 76%), indicating that their associated symptoms have increased considerably.

Customizing the system

The structure of the basis-function ANN allows users to easily and quickly introduce their own personal experience into the network via new training samples. For already existing diagnoses, the user can create and add completely new facts to the network, or edit facts that have been copied from the standard rulebase supplied with the system. The defined fact is associated to one particular machine component (in real life, a turbine stage or row, bearing, gearwheel, etc.) and becomes an integral characteristic of that component.

User-defined facts can be used to influence any of the diagnoses in the system. If none of the supplied diagnoses are applicable, the user can also input a completely new diagnosis into the system. For example, if from the user's experience a specific pattern of measured symptom values indicates a fault not already detected by the system, the user can make a positive, negative and null fact from the symptom pattern, and add them to the user-defined rulebase under a new fault name. These facts can be immediately used by the system to diagnose the new fault. The network views the new facts as training samples for the specified diagnosis, and automatically handles the complex statistical interpolation process quickly and efficiently.

In practice, any type of symptom can be defined in the system including frequency spectra or scalar measurements from the monitoring system; a specific frequency band in the spectrum; a process parameter such as temperature or pressure; an absolute value or a value relative to the reference measurement; a level value or a trend on historical data.

Conclusion

`Humanizing' an expert system is the ultimate goal of all designers, especially those concerned with the area of dynamic applications. The idea is of course to produce effective and quality results even when the system is presented with unfamiliar or even incorrect information.

The principles used in the design of the presented system removes the stringency of a conventional rule based system by introducing a more heuristic approach which makes the knowledge acquisition much easier. Updating the rule database by entering a new rule, or adjust an existing, can be done within minutes. The approach also makes it possible to let the users of the system add their own rules or modify existing rules, only by using their specialist knowledge of the application area, rather than being a specialist in expert systems.

Using Prolog for this application has made it possible to concentrate on the logical structure of the program rather than bothering with details of the implementation and programming details of conventional programming languages.

The extensive use of dynamic data structures in the design of this system, as facilitated by Prolog, is a necessity, as the different objects to be diagnosed (in this case machine structures) varies in size and complexity.

The recursive techniques of Prolog is as made for the hierarchic structure of the system where a machine consists of a number of components, which has a number of rules attached, and with each of the rules referring to the symptoms which contains the actual values evaluated by the rules.

The unification facilities of Prolog supported the connection to the data acquisition system as the problem on this interface is to match several characteristics of the transducers and measurement techniques of the data acquisition system, to several requirements defined by the symptoms in order to be calculated correctly. Doing the same job with "case" and "if-then-else" structures of a conventional programming language would be cumbersome.

The unification techniques of multiple values also very well supports the state table approach when decoding a dialogue window by the setting of a new state of the dialogue as a result of a given combination of field values, or by giving a sensible message to the user.

References

  1. 1996, ‘Automated Neural-network and User-defined Knowledge-based Diagnosis system for users of Turbonachinery’ - Turbomachinery Maintenance Congress
  2. 1997, ‘Effective Automatic Expert Systems for Dynamic Predictive Maintenance Applications - The American Society of Mechanical Engineers, Paper No. 97-GT-64
  3. Caudill, M., Butler, C., 1992, "Understanding Neural Networks: Computer Explorations, Volume 2 Advanced Networks" - Massachusetts Institute of Technology
  4. Medsker, L. R., 1994, "Hybrid Neural Network and Expert Systems" - Kluwer Academic Publishers.