Model-Checking eines Materialflusssystems mittels UPPAAL und SMV

Fachbereich 17 • Mathematik – Informatik
Arbeitsgruppe Softwaretechnik
Warburger Strasse 100
33098 Paderborn
Model-Checking eines Materialflusssystems
mittels UPPAAL und SMV
Bachelorarbeit
zur Erlangung des Grades
Bachelor of Computer Science“
”
für den integrierten Studiengang Informatik
von
Martin Hirsch
Batenhorstweg 3
59494 Soest
und
Markus Zarbock
Wehler Weg 52
31785 Hameln
vorgelegt bei
Herrn Prof. Dr. Wilhelm Schäfer
und
Frau Prof. Dr. Gitta Domik
Paderborn, den 10. September 2002

Erklärung
Ich versichere, dass ich die namentlich kenntlich gemachten Teile 1 der Arbeit
ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertig
habe und dass die Arbeit in gleicher Form noch keiner anderen Prüfungsbehörde
vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen
wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden,
sind als solche gekennzeichnet.
Paderborn, den 3. August 2004
Martin Hirsch
Ich versichere, dass ich die namentlich kenntlich gemachten Teile 1 der Arbeit
ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertig
habe und dass die Arbeit in gleicher Form noch keiner anderen Prüfungsbehörde
vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen
wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden,
sind als solche gekennzeichnet.
Paderborn, den 3. August 2004
Markus Zarbock
1 Unterkapitel, die nicht mit einem Namen gekennzeichent sind, wurden von dem Autor
erstellt, der im letzten vorherigen Oberkapitel genannt wurde

Zusammenfassung
In dieser Studienarbeit werden zwei verschiedene Model-Checker Werkzeuge,
SMV und Uppaal, vorgestellt. Anhand von ausgewählten Beispielen werden
die wichtigsten Eigenschaften der beiden Werkzeuge in einer kurzen Einführung
herausgestellt.
Die Modellierung des Materialflusssystems zeigt eine praktische Anwendung der
Werkzeuge, die auch die Vor- und Nachteile von Uppaal und SMV noch einmal
verdeutlicht und gleichzeitig Probleme, die in der Modellierungsphase entstehen,
aufzählt.
Abstract
In this paper two different model-checker tools are presented. On the basis
of selected examples the most important characteristics of the two tools are
shown in a short introduction.
The modelling of the material-flow-system shows a practical application of this
tools, which clarifies also the pro and cons of Uppaal and SMV. By this way
problems which occour during the development of the sytem are shown.

Inhaltsverzeichnis
1 Einleitung (Martin Hirsch) 9
1.1 Einführung in die Thematik ”
Model-Checking“ (Martin Hirsch) 9
1.2 Überblick über die folgenden Kapitel (Martin Hirsch) . . . . . . 11
2 Vorstellung von Uppaal und SMV 13
2.1 Uppaal (Martin Hirsch) . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3 Benutzung von Uppaal . . . . . . . . . . . . . . . . . . . 17
2.1.4 Die Verifikationssprache TCTL . . . . . . . . . . . . . . 20
2.2 SMV (Markus Zarbock) . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Entwicklungsgeschichte . . . . . . . . . . . . . . . . . . . 22
2.2.2 Eigenschaften der Modellierungssprache . . . . . . . . . 22
2.2.3 Eigenschaften der Spezifikationen . . . . . . . . . . . . . 28
2.2.4 Verwendung von SMV . . . . . . . . . . . . . . . . . . . 29
3 Fallstudie 31
3.1 Vorstellung (Martin Hirsch) . . . . . . . . . . . . . . . . . . . . 31
3.2 Uppaal (Martin Hirsch) . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 Vorgehensweise zur Modellierung der Fallstudie . . . . . 33
3.2.2 Die Modellierung . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3 Ergebnisse der Verifikation . . . . . . . . . . . . . . . . . 40
3.3 SMV (Markus Zarbock) . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Allgemeine Bemerkungen . . . . . . . . . . . . . . . . . . 46
3.3.2 Das Weichenmodell . . . . . . . . . . . . . . . . . . . . . 47
3.3.3 Der Koordinator . . . . . . . . . . . . . . . . . . . . . . 51
3.3.4 Modelchecking . . . . . . . . . . . . . . . . . . . . . . . 52
7

4 Zusammenfassung 57
4.1 Zusammenfassung SMV (Markus Zarbock) . . . . . . . . . . . . 57
4.2 Zusammenfassung Uppaal (Martin Hirsch) . . . . . . . . . . . . 58
Anhang
A Uppaal Quellcode (Martin Hirsch) 61
A.1 Quellcode: Deklarationen der globalen Variablen, Automaten Instanziierungen
und System Definition . . . . . . . . . . . . . . . 61
A.2 Quellcode: Weiche . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.3 Quellcode: Ventilinsel . . . . . . . . . . . . . . . . . . . . . . . . 63
A.4 Quellcode: Koordinator . . . . . . . . . . . . . . . . . . . . . . . 63
A.5 Quellcode: Switch . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.6 Quellcode: Shuttle . . . . . . . . . . . . . . . . . . . . . . . . . 65
B SMV (Markus Zarbock) 67
B.1 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.2 Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
C CDROM – alle Unterlagen 83
Abbildungsverzeichnis 84
Literaturverzeichnis 85

Kapitel 1
Einleitung (Martin Hirsch)
The bug is always in the case you didn’t test
Murphy’s Law
In vielen technologischen Bereichen ist eine solch pessimistische Einstellung, wie
Murphy sie in seinen Gesetzen beschreibt, durchaus angebracht. If anything
”
can go wrong, it will go wrong “ – dies kann bei Maschinen, die uns in unserem
täglichen Leben begleiten und auf deren Korrektheit wir damit angewiesen
sind, fatale Folgen haben. Neben bekannten Beispielen wie Verkehrsampeln,
Bahnschranken oder Steuerungsanlagen gehen wir auch davon aus, dass unser
Heimcomputer verlässliche Rechenergebnisse liefert. Dass dies nicht immer der
Fall ist, machte der Intel Pentium Bug“ aus dem Jahre 1994 deutlich, bei dem
”
ein millionenfach verkaufter Prozessor für die Aufgabe x−( x )·y mit x = 4195835
y
und y = 3145727 den Wert 256 errechnete, obwohl eigentlich der Wert 0 herauskommt.
Die Tatsache, dass neben der möglichen Gefahr für unsere Gesundheit
auch schwere wirtschaftliche Schäden aus solchen Fehlern entstehen, bewog
immer mehr Hersteller, weniger auf das zeitaufwendige Testen ihrer Produkte
als vielmehr auf einen formalen Beweis der Korrektheit zu vertrauen. Mittels
eines Programms kann eine automatische Verifikation von Anforderungen durchgeführt
werden, was unter dem Begriff Model-Checking“ bekannt wurde.
”
1.1 Einführung in die Thematik ”
Model-Checking“
(Martin Hirsch)
Das Gebiet des Software-Engineering beschäftigt sich mit der Systementwicklung.
Formale Methoden [13] stellen mathematisch fundierte Techniken zur
Spezifikation von Systemen zur Verfügung. Der Einsatz formaler Methoden
erhöht das Verständnis für das zu entwickelnde System. Die formale Spezifikation
von Systemen wirkt sich damit positiv auf die Qualität des entwickelten
Produkts aus. Das Risiko von Spezifikationsfehlern wird reduziert.
9

10 KAPITEL 1. EINLEITUNG (MARTIN HIRSCH)
Jedes entwickelte System wird normalerweise auf seine Funktionen hin überprüft.
Neben manuellen Testverfahren, die vom Entwickler durchgeführt werden müssen,
existieren auch automatische Verifikationstechniken. Der Einsatz formaler Methoden
ermöglicht die Verwendung formaler Verifikationstechniken zur Überprüfung
des entwickelten Systems. In [12] wird ein Überblick über formale Methoden
und formale Verifikationstechniken gegeben. Eine formale Verifikationstechnik
ist das Model-Checking. Diese Technik ermöglicht die Überprüfung
endlicher Zustandssysteme. Der Entwickler spezifiziert das System und legt
gleichzeitig Eigenschaften fest, die das System erfüllen muss. Durch das Model-
Checking wird automatisch überprüft, ob die festgelegten Eigenschaften durch
die Spezifikation erfüllt werden. Zum Überprüfen der Eigenschaften wird der Zustandsübergangsgraph
des Systems betrachtet. Die Einhaltung der Eigenschaften
wird in den Zuständen und den Zustandsübergängen des Systems verifiziert.
Das Model-Checking ist eine Beweistechnik, mit der sich die Einhaltung vorgegebener
Eigenschaften in Systemen zeigen lässt. Bestimmte Fehler innerhalb
der Spezifikation lassen sich durch den Einsatz von Model-Checking entweder
finden, oder es kann ausgeschlossen werden, dass das System den vorgegebenen
Fehler enthält.
Die Technik des Model-Checking wurde unabhängig voneinander durch Clarke
und Emerson in [10] und Quielle und Sifakis in [11] erstmals beschrieben.
Vor allem bei reaktiven Systemen mit sicherheitskritischen Anforderungen bietet
sich der Einsatz von Model-Checking an. Sicherheitsrelevante Eigenschaften
lassen sich durch das Model-Checking Programm überprüfen. Dadurch können
Spezifikationsfehler ausgeschlossen werden, die zu einer Verletzung der sicherheitskritischen
Vorgaben führen. Auf diese Weise lassen sich qualitativ hochwertige
Systeme entwickeln, bei denen beispielsweise Gefahren für Menschenleben
nahezu ausgeschlossen sind.
Für die Verifikation von verteilten Systemen bieten viele Model-Checking Programme
zusätzliche Unterstützungen an. Sie bieten Möglichkeiten zum Finden
von Dead-Locks und Life-Locks. So lassen sich beispielsweise bei der Überprüfung
eines Protokolls Verklemmungssituationen finden, bei denen kein Fortschritt in
der Ausführung des Systems mehr möglich ist.
Die benötigte Rechenzeit und der Speicherbedarf hängen beim Model-Checking
von der Größe des zu überprüfenden Systems ab. Die Zahl der Zustände wächst
mit der Komplexität von Systemen sehr schnell an. Im schlimmsten Fall gehen
Zustände von Teilsystemen als kartesisches Produkt in die Zahl der Zustände des
Gesamtsystems ein. Effiziente Algorithmen werden beim Model-Checking eingesetzt,
um möglichst große Systeme überprüfen zu können. Trotzdem ist eine
Überprüfung herkömmlicher Software-Systeme in den meisten Fällen auf Grund
der Größe des Zustandsraums durch diese Verifikationstechnik nicht möglich.
Ist ein System für die Überprüfung durch die Model-Checking Technik zu groß,
kann durch geeignete Abstraktionen ein entsprechend kleineres System festgelegt
werden. Dieses abstrakte System besitzt weniger Zustände und lässt sich
dann eventuell durch das Model-Checking Programm überprüfen.

1.2. ÜBERBLICK ÜBER DIE FOLGENDEN KAPITEL (MARTIN
HIRSCH) 11
Heute werden hauptsächlich zwei verschiedene Ansätze des Model-Checkings eingesetzt.
Beim symbolischen Model-Checking wird der Zustandsübergangsgraph
als eine Formel in einem Binary Decision Diagram (BDD) abgelegt. Durch symbolische
Operationen wird festgestellt, ob die Formel im BDD die durch den
Benutzer vorgegebenen Eigenschaften erfüllt. Der zweite Ansatz wird mit onthe-fly
Model-Checking bezeichnet. Bei dieser Art des Model-Checking wird
der Zustandsübergangsgraph während der Überprüfung explizit aufgebaut und
durchsucht. Jeder Zustand und jeder Zustandsübergang dieses Graphen wird dabei
auf die Einhaltung der vorgegebenen Eigenschaften überprüft. Um mit der
eventuell großen Anzahl von Systemzuständen zurechtzukommen, werden verschiedene
effiziente Algorithmen für die Durchführung der Suche und die Speicherung
von Zuständen angewendet. Der in der vorliegenden Arbeit vorgestellte
Model-Checker SMV verwendet die Art des symbolischen Model-Checkings.
Das Werkzeug Uppaal dagegen verwendet eine Kombination von symbolischem
Model-Checking und on-the-fly Model-Checking.
1.2 Überblick über die folgenden Kapitel
(Martin Hirsch)
Kapitel 2 gibt eine Einführung in die beiden Model-Checker Werkzeuge UP-
PAAL und SMV und bildet die Grundlage für die folgenden Kapitel.
Kapitel 3 geht auf die untersuchte Fallstudie ein. Ein Materialflusssystem, ein
Ausschnitt aus der ISILEIT 1 -Fallstudie [18, 5] wird in Uppaal und SMV modelliert.
Probleme, die es bei Modellierungen zu beachten gilt, werden anhand
dieses Beipiels aufgeführt. Abschließend werden konkrete Ergebnisse des Verifikationsprozesses
genannt.
Kapitel 4 gibt schließlich einen zusammenfassenden Überblick und zeigt weitere
Perspektiven auf.
Der Anhang beinhaltet den kompletten Quellcode beider Implementierungsvarianten
sowie eine CDROM mit den beiden Werkzeugen Uppaal und SMV.
1 Integrative Spezifikation von Leitsystemen der flexibel automatisierten Fertigung

Kapitel 2
Vorstellung von Uppaal und
SMV
2.1 Uppaal (Martin Hirsch)
Dieses Kapitel gibt eine kurze Einführung in das Model-Checker Werkzeug Uppaal
[17]. Nach einer kurzen Einleitung, die sich mit der Geschichte Uppaals
befasst, erfolgt ein Überblick über die Syntax und Semantik sowie über die Benutzung
des Werkzeugs. Diese Einführung soll kein Handbuch sein, sondern
lediglich die wichtigsten Gesichtspunkte erläutern, die zum späteren Verständnis
der Beispiele notwendig sind. Für eine ausführliche Beschreibung der Syntax
und Semantik wird z. B. auf [17, 3] verwiesen.
2.1.1 Allgemeines
1993 wurde der erste Prototyp des Model-Checkers Uppaal [17], TAB, an der
Universität Uppsala (Schweden) entwickelt. Das Werkzeug TAB ermöglichte es,
einfache Eigenschaften eines Systems, die man leicht durch die Erreichbarkeit
von Zuständen in einem Netzwerk von Timed Automata darstellen kann, wie z.
B. Deadlockfreiheit, zu überprüfen.
Im Jahre 1995 schlossen sich das Department of Computer Systems“ der Universität
Uppsala (Schweden) und das Department of Computer Science and
”
”
Mathematics“ der Universität Aalborg (Dänemark) zusammen und entwickelten
die erste Version von Uppaal (September 1995). Aus den jeweiligen drei
Anfangsbuchstaben der Städte ergibt sich der Name des Werkzeugs.
Uppaal ist ein Werkzeug für die Modellierung, Simulation und Verifikation von
Echtzeitsystemen. Es eignet sich besonders gut für Systeme, die man durch
ein Netzwerk von nicht deterministischen Automaten, versehen mit Zeitangaben,
die über Kanäle bzw. gemeinsame Variablen kommunizieren, modellieren
kann. Typische Anwendungsbereiche sind Echtzeitsysteme, Kommunikationsprotokolle
und komplexe Systeme, in denen Zeitaspekte eine wichtige und kritische
Rolle spielen.
Seit Uppaal 1995 zum ersten Mal für die Öffentlichkeit verfügbar war, wurden im
13

14 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
jährlichen Abstand immer wieder neue Versionen herausgebracht. Die Veränderungen
bezogen sich hauptsächlich auf Verbesserungen im Bereich der Datenstrukturen
und Algorithmen des Verifizierers. Brauchte Uppaal 1995 noch 304
Sekunden zum verifizieren für das Philips audio protocol [2], so benötigt es auf
derselben Hardware mit der aktuellen Uppaal-Version nur noch 5.5 Sekunden.
Aber auch die Bedienung und die grafische Oberfläche des Werkzeugs wurden
sukzessive verbessert.
2.1.2 Grundlagen – Syntax und Semantik von Uppaal
Uppaal arbeitet basierend auf dem Formalismus der timed automata“ (oft auch
”
Zeitautomaten genannt). Es handelt sich hierbei um endliche Automaten, die
von Rajeev Alur und Davil L. Dill um clocks“, die im Folgenden als Uhren
”
bezeichnet werden, und entsprechende Ausdrücke, um auf diese eingehen zu
können, erweitert wurden [9]. Uppaal arbeitet auf einer Menge von Automaten,
die noch um weitere Eigenschaften erweitert sind. Im Folgenden werden die
timed automata“ sowie weitere Eigenschaften von Uppaal näher beschrieben.
”
Timed automata
sind endliche Automaten, die um folgende Komponenten erweitert wurden:
➫ Uhren
➫ Integer Variablen
➫ Kommunikationskanäle
➫ entsprechende Beschriftungen der Transitionen mit Ausdrücken
– zum Setzen, Manipulation von Uhren
– zum Setzen von Werten für die Variablen
– zur Formulierung von Bedingungen (guards) für Uhren und Variablen
– zur Synchronisation mit anderen Automaten über einen Kanal
Jeder in Uppaal instanziierte Automat stellt einen Prozess dar. Dieser ist erst
einmal von allen anderen unabhängig. Das hat zur Folge, dass die Automaten a
priori asynchron laufen, d. h. jeder besitzt einen eigenen Takt. Automaten sind
reaktive Systeme. Sie besitzen immer nur einen definierten Anfangszustand,
aber keinen Endzustand. In Uppaal werden die zu einem Zeitpunkt t aktiven
Zustände durch eine Marke (Token), wovon jeder Automat genau eine besitzt,
gekennzeichnet.
Uhren
Die oben erwähnten Uhren spielen in Uppaal bei den Timed Automata eine besondere
Rolle. Die Werte der Uhren steigen während eines Systemdurchlaufes

