3.2 Spezifikationen mit Zeit

Transkript

1 32 Spezifikationen mit Zeit typische Anforderungen mit Zeitbezug Einführung von Uhren Semantik von Uhren Datentypen Deadlocks durch Zeitbedingungen Urgent und Committed 178

2 Spezifikation mit Zeit Zeit spielt bei verteilten und eingebetteten Systemen häufig eine wichtige Rolle für die Korrektheit, es sollen Fragen beantwortet werden, wie läuft das Protokoll, wenn man Verzögerungen durch Laufzeiten berücksichtigt? welche neuen Situationen entstehen, wenn man die Dauer einer Aktion berücksichtigt? welche minimalen Reaktionszeiten kann man erhoffen? welche maximalen Reaktionszeiten sind zu befürchten? wann kann ein Zustand erreicht werden? Diese Fragen können neben den schon bekannten Fragen eine wichtige Rolle spielen 179

3 Timed Automata (zeitbehaftete Automaten) Idee: Parallelkomposition von Automaten, die um spezielle Variablen für Zeit (sogenannte Uhren) erweitert werden nur in Zuständen kann Zeit vergehen Zustände können abhängig von Zeitbedingungen verlassen werden (Zustände besser als Locations, Lokationen, Aufenthaltsbereiche bezeichnen) Anforderungen können in einer temporalen Logik TCTL (Timed Computation Tree Logic) formuliert werden; dazu existiert Modelchecking-Ansatz Realisiert im Werkzeug Uppaal, entwickelt in Uppsala (Schweden) und Aalborg (Dänemark) clock x; Invariante fordert, dass z1 nach höchstens 5 Einheiten verlassen wird Bedingung der Transition fordert, dass mindestens 2 Einheiten vergangen sind z1 x<=5 x>=2 180

4 Invarianten in Zuständen Zustandsinvarianten geben Regeln für die Zustände an x<=2: Der Zustand muss spätestens dann verlassen werden, wenn die Uhr x mehr als zwei Zeiteinheiten (2 E) hat Uhren laufen kontinuierlich weiter, x:=0 ist möglich (Reset) Invarianten haben die Form <clock> op <Ausdruck> mit op {<,<=,=}, Ausdruck darf Uhren, Integer-Variablen und Konstanten enthalten, keine oder-verknüpfung von Uhren Auf den Transitionen wird keine Zeit verbraucht Automat verlässt nach maximal 2 E start, da Uhr weiterläuft, und versucht nach maximal 3E wieder nach start zurück zu kehren Theoretisch können Zustände beliebig oft gewechselt werden Läuft die Uhr im Zustand weiter über 2 E hinaus, ist Rückkehr nach start nicht mehr möglich, da Invariante verletzt würde (Deadlock) 181

