HyPLC: Hybrid Programmable Logic Controller Program Translation for Verification

TL;DR

HyPLC is a tool that translates verified hybrid program models, which include both control algorithms and continuous plant dynamics, into correct PLC code for safety-critical industrial systems.

Contribution

This paper introduces HyPLC, a novel tool that translates hybrid programs into PLC code, enabling verified hybrid models to be implemented in industrial controllers.

Findings

HyPLC successfully translates hybrid programs into PLC code.

The approach preserves correctness from verified models to implementation.

HyPLC bridges formal verification and practical deployment of control systems.

Abstract

Programmable Logic Controllers (PLCs) provide a prominent choice of implementation platform for safety-critical industrial control systems. Formal verification provides ways of establishing correctness guarantees, which can be quite important for such safety-critical applications. But since PLC code does not include an analytic model of the system plant, their verification is limited to discrete properties. In this paper, we, thus, start the other way around with hybrid programs that include continuous plant models in addition to discrete control algorithms. Even deep correctness properties of hybrid programs can be formally verified in the theorem prover KeYmaera X that implements differential dynamic logic, dL, for hybrid programs. After verifying the hybrid program, we now present an approach for translating hybrid programs into PLC code. The new tool, HyPLC, implements this translation of discrete control code of verified hybrid program models to PLC controller code and, vice versa, the translation of existing PLC code into the discrete control actions for a hybrid program given an additional input of the continuous dynamics of the system to be verified. This approach allows for the generation of real controller code while preserving, by compilation, the correctness of a valid and verified hybrid program. PLCs are common cyber-physical interfaces for safety-critical industrial control applications, and HyPLC serves as a pragmatic tool for bridging formal verification of complex cyber-physical systems at the algorithmic level of hybrid programs with the execution layer of concrete PLC implementations.

Equations

$$\varphi \to [\alpha ]\psi$$

$$A\to [{\{\text{ctrl};\text{plant}\}}^{\ast }]S,$$

$$\theta ,\eta ::=a|x|-\theta |\theta \sim \eta \text{where }\sim \in \{+,-,\ast ,/,\ast \ast \}$$

$$\theta ,\eta ::=x|n|\theta \sim \eta \text{where }\sim \in \{+,-,\cdot ,/,^\}$$

$$\text{ST}(-(x))▹-(\text{ST}(x))$$

$$\text{ST}(\theta \sim \eta )▹\text{ST}(\theta )\sim \text{ST}(\eta )$$

$$\text{ST}(\theta \cdot \eta )▹\text{ST}(\theta )\ast \text{ST}(\eta )$$

$$\text{ST}(\theta ^\eta )▹\text{ST}(\theta )\text{**}\text{ST}(\eta )$$

$$\varphi ,\psi ::=\text{TRUE}$$

$$\displaystyle\text{where }\bowtie_{\texttt{ST}}\$$

$$\displaystyle\text{and }\frown_{\texttt{ST}}\$$

$$\begin{gathered} \varphi ,\psi ::=true|false|\theta {\bowtie }_{\text{HP}}\eta |\neg \varphi |\varphi {⌢}_{\text{HP}}\psi \\ \text{where }{\bowtie }_{\text{HP}}\in \{<,>,\ge ,\le ,=\}\text{ and }{⌢}_{\text{HP}}\in \{\wedge ,\vee ,\to ,\leftrightarrow \} \end{gathered}$$

$$\text{ST}(true)$$

$$\text{ST}(false)$$

$$\text{ST}(\theta =\eta )$$

$$\text{ST}(\theta \ne \eta )$$

$$\text{ST}(\theta >\eta )$$

$$\text{ST}(\theta \ge \eta )$$

$$\text{ST}(\theta <\eta )$$

$$\text{ST}(\theta \le \eta )$$

$$\text{ST}(\neg (\varphi ))▹\text{NOT}(\text{ST}(\varphi ))\text{HP}(\text{NOT}(\varphi ))▹\neg (\text{HP}(\varphi ))$$

$$\text{ST}(\varphi \wedge \psi )$$

$$\text{HP}(\varphi \text{AND}\psi )$$

$$\text{ST}(\varphi \vee \psi )$$

$$\text{HP}(\varphi \text{OR}\psi )$$

$$\text{ST}(\varphi \to \psi )$$

$$\text{ST}(\varphi \leftrightarrow \psi )$$

$$\text{HP}(\varphi \text{XOR}\psi )$$

$$\text{OR}(\text{NOT}(\psi )\text{AND}\varphi ))$$

$$s_1,s_2::=x:=\theta |$$

$$\text{if}(\varphi )\text{then}{s}_1|s_1;s_2$$

$$\alpha ,\beta ::=x:=\theta |(?\varphi ;\alpha )\cup \beta |$$

$$(?\varphi ;\alpha )\cup ?\neg \varphi |\alpha ;\beta$$

$$\text{ST}(x:=\theta )$$

$$\text{HP}(x:=\theta )$$

$$\text{ST}(\alpha ;\beta )▹\text{ST}(\alpha );\text{ST}(\beta )\text{HP}(\alpha ;\beta )▹\text{HP}(\alpha );\text{HP}(\beta )$$

$$\text{ST}((?\varphi ;\alpha )\cup \beta )$$

$$\text{ST}((?\varphi ;\alpha )\cup (?\neg \varphi ;\beta ))$$

$$\text{ST}((?\varphi ;\alpha )\cup ?\neg \varphi )$$

$$\text{HP}(\text{if}(\varphi )\text{then}\alpha \text{else}\beta )▹$$

$$(?\text{HP}(\varphi );\text{HP}(\alpha ))\cup (?\neg \text{HP}(\varphi );\text{HP}(\beta ))$$

$$\text{HP}(\text{if}(\varphi )\text{then}\alpha )▹(?\text{HP}(\varphi );\text{HP}(\alpha ))\cup ?\neg \text{HP}(\varphi )$$

$$A\to [{(i:=\ast ;u:\in \text{ctrl}(x,i);t:=0;\{x^{\prime }=f(x,u),t^{\prime }=1\&t\le \epsilon \})}^{\ast }]S$$

Full text

Industrial control, programming languages, formal verification, semantics

††copyright: rightsretained††doi: 10.475/123_4††isbn: 123-4567-24-567/08/06††conference: ACM/IEEE International Conference on Cyber-Physical Systems; April 2019; Montreal, Canada††journalyear: 2019††ccs: Theory of computation Formal languages and automata theory††ccs: Computing methodologies Model verification and validation††ccs: Computer systems organization Embedded and cyber-physical systems

1. Introduction

There has been an increased emphasis on the verification and validation of software used in embedded systems in the context of industrial control systems (ICS). ICS represent a class of cyber-physical systems (CPS) that provide monitoring and networked process control for safety-critical industrial environments, e.g., the electric power grid (mcgranaghan1993voltage, ), railway safety  (abbpluto2016, ), nuclear reactors  (kesler2011vulnerability, ), and water treatment plants  (manesis1998intelligent, ). A prominent choice of implementation platform for many ICS applications are programmable logic controllers (PLCs) that act as interfaces between the cyber world–i.e., the monitoring entities and process control–and the physical world–i.e., the underlying physical system that the ICS is sensing and actuating. Efforts to verify the correctness of PLC applications focus on the code that is loaded onto these controllers (moon1994modeling, ), (darvas2015formal, ), (mader1999timed, ), (thapa2005transformation, ). Existing methods are based on model checking of safety properties specified in modal temporal logics, e.g., Linear Temporal Logic (LTL) (gerth1995simple, ) and Computation Tree Logic (CTL) (clarke1986automatic, ). However, since PLC code does not include a model of the system plant, such analyses are limited to more superficial, discrete properties of the code instead of analyzing safety properties of the resulting physical behavior.

In this paper, we thus start from hybrid systems models of ICS, in which the discrete computations of controllers run together with the continuous evolution of the underlying physical system. That way, correctness properties that consider both control decisions and physical evolution can be verified in the theorem prover KeYmaera X (fulton2015keymaera, ). The verified hybrid programs can then be compiled to PLC code and executed as controllers. The reverse compilation from PLC code to hybrid programs facilitates verifying existing PLC code with respect to pre-defined models of the continuous plant dynamics.

