Verification Condition Generation for Hybrid Systems described by Synchronous Languages

Transcription

1 UNIVERSITY OF KAISERSLAUTERN Verification Condition Generation for Hybrid Systems described by Synchronous Languages by Marcel Heer A thesis submitted in partial fulfillment for the degree of Master of Science (M.Sc.) in the Department of Computer Science July 2016 Supervisors: Prof.Dr. Klaus Schneider M.Eng. Xian Li

2

3 Declaration of Authorship I, Marcel Heer, declare that this thesis titled, Verification Condition Generation for Hybrid Systems described by Synchronous Languages and the work presented in it are my own. I confirm that this thesis has been composed by me, based on my own work, unless stated otherwise. No other person s work has been used without acknowledgement in this thesis. All references have been quoted and all sources of information have been acknowledged. Signed: Date: iii

4 Acknowledgements I hereby want to thank my supervisors Xian Li and Klaus Schneider of the Embedded Systems Group for the opportunity to write this thesis, the support all along and for providing a good working environment. iv

5 Abstract While synchronous programming languages like Esterel and Quartz are capable of modeling embedded systems, extensions like Hybrid Quartz are needed to model hybrid systems. These systems contain continuous behavior additional to their discrete states. Since embedded systems are safety-critical in many applications, formal verification is needed to check programs against their specification. In this thesis, an implementation of an interactive verification method is presented, which is based on inductive assertions. Therefore, Verification Conditions are generated. To verify these generated proof goals validity, SMT solvers are utilized. In interactive verification, a user is required to interact by providing assertions. Thus, multiple possibilities of providing these assertions are discussed. Zusammenfassung Während synchrone Programmiersprachen wie Esterel und Quartz imstande sind, Eingebettete Systeme zu modellieren, werden Erweiterungen wie Hybrid Quartz benötigt, um hybride Systeme zu entwickeln. Diese Systeme enthalten zusätzlich zu diskreten Zuständen stetiges, kontinuierliches Verhalten. Weil Eingebettete Systeme in vielen Anwendungen in sicherheitskritischen Bereichen eingesetzt werden, ist formale Verifikation notwendig, um Programme auf ihre Spezifikation hin zu überprüfen und sie mit dieser abzugleichen. In dieser Arbeit wird eine Implementierung einer Methode zur interaktiven Verifikation präsentiert, welche auf induktiven logischen Aussagen (inductive assertions) basiert. Dazu werden logische Bedingungen generiert und es werden SMT solver verwendet, um deren Gültigkeit zu verifizieren. In der interaktiven Verifikation müssen logische Aussagen vom Anwender bereitgestellt werden. Daher werden mehrere Möglichkeiten erläutert, wie diese Aussagen angegeben werden können.

6

7 Contents Declaration of Authorship Acknowledgements Abstract Zusammenfassung List of Figures Abbreviations Symbols iii iv v v ix xi xii 1 Introduction Motivation Task and Scope of the Thesis Outline Related Work Modeling of Hybrid Systems Verification of Synchronous Programs Hybrid System Verification Approaches and Tools Fundamentals Modeling of Hybrid Systems Hybrid Systems, Hybrid Automata and ODEs Models of Computation and Synchronous Languages The Synchronous Programming Language Quartz Graph Definitions Extended Finite State Machine Hybrid Quartz Verification of Hybrid and Synchronous Systems Model Checking and Deductive Techniques SMT Solvers Restriction of Quartz: SSTA Normal Form Software Verification While- and GoTo-Programs Hoare Logic and Inductive Assertions vii

8 CONTENTS Interference Optimization Problems Verification Condition Generation General Idea Generating and Solving Verification Conditions The SafePath Predicate The SafeTrans Predicate Prerequisites for VC Generation Approaches for VC Generation Implementation Choice of Programming Language and Frameworks Structure of the VCG Program Proof Goals EFSM Assuming Safety Properties Challenges with Providing Assertions Relating SCC-Generating Statements to SCCs by the SOS Transition Rules Providing Assertions for Discrete Programs Providing Assertions for Hybrid Programs Paths with Common Steps Providing ODE Solutions Determining the Release Time of a Continuous Phase Parallelization Evaluation The Resulting VCG Program Application Limitations Conclusion Problems Possible Future Work A Example: Vector Length - Algorithm 67 B Example: Water Tank - Hybrid System 71 Bibliography 75 viii

9 List of Figures 3.1 Example of a Hybrid Automaton, taken from [1] Schizophrenic Quartz program Map: Condition incarnation for the macro step at l Examples of causally incorrect programs without (left) and with (right) logically consistent behaviors, according to [2] Parallel composition of flow statements [3] A while-loop entered at different locations irreducible state machine Overall function for checking properties Detailed steps of the VC computation Example: BouncingBall [3] ODE solution Implementation Structure Options to call the VCG program Type of a proof goal Type of a verification condition Type of EFSM nodes Transitions with different locations Example for the necessity of the absence reaction A safety property as an assumption Dependencies of a terminal assertion Terminal assertions of parallel SCC-generating statements Multiple SCCs for a combination of Statements Syntax tree of the program presented in figure Example for providing assertions inside programs EFSM of the assertions example Example of assertions provided for SCC-statements Combining approaches for providing assertions Combining approaches for providing continuous invariants Paths with common steps to SCCs Parallelization of independent verification conditions Performance comparison of Z3 and isat, with the number of VCs successfully proved; Average times of 20 iterations in ms (CPU: Intel i3-2120) Performance comparison of the scaled VectorLength example; Average times of 20 iterations in ms (CPU: Intel i3-2120) A.1 Quartz program of the 2-dimensional Vector Length algorithm [4] A.2 Assertions for the 2-dimensional Vector Length algorithm ix

10 LIST OF FIGURES A.3 SCC Mappings for the Vector Length algorithm A.4 EFSM: VectorLength A.5 Path Mappings for the Vector Length algorithm A.6 VectorLength: Verification Conditions for IB and IS B.1 Quartz programs of WaterTank systems [5] B.2 Assertions for the hybrid system: WaterTank B.3 Path mappings for the hybrid system: WaterTank B.4 Path mappings for the hybrid system: WaterTank B.5 EFSM: WaterTank B.6 WaterTank7: Verification Conditions for IB and IS x

11 ABBREVIATIONS Abbreviations MoC VC VCG SMT SCC DFS SGA AIF EFSM CTL LTL NLP MILP MINLP VHSIC HDL VHDL SOS ODE AMS Model of Computation Verification Condition Verification Condition Generation Satisfiability Modulo Theories Strongly Connected Component Depth-First Search Synchronous Guarded Actions Averest Intermediate Format Extended Finite State Machine Computation Tree Logic Linear Temporal Logic Non-Linear Programming Mixed Integer Linear Programming Mixed Integer Non-Linear Programming Very High Speed Integrated Circuit Hardware Description Language VHSIC HDL Structural Operational Semantics Ordinary Differential Equation Analog Mixed Signal xi

12 SYMBOLS Symbols [ϕ] x t x Substitution Replace x with x t in ϕ Φ Safety Property Boolean Expression φ Induction Base Boolean Expression φ Induction Step Boolean Expression I SCC Invariant Boolean Expression Ψ Continuous Invariant Boolean Expression V Variable QType E d Discrete Variable Environment V V alue E c Continuous Variable Environment V V alue s i State-machine State with index i Node of EFSM D d (s i ) Discrete Guarded Actions Set<Boolean Expression> D c (s i ) Continuous Guarded Actions Set<Boolean Expression> ϕ Transition Condition Boolean Expression α Precondition Boolean Expression β Path Conditions Boolean Expression list ψ Continuous Path Conditions Boolean Expression list γ Postcondition Boolean Expression xii

