1 Computergestützte Verifikation

2 Model Checking für finite state systems explizit:symbolisch: 3.1: Tiefensuche 3.2: LTL-Model Checking 3.3: CTL-Model Checking 3.5: Reduktion durch Symmetrie 3.6: Partial Order Reduction 3.7: Tools 4.1: BDD-basiertes CTL-Model Checking 4.2: SAT-basiertes Model Checking 4.3: Tools 3.4: Fairness Kapitel 3 Kapitel 4

3 Zusammenfassung Symmetrie Symmetrien können in speziellen Datentypen oder als Automorphismen geeigneter Graphen gefunden werden Datentypsymmetrie: - nur einige spezielle Symmetriegruppen, + Erkennung der Symmetrien trivial + Orbit-Problem effizient lösbar Automorphismen: + viele Symmetriegruppen ( mehr Reduktion) - Erkennung der Symmetrien aufwendig, obwohl meist doch polynomiell - Orbit-Problem langsam oder approximativ

4 3.6 Partial Order Reduction

5 Verteilte Systeme Unabhängigkeitsrelation I zwischen Aktionen: [a,b] in I gdw. keine der beiden Aktionen kann die Enabling- Bedingung der anderen ändern, und Resultat der Hinterein- anderausführung von a und b ist unabhängig von der Reihenfolge s s1 s2 s z.B. [g,g] in I gdw. vorkommende Variablen disjunkt Unabhängige Aktionen tragen wesentlich zur Zustandsraumexplosion bei.

6 Zustandsexplosion in verteilten Systemen Prozess AProzess BProzess C internal sync internal sync internal sync

7 Ansatz bekämpfe Zustandsraumexplosion durch Unabhängigkeit unabhängige Aktionen können in beliebiger Reihenfolge stattfinden Reihenfolge ist oft unerheblich für Eigenschaft reduziere, wo möglich, die Anzahl der Reihenfolgen, in denen unabhängige Aktionen ausgeführt werden

8 Geschichte 1988 Valmari stubborn sets 1991 Godefroid persistence sets 1993 Peled ample sets unabhängige Ansätze stubborn sets: Prinzipien am meisten pushed to the limit ample sets: pragmatischer für Implementation hier: Amalgam aus stubborn und ample sets

9 Ample sets Sei s Zustand. ample(s) ist eine (wenn möglich) nichtleere Teilmenge der Aktionen, die bei s enabled sind Reduziertes Transitionssystem: verfolge bei s nur die Aktionen in ample(s)

10 Reduziertes Transitionssystem

11 Weiteres Vorgehen 1. Studieren Prinzipien, die Ample sets erfüllen müssen, um LTL-Eigenschaften zu bewahren 2. Implementationsfragen 3. Wie es bei CTL(*) aussieht 4. Varianten für einfache Eigenschaftsklassen

12 Prinzip # 1: Unabhängigkeit Alle Aktionen, die in s enabled sind und nicht in ample(s), sind von jeder Aktion in ample(s) unabhängig Stattfinden der ausgeschlossenen Aktionen wird auf Nachfolgezustände vertröstet Für jeden bei s beginnenden Pfad des originalen Systems: Keine Aktion, die von einer Aktion in ample(s) abhängig ist, kommt vor einer Aktion aus ample(s) vor.

13 Erstes Prinzip und Deadlocks Deadlock = Zustand, in dem keine Aktion stattfinden kann Satz: Wenn ein red. Transitionssystem alle Initialzustände und, zu jedem s, alle Nachfolger aus ample(s) enthält, und ample(s) Prinzip # 1 genügt, dann sind im red. System alle Deadlocks des originalen Systems enthalten. s d Sei w length(w) = min 1. Fall: in w kommt ein a aus ample(s) vor s s1s2 d w1a w2 ss1 s2 d w1 a w2 s1 im red. TS, näher an d! 2. Fall: in w kommt kein a aus ample(s) vor s d w a a d kein Deadlock!

14 Erstes Prinzip und unendliche Pfade Satz: Wenn das originale TS einen unendlichen Pfad enthält, so auch das reduzierte. s w 1. Fall: in w kommt ein a aus ample(s) vor s s1s2 w1a w2 2. Fall: in w kommt kein a aus ample(s) vor s w a s1 s2 w1 a w2 Wenn bei s unendl. Pfad ausführbar ist, so gibt es im red. TS einen Nachfolger von s, bei dem ein unendl. Pfad ausführbar ist. Rest: Induktion s1 w

15 Idee der weiteren Prinzipien Voriger Satz: Wenn unendl. Pfad im originalen System, so unendl. Pfad im reduzierten System Zukunft: Wenn unendl. Pfad mit Eigenschaft Y im orig. TS, so unendl. Pfad mit Eigenschaft Y im red. TS Beweis des vorigen Satzes liefert Zuordnung eines Pfades im red. System zu einem Pfad im originalen System Wir sorgen jetzt dafür, daß ein passender Pfad zugeordnet wird.

16 Vorbereitung auf Prinzip # 2 Ziel: In dem zugeordneten Pfad finden wichtige Aktionen in derselben Reihenfolge statt wie im originalen Pfad Sei LTL-Formel. Aktion a heißt unsichtbar für, wenn a in keinem Zustand den Wahrheitswert irgendeiner in vorkommenden elementaren Zustandsaussage ändern kann. wichtig = sichtbar einzige Bedeutung unsichtbarer Aktionen: An- oder Abwesenheit entscheidet darüber, wie lange ein und dieselbe Kombination von Wahrheitswerten andauert SStttooooteeerrrnnn

17 Stotteräquivalenz Sei X Alphabet und w Wort (endlich oder unendlich) Die Stotterklasse von w enthält w und ist abgeschlossen bzgl.: -mit waw ist auch waaw enthalten -mit waaw ist auch waw enthalten Satz: Mit dem üblichen Alphabet (Vektoren von Wahrheitswerten) sind alle LTL-Eigenschaften, die kein X benutzen, stotterinvariant. LTL-X Eine Menge von Wörtern ist stotterinvariant, wenn sie mit w immer die ganze Stotterklasse von w enthält.

18 Stottern in verteilten Systemen Stottern wird induziert durch nebenläufige unbeteiligte Komponenten relevante Eigenschaften verteilter Systeme sind immer stotterinvariant Einschränkung auf LTL-X nicht tragisch (partial order reduction zielt eh nur auf verteilte Systeme)

19 Prinzip # 2: Sichtbarkeit ample(s) enthält entweder keine einzige sichtbare Aktion oder alle Aktionen, die enabled sind (sichtbar wie unsichtbar) 1. Fall: in w kommt ein a aus ample(s) vor s s1s2 w1a w2 s1 s2 d w1 a w2 a unsichtbar oder w1 leer 2. Fall: in w kommt kein a aus ample(s) vor s w a s1 w a unsichtbar diejenigen sichtbaren Aktionen, die aus dem Originalpfad in den reduzierten Pfad übernommen werden, bleiben in der gleichen Reihenfolge

20 Vorbereitung auf Prinzip # 3 Problem: Mit Prinzipien 1 und 2 kann das Vorkommen sichtbarer Aktionen auf ewig aufgeschoben werden. Aus einem Pfad, der a U b im Originalsystem erfüllt, kann im red. System ein Pfad werden, der G a erfüllt. müssen ewiges Aufschieben verhindern

21 Prinzip # 3: Nichtignorierung Jeder Kreis im reduzierten Transitionssystem enthält einen Zustand s, wo ample(s) alle Aktionen enthält, die in s enabled sind Wirkung: in einem solchen Zustand kann Fall 1 der Pfadargumentation angewendet werden. Jede Aktion des Originalpfades wird irgendwann\ auch im konstruieerten Pfad ausgeführt

22 Prinzipien # 1-3 bewahren LTL-X Satz: Ein TS erfüllt eine LTL-X-Formel gdw. ein beliebiges reduziertes TS, das Prinzipien 1-3 befolgt, die Formel erfüllt. Bew.: Wenn das Originalsystem einen unendlichen Gegenbsp.- pfad enthält, so enthält das reduzierte System einen unendlichen Pfad (P # 1), in dem alle sichtbaren Aktionen des Originalpfades irgendwann vorkommen (P # 1,3), und zwar in der gleichen Reihenfolge (P # 1,2), und ansonsten nur unsichtbare Aktionen (P # 1,2) Dieser Pfad ist ebenfalls Gegenbsp. (Wahl der sichtbaren Aktionen, Stottoerinvarianz)

23 Implementation von Prinzip # 2 Einfach: Jede Aktion, die Variablen schreibt, die in einer elementaren Zustandsaussage vorkommen, ist sichtbar. Komplizierter (Bsp): = pc = 17 g = pc = 23 bla pc := 42,.... Wichtig: Umsetzung darf nicht zu viel Zeit kosten. kann unsichtbar bleiben, obwohl es pc schreibt

24 Implementation von Prinzip # 3 Satz: Jeder Kreis enthält eine Rückwärtskante Sei s1... sn Kreis, o,B.d.A s1 der zuerst bei Tiefensuche betretene Zustand. sn von s1 erreichbar sn Baumnachfolger von s1 [sn,s1] ist Rückwärtskante Implementation: -Benutze zunächst ample set nach Prinzipien 1 und 2 -Markiere alle Zielknoten von Rückwärtskanten -Bei Backtracking zu einem markierten Knoten, ersetze ample(s) durch alle Aktionen, die enabled sind. Die nachträgliche Änderung stellt keinen ernsten Eingriff dar

25 Implementation von Prinzip # 1 Für jeden bei s beginnenden Pfad des originalen Systems: Keine Aktion, die von einer Aktion in ample(s) abhängig ist, kommt vor einer Aktion aus ample(s) vor. Problem: a a c c b Eine von a unabhängige Aktion c könnte eine von a abhänige Aktion aktivieren. jetzt: ample*(s) – sowohl Aktionen, die enabled sind, als auch welche, die disabled sind. ample(s) = ample*(s) en(s)

26 Eingeschränkte Guardbedingungen z.B. pc = 17 mailbox.... g heißt enabled in s bzgl. U Var (en(g,s,U) ), falls ein s ex. mit s(v) = s(v) für v in U, und g enabled in s ( en(g,s) ) z.B. en(pc = 17 mailbox...., (17, ),{ pc}) ¬en(pc = 17 mailbox...., (17, ), {mailbox}) ¬ en(g,s,U) ¬ en(g,s)

27 Write-Up-Mengen geg. guarded command g, ¬ en(g,s,U) wrup(g,U) : Eine Menge von guarded commands mit: Wenn s von s ohne Verwendung von commands aus wrup(g,U) erreicht wird, so ¬ en(g,s,U) Bsp: g = pc = 17 mailbox.... wrup(g,{pc}) = { g | g ,pc:= 17,....} Bsp: g = x > wrup(g,{x}) = {g | g kann Wert von x erhöhen} notfalls: wrup(g,U) := {g | g schreibt Variablen in U}

28 Implementation von Prinzip # 1 Wenn ample*(s) folgende Bedingungen erfüllt: (E) Wenn g in ample*(s) und en(g,s), so sind alle von g abhängigen Aktionen in ample*(s) (D) Wenn g in ample*(s) und ¬en(g,s), so sind für ein U mit ¬en(g,s,U) alle Aktionen aus wrup(g,U) in ample*(s) dann erfüllt ample(s) := ample*(s) en(s) Prinzip # 1: Wenn g in ample(s), so sind alle abhängigen Aktionen in ample*(s) (E) Wenn g in ample*(s) und disabled, so können Aktionen außerhalb ample*(s) g nicht aktivieren. Algorithmus: Ersetze sind drin durch müssen auch rein, löse Nichtdeterminismus bei der Wahl von U irgendwie auf.

29 Implementation von Prinzip # 1 genauer: muß auch rein bildet gerichteten Graph zwischen Aktionen. ample(s) := die aktivierten Aktionen aus der ersten gefundenen SZK, die aktivierte Aktionen enthält. ample(s) wird durch Tiefensuche in diesem Graph bestimmt Der Abschluß dieser SZK bzgl. muß auch rein enthält weitere Aktionen, aber keine weiteren aktivierten Aktionen.

30 Übung 1 Bestimme eine größtmögliche Unabhängigkeitsrelation zwischen folgenden guarded commands (alle Variablen sind vom Typ Nat). g1: x > 0 x := x – 1, z := z + 1, y := y + 1 g2: y > 0 y := y – 1, u := u + 1 g3: u > 1 v > 0 u := u – 1, v := v – 1, x := x + 1 g4: z > 0 z := z – 1, v := v + 1 g5: y > 0 y := y – 1, z := z + 1

31 Übung 2 Welche Aussagen sind für diese guarded commands im Zustand s = (x = 0, y = 0, z = 1, u = 1, v = 0) richtig? g1: x > 0 x := x – 1, z := z + 1, y := y + 1 g2: y > 0 y := y – 1, u := u + 1 g3: u > 1 v > 0 u := u – 1, v := v – 1, x := x + 1 g4: z > 0 z := z – 1, u := u + 1 g5: y > 0 y := y – 1, z := z + 1 a)en(g3, s, {u}) b)en(g3,s,{v}) c)en(g3,s,{u,v}) d)en(g3,s) e) en(g4,s) f ) en(g4,s,{z}) g) en(g1,s) h) en(g1,s,{y})

32 Übung 3 Bestimme für diese guarded commands folgende Mengen! g1: x > 0 x := x – 1, z := z + 1, y := y + 1 g2: y > 0 y := y – 1, u := u + 1 g3: u > 1 v > 0 u := u – 1, v := v – 1, x := x + 1 g4: z > 0 z := z – 1, u := u + 1 g5: y > 0 y := y – 1, z := z + 1 a)wrup(g3,{u}) b)wrup(g3, {v}) c)wrup(g3,{u,v}) d) wrup(g4,{z}) e) wrup(g4,s,{x,y,z,u,v})