CSCI1600: Embedded and Real Time Software Lecture 31: Verification II Steven Reiss, Fall 2016 This lecture ran a little short. Add more examples of formulas to decipher. Then add some examples of sentences to encode as formulas.

Requirements Specification Properties we want to check in software systems What is needed to make the system safe What is needed to ensure functionality Lecture 31: Verification II 2/22/2019

How to State Properties Informal English Doesn’t work for proofs Alternatives Finite state machines Stating what is legal or what is illegal State-based assertions Logic formal (for all X …) Temporal Logic Properties often involve TIME Both relative (after/before) and absolute Lecture 31: Verification II 2/22/2019

Finite-State Representations If all 3 flip targets go down, they are popped up within 2 seconds NONE A B C A,B A,C B,C A,B,C <= 2 sec ERROR >2 sec Lecture 31: Verification II 2/22/2019

What’s Wrong With This? Other transitions are possible NONE A B C A,B A,C B,C A,B,C <= 2 sec ERROR >2 sec Other transitions are possible Are other states possible? Some are illegal Others are legal We only care about the end transition The proposition isn’t true Lecture 31: Verification II 2/22/2019

Problems Need to define appropriate events in the code Where in the code is a flip target down Where in the code is a flip target up Some events are in the world, not the code Need a running model of the world as well as the code Patterns can be positive or negative Time can be difficult to express Execution is infinite Lecture 31: Verification II 2/22/2019

Formalizing Properties A more formal notation for properties Can make proofs easier Can make expressing the properties easier Can make property definition checkable Regular expressions formalize FSAs Propositional Logic Is widely used for stating properties Preconditions and postconditions We need an extension that includes time Lecture 31: Verification II 2/22/2019

Temporal Logic Formal notation that includes time Several forms exist Think of it as regular expressions that include time Translatable into FSAs over infinite strings Where the properties of interest include time Several forms exist RTL (restricted temporal logic) LTL (linear temporal logic) CTL (computation tree logic) These are comparable, not quite similar All express predicates over computation paths Lecture 31: Verification II 2/22/2019

Linear Temporal Logic Predicates over all computation paths What is a computation path AP: set of primitive predicates These represent conditions Of the program or the outside world Properties hold in a set of states Can also think of them as states or sets of states In a finite-state representation of the program Of the overall program + the real world Lecture 31: Verification II 2/22/2019

Example: Microwave Oven Primitive Predicates start, close, heat, error Computation Paths Sequence of states Lecture 31: Verification II 2/22/2019

Simple LTL Path Formulas A path formula is a formula in LTL If p ϵ AP then p is a path formula If f and g are path formulas then so are ~f f ˅ g f ˄ g f  g Can allow other logical primitives (e.g. xor) This gives us formulas verifiable at a state But we want to talk about computation paths But how should we interpret them Need a notion of time Lecture 31: Verification II 2/22/2019

Time-Based LTL Path Formulas X f (neXt time) f host at the second state of the path F f (finally, eventually, in the Future) f will hold at some point on the path G f (always, Globally) f holds at every state on the path f U g (Until) There is a state on the path where g holds and f holds in every preceding state on the path f R g (Release) g holds in every state on the path up to and including the first state where f holds Lecture 31: Verification II 2/22/2019

LTL Example Lecture 31: Verification II 2/22/2019

CTL (Computation Tree Logic) Adds quantifiers to LTL operators A: for all computation paths E: for some computation path (exists) These are combined AX, EX, AF, EF, AG, EG, AU, EU, AR, ER Lecture 31: Verification II 2/22/2019

CTL Examples EF(start ^ ~ready) AG(req -> AF ack) It is possible to get to a state where start holds, but ready does not hold AG(req -> AF ack) LTL: G(req -> F ack) If a request occurs, then it will eventually be acknowledged AG(AF deviceEnabled) The proposition ‘deviceEnabled’ holds infinitely often on every path AG(EF restart) From any state it is possible to get to the restart state Lecture 31: Verification II 2/22/2019

Modeling the Program This gives us a way of expressing conditions But conditions against what We need to model the program We also need to model the outside world As part of the program As inputs to the program We need a checkable representation Programs are inherently undecidable Finite state automata are decidable We want to create a FS model from the actual code Lecture 31: Verification II 2/22/2019

Finite-State Programs Assume we have a finite automata States and transitions between the state Any form of FSA you want (parallel, synchronized, Statecharts, Petri nets, …) What the states and transitions are is not important Assume we know what conditions hold in each state The conditions of interest are the primitive predicates (AP) Label each state with a subset of these predicates Then LTL and CTL become well defined Paths are valid state sequences in the FSA Lecture 31: Verification II 2/22/2019

Mapping the Program Can generate a FSA from the program We might already have a finite state model Of each task in an embedded system Can work directly with those models Annotate with the appropriate state predicates Then prove that the program implements the model Or generate the program from these models This is often easier We showed how this could be automated last time Lecture 31: Verification II 2/22/2019

Proving Properties AG(start -> AF heat) How would you prove it? For all paths, if we hit start, then we eventually get heat Is this true? How would you prove it? Lecture 31: Verification II 2/22/2019

Recall: Iterator Example D E B it = x.iterator / ALLOC it.hasNext() / HASNEXT y = it.next() / NEXT

Proving Properties AG(start -> AF heat) How would you prove it? For all paths, if we hit start, then we eventually get heat Is this true? How would you prove it? Lecture 31: Verification II 2/22/2019

Homework 11/21: Project status Updates 11/28: Read chapter 15 Lecture 31: Verification II 2/22/2019

Checking the Program Given a finite representation of the program We have a notion of execution paths The paths consists of states with properties We have a language for expressing requirements Over paths consisting of states with properties Taking (relative) time into consideration Can we use this to check the program Enumerate all possible paths This may be finite or have a finite representation (e.g. regex) Check the formula at each point How can this be done practically NEXT TIME Lecture 31: Verification II 2/22/2019

Mapping the Program Static analysis for control flow Provides a state-based representation Think of the control flow diagram Nodes here represent potential states Need to add the variable values in Can take into account exceptions, threads, etc. Build a statechart for parallelism Using the limited variable values Lecture 31: Verification II 2/22/2019

Are Programs Finite Automata? Consider normal programs Each point in the program is a state State includes the PC, variables, stack, heap, … Code determines the transition to the next state If all variables and the heap and stack are finite This is equivalent to a finite state automata Is a more convenient representation for doing proofs Possible to achieve this automatically Symbolic execution Simulated execution Lecture 31: Verification II 2/22/2019

What’s Wrong Here Determining potential control flows How precise do you want to be Determining values on a branch Based on possible input values Interleaving of multiple tasks (interrupts) Ensuring realistically small finite domains Don’t want to look at (2^32)^(2^32) possible states But 2^80 is doable!! Lecture 31: Verification II 2/22/2019

Finite Domain Variables Treat variables in restricted manners int x: x is 0, 1, or something else x is <10, x = 10, x > 10 x can hold any integer value Can define arithmetic over these limited domains Then you can map all variables to Boolean predicates This is generally done with programmer assistance What values are significant Much can be done automatically What happens if you generalize incorrectly? Lecture 31: Verification II 2/22/2019

LTL/CTL Examples Take a property of your project Recall Express it using CTL/LTL Recall X f (neXt time) F f (eventually, in the Future) G f (always, Globally) f U g (Until) f R g (Release) Lecture 31: Verification II 2/22/2019