Realzeitautomaten und Modelchecking Eine Einführung in das ...

Realzeitautomaten und Modelchecking
Eine Einführung in das ModelcheckingTool Uppaal
Vortrag im Rahmen der PG KautS, Seminarphase
von Stephanie Kemper
16. Dezember 2002
1 Motivation
Bei “normalen” endlichen Automaten hängt die Ausgabe/Reaktion des Systems nur von
der Reihenfolge der Eingabesignale ab. Was aber ist mit Systemen, bei denen nicht nur
die Reihenfolge, sondern auch, bezogen auf den Start des Systems, der konkrete Zeitpunkt
des Auftretens oder der zeitliche Abstand interessant sind?
Man stelle sich beispielsweise einen “Intelligenten Lichtschalter” vor [3]: Wird er zweimal
innerhalb kurzer Zeit gedrückt, so soll das Licht heller werden, andernfalls soll es
ausgehen (Abbildung 1). Modelliert werden kann dieses Verhalten durch hinzufügen einer
Uhr X (Abbildung 2): X misst die Zeit, die zwischen dem wiederholten Drücken vergeht.
Abhängig von dem Wert, den X zum Zeitpunkt des Drückens hat, wird der Zustand
gewechselt (von ‘Licht an’ nach ‘Heller’ oder ‘Aus’).
★
press?
✥
★✥
❄ ★✥ ★✥
press? press?
✲ Off ✲ Light ✲ Bright
✧✦ ✧✦ ✧✦
✧ ✻ press?
✦
Abbildung 1: Intelligenter Lichtschalter
★
press?
✥
★✥
❄ ★✥ ★✥
press? press?
✲ Off ✲ Light ✲ Bright
✧✦
X := 0 X ≤ 3
✧✦ ✧✦
✧ ✻ press?
✦
X > 0
Abbildung 2: Intelligenter Lichtschalter
mit Uhr X
Zur Spezifikation, Simulation und Verifikation solcher Automaten bietet sich das Modellchecking-Tool
Uppaal an, auf das weiter unten noch genauer eingegangen werden soll.
2 Definition
Büchi-Automaten: Ein Büchi-Automat A ist ein 5-Tupel A = (Σ, Q, →, q 0 , F ). Diese Komponenten
sind wie bei Endlichen Automaten definiert mit dem Unterschied, dass Büchi-
Automaten zur Verarbeitung unendlicher Wörter eingesetzt werden. Ein Wort wird dabei
von einem Büchi-Automaten akzeptiert, wenn mindestens ein Endzustand unendlich oft
durchlaufen wird.
Realzeitautomaten (RAen): Ein RA A ist ein 6-Tupel A = (Σ, Q, →, q 0 , F, X) mit
1

• Σ, Q, q 0 , F wie bei Büchi-Automaten
• X ist eine endliche Menge von Uhren. Diese fangen bei Systemstart an zu laufen.
• → ist die Transitionsrelation, →⊆ Q × Σ × Φ(X) × P(X ) × Q. Hierbei ist Φ(X)
die Menge der Zeitbedingungen über X, also anschaulich die Menge der Vergleiche
von Uhren miteinander oder mit rationalen Konstanten, ein Element aus P(X ) zeigt
eine Teilmenge von Uhren an, die beim Schalten auf 0 zurückgesetzt werden.
Realzeitautomaten basieren auf der Vorstellung [1], dass das Schalten einer Transition
keine Zeit kostet und Zeit nur verstreicht, während der Automat in einem seiner Zustände
verharrt.
RAen verarbeiten Realzeitwörter:
Ein Realzeitwort ist ein Paar (σ, τ) bestehend aus einem unendlichen Wort σ ∈ Σ ω und
einer Realzeitfolge τ, das heisst einer monotonen Folge von Zeitpunkten. Anschaulich wird
also jedem Eingabezeichen der Zeitpunkt, zu dem es auftritt, zugeordnet.
Beispiel für einen RA: Abbildung 3. Der Automat kann beliebig lange im Zustand q 0
bleiben. Mit jeder a-Transition wird die Uhr X auf 0 gesetzt und der Automat geht in
Zustand q 1 über. Die b-Transition muss nun spätestens zwei Zeiteinheiten später erfolgen.
Der RA akzeptiert die Sprache L = {(σ, τ) | σ ∈ L((ab) ω ) ∧ ∀i ≥ 1 : τ 2i ≤ τ 2i−1 + 2}
a
★
X := 0
★✥
❄
✥
★✥
✤✜
✲ q 0
✧✦
✲ q 1
✧✦
✣✢
✧ ✻ b
✦
X ≤ 2
Abbildung 3: Beispiel für einen RA
3 Temporale Logik
Zur Spezifikation von Anforderungen an das System wird in Uppaal eine “abgespeckte
Form” der Temporalen Logik CT L (computation tree logic) verwendet. In CT L (und
somit auch in Uppaal) werden mögliche Läufe/Pfade durch den RA betrachtet.
Es werden zwei der vier temporallogischen CLT -Operatoren verwendet: ✷ (globally)
und ✸ (eventually). Diese können nicht alleine verwendet werden, sondern müssen stets
mit A ( ̂=∀) oder E ( ̂=∃) quantifiziert werden. Dabei bedeuten die Operatoren:
• ✷: Auf den betrachteten Pfaden gilt immer (in jedem Zustand) die Bedingung
• ✸: Auf den betrachteten Pfaden gilt irgendwann (in einem erreichbaren Zustand)
die Bedingung
Zur genaueren Syntax siehe Uppaal-Hilfe.
2

