Sie sind auf Seite 1von 6

A Knowledge-Based Real-Time Diagnostic System for PLC Controlled Manufacturing Systems

W. Hu*, M. Schroeder* & A.G. Starr** *Department of Computing, City University London, London, EC1V 0HB, UK E-mail: w.hu@cs.city.ac.uk, msch@cs.city.ac.uk **School of Engineering, University of Manchester, Manchester, M13 9PL, UK E-mail: a.g.starr@man.ac.uk

ABSTRACT

This paper presents an approach to a knowledge-based real-time diagnostic system for PLC controlled manufacturing systems. A general structure of the diagnostic system is implemented, which is the extension of an existing diagnostic system we developed in recent years. Diagnostic knowledge is acquired artificially and by model-based methods from the pneumatic and hydraulic circuit diagrams and the PLC program. The knowledge is the description of the functional and operational logic embedded in the PLC in a more usable form compared to that held in the mind of manufacturing system designers themselves. These models contain the design and engineering knowledge about the manufacturing system to be diagnosed. During the operation of the manufacturing system, the diagnostic system can continuously acquire data from the PLC, identify possible faults, search for their causes and suggest corrective actions.

1.

INTRODUCTION

In order to meet the quest for automation and flexibility, many complex manufacturing systems are controlled by Programmable Logical Controllers (PLC) [1]. This is because that PLC’s are adaptable, modular, user-friendly and acquired at low cost. However, because of PLC’s inflexible programming system, their capability in fault detection and diagnosis is limited. Operation faults associated with PLC control processes often puzzle the maintenance personnel at workshop level. Statistics shows that these faults occur most often (about 70%) among all kinds of faults, and when such a fault occurs, about 80% of downtime is spent locating its source and only 20% is spent on the repair [2]. The availability and productivity of these automated manufacturing systems can be improved by shortening their downtime resulted from faults. This has led to the development of automatic diagnostic tools or systems.

Usually when a fault occurs, maintenance personnel will check the Input/Output (I/O) of the PLC at first. Then he/she will try to use a PLC software debugging tool to trace the signals in the PLC with the help of PLC source code, documentation on the machine design and the observations, until the input signals, which have caused the fault, is found. Sometimes this does work

with a sacrifice of time. However, this kind of diagnosis process has been found with the following bottlenecks [3]:

The PLC programming devices do not support automatic analysis of the logic circuits, which could help in finding the most likely causes of the fault.

Most PLC code is graphically presented by function block diagrams or ladder logic. It is difficult to read and functionality of complex programs is hard to recover.

There is a huge amount of documentation on the mechanical, electrical and operative design of a complex system. Most of them are needed in order to solve a problem, but there are often not available at work-site.

The maintenance personnel’s observation of the

manufacturing system may be wrong or incomplete, which may lead to incorrect diagnosis. Therefore, automatic algorithms and intelligent system approaches need to be investigated to improve the efficiency of diagnosing complex PLC controlled manufacturing systems.

This is an area which is attracting more and more researchers and industrial partners. Some relevant diagnostic methods as well as systems have been reported in literatures. Jarvis proposed an approach which was used to develop a model of a PLC controlled assembly line. The objective of the approach was to simulate the sequence of manufacturing events that occur for each station in the assembly line. During the simulation, meaningful comparisons were made between the simulated state of the system and the observed state of the system (as specified by a snapshot of the PLC state) [4]. Plomp described a prototype of a support tool for PLC analysis. The tool was motivated by observations regarding the inefficiency of current PLC software debugging tools and the poor availability of cross-referenced documentation and manuals. The prototype analyses the temporal signal dependencies within the PLC logic model and a history of logged values [5]. Matthias presented a method to model event based systems and described how post-mortem diagnosis based on the use of such models can be performed for PLC controlled equipment [6].

In this paper, we employ knowledge-based techniques to implement intelligent and real-time diagnosis of PLC controlled manufacturing systems. The diagnostic system is constructed

mainly by associating the machine states (indicated by PLC signals) with the possible faults. The association which is represented as diagnostic knowledge in the diagnostic system, is acquired by an artificial method or using model-based methods.

2. PLC CONTROL OF MANUFACTURING SYSTEMS

In a manufacturing system, PLC is used to control the behaviors of the system. The operating actions of the system and the sequence of these actions were edited beforehand into the control program by the manufacturer. The control program sets a series of operations of the manufacturing system, which tells the PLC how to control a system.