2.1. UPPAAL (MARTIN HIRSCH) 15
stetig an. Uppaal berechnet für die Uhren die Bereiche, in denen ihre Werte
liegen müssen, damit sie den Spezifikationen des Systems genügen. Die Berechnungsgrundlagen
liefern die Bedingungen an die Uhren, die in den Automaten
enthalten sind. Die Manipulation der Uhren, z. B. das Zurücksetzten auf 0,
geschieht durch eine Zuweisung ”
:=“.
Variablen
Uppaal unterstützt als Variablentypen nur Integervariablen. Variablen können
an Transitionsübergängen neue Werte zugewiesen bekommen. Es besteht die
Möglichkeit, den Wertebereich einer Integervariablen einzuschränken. Dies ermöglicht
u. a. die Simulation von Bool’schen Variablen, indem der Bereich
auf [0,1] beschränkt wird. Zusätzlich können Konstanten definiert werden, z.B
const true 1 oder const false 0, die es dann ermöglichen, Zuweisungen oder
Vergleiche über true und false, anstatt über 0 oder 1 zu machen.
Bedingungen und Invarianten
Die Variablen können an den Transitionen auch als Bedingungen stehen.
Erst wenn die Bedingung der Variablen erfüllt ist, darf die Transition schalten.
Nicht nur Variablen wachen über die Transitionen, sondern auch Uhren.
Die Besonderheit der Uhren ist, dass sie auch als Invarianten an den Zuständen
fungieren können (dies ist nur für Uhren erlaubt). Zur Behandlung der Uhren
bzw. Variablen sind hier nur einfache arithmetische Ausdrücke erlaubt:
k 1 ∼ x ∼ k 2 ,
k 1 ∼ x, y ∼ k 2 ,
wobei k 1 , k 2 ∈ N, x,y clocks bzw. Variablen und ∼ ∈ {≤, ≤, ≥, ≥, ==}. Komplexere
Ausdrücke würden den Vorgang des Model-Checkings erheblich verlangsamen,
da sich der Zustandsraum enorm vergrößern würde (Zustandsraumexplosion).
Kanäle
Über die sogenannten channel Kommunikationskanäle können sich die Automaten
untereinander synchronisieren. Gelangt ein Automat an eine Transition, die
mit einem Kommunikationskanal gekennzeichnet ist, z.B. kanal, so kann diese
erst dann schalten, wenn ein anderer Automat ebenfalls an einer Transition angekommen
ist, die diese Kanalvariable besitzt, kanal!. Die Kanaldefinitionen
können zusätzlich mit dem Schlüsselwort urgent versehen werden. Dieses bewirkt,
dass das Schalten der Transition unmittelbar eintritt, wenn beide Parteien
die Möglichkleit haben. Ohne das Schlüsselwort urgent ist das sofortige Schalten
nicht garantiert. Die Synchronisation zwischen zwei Automaten in Uppaal
bezieht sich jeweils auf genau zwei Transitionen, an denen dann der jeweilige
Ausdruck steht.

16 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
Folgendes Beispiel illustriert die vorgestellten Konzepte noch einmal.
Beispiel
Es soll ein System ”
Intelligenter Lichtschalter “ durch Echtzeitautomaten modelliert
werden. Ein Lichtschalter, der von einem Benutzer betätigt wird, soll
folgende drei Eigenschaften besitzen:
1. Nach einmaligem Betätigen des Schalters geht das Licht an,
2. wird innerhalb von 3 Sekunden der Schalter erneut betätigt, wird das Licht
heller,
3. wird der Lichtschalter nach 3 Sekunden erneut betätigt, erlischt das Licht
wieder.
Abbildung 2.1: Automaten Benutzer und Lichtschalter des Beipiels ”
Intelligenter
Lichtschalter“
Die beiden Automaten sind wie folgt aufgebaut:
Prozess Benutzer
Der Automat Benutzer (siehe Abb. 2.1 ) besitzt nur den einen Zustand idle,
dieser ist zugleich auch der Initialzustand (optisch erkennbar an den Doppelkreisen).
Von diesem gehen zwei (Selbst-)Transitionen aus. Die Transition ohne
Label stellt einen ɛ -Übergang 1 dar, die mit press! markierte Transition dient
1 Diese Transition kann immer schalten. Sie zu feuern, bedarf keines äusseren Einflusses

2.1. UPPAAL (MARTIN HIRSCH) 17
dazu, sich mit dem Automaten Lichtschalter zu synchronisieren, den ”
Lichtschalter“
zu drücken. Dieser sehr einfache Automat spiegelt alle möglichen Verhaltensweisen
des Benutzers aus der Realität 1:1 wieder. Entweder kann der
Lichtschalter gedrückt werden oder der Benutzer führt keine Aktion aus.
Prozess Lichtschalter
Der Automat Lichtschalter ist dagegen schon etwas komplizierter. Er besitzt
die Zustände Licht aus, Licht an und Heller, Initialzustand des Automaten
ist Licht aus. Die Transition von Licht aus nach Licht an ist mit der Kanalvariablen
press sowie mit der Zuweisung x:=0 der Uhrenvariablen x markiert.
Betätigt der Benutzer den Lichtschalter, wechselt dieser Prozess in den Zustand
Licht an, startet dabei eine Uhr x und initialisiert diese mit 0. Von dem Zustand
Licht an gehen zwei Transitionen aus. Der Übergang zu Licht aus ist
wiederum mit der Kanalvariablen press markiert. Zusätzlich gibt es hier auch
noch eine Bedingung, x>3. Die Transition schaltet also nur dann, wenn der
Benutzer nach Anschalten der Beleuchtung nach 3 Sekunden den Lichtschalter
erneut betätigt. Wird innerhalb von 3 Sekunden der Schalter erneut gedrückt,
schaltet die andere Transition, die in den Zustand Heller führt. Dieser Übergang
ist neben der Kanalvariablen press mit der Bedingung x

18 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
Abbildung 2.2: Uppaal – System Editor
Datei und die Daten für die Visualisierung in der .UGI Datei abgespeichert.
Ein integrierter Syntax-Checker überprüft bei Bedarf und automatisch vor jeder
Simulation bzw. Verifikation die Korrektheit der Syntax des erstellten System.
Alternativ zur Konstruktion im Systemeditor kann man die Modellierung des
Systems auch direkt in einem normalen Texteditor in der für die Automaten spezifischen
Beschreibungssprache vornehmen und als .XTA Datei abspeichern. Auf
diese Art der Modellierung wird in der Arbeit nicht weiter eingangen. Der Nachteil
dieser Vorgehensweise ist, dass bei einem späteren Editieren die grafischen
Daten zur Visualisierung im Simulator fehlen und dadurch die Übersichtlichkeit
verloren geht. Das manuelle Erstellen der .UGI Datei wird nicht empfohlen. Auf
den Verifizierer hat dies alles keinen Einfluss, so dass, wenn man die Simulation
nicht benötigt, z. B. bei einer automatischen Codetransformation von einer Programmiersprache
nach Uppaal, diese Variante durchaus von Vorteil sein kann.
Eine Möglichkeit wäre z. B., das bereits an der Arbeitsgruppe Softwaretechnik

2.1. UPPAAL (MARTIN HIRSCH) 19
der Universität Paderborn entwickelte Werkzeug FUJABA 2 um diese Funktion
zu erweitern und über eine Plugin-Struktur anzubinden.
Simulator
Die Simulatoroberfläche (siehe Abb. 2.3) bietet dem Benutzer die Möglichkeit,
das vorher definierte System anhand einer Beipielausführung nachzuvollziehen.
Die Variablenbelegung der Automaten kann in einem extra Fenster verfolgt werden.
Außerdem zeigt eine extra Ausgabe (Trace) an, welche Automatenzustände
gerade aktiv sind. Zum Einsatz kommt der Simulator besonders in der Entwicklungsphase
des Systems. So können, auch wenn das System noch nicht komplett
ist, schon einzelne Abläufe überprüft und eventuelle Fehler erkannt werden.
Abbildung 2.3: Uppaal – Simulator
Verifizierer
Im Verifizierer (siehe Abb. 2.4) werden die Prüfformeln für das zu testende System
angegeben. Hier ist die Spezifikationssprache eine eingeschränkte Form
2 From UML to Java and back again; www.FUJABA.de

20 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
von TCTL 3 , eine Erweiterung von CTL 4 . Der Verifizierer bietet die Option, bei
nicht erfüllten Formeln ein Gegenbeispiel anzugeben. Dieses geschieht in Form
eines Traces, der im Simulator nachvollzogen werden kann.
Abbildung 2.4: Uppaal – Verifizierer
2.1.4 Die Verifikationssprache TCTL
Eine Erläuterung der theoretischen Hintergründe von TCTL erfolgt nur insoweit,
als diese für das Verständnis der in dieser Arbeit, besonders in Kapitel 3
vorkommenden Prüfformeln, erforderlich ist.
TCTL ist aus CTL hervorgegangen. TCTL ist entwickelt worden, um zeitbehaftete
Modelle, wie sie in Uppaal durch Zeitautomaten vorkommen, mittels eines
mathematischen Formalismus überprüfen zu können. CTL wurde daher um Eigenschaften
erweitert, die insbesondere das Zeitverhalten von zustandsbasierten
Systemen überprüfen können.
Uppaal unterstützt nicht den vollen Umfang von TCTL. Lediglich folgende Arten
von Formelkonstrukten sind erlaubt:
3 Timed Computation Tree Logic
4 Computation Tree Logic

2.1. UPPAAL (MARTIN HIRSCH) 21
Als Quantoren gibt es den Allquantor A□ und den Existenzquantor E♦. Diese
treten immer in Verbindung mit einem Ausdruck, der einen Zustand des System
präsentiert, auf. Die Kette der Ausdrücke kann beliebig durch die logischen
Operatoren and und or geschachtelt und erweitert werden.
Bezugnehmend auf das unter 2.1.2 erklärte Beipiel lassen sich z. B. durch diese
Konstrukte folgende Formeln erstellen:
Beispiel:
A□ Lichtschalter.Licht ist aus
E♦ Lichtschalter.Licht ist an or Lichtschalter.Heller
Mit der ersten Formel wird geprüft, ob der Automat Lichtschalter sich stets im
Zustand Licht ist aus befindet. Natürlich ist dies nicht der Fall, so dass der
Verifizierer diese Formel nicht bestätigt. In diesem Fall wird vom Verifizierer
der oben erwähnte Trace ausgegeben.
Die zweite Formel überprüft, ob der Automat jemals in den Zustand Licht ist an
oder Heller gelangt, was vom Verifizerer bestätigt wird.
Erwähnt werden sollten noch die Operatoren ”
−→“ (leadsto) und ”
imply“.
Imply stellt einen Bezug zwischen 2 Automaten dar. Wenn sich z. B. ein
Automat A zum Zeitpunkt t in einem Zustand S 1 und ein Automat B zum
selben Zeitpunkt t in einem Zustand S 2 befindet, so würde die Formel
A.S 1 imply B.S 2
akzeptiert werden.
Der −→ (leadsto) Operator dagegen überprüft eine Fortschrittseigenschaft.
Beispiel:
Lichtschalter.Licht ist an −→ Lichtschalter.Licht ist aus
Wann immer das Licht angeschaltet wurde, so gibt es in der Zukunft einen Zustand,
zu dem das Licht wieder ausgeschaltet ist. Im vorliegenden Beispiel würde
diese Formel nicht akzeptiert werden, da der Automat Benutzer nicht gezwungen
wird, die Transition, mit press! markiert, mehr als einmal zu aktivieren.
Es besteht die Möglichkeit für den Automaten, im Zustand idle zu verweilen
und keine Aktion mehr auszuführen.
Die Uhren eines Automaten werden genauso wie Variablen in die Prüfformeln
eingebunden.
Beispiel:
E♦ Lichtschalter.Heller and Lichtschalter.x

22 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
2.2 SMV (Markus Zarbock)
2.2.1 Entwicklungsgeschichte
Der Symbolic Model Verifier, SMV wurde Mitte der neunziger Jahre von Ken
McMillan, an der Carnegie Mellon University (CMU) entwickelt. Ken McMillan
ist einer der maßgeblichen Entwickler des symbolischen Modelcheckings. Diese
erste Version von SMV verwendete CTL 5 für Spezifikationen und ermöglichte
die Verwendung verschiedener Zeitmodelle. Viele Halbleiterhersteller verwendeten
und verwenden diese Version, um ihre eigenen Tools zu entwickeln, zum
Beispiel IBM’s RuleBase. Ende der neunziger Jahre, Ken McMillan wechselte
zur University of Carlifornia, Berkeley wurde SMV erweitert. Es wurde eine
erweiterte Eingabesprache (extendet SMV) und die Fähigkeit LTL 6 als Spezifikationskalkül
zu verwenden hinzugefügt. Desweiteren ist SMV nun in der Lage
VeriLog zu verstehen einer Sprache, die zur Beschreibung von Halbleiterbbauelementen
und elektronischen Schaltungen verwendet wird. Diese Cadence SMV
genannte Version ist voll abwärtskompatibel zur CMU Version. SMV beherrscht
damit drei Eingabesprachen sowie CTL und LTL für Spezifikationen. Es kann
jedoch CTL nur für Spezifikationen von Modellen in der alten Syntax verwendet
werden und LTL für solche mit extendet SMV. Für diese Studienarbeit wurde
extended SMV verwendet und Spezifikationen in LTL.
2.2.2 Eigenschaften der Modellierungssprache
Zur Beschreibung von Modellen verwendet SMV eine eigene Sprache, die sich in
der Syntax an gängige Programmiersprachen anlehnt. Allerdings unterscheidet
sich diese Sprache in der Semantik erheblich von imperativen Programmiersprachen,
wie Java oder C++. Deshalb beginnt dieser Überblick mit einer Beschreibung
der beiden in SMV möglichen Zeitmodelle. Danach wird eine kurze
Einführung die Syntax von SMV beschreiben. Ziel ist es, neben der Vorstellung
der Modellierungssprache, klar zu machen, daß SMV ein Werkzeug zur
Modellierung und nicht zur Programmierung ist.
Zeitmodelle
Modellbeschreibungen kann man mit SMV in Module unterteilen, die wie Klassendefinitionen
in objektorientierten Programmiersprachen als Typen für Instanziierungen
dienen. Ein besonderes ist das Main-Modul, da dieses alle Instanziierungen
anstößt und als erstes ausgewertet wird.
Warum wird nun ein Zeitmodell benötigt, um Modelle zu überprüfen Prinzipiell
muss ein Modelchecker alle möglichen Abläufe eines Modells berechnen
können. Dafür diskretisiert SMV die Zeit und kann so einen Takt zu definieren,
in dem Programmschritte ausgeführt werden. Dieser Takt ist eine atomare Einheit,
das bedeutet es wird nur der Zustand vor und nach dem Takt betrachtet,
Zwischenzustände gibt es nicht.
5 Computation Tree Logic
6 Linear Temporal Logic

2.2. SMV (MARKUS ZARBOCK) 23
module main()
{
next(x) := true;
next(y) := false;
}
Ausführbahre Anweisungen werden in SMV in einem Takt echt parallel ausgeführt.
Das bedeutet die Reihenfolge in obigem Beispiel ist irrelevant. Daraus
ergeben sich eine Reihe von Konsequenzen, die später noch detailliert beschrieben
werden. Wenn nun aber die Anweisungen eines Moduls parallel ausgeführt
werden wie sieht es dann mit den Anweisungen instanziierter Module aus Dazu
bietet SMV, wie schon erwähnt zwei Zeitmodelle an, ein synchrones und ein
asynchrones.
Im synchronen Zeitmodell wird eine Modulreihenfolge festgelegt und dann werden
bei der Ablaufberechnung alle Module gleichgetaktet. Man kann das mit
einer elektronischen Schaltungsgruppe vergleichen, die über einen globalen Takt
geschaltet wird. Es gibt also einen globalen Takt und wenn dieser von t nach
t+1 gesetzt wird, dann werden für alle Module die möglichen Anweisungen ausgeführt.
Beispiel:
module a()
{
x : 0..127;
init(x) := 0;
next(x) := x + 1;
}
Wird dieses Modul mehrmals instanziiert und als Zeitmodell das synchrone
gewählt, so kann man beobachten, dass die x-Werte aller Modulinstanzen stets
gleich sind, da alle Modulinstanzen in einem atomaren Schritt weitergetaktet
werden.
Wird nun eine Modulinstanziierung mit dem Schlüsselwort process eingeleitet,
so verwendet SMV ein asynchrones Zeitmodell. Das bedeutet, dass für Instanzen
solcher Module beliebige Taktreihungen berücksichtigt werden. Der im synchronen
Modell globale atomare Zeittakt, existiert nun nicht mehr. Stattdessen gibt
es für jede Modulinstanz einen eigenen atomaren Takt. Wie für die Anweisungen
eines Moduls gilt nun für den Zustand der Modulinstanzen, daß alle möglichen
Ausführungen berücksichtigt werden müssen. Es gilt im asynchronen Fall jedoch,
dass keine zwei Prozesse gleichzeitig weitergetaktet werden. Grafik 2.5
zeigt für zwei Modulinstanzen P1 und P2 den Unterschied. Im synchronen Fall
gehen P1 und P2, bei Zeitfortschritt t nach t+1, in die Folgezustände P1’ bzw
P2’ über. Sind P1 und P2 jedoch asynchrone Instanzen, so berechnet SMV
alle möglichen Ausführungsreihenfolgen und wendet auf diese die Spezifikationen
an. Bei asynchronen Modellen kann man häufig beobachten, daß SMV als
Gegenbeispiel ein Ausführungsreihenfolge angibt, in der eine Modulinstanz stets
Rechenschritte ausführt alle anderen jedoch nicht. Dies gilt es bei der Festlegung
der Spezifikationen zu berücksichtigen.

24 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
Abbildung 2.5: SMV – Zeitmodelle
Das Verständnis des Zeitbegriffs, ist für die Modellierung in SMV von grundlegender
Bedeutung, da die im Folgenden vorgestellten Sprachelemente zwar
denen einer Programmiersprache ähneln, Modelle aber nicht im herkömmlichen
Sinne programmiert werden können. Die Semantik von SMV ähnelt eher Sprachen
zur Beschreibung von elektronischen Bauteilen, wie zum Beispiel VHDL.
Sprachelemente
Die Syntax von SMV, soll hier nur auszugsweise beschrieben werden. Für Details
sei auf die Sprachreferenz verwiesen [19]. Die Beschreibung ist so ausgelegt,
dass davon ausgegangen wird, daß der Leser mit imperativen Programmiersprachen
vertraut ist. Die Auswahl erfolgte unter dem Gesichtspunkt, der während
der Modellierung aufgetretenen Probleme.
Typen
SMV kennt als primitive Datentypen bool’sche Werte, Mengen und Ganzahlen.
Die Deklaration einer bool’schen Variablen sieht so aus:
bit1 : boolean;
Bei Zuweisungen gilt es zu beachten, dass SMV keine Schlüsselworte für true/false
kennt, diese kann man aber für alle Module festlegen, wenn man Beginn einer
Modelldefinition folgendes schreibt:
#define true 1
#define false 0
Mengen deklariert man wie folgt:

