computer-aided verification

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: yen@ee.ntu.edu.twPhone: 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); }}