Proceedings of STeP'96. Jarmo Alander, Timo Honkela and Matti Jakobsson (eds.),
Publications of the Finnish Artificial Intelligence Society.

An Object-Oriented Approach to PLC Explanation

Johan Plomp*, Pertti Huuskonen*, Esko Malm* and Jari Paanasalo**
*VTT-Electronics
PO-Box 1100, FIN-90571 Oulu, Finland
**Valmet
Wärtsilänkatu 100
FIN-04400 Järvenpää, Finland


Abstract. In this paper we present a methodology to model PLC programs and use these models to explain the operation of PLC's to process operators. The models provide a representation of the program, hooks for process information and a structure for reasoning processes. The user can query elements of the model for their purpose or state, for an explanation as to how the process reached the current state, and for advice how to proceed. Producing the advice requires a combination of simulation, graph analyses and heuristics.

Keywords: PLC, Object-oriented, Modelling, User-support, Graphs


1. Introduction

The control of industrial machinery is often taken care of by Programmable Logic Controllers (PLC). PLC's may be used to control one or a number of devices, or even the combined control of a number of (partially) self-contained devices. The PLC receives sensor stimuli and controls actuators via mostly digital and some analogue signals. In a typical industrial application, several PLC's, each with its own program, are co-operating to control the machinery. The PLC's provide process information to the control room, where the operator uses dedicated displays to monitor the process. The tasks of control logic include: In case of a malfunction of the machinery, the PLC flags an error and possibly halts the machinery to wait for manual control. The operator in the control room will notice the alarm on the control display, and he will deal with the alarm depending on its familiarity and urgence. Well known alarms will cause the operator to react based on experience. This reaction may also include ignoring the alarm, if the alarm is known to be harmless. In one particular case study approx. 95% of the errors were well-known. The remaining few percents were unknown, or infrequently appearing alarms. In order to deal with the alarms, the cause needs to be located. If the alarm indicates a hazardous situation, or caused the machinery to halt, time is pressing to solve this task. The operator only has limited abilities to monitor the internals of the process, since the control room's terminals typically only show the main process parameters. Often he will not be able to resolve the problem and will order maintenance personnel to check the equipment on the spot, if possible. If no obvious damage is done, the last resort is to analyse the design. Design documents and PLC program listings may occupy several meters of shelve-space and cross-referencing may be poor. Equipment available to the operator to check the PLC's internal status include a programming and debugging device and, surprisingly often, the indicator LED's on the inputs and outputs of the PLC.

Tracing is a repeated cycle of checking the documentation for the erroneous outputs and checking their states using the programming device. Hereafter the "guilty" inputs are determined using the documentation, where experience rules out the unlikely inputs. Subsequently flag-inputs (intermediate variables) are traced back to the segments producing the signal using the cross-connection reference list, and the cycle starts from the beginning. This inefficient cross-referencing between paper-documentation and current state information from the debugger may inhibit the use of the machinery for a relatively long period of time. Such delays may be very expensive for the factory and should thus be minimised by providing the operator with powerful diagnostic tools.

The goal of the LEPO project (acronym for Logic Explanation to Process Operators, [1]) is to provide a tool, which combines documentation and state information in order to aid the operator to analyse the logic on-line. The state information includes history data and the operator is presented with a graphical representation of the code, including the current state of the data. The tool strongly supports the most frequently needed operations, like determining the inputs causing the current output state. It will also include an analysis of the current situation and list a number of causes and possible solutions ordered according to likelihood and importance. The information will be presented on different levels of abstraction, depending on the user's needs. In this paper we will first discuss options to model and represent PLC programs and the models' suitability for operator support of logic examination. Subsequently we will address the types of queries that can be expected and the information sources for the explanations. We continue by presenting the architecture of our prototype and we will conclude by discussing future developments.

2. Modelling PLC software

Traditionally PLC's have been programmed in assembly-like languages, which define the logical operations of the PLC. These assembly programs are generally difficult to read, and even for fluent readers hide much of the functionality of the PLC. It has been attempted to describe the logic on a higher level, borrowing the notation from hardwired combinatorial logic as implemented by gates (function blocks) or relays (ladder logic). These representations were used to describe most of the logical behaviour of the PLC, but were not suitable to represent execution control information satisfactory. For this purpose, one often relied on assembly-like representations, or perhaps a more formal state-machine description. A standard for these languages and representations was developed in IEC 1131 [2]. From the point of view of the logic designers, the higher-level representations may in the future result in better and safer code, but operators are often not been able to fully benefit from these improvements in their controlling tasks.

