1. 1 Computer-Aided Verification 電腦輔助驗證

2. Other names Formal methods Formal verification Automated verification

3. Class Web Page zwww.ee.ntu.edu.tw/~yen/courses/cav02www.ee.ntu.edu.tw/~yen/courses/cav02 zE-mail: yen@ee.ntu.edu.twyen@ee.ntu.edu.tw zPhone: 2363 5251 ext. 540 zOffice Hours: By appointment

4. Useful book: zModel Checking, E. Clarke, O. Grumberg, D. Peled, MIT Press

5. Topics zIntroduction zAutomata Theory zTemporal Logics: LTL, CTL, CTL* zModel Checking   -Automata,  -calculus zBDD and Symbolic Model Checking zTimed and Hybrid Automata, Notion of Equivalence, Region Technique, Approximation zOther Infinite-State Systems (Petri Nets, Parameterized Systems, Broadcast Protocols, CFSM …) and analytical techniques zCase Study

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

7. What? Validation and Verification of software and hardware DESIGNS! (E.g., real time systems, embedded systems, communication protocols)

8. A REAL real time system Klaus Havelund, NASA

9. Embedded Systems SyncMaster 17GLsi Telephone Tamagotchi Mobile Phone Digital Watch

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

11. 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 Problem Area Running System REVIEWS

12. Introducing, detecting and repairing errors

13. Formal Verification & Validation Design ModelSpecification Verification & Refusal Analysis Validation FORMAL METHODS Implementation Testing UML

14. Formal Verification & Validation Design ModelSpecification Verification & Refusal Analysis Validation FORMAL METHODS Implementation Testing UML TOOLS: UPPAAL visualSTATE SPIN

15. Formal Verification & Validation Design ModelSpecification Verification & Refusal Analysis Validation FORMAL METHODS Implementation Testing UML Automatic Code generation TOOLS: UPPAAL visualSTATE …..

16. Formal Verification & Validation Design ModelSpecification Verification & Refusal Analysis Validation FORMAL METHODS Implementation Testing UML Automatic Code generation Automatic Test generation TOOLS: UPPAAL visualSTATE …..

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

18. UPPAAL

19. SPIN, Gerald Holzmann AT&T

20. visualSTATE zHierarchical state systems zFlat state systems zMultiple and inter- related state machines zSupports UML notation zDevice driver access VVS w Baan Visualstate, DTU (CIT project)

21. Train Simulator 1421 machines 11102 transitions 2981 inputs 2667 outputs 3204 local states Declare state sp.: 10^476 BUGS ? VVS visualSTATE Our techniuqes has reduced verification time with several orders of magnitude (ex 14 days to 6 sec)

22. ‘State Explosion’ problem a cb 1 2 43 1,a 4,a 3,a4,a 1,b2,b 3,b4,b 1,c2,c 3,c4,c All combinations = exponential in no. of components M1 M2 M1 x M2 Provably theoretical intractable

23. Tool Support TOOL 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

24. Model Checking zoutput yyes yno + counterexample zinput: ytemporal logic spec yfinite-state model MC G(p -> F q) yes no p q p q

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

26. Types of temporal properties zSafety(nothing bad happens) G ~(ack1 & ack2) “ mutual exclusion ” G (req -> (req W ack)) “ req must hold until ack ” zLiveness(something good happens) G (req -> F ack) “ if req, eventually ack ” zFairness GF req -> GF ack “ if infinitely often req, infinitely often ack ”

27. Example: traffic light controller zGuarantee no collisions zGuarantee eventual service E S N

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

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

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

31. 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); zFairness constraints GF ~(N_Go & N_Sense); GF ~(S_Go & S_Sense); GF ~(E_Go & E_Sense); /* assume each sensor off infinitely often */

32. Counterexample zEast 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_Req N light goes on at same time S light goes off. S takes priority and resets NS_Lock N light goes on at same time S light goes off. S takes priority and resets NS_Lock

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

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

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

36. All properties verified zGuarantee no collisions zGuarantee service assuming fairness zComputational resources used: y57 states searched y0.1 CPU seconds

37. 7 Computation tree logic (CTL) zBranching time model zPath quantifiers  A = “ for all future paths ”  E = “ for some future path ”  Example: AF p = “ inevitably p ” AF p p p p zEvery operator has a path quantifier yAG AF p instead of GF p

38. 8 Difference between CTL and LTL zThink of CTL formulas as approximations to LTL yAG EF p is weaker than G F p So, use CTL when it applies... yAF AG p is stronger than F G p p Good for finding bugs... Good for verifying... pp zCTL formulas easier to verify

39. CTL model checking algorithm  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

40. Specifying using  automata zAn automaton accepting infinite sequences yFinite set of states (with initial state) yTransitions labeled with Boolean conditions ySet of accepting states p G (p -> F q) ~q~q q ~p~p Interpretation: A run is accepting if it visits an accepting state infinitely often Language = set of sequences with accepting runs

41. Verifying using  automata zConstruct parallel product of model and automaton  Search for “ bad cycles ” yVery similar algorithm to temporal logic model checking zComplexity (deterministic automaton) yLinear in model size yLinear in number of automaton states yComplexity in number of acceptance conditions varies

42. Comparing automata and temporal logic zTableau procedure yLTL formulas can be translated into equivalent automata yTranslation 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;

43. State explosion problem zWhat if the state space is too large? ytoo much parallelism ydata in model zApproaches  “ Symbolic ” methods (BDD ’ s) yAbstraction/refinement yExploit symmetry yExploit independence of actions

44. Binary Decision Diagrams (Bryant) zOrdered decision tree for f = ab + cd 0001000100011111 d ddddddd c ccc 01 0 101 0 1010101 b b a

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

46. OBDD properties zCanonical form (for fixed order) ydirect comparison zEfficient algorithms  build BDD ’ s for large circuits f g O(|f| |g|) fg zVariable order strongly affects size

47. Symbolic Model Checking zRepresent sets and relations with Boolean functions a,ba’,b’ R(a,b,a’,b’) yEnables search of larger state spaces yHandle more complex control yCan in some cases extend to data path specifications  Breadth-first search using BDD ’ s S 0 = pS1S1... SS S i+1 = S i \/ EX S i

48. Abstraction zReduces state space by hiding some information zIntroduces non-determinism Abstract states Concrete states zAllows verification at system level

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

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

51. Validation & Verification Construction of UPPAAL models Plant Continuous Controller Program Discrete sensors actuators Task a cb 1 2 43 a cb 1 2 43 1 2 43 1 2 43 a cb Model of environment (user-supplied) Model of tasks (automatic)

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

53. Intelligent Light Control OffLightBright press? Solution: Add real-valued clock x X:=0 X<=3 X>3

54. Timed Automata n m a Alur & Dill 1990 Clocks: x, y x 3 x := 0 Guard Boolean combination of comp with integer bounds Reset Action 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 Action used for synchronization

55. n m a Clocks: x, y x 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 Location Invariants g1 g2 g3 g4 Invariants insure progress!! Timed Automata - Invariants

56. Networks of Timed Automata + Integer Variables +…. l1 l2 a! x>=2 i==3 x := 0 i:=i+4 m1 m2 a? y<=4 …………. Two-way synchronization on 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

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

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

59. 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); }