The control loop of a PLC and the overall model of a PLC controlled manufacturing system can be described as in Figure 1 and Figure 2 respectively [4].

For (ever)

{

Read all PLC inputs; Evaluate the PLC program; Set all PLC outputs;

}

Figure 1. The PLC control loop

 

Actuator

  Actuator PLC

PLC

 

states

outputs

Detailed actuator

PLC

behaviors

program

Sensors   PLC

Sensors

 
Sensors   PLC

PLC

 

inputs

Physical model

Control model

Figure 2. The overall model for a PLC controlled manufacturing system

The PLC controls the manufacturing system according to its control program, which is embedded in the controller. When a fault occurs, the current states of all sensors or actuators are saved as an array of input, output or flag signals in the PLC memory. Therefore, the PLC program is the basis of diagnosis in a PLC controlled manufacturing system.

3. THE DIAGNOSTIC SYSTEM DESIGN

From Figure 2 we can know that, when diagnosing a PLC controlled manufacturing system, we always have to consider both of its two sub-systems, i.e., the control system (PLC) and the physical system (the system being controlled), which are linked by wiring diagrams. These wiring diagrams are maintained separately from the PLC program and the pneumatic and hydraulic circuit diagrams those typically constitute the documentation for the physical system. Usually in order to

understand the behavior of the manufacturing system, we need to understand how both of its two sub-systems behave and how they interact with each other [1]. That is to say, we need to have knowledge about their linkage, the wiring diagrams, which as mentioned above, include the PLC program and the pneumatic and hydraulic circuit diagrams.

PLC controlled manufacturing systems have automatic monitoring available for faults characterized by discrete state signals in their PLC memory. These discrete state signals indicate the operating states of the manufacturing systems, by which further diagnosis can be carried out. These signals can be obtained directly using a real-time linkage (RS232 series interface) between the PLC I/O board and the diagnostic system computer (This can also be carried out via several information- technical levels using LAN), which are the major contents of the diagnostic system database.

It can be seen that, an automatic diagnosis of PLC controlled manufacturing systems is to use specific reasoning algorithms to search all the possible fault causes under the help of the relevant diagnostic knowledge as well as real-time data. Therefore, a knowledge-based system scheme is suitable for the diagnosis of complex PLC controlled manufacturing systems. The knowledge acquisition task involved in the development of such a system is extremely time-consuming, thus more disincentive. If all the diagnostic knowledge is acquired artificially from a large amount of documentation for the physical systems, they will often be inconsistent and incomplete, and therefore lead to false diagnosis or inaccurate diagnosis. Model-based knowledge acquisition mechanisms can help to solve this problem, which will result in the improvement of knowledge acquisition and diagnosis efficiency.

Figure 3 is the general structure of a knowledge-based real-time diagnostic system for PLC controlled manufacturing systems. It is the extension of an existing diagnostic system we developed for a Flexible Manufacturing System (FMS) [7]. The system can continuously acquire data from the PLC, identify possible faults, search for their causes and suggest corrective actions. The knowledge associated with pneumatic and hydraulic circuit diagrams is acquired artificially by knowledgeable engineers, while the knowledge associated with the PLC program is acquired from the source code running the PLC automatically or half automatically by model-based methods.

4. DIAGNOSTIC KNOWLEDGE ACQUISITION

4.1 Artificial knowledge acquisition

In a PLC controlled manufacturing system, there are some alarms for the purpose of self-protection of the system. Each alarm is normally indicated via one PLC signal or the combination of multiple PLC signals. These alarms protect the manufacturing system from working in an error condition. An alarm appears when there is a fault such as the temperature is too high (temperature of a motor, temperature of a bearing, temperature of the control cabinet,

Manufacturing system

PLC

program

Manufacturing system PLC program Pneumatic and hydraulic circuit diagrams PLC I/O board Artificial knowledge acquisition

Pneumatic and hydraulic circuit diagrams

system PLC program Pneumatic and hydraulic circuit diagrams PLC I/O board Artificial knowledge acquisition Model-based

PLC

I/O board

Pneumatic and hydraulic circuit diagrams PLC I/O board Artificial knowledge acquisition Model-based knowledge

Artificial

knowledge acquisition

diagrams PLC I/O board Artificial knowledge acquisition Model-based knowledge acquisition Real-time data

Model-based

knowledge acquisition

knowledge acquisition Model-based knowledge acquisition Real-time data acquisition Knowledge base Database

Real-time

data acquisition

knowledge acquisition Real-time data acquisition Knowledge base Database Diagnostic reasoning Diagnostic

Knowledge base

acquisition Real-time data acquisition Knowledge base Database Diagnostic reasoning Diagnostic report 1. Possible

Database

Real-time data acquisition Knowledge base Database Diagnostic reasoning Diagnostic report 1. Possible faults 2.

Diagnostic reasoning

acquisition Knowledge base Database Diagnostic reasoning Diagnostic report 1. Possible faults 2. Fault causes 3.

Diagnostic report

1. Possible faults

2. Fault causes

3. Corrective actions

Figure 3. The general structure of the diagnostic system

temperature of the hydraulic and cooling oil);

