1. 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.

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

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

11. 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

12. 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

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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

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

21. 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

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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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