1
Computer-Aided Verification
電腦輔助驗證
Other names
Formal methods
Formal verification
Automated verification
Class Web Page
www.ee.ntu.edu.tw/~yen/courses/cav02
E-mail: [email protected]: 2363 5251 ext. 540Office Hours: By appointment
Useful book
Model Checking, E. Clarke, O. Grumberg, D. Peled, MIT Press
Topics
Introduction Automata Theory Temporal Logics: LTL, CTL, CTL* Model Checking -Automata, -calculus BDD and Symbolic Model Checking Timed and Hybrid Automata, Notion of Equivalence, Region
Technique, Approximation Other Infinite-State Systems (Petri Nets, Parameterized Systems,
Broadcast Protocols, CFSM …) and analytical techniques Case Study
Framework
Logic• Temporal Logic• Modal Logic• MSOL • •
Algorithmic• (Timed) Automata Theory• Graph Theory• BDDs• Polyhedra Manipulation• •
Semantics• Concurrency Theory• Abstract Interpretation• Compositionality• Models for real-time & hybrid systems• •
HOL TLP
Applications
PVS ALF
SPINvisualSTATE UPPAAL
What?
Validation and Verification of
software and hardware DESIGNS!
(E.g., real time systems, embedded systems,communication protocols)
A REAL real time system
Klaus Havelund, NASA
Embedded Systems
SyncMaster 17GLsi
Telephone
Tamagotchi
Mobile Phone
Digital Watch
Why?
Testing/simulation of designs/implementations may not reveal error (e.g., no errors revealed after 2 days)
Formal verification (=exhaustive testing) of design provides 100% coverage (e.g., error revealed within 5 min).
TOOL support.
Traditional Software Development
The Waterfall Model
Analysis
Design
Implementation
Testing Costly in time-to-market and money Errors are detected late or never Application of FM’s as early as possible
ProblemArea
Runni
ng
Syst
em
REVI
EWS
REVI
EWS
Introducing, detecting and repairing errors
Formal Verification & Validation
Design Model SpecificationVerification & Refusal
AnalysisValidation
FORMAL
METHODS
Implementation
Testing
UML
Formal Verification & Validation
Design Model SpecificationVerification & Refusal
AnalysisValidation
FORMAL
METHODS
Implementation
Testing
UML
TOOLS:
UPPAAL
visu
alSTATE
SPIN
Formal Verification & Validation
Design Model SpecificationVerification & Refusal
AnalysisValidation
FORMAL
METHODS
Implementation
Testing
UML
AutomaticCode generation
TOOLS:
UPPAAL
visu
alSTATE
…..
Formal Verification & Validation
Design Model SpecificationVerification & Refusal
AnalysisValidation
FORMAL
METHODS
Implementation
Testing
UML
AutomaticCode generation
AutomaticTest generation
TOOLS:
UPPAAL
visu
alSTATE
…..
How?
Unified Model = State Machine!
a
b
x
ya?
b?
x!
y!b?
Control states
Inputports
Outputports
UP
PA
AL
SP
IN, G
erald H
olzm
ann
AT
&T
visualSTATE
Hierarchical state systems
Flat state systems Multiple and inter-
related state machines
Supports UML notation
Device driver access
VVS w Baan Visualstate, DTU (CIT project)
Train Simulator1421 machines11102 transitions2981 inputs2667 outputs3204 local statesDeclare state sp.: 10^476
BUGS ?
VVSvisualSTATE
Our techniuqes has reduced verific
ation
time w
ith several orders of magnitude
(ex 14 days to 6 sec)
‘ State Explosion’ problem
a
cb
1 2
43
1,a 4,a
3,a 4,a
1,b 2,b
3,b 4,b
1,c 2,c
3,c 4,c
All combinations = exponential in no. of components
M1 M2
M1 x M2
Provably theoretical
intractable
Tool Support
TOOLTOOL
System Description A
Requirement F Yes, Prototypes Executable Code Test sequences
No!Debugging Information
Tools: UPPAAL, SPIN, VisualSTATE, Statemate, Verilog, Formalcheck,...
Course Objectives:• Model systems and specify requirements• Understand main underlying theoretical and practical problems• Validate models using TOOLS
Model Checking
output yes no +
counterexample
input: temporal logic
spec finite-state model
MC
G(p -> F q)yes
nop
q
p
q
Linear temporal logic (LTL)A logical notation that allows to:
specify relations in time conveniently express finite control properties
Temporal operators G p “henceforth p” F p “eventually p” X p “p at the next time” p U q “p until q”
Types of temporal propertiesSafety (nothing bad happens)
G ~(ack1 & ack2) “mutual exclusion”
G (req -> (req W ack)) “req must hold until ack”
Liveness (something good happens)G (req -> F ack) “if req, eventually ack”
FairnessGF req -> GF ack “if infinitely often req, infinitely often ack”
Example: traffic light controller
Guarantee no collisionsGuarantee eventual service
E
S
N
Controller program
module main(N_SENSE,S_SENSE,E_SENSE,N_GO,S_GO,E_GO); input N_SENSE, S_SENSE, E_SENSE; output N_GO, S_GO, E_GO; reg NS_LOCK, EW_LOCK, N_REQ, S_REQ, E_REQ;
/* set request bits when sense is high */
always begin if (!N_REQ & N_SENSE) N_REQ = 1; end always begin if (!S_REQ & S_SENSE) S_REQ = 1; end always begin if (!E_REQ & E_SENSE) E_REQ = 1; end
Example continued...
/* controller for North light */ always begin if (N_REQ) begin wait (!EW_LOCK); NS_LOCK = 1; N_GO = 1; wait (!N_SENSE);
if (!S_GO) NS_LOCK = 0; N_GO = 0; N_REQ = 0;
end end
/* South light is similar . . . */
Example code, cont…
/* Controller for East light */ always begin if (E_REQ) begin EW_LOCK = 1; wait (!NS_LOCK); E_GO = 1; wait (!E_SENSE); EW_LOCK = 0; E_GO = 0; E_REQ = 0; end end
Specifications in temporal logic
Safety (no collisions) G ~(E_Go & (N_Go | S_Go));Liveness G (~N_Go & N_Sense -> F N_Go); G (~S_Go & S_Sense -> F S_Go); G (~E_Go & E_Sense -> F E_Go);Fairness constraints GF ~(N_Go & N_Sense); GF ~(S_Go & S_Sense); GF ~(E_Go & E_Sense); /* assume each sensor off infinitely often */
CounterexampleEast and North lights on at same time...
E_Go
E_Sense
NS_Lock
N_Go
N_Req
N_Sense
S_Go
S_Req
S_Sense
E_ReqN light goes on atsame time S light goesoff.
S takes priority andresets NS_Lock
N light goes on atsame time S light goesoff.
S takes priority andresets NS_Lock
Fixing the error
Don’t allow N light to go on while south light is going off.
always begin if (N_REQ) begin wait (!EW_LOCK & !(S_GO & !S_SENSE)); NS_LOCK = 1; N_GO = 1; wait (!N_SENSE); if (!S_GO) NS_LOCK = 0;
N_GO = 0; N_REQ = 0; end end
Another counterexampleNorth traffic is never served...
E_Go
E_Sense
NS_Lock
N_Go
N_Req
N_Sense
S_Go
S_Req
S_Sense
E_Req N and S lights gooff at same time
Neither resets lock
Last state repeatsforever
Fixing the liveness error
When N light goes off, test whether S light is also going off, and if so reset lock.
always begin if (N_REQ) begin wait (!EW_LOCK & !(S_GO & !S_SENSE)); NS_LOCK = 1; N_GO = 1; wait (!N_SENSE); if (!S_GO | !S_SENSE) NS_LOCK = 0;
N_GO = 0; N_REQ = 0; end end
All properties verified
Guarantee no collisionsGuarantee service assuming fairnessComputational resources used:
57 states searched 0.1 CPU seconds
7
Computation tree logic (CTL)
Branching time modelPath quantifiers
A = “for all future paths” E = “for some future path”
Example: AF p = “inevitably p” AF p
p
p
p
Every operator has a path quantifier AG AF p instead of GF p
8
Difference between CTL and LTLThink of CTL formulas as approximations to LTL
AG EF p is weaker than G F p
So, use CTL when it applies...
AF AG p is stronger than F G p
pGood for finding bugs...
Good for verifying...p p
CTL formulas easier to verify
CTL model checking algorithm
Example: AF p = “inevitably p”
p
Complexity– linear in size of model (FSM)– linear in size of specification formula
Note: general LTL problem is exponential in formula size
Specifying using automataAn automaton accepting infinite sequences
Finite set of states (with initial state) Transitions labeled with Boolean conditions Set of accepting states
pG (p -> F q)
~q
q
~p
Interpretation:• A run is accepting if it visits an accepting state infinitely often• Language = set of sequences with accepting runs
Verifying using automata
Construct parallel product of model and automaton
Search for “bad cycles” Very similar algorithm to temporal logic model
checking
Complexity (deterministic automaton) Linear in model size Linear in number of automaton states Complexity in number of acceptance conditions
varies
Comparing automata and temporal logic
Tableau procedure LTL formulas can be translated into equivalent automata Translation is exponential
-automata are strictly more expressive than LTL
p
T
“p at even times”
Example:
LTL with “auxiliary” variables = -automata
Example: G (even -> p)
where: init(even) := 1; next(even) := ~even;
State explosion problem
What if the state space is too large? too much parallelism data in model
Approaches “Symbolic” methods (BDD’s) Abstraction/refinement Exploit symmetry Exploit independence of actions
Binary Decision Diagrams (Bryant)
Ordered decision tree for f = ab + cd
0 0 0 1 0 0 0 1 0 0 0 1 1 1 1 1
d d d d d d d d
c c c c
0 1
0 1 0 1
0 1 0 1 0 1 0 1
b b
a
OBDD reduction
Reduced (OBDD) form:
0 1
d
c
01
0 1
0 1
b
a
0
1
Key idea: combine equivalent sub-cases
OBDD properties
Canonical form (for fixed order) direct comparison
Efficient algorithms build BDD’s for large circuits
f
g O(|f| |g|)
fg
Variable order strongly affects size
Symbolic Model CheckingRepresent sets and relations with Boolean functions
a,b a’,b’R(a,b,a’,b’)
Enables search of larger state spaces Handle more complex control Can in some cases extend to data path specifications
Breadth-first search using BDD’s
S0 = pS1...S
Si+1 = Si \/ EX Si
Abstraction
Reduces state space by hiding some information
Introduces non-determinism
Abstract states
Concrete states
Allows verification at system level
Refinement maps
Maps translate abstract events to implementation level
Allows verification of component in context of abstract model
Abstract model-- protocol-- architecture, etc...
ImplementationComponent
Refinement Maps
Hybrid & Real Time Systems
PlantContinuous
Controller ProgramDiscrete
Control Theory Computer Science
Eg.:Pump ControlAir BagsRobotsCruise ControlABSCD PlayersProduction Lines
Real Time SystemA system where correctness not only depends on the logical order of events but also on their timing
Real Time SystemA system where correctness not only depends on the logical order of events but also on their timing
sensors
actuators
TaskTask
TaskTask
Validation & VerificationConstruction of UPPAAL models
PlantContinuous
Controller ProgramDiscrete
sensors
actuators
TaskTask
TaskTask
a
cb
1 2
43
a
cb
1 2
43
1 2
43
1 2
43
a
cb
Modelofenvironment(user-supplied)
Model oftasks(automatic)
Intelligent Light Control
Off Light Brightpress? press?
press?
press?
WANT: if press is issued twice quickly then the light will get brighter; otherwise the light is turned off.
Intelligent Light Control
Off Light Brightpress? press?
press?
press?
Solution: Add real-valued clock x
X:=0X<=3
X>3
Timed Automata
n
m
a
Alur & Dill 1990
Clocks: x, y
x<=5 & y>3
x := 0
Guard Boolean combination of comp withinteger bounds
ResetAction perfomed on clocks
Transitions
( n , x=2.4 , y=3.1415 ) ( n , x=3.5 , y=4.2415 )
e(1.1)
( n , x=2.4 , y=3.1415 ) ( m , x=0 , y=3.1415 )
a
State ( location , x=v , y=u ) where v,u are in R
Actionused
for synchronization
n
m
a
Clocks: x, y
x<=5 & y>3
x := 0
Transitions
( n , x=2.4 , y=3.1415 ) ( n , x=3.5 , y=4.2415 )
e(1.1)
( n , x=2.4 , y=3.1415 )
e(3.2)
x<=5
y<=10
LocationInvariants
g1g2 g3
g4
Invariants insure progress!!
Timed Automata - Invariants
Networks of Timed Automata + Integer Variables +….
l1
l2
a!
x>=2i==3
x := 0i:=i+4
m1
m2
a?
y<=4
…………. Two-way synchronizationon complementary actions.
Closed Systems!
(l1, m1,………, x=2, y=3.5, i=3,…..) (l2,m2,……..,x=0, y=3.5, i=7,…..)
(l1,m1,………,x=2.2, y=3.7, I=3,…..)
0.2
tau
Example transitions
If a URGENT CHANNEL
Lego RCX BrickLEGO MINDSTORMS, LEGO ROBOLAB
3 Input (sensors)Light, rotation, temperature, pressure,.....
3 Output ports (actuators)motor, light
1 Infra-redport
First UPPAAL modelSorting of Lego Boxes
Conveyer Belt
Exercise: Design Controller so that only black boxes are being pushed out
BoxesPiston
Black
Red9 18 81 90
99
BlckRd
remove
eject
Controller
Main Skub_af
NQC programs
task skub_af{ while(true){ wait(Timer(1)>DELAY && active==1); active=0; Rev(OUT_C,1); Sleep(8); Fwd(OUT_C,1); Sleep(12); Off(OUT_C); }}
task skub_af{ while(true){ wait(Timer(1)>DELAY && active==1); active=0; Rev(OUT_C,1); Sleep(8); Fwd(OUT_C,1); Sleep(12); Off(OUT_C); }}
int active;int DELAY;int LIGHT_LEVEL;
int active;int DELAY;int LIGHT_LEVEL;
task main{ DELAY=25; LIGHT_LEVEL=35; active=0; Sensor(IN_1, IN_LIGHT); Fwd(OUT_A,1); Display(1);
start skub_af; while(true){ wait(IN_1<=LIGHT_LEVEL); ClearTimer(1); active=1; PlaySound(1); wait(IN_1>LIGHT_LEVEL); }}
task main{ DELAY=25; LIGHT_LEVEL=35; active=0; Sensor(IN_1, IN_LIGHT); Fwd(OUT_A,1); Display(1);
start skub_af; while(true){ wait(IN_1<=LIGHT_LEVEL); ClearTimer(1); active=1; PlaySound(1); wait(IN_1>LIGHT_LEVEL); }}