SlideServe
Menu
Préférences
© SlideServe · v2026

Model checking

harrylewis avatar
27 diapositives · 374 Views · Jan 02, 2020

Learn how to model reactive systems using automata, verify correctness conditions, and conduct model checking to increase system reliability. Understand translating LTL formulas to automata and checking for correctness.

Model checking - slide 1
01 / 27Model checking
1 / 17

Télécharger la présentation

Model checking
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. Model checking

  2. And now... the system • How do we model a reactive system with an automaton ? • It is convenient to model systems with • Transition systems (textutal representation), or, equivalenely, with a • Kripke structures (automata representation).

  3. Kripke structures • A convenient model for describing reactive systems • Implicitly all states areaccepting. • M=hS, , I, Li • S: States (finite). •  µ S x S is the transition relation. • I µ S are the Initial states. • L: S ) 2AP(where AP is a set of atomic propositions) Convention: we will only write the positive literals.

  4. A Kripke structure • Note: the alphabet is NOT the set AP. • Rather it is 2AP

  5. From a Kripke structure to a Buchi automata • Given a Kripke structure M=hS, M, IM, Li... ...we can build an equivalent Buchi automata BM = h, S, ¢, I, Fi where •  = 2Prop • S // same states • (s, t) 2¢ iff (s,t) 2¢M and a = L(s) // transition relation • I = IM // same initial state • F = S //every state is accepting

  6. Example Recall that this is {p,q} • The system: M = p,q p becomes the Buchi automaton (recall: a transition is labelled with an element of 2AP) p,q  p  p

  7. Correctness condition • An LTL formula  = a set of allowed computations (‘models’). • A Kripke structure M = a set of computations. • Are the computations of M models of  ?

  8. Correctness Sequencessatisfying Spec Program computations All sequences

  9. Incorrectness Counter examples Sequencessatisfying Spec Program computations All sequences

  10. Model-Checking: formally • Language of a model M: L(M) • Language of a specification : L(). • We need: L(M) L(). This is called Model-Checking • If yes, we write M ².

  11. q Model checking – example : G (p U q) p,y p,x s0 s1 p s2 q,x model M spec B M ² ? • Let = s0,s1. • 2L(M) but   L(B). Hence L(M) *L(B).

  12. S M M : S M µ S M Å: S ¹; How to model-check? • Show that L(Model)  L(Spec). • Equivalently: Show that L(Model)  L(Spec) = Ø. • How? Check that Amodel £A:Specis empty.

  13. What do we need to know? • How to translate from LTL to an automaton ? • How to complement an automaton? • How to intersect two automata? • How to check for emptiness of an automaton ? L(Model)  L(Spec) = Ø.

  14. How to complement? • Complementation is hard! • We know how to translate an LTL formula to a Buchi automaton. So we can: • Build an automaton A for , and complement A, or • Negate the property, obtaining ¬ (the sequences that should never occur). Build an automaton for ¬ .

  15. But... reacall... • Theoretically, model checking gives us a proof of correctness • Practically, it mainly attempts to increase reliability: • Automated systematic debugging • VERY good at finding errors! • Why ? • Possible bugs in the model checker • Capacity limitations • Wrong or missing properties • ...

  16. From programs to Kripke structures • Supposed that we wish to model-check a program / concurrent program – • How can we represent it as a Kripke structure ?

  17. Kripke structures • Kripke structures are suitable for modeling a synchronous system. • When we move from state s to state s’, the values of the atoms in the state are changed synchronously. • Is this the case for programs ? • How can we describe programs as transition systems?

  18. Programs as transition systems • Programs we know are sequential. • What is the result of this computation : ... x = y; y = x; • We need to model the location in the program • We will use a variable called the program counter (PC)

  19. L0:While True do nc0:wait (Turn=0); cr0:Turn=1 T0:(pc0=L0, pc0=nc0) T1: (pc0=nc0Æ Turn=0, pc0=cr0) T2: (pc0=cr0, pc0 =L0 Æ Turn=1) T3: (pc1=L1, pc1=nc1) T4: (pc1=nc1 Æ Turn=1, pc1=cr1) T5: (pc1=cr1, pc1 = L1 ÆTurn = 0) Example: A program that maintains mutual exclusion Initially: pc0=L0Æ pc1=L1 L1:While True do nc1:wait (Turn=1); cr1:Turn=0 || Possible transitions:

  20. Turn=0 L0,L1 Turn=1 L0,L1 Turn=0 L0,nc1 Turn=0 nc0,L1 Turn=1 L0,nc1 Turn=1 nc0,L1 Turn=0 nc0,nc1 Turn=0 cr0,L1 Turn=1 L0,cr1 Turn=1 nc0,nc1 Turn=0 cr0,nc1 Turn=1 nc0,cr1 And now as a Kripke structure PC0 = L0, PC1 = L1

  21. Turn=0 L0,L1 Turn=1 L0,L1 Turn=0 L0,nc1 Turn=0 nc0,L1 Turn=1 L0,nc1 Turn=1 nc0,L1 Turn=0 nc0,nc1 Turn=0 cr0,L1 Turn=1 L0,cr1 Turn=1 nc0,nc1 Turn=0 cr0,nc1 Turn=1 nc0,cr1 G:(pc0=cr0Æ pc1=cr1) (a safety property)

  22. Turn=0 L0,L1 Turn=1 L0,L1 Turn=0 L0,nc1 Turn=0 nc0,L1 Turn=1 L0,nc1 Turn=1 nc0,L1 Turn=0 nc0,nc1 Turn=0 cr0,L1 Turn=1 L0,cr1 Turn=1 nc0,nc1 Turn=0 cr0,nc1 Turn=1 nc0,cr1 G(Turn=0 !FTurn=1) (a liveness property)

  23. What properties can we check? • Examples: • Invariants: a property that has to hold in each state. • Deadlock detection: can we reach a state where the program is blocked? • Dead code: does the program have parts that are never executed?

  24. If it is so good, is this all we need? • Model checking works only for finite state systems. Would not work with • Unconstrained integers. • Unbounded message queues. • General data structures: • queues • trees • stacks • Parametric algorithms and systems.

  25. The state space explosion problem • Need to represent the state space of a program in the computer memory. • Each state can be as big as the entire memory! • Many states: • Each integer variable has 232 possibilities. Two such variables have 264 possibilities. • In concurrent protocols, the number of states usually grows exponentially with the number of processes.

  26. If it is so constrained, is it of any use? • Many protocols are finite state. • Many programs or procedures are finite state in nature. Can use abstraction techniques.

  27. If it is so constrained, is it of any use? • Sometimes it is possible to decompose a program, and prove part of it by model checking and part by other methods. • Many techniques to reduce the state space explosion • We will NOT learn about such techniques, but let us mention some names: • Data structures such as Binary Decision Diagrams, • Reductions, such as Partial Order Reduction.