2.2. SMV (MARKUS ZARBOCK) 25
state : {idle , waiting , active};
Schließlich kann man Ganzahlenvariablen definieren.
byte : 0..7;
An komplexen Datentypen stellt SMV Arrays und Structs zur Verfügung. Arrays
sehen so aus:
word : array .. of ;
matrix : array 0..1 of array 2..0 of 0..7;
Verbundene Datentypen erzeugt man mit dem Schlüsselwort struct.
message : struct
{
flag : boolean;
byte : 0..7;
datas : array 0..31 of 0..31;
}
Wenn man mit struct definierte Datentypen, wie die vordefinierten Datentypen
verwenden will, so muss man die selbstdefinierten Datentypen mit typedef
definieren.
typedef message struct
{...}
Schleifen und Konditionale
Die Syntax von Schleifen (for) bzw Konditionalen (if/else, case) ist der in Sprachen
wie Java oder C++ sehr ähnlich, daher sei auf die Sprachreferenz verwiesen
[19].
Zuweisungen
Zuweisungen sind, aufgrund der Tatsache, dass SMV eine Sprache zur Beschreibung
von Modellen und keine Programmiersprache ist, besonders zu betrachten.
Die Art der Zuweisung bestimmt in SMV, wann der Wert einer Variablen
geändert wird. Sei im Folgenden x eine Ganzahlvariable. Will man x im gleichen
Takt ändern, so schreibt man :
x := 2;
Erfolgt diese Anweisung zum Zeitpunkt t, so gilt ab einschließlich t, daß x = 2
ist. Schreibt man dagegen :
next(x) := 2;
So wird der Wert von x erst zum Zeitpunkt t+1 verändert. Wird eine Variable
so deklariert, so kann man mit:
init(x) := 0;

26 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
einen Anfangswert definieren. Um die Zuweisungsarten etwas plausibler zu machen
folgen nun zwei Beispiele.
module a()
{
x : 0..31;
y : 0..31;
init(x) := 0; -- Anfangswerte setzen
init(y) := 0;
next(x) := x + 1;
next(y) := x;
}
equal : assert G (x = y);
module b()
{
x : 0..31;
y : 0..31;
init(x) := 0; -- y darf nicht mehr mit init() gesetzt werden
next(x) := x + 1;
y := x;
}
equal2 : assert G (x = y);
Für die Spezifikation equal wird als Ergebnis false berechnet, da y ja stets den
aktuellen Wert von x erst im nächsten Takt zugewiesen bekommt, x jedoch erst
im nächsten Takt verändert wird. Im Modul b darf der Wert für y nicht mit
init() initialisiert werden, da die Anweisung y := x den ersten Takt einschließt.
Würde y initalisiert werden so wäre dies eine Verletzung der single assignment
Regel. Für die Spezifikation equal2 berechnet SMV true.
Die Single Assignment Regel
In SMV werden alle Anweisungen eines Taktes echt parallel ausgeführt. Ein
Taktschritt ist eine atomare Einheit ohne Zwischenschritte. Daraus folgt unmittelbar,
dass es in einem Taktschritt für eine Variable nur eine Zweisung geben
darf, gäbe es mehrere so existierten auch Zwischenzustände. Diese Regel gilt in
beiden Zeitmodellen mit unterschiedlichen Auswirkungen.
Für die folgenden Beispiele seien x und y Ganzzahlvariablen. SMV prüft if-
Blöcke nicht auf Ausschluß, daher ist es nicht erlaubt in mehreren solchen den
Wert einer Variablen zu verändern.

2.2. SMV (MARKUS ZARBOCK) 27
if(y = 1)
next(x) := 1;
if(y = 2)
next(x) := 0; -- nicht erlaubt
...
Hierfür ist das Case Konstrukt vorgesehen, das dieses stets garantiert, dass nur
einer der aufgeführten Fälle tatsächlich eintritt.
Das folgende Beispiel ist in einer imperativen Programmiersprache möglich.
next(x) := x + 2;
...
next(y) := y + 3;
next(x) := y; -- nicht erlaubt
In SMV ist die zweite Zuweisung für x nicht gestattet. Hier gibt es zwei Möglichkeiten
entweder es wird eine neue Variable eingeführt oder Berechnungen werden
so optimiert, daß zwei Zuweisungen nicht notwendig sind.
Im folgenden gilt das synchrone Zeitmodell.
1 module a()
2 {
3 x : 0..7;
4 init(x) := 0;
5
6 next(x) := x+1;
7 }
8 module main()
9 {
10 aInstanz : a();
11 next(aInstanz.x) := 0; --nicht erlaubt
12 }
Da im synchronen Zeitmodel ein globaler Takt weitergesetzt wird, werden hier
die Zuweisungen in Zeile 6 und Zeile 11 parallel ausgeführt und somit würde
die single assignment Regel verletzt werden. Im synchronen Zeitmodell ist dies
also nicht möglich. Wäre aber aInstanz als asynchroner Prozess (Schlüsselwort
process) instanziiert worden, so wären die Zuweisungen erlaubt. Das liegt daran,
dass im asynchronen Zeitmodell keine zwei Prozesse gleichzeitig weitergetaktet
werden. Die single assignment Regel folgt zwingend aus den Definitionen der
Zeitmodelle. Dennoch sollte sie hier betrachtet werden, da sie sich beim Prozess
des Modellierens als Stolperstein erwiesen, weil sie in Bezug auf imperatives
Programmieren ein Paradigmenwechsel darstellt.
Die Circular Dependency Regel
Diese Regel besagt, dass es nicht gestattet ist kreisförmige Zuweisungen ohne
Zeitverzögerungen durchzuführen. Eine kreisförmige Zuweisung sieht zum Beispiel
so aus:

28 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
x := y;
y := x;
Erlaubt sind dagegen kreisförmige Zuweisungen, die Verzögerungen enthalten.
Beispiel :
x := y;
next(y) := x;
2.2.3 Eigenschaften der Spezifikationen
Mit der Modellierungssprache von SMV beschreibt man die Eigenschaften eines
Systems, das tatsächlich existiert oder realisiert werden soll. Eine Spezifkation
soll eine Eigenschaft beschreiben, deren Einhaltung am modellierten System
vom Modelchecker zu prüfen ist. SMV verwendet für Spezifikationen Linear
Temporal Logic, kurz LTL. Zunächst zur Syntax, Spezifikationen werden mit
dem Schlüsselwort assert gekennzeichnet.
Beispiel:
spez1 : assert G ( a = true);
Jede Spezifikation besteht also aus einem Namen, dem Schlüsselwort assert und
der eigentlichen Spezifikation in LTL. Diese Zerlegung in einzelne Spezifikationen
geschieht nicht nur aus Gründen der übersichtlichkeit, sondern auch um
Berechnungen zu minimieren. SMV kann nämlich gezielt einzelne Spezifikationen
prüfen.
Spezifikationen können auch komplexe Gebilde sein, da man Sprachelemente verwenden
kann, um Spezifikationen zu generieren. Um beispielsweise, die Werte
eines Arrays prüfen zu lassen kann man folgende Konstruktion verwenden:
for (i = 0 ; i < 32 ; i = i + 1)
{
dats[i] :
assert G (datas[i] < 31 & datas[i] >= 0);
}
Eine weitere praktische Möglichkeit ist die Verwendung von Mengenschreibweisen,
um den Wertebereich von Variablen zu beschreiben. Beispiel:
spezifikation : assert G ( a = {0..7});
Übersicht Operatoren
Für die Spezifikationen verwendet SMV Formeln, die zum einen aus den Operatoren
der Sprache bestehen. Beispielsweise sind die logischen Operatoren:

2.2. SMV (MARKUS ZARBOCK) 29
UND &
ODER |
NICHT ~
Zum anderen aus Temporaloperatoren X, G, F und U, die wie folgt definiert
sind:
Seien p und q Formeln.
X p gilt zum Zeitpunkt t, wenn p zum Zeitpunkt t+1 gilt
G p gilt zum Zeitpunkt t, wenn für alle t’ ≥ t p gilt
F p gilt zum Zeitpunkt t, wenn für ein t’ ≥ t p gilt
p U q gilt, wenn q für ein t’ ≥ t gilt und zwischen t und t’ p gilt
Bemerkungen zur Verwendung
Da SMV ein Kommandozeilen orientiertes Tool ist und es in der frei verfügbaren
Version auch keine grafische Repräsentation für Modelle gibt, sind Spezifikationen
das einzige Mittel, um ein Modell dahingehend zu überprüfen, ob es
überhaupt das zu prüfende System korrekt modelliert. Zu diesem Zweck hat es
sich häufig gezeigt, dass Forderungen wie:
“Von jedem Zustand gibt es einen Weg zu einem Zustand in dem
eine Formel gilt.“
dafür sehr praktisch wären. Zum Beispiel könnte man so prüfen lassen, ob ein
Shuttle in einem geschlossenen Gleiskreis immer wieder über ein bestimmtes
Gleis fährt. Formeln, die wie obige kann man in CTL ausdrücken.
AG(EF) p
Für alle Zustände, gibt es einen Pfad zu einem Zustand, in dem p gilt. Leider
lässt sich so etwas nicht in LTL ausdrücken. Die Quantoren F und G müsste man
in LTL eigentlich als AF, bzw als AG schreiben. Da es keinen Existenzquantor
gibt kann man mit LTL Formeln einzelne Pfade nicht erfassen. Dieser Nachteil
ist für die eigentlichen Spezifikationen dann jedoch eher vernachlässigbar, weil
es dann ja gerade erwünscht ist Bedingungen zu formulieren, die für alle Pfade
gelten.
2.2.4 Verwendung von SMV
Konsole
SMV kann auf zwei unterschiedliche Arten bedient werden. Zunächst ist SMV
ein Kommandozeilenprogramm, dem man ein Modell und die Spezifikationen
übergibt. Die Ausgabe besteht zum einen aus dem Ergebnis der Spezifikationsprüfung,
sprich wahr oder falsch, wobei SMV nach der ersten falschen Spezifikation
mit einem Gegenbeispiel abbricht. Zum anderen gibt SMV eine ganze
Reihe von Angaben zum internen Ablauf, durch die man sich den Umfang der
Berechnungen verdeutlichen kann.

30 KAPITEL 2. VORSTELLUNG VON UPPAAL UND SMV
GUI
Die zweite Art mit SMV zu arbeiten besteht in der Benutzung der mit TCL/TK
geschriebenen grafischen Benutzeroberfläche. Diese kapselt im wesentlichen die
parametrisierten Kommandozeilenaufrufe. Wenn man das Programm startet
und eine Modelldatei (*.smv) lädt, so zeigt SMV zunächst den Quelltext und in
einer Baumstruktur alle instanziierten Module sowie deren Variablen an, (Abbildung
B.1).
Wechselt man nun in die Spezifikationsansicht ( Abbildung B.2), so werden
nun im oberen Fenster die im Quelltext gefunden Spezifikationen aufgelistet.
Diese kann man unter dem Menüpunkt Prop einzeln prüfen lassen. Diese Einzelprüfung
ist sehr hilfreich, wenn man in großen Modellen mit vielen Spezifikationen
gezielt Prüfungen vornehmen kann.
Hat man SMV nun eine oder mehrere Spezifikationen prüfen lassen, so bekommt
man die Ergebnisse und die Berechnungsdaten im Logfenster angezeigt (Abbildung
B.3).
Erfüllt ein Modell eine Spezifikation nicht, so berechnet SMV ein Gegenbeispiel.
Dieses wird dann in einem Trace angezeigt (Abbildung B.4). Man kann dieses
Gegenbeispiel auch in wählbarer Schrittzahl weiterberechnen lassen.

Kapitel 3
Fallstudie
Dieses Kapitel bildet das Kernstück dieser Studienarbeit. Anhand eines praktischen
Beispiels, eines Ausschnitts aus der ISILEIT 1 -Fallstudie [18, 5], wird
der stetig wachsende Einsatz von Model-Checker Werkzeugen in der Praxis gezeigt.
Außerdem wird an diesem Beispiel gezeigt, wo Grenzen der einzelnen
Model-Checker liegen, bzw. welche Werkzeuge für welche Gebiete besonders
prädestiniert sind.
Abbildung 3.1: Eine mögliche Topologie der ISILEIT-Fallstudie
3.1 Vorstellung (Martin Hirsch)
In der Fallstudie geht es um die Simulation eines komplexen Materialflusssystems.
Verschiedene Arbeitsstationen sind durch ein Schienennetz, auf dem
autonome Shuttles verkehren, verbunden. An den einzelnen Stationen können
die Shuttles mit Material beladen bzw. entladen werden. Weiterhin stehen an
den einzelnen Stationen verschiedene Roboter bereit, die die Materialien weiterverarbeiten
oder bis zu einer späteren Verwendung lagern.
1 Integrative Spezifikation von Leitsystemen der flexibel automatisierten Fertigung
31

32 KAPITEL 3. FALLSTUDIE
An strategischen Punkten des Schienensystems sind Sensoren angebracht, die einer
Steuereinheit, einem Koordinator, der für diesen Systemabschnitt zuständig
ist, melden, wenn ein Shuttle diesen passiert. Ein Koordinator übernimmt jeweils
die Koordination seiner angeschlossenen Komponenten, d. h. er sorgt
dafür, dass Shuttles z. B. an den richtigen Stationen zum Be- bzw. Entladen
gestoppt werden und Weichen immer richtig gestellt sind, so dass die Shuttles
immer den richtigen Weg nehmen bzw. es zu keiner Entgleisung kommt.
Abbildung 3.2: Ausschnitt aus der ISILEIT-Fallstudie
Ein mögliches Szenario für einen Koordinator, die Ansteuerung von Weichen mit
den dazugehörigen Komponenten, ist in Abb. 3.2 dargestellt. Wie in Abb. 3.2
zu erkennen, gibt es hier die Komponenten Switch 1, Switch 2 (Weichensteuerungseinheiten)
und Ventilinsel und natürlich die beiden Weichen. Jede Weichensteuerungseinheit,
die in der Realität durch eine Speicherprogrammierbare
Steuereinheit (SPS) verkörpert wird, steht über eine Kommunikationsleitung
mit dem Koordinator in Verbindung. Über eine elektronische Verbindung kann
eine Weichensteuerungseinheit die Ventilinsel, ein 4/2 Wegeventil, ansteuern,
das wiederum die Weichen bewegt.
In unserer Modellierung haben wir uns auf die in Abb. 3.2 dargestellten Komponenten
beschränkt. Die Be- und Entladesteuerung, Verarbeitung sowie die
Lagerverwaltung der einzelnen Materialien wurden aus Komplexitätsgründen
weggelassen. Folgende Regeln und Anforderungen wurden an unser System gestellt:
1. Im kompletten System darf es zu keiner Deadlocksituation kommen.
2. Auf Grund der gegebenen technischen Voraussetzung der Ventilinsel kann
zu einem Zeitpunkt immer nur eine Weiche geschaltet werden. Dieses muss
vom Koordinator geregelt werden.

3.2. UPPAAL (MARTIN HIRSCH) 33
3. Die beiden Weichensteuerungseinheiten verfügen über keine Kommunikation
untereinander, d. h, sie können sich über keine globalen Variablen
gegenseitig sperren um die unter 2. genannte Voraussetzung zu erfüllen.
Dieser Vorgang muss vom Koordinator gelöst werden.
4. Bevor ein Shuttle die Passage Schiene1, Schiene3, Schiene4 passieren
will, müssen Weiche 1 und Weiche 2 richtig gestellt sein. Erst nachdem
das Shuttle auf Schiene4 angekommen ist, werden die Weichen wieder freigegeben.
5. Möchte ein Shuttle die Passage über Schiene1, Schiene2, Schiene4 nehmen,
so wird vorerst nur Weiche 1 geschaltet, Weiche 2 wird erst geschaltet,
wenn das Shuttle an der Arbeitsstation angekommen ist und weiter
möchte.
6. Auf Schiene3 darf sich zu keinem Zeitpunkt mehr als ein Shuttle befinden.
Weiterhin darf ein Shuttle auf diesem Schienenstück nicht stehen bleiben.
7. Eine Weiche darf nur dann von einem Shuttle passiert werden, wenn sie
arretiert ist.
3.2 Uppaal (Martin Hirsch)
In diesem Abschnitt wird die Vorgehensweise bei der Modellierung der Fallstudie
erläutert und das ”
Programm“ anhand der Automaten und Quelltextausschnitte
weitestgehend erklärt. Abschließend werden Resultate des Verifikationsprozesses
genannt.
3.2.1 Vorgehensweise zur Modellierung der Fallstudie
Im ersten Schritt wurde die Sichtung der vohandenen beteiligten Komponenten
vorgenommen. Aus obiger Beschreibung ergibt sich folgende Liste:
1. Koordinator
2. Switch 1 und Switch 2
3. Ventilinsel
4. Shuttles
5. Weiche 1 mit Zustandssensor und Weiche 2 mit Zustandssensor
6. Schiene 1 mit Sensor 1, Schiene 2 mit Sensor 2, Schiene 3 mit Sensor 3,
Schiene 4 mit Sensor 4
Die Realisierung der einzelnen Komponenten wird im Folgenden erläutert, bei
der Modellierung aufgetretene Probleme werden aufgezeigt.

