Transcript CSC2108: Automated Verification or Everything you Wanted to Know about Model-Checking Instructor:

CSC2108: Automated Verification or
Everything you Wanted to Know about
Model-Checking
 Instructor:
Marsha Chechik
 Contact:
[email protected]
Bahen 3248, 416-978-3820
 TA:
Shiva Nejati
[email protected]
 Web
page:
http://www.cs.toronto.edu/~chechik/courses07/csc2108
Software Engineering and
Formal Methods
Motivation
“To err is human but to really foul things up requires
a computer”
Farmer’s Almanac for 1978
“Capsules of Wisdom”
“60% of all major industrial disasters from 1921 to
1989 occurred after 1975”
Nancy Leveson
“Safeware: Computers and Technology”
Example: auto-pilot
Problem:
“Design a part in auto-pilot that avoids
collision with other planes.”
Solution:
“When distance is 1km, give warning to other
plane and notify pilot. When distance is 300m,
and no changes in the course of other plane
were noticed, go up to avoid collision”
Problem with solution
 Both
planes have the same software. Both go up...
This happens in real software!
 Some
famous bugs
NASA Space Rover, Intel floating point processor,
etc.
 Hard
to predict all behaviours!
US aircraft went to southern hemisphere and …
flipped when crossing the equator
Air traffic controller: US to Britain.
 It never dealt with problem of 0 degrees longitude.
 Result: software “folded” Britain along Greenwich Meridian
Software written for US F-16
 accidents when reused in Israeli aircraft flown over the Dear Sea
(altitude < sea level)
Year 2000 problem
Yet more such examples
 NASA
Space Shuttle software (in use since 1980)
16 severity-level 1 software errors
8 remained in code that was used in flights
none encountered during flights
total size - only 400,000 words
So, why not test?
Testing only shows presence of bugs
not their absence!
Formal Methods
Mathematically-based techniques for describing
properties of systems
 Provide
framework for
Specifying systems (and thus notion of correctness)
Developing systems
Verifying correctness
 Of implementation w.r.t. the specification
 Equivalence of different implementations
 Reasoning
is based on logic
Amenable to machine analysis and manipulation
In principle, can verify everything that is true in the
system!
 Given enough time, skill and patience
Why aren’t FMs used more?
“Formal methods can
revolutionize
development!”
“Formal methods are difficult,
expensive, not widely useful
and for safety-critical systems
only”
… and one more problem
 Need
to know what to build (specification) before
you start building
System
engineering
Analysis
Design
Coding
“water-fall” model
Testing
Maintenance
 Unrealistic!
May need to discover what to build iteratively
Software changes all the time
Formal Methods “Light”
 Partial
application of formal methods
only parts of systems are specified
 Emphasis
on analysis of some properties
security, fairness, deadlock freedom, rather than
complete verification
 Debugging
rather than assurance
 Automation
Most successful lightweight technique:
Model-Checking
Model-Checking
Overview of Automated Verification
SW/HW
artifact
Correct?
Model
Extraction
Translation
Model of
abstraction
Correctness
properties
Temporal
logic
System
Checker
Engine
Answer +
Counter-example
CTL Model-Checking
 CTL:
Branching-time propositional temporal logic
 Model - a tree of computation paths
 Example:
S1
S2
S1
S2
S1
S3
Kripke Structure
S2
S1
S3
S3
S1
S2
S3
S1
S3
Tree of computation
Models: Kripke Structures
 Conventional
state machines
M = <S, A, s0, I , R>
S is a (finite) set of states
s0
 p
p
q
r
A is a (finite) set of propositional
variables
q
r
s1
p
q
s2  r
s0 is a unique initial state (s0  S)
I: S  2A is a labeling function that maps each state
to the set of propositional variables that hold in it
R  S  S is a (total) transition relation
Propositional Variables
Fixed set of atomic propositions {p, q, r}
Atomic descriptions of a system
“Printer is busy”
“There are currently no requested jobs for the printer”
“Conveyer belt is stopped”
How to choose them?
Should not involve time!
CTL: Computation Tree Logic
propositional temporal logic.
allows explicit quantification over possible futures
 Syntax:
True () and False () are CTL formulae;
propositional variables are CTL formulae;
if and  are CTL formulae, then so are:  ,    ,  
EX  ---  holds in some next states;
EF  --- along some path,  is true in a future state;
E[ U  ] --- along some path,  holds until  holds;
EG  --- along some path,  holds in every state
Universal quantification: AX  , AF  , A[ U  ], AG 
Examples



EX (exists next)
AX (all next)







EG (exists global)



    
AG (all global)
Examples, Cont’d


 