the pressure is too low (hydraulic and pneumatic pressure);

the circuit is broken (the current is too high);

the oil level is not high enough (hydraulic and cooling oil);

an error operation is made (protection doors, push buttons, switches);

etc. Knowledge about such a fault alarm can be described as

fault < (signal, state) {, (signal, state)}

where {} means it may be the combination of multiple signals.

Sometimes the faulty state of a signal is 0. Sometimes it is just the opposite, i. e. the faulty state of a signals is 1. This will be referred to the documentation (PLC program, pneumatic and hydraulic circuit diagrams) of the concrete manufacturing system. In a FFS-1500-2 FMS for example, it is faulty when the state of a signal for temperature protection is 0, or when the state of a signal for current protection is 1. These two kinds of faults can be represented as

or

fault < (signal, 1)

fault < (signal, 0)

Sometimes a fault may be indicated via the combination of states of two or more signals. In these cases, it is faulty when the states of all the signals match the observed state values. It may not be faulty if only the state(s) of one signal or a part of the signals in the combination are matched with the observed state values.

Except knowledge about fault alarms, there is another kind of knowledge that can be acquired artificially from a PLC controlled manufacturing system. This kind of knowledge is about faults that the actions do not finish after a control command is received. Obviously this kind of fault exists only under the conditions that a control command is received and the actions do not finish. An unfinished action may appear to be that an actuator is not in its proper position.

Figure 4 is an example of an elevator in a PLC controlled production line. When there is a control command, a relevant valve will then be activated and make the elevator move the table to its top or bottom position. At the top and bottom positions of the table, there are two limit switches (LS1 and LS2) which are used to detect the current position of the table.

LS1 Valve for movement to the bottom LS2 Table Valve for movement to the top
LS1
Valve for movement
to the bottom
LS2
Table
Valve for movement
to the top

Figure 4. An elevator example

When a control command is issued but the elevator does not move or the table does not reach its proper position, a fault occurs. Suppose “comm1” and “comm2” are the commands for movement to the top and bottom positions respectively, in the normal working conditions of the elevator, there are

normal < (comm1, 1), (LS1, 1), (LS2, 0) normal < (comm2, 1), (LS2, 1), (LS1, 0)

Therefore, the following diagnostic knowledge about the elevator faults can be acquired.

Movement to the top is not finished, represented as

fault < (comm1, 1), (LS1, 0), (LS2, 0)

fault < (comm1, 1), (LS1, 0), (LS2, 1)

Movement to the bottom is not finished, represented as

fault < (comm2, 1), (LS1, 0), (LS2, 0) fault < (comm2, 1), (LS1, 1), (LS2, 0)

Limit switches may be error, represented as

fault < (LS1, 0), (LS2, 0) fault < (LS1, 1), (LS2, 1)

Similarly, other diagnostic knowledge can be acquired artificially from the pneumatic and hydraulic circuit diagrams of the manufacturing system.

4.2 Model-based knowledge acquisition

The behavior of a PLC controlled manufacturing system is defined in its PLC program [6]. The PLC program determines the system’s control processes which are generally characterized by logic control and sequential control. Therefore, by modeling the manufacturing system behavior, we can acquire a large amount of diagnostic knowledge. The following models have been developed for this purpose.

4.2.1 Model based on PLC control logic. In this model, all variables associated with PLC control logic are described in a binary form. These binary variables include all the signals in PLC (input signal, output signal and flag signal, etc.). The model is constructed by these variables in accordance with PLC control logic. The detailed algorithm is as follows.

