We’re sorry, something doesn't seem to be working properly.

Please try refreshing the page. If that doesn't work, please contact support so we can address the problem.


Leveraging Horn clause solving for compositional verification of PLC software

We’re sorry, something doesn't seem to be working properly.

Please try refreshing the page. If that doesn't work, please contact support so we can address the problem.

  • 99 Accesses


Real-world PLC software is modular and composed of many different function blocks. Nevertheless, common approaches to PLC software verification do not leverage this but resort to inlining, or analyse instances of the same function block type independently. With the advent of constrained Horn clauses as the basis for automated program verification, many state-of-the-art verification procedures build upon them. We illustrate how this formalism allows for a uniform characterisation of PLC program semantics and safety goals, derived from reactive systems safety foundations. Furthermore, we give a natural extension of the resulting encoding which enables compositional reasoning about modular software. Due to the cyclic execution of PLCs, an engineer’s mental model of a single function block often exhibits state machine semantics – partitioning a block’s behaviour into different modes of operation. We illustrate how such a mode space, and similar high-level knowledge, can be integrated with our compositional characterisation. We investigate the impact of each technique on the model checking performance by characterising PLC software verification problems, both in a non-compositional and a compositional way that may incorporate mode transitions, and solving them with an SMT solver. Evaluation of our prototypical implementation on examples from the PLCopen Safety library shows the effectiveness of both the chosen formalism and using high-level summaries.

This is a preview of subscription content, log in to check access.

Access options

Buy single article

Instant unlimited access to the full article PDF.

US$ 39.95

Price includes VAT for USA

Subscribe to journal

Immediate online access to all issues from 2019. Subscription will auto renew annually.

US$ 99

This is the net price. Taxes to be calculated in checkout.

