prasentation der seminararbeit¨ · prasentation der seminararbeit¨ interaktive veriﬁkation von...

Prasentation der SeminararbeitInteraktive Verifikation von synchronen Systemen

Alpin Mete Sahin, Cenk Gundogan

Fachbereich fur Mathematik und InformatikInstitut fur Informatik23. Juli 2013

Institut fur Informatik – Prasentation der Seminararbeit – 23. Juli 2013 1

Inhalt

1. Motivation

2. Synchrone Systeme

3. Quartz

4. Synchrone bedingte Aktionen

5. Averest-Framework

6. Interaktive Verifikation von synchronen Systemen

7. Zusammenfassung


Motivation

Motivation


Motivation

Programmverifikation– Nachweis, dass ein Programm das tut, was es soll– es existieren verschiedene etablierte Techniken zur Programmverifikation

– formale Programmverifikation– Modelchecking-Verfahren

– Nachteile beschranken die Benutzung dieser Programmverifikationstechniken


MotivationFormale Programmverifikation

Abbildung: Fakultat-Funktion [1]


MotivationFormale Programmverifikation

Abbildung: Hoare-Kalkul zur Fakultat-Funktion [1]


MotivationModelchecking

Abbildung: Modellchecking-Prozess [2]


MotivationModelchecking

– Anzahl der Zustande wachst exponentiell zur Anzahl der Variablen– N Variablen mit k moglichen Werten ergeben kN Zustande– Zustandsraum-Explosions-Problem

Ein Programm mit 10 Anweisungen, 3 bool und 5 int (von 0...9) Variablen besitztfolgende Anzahl an Zustanden:

10 · 23 · 105 = 800, 000

Hinzugabe eines bool[50]-Arrays erhoht den Zustandsraum auf

800, 000 · 250


Synchrone Systeme

Synchrone Systeme


Synchrone SystemeFunktionsweise

Abbildung: Funkionsweise eines synchronen Systems


Synchrone SystemeKlassifizierung

KlassifizierungSynchrone Systeme werden nach dem Verhalten ihrer Ausgabeparameter in zweiverschiedene Klassen klassifiziert.

– getaktete synchrone Systeme– perfekte synchrone Systeme


Synchrone SystemeKlassifizierung

getaktete synchrone SystemeAusgabe eines Makroschrittes wird nur folgendem Makroschritt zur Verfugung gestellt

– Einschrankung der Lese-Zugriffe anderer Makroschritte auf diese Ausgaben– Weitergabe der Referenz auf die Ausgaben direkt in den nachsten Makroschritt

perfekte synchrone Systeme– Variablenanderungen werden sofort einsehbar– konnen im aktuellen Makroschritt benutzt werden


Synchrone SystemeKausalitatszyklen

Kausalitatszyklen– parallele Ausfuhrung der Ausdrucke kann zu Kausalitatszyklen fuhren– Vorbedingung einer Anweisung wird durch eine andere Anweisung negiert– muss vom Compiler uberpruft werden


Quartz

Quartz


Quartzsynchrone Programmiersprache

– statisch getypte synchrone Programmiersprache– Programme werden aus einem oder mehreren Modulen aufgebaut– Variablendeklaration bestimmt Zugriff auf den Variablenwert– zusatzlich zum Systemverhalten existieren ebenfalls Spezifikationen



Modul

Listing 1: Modul-Block in Quartz

module M1(int<3> a[8], event !o, nat<5> b, bool ?p, int !r)



Variablendeklaration– Datentyp (atomare, zusammengesetzte)– Informationsfluss (input, output, inout, local)– Speichertyp (event, memorized)



Listing 2: Modul-Block in Quartz

module M1(int<3> a[8], event !o, nat<5> b, bool ?p, int !r)

Name Datentyp Informationsfluss Speichertyp

a array(int<3>,8) unkontrollierter input -o bool output eventb nat<5> unkontrollierter input -p bool kontrollierter input -r int output memorized

Tabelle: Erklarung der Variablendeklarationen



Programmspezifikation– Temporale Logiken zur Spezifikation und Verifikation von Computersystemen– Linear-time temporal logic (LTL)– Computation tree logic (CTL)– CTL*



Abbildung: Mengenbeziehung von LTL, CTL und CTL* [3]



Abbildung: Operatoren in LTL [4]



Abbildung: Operatoren in CTL [5]


Synchrone bedingte Aktionen




– um von den synchronen Programmiersprachen zu abstrahieren– Aussagen uber die Verifikation unabhangig von der Programmiersprache– Synchrone bedingte Aktionen sind atomare Aktionen, die innerhalb im

Makroschritt eines synchronen Systems ausgefuhrt werden– es existieren sofortige Aktionen und verzogerte Aktionen– Synchrone bedingte Aktionen besitzen die Form 〈γ ⇒ C〉