13 Chapter 1 Introduction 1.1 Motivation Many computer systems nowadays are embedded systems. Most of them are not even recognized by humans, since the systems themselves are hidden and there is hardly any interaction with humans directly, although humans are affected by these systems. Many embedded systems are so-called reactive systems, which react to inputs from their environment. Therefore, their internal state depends on the environment [2]. Applications using embedded systems are in many cases safety-critical. It is quite common to test software as well as hardware designs described in hardware description languages by simulation for various input values. However, when applying testing, only very few input combinations can be considered (in relation to all possible input combinations) and therefore the overall behavior of a system is observed only for very few states of that system and only very few program runs of such a system can be covered that way. This is insufficient for safety-critical applications. Therefore, formal methods are needed to check the system s behavior not for specific input combinations, but for all possible input combinations. Synchronous languages like Esterel [6] and Quartz [2] (an Esterel-like language developed by the Embedded Systems Group at the University of Kaiserslautern) offer a formal and deterministic semantics (Quartz additionally supports the modeling of non-deterministic behavior) as well as an abstraction to logical time. This is motivated by digital circuits, which compute output signals depending on input signals and a clock tick. In Quartz program code, progression of logical time is noted explicitly by program statements [7]. Since reactive embedded systems often depend on continuous behaviors of their environment, the overall system is not purely discrete. To describe such hybrid systems, the Quartz language has been extended to Hybrid Quartz [3]. Embedded control systems are examples of hybrid systems and they are used e.g. in applications in the automotive industry: engines with continuous fuel injection controlled by a microprocessor. Verification matters for hybrid systems as well since they are more 1

14 Chapter 1 Introduction frequently used in safety-critical applications [1]. 1.2 Task and Scope of the Thesis In the paper Verification Condition Generation for Hybrid Systems [8], a method was proposed that allows to prove safety properties 1 for imperative synchronous languages. Based on that paper, a verification tool was implemented (extending existing program code of the Embedded System Group and utilizing the Averest framework [4]) for the interactive verification of synchronous programs. To generate proof goals, that can then be checked for validity by an SMT solver, paths are built for the state machine of these synchronous programs and for those paths, verification conditions are generated that include the assertions provided by the user. Since assertions can be given in multiple ways and the most convenient way for the user to provide assertion information might depend on the underlying program and its structure, the tool accepts multiple ways of providing assertions. Generation of Verification Conditions From a program s state machine s paths, path formulas are generated. Since these verification conditions are related to some component of the program (one or multiple program statements), solving such a VC 2 returns information to the user in that context. If one verification condition gets disproved, the user can figure out whether a provided assertion was incorrect or if the safety property does not hold for the corresponding program. Application of SMT Solvers Modern SMT solvers like Z3 or isat are capable of solving quite large formulas and are therefore suitable for the problems described in this thesis. 1.3 Outline In chapter 2, other approaches regarding the verification of hybrid systems are discussed. Subsequent to this, the fundamentals required for this thesis s topic are given in chapter 3. This comprises imperative synchronous programming languages, hybrid systems and SMT solvers. Next, the implementation of the VCG program is discussed in chapter 5 in detail. It is described what needs to be implemented to apply this verification tool to both discrete and hybrid synchronous programs and all approaches for the actual implementation are explained in detail. The implementation s results are then discussed in chapter 6 as well as examples for the application of the VCG program, which are given in the appendixes (A,B). Finally, the thesis is concluded in chapter 7. 1 Safety property: a property that holds all the time 2 VC: Verification Condition 2

15 Chapter 2 Related Work In this chapter, work related to this thesis is summarized. This comprises work related to the Quartz language and its representations as well as work related to software verification and the verification of hybrid systems. 2.1 Modeling of Hybrid Systems Hybrid systems combine discrete state machines with differential equations. They can be modeled with e.g. Hybrid Automata or Hybrid Quartz. Hybrid Automata One popular model [9] that has been developed for mixed discretecontinuous systems is a Hybrid Automaton. The goal of Hybrid Automata is to be able to apply model-checking techniques to hybrid systems. Hybrid Automata have discrete as well as continuous changes whereas the abstraction to a transition system yields a fully discrete one [1]. Hybrid Quartz Synchronous languages are suitable for the development of reactive systems [10]. To include hybrid systems as well, the syntax and semantics of the Quartz language have been extended to Hybrid Quartz by adding program statements and data types. Hybrid Quartz is related to Hybrid Automata and is able to model all deterministic Hybrid Automata [3]. 2.2 Verification of Synchronous Programs For the imperative synchronous language Quartz, multiple representations exist. Most notably, an intermediate representation based on synchronous guarded actions and a state-machine based representation exist. Many verification approaches utilize these representations. 3

16 Chapter 2 Related Work Interactive Verification by Restriction of Quartz: SSTA Normal Form An approach for the application of Hoare logic to synchronous programs described in the Quartz language restricted to a normal form is discussed in the thesis Interactive Verification of Synchronous Systems [11]. Since Hoare logic cannot be applied to synchronous programs in general, the synchronous programs are restricted. This approach for interactive verification at the source code level is summarized in detail in section Interactive Verification with Intermediate Representations An alternative approach for the interactive verification of synchronous programs makes use of an intermediate format, the AIF 1, which is used as a representation system additional to a Quartz program. The Quartz program is compiled to a set of synchronous guarded actions, to which both assumptions and assertions are added. This guarded action set is then used as a system description as well as a proof goal. Proof rules, which decompose the intermediate format are then selected by the user on the intermediate format. Since there is a back-annotation from the AIF to the Quartz code, the human-readable program code can still be used while selecting proof rules. For this approach an EFSM 2 can be utilized and control flow states are enumerated. Checking safety properties can then often be done locally in each state. Furthermore, an extension to this approach supports logic specifications in LTL 3 [11]. In addition, a translation from the AIF to Isabelle/HOL (a proof assistant for Higher- Order Logic) exists, for which a variable is interpreted as a function whose value depends on some point in time. Accordingly, guarded actions are interpreted as predicates describing the variables, whereas the program itself is interpreted as a boolean formula over time [12]. 2.3 Hybrid System Verification Approaches and Tools Hybrid systems usually contain differential equation systems and a release condition for the continuous phase (e.g. in Hybrid Automata and Hybrid Quartz). The outcome of this is an optimization problem. Depending on the system, various optimization problems need to be solved symbolically. The most general one is the Mixed Integer Non-Linear Programming (MINLP) problem, whereas Non-Linear Programming (NLP) and Mixed Integer Linear Programming are subproblems. For these, multiple solvers exist [13]. 1 AIF: Averest Intermediate Format 2 EFSM: Extended Finite State Machine 3 LTL: Linear Temporal Logic 4

17 Chapter 2 Related Work SMT Solvers Within the set of applicable tools for hybrid system verification there are SMT 4 solvers such as Z3 as well. These are discussed in more detail in section since some of them are used for implementations for this thesis. The KeYmaera Prover KeYmaera is a hybrid theorem prover that combines various prover techniques such as deductive, real algebraic, and computer algebraic. This prover combines KeY (deductive theorem prover) with Mathematica (computer algebra system). KeYmaera makes use of a first-order dynamic logic for hybrid programs [14]. KeYmaera as a Target Tool for Averest For the Averest system, targeting an interactive theorem prover was preferred, since it allows the modeling capabilities of Quartz to be combined with verification capabilities for continuous components of KeYmaera, which is not suitable for modeling parallel compositions. The Averest prover is used for the interactive verification task. Only assertions for continuous parts of a program are verified by KeYmaera, since the language of KeYmaera differs especially in the discrete semantics [15]. 4 SMT: Satisfiability Modulo Theories 5

18

19 Chapter 3 Fundamentals This chapter provides a summary of the synchronous model of computation, the language Quartz and its representations and properties as well as a summary of the fundamentals required for hybrid systems. Lastly, it contains various definitions and explanations of verifications approaches that are related to the implementation described in chapter Modeling of Hybrid Systems The model of hybrid systems combines discrete state machines with differential equations for continuous behavior and is considered appropriate to model embedded control systems. Due to the addition of differential equations, hybrid systems cover modeling controllers as well as their environment [9] Hybrid Systems, Hybrid Automata and ODEs A Hybrid Automaton is a formal model to describe mixed discrete-continuous systems. Additionally to discrete dynamics of e.g. controllers, continuous dynamics can be modeled by using differential equations [1]. Thereby, both digital systems and their environments can be modeled. Definition (Hybrid Automaton [1]) A Hybrid Automaton H consist of: Variables finitely many real-numbered variables x i, corresponding Control Graph Predicates Events derivatives ẋ i and values at the conclusion of a discrete change x i finite directed multigraph with control modes V and control switches E the initial, invariant, and flow conditions per vertex: init(v), inv(v), and flow(v) jump(e): condition for a transition to be taken a labeling function event(e) assigns an event per control switch In figure 3.1, an example of a Hybrid Automaton is given. It models a thermostat that turns on a heater to keep the measured temperature in its intended range. For 7