Listing 1
Fig. 1
Fig. 2
Fig. 3


  1. 1.



  1. Apel S, Beyer D, Friedberger K, Raimondi F, von Rhein A (2013) Domain types: Abstract-domain selection based on variable usage. In: Hardware and Software: Verification and Testing - 9th International Haifa Verification Conference, HVC 2013, Haifa, Israel, November 5-7, 2013, Proceedings, pp 262–278

  2. Beckert B, Ulbrich M, Vogel-Heuser B, Weigl A (2015) Regression verification for programmable logic controller software. In: Formal Methods and Software Engineering - 17th International Conference on Formal Engineering Methods, ICFEM 2015, Paris, France, November 3-5, 2015, Proceedings, pp 234–251

  3. Beyene TA, Popeea C, Rybalchenko A (2016) Efficient CTL verification via horn constraints solving. In: Proceedings 3rd Workshop on Horn Clauses for Verification and Synthesis, HCVS@ETAPS 2016, Eindhoven, The Netherlands, 3rd April 2016., pp 1–14

  4. Beyer D (2015) Software verification and verifiable witnesses - (report on SV-COMP 2015). In: Tools and Algorithms for the Construction and Analysis of Systems - 21st International Conference, TACAS 2015, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2015, London, UK, April 11-18, 2015. Proceedings, pp 401–416

  5. Beyer D (2019) Automatic verification of C and java programs: SV-COMP 2019. In: Tools and Algorithms for the Construction and Analysis of Systems - 25 years of TACAS: TOOLympics, Held as Part of ETAPS 2019, Prague, Czech Republic, April 6-11, 2019, Proceedings, Part III, pp 133–155

  6. Beyer D, Stahlbauer A (2014) Bdd-based software verification. Int J Softw Tools Technol Transfer 16(5):507–518

  7. Beyer D, Henzinger TA, Théoduloz G (2007) Configurable software verification: Concretizing the convergence of model checking and program analysis. In: Computer Aided Verification, 19th International Conference, CAV 2007, Berlin, Germany, July 3-7, 2007, Proceedings, pp 504–518

  8. Beyer D, Cimatti A, Griggio A, Keremoglu ME, Sebastiani R (2009) Software model checking via large-block encoding. In: Proceedings of 9Th International Conference on Formal Methods in Computer-aided Design, FMCAD 2009, 15-18 November 2009, Austin, Texas, USA, pp 25–32

  9. Biallas S, Brauer J, Kowalewski S (2012) Arcade.plc: a verification platform for programmable logic controllers. In: IEEE/ACM International Conference on Automated Software Engineering, ASE’12, Essen, Germany, September, 3-7, 2012, pp 338–341

  10. Biallas S, Giacobbe M, Kowalewski S (2013) Predicate abstraction for programmable logic controllers. In: Formal Methods for Industrial Critical Systems - 18th International Workshop, FMICS 2013, Madrid, Spain, September 23-24, 2013. Proceedings, pp 123–138

  11. Bjørner N, Gurfinkel A, McMillan KL, Rybalchenko A (2015) Horn clause solvers for program verification. In: Fields of Logic and Computation II - Essays Dedicated to Yuri Gurevich on the Occasion of His 75th Birthday, pp 24–51

  12. Blass A, Gurevich Y (1987) Existential Fixed-point Logic. Springer, Berlin, pp 20–36

  13. Bohlender D, Kowalewski S (2018a) Compositional verification of plc software using horn clauses and mode abstraction. IFAC-PapersOnLine 51(7):428–433. 14th IFAC Workshop on Discrete Event Systems WODES 2018

  14. Bohlender D, Kowalewski S (2018b) Design and verification of restart-robust industrial control software. In: Integrated Formal Methods - 14th International Conference, IFM 2018, Maynooth, Ireland, September 5-7, 2018, Proceedings, pp 47–68

  15. Bohlender D, Simon H, Kowalewski S (2016) Symbolic verification of PLC safety-applications based on plcopen automata. In: 19th GI/ITG/GMM Workshop Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen, MBMV 2016, Freiburg im Breisgau, Germany, March 1-2, 2016., pp 33–45

  16. Bohlender D, Hamm D, Kowalewski S (2018) Cycle-bounded model checking of PLC software via dynamic large-block encoding. In: Proceedings of the 33rd Annual ACM Symposium on Applied Computing, SAC 2018, Pau, France, April 09-13, 2018, pp 1891–1898

  17. Carter M, He S, Whitaker J, Rakamaric Z, Emmi M (2016) SMACK software verification toolchain. In: Proceedings of the 38th International Conference on Software Engineering, ICSE 2016, Austin, TX, USA, May 14-22, 2016 - Companion Volume, pp 589–592

  18. Cavada R, Cimatti A, Dorigatti M, Griggio A, Mariotti A, Micheli A, Mover S, Roveri M, Tonetta S (2014) The nuxmv symbolic model checker. In: Computer Aided Verification - 26th International Conference, CAV 2014, Held as Part of the Vienna Summer of Logic, VSL 2014, Vienna, Austria, July 18-22, 2014. Proceedings, pp 334–342

  19. Clarke EM, Klieber W, Nováček M, Zuliani P (2012) Model checking and the state explosion problem. Springer, Berlin, pp 1–30

  20. Darvas D, Fernandez Adiego B, Blanco E (2013) Transforming PLC Programs into Formal Models for Verification Purposes. Tech rep., EN-ICE-PLC, CERN

  21. Darvas D, Majzik I, Viñuela EB (2016) Formal verification of safety PLC based control software. In: Integrated Formal Methods - 12th International Conference, IFM 2016, Reykjavik, Iceland, June 1-5, 2016, Proceedings, pp 508–522

  22. De Angelis E, Fioravanti F, Pettorossi A, Proietti M (2014) Verimap: A tool for verifying programs through transformations. In: Tools and Algorithms for the Construction and Analysis of Systems - 20th International Conference, TACAS 2014, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2014, Grenoble, France, April 5-13, 2014. Proceedings, pp 568–574

  23. Dijkstra EW, Schölten CS (1990) The Strongest Postcondition. Springer, New York, pp 209–215

  24. Eén N, Mishchenko A, Brayton RK (2011) Efficient implementation of property directed reachability. In: International conference on formal methods in computer-aided design, FMCAD ’11, austin, TX, USA, October 30 - November 02, 2011, pp 125–134

  25. Frey G, Drath R, Schlich B, Eschbach R (2012) “safety automata” - A new specification language for the development of PLC safety applications. In: Proceedings of 2012 IEEE 17th International Conference on Emerging Technologies & Factory Automation, ETFA 2012, Krakow, Poland, September 17-21, 2012, pp 1–8

  26. Graf S, Saïdi H (1997) Construction of abstract state graphs with PVS. In: Computer Aided Verification, 9th International Conference, CAV ’97, Haifa, Israel, June 22-25, 1997, Proceedings, pp 72–83

  27. Hoare CAR (1969) An axiomatic basis for computer programming. Commun ACM, pp 576–580

  28. Hoder K, Bjørner N (2012) Generalized property directed reachability. In: Theory and Applications of Satisfiability Testing - SAT 2012 - 15th International Conference, Trento, Italy, June 17-20, 2012. Proceedings, pp 157–171

  29. Komuravelli A, Bjørner N, Gurfinkel A, McMillan KL (2015) Compositional verification of procedural programs using horn clauses over integers and arrays. In: Formal Methods in Computer-Aided Design, FMCAD 2015, Austin, Texas, USA, September 27-30, 2015., pp 89–96

  30. Lange T, Neuhäußer MR, Noll T (2013) Speeding up the safety verification of programmable logic controller code. In: Hardware and Software: Verification and Testing - 9th International Haifa Verification Conference, HVC 2013, Haifa, Israel, November 5-7, 2013, Proceedings, pp 44–60

  31. Ljungkrantz O, Åkesson K, Fabian M, Yuan C (2010) Formal specification and verification of industrial control logic components. IEEE Trans Automation Science and Engineering 7(3):538–548

  32. Manna Z, Pnueli A (1995) Temporal verification of reactive systems - safety. Springer

  33. McMillan KL (1993) Symbolic model checking. Kluwer

  34. Moon I (1994) Modeling programmable logic controllers for logic verification. IEEE Control Syst Mag 14(2):53–59

  35. de Moura LM, Bjørner N (2008) Z3: an efficient SMT solver. In: Tools and Algorithms for the Construction and Analysis of Systems, 14th International Conference, TACAS 2008, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2008, Budapest, Hungary, March 29-April 6, 2008. Proceedings, pp 337–340

  36. Ovatman T, Aral A, Polat D, Ünver A O (2016) An overview of model checking practices on verification of PLC software. Software and System Modeling 15 (4):937–960

  37. PLCopen TC5 (2006) Safety Software, Technical Specification, Part 1: Concepts and Function Blocks. PLCopen

  38. PLCopen TC5 (2008) Safety Software, Technical Specification, Part 2: User Examples. PLCopen

  39. Quinton S, Graf S (2008) Contract-based verification of hierarchical systems of components. In: Sixth IEEE International Conference on Software Engineering and Formal Methods, SEFM 2008, Cape Town, South Africa, 10-14 november 2008, pp 377–381

  40. Simon H, Kowalewski S (2018) Mode-aware concolic testing for PLC software. In: Integrated Formal Methods - 14th International Conference, IFM 2018, Maynooth, Ireland, September 5-7, 2018, Proceedings, pp 367–376