In this paper, we present HyPLC, a tool that compiles verified hybrid systems models into PLC code and vice versa. Figure 1 depicts a high-level overview of the bidirectional compilation provided by HyPLC. The hybrid models are specified in differential dynamic logic, dL (DBLP:journals/jar/Platzer08, ; DBLP:journals/jar/Platzer17, ), which is a dynamic logic for hybrid systems expressed as hybrid programs. Compiling hybrid programs to PLC code generates deterministic implementations of the controller abstractions typically found in hybrid programs, which focus on capturing the safety-relevant decisions for verification purposes concisely with nondeterministic modeling concepts. Nondeterminism in hybrid programs can be beneficial for verification since nondeterministic models address a family of (control) programs with a single proof at once, but is detrimental to implementation with Structured Text (ST) programs on PLCs. Therefore, in this paper we focus on hybrid programs in scan cycle form. The compilation adopts the IEC 61131-3 standards for PLCs (john2010iec, ). Compiling PLC code to dL and hybrid programs, implemented on top of the open-source MATIEC IEC 61131-3 compiler (sousamatiec, ), provides a means of analyzing PLC code on pre-defined models of continuous evolution with the deductive verification techniques of KeYmaera X. The core contributions of this paper lie in our correctness proofs for the bidirectional compilation, so that both directions of compilation yield a way of obtaining code with safety guarantees. Finally, we evaluated our tool on a water treatment testbed (mathur2016swat, ) that consists of a distributed network of PLCs.

The rest of the paper is organized as follows. Section 2 provides background information. Section 3 introduces compilation rules for terms in both languages and describes how the semantics is preserved. Section 4 and Section 5 describe the compilation of formulas and programs, respectively, and include formal proofs of correctness and preservation of safety across compilation. Section 6 presents our evaluation of HyPLC on a water treatment case study. We discuss the limitations of HyPLC and conclude in Section 7.

2. Preliminaries

This section explains the preliminaries necessary to understand the underlying concepts of HyPLC. We first provide a brief overview of PLCs, including how they are integrated into ICS as well as the associated programming languages and software model as defined by the IEC 61131-3 standard for PLCs (john2010iec, ). We then discuss previous works in formal verification of PLC programs, followed by an overview of the dynamic logic and hybrid program notation used by HyPLC.

2.1. Programmable Logic Controllers

Part 3 of the IEC 61131 standards (john2010iec, ) for PLCs specifies both the software architecture as well as the programming languages for the control programs that run on PLCs. We will provide the requisite knowledge for understanding the assumptions made by HyPLC.

PLCs in the context of ICS. Figure 2 shows how PLCs are integrated into ICS as well as a schematic overview of the PLC scan cycle. Scan cycles are typical control-loop mechanisms for embedded systems. The PLC “scans” the input values coming from the physical world and processes this system state through the control logic of the PLC, which is essentially a reprogrammable digital logic circuit. The outputs of the control logic are then forwarded through the output modules of the PLC to the physical world. HyPLC focuses on hybrid programs of a shape that fits to this scan cycle control principle using time-triggered models.

Programming languages and software execution model. HyPLC focuses on bidirectional compilation of the Structured Text (ST) language, which is a textual language similar to Pascal that, for formal verification purposes (darvas2017plc, ), can be augmented to subsume all other languages111ladder diagrams (LD), function block diagrams (FBD), sequential function charts (SFC), and instruction list (IL) defined by the IEC 61131-3 standard. For the software execution model, we refer to (john2010iec, ). We initially consider a single-resource configuration of a PLC that has a single task associated with a particular program that executes for a particular interval,  $\varepsilon$. Because, it is a single task configuration, we initially do not consider priority scheduling.

2.2. PLC Programming Language Verification

Due to their wide use, there have been numerous works regarding the verification of safety properties of PLC programming languages. Rausch et al. (rausch1998formal, ) modeled PLC programs consisting only of Boolean variables, single static assignment of variables, no special functions or function blocks, and no jumps except subroutines. Such an approach was an initial attempt to provide formal verification of discrete properties of the system, i.e., properties that can be derived and verified purely from the software, ignoring the physical behavior of its plant. Similarly, other approaches have been presented whose safety properties are specified and modeled using linear temporal logic (mclaughlin2014trusted, ; pavlovic2007automated, ) or by representing the system as a finite automaton (mertke2001formal, ; darvas2015plcverif, ; tapken1998moby, ). The formal verification of such systems is limited by state-space exploration techniques, e.g., there will be an uncontrollable number of states for continuous systems because time is a variable. As such, these techniques will only be able to explore a subset of the states.

Conversely, there have been several works regarding the generation of PLC code based on the formal models of PLC code. PLCSpecif (darvas2015formal, ) is a framework for generating PLC code based on finite automata representations of the PLC. Although this framework provides a means of generating PLC code based on formally verified models, the formal verification has the aforementioned limitations of providing correctness guarantees for discrete properties of the PLC code that can be verified for a finite time horizon. The approach presented by Sacha (sacha2005automatic, ) has similar limitations since it uses state machines to represent finite-state models of PLC code. Darvas  et al. also used PLCSpecif for conformance checking of PLC code against temporal properties (darvas2016conformance, ). Flordal et al. automatically generated PLC-code for robotic arms based on generated zone models to ensure the arms do not collide with each other as well as to prevent deadlock situations  (flordal2007automatic, ). The approach generates a finite-state model of the robot CPS environment that is then used to generate supervisory code within the PLC that controls its arm. The approach abstracts the PLC’s discrete properties and does not incorporate the PLC’s timing properties into the physical plant model. Furthermore, this is a domain-specific approach for robot simulation environments and does not provide generalizability nor a means of formal verification of the initially generated finite-state models.

VeriPhy (bohrer2018veriphy, ) compiles CPS models specified in dL to verified executables that sandbox controllers with safe fallback control and monitor for expected plant behavior. The VeriPhy pipeline combines multiple tools to bridge implementation and arithmetic gaps and provide proofs that safety is preserved when compiling to a controller executable–while HyPLC provides bi-directional compilation in the context of PLC scan cycles. Majumdar et al. also explored equivalence checking of C code and an associated SIMULINK model (majumdar2013compositional, ). Although such an approach is useful for modelling the behavior of C code in a control system model, additional efforts are needed to interface such a model with verification tools such as KeYmaera X as well as to model the behavior of PLCs.

2.3. Differential Dynamic Logic and Hybrid Programs

HyPLC works on models that have been specified in differential dynamic logic (dL) (platzer2010logical, ; DBLP:journals/jar/Platzer17, ), a logic that models hybrid systems and can be formally verified with a sound proof calculus. The formalized models that use dL are referred to as hybrid programs. As with ST, we will recall the syntax and semantics of dL and hybrid programs as needed throughout the course of this paper.

The modal operators ${[{\alpha}]}$ and $\langle\alpha\rangle$ are used to formally describe the behavioral properties the system has to satisfy. If $\alpha$ denotes a hybrid program, and $\phi$ and $\psi$ are formulas, then the dL formula

[TABLE]

means “if $\phi$ is initially satisfied, then $\psi$ holds true for all the states after executing the hybrid program $\alpha$”. This way, safety properties can be encoded for a model $\alpha$. We use the modeling pattern

[TABLE]

where $A$ represents assumptions on the initial state of the system, ctrl describes the discrete control transitions of the system, plant defines the continuous physical behavior of the system, and $S$ is the safety property we want to prove. In this pattern, control and plant are repeated any number of times, as indicated with the nondeterministic repetition operator ∗.

We use $\mathop{\text{FV}}(\phi)$ to refer to the free variables and $\mathop{\text{BV}}(\phi)$ to refer to the bound variables of formula $\phi$ (accordingly for terms and programs) (DBLP:journals/jar/Platzer17, ).

2.4. Use Case: Water Treatment Testbed

As a running example for this paper, we will use a simple water tank component taken from the first of six control processes of a water treatment testbed (mathur2016swat, ), depicted in Figure 3. This process is responsible for taking in water from a raw water source and feeding it into a tank. This water will then be pumped out into a second tank to be treated with chemicals. For this first process, the PLC is responsible for controlling the inflow of water for both tanks by opening or closing valves, $V_{1}$ and $V_{2}$, as well as the outflow of water to the second tank by running the pump, $P$. The PLC monitors the water level of both water tanks, $x_{1}$ and $x_{2}$, to ensure that $V_{1}$ and $V_{2}$, respectively, are closed before each respective tank overflows beyond an upper bound, $H$. Furthermore, the PLC is responsible for protecting the outflow pump, $P$, by ensuring that the pump is off if the water level of $x_{1}$ is below a lower threshold, $L$, or if the flow rate of the pump, $f_{2}$, is below a certain lower threshold, $F_{L}$ (not pictured in Figure 3).