We assume that S(x) is the state function of an operating state signal of the manufacturing system, S(x)=1 means that the operation associated with S(x) is on, while S(x)=0 means that the operation associated with S(x) is off. {s k } denotes the combination of several PLC signals connected by logical “ and” which is written as “ ” in model expressions, and ({s k }) is the

state of {s k }, {s

k

}

=

s

1

s

2

s

k

.

In practice, the logical expression of S(x) is given by signal decomposition according to PLC control logic. Therefore, if we define ji ({s ki }) as the i-th term of S(x) at the j-th level, then the result of the decomposition of S(x) at the j-th level is

(1)

(

j

1)

i

({s

ki

})

=

j

1

({s

k

1

})

+

j

2

({s

k

2

})

+

=

i

ji

({s

ki

})

where ji ({s ki }) is a factor that makes (j-1)i ({s ki })=1. It may be a signal or the combination of several signals connected by logical “ and”. Except for the terms expressed by input signals or flag signals that are unable or need not to be decomposed, other terms usually can be decomposed further according to PLC control logic.

The decomposition can proceed level by level in the same form till all the terms are expressed by input signals or non- decomposable flag signals. Then substituting the decomposition expression at every level into that at its higher level, we have

(2)

ni

({

s

ki

})

(

n

1)

i

({

s

ki

})

1

i

({

s

ki

})

S

(

x

)

In the end we get a non-decomposable and minimized logical expression of S(x), i.e.

({s

(3)

S(x)

=

1

({s

ki

})

+

2

ki

})

+

=

i

({s

ki

})

i

where i ({s ki }) is also a factor that makes S(x)=1 and is composed of input signals or non-decomposable flag signals.

Now, let F(x) be the fault state function of the manufacturing system. F(x)=1 means that a fault has occurred, while F(x)=0 means that there is no fault at all. If F(x) equals to S(x), all the fault terms that make S(x)=1 can be determined, which are expressed as f 1 ({s k1 }), f 2 ({s k2 }), , respectively. That is

(4)

F (x)

=

S(x)

=

f ({s

1

k

1

})

+

f ({s

2

k

2

})

+

=

f ({s })

ki

i

If F(x) equals to the inverse state of S(x), the first step will be to extract the logical expression of the inverse S(x). Each term of the expression is a combined pattern of causes of the fault, i.e.

S(x)

=

i

i

({s

ki

})

=

f ({s

1

k

1

})

+

f ({s

2

k

2

})

+

=

i

f ({s

i

ki

})

(5)

Thus, the logical expression at the faulty state of the manufacturing system is obtained as

F (x)

=

s(x)

=

i

f ({s

i

ki

})

(6)

From (4) and (6) diagnostic knowledge about PLC logic control can be easily obtained. This kind of knowledge describes the logic relationship between every fault and its cause(s).

4.2.2 Model based on PLC control sequence. This model consists of a certain number of system states and state changes in the PLC control sequence. It describes the sequential changes of the manufacturing system operating states. The action in a certain step is not only related to the control commands in this step, but also related to the step conditions in the previous step. The current step can only be started under the condition that the previous step has finished and the current control commands have been received. Whether a step is finished or not is decided according to its step conditions. So, this model can be constructed as follows.

We assume that C(t) is the combined state of all the step

conditions in the t-th step. Since each condition is normally a PLC signal, marked by c 1 (t), c 2 (t), , thus

(7)

C(t)

=

c (t)

1

c (t)

2

=

j

c (t)

j

where “ C(t)=1” indicates that the step conditions are satisfied and the next step can be started, and “ C(t)=0” indicates that the conditions are not satisfied and the action sequence cannot be carried out. Similarly, the step conditions of the previous step is expressed by

(8)

C(t

1)

=

c (t

1

1)

c (t

2

1)

=

j

c (t

j

1)

Now we can let I(t) be the combined state of all the control commands in the t-th step, just like step conditions. Notice that

every control command is also a PLC signal, marked by i 1 (t),

i 2 (t),

(9)

, thus

I(t)

=

i (t)

1

i (t)

2

=

j

i (t)

j

where “ I(t)=1” indicates that the commands are received while “ I(t)=0” indicates not received.

As mentioned above, if we let F(t) be the faulty state of the step, “ F(t)=1” indicates that the step is faulty. In the case where a fault exists, it is possible that

F(t) = C(t 1)I(t)

(10)

When F(t)=1, C(t-1)=1 and I(t)=0, it means the previous step has finished and current step has started, but the control commands have not been received. From

