Leveraging Horn clause solving for compositional verification of PLC software

Abstract

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.

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. the PLC cycle, calling the program’s main function block, is characterised by clauses (25) to (28),

• 2. the query for safety, characterised by clause (29),

• 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)}\! $$

(36)

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)} $$

(37)

1.1 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} $$

(38)

$$ \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} $$

(39)

$$ \begin{array}{@{}rcl@{}} \mathit{Main}_{0}(\mathbf{X},\mathbf{X}) &\leftarrow& \mathit{cycle}_{e}(\mathbf{X}) \end{array} $$

(40)

$$ \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} $$

(41)

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.

1.2 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} $$

(42)

1.3 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} $$

(43)

$$ \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} $$

(44)

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} $$

(45)

$$ \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} $$

(46)

$$ \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} $$

(47)

$$ \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} $$

(48)

As stated in Section 5.3, the effect of calling a CFA B is captured by the predicate $B_{l_{B,x}}$, where l_B,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:

(49)

(50)

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} $$

(51)

$$ \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} $$

(52)

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 ReqHandler₄₂ 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 ReqHandler₄₂ will transitively depend on the entry location predicate ReqHandler₀ for any concrete implementation of ReqHandler.