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<=3 markiert. Befindet sich der Automat im Zustand Heller, löscht ein erneutes Drücken des Lichtschalters die Lampe. Dieses wird durch die aus diesem Zustand zum Anfangszustand führende Transition, nur mit press? markiert, dargestellt. 2.1.3 Benutzung von Uppaal Die aktuelle Version von Uppaal, auch Uppaal2k (Version 3.2.9, April 2002) genannt, besteht aus einer Client/Server Architektur. Auf der Serverseite ist der eigentliche Verifizierer, implementiert in C++, auf der Clientseite die Benutzeroberfläche, implementiert in der plattformunabhängigen Programmiersprache Java. Die Benutzeroberfläche stellt die Schnittstellen für die Komponenten des Systemeditors, des Simulators und des eigentlichen Verifizierers zur Verfügung. Systemeditor Im Systemeditor (siehe Abb. 2.2) kann der Benutzer die Modellierung eines Systems vornehmen. Die Konstruktion der Automaten-Templates geschieht durch das Zeichnen von Zuständen und den zugehörigen Transitionen. Um aus den Templates das zu simulierende System zu erhalten, müssen diese erst instanziiert (Process assignments) und in einer System Definition (System definition) aufgenommen werden. Die Verwendung von Templates hat den Vorteil, dass ein und derselbe Automat mit verschiedenen Variablen und Kanälen benutzt werden kann, ohne ihn jedesmal neu zu implementieren. Das modellierte System kann als Datei im XML-Format oder im XTA+UGI Format abgespeichert werden. Ersteres speichert die Daten für die Visualisierung im Simulator und für die Logik in einer Datei. Bei der zweiten Variante wird die Logik der Automaten in der.xta

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<3 Es wird überprüft, ob es eine Situation gibt, in der sich der Lichtschalter im Zustand Heller befindet und gleichzeitig nicht mehr als 3 Zeiteinheiten seit dem Anschalten vergangen sind.

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 <0>..<15> of <boolean>; 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.