Figure 4 shows a simplified representation of the actual ST code that is loaded onto the PLC for a particular sample rate of $\varepsilon$ for all the associated sensors. In this model, the flow rate for the incoming raw water, $f_{1}$, is not incorporated into the process control. The real system simply monitors the value of this flow rate without establishing a physical dependency. The upper limits of the water tank level, $H_{1}$ and $H_{2}$, and the lower limits, $L_{1}$ and $L_{2}$, represent trigger levels that are below and above, respectively, the actual safety thresholds, $H_{H}$ and $L_{L}$. The trigger values were determined empirically in (mathur2016swat, ); in our proofs, we will find and verify symbolic characterizations of these trigger values. This simple model will be used throughout the paper to illustrate how an existing ST program can be systematically compiled to the discrete control of a hybrid program and updated if necessary to ensure the safe operation of the ICS.

3. Compilation of Terms

Compilation approach overview. Compilation between ST and hybrid programs bases on two main ingredients: the syntax of the languages, given in grammars, define their notation; the language semantics give meaning to the syntactic constructs. Compilation translates from one syntax to another, but it must be done in a way that preserves the semantics of the compiled programs.

With compilation rules, we define how to compile a term, formula, or program in the source syntax into a corresponding term, formula, or program of the target syntax. Each rule will compile a certain program operator, and often invoke compilation on the operands. For example, $\textsf{\small ST}(\phi\land\psi)\triangleright\textsf{\small ST}(\phi)~{}\text{AND}~{}\textsf{\small ST}(\psi)$ compiles conjunction $\land$ in hybrid program formulas into conjunction AND in ST of the recursively compiled sub-formulas $\phi$ and $\psi$. Here, $\textsf{\small ST}(\phi\land\psi)$ means that we compile hybrid program formula $\phi\land\psi$ into an ST formula; the operator $\triangleright$ describes how the compilation is done.

With proofs of compilation correctness we then show that the compilation rules preserve the semantics in a way that will allow us to conclude safety of an ST program from a safety proof of a hybrid program. The proofs will exploit the recursive nature of the compilation rules and apply structural induction on the program syntax constructs, where we inductively justify each compilation rule from its easier pieces, basing on the hypothesis that the easier pieces are correctly built from the base constructs (e.g. complicated terms built from numbers and variables).

For terms and propositional formulas, the compilation rules are mostly straightforward. The main syntactic difference is between nondeterministic choices in hybrid programs and if-then-else constructs in ST. Aligning the semantics in the compilation correctness proofs, however, requires more work: the semantics of ST is given as an operational semantics (darvas2017plc, ), which describes the effects of taking a step in a program, whereas the semantics of hybrid programs is denotational, which describes how states are related through operations of a program.

Term compilation overview. In this section, we will define birectional compilation rules of the arithmetic terms in both hybrid programs and ST for PLCs. The terms of ST are the leaf elements of ST expressions that represent the values stored in the PLC’s memory and directly affect the sensing and actuation of the cyber-physical system for a particular context. As such, these values will need to be abstracted to represent the terms of an equivalent hybrid program. We will first discuss syntax of the terms in both languages and then define the semantics-preserving compilation.

Notation. We write ST$(\theta)$ for the result of compiling a hybrid program term, $\theta$, to an ST term, and we write HP$(\theta)$ to represent compiling an ST term to a hybrid program term. We write $\textsf{\small ST}(\theta)\triangleright s$ when $s$ is the result of compiling $\theta$ to an ST term, and $\textsf{\small HP}(s)\triangleright\theta$ when $\theta$ is the result of compiling $s$ to a dL term. This notation will also be used for the bidirectional compilation of formulas and programs.

3.1. Grammar Definitions

In order to compile terms between both languages while preserving the respective semantics, we first define the grammar for both languages.

Grammar of ST terms. The terms of ST considered in this paper are defined by the grammar:

[TABLE]

and where $a$ is a number literal, $x\in V$ is an ST variable, and $V$ is the subset of all ST variables, and both number literals and variables are restricted to LReal222LReal variables are 8 byte values represented as floating points from the IEC 60559 standard. of the numeric elementary data types defined by the IEC 61131-3 standard.

Grammar of dL terms. The translatable terms of dL and hybrid programs (DBLP:journals/jar/Platzer08, ; DBLP:journals/jar/Platzer17, ) are defined by the grammar:

[TABLE]

and where $x\in V$ is a variable and $V$ is the set of all variables. The grammar allows the use of number literals $n$ as functions without arguments that are to be interpreted as the value they represent.

Next, we provide the bidirectional compilation rules of terms and prove term compilation correctness.

3.2. Compilation Rules

We will first define compilation rules for the terminal expressions, referred to as atomic terms, and compose the other expressions following the recursive nature of the grammars.

Atomic terms. Atomic terms in hybrid programs include variables and number literals. For the sake of simplicity, we do not consider functions within hybrid programs as we want to focus on the core elements of discrete control, and we assume that the data type LReal of the IEC 61131-3 standard represents mathematical reals. In practice, when a PLC implements LReal with floating point numbers, this assumption can be met with an appropriate sound encoding using, for example, interval arithmetic as verified in (bohrer2018veriphy, ).

HyPLC compiles number literals and variables of hybrid programs, which evaluate to mathematical reals, to numbers and variables of data type LReal of the IEC 61131-3 standard as follows: Number literals $n$ and variables $x$ then do not need conversion, so $\textsf{\small ST}(n)~{}\triangleright~{}n$ and $\textsf{\small HP}(n)~{}\triangleright~{}n$, as well as $\textsf{\small ST}(x)~{}\triangleright~{}x$ and HP(x)$~{}\triangleright~{}x$.

Next, we inductively define the compilation rules for arithmetic operations.

Arithmetic operations. Arithmetic operations are similarly defined in an inductive fashion in similar syntax in both languages, which makes translation of terms $\theta$ and $\eta$ straightforward as follows:

[TABLE]

where $\sim\ \in\{+,-,/\}$.

We now provide the Lemmas for correctness of the translation of terms in both directions. We follow (darvas2017plc, ) and write $(\theta,{{{\nu}}})\rightarrow_{a}c$ to express that in ST a term $\theta$ evaluates to $c$ in context ${{{\nu}}}$. We write ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}=c$ to express that in dL a term $\theta$ evaluates to $c$ at state ${{{\nu}}}$. Details on the dL semantics and ST semantics used in the proof can be found in Appendix A and Appendix B, respectively.

Lemma 3.1 (Correctness of term compilation).

Assuming $\texttt{LReal}=\mathbb{R}$: if $(\theta,{{{\nu}}})\rightarrow_{a}c$ then ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(\theta)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}=c$; conversely, if ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}=c$ then $(\textsf{\small ST}(\theta),{{{\nu}}})\rightarrow_{a}c$.

Proof.

See Appendix C.∎

We next define how the compilation of terms is leveraged to compile the formulas of both languages in both directions.

4. Compilation of Formulas

In this section, we compile modality- and quantifier-free formulas used in tests in hybrid programs and conditional expressions of ST statements. As was done with the terms of each language, we first discuss the syntax of the formulas for both languages.

4.1. Grammar Definitions

Grammar of ST formulas. ST formulas are used in conditional expressions defined by the IEC 61131-3 standard as follows.

[TABLE]

The values TRUE and FALSE represent the two Boolean values a conditional expression can take upon evaluation, $\theta$ and $\eta$ are ST terms, operator $\bowtie_{\texttt{ST}}$ ranges over relational operators used in ST, operator $\frown_{\texttt{ST}}$ ranges over logical operators between two formulas, and $\text{NOT}(\phi)$ is the logical negation of a formula $\phi$.

Grammar of dL formulas. The truncated grammar for modality- and quantifier-free formulas in dL that we consider in this paper is built using propositional connectives $\lnot$, $\land$, $\lor$, $\rightarrow$, and $\leftrightarrow$ (DBLP:journals/jar/Platzer08, ) as follows:

[TABLE]

and where $\theta$ and $\eta$ are dL terms. Given these base grammars, next we present the compilation rules and the formula compilation correctness proof.

4.2. Compilation Rules

Atomic formulas. Atomic formulas in both languages comprise the literals $\mathit{true}$ and $\mathit{false}$ and comparisons of terms and are compiled in a straightforward way:

[TABLE]

Comparisons are compiled as follows:

[TABLE]

The compilation rules for the atomic formulas are the basis for compiling compositional formulas.

Logical formulas. Logical connectives $\lnot,\land,\lor$ are straightforward, whereas $\rightarrow,\leftrightarrow$ are rewritten in terms of $\land,\lor$ before compilation (similar for XOR):

[TABLE]

[TABLE]