20 Chapter 3 Fundamentals this purpose it has the two discrete states On and Off with flow conditions given as differential equations that describe the behavior of the temperature. x=20 Off ẋ = 0.1x x 18 x > 21 x < 19 On ẋ = 5 0.1x x 22 initial condition x = 20 jump conditions x > 21, x < 19 invariant conditions x 18, x 22 flow conditions ẋ = 0.1x, ẋ = 5 0.1x events Off, On Figure 3.1: Example of a Hybrid Automaton, taken from [1] Ordinary Differential Equations Ordinary differential equations can be used to describe continuous dynamics of a system. They are i.e. used by Hybrid Automata and Hybrid Quartz. Definition (Ordinary Differential Equation [16]) Let f(x) define a function of x on an interval I. An ODE is an equation involving x, f(x) and its derivatives. The order of an ODE is the order of the highest non-removable derivative involved in the equation. To reason about a system s behavior given by differential equations, it is often necessary to solve the differential equation system to gain functions over physical time. Definition (Solution of an ODE [16]) A function f(x) is a solution of an ODE involving x, f(x) and the derivatives of f(x), if it satisfies the equation for every x. i.e.: f(x) is a solution of the differential equation F (x, y, y,..., y (n) ) = 0 if F [x, f(x), f (x),..., f (n) (x)] = 0 Therefore, solving a differential equation means retrieving a function which is a solution of that differential equation Models of Computation and Synchronous Languages MoCs 1 are more abstract than programming languages and help to classify these. Both communication and the triggers to execute (concurrent) actions are determined by a MoC [2]. Hardware description languages like VHDL 2 usually rely on the event-triggered MoC, where computations e.g. are triggered by some event or by reaching some point in time. Since languages based on the event-triggered MoC are not suitable for verification, the synchronous MoC is preferred for this. 1 MoC: Model of Computation 2 VHDL: (Very high speed integrated circuit) Hardware Description Language 8

21 Chapter 3 Fundamentals The Synchronous MoC A suitable MoC for the design and verification of reactive systems is the synchronous MoC. It is based on perfect synchrony, so that statements are executed in zero logical time at one point in logical time. A global logical clock determines these logical time steps. At each of these logical points in time, a reaction step happens, at which all inputs are read and all outputs are computed. Since statements do not consume logical time, this consumption has to be programmed using specific statements (e.g. a pause statement). Since only a couple of control flow statements are active at one point in logical time, synchronous programs can be translated to state machines describing their control flow. The data flow can be determined for these states and synchronous programs can therefore be translated to sequential imperative programs as well as to hardware description languages. Additionally, the differentiation between control and data flow results in a better usability for verification. The data flow can be formulated in terms of guarded actions of the form (γ, A) in which γ is a condition under which the action A is executed [2, 7]. Throughout this thesis, the term logical time is used to refer to the logical time in the synchronous MoC. In addition, the terms physical time and continuous time are used to refer to physical time, with continuous time referring to the physical time during the continuous phase of a state. Synchronous Languages Many embedded systems have an ongoing interaction with their environment and are therefore called reactive systems. Since these systems are often used in safety-critical applications, testing is insufficient and formal verification matters. To meet the requirements of modeling such systems, a language additionally needs a formal semantics that allows the translation to transition systems. Traditional programming languages are therefore not suitable for the development of reactive systems. Furthermore, they usually don t allow synthesis to hardware and software for one single program and the required notion of logical time and concurrency is missing. Synchronous programming languages, which are based on the synchronous MoC, have therefore emerged to match this task [2] The Synchronous Programming Language Quartz Quartz is an imperative synchronous programming language that emerged from the Esterel language. Quartz programs can be synthesized to both hardware and software. The language is developed by the Embedded Systems Group [17] at the University of Kaiserslautern Compilation to Guarded Actions and the AIF With the Quartz compiler, Quartz programs can be compiled to the Averest Intermediate Format (AIF). This format contains the compiled Quartz program represented 9

22 Chapter 3 Fundamentals as guarded actions and further transformations are then based on the guarded action system. For this implementation, a similar intermediate representation is employed Macro Steps and Micro Steps Since Quartz is a synchronous language, it has so-called macro steps (i.e. reactions) and micro steps. One macro step contains all actions in between two pause-statements, whereas one micro step is one single action. In a macro step, all inputs are read and all outputs are computed. The computation happens according to data dependencies. Note however, that simply statically scheduling the guarded actions of their corresponding macro step is insufficient because their execution depends on their guards and only some actions are executed - those whose guards evaluate to true. Therefore they have to be either evaluated dynamically or translated to control flow (in case of software synthesis) [2]. Macro steps are also called reactions and the programming paradigm for macro steps is therefore reactive programming, which is declarative. Despite this, Quartz is called an imperative synchronous language because of the notion of a next macro step triggered by moves in the control flow and a set of control flow locations becoming active for that next reaction (see ) Data Types Due to the notion of macro steps, where one variable may not be written by different conflicting actions, which would lead to write conflicts and causality cycles, atomic and composite data types need to be distinguished. Composite data types may be written multiple times in one macro step - as long as these are writes to different components. Atomic data types on the other hand may only be written once per macro step. When a variable is declared, the following information has to be provided: information flow, storage, and data type [2]. Remark (Information Flow [2]) The information flow determines how variables can be accessed. Local variables inside a module are classified separately from input and output variables. Flow Declaration and Access input Input variables of a module, can only be read, declared with? inout InOut variables of a module, can be read and written (in Quartz these are actually controllable input variables) output Output variables of a module, can only be written, declared with! local Local variables inside a module, can be read and written 10

23 Chapter 3 Fundamentals Remark (Storage Types, Reaction to Absence [2]) Whenever there is no action writing to a variable in a macro step, a so-called reaction to absence occurs. This reaction to absence depends on the variable s data type and on its storage type: Storage Impact on Absence event memorized hybrid correlates to signals absence: set to default value correlates to buffered values absence: keeps previous value correlates to continuous evolution over time absence: keeps the value of the previous discrete environment The distinction between event variables and memorized variables is related to hardware circuits. Outputs of combinational gates can be modeled with event variables, since they are not memorized. Outputs of registers on the other hand are memorized. Variables declared as hybrid are introduced by Hybrid Quartz. In the discrete environment, they behave similarly to memorized variables. In the continuous environment, they evolve over time. Since dynamic typing is inappropriate for hardware description languages, Quartz is a statically typed language. Therefore, the type of an expression can be determined at compile time. It does not change during run time and represents a set of values [2]. Remark (Data Types [2]) atomic data types: bool boolean values true and false bv[n] bitvector, bounded length n > 0 nat<n> int<n> bv nat int unsigned integer, bounded signed integer, bounded bitvector, unbounded length unsigned integer, unbounded signed integer, unbounded composite data types: array(α,n) array of type α with n field entries α β tuple composed of α and β Specifications Quartz programs feature a temporal behavior and for these behaviors, Quartz has builtin verification capabilities. Specifications can be stated in e.g. LTL, CTL or the µ- calculus [2]. For the implementation presented in chapter 5, specifications can be used to provide logical formulas (e.g. assumptions about variable ranges for input and output variables can be given as safety properties). 11

