ComputerAided Verification 1 Other names Formal methods Formal

電腦輔助驗證 Computer-Aided Verification 1

Other names Formal methods Formal verification Automated verification

Class Web Page zwww. ee. ntu. edu. tw/~yen/courses/cav 02 z. E-mail: yen@ee. ntu. edu. tw z. Phone: 2363 5251 ext. 540 z. Office Hours: By appointment

Useful book z. Model Checking, E. Clarke, O. Grumberg, D. Peled, MIT Press

Topics Introduction Automata Theory Temporal Logics: LTL, CTL* Model Checking w-Automata, m-calculus BDD and Symbolic Model Checking Timed and Hybrid Automata, Notion of Equivalence, Region Technique, Approximation z Other Infinite-State Systems (Petri Nets, Parameterized Systems, Broadcast Protocols, CFSM …) and analytical techniques z Case Study z z z z

Framework Applications visual. STATE PVS Logic • Temporal Logic • Modal Logic • MSOL • • UPPAAL SPIN HOL Algorithmic TLP • (Timed) Automata Theory • Graph Theory • BDDs • Polyhedra Manipulation • • ALF Semantics • Concurrency Theory • Abstract Interpretation • Compositionality • Models for real-time & hybrid systems • •

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 Sync. Master 17 GLsi Mobile Phone Telephone Digital Watch Tamagotchi

Why? z. Testing/simulation of designs/implementations may not reveal error (e. g. , no errors revealed after 2 days) z. Formal verification (=exhaustive testing) of design provides 100% coverage (e. g. , error revealed within 5 min). z. TOOL support.

W VI E Problem Area RE The Waterfall Model S Traditional Software Development Analysis VI Testing Ru Sy nni st ng em ¨ Costly in time-to-market and money ¨ Errors are detected late or never ¨ Application of FM’s as early as possible RE Implementation EW S Design

Introducing, detecting and repairing errors

Formal Verification & Validation Analysis S D HO AL FO RM ET Design Model M UM Validation L Specification Verification & Refusal Implementation Testing

Formal Verification & Validation Analysis S D HO AL FO RM ET Design Model M UM Validation L Specification Verification & Refusal : LS AL TE O TO UPPA l. STA ua s i v N I SP Implementation Testing

Formal Verification & Validation Analysis S D HO AL FO RM ET Design Model M UM Validation L Specification Verification & Refusal Automatic Code generation : LS AL TE O TO UPPA l. STA ua s i v. …. Implementation Testing

Formal Verification & Validation Analysis S D HO AL FO RM ET Design Model M UM Validation L Specification Verification & Refusal Automatic Code generation Automatic Test generation : LS AL TE O TO UPPA l. STA ua s i v. …. Implementation Testing

How? Unified Model = State Machine! b? a Input ports y! x b? b x! Control states a? y Output ports

UPPAAL

SPIN, Gerald Holzmann AT&T

visual. STATE VVS w Baan Visualstate, DTU (CIT project) z Hierarchical state systems z Flat state systems z Multiple and interrelated state machines z Supports UML notation z Device driver access