We now prove correctness of the compilation of formulas in both directions. In ST, we write $(\phi,{{{\nu}}})\rightarrow_{a}\top$ and in dL ${{{\nu}}}\models\phi$ to say that formula $\phi$ is true at state ${{{\nu}}}$.

Lemma 4.1 (Correctness of formula compilation).

Formulas evaluate equivalently: ${{{\nu}}}\models\phi$ iff $(\textsf{\small ST}(\phi),{{{\nu}}})\rightarrow_{a}\top$ and, conversely, $(\phi,{{{\nu}}})\rightarrow_{a}\top$ iff ${{{\nu}}}\models\textsf{\small HP}(\phi)$.

Proof.

See Appendix C.∎

5. Compilation of Programs

Now that we know how to correctly compile terms and formulas in both languages, we turn to compiling program constructs. Since these programs, when executed on a PLC, interact with the physical world, our overall goal is to provably establish safety properties of the physical behavior of an ICS. To this end, we again show compilation correctness with respect to the semantics of the languages, which will serve as a stepping stone to describe the program effect in the larger context of the PLC scan cycle.

We first provide an overview of our hybrid system model of a PLC scan cycle, before we introduce the grammars and compilation rules for both languages and prove compilation correctness.

5.1. Scan Cycle Hybrid System Model

We model the PLC scan cycle as a hybrid program of a particular shape—referred to as a hybrid program in scan cycle normal form—in order for safety properties verified about a hybrid program to directly transfer to its implementation in ST.

Figure 5 provides an overview of the components of a hybrid program in scan cycle normal form and how they relate to a PLC scan cycle. A PLC scan cycle is a periodic process that, on each iteration, scans the inputs, then executes the control logic to set outputs, and finally forwards outputs to the actuators. The total scan cycle duration in this abstracted model is $\varepsilon$.

Our hybrid program model of such a scan cycle uses nondeterministic assignments $i\mathrel{{:}{=}}\ast$ to model arbitrary external input to the PLC system, such as sensor values whose state cannot be estimated or user input from a user interface. Based on the current state $x$ and inputs $i$, the controller $u{\,:\in\,}\text{ctrl}(x,i)$ then chooses control actions $u$ from a set of possible choices. The plant modeled by $t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\}$ continuously evolves the system state $x$ according to the control actions along the differential equations $x^{\prime}=f(x,u)$ and keeps track of the scan cycle duration bound $\varepsilon$ with a clock $t$.

Definition 5.1 (Scan cycle normal form).

We call a hybrid program with shape $i\mathrel{{:}{=}}\ast;{u{\,:\in\,}\text{ctrl}(x,i)};t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\}$ a program in scan cycle normal form. It is safe, if formula $A\rightarrow{[{{(i\mathrel{{:}{=}}\ast;{u{\,:\in\,}\text{ctrl}(x,i)};t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\})}^{*}}]}S$ is valid.

In the following subsections, we detail how a controller $u{\,:\in\,}\text{ctrl}(x,i)$ is translated into an ST program and its associated configuration. We will leave the generation of code for nondeterministic inputs and physical plant components (e.g., monitors that check model and true system execution for compliance) as future work.

We will use the operational semantics of ST and dynamic semantics of hybrid programs to ensure that the compilation preserves meaning. Additionally, we will use the static semantics of hybrid programs in terms of their bound and free variables to derive configuration information for the PLC code (e.g., distinguish between input and output variables).

5.2. Grammar Definitions

We present the respective grammars for programs in each language.

Grammar of ST programs. ST programs refer to the sequence of statements defined by the IEC 61131-3 standard that form entire ST programs. We consider ST statements $s_{1}$ and $s_{2}$ as follows:

[TABLE]

Where $x:=\theta$ is assignment of an ST term $\theta$ to variable $x$, $\textsf{if}~{}(\phi)~{}\textsf{then}~{}s_{1}~{}\textsf{else}~{}s_{2}$ is a conditional statement where $s_{1}$ is executed if $\phi$ is true and $s_{2}$ is executed otherwise, and $s_{1};s_{2}$ is the sequential composition of ST programs where $s_{2}$ executes after $s_{1}$ has finished its execution. While the structured grammar can support several other control structures such as finitely bounded loops and case-statements, these structures can be represented as a series of if-then-else statements. The dL grammar is composed in a similar fashion.

Grammar of dL programs. The grammar for PLC-translatable dL hybrid programs is defined as follows.

[TABLE]

Where $x\mathrel{{:}{=}}\theta$ are assignments of the value of a term $\theta$ to the variable $x$, ${(?\phi;\alpha)}\cup{\beta}$ is a guarded execution of $\alpha$ (possible if $\phi$ is true) and default $\beta$ (can be executed nondeterministically regardless of $\phi$ being true or false), ${(?\phi;\alpha)}\cup{(?\lnot\phi;\beta)}$ is an if-then-else conditional statement, ${(?\phi;\alpha)}\cup{?\lnot\phi}$ is an if-then conditional statement without else, and $\alpha;\beta$ is a sequential composition  (DBLP:journals/jar/Platzer08, ; DBLP:journals/jar/Platzer17, ). Given these base grammars for the programs, we now present the compilation rules and the associated correctness proofs that will allow us to conclude safety of ST programs from safety proofs of hybrid programs. Preserving safety will allow us to compile existing ST programs into hybrid programs and analyze their interaction with the physical plant for safety, and conversely compile the controllers of hybrid programs into ST programs for execution on a PLC.

5.3. Compilation Rules

Deterministic assignment. Assignments of terms to variables in hybrid programs represent the core of discrete state transitions in a hybrid system.

The syntax and operational effect of a discrete assignment is the same in both languages, so compilation is straightforward:

[TABLE]

The static semantics of discrete assignments in hybrid programs provides information about input and output variables of the generated ST code: an assignment contributes $\mathop{\text{BV}}(x\mathrel{{:}{=}}\theta)=\{x\}$ to the set of output variables, and $\mathop{\text{FV}}(x\mathrel{{:}{=}}\theta)=\mathop{\text{FV}}(\theta)$ to the set of input variables (DBLP:journals/jar/Platzer17, ).

Sequential composition programs. The sequential composition of two hybrid programs $\alpha$ and $\beta$ lets the hybrid program $\beta$ starts executing after $\alpha$ has finished, meaning that $\beta$ never starts if the program $\alpha$ does not terminate. Sequential composition of ST statements has identical meaning, and so compilation between ST and hybrid programs is straightforward as follows:

[TABLE]

A sequential composition contributes the input and output variables of both its sub-programs: it has output variables $\mathop{\text{BV}}(\alpha;\beta)=\mathop{\text{BV}}(\alpha)\cup\mathop{\text{BV}}(\beta)$ and input variables $\mathop{\text{FV}}(\alpha;\beta)=\mathop{\text{FV}}(\alpha)\cup(\mathop{\text{FV}}(\beta)\setminus\mathop{\text{MBV}}(\alpha))$. Note that the input variables are not simply the union of both sub-programs, since some of the free variables of $\beta$ might be bound on all paths in $\alpha$—in $\mathop{\text{MBV}}(\alpha)$—and therefore no longer be free in the sequential composition (DBLP:journals/jar/Platzer17, ).

Remark 1 (ST Task Execution Timing).

The execution of a series of statements with respect to sequential composition assumes that the statements execute atomically, which is defined in the transition semantics of hybrid programs. We do not model the preemption of higher priority tasks as the modeling of the PLC’s task scheduling is beyond of the scope of this paper and left for future research.

HyPLC* assumes that the developer designs a system with multiple tasks such that (1) the execution time of a highest priority task is less than its period and that (2) the total execution of all tasks is less than the period of the lowest priority tasks (allenbradley2008, ). *

Conditional programs. In the translatable fragment of hybrid programs we allow tests to occur only as the first statement of the branches in nondeterministic choices, and we allow only nondeterministic choices that are guarded with tests. A nondeterministic choice between hybrid programs $?\phi;\alpha$ and $\beta$ executes either hybrid program and is resolved on a PLC by favoring execution of $?\phi;\alpha$ over $\beta$ in an if-then-else statement. The test statement $?\phi$ in the beginning avoids backtracking. The compilation is defined as follows.

[TABLE]

The static semantics combines the input and output variables of both programs: output variables $\mathop{\text{BV}}({(?\phi;\alpha)}\cup{\beta})=\mathop{\text{BV}}({(?\phi;\alpha)}\cup{(?\lnot\phi;\beta)})=\mathop{\text{BV}}(\alpha)\cup\mathop{\text{BV}}(\beta)$ and input variables $\mathop{\text{FV}}({(?\phi;\alpha)}\cup{\beta})=\mathop{\text{FV}}({(?\phi;\alpha)}\cup{(?\lnot\phi;\beta)})=\mathop{\text{FV}}(\phi)\cup\mathop{\text{FV}}(\alpha)\cup\mathop{\text{FV}}(\beta)$.