34 KAPITEL 3. FALLSTUDIE
3.2.2 Die Modellierung
Koordinator
Der Koordinator als koordinierende Instanz für die Komponenten der Weichensteuerungseinheiten
wird als eigener Automat realisiert. Dabei muss beachtet
werden, dass der Koordinator in der Struktur eines ”
switch case Blocks“ aufgebaut
werden muss. Der Koordinatorprozess muss in jedem Takt neue Inputs
verarbeiten können und sollte sich nicht in einer Schleife aufhalten. Dieses wird
am besten durch einen Automaten mit nur einem Zustand, von dem alle ”
cases“
ausgehen, dargestellt durch (Selbst-)Transitionen, umgesetzt.
Der relativ komplexe Automat für den Koordinator, komplex bezieht sich hierbei
nicht auf die Anzahl der Zustände, der Automat besitzt nur einen Zustand, sondern
auf die umfangreiche Steuerlogik, wurde in Form eines ”
switch case Blocks“
aufgebaut. So fragt der Koordinator in jedem Takt seine Signale bzw. Variablen
ab und kann dementsprechend reagieren. Die Signale sind Inputs von den
Weichensteuerungseinheiten Switch 1 und Switch 2, die Variablen sind lokaler
Art, die einen Zustand des Koordinators darstellen und durch Veränderungen
im nächst möglichen Takt eine Transition feuern lassen.
Folgende Beispielabläufe erklären die Logik des Automaten, der Quellcode ist
im Anhang unter A.4 aufgelistet.
Beispielablauf 1: Ein Shuttle möchte den Weg über die Schiene 1,
Schiene 2, Schiene 4 nehmen.
Das Shuttle löst als erstes den Sensor 1 der Schiene 1 aus. Der Koordinator
merkt sich in einer Variablen zustand sensor 1, dass ein Signal anliegt
und stellt den Richtungswunsch des Shuttles fest richtung==links. Ist zustand
sensor 1==true, liegt also ein Signal an, überprüft der Koordinator
als nächstes, ob die zu schaltende Weiche 1 frei ist. Den Zustand der Weiche
merkt sich der Koordinator stets in einer lokalen Variablen weiche belegt 1.
Ist weiche belegt 1==false, die Weiche also von keinem anderen Schaltvorgang
belegt, setzt der Koordinator weiche belegt 1:=true, die Komponente
Weiche 1 wird also belegt und die Variable bewege weiche 1:=true wird gesetzt.
Nun weiß der Koordinator, dass eine Anforderung zum Schalten der Weiche
1 existiert. Sobald möglich, sendet er nun über einen Kommunikationskanal
steuer weiche 1! ein Signal an Switch 1, der den Schaltvorgang der Weiche
übernimmt. Bei diesem Vorgang setzt der Koordinator seine lokale Variable
ventilinsel belegt:=true. Diese Variable sperrt die Ventilinsel, da diese zu
einem Zeitpunkt schließlich immer nur eine Weiche schalten kann. Wenn nun
die Weiche geschaltet ist, bekommt der Koordinator über einen Kommunikationskanal
vom Switch 1 ein Signal. Der Koordinator setzt erst jetzt die Flags
ventilinsel belegt, weiche belegt 1 wieder auf false und gibt dem Shuttle
das Signal weiter 1 zur Weiterfahrt über die Weiche 1 auf Schiene 2. Befindet
sich das Shuttle nun auf Schiene 2 und löst dort den Sensor 2 der Schiene 2
aus, verhält sich der Koordinator genauso wie oben, nur mit den Signalen und
Variablen ˜ 2.

3.2. UPPAAL (MARTIN HIRSCH) 35
Beispielablauf 2: Ein Shuttle möchte den Weg über die Schiene 1,
Schiene 3, Schiene 4 nehmen.
Das Shuttle löst als erstes den Sensor 1 der Schiene 1 aus. Der Koordinator
merkt sich in einer Variablen, zustand sensor 1, dass ein Signal anliegt und
stellt den Richtungswunsch des Shuttles fest richtung==links. Ist zustand sensor
1==true, liegt also ein Signal an, überprüft der Koordinator als nächstes,
ob die zu schaltende Weiche 1 und Weiche 2 frei sind. Ist dieses der Fall, werden
beide Weichen als belegt gekennzeichnet, weiche belegt 1:=true, weiche belegt
2:=true, sowie die Anforderungsvariablen zum Schalten der Weichen gesetzt
(bewege weiche 1:=true, bewege weiche 2:=true). Im Folgenden werden
jetzt die beiden Weichen geschaltet. In welcher Reihenfolge dies geschieht,
ist nicht festgelegt. Es kann also sein, dass entweder Weiche 1 als erstes schaltet
oder Weiche 2. Die Variable ventilinsel belegt, die bei jedem Schaltvorgang
auf den Wert true gesetzt wird und erst nach Vollendung wieder auf false,
verhindert, dass beide Weichen gleichzeitig schalten. Der Schaltvorgang einer
Weiche wird hier genauso gelöst wie unter Beispiel 1. Erst wenn beide Weichensteuerungseinheiten
das Signal an den Koordinator gegeben haben, dass
die Weichen geschaltet sind, wird das Shuttle weitergeschickt (weiter 1!). Da
das Shuttle auf dieser Passage vor der Weiche 2 nicht angehalten werden kann,
wie es auf Schiene 2 möglich ist, darf die Weiche 2 erst dann wieder freigegeben
werden, wenn das Shuttle den Sensor der Schiene 4 ausgelöst hat. Andernfalls
könnte ein Shuttle, das auf Schiene 2 steht, die Weiche für sich richtig stellen lassen.
Um dieses zu umgehen, wird die Variable weiche belegt 2 erst zu diesem
Zeitpunkt wieder auf false gesetzt und die Komponente Weiche 2 freigegeben.
Weichensteuerungseinheiten
Die Weichensteuerungseinheiten Switch 1 und Switch 2, ebenfalls notwendig
für die Modellierung, werden als Instanzen eines Automaten Switch realisiert.
Dieses ist möglich, da die beiden Speicherprogrammierbaren Steuerungen (SPS)
dieselbe Logik haben, nur mit anderen Ein- bzw. Ausgangssignalen. Bei der
Modellierung muss berücksichtig werden, dass die beiden SPS’en untereinander
nicht direkt kommunizieren können. Die Weichensteuerungseinheit soll sich in
einer lokalen Variablen die jeweilige Position der Weiche, für die sie verantwortlich
ist, merken.
Der Automat Switch (siehe Abb. 3.4) besitzt 10 Zustände und befindet sich
initial im start Zustand, erkennbar an den Doppelkreisen des Zustandsymbols.
Die Steuerungseinheit ist, wie oben erwähnt, für die Ansteuerung der Weichen
bzw. genauer der Ventilinsel, zuständig. Bekommt der Automat nun vom Koordinator
das Signal steuer weiche zum Schalten der Weiche (Transition start
→ S0), springt der Automat in den Zustand S0 und startet eine Uhr x:=0.
Innerhalb desselben Taktes wertet der Automat aus, in welche Richtung das
Shuttle fahren möchte (Transition S0 → S1 bzw. S0 → S2 ) und stellt fest,
ob sich die Weiche schon in der richtigen Position befindet oder nicht. Dies ist
möglich, da sich der Automat in einer lokalen Variablen weichen position stets
die Position der Weiche merkt. Befindet sich die Weiche schon in der korrekten

36 KAPITEL 3. FALLSTUDIE
Stellung, gibt der Automat noch im selben Takt ein Signal weiche geschaltet!
an den Koordinator (Transition S4 → start bzw. S8 → start) und schaltet
wieder in den Ruhezustand start. Ist die Position der Weiche allerdings noch
nicht die richtige, der Automat befindet sich in den Zuständen S3 bzw. S6,
gibt dieser ein Signal an die Ventilinsel druckluft ventilinsel und löst die
Arretierung der Weiche arretiert:=false. Für diesen Vorgang braucht die
Steuerungseinheit einen Zeittakt, erkennbar an der Zeitbedingung x==1 der
Transition S3 → S5 bzw. S6 → S7, der Automat befindet sich nun in S5 bzw.
S7. Frühestens nach 2 weiteren (guard x>=3) und spätestens nach 3 Zeiteinheiten,
die Zustände S5 und S7 sind mit Invarianten x

3.2. UPPAAL (MARTIN HIRSCH) 37
Weiche 1 und Weiche 2
Die beiden Weichen, obwohl unterschiedlich (Splitter und Joiner), werden im
Modell als ein Typ angesehen. Auf den ersten Blick ist dieses nicht so ganz
einsehbar aber dennoch korrekt. Im physikalischen Modell kennt die Weiche
auch nur ihre zwei Zustände, Links oder Rechts. Die Art und Weise, wie sie
in das Schienennetz eingebaut ist, ist für die Weiche selbst uninteressant, lediglich
die steuernde Instanz, also der Koordinator, muss dieses berücksichtigen.
Auf Grund dieser Gegebenheit können die beiden Weichen deshalb Instanz ein
und desselben Automaten sein. Da man aber auch Fehlverhalten bzw. nicht
korrektes Schalten oder Blockieren einer Weiche mit modellieren möchte, muss
der Weichen-Automat neben den zwei Zuständen Links bzw. Rechts auch noch
zwei weitere Zustände bekommen. Diese stellen Zwischenzustände dar, d. h.
die Weiche schaltet über einen Zwischenzustand in die neue Position. Die Wei-
Abbildung 3.4: Uppaal – Automat Weiche
che (siehe Abb. 3.4) besteht aus den vier Zuständen weiche ist rechts, S2,
S1 und weiche ist links. Anfangszustand ist weiche ist links, d. h. beim
Starten des Systems befindet sich die Weiche in der definierten Linken Stellung
(Anfangszustand ist immer durch den doppelten Kreis gekennzeichnet). S1 und
S2 sind Zwischenstellungen, schließlich springt die Weiche in der Realität auch
nicht sofort von Links nach Rechts bzw. Rechts nach Links. Bekommt die
Weiche nun Druckluft von der Ventilinsel, die Weiche befindet sich zu diesem
Zeitpunkt entweder im Zustand weiche ist links oder weiche ist rechts,
schaltet sie zuerst in S1 bzw. S2 (Transition 1 bzw. 3). Dieser Vorgang wird
durch die Kanalvariable druckluft 1! realisiert, die von der Ventilinsel ausgelöst
wird (siehe Automat Ventilinsel). Nachdem ein Zeittakt verstrichen ist
(clock x>=1), schaltet die Weiche in den neuen Zustand weiche ist links
bzw. weiche ist rechts (Transition 2 bzw. 4) und löst den entsprechenden
Näherungssensor der Weiche aus, so dass die Weichensteuerungseinheit eine