Download references

Author information

Correspondence to Dimitri Bohlender.

Additional information

Publisher’s note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

This article belongs to the Topical Collection: Theory-2020

Guest Editors: Francesco Basile, Jan Komenda, and Christoforos Hadjicostis

Appendix A: Compositional characterisation of the running example

Appendix A: Compositional characterisation of the running example

In the following we explicitly instantiate the characterisation from Section 5, that is clauses (25)–(31), using the example CFA from Fig. 1, including the higher-level knowledge provided by the mode abstraction (cf. Fig. 1). Note that for the sake of exposition, and lack of bit-operations in our example, we do not resort to the theory of fixed-size bit-vectors but capture the program semantics over booleans and integers. A characterisation over bit-vectors can and has been used in previous work (Bohlender and Kowalewski 2018b).

Let h.res = out be an example invariant the program should be compliant with, stating that the outputs of both function blocks coincide in all observable states. The characterisation can be split into three parts:

  1. 1.

    the PLC cycle, calling the program’s main function block, is characterised by clauses (25) to (28),

  2. 2.

    the query for safety, characterised by clause (29),

  3. 3.

    and each CFA’s characterisation, as given by clauses (30) and (31).

Similar to Eq. 33, the variables of the occurring CFA instances are given by

$$ \mathbf{X}={\left( \mathit{req},\mathit{in},m,\mathit{h.data},\mathit{h.DiagCode},\mathit{h.res},\mathit{out} \right)} \quad \mathbf{X}_{h}={\left( \mathit{h.data},\mathit{h.DiagCode},\mathit{h.res} \right)}\! $$