5 Transitionswächter (Guard) Wächter ist Boolesche Bedingung, kann Uhren, Integer-Variablen und Konstanten enthalten Uhren und Differenzen zwischen Uhren werden nur mit Integer-Ausdrücken verglichen Uhren-Bedingungen können nur mit Konjunktionen verknüpft werden Ausgangstransition von start kann nach einer Zeiteinheit verlassen werden, es folgt: start wird im Intervall (1,2] verlassen ( ( offen, [ geschlossen) weiter kann erst nach 2 E verlassen werden; dies verstößt gegen Invariante von start, d h deadlock (bzw nicht wohldefinierter Zustand) x>2 start weiter x<=2 x>1 x<=3 182

6 Zuweisungen, Nichtdeterminismus, Variablen clock x; clock y; int [0,5] zwei:=0; int [0,5] drei:=0; x:=0 start x<=4 x>2 && zwei<5 zwei:=zwei+1 x>3 && drei<5 drei:=drei+1 weiter nach 3 E kann nichtdeterministisch eine ausgehende Kante gewählt werden Integer-Variablen erlaubt, können in Wächtern gelesen und bei Transitionsnutzung verändert werden Uhren können zurückgesetzt werden System kann jede von start ausgehende Transition 5-mal nutzen Uhr y zur Beobachtung; Analysefrage: Welchen Wert nimmt y minimal bis Deadlock (genauer: Inkonsistenz in start) an? 183

7 Visualisierung als Zeitdiagramm start x<=4 x:=0 x>2 && zwei<5 zwei:=zwei+1 x>3 && drei<5 drei:=drei+1 zwei drei weiter start weiter x Gesamtzeit y Zeit 184

8 Variablenarten Definition von Konstanten: const <Typ> <name> = <wert>; Variable im Wertebereich min bis max int[<min>,<max>] <Variablenname>; ohne min max [ bis 32767] Boolesche Variablen: bool <Variablenname>; Definition von Uhren: clock <Uhrenname>; Kanal, über den synchron (Paar Sender, Empfänger) kommuniziert wird: chan <Kanalname>; ein Sender kann mit beliebig vielen Empfängern synchronisiert werden (auch null): broadcast chan <Kanalname>; Kanal wird für unmittelbare Kommunikation ohne Zeitverbrauch genutzt, Transition darf keinen Zeitwächter haben urgent <Kanaldeklaration wie vorher>; Felddeklarationen für alle Typen, zb clock x[4]; Initialisierungen sind bei Integer-Variablen möglich, zb int i:=3; int[2,5] j[3]:={2,3,4}; 185

9 Doppelklick clock x; int[0,2] modus:=0; start chan klick; modus:=1 klick? x:=0 einfach x<=3 klick? modus:=2 In modus wird Auswahlart codiert (=1 einfach, =2 doppelt) doppelt doppelt ist committed Zustand; d h in diesem Zustand darf keine Zeit verbracht werden, er wird sofort verlassen (für einen Automaten entspricht dies atomarem Schritt, Ausnahme wenn mehrere Automaten interleavt committed Zustände durchlaufen) 186

10 Zustand Committed Zustand mit C markiert Committed : Zustand muss so schnell wie möglich, d h ohne Zeit zu verbrauchen, verlassen werden sinnvoll, wen man mehrere Zustände nutzt um Berechnungen durchzuführen, damit diese ohne Zeit ablaufen Alternativen mit Uhren, in denen man warten müsste, werden nie ausgeführt Vorheriges Beispiel: modus-variable soll sofort Wert annehmen (Variante: modus auf vorheriger Kante setzen) 187

11 Deadlocks durch Zeit clock x; wegen Zeitbedingung nicht ausführbare Transition wegen Zeitbedingung nicht betretbarer Zustand 188

12 Zustand Urgent Die Markierung mit U ist verwandt mit Committed wieder Ziel, Zustand schnellstmöglich zu verlassen etwas weicher als Committed Committed: Zustand muss im nächsten Schritt verlassen werden (genauer: solange es bei Ausführung mit committed markierte, erreichte Zustände gibt, müssen diese verlassen werden Urgent: es darf auch auf keinen Fall Zeit verbraucht werden, aber andere, nicht Zeit verbrauchende, Schritte sind erlaubt 189

13 Urgent- und Committed-Zustände (a) Deadlock mit Committed (und Urgent) c! x>=2 c? (b) Urgent: c und d ausführbar c! c? d! d? (c) Committed: nur c ausführbar c! c? d! d? 190

14 Zusammenfassung typischer Zeitnutzungen z Der Zustand z wird nach weniger als 3 E verlassen z Der Zustand z kann zwischen 3 und 5 E verlassen werden, Zustand muss aber nicht verlassen werden z Der Zustand z wird garantiert zwischen 3 und 5 E verlassen 191

15 33 Nutzung von Uppaal Beispiel: Weiterleitungsmodul Eingabe von Timed Automata Nutzung des Simulators 192

16 Weiterleitung (1/7) Zu untersuchen ist die Verzögerung, die durch ein Weiterleitungsmodul TM (transmission module) entstehen kann Das Modul übernimmt eine Nachricht, liefert diese weiter, wartet auf eine Bestätigung und leitet dann diese weiter Uppaal erlaubt die Erzeugung von Systemen durch so genannte Templates (einzelne Prozesse als Timed Automata), dabei können Parameter an eine Spezifikation übergeben werden Dies wird im folgenden zusammen mit der Nutzung von Uppaal erklärt Sender (Send) Trans1 (TM) Trans2 (TM) Trans3 (TM) Empfaenger (Emp) 193

17 Weiterleitung (2/7) Zustandseingabe Transitionseingabe Kanteneckpunkte (Nails) Prozessparameter (Templateparameter) Prozessname 194

18 Weiterleitung (3/7) System Editor zur Eingabe Declarations : Eingabefenster für lokale Variablen Syntaxprüfung mit F7 (oder File->Check Syntax), Ergebnis wird unten angezeigt (von Hand vergrößern) 195

19 Weiterleitung (4/7) Empfängerprozess Emp Doppelklick auf Zustand ermöglicht Eingabe von Invarianten und Zustandsart 196

20 Weiterleitung (5/7) Spezifikation von TM Durch Doppelklick auf eine Kante können deren Eigenschaften parametrisiert, Wächter, Kommunikation und veränderte Variablen angegeben werden 197

21 Weiterleitung (6/7) 198

22 Weiterleitung (7/7) Hier müssen globale Variablen stehen, direkte Angaben wie 2 als Parameter sind nicht möglich 199

23 Überblick Simulator (1/7) Ausführbare Aktionen bisher ausgeführte Aktionen aktuelle Variabenwerte (mit Uhren) Prozesse in ihren aktuellen Zuständen Simulationssteuerung ausgeführte Aktionen als Message Sequence Chart 200

24 Überblick Simulator (2/7) mögliche Transition anwählen (hier nur eine möglich) dann Next drücken Neuanfang mit Reset (gewählte Transition hat Einfluss auf andere Fenster) 201

25 Überblick Simulator (3/7) zuletzt ausgeführte Aktionen (auswählbar) in der Form (Zustände) (Transition) (Auswahl hat Einfluss auf andere Fenster) 202

26 Überblick Simulator (4/7) Simulationssteuerung: Simulationen können geladen, gespeichert und wiederholt werden Bei Random läuft die Simulation automatisch ab, dazu kann die Geschwindigkeit eingestellt werden (Ist Togglebutton, bleibt also gedrückt) 203

27 Überblick Simulator (5/7) Anzeige der Werte aller Variablen und Uhren, für die Uhren und die angewählte Aktion werden die Intervalle der Uhren angezeigt 204

28 Überblick Simulator (6/7) Prozessnamen aktuelle Zustände Kommunikationen (immer synchron) 205

29 Überblick Simulator (7/7) Prozesse 206

30 34 Timed Computation Tree Logic und Verifikation Syntax und Semantik von Timed Computation Tree Logic (TCTL) typische Anforderungen in TCTL Fairnessuntersuchung in Timed Automata Nutzung der Verifikationskomponente in Uppaal Interpretation von Verifikationsergebnissen 207

31 Ansatz von CTL LTL betrachtet alle möglichen Ausführungssequenzen CTL (Computation Tree Logic) betrachtet alle möglichen Folgezustände und macht Aussagen, was in diesen Folgezuständen gilt Ausgangszustand alle möglichen Folgezustände wieder unendliche Abläufe betrachtet Es gibt Anforderungen, die man in LTL und nicht in CTL und Anforderungen, die man in CTL und nicht in LTL ausdrücken kann 208

32 Syntax von TCTL in Uppaal Einfache Prädikate der Form <Integer-Ausdruck> <op> <Integer-Ausdruck> <Uhr-Variable> <op> <Integer-Ausdruck> In <Integer-Ausdruck> können außer Uhren beliebige Variablen vorkommen Sind p und q Prädikate, dann auch p and q, p or q, not p, p imply q, (p) (Logik wird ausgeschrieben, oder &&, sowie! ) A p (all pathes always, immer ) A p (all pathes sometimes, immer irgendwann ) E p (exists a path always, für einen Weg immer ) E p (exists a path sometimes, kann garantiert irgendwo ) p q (p leads to q, wenn p dann irgendwann q ) Spezielle Formel: deadlock; erfüllt, wenn kein Prozess weiter kann man beachte: Keine Schachtelungen erlaubt E A p (wäre in CTL möglich, erhöht aber Modelcheck-Aufwand drastisch) A: für alle Pfade E: es gibt einen Pfad 209

33 Veranschaulichung der Formeln (1/3) A p A[] p : genau hier gilt p E p E[] p Anmerkung: Knoten müssen nicht immer zwei Blätter haben 210

34 Veranschaulichung der Formeln (2/3) A p A<> p E p E<> p 211

35 Veranschaulichung der Formeln (3/3) q Rechenregeln: A p A p p q p q q q E p E p p q p leads to q p --> q (nicht mit unserer eingeschränkten Version von CTL, aber im normalen CTL formulierbar) p q A (p imply (A q)) 212

36 Typische Formeln Sicherheit: A[] p (Invariante) Sicherheit: E[] p (Es gibt einen sicheren Pfad) Lebendigkeit: A<> p (Zustand muss erreicht werden) Lebendigkeit: p --> q (p führt irgendwann zu q) Erreichbarkeit = Mix aus Sicherheit und Lebendigkeit: E<> p (p kann irgendwann eintreten) Anmerkung: In Uppaal nie Leerzeichen zwischen A (E) und [] (<> <>) 213

37 Analyse von Fairness in Uppaal Automat Fairness int i:=0; 214

38 Nutzung der Verifikationskomponente (1/2) Ansicht der Formeln (keine Änderung) Formeln werden durch Anklicken selektiert (mehrere mit gedrückter Hochstelltaste) Modelchecking starten, unten wird Ergebnis angezeigt Formelverwaltung Eingabe von Formeln informeller Kommentar 215

39 Nutzung der Verifikationskomponente (2/2) Achtung! Formeln (Queries) können getrennt gespeichert und geladen werden Weitere Einstellungen werden hier nicht im Detail betrachtet Um Trace zum Fehler (A) oder Erfolg (E) zu bekommen, muss eine Diagnostic Trace gewählt werden 216

40 Analyse des Verifikationsverhaltens (1/3) Automat P int i:=0; clock x; Es wird immer s3 durchlaufen A<> Ps3 Es wird Gegenbeispiel erzeugt, das schrittweise mit Next im Simulator durchlaufen werden kann 217

41 Analyse des Verifikationsverhaltens (2/3) Achtung, Ausgaben hängen von Verifikationseinstellungen (Options) ab, hier: - Breadth First - State Space Reduction: none - State Diagnostic Representation: DBM - Diagnostic Trace: shortest 218

42 Analyse des Verifikationsverhaltens (3/3) i hat nie den Wert 42 A[] Pi!=42 (erzeugt Trace mit Gegenbeispiel) i hat irgendwann den Wert 5 E<> Pi==5 (Verifikation scheitert, kein Gegenbeispiel [!?]) möglich, dass i nie einen Wert größer-gleich 7 annehmen wird E[] Pi<7 (Verifikation scheitert, kein Gegenbeispiel) Anmerkung: Ohne Uhren ist Beweis erfolgreich [!]) Möglich, dass i nie einen Wert größer 8 annimmt E[] Pi<8 (Verifikation erfolgreich, Trace wird konstruiert mit Deadlock in s3) 219

43 35 Beispiele Timeout Systemstart Modellierung von Arbeitsabläufen Verifikation deterministischer Programme (sortieren) Telefonsystem 220

44 Timeout (1/2) Reaktive Systeme haben oft einen Timer, der Aktionen abbrechen kann oder Alarm auslöst; dies kann auch in Uppaal spezifiziert werden chan reset; chan abort; Automat Timer const int grenze:=10; clock timer; clock x; timer<grenze abbruch start reset? timer:=0 timer==grenze abort! x<4 s0 abort? x:=0 s1 abort? x<5 s3 reset! x:=0 x:=0 abort? x<6 s2 221

45 Timeout (2/2) const int grenze:=10; chan reset; clock timer; chan abort; timer<grenze abbruch start reset? timer:=0 timer==grenze abort! s0 clock x; reset! s1 x<5 x<4 x:=0 x:=0 abort? abort? x:=0 abort? x<6 s2 Ist es möglich, dass nie ein Abbruch passiert? (ja) E[]!Timerabbruch Ist es garantiert, dass kein Abbruch passiert? (nein) A[]!Timerabbruch s3 222

46 Systemstart und Invarianten Häufig sollen Invarianten erst gelten, wenn eine Initialisierung durchlaufen wurde Ansatz: Definiere Boolesche Variable ok:=false, die nach der Initialisierung auf true gesetzt wird und den Wert behält Beispiel: Nach Initialisierung liegt der Wert von i immer zwischen 10 und 20 Automat P int[0,30] i:=0; bool ok:=false; Folgende Anforderung ist erfüllt: A[] Pok imply (Pi>10 && Pi<20) 223

47 Modellierung von Arbeitsabläufen (1/2) Modelle werden nicht nur für HW- und SW-Systeme zur Prüfung genutzt, sie können auch zur Analyse von Geschäftsprozessen dienen; dazu bietet auch Uppaal Möglichkeiten Anmerkung: Natürlich kann man solche Modellierungsansätze auch mit SPIN verfolgen; es gibt kommerzielle Ansätze, um hier mit (linearen) Optimierungen zu arbeiten Spezifikation: Es gibt zwei Möglichkeiten, ein Gesamtergebnis herzustellen, einmal in zwei Teilschritten, die etwas zeitintensiver, aber kostengünstiger sind, der andere Ansatz besteht aus einem Schritt, der kostenintensiver, aber schneller ist 224

48 Modellierung von Arbeitsabläufen (2/2) Automat P clock x; clock y; int i:=0; bool fertig:=false; x misst die Gesamtzeit fertig gesetzt, wenn Arbeit abgeschlossen (alternativ Ps3) i steht für Kosten Gibt es kostengünstigen (i<3) Weg in maximal 7 E (nein) E<> Pfertig && Pi<3 && Px<=7 Gibt es Weg in maximal 7 E (ja) E<> Pfertig && Px<=7 Gibt es kostengünstigen Weg in maximal 8 E (ja) E<> Pfertig && Pi<3 && Px<=8 225

49 Verifikation deterministischer Programme Sortierverfahren, informelle Spezifikation: Laufe mit dem Zähler i von 0 bis zur Arraygröße-1 Laufe mit dem Zähler j von i+1 bis zur Arraygröße falls das j-te Element kleiner als das i-te Element ist, vertausche diese 226

50 Sortierer (1/4) const int N:=5; const int MAX:=3; int[0,max] array[n]; int[0,max] save[n]; int count:=0; int[0,n] count2:=0; int[0,n] j:=0; int[0,max] tmp; int[0,n] anzahl1; int[0,n] anzahl2; 227

51 Sortierer (2/4) mit kleinem Fehler 228

52 Sortierer (3/4) Gleiche Elemente 229

53 Sortierer (4/4) A[]!deadlock Processok (alternativ: A<> Processok) Processarray[0] = 0 Processarray[1] = 0 Processarray[2] = 0 Processarray[3] = 1 Processarray[4] = 0 Processsave[0] = 0 Processsave[1] = 0 Processsave[2] = 0 Processsave[3] = 1 Processsave[4] = 0 Processcount = 3 Processj = 4 Processtmp = 0 Ergebnis nach Ausführung fehlerhafter Trace (Korrekt im Sortieren: j>n-1 und jeweils j<=n-1 && ) alternativ e Formel: A<> Processok 230

54 Beispiel: Telefonsystem (1/8) Informelle Beschreibung: Zu entwickeln ist eine Timed Automata-Spezifikation für ein Telefonsystem mit N Teilnehmern Dabei besteht das System aus den Teilnehmern und dem Vermittlungssystem Zur Kommunikation zwischen den Teilnehmern und dem Vermittlungssystem werden folgende Kommunikationen (Synchronisationen) genutzt Kommunikation dial, x busy connect dialled disconnect Bedeutung Teilnehmer wählt Nummer x Teilnehmer erhält die Information gewählte Nummer besetzt Teilnehmer erhält die Information gewählte Nummer erreicht Teilnehmer erhält die Information, dass er von einem anderen Teilnehmer angerufen wurde Teilnehmer beendet das Gespräch disconnected verbundener Teilnehmer hat Gespräch beendet Vereinfachend wird angenommen, dass ein erfolgreich angerufener Teilnehmer immer das Gespräch annimmt und dass der Telefonhörer unmittelbar mit busy, disconnect und disconnected aufgelegt wird 231

55 Beispiel: Telefonsystem (2/8) Teilnehmer 1 Vermittlungssystem Teilnehmer 2 alternativ kann Teilnehmer 1 auflegen dial,2 connect disconnected dialled disconnect Teilnehmer 1 Vermittlungssystem dial,2 busy 232

56 Beispiel: Telefonsystem (3/8) Anforderungen: Die zentrale funktionale Anforderung ist, dass jeder Teilnehmer immer wieder die Möglichkeit hat, jeden anderen Teilnehmer zu erreichen Weiterhin soll das System folgende Zeitrandbedingungen berücksichtigen: Es werden minimal 3 und maximal 7 Zeiteinheiten benötigt, um festzustellen, dass ein Teilnehmer nicht erreichbar ist Es werden minimal 4 und maximal 10 Zeiteinheiten benötigt, um die Verbindung (dialled) zu einem erreichbaren Teilnehmer aufzubauen Ein Telefonat (zwischen connect und disconnect, bzw dialled und disconnect) dauert minimal 20 und maximal 40 Zeiteinheiten (z B Werbung + echtes Gespräch) Wie lange kann es maximal dauern, bis ein Telefonat(sversuch) beendet wurde? 233

57 Beispiel: Telefonsystem (4/8) Verwaltungsdaten: const int N := 5; // für vier Teilnehmer, mit // Nummern 1,2,3,4 // Teilnehmer 0, bzw Wert 0 für keine Verbindung chan dial[n]; chan connect[n]; chan busy[n]; chan disconnect[n]; chan disconnected[n]; chan dialled[n]; int[0,n] anrufen[n]; // Nummer, die Teilnehmer i // anruft int[0,n] aktiv[n]; // mit wem ist i verbunden? 234

58 Beispiel: Telefonsystem (5/8) Teilnehmer Parameter: int[1,n] ich clock y; clock dauer; 235

59 Beispiel: Telefonsystem (6/8) int[1,n] caller; int[1,n] calling; int[1,n] tmp; clock x; Telefonsystem 236

60 Beispiel: Telefonsystem (7/8) // Komposition unter Nutzung eines // Verbindungsknotens Tel1 = Teilnehmer(1); Tel2 = Teilnehmer(2); Tel3 = Teilnehmer(3); Tel4 = Teilnehmer(4); Verbindung = Telefonsystem() system Tel1, Tel2, Tel3, Tel4, Verbindung; System hat kein Deadlock A[]!deadlock Property is satisfied 237

61 Beispiel: Telefonsystem (8/8) Analyse der maximalen Gesprächsdauer (Grenzen durch try and error) A[] ((!Tel2start) imply Tel2dauer<47) Property is not satisfied A[] ((!Tel2start) imply Tel2dauer<48) Property is satisfied Annäherung an: Jeder kann jeden anrufen E<> (aktiv[1]==2 && aktiv[2]==1) Property is satisfied Prüfung: alle gleichzeitig aktiv E<> (Tel1verbunden && Tel2verbunden && Tel3verbunden && Tel4verbunden) Property is not satisfied Spezifikation zusätzlicher Leitungen (Verbindungsknoten) Verbindung2 = Telefonsystem() system Tel1, Tel2, Tel3, Tel4, Verbindung, Verbindung2; 238

62 Grenzen von Timed Automata Alle Uhren laufen synchron, dh es ist keine Clock- Drift einfach spezifizierbar (Uhren weichen mit der Zeit leicht voneinander ab) Anforderungssprache TCTL nicht sehr mächtig, weniger als CTL oder CTL* (hauptsächlich Performancegründe) Umgang mit Uhren nur sehr eingeschränkt in Bedingungen möglich; keine Zuweisungen an Uhren; keine Nutzung im Zusammenhang mit Variablen (Problem: Logik wird sonst schnell unentscheidbar) 239