I

( )

t

=

j

i

j

( )

t

=

i

1

( )

t

+

i

2

( )

t

+

=

j

i

j

( )

t

=

1

(11)

the exact command that is not received can be found. It is also possible that

F(t) = I(t)C(t)

(12)

When F(t)=1, I(t)=1 and C(t)=0, it means the current control commands have been received, but the action has not finished. Similar to the first case, from

( )

C t

=

c

j
j

( )

t

=

c

1

( )

t

+

c

2

t

( )

+

=

j

c

j

t

( )

=

1

(13)

the exact condition that is not satisfied can be found.

4.2.3 Model based on logic programming. This model was first developed and used in REVISE [8], a non-monotonic reasoning system that revises extended logic programs [9]. It is based on logic programming with explicit negation and integrity constraints and provides two-value revision assumptions to remove contradictions from the knowledge base.

The behavior of the system to be diagnosed is coded as an extended logic program. To express the assumption that the system works correctly we use negation by default. To model the behavior of the PLC we employ the following schema:

value(out(Comp, k), Out_k)<

mode(Comp, Mode), value(in(Comp, 1), In_1), table(Comp, Mode, In_1,

, value(in(Comp, n), In_n),

, In_n, Out_1,

, Out_k,

, Out_m)

where the predicate “ table” consists of facts that describe the I/O relation of the components wrt the current mode. To express the default assumption that the components are working fine we use negation as default:

mode(Comp, ok)< not mode(Comp, ab)

The above schema captures the behavior of a single component. Additionally, we have to code the propagation of values through the system. Given the causal connection of the system as relation

conn(N, M), where N and M are nodes, we express that a value is propagated through the causal connection or else observed:

value(N, V)< conn(N, M), value(M, V)

value(N, V)< obs(N, V)

These modeling concepts allow predicting the behavior of the system to be diagnosed in case it is working fine. To express that normality assumptions may lead to contradiction between predictions and actual observations we introduce integrity constraints, such as

false< value(N, 0), obs(N, 1) false< value(N, 1), obs(N, 0)

A contradiction is always based on the assumption that the

components work fine, i.e. the default literal are false. In general,

we can remove a contradiction by partially dropping some of

them. Technically, we compute such a diagnosis by changing a minimal set of revisable to remove the contradiction from the initially contradictory program. REVISE allows one to select different minimality criteria such as minimality by set inclusion, cardinality, or probability. It caters for multiple faults and fault modes such as "stuck at one" or "stuck at zero". Since REVISE distinguishes clearly topology and the behavior of the system to

be diagnosed, it provides an easy way to maintain and extend a

component library.

5. DIAGNOSTIC REASONING

When the manufacturing system fails to work, diagnostic reasoning is performed and produces a diagnostic report in the

end. The report includes the possible fault positions, fault causes and the corresponding corrective actions. The reasoning is based

on the diagnostic knowledge in the knowledge base as well as

real-time fault data in the database. For different diagnostic knowledge, we have developed different reasoning mechanisms, which are introduced in the following.

5.1 Diagnostic reasoning for logic control faults

Having had the logical expression at a fault state of the machine

using the logical diagnosis model, we can see that each term of

the expression represents a possible combined signal pattern of fault causes. The following step is to analyze all those possible combined patterns, till finding an input signal that causes the fault or an non-decomposable flag signal. Consequently the fault is located. The detailed diagnostic procedure is as follows.

to compare the faulty state of S(x) with the current state of signals in PLC, if they are the same, then a fault is thought to have occurred.

to establish a logical equation about the fault state, i.e

F

(

x

) =

i

f

i

({

s

ki

}) = 1

(14)

to substitute the actual state values of signals in PLC into the above equation and calculate if any term f i ({s ki })=1.

to acquire the combined pattern corresponding to the term f i ({s ki })=1. The pattern shows the exact cause of the fault.

Using this reasoning method, we must make sure that, at a fault state, the combined patterns in the logical expression cover all the possible fault causes, and are independent to each other.

5.2 Diagnostic reasoning for sequential control faults

Under normal operating conditions, the PLC controls the manufacturing system according to the sequence of actions. At the same time, each step in the control sequence is monitored by the watch-dog-timer in PLC. If the machine is in normal condition, it will operate sequentially according to the preset sequence. Therefore, overstaying of the machine control status at a certain action suggests the occurrence of a fault.

Upon the detection of a sequential control fault, diagnosis is carried out using the knowledge about the sequential control of the manufacturing system. At first the current values of all the signals in PLC will be read. Then the start conditions of every step are analyzed according to these values, in conjunction with the control sequence. By doing so, the step where a fault has occurred can be determined. In the end, each control command and condition of the faulty step are checked, till the exact fault cause is found.

5.3 Diagnostic reasoning based on logic programming

The REVISE engine consists of three components: A conflict generator, a hitting-set tree, and a preference ordering. The conflict generator takes as input a partial diagnosis and determines whether there are still constraints violated. If so, it returns the assumptions involved in this violation. These conflicts are returned to the hitting-set tree, which contains the partial diagnoses. The partial solution sent to the conflict generator is expanded according to the newly generated conflict. The decision, which partial diagnosis to expand next, is determined by the preference ordering. This component re- orders the partial diagnoses in the tree according to the users’ preference criteria such as minimal by set-inclusion, cardinality, or probability. If the conflict generator does not find any conflicts anymore, the partial diagnosis is a diagnosis. For details see [9].

6.

CONCLUSIONS

Manufacturing systems present an important domain of diagnostic application. The development of automated diagnostic techniques and systems can help to minimize downtime and maintain an efficient output. This is a need common to all manufacturing enterprises. The knowledge-based real-time diagnostic system is developed to meet this need. It can continuously acquire data from the PLC, identify possible faults, search for their causes and suggest corrective actions.

The problems and complexity in after-market development of such a diagnostic system have left the manufacturers of the manufacturing systems as the best people in a position to apply diagnosis effectively to their products. There are diagnostic functions available in modern PLC controlled manufacturing systems. However, they are still limited and need further

development. The prospects are greater where larger investments are concerned, as the cost of a fault is higher.

This is a rapidly developing area which has attracted more and

more researchers. Good results have been achieved, but there is still much work to do. From the author’s point of view, future work will concentrate to

refine the diagnostic knowledge acquisition methods and reasoning algorithms, so as to improve the efficiency of the diagnostic system.

investigate models that incorporate PLC control on continuous processes of the manufacturing systems, implementing a systematic integrated methodology for prediction, monitoring and diagnosis.

define an embedded diagnosis system approach which will integrate the diagnostic models in the PLC’s, so that faults can be diagnosed in real time.

7.

REFERENCES

[1] J. Jarvis and D. Jarvis, "Life Cycle Support for PLC Controlled Manufacturing Systems", in A. Storr and D.H. Jarvis (Eds), Software Engineering for Manufacturing Systems:

Methods and CASE Tools, Chapman & Hall, 1996. [2] R.L .Kegg. "On-line Machine and Process Diagnostics," Annals of the CIRP, 32(2), 1984, pp. 469-473. [3] P. Huuskonen, K. Kaarela, J. Okkonen and A. Vaisanen, "Explaining Control Logic to Process Operators," Proc. of 8th Int. Conf. On Industrial & Engineering Applications of AI & Expert Systems, Melbourne, Australia, 1995, pp. 203-211. [4] J. Jarvis and D. Jarvis, "Simulation of a PLC-Controlled Assembly Line," Proc. of 9th European Simulation Symposium, 1997, pp. 342-346. [5] J. Plomp, P, Huskonen and E. Malm, "Operator and maintenance Support Through PLC Logic Analysis and Hypertext Documentation," Proc. of Int. Conf. on Condition Monitoring and Diagnostic Engineering management, 1997, pp.

354-363.

[6] Z. S. Matthias, "Model-based Diagnosis of PLC Controlled Assembly Equipment," Proc. of 6th Int. Conf. On Data and Knowledge Systems for Manufacturing and Engineering (DKSME’96), Tampe (Arizona), USA. 1996, pp. 11-22. [7] W. Hu, Research on a Quality-Control-Based Fault Diagnosis System in a Flexible Manufacturing Environment, PhD Thesis, Huazhong Uni. Of Sci. & Tech., 1995. [8] J. J. Alferes and L. M. Pereira, Reasoning with Logic Programming, 1996, LNAI 1111, Springer-Verlag. [9] C. V. Damasio, Luis Moniz Pereira, and Michael Schroeder, "REVISE: Logic Programming and Diagnosis," Proc. of the Conf. on Logic Programming and Non-monotonic Reasoning LPNMR97, 1997, LNAI 1265, Springer-Verla.