Because we only consider loop-free semantics, we avoid having to enforce backtracking for deep tests that may exist in $\alpha$ or $\beta$. Instead, the tests will simply be compiled as nested conditional programs.

ST conditional programs statements compile to guarded nondeterministic choices in hybrid programs as follows:

[TABLE]

Next, we prove compilation correctness that will allow us to transfer safety proofs of hybrid programs to ST programs. We write $(s_{1},{{{\nu}}})\rightarrow(s_{2},{{{\omega}}})$ to say that program $s_{1}$ executed in context ${{{\nu}}}$ transitions to a new context ${{{\omega}}}$ with remaining program $s_{2}$. We write $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ to say that the final state ${{{\omega}}}$ is reachable from the initial state ${{{\nu}}}$ by running the hybrid program $\alpha$.

Lemma 5.2 (Correctness of ST to HP compilation).

All states reachable with the ST control program are also reachable by the target hybrid program: If $(s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$ then $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ for all ${{{\nu}}},{{{\omega}}}$, where skip denotes the end of code for a scan cycle.

Proof.

See Appendix C.∎

Lemma 5.3 (Correctness of HP to ST compilation).

All states reachable with the ST control program are also reachable by the source hybrid program: If $(\textsf{\small ST}(\alpha),{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$ then $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ for all ${{{\nu}}},{{{\omega}}}$.

Proof.

See Appendix C.∎

5.4. Preserving Safety Guarantees across Compilation

Correct compilation guarantees that safety properties verified for hybrid programs in scan cycle normal form shape are preserved for the runs of translated ST programs. Def. 5.4 expresses how a loop-free ST program is executed repeatedly in the scan cycle of a PLC, connected to inputs, and drives the plant through its results.

Definition 5.4 (Run of ST program).

A sequence of states

${{{\sigma}}}_{0},{{{\sigma}}}_{1},{{{\sigma}}}_{2},\ldots,{{{\sigma}}}_{n}$ is a run of ST program $s_{1}$ with input (variable vector) $i$ and plant $t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\}$ with scan cycle duration $\varepsilon$ iff for all $i{<}n$ the program executes to completion $(s_{1},{{{\mu}}}_{i})\rightarrow(\textsf{skip},{{{\nu}}}_{i})$ for some program start state ${{{\mu}}}_{i}$ obtained from the previous state ${{{\sigma}}}_{i}$ in the run by reading input s.t. $({{{\sigma}}}_{i},{{{\mu}}}_{i})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}i\mathrel{{:}{=}}\ast\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and some program result state ${{{\nu}}}_{i}$ driving the plant to the next state ${{{\sigma}}}_{i+1}$ in a continuous transition of duration $t{\leq}\varepsilon$ s.t. $({{{\nu}}}_{i},{{{\sigma}}}_{i+1})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

Def. 5.4 expresses how a ST program interacts with the physical world; Def.5.1 says that a hybrid program in scan cycle normal form, $i\mathrel{{:}{=}}\ast;{u{\,:\in\,}\text{ctrl}(x,i)};t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\}$, is safe if it reaches only safe states in which $S$ is true when started in states where $A$ is true. We now translate safety to the compiled ST program. Intuitively, a hybrid program is compiled safe to ST when any ST program run that starts in a state matching the assumptions $A$ reaches only states where running the plant is safe $S$, as expressed in Theorem 5.5.

Theorem 5.5 (Compilation Safety).

If the dL formula

[TABLE]

is valid, and a run ${{{\sigma}}}_{0},{{{\sigma}}}_{1},{{{\sigma}}}_{2},\ldots,{{{\sigma}}}_{n}$ of $\textsf{\small ST}(u{\,:\in\,}\text{ctrl}(x,i))$ with input $i$ and plant $t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\}$ starts with satisfied assumptions ${{{\sigma}}}_{0}\models A$, then ${{{\sigma}}}_{i}\models S$ for all $i$.

Proof.

By Lemma 5.3: if $(\textsf{\small ST}(u{\,:\in\,}\text{ctrl}(x,i)),{{{\mu}}}_{i})\rightarrow(\textsf{skip},{{{\nu}}})$ then $({{{\mu}}}_{i},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}u{\,:\in\,}\text{ctrl}(x,i)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$. Since ${{{\sigma}}}_{0},\ldots,{{{\sigma}}}_{n}$ is a run of $\textsf{\small ST}(u{\,:\in\,}\text{ctrl}(x,i))$ in input $i$ and plant $t\mathrel{{:}{=}}0;\{x^{\prime}=f(x,u),t^{\prime}=1~{}\&~{}t{\leq}\varepsilon\}$, we have for all $i{<}n$ that $({{{\sigma}}}_{i},{{{\mu}}}_{i})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}i\mathrel{{:}{=}}\ast\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$, $({{{\mu}}}_{i},{{{\nu}}}_{i})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}u{\,:\in\,}\text{ctrl}(x,i)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$, and

[TABLE]

Thus, by the semantics of sequential composition (DBLP:journals/jar/Platzer17, ),

[TABLE]

for all $i{<}n$. Hence, we conclude ${{{\sigma}}}_{i}\models S$ for all $i$ by the validity of

[TABLE]

Theorem 5.5 means that an ST program enjoys the safety proof of a hybrid program if our compilation was used in the process (either the hybrid program used in the proof was compiled from the ST program, or the hybrid program was the source for compiling the ST program). Next, we analyze the shape and static semantics of a hybrid program in scan-cycle normal form to extract configuration information.

5.5. Cyclic Control Configuration

ST programs are complemented with a configuration that structures the programs into tasks, assigns priorities and execution intervals to these tasks, and allocates computation resources for the tasks. For a hybrid program in scan-cycle normal form per Def. 5.1

[TABLE]

do its shape and static semantics provide essential insight into the required configuration information. The modeling pattern in the scan-cycle normal form is that of a time-triggered repetition, achieved by a clock variable $t$ that is reset to [math] before the continuous dynamics, evolves with constant slope $1$, and allows following the continuous dynamics for up to $\varepsilon$ time. The combined effect is that the input $i\mathrel{{:}{=}}\ast$ and control $u{\,:\in\,}\text{ctrl}(x,i)$ are executed at least once every $\varepsilon$ time. In the compilation setup, a value for $\varepsilon$ must be provided (e.g., with a formula $\varepsilon=n$ as part of the assumptions $A$ in the safety proof) and is taken as the scan cycle configuration of a PLC.

For a single task, we define the compilation of a safety property of a hybrid program in scan-cycle normal form to a task as:

[TABLE]

and Task($\alpha$,$\epsilon$) is a shorthand defining a task333A task is being used here to abstract the other configuration components of an ST program, i.e., Configurations and Resources. We assume only one configuration and one resource at a time in this paper for a single PLC. that executes $\alpha$ (here the discrete control $u{\,:\in\,}\text{ctrl}(x,i)$ translated to ST), cyclically with an interval $\varepsilon$. Similarly, we define the converse compilation of a task with an ST program $\alpha$–whose variables $i$ are of type VAR_INPUT from the configuration–and execution time of $\varepsilon$ as

[TABLE]

Since the ST program does not include an analytic plant model, the compiled controller is augmented with the differential equations from a plant given as extra input. The sets of input and output variables determined by analyzing the static semantics of the hybrid program inform the program configuration variable declaration blocks VAR_INPUT and VAR_OUTPUT, as seen in Figure 4.

Extension to multiple tasks. A future extension to multiple tasks would consider a single configuration of a PLC with a single resource that has a one-to-one mapping of task configurations to ST programs. A designated clock $t_{n}$ per task would keep track of the associated task’s execution interval $\varepsilon_{n}$. The task execution intervals would be checked periodically every $\varepsilon_{\text{sc}}$ times, which represents the scan cycle timing of the PLC. Any task with elapsed clock $t_{n}\geq\varepsilon_{n}$ is executed (which means that tasks are executed with at most $\varepsilon_{\text{sc}}$ delay).

6. Evaluation

Now that we have provided the compilation rules that will be used by HyPLC, we evaluate the tool on a real system. HyPLC was implemented as two module extensions for the KeYmaera X tool: one for each compilation direction. For the compilation of hybrid programs to ST, the compilation rules were implemented on top of the existing parser of the KeYmaera X tool. Given the abstract syntax tree of a hybrid program, HyPLC generates the associated ST code based on the compilation rules. The implementation was written in Scala with $\sim$700 LoC.