24 Chapter 3 Fundamentals Modules and Statements In Quartz, there is a distinction between behavioral and specification modules. While specification modules simply contain specifications, behavioral modules describe a system and can be viewed as hardware circuits. For some input data streams, they generate some output data streams. Due to the synchronous MoC, these data streams have a logical time (i.e. a data steam is an infinite sequences of values of its data type). In addition to input and output variables, a module s semantics is determined by its body statement. Statements contained in this body statement may contain control flow locations [2]. Definition (Active Statement [2]) A statement is called active at some point t in logical time iff some control flow locations inside that statement evaluate to true in the variable environment at that time t Depending on the statement, it may consume logical time for its execution. Statements are called instantaneous if they are executed in zero logical time. There exist various kinds of statements [2]: Statements Related to the Control Flow Statements like e.g. the pause-statement determine the control flow of a Quartz program. These statements can be annotated with a location variable (i.e. a label, e.g. l:pause;) which then encodes the control flow. The location variables are boolean variables that evaluate to true iff the control flow is at that location [2]. Delayed Assignments Actions can be either immediate assignments of the form x = τ or delayed assignments of the form next(x) = τ. For the latter, τ is evaluated by the current variable environment and the value of x is determined for the variable environment of the next point in logical time. The actions are executed inside macro steps in zero logical time [2]. Threads Since modeling concurrency is of importance for synchronous languages, statements can not only be executed in sequence but also in parallel. The most important possibilities how to combine statements are: S 1 ;S 2 sequential: S 1 immediately starts, S 2 immediately starts if S 1 is instantaneous, otherwise S 2 is started in the macro step in which S 1 terminates (but only if S 1 actually terminates) S 1 S 2 synchronous parallel: S 1 and S 2 are executed in lockstep. In the case of synchronous or asynchronous parallel executions, the macro steps may contain micro steps of all or some threads. 12

25 Chapter 3 Fundamentals For parallel executions, two variants exist: disjunctive (e.g. (S 1 S 2 )) and conjunctive (e.g. S 1 &&S 2 ). The former terminates only when all threads have terminated while the latter terminates when at least one thread has terminated. In addition to the synchronous parallel composition, Quartz features asynchronous parallel compositions (S 1 S 2 ) and interleaved parallel compositions (S 1 S 2 ). The synchronous parallel statement is deterministic, while the asynchronous and the interleaved statements are non-deterministic [2]. Statements Overview for this thesis are listed below, according to [2]: Actions x = τ; next(x) = τ; l : pause; if(σ) S 1 if(σ) S 1 else S 2 S 1 S 2 and S 1 &&S 2 while(σ) S loop S abort S when(σ) weak suspend S when(σ) l : immediate suspend S when(σ) Quartz contains multiple statements. The most relevant ones immediate assignment, x: left-hand side expression, τ: expression delayeed assignment Wait Statements ends macro step; next macro step at location l Conditional Statements conditional statement conditional statement with else case Parallel Control Flow parallel synchronous execution, in lockstep Loops while loop, only entered if σ holds infinite loop Abortion and Suspension strong abortion weak suspend immediate suspend The abort statement moves the control flow out of the statement S once the condition σ holds. For the immediate variant of abort, the condition σ is additionally evaluated at starting time. The weak abort executes actions of statement S in a macro step even if S was aborted in that macro step. The suspend statement prevents the control flow from moving inside the statement S, if σ evaluates to true and its immediate variant works in the same way as for the abort statement. The weak variant additionally executes actions of S in macro steps where S is suspended under condition σ [2] Semantic Problems For synchronous languages, semantic problems may occur that have to be resolved [2]. It is therefore necessary to clarify what the semantics of a program yielding these problems is. 13

26 Chapter 3 Fundamentals Schizophrenic Statements In the case of loop-like statements (statements that introduce a loop in the control flow graph of the program), it may occur that one variable has more than one instance. Such statements are called schizophrenic. Although a variable s value is evaluated only once per macro step, multiple instances exist if scopes are left and re-entered and the variable is therefore reincarnated. For those reincarnations, copies of the variable have to be generated [2]. Figure 3.3 shows the preconditions under which a reincarnation for variable b exists. Assuming that the control flow currently lasts at location l 1, the loop is re-entered in the corresponding macro step under condition j and thus a reincarnation exists under that precondition. 1 module schizo(bool?j) { 2 while(j){ 3 bool b; 4 b=true; 5 l1:pause; 6 b=false; 7 } 8 } Precondition Incarnation j b@1 true b Figure 3.3: Map: Condition incarnation for the macro step at l 1 Figure 3.2: Schizophrenic Quartz program Causality Causality cycles occur e.g. if an action changes a variable on which the action s precondition depends. Thus, it is necessary for the compiler to detect such cycles to avoid e.g. deadlocks [2]. 1 module P05(event o1,o2){ 2 if(o1) o2=true; 3 if(!o2)o1=true; 4 } 1 module P06(event o1,o2){ 2 if(o1) o2=true; 3 if(o2) o1=true; 4 } Figure 3.4: Examples of causally incorrect programs without (left) and with (right) logically consistent behaviors, according to [2] Structural Operational Semantics The formal semantics of Quartz are given by the structural operational semantics (SOS) rules. Two different kinds of rules are distinguished: the SOS transition rules and the SOS reaction rules. These rules are the basis for interpreters that can determine whether Quartz programs are causally correct. A complete listing of these rules can be found in ([2], chapter 4.2 and 4.3). In addition, symbolic versions of the SOS rules exist (see [18] or [2], chapter 4.5 and 4.6). 14

27 Chapter 3 Fundamentals SOS Transition Rules Individual steps of transitions are described by the SOS transition rules, for which the complete knowledge of the corresponding environment is the basis. By the SOS transition rules [2]: consistency of the environment can be checked by considering the reactions and the reactions to absence delayed actions can be computed by collecting pairs of (variable,value), which are then forwarded to the next macro step residual statements can be computed (statements that are to be executed in the next macro step) Symbolic SOS Transition Rules The SOS transition rules are defined such that they depend on a macro step s environment. Since Quartz contains infinite data types, it is impossible to enumerate all cases and even for the finite data types, it is still not practicable. Therefore, the symbolic SOS transition rules can be applied. These symbolic rules are called control flow predicates and they analyze all inputs at compile time by utilizing symbolic representations instead of environments that are updated. Thus, the symbolic SOS rules can be used for formal verification [2]. Remark (Most important functions [2]) For the control flow predicates of the symbolic SOS rules, various functions are defined: incarnation level function lbls(s) in(s) inst (S) enter (S) term (S) move(s) ActSurf (ϕ,s) stutter(s) set of control flow locations, labels inside statement S boolean formula of labels that determines whether a location inside S is active instantaneous execution of S describes the next control flow locations condition for leaving S, which can be re-entered by e.g. loops describes transitions from one Set<label> to another one inside S set of guarded actions of the surface under precondition ϕ : l lbls(s) l = next(l) freezing the current control flow (for suspension statements) SOS Reaction Rules The SOS reaction rules compute for given inputs and one macro step the corresponding outputs. If a program s unique reaction can be computed by the SOS reaction rules, it is causally correct. Algorithmically, these rules compute a refinement of an environment by approximations of the set of actions that are actually executed in the current macro step. In doing so, both a pessimistic and an optimistic approximation is computed to determine these actions [2]. Symbolic SOS Reaction Rules For the SOS reaction rules, a symbolic version exists as well. It is therefore possible to use symbolic descriptions to analyze Quartz s 15

28 Chapter 3 Fundamentals full semantics. For these rules, an additional boolean variable x is introduced per variable x to encode the unknown value (x holds iff the value of x is known) [2] Graph Definitions The publications considered subsequently make use of control flow graphs to reason about programs. Therefore, the required definitions that are common in literature are listed: Definition (Graph, Subgraph, Directed Graph [19]) A graph is a tuple G = (V, E) of disjoint sets where E (V V ) The elements of V are called vertices and the elements of E are called edges. Let G 1 = (V 1, E 1 ) and G 2 = (V 2, E 2 ). If V 2 V 1 and E 2 E 1 then G 2 is called a subgraph of G 1. A proper subgraph of G 1 does not contain at least one edge or vertex of G 1 (i.e. V 2 V 1 and E 2 E 1 and (either V 2 V 1 or E 2 E 1 ) ). A directed graph D is a tuple (V, E) of disjoint sets of vertexes and edges with two additional functions: init: E V, assigns an initial (i.e. source) vertex to each edge dest: E V, assigns a destination vertex to each edge Each edge e is then directed from init(e) to dest(e). If init(e) = dest(e) then e is called a loop (or self-loop). A multi graph is a graph with an additional function E V [V ] 2 that assigns one or two vertexes to each edge. It may have self-loops and multiple-edges and can be seen as a directed graph minus its orientation. While the terms loop and self-loop are both used in literature for edges from a vertex to itself, the term self-loop is preferred in this thesis. The term loop is subsequently used to refer to statements of the Quartz language. Definition (Path [20]) If G = (V, E) is a graph, a path p : v w is a sequence of vertexes and edges leading from v to w. A simple path has only distinct vertexes, while a closed path p : v v leads to the vertex it originated from. A cycle is a closed path p : v v where all of its edges and vertexes are distinct, except for the vertex v, which occurs as the initial vertex and as the last destination vertex. In this thesis, simple paths that lead to strongly connected components are considered as well as paths inside these components that only consist of a single step. 16

