A Formal Specification Method for PLC-based Applications

The correctness of the software used in control systems has been always a high priority, as a failure can cause serious expenses, injuries or loss of reputation. To improve the quality of these applications, various development and verification methods exist. All of them necessitate a deep understanding of the requirements which can be achieved by a well-adapted formal specification method. In this paper we introduce a state machine and data-flow-based formal specification method tailored to PLC modules. This paper presents the practical benefits and new possibilities of this method, comprising consistency checking, PLC code generation, and checking equivalence between the specification and its previous versions or legacy code. The usage of these techniques can improve the level of understanding of the requirements and increase the confidence in the correctness of the implementation. Furthermore, they can help to apply formal verification techniques by providing formalised requirements. INTRODUCTION AND MOTIVATION The complexity of process control systems is steadily increasing, resulting in more and more complex control software. Without an appropriate specification it is increasingly difficult to understand the requirements, hence to develop and maintain the programs. The motivation of this work originates from CERN (the European Organization for Nuclear Research), where numerous control systems are in use to operate the research facilities. Many of these control systems rely on Programmable Logic Controllers (PLCs). The increasing complexity of the control systems results implies an increasing complexity issue. The non-formal, ad-hoc specification methods in use are less and less able to cope with the complexity of the systems. Therefore we propose a new specification method that aims to handle the increasing complexity of PLC program units. Obviously, this is not the first work on specification methods for PLCs. Grafcet is a standardised specification method [1] based on safe Petri nets. It is convenient to describe finite state machines, but they are not universal enough to be generally used in the development of CERN’s control software as the finite state machines are just one part of the final code deployed. ProcGraph [2] is one of the recent attempts to improve specifications of PLC programs, but it is on a low abstraction level, too close to the real program code. Other PLC-related specification methods also exist, but none of ∗ Corresponding author. E-mail: ddarvas@cern.ch, darvas@mit.bme.hu them seemed to be able to cope with the size and complexity of the PLC programs used at CERN. Also, there are numerous general-purpose modelling methods that can be used for specifying PLC programs. One of them is the widely-known Simulink Stateflow, that has a complex semantics not adjusted to the needs of the PLC domain, making its usage difficult and potentially error-prone. The structure of the paper is the following. The next section introduces the main concepts and the structure of the proposed formal specification method. After, the potential benefits of the new method are discussed. Finally, the last section concludes the paper and draws up the future work. Due to space limitations, the discussion of the syntax and semantics of the specification method is introductory. The reader can find more details in our technical report [3]. MAIN SPECIFICATION CONCEPTS The goal of our work is to provide a specification method that is a complete, formal behaviour description of specific functionality which corresponds to one or some PLC components. Therefore it can be used to describe individual PLC components with high precision. Then, these precise descriptions can be naturally composed into complete control systems in the future. Previous work [4] discussed the requirements towards such a formal PLC specification method. The main requirements can be summarised as follows: (1) providing multiple formalisms adapted to the needs and knowledge of the PLC community, (2) keeping the “core logic” clean by decoupling the input/output-handling, (3) supporting events with proper semantics, and (4) limiting the set of possible errors by limiting the expressivity. The domain-specific requirements are complemented by general requirements, most notably the need for a formal, precise specification formalism, that is also lightweight (can be introduced with small effort) and complete (it describes all required and allowed behaviours). These requirements resulted in PLCspecif, a complete formal specification method for PLC programs. Structure of the Specification The main building block of the specification is the module that is either a composite module (its behaviour is described by some submodules) or a leaf module (its behaviour is directly described). To provide a specification method that is familiar for the PLC developers, the leaf module descriptions are based on three widely-known formalisms: state machines, data-flow diagrams, and standard PLC timers. Each module (both composite and leaf modules) is further decomposed into three main parts: (1) input definitions, (2) Proceedings of ICALEPCS2015, Melbourne, Australia Pre-Press Release 23-Oct-2015 11:00 WEPGF091 Software Technology Evolution ISBN 978-3-95450-148-9 1 Co py rig ht © 20 15 CC -B Y3. 0 an d by th er es pe ct iv ea ut ho rs Pr ePr es sR ele as e2 3O ct -2 01 5 11 :0 0 core logic, and (3) output definitions. According to the semantics of PLCspecif, these parts are executed sequentially in a loop, following a structure similar to the cyclic execution scheme of the PLCs. In the input definitions part, named expressions can be defined to simplify the specification. For example, if there are three digital inputs from three buttons (Button1, Button2, Button3), but the program provides the same response for pressing any button, writing “Button1 OR Button2 OR Button3” in the core logic makes the understanding more difficult. Instead, the user can specify a ButtonPressed expression that is defined once and used later in the core logic. This helps to decouple the physical structure (i.e. three digital inputs) from the concepts to be used in the core logic (i.e. a button was pressed). Some special inputs called event inputs can also be defined. An event input is an expression with Boolean type that has a priority assigned. We call an event input enabled if its expression is evaluated to true. In each module only the enabled event input with the highest priority can trigger. The input definitions are followed by the core logic description part. It can be described using various formalisms, that are introduced later in this paper. The output definitions part is responsible to assign values to the output variables, based on the input values and on the core logic (e.g. the current state of a state machine). This helps to keep the core logic clean. Including the output variable assignments in a state machine (as entry/exit actions or as transition actions) might make the state machine difficult to overview, therefore it is error-prone. Optionally, the output definitions part can be followed by invariant properties. These are additional requirements and assumptions identified during the specification phase that are not obviously described by the core logic, but have to be satisfied by the module. Expression Descriptions The input or output definitions may contain complex expressions. While the arithmetic form is suitable to describe simple expressions (e.g. “a OR b”), it does not scale up well. PLCspecif supports the usage of other expression description methods: AND/OR tables and switch-case tables. AND/OR tables were introduced in the RSML formalism [5], but not widely used since. In an AND/OR table each column represents a case, that is true if in all the rows the value of the expression in the row header equals to the value in the corresponding cell of the case. The whole expression is the OR-connection of the defined cases. The symbol “·” marks that the value of the variable is not taken into account (“don’t care”). Figure 1(a) shows an example, representing the a AND NOT b AND (c OR NOT d) expression. Switch-case tables —as their name suggests— are based on similar principles as the case constructs of various programming languages. Figure 1(b) shows an example, representing _Value, limited by lower limit PMin and upper limit PMax. Case 1 Case 2 a true true b false false c true · d · false (a) AND/OR table _Value _Value < PMin > PMax result