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
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.
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:
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.
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.
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
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.
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.
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].
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.