JACoW : What is special about PLC software model checking?

Model checking is a formal verification technique to check given properties of models, designs or programs with mathematical precision. Due to its high knowledge and resource demand, the use of model checking is restricted mainly to core parts of highly critical systems. However, we and many other authors have argued that automated model checking of PLC programs is feasible and beneficial in practice. In this paper we aim to explain why model checking is applicable to PLC programs even though its use for software in general is too difficult. We present an overview of the particularities of PLC programs which influence the feasibility and complexity of their model checking. Furthermore, we list the main challenges in this domain and the solutions proposed in previous works. Authors’ manuscript. Presented at the 16th Int. Conference on Accelerator and Large Experimental Control Systems (ICALEPCS 2017), Barcelona, Spain, 2017. The final publication is available via DOI 10.18429/JACoW-ICALEPCS2017-THPHA159. © 2017 CC BY 3.0 by the respective authors. INTRODUCTION AND MOTIVATION The promise of model checking is to provide precise, mathematically sound means to check the satisfaction of given requirements on models, representing for example software. Although some tools are available (e.g. CBMC1 [1], BLAST2, Bandera3 [2], DIVINE4 [3]), it is still difficult to use model checking on real-sized software in practice. One of the bottlenecks is the verification performance, the excessive need of resources for the successful verification. Besides checking software written in general-purpose programming languages (e.g. C, C++, Java), active research can be observed focusing on PLC (Programmable Logic Controller) programs specifically. It has been studied by dozens of research groups over the last 20 years [4]. However, model checking is still far away from being easy-to-use or part of the state of the practice of PLC program development. The reader may ask the question: what is the reason for targeting PLC model checking specifically? What makes this domain special and why there is a need for specific tools? What makes PLC model checking different from verifying general-purpose programs? This paper is dedicated to the specificities of PLC programs, which facilitate their verification, or contrarily, make the model checking more difficult. Our aim is to summarise our experience with PLC software model checking that we have acquired during the development of PLCverif [5], and to help formal verification researchers to specialise in this field, or to make their model checker tools applicable to the PLC program verification domain too. ∗ Corresponding author. E-mail: ddarvas@cern.ch 1 http://www.cprover.org/cbmc/ 2 http://cseweb.ucsd.edu/~rjhala/blast.html 3 http://bandera.projects.cs.ksu.edu/ 4 http://divine.fi.muni.cz/ The paper first overviews the difficulties and advantages arising from the domain specificities. Then the syntactic and semantic particularities of PLC programs are discussed. Finally, the need for environment modelling is mentioned. An extended version [6] of this paper is also available which contains more details and example programs. DOMAIN SPECIFICITIES Many of the differences between the general-purpose and PLC programming languages, but also between the available verification methods originate from the differences in the respective domains. Therefore, we start by overviewing the most important properties and specificities of the PLC domain which influence the formal verification of PLC programs. “Medium criticality” Except for trivial programs, it is difficult to imagine and prove absolute correctness or safety, just as absolute security. Instead of pursuing those ideals, a more pragmatic approach is needed: the verification costs and the risks of failure should be in balance. Formal verification is already often used where the cost of failure is exceptionally high: in case of highly critical systems (e.g. nuclear, railway or avionics systems) or systems produced in high quantities (e.g. microprocessors). Even the methods requiring special knowledge and lots of resources may be affordable in those cases. Contrarily, in case of systems with low criticality, deep analysis may not be required. PLC systems are in the middle of this criticality scale: their criticality is often not high enough to afford an independent, specially skilled verification team. However, a potential failure or outage may cause significant economic losses, motivating a sound and detailed verification approach. Consequence. PLC model checking approaches should be easily accessible, specifically targeting the PLC domain, without requiring unaffordable resources or having an excessive cost compared to the level of criticality. Advantage: Simple operations and data structure In general, the functionality of PLC programs is simpler than most programs written in C or Java. PLC programs do not deal with graphical interfaces, large data structures; they do not create files, do not perform complex operations. All these features may complicate the software model checking. Consequence. The simplicity of the programs makes model checking more feasible computationally. This makes the PLC domain a good target for formal verification. Difficulty: Variety of PLC languages PLCs use special languages, not used outside this domain. Furthermore, there is a wide variety of PLC programming languages. IEC 61131, the relevant standard [7] defines five different languages: Structured Text (ST), Instruction List (IL), Function Block Diagram (FBD), Ladder Diagram (LD) and Sequential Function Chart (SFC). Furthermore, each vendor provides their own flavour, with minor or major differences compared to the standard. Siemens PLCs typically support Structured Control Language (SCL), Statement List (STL), Function Block Diagram (FBD), Ladder Logic (LAD), and S7-GRAPH, which correspond to the previously listed standard languages, respectively. The difference between some of them is minor (e.g. between LAD and LD), but in other cases it is very significant (e.g. between STL and IL or SCL and ST). Consequence. As PLC programs can mix these languages (e.g. a function written in FBD can call a function written in SCL), each language should be supported by a PLC program verification tool. Furthermore, as there are common parts in those languages (e.g. variable declarations), the language infrastructure of the verification tool (parser and program representation) should be generic and reusable. Difficulty: Different background knowledge of developers General purpose programming languages, their development environments and verification tools are typically developed “inside the community”: by software engineers, for software engineers. PLC programs, however, are often written by people with different skills and background knowledge: automation engineers, technicians, etc. The theory and practice of formal verification is often not part of the general curriculum of software engineers, making the application of model checking hard. This knowledge gap is even bigger and more severe in case of the PLC program developers. Consequence. Special attention should be paid to bridge the semantic gap between the user and the verification tool. The tools should use inputs and outputs which are close to the users’ domain. For example, the PLCverif tool [5] uses the PLC programs and requirement patterns based on English sentences as inputs, and the outputs are provided in an easy-to-understand, self-contained form, using concepts directly from the PLC domain. SYNTAX OF PLC LANGUAGES As mentioned earlier, PLC programs are written using a wide variety of programming languages. Since—according to their claims—Siemens is a market leader in the field of automation, we mainly focus on the languages supported by Siemens S7 PLCs, especially the high-level Structured Control Language (SCL), which is a variant of the Structured Text (ST) language defined in IEC 61131 [7]. In this section, we show that although the PLC programs are simpler, their syntax may actually be more complex than that of general-purpose programs. Difficulty: Complex syntax PLC programming languages— especially their Siemens variants—often have richer and more complex syntax than general-purpose programming languages supported by software model checkers. For example, C (the C99 version) contains 6 basic data types with built-in support5, Java contains 9, but SCL contains 16 base types, which was extended to 30 in the new version of the language supported by the new development environment (TIA Portal) and the new hardware (e.g. S7-1500). Consequence. Development of the language infrastructure for PLC software model checking needs a lot of effort. As there is no good, reusable language infrastructure available, the entry cost of PLC program verification is high. Difficulty: No precise syntax definition The wellestablished general-purpose languages typically have precisely, often formally defined syntax. For example, the syntax of C is standardized by ANSI, ISO and IEC (ISO/IEC 9899), C# is defined by the ECMA-334 standard. The Java syntax is not standard, but a detailed specification is provided by Oracle. The syntax of standard PLC programming languages are defined in IEC 61131 (with some ambiguities [8, 9]). However, having a precise definition for the vendors’ flavours is not always easy. Siemens provided syntax definition for SCL version 5.3 [10] and for STL [11], which cover most, but not all aspects. The authors are not aware of any precise syntax description of the new version of SCL, supported by the new development environment, TIA Portal. Consequence. As the available syntax definitions are partial or too vague, the only way to determine the precise syntax is through systematic trials with the compilers. Creating precise descriptions for the most commonly used PLC programming languages and open source, generic parse