Train Simulator 1421 machines 11102 transitions 2981 inputs 2667 outputs 3204 local states Declare state sp. : 10^476 VVS visual. STATE BUGS ? n o i t a e c i f i er nitud v d ag e c u ed s of m ) r as rder sec h es ral o to 6 q iu ve n ys h a e c d s r te with x 14 u O e (e m ti

‘State Explosion’ problem M 1 b a 1 c M 2 2 3 4 M 1 x M 2 1, a 4, a 1, b 2, b 1, c 2, c 3, a 4, a 3, b 4, b 3, c 4, c l All combinations = exponential in no. of tica e r heo le t b ly components rovab tracta P in

Tool Support System Description A No! Debugging Information TOOL Requirement F Course Objectives: • Model systems and specify requirements • Understand main underlying theoretical and practical problems • Validate models using TOOLS Yes, Prototypes Executable Code Test sequences Tools: UPPAAL, SPIN, Visual. STATE, Statemate, Verilog, Formalcheck, . . .

Model Checking G(p -> F q) yes MC no p q z output y yes y no + counterexample z input: y temporal logic spec y finite-state model

Linear temporal logic (LTL) z. A logical notation that allows to: yspecify relations in time yconveniently express finite control properties z. Temporal operators y. G p y. F p y. X p yp U q “henceforth p” “eventually p” “p at the next time” “p until q”

Types of temporal properties z Safety (nothing bad happens) G ~(ack 1 & ack 2) “mutual exclusion” G (req -> (req W ack)) “req must hold until ack” z Liveness (something good happens) G (req -> F ack) “if req, eventually ack” z Fairness GF req -> GF ack req, ack” “if infinitely often

Example: traffic light controller S E N z Guarantee no collisions z Guarantee eventual service

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 /* 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

Specifications in temporal logic z Safety (no collisions) G ~(E_Go & (N_Go | S_Go)); z 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); z Fairness constraints GF ~(N_Go & N_Sense); GF ~(S_Go & S_Sense); GF ~(E_Go & E_Sense); /* assume each sensor off infinitely often */

Counterexample z East and North lights on at same time. . . E_Go E_Req E_Sense NS_Lock N_Go N_Req N_Sense S_Go S_Req S_Sense N light goes on at same time S light goes off. S takes priority and resets NS_Lock

Fixing the error z 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

Another counterexample z North traffic is never served. . . E_Go E_Sense N and S lights go off at same time NS_Lock Neither resets lock E_Req N_Go N_Req N_Sense S_Go S_Req S_Sense Last state repeats forever

Fixing the liveness error z. 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

All properties verified z. Guarantee no collisions z. Guarantee service assuming fairness z. Computational resources used: y 57 states searched y 0. 1 CPU seconds

Computation tree logic (CTL) z Branching time model z Path quantifiers y. A = “for all future paths” y. E = “for some future path” z Example: AF p = “inevitably p” p p AF p p z. Every operator has a path quantifier y. AG AF p instead of GF p 7

Difference between CTL and LTL z Think of CTL formulas as approximations to LTL y. AG EF p is weaker than G F p Good for finding bugs. . . p y. AF AG p is stronger than F G p p p Good for verifying. . . z. CTL formulas easier to verify So, use CTL when it applies. . . 8

CTL model checking algorithm z. Example: AF p = “inevitably p” p l Complexity – linear in size of model (FSM) – linear in size of specification formula Note: general LTL problem is exponential in formula size

Specifying using w-automata z An automaton accepting infinite sequences G (p -> F q) p ~q ~p q y. Finite set of states (with initial state) y. Transitions labeled with Boolean conditions y. Set of accepting states Interpretation: • A run is accepting if it visits an accepting state infinitely often • Language = set of sequences with accepting runs

Verifying using w-automata z Construct parallel product of model and automaton z Search for “bad cycles” y. Very similar algorithm to temporal logic model checking z Complexity (deterministic automaton) y. Linear in model size y. Linear in number of automaton states y. Complexity in number of acceptance conditions varies

temporal logic z Tableau procedure y. LTL formulas can be translated into equivalent automata y. Translation is exponential z w-automata are strictly more expressive than LTL Example: p “p at even times” T z. LTL with “auxiliary” variables = w-automata Example: G (even -> p) where: init(even) : = 1; next(even) : = ~even;

State explosion problem z. What if the state space is too large? ytoo much parallelism ydata in model z. Approaches y“Symbolic” methods (BDD’s) y. Abstraction/refinement y. Exploit symmetry y. Exploit independence of actions

Binary Decision Diagrams (Bryant) z. Ordered decision tree for f = ab + cd a 0 0 0 d c b 1 1 1 0 d d 0 c 1 0 d d c b 1 1 0 d d c 1 d 0 0 0 1 1 1

OBDD reduction z. Reduced (OBDD) form: a 1 0 0 c 1 b 1 1 d 0 1 l Key idea: combine equivalent sub-cases

OBDD properties z Canonical form (for fixed order) ydirect comparison z Efficient algorithms ybuild BDD’s for large circuits f fg g O(|f| |g|) z. Variable order strongly affects size

Symbolic Model Checking z Represent sets and relations with Boolean functions a, b R(a, b, a’, b’) a’, b’ z. Breadth-first search using BDD’s Sw . . . S 1 S 0 = p y. Enables search of larger state spaces y. Handle more complex control y. Can in some cases extend to data path specifications Si+1 = Si / EX Si

Abstraction z Reduces state space by hiding some information z Introduces non-determinism Abstract states Concrete states z. Allows verification at system level

Refinement maps Abstract model -- protocol -- architecture, etc. . . Refinement Maps Implementation Component z Maps translate abstract events to implementation level z Allows verification of component in context of abstract model

Hybrid & Real Time Systems Computer Science Control Theory sensors actuators Plant Continuous Eg. : Pump Control Air Bags Robots Cruise Control ABS CD Players Production Lines Task Controller Program Discrete Real Time System A system where correctness not only depends on the logical order of events but also on their timing

Validation & Verification Construction of UPPAAL models Controller Program Plant Continuous Discrete sensors Task actuators Model of environment (user-supplied) 1 a 2 3 b 4 c 1 a b c 3 Model of tasks (automatic) 2 1 2 3 4 a 4 b c

Intelligent Light Control press? Off press? Light press? Bright press? WANT: if press is issued twice quickly then the light will get brighter; otherwise the light is turned off.

Intelligent Light Control Off press? X: =0 Light X<=3 press? Bright press? X>3 Solution: Add real-valued clock x

Timed Automata Alur & Dill 1990 Clocks: x, y Guard n Action used for synchronization Boolean combination of comp with integer bounds x<=5 & y>3 Reset Action perfomed on clocks a State ( location , x=v , y=u ) x : = 0 Transitions m where v, u are in R a ( n , x=2. 4 , y=3. 1415 ) ( m , x=0 , y=3. 1415 ) e(1. 1) ( n , x=2. 4 , y=3. 1415 ) ( n , x=3. 5 , y=4. 2415 )

Timed Automata Invariants n Clocks: x, y x<=5 & y>3 Location Invariants Transitions ( n , x=2. 4 , y=3. 1415 ) a e(3. 2) e(1. 1) ( n , x=2. 4 , y=3. 1415 ) ( n , x=3. 5 , y=4. 2415 ) x : = 0 m y<=10 g 1 g 2 g 3 g 4 Invariants insure progress!!

Networks of Timed Automata + Integer Variables +…. m 1 l 1 x>=2 i==3 y<=4 a! a? …………. x : = 0 i: =i+4 l 2 Two-way synchronization on complementary actions. Closed Systems! m 2 Example transitions (l 1, m 1, ………, x=2, y=3. 5, i=3, …. . ) 0. 2 tau (l 2, m 2, ……. . , x=0, y=3. 5, i=7, …. . ) (l 1, m 1, ………, x=2. 2, y=3. 7, I=3, …. . ) If a URGENT CHANNEL

Lego RCX Brick LEGO MINDSTORMS, LEGO ROBOLAB 3 Input (sensors) Light, rotation, temperature, pressure, . . . 1 Infra-red port 3 Output ports (actuators) motor, light

First UPPAAL model Sorting of Lego Boxes Piston Boxes eject remove Conveyer Belt 18 9 81 90 99 Red Blck Rd Controller Main Exercise: Skub_af Black Design Controller so that only black boxes are being pushed out

NQC programs 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); Clear. Timer(1); active=1; Play. Sound(1); wait(IN_1>LIGHT_LEVEL); } } int active; int DELAY; int LIGHT_LEVEL; 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); } }