38 KAPITEL 3. FALLSTUDIE
Rückmeldung erhält. Diese Rückmeldung wird wiederum durch eine Kanalvariable
naeherungs sensor rechts! bzw. naeherungs sensor links! gelöst.
Ventilinsel
Die Ventilinsel ist im Modell nicht unbedingt mit zu modellieren, da sie im realen
System keine weitere Aufgabe hat als die elektronischen Signale in Druckluft
umzuwandeln und an die Weiche weiterzugeben. D. h. man könnte z. B. in der
Modellierung das Signal direkt an die Weiche geben und stattdessen eine längere
fingierte Schaltzeit für die Weiche einplanen. Diese Abstraktion hat zum Nachteil,
dass ein in der Realität auftretendes Fehlverhalten der Ventilinsel bei der
Modellierung unberücksichtig gelassen würde. Da man beim Model-Checking
aber gerade solche Verhaltensweisen von Systemen überprüfen will, wird die
Ventilinsel in das Model mit aufgenommen.
Wie erwähnt dient die Ventilinsel lediglich dazu, die Signale, die sie von einer
Weichensteuerungseinheit bekommt, in Druckluft umzuwandeln. Allerdings
kann die Ventilinsel, wie oben unter den Anforderungen an das System bereits
genannt, zu einem Zeitpunkt immer nur genügend Luft zum Schalten einer Weiche
bereitstellen.
Der Quellcode des Automaten-Templates Ventilinsel
1 process Ventilinsel
2 {
3 clock x;
4 state S3{x S0{sync druckluft_weiche_rechts_1;
13 assign x:=0; },
14 S0 -> start{guard x>=1;
15 sync druckluft_1!; },
16 start -> S1{sync druckluft_weiche_links_1;
17 assign x:=0; },
18 S1 -> start{guard x>=1;
19 sync druckluft_1!; },
20 start -> S3{sync druckluft_weiche_links_2;
21 assign x:=0; },
22 S3 -> start{guard x>=1;
23 sync druckluft_2!; };
24 }

3.2. UPPAAL (MARTIN HIRSCH) 39
Der Automat Ventilinsel besteht aus den 5 Zuständen start, S0, S1, S2
und S3, deklariert durch das Schlüsselwort state (Zeile 4), initial start (Zeile
6). Soll z. B. Weiche 1 von Links nach Rechts geschaltet werden (Zeile 10), bekommt
die Ventilinsel vom Automat Switch 1 ein Signal druckluft weiche rechts 1,
schaltet vom Zustand start in den Zustand S1, wartet eine Zeiteinheit, um den
Druck aufzubauen, und gibt schließlich Druckluft druckluft 1! an Weiche 1,
die daraufhin schaltet (Zeile 12). Die anderen Schaltvorgänge laufen analog ab.
Shuttles und Schienennetz
Die Komponenten Shuttle und Schienennetz sind gemeinsam zu betrachten.
Bei der Realisierung der beiden Komponenten ist zu überlegen, ob man das
Shuttle als aktives, die Schiene als passives Objekt bzw. umgekehrt darstellt.
Wird das Shuttle als passives Objekt angesehen, so bedeutet dies eine hohe Abstraktion
von den realen Gegebenheiten. Die Schiene würde als Aktionsträger
die Shuttles bereits beinhalten. In Uppaal würde das Shuttle durch ein Token
dargestellt. Durch Kommunikationskanäle würden sich die Schienen nun untereinander
verständigen und sich gegenseitig aktivieren, das Shuttle also weiterreichen.
Diese Variante hat den Vorteil, dass die Anzahl der Zustände des
gesamten System relativ gering bleibt, da man die Schienen an sich durch einfache
Automaten aus je 2 Zuständen darstellen kann. Der Nachteil ist, dass
man die Shuttles nicht unterscheiden kann. Außerdem ist es nicht möglich, die
Shuttles in irgendeiner Form zu beladen“, wie es in der Fallstudie vorgesehen
”
ist.
Betrachtet man das Shuttle nun als aktives Element, wird das Shuttle als Instanz
eines Shuttle-Automaten dargestellt. Durch die Anzahl der Instanzen, die
man vorab festlegt, wird die Menge der Shuttles im System, das geprüft werden
soll, bestimmt. Die Vorteile dieser Variante sind klar ersichtlich. Die Shuttles
können nun identifziert werden, da sie eine Instanz sind. Jedes Shuttle hat
sein eigenes Verhalten, es kann z. B. Ladung aufnehmen. Durch die geringere
Abstraktion von der Realität werden in diesem Fall die Zustände des Systems
erheblich gegenüber der ersten Variante erhöht. Dieser Nachteil ist jedoch nicht
so schlimm, wie in Kapitel 3.2.3 anhand von Auswertungen belegt wird.
Abb. 3.5 zeigt eine Möglichkeit der Realisierung eines Automaten für ein Shuttle.
Wie zu erkennen, ist der Automat in Form des in 3.2 dargestellten Schienensystems
aufgebaut. Das Shuttle besitzt intern eine Abbildung der gegebenen
Topologie. Ein Shuttle weiß, in welcher Reihenfolge welche Signale empfangen
und gesendet werden dürfen und an welcher Stelle es sich gerade befindet. So
ergibt sich folgende Einteilung:
Schiene 1: Zustände Start & Sensor 1
Schiene 2: Zustände S1 & Sensor 2
Schiene 3: Zustände S2 & Sensor 3
Schiene 4: Zustände S3 & Sensor 4.
Das autonom reagierende Shuttle kann lediglich Sensoren sensor 1, sensor 2,
sensor 3, sensor 4 der entsprechenden Schienen auslösen und an ensprechen-

40 KAPITEL 3. FALLSTUDIE
Abbildung 3.5: Uppaal – Automat Shuttle
den Stationen Sensor 1, Sensor 2, Sensor 4 gestoppt werden. Durch ein Signal
weiter 1, weiter 2, weiter 4 wird es wieder in Bewegung gesetzt.
3.2.3 Ergebnisse der Verifikation
In diesem Abschnitt werden die Ergebnisse des Verifikationsprozesses vorgestellt.
Anhand der in 3.1 an das System gestellten Bedingungen wurden entsprechende
Prüfformeln erstellt.
Prüfformeln sind (sollten) eine ”
bijektive Abbilung“ eines sprachlich formulierten
Regelwerks eines Systems auf eine mathematische Formel (sein). Durch die
mathematische Formel, in diesem Fall in TCTL (siehe 2.1.4) formuliert, wird
also immer nur das überprüft, was letztendlich auf diese abgebildet wurde. Eine
Schwierigkeit des Verifikationsprozesses ist es also auch, das und nur das auf
Prüfformeln abzubilden, was gefordert war.
Da in 3.1 die Regeln schon recht eindeutig formuliert wurden, ist es in diesem
Fall recht einfach, diese genau abzubilden. Dieses ist jedoch häufig nicht der Fall.
So steht fast immer vor dem Verifikationsprozess durch den Model Checker erst
der ”
Beweis“, dass die Formeln auch wirklich die zu prüfenden Eigenschaften
ausdrücken.
Eigenschaft Nr.1
Im System tritt nie eine Deadlock Situation auf.
Zur Überprüfung dieser Eigenschaft stellt Uppaal schon eine vorgegebene Formel,
deadlock, zur Verfügung. Will man also die Deadlockfreiheit des ganzen

3.2. UPPAAL (MARTIN HIRSCH) 41
Systems zu jedem Zeitpunkt überprüfen, formuliert man folgende Formel:
A□ not deadlock.
Eine Auswertung durch den Verifizierer 2 hat folgende Werte ergeben.
Anz. Shuttle Anz. Zustände Verifikationszeit Anforderung
Instanzen des Systems (in Sek.) erfüllt (j/n)
1 44 ≪ 1 j
2 54 < 1 j
3 64 ≈ 1 j
4 74 ≈ 3 j
5 84 ≈ 21 j
6 94 ≈ 66 j
7 104 ≈ 189 j
Neben der Eigenschaft, dass diese Formel immer akzeptiert wird, ist zu beobachten,
dass schon mit geringer Erhöhung der Zustände des Gesamtsystems die Verifikationszeit
erheblich ansteigt. So ist bei der Erhöhung von 74 auf 84 Zustände
ein Faktor 7, von 84 auf 94 sowie von 94 auf 104 Zustände ein Faktor 3 festzustellen,
die Verifikationszeit bei maximaler Zustandszahl beträgt schon über 3
Minuten. Bei einer Verifikation auf einer anderen, nicht so schnellen Hardware 3
benötigt der Verifizierer für das System mit 7 Shuttles (104 Zustände) schon über
2 Stunden! Diese Zahl verdeutlicht die doch schon relativ große Komplexität
des Model-Checkings bei einem doch recht einfachen Beispiel sehr gut.
Eigenschaft Nr.2
Zu einem Zeitpunkt t wird immer nur eine Weiche geschaltet.
Die Prüfformel für diese Systemeigenschaft ist schon etwas komplexer. Aus
3.2.2 ist bekannt, dass eine Weiche 4 Zustände besitzt, weiche ist rechts,
weiche ist links, S1, S2. Befindet sich nun eine Weiche zu einem Zeitpunkt
t im Zustand S1 bzw. S2, die Weiche schaltet also gerade, muss die andere
Weiche entweder im Zustand weiche ist rechts bzw. weiche ist links sein.
Dieses muss für beide Weichen zu jedem Zeitpunkt des Systemablaufes gelten.
Unter Verwendung der in 2.1.3 vorgestellten Operatoren ergibt sich folgende
Prüfformel:
A□ (((weiche 1.S1 or weiche 1.S2) imply (weiche 2.weiche ist links
or weiche 2.weiche ist rechts)) and ((weiche 2.S1 or weiche 2.S2)
imply (weiche 1.weiche ist links or weiche 1.weiche ist rechts)))
2 auf folgender Hardware: Dual Intel Pentium III Prozessor, 933 MHz, 512 MB Hauptspeicher;
OS: Linux, Debian Distribution
3 Intel Pentium III 450 MHZ, 128 MB Hauptspeicher; OS: Windows 98

42 KAPITEL 3. FALLSTUDIE
Die zeitliche Auswertung des Verifikationsprozesses ergibt ein ähnliches Bild wie
oben was den Faktor des Zeitanstieges betrifft. Auffällig ist, dass die Verifikation
hier allgemein in kürzerer Zeit geschieht. Das ist dadurch zu erklären, dass im
obigen Fall alle Zustände des Systems überprüft werden mussten, im vorliegenden
Fall lediglich eine eingeschränkte Menge.
Anz. Shuttle Anz. Zustände Verifikationszeit Anforderung
Instanzen des Systems (in Sek.) erfüllt (j/n)
1 44 ≪ 1 j
2 54 ≪ 1 j
3 64 < 1 j
4 74 ≈ 2 j
5 84 ≈ 9 j
6 94 ≈ 32 j
7 104 ≈ 86 j
Eine weitere Verwendung des imply Operators zeigt die folgende Formel für die
nächste Bedingung.
Eigenschaft Nr.3
Eine Weiche muss arretiert sein, wenn sie von einem Shuttle passiert
wird.
A□ (shuttle 1.Weiche1 imply switch 1.arretiert==true)
bzw.
A□ (shuttle 1.Weiche2 imply switch 2.arretiert==true)
Da im System alle Shuttle-Instanzen gleichberechtigt sind, ist es egal, welche
in der Prüfformel verwendet wird. Wenn sich also ein Shuttle auf der Weiche1
befindet, hat die Variable arretiert der Weichensteuerungseinheit switch 1
bzw. switch 2 immer den Wert true, d. h. die Weiche ist in der Realität
arretiert.
Anz. Shuttle Anz. Zustände Verifikationszeit Anforderung
Instanzen des Systems (in Sek.) erfüllt (j/n)
1 44 ≪ 1 j
2 54 ≪ 1 j
3 64 < 1 j
4 74 ≈ 2 j
5 84 ≈ 8 j
6 94 ≈ 28 j
7 104 ≈ 83 j

3.2. UPPAAL (MARTIN HIRSCH) 43
Eigenschaft Nr.4
Wenn ein Shuttle nach Links, also auf die Schiene 2 fahren möchte,
gelangt es auch immer dorthin.
In der folgen Prüfformel kommt der in 2.1.3 erwähnte leadsto Operator zur
Verwendung. Wie an der formulierten Eigenschaft schon zu erkennen, soll eine
Fortschrittseigenschaft überprüft werden, d. h. trifft dieses Ereignis unter den
gegebenen Bedingungen in der Zukunft ein.
(shuttle 1.Weiche1 and richtung==links) −→ shuttle 1.S1
Anz. Shuttle Anz. Zustände Verifikationszeit Anforderung
Instanzen des Systems (in Sek.) erfüllt (j/n)
1 44 ≪ 1 j
2 54 ≪ 1 j
3 64 < 1 j
4 74 ≈ 2 j
5 84 ≈ 9 j
6 94 ≈ 32 j
7 104 ≈ 84 j
Eigenschaft Nr.5
Bevor ein Shuttle die Passage über Schiene 1, Schiene 3, Schiene 4
nimmt, sind beide Weichen bereits in der korrekten, also in der Rechten
Stellung arretiert.
Folgende Formel zeigt, wie mehrere Bedingunen in einer Prüfformel miteinander
verknüpft werden.
A□ (shuttle 1.Weiche1 and richtung==rechts) imply
((weiche 1.weiche ist rechts and weiche 2.weiche ist rechts)
and (switch 1.arretiert==true and switch 2.arretiert==true))
Anz. Shuttle Anz. Zustände Verifikationszeit Anforderung
Instanzen des Systems (in Sek.) erfüllt (j/n)
1 44 ≪ 1 j
2 54 ≪ 1 j
3 64 < 1 j
4 74 ≈ 3 j
5 84 ≈ 10 j
6 94 ≈ 32 j
7 104 ≈ 98 j
Trotz der komplexen Formel ist bei der Verifikationszeit kein großer Unterschied
zu den vorherigen Zeiten festzustellen.

44 KAPITEL 3. FALLSTUDIE
Eigenschaft Nr.6
Wenn ein Shuttle die Passage über Schiene 3 gewählt hat, hat das
Shuttel dieses Schienenstück nach spätestens 3 Zeiteinheiten wieder
verlassen.
A□ (shuttle 1.Weiche2 and von richtung==rechts) imply shuttle 1.x

3.2. UPPAAL (MARTIN HIRSCH) 45
Abbildung 3.6: Grafische Auswertung der Verifikationszeiten
Anstieg bei Erhöhung der Gesamtzustände sehr gut. Es ist ersichtlich, dass die
Verifikatonszeiten bei Systemen mit noch mehr Zuständen als im vorliegenden
Fall sprunghaft ansteigen werden.

46 KAPITEL 3. FALLSTUDIE
3.3 SMV (Markus Zarbock)
3.3.1 Allgemeine Bemerkungen
In diesem Kapitel soll der Ansatz, die Fallstudie in SMV zu modellieren vorgestellt
werden. Zunächst sollen einige grundlegende Betrachtungen zur Machbarkeit
gemacht werden. Dann soll die Modellierung der einzelnen Komponenten
erläutert werden. Schließlich werden die Spezifikationen vorgestellt, die das Modell
überprüfen sollen bzw deren Ergebnisse und Rechenaufwände.
Vorgehensweise
Zunächst gilt es die, für die Modellierung notwendigen Komponenten zu indentifizieren.
Dazu nocheinmal die Übersichtsgrafik (Abbildung 3.7) aus dem
Einführungskapitel .
Abbildung 3.7: Die ISILEIT-Fallstudie
Um diesen Auschnitt zu modellieren müssen die in der Grafik erkennbaren Blöcke
modelliert werden. Auf die möglichen Kommunikationsprobleme zwischen den
Komponenten wird im folgenden Modell nicht eingegangen. Welchen Einfluss
sie auf die Ergebnisse haben, muss in einem nächsten Verfeinerungsschritt des
Modells überprüft werden. Wenn man die einzelnen Komponenten betrachtet,
so fällt auf, dass es für die Weichen eine Doppelstruktur gibt. Auf der
einen Seite das physikalische Modell,z.B. die tatsächlich existierende Weiche und
auf der anderen Seite die Instanz, die diese steuert, z.B. die Weichensteuerung
(Switch1,Switch2). Diese Struktur muss nun in der Modellierung ihre Entsprechung
finden. Dies kann auf verschiedene Arten geschehen. Der aufwändigste
Ansatz ist, die physikalischen Eigenschaften der mechanischen/elektrischen

3.3. SMV (MARKUS ZARBOCK) 47
Geräte zu modellieren. Beispielsweise können die Bewegungen der Shuttles, beschleunigen,
fahren, bremsen durch entsprechende Gleichungssysteme modelliert
werden. Sind physikalisches Modell und Steuerinstanz modelliert, so ergibt sich
die in 3.8 abgebildete Struktur.
Abbildung 3.8: Modellieren
Für den Systemausschnitt Weiche, Ventilinsel, Weichensteuerung wird im folgende
Kapitel gezeigt, wie eine solche Modellierung realisiert werden kann. Das
sich daran anschließende Kapitel wird die Modellierung des Koordinators behandeln.
Zwischen den Modelierungen dieser beiden Blöcke gibt es einen wichtigen Unterschied.
Die Shuttles, die der Koordinator steuert, werden nicht als physiklisches
Modell mitmodelliert. Die Ursache hierfür liegt in der komplexen Natur der
Shuttles, die zu modellieren den Rahmen dieser Arbeit gesprengt hätte. Da der
prinzipielle Weg jedoch für die Weichen aufgezeigt wird, lässt sich dieses Problem
jedoch in späteren Arbeiten wiederaufgreifen.
3.3.2 Das Weichenmodell
In diesem Kapitel soll gezeigt werden, wie die Weiche und ihre Steuerung modelliert
werden können. Die Weiche ist ein System, das grob betrachtet nur
zwei Zustände besitzt. Diese entsprechen den beiden Richtungen, in die sie geschaltet
sein kann. Dazu kommt ein Verriegelungsmechanismus, der die Weiche
mechanisch arretiert, sobald sie einen sicheren Zustand erreicht hat (geradeaus,
abbiegend). Der Antrieb dieser Weiche wird durch die Ventilinsel erzeugt. Über
ein Ventil wird die Richtung der Weiche festgelegt und ein pneumatischer Zylinder
steuert die Arretierung. Der Weichenkontroller steuert die Weiche nicht

48 KAPITEL 3. FALLSTUDIE
direkt, sondern gibt seine Befehle auf elektrischem Wege der Ventilinsel, die diese
dann in pneumatische Steuerimpulse umwandelt. Daher ist die Ventilinsel eigentlich
nur ein Mediumswechsler für die Kommunikation zwischen Weiche und
Steuerung. Für spätere Abstraktionsschritte ist daher denkbar, die Ventilinsel
wegzulassen und durch ein allgemeineres Kommunikationsmodell zu ersetzen. In
dieser Arbeit wird sie jedoch betrachtet. Deswegen kann man die in Abbildung
3.8 gezeigte Grafik auf die in Abbildung 3.9 gezeigte Art erweitern.
Abbildung 3.9: Modellieren 2
Die drei dort dargestellten Module gilt es also zu modellieren.
Die Weiche
Das Modul switcher soll das physikalische Verhalten einer Weiche nachbilden.
Für diese Modellierung wird das Verhalten der Weiche jedoch vereinfacht. Das
Schaltverhalten der Weiche ist in der Realität eine kontinuierliche Bewegung.
Diese wird im Model auf diskrete Übergänge abstrahiert. Abbildung 3.10 zeigt
den endlichen Automaten, der dem Weichenmodell entspricht. Fett sind sind die
für die Transition notwendigen Vorbedingungen dargestellt, normal die bei der
Transition vorgenommenen Änderungen. Alle Variablen dieses Moduls haben
bool’sche Werte, mit Ausnahme der Zustandsvariablen. Die Werte der beiden
Näherungssensoren, mit deren Hilfe festegestellt wird, in welche Richtung
die Weiche geschalten ist, werden als approxSensorEven und approxSensorSwitched
gespeichert. Diese Sensoren werden von der Weiche nur dadurch ausgelöst,
dass das Schienenstück am Ende des Schaltvorgangs gegen einen solchen Sensor
stösst. Daher könnten die Sensoren auch in ein extra Modul verlagert werden,
dass dann nur die Sensoren enthielte. Wenn das Weichenmodell durch exaktere
Modellierung der physikalischen Eigenschaften komplexer würde, wäre eine eine

3.3. SMV (MARKUS ZARBOCK) 49
solche Verlagerung sinnvoll, da so Spezifikationen abgestufter geprüft werden
könnten. Für diese Modellierung sind diese Sensoren jedoch Teil der Weiche. Da
Sensoren und Weiche in der Realität in einem Block verbaut sind erscheint diese
Vorgehensweise auch intuitiver. Desweiteren hat die Weiche eine Variable lock,
die die Arretierung modellieren soll. Zwei weitere Variablen modellieren die von
der Ventilinsel kommenden Druckleitungen. Die Druckvariablen unterscheiden
sich insofern von den restlichen Variablen, als sie nicht bei Zustandsübergängen
verändert werden, sondern von außerhalb gesetzt werden.
Dieses Weichenmodell enthält keine Fehlerbehandlung, wie es später im Weichencontroller
der Fall ist. Es soll ausschließlich steuerungslose Mechanik/Pneumatik
modellieren. Daher kann auf eine spezifische Modellierung der beiden Weichen
verzichtet werden und stattdessen werden zwei Instanziierungen des gleichen
Moduls verwendet. Dies entspricht auch der Realität, in der es möglich ist, eine
Weiche an beiden Positionen einzubauen.
Abbildung 3.10: Weiche
Die Ventilinsel
Das Modul pressureDistributor modelliert die Ventilinsel. Sie setzt die elektrischen
Steuerimpulse, des Weichencontrollers in Druckimpulse um, die dann
die Weiche selbst steuern. Eine Weiche kann zwei mögliche Zustände einnehmen,
geradeaus und abgebogen. Bei zwei Weichen, muss die Ventilinsel
also vier verschiedene Druckbeschaltungen ermöglichen. Diese vier notwendigen
Zustände stellt die Variable control dar. Je nach deren Wert werden die Druckleitungen
befüllt. Ist beispielsweise control = oneEven, so wird die Leitung
pressureEven, der ersten Weiche befüllt (bzw auf true gesetzt). Die Ventilinsel
erhält bei der Instanziierung, Referenzen, auf die Weichenmodelle und kann
so deren Variablen, wie oben beschreiben setzen. Dieses Modell ist passiv insofern,
als die Variable control innerhalb des Moduls nicht verändert wird, es ist
also ein Anstoß von aussen notwendig. Diesen löst die Weichensteuerung aus.

50 KAPITEL 3. FALLSTUDIE
Die Weichensteuerung
Die Steuerung einer Weiche wird durch die Module leftSwitchController und
rightSwitchController modelliert. Es wurde für jede Weiche ein eigenes Steuermodell
geschrieben, weil jeder Controller Steuersignale für eine spezielle Weiche
schicken muss. Grafik 3.11 zeigt, den endlichen Automaten, der dem Controller
der linken Weiche ( in Abbildung 3.12 mit one bezeichnet) entspricht.
Wie in Abbildung 3.10 gilt, fett sind sind die für die Transition notwendigen
Vorbedingungen dargestellt, normal die bei der Transition vorgenommenen
Änderungen. Prinzipiell könnte auch ein Controller modelliert werden, der festellt,
welche Weiche er zu steuern hat. Allerdings sind generische Strukturen in
SMV erheblich schwieriger zu modellieren, als sie in imperativen Programmiersprachen
zu implementieren sind. Hier sei auf die single assignment Regel (siehe
2.2.2) verwiesen.
Abbildung 3.11: Weichencontroller
Die Beschreibung des Controllers für die linke Weiche ist beispielhaft für den der
Rechten. Es müssen im wesentliche nur die Steuerkommandos an die Ventilinsel
ensprechend verändert werden. Der Automat des Weichenmodells (Abbildung
3.10) ähnelt dem des Controller (Abbildung 3.11). Dies ist damit zu begründen,
dass die Software des Controllers die Realität abbilden muss, um Steuerkommandos
geben zu können. Die Zustandsübergänge werden mit bool’schen Wert
commitSwitch angestossen, dieser wird von ausserhalb des Controllers gesetzt
und modelliert so die Steuerleitung vom Koordinator zum Weichencontroller.
Die Zustandsmenge entspricht dem des Weichenmodells, erweitert um einen Fehlerzustand.
Dieser wird immer dann ausgelöst, wenn Fehler in der Steuerung
auftreten, zum Beispiel wenn ein falscher Sensor ausgelöst wird. Allerdings
findet in der vorliegende Modellierung im Koordinator noch keine Behandlung
einer solchen Fehlersituation statt. In Abbildung 3.11 ist allerdings nur ein

3.3. SMV (MARKUS ZARBOCK) 51
Zustandsübergang in einen Fehlerzustand abgebildet, dieser Übergang ist beispielhaft,
für alle anderen (siehe hierzu B.1).
Weiterhin hält der Controller in einer bool’schen Variable, die Information, ob
die Weiche verfügbar ist. Dies ist immer dann der Fall, wenn die Weiche in einem
arretierten Zustand ist. Ob eine Weiche durch ein Shuttle belegt ist ist dem Weichencontroller
jedoch unbekannt und wird daher auch nicht modelliert. Daher
findet vor dem Schalten auch keine Überprüfung statt, ob sich auf der Weiche
ein Shuttle befindet, wird commitSwitch durch den Koordinator gesetzt schaltet
der Weichencontroller. Dies geschieht indem die Steuervariable (control) der
Ventilinsel gesetzt wird.
3.3.3 Der Koordinator
Vorbemerkungen
Die Modellierung des Koordinators unterscheidet sich erheblich von Modellierungen
der bisher betrachteten Komponenten der Fallstudie. Zunächst hat der
Koordinator eine wesentlich komplexere Augabe als beispielsweise der Weichencontroller.
Desweiteren gibt es für ihn keine eindeutig zuordnenbare physikalische
Entsprechung, er ist als Software realisiert.
Umsetzung
Der hier vorgestellte Ansatz folgt im wesentlichen der Idee, für jedes Shuttle im
Koordinator eine steuernde Instanz zu schaffen, die einerseits alle notwendigen
Daten des Shuttles enthält und andererseits die notwendigen Entscheidungen
treffen kann, um ein Shuttle durch das System zu steuern. Daher gibt es in dieser
Realisierung kein eigenes Modul für den Koordinator, es werden stattdessen
im Hauptmodul eine Reihe von Shuttlemodulen instanziiert. Um die Shuttles
zu koordinieren, muss ein gegenseitiger Auschluss für die Weichen realisiert werden,
dies geschieht über das Modul channel, das für jede Weiche eine Variable
hält, die entscheidet, ob ein Weiche belegt ist oder nicht. Darüberhinaus gibt
es ein Modul track, das speichert, ob ein Gleisabschnitt von einem Shuttle befahren
ist. Die Module shuttle, channel und track bilden zusammen den
Koordinator. Um die Gleisschlaufe mit den beiden Weichen darzustellen, sind
die Gleismodule wie in 3.12 angeordnet. Die Weichen erhalten erhalten in den
Shuttleprozessen die Nummern 11 und 12. Es gibt jedoch in den Gleismodulen
keine Verweise, auf Nachbarn oder ähnliches, die Topologie wird nur durch die
Steuerung der Shuttles festgelegt. Da es keine Zeiger in SMV gibt und komplexe
Datentypen rechenzeitproblematisch sind, erschien diese Art der Repräsentation
des Gleissystems am plausibelsten. Die physikalische Länge, die ein Gleismodul
modellieren soll entspricht einer Shuttlelänge, das bedeutet, das in der vorliegenden
Modellierung der Koordinator erheblich präziser festellen kann, wo sich
ein Shuttle aktuell befindet. Diese Einschränkung ließe sich umgehen, wenn
es für ein Shuttle ein physikalisches Bewegungsmodell gäbe, aus welchem für
den Koordinator entsprechende Zeitannahmen gemacht werden könnten. Die
Schlaufe unterhalb der Weichen wurde eingefügt, um kontinuierliche Shuttlebewegungen
zu ermöglichen. Die Verbindung oberhalb der Weichen, kann in einer
nächsten Entwicklungsphase verwendet werde, um dort die Beladungsautomatik

52 KAPITEL 3. FALLSTUDIE
Abbildung 3.12: Modellieren 2
einzufügen.
Als Zeitmodell wurde für alle Modulinstanzen das asynchrone verwendet, da
mit einem synchronen Modell grundlegende Eingenschaften, der Fallstudie nicht
hätten modelliert werden können. Beispielsweise werden die Shuttles nicht synchron
im System bewegt, während eines beladen wird, soll ein anderes eine
Weiche passieren können.
Probleme
Bei der Entwicklung des Koordinatormodells ergaben sich eine Reihe von Problemen.
Durch die Entscheidung jedem Shuttle einen es steuernden Prozess
zuzuordnen, geht die Reihenfolgeunabhängikeit der Shuttles verloren. Wird ein
Shuttleprozess instanziiert so muss entschieden werden, auf welchem Gleisabschnitt
dies geschieht. Im vorliegenden Modell wurde darauf verzichtet, eine
Methode zu entwickeln, der Shuttles zufallsbasiert auf Gleise verteilt und so die
Reihenfolgeunabhängigkeit wiederherzustellen.
3.3.4 Modelchecking
In diesem Abschnitt werden die Spezifikationen vorgestellt, denen das modellierte
System genügen muss. Die in Kapitel 3.1 vorgestellte Liste mit Bedingungen
diente hierzu als Orientierung. Die präzise Übernahme, war bei einigen
nicht möglich. Beispielsweise verfügt SMV über keinen vordefinierten Mechanismus,
um Deadlockfreiheit zu garantieren. Eine Möglichkeit, diese Bedingung
mit SMV zu spezifizieren wäre einen Fortschritt zu definieren und zu zeigen,
dass dieser in jedem Zustand möglich ist. Der Aufwand, für ein solches System
eine Fortschritt zu definieren hätte den Rahmen dieser Arbeit jedoch gesprengt.

3.3. SMV (MARKUS ZARBOCK) 53
Alle hier aufgeführten Zahlen wurden mit folgender Rechnerausstattung ermittelt:
Pentium 4 1,7 GHz, 1GB RAM, RedHatLinux 7.2.
Shuttles pro Gleis/Weiche
Eine grundsätzliche Forderung, denen das System grundsätzlich genügen muss,
ist die, dass sich zu keinem Zeitpunkt mehr als ein Shuttle auf einem Gleisstück,
bzw einer Weiche befinden darf. Die Spezifikation, die für die Prüfung dieser
Bedingung ermöglichen soll, fragt ab, ob die Gleisvariablen der Shuttles gleich
sind. Daraus ergibt sich, dass die Anzahl der Shuttle auch die Spezifikation
ändert. So lautet die Formel für fünf Shuttles:
notMoreThanOneOnSameTrack5 :
assert G ~((s1.myTrack = s2.myTrack) | (s1.myTrack = s3.myTrack)
| (s1.myTrack = s4.myTrack) | (s1.myTrack = s5.myTrack)
| (s2.myTrack = s3.myTrack) | (s2.myTrack = s4.myTrack)
| (s2.myTrack = s5.myTrack) | (s3.myTrack = s4.myTrack)
| (s3.myTrack = s5.myTrack) | (s4.myTrack = s5.myTrack));
Die Prüfung dieser Bedingung in einem System mit weniger als fünf Shuttles,
geschieht nach einem ähnlichen Muster. Hier nun die Ergebnisse dieser Prüfung.
Anz. Shuttle Anz. BDD-Knoten Verifikationszeit Anforderung
Instanzen (in Sek.) erfüllt (j/n)
2 65.675 0,83 j
3 96.893 1,2 j
4 394.239 11.47 j
5 1.157.910 115.15 j
Sowohl die Zeitangaben als auch der mitt BDD-Knoten repräsentierte Zustandsraum,
verdeutlichen den enormen Anstieg, bei steigender Shuttlezahl. Interessant
ist auch, daß die Rechenzeit erheblich schneler ansteigt, als der Zustandsraum.
Im Schritt von vier auf fünf Shuttles steigt die Größe des Zustands etwa
mit dem Faktor vier, die Rechenzeit jedoch etwa um den Faktor 10.
Weichenschalten
Aufgrund der Konstruktion der Ventilinsel (siehe Abbildung 3.7) ist es nicht
möglich mehr als eine Weiche gleichzeitig zu schalten. In zwei Schritten wird gezeigt,
dass das Modell dieser Forderung entspricht. Im ersten Schritt, werden die
Weichenmodelle darauf überprüft, ob ihre Zustandsvariablen gleichzeitig in der
Menge (switchingToSwiched,switchingToEven) sind. Dies kann nur geschehen,
wenn beide Weichen gleichzeitig schalten oder ein Schaltvorgang nicht atomar
ist. Die Spezifikation dazu:
switches1 :
assert G ~(one.state ={switchingToSwitched,switchingToEven}
& two.state ={switchingToSwitched,switchingToEven});

54 KAPITEL 3. FALLSTUDIE
Die Auswertung dieser Spezifikation führte zu folgenden Ergebnissen:
Anz. Shuttle Anz. BDD-Knoten Verifikationszeit Anforderung
Instanzen (in Sek.) erfüllt (j/n)
5 946.441 106.77 j
Analog dazu muss ebenfalls überprüft weren, ob die Weichencontroller gleichzeitig
den Schaltbefehl geben. Die Überprüfung dieser Forderung geschieht auf
sehr ähnliche Weise, wie die für die Weichenmodelle.
switches2 :
assert G ~(controlOne.state ={switchingToSwitched,switchingToEven}
& controlTwo.state ={switchingToSwitched,switchingToEven});
Diese Spezifikation wurde mit folgendem Ergebnis auf das Modell angewendet:
Anz. Shuttle Anz. BDD-Knoten Verifikationszeit Anforderung
Instanzen (in Sek.) erfüllt (j/n)
5 946.441 103.77 j
Weichen überfahren
Fährt ein Shuttle über eine Weiche so muss diese sich in einem der arretierten
Zustände befinden, also geradaus oder abgebogen. Befindet sich die Weiche in
einem Umschaltvorgang, so darf ein Shuttle nicht über diese Weiche fahren. Mit
zwei Spezifikationen wird diese Eigenschaft überprüft. In beiden wird geprüft,
dass es nicht vorkommen kann, dass ein Shuttle auf einer Weiche steht (Gleis 11
oder 12) und gleichzeitig die Variable lock false ist. In SMV Notation:
lockedOne2 :
assert G ~((s1.myTrack = 11 | s2.myTrack = 11
| s3.myTrack = 11 | s4.myTrack = 11 | s5.myTrack = 11)
& ~one.lock);
Die Prüfung dieser Spezifikation führte zu folgenden Ergebnissen:
Anz. Shuttle Anz. BDD-Knoten Verifikationszeit Anforderung
Instanzen (in Sek.) erfüllt (j/n)
5 1.156.454 116.89 j
Dieselbe Forderung gestellt für die zweite Weiche:

3.3. SMV (MARKUS ZARBOCK) 55
lockedTwo2 :
assert G ~((s1.myTrack = 12 | s2.myTrack = 12
| s3.myTrack = 12 | s4.myTrack = 12 | s5.myTrack = 12)
& ~two.lock);
Mit folgenden Ergebnissen:
Anz. Shuttle Anz. BDD-Knoten Verifikationszeit Anforderung
Instanzen (in Sek.) erfüllt (j/n)
5 1.141.572 116.72 j
Weichen arretieren
Wenn eine Weiche schaltet, so muss dazu die Arretierung gelöst sein. Die folgenden
zwei Spezifikationen überprüfen dies für die beiden Weichen.
lockedOne :
assert G ~(one.lock & one.state ={switchingToSwitched,switchingToEven});
lockedTwo :
assert G ~(two.lock & two.state ={switchingToSwitched,switchingToEven});
Mit folgenden Ergebnissen:
Spezifikation Anz. BDD-Knoten Verifikationszeit Anforderung
(in Sek.) erfüllt (j/n)
lockedOne 971.964 105.1 j
lockedTwo 932.678 100.87 j

Kapitel 4
Zusammenfassung
4.1 Zusammenfassung SMV (Markus Zarbock)
Als ein Ergebnis der Untersuchungen zur Fallstudie, kann man SMV als taugliches
Werkzeug zur Modellierung von Systemen der hier vorgestellten Art. Allerdings
gilt dies mit einigen Einschränkungen.
Zunächst ist das Fehlen einer grafischen Repräsentation des modellierten Systems
ein erheblicher Nachteil. Beispielsweise die Strukuren, die sich durch
die Übergabe von Referenzen bei der Instanziierung von Modulen, ergeben,
sind ohne eine solche Repräsentation nur schwer nachzuvollziehen. Als Vergleich
können hierzu Assoziationen aus objektorientierten Sprachen dienen, auch
dort sind grafische Mittel gut geeignet, um Verständnis und Fehlersuche zu unterstützen.
Problematisch ist weiterhin die auschliessliche Verwendung von LTL. Wenn man
nur auf Codeebene ein Modell entwickelt und auf Korrektheit im Sinne der korrekten
Umsetzung des existierenden Systems in ein SMV Modell prüfen will ist
LTL ein umständliches Mittel. Mit CTL lassen sich, wie in ( 2.2.3) gezeigt,
typische Anfragen besser formulieren. Da SMV mit der alten Syntax CTL implementiert,
mit der neuen aber LTL sollte möglich sein, in späteren Versionen
sowohl CTL als auch LTL als Spezifikationskalkül zu verwenden.
Eine weitere Einschränkung ist zweifelsohne die notwendige Rechenzeit, um hinreichend
komplexe Systeme zu prüfen. Die für diese Fallstudie notwendigen Rechenzeiten
lassen vermuten, dass SMV angewand auf komplexe Softwaresysteme
rasch an die Grenzen der heute verfügbaren Rechenleistung dringt. Daher ist es
für solche Systeme notwendig Strategien zu entwickeln diese in kleinere Einheiten
zu zerlegen und so die Prüfungen von Spezifikationen erst möglich zu machen.
Ein interessanter Ansatz dazu ist in [16] beschrieben. Dort werden State Flow
Diagramme mittels automatischer Verfahren in SMV Modelle übersetzt. Wenn
es gelänge, dieses Verfahren auf die sehr ähnlichen State Chart Diagramme aus
der UML 1 azuwenden, so wäre es denkbar die mit CASE 2 Tools, wie zum Beispiel
FUJABA 3 entwickelte Software automatisch in SMV Modelle zu übersetzen
1 Unified Modelling Language
2 Computer Aided Software Engineering
3 From UML to Java and back again; www.FUJABA.de
57

58 KAPITEL 4. ZUSAMMENFASSUNG
und somit einen großen Schritt in Richtung automatischer Softwareverifikation
zu gehen.
Bezüglich der Fallstudie sind für den Modellierungsprozess noch eine ganze Reihe
von Verfeinerungen denkbar. So sollten die Shuttles, analog zu den Weichen,
ebenfalls als physikalisches Modell erfasst werden. Ein weiterer wichtiger Aspekt
sind Fehlermodellierungen. Wenn die vorhandenen Komponenten alle als Modell
erfasst sind, wäre der nächste Schritt Fehlermöglichkeiten mitzumodellieren,
beispielweise den Ausfall oder die Störung der Kommunikation.
Prinzipiell ist es also möglich eine Reihe grundsätzlicher Probleme bei der Modellierung
von komplexen Systemen mit dieser Fallstudie nachzuvollziehen.
4.2 Zusammenfassung Uppaal (Martin Hirsch)
Uppaal ist ein Werkzeug, das sich besonders für die Modellierung von Echtzeitsystemen
eignet, die man gut durch Automaten darstellen kann.
Durch einen grafischen Editor zum Erstellen der Automaten wird die Modellierung
allgemein erleichtert. Der integrierte Simulator hilft schon in der Modellierungsphase,
das System ständig zu überprüfen und Fehler ausfindig zu machen.
TCTL, die Verifikationssprache für die Prüfformeln, ist relativ leicht, auch ohne
Vorkenntnisse zu verstehen und anzuwenden. Diese Punkte machen Uppaal zu
einem Model-Checker, der sehr gut in der Praxis einzusetzen ist.
Trotz der durch Uppaal recht gut unterstützen Modellierung von Automaten
ist die Modellierungsphase jedoch nicht zu unterschätzen. Wie in dieser Arbeit
deutlich gemacht, besteht ein Großteil dieser Phase auch in Überlegungen, wie
ein System zu realisieren ist und zu entscheiden, was wichtig und unwichtig ist
für die Modellierung. Hier spielt der Grad der Abstraktion eine große Rolle.
Durch eine hohe Abstraktion ist das Modell häufig leichter und schneller zu
verifizieren, da das System im Allgemeinen aus weniger Zuständen besteht. Jedoch
bedeutet dies auf der anderen Seite meistens eine starke Idealisierung des
Systems, so dass Probleme, die im realen System auftreten können und die es
gilt herauszufinden, vernachlässigt oder übersehen werden können.
Schließlich steht am Ende der Modellierungsphase der Prozess der Verifikation,
das eigentliche Model-Checking. Für diesen Vorgang müssen die meist umgangssprachlich
vorgegebenen Regeln und Anforderungen an das System auf
Prüfformeln in TCTL abgebildet werden. Hierbei ist darauf zu achten, dass
auch wirklich genau das Geforderte abgebildet wird.
Das in der Arbeit in Uppaal modellierte Materialflusssystem, ein Ausschnitt aus
der ISILEIT-Fallstudie [18, 5], zeigt die Wichtigkeit des Model-Checkings in der
Praxis.
Es hat sich gezeigt, das Uppaal sich für das Model-Checking auf dem Gebiet der
Steuerungsanlagen im Fertigungsbereich gut eignet. Diskrete, untereinander
kommunizierende reaktive Systeme mit Echtzeitverhalten lassen sich sehr gut
durch Echtzeitautomaten, wie sie in Uppaal vorkommen, darstellen.

4.2. ZUSAMMENFASSUNG UPPAAL (MARTIN HIRSCH) 59
Die Modellierung des in dieser Arbeit ausgewählten Ausschnittes aus der ISILEIT-
Fallstudie ist so konzipiert, dass sich Erweiterungen auf die übrigen Teile der
Fallstudie leicht vornehmen lassen. Verifikationszeiten von momentan maximal
4 Minuten auf heutiger Standardhardware lassen dieses ohne weiteres realisieren.
Allerdings wäre für diese Aufgabe eine genauere Beschreibung seitens der SPS
Programmierung notwendig, um die Abläufe besser darstellen zu können. Ebenfalls
wären genauere Zeitangaben über die Abläufe notwendig, da Uppaal gerade
hier seine Stärken besitzt.

Anhang A
Uppaal Quellcode (Martin Hirsch)
In diesem Abschnitt ist der Quellcode der Automaten aufgelistet, die in Kapitel
3.2.2 nur textuell bzw. visuell dargestellt wurden.
A.1 Quellcode: Deklarationen der globalen Variablen,
Automaten Instanziierungen und
System Definition
Der Quellcode: Deklarationen
1 // ************** Beginn Konstantendeklarationen *********************
2 // Einige Konstendeklarationen, damit es "ubersichtlicher ist ;-)
3 const rechts 1;
4 const links 0;
5 const true 1;
6 const false 0;
7 // ************** Ende Konstantendeklarationen ***********************
8
9 // ************** Beginn der Kanaldefinitionen ***********************
10 // Jedes Schienest"uck besitzt einen Sensor, der dem Controller meldet,
11 // wenn ein Shuttle eine Weiche passieren m"ochte
12 chan sensor_1,sensor_2,sensor_3,sensor_4;
13
14 // Die Kommunikatioskan"ale zwischen den SPS’en Switch_1 bzw. Switch_2
15 // und dem Controller
16 chan weiche_geschaltet_1,weiche_geschaltet_2;
17 chan steuer_weiche_1,steuer_weiche_2;
18
19 // jedes Shuttle bekommt eine Impuls, wenn es "uber
20 // an der Sensorstation weiterfahren darf
21 urgent chan weiter_1,weiter_2,weiter_4;
22
23 // die Kommunikationskan"ole zwischen Switch und der Ventilinsel
24 chan druckluft_weiche_rechts_1, druckluft_weiche_links_1,
25 druckluft_weiche_rechts_2, druckluft_weiche_links_2;
26
27 // die Signalleitungen zwischen Ventilinsel und der eigentlichen
28 // Weiche
29 chan druckluft_1,druckluft_2;
30
31 // die Benachrichtigung von der Weiche an de Switch, dass die
32 // Weiche die neue Entstellung erreicht hat
33 chan naeherungs_sensor_rechts_1,naeherungs_sensor_links_1,
34 naeherungs_sensor_rechts_2,naeherungs_sensor_links_2;
35 // ************** Ende der Kanaldefinitionen *************************
36
37 // ************** Beginn Variablendeklarationen **********************
61

62 ANHANG A. UPPAAL QUELLCODE (MARTIN HIRSCH)
38 // "Boolsche" Varibalen
39 int [0,1] richtung, von_richtung;
40 int [0,1] weichen_position_1,weichen_position_2;
41 // ************** Ende Variablendeklarationen ************************
42
43 // ************** Uhren **********************************************
44 // die globale Uhr
45 clock clk;
46
47 // ************************ Automaten Instanziierungen ***************
48 weiche_1 := Weiche(druckluft_1,naeherungs_sensor_links_1,naeherungs_sensor_rechts_1);
49 weiche_2 := Weiche(druckluft_2,naeherungs_sensor_links_2,naeherungs_sensor_rechts_2);
50
51 // Ventilinsel
52 ventilinsel := Ventilinsel();
53
54 // Switch 1 & 2
55 switch_1 := Switch(steuer_weiche_1,weiche_geschaltet_1,
56 druckluft_weiche_links_1,
57 druckluft_weiche_rechts_1,
58 naeherungs_sensor_links_1,
59 naeherungs_sensor_rechts_1,
60 richtung,weichen_position_1);
61 switch_2 := Switch(steuer_weiche_2,weiche_geschaltet_2,
62 druckluft_weiche_links_2,
63 druckluft_weiche_rechts_2,
64 naeherungs_sensor_links_2,
65 naeherungs_sensor_rechts_2,
66 von_richtung,weichen_position_2);
67
68 // MasterController
69 controller := Controller();
70
71 // Shuttles
72 shuttle_1 := Shuttle();
73 shuttle_2 := Shuttle();
74 shuttle_3 := Shuttle();
75 shuttle_4 := Shuttle();
76 shuttle_5 := Shuttle();
77 shuttle_6 := Shuttle();
78 shuttle_7 := Shuttle();
79
80 // System Definition
81 system weiche_1, weiche_2, ventilinsel, switch_1, switch_2,
82 controller, shuttle_1,shuttle_2,shuttle_3,
83 shuttle_4,shuttle_5,shuttle_6,shuttle_7;
A.2 Quellcode: Weiche
Der Quellcode Weiche
1 process Weiche(chan druckluft,
2 naeherungs_sensor_links,
3 naeherungs_sensor_rechts)
4 {
5 clock x;
6
7 state weiche_ist_rechts,weiche_ist_links,
8 S2{x weiche_ist_rechts{guard x>=1;
15 sync naeherungs_sensor_rechts!;
16 assign x:=0; },
17 weiche_ist_rechts -> S2{sync druckluft; assign x:=0; },

A.3. QUELLCODE: VENTILINSEL 63
18 S2 -> weiche_ist_links{guard x>=1;
19 sync naeherungs_sensor_links!;
20 assign x:=0; };
21 }
A.3 Quellcode: Ventilinsel
1 process Ventilinsel
2 {
3 clock x;
4
Der Quellcode Ventilinsel
5 state S3{x S0{sync druckluft_weiche_rechts_1;
14 assign x:=0; },
15 S0 -> start{guard x>=1;
16 sync druckluft_1!; },
17 start -> S1{sync druckluft_weiche_links_1;
18 assign x:=0; },
19 S1 -> start{guard x>=1;
20 sync druckluft_1!; },
21 start -> S3{sync druckluft_weiche_links_2;
22 assign x:=0; },
23 S3 -> start{guard x>=1;
24 sync druckluft_2!; };
25 }
A.4 Quellcode: Koordinator
Der Quellcode Controller
1 process Controller
2 {
3 int[0,1] ventilinsel_belegt:=0;
4 int anzahl:=0;
5 int [0,1] zustand_sensor_1:=0,zustand_sensor_2:=0,
6 zustand_sensor_3:=0,zustand_sensor_4:=0;
7 int [0,1] gleis_belegt_1:=0,gleis_belegt_2:=0,
8 gleis_belegt_3:=0,gleis_belegt_4:=0;
9 int [0,1] weiche_ist_geschaltet_1:=0,weiche_ist_geschaltet_2:=0;
10 int[0,1] route_1:=0,route_2:=0;
11 int [0,1] weiche_belegt_1:=0,weiche_belegt_2:=0;
12 int[0,1] bewege_weiche_1,bewege_weiche_2;
13
14 state S0;
15 init S0;
16
17 trans
18 S0 -> S0{guard zustand_sensor_1==false;
19 sync sensor_1;
20 assign zustand_sensor_1:=true, richtung:=rechts; },
21 S0 -> S0{guard zustand_sensor_2==false;
22 sync sensor_2;
23 assign zustand_sensor_2:=true,gleis_belegt_2:=false; },
24 S0 -> S0{guard zustand_sensor_1==true, richtung==rechts,
25 weiche_belegt_1==false, weiche_belegt_2==false;

64 ANHANG A. UPPAAL QUELLCODE (MARTIN HIRSCH)
26 assign weiche_belegt_1:=true, bewege_weiche_1:=true,
27 bewege_weiche_2:=true, route_1:=true,
28 weiche_belegt_2:=true, von_richtung:=rechts; },
29 S0 -> S0{guard zustand_sensor_1==false;
30 sync sensor_1;
31 assign zustand_sensor_1:=true, richtung:=links; },
32 S0 -> S0{guard zustand_sensor_1==true, richtung==links,
33 weiche_belegt_1==false;
34 assign weiche_belegt_1:=true, bewege_weiche_1:=true; },
35 S0 -> S0{guard richtung==rechts, weiche_ist_geschaltet_2==true,
36 weiche_ist_geschaltet_1==true, gleis_belegt_4==false;
37 sync weiter_1!;
38 assign weiche_ist_geschaltet_1:=false, weiche_ist_geschaltet_2:=false,
39 zustand_sensor_1:=false, gleis_belegt_4:=true; },
40 S0 -> S0{guard zustand_sensor_2==true, weiche_belegt_2==false;
41 assign von_richtung:=links, weiche_belegt_2:=true,
42 bewege_weiche_2:=true; },
43 S0 -> S0{guard zustand_sensor_2==true, route_1==false,
44 weiche_ist_geschaltet_2==true, gleis_belegt_4==false;
45 sync weiter_2!;
46 assign weiche_ist_geschaltet_2:=false, zustand_sensor_2:=false,
47 weiche_belegt_2:=false, route_2:=true, gleis_belegt_4:=true; },
48 S0 -> S0{guard zustand_sensor_3==false;
49 sync sensor_3;
50 assign zustand_sensor_3:=true,weiche_belegt_1:=false; },
51 S0 -> S0{guard zustand_sensor_4==false, route_2==true;
52 sync sensor_4;
53 assign zustand_sensor_4:=true, route_2:=false, gleis_belegt_4:=false; },
54 S0 -> S0{guard zustand_sensor_4==true;
55 sync weiter_4!;
56 assign zustand_sensor_4:=false; },
57 S0 -> S0{guard zustand_sensor_4==false, route_1==true, route_2==false;
58 sync sensor_4;
59 assign zustand_sensor_4:=true, route_1:=false,
60 weiche_belegt_2:=false, zustand_sensor_3:=false,
61 gleis_belegt_4:=false; },
62 S0 -> S0{guard ventilinsel_belegt==false, bewege_weiche_1==true;
63 sync steuer_weiche_1!;
64 assign ventilinsel_belegt:=true, bewege_weiche_1:=false; },
65 S0 -> S0{guard ventilinsel_belegt==false, bewege_weiche_2==true;
66 sync steuer_weiche_2!;
67 assign ventilinsel_belegt:=true, bewege_weiche_2:=false; },
68 S0 -> S0{guard gleis_belegt_2==false, weiche_ist_geschaltet_1==true,
69 richtung==links;
70 sync weiter_1!;
71 assign gleis_belegt_2:=true, weiche_belegt_1:=false,
72 zustand_sensor_1:=false, weiche_ist_geschaltet_1:=false; },
73 S0 -> S0{sync weiche_geschaltet_1;
74 assign ventilinsel_belegt:=false, weiche_ist_geschaltet_1:=true; },
75 S0 -> S0{sync weiche_geschaltet_2;
76 assign ventilinsel_belegt:=false, weiche_ist_geschaltet_2:=true; };
77 }
A.5 Quellcode: Switch
Der Quellcode des Automaten-Templates Switch
1 process Switch(chan steuer_weiche,weiche_geschaltet,
2 druckluft_weiche_links,
3 druckluft_weiche_rechts,
4 naeherungs_sensor_links,
5 naeherungs_sensor_rechts;
6 int[0,1] richtung}
7 {
8 int[0,1] arretiert:=1;
9 int[0,1] weichen_position:=0;
10 clock x;

A.6. QUELLCODE: SHUTTLE 65
11
12 state S0, start, S8, S7{x S3{guard weichen_position==rechts; },
23 S3 -> S5{guard x==1;
24 sync druckluft_weiche_links!;
25 assign arretiert:=false; },
26 S5 -> S4{guard x>=3;
27 sync naeherungs_sensor_links;
28 assign arretiert:=true,
29 weichen_position:=links; },
30 S4 -> start{sync weiche_geschaltet!; },
31 S1 -> S4{guard weichen_position==links; },
32 S2 -> S6{guard weichen_position==links; },
33 S6 -> S7{guard x==1;
34 sync druckluft_weiche_rechts!;
35 assign arretiert:=false; },
36 S2 -> S8{guard weichen_position==rechts; },
37 S7 -> S8{guard x>=3;
38 sync naeherungs_sensor_rechts;
39 assign arretiert:=true,
40 weichen_position:=rechts; },
41 S8 -> start{sync weiche_geschaltet!; };
42 }
A.6 Quellcode: Shuttle
1 process Shuttle
2 {
3 clock x;
4
Der Quellcode: Shuttle
5 state Sensor_4, Sensor_3{x Sensor_3{guard x>=1; sync sensor_3!; },
16 Sensor_4 -> Start{sync weiter_4; },
17 Sensor_3 -> Weiche2{guard x>=2; },
18 Sensor_2 -> Weiche2{sync weiter_2; },
19 Sensor_1 -> Weiche1{sync weiter_1; assign x:=0; },
20 Weiche1 -> S1{guard richtung==links; },
21 Weiche1 -> S2{guard richtung==rechts; },
22 Weiche2 -> S3{assign x:=0; },
23 S3 -> Sensor_4{sync sensor_4!; },
24 Sensor_2 -> Sensor_2{},
25 Sensor_1 -> Sensor_1{};
26 }

Anhang B
SMV (Markus Zarbock)
B.1 Quellcode
Hier befindet sich der vollständige, nach Modulen gegliederte Quellcode der Modellierung
bzw. der Spezifikationen.
1 /**
2 * hw module for switch
3 */
4 module switcher()
5 {
6 /** true if locked*/
7 lock : boolean;
8 init(lock) := true;
9
10 /** true if sensor has contact*/
11 approxSensorEven : boolean;
12 init(approxSensorEven) := true;
13
14 /** true if sensor has contact*/
15 approxSensorSwitched : boolean;
16 init(approxSensorSwitched) := false;
17
18 /** true if pressure is high*/
19 pressureEven : boolean;
20 init(pressureEven) := false;
21
22 /** true if pressure is high*/
23 pressureSwitched : boolean;
24 init(pressureSwitched) := false;
25
Quellcode Weichenmodell
26 /** state variable */
27 state :
28 {even,switched,switchingToEven,switchingToSwitched};
29 init(state) := even;
30
31 case
32 {
33 /** switch even, no pressure or pressure on even pipe */
34 (state = even & ~pressureSwitched)
35 | (state = even & pressureEven) :
36 {
37 next(state) := even;
38 }
39 /** switch even, pressure on switched pipe */
40 (state = even & pressureSwitched) :
41 {
42 next(state) := switchingToSwitched;
67

68 ANHANG B. SMV (MARKUS ZARBOCK)
43 next(approxSensorEven) := false;
44 next(lock) := false;
45 }
46 /** switching */
47 state = switchingToSwitched & pressureSwitched :
48 {
49 next(state) := switched;
50 next(approxSensorSwitched) := true;
51 next(lock) := true;
52 }
53 /** nothing to do */
54 (state = switched & ~pressureEven)
55 | (state = switched & pressureSwitched) :
56 {
57 next(state) := switched;
58 }
59 /** switched, pressure on even pipe */
60 (state = switched & pressureEven) :
61 {
62 next(state) := switchingToEven;
63 next(approxSensorSwitched) := false;
64 next(lock) := false;
65 }
66 /** switching */
67 state = switchingToEven & pressureSwitched :
68 {
69 next(state) := even;
70 next(approxSensorEven) := true;
71 next(lock) := true;
72 }
73 }
74 locked :
75 assert G ~(lock & state ={switchingToSwitched,switchingToEven});
76 }

B.1. QUELLCODE 69
Quellcode Ventilinsel
1 /**
2 * shall be a model for the pressure
3 * distribution system, that drives the switches
4 */
5 module pressureDistributor(one,two)
6 {
7 /** control variable for pressureDistributor */
8 control : {oneEven,oneSwitched,twoEven,twoSwitched};
9
10 /** modeling pressureDistributor behaviour */
11 case
12 {
13 control = oneEven :
14 {
15 next(one.pressureEven) := true;
16 next(one.pressureSwitched) := false;
17 next(two.pressureEven) := false;
18 next(two.pressureSwitched) := false;
19 }
20 control = oneSwitched :
21 {
22 next(one.pressureEven) := false;
23 next(one.pressureSwitched) := true;
24 next(two.pressureEven) := false;
25 next(two.pressureSwitched) := false;
26 }
27 control = twoEven :
28 {
29 next(one.pressureEven) := false;
30 next(one.pressureSwitched) := false;
31 next(two.pressureEven) := true;
32 next(two.pressureSwitched) := false;
33 }
34 control = twoSwitched :
35 {
36 next(one.pressureEven) := false;
37 next(one.pressureSwitched) := false;
38 next(two.pressureEven) := true;
39 next(two.pressureSwitched) := false;
40 }
41 }
42 pressureControl :
43 assert G ~(~one.pressureEven & two.pressureEven);
44 }

70 ANHANG B. SMV (MARKUS ZARBOCK)
Quellcode Weichensteuerung links
1 /**
2 * left switch controller
3 */
4 module leftSwitchController(pd,one)
5 {
6 /** true if switch not available for shuttles (switching) */
7 available : boolean;
8 init(available) := true;
9
10 /** control flag to start switching */
11 commitSwitch : boolean;
12 init(commitSwitch) := true;
13
14 /** two "locked" states and two swinging states */
15 state :
16 {even,switchingToEven,switchingToSwitched,switched,errorState};
17 init(state) := even;
18
19 /** modeling the switch as a state machine */
20 case
21 {
22 /** begin switch from even to switched */
23 state = even & commitSwitch :
24 {
25 next(state) := switchingToSwitched;
26 next(commitSwitch) := false;
27 next(available) := false;
28 next(pd.control) := oneSwitched;
29 }
30 /** switching */
31 state = switchingToSwitched & one.approxSensorSwitched :
32 {
33 next(state) := switched;
34 next(available) := true;
35 }
36 /** switching error*/
37 state = switchingToSwitched & one.approxSensorEven :
38 {
39 next(state) := errorState;
40 }
41 /** begin switch from switched to even */
42 state = switched & commitSwitch :
43 {
44 next(state) := switchingToSwitched;
45 next(commitSwitch) := false;
46 next(available) := false;
47 next(pd.control) := oneEven;
48 }
49 /** switching */
50 state = switchingToEven & one.approxSensorEven :
51 {
52 next(state) := even;
53 next(available) := true;
54 }
55 /** switching error*/
56 state = switchingToSwitched & one.approxSensorSwitched :
57 {
58 next(state) := errorState;
59 }
60 /** wait state */
61 default : next(state) := state;
62 }
63 }

B.1. QUELLCODE 71
Quellcode Weichensteuerung links
1 /**
2 * right switch controller
3 */
4 module rightSwitchController(pd,two)
5 {
6 /** true if switch not available for shuttles (switching) */
7 available : boolean;
8 init(available) := true;
9
10 /** control flag to start switching, stupid solution*/
11 commitSwitch : boolean;
12 init(commitSwitch) := false;
13
14 /** two "locked" states and two swinging states */
15 state : {even,switchingToEven,switchingToSwitched,switched,errorState};
16 init(state) := even;
17
18 /** modeling the switch as a state machine */
19 case
20 {
21 /** begin switch from even to switched */
22 state = even & commitSwitch :
23 {
24 next(state) := switchingToSwitched;
25 next(commitSwitch) := false;
26 next(available) := false;
27 next(pd.control) := twoSwitched;
28 }
29 /** switching */
30 state = switchingToSwitched & two.approxSensorSwitched :
31 {
32 next(state) := switched;
33 next(available) := true;
34 }
35 /** switching error*/
36 state = switchingToSwitched & two.approxSensorEven :
37 {
38 next(state) := errorState;
39 }
40 /** begin switch from switched to even */
41 state = switched & commitSwitch :
42 {
43 next(state) := switchingToSwitched;
44 next(commitSwitch) := false;
45 next(available) := false;
46 next(pd.control) := twoEven;
47 }
48 /** switching */
49 state = switchingToEven & two.approxSensorEven :
50 {
51 next(state) := even;
52 next(available) := true;
53 }
54 state = switchingToSwitched & two.approxSensorSwitched :
55 {
56 next(state) := errorState;
57 }
58 /** wait state */
59 default : next(state) := state;
60 }
61 }

72 ANHANG B. SMV (MARKUS ZARBOCK)
Quellcode Shuttle
1 /**
2 * models a shuttle controller
3 */
4 module shuttle(startTrack,t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,
5 controlOne,controlTwo,chan)
6 {
7
8 /** true if shuttle wants to drive straight ahead*/
9 straight : boolean;
10 init(straight) := {0,1};
11
12 /**
13 * to memorize wether switch one was caused to switch
14 * as shuttles passed the switch
15 */
16 causedOneToSwitch : boolean;
17 init(causedOneToSwitch) := false;
18
19 /**
20 * to memorize wether switch two was caused to switch
21 * as shuttles passed the switch
22 */
23 causedTwoToSwitch : boolean;
24 init(causedTwoToSwitch) := false;
25
26 /** shuttle states */
27 state : {idle, halted, driving};
28 init(state) := idle;
29
30 myTrack : 1..12;
31
32 /** put shuttle on start track */
33 case
34 {
35 startTrack = 3 : init(myTrack) := 3;
36 startTrack = 7 : init(myTrack) := 7;
37 startTrack = 8 : init(myTrack) := 8;
38 startTrack = 9 : init(myTrack) := 9;
39 startTrack = 10 : init(myTrack) := 10;
40 }
41 /** shuttle logic */
42 case
43 {
44 /** 10 -> 1 */
45 myTrack = 10 :
46 {
47 if(t1.state = empty)
48 {
49 next(state) := driving;
50 next(t1.state) := passed;
51 next(myTrack) := 1;
52 next(t10.state) := empty;
53 }
54 else
55 {
56 next(state) := halted;
57 next(myTrack) := 10;
58 }
59 }
60 /** 9 -> 10 */
61 myTrack = 9 :
62 {
63 if(t10.state = empty)
64 {
65 next(state) := driving;
66 next(t10.state) := passed;
67 next(myTrack) := 10;
68 next(t9.state) := empty;
69 }

B.1. QUELLCODE 73
70 else
71 {
72 next(state) := halted;
73 next(myTrack) := 9;
74 }
75 }
76 /** 8 -> 9 */
77 myTrack = 8 :
78 {
79 if(t9.state = empty)
80 {
81 next(state) := driving;
82 next(t9.state) := passed;
83 next(myTrack) := 9;
84 next(t8.state) := empty;
85 }
86 else
87 {
88 next(state) := halted;
89 next(myTrack) := 8;
90 }
91 }
92 /** 7 -> 8 */
93 myTrack = 7 :
94 {
95 if(t8.state = empty)
96 {
97 next(state) := driving;
98 next(t8.state) := passed;
99 next(myTrack) := 8;
100 next(t7.state) := empty;
101 }
102 else
103 {
104 next(state) := halted;
105 next(myTrack) := 7;
106 }
107 }
108 /** shuttle on track in front of switch one 1 -> 11*/
109 myTrack = 1 :
110 {
111 case
112 {
113 straight = true :
114 {
115 case
116 {
117 controlOne.state = even & ~chan.onePassed :
118 {
119 next(myTrack) := 11;
120 next(chan.onePassed) := true;
121 next(state) := driving;
122 next(t1.state) := empty;
123 if (causedOneToSwitch)
124 {
125 next(chan.pressureAvailable) := true;
126 next(causedOneToSwitch) := false;
127 }
128 }
129 controlOne.state = switched & ~chan.onePassed :
130 {
131 if (chan.pressureAvailable)
132 {
133 next(controlOne.commitSwitch) := true;
134 next(state) := halted;
135 next(chan.pressureAvailable) := false;
136 next(causedOneToSwitch) := true;
137
138 }
139 }
140 /** occurs if switch is switching -> shuttle has to wait */

74 ANHANG B. SMV (MARKUS ZARBOCK)
141 default : next(state) := halted;
142 }
143 }
144 straight = false :
145 {
146 case
147 {
148 controlOne.state = switched & ~chan.onePassed :
149 {
150 next(myTrack) := 11;
151 next(t1.state) := empty;
152 next(state) := driving;
153 next(chan.onePassed) := true;
154 if (causedOneToSwitch)
155 {
156 next(chan.pressureAvailable) := true;
157 next(causedOneToSwitch) := false;
158 }
159 }
160 controlOne.state = even & ~(chan.onePassed) :
161 {
162 if (chan.pressureAvailable)
163 {
164 next(controlOne.commitSwitch) := true;
165 next(state) := halted;
166 next(chan.pressureAvailable) := false;
167 next(causedOneToSwitch) := true;
168
169 } /** occurs if switch is switching -> shuttle has to wait */
170 }
171 default : next(state) := halted;
172 }
173 }
174 }
175 }
176 /** shuttle on first switch */
177 myTrack = 11 :
178 {
179 case
180 {
181 /** 11 -> 2*/
182 straight = true :
183 {
184 if(t2.state = empty)
185 {
186 next(state) := driving;
187 next(t2.state) := passed;
188 next(chan.onePassed) := false;
189 next(myTrack) := 2;
190 }
191 else
192 {
193 next(state) := halted;
194 next(myTrack) := 11;
195 }
196 }
197 /** 11 -> 4 */
198 straight = false :
199 {
200 if(t4.state = empty)
201 {
202 next(state) := driving;
203 next(t4.state) := passed;
204 next(chan.onePassed) := false;
205 next(myTrack) := 4;
206 }
207 else
208 {
209 next(state) := halted;
210 next(myTrack) := 11;
211 }

B.1. QUELLCODE 75
212 }
213 }
214 }
215 /** 4 -> 6 */
216 myTrack = 4 :
217 {
218 if(t6.state = empty)
219 {
220 next(state) := driving;
221 next(t6.state) := passed;
222 next(myTrack) := 6;
223 next(t4.state) := empty;
224 }
225 else
226 {
227 next(state) := halted;
228 next(myTrack) := 4;
229 }
230 }
231 /** shuttle on track modelling track loop -> later loading area 6 -> 5*/
232 myTrack = 6 :
233 {
234 if(t5.state = empty)
235 {
236 next(state) := driving;
237 next(t5.state) := passed;
238 next(myTrack) := 5;
239 next(t6.state) := empty;
240 }
241 else
242 {
243 next(state) := halted;
244 next(myTrack) := 6;
245 }
246 }
247 /** shuttle on track above switch two */
248 myTrack = 5 :
249 {
250 case
251 {
252 controlTwo.state = switched & ~(chan.twoPassed) :
253 {
254 next(myTrack) := 12;
255 next(t5.state) := empty;
256 next(state) := driving;
257 next(chan.twoPassed) := true;
258 if (causedTwoToSwitch)
259 {
260 next(causedTwoToSwitch) := false;
261 next(chan.pressureAvailable) := true;
262 }
263
264 }
265 controlTwo.state = even & ~(chan.twoPassed) :
266 {
267 if (chan.pressureAvailable)
268 {
269 next(controlTwo.commitSwitch) := true;
270 next(state) := halted;
271 next(chan.pressureAvailable) := false;
272 next(causedTwoToSwitch) := true;
273 }
274 }
275 /** occurs if switch is switching -> shuttle has to wait */
276 default : next(state) := halted;
277 }
278 }
279 /** shuttle on switch two 12 -> 3*/
280 myTrack = 12 :
281 {
282 if(t3.state = empty)

76 ANHANG B. SMV (MARKUS ZARBOCK)
283 {
284 next(state) := driving;
285 next(t3.state) := passed;
286 next(chan.twoPassed) := false;
287 next(myTrack) := 3;
288 }
289 else
290 {
291 next(state) := halted;
292 next(myTrack) := 12;
293 }
294 }
295 /** shuttle between switches */
296 myTrack = 2 :
297 {
298 case
299 {
300 controlTwo.state = even & ~(chan.twoPassed) :
301 {
302 next(myTrack) := 12;
303 next(t2.state) := empty;
304 next(state) := driving;
305 next(chan.twoPassed) := true;
306 if(causedTwoToSwitch)
307 {
308 next(causedTwoToSwitch) := false;
309 next(chan.pressureAvailable) := true;
310 }
311 }
312 controlTwo.state = switched & ~(chan.twoPassed) :
313 {
314 if (chan.pressureAvailable)
315 {
316 next(controlTwo.commitSwitch) := true;
317 next(state) := halted;
318 next(chan.pressureAvailable) := false;
319 next(causedTwoToSwitch) := true;
320 }
321 }
322 /** occurs if switch is switching -> shuttle has to wait */
323 default : next(state) := halted;
324 }
325 }
326 /** 3 -> 7 */
327 myTrack = 3 :
328 {
329 if(t7.state = empty)
330 {
331 next(state) := driving;
332 next(t7.state) := passed;
333 next(myTrack) := 7;
334 next(t3.state) := empty;
335 }
336 else
337 {
338 next(state) := halted;
339 next(myTrack) := 3;
340 }
341 }
342 }
343 }/** shuttle */

B.1. QUELLCODE 77
Quellcode Track
1 /**
2 * models a track segment
3 */
4 module track()
5 {
6 /** flag to store if track is passed by shuttle or not */
7 state : {empty, passed};
8 }
1 /**
2 * used to ensure mutex between shuttles
3 * driving over switches
4 */
5 module channel()
6 {
7 /** true if switch one is empty */
8 onePassed : boolean;
9 init(onePassed) := false;
10
11 /** true if switch two is empty */
12 twoPassed : boolean;
13 init(twoPassed) := false;
14
15 /** true if pressure is available */
16 pressureAvailable : boolean;
17 init(pressureAvailable) := true;
18 }
Quellcode channel

78 ANHANG B. SMV (MARKUS ZARBOCK)
1 module main()
2 {
3 /**
4 * processes to model switches
5 */
6
7 pd : process pressureDistributor(one,two);
8
9 /** physical models */
10 one : process switcher();
11 two : process switcher();
12
Quellcode Instanziierungen
13 /** control models */
14 controlOne : process leftSwitchController(pd,one);
15 controlTwo : process rightSwitchController(pd,two);
16
17 /**
18 * mastercontroller parts
19 */
20
21 t1 : process track();
22 t2 : process track();
23 t3 : process track();
24 t4 : process track();
25 t5 : process track();
26 t6 : process track();
27 t7 : process track();
28 t8 : process track();
29 t9 : process track();
30 t10 : process track();
31
32 /** holds shared variables */
33 chan : process channel();
34
35 /** init shuttles, up to now in fixed order */
36
37 s1 : process shuttle(7,t1,t2,t3,t4,t5,t6,t7,t8,t9,
38 t10,controlOne,controlTwo,chan);
39 s2 : process shuttle(8,t1,t2,t3,t4,t5,t6,t7,t8,t9,
40 t10,controlOne,controlTwo,chan);
41 s3 : process shuttle(9,t1,t2,t3,t4,t5,t6,t7,t8,t9,
42 t10,controlOne,controlTwo,chan);
43 s4 : process shuttle(10,t1,t2,t3,t4,t5,t6,t7,t8,t9,
44 t10,controlOne,controlTwo,chan);
45 s5 : process shuttle(3,t1,t2,t3,t4,t5,t6,t7,t8,t9,
46 t10,controlOne,controlTwo,chan);
47
48 /** initializing tracks */
49 init(t1.state) := empty;
50 init(t2.state) := empty;
51 init(t3.state) := passed;
52 init(t4.state) := empty;
53 init(t5.state) := empty;
54 init(t6.state) := empty;
55 init(t7.state) := passed;
56 init(t8.state) := passed;
57 init(t9.state) := passed;
58 init(t10.state) := passed;
59
60 /** specifications */
61
62 notMoreThanOneOnSameTrack5 :
63 assert G ~((s1.myTrack = s2.myTrack) | (s1.myTrack = s3.myTrack)
64 | (s1.myTrack = s4.myTrack) | (s1.myTrack = s5.myTrack)
65 | (s2.myTrack = s3.myTrack) | (s2.myTrack =s4.myTrack)
66 | (s2.myTrack = s5.myTrack) | (s3.myTrack = s4.myTrack)
67 | (s3.myTrack = s5.myTrack) | (s4.myTrack = s5.myTrack));
68
69 notMoreThanOneOnSameTrack4 :

B.1. QUELLCODE 79
70 assert G ~((s1.myTrack = s2.myTrack) | (s1.myTrack = s3.myTrack)
71 | (s1.myTrack = s4.myTrack) | (s2.myTrack = s3.myTrack)
72 | (s2.myTrack = s4.myTrack) | (s3.myTrack = s4.myTrack));
73
74 notMoreThanOneOnSameTrack3 :
75 assert G ~((s1.myTrack = s2.myTrack) | (s1.myTrack = s3.myTrack)
76 | (s2.myTrack = s3.myTrack));
77
78 notMoreThanOneOnSameTrack2 : assert G ~(s1.myTrack = s2.myTrack);
79
80 switches1 :
81 assert G ~(one.state ={switchingToSwitched,switchingToEven}
82 & two.state ={switchingToSwitched,switchingToEven});
83
84 switches2 :
85 assert G ~(controlOne.state ={switchingToSwitched,switchingToEven}
86 & controlTwo.state ={switchingToSwitched,switchingToEven});
87
88 lockedOne :
89 assert G ~(one.lock & one.state ={switchingToSwitched,switchingToEven});
90
91 lockedTwo :
92 assert G ~(two.lock & two.state ={switchingToSwitched,switchingToEven});
93
94 lockedOne2 :
95 assert G ~((s1.myTrack = 11 | s2.myTrack = 11 | s3.myTrack = 11
96 | s4.myTrack = 11 | s5.myTrack = 11) & ~one.lock);
97
98 lockedTwo2 :
99 assert G ~((s1.myTrack = 12 | s2.myTrack = 12 | s3.myTrack = 12
100 | s4.myTrack = 12 | s5.myTrack = 12) & ~two.lock);
101 }/** main */

80 ANHANG B. SMV (MARKUS ZARBOCK)
B.2 Abbildungen
Hier befinden sich die Abbildungen zur grafischen Benutzeroberfläche für SMV.
Die Verwendung dieser Oberfläche befindet sich in Kapitel 2.2.4.
Abbildung B.1: SMV – Variablenbrowser

B.2. ABBILDUNGEN 81
Abbildung B.2: SMV – Spezifikationen
Abbildung B.3: SMV – Auswertung

82 ANHANG B. SMV (MARKUS ZARBOCK)
Abbildung B.4: SMV – Trace

Anhang C
CDROM – alle Unterlagen
83

Abbildungsverzeichnis
2.1 Automaten Benutzer und Lichtschalter des Beipiels ”
Intelligenter
Lichtschalter“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Uppaal – System Editor . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Uppaal – Simulator . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Uppaal – Verifizierer . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 SMV – Zeitmodelle . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Eine mögliche Topologie der ISILEIT-Fallstudie . . . . . . . . . 31
3.2 Ausschnitt aus der ISILEIT-Fallstudie . . . . . . . . . . . . . . 32
3.3 Uppaal – Automat Switch . . . . . . . . . . . . . . . . . . . . . 36
3.4 Uppaal – Automat Weiche . . . . . . . . . . . . . . . . . . . . . 37
3.5 Uppaal – Automat Shuttle . . . . . . . . . . . . . . . . . . . . . 40
3.6 Uppaal – Grafische Auswertung der Verifikationszeiten . . . . . 45
3.7 Ausschnitt aus der ISILEIT-Fallstudie . . . . . . . . . . . . . . 46
3.8 SMV Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9 SMV Weiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.10 SMV Weichenmodell . . . . . . . . . . . . . . . . . . . . . . . . 49
3.11 SMV Weiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.12 SMV Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.1 SMV – Variablenbrowser . . . . . . . . . . . . . . . . . . . . . . 80
B.2 SMV – Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . 81
B.3 SMV – Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.4 SMV – Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
84

Literaturverzeichnis
[1] Petterson, R / Larsen, K. G.: Uppaal2k: Small Tutorial
[2] Bengtsson J, / Griffioen, D / Kristoffersen, K / Larsen, K. G./ Larrson, F /
Pettersson, P / Yi, W: Verification of an Audio Protocol with Bus Collision
Using Uppaal; in Alur, R / Henzinger, T. A. (Hrsg): Proc. of 9th Int. Conf.
on Computer Aided Verification, Nr. 1102, Seiten 244-256; Springer Verlag,
Juli 1996
[3] Larsen, K. G. / Pettersson, P / Yi, W.: Uppaal in a Nutshell
[4] Bengtsson, J. / Larsen, K. G. / Larsson, F. / Pettersson, P. / Yi, W. /
Weise, C.: New Generation of UPPAAL
[5] Schäfer, W. / Kardos, M.:Vortrag: Integrative Spezifikation von verteilten
Leitsystemen der flexibel automatisierten Fertigung,
[7] UPPAAL Workshop, Sunnersta Herrgard, Uppsala, Oktober 1998
[8] Larsen, K. G. / Pettersson, P:Timed and Hybird System in UPPAAL2K,
Juni 2000
[9] Alur, R. / Dill, D. L.: A theory of timed automta Timed Theoretical Computer
Science, 1994
[10] Clarke, E. M. / Emerson, E. A.: Synthesis of Synchronization Skeletons
for Branching Time Temporal Logic; in Logics of Programms: Workshop,
volume 131 of Lecture Notes in Computer Science, Yorktown Heights, New
York, May 1981, Springer Verlag
[11] Quielle, J. P. / Sifakis, J.: Spezification and verification of concurrent systems
in CESAR; in: Proceedings of the Fifth International Symposium in
Programming, 1981
[12] Clarke, E. M. / Wing, J. M.: Formal methods: State of the art and future
directions; Technical Report CMU-CS-96-178, School of Computer Science,
Carnegie Mellon University, Semptember 1996
[13] Wing, J. M.: A specifiers’s introduction to formal methods; IEEE Computer,
September 1990
85

86 LITERATURVERZEICHNIS
[14] McMillan, K.: Symbolic model checking: an approach to the state explosion
problem; Carnegie Mellon University, School of Computer Science; Ph.D.
Thesis, 1992.
[15] McMillan, K.: SMV system; Carnegie Mellon University, Technical Report,
School of Computer Science, 1992.
[16] Banphawatthanarak, C. / Krogh, B. H.: Verification of Stateflow Diagrams
Using SMV
[17] http://www.uppaal.com
[18] http://www.uni-paderborn.de/cs/ISILEIT
[19] http://www-cad.eecs.berkeley.edu/˜kenmcmil/smv/