3.1 Synchron kommunizierende Automaten. 3. Modelchecking mit Timed Automata und Uppaal

Transkript

1 3 Modelchecking mit Timed Automata und Uppaal 31 Synchron kommunizierende Automaten 31 Synchron kommunizierende Automaten 32 Spezifikationen mit Zeit 33 Nutzung von Uppaal 34 Timed Computation Tree Logic und Verifikation 35 Beispiele Automaten mit Kommunikationen bedingte Transitionen parametrisierte Transitionen parametrisierte Automaten Zustandsinvarianten Graphische Spezifikation //global chan a; chan b; chan c; Automaten mit lokalen Variablen Jeder Automat kann zusätzlich lokale Variablen haben, die auf Transitionen geändert werden können weiterhin können Funktionen zur Änderung spezifiziert werden Parameter: int x (Call by Value) int& x (Call by Reference) Template A c? a! Template A b! a? c! b? Template B Template C // lokale Variablen int x:=0; void sub (int int& v){ v:=v-1; } c? sub(x) a! x:=x+1 system A,B,C;

2 Transitionen mit Bedingungen //global chan c,d,e,q; //system system A,B; // A local int[0,255] v:=0; Template A v%2==1 q? d! c! e! v:=(v+1)%256 Template B 174 q! d? v%2==0 v:=v+1 e? q! c? v%4==0 v:=v+1 Parametrisierte Transition und Automaten //global Template V const int N=4; chan c[n]; chan d[n]; bool gesendet[n]; i: int[0,n-1] i:int[0,n-1]!gesendet[i] // template instantiations d[i]? c[i]! E0 = Emp(0); E1 = Emp(1); check() sum:=sum+i, E2 = Emp(2); gesendet[i]:=true E3 = Emp(3); // processes composed to system system V,E0,E1,E2,E3; Template Emp // local V int sum:=0; Parameter: int name void check(){ bool allegesendet:=true; for(i: int[0,n-1]) allegesendet:=allegesendet && gesendet[i]; c[name]? d[name]! if(allegesendet) for(i: int[0,n-1]) gesendet[i]:=false; } 175 Variante: Visualisierter Ablauf // local V int sum:=0; int[0,n] tmp; bool allegesendet; tmp<n gesendet[tmp]:=false, tmp:=tmp+1 tmp==n && allegesendet tmp:=0 tmp<n allegesendet:= allegesendet && gesendet[tmp], tmp:=tmp+1 Statt C-artige Funktionen zu nutzen, kann Ablauf visualisiert werden Vorteil: bessere Debug-Möglichkeit Nachteil: wesentlich mehr Zustände auch in der Verifikation tmp==n tmp==n &&!allegesendet i: int[0,n-1] d[i]? tmp:=0, allegesendet:=true i: int[0,n-1]!gesendet[i] c[i]! sum:=sum+i, gesendet[i]:=true Kommunikation mit Werten Da Kanäle keine Parameterlisten haben, müssen diese mit globalen Variablen simuliert werden Übertragen der Werte von 1 bis 10 // global const int max:=10; int[0,max] senden:=0; chan c; //Empfaenger int summe:=0; system Sender, Empfaenger Template Sender senden<max c! senden:=senden+1 Template Empfaenger c? summe:=summe+senden

3 Berücksichtigung von Zustandsinvarianten Zustände können Namen haben Transitionen ausgehend von z1 nur abwechselnd nutzbar In Zuständen stehen Invarianten int x:=0 x:=x+1 z2 z1 x:=x+1 z3 32 Spezifikationen mit Zeit typische Anforderungen mit Zeitbezug Einführung von Uhren Semantik von Uhren Datentypen Deadlocks durch Zeitbedingungen Urgent und Committed x%2==1 x%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 180 Timed Automata (zeitbehaftete Automaten) Idee: Parallelkomposition von Automaten, die um spezielle Variablen für Zeit (sogenannte Uhren) erweitert werden In den 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; z1 x<=5 Invariante fordert, dass z1 nach höchstens 5 Einheiten verlassen wird Bedingung der Transition fordert, dass mindestens 2 Einheiten vergangen sind x>=2 181

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 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 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<= Zuweisungen, Nichtdeterminismus, Variablen Visualisierung als Zeitdiagramm 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 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? 184 weiter zwei drei 0 1 start weiter x Gesamtzeit y Zeit

5 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}; 186 Doppelklick clock x; int[0,2] modus:=0; chan klick; modus:=1 einfach start klick? x:=0 x<=3 klick? modus:=2 doppelt In modus wird Auswahlart codiert (=1 einfach, =2 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) 187 Deadlocks durch Zeit Urgent- und Committed-Zustände clock x; wegen Zeitbedingung nicht ausführbare Transition (a) Deadlock mit Committed (und Urgent) c! x>=2 c? (b) Urgent: c und d ausführbar c! c? d! wegen Zeitbedingung nicht betretbarer Zustand d? (c) Committed: nur c ausführbar c! c? d! d?