and \(\mathbf {X}^{\prime },\mathbf {X}_{h}^{\prime }\), or \(\mathbf {X}^{\prime \prime },\mathbf {X}_{h}^{\prime \prime }\), are further variants of these variables that are primed once or twice, respectively, i.e.

$$ \mathbf{X}^{\prime}={\left( \mathit{req}^{\prime},\mathit{in}^{\prime},m^{\prime},\mathit{h.data}^{\prime},\mathit{h.DiagCode}^{\prime},\mathit{h.res}^{\prime},\mathit{out}^{\prime} \right)} \quad \mathbf{X}_{h}^{\prime}={\left( \mathit{h.data}^{\prime},\mathit{h.DiagCode}^{\prime},\mathit{h.res}^{\prime} \right)} $$

A.1 PLC Cycle

Since Listing 1 provides no explicit initialisation, all variables are initialised to 0 orfalse (cf. IEC 61131-3). Instantiating clauses 25-28 yields the following constraints:

$$ \begin{array}{@{}rcl@{}} \mathit{cycle}_{x}(\mathbf{X}) &\leftarrow& {\left( \begin{array}{cc} \mathit{req}=\mathit{false}\wedge \mathit{in}=0\wedge m=\mathit{false}\wedge \mathit{h.data}=0\wedge \mathit{h.DiagCode}=0\\ \wedge\ \mathit{h.res}=0\wedge \mathit{h.out}=0 \end{array} \right)} \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{cycle}_{e}(\mathbf{X}^{\prime}) &\leftarrow& \mathit{cycle}_{x}(\mathbf{X}), {\left( \begin{array}{cc} m^{\prime}=m\wedge \mathit{h.data}^{\prime}=\mathit{h.data}\wedge \mathit{h.DiagCode}^{\prime}=\mathit{h.DiagCode}\\ \wedge\ \mathit{h.res}^{\prime}=\mathit{h.res}\wedge \mathit{h.out}^{\prime}=\mathit{h.out} \end{array} \right)} \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{0}(\mathbf{X},\mathbf{X}) &\leftarrow& \mathit{cycle}_{e}(\mathbf{X}) \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{cycle}_{x}(\mathbf{X}^{\prime}) &\leftarrow& \mathit{cycle}_{e}(\mathbf{X}), \mathit{Main}_{7}(\mathbf{X}, \mathbf{X}^{\prime}) \end{array} $$

Here, 7 is the exit location of the main function block Main, and the predicate \(\mathit {Main}_{7}(\mathbf {X},\mathbf {X}^{\prime })\) characterises the possible values \(\mathbf {X}^{\prime }\) after a single execution of the main CFA when started with values X.

A.2 Query

Instantiating clause (29), we require all observable states to satisfyh.res = out:

$$ \begin{array}{@{}rcl@{}} \mathit{h.res}=\mathit{out} &\leftarrow \mathit{cycle}_{x}(\mathbf{X}) \end{array} $$

A.3 CFA Semantics

While the running example states an implementation of the main function block Main, no concrete implementation of the ReqHandler block is provided, but only its interface. Accordingly, no sensible characterisation of its body can be provided here, but should be easy to establish given a concrete CFA. Every CFA is characterised independently by instantiating clause (30) for every edge of the CFA, and (31) for everycall-edge. For reference, complete characterisations of every benchmark are provided with the artefacts of this work.

In the following we characterise Main (cf. Fig. 1) by sequentially instantiating (30) for its assume-, assign-, and call-edges. The instantiation for the assumes \({\left (0,\mathit {req\wedge \neg m},1 \right )}\) and \({\left (0,\mathit {\neg (req\wedge \neg m)},4 \right )}\) yields:

$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{1}(\mathbf{X},\mathbf{X}^{\prime\prime}) &\leftarrow& \mathit{Main}_{0}(\mathbf{X},\mathbf{X}^{\prime}),\mathit{req}^{\prime}\wedge \neg m^{\prime} \wedge \mathbf{X}^{\prime\prime}=\mathbf{X}^{\prime} \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{4}(\mathbf{X},\mathbf{X}^{\prime\prime}) &\leftarrow& \mathit{Main}_{0}(\mathbf{X},\mathbf{X}^{\prime}),\neg{\left( \mathit{req}^{\prime}\wedge \neg m^{\prime} \right)} \wedge \mathbf{X}^{\prime\prime}=\mathbf{X}^{\prime} \end{array} $$

and the assignments \({\left (1,\mathit {h.data:=in},2 \right )}, {\left (3,\mathit {out:=h.res},6 \right )}, {\left (5,\mathit {out:=h.res},6 \right )}\) and \({\left (6,\mathit {m:=req},7 \right )}\) become:

$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{2}(\mathbf{X},\mathbf{X}^{\prime\prime}) &\leftarrow& \mathit{Main}_{1}(\mathbf{X},\mathbf{X}^{\prime}),\mathit{h.data}^{\prime\prime}=\mathit{in}^{\prime} \wedge {\left( \begin{array}{cc} \mathit{req}^{\prime\prime}=\mathit{req}^{\prime}\wedge \mathit{in}^{\prime\prime}=\mathit{in}^{\prime}\wedge m^{\prime\prime}=m^{\prime}\\ \wedge\ \mathit{h.DiagCode}^{\prime\prime}=\mathit{h.DiagCode}^{\prime}\\ \wedge\ \mathit{h.res}^{\prime\prime}=\mathit{h.res}^{\prime}\wedge \mathit{h.out}^{\prime\prime}=\mathit{h.out}^{\prime} \end{array} \right)} \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{6}(\mathbf{X},\mathbf{X}^{\prime\prime}) &\leftarrow& \mathit{Main}_{3}(\mathbf{X},\mathbf{X}^{\prime}),\mathit{out}^{\prime\prime}=\mathit{h.res}^{\prime} \wedge {\left( \begin{array}{cc} \mathit{req}^{\prime\prime}=\mathit{req}^{\prime}\wedge \mathit{in}^{\prime\prime}=\mathit{in}^{\prime}\\ \wedge\ m^{\prime\prime}=m^{\prime} \wedge \mathit{h.data}^{\prime\prime}=\mathit{h.data}^{\prime}\\ \wedge\ \mathit{h.DiagCode}^{\prime\prime}=\mathit{h.DiagCode}^{\prime} \wedge \mathit{h.res}^{\prime\prime}=\mathit{h.res}^{\prime} \end{array} \right)} \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{6}(\mathbf{X},\mathbf{X}^{\prime\prime}) &\leftarrow& \mathit{Main}_{5}(\mathbf{X},\mathbf{X}^{\prime}),\mathit{out}^{\prime\prime}=\mathit{h.res}^{\prime} \wedge {\left( \begin{array}{cc} \mathit{req}^{\prime\prime}=\mathit{req}^{\prime}\wedge \mathit{in}^{\prime\prime}=\mathit{in}^{\prime}\\ \wedge\ m^{\prime\prime}=m^{\prime} \wedge \mathit{h.data}^{\prime\prime}=\mathit{h.data}^{\prime}\\ \wedge\ \mathit{h.DiagCode}^{\prime\prime}=\mathit{h.DiagCode}^{\prime} \wedge \mathit{h.res}^{\prime\prime}=\mathit{h.res}^{\prime} \end{array} \right)} \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{7}(\mathbf{X},\mathbf{X}^{\prime\prime}) &\leftarrow& \mathit{Main}_{6}(\mathbf{X},\mathbf{X}^{\prime}),\mathit{m}^{\prime\prime}=\mathit{req}^{\prime} \wedge {\left( \begin{array}{cc} \mathit{req}^{\prime\prime}=\mathit{req}^{\prime}\wedge \mathit{in}^{\prime\prime}=\mathit{in}^{\prime}\\ \wedge\ \mathit{h.data}^{\prime\prime}=\mathit{h.data}^{\prime} \wedge \mathit{h.DiagCode}^{\prime\prime}=\mathit{h.DiagCode}^{\prime}\\ \wedge\ \mathit{h.res}^{\prime\prime}=\mathit{h.res}^{\prime}\wedge \mathit{h.out}^{\prime\prime}=\mathit{h.out}^{\prime} \end{array} \right)} \end{array} $$