29 Chapter 3 Fundamentals Definition (Back edge, Irreducible Graph [21 23]) A vertex v is a dominator for vertex w v if every path from the start vertex (i.e. the initial state in case of state machines) to w contains v. Retreating edges are edges to ancestor vertexes (vertexes closer to the start vertex on some path) and a back edge is a retreating edge whose target vertex dominates its source vertex. A flow graph is called reducible if it can be transformed into a single node by repeatedly removing loops and replacing pairs of vertexes (v, w) with a single vertex if the only edge to w has source v. Otherwise it is called irreducible. In reducible graphs, retreating edges are back edges for any DFST (depth-first spanning tree). A graph is reducible if for paths from the start vertex, every loop has a single entry vertex. Synchronous programs yield state machines that are irreducible graphs due to the abstraction to logical time [8]. When a loop statement is entered, there may be multiple possibilities for the next location the control flow rests at. This results in multiple entry vertexes for a loop. Definition (Strongly Connected Component [20]) Let G be a directed graph. Suppose that for each pair of vertices (v, w) in G, there exist paths p 1 : v w and p 2 : w v. Then G is said to be strongly connected. A strongly connected component of a graph is therefore a strongly connected subgraph of that graph (if it is not a proper subgraph of some other strongly connected subgraph). Strongly connected components can be computed by Tarjan s algorithm [20], which applies a depth-first search (DFS) on the graph and yields the graph s SCCs with indexes Extended Finite State Machine Beside the transformation to guarded actions, a synchronous program can be translated to an EFSM 3, which describes a possibly infinite transition system with finitely many nodes and transitions between them. Definition (Extended Finite State Machine [24]) An Extended Finite State Machine is a tuple (S, s 0, T, D) where: S set of states, finite s 0 T (S C S) D(s) initial state, s 0 S transitions: current state condition next state maps to every state the guarded actions to be executed in that state (s S) The states of the EFSM contain guarded actions of their corresponding macro step. The EFSM does moreover differ from classic control-data-flow graphs since the guarded actions are executed according to the synchronous MoC [24]. It is possible to add control flow guarded actions to the states and thereby gain access 3 EFSM: Extended Finite State Machine 17

30 Chapter 3 Fundamentals to the boolean control flow variables, whose values are in each state determined for the succeeding state. Whenever a state of the EFSM is visited, a set of control flow variables holds. This set describes at which locations in the Quartz program the control flow currently rests. The control flow variables thereby help to determine the relation between program statements and EFSM states Hybrid Quartz The hardware of an embedded system is digital and can therefore be modeled by a discrete state transition system. To describe hybrid systems with their continuous environments, this is certainly not sufficient. The continuous environment has to be considered and the discrete transitions may influence the continuous evolution of the environment. To gain a holistic view of an embedded system and its environment, simulation and verification of hybrid system descriptions is necessary. Synthesis of mixed-signal systems however is not necessarily needed for this [2]. There are multiple advantages of synchronous languages that make them suitable for the modeling and the verification of hybrid systems: discrete transition systems of synchronous programs can be obtained efficiently (the continuous behavior is added to the discrete states in case of programs describing hybrid systems) symbolic representations used in formal verification can be computed formal semantics of the languages (AMS 4 extensions of hardware description languages usually lack formal semantics) modeling of both the discrete and the continuous part of a system simulation through operational semantics Therefore, the Quartz language was extended for the hybrid case, which allows to add the continuous dynamics of a system as differential equation systems. This hybrid extension is related to Hybrid Automata in that the EFSM generated from a Hybrid Quartz program behaves similarly. Since Hybrid Quartz extends Quartz s syntax and semantics, purely discrete Quartz programs are still compatible [3]. Hybrid Quartz is fully deterministic and can model all deterministic Hybrid Automata. For the support of non-determinism, the language s syntax and semantics require only minor changes. For Hybrid Quartz, macro steps are extended by a continuous phase. Only this continuous part consumes physical time [3]. 4 AMS: analog mixed signal 18

