Formal Verification by Model Checking

Transcription

1 Outline Formal Verifiation by Model Cheking Natasha Sharygina Carnegie Mellon University Guest Letures at the Analysis of Software Artifats Class, Spring Leture 1: Overview of Model Cheking Leture 2: Complexity Redution Tehniques Leture 3: Software Verifiation Leture 4: State/Event-based software model heking Leture 5: Component Substitutability Leture 6: Model Cheking Pratium (Student Reports on the Lab exerises) 2 Today s Leture Temporal Logi Model Cheking Motivation Model Cheking Overview Motivation More and more omplex systems => exploding testing osts Inreased dependability => quality onerns Inreased funtionality 3 4 1

2 v EEF NASA Robot Controller v EEF Verifiation Properties ee_referene=0; end_position=0; EE6: MoveEndEffetor(EE_ID) Idle EE5: bak(ee_id) Initial Following positioning Desired EE3: BaktoIdle(EE_ID) Trajetory EE2: ChekLimits(EE_ID) ee_referene=1;.. For (int i=0;i<6;i++){ if(current_position>=final_point) if (Current_position[i]>Limit[i]{ end_position=1; End_position=1;}} EE4: ChekConstraints(EE_ID) Cheking onstraints EndEffetor Foreah Joint{ Generate J1:Configure(Joint(Joint_ID).Joint_ID);} arm_status=0; MovingJoints A1:Valid(Arm_ID) A2: NotValidConfiguration(Arm_ID) A3:toNotValidState(Arm_ID Valid ) Not_Valid arm_status=0; arm_status=1; A4:toValidState(Arm_ID) A5:stop(Arm_ID) stopped abort_var=1; Arm A6:terminate(Arm_ID) 5 Configuration Validity Chek If the EndEffetor is in the FollowingDesiredTrajetory state, then the Arm is in the Valid state Always((ee_referene=1) ->(arm_status=1)) Safety If the EndEffetor reahes an undesired position, then the program terminates prior to a new move of the EndEffetor AfterAlwaysUntil(undesired_position =1,ee_referene=1,abort_var=1) 6 v EEF Verifiation Properties Configuration Validity Chek (FALSE) If the EndEffetor is in the FollowingDesiredTrajetory state, then the Arm is in the Valid state Why is this hard? Generating all possible paths of exeution is hard; ask any testing expert. In partiular, foring a olletion of (potentially distributed) proesses to exeute in all possible relative orders is notoriously diffiult. A B A B Always((ee_referene=1) ->(arm_status=1)) C D C D E F E F 7 8 2

3 Motivation What are the problems with the analysis tehniques you have learned so far? - not exhaustive (missed behaviors) - not all are automated (manual reviews, manual testing) - do not sale (large programs are hard to handle) - no guarantee of results (no mathematial proofs) - onurreny problems Formal Verifiation by Model Cheking Domain: Continuously operating onurrent systems (e.g. operating systems, hardware ontrollers and network protools) Ongoing, reative semantis Non-terminating, infinite omputations Manifest non-determinism Instrument: Temporal logi [Pnueli 77] is a formalism for reasoning about behavior of reative systems Need for automated, exhaustive and mathematially sound analysis! 9 10 Temporal Logi Model Cheking [Clarke,Emerson 81][Queille,Sifakis 82] Temporal Logi Model Cheking Systems are modeled by finite state mahines Properties are written in propositional temporal logi Verifiation proedure is an exhaustive searh of the state spae of the design Finite State Mahine Preproessor Property Diagnosti ounterexamples Model Cheker True or Counterexample

4 What is Model Cheking? What is M? Does model M satisfy a property P? (written M = P) What is M? States: valuations to all variables Initial states: subset of states Ars: transitions between states What is P? Atomi Propositions: e.g. x = 5, y = true b What is satisfy? Observation (olor): Valuation to all atomi propositions State Transition Graph or Kripke Model What is M? Model of Computation M = W, I, R, L, Γ W - set of states I W set of initial states R W X W - set of ars L - set of atomi propositions b b Γ : W 2 L mapping from states to olors State Transition Graph Infinite Computation Tree Unwind State Graph to obtain Infinite Tree. 15 A trae is an infinite sequene of states. 16 4

5 Semantis What is P? Different kinds of temporal logis b Syntax: What are the formulas in the logi? b Semantis: formula P? What does it mean for model M to satisfy State Transition Graph Infinite Computation Tree The semantis of a FSM is a set of traes. Semantis of the omposition of FSMs is the intersetion of traes of individual FSMs. 17 Formulas: - Atomi propositions: properties of states - Temporal Logi Speifiations: properties of traes. 18 Computation Tree Logis Computation Tree Logis Examples: Safety (mutual exlusion): no two proesses an be at a ritial setion at the same time Formulas are onstruted from path quantifiers and temporal operators: Liveness (absene of starvation): every request will be eventually granted Temporal logis differ aording to how they handle branhing in the underlying omputation tree. In a linear temporal logi (LTL), operators are provided for desribing system behavior along a single omputation path. 1. Path Quantifiers: A for every path E there exists a path 2. Temporal Operator: Xα - α holds next time Fα - α holds sometime in the future Gα - α holds globally in the future α U - α holds until holds In ranhing-time logi (CTL), the temporal operators quantify over the paths that are possible from a given state

6 The Logi LTL The Logi CTL Linear Time Logi (LTL) [Pnueli 77]: logi of temporal sequenes. In ranhing-time logi (CTL), the temporal operators quantify over the paths that are possible from a given state (s 0 ). AXα: α holds in the next state α AFγ: γ holds eventually Aλ: λ holds from now on λ λ γ λ λ M, s 0 = AG M, s 0 = AF α U β: α holds until β holds α α β 21 M, s 0 = EF M, s 0 = EG 22 Typial CTL Formulas Robot Controller System EF (Started Ready): it is possible to get to a state where Started holds but Ready does not hold. AG (Req AF Ak): if Request ours, then it will be eventually Aknowledged. AG (DevieEnabled): DevieEnabled holds infinitely often on every omputation path. AG (EF Restart): from any state it is possible to get to the Restart state. 23 ee_referene=0; end_position=0; EE6: MoveEndEffetor(EE_ID) Idle EE5: bak(ee_id) Initial Following positioning Desired EE3: BaktoIdle(EE_ID) Trajetory EE2: ChekLimits(EE_ID) ee_referene=1;.. For (int i=0;i<6;i++){ if(current_position>=final_point) if (Current_position[i]>Limit[i]{ end_position=1; End_position=1;}} EE4: ChekConstraints(EE_ID) Cheking onstraints EndEffetor Foreah Joint{ Generate J1:Configure(Joint(Joint_ID).Joint_ID);} arm_status=0; MovingJoints A1:Valid(Arm_ID) A2: NotValidConfiguration(Arm_ID) A3:toNotValidState(Arm_ID Valid ) Not_Valid arm_status=0; arm_status=1; A4:toValidState(Arm_ID) A5:stop(Arm_ID) stopped A6:terminate(Arm_ID) abort_var=1; Arm 24 6

7 Examples of the Robot Control Properties Safety Operation: If the EndEffetor reahes an undesired position, then the program terminates prior to a new move of the EndEffetor AfterAlwaysUntil(undesired_position =1,ee_referene=1,abort_var=1) Configuration Validity Chek: If an instane of EndEffetor is in the FollowingDesiredTrajetory state, then the instane of the orresponding Arm lass is in the Valid state Always((ee_referene=1) ->(arm_status=1) Control Termination: Eventually the robot ontrol terminates Linear vs. branhing-time logis some advantages of LTL LTL properties are preserved under abstration : i.e., if M approximates a more omplex model M, by introduing more paths, then M ² ψ ) M ² ψ ounterexamples for LTL are simpler: onsisting of single exeutions (rather than trees). The automata-theoreti approah to LTL model heking is simpler (no tree automata involved). anedotally, it seems most properties people are interested in are linear-time properties. some advantages of BT logis BT allows expression of some useful properties like reset. CTL, a limited fragment of the more omplete BT logi CTL*, an be model heked in time linear in the formula size (as well as in the transition system). But formulas are usually far smaller than system models, so this isn t as important as it may first seem. Some BT logis, like µ-alulus and CTL, are well-suited for the kind of fixed-point omputation sheme used in symboli model heking. EventuallyAlways(abort_var=1) What is satisfy? M satisfies P if all the reahable states satisfy P Different Algorithms to hek if M = P. Common Feature: Exhaustive State Spae Exploration! Expliit state spae exploration: 1) Invariant heking Algorithm. Invariant: ϕ: What is satisfy? atomi propositions (e.g. x =5, b=true) ϕ ϕ ψ ϕ ψ 27 satisfation: M satisfies ϕ if all the reahable states satisfy ϕ 28 7

8 Invariant heking Algorithm Refinement Does M satisfy P? 1. Start at the initial states and explore the states of M using DFS or BFS. r 1 r 2 r 1 F r 2 G 1 G 2 g 1 g 2 Idea: Implementation Speifiation 2. In any state, if P is violated then print an error trae. 3. If all reahable states have been visited then say yes. r 1 ~r 1 F 1 ~r F 2 2 g 1 Every behavior of the implementation should be an allowable behavior of the speifiation. Model heking omplexity: M r 2 r 1 r 2 G 1 G 2 g Every trae of M is a trae of S Language Containment M S - Linear Time Every formula in linear logi (LTL) satisfied by S, is also satisfied by M Complexity: M * 2 S In pratie an be done using reahability Symboli State Spae Exploration What is satisfy? (ont.) a 0 1 b b d d d d d d d d Idea: to use Boolean enoding for state mahine and sets of states. Compat representation of transition relations. Can handle muh larger designs hundreds of state variables BDDs traditionally used to represent Boolean funtions

9 State Spae Explosion Problem: Size of the state graph an be exponential in size of the program (both in the number of the program variables and the number of program omponents) Model Cheking Performane Model Chekers today an routinely handle systems with between 100 and 300 state variables. M = M 1 M n If eah M i has just 2 loal states, potentially 2 n global states Systems with reahable states have been heked. By using appropriate abstration tehniques, systems with an essentially unlimited number of states an be heked. Researh Diretions: State spae redution (next lass) Notable Examples IEEE Salable Coherent Interfae In 1992 Dill s group at Stanford used Murphi to find several errors, ranging from uninitialized variables to subtle logial errors IEEE Futurebus In 1992 Clarke s group at CMU found previously undeteted design errors PowerSale multiproessor (proessor, memory ontroller, and bus arbiter) was verified by Verimag researhers using CAESAR toolbox The Grand Challenge: Model Chek Software Extrat finite state mahines from programs written in onventional programming languages Use a finite state programming language: exeutable design speifiations (Stateharts, xuml, et.). Unroll the state mahine obtained from the exeutable of the program. Luent teleom. protools were verified by FormalChek errors leading to lost transitions were identified PowerPC 620 Miroproessor was verified by Motorola s Verdit 35 model heker. 36 9

10 The Grand Challenge: Model Chek Software Use a ombination of the state spae redution tehniques to avoid generating too many states. Verisoft (Bell Labs) FormalChek/xUML (UT Austin, Bell Labs) ComFoRT (CMU/SEI) Use stati analysis to extrat a finite state skeleton from a program. Model hek the result. Bandera Kansas State Java PathFinder NASA Ames SLAM/Bebop - Mirosoft 37 10