As stated in Section 5.3, the effect of calling a CFA B is captured by the predicate \(B_{l_{B,x}}\), where lB,x is the exit location of B, similar to the embedding of Main in the PLC cycle in (41). However, since no concrete implementation of ReqHandler was stated, in the following, we use example locations 0 and 42 as entry and exit respectively. The instantiation of (30) for the calls \({\left (2,\mathit {ReqHandler(h.data,h.DiagCode,h.res)},3 \right )}\) and \({\left (4,\mathit {ReqHandler(h.data,h.DiagCode,h.res)},5 \right )}\) results in:


where the grey constraint is the optional information provided by the example mode space (cf. Section 5.3). Similar to the passing of state to Main in (40), the instantiation of clause (31) for the call edges yields:

$$ \begin{array}{@{}rcl@{}} \mathit{ReqHandler}_{0}(\mathbf{X}_{h}^{\prime},\mathbf{X}_{h}^{\prime}) &\leftarrow& \mathit{Main}_{2}(\mathbf{X},\mathbf{X}^{\prime}) \end{array} $$
$$ \begin{array}{@{}rcl@{}} \mathit{ReqHandler}_{0}(\mathbf{X}_{h}^{\prime},\mathbf{X}_{h}^{\prime}) &\leftarrow& \mathit{Main}_{4}(\mathbf{X},\mathbf{X}^{\prime}) \end{array} $$

This achieves the passing of h’s state to the functional characterisation of ReqHandler at both locations 2 and 4, such that the corresponding relations ReqHandler42 in (49) and (50) are guaranteed to not be empty. Just as \(\mathit {Main}_{7}(\mathbf {X},\mathbf {X}^{\prime })\) transitively depends on \(\mathit {Main}_{0}(\mathbf {X},\mathbf {X}^{\prime })\), the exit location predicate ReqHandler42 will transitively depend on the entry location predicate ReqHandler0 for any concrete implementation of ReqHandler.

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Bohlender, D., Kowalewski, S. Leveraging Horn clause solving for compositional verification of PLC software. Discrete Event Dyn Syst (2019). https://doi.org/10.1007/s10626-019-00296-8

Download citation


  • Formal verification
  • Programmable logic controllers
  • Predicate abstraction
  • Constrained Horn clauses
  • Software safety
  • Industry automation