Similarly, the module for the compilation of an ST program to a hybrid program was implemented on top of the lexical analysis provided by the MATIEC IEC 61131-3 compiler (sousamatiec, ). The MATIEC compiler provides modules that compile ST programs to either C code or other languages provided by the IEC standard. With the same APIs we implemented the compilation rules from the abstract syntax tree of an ST program. The module was implemented in C++ with $\sim$1000 LoC.

We next present how HyPLC was evaluated against the water treatment testbed.

6.1. Use Case: Water Treatment Testbed

In the case study, we first compiled the PLC code from the water treatment testbed shown in Figure 4 into a hybrid program. Formal verification in KeYmaera X showed that this implementation is unsafe. We then updated the generated hybrid program with the necessary assumptions to guarantee the safety of the ICS. Finally, we compiled the fixed hybrid program into PLC code that, by Theorem 5.5, enjoys the safety proof of the hybrid program.

6.1.1. Counterexamples in Existing PLC Code

In order to compile the ST controller into a hybrid program of the water treatment testbed, we provide the continuous plant of the ICS in terms of differential equations, as well as the initial state constraints $A$. These are combined with the compiled ctrl of the ICS that provides the discrete-state transitions of the system. Finally, we define the safety requirement, $S$, that ensures that the water tank levels always remain within their upper ($H_{H}$) and lower ($L_{L}$) thresholds.

Figure 6 shows the full hybrid program generated by HyPLC that incorporates both the compiled ST code as well as the continuous dynamics of the water treatment testbed. Intuitively, this model cannot be proven as there are no constraints on the flow rates $f_{1}$ and $f_{2}$, nor do the guards on actuation enforce such constraints. We use KeYmaera X and the dL proof calculus to find counterexamples for the faulty combinations of operating the valves $V_{1}$ and $V_{2}$, both for concrete threshold values (gohAdepuJunejoMathur, ) and the generalized threshold conditions $L_{L}<L_{1}<H_{1}<H_{H}\land L_{L}<L_{2}<H_{2}<H_{H}$ of Figure 6. Some representative examples are listed below:

• •

If $x_{1}\geq H_{1}$ (so $V_{1}=0$) and $x_{2}\leq H_{2}$ (so $V_{2}=1$): without time and flow rate bounds, the pump may drain the first tank when it attempts to protect underflow in the second tank; it may also cause overflow of the second tank.

• •

If only $V_{1}=1$ is open, the first tank may overflow.

• •

If both valves are open, either tank may overflow, or the first tank may underflow, depending on the ratio of flow rates.

KeYmaera X finds such counterexamples by unrolling the loop and analyzing paths through the loop body to (i) collect assumptions (e.g., conditions in tests $x_{1}\geq H_{1}$, and effects of assignments $V_{1}=1$ from $V_{1}\mathrel{{:}{=}}1$) and (ii) propagate program effects into proof obligations (e.g., the effect of the flow rate and valves on the water level $x^{\prime}_{1}=V_{1}\cdot f_{1}-V_{2}\cdot P\cdot f_{2}$ is propagated into $S$). A counterexample consists of sample values for the variables such that the collected assumptions are satisfied but the proof obligations are not. Analyzing these sample values point to potential fixes (e.g., no flow into the first tank $f_{1}=0$ with simultaneous large out flow $f_{2}$ indicates that the valve $V_{2}$ must be turned off before the first tank drains entirely).

6.1.2. Generating Safe PLC Code

The hybrid program was updated to reflect a safe system that restricts the flow rates by modifying the guard values on the discrete control. Figure 7 shows the updated hybrid program that was proven to be safe with KeYmaera X. Once verified, HyPLC generates the associated PLC code, listed in Figure 8.

Comparison on real-world data. To illustrate the safety guarantees of our system, we developed a Python script to analyze the sensor and actuation values of 4 days worth of sensor data (gohAdepuJunejoMathur, ). We check the values of the sensor data relevant to the process described by our model and instantiate the parameters in the model with the values provided in the dataset. At each time sample, the script checks that the collective system state complies444The relevant conditions to check and expected control choices can be extracted by proof from a hybrid program using ModelPlex (DBLP:journals/fmsd/MitschP16, ). with the expected test-actuation sequences enumerated in our model: the recorded actuator commands for the valves and pump must match the expected command from our model, which is determined by matching the recorded sensor values with the test conditions in the model. For instance, the script records a violation if the condition in IF (f1 > (HH-x1)/$\varepsilon$) THEN V1:=0; from Figure 8 is met but the recorded actuation differs from closing the valve. We compared the violations with the original ST program in Figure 4 where, e.g., the corresponding condition reads IF (x1 >= H1) THEN V1:=0;. Figure 9 illustrates this difference on a snippet of the real data. In particular, this snippet represents a period of manual operation. The original model will have raised an incorrect safety violation flag, while the model generated by HyPLC will not raise a flag during this period.

Our results revealed that the recorded data did not comply with Figure 8 for 238 instances555An instance of a model compliance violation is a range of uninterrupted scan cycles where the recorded data deviates from the expected model. for the verified code in Figure 8 and 439 instances for the original code in Figure 4 out of  40K possible instances666For 403K samples, the duration of each instance was on average 10 scan cycles.. Note that the verified code allows the system to operate closer to its limits for reasons detailed below, providing a more efficient system operation while enjoying the safety guarantees of the proofs in KeYmaera X.

Upon inspection, most of the violations observed occur during initialization and at the thresholds in oscillating normal system operation (gohAdepuJunejoMathur, ). For example, during initialization, the data shows a period where valve $V_{1}$ is closed and the tank is drained despite not having reached the lower threshold $L_{1}$, see (gohAdepuJunejoMathur, , Fig. 4b). During normal operation, the system slightly overshoots or undershoots the intended limits for discrete switching states, e.g., if the system was supposed to close $V_{1}$ when $x_{1}\leq L_{1}$, the system may undershoot $L_{1}$. These slight overshoots or undershoots are not allowed in the original ST code, but can be tolerated in the verified model that takes into account flow rates for making decisions.

This study allowed us to not only generate safe PLC code, but to also reveal missing conditions in PLC code that has been evaluated empirically to be safe. We further showed that HyPLC may provide a means of operating a system closer to safety limits while at the same time provably maintaining crucial safety guarantees.

7. Conclusion and Future Work

In this paper, we formalize compilation between safety-critical code utilized in industrial control systems (ICS) and the discrete control of hybrid programs specified in differential dynamic logic (dL). We present HyPLC, a tool for bi-directional compilation of code loaded onto programmable logic controllers (PLCs) to and from hybrid programs specified in dL to provide safety guarantees for “deep” correctness properties of the PLC code in the context of the cyber-physical ICS. We evaluated HyPLC on a real water treatment testbed, demonstrating how HyPLC can be utilized to both verify the safety of existing PLC code as well as generate correct PLC code given a verified hybrid program. Future work will focus on lifting assumptions for PLC arithmetic, support for multiple tasks, as well as support for security analysis. This work serves as a foundation for pragmatic verification of PLC code as well as to understand the safety implications of a particular implementation given complex cyber-physical interdependencies.

Acknowledgment

We would like to thank the U.S. Department of Education (Graduate Assistance in Areas of National Need), the U.S. Department of Energy (Award Number DE-OE0000780), the Air Force Office of Scientific Research (Award Number FA9550-16-1-0288), as well as the Defense Advanced Research Projects Agency (Award Number FA8750-18-C-0092) for their support of this work. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the U.S. Department of Education, the U.S. Department of Energy, AFOSR, DARPA, or the U.S. Government. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation here on.

Appendix A Semantics of Differential Dynamic Logic