4 Uppaal
Uppaal wurde 1995 entwickelt an den Universitäten Uppsala (Schweden) und Aalborg
(Dänemark). Uppaal ist ein Tool zur Modellierung, Simulation und Verifikation von Realzeitsystemen.
Realzeitsysteme werden in Uppaal durch parallele, miteinander kommunizierende
Realzeitautomaten modelliert. Bezüglich der Syntax aller Spezifikationen, Wertübergaben
und ähnlichem stellt Uppaal eine umfangreiche Hilfe zur Verfügung.
4.1 Der Editor
Die Modellierung eines Realzeitsystems in Uppaal kann vom Vorgehen her in etwa verglichen
werden mit der Programmierung einer main-Methode einer OO-Programmiersprache.
Diese Analogie soll hier zum besseren Verständnis verwendet werden.
Grundbausteine in Uppaal sind die sogenannten “Templates”. Templates stellen dabei
(in der Regel) noch nicht die Automaten dar, wie sie später im System erscheinen; sie
sind vielmehr “Bauvorschriften”, vergleichbar mit den Klassen einer OO-Sprache.
Jedes Template benutzt eine Anzahl Parameter, diese werden, analog zu Konstanten/Variablen
einer Klasse, unter “Lokal Declarations” definiert und eventuell gleich initialisiert.
Parameter in Uppaal können neben Integerkonstanten und -variablen auch Uhren,
Kanäle und Integerarrays sein. Darüber hinaus (und hier passt die Analogie leider
nicht) kann es Parameter geben, die von mehreren Templates gemeinsam benutzt werden,
insbesondere Kanäle zur Synchronisation. Diese werden unter “Global Declarations” definiert
und müssen dem Template unter “Parameters” übergeben werden. An dieser Stelle
wird nur Name und Typ des Parameters übergeben, die Wertzuweisung erfolgt an anderer
Stelle.
Unter “Process assignments” werden die definierten Templates nun initialisiert, ähnlich
wie Objekte. Eine Instanz eines Templates nennt sich Prozess. Natürlich müssen auch die
zuvor definierten Parameter mit initialisiert werden, so dies nicht schon vorher geschehen
ist.
Nachdem alle benötigten Prozesse erzeugt werden, wird aus den Prozessen unter “System
definition” ein (Realzeit-)System, bestehend aus den verschiedenen Prozessen, definiert.
Dies ist vergleichbar mit der main-Methode, in der verschiedene Objekte vorkommen.
4.1.1 Detaillierte Spezifikation von Stellen und Transitionen
Durch Doppelklick auf eine Stelle öffnet sich eine Eingabemaske. Hier besteht die Möglichkeit,
die Stelle als Startstelle (‘initial’) zu definieren, ihr einen Namen zu geben - um sie
später im Verifier referenzieren zu können - und eine Invariante für diese Stelle zu definieren.
Zur Erklärung der Eigenschaften ‘commited’ und ‘urgent’ siehe [4].
Durch Doppelklick auf eine Transition öffnet sich ebenfalls eine Eingabemaske. Hier
können folgende Dinge spezifiziert werden: Die Transition kann einen ‘guard’ zugeordnet
bekommen, das heisst eine Bedingung über Variablen und/oder Uhren, unter der sie
nur schalten darf. Unter dem Punkt ‘assign’ werden Uhren angegeben, die beim Schalten
der Transition zurückgesetzt werden, gemeinsam mit dem Wert, auf den sie gesetzt
werden. Unter ‘sync’ werden ein oder mehrere Kanalnamen angegeben, diese dienen zur
Synchronisation (s. u.).
3

4.1.2 Synchronisation über Kanäle
Synchronisation zwischen den einzelnen Templates kann mit Hilfe der definierten Kanäle
stattfinden. Die Synchronisation verläuft nach dem “Handshaking”-Prinzip: Ein Template
gibt mittels < kanalname >! (zu definieren unter ‘sync’, s. o.) einen Impuls auf den Kanal,
ein weiteres nimmt diesen mittels < kanalname >? entgegen. Die beiden Transitionen
können nur gleichzeitig schalten. Zur Synchronisation mehrerer Templates siehe [4].
4.2 Der Simulator
Ist das definierte Realzeitsystem syntaktisch korrekt, kann im Simulator das Verhalten
des Systems “per Hand” ausprobiert werden. Sonst kann nicht in den Simulator oder
Verifier gewechselt werden, ausserdem gibt Uppaal Hinweise, wo der Fehler möglicherweise
zu finden ist. Da der Simulator intuitiv verständlich ist, soll hier nicht weiter darauf
eingegangen werden.
4.3 Der Verifier
Auch der Verifier ist eigentlich selbsterklärend. Anforderungen an das System (Queries)
können mittels der gegebenen Syntax (Uppaal-Hilfe) spezifiziert und anschliessend überprüft
werden.
Erwähnenswert ist an dieser Stelle lediglich die Funktion “Diagnostic Trace” (unter
“Options”): Ist diese Funktion aktiviert, so erstellt Uppaal zur gerade überprüften Anforderung
einen Lauf durch das System, auf dem diese Anforderung gilt bzw. verletzt
wird. Nützlich ist dies insbesondere bei der Fehleranalyse, wenn zum Beispiel gewünschte
Anforderungen nicht erfüllt werden.
Literatur
[1] E.-R. Olderog, M. Schenke und H. Dierks, Skript zur VL Realzeitsysteme, Universität
Oldenburg, März 2001
[2] R. Alur, D. Dill: A Theory of Timed Automata, TCS 126:183-235, 1994
[3] K. G. Larsen, Tutorial: Advances in Real-Time Model Checking, FTRTFT-Tagung
2002 in Oldenburg,
[4] A. David, T. Amnell, Uppaal2k: Small Tutorial, Tutorial zur aktuellen Uppaal-
Version, http://www.uppaal.com, 16. Oktober 2002
4