EF (exists future)
AF (all future)






 

EU (exists until)
AU (all until)
CTL (Cont’d)
 Examples:
Properties that hold:
 (EX p)(s0)
 (A[p U q])(s0)
 ( EX AF p )(s0)
 Properties that fail:
 (A[ p U q])(s0)
 p
q
r s1
p
q
s0 r
s2
p
q
r
Some Statements To Express
It is possible to get to a state where started holds,
but ready does not hold
 EF (started  ready)
When a request occurs, it will eventually be
acknowledged
 AG (request  AF acknowledge)
CTL Model-Checking
 Receive:
Kripke structure K
Temporal logic formula 
 Assumptions:
Finite number of processes
 Each having a finite number of finite-valued variables
Finite length of a CTL formula
 Algorithm:
Label states of K with subformulas of that  are
satisfied there and working outwards towards .
Output states labeled with 
Example: EX AG (p  E[p U q])
CTL Model-Checking (Cont’d)
EX 
AF 
Label any state with EX  if
any of its successors are
labeled with 
If any state s is labeled with
, label it with AF
Repeat:
label any state with AF

if all of its successors

are labeled with AF
EX 
until there is no change
,

AF 

,
AF 
,
AF  AF 
,
AF 
,
AF 
,
AF  AF 
Counterexamples
 Explain:
Why the property fails to hold
to disprove that  holds on all elements of S, produce
a single element s  S s.t.  holds on s.
 counterexamples restricted to universally-quantified formulas
 counterexamples are paths (trees) from initial state illustrating
the failure of property
AG p
 p
p
q
r
s0
s0
s1
AX p  AX q
 p
p
q
r
q
r
s2
p
q
r
q
r
s0
s1
 p
s1
q
r
p
q
r
p
q
s2 r
Symbolic model-checking
 Idea
of model-checking
x
recursively go through the structure of the
F
CTL property…
associating each subformula with a set of
states where each subproperty is true
 Symbolic
model-checking
effective cure for state explosion problem
use symbolic representation for sets of
states
use symbolic representation for transition
relation
use binary decision diagrams (BDDs) to
encode these
 Example:
 xy in classical logic
T
y
F
T
F
T
Questions:
 Where
does the Kripke structure come from?
Computing it from several concurrent processes
 Models of concurrency: maximum parallelism, interleaving
What happens if Kripke structure is infinite?
 Abstraction!
How to represent large Kripke structures?
 Abstraction!
 Symbolic encoding of transition relation
 SAT-based encoding (BMC)
 Symmetry (not part of the course)
 Compositional verification
 What
other methods are there?
2108: Automated Verification
A course on model-checking technology
 Theory:
Different temporal logics (CTL, LTL, mu-calculus)
Foundations:
 Automata theory (automata on infinite strings, tree automata,
alternating tree automata), lattice theory, fixpoint computations
 Introduced as needed!
Different model-checking approaches:
 Explicit-state, Symbolic, Bounded (BMC)
 Game-theoretic
 Automata-theoretic
 Tools:
SMV, SPIN, Concurrency workbench
Automated Verification (Cont’d)
 Making
this work:
Decision diagrams, SAT solvers
Compositional verification
Partial order reduction
Abstraction and refinement
 Some
applications
Debugging
Requirements monitoring
Test case generation
 Extensions
Query-checking
Model-checking over partial and inconsistent systems
Etc.
2108: Pragmatics

Time: Wednesdays, 2-5 p.m.

Readings:
Book:
 Clarke, Grumberg, Peled. Model-Checking. MIT Press, 1999
Many research papers

Course work:
2-3 small modeling exercises
Regular (small) paper-and-pencil homeworks
Research project
Possibly presentation of a topic related to model-checking

Prerequisites:
Discrete mathematics, general inclination towards theory
Prior experience with concurrent systems a plus
Pros and Cons of Model-Checking
 Often
cannot express full requirements
Instead check several smaller properties
 Few
systems can be checked directly
Must generally abstract
 Work
better for certain types of problems
Very useful for control-centered concurrent systems
 Avionics software
 Hardware
 Communication protocols
Not very good at data-centered systems
 User interfaces, databases
Pros and Cons, Cont’d
 Largely
 Better
automatic and fast
use for debugging
… rather than assurance
 Testing
vs model-checking
Usually, find more problems by
exploring all behaviours of a downscaled system
than by
testing some behaviours of the full system
Readings
 List
of readings on the web site
Chapter 1 of the textbook
Several papers on formal methods in general. Links
from the reading list on the course web page
 For
next week:
Chapter 3 of the textbook