6 Zusammenfassung typischer Zeitnutzungen 33 Nutzung von Uppaal z z Der Zustand z wird nach weniger als 3 E verlassen Der Zustand z kann zwischen 3 und 5 E verlassen werden, Zustand muss aber nicht verlassen werden Beispiel: Weiterleitungsmodul Eingabe von Timed Automata Nutzung des Simulators z Der Zustand z wird garantiert zwischen 3 und 5 E verlassen 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 Weiterleitung (2/7) Zustandseingabe Transitionseingabe Kanteneckpunkte (Nails) 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) Prozessname Prozessparameter (Templateparameter)

7 Weiterleitung (3/7) Weiterleitung (4/7) Empfängerprozess Emp Doppelklick auf Zustand ermöglicht Eingabe von Invarianten und Zustandsart 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) Weiterleitung (5/7) Weiterleitung (6/7) Spezifikation von TM Durch Doppelklick auf eine Kante können deren Eigenschaften parametrisiert, Wächter, Kommunikation und veränderte Variablen angegeben werden

8 Weiterleitung (7/7) Überblick Simulator (1/7) Ausführbare Aktionen bisher ausgeführte Aktionen aktuelle Variabenwerte (mit Uhren) Prozesse in ihren aktuellen Zuständen Hier müssen globale Variablen stehen, direkte Angaben wie 2 als Parameter sind nicht möglich Simulationssteuerung ausgeführte Aktionen als Message Sequence Chart Überblick Simulator (2/7) Überblick Simulator (3/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) zuletzt ausgeführte Aktionen (auswählbar) in der Form (Zustände) (Transition) (Auswahl hat Einfluss auf andere Fenster)

9 Überblick Simulator (4/7) Überblick Simulator (5/7) Simulationssteuerung: Simulationen können geladen, gespeichert und wiederholt werden Anzeige der Werte aller Variablen und Uhren, für die Uhren und die angewählte Aktion werden die Intervalle der Uhren angezeigt Bei Random läuft die Simulation automatisch ab, dazu kann die Geschwindigkeit eingestellt werden (Ist Togglebutton, bleibt also gedrückt) Überblick Simulator (6/7) Überblick Simulator (7/7) Prozessnamen aktuelle Zustände Kommunikationen (immer synchron) Prozesse

10 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 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 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 208 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 209

11 Veranschaulichung der Formeln (2/3) Veranschaulichung der Formeln (3/3) A p A<> p E p E<> p 210 q p Rechenregeln: A p A 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)) 211 Typische Formeln Sicherheit: A[] p (Invariante) Sicherheit: E[] p (Es gibt einen sicheren Pfad) Analyse von Fairness in Uppaal Automat Fairness int i:=0; 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 [] (<> <>)

12 Nutzung der Verifikationskomponente (1/2) Ansicht der Formeln (keine Änderung) Formeln werden durch Anklicken selektiert (mehrere mit gedrückter Hochstelltaste) Nutzung der Verifikationskomponente (2/2) Achtung! Formeln (Queries) können getrennt gespeichert und geladen werden Modelchecking starten, unten wird Ergebnis angezeigt Formelverwaltung Eingabe von Formeln informeller Kommentar 214 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 215 Analyse des Verifikationsverhaltens (1/3) Analyse des Verifikationsverhaltens (2/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 Achtung, Ausgaben hängen von Verifikationseinstellungen (Options) ab, hier: - Breadth First - State Space Reduction: none - State Diagnostic Representation: DBM - Diagnostic Trace: shortest

13 Analyse des Verifikationsverhaltens (3/3) 35 Beispiele 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) 218 Timeout Systemstart Modellierung von Arbeitsabläufen Verifikation deterministischer Programme (sortieren) Telefonsystem 219 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? abort? reset! x:=0 220 x:=0 s1 x<5 s3 x:=0 abort? x<6 s2 Timeout (2/2) const int grenze:=10; clock timer; timer<grenze abbruch start reset? timer:=0 timer==grenze abort! chan reset; chan abort; x<4 s0 clock x; abort? abort? reset! x:=0 221 x:=0 s1 x<5 s3 x:=0 abort? Ist es möglich, dass nie ein Abbruch passiert? (ja) E[]!Timerabbruch Ist es garantiert, dass kein Abbruch passiert? (nein) A[]!Timerabbruch x<6 s2

14 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 Folgende Anforderung ist erfüllt: A[] Pok imply (Pi>10 && Pi<20) Automat P int[0,30] i:=0; bool ok:=false; 222 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 223 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 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

15 Sortierer (1/4) Sortierer (2/4) mit kleinem Fehler 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; Sortierer (3/4) Sortierer (4/4) Gleiche Elemente A[]!deadlock 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 (alternativ: A<> Processok) Ergebnis nach Ausführung fehlerhafter Trace (Korrekt im Sortieren: j>n-1 und jeweils j<=n-1 && ) alternativ e Formel: A<> Processok

16 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 disconnected 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 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 230 Beispiel: Telefonsystem (2/8) alternativ kann Teilnehmer 1 auflegen Teilnehmer 1 dial,2 connect disconnected Teilnehmer 1 Vermittlungssystem dial,2 busy dialled disconnect Vermittlungssystem Teilnehmer 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? 232 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? 233

17 Beispiel: Telefonsystem (5/8) Beispiel: Telefonsystem (6/8) Teilnehmer Parameter: int[1,n] ich clock y; clock dauer; int[1,n] caller; int[1,n] calling; int[1,n] tmp; clock x; Telefonsystem 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 236 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; 237

18 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) 238