The semantics of dL (DBLP:journals/jar/Platzer08, ; DBLP:conf/lics/Platzer12a, ; DBLP:journals/jar/Platzer17, ) is a Kripke semantics in which the states of the Kripke model are the states of the hybrid system. Let $\mathbb{R}$ denote the set of real numbers and $\mathcal{V}$ denote the set of variables. A state is a map ${{{\nu}}}:\mathcal{V}\to\mathbb{R}$ assigning a real value ${{{\nu}}}(x)$ to each variable $x\in\mathcal{V}$. We write ${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\phi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ if formula $\phi$ is true at ${{\text{state}}}~{}{{{\nu}}}$ (Def. A.2). The real value of term $\theta$ at ${{{\nu}}}$ is denoted ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

The semantics of translatable hybrid programs $\alpha$ is expressed as a transition relation between states (Def. A.1).

Definition A.1 (Transition semantics of translatable hybrid programs).

The transition relation ${{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ specifies which states $\omega$ are reachable from a state $\nu$ by operations of $\alpha$. It is defined as follows:

1. (1)

$(\nu,\omega)\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}x\mathrel{{:}{=}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ iff $\omega(x)={{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$, and for all other variables $z\neq x$, $\omega(z)=\nu(z)$ 2. (2)

$(\nu,\omega)\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ iff ${{{\nu}}}=\omega$ and ${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ 3. (3)

${{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{\alpha}\cup{\beta}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}={{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}\cup{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ 4. (4)

${{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{\alpha};{\beta}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}=\{(\nu,\omega)~{}|~{}\textrm{exists}~{}\mu~{}\textrm{s.t.}~{}(\nu,\mu)\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}~{}\textrm{and}~{}(\mu,\omega)\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}\}$

Definition A.2 (Interpretation of translatable dL formulas).

Truth of translatable dL formula $\phi$ in ${{\text{state}}}~{}{{{\nu}}}$, written ${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\phi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$, is defined as follows:

1. (1)

${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta_{1}\sim\theta_{2}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ iff ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta_{1}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}\sim{{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta_{2}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ for ${\sim}\in\{=,\leq,<,\geq,>\}$ 2. (2)

${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\phi\land\psi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ iff ${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\phi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ and ${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\psi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$, so on for $\lnot,\lor,\rightarrow,\leftrightarrow$ 3. (3)

${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{[{\alpha}]}\phi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ iff ${{{{{{\omega}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\phi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ for all ${\omega~{}\textrm{with}~{}(\nu,\omega)\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$

We denote validity as $\models\phi$, i.e., ${{{{{{\nu}}}\in{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\phi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}}$ for all states ${{{\nu}}}$.

Appendix B Semantics of Structured Text

Figure 10 lists the operational ST semantics based on (darvas2017plc, ). The context of an ST statement is denoted by ${{{\nu}}}$, which is a function ${{{\nu}}}:V\rightarrow D$ that assigns a value from pre-defined domains $D$ to each defined variable $x\in V$ (we use $D=\text{LReal}$). We follow (darvas2017plc, ) where a program $s$ is executed from an initial context ${{{\nu}}}$ and results in a subsequent context ${{{\omega}}}$ that determines the values of the physical outputs and values of the variables for the subsequent PLC scan cycle. Execution of a cycle ends when the final configuration $(\textsf{skip},{{{\nu}}})$ is reached, where skip denotes the end of the code for this scan cycle. Variables are denoted as $x_{1}$, expressions are denoted as $e_{1}$ and $e_{2}$, constants are denoted as $c_{1}$ and $c_{2}$, and ST statements are denoted as $s_{1}$ and $s_{2}$. Arithmetic/logic evaluations are denoted by $\rightarrow_{a}$ and single-step program evaluations are denoted as $\rightarrow$. The context ${{{\nu}}}[x_{1}\mapsto c_{1}]$ denotes a context ${{{\omega}}}$ that agrees with ${{{\nu}}}$ except that ${{{\omega}}}(x_{1})=c_{1}$. Figure 10 lists AND and OR as representative examples for the other arithmetic/logical operations for two ST terms as defined by the IEC 61131-3 standard.

Appendix C Proofs

Proof of Lemma 3.1.

Straightforward structural induction from

• •

Number literals $(n,{{{\nu}}})\rightarrow_{a}n$ for all ${{{\nu}}}$ and ${{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}n\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}=n$

• •

ST Variable Value $\frac{{{{\nu}}}(x)=c}{(x,{{{\nu}}})\rightarrow_{a}c}$ and dL variable valuation ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}x\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}={{{\nu}}}(x)$

• •

Negation in ST $\frac{(\theta,{{{\nu}}})=c_{1}}{(-\theta,{{{\nu}}})\rightarrow_{a}-c_{1}}$ and dL ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}-\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}=-{{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ for term $\theta$

• •

Binary arithmetic operator $\sim$ in ST $\frac{(\theta,{{{\nu}}})=c_{1}~{}~{}~{}(\eta,{{{\nu}}})=c_{2}}{(\theta\sim\eta,{{{\nu}}})\rightarrow_{a}c_{1}\sim c_{2}}$ and dL ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\sim\eta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}={{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}\sim{{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\eta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ for terms $\theta$ and $\eta$. ∎

Proof of Lemma 4.1.

Straightforward structural induction from

• •

Comparisons $\bowtie_{\texttt{ST}}\ \in\{<,>,>=,<=,<>,=\}$ in ST

[TABLE]

and dL ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\bowtie_{\texttt{HP}}\eta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}={{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}\bowtie_{\texttt{HP}}{{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\eta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ for operator $\bowtie_{\texttt{HP}}\in\{<,\leq,=,\geq,>\}$ and terms $\theta$ and $\eta$.

• •

Logical connectives in ST

[TABLE]

in dL ${{{{}\nu\mathopen{\mathrel{[}\joinrel\mathrel{[}}\phi\land\psi\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}=\mathit{true}$ iff ${{{\nu}}}\models\phi$ and ${{{\nu}}}\models\psi$, accordingly for $\lnot,\lor$. ∎

Proof of Lemma 5.2.

By structural induction on ST programs from the base case $(\textsf{skip},{{{\nu}}})$, so $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\mathit{true}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$, and induction hypothesis $(s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$ then $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

Case 1 (Assignment $\textsf{\small HP}(x:=\theta)\triangleright{\textsf{\small HP}(x)\mathrel{{:}{=}}\textsf{\small HP}(\theta)}$).

We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(x)\mathrel{{:}{=}}\textsf{\small HP}(\theta)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$. Direct consequence of ST Assignment and induction hypothesis: $(x:=\theta,{{{\nu}}})\rightarrow(\textsf{skip},{{{\nu}}}[x\mapsto c])$ for ${{{\nu}}}(x)\rightarrow_{a}c$, i.e., ${{{\nu}}}[x\mapsto c]$ denotes a state ${{{\omega}}}={{{\nu}}}$ except ${{{\omega}}}(x)$ is replaced with $\theta$ at ${{{\nu}}}$.

Case 2 (Sequential $\textsf{\small HP}(s_{1};s_{2})\triangleright\textsf{\small HP}(s_{1});\textsf{\small HP}(s_{2})$).

We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1});\textsf{\small HP}(s_{2})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$. Let $(s_{1};s_{2},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$ so by operational semantics there is ${{{\mu}}}$ such that $(s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\mu}}})$ and $(s_{2},{{{\mu}}})\rightarrow(\textsf{skip},{{{\omega}}})$. From $(s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\mu}}})$ we get $({{{\nu}}},{{{\mu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis, and from $(s_{2},{{{\mu}}})\rightarrow(\textsf{skip},{{{\omega}}})$ we get $({{{\mu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{2})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis and conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1});\textsf{\small HP}(s_{2})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

Case 3 (If-Then-Else $\textsf{\small HP}(\textsf{if}{}(Q){}\textsf{then}{}s_{1}{}\textsf{else}~{}s_{2})\triangleright\

{?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})}\cup{?\lnot\textsf{\small HP}(Q);\textsf{\small HP}(s_{2})}$).

Let $(\textsf{if}~{}(Q)~{}\textsf{then}~{}s_{1}~{}\textsf{else}~{}s_{2},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$. We have to show

[TABLE]

(i) Case ${{{\nu}}}\models Q$ and so ${{{\nu}}}(Q)\rightarrow_{a}\top$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (1) (darvas2017plc, ) therefore $(\textsf{if}~{}(Q)~{}\textsf{then}~{}s_{1}~{}\textsf{else}~{}s_{2},{{{\nu}}})\rightarrow(s_{1},{{{\nu}}})$ and so $(s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$. Hence in turn we get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis. Now $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and so we get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

(ii) Case ${{{\nu}}}\not\models Q$ and so ${{{\nu}}}(Q)\rightarrow_{a}\bot$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (2) therefore $(\textsf{if}~{}(Q)~{}\textsf{then}~{}s_{1}~{}\textsf{else}~{}s_{2},{{{\nu}}})\rightarrow(s_{2},{{{\nu}}})$ and so $(s_{2},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$. Hence in turn we get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{2})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis. Now $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{2})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and so we get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q);\textsf{\small HP}(s_{2})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

(iii) Now either $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ or otherwise $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q);\textsf{\small HP}(s_{2})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and so we conclude

[TABLE]

Case 4 (If-Then $\textsf{\small HP}(\textsf{if}{}(Q){}\textsf{then}~{}s_{1})\triangleright\

{?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})}\cup{?\lnot\textsf{\small HP}(Q)}$).

Let $(\textsf{if}~{}(Q)~{}\textsf{then}~{}s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$. We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})}\cup{?\lnot\textsf{\small HP}(Q)}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

(i) Case ${{{\nu}}}\models Q$ and so ${{{\nu}}}(Q)\rightarrow_{a}\top$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (3) therefore $(\textsf{if}~{}(Q)~{}\textsf{then}~{}s_{1},{{{\nu}}})\rightarrow(s_{1},{{{\nu}}})$ and so $(s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$. Hence in turn we get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis. Now $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and so we get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

(ii) Case ${{{\nu}}}\not\models Q$ and so ${{{\nu}}}(Q)\rightarrow_{a}\bot$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (4) therefore $(\textsf{if}~{}(Q)~{}\textsf{then}~{}s_{1},{{{\nu}}})\rightarrow(\textsf{skip},{{{\nu}}})$. Now $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and ${{{\nu}}}={{{\omega}}}$ and so we get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

(iii) Now either $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ or $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot\textsf{\small HP}(Q)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and so we conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?\textsf{\small HP}(Q);\textsf{\small HP}(s_{1})}\cup{?\lnot\textsf{\small HP}(Q)}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$. ∎

Proof of Lemma 5.3.

By structural induction over hybrid programs from the base case $(\textsf{skip},{{{\nu}}})$ so $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\mathit{true}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$, and induction hypothesis $(\textsf{\small ST}(\alpha),{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$ then $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

Case 1 (Assignment $\textsf{\small ST}(x\mathrel{{:}{=}}\theta)\triangleright\textsf{\small ST}(x):=\textsf{\small ST}(\theta)$).

We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}x\mathrel{{:}{=}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$. From ST Assignment, we know that $(\textsf{\small ST}(x):=\textsf{\small ST}(\theta),{{{\nu}}})\rightarrow(\textsf{skip},{{{\nu}}}[\textsf{\small ST}(x)\mapsto c])$ for $\textsf{\small ST}(\theta)\rightarrow_{a}c$, i.e., there is a state ${{{\omega}}}$ which agrees with ${{{\nu}}}$ except for the value of $\textsf{\small ST}(x)$: ${{{\omega}}}(\textsf{\small ST}(x))={{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\textsf{\small ST}(\theta)\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}_{{{{\nu}}}}$ and we conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}x\mathrel{{:}{=}}\theta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL from Lemma 3.1.

Case 2 (Sequential $\textsf{\small ST}(\alpha;\beta)\triangleright\textsf{\small ST}(\alpha);\textsf{\small ST}(\beta)$).

We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha;\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$. Let $(\textsf{\small ST}(\alpha;\beta),{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}})$ and so by operational semantics there is ${{{\mu}}}$ such that $(\textsf{\small ST}(\alpha),{{{\nu}}})\rightarrow(\textsf{skip},{{{\mu}}})$ and $(\textsf{\small ST}(\beta),{{{\mu}}})\rightarrow(\textsf{skip},{{{\omega}}})$. Therefore in turn $({{{\nu}}},{{{\mu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and $({{{\mu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis and we conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha;\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

Case 3 (Guarded Choice $\textsf{\small ST}({?Q;\alpha}\cup{\beta})\triangleright\textsf{if}{}(\textsf{\small ST}(Q)){}\textsf{then}~{}\textsf{\small ST}(\alpha)\

{}\textsf{else}{}\textsf{\small ST}(\beta)$).

Let $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha)~{}\textsf{else}~{}\textsf{\small ST}(\beta),{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}}))$. We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?Q;\alpha}\cup{\beta}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

(i) Case ${{{\nu}}}\models Q$ and so ${{{\nu}}}(\textsf{\small ST}(Q))\rightarrow_{a}\top$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (1) therefore $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha)~{}\textsf{else}~{}\textsf{\small ST}(\beta),{{{\nu}}})\rightarrow(\textsf{\small ST}(\alpha),{{{\nu}}}))$ and in turn $(\textsf{\small ST}(\alpha),{{{\nu}}}))\rightarrow(\textsf{skip},{{{\omega}}})$. Now $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis and we therefore get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q;\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

(ii) Case ${{{\nu}}}\not\models Q$ and so ${{{\nu}}}(\textsf{\small ST}(Q))\rightarrow_{a}\bot$. By ST IF (2) therefore $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha)~{}\textsf{else}~{}\textsf{\small ST}(\beta),{{{\nu}}})\rightarrow(\textsf{\small ST}(\beta),{{{\nu}}}))$ and so $(\textsf{\small ST}(\beta),{{{\nu}}}))\rightarrow(\textsf{skip},{{{\omega}}})$ and in turn $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis.

(iii) Now either $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q;\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ or $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and we conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?Q;\alpha}\cup{\beta}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

Case 4 (If-Then-Else $\textsf{\small ST}({?Q;\alpha}\cup{?\lnot Q;\beta})\triangleright\textsf{if}{}(\textsf{\small ST}(Q)){}\textsf{then}~{}\

\textsf{\small ST}(\alpha){}\textsf{else}{}\textsf{\small ST}(\beta)$).

We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?Q;\alpha}\cup{?\lnot Q;\beta}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$. Let $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha)~{}\textsf{else}~{}\textsf{\small ST}(\beta),{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}}))$.

(i) Case ${{{\nu}}}\models Q$ and so ${{{\nu}}}(\textsf{\small ST}(Q))\rightarrow_{a}\top$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (1) therefore $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha)~{}\textsf{else}~{}\textsf{\small ST}(\beta),{{{\nu}}})\rightarrow(\textsf{\small ST}(\alpha),{{{\nu}}}))$ and in turn $(\textsf{\small ST}(\alpha),{{{\nu}}}))\rightarrow(\textsf{skip},{{{\omega}}})$. Now $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis and we therefore get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q;\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

(ii) Case ${{{\nu}}}\not\models Q$ and so ${{{\nu}}}(\textsf{\small ST}(Q))\rightarrow_{a}\bot$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (2) hence $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha)~{}\textsf{else}~{}\textsf{\small ST}(\beta),{{{\nu}}})\rightarrow(\textsf{\small ST}(\beta),{{{\nu}}}))$, so $(\textsf{\small ST}(\beta),{{{\nu}}}))\rightarrow(\textsf{skip},{{{\omega}}})$ and in turn $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis; we conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot Q;\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

(iii) Now either $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q;\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ or $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot Q;\beta\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and we conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?Q;\alpha}\cup{?\lnot Q;\beta}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

Case 5 (If-Then $\textsf{\small ST}({?Q;\alpha}\cup{?\lnot Q})\triangleright\textsf{if}{}(\textsf{\small ST}(Q)){}\textsf{then}~{}\

\textsf{\small ST}(\alpha)$).

Let $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha),{{{\nu}}})\rightarrow(\textsf{skip},{{{\omega}}}))$. We have to show $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?Q;\alpha}\cup{?\lnot Q}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

