1 / 59

Computer-Aided Verification

電腦輔助驗證. 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.tw Phone: 2363 5251 ext. 540 Office Hours: By appointment. Useful book.

seoras
Download Presentation

Computer-Aided Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Other names Formal methods Formal verification Automated verification

  3. Class Web Page • www.ee.ntu.edu.tw/~yen/courses/cav02 • E-mail: yen@ee.ntu.edu.tw • Phone: 2363 5251 ext. 540 • Office Hours: By appointment

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

  5. Topics • Introduction • Automata Theory • Temporal Logics: LTL, CTL, CTL* • Model Checking • w-Automata, m-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

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

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

  8. A REAL real time system Klaus Havelund, NASA

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

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

  11. Traditional Software Development The Waterfall Model REVIEWS Problem Area Analysis Design REVIEWS Implementation Testing • Costly in time-to-market and money • Errors are detected late or never • Application of FM’s as early as possible Running System

  12. Introducing, detecting and repairing errors

  13. Formal Verification & Validation Analysis Validation Design Model • Specification FORMAL METHODS Verification & Refusal UML Implementation Testing

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

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

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

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

  18. UPPAAL

  19. SPIN, Gerald Holzmann AT&T

  20. visualSTATE VVS w Baan Visualstate, DTU (CIT project) • Hierarchical state systems • Flat state systems • Multiple and inter-related state machines • Supports UML notation • Device driver access

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

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

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

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

  25. 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”

  26. Types of temporal properties • Safety (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” • Fairness GF req -> GF ack “if infinitely often req, infinitely often ack”

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

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

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

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

  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 end

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

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

  36. All properties verified • Guarantee no collisions • Guarantee service assuming fairness • Computational resources used: • 57 states searched • 0.1 CPU seconds

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

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

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

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

  41. Verifying using w-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

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

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

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

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

  46. OBDD properties • Canonical form (for fixed order) • direct comparison • Efficient algorithms • build BDD’s for large circuits f fg g O(|f| |g|) • Variable order strongly affects size

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

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

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

  50. Hybrid & Real Time Systems Computer Science Control Theory sensors Task Task Task Task actuators Controller Program Discrete Plant Continuous 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

More Related