31 Chapter 3 Fundamentals Model of Time Discrete transitions in Hybrid Quartz have no time-delay, which is advantageous because it doesn t produce challenges for modeling, simulation, and verification and still covers the expressiveness of other models. Models that attach a time-delay function to discrete transitions can be expressed by replacing a single discrete transition with a sequence of discrete transitions and continuous phases [3] Execution Order in Macro Steps Inside a macro step, immediate discrete and delayed discrete actions have to be executed as well as continuous actions. Thereby, the execution order matters. Definition (Execution Order [3]) g{i,c,d} n evaluation of the guards of macro step n computation of the right hand sides of actions of macro step n c n {i,c,d} a n {i,c,d} i c assignment of the actions of macro step n immediate continuous d delayed The execution order then is: step n a n 1 d g n i c n i a n i {E discr } } {{ } discrete computation g n c c n c a n c { E discr E cont } } {{ } continuous computation gd n cn step n+1 d }{{} delayed comp. (3.1) The discrete computation contains the delayed assignments a n 1 d of the previous macro step and the evaluation of the current environment, which it then yields. The continuous computation contains the evaluation of the guards of the continuous actions and the determination of the continuous environment. Then, both E discrete and E continuous are determined. At last, the delayed actions are computed for the next macro step. By choosing this execution order, it is possible for the delayed assignments to depend on the continuous environment (i.e. the last value of the variables in the continuous phase) [3] Syntax and Semantics Syntax The storage types and data types that exist in Quartz are not sufficient for modeling hybrid systems. Therefore, the storage type hybrid was introduced. These 19

32 Chapter 3 Fundamentals hybrid variables may only be declared as variables of data type real, since other data types don t make sense for hybrid variables and expressions in which a hybrid variable is not declared as real are therefore not valid. Hybrid variables differ from discrete reals. In the discrete environment E disc, a variable declared as hybrid real behaves similarly to a variable declared as memorized real. The value for the discrete environment of the current macro step is determined either by some action or by the reaction to absence. Since the reaction to absence for both memorized and hybrid variables is defined as the last known value, they behave differently in this case. Hybrid variables are functions over physical time and therefore change their value in the continuous phase, for which the continuous environment E cont is computed. Their last known value for some macro step is therefore not the value of the previous macro step s discrete environment, but the value of the previous continuous environment at release time (the point in physical time during the continuous phase where a transition to the next macro step is taken). Due to this additional continuous environment E cont, two variable environments (E disc,e cont ) have to be considered for evaluating expressions. The continuous environment can be accessed by the operator cont(expr), which can only be used in continuous and delayed actions (since E cont is computed after E disc, E cont cannot be accessed by immediate actions). The derivation rule drv(x) τ describes differential equations and the continuous assignment rule x τ assigns functions to hybrid variables during the continuous phase. On their right hand side, both E disc and the hybrid variables during the continuous phase can be accessed (Example: x cont(y) + x). If there is no such action for a variable in one macro step, the continuous reaction to absence has to be executed. Since keeping the previous value means either an assignment of the continuous value to that value or setting the derivation to zero, the absence action that has to be added is either x x or drv(x) 0.0 [3]. Since Hybrid Quartz is an extension, it is desired to keep the stability under parallel composition. This means that the traces of a program are time-equivalent (the programs execution paths are equivalent with respect to time) with the traces of its component that is composed in parallel with another Quartz program. Because parallel hybrid program fragments may have different release conditions, it may occur that the release condition of one fragment already holds while the other one does not. The continuous phase of the other program fragment then has to be restarted in the next macro step [3]. 1 flow{ 2 drv(x)<-1 3 }until(x>=2); 4 l1:pause; 1 flow{ 2 drv(y)<-2 3 }until(y>=2); 4 l2:pause; Figure 3.5: Parallel composition of flow statements [3] 20

33 Chapter 3 Fundamentals An example can be found in figure 3.5, where the program fragment on the right has a release condition (y 2) that is satisfied before the other release condition (x 2) holds. Therefore, the action drv(x) 1 with release condition (x 2) has to be restarted in the next macro step. Otherwise that program s trace would not be time-equivalent to the trace of its fragment s isolated execution. It is therefore necessary to know which actions do have to be restarted. Thus, continuous actions in Hybrid Quartz are always collected in flow statements, which is necessary to achieve stability under parallel composition. Due to this encapsulation and the fact that a flow statement (which is a micro step) is linked to control flow locations, continuous actions can be restarted if necessary [3]. Remark (Syntax Overview [3]) hybrid real x declaration of a hybrid variable cont(expr) x τ drv(x) τ operator for accessing hybrid variables during the continuous phase cont(expr): action for the continuous rule Expression -> Expression action for the derivation rule (to provide ODEs) 1 rl,cl:flow{ continuous actions encapsulated in a flow 2 x <- τ statement, which is linked to control flow 3 drv(x) <- τ labels (rl : release label, cl : label of the 4 }until(σ) continuous phase) Flow statements without any release condition only terminate if the release condition of a flow statement executed in parallel holds. Thus, they do not influence the program s control flow. The combination of flow statements with Quartz s preemption statements may result in conflicts. Since preemption statements are evaluated in the discrete environment, they take precedence over flow statements [3]. Semantics The semantics of Hybrid Quartz programs is given by the execution order (see definition ), the continuous absence reaction and the semantics of discrete Quartz. The corresponding additional SOS rules can be found in ([3], chapter 3.4). For the continuous phase, two steps have to be considered [3]: Solve the system of active ODEs given by the continuous actions. Thereby, the system of continuous functions is determined. Solve the optimization problem for the release condition and thereby gain the release time t release (the duration of the continuous phase). The release time is defined as the first point in continuous time where the release condition holds. It is not possible to determine t release symbolically in general (since the problem is undecidable in general). 21

34 Chapter 3 Fundamentals Properties and Challenges of Models for Hybrid Systems Stuttering Transitions Continuous phases that do not advance in physical time and just move on to another state by a discrete transition are called stuttering transitions. They are necessary in case of parallel compositions in which one subsystem takes a discrete transition while the other subsystems don t. Since these transitions do not influence most verification issues, they are part of Hybrid Quartz [3]. Urgency of Discrete Transitions Transitions that must be taken the first time their release condition evaluates to true are called urgent whereas non-urgent transitions may be taken any time their condition becomes true. Since Hybrid Quartz is supposed to be deterministic, only urgent discrete transitions are allowed [3]. Zeno Behavior The situation of time advancement becoming infinitesimal due to an alternation between continuous phases and non-stuttering discrete transitions is called zeno behavior. In this case the continuous phase gets shorter with each iteration. Hybrid Automata (or Hybrid Quartz programs) with this behavior are inconsistent (neither do they have finitely many transitions nor do they eventually stay in a continuous phase) [3]. 3.2 Verification of Hybrid and Synchronous Systems Although there are multiple tools for the verification of hybrid systems, the problem itself is challenging. Scalability for example is one of the most important issues [9]. Hybrid system verification tools make use of the techniques discussed here Model Checking and Deductive Techniques Model checking is the problem of evaluating a given formula (e.g. in temporal logics) in a given model [10]. Though being automated is advantageous, model checking usually does not scale well. Deductive techniques on the other hand can be applied to prevent state space explosions, but require user interaction [8] SMT Solvers SMT 5 solvers decide the satisfiability or validity of formulas in first order logic [25]. For this thesis, they are used to check the validity of verification conditions. Both Z3 and isat3 are used as target tools for the implementation presented in this thesis. Z3 Z3 is an SMT solver implemented in C++ that contains various components: a DPLL 6 -based SAT solver, theory solvers (e.g. for the theory of linear arithmetic) and an E-matching abstract machine [25]. 5 SMT: satisfiability modulo theories 6 DPLL: Davis-Putnam-Logemann-Loveland algorithm 22

35 Chapter 3 Fundamentals isat isat is an DPLL-based SMT solver as well. It integrates interval-based arithmetic constraint solving and does not use separate solvers for arithmetic decisions. Furthermore, it is not limited to linear arithmetic and can deal with nonlinear constraints [26] Restriction of Quartz: SSTA Normal Form In the thesis Interactive Verification of Synchronous Systems [11], an approach for the application of Hoare logic to synchronous programs of the Quartz language is discussed. However, Hoare logic cannot be applied to synchronous programs in general because the synchronous MoC 7 differs from the sequential MoC. Applying the rules of Hoare logic, variables are updated after each assignment just as in the sequential MoC, whereas for the synchronous MoC multiple assignments are executed at the same logical point in time. These models are therefore not compatible, since in the synchronous MoC only macro steps that consume logical time can have pre- and post-conditions [11]. Many difficulties emerge trying to define a Hoare calculus for synchronous languages. The most important ones are [11]: In the synchronous MoC, variables are updated synchronously at the beginning of a macro step. Micro steps do not update the variable environment - unlike the assignment rule of the Hoare calculus / the sequential MoC. Assignments inside one macro step may belong to various program statements (e.g. statements inside parallel composition). This is not compatible to Hoare logic, since a global view of the program would be needed. In the sequential MoC there are no delayed assignments and there is no reaction to absence. One possible approach would be to translate synchronous programs to sequential programs and then apply the rules of the Hoare calculus. Though applicable, it has the drawback that the original control flow is destroyed, which makes user interaction inconvenient (or even inapplicable in practice). Due to this notion of micro steps and macro steps and the incompatibility to the sequential MoC, another approach has been suggested and described: Step 1: Transformation of the synchronous program into the SSTA (sequential synchronous tuple assignment) normal form, collecting all micro steps and bundling them into an assignment statement. All Quartz programs (without parallel statements) can be transformed into this normal form, requiring additional variables. The advantage of this normal form is the preservation of the synchronous program s structure, hence the invariants of the original program can be used, which is convenient for interactive verification. 7 MoC: Model of Computation 23

36 Chapter 3 Fundamentals Step 2: Application of a Hoare logic extended by further rules to the transformed program. Definition (Synchronous Tuple Assignments (STAs)[11]) If the left-hand side expressions x i and y i are pairwise different for all i {1..m} and their assignments x i = τ i and delayed assignments next(y i ) = π i are ordered by their indexes so that no RAW (read-after-write) conflicts occur, then the statement (x 1,..., x m ).(y 1,..., y m ) = (τ 1,..., τ m ).(π 1,..., π m ) is a synchronous tuple assignment. Definition (SSTA form [11]) A synchronous program is in sequential synchronous tuple assignment form if all its actions are STAs and there is at least one pause statement between the execution of two STAs. Thereby, the behavior of a macro step is collected into STAs and at most one STA is executed per macro step for programs in SSTA form. Parallel statements are prohibited. To apply the Hoare calculus to an SSTA-transformed program, additional rules for tupleassignments and for the pause statement are introduced. It is moreover proved that the transformation of synchronous programs to SSTA form is impossible in the general case without adding new variables for the translation of control flow to data flow. Still, transformations into SSTA form exist for most Quartz programs. Since the SSTA form allows a program to be kept in its original structure, readable for the user, it allows the application of interactive verification of many synchronous programs [11]. 3.3 Software Verification In software verification, knowledge about the programming paradigm (like e.g. structured programming) is needed to determine whether a verification approach can be applied or not. Furthermore, it is relevant whether programs can consist of multiple threads While- and GoTo-Programs For verification approaches for programming languages, it is important to point out which properties the underlying language has. Quartz programs that are translated to state machines yield irreducible flow graphs - in contrast to structured sequential programs, which yield reducible flow graphs. Therefore, Hoare logic cannot be applied [8]. For sequential programs, go to programs yield irreducible control flow graphs whereas 24

37 Chapter 3 Fundamentals while (i.e. structured) programs yield reducible flow graphs. Since programs in synchronous languages have a different underlying MoC, their flow graphs differ as well. This is demonstrated in figure 3.6: when a while statement is entered, it is unclear which location will be active in the next macro step since this may depend on the current variable environment. 1 module Irreducible 2 (bool?c1,?c2){ 3 while(true) { 4 if(c1){l1:pause;} 5 if(c2){l2:pause;} 6 } 7 } c 1 c 2 {} c 1 c 1 c 2 c 2 {l 1 } {l 2 } c 1 c 1 c 2 Figure 3.6: A while-loop entered at different locations irreducible state machine It was already shown by Ashcroft and Manna that every go to program can be rewritten as an equivalent (two programs are equivalent if they have the same behavior in that either both do not terminate or both terminate with the same output) while program, but in general not without adding variables. One approach for a rewriting is the introduction of a while loop that modifies newly introduced boolean variables that simulate a program counter for the old program. Moreover, a more advanced approach exists, that partially preserves the structure of the original program since it does not alter its while loops, but adds additional boolean variables [27]. For the application of Hoare logic it is however only convenient for the user if assertions can be provided for the original program code. Doing this for translations of a program is at least inconvenient [11] Hoare Logic and Inductive Assertions Hoare Logic Hoare logic is a popular formal system used in software verification for proving the correctness of while programs. For program fragments, a precondition P and a postcondition Q ({P }C{Q}) need to be given and through application of the formal system s rules it is determined whether execution of C with precondition P yields Q. For while-statements, loop invariants have to be provided. It can thereby be determined whether a program matches its intended function [28]. Inductive Assertions Hoare logic is inspired by Floyd s inductive assertions [29], which is not restricted to while programs. For reasoning about programs with inductive assertions, transitions in a control flow graph are associated with propositions that have to hold if their corresponding transition is taken by a run of the program. It is then proved by induction over the number of commands that if a program is entered with some assertion, some other assertion holds on termination. The overall proof goal is called a verification [29]. 25

38 Chapter 3 Fundamentals Definition (Verification Condition [29]) A verification of assertions assigned to edges of the control flow graph is the proof that for every state entered with some assertion, a corresponding assertion holds on exiting. A verification condition is one single formula constructed for a part of the verification (Floyd: one verification condition per command). The verification conditions must be generated in a way that proving all of them means verifying the program. With inductive assertions, automatic verification is possible but user interaction is required in case of loops [29] Interference Owicki and Gries [30] extended Hoare logic for parallel programs with shared memory. In their model, actions of parallel threads are able to manipulate shared variables, but it is assumed that a thread receives writes to variables by other threads either before or after executing one of their own actions so that no spurious values occur. For the rules of their logic, the notion of interference-freedom was introduced. In a program consisting of multiple parallel threads for example - each thread with its own precondition and postcondition - it can be concluded that the conjunction of all preconditions is the precondition for the overall program and that the conjunction of all postconditions is the postcondition of the overall program if the threads are interference-free [30]. Definition (Interference-Free [30]) Given a proof {P }S{Q} and a statement T with precondition pre(t ), T does not interfere with {P }S{Q} if: {Q pre(t )}T {Q} for any statement S in S it holds: {P re(s ) P re(t )}T {P re(s )} If threads interfere, their assertions have to be adjusted, so that they consider the influence of threads that are executed in parallel. 3.4 Optimization Problems From Hybrid Quartz programs, state machines can be generated as described previously. The state machine s discrete states have a continuous behavior attached to them via ODE systems. Once these ODE systems are solved, functions over continuous time are obtained. Given these functions and the release condition of the state s transition, it is then the task to find the release time (i.e. the first point in continuous time where the release condition holds for the given functions). This is an optimization problem that can be formulated as a (non)-linear programming problem. 26

39 Chapter 3 Fundamentals Definition (Linear Programming [31]) A linear program is an optimization problem in which the objective function is linear in the unknowns and the constraints consist of linear (in)equalities. These problems can be transformed into a standard form: minimize c T x subject to Ax = b and x 0 Nonlinear Programming As in linear programming, a nonlinear mathematical program consist of constraints, variable bounds and an objective function. However, at least either the objective function or a constraint is nonlinear [32]. Mixed-Integer Programming In contrast to integer programming, in mixed-integer programming, some variables can be of type real and besides some are of type integer. Definition (Mixed-Integer Linear Programming (MINLP) [33, 34]) MINLP is a combination of nonlinear programming and mixed-integer programming. At least one function is nonlinear and only some of the variables are restricted to be of type integer. While integer linear programming is NP-hard already, MINLP is undecidable in general. General form of Mixed-Integer Linear Program: minimize f(x, a) subject to g(x, y) 0 x X y Y integer 27

40

41 Chapter 4 Verification Condition Generation In this chapter, a verification condition generator (VCG) based on the paper Verification Condition Generation for Hybrid Systems [8] is presented. Here, the ideas of the approach are discussed while the implementation is discussed subsequently in chapter 5. A VCG [35] generates verification conditions from programs for which assertions are provided by e.g. annotations. These conditions can then be checked for validity. 4.1 General Idea The general idea of the paper [8] is as follows: Since it is not possible in general to apply Hoare logic to synchronous programs, the paper suggests a method based on inductive assertions, for which induction proofs are set up over SCCs. When a program is executed, for some point in logical time the control flow rests either in a state contained in an SCC or in a state not contained in an SCC (also called trivial SCC). States not contained in SCCs are located on paths from the initial state or an SCC to an SCC whereas SCC-states can be visited indefinitely often. To prove safety properties, path predicates are set up for paths to SCCs as induction bases and step predicates are set up for steps inside SCCs as induction steps. By this it can be proved that the property holds all the time and is never violated (i.e. the safety property can be proved). For the correctness, it is argued that a safety property holds for all computation paths that are composed as follows: a path π = π 0... π n consists of subsequences π i. π 0 is the finite path between the initial state and an SCC, paths with even indexes are finite paths between SCCs and paths with odd indexes are finite paths inside SCCs. π n is either an infinite path inside an SCC or a finite path ending at a terminal state. By the introduction of a sink state with a self-loop, finite paths ending at a terminal state do not have to be distinguished anymore since transitions from the terminal states to the sink state are introduced and these paths become infinite. It is then argued that the safety property must hold on every state on any path between the initial state and an arbitrary state, between two arbitrary states inside different SCCs and between two arbitrary states inside the same SCC due to the safe path predicates [8]. 29

42 Chapter 4 Verification Condition Generation Remark (Overall Proof Goal [8]) Assuming that the SCCs C = n i=0 C i of a program are indexed in the range of [0..n] and the continuous invariants correspond to states in the range of [0..m], the overall proof goal is: Φ x 0 x [Ψ 0 ] x 0 x n (φ i φ i) i=0 n m m (I i Φ) (Ψ j Φ) (Ψ j I(C(j))) i=0 A safety property Φ holds for a program for all computation paths with given continuous invariants Ψ j and discrete invariants I i if: the safety property and the continuous invariant of the initial state hold in the discrete environment of the initial state when the program is started (with a variable substitution for the corresponding logical time), the induction base (φ i ) and induction step (φ i ) formulas are all valid and all discrete invariants I i are stronger than the safety property. Furthermore, the continuous invariants have to be stronger than the safety property, though it is sufficient to prove continuous invariants of states inside SCCs to be stronger than the corresponding SCC invariant, which itself has to imply the safety property. The formulas for the induction bases and induction steps are composed as follows: j=0 j C j=0 j C φ i : SafeP ath(s k,..., s l ) (s k,...,s l ) P aths to C i φ i : SafeP ath(s k, s k+1 ) s k,s k+1 Steps in C i 4.2 Generating and Solving Verification Conditions The overall procedure is as follows: First, the Quartz program file and the assertion file containing the information provided by the user are read and parsed. Then, Averest s compiler functions are called, which yield the program statement s syntax tree and all kinds of variables (e.g. interface variable declarations like inputs, inouts and outputs, the local variables and the variables of control flow locations). In the next step, the SOS rules are applied to the program statement s syntax tree, which yields information for the first reaction of that statement: e.g. the residual statements and the surface actions. This is the information required to build the EFSM in the next step. Since the approach described in the paper [8] reasons about paths of the state machine, a sink state collecting all dead ends has to be added so that induction bases and steps are set up for all runs of the program. Furthermore, the absence reaction has to be added to the states of the EFSM. Once the EFSM is set up it is used to detect SCCs, based on which the verification conditions are generated. Depending on the method applied, these VCs are computed for e.g. SCCs or components related to loops. The overall proof goal then has to be checked for validity. Since it is a conjunction of 30

43 Chapter 4 Verification Condition Generation multiple VCs, the computed VCs can either be proved independently or the overall proof goal itself can be proved. Which of these approaches is faster cannot be determined in general, since it depends on both the formula and the solver. The cases of the SMT solver not being able to prove a VC or not terminating in a reasonable amount of time are much bigger challenges than an improvement in runtime. Therefore it is usually preferred to prove the VCs independently. In the end, the verification results are printed to various tables in a human-readable form. The overall function is depicted in figure 4.1. Figure 4.1: Overall function for checking properties 4.3 The SafePath Predicate To apply the induction discussed in section 4.1 predicates similar to the SafePath predicate specified in [8] need to be defined. The selection of the appropriate predicate depends on what kind of path it is generated for. These predicates are used for the various approaches to build formulas for paths computed prior to this. The operator cont (ψ(t)) expresses that the proposition ψ must hold in the continuous phase related to the logical time t (i.e. the continuous phase between t and t + 1). Besides, the operator fun(d c (s t )) represents the functions over time of the ODEs (i.e. their solution) of some state s t. ϕ t = ϕ(s t, s t+1 ) is the condition for the transition from 31

44 Chapter 4 Verification Condition Generation state s t to state s t+1. The overall predicate for a safe path then is as follows: SafeP ath((s 0,..., s n ), (ϕ 0,..., ϕ n 1 ), SafeAssume, α, (ψ 0,..., ψ n ), (β 0,..., β n ), γ) : ( n [D d (s t )] x t, x t+1 ) ( n 1 cont ([fun(d c (s t ))] x t c ) ) ( n 1 [fun(d c (s t ))] x t r ) x,next( x ) x x t=0 [LabelF ormula(s 0 )] x 0 x t=0 t=0 ( n [LabelF ormula((s t 1, ϕ t 1 ), s t )] x t ) ( n x t=1 t=0 [SafeAssume] x t ) x ( n 1 [ϕ t ] x t ) [α] x 0 [ψ 0 ] x 0 ( n 1 [ReleaseF ormula(s t, ϕ t )] n 1 x t r ) [0 t c < t r ] x t x x t=0 t=0 x ( n 1 cont ([ψ t ] x t c ) ) ( n 1 [ψ t ] x t r ) ( n 1 [β t ] x t ) [γ] x n x x x x t=0 t=0 t=1 x t=0 x (4.1) To compute this predicate, further functions are used: LabelF ormula(s t ) For the first state: formula describing possibly active labels Saf eassume ReleaseF ormula(s t, ϕ t ) (disjunction of conjunction of literals), logical time 0 For s t with t [1..n]: formula describing active labels (conjunction of literals), logical time t A safety property assumed to hold, e.g. variable ranges to be timed at some logical time t Describes the release time for a state and a transition This SafePath predicate is applied to all induction base paths with variables as follows: α : initial state safety property (proved in the overall proof goal) ψ t : β t : γ : state in SCC program state for this state the continuous invariants per state s t the safety property to be proved at logical time t the assertion (e.g. SCC-invariant) of the target state If a SafePath predicate is proved valid for a safety property, it then holds on this path and formulas proved to hold for the last state s n can then be added to the antecedent of path formulas starting in that state. InductionStepInSCC((s 0, s 1 ), (ϕ 0 ), SafeAssume, α, (ψ 0, ψ 1 ), γ) : SafeP ath((s 0, s 1 ), (ϕ 0 ), SafeAssume, α, (ψ 0, ψ 1 ), (), γ) (4.2) The InductionStepInSCC predicate is applied to all induction steps with variables as follows: α : the assertion I (e.g. SCC invariant) ψ 0 : γ : the continuous invariants of the state where the step starts condition for transitions leaving the SCC terminal condition (i.e. program state when leaving the SCC) condition for transition staying inside the SCC the SCC assertion/invariant 32

45 Chapter 4 Verification Condition Generation Because continuous self-loops generated by flow statements as described in subsection are treated by separate paths, additional predicates are needed (SafePathAnte is the antecedent of the SafePath predicate and SafePathCons is the consequent): T oselfloop((s 0,..., s n ), (ϕ 0,..., ϕ n ), SafeAssume, α, (ψ 0,..., ψ n ), (β 0,..., β n ), γ) : SafeP athante((s 0,..., s n ), (ϕ 0,..., ϕ n 1 ), SafeAssume, α, (ψ 0,..., ψ n ), (β 0,..., β n ), γ) cont ([fun(d c (s n ))] x n c x ) cont ([ϕ n ] x n c ) x SafeP athcons((s 0,..., s n ), (ϕ 0,..., ϕ n 1 ), SafeAssume, α, (ψ 0,..., ψ n ), (β 0,..., β n ), γ) cont ([ψ n ] x n c x ) (4.3) InSCCSelfLoop((s 0 ), (ϕ 0 ), SafeAssume, I, (ψ 0 ), (), ()) : SafeP athante((s 0 ), (ψ 0 ), SafeAssume, I, (ψ 0 ), (), ()) cont ([ϕ n ] x n c x ) (4.4) SafeP athcons((s 0 ), (ψ 0 ), SafeAssume, I, (ψ 0 ), (), ()) For continuous self-loops outside of SCCs, paths to their states similar to the paths to SCCs are generated and the ToSelfLoop predicate is built. The continuous functions of the last state s n and the transition condition that ensures that the self-loop is never left have to be added to the antecedent of the SafePath predicate, while the continuous invariant has to be proved in the consequent for all points in continuous time. Continuous self-loops inside SCCs work analogously with the InSCCSelfLoop predicate. 4.4 The SafeTrans Predicate If the SMT solver is not able to prove a safety property for some path, the proof can be done more manually by providing assertions for every single step. One advantage is that it might become possible to prove the property at all. Another advantage is as follows: while it may happen in case of using the SafePath predicate that a single transition is included in multiple path formulas (in the worst case exponentially many times [36]), each step has to be proved only once in case of using the SafeTrans predicate. Disadvantageous however is the inconvenience: for every single transition of the EFSM, the program state has to be provided symbolically for its source state as well as for its target state, so that the step can be checked by an SMT solver again. The predicate SafeTrans is defined as follows: SafeT rans((s 0, s 1 ), (ϕ 0 ), SafeAssume, Φ, α, (ψ 0, ψ 1 ), γ) : ( [α] x 0 x [Φ] x 0 x ) ( [γ] x 1 x [Φ] x 1 x ) (4.5) SafeP ath((s 0, s 1 ), (ϕ 0 ), SafeAssume, α, (ψ 0, ψ 1 ), (), γ) 33

46 4.5 Prerequisites for VC Generation Chapter 4 Verification Condition Generation The computation of VCs shown in the diagram 4.1 is illustrated in more detail in figure 4.2. The continuous behavior is provided per EFSM state as an ODE system. For generating the VCs however, functions over time (i.e. the solutions of the ODE systems) are needed. Therefore they have to be solved first. Furthermore, the release times have to be determined per EFSM transition from the solved ODEs and the release conditions. Figure 4.2: Detailed steps of the VC computation ODE Solutions Figure 4.3 shows a program fragment describing the continuous behavior of the height and velocity of a ball falling to the ground. This continuous behavior is provided as an ODE system and can be solved e.g. in Mathematica [37]. The ODE solution contains variables c 1 and c 2 which are the starting values for the height h and the velocity v in this continuous phase. This means that they have to be equivalent to h and v of the discrete environment E disc. 1 flow{ 2 drv(h) <- cont(v); 3 drv(v) < ; 4 } until(h<=0.0 and v<0.0); ODE System: [h = v, v = 9.81] Solution: h(t) = c 2 t + c t 2 c 2 = v start, c 1 = h start Functions: h v t + h t 2 v v 9.81 t Figure 4.3: Example: BouncingBall [3] ODE solution Release Times Once the continuous functions over (continuous) time are determined, the release time has to be determined by minimizing the time for which the release condition holds. This optimization problem has to be solved symbolically so that a formula describing the release time is obtained. Additionally, a formula has to be determined for the case of staying inside a continuous phase indefinitely. 4.6 Approaches for VC Generation In [36], various approaches for the generation of VCs are discussed. For all of these approaches, either path formulas can be computed using the SafePath predicate or step formulas can be computed using the SafeTrans predicate. Both the correctness and 34