(i) Case ${{{\nu}}}\models Q$ and so ${{{\nu}}}(\textsf{\small ST}(Q))\rightarrow_{a}\top$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (3) therefore $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha),{{{\nu}}})\rightarrow(\textsf{\small ST}(\alpha),{{{\nu}}}))$ and in turn $(\textsf{\small ST}(\alpha),{{{\nu}}}))\rightarrow(\textsf{skip},{{{\omega}}})$. Now $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by induction hypothesis and we therefore get $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q;\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL.

(ii) Case ${{{\nu}}}\not\models Q$ and so ${{{\nu}}}(\textsf{\small ST}(Q))\rightarrow_{a}\bot$ and in turn $({{{\nu}}},{{{\nu}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by Lemma 4.1. By ST IF (4) therefore $(\textsf{if}~{}(\textsf{\small ST}(Q))~{}\textsf{then}~{}\textsf{\small ST}(\alpha),{{{\nu}}})\rightarrow(\textsf{skip},{{{\nu}}}))$ and so ${{{\nu}}}={{{\omega}}}$ and in turn $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$.

(iii) Now either $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?Q;\alpha\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ or $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}?\lnot Q\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ and we conclude $({{{\nu}}},{{{\omega}}})\in{{{{}\mathopen{\mathrel{[}\joinrel\mathrel{[}}{?Q;\alpha}\cup{?\lnot Q}\mathclose{\mathrel{]}\joinrel\mathrel{]}}}}}$ by dL. ∎