PLC programming languages differ between manufacturers. In this paper we will use the IEC terminology, which is rather close to the Siemens Step 5 language used in most of our case studies (The recently released S7 is even closer). Program organisation units are:

For sequence structuring IEC furthermore defines:

Operations in these organisation units may be defined in several languages with different representations mostly capable of defining the similar behaviour. IEC 1131-3 defines the following representations:

Fig 1:Some PLC-program language examples.

All organisation units can be represented in IL, ST, LD or FBD languages and function blocks and programs may contain SFC elements as well. In PLC programming ladder diagrams are for historic reasons still very popular [3], and programming itself is very often done in instruction list (assembler-like) languages. However, function block diagrams are intuitively easy to understand.

PLC programs may be very complicated and interdependencies between the used input and output variables are far from obvious. When using equipment controlled by PLC's, operators make their own assumptions about the input/output relationships. By forming this mental model, they are able to make predictions about the behaviour of the logic in certain cases. These predictions are often correct for normal operation modes, but are incomplete, and unexpected alarms may be inexplicable by the mental model. In order to deal with the problem at hand, the operator will have to change, or enhance his mental model. This learning process is best supported by providing the operator with a model of the software, which is close to the mental model the operator has constructed, and which is able to explain its functionality, purpose and current state when queried. Naturally, a familiar modelling method has its advantages in this case, and we found the function block diagram to be a sufficiently versatile language, supporting hierarchies, for modelling most of the PLC software.

Modelling the PLC program by function blocks results in a graph of simple functions interconnected by signals. Since most of the functions are logic operators, the graph is very much like a combinatorial logic circuit. Analogue signals often only appear at the interface with the input- and output-devices. The graph structure is also attractive because of the great number of algorithms applicable to graphs. Furthermore, combinatorial logic has received ample attention in literature.

The graph structure serves well as long as pure logic circuits are being modelled, as used in control operations. While it is possible to represent also sequences (state machine like structures) by function blocks, it does not conform with the model preferred by humans. A sequence is a list of tasks, where each task has a number of conditions which should be met before the next task can be performed. The SFC model is clearly superior to represent this type of behaviour. Therefore we are currently extending our prototype with SFC state machines. We intend to integrate the FBD and SFC models as suggested in the IEC standard.

3. Explaining PLC software

Prerequisites for a good explanation of the operation of a system are a model of its structure and behaviour and a means to communicate this model to the user. As we argued in the previous section, we believe that a combination of the FBD and SFC models will fulfil these requirements. We will now show how we use these models to store background information about the design, simulate the behaviour of the PLC and generate solutions for occurred problems.

3.1 Information sources for explanations

Chandrasekaran [4] defined three categories of explanation of complex systems, which Huuskonen adapted for logic circuits [1]:

The information needed for providing the above user support can be found from the following sources:

A secondary source of information is provided by the simulation of the system. The simulation uses the design knowledge and possibly an initial state from the run-time data in order to produce missing data and/or speculative data.

The different kinds of information must be stored in the elements used for modelling the PLC programs. Extending the object-oriented paradigm for our purposes, we distinguish between the following generic types of information sources within the model:

Let us now analyse more closely what these explanation categories mean for the requirements of our model. We will use an object oriented approach for this analysis.

3.2. Explaining Function Block Diagrams (FBD's)

Function block diagrams in their simplest form consist of generalised function blocks, provided with input and output connectors, which can be interconnected with other function blocks by links representing the values being passed from block output to block input. We will call these links nodes, following the tradition of combinatorial logic circuits. The algorithm mapping the input values to the output values of a function block is a property of a specific type of block. The basic functions as defined in IEC 1131 can be represented by function blocks with a simple non-storing input/output relationship. IEC 1131 programs and function blocks can be implemented by a special type of function block, which defines its mapping algorithm by a graph of interconnected function blocks. Subclasses of these basic elements implement specific functions.

Fig. 2: Example circuit with typical queries

Figure 2 depicts a circuit with a number of typical queries presented by an operator. The following table gives examples of four classes of queries, like those defined by Chandrasekaran and Huuskonen. The behaviour class has been split in static behaviour, where only the operation of the circuit is explained, without knowledge of real-world values, and dynamic behaviour, where the state history is taken into account.

Query type     Examples                  Used information sources

Purpose What is the purpose Class type general information of this block? Intention What is the meaning of Instance parameters (textual info) the state of this node?
Static What is the output of Class type behaviour this block given these inputs? Instance parameters (for function) How can I set this node Instance context (for circuit) to one/zero?
Dynamic Why is this node See static behaviour + state history behaviour one/zero?
Speculative What will happen if See dynamic behaviour, the state I change this node's history is now enhanced by state? simulated data. How can I change this node to one/zero

3.3. SFC State Machine Explanation

The elements of a simplified SFC state machine are:

Conditions and actions resemble function blocks. Conditions can be regarded as special function blocks with only one output, which activates the associated transition. Actions in turn can be any function block with inputs and outputs and they are activated by the associated step. IEC furthermore defines that actions may be represented in SFC format, thus allowing for a hierarchy of state machines. A state machine as a whole can now be regarded as a special kind of function block.

The same types of information sources can be found in the SFC as were used in the FBD. Since actions and conditions are basically function blocks, they can be handled using the FBD information. SFC state machines only introduce states and transitions, with no sub-classes. States and transitions both may contain design information in textual form, and the interconnection (context) of the instances models the behavioural part of the design. A state history can be built by logging the active state or by simulating the behaviour of the state machine.

Typical queries with regard to the state machine are:

Query type   Examples                             Information sources

Purpose What is the purpose of this step? Class type general Intention information For what reason has this transition Instance parameters been inserted? (textual info)
Static Which input combinations will Class type behaviour cause this transition to be active? Instance parameters (for function) Which sequence of inputs will cause Instance context a given step to become active? (for circuit)
Dynamic How did we reach this step? See static behaviour behaviour + state history Why was this transition activated?
Speculative How can we reach this step from See dynamic behaviour, the current one? the state history is now enhanced by simulated data.

When FBD and SFC models are used simultaneously and interconnected, explanations for an element of one of the models will most often also involve queries to the elements of the other model.

3.4. Levels of explanation

We aim to provide different levels of explanation. The highest level would contain a natural language high-level explanation of the current (erroneous) state and the possible causes, while lower levels may give details concerning the state of individual signals. We distinguish four levels of abstraction in our explanation process:

Level          Representations                    User

Diagnostics Machine diagram / Textual Daily operator level
Dependency Dependency graphs with timing Internal/Operator level
Logics level Logic Networks / State Machines Operator
PLC level Sequential instruction lists Programmer/Operator (assembly)

The third level corresponds to the internal models which we presented in this paper and which form the actual representation of the PLC software in our system. By means of using reasoning on these models, we will present the operator with higher level information. The first derived intermediate format consists of dependency graphs, which may be graphically presented to the operator. These dependency graphs then serve as a base for the production of natural language explanations which can be presented to the daily operator.

4. Building the prototype

Following the object-oriented approach, we equip all the elements with methods to display and explain themselves. The result of calling the display method with appropriate arguments (canvas and position) will result in a drawing according to the type and connections of the object, which in turn depends on the objects class. Similarly we provide a virtual method for having the object explain itself to the caller. The concept of explainable objects in this context has been presented earlier by Huuskonen [5], who built a similar prototype system in Lisp.

The explanations are shown to the operator by hypertext and/or by means of a graphical viewer. The user is presented with suitable context dependent query-menus by simply clicking the interesting object.

We are currently implementing a prototype using C++ on a Windows NT platform while supporting portability to UNIX platforms [6]. The prototype constructs the logic network from Siemens Step 5 code via an intermediate representation. The history of the data values can be retrieved utilising a data logger connected to a Siemens PLC. The S5 code filter and the data logger have been realised by our industrial partner.

Since usually not all variables are logged into the state history, it is not always possible to reconstruct afterwards the events in a state machine. We attempt to circumvent this problem by going back to a known state and forward simulating the state machine while logging its active state. This should provide us with logged data after which backtracing can be performed. In the case of function block diagrams, the missing intermediate logic signals can be simulated at any time. Only when time-dependent (internal state) elements are included, this is not necessarily possible.

A typical program consists of a huge number of simple elements, which are interconnected. Interconnection happens within segments, in which case the value of the connection is not stored and only held in an accumulator of the CPU, or between segments, using a stored variable, or flag. The user querying the system will most often be interested in the inputs and outputs of the system, not in the flags. Therefore most queries will cause the system to traverse the constructed graph for the "guilty" inputs. The number of guilty inputs can be quite high, if no limitations are included. Operators performing this same task will use a number of heuristics in order to limit the search space. They will take the states of the nodes into account (if an output of an OR gate is "one", only the inputs which are "one" are guilty), they will have some knowledge of the usual state of the signals based on experience, and they will have a notion of the most urgent or most likely signals. Not all heuristics used by operators can therefore be implemented in our system. However, our implementation takes the state into account and we will provide means to add a notion of urgence to signals. Furthermore, since we have history information, we are able to check the most recently changed signals, which are the most likely candidates for causing the current trouble.

When the user asks for advice how to proceed, the system will give suggestions how the desired state can be reached. In case of logic combinations, this state can be reached by changing a set of input variables. If the state depends on state-machines or state-machine-like logic constructions, a path must be planned in the state machine in order to reach the desired state. The planned path will provide the user with a sequence of actions to be performed, each consisting of a number of input variable changes. Naturally the user may not always be able to set the input variables to any desired value. In fact, most of the input variables will be measurements in the process. We expect that in most cases the operator will be able to get the process back on track by changing the few input variables that are in his control. A better prediction of the success of changing these variables can be made when a model of the controlled process is also provided, so that the sensor readings can be predicted also.

The explanations generated by the prototype are provided in HTML format and it is easy to include links to related documentation. If the process documentation is structured, preferrably using a formal method, the links may provide a quick access to the relevant sections of the documentation [7].

5. Conclusions

Our system is capable of representing PLC logic programs by suitable models, which can subsequently be used to aid in explaining the functionality to the operator. The models have well-known graphical representations which can be shown to the user in order to assist and navigate in the explanation process. The user may query elements of the models for their purpose and their static and dynamic behaviour. State information is essential for the dynamic explanations and is obtained from the PLC for a period of time preceding the explanation time. Missing data can be generated by simulation of the system. The models may also be used to provide the user with cues pertaining to the source of problems, and advice how to get the process back on track. The system presents its models and explanations via a set of user interfaces including a logic viewer and Netscape (for html explanations and documents). The hyper-text based interface facilitates navigation in the explanations and linkage to process documentation.

We expect our system to be a valuable addition to the tools available for process operators, resulting in a decrease of time needed to trace faults in the controlled system, while increasing the operator's understanding of the process and its control.

While our system will be capable of dealing with most encountered structures in PLC logic programs, its power does depend on the style used in the program and the provided documentation. A well-documented program will automatically provide additional textual information in our explanation, clarifying the purpose of program elements. Likewise, an ill- structured program will be difficult to understand, even with our additional explanations. State machines are implemented in various ways, and their recovery is not a trivial task. In the worst case parts of the state machine are spread over the code, which may inhibit our system from recognising it as a state machine. The best results can be achieved when the use of the explainer is already taken into account in the design of the PLC's software and a structured programming approach is adopted. Naturally when using suitable models (FBD/SFC) already in the design phase, these models don't need to be retrieved from the assembly code as happens now.

We are currently extending our system with the state-machine handling as presented in this paper, after which we will test the functionality and suitability of our system in four different industrial environments. The explanations will be enhanced according to the wishes of the users and will be tailored for use by maintenance personnel and operators.

Acknowledgements

We gratefully acknowledge the support provided by TEKES for this project, and by our industrial partners.

References

[1] Pertti Huuskonen, Kari Kaarela, Jyrki Okkonen, Anne Väisänen,
"Explaining Control Logic to Process Operators", 8th Int. Conf. on Industrial & Engineering Applications of Artificial Intelligence & Expert Systems, Melbourne, Australia, 5-9.6.1995

[2] IEC 1131-3
"IEC 1131-3, Programmable Controllers, Part3: Programming languages", International Electrotechnical Commission, 1993, 207 p.

[3] Jeremy R. Pollard,
"Ladder Logic Remains the PLC Language of Choice", Control Engineering, April 1994, pp. 77-79.

[4] Chandrasekaran, B. et al.,
"Explaining Control Strategies in Problem Solving", IEEE Expert, Spring 1989, pp. 9-24.

[5] Pertti Huuskonen, Anneli Korteniemi,
"Explanation Based On Contexts", Proc. 8th IEEE Conf. on Artificial Intelligence for Applications, Monterey, California, March 2-6, 1992, pp. 179-185.

[6] Malm, Esko-Juhani,
"Object-oriented methods for explaining the behaviour of control logic", Master's Thesis, Dept. of Electrical Eng., Univ. of Oulu, Finland, 68 p. (Finnish)

[7] Kaarela, Kari,
"Enhancing communication of plant design knowledge", Dissertation, Technical Research Centre of Finland, VTT Publications 272, 191 p. 15