In this article 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.
\nKeywords: PLC, Object-oriented, Modelling, User-support, Graphs
\n1. Introduction
\nThe 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:
\nControl – Changing of process parameters as a reaction to changes in the process or its environment
\nSequences – Performing a number of sequential steps, where the progress is guarded by conditions concerning the process and time.
\nInterlocks – Protection of the device or its users by a set of monitoring processes, which disallow some actions or halt the machinery under certain conditions.
\nAlarms – Warns the operator of abnormal process behaviour, where human intervention is required to bring the process back on track. Logic is used both for fault detection and unnecessary alarm suppression.<\/p>\n
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.
\nTracing 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.<\/p>\n
2. Modelling PLC software<\/p>\n
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.
\nPLC 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:<\/p>\n
Programs – Highest organisation unit; instantiated in resources
\nFunction blocks – User defined, takes arguments, returns data elements, may contain internal state, instantiated in programs or other function blocks
\nFunctions – Simple functions, often provided by manufacturer, takes arguments, returns one data element, no internal state, instantiation within function blocks.
\nFor sequence structuring IEC furthermore defines:<\/p>\n
Sequential Function Charts – State machines consisting of steps with associated actions and guarded transitions
\nOperations 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:
\nIL – Instruction List, a text-based assembler-like programming language listing a sequence of simple instructions
\nST – Structured text, a text-based simple programming language with a pascal-like syntax
\nLD – Ladder Diagram, a graphical language using a relay-based notation.
\nFBD – Function Block Diagram, a graphical function-block oriented representation like used for asynchronous logic
\nSFC – Sequential function charts have their own graphical representation with steps and transitions<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
3. Explaining PLC software<\/p>\n
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.
\n3.1 Information sources for explanations<\/p>\n
Chandrasekaran [4] defined three categories of explanation of complex systems, which Huuskonen adapted for logic circuits
\nExplaining the meaning – the purpose of parts of the design is explained to the user
\nExplaining the behaviour – reasoning how the current state was reached
\nSpeculative help – assisting the user to find ways to reach a desired state
\nThe information needed for providing the above user support can be found from the following sources:<\/p>\n
Domain knowledge – basic knowledge about the type of elements used to build application, e.g. basic logic elements in FBD’s are or, and, not and xor gates, as well as RS\/SR flip flops and delays.
\nDesign knowledge – consisting of the actual design as coded into the program and the design documentation, which is partially provided with the program code. The program and it’s documentation follow strict syntactic rules, which facilitates modelling the knowledge.
\nRun-time data – monitoring some key elements while the program is running provides us with information of the behaviour of the program.
\nA 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.<\/p>\n
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:<\/p>\n
Class information – information pertaining to the type of object; differs between distinct classes, like nodes and functions, and between ancestors and descendants of a particular class. This information is available already during the design of the system; it persists between different runs and is independent of the modelled program. (domain information)
\nInstance context – information pertaining to the configuration of the object instance; which other elements are associated with the studied instance and how. The instance context is created at start-up, when the modelled program is read into the system. It is the same during one run and the state of the system does not affect it. (design information)
\nInstance parameters – features that make one object instance differ from another instance of the same class, other than by its context. Objects may e.g. implement a function with certain options or parameters. This knowledge is obtained from the modelled program at start up and will, like the instance context, not change during one run. Also design-related documentation can be stored in instance parameters.
\nDynamic data – Values of the instance attributes which change continuously as a result of user interaction or changes in the monitored device. In our prototype this involves mainly the state history – the collection of states and associated times for instances which have a run-time value, obtained by monitoring the running system (logged data) or by simulating the system. The current state is a special case being the concurrent state of the element or system at one observed time. (run-time data)
\nLet 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.<\/p>\n
3.2. Explaining Function Block Diagrams (FBD’s)<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
In this article 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, […]<\/p>\n","protected":false},"author":1,"featured_media":106,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[],"class_list":["post-105","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles"],"_links":{"self":[{"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/posts\/105","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/comments?post=105"}],"version-history":[{"count":5,"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/posts\/105\/revisions"}],"predecessor-version":[{"id":110,"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/posts\/105\/revisions\/110"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/media\/106"}],"wp:attachment":[{"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/media?parent=105"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/categories?post=105"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tis-eg.com\/en\/wp-json\/wp\/v2\/tags?post=105"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}