Abbildung: Synchrone bedingte Aktionen [6]



Kausalitatszyklus– Kein Kausalitatszyklus:

a⇒ y = x + 1

¬a⇒ x = y + 2 (1)

– Kausalitatszyklus:

a⇒ x = ¬y

a⇒ y = x (2)

– Kausalitatszyklus:

a⇒ x = true

a⇒ x = false (3)


Averest-Framework

Averest-Framework


Averest-FrameworkFunktionalitat

Abbildung: Entwickelt von der Embedded Systems Group, Universitat Kaiserslautern [7]



Abbildung: Verschiedene Transformationsmoglichkeiten aus dem AIF heraus [8]



Abbildung: Die GUI vom Averest-Framework basiert auf Drag’n’Drop



Abbildung: Es existieren diverse Transformationsmoglichkeiten fur das AIF


Interaktive Verifikation von synchronenSystemen




Interaktive Theorembeweiser– “Maschinengestutztes Beweisen”– Alterenative zu Modelchecking-Verfahren– Beweise werden in Teilbeweise aufgeteilt– Mensch liefert interaktiv “Hinweise” zur Beweissuche– Beispiele: HOL, Isabelle– basieren auf Logic for Computable Functions (LCF)



Logic for Computable Functions (LCF)– funktionale Programmiersprache ML als Meta-Sprache

– Formeln, Beweisziele und Theoreme als Datentypen in ML implementiert– Beweisregeln als Funktionen in ML implementiert

– Einsatz von funktionalen Programmiersprachen⇒ Benutzung von interaktiven Sessions moglich



Interaktive Verifikation mit Averest (AIFProver)– Verifikation kann Datentypen und Transformationen der Synthese verwenden– mit dem Resultat der Verifikation kann HW/SW-Design optimiert werden



Vorgehen fur die interaktive Verifikation mit Averest

Abbildung: Hier wird das generelle Vorgehen vom interaktiven Verifizieren in synchronen Systemenmithilfe des Averest-Frameworks dargestellt [9]



Abbildung: Hier wird die Zerlegung der Sequenz P1; P2 dargestellt [10]



Exemplarische Veranschaulichung

Listing 3: ABRO System in Quartz

module abro(event ?a ,? b ,? r ,! o ) {loop

abort{{wa: await(a); || wb:await (b);}emit(o);s0: assert(a|b);wr: await(r);

} when(r);}satisfies {

s1: assert A G (o -> a|b);s2: assert A G (o -> A X !o);

}



Listing 4: Synchrone bedingte Aktionen

system abro:interface:

a: input event boolb: input event boolr: input event boolo: outputevent bool

locals:w0: label boolwa: label boolwb: label boolwr: label bool

control flow:True => next(w0) = True!w0 => next(wa) = True!w0 => next(wb) = True((wa&!a)&!r)&!r|(r&wr|r&(wr|(wa|wb))) => next(wa) = True((wb&!b)&!r)&!r|(r&wr|r&(wr|(wa|wb))) => next(wb) = True((wr&!r)&!r)&!r|((((a&wa)&(b&wb))|(((b&wb)&!wa)|((a&wa)&!wb)))&!r)&!r =>

next(wr) = True



Listing 5: Verifikation des ABRO Systems

ShowCorrectness (fsi.CommandLineArgs.[0]);;// property s0:AutoTac();;

// property s1:RWSWIA o;;UseVarDefs [wa;wb];;UseBootFlagDef w0;;RW_NEXT();;AutoTac();;



AIFProver– AIFProver noch in der Alpha-Version– ist momentan nicht zur Benutzung freigegeben– wird in den kommenden Wochen in Averest integriert– Beweisbeispiel mit Isabelle/HOL



Isabelle/HOL– “generischer” Beweisassistent– University of Cambridge (Larry Paulson)– Technische Universitat Munchen (Tobias Nipkow)– Universite Paris-Sud (Makarius Wenzel)– open-source (BSD)



Listing 6: rev(rev xs) eq xs

theorem rev_rev [simp]: "rev(rev xs) = xs"apply(induct_tac xs)

output subgoals:1. rev (rev []) = []2. rev (rev list) = list ==> rev (rev (a # list)) = a # list-----------apply(auto)

output subgoals:1. rev (rev list) = list ==> rev (rev (a # list)) = a # list

Listing 7: rev(xs @ ys) eq (rev ys) @ (rev xs)

lemma rev_app [simp]: "rev(xs @ ys) = (rev ys) @ (rev xs)"apply(induct_tac xs)apply(auto)

output subgoals:1. rev ys = rev ys @ []



Listing 8: xs @ () eq xs

lemma app_Nil2 [simp]: "xs @ [] = xs"apply(induct_tac xs)apply(auto)

output subgoals:No subgoals!

Listing 9: rev(xs @ ys) eq (rev ys) @ (rev xs)

rev_app [simp]: "rev(xs @ ys) = (rev ys) @ (rev xs)"apply(induct_tac xs)apply(auto)

output subgoals:rev (list @ ys) = rev ys @ rev list

==> (rev ys @ rev list) @ (a # []) = rev ys @ (rev list @ (a # []))



Listing 10: (xs @ ys) @ zs eq xs @ (ys @ zs)

lemma app_assoc [simp]: "(xs @ ys) @ zs = xs @ (ys @ zs)"apply(induct_tac xs)apply(auto)done

Jetzt kann das erste Lemma bewiesen werden.

Listing 11: Lemma1

lemma rev_app [simp]: "rev(xs @ ys) = (rev ys) @ (rev xs)"apply(induct_tac xs)apply(auto)done



Jetzt kann das Haupttheorem bewiesen werden.

Listing 12: Haupttheorem

theorem rev_rev [simp]: "rev(rev xs) = xs"apply(induct_tac xs)apply(auto)done



Listing 13: Gesamtuberblick

lemma app_Nil2 [simp]: "xs @ [] = xs"apply(induct_tac xs)apply(auto)done

lemma app_assoc [simp]: "(xs @ ys) @ zs = xs @ (ys @ zs)"apply(induct_tac xs)apply(auto)done

lemma rev_app [simp]: "rev(xs @ ys) = (rev ys) @ (rev xs)"apply(induct_tac xs)apply(auto)done

theorem rev_rev [simp]: "rev(rev xs) = xs"apply(induct_tac xs)apply(auto)doneend


Zusammenfassung

Zusammenfassung


Zusammenfassung

Zusammenfassung– herkommliche Modelchecking-Verfahren haben das Problem der

Zustands-Explosion– interaktive Theorembeweiser umgehen dieses Problem durch Aufteilung der

Beweise– AIFProver ist Bestandteil von Averest und kann auf die existierenden

Datenstrukturen zugreifen– synchrone bedingte Aktionen liefern bessere Beweisziele– labels auf den Quellcode (Quartz)⇒ bessere Lesbarkeit fur Menschen und Navigation zwischen sync. bed.Aktionen und Quellcode


AbschlussTM

Vielen Dank fur Ihre Aufmerksamkeit.Fragen?


AbschlussTM

M. Gellner, “Der umgang mit dem hoare-kalkul zur programmverifikation,” June2006.

F. T. Wiena, “Model checking - a short informal introduction,”http://embsys.technikum-wien.at/projects/decs/verification/formalmethods.html,letzter Zugriff: 15.07.2013.

L. Biermann, “Ctl/ltl se systemanalyse,”http://www2.informatik.hu-berlin.de/top/lehre/WS06-07/se se/folien/ctl ltl.pdf,13.11.2006.

“Computation tree logic,” letzter Zugriff: 18.07.2013. [Online]. Available:http://en.wikipedia.org/wiki/Linear temporal logic

“Linear temporal logic,” letzter Zugriff: 18.07.2013. [Online]. Available:http://upload.wikimedia.org/wikipedia/de/thumb/2/2c/Computational Tree Logic Example.png/635px-Computational Tree Logic Example.png

Translating concurrent action oriented specifications to synchronous guardedactions, 2010.

Averest, “Averest,” http://www.averest.org, letzter Zugriff: 03.07.2013.


http://en.wikipedia.org/wiki/Linear_temporal_logic

http://upload.wikimedia.org/wikipedia/de/thumb/2/2c/Computational_Tree_Logic_Example.png/635px-Computational_Tree_Logic_Example.png



AbschlussTM

K. Schneider and T. Schuele, “Averest: Specification, verification, andimplementation of reactive systems,” in Application of Concurrency to SystemDesign (ACSD), J. Desel and Y. Watanabe, Eds. Saint-Malo, France:Participant’s proceedings, 2005.

M. Gesell and K. Schneider, “Interactive verification of synchronous systems,” inFormal Methods and Models for Codesign (MEMOCODE), S. Shukla, L. Carloni,D. Kroening, and J. Brandt, Eds. Arlington, Virginia, USA: ACM, 2012, pp. 75–84.

——, “An interactive verification tool for synchronous/reactive systems,” inMethoden und Beschreibungssprachen zur Modellierung und Verifikation vonSchaltungen und Systemen (MBMV), C. Haubelt and D. Timmermann, Eds.Warnemunde, Germany: University of Rostock, 2013, pp. 267–277.


prasentation der seminararbeit¨ · prasentation der seminararbeit¨ interaktive veriﬁkation von...

Documents