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.

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 personnels 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.

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 PLCs are
adaptable, modular, user-friendly and acquired at low cost.
However, because of PLCs 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

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
states

PLC
outputs

Detailed actuator
behaviors

PLC
program

Sensors

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.

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 informationtechnical 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.

3.

DIAGNOSTIC KNOWLEDGE ACQUISITION

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

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

Model-based
knowledge acquisition

Pneumatic and hydraulic

circuit diagrams

PLC
I/O board

Artificial
knowledge acquisition

Knowledge base

Real-time
data acquisition

Database

Diagnostic reasoning

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

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.

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
fault < (signal, 1)

or

LS1
Valve for movement
to the bottom
LS2

Table

Valve for movement

to the top

fault < (signal, 0)

Figure 4. An elevator example

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.

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)

In the end we get a non-decomposable and minimized logical

expression of S(x), i.e.

Movement to the bottom is not finished, represented as

S ( x) = 1 ({ski }) + 2 ({ski }) + = i ({ski })

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

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

where i({ski}) is also a factor that makes S(x)=1 and is

composed of input signals or non-decomposable flag signals.

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 systems 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. {sk} denotes the
combination of several PLC signals connected by logical and
which is written as in model expressions, and ({sk}) is the
state of {sk}, {s k } = s1 s2 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({ski}) 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

( j 1)i ({ski }) = j1 ({sk 1}) + j 2 ({sk 2 }) + = ji ({ski })

(1)

where ji({ski}) is a factor that makes (j-1)i({ski})=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 nondecomposable flag signals. Then substituting the decomposition
expression at every level into that at its higher level, we have

ni ({ski }) ( n1)i ({ski }) 1i ({ski }) S ( x)

(3)

(2)

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 f1({sk1}), f2({sk2}), , respectively. That is
F ( x) = S ( x) = f1 ({sk 1}) + f 2 ({sk 2 }) + = f ({ski })

(4)

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 ({ski }) = f1 ({sk1}) + f 2 ({sk 2 }) + = f i ({ski })
i

(5)

Thus, the logical expression at the faulty state of the

manufacturing system is obtained as
F ( x) = s ( x) = f i ({ski })

(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 c1(t), c2(t), , thus
C (t ) = c1 (t ) c2 (t ) = c j (t )

(7)

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
C (t 1) = c1 (t 1) c2 (t 1) = c j (t 1)

(8)

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 i1(t),

i2(t), , thus

conn(N, M), where N and M are nodes, we express that a value

is propagated through the causal connection or else observed:

I (t ) = i1 (t ) i2 (t ) = i j (t )

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

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

(9)

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 )

I (t ) = i j (t ) = i1 (t ) + i2 (t ) + = 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 (t ) = c1 (t ) + c2 (t ) + = c j (t ) = 1
j

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

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

(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
j

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

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.

(13)

5.

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), , value(in(Comp, n), In_n),
table(Comp, Mode, In_1, , 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

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) = fi ({ski }) = 1

(14)

to substitute the actual state values of signals in PLC into

the above equation and calculate if any term fi({ski})=1.
to acquire the combined pattern corresponding to the term
fi({ski})=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 reorders 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 authors 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 PLCs, 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
(DKSME96), 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.