scieee Science in your language
[en] (orig)
Fakultät für Elektrotechnik – Informatik – Mathematik
Institut für Informatik
Fachgebiet Softwaretechnik
Warburger Straße 100
33098 Paderborn
Modell-basierte Verifikation
von
vernetzten mechatronischen Systemen
shuttle1: Shuttleshuttle2: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
shuttle3: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
:P :P
shuttle1: Shuttleshuttle2: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
shuttle3: Shuttle
:P :P
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
Martin Hirsch
Fakultät für Elektrotechnik – Informatik – Mathematik
Institut für Informatik
Fachgebiet Softwaretechnik
Warburger Straße 100
33098 Paderborn
Modell-basierte Verifikation
von
vernetzten mechatronischen Systemen
Genehmigte Dissertation
zur Erlangung des akademischen Grades
„Doktor der Naturwissenschaften“
(Dr. rer. nat.)
vorgelegt von
Dipl.-Inform. Martin Hirsch
Promotionskommission:
Vorsitzender: Prof. Dr. rer. nat. Wilhelm Schäfer (Universität Paderborn)
Koreferat: Prof. Dr. rer. nat. Heike Wehrheim (Universität Paderborn)
Koreferat: Prof. Dr. rer. nat. Ingolf H. Krüger (University of California at San Diego)
Beisitzer: Prof. Dr.-Ing. Ansgar Trächtler (Universität Paderborn)
Beisitzer: Prof. Dr. rer. nat. Gregor Engels (Universität Paderborn)
Die Dissertation wurde am 15. Juli 2008 bei der Fakultät für Elektrotechnik, Informatik
und Mathematik der Universität Paderborn eingereicht und am 15. September 2008 vor
der Promotionskommission verteidigt und durch die Fakultät angenommen.
Dank
An dieser Stelle möchte ich mich bei all den Menschen bedanken, die mir auf dem Weg
zur Promotion geholfen, mich ermutigt oder mir freundschaftlich zur Seite gestanden
haben.
Als erstes bedanke ich mich bei meinem Doktorvater Prof. Dr. Wilhelm Schäfer. Bei
Wilhelm möchte ich mich dafür bedanken, dass er meine Promotion mitbetreut hat und er
trotz seines mehr als randvollen Terminkalenders stets Zeit sowohl für wissenschaftliche
Diskussionen, als auch für private Gespräche für mich hatte. Danke, Wilhelm!
Prof. Dr. Holger Giese möchte ich danken, dass er mich 2004 zur Promotion „überredet“
hat, meine Promotion mitbetreut und zu jeder Tages- und Nachtzeit für wissenschaftlichen
Input gesorgt hat. Danke, Holger!
Bei Prof. Dr. Heike Wehrheim und Prof. Dr. Ingolf Krüger bedanke ich mich, dass sie das
Koreferat meiner Dissertation übernommen haben und für die Diskussionen bei der Fer-
tigstellung dieser Arbeit. Des weiteren möchte ich mich bei Ingolf für den Gastaufenthalt
in seiner Arbeitsgruppe an der University of California, San Diego, bedanken. Für die
Teilnahme an meiner Promotionskommission danke ich weiterhin Prof. Dr.-Ing. Ansgar
Trächtler und Prof. Dr. Gregor Engels.
Ganz besonders möchte ich mich bei Stefan Henkler (und seiner Frau Sandra und seinen
beiden Kindern Gavin und Jarne, die es „erlaubt haben“, dass Stefan so viel Zeit für mich
haben durfte) bedanken! Nicht nur, weil du für mich ein super Bürokollege warst, son-
dern auch für die zahlreichen wissenschaftlichen und privaten Diskussionen, Gespräche
und „geselligen Stunden“, teilweise bei Kaffee, Bier, Sekt und allen möglichen anderen
Getränken in und außerhalb der Uni. Ohne dich würde es diese Dissertation nicht geben!
Danke, Stefan!
Bürokratische Probleme sind während meiner Promotionszeit in Paderborn dank Jutta
Haupt und Sarah Latsch nie aufgetreten. Jürgen (Sammy) Maniera danke ich für die Hil-
fe bei technischen Problemen und für die Anfangszeit als Bürokollege, sowie Sabrina
Clemens, für das anfängliche „Schreibtischsharing“.
Eine Promotion kann nicht alleine und im stillen Kämmerchen geschrieben werden. An
dieser Stelle möchte ich mich bei allen anderen Kollegen und Ex-Kollegen Björn Axe-
nath, Dr. Sven Burmester, Dr. Matthias Gehrke, Joel Greenyer, Stefan Henkler, Prof. Dr.
iii
Ekkart Kindler, Florian Klein, Ahmet Mehic, Matthias Meyer, Claudia Priesterjahn, Dr.
Vladimir Rubin, Matthias Tichy (MTT), Dr. Daniela Schilling, Oliver Sudmann, Dietrich
Travkin, Markus von Detten, Robert Wagner, Dr. Lothar Wendehals bedanken, die immer
für wissenschaftliche, aber auch private Gespräche zur Verfügung standen.
Bei Ahmet bedanke ich mich für die vielen Ratschläge aus der „nicht informatischen“
Sicht. Ekkart danke ich für seine vielen Tipps und Hinweise, besonders auch um mal
„über den Tellerrand hinauszuschauen“. Claudia, MTT und Stefan danke ich für das Kor-
rekturlesen meiner Arbeit.
Was wäre eine interdisziplinäre Dissertation ohne interdisziplinäre Gespräche – bei mei-
nen Kollegen Eckehard Münch und Henner Vöcking vom Lehrstuhl für Regelungstechnik
und Mechatronik bedanke ich mich für interessante Diskussionen. Henner danke ich dar-
über hinaus für seinen Crashkurs in Regelungstechnik.
Vor allem möchte ich mich ganz herzlich bei meinen Eltern bedanken, dass sie mir meine
Ausbildung ermöglicht haben, dass sie immer für mich da waren, mich unterstützt und sie
sich mit mir und für mich über Erfolge gefreut haben. Danke, Mama und Papa!
Meinem Bruder Henrik danke ich für zahlreiche Tipps und Hinweise während meines
Studiums und meiner Promotion.
Meinem besten Freund Hansjörg und seiner Freundin Manon danke ich ganz herzlich für
die vielen vergnüglichen gemeinsamen Stunden, für viele aufmunternde Gespräche, Spa-
ziergänge und die Ablenkung von allem, was mit meiner Dissertation zu tun hat. Danke,
Hansjörg und Manon!
iv
Zusammenfassung
Beim Entwurf selbstoptimierender, mechatronischer Systeme stellt die eingebettete Soft-
ware einen großen Teil der Wertschöpfung dar. Typischerweise werden Regelungen oder
Steuerungen in Software umgesetzt. Durch die starke Vernetzung selbstoptimierender
Systeme wird Software auch zur nachrichtenbasierten Kommunikation und Koordination
zwischen den einzelnen verteilten selbstoptimierenden Systemen eingesetzt. Diese Kom-
munikation geht über die Aufnahme von System- und Umweltdaten durch Sensorik hin-
aus. Hier werden ggf. komplexe Zustandsinformationen über entsprechende Protokolle
und zugrunde liegende Kommunikationskanäle ausgetauscht, die dann wieder das Ver-
halten bzw. die zugrunde liegenden Berechnungen der einzelnen Komponenten massiv
beeinflussen können. Diese Entwicklung führt zu äußerst komplexer hybrider (diskreter
/ kontinuierlicher) Software. Des Weiteren werden selbstoptimierende, mechatronische
Systeme oftmals in sicherheitskritischen Umgebungen eingesetzt. Hierdurch müssen for-
male Verfahren zur Verifikation der Korrektheit des Systems gegenüber sicherheitskriti-
schen Eigenschaften eingesetzt werden.
Im Rahmen dieser Dissertation werden nun Konzepte und Methoden zur Modellierung
und Verifikation mechatronischer Systeme entwickelt und formal beschrieben. Der hier
vorgestellte Ansatz baut auf dem im Sonderforschungsbereichs 614 entwickelten ME-
CHATRONIC UML Ansatz auf. Dieser unterstützt einen kompositionellen Verifikations-
ansatz für das Echtzeitverhalten von mechatronischen Systemen.
Um eine effiziente Verifikation solcher vernetzten mechatronischen Systeme zu ermögli-
chen, werden in dieser Arbeit Techniken der Abstraktion,Dekomposition sowie der regel-
basierten Modellierung eingeführt. Hierbei werden diese nicht orthogonalen Techniken
geschickt miteinander kombiniert. Ziel ist es, die besonders durch die Verwendung domä-
nenübergreifender Modelle, wie sie bei der Modellierung von mechatronischen Systemen
vorkommen, entstehenden inhärenten multi-Paradigmenwechsel modellieren zu können.
Der hier vorgeschlagene Ansatz zur modell-basierten Verifikation mechatronischer Sys-
teme zeichnet sich durch die Integration effizienter Verifikationstechniken, basierend auf
dem Modellwissen und einer geschickten Modellierung, aus.
v
vi
Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation.................................. 2
1.2 Anwendungsbeispiel ............................ 4
1.3 ZielundLösungsansatz........................... 5
1.4 AufbauderArbeit.............................. 11
2 Grundlagen 13
2.1 Mechatronische Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Regelungstechnik.............................. 15
2.2.1 AdaptiveRegler .......................... 17
2.2.2 Rekonfiguration........................... 18
2.2.3 BlockDiagramme ......................... 18
2.3 Modell-basierte Softwareentwicklung . . . . . . . . . . . . . . . . . . . 22
2.3.1 Automaten ............................. 22
2.3.2 TimedAutomata .......................... 23
2.3.3 Hybride Automaten . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.4 Graphen............................... 28
2.3.5 Verifikation............................. 33
2.4 MechatronicUML ............................. 42
2.4.1 Echtzeitverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.2 Echtzeit-Koordinationsmuster . . . . . . . . . . . . . . . . . . . 43
2.4.3 Komponenten............................ 46
2.4.4 Einbettung hybrider Komponenten . . . . . . . . . . . . . . . . . 48
2.4.5 Anpassung der Softwarestruktur . . . . . . . . . . . . . . . . . . 52
2.5 Zusammenfassung ............................. 54
3 Verifikation eines OCM 55
3.1 Beispiel ................................... 55
3.1.1 Komponenten Struktur . . . . . . . . . . . . . . . . . . . . . . . 58
3.1.2 Verhalten der Komponenten . . . . . . . . . . . . . . . . . . . . 59
3.1.3 Beschreibung des Interface . . . . . . . . . . . . . . . . . . . . . 59
3.1.4 Einbettung ............................. 61
3.2 Verifikation der hierarchischen Rekonfiguration bedingt durch lokale
Zeitbedingungen .............................. 61
vii
Inhaltsverzeichnis
3.2.1 Modularität............................. 63
3.2.2 Überprüfung der Verfeinerung . . . . . . . . . . . . . . . . . . . 66
3.2.3 Überprüfung der korrekten Einbettung . . . . . . . . . . . . . . . 67
3.2.4 Grenzen des Ansatzes . . . . . . . . . . . . . . . . . . . . . . . 69
3.3 Modellierung hierarchischer Rekonfiguration bedingt durch proaktives
Verhalten .................................. 70
3.3.1 Erweitertes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3.2 Verhalten der Komponente . . . . . . . . . . . . . . . . . . . . . 71
3.3.3 Einbettung ............................. 72
3.4 Verifikation der hierarchischen Rekonfiguration bedingt durch proaktives
Verhalten .................................. 72
3.4.1 Überprüfung der Verfeinerung . . . . . . . . . . . . . . . . . . . 73
3.4.2 Dynamische Überprüfung der Einbettung . . . . . . . . . . . . . 75
3.5 Evaluierung................................. 77
3.6 Zusammenfassung ............................. 79
4 Verifikation des Verhaltens eines OCM in der Umwelt 81
4.1 Grenzen des bisherigen Ansatzes . . . . . . . . . . . . . . . . . . . . . . 81
4.2 Modellierung ................................ 84
4.2.1 Beispiel............................... 84
4.2.2 Zeit und Graphtransformationssysteme . . . . . . . . . . . . . . 85
4.3 Semantik .................................. 95
4.3.1 Clockinstanzen........................... 95
4.3.2 Zeitbehaftete Anwendungsregeln . . . . . . . . . . . . . . . . . 97
4.3.3 Zeitbehafteter Graph & Graphtransformationssystem . . . . . . . 99
4.4 Erreichbarkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4.1 Darstellung durch Clockzones . . . . . . . . . . . . . . . . . . . 102
4.4.2 Zeitbehafteter Folgegraph . . . . . . . . . . . . . . . . . . . . . 104
4.4.3 Erreichbares Graphtransformationssystem . . . . . . . . . . . . . 108
4.5 Evaluierung.................................112
4.6 Zusammenfassung .............................114
5 Parametrisierte Koordinationsmuster 115
5.1 Beispiel ...................................116
5.2 Grenzen des bisherigen Ansatzes . . . . . . . . . . . . . . . . . . . . . . 117
5.3 ErweitertesBeispiel.............................118
5.3.1 Lösungsidee ............................119
5.3.2 Regelungstechnischer Entwurf . . . . . . . . . . . . . . . . . . . 122
5.3.3 Softwaretechnische Umsetzung . . . . . . . . . . . . . . . . . . 125
5.4 Parametrisierte Koordinationsmuster . . . . . . . . . . . . . . . . . . . . 126
5.4.1 Informale Beschreibung . . . . . . . . . . . . . . . . . . . . . . 127
viii
Inhaltsverzeichnis
5.4.2 Modellierung des Verhaltens eines parametrisierten Koordinati-
onsmusters .............................129
5.4.3 Modellierung der dynamischen Strukturänderungen . . . . . . . . 133
5.4.4 Formalisierung...........................136
5.4.5 Verifikation.............................138
5.5 Zusammenfassung .............................139
6 Verwandte Arbeiten 141
6.1 Verifikation von Echtzeitsystemen . . . . . . . . . . . . . . . . . . . . . 141
6.1.1 Generelle Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.1.2 Techniken..............................143
6.1.3 Komplexe Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.2 Verifikation von hybriden Systemen . . . . . . . . . . . . . . . . . . . . 145
6.2.1 Generelle Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.2.2 Techniken..............................146
6.2.3 Stabilität ..............................148
6.2.4 Barrier certificates . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.3 Verifikation von Architekturen beschrieben durch hybride Modelle . . . . 150
6.4 AdaptiveSysteme..............................151
6.5 Zusammenfassung .............................151
7 Zusammenfassung & Ausblick 153
7.1 Zusammenfassung .............................154
7.2 Ausblick...................................155
8 Literaturverzeichnis 157
A Algorithmen zu zeitbehaften Graphtransformationssystemen 175
B Regeln zum Shuttlebeispiel aus Kapitel 4 179
Abbildungsverzeichnis 185
ix
Inhaltsverzeichnis
x
Kapitel 1
Einleitung
Intelligente mechatronische Systeme, die autonom und flexibel auf Änderungen in ihrem
Umfeld reagieren, sind in unserer Zukunft nicht mehr wegzudenken. Nicht nur in kleinen
Anwendungen wie in der intelligenten Lichtsteuerung in modernen Autos, sondern auch
in großen Projekten wie in der Entwicklung des „intelligenten, selbst denkenden Hau-
ses“ oder in innovativen Güter- und Personentransportsystemen der Zukunft fließen diese
Konzepte maßgeblich mit ein. Um solche Systeme zu realisieren, bedarf es einer engen
Verknüpfung der Konzepte und Methoden der in der Mechatronik verankerten Domänen
Maschinenbau, Elektronik und Softwaretechnik (siehe Abbildung 1.1). Im Gegensatz zu
reinen Softwareanwendungen bekommt der Sicherheitsaspekt in solchen Systemen einen
deutlich höheren Stellenwert, da Fehler meist unmittelbar Gefahr für Menschenleben be-
deuten [Lev95][Her99].
Mechanical Engineering
Mechanisation
Electrical Technology
Elctro-mechanical
Systems
Information Technology &
Software
Mechatronics
Electronics
Softwaretechnik
Mechanik Elektronik
Mechatronik
Abbildung 1.1: Die Disziplin Mechatronik ergibt sich aus der Kombination der drei Dis-
ziplinen Softwaretechnik, Mechanik und Elektronik
Solche intelligenten, mechatronischen Systeme, wie sie von Schäfer und Wehrheim
[SW07] oder auch von Dawson und anderen [DSBB00] beschrieben werden, bestehen
heutzutage aus einer Vielfalt von komplexen Einzelkomponenten, welche untereinander
verbunden sind und miteinander interagieren. Das Verhalten des Gesamtsystems ist ent-
sprechend durch die Kommunikation und Kooperation der intelligenten Systemelemente
1
Kapitel 1 Einleitung
charakterisiert. Aus informationstechnischer Sicht handelt es sich um verteilte Systeme
von miteinander kooperierenden Agenten.
1.1 Motivation
Beim Entwurf selbstoptimierender, mechatronischer Systeme stellt die eingebettete Soft-
ware einen großen Teil der Wertschöpfung dar. Typischerweise werden Regelungen oder
Steuerungen in Software umgesetzt. Durch die starke Vernetzung selbstoptimierender
Systeme wird Software auch zur nachrichtenbasierten Kommunikation und Koordination
zwischen den einzelnen verteilten selbstoptimierenden Systemen eingesetzt. Diese Kom-
munikation geht über die Aufnahme von System- und Umweltdaten durch Sensorik hin-
aus. Hier werden ggf. komplexe Zustandsinformationen über entsprechende Protokolle
und zugrunde liegende Kommunikationskanäle ausgetauscht, die dann wieder das Ver-
halten bzw. die zugrunde liegenden Berechnungen der einzelnen Komponenten massiv
beeinflussen können. Diese Entwicklung führt zu äußerst komplexer hybrider (diskret /
kontinuierlicher) Software. In Abbildung 1.2 ist ein Beispiel für hybrides Verhalten ge-
zeigt. In dem linken Oval ist rein kontinuierliches Verhalten, im rechten Oval rein diskre-
tes Verhalten beschrieben. Das Zusammenspiel, das Umschalten zwischen verschiedenen
kontinuierlichen Verhalten, kann nun durch die Integration beider Verhalten vorgenom-
men werden. Genau dieses wird als hybrid bezeichnet.
0
5
10
15
20
25
01234
t [s]
s
[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
kontinuierlich diskret
hybrid
-2
0
2
4
6
8
10
1234
t
[
s
]
0
v[m/s]
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
-2
0
2
4
6
8
10
123
4
t [s]
0
v[m/s]
Abbildung 1.2: Hybrides Verhalten
Des Weiteren werden selbstoptimierende, mechatronische Systeme oftmals in sicherheits-
kritischen Umgebungen eingesetzt. Hierdurch müssen formale Verfahren zur Verifikati-
on der Korrektheit des Systems gegenüber sicherheitskritischen Eigenschaften eingesetzt
werden.
Auf Grund der steigenden Komplexität solcher Systeme ist es notwendig, Methoden zu
entwickeln, die auf der einen Seite eine geeignete Modellierung erlauben und auf der
anderen Seite die Validierung und Verifikation dieser Modelle in akzeptabler Zeit durch-
führen können. Das Gebiet der Softwaretechnik beschäftigt sich mit dieser Thematik.
2
1.1 Motivation
Softwaretechnik: Zielorientierte Bereitstellung und systematische Verwen-
dung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für
die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von um-
fangreichen Software-Systemen. (Nach Balzert [Bal98])
Um einen sicheren Betrieb eines mechatronischen Systems zu gewährleisten, müssen die
Sicherheitseigenschaften dieses Systems überprüft werden. Die Überprüfung eines me-
chatronischen Systems durch Testen, d.h. die experimentelle Ausführung des Systems,
kann ein sicheres Verhalten alleine nicht ausreichend nachweisen, da durch reines Testen
nicht alle Ausführungspfade erreicht werden können. Dabei ist dann nicht auszuschlie-
ßen, dass Pfade, die durch das Testen nicht überprüft wurden, sicherheitskritische Eigen-
schaften aufweisen. Außerdem werden durch Testen erhebliche Kosten verursacht, da sie
oftmals manuell durchgeführt werden und unvollständig sind [BN03].
In der Softwaretechnik werden formale Methoden [Win90] verwendet, die mathematisch
fundierte Techniken zur Spezifikation von Systemen zur Verfügung stellen. In [CW96]
wird ein Überblick über formale Methoden und formale Verifikationstechniken gegeben.
Diese gehen von manuellen, unvollständigen Testverfahren, über interaktive Theorembe-
weise, bis hin zu automatischen, vollständigen formalen Verifikationsverfahren. Eine for-
male Verifikationstechnik ist z.B. das Model Checking. Im Gegensatz zum Testen werden
hier alle Pfade des Systems automatisch erstellt und überprüft. Jedoch bringt der Einsatz
von formalen Verifikationstechniken eine ganze Reihe von Problemen mit sich.
Die benötigte Rechenzeit und der Speicherbedarf hängen z.B. beim Model Checking von
der Größe des zu überprüfenden Systems ab. Daher werden beim Model Checking effi-
ziente Algorithmen eingesetzt, um möglichst große Systeme überprüfen zu können. Die
Software eines mechatronischen Systems kann jedoch einen sehr großen oder unendlich
großen Zustandsraum besitzen. Deshalb ist eine Überprüfung mechatronischer Systeme
in den meisten Fällen auf Grund der Größe des Zustandsraums durch diese Verifikations-
technik alleine nicht möglich. Deshalb müssen weitere Techniken wie z.B. Abstraktion,
Approximation und viele andere mit dem Model Checking kombiniert werden, um die
Verifikation durchführen zu können. Nicht nur die Größe des zu verifizierenden Systems
stellt beim Model Checking ein Problem dar. Die Konstruktion des Modells, die Spezifi-
kation der zu überprüfenden Eigenschaften in der geeigneten temporallogischen Formel,
das Problem der Zustandsraumexplosion sowie die Interpretation der Ergebnisse sind wei-
tere Probleme beim Model Checking (siehe [CGP00, Dwy02]).
Der interdisziplinäre Sonderforschungsbreich „SFB 614: Selbstoptimierende Systeme des
Maschinenbaus“1an der Universität Paderborn beschäftigt sich unter anderem mit dem
oben beschriebenen Forschungsgebiet der effizienten Verifikation von mechatronischen
Systemen. Im Folgenden wird das Anwendungsbeispiel genau erklärt, welches im Ver-
1http://www.sfb614.de
3
Kapitel 1 Einleitung
laufe der Arbeit als durchgängiges Beispiel genutzt wird, um die bisherigen Probleme in
der Verifikation zu beleuchten und die neuen Konzepte vorzustellen.
1.2 Anwendungsbeispiel
Im Rahmen des Sonderforschungsbereichs 614 „Selbstoptimierende Systeme des Maschi-
nenbaus“ werden Konzepte und Methoden zur Entwicklung von mechatronischen Syste-
men mit inhärenter Teilintelligenz erforscht. Konkret finden die entwickelten Konzepte
im RailCab2Forschungsprojekt Anwendung. In diesem Projekt werden innovative Güter-
und Personentransportsystemen der Zukunft, so genannte Shuttles, entwickelt. Diese wer-
den durch einen Linear-Motor angetrieben und verfügen über drahtlose Netzwerke zur
Kommunikation untereinander. Die Energieübertragung wird durch einen Streckenstator,
der einem üblichen Schienennetz hinzugefügt werden kann, erreicht.
Ein Shuttle ist eine kleine, autonome, führerlose Einheit (siehe Abbildung 1.3(a)). Diese
Shuttles sollen Personen und Güter, auf Nachfrage, individuell von ihrem Ausgangspunkt
zu ihrem gewünschten Zielort transportieren. Während der Fahrt können sich einzelne
Shuttles zu einem Konvoi zusammenschließen (siehe Abbildung 1.3(b)). Dies spart durch
die Windschattenfahrt Energie und erhöht bei stark frequentierten Strecken die Kapazität,
da die Züge nicht mehr getrennt fahren müssen. Die Shuttles bleiben während der Kon-
voifahrt weiterhin autonom und treffen individuelle Entscheidungen. Durch das autonome
Verhalten treten jedoch Schwierigkeiten auf. Das Problem besteht darin, die Shuttles so zu
koordinieren, dass sie so häufig wie möglich Konvois bilden um den Windwiderstand und
hiermit den Energieverbrauch zu reduzieren. Zusätzlich sollte der Abstand zwischen den
Fahrzeugen so gering wie möglich sein, um den Effekt noch zu verstärken. Die Erstellung
und Auflösung eines Konvois ist ein sicherheitskritisches Manöver, bei dem eine Reihe
von Echtzeitbedingungen eingehalten werden müssen. Dabei ist das Verhalten der Be-
schleunigungsregelung jedes Shuttles je nach aktuellem Szenario verschieden. So könnte
es für ein führendes oder einem allein fahrenden Shuttle ein Ziel sein, eine möglichst
gleichmäßige Geschwindigkeit zu halten. Dieses Verhalten ist innerhalb des Konvois je-
doch nicht optimal. Durch das autonome Verhalten der Shuttles kann es zu kleinen Abwei-
chungen zwischen den Geschwindigkeitseinstellungen der Regler kommen. Sobald ein
nachfolgendes Shuttle, welches in einem Abstand von 10 cm folgt, nur 0,01 km
hschneller
wäre, würde dies nach nur 36 Sekunden mit dem vorausfahrenden Shuttle kollidieren. Für
diesen Fall ist also ein Konvoimodus, in dem der Abstand konstant gehalten wird, besser
als eine konstante Geschwindigkeit.
2http://www-nbp.upb.de
4
1.3 Ziel und Lösungsansatz
(a) Shuttles im Konvoi (b) Zwei Shuttles bei der Bildung eines Konvois
Abbildung 1.3: Fallstudie „RailCab – Neue Bahntechnik Paderborn“ (Quelle: NBP)
1.3 Ziel und Lösungsansatz
Ziel dieser Dissertation ist es, Konzepte und Methoden zur Modellierung und Verifika-
tion mechatronischer Systeme zu entwickeln und formal zu beschreiben. Ziel ist es da-
bei, die besonders durch die Verwendung domänenübergreifender Modelle, wie sie bei
der Modellierung von mechatronischen Systemen vorkommen, entstehenden inhärenten
multi-Paradigmenwechsel [HH06] modellieren und verifizieren zu können. Der hier vor-
geschlagene Ansatz zur modell-basierten Entwicklung mechatronischer Systeme zeichnet
sich durch die Integration effizienter Verifikationstechniken, basierend auf dem Modell-
wissen, Abstraktionstechniken und einer geschickten Modellierung, aus.
Im Rahmen des Sonderforschungsbereichs 614 wurde die MECHATRONIC UML
[GHH+08b] entwickelt. Diese erlaubt es, Struktur und Verhalten von mechatronischen
Systemen und die Interaktion zwischen mechatronischen Systemen zu spezifizieren und
zu verifizieren. Dabei richtet sich die Struktur eines komplexen mechatronischen Systems
nach der von Lückel [LHLH01][OHG04][HOG04][Ge05] vorgeschlagenen Struktur.
Die konkrete Umsetzung dieser Struktur findet sich im Operator-Controller-Modul
(OCM) wieder. Die Informationsverarbeitung eines mechatronischen Systems kann als
Operator-Controller-Modul (OCM) aufgefasst werden. Ein solches Modul ist in die
drei Ebenen Controller, reflektorischer Operator und kognitiver Operator unterteilt.
Während der Controller direkten Zugriff auf die Aktuatoren des Systems hat, wird der
reflektorische Operator dazu verwendet, den Controller zu steuern und die Interaktion
mit anderen OCMs zu koordinieren. Die Aufgabe des kognitiven Operators besteht darin
Wissen über die Umwelt und das OCM selber zu sammeln und dazu zu nutzen, das
Verhalten des OCM besser an die gegebenen Anforderungen anzupassen.
Da die Software des reflektorischen Operators für die Steuerung des Controllers sowie
die Interaktion des OCMs mit anderen OCMs verantwortlich ist, ist sie sicherheitskri-
tisch. Deshalb besteht das Ziel dieser Arbeit in der Entwicklung eines ganzheitlichen,
5
Kapitel 1 Einleitung
effizienten Ansatzes zur Modellierung und Verifikation für die Software des OCMs sowie
für die Koordination zwischen OCMs.
Im Folgenden wird eine erste Idee vermittelt, wie und welche Techniken verwendet wer-
den, um die effiziente Verifikation von durch MECHATRONIC UML beschriebenen ver-
netzen mechatronischen Systemen zu ermöglichen. In Abbildung 1.4 ist ein Überblick
über das Zusammenspiel der in dieser Arbeit verwendeten Techniken „Kompositioneller
Aufbau & Verifikation“, „Abstraktion und Verfeinerung“, „Dekomposition“ und „Regel-
basierte Modellierung“ gegeben.
Abbildung 1.4: Die einzelnen „Bausteine“ zu einer effizienten Verifikation von mechatro-
nischen Systemen
Durch den nach innen schwächer werdenden Farbverlauf ist kenntlich gemacht, dass die
einzelnen Techniken nicht orthogonal zueinander stehen, sondern ineinander greifen und
aufeinander aufbauen. Dies wird in den Folgenden Abschnitten deutlich.
Kompositioneller Aufbau & Verifikation. Die kompositionelle Verifikationsme-
thode ist eine effiziente Möglichkeit, um große Modelle zu verifizieren [CGP00]. Die-
se stellen wirkungsvolle Methoden für die Verifikation eines nebenläufigen Systems dar,
weil hier direkt der Ursache für den exponentiellen Anstieg des Zustandsraums entgegen-
gewirkt wird. Im Gegensatz zur Überprüfung einer temporallogischen Spezifikation auf
dem globalen Zustandsraum wird die kompositionelle Verifikation lediglich auf Teilzu-
standsräumen mit lokalen temporallogischen Spezifikationen durchgeführt.
6
1.3 Ziel und Lösungsansatz
Ein Vorteil dieses Verfahrens gegenüber Verfahren, die auf globalem Zustandsraum ar-
beiten, ist, dass dadurch, dass Komponenten unabhängig voneinander spezifiziert und ve-
rifiziert werden können, Komponenten zu verschiedenen Zeitpunkten während der Soft-
wareentwicklung überprüft werden können. Durch diese unabhängige Verifizierung der
Komponenten lässt sich der Verifikationsprozess in den Modellierungsprozess integrieren.
Dies hat den Vorteil, dass Fehler zu einem sehr frühen Zeitpunkt in der Entwicklungspha-
se entdeckt und beseitigt werden können. Auch lassen sich so wiederverwendbare Module
spezifizieren und verifizieren.
In Abbildung 1.5 ist der in dieser Arbeit verfolgte Ansatz für einen kompositionellen
Aufbau anhand einer Komponentenarchitektur dargestellt [GTB+03][HG03][Hir04]. Das
Verhalten des Systems ist hierbei zustandsbasiert und rein zeit-kontinuierlich beschrie-
ben. Hier wird in einem ersten Schritt die Echtzeit-Koordination zwischen zwei Kompo-
nenten durch ein so genanntes Echtzeit-Koordinationsmuster modelliert (siehe Abbildung
1.5(a)), welches einzeln verifiziert werden kann. In einem nächsten Schritt wird hieraus
das Verhalten von Komponenten hergeleitet (siehe Abbildung 1.5(b)), das nun auch sepa-
rat verifiziert werden kann. Da jetzt sowohl die Kommunikation als auch das Komponen-
tenverhalten verifiziert wurden (und beide in einer bestimmten Verfeinerungsbeziehung
(siehe nächster Abschnitt) stehen), ist es möglich, das System durch reine, korrekte syn-
taktische Anwendungen der Koordinationsmuster und Komponenten zu modellieren.
shuttle coordinator
ConvoyCoordination
shuttle.convoy implies coordinator.convoy
(a) Echtzeit-Koordinationsmuster
<<Component>>
shuttle2 :Shuttle
shuttle <<Component>>
shuttle1 :Shuttle
coordinator
(b) Anwendung des Echtzeit-Koordinationsmusters
Abbildung 1.5: Kompositioneller Ansatz
Abstraktion & Verfeinerung. Eine Abstraktion eines Modells abstrahiert von den
internen Eigenschaften und ist das Gegenstück von Verfeinerung. Ist ein System A eine
7
Kapitel 1 Einleitung
Abstraktion von B, so ist B eine Verfeinerung von A. Die Eigenschaft der Abstrakti-
on und Verfeinerung kann zur Unterstützung der Verifikation genutzt werden. Kann das
ursprüngliche Modell aufgrund seiner Komplexität nicht in einem angemessenen Zeitrah-
men verifiziert werden, wird das Modell mit Hilfe der Abstraktion handhabbar gemacht.
Das neu erstellte Modell, das vom Umfang her kleiner ist, beinhaltet weiterhin die für
eine Verifikation relevanten Eigenschaften und kann schneller verifiziert werden.
Abbildung 1.6 zeigt exemplarisch den Aufbau eines zeit-kontinuierlichen Echtzeitsystems
und eines hybriden Systems. Das Verhalten beider Systeme ist durch Echtzeitverhalten
charakterisiert. Da eine falsche Spezifikation des Echtzeitverhaltens zum Beispiel zu ei-
nem Ausfall des Systems führen kann, muss hier eine geeignete Verifikation durchgeführt
werden. Im letzten Abschnitt wurde kompositionelles Model Checking zur Verifikation
des Echtzeitverhaltens vorgestellt. Zur Verifikation des Echtzeitverhaltens eines hybriden
Systems bietet es sich ebenfalls an, dieses Verfahren zu verwenden. Dazu muss jedoch
eine Abstraktion von dem hybriden Verhalten erfolgen. Diese wird mit Hilfe der Verfei-
nerungsbeziehung zwischen den beiden Systemen erstellt.
Universität Paderborn
AG Softwaretechnik
Prof. Dr. W. Schäfer
3.4 Abstraktion
Echtzeitsystem
Hybrides
S1
S2
Abstraktion von hybridem Verhalten
Hybrides
System
S1
C1
<D
>
C1
<D
>
S2
<D
1
>
<D
3
>
D
D
D
1
C2
<E
1
>
C3
<E
3
>
D
3
C4
<F
2
>
Modulare Echtzeitverifikation hybrider UML-Komponenten Seite: 41
<E
1
>
<E
3
>
<F
2
>
Abbildung 1.6: Abstraktion
Wichtig ist zudem, dass der unterschiedliche Aufbau der beiden Systeme berücksichtigt
wird. Während ein Echtzeitsystem auf einer Hierarchieebene spezifiziert wird, sind hybri-
de Systeme hierarchisch aufgebaut [GBSO04]. Abbildung 1.6 verdeutlicht diesen Unter-
schied. Aufgrund des unterschiedlichen Aufbaus reicht kompositionelles Model Checking
8
1.3 Ziel und Lösungsansatz
allein zur Verifikation des Echtzeitverhaltens nicht aus. Neben der Spezifikation von Echt-
zeitverhalten können zudem Inkonsistenzen durch den hierarchischen Aufbau und die da-
durch bedingte Rekonfiguration entstehen [GH05b][GH06].
Dekomposition. In hybriden Systemen ist häufig eine klare Trennung zwischen der
diskreten und der kontinuierlichen Komponente gegeben. Der kontinuierliche Teil dient
der möglichst exakten Abbildung mechatronischer oder physikalischer Abläufe und Zu-
sammenhänge. Die diskrete Komponente muss ihr Verhalten an die kontinuierliche Kom-
ponente koppeln, um so z.B. auf Veränderungen der Umwelt zu reagieren.
Durch die bereits erwähnte kompositionelle Modellierung der Echtzeitkoordination und
der Abstraktion, die Steuer- und Regelungsalgorithmen entsprechend integriert, ist es
möglich, für Verifikationszwecke eine abstrakte Betrachtung des relevanten kontinuier-
lichen und diskreten Verhaltens der Koordinationslogik vorzunehmen. Dabei werden ent-
sprechend benötigte Eigenschaften der unterlagerten Regelung, die mit klassischen Tech-
niken der Mathematik und der Regelungstechnik verifiziert werden können, als Basis für
weitere Betrachtungen verwendet. Darauf aufbauend lässt sich dann durch formale Veri-
fikationstechniken für Echtzeitsysteme eine Verifikation der benötigten Sicherheitseigen-
schaften der Echtzeitkoordination erreichen [GHH+06c].
In Abbildung 1.7 ist die hierbei zugrunde liegende Idee der Dekomposition skizziert.
Die obere Hälfte der Abbildung zeigt die Modellierung des Komponentenverbunds ei-
nes Shuttlekonvois. Jede Komponente kommuniziert mit ihrer Nachbarkomponente. In
einer Komponente selber ist das interne, sowohl Zeit-kontinuierliche als auch Werte-
kontinuierliche Verhalten skizziert. Der untere Teil der Abbildung zeigt die Dekomposi-
tion des Modells. Der Komponentenverbund wurde in die Kommunikation und die Kom-
ponenten (siehe Kompositioneller Ansatz), aufgeteilt. Weiterhin wurde auch das interne
Verhalten dekomponiert. So ist zu erkennen, dass nun das Zeit-kontinuierliche Verhal-
ten von dem Werte-kontinuierlichen Verhalten getrennt ist. Dies ermöglicht, wie schon
beschrieben, eine getrennte Verifikation der einzelnen Verhalten.
Regelbasierte Modellierung. In komplexen, vernetzten mechatronischen Systemen
stehen nur begrenzte Rechen- und Speicherkapazitäten zur Verfügung. Zusätzlich unter-
liegt das System zur Laufzeit einer Evolution abhängig vom gegebenem Kontext. Anfor-
derungen an komplexe, mechatronische Systeme sehen deshalb Dynamik vor, d.h. Steue-
rungssoftware muss zu Laufzeit ausgetauscht werden können.
In Schilling [Sch06] wurde bereits beschrieben, wie Graphtransformationssysteme zur
Beschreibung von dynamischen Veränderungen im Kontext von mechatronischen Syste-
men eingesetzt werden können. So wurde das in Abbildung 1.8 dargestellte Szenario auf
der Basis von Graphtransformationssystemen beschrieben. Die obere Hälfte des Bildes
9
Kapitel 1 Einleitung
shuttle1: Shuttleshuttle2: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
shuttle3: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
:P :P
shuttle1: Shuttleshuttle2: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
shuttle3: Shuttle
:P :P
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
Abbildung 1.7: Dekomposition der Struktur und des internen Verhaltens
zeigt einen aktuellen Systemzustand. Hier fahren zwei Shuttles hintereinander auf zwei
verschiedenen Streckenabschnitten. Die untere Hälfte des Bildes zeigt die koordinierte
Bewegung des Shuttles auf den Streckenabschnitten, modelliert durch eine graphbasierte
Regel. Hier wird beschrieben, welche Objekte existieren und wie miteinander verbunden
sind. Im vorliegenden Beispiel existiert eine Instanz des DistanceCoordinationPattern,
welches die Verhaltenskoordination zweier verbundener Shuttles realisiert.
Neben der reinen Beschreibung der Strukturdynamik eines einzelnen OCMs ist es mög-
lich, eine regelbasierte Modellierung für die Koordination von OCMs in gegebenen Kon-
texten, wie einem Konvoi, zu verwenden. So ist nachzuvollziehen, dass ein Konvoi, um
auch wirklich energieeffizient zu sein, aus mehr als zwei Shuttles bestehen muss. Weiter-
hin ist die Anzahl der Konvoiteilnehmer zum Zeitpunkt der Instanziierung der initialen
Konvoikoordination unbekannt. Mal muss ein und dasselbe Koordinationsprotokoll ein
Konvoi der Länge kund im nächsten Moment ein Konvoi der Länge k+ 1 koordinieren,
ohne die Stabilität eines Konvois zu verletzten. Abbildung 1.9 zeigt eine Graphtransfor-
mationsregel, die den Zusammenschluss zweier Shuttles zur Laufzeit in einem Konvoi
darstellt. Hier ist zu erkennen, welche Modellelemente bei der Konvoibildung erzeugt
werden.
10
1.4 Aufbau der Arbeit
s1:Shuttle
t1:Track
at
:Track
next :Track
go
next
at
s2:Shuttle
dc1:DistanceCoordinationPattern
front
rear
go
<<create>>
Regel:
Shuttle Shuttle
Systemzustand:
Abbildung 1.8: Beispiel für ein Graphtransformationssystem
: Shuttle
: Coordinator
: VelocityControl
:P
:P
: Shuttle
: VelocityControl :P :P:P ++ :P
:P
:P << last >> ++
t>5
clock:t
clock:t
clock:t
++ ++
++
++
++
++
Abbildung 1.9: Regelbasierte Modellierung der Koordination
1.4 Aufbau der Arbeit
Die vorliegende Arbeit gliedert sich wie folgt:
Im nächsten Kapitel 2 werden die für diese Arbeit notwendigen Grundlagen beschrieben.
Hier wird zuerst der Aufbau von mechatronischen Systemen beschrieben. Anschließend
wird die Idee der modell-basierten Softwareentwicklung beschrieben. An den hier fest-
gemachten Prinzipien werden nun Konzepte, Modelle und Verifikationstechniken für me-
11
Kapitel 1 Einleitung
chatronische Systeme vorgestellt, welche die Grundlage für die MECHATRONIC UML,
die als letztes vorgestellt wird, bilden.
Im Anschluss wird in Kapitel 3 der neue Ansatz zur Verifikation eines wie in Kapitel 2
eingeführten OCMs beschrieben und diskutiert.
In Kapitel 4 wird darauf eingegangen, wie sich mechatronische Systeme, dessen Hardwa-
reressourcen beschränkt sind und ihr Verhalten kontextabhängig dynamisch anpassen, mit
zeitbehafteten Graphtransformationssystemen modellieren lassen und welche Techniken
hier zur Verifikation eingesetzt werden.
Kapitel 5 bedient sich der Ansätze aus den vorherigen beiden Kapiteln 3 und 4 und be-
schreibt die Modellierung und Verifikation von parametrisierten Koordinationsmustern
mit Strukturveränderungen in mechatronischen Systemen.
In Kapitel 6 werden verwandte Arbeiten auf dem Gebiet der Verifikation von mechatro-
nischen Systemen diskutiert.
Die vorliegende Dissertation schließt in Kapitel 7 mit einer Zusammenfassung. Dabei
werden die Ergebnisse dieser Arbeit zusammengefasst und ein Überblick über mögliche
Erweiterungen des Ansatzes wird gegeben.
12
Kapitel 2
Grundlagen
Dieses Kapitel behandelt die theoretischen Konzepte und Modelle, die als Grundlage zu
dieser Arbeit dienen. Im ersten Teil (Abschnitt 2.1) werden mechatronische Systeme, wie
sie in dieser Arbeit aufgefasst werden, beschrieben. Daran schließt sich ein Abschnitt
über die Grundlagen der Regelungstechnik, wie sie für die Modellierung von mechatroni-
schen Systemen benötigt werden an. Dieser Abschnitt motiviert besonders die Integration
der Domäne Regelungstechnik in die Domäne der Softwaretechnik. Nachfolgend schließt
sich ein Abschnitt über die Modell-basierte Softwareentwicklung mechatronischer Syste-
me an (siehe Abschnitt 2.3). In diesem Abschnitt werden Modelle zur Beschreibung von
mechatronischen Systemen sowie Verifikationsverfahren grundlegend erklärt. Im Detail
werden Automatenmodelle sowie Graphmodelle vorgestellt und deren Gemeinsamkeiten
diskutiert. Weiterhin werden hierfür Verifikationsverfahren, Model Checking und Erreich-
barkeitsanalysen beschrieben. Der MECHATRONIC UML Ansatz (siehe Abschnitt 2.4)
integriert alle bis dahin vorgestellten Modelle und Verfahren zur Modellierung und Ve-
rifikation von mechatronischen Systemen. Der MECHATRONIC UML Ansatz bildet die
Grundlage für alle in dieser Arbeit neuen Modellierungs- und Verifikationsverfahren. Das
Grundlagenkapitel schließt mit einer Zusammenfassung im letzten Abschnitt 2.5.
2.1 Mechatronische Systeme
Der Begriff „Mechatronik“ (Mechanik - Elektronik) wurde 1969 von einer japanischen
Firma geprägt [STF96] und bezeichnete zunächst nur die ganzheitliche Betrachtung me-
chanischer und elektrischer Bestandteile eines technischen Systems. Im Laufe der Zeit
wurden immer häufiger Mikrokontroller zu technischen Systemen hinzugefügt, so dass
die Mechatronik heute die interdisziplinäre Betrachtung mechanischer, elektrischer und
informationstechnischer Bestandteile umfasst. Die stetige Zunahme des informationstech-
nischer Anteils ermöglicht unter anderem mechatronische Systeme, die ihr Verhalten an
geänderte Bedingungen ihrer Umwelt anpassen, also eine Teilintelligenz besitzen.
13
Kapitel 2 Grundlagen
In der Entwicklung mechatronischer Systeme wird zunächst ein Modell des Systems er-
stellt. Dieses Modell wird dann in ein reales System überführt. Aufgrund der Komplexität
mechatronischer Systeme hat sich in den letzten Jahren eine komponentenbasierte Mo-
dellierung bewährt. Hierbei wird das System als Menge von Komponenten dargestellt,
die Informationen verarbeiten. Diese Komponenten sind untereinander verbunden, sodass
sich das Verhalten des Gesamtsystems aus der Interaktion der einzelnen Komponenten er-
gibt. Jede dieser Komponenten ist durch die von ihr zur Verfügung gestellten und benötig-
ten Informationen, deren Verarbeitung, sowie die Parameter dieser Verarbeitung eindeutig
charakterisiert.
Im Rahmen des SFB 614 wurde der in Abbildung 2.1 dargestellte hierarchische, modulare
Aufbau von mechatronischen Systemen entwickelt. Abbildung 2.1 zeigt den Aufbau eines
komplexen mechatronischen Systems nach Lückel [LHLH01][Ge05][GHH+08b].
GIESE et al.: MODEL-DRIVEN DEVELOPMENT WITH MECHATRONIC UML (SEPTEMBER 23, 2006, REV ISION : 1.43) 3
The distinction between the reflective and cognitive operator
clearly decouples control under hard real-time constraints
from long-range planning and the resulting input for self-
optimization.
In general, the OCM-hierarchy defines a strictly hierarchical
control flow low, i.e. each level tries to execute control as
much as possible locally but whether reconfiguration is to be
executed is decided on the next higher level.
lineardriveOCM
energy
subsystem
RO+C
trackcontrolOCM
motion
control
RO+C
shuttle
RO+C
suspensiontiltOCM
hierarchicaldecomposition(hardreal-time)
peer-to-peercoordination(softreal-time)
motion
control
CO
energy
sub-
system
CO
safedecoupledguidance(softreal-time)
shuttle
RO+C
shuttle
CO
shuttle
CO
peer-to-peercoordination(hardreal-time)
shuttleOCM shuttleOCM
motioncontrolOCM energysubsystemOCM
Fig. 3. The OCM hierarchy of a shuttle and its connections with other
shuttles
The OCM hierarchy can be nested, i.e. each nesting level
may include an OCM which however does not include the
controller part. Controllers, which implement the continuous
part of the software, usually exist only on the leave level of
a nested OCM hierarchy. As an example, consider the above
mentioned shuttles of the RailCab project. The architecture
is defined by OCMs w.r.t. the reflective operators and the
controllers as depicted in Fig. 3. A shuttle consists of compo-
nents like the suspension/tilt module, the engine, the tracking
module1etc. which in turn is defined by OCMs.
As a complete mechatronic system usually consists of
several concurrently running components, there exists a further
possibility of communication between components besides the
strict hierarchical control flow. Top-level OCMs of several
nested hierarchies, which usually represent a major system
component, may act as freely interacting software agents. This
means that agents exchange information but no central control
is defined anymore. As examples of such major system com-
ponents consider the different shuttles, stations and possibly
job brokers of the RailCab project. These agents interact with
each other through well-defined interfaces. In principle, the
controllers of different agents can interact with each other,
as well as the reflective operators and the cognitive operators,
each on their corresponding levels. In any case their interaction
is limited to a peer-to-peer connection, i.e. for safety reasons
no broadcasting of messages is supported which avoids any
side effects between many messages being exchanged concur-
rently.
1TODO: ”Spurf¨
uhrungsmodul” heisst laut NBP Seite tracking mod-
ule, aber wohl auch nur dort. Beim suchen habe ich eher steer-
ing module gefunden: z.B. folgendes: The aim of the steering con-
troller is to provide good tracking performance when the vehicle is in
tight curves and to minimize wheel/rail wear. It will utilize the same
hardware (actuators, sensors and controller) and will require additional
software only (from: http://www.lboro.ac.uk/departments/el/research/esc-
miniconference/papers/pearson.pdf).
As all safety and time critical aspects are handled by the re-
flective operators and controllers, peer-to-peer communication
(across the hierarchy) is also allowed between the different
cognitive operators of different levels in the nested OCM
hierarchies. This may facilitate complex planning and the
needed information exchange between different components
but the interface between a reflective and cognitive operator
resp. in each component and on each nesting level will make
sure that no changes are introduced by the cognitive operators
which invalidate safety properties.
Our MDD approach takes the general model of Fig. 3
as an informal architectural basis. It provides for a formal
definition of arbitrary OCM hierarchies, their behavior as well
as their peer-to-peer communication using a refined UML 2.0
component model and a refined notion of statecharts including
the definition of timing constraints and hybrid behavior. This
definition is the input for our model checking approach which
uses standard model checkers but before using them decom-
poses the overall system in such a way that the individual
parts can be checked separately, i.e. no side effects between
their behavior definitions exist which invalidate the model
checking results. This is guaranteed mainly by the well-defined
interfaces between the three levels of the OCM hierarchy and
especially the separation between the reflective and cognitive
operator as well as the completely independent side-effect free,
peer-to-peer communication between different components.
TODO:
Wilhelm, du wolltest das Folgende noch ¨
uberarbeiten.
For the specific domain of mechatronic system, the outlined
MUML approach therefore includes the architectural description of
the software via component and connectors for hierarchies and peer-
to-peer structures.2
III. THE HIERARCHICAL COMPONENT MODEL
The formal definition of an OCM hierarchy, as given in
this section, not only defines component interfaces in such
a way that modular model checking becomes possible, but
also enables syntactic checks of important system properties
such as the consistent refinement of timing restrictions on the
various levels of the hierarchy.
A. Static Component Structures
1) Structure: To support the coupling of time-continuous
control behavior with discrete behavior, we extend the defi-
nition of ports in the UML 2.0 component model. Ports may
also be defined by time-continuous variables. While a signal
is sent and received at discrete points in time (cf. SignalEvent
in UML), a time-continuous variable has a well-defined value
for each point in time.
As an example the MUML model of the OCM of the shuttle
responsible for travelling either in convoy or stand alone
mode is depicted in Fig. 4. The Shuttle component instance
sh contains a AccelerationControl (AC) component instance ac
representing the controller and a Planer component instance
pl representing the cognitive operator. The reflective operator
2Due to the ROOM [?] concepts present in UML 2.0 the deficits of former
UML versions as an architectural description language are not present an more
(cf. [?]).
Abbildung 2.1: Hierarchische Struktur eines mechatronischen Systems nach Lückel
Die Basis bildet das mechatronische Funktionsmodul (MFM). Es ist aus einer mechani-
schen Grundstruktur, Sensoren und Aktoren und einer lokalen Informationsverarbeitung
aufgebaut. Die mechanische Grundstruktur führt die Aufgaben des mechatronischen Sys-
tems in der realen Welt aus. Dazu gehört zum Beispiel das Heben einer Last oder wie in
dem in Abbildung 2.1 dargestellten Beispiel das Neigen eines Fahrzeugs (suspension tilt
OCM). Die Steuerung des Systems übernimmt die Informationsverarbeitung. Sie kom-
muniziert über Sensoren und Aktoren mit der mechanischen Grundstruktur. Autonome
mechatronische Systeme (AMS) sind aus MFM aufgebaut, die informationstechnisch oder
14
2.2 Regelungstechnik
mechanisch gekoppelt sind. Die Informationsverarbeitung eines AMS übernimmt überge-
ordnete Aufgaben. Dazu gehören zum Beispiel die Überwachung mit Fehlerdiagnose und
Instandhaltungsentscheidungen (motion control OCM). Außerdem werden Vorgaben für
die lokale Informationsverarbeitung generiert. Aus den AMS werden vernetzte mechatro-
nische Systeme (VMS) gebildet. Sie entstehen durch die Verbindung von AMS über die
Informationsverarbeitung. Im dargestellten Beispiel entspricht das Feder-Neige-Modul
dem MFM, das Shuttle einem AMS und ein Fahrzeugverband einem VMS. In der Abbid-
lung ist zu sehen, dass jede Schicht, MFM, AMS sowie VMS durch OCMs beschrieben
wird.
Abbildung 2.2 zeigt ein Operator-Controller-Modul (OCM) [Ge05][HOG04]. Das OCM
ist in die drei Ebenen Controller, reflektorischer Operator und kognitiver Operator auf-
geteilt. Der Controller bildet die unterste Ebene. Er arbeitet direkt mit der mechanischen
Grundstruktur, verarbeitet auf direkte Weise die Messsignale, ermittelt daraus Stellsignale
und gibt sie an die mechanische Grundstruktur weiter. Der Controller arbeitet kontinuier-
lich und unter harten Echtzeitbedingungen. Der reflektorische Operator bildet die mittlere
Ebene. Er steuert den Controller und unterliegt ebenfalls harten Echtzeitbedingungen. Er
agiert nicht direkt mit dem System, sondern beeinflusst den Controller durch Initiierung
von Parameter- und Strukturänderungen. Die oberste Ebene bildet der kognitive Operator.
Auf dieser Ebene kann das System Wissen über sich und die Umgebung zur Verbesserung
des eigenen Verhaltens nutzen. Der kognitive Operator unterscheidet sich von den ande-
ren beiden Ebenen vor allem dadurch, dass er weichen Echtzeitanforderungen unterliegt.
Das dargestellte System kann also in zwei Teile untergliedert werden: Ein Teil, der unter
harten Echtzeitbedingungen arbeitet und den Controller und den reflektorischen Opera-
tor umfasst und ein Teil, der unter weichen Echtzeitbedingungen arbeitet. Zum letzteren
gehört der kognitive Operator. Um zu verstehen, wie das Werte-kontinuierliche Verhalten
des Controllers spezifiziert ist, werden im Folgenden Grundlagen der Regelungstechnik
beschrieben.
2.2 Regelungstechnik
Technische Systeme lassen sich im regelungstechnischen Sinn durch Zustandsgrößen be-
schreiben. In vielen Fällen will man diese Zustandsgrößen gezielt beeinflussen, um ge-
wünschtes Verhalten zu erzielen. Das Ziel ist es, die Zustandsgrößen an einen bestimmten
Wert zu ändern oder sie an einem Wert zu halten (z.B. die Rotationsgeschwindigkeit soll
immer 100rad
sbetragen).
In der Regelungstechnik liegt der Schwerpunkt nicht auf der Konstruktion eines Sys-
tems, sondern auf der Beschreibung der kontinuierlichen Zustandsgrößen durch Differen-
15
Kapitel 2 Grundlagen
Abbildung 2.2: Operator-Controller-Modul
tialgleichungen. Hierbei wird das dynamische Verhalten der Regler durch Differential-
gleichungen beschrieben, die dafür sorgen, dass sich das System wie gewünscht verhält
[Föl05].
In Abbildung 2.3 ist die generelle Struktur einer Steuerung dargestellt. Das Problem ei-
ner Steuerung kann wie folgt beschrieben werden: Gegeben sei das Ziel eines Systems.
Die Stellgröße (control) yund die Zustandsgröße/Ausgangsgröße (controlled) x. Die Auf-
16
2.2 Regelungstechnik
gabe der Steuerung ist die Beeinflussung von xdurch yin der Art und Weise, dass ein
gewünschtes Verhalten trotz Einwirkung von Störgrößen z(disturbance), die nicht immer
bekannt sind, erreicht wird. xund ysind Elemente eines Vektors ~x bzw. ~y. Da Systeme mit
mehr als einer Zustandsgröße und einer Stellgröße nach demselben Prinzip funktionieren,
werden im Folgenden nur Systeme mit xund ybetrachtet.
Plant
control y controlled x
disturbance z
Abbildung 2.3: Generelle Struktur einer Steuerung
Grundsätzlich wird zwischen Steuerungen (Feed-Forward-Regler] und Reglern (Feed-
Back-Reglern) unterschieden. Steuerungen reagieren schneller auf a priori bekannte Stö-
rungen, allerdings nicht auf unbekannte Störungen. Regler reagieren durch den Regelkreis
auf jede Art von Störungen, allerdings nur, wenn die Zustandsgrößen und die Abweichun-
gen messbar sind. Das Ziel einer Regelung ist es, die Differenz zwischen einem Vorgabe-
wert und der Realität gegen 0zu regeln. (siehe Abbildung 2.4).
control y
Control law Plant
zdisturbance
e=w−rw difference
control
−
Controller
variable
reference controlled x
Abbildung 2.4: Einfacher Regelkreis
Die Entscheidung für einen bestimmten Regler-Typ hängt von den Zeiteigenschaften und
der Genauigkeit des Systems ab. In der Literatur wird hier zwischen drei Regler-Typen
unterschieden: Proportionalregler (P), Proportional-Integral-Regler (PI) und Proportional-
Integral-Differential-Regler (PID). Letzterer wird am meisten in der Praxis verwendet
[HPPS03]. Je nach Eigenschaft der Strecke und der vorgegebenen Anforderungen werden
nun die Regler ausgesucht, um eine möglichst hohe Stabilität des Systems zu erreichen
dabei Überschwingen zu vermeiden und Reaktionszeiten zu verbessern.
2.2.1 Adaptive Regler
Einige Systemänderungen sind nicht vorhersagbar und gewöhnliche Regelsysteme kön-
nen möglicherweise nicht richtig reagieren, wenn die Eingangs- und Ausgangsrelation
sich verändert. Manchmal können diese Effekte durch herkömmliche Regelungstechni-
ken geregelt werden, jedoch nicht immer [IML92].
17
Kapitel 2 Grundlagen
Adaptive Regelungen können hier helfen, die Stabilität sowie die Reaktionszeit zu ver-
bessern. Dieser Ansatz verändert die Regler-Algorithmen in Echtzeit, um sich an die Än-
derungen der Umgebung anzupassen. Allgemein beobachtet der Regler periodisch die
System Eingabe- und Ausgaberelation und ändert den Regler-Algorithmus. Das Ziel ist
es, dadurch den Regler so robust wie möglich zu haben, und damit das dynamische Sys-
tem so unempfindlich gegen Störungen wie möglich zu halten.
In der Literatur gibt es drei Hauptansätze, um adaptive Feed-Back Regler zu modellieren:
Der erste, triviale Ansatz legt z.B. in einer Datenbank a priori fest, wie sich der Regler
bei bestimmten Änderungen zu verhalten hat. Neben der trivialen adaptiven Regelung
gibt es noch den Model Reference Adaptive Control (MRAC) und Self-Tuning Regulators
(STRs) Ansatz. Beim MRAC Ansatz beschreibt ein Referenzmodell die Systemeigen-
schaften. Der adaptive Regler ist hier so aufgebaut, dass das System bzw. die Strecke sich
so verhält, wie das Referenzmodell. Die Ausgaben des Modells werden mit den tatsäch-
lichen Ausgaben verglichen und die Differenz wird verwendet, um die Regler-Parameter
anzupassen. Im dritten Ansatz STRs werden selbsteinstellende Regler verwendet. Diese
nehmen ein lineares Modell an. Die Regler verwenden die zugrunde liegenden Reglerge-
setze, um ihre Koeffizienten zu verändern.
2.2.2 Rekonfiguration
Bis jetzt wurden nur Regler betrachtet, die immer aktiv sind. Zusätzlich wurde angenom-
men, dass für eine Aufgabe immer ein Regler zur Verfügung steht. Für das Shuttle System
wird Rekonfiguration benötigt, um die Regler-Algorithmen auszutauschen, wenn z.B. ein
Konvoi gebildet wird um die beste Strategie zu fahren. Da die Ressourcen in eingebetteten
Systemen typischerweise begrenzt sind, ist es erforderlich, diese soweit wie möglich ein-
zusparen. Hierfür wird Rekonfiguration verwendet, um zwischen verschiedenen Rollen,
z.B. Führungsfahrzeug oder letztes Shuttle im Konvoi, hin und her zuschalten. Um dies
zu ermöglichen, muss eine Logik, welche die Reglerstruktur steuert, hinzugefügt wer-
den. Durch Hybride Rekonfigurations Charts (siehe Kapitel 2.4) kann modelliert werden,
welche Regler in welcher Situation aktiv oder inaktiv sein sollen.
2.2.3 Block Diagramme
Eine gängige Technik für die Modellierung von Reglerstrukturen sind hierarchische Block
Diagramme. Block Diagramme bestehen aus Grund-Blöcken, die das Verhalten modellie-
ren und hierarchischen Blöcken, welche die Grund-Blöcke oder andere hierarchische Blö-
cke beinhalten, um die visuelle Komplexität zu reduzieren. Jeder Block besitzt Eingabe-
und Ausgabesignale. Blöcke sind durch gerichtete Verbindungen untereinander verbun-
18
2.2 Regelungstechnik
den, um den Informationsfluss darzustellen. Z.B. kann das Ausgabesignal eines Blocks
als Eingabesignal eines anderes Blocks verwendet werden.
Definition 1
Ein kontinuierlicher Block Mwird durch ein 7 Tupel (Vx, V u, V y, F, G, C, X0)definiert:
•Vx: Menge der Zustandsvariablen,
•Vu: Menge der Eingabevariablen,
•Vy: Menge der Ausgabevariablen,
•F⊆EQ(V˙xSVa, V xSVuSVa)mit Va=VyTVu: beschreibt den Fluss der
Zustandsvariablen,
•G⊆EQ(V˙ySVa, V xSVuSVa): bestimmt die Ausgabevariablen,
•C∈COND(Vx): Invariante, welche die Menge der zulässigen Zustände bestimmt
und
•X0: Menge der Anfangszustände.
Die Menge EQ(Vl, Vr)bezeichnet alle Gleichungen der Form vl=fi(v1
r, ..., vn
r), mit den
Funktionen fi, die nArgumente besitzen, und den Variablen vl∈Vlund v1
r, ..., vn
r∈Vr.
Die Menge COND(V)beinhaltet alle Bedingungen über die Variable V.
Ein Block Mist wohl-definiert, wenn für alle Differentialgleichungen des Systems FSG
gilt, dass es keine zyklischen Abhängigkeiten gibt, keine doppelten Zuweisungen, alle un-
definierten Verweise auf Variablen in Vu−Vyenthalten sind und jeder Zustandsvariablen
Vxund Ausgabevariablen Vyein Wert zugewiesen ist.
2.2.3.1 Beispiel
Wie in Kapitel 1.2 beschrieben, wird die Konvoifahrt genutzt, um möglichst energieeffizi-
ent zu fahren. Das ist nur dann möglich, wenn die Shuttles möglichst nah hintereinander
fahren. Hierbei muss die Distanz ständig geregelt werden, um Auffahrunfälle zu vermei-
den. Die Geschwindigkeit des Shuttles muss also ständig in Bezug auf die Distanz zum
Führungsfahrzeug angepasst werden. Um dies zu erreichen, benötigt das hinterherfah-
rende Shuttle zwei Regler, einen Distanzregler und einen Geschwindigkeitsregler. Das
Führungsshuttle hingegen benötigt nur einen Geschwindigkeitsregler.
Als erstes wird das Modell der Strecke beschrieben. Dieses ist in Abbildung 2.5 darge-
stellt. Es gilt: m˙v+bv =u, y =v, wobei mdie Masse eines Shuttles, vdie Geschwin-
digkeit, ˙vdie Ableitung der Geschwindigkeit v,bv die Reibungkraft, udie Antriebskraft
und ydie Zustandsgröße ist.
19
Kapitel 2 Grundlagen
Abbildung 2.5: Model der Strecke
Als nächstes wird der PID Regler beschrieben. Der Unterschied zwischen dem gewünsch-
ten Eingabewert und dem tatsächlichen Ausgabewert wird durch den Fehler edargestellt
(siehe Abbildung 2.4). ewird an den PID Regler weitergeleitet, der daraufhin die Ablei-
tung sowie das Integral von eberechnet. Das Signal uist nun, nachdem es zum Regler
weitergeleitet wurde, gleich dem Proportionalglied KPmultipliziert mit dem Betrag des
Fehlers plus dem Integrationsglied KImultipliziert mit dem Integral des Fehlers plus
dem Differenzialglied KDmultipliziert mit der Ableitung des Fehlers. Das Signal uwird
danach an die Strecke weitergegeben. Der neue Ausgabewert xwird entsprechend herge-
leitet. Der neue Ausgabewert xwird erneut zurück an den Sensor geleitet, um den neuen
Fehler ezu bekommen. Der Regler bekommt diesen neuen Fehler und berechnet die Ab-
leitung und das Integral erneut (siehe Abbildung 2.6). Der PID Regler wurde entsprechend
am linearisierten Modell der Strecke ausgelegt.
Abbildung 2.6: PID Geschwindigkeitsregler
2.2.3.2 Rekonfiguration
Abbildung 2.7 zeigt die Logik der Abstandsregelung in einem Stateflow Diagramm. Das
Modell besteht aus drei Modi. Initial ist das Shuttle im Modus NoConvoy. Die Ereignisse
convoyFront und convoyRear erzwingen den Wechsel von NoConvoy zum Modus Con-
voyFront oder ConvoyRear. Das Ereignis breakConvoy löst den Konvoi auf und erzwingt
20
2.2 Regelungstechnik
den Wechsel in den Modus NoConvoy. In den Modi NoConvoy und ConvoyFront ist die
Geschwindigkeitsregelung implementiert. Im Zustand ConvoyRear ist die Distanzrege-
lung implementiert.
Abbildung 2.7: Stateflow Diagramm der Shuttlesteuerung
In Abbildung 2.8 ist das hybride Modell einer Shuttleregelung für die Konvoiregelung
als Simulink Diagramm dargestellt. Es beinhaltet die Reglerlogik (oben links), die Regl-
ergesetze für die Distanz- und Geschwindigkeitsregelung (mitte) und die Beschreibung
des physikalischen Modells (rechts). Der Block zur Distanzkontrolle beinhaltet sowohl
den Distanzregler als auch den Geschwindigkeitsregler. Der schwarze Balken (rechts) ist
ein Umschalter. Durch die Mode/Konfigurationseingabe beider Kontroller und dem Um-
schalter ist es möglich, den gerade benötigten Regler zu aktivieren und einen anderen zu
deaktivieren.
Abbildung 2.8: Hybrides Modell der Shuttelsteuerung
21
Kapitel 2 Grundlagen
2.3 Modell-basierte Softwareentwicklung
Die Techniken der modell-basierten Softwareentwicklung wurden eingeführt, um die
Komplexität eines Problems zu reduzieren und ein abstrakteres Modell zu erhalten, wel-
ches frei von Implementierungsdetails ist [Fav05]. Damit wird das Modell übersichtlicher
und es lassen sich einfacher Operationen durchführen. Drei wesentliche Schritte in der
modell-basierten Entwicklung sind die (1) Modellierung, (2) Verifikation und (3) Code-
synthese.
Die UML hat sich als Standardmodellierungssprache für die modell-basierte Software-
entwicklung durchgesetzt. Sie bietet eine große Palette von Diagrammen, um ein System-
modell zu erstellen und ihr Verhalten zu spezifizieren. Um allerdings komplexe, vernetz-
te mechatronische Systeme, wie sie bereits vorgestellt wurden, adäquat zu modellieren,
reicht die UML nicht mehr aus. Um dem domänenübergreifenden Charakter von mecha-
tronischen Systemen gerecht zu werden, müssen bei der modell-basierten Entwicklung
auch die entsprechenden Techniken der verschiedenen Domänen miteinander integriert
werden [Bur06][HHKS08][GHH+08b][BGH+07]. Neben der Modellierung steht bei der
modell-basierten Entwicklung auch die Verifikation im Vordergrund. Da nun Modelle des
eigentlichen System vorliegen, ist es möglich, diese formal zu verifizieren. Jedoch wirft
die Welt der komplexen, vernetzen mechatronischen Systeme auch hier Probleme auf.
Bisherige Ansätze lassen sich nicht anwenden, da sie mit der Vielfalt der Modelle der
anderen Domänen nicht entsprechend klar kommen oder nicht skalieren [GH06].
Im Folgenden werden nun zuerst Verhaltens- und Strukturmodelle vorgestellt, die bei der
klassischen Modellierung und Verifikation von mechatronischen Systemen bisher ver-
wendet wurden. Die Auswahl der aufeinander aufbauenden Modelle wurde getroffen,
da sie die syntaktische und semantische Grundlage für die später in der MECHATRO-
NIC UML eingeführten Modelle bilden.
2.3.1 Automaten
Um das Verhalten von reaktiven Systemen zu modellieren, können endliche Automaten
verwendet werden. Von den verschiedenen existierenden Formen von Automaten werden
hier die endlichen Automaten betrachtet, welche auch bei [CGP00] als Grundlage für das
dort definierte Modell eines Timed Automaton dienen. Für weitergehende Informationen
zu endlichen Automaten siehe [HU79]. Ein endlicher Automat setzt sich zusammen aus
einzelnen Knoten, welche über Kanten miteinander verbunden sind. Die Knoten stellen
einzelne Zustände und die Kanten Transitionen zwischen diesen dar.
22
2.3 Modell-basierte Softwareentwicklung
Definition 2
Ein endlicher Automat Mist ein Quadrupel M:= (Σ,Q,∆,Q0), wobei Σein endli-
ches Eingabealphabet, Qeine endliche Menge an Zuständen, ∆⊆ Q × ∆× Q eine
Transitionsrelation und Q0die endliche Menge der initialen Startzustände darstellt.
Ein endlicher Automat Mbesteht aus Q, einer endlichen Menge an Knoten bzw. Zustän-
den, ∆der Menge an Kanten, welche die Transitionen zwischen den Zuständen abbilden,
aus Q0, einer endlichen Menge an initialen Startzuständen sowie aus Σ.Σsetzt sich zu-
sammen aus einer Menge an möglichen Eingaben, bei welchen über die Transitionen
δ∈∆zwischen den Zuständen aus Q∪Q0gewechselt werden kann. Ein Beispiel für
einen solchen Automaten zeigt die Abbildung 2.9. Der abgebildete Automat setzt sich
zusammen aus der Eingabemenge Σ = {a, b}, den Zuständen Q={s0, s1}und dem
Startzustand Q0={s0}. Die Menge der Übergangstransitionen ∆lässt sich beschreiben
durch die Tripel (s0, a, s1)und (s1, b, s0).
<< Component >>
Shuttle
<< Component >>
c: Coordinator
<< Component >>
vc1: VelocityControl
S0S1
a
b
Abbildung 2.9: Ein endlicher Automat mit den Zuständen s0, s1und zwei Kanten, welche
mit aund bbeschriftet sind.
Die in diesem Abschnitt vorgestellten Modelle eignen sich zur Beschreibung von Sys-
temen, welche durch ein diskretes Zeitmodell (siehe [CGP00], Kapitel 16) beschrieben
werden können. Um Zeit-kontinuierliche Eigenschaften zu modellieren, müssen die Mo-
delle erweitert werden. Es gibt verschiedene Möglichkeiten, um Zeit in einem Modell
abzubilden. Dies bezieht sich z.B. auf das Verhalten von Uhren (eine solche Uhr wird
nachfolgend Clock genannt), durch welche das Fortschreiten der Zeit abgebildet wird. So
wird bei [CGP00][Kop97] unterschieden zwischen diskreter und kontinuierlicher Echt-
zeit, wobei in der vorliegenden Arbeit Modelle mit kontinuierlichem Echtzeit-Verhalten
betrachtet werden. Als Gemeinsamkeit für die hier verwendeten Modelle gilt weiterhin,
dass alle dort auftretenden Uhren mit der gleichen Geschwindigkeit voranschreiten und
somit synchron laufen. In [GHH06a] wird beschrieben, weshalb diese Annahme für me-
chatronische Systeme, wie hier beschrieben, gültig ist.
2.3.2 Timed Automata
Synchrone Modelle basieren meistens auf einem diskreten Zeitmodell. Ein Beispiel ist
das gleichmäßige Takten einer Hardwareeinheit. Dies hat zur Folge, dass als Uhrwerte
23
Kapitel 2 Grundlagen
nur positive ganzzahlige Werte zur Verfügung stehen und Ereignisse nur zu ganzzahli-
gen Zeitpunkten auftreten können. Will man nun asynchrone Modelle untersuchen, muss
man ein kontinuierliches Zeitmodell zu Grunde legen. Hier können z.B. Ereignisse in be-
liebig kleinen Abständen hintereinander auftreten. Um solche Systeme zu diskretisieren,
ist es nötig, kleine, a priori vorgegebene minimale Zeitintervalle, festzulegen. Abstände
zwischen Ereignissen können nun als Vielfache dieser Maßeinheit ausgedrückt werden.
Dieses ist jedoch schwer von Beginn an festzulegen und schränkt zusätzlich die Genau-
igkeit eines Systems ein. Brzozowski und Seger [BS91] haben sogar gezeigt, dass das
Erreichbarkeitsproblem für asynchrone Schaltkreise unter der Annahme von festen Zeit-
intervallen, Zeit wird diskretisiert, nicht korrekt gelöst werden kann. Hinzu kommt, dass
der Zustandsraum bei der Verwendung von sehr kleinen Intervallen, wie sie bei einer mög-
lichst exakten Modellierung eines asynchronen Systems vorkommen, schlagartig explo-
diert. Dadurch wird die Verifikation undurchführbar. Obgleich viele verschiedene Ansätze
zur Modellierung von Systemen mit einem kontinuierlichen Zeitsystem gemacht wurden,
hat sich das Modell der Timed Automata von Alur, Courcoubetis und Dill [ACD90] eta-
bliert, welches im Folgenden beschrieben wird.
Ein Timed Automaton ist ein endlicher Automat, der über eine feste Anzahl von Clocks
verfügt. Eine Clock kann dabei einen Wert aus den positiven reellen Zahlen annehmen,
wodurch Modelle mit kontinuierlichen Echtzeit-Bedingungen formuliert werden können.
Die Transitionsrelation ∆des Timed Automaton verfügt zusätzlich zu den endlichen Au-
tomaten über zeitliche Bedingungen, welche erfüllt sein müssen, damit der jeweilige
Übergang stattfinden kann. Diese Bedingungen werden als Guards bezeichnet. Weiter-
hin kann eine solche Transition über so genannte Resets verfügen, welche beim Schalten
dafür sorgen, dass einzelne Clocks auf den Zahlenwert 0zurück gesetzt werden.
Ähnlich wie die Kanten (Kanten repräsentieren die Transitionen) über Guards verfügen
können, kann jeder Knoten ebenfalls zeitliche Bedingungen besitzen, so genannte Invari-
anten. Diese müssen erfüllt sein, damit bei dem jeweiligen Knoten verweilt werden kann.
Entsprechend ist es möglich bei einem Knoten zu verweilen, während die Transitionen
zwischen den einzelnen Knoten in Null-Zeit passiert.
Im Unterschied zu den einfachen endlichen Automaten, bei denen die Zustände durch die
Menge Qbeschrieben werden können, hängt der Zustand beim Timed Automaton zusätz-
lich von den geltenden Bedingungen über die einzelnen Clocks ab. Somit wird hier nicht
von der Menge der Zustände Q, sondern von so genannten Locations Sgesprochen, wel-
che den Knoten des Automaten zugeordnet sind. Dabei kann es innerhalb einer Location
für die einzelnen Clocks nicht nur eine Belegung geben, sondern eine unendlich große
Menge an möglichen Belegungen. Diese Eigenschaft ergibt sich aus der Verwendung von
Ungleichungen bei den Invarianten und Guards, durch welche komplette zeitliche Er-
reichbarkeitsräume aufgebaut werden können. So ist es möglich innerhalb einer Location
für eine Zeitspanne zu verweilen. Dabei können die Clockvariablen Werte aus den posi-
24
2.3 Modell-basierte Softwareentwicklung
tiven reellen Zahlen annehmen. Auf diese Eigenschaft der Locations wird im Folgenden
noch genauer eingegangen.
Ein Beispiel für einen entsprechenden Timed Automaton zeigt die Abbildung 2.10. Der
Automat verfügt über die Locations s0,s1, die zwei Clock-Variablen x1,x2sowie über
die Transition a, welche s0mit s1verbindet und die Transition b, welche s1mit s0verbin-
det. Der Automat startet in der Location s0und kann dort höchstens solange verweilen,
bis die Clock x2den Wert 2 erreicht hat. Dies wird durch die Invariante x2≤2in s0
vorgegeben. Sobald die Clockvariable x2den Wert 1 erreicht oder überschreitet, kann
der Automat über die Transition azu der Location s1wechseln. Dieser Wechsel muss
spätestens vollzogen werden, wenn die Clock x2den Wert 2erreicht. Diese Eigenschaft
ergibt sich durch die Kombination des entsprechenden Guards x2≥1an der Transition
a, zusammen mit der Invariante innerhalb der Location s0. Beim Übergang von s0nach
s1wird die Clock-Variable x2durch den Reset x2:= 0 zurück gesetzt. Ähnlich verfügt
die Location s1über die Invarianten x2≤3und x1≤2, sowie die Transition büber den
Guard x1≥2und den Clock-Reset x1:= 0.
<< Component >>
Shuttle
<< Component >>
c: Coordinator
<< Component >>
vc1: VelocityControl
S0S1
a
b
x2≤2x2≤3
x1≤2
x2≥1x2:=0
x1:=0 x1≥2
Abbildung 2.10: Ein Timed Automaton, der über zwei Location, drei Invarianten und
zwei Kanten mit jeweils einem Guard und einem Clockreset verfügt.
Formal ist ein Timed Automaton nach [CGP00] wie folgt definiert:
Definition 3
Ein Timed Automaton Aist ein 6-Tupel A:= (Σ,S,S0, X, I, T), wobei Σein endli-
ches Eingabealphabet, Seine endliche Menge an Locations, S0⊆ S eine endliche Men-
ge von Start-Locations, X:= (x1, .., xn)eine endliche Menge an Clock-Variablen mit
xi∈R+,Ieine Zuordnungsfunktion I→ C(X), welche den einzelnen Locations eine
Menge an Ungleichungen zuordnet, die so genannten Invarianten, und Tist die Menge
der Transitionen. C(X)ist eine Menge von Bedingungen über die Clock-Variablen aus
X. Dabei besteht C(X)aus einer Menge an Ungleichungen der Form xi≺c∨c≺xi,
wobei ≺entweder <oder ≤ist und c∈N+. Für T, die Menge der Transitionen gilt
T⊆ S × Σ× C(X)×2X× S. Eine Transition von Location snach s0läßt sich durch
ein 5-Tuple (s, a, ϕ, λ, s0)beschreiben. Dabei ist a∈Σdie Beschriftung der zugehörigen
Kante, ϕeine Bedingung, die erfüllt sein muss damit die Transition schalten kann und
λ⊆Xeine Anzahl an Clockvariablen, die beim Schalten auf 0 zurück gesetzt werden.
25
Kapitel 2 Grundlagen
2.3.3 Hybride Automaten
Mit einem hybriden Automaten kann das Verhalten von hybriden Systemen modelliert
werden. Hybride Systeme sind dadurch gekennzeichnet, dass sie sowohl aus einem dis-
kreten wie auch einem kontinuierlichen Teil bestehen. Der hybride Automat stellt eine
Erweiterung zum endlichen Automaten und zum Timed Automaton dar, da er zusätzlich
zu einem diskreten Teil auch einen kontinuierlichen Teil besitzt.
Jeder hybride Automat besteht aus Locations und Transitionen, die einen Übergang zwi-
schen zwei Locations ermöglichen. Wie auch beim endlichen Automaten existiert im hy-
briden Automaten eine ausgezeichnete Teilmenge der Locations, welche die Anfangslo-
cations bilden. Das Hauptmerkmal des hybriden Automaten ist, dass er es erlaubt, in je-
der Location eine Differentialgleichung, die einen kontinuierlichen Regler repräsentiert,
einzubetten. Der Übergang zwischen zwei Locations erfolgt durch diskrete Übergänge.
Durch diese Einbettung und die Übergänge kann mit Hilfe eines hybriden Automaten
das Verhalten von hybriden Systemen modelliert werden. Des Weiteren wird durch den
Wechsel von einer Location in eine andere ein Austausch von kontinuierlichen Reglern
erreicht.
Neben der Einbettung von kontinuierlichen Reglern ermöglicht der hybride Automat wie
auch der Timed Automaton die Spezifikation von Zeitangaben. Innerhalb einer Location
können Zeitinvarianten in Bezug auf eine Uhr angegeben werden. Eine Zeitinvariante
drückt aus, bis wann eine Location spätestens verlassen sein muss. Ein Locationübergang
kann nur stattfinden, wenn der spezifizierte Timeguard wahr ist und das entsprechende
Event anliegt. Während des Schaltvorgangs einer Transition ist es möglich, Uhren auf
den Wert Null zu setzen. Nach [BGH05a] ist ein hybrider Automat Mwie folgt definiert:
Definition 4
Ein hybrider Automat ist durch ein 6-Tupel (L, D, I, O, T, S0)definiert. Dabei ist Leine
endliche Menge von Locations, Deine Funktion über L, die jeder Location l∈Lein
kontinuierliches Modell D(l) = (Vx, V u, V y, F(l), G(l), C(l), X0(l)) wie in Definition 1
beschrieben, zuweist, Ieine endliche Menge von Eingabesignalen, Oeine endliche Menge
von Ausgabesignalen, Teine endliche Menge von Transitionen und S0⊆ {(l, x)|l∈
L∧x∈X0(l)}die Menge der Anfangslocations.
Für jede Transition (l, g, g0, a, l0)∈Tist l∈Ldie Startlocation, g∈COND(Vx∪Vu)
der kontinuierliche Guard, der eine Bedingung über die Zustands- oder die Eingabeva-
riablen angibt, g0∈℘(I∪O)der I/O-Guard, a∈[[Vx→R]→[Vx→R]] die
kontinuierliche Aktualisierung und l0∈LZiellocation.
Abbildung 2.11 aus [Bur06] zeigt einen hybriden Automaten, der das Fahrverhalten eines
Shuttles modelliert. Ein Shuttle kann entweder alleine oder im Konvoi fahren. Abhängig
von der Situation ist ein bestimmter Regler aktiv. Nutzt das Shuttle den Geschwindig-
26
2.3 Modell-basierte Softwareentwicklung
Velocity Position
PositionToVelocity
VelocityToPosition
velocity
velocityFailure
position positionFailure
y(t)=k*(v (t)-v (t))
req cur
t=0
1
dtd
22
low 2 up
##
dtd
11
low 1 up
##
y(t) = (t) * v + (1 - (t)) * paa
out out
td
1up
#
1
y(t) = (t) * p + (1 - (t)) * vaa
out out
td
2up
#
2
t=0
2
T * y(t) = k * (p (t) - p (t)) +
k * (p (t) - p (t)) - y(t)
1 1 req cur
2 req cur
Abbildung 2.11: Hybrider Automat
keitsregler, bewegt es sich mit einer bestimmten Geschwindigkeit fort, die sich innerhalb
eines vorgegebenen Intervalls befindet. Wenn es mit einem anderen Shuttle in einem Kon-
voi fährt, wird die Geschwindigkeit des Shuttles anhand seiner Position geregelt. Hierbei
stellt der Positionsregler sicher, dass der Abstand zwischen den beiden Shuttles nicht zu
groß bzw. nicht zu klein wird.
Zu Anfang befindet sich das Shuttle in der Location Velocity. Diese Location beinhal-
tet eine Differentialgleichung, die den Geschwindigkeitsregler repräsentiert. Anhand der
Differentialgleichung ist zu erkennen, dass der Ausgang ydes Reglers von den beiden
Eingängen vreq und vcur und einer Konstante kabhängt.
Liegt das Event position an, wird vom Geschwindigkeitsregler zum Positionsregler ge-
wechselt. Um den Wechsel zwischen diesen beiden Reglern zu ermöglichen, existiert ein
so genannter Überblendzustand. Dieser Überblendzustand enthält eine Funktion, die den
Ausgang des Geschwindigkeitsreglers auf den Ausgang des Positionsreglers überblen-
det. Diese Funktion wiederum beinhaltet die Überblendfunktion α(t)aus [Voe03] mit:
α(t) = −2( t−t0
tdauer )3+ 3( t−t0
tdauer )2
Wird von der Location Velocity in die Location VelocityToPosition gewechselt, wird der
Wert der Uhr t1auf Null gesetzt. In der Location VelocityToPosition befindet sich eine
Zeitinvariante, die aussagt, dass die Location verlassen sein muss, wenn t1> d1
up gilt.
Liegt das Event positionFailure an, ist während des Überblendvorgangs ein Fehler auf-
getreten und der hybride Automat wechselt wieder in die Location Velocity. Liegt kein
Event an und ist der Timeguard d1
low ≤t1≤d1
up wahr, verlässt der hybride Automat die
Location VelocityToPosition und wechselt in die Location Position. Diese Location bein-
haltet eine Differentialgleichung, die den Positionsregler repräsentiert. Der Ausgang yder
Differentialgleichung ist von den beiden Eingängen preq und pcur und den Konstanten k1
und k2abhängig.
27
Kapitel 2 Grundlagen
Liegt das Event velocity an, muss vom Positionsregler auf den Geschwindigkeitsregler
gewechselt werden. Hierfür existiert der Überblendzustand PositionToVelocity. Wenn die
Location Position verlassen wird, wird der Wert der Uhr t2auf Null gesetzt. In der Lo-
cation PositionToVelocity ist eine Funktion eingebettet. Diese wiederum beinhaltet die
Überblendfunktion α(t). Die Zeitinvariante t2≤d2
up sagt aus, bis wann die Location
spätestens verlassen sein muss. Die Location kann verlassen werden, wenn das Event
velocityFailure anliegt oder der Timeguard d2
low ≤t2≤d2
up wahr ist.
Wie dieses Beispiel zeigt, vereinen hybride Automaten kontinuierliche Regler und dis-
krete Zustände. Durch diese Kombination ermöglichen sie unter anderem die Simulation
von physikalischen Gesetzen, die häufig für hybride Systeme benötigt werden. Zudem ist
eine automatische, formale Überprüfung von Invarianten möglich.
Allerdings werden alle Komponenten durch einen einzigen hybriden Automaten model-
liert. Dies führt schnell zu komplexen Modellen, die schwer zu verifizieren sind. Des
Weiteren ermöglicht das Modell des hybriden Automaten keine Rekonfiguration, wie sie
in [FGK+04][Bur06] definiert ist. Durch einen Wechsel der Locations werden zwar die
Regler ausgetauscht, aber die Struktur und der interne Zustand der Regler können von
einem hybriden Automaten nicht beeinflusst werden. Wie auch beim Timed Automaton
findet beim hybriden Automaten ein Schaltvorgang in Null Zeit statt. Dies entspricht je-
doch nicht der Realität, da ein Locationwechsel oft eine gewisse Zeit benötigt.
2.3.4 Graphen
Die in den vorherigen Abschnitten vorgestellten Modelle der Timed Automata und der
Hybriden Automaten verfügen über eine zeitliche Komponente, mit welcher es möglich
ist, kontinuierliches (Echtzeit-)Verhalten zu modellieren. Das Verhalten ist dabei auf eine
vorgegebene Zustandsstruktur festgelegt. In komplexen, vernetzten mechatronischen Sys-
temen stehen nur begrenzte Rechen- und Speicherkapazitäten zur Verfügung. Zusätzlich
unterliegt das System zur Laufzeit einer Evolution abhängig vom gegebenem Kontext.
Anforderungen an komplexe, mechatronische Systeme sehen deshalb Dynamik vor. So
müssen z.B. zur Laufzeit Softwarekomponenten instanziiert und deinstanziiert werden.
An dieser Stelle wird das Modell der Graphtransformationssysteme vorgestellt, welches
über keine vergleichbare zeitliche Komponente verfügt. Allerdings ist es im Gegensatz
zu den vorgestellten Automatenmodellen möglich, dynamische Bestandteile abzubilden
und damit eine Zustandsstruktur dynamisch zu erzeugen. Mit Hilfe von Graphtransfor-
mationssystemen werden strukturelle Veränderungen auf Graphen herbeigeführt.
Definition 5
Ein gerichteter Graph ist ein Tupel G:= (V, E, Es, Et), bestehend aus einer Menge von
Knoten Vsowie einer Menge von Kanten E. Eine Kante e∈Everbindet einzelne Knoten
28
2.3 Modell-basierte Softwareentwicklung
vs, vt∈Vmiteinander. Die Funktion Esordnet jeder Kante e∈Eeinen Startknoten vs
zu. Entsprechend ordnet die Funktion Etjeder Kante eeinen Zielknoten vtzu.
Zusätzlich zu den bis hier beschriebenen Eigenschaften gibt es die Möglichkeit, für die
einzelnen Knoten und Kanten eines Graphen eindeutige IDs zu vergeben, um eine ein-
deutige Zuordnung aller Elemente vornehmen zu können.
Definition 6
Ein gerichteter Graph mit Knoten und Kanten IDs besteht aus G:= (V, E, Es, Et, Vi, Ei),
wobei V, E, Es, Etwie beim gerichteten Graphen in Definition 5 definiert sind. Zusätzlich
existiert eine injektive Funktion Vi, welche jedem Knoten aus Vein eindeutiges nizuord-
net, sowie Eieine injektive Funktion, die jeder Kante aus Eeine eindeutiges eizuordnet.
Dabei sind ni, ei∈N+.
Eine Eigenschaft, welche für den Umgang mit den hier verwendeten Graphen notwendig
ist, ist die Teilgraphbeziehung.
Definition 7
G= (V, E, Es, Et)ist ein Teilgraph von G0:= (V0, E0, E0
s, E0
t) (G≤G0)wenn gilt,
V⊆V0,E⊆E0, sowie das die Zuordnungsfunktionen Esund E0
sfür die Kanten V∩V0
identisch sind. Ebenfalls muss gelten Etund E0
tsind identisch für die Menge V∩V0.
In Abbildung 2.12 sind zwei Graphen abgebildet, wobei der rechte Graph einen Teilgraph
des linken Graphen darstellt. Die Knoten n1, n2sowie die Kante e2des rechten Graphen
sind ebenfalls im linken vorhanden.
n1e2
n3
e3e1
n2
e2
n1n2
Abbildung 2.12: Die Abbildung zeigt zwei Graphen, wobei der rechte im linken Graphen
enthalten ist.
Um über Graphtransformationssysteme zu reden, ist es notwendig, Relationen zwischen
Graphen zu definieren. Eine Relation wäre z.B. die gerade erwähnte Teilgraph-Relation.
Um Abbildungen zwischen einzelnen Graphen vornehmen zu können, muss hierfür ein
Graphmorphismus für Graphtransformationssysteme definiert werden:
29
Kapitel 2 Grundlagen
Definition 8
Für einen Graphmorphismus m:= (mv, me)mit mv∈V→V0und me∈E→E0,
welcher einen Graphen G:= (V, E, Es, Et)auf G0:= (V0, E0, E0
s, E0
t)abbildet gilt:
• ∀v:v∈V→mv(v)∈V0
• ∀e:e∈E→me(e)∈E0
• ∀e:e∈E→mv(Es(e)) = E0
s(me(e)) ∧mv(Et(e)) = E0
t(me(e))
Die einzelnen, innerhalb der Graphtransformationssysteme vorhandenen Graphen haben
eine statische Struktur. Damit ein dynamisches Strukturverhalten ermöglicht wird, fin-
den Übergänge zwischen einzelnen Graphen statt, wobei die einzelnen Graphen Zustände
des Graphtransformationssystems repräsentieren. Um diese Übergänge zu ermöglichen,
werden Regeln verwendet, die durch ihre Anwendung Strukturen innerhalb von Graphen
suchen und Veränderungen herbeiführen. Diese Regeln werden nachfolgend Graphtrans-
formationsregeln genannt.
Definition 9
Eine Graphtransformationsregel P:= (Pl, Pr, h)besteht aus den Graphen Pl, Prund
dem partiellen Graphhomomorphismus h∈pl→pr. Dabei gilt: plist ein Teilgraph von
Pl, so wie prein Teilgraph von Prist. Die Menge d(P) := {VPl\VPr} ∪ {EPl\EPr}
beschreibt die Elemente, welche durch Pgelöscht werden und n(P) := {VPr\VPl} ∪
{EPr\EPl}die Elemente, welche durch die Anwendung von Phinzugefügt werden. Dabei
sind EPl, VPldie Knoten und Kanten aus Plund EPr, VPrdie Knoten und Kanten aus Pr.
Ein Graph Gkann mit Hilfe einer Graphtransformationsregel Pin einen Nachfolgegra-
phen G0überführt werden. Den Graphen G, auf welchem die Graphtransformationsregel
angewendet wird, bezeichnet man auch als Wirts- oder Muttergraph. Entsprechend wird
der resultierende Graph G0als Tochtergraph bezeichnet.
Damit die Anwendung einer Graphproduktion P(Pl, Pr, h)auf einen Wirtsgraphen G
möglich ist, aus der ein Tochtergraph G0resultiert, muss ein Teilgraph gaus G, sowie
ein Graphmorphismus mexistieren, welcher Plauf gabbildet. Der resultierende Tochter-
graph G0ergibt sich aus den Kanten EG0und Knoten VG0:
VG0={VG\mv(v) : v∈d(P)∩Vl}∪{v:v∈n(P)∩Vr}
EG0={EG\me(e) : e∈d(P)∩El}∪{e:e∈n(P)∩Er}
Vlund Elsind die Knoten und Kanten der linken Seite Plund Vr, Erdie Knoten und Kan-
ten aus Pr, der rechten Seite von P. Ein Beispiel für eine derartige Regelanwendung zeigt
die Abbildung 2.13, bei der aus dem linken Graphen der Knoten n3, sowie die Kanten
e1, e3, e4entfernt werden. Bei der Anwendung wird die Kante e5hinzugefügt.
30
2.3 Modell-basierte Softwareentwicklung
n1e2
n3
e3e1
n2
n4
e4
e2
e5
n4
n2
n1
Abbildung 2.13: Schematische Darstellung einer Regelanwendung.
Dabei ist es möglich, die einzelnen Graphtransformationsregeln mit Prioritäten zu verse-
hen. Eine solche priorisierte Graphtransformationsregel erlaubt es dann in dem Fall, dass
auf einen Wirtsgraphen Gzwei unterschiedliche Regeln P1und P2angewendet werden
können. Die Reihenfolge der Anwendung wird durch die Prioritäten geregelt. Hierdurch
wird Nichtdeterminismus vermieden.
Definition 10
Eine Graphtransformationsregel P:= (Pl, Pr, h, r)besteht zusätzlich zu der in Definiti-
on 9 definierten Graphtransformationsregel P:= (Pl, Pr, h)aus einer Priorität r, wobei
r∈N+. Ein Regel pimit einem zugehörigen ri, wird gegenüber einer Regel Pjmit
zugehörigem rjbevorzugt, falls ri> rj.
Am Beispiel bedeutet dies auch, dass falls zwei Regeln Pi, Pjauf einen Graphen Gange-
wendet werden können, eine Regel mit höherer Priorität die andere verdrängt. Mit Hilfe
der bis hier vorgestellten Definitionen lässt sich ein Graphtransformationssystem wie folgt
formulieren:
Definition 11
Ein Graphtransformationssystem S:= (G,G0,P)besteht aus einer potentiell unendli-
chen Menge an Zuständen in Form der Graphen G, einer endlichen Anzahl an Startzu-
ständen in Form der Graphen G0sowie P:= (P1, ..., Pn)einer endlichen Anzahl an
Graphtransformationsregeln Pi, mit i∈N.
Bei der Anwendung von Graphtransformationsregeln kommt es vor, dass einzelne Kanten
und Knoten aus dem Wirtsgraphen entfernt werden. Dabei kann es passieren, dass Kan-
ten entstehen, bei welchen kein Zielknoten, bzw. kein Startknoten vorhanden ist (siehe
31
Kapitel 2 Grundlagen
Abbildung 2.14). Eine solche Kante wird als Dangling-Edge bezeichnet. Zur Behand-
lung dieses Problems gibt es zwei unterschiedliche Vorgehensprinzipien, den so genann-
ten single-pushout approach (SPO) und den double-pushout approach (DPO) [Roz97]. In
der vorliegenden Arbeit wird der SPO verwendet. Wird bei einem Wirtsgraphen durch die
Anwendung des linken Teils einer Graphtransformationsregel ein Knoten e∈Eentfernt,
so werden beim SPO alle mit dem Knoten inzidenten Kanten v∈Vgelöscht. Somit ist
die Entstehung von Dangling-Edges zwar ausgeschlossen, allerdings kann es passieren,
dass Elemente aus einem Graphen entfernt werden, obwohl dies nicht beabsichtigt ist.
n1e2
n3
e3e1
n2
e1
n3n2
Wirtsgraph
Anwendungsregel
n1e2
e3
Resultierender
Graph
Abbildung 2.14: Die Abbildung zeigt oben einen Wirtsgraphen, auf den eine Regel (blau
gestrichelt) angewendet wird und durch das Entfernen von Elementen
ein resultierender Graph mit zwei Dangling-Edges entsteht (grau mar-
kierte Kanten im unteren Graph).
Um zu vermeiden, dass zu viele Knoten und Kanten unbeabsichtigt durch eine Graph-
transformationsregel gelöscht werden, besteht die Möglichkeit, eine sogenannte Negative-
Application-Condition (NAC) zu verwenden (siehe [HHT96]). Mit Hilfe einer NAC kann
formuliert werden, welche Bedingung im Wirtsgraphen nicht vorhanden sein darf, da-
mit eine Graphtransformation angewendet werden kann. Eine Graphtransformationsregel
kann entsprechend mit einer zusätzlichen NAC versehen werden, wobei es sich bei die-
ser ebenfalls um einen Graphen handelt. Kann die NAC im Wirtsgraphen an der gleichen
Stelle aufgefunden werden wie die linke Seite Pl, so wird die zugehörige Graphtransfor-
mation an dieser Stelle nicht angewendet. Eine Graphtransformationsregel mit NAC wird
wie folgt definiert:
32
2.3 Modell-basierte Softwareentwicklung
Definition 12
Eine Graphtransformationsregel P:= (Pl, Pr, PNAC, h)mit negativer Anwendungsbe-
dingung besteht aus einem linken Anwendungsteil Pl, welcher die Vorbedingung darstellt,
sowie einem rechten Anwendungsteil Pr, welcher die Nachbedingung abbildet. Zusätzlich
verfügt Püber PNAC , eine negative Anwendungsbedingung, welche nicht im Wirtsgra-
phen an der gleichen Stelle auffindbar sein darf, damit die Graphtransformationsregel P
an dieser Stelle angewendet werden kann. PNAC kann entweder Plvollständig enthal-
ten und um zusätzliche Knoten und Kanten erweitern oder PNAC entspricht dem leeren
Graphen.
Die Anwendung einer Graphtransformationsregel mit Negative-Application-Condition ist
wie folgt definiert:
Definition 13
Eine Graphtransformationsregel P:= (Pl, Pr, PNAC, h)mit Negative-Application-Con-
dition kann auf einen Wirtsgraphen G:= (V, E, Es, Et)angewendet werden, wenn die
Bedingungen erfüllt sind, dass:
∃g:g≤G
∃h:h:Pl→g
6 ∃hNAC :hNAC :PNAC →g0∧g≤g0
2.3.5 Verifikation
Bei der Analyse und Verifikation von Modellen, so auch bei den Automaten und Graph-
transformationssystemen, können unterschiedliche Eigenschaften untersucht werden. Da-
bei wird zwischen der Berechnung der erreichbaren Zustände und dem erweiterten Ver-
fahren des Model Checking unterschieden. Nachfolgend wird hier kurz auf die unter-
schiedlichen Verfahren eingegangen.
2.3.5.1 Erreichbarkeitsanalyse
Um die erreichbaren Zustände, bzw. den Zustandsraum eines Modells zu erzeugen, ist
es notwendig, basierend auf den initial gegebenen Zuständen eine Erreichbarkeitsanalyse
durchzuführen. So auch bei den Modellen des Timed Automaton und der Graphtrans-
formationssysteme. Hierbei ist von Interesse, welche Zustände innerhalb des Modells er-
reichbar sind, oder sicher zu stellen, dass bestimmte Zustände ausgeschlossen werden
können. Nachfolgend wird für die beiden Modelle des Timed Automaton und der Graph-
transformationssysteme jeweils ein Verfahren vorgestellt, mit dem eine solche Erreich-
barkeitsanalyse durchgeführt werden kann.
33
Kapitel 2 Grundlagen
2.3.5.2 Model Checking
Ein Verifikationsverfahren ist das so genannte Model Checking [CGP00], bei dem auch
komplexere Aussagen in Form einer speziellen Logik gegen ein Modell geprüft werden.
Bei dem zu überprüfenden Modell kann es sich beispielsweise um einen Automaten oder
ähnliches handeln. Es existieren dabei verschiedene Logiken um Aussagen zu formu-
lieren, sowie unterschiedliche Verfahren um diese gegen das entsprechende Modell zu
prüfen. So gibt es Logiken und Verfahren für diskrete sowie kontinuierliche Modelle
und Eigenschaften. Model Checking kann als folgendes Entscheidungsproblem formu-
liert werden:
Sei Mein zu testendes Modell und Ψeine Spezifikation. Erfüllt das Modell
die Spezifikation, gilt also M|= Ψ?
Die Eigenschaften, die sich mit Hilfe einer solchen Logik formulieren lassen, können
wesentlich komplexer sein als die einfache Erreichbarkeit von Zuständen. So kann über-
prüft werden, ob die einzelnen Zustände in einer bestimmten Reihenfolge innerhalb des
Modells erreicht werden können. Im Vergleich zu der Erreichbarkeitsanalyse, kann dort
nicht nur überprüft werden, welche Zustände erreicht werden. Beim Model Checking gibt
es die Möglichkeit, Aussagen zu formulieren und zu überprüfen, in welcher Reihenfol-
ge diese Zustände erreicht werden müssen. Dabei ist Voraussetzung für eine derartige
Überprüfung, dass diese entsprechenden Zustände bereits ermittelt wurden.
Jedoch hat auch das Verfahren des Model Checking seine Grenzen. Abbildung 2.15 zeigt
noch einmal die generelle Vorgehensweise beim Model Checking. Werden jedoch die
Eingabemodelle, wie in Abbildung 2.16 beschrieben, immer komplexer, skaliert das Ver-
fahren des Model Checkings aufgrund des Problems der Zustandsraumexplosion nicht
mehr. In 2.15 ist verdeutlicht, dass Model Checking für hybride Modelle nicht in akzep-
tabler Zeit durchgeführt werden kann.
Um ein Gefühl für die Komplexität solcher Zustandsräume, die bei der Verifikation erstellt
werden, zu bekommen, wird im folgenden die Konstruktion für das Eingabemodell der
Timed Automata (siehe Abschnitt 2.3.5.3) und anschließend für Graphtransformations-
system (siehe Abschnitt 2.3.5.4) gezeigt.
2.3.5.3 Zustandsraum des Timed Automaton
Bei einem Timed Automaton A:= (Σ,S,S0, X, I, T)hängen die Zustände nicht nur
von der jeweiligen Location ab, der aktuelle Zustand ergibt sich zusätzlich aus der Bele-
gung der einzelnen Clocks. Einer Location s∈ S wird durch eine Zuordnungsfunktion
ein C(X)zugeordnet. Dabei ist C(X)eine Teilmenge der Bedingungen über die Clock-
variablen aus X. Dies bedeutet, dass sich der Zustand eines Timed Automaton aus der
34
2.3 Modell-basierte Softwareentwicklung
Lehrstuhl für Regelungs-
technik und Mechatronik Fachgebiet
Softwaretechnik
Zu keinem Zeitpunkt
Anforderung
ist der Abstand zum
vorausfahrenden
Shuttle kleiner als 4m
Hybrider Model-Checke
r
331.03.2006
H. Giese, S. Henkler, M. Hirsch, M. Tichy, H. Vöcking
Abbildung 2.15: Problem: Hybrides Model Checking
Effizienz beim Model
Checking
Synchrone Sprachen
Endliche Automaten
Timed Automata
Hybride Automaten
Komplexität des Modells
Synchrone Sprachen
Endliche Automaten
Timed Automata
Hybride Automaten
Komplexität des Modells
Komplexität des Modells
Effizienz beim Model
Checking
Effizienz beim Model
Checking
Abbildung 2.16: Mächtigkeit des Eingabemodells vs. Effizienz beim Model Checking
aktuellen Location, sowie den dort aktuell geltenden zeitlichen Bedingungen über die
einzelnen Clocks zusammen setzt.
Im Beispiel des Automaten aus Abbildung 2.10 setzt sich der initiale Zustand aus der Lo-
cation s0, sowie der dort vorhandenen Invariante zusammen. Die Invariante, welche die
Clock-Variable x2beinhaltet, definiert einen zeitlichen Erreichbarkeitsraum, in dem gilt,
dass der Wert von x2≤2ist. Über die Clock x1ist im initialen Zustand in der Location s0
keine einschränkende Bedingung vorhanden, allerdings haben die im Automaten existie-
renden Clocks die Eigenschaft, dass diese in der Zeit synchron voranschreiten. Hierdurch
ergibt sich eine Abhängigkeit zwischen x1und x2in der Art und Weise, dass beide den
35
Kapitel 2 Grundlagen
gleichen Wert besitzen müssen. Diese Abhängigkeit zwischen x1und x2gilt solange, bis
durch einen Reset eine der beiden Clocks auf den Wert 0 zurück gesetzt wird. Auch dann
laufen beide weiterhin synchron, allerdings können die einzelnen Werte sich unterschei-
den. Solange in der initialen Location s0verweilt wird, sind die entsprechenden Werte
identisch und somit x1und x2jeweils kleiner oder gleich dem Wert 2.
Die Wertemengen, welche durch die möglichen Clock-Belegungen aufgebaut werden,
sind in der Regel unendlich groß. Bei der Analyse des Erreichbarkeitsraumes ist es nicht
möglich, jeden Zustand einzeln abzubilden, da nicht jeder Zustand und die daraus resul-
tierenden Folgezustände in endlicher Zeit betrachtet werden können. Somit ist es notwen-
dig, eine endlich große Repräsentation dieser Erreichbarkeitsräume vorzunehmen. Um ei-
ne endliche Repräsentation dieser Bereiche zu ermöglichen, existieren verschiedene Da-
tenstrukturen. Eine davon ist das Modell der sogenannten Clock-Regions, welches bei
[CGP00] sowie [BBF+01] genauer beschrieben wird.
Die entsprechende Clock-Region für den initialen Zustand des Timed Automaton aus dem
Beispiel im Abschnitt 2.3.2, lässt sich grafisch wie in Abbildung 2.17 darstellen. Dabei
stellen die grau markierten Bereiche die Wertemenge dar, welche die Clock-Variablen x1
und x2annehmen können. In dieser Menge sind alle Werte enthalten, die auf der Win-
kelhalbierenden des ersten Quadranten des Koordinatensystems liegen und kleiner oder
gleich dem Wert 2 sind.
x1
x2
0
1
2
3
1
2
3
Abbildung 2.17: Der zeitliche Erreichbarkeitsraum des initialen Zustandes des Automa-
ten aus Abbildung 2.10. Die grau markierten Bereiche entsprechen der
Menge der Werte, welche die Clocks x1und x2annehmen können.
Zusammen mit der Location s0bildet diese Clock-Region den initialen Zustand des
Beispiel-Automaten aus Abbildung 2.10. In der vorliegenden Arbeit wird allerdings mit
36
2.3 Modell-basierte Softwareentwicklung
einer anderen Form zur Darstellung der zeitlichen Erreichbarkeitsräume gearbeitet. Dies
sind die sogenannten Clockzones, die in dieser Arbeit Verwendung finden.
Clockzone Hier wird kurz auf die Datenstruktur und Operationen der Clockzones ein-
gegangen. Eine genauere Definition für die hier vorgestellte Datenstruktur ist bei Clarke
und anderen [CGP00] zu finden.
Eine Clockzone definiert eine Reihe an Bedingungen über einzelne Clock-Variablen, wo-
bei hierzu Ungleichungen ähnlich wie beim Modell des Timed Automaton (siehe Defini-
tion 3) verwendet werden:
i, j ∈N+, d ∈Z, xi∈R+,≺∈ {<, ≤} :xj≺d, d ≺xj, xi−xj≺d.
Zusätzlich verfügt jede Clockzone über eine Referenz-Clock x0, welche zu jedem Zeit-
punkt den Wert 0 besitzt. Die gesamte Clockzone ergibt sich durch die Konjunktion der
einzelnen Ungleichungen über die Clock-Variablen. Am Beispiel aus der Abbildung 2.10
wird die initiale Clockzone durch die folgenden Ungleichungen aufgebaut:
x2≤2, x0−x2≤0∧x1−x2≤0∧x2−x1≤0∧x0−x1≤0
Dabei resultiert die erste Ungleichung aus der Invariante der initialen Location s0. Die
restlichen Bedingungen entstehen aus der Eigenschaft, dass alle vorhandenen Clocks xi∈
Xdes Beispiel-Automaten synchron in der Zeit voranschreiten, sowie dass diese immer
≥0seien müssen.
Definition 14
Eine Clockzone Zhat eine Menge Xan Clock-Variablen xi. Jedes xikann Werte aus
R+∪0annehmen, wobei i∈N+und i > 0. Zusätzlich existiert eine Referenz-Clock
x0, die immer den Wert 0besitzt, sowie eine Anzahl von Bedingungen c∈Cin Form
von Ungleichungen der Art xj≺d, d ≺xj, xi−xj≺d, mit i, j ∈N+,d∈Zund
≺∈ {<, ≤}. Die Clockzone ergibt sich aus der Konjunktion über die Bedingungen aus C.
Eine Clockzone mit kverschiedenen Clocks wird als k-dimensional bezeichnet, da jede
Clock im euklidischen Raum eine eigene Dimension aufspannt (ohne die Referenz-Clock
x0). Der hierbei aufgespannte Raum erfüllt zusätzlich die Eigenschaft, dass dieser konvex
ist. Die Abbildung 2.18 zeigt in grafischer Form die Clockzone φmit den zwei Clocks
x1, x2und den folgenden Bedingungen:
x1≤4∧x2≤5∧2≤x1∧1≤x2∧x1≤x2
37
Kapitel 2 Grundlagen
x1
x2
2
5
4
1
Abbildung 2.18: Die Clockzone φ
Es existieren eine Anzahl an Operatoren, welche auf eine, bzw. mehrere Clockzones an-
gewendet werden können. Dabei werden für die zeitliche Erreichbarkeitsanalyse, wie die-
se etwa beim Timed Automaton vorgenommen wird, drei spezielle Operatoren benötigt.
Hierzu zählt die Vereinigung von zwei Clockzones, das Verstreichen lassen von Zeit und
das Zurücksetzen von einzelnen Clocks:
•Vereinigung von zwei Clockzones: φ1∧φ2
•Verstreichen lassen von Zeit (Up-Operation): φ⇑
•Zurücksetzen von Uhren (Clock-Reset): φ[γ]mit γ⊆X, wobei Xdie Menge der
Clock-Variablen in φist.
Bei der Vereinigung von zwei Clockzones ist es auch möglich, dass φ1oder φ2nur aus
einer einzigen Bedingung besteht, wie diese etwa durch einen Guard oder eine Invariante
gegeben ist.
Die entsprechenden drei Operatoren werden benötigt, um die Erreichbarkeitsanalyse beim
Timed Automaton durchzuführen. So etwa beim Zustandswechsel innerhalb des Auto-
maten. Dabei setzt sich ein Zustand aus der jeweiligen Location sowie der dort momen-
tan vorhandenen Belegung der einzelnen Clockvariablen zusammen. Diese Belegung der
Clockvariablen kann durch eine entsprechende Clockzone dargestellt werden. So exis-
tiert etwa für die Location seine Clockzone φund der Zustand des Automaten ergibt
sich aus dem Tupel hs, φi. Um den Nachfolgezustand succ(s, φ, t)beim Wechsel von der
Location süber eine Transition tzu einer Location s0zu berechnen, sind die vorgestell-
ten Operatoren auf die Clockzone φanzuwenden. Dabei wird hier zur Berechnung der
Folge-Clockzone φ0die Funktion succφeingeführt, welcher φselbst, die Invarianten I
der Location s, sowie die Guards ϕder Transition tübergeben werden.
38
2.3 Modell-basierte Softwareentwicklung
Algorithmus 2.1 procedure φsucc =succφ(φ, I, ϕ)
procedure φsucc =succφ(φ, I, ϕ)
1: Bilden der Schnittmenge: φ=φ∧I
2: Verstreichen lassen von Zeit: φ⇑
3: Wiederum Bilden der Schnittmenge: φ=φ∧I
4: Vereinigen mit ϕ:φ=φ∧ϕ
Falls die resultierende Clockzone φsucc nicht leer1ist, kann über die Transition tzur Lo-
cation s0gewechselt werden. Eine Clockzone φist leer, wenn für alle c∈φgilt: Es gibt
keine mögliche Belegung für die Clocks xiaus c, so dass alle Ungleichungen cerfüllt
sind.
Anschließend müssen noch die Clockresets λder Transition tausgeführt werden, um aus
φsucc,φ0zu erhalten. Dies wird durch den Algorithmus 2.2 succ0
φbeschrieben.
Algorithmus 2.2 procedure φ0=succ0
φ(φsucc, λ)
procedure φ0=succ0
φ(φsucc, λ)
1: Zurücksetzen der Clocks λ:φ0=φsucc[λ:= 0]
Bevor φ0zu s0als Folge-Clockzone hinzugefügt wird, muss die Schnittmenge φ0mit den
Invarianten φ0∧I(s0)von s0gebildet werden. Diese Schnittmenge ergibt zusammen mit s0
den Folgezustand, welcher über die Transition terreicht wird. Dabei kann es vorkommen,
dass durch die Berücksichtigung der Invarianten von s0, beim Bilden der Schnittmenge
φ0∧I(s0)eine Clockzone entsteht, die leer ist. Der hierdurch abgebildete Zustand wird
auch als Timedeadlock bezeichnet.
Ein Timedeadlock bezeichnet einen erreichten Zustand, bei dem aufgrund der zeitlichen
Bedingungen aus diesem kein Folgezustand erreicht werden kann. Für eine Clockzone φ
mit einem Timedeadlock gilt, dass φeinerseits erreicht wurde und es andererseits mindes-
tens eine Ungleichung der Form x1−x2∼dgibt, welche zusammen mit den restlichen
Ungleichungen aus φnicht erfüllt werden kann.
Die Funktionen succφ, die Überprüfung ob die resultierende Clockzone leer ist, sowie die
Funktion succ0
φwerden zu der Funktion succ(φ, I(s), ϕ, λ, I(s0)) zusammengefasst. Die
Berechnung ist in Algorithmus 2.3 beschrieben.
Mit Hilfe von succ(φ, I(s), ϕ, λ, I(s0)) wird nun die Funktion reach(A)zur Berechnung
der erreichbaren Zustände formuliert. Die Berechnung ist in Algorithmus 2.4 beschrieben.
1Siehe [CGP00] zur Definition einer leeren Clockzone und wie dies festgestellt werden kann.
39
Kapitel 2 Grundlagen
Algorithmus 2.3 procedure φ0=succ(φ, I(s), ϕ, λ, I(s0)
procedure φ0=succ(φ, I(s), ϕ, λ, I(s0)
1: φsucc =succφ(φ, I(s), ϕ))
2: if φsucc ist nicht leer then
3: φ0=succ0
φ(φsucc, λ)
4: φ0=φ0∧I(s0)
5: end if
Algorithmus 2.4 procedure reach(A)
procedure reach(A)
1: A:= (Σ,S,S0, X, I, T)
2: Open =∅, Close =∅
3: for all s∈S0do
4: z:= hs, I(s)i
5: Open =Open ∪z
6: end for
7: while Open 6=∅do
8: for all t∈T:t:= s×C(X)×2X×s0do
9: φt=succ(s, φ, t)
10: if φt6=empty then
11: φ0=φt∧I(s0)
12: z0=hs0, φ0i
13: Open =Open ∪z0
14: end if
15: end for
16: Open =Open \z
17: Close =Close ∪z
18: end while
Das Ergebnis der Berechnung ist die Menge Close, welche sich aus einzelnen Tupeln
hs, φizusammen setzt. Diese Tupel beschreiben die Menge der erreichbaren Zustände.
Bei jedem berechneten Folgezustand hs0, φ0istammt s0immer aus der Menge Sdes
Timed Automaton A. Somit sind alle Locations und hierdurch auch die Struktur des
durch Aabgebildeten Modells bereits fest vorgegeben. Strukturdynamische Eigenschaf-
ten werden hier somit nicht abgebildet, im Gegensatz zu den Graphtransformationssys-
temen. Die Datenstruktur der Difference-Bound-Matrices erlaubt es, Clockzones effizi-
ent zu kodieren und zu manipulieren. Ein Vorteil der Datenstruktur Difference-Bound-
Matrice liegt darin, dass eine kanonische Form herleitbar ist, welche es möglich macht
mehrere Difference-Bound-Matrices effizient miteinander zu vergleichen. Für weiterge-
hende Informationen zu der Datenstruktur der Difference-Bound-Matrice siehe [CGP00].
40
2.3 Modell-basierte Softwareentwicklung
2.3.5.4 Zustandsraum des Graphtransformationssystems
Im Gegensatz zu dem Modell des Timed Automaton lassen sich mit Hilfe von Graph-
transformationssystemen dynamische Strukturen modellieren. Diese Strukturen werden
in Form von Graphen, während der Erreichbarkeitsanalyse, durch Anwendung der ein-
zelnen Graphtransformationsregeln aufgebaut. Eine zeitliche Komponente, wie sie beim
Timed Automaton vorhanden ist, gibt es hingegen nicht.
Der Ausgangspunkt ist dabei ein Graphtransformationssystem S:= (G,G0,P), mit einer
Menge an Graphen G, einer Menge an initialen Graphen G0und einer Menge an Graph-
transformationsregeln P. Damit der erreichbare Zustandsraum ermittelt werden kann,
wird hier davon ausgegangen, dass alle Mengen endlich sind2.
Um, ausgehend von einem gegebenen Wirtsgraphen G, über eine Graphtransformations-
regel Pdie Menge der daraus resultierenden Tochtergraphen G0zu berechnen, wird die
Funktion prod(G, P)eingeführt. Diese liefert die Menge der Graphmorphismen m∈M
zurück, welche Plaus der Graphtransformationsregel Pauf einem Teilgraphen gdes
Wirtsgraphen Gabbilden. Für diese Morphismen m:= (mv, me)gelten die Eigenschaf-
ten, die in Abschnitt 2.3.4 bei der Anwendung einer Graphtransformationsregel beschrie-
ben wurden.
Der Tochtergraph G0ergibt sich aus der Anwendung von Pzusammen mit dem jeweiligen
Morphismus m:
Gm,P
−−→ G0
Um die Notation abzukürzen wird die Funktion prod(G, P)verwendet, um sowohl die
Morphismen mals auch die Folgegraphen G0herzuleiten. Für weitergehende Details, z. B.
wie genau eine Graphtransformationsregel Pauf einen Wirtsgraphen nach dem Prinzip
des SPO angewendet wird, siehe [Roz97].
Mit Hilfe der Funktion prod wird ein Algorithmus formuliert, mit dem das gesamte
Graphtransformationssystem aufgebaut werden kann. Der hier angegebene Algorithmus
2.5 entspricht einer Breitensuche über ein Graphtransformationssystem S.
Um auch die Priorität einer einzelnen Graphtransformationsregel zu berücksichtigen,
muss die Zeile 5 des Algorithmus angepasst werden. Dort werden alle Graphproduktio-
nen in einzelnen Mengen Qrzusammengefasst, die über die gleiche Priorität rverfügen.
Aus diesen Mengen werden ihrer Priorität entsprechend absteigend, die einzelnen Regeln
wie in Zeile 6 auf den Wirtsgraphen Gangewendet. Die einzelnen Mengen Qrwerden
solange verarbeitet, bis mindestens eine Regel aus Qrauf Gangewendet werden kann, al-
so die Funktion prod nicht die leere Menge zurück geliefert hat. Falls dieser Fall eintrifft,
2Falls eine der Mengen G,G0oder Pnicht endlich ist, würde das hier vorgestellte Verfahren nicht termi-
nieren.
41
Kapitel 2 Grundlagen
Algorithmus 2.5 procedure Open =reachGTS(S)
procedure Open =reachGTS(S)
1: S:= (G,G0,P)
2: Open =G0, Close =∅
3: while Open 6=∅do
4: for all G∈Open do
5: for all P∈ P do
6: Open =Open ∪prod(G, P)
7: end for
8: end for
9: Close =Close ∪G
10: Open =Open \G
11: end while
12: return Close
wird die innere Schleife in Zeile 5 verlassen und mit der äußeren in Zeile 3 fortgefah-
ren. Das hieraus resultierende Graphtransformationssystem verfügt in Form der durch die
Transitionen erzeugten Tochtergraphen über die hinzugekommenen dynamischen Struk-
turbestandteile allerdings über keine zeitliche Komponente, wie dies beim Modell des
Timed Automaton der Fall ist.
Nachdem nun die Modelle zur Beschreibung der Struktur und des Verhaltens von re-
gelungstechnischen Systemen (Abschnitt 2.2) sowie von Softwaresystemen beschrieben
wurden, wird im nächsten Abschnitt nun auf die Integration der Domäne des Software
Engineering mit der Domäne der Regelungstechnik eingegangen. Der nun im Folgenden
beschriebene MECHATRONIC UML Ansatz vereint beide Domänen.
2.4 Mechatronic UML
Der MECHATRONIC UML Ansatz [GHH+08b] ermöglicht die modell-basierte Ent-
wicklung von mechatronischen Systemen (siehe Abschnitt 2.1). MECHATRONIC UML
unterstützt dabei die Spezifikation von Softwarestrukturen und Strukturänderungen
[BBG+06], die Koordination von komplexem Echtzeitverhalten [BGS05], formale
Verifikation von Sicherheitseigenschaften [BGH+05b][GTB+03][Hir04][HG03] und
die Fehleranalyse [GT06]. Neben diesen unterstützt MECHATRONIC UML auch die
Integration der Modellierung von Regelungstechnik, kontinuierlichen Verhalten durch die
Einbettung von Reglerstrukturen in die Zustände, ohne dabei die Verifikationsergebnisse
der Echtzeiteigenschaften zu verletzen. [BGH05a].
42
2.4 Mechatronic UML
2.4.1 Echtzeitverhalten
Das Echtzeit-Koordinationsverhalten beschreibt die nachrichtenbasierte Kommunikation
zwischen verschiedenen mechatronischen Komponenten unter harten Echtzeitbedingun-
gen. Zuallererst wird bei dem Ansatz das Kommunikationsverhalten verschiedener Sze-
narien durch die Verwendung von Echtzeit-Sequenzdiagrammen spezifiziert. Die Menge
von spezifizierten Szenarien, z.B. die Bildung des Konvois von Shuttles, kann automa-
tisch zu Realtime Statecharts synthetisiert werden, wobei die beteiligten Rollen auf Soft-
ware Komponenten abgebildet werden. Realtime Statecharts sind eine Erweiterung von
UML State Machines um spezielle Echtzeiteigenschaften für die periodische Ausführung,
Echtzeitverhalten, Wort Case Ausführungszeiten usw. zu modellieren. Die Semantik der
Realtime Statecharts ist über die Semantik der Timed Automata (siehe Abschnitt 2.3.2
und [HG03][Hir04][BGHS04]) definiert.
Die Realtime Statecharts der verschiedenen Software Komponenten werden aus den so
genannten Echtzeit-Koordinationsmustern abgeleitet. Realtime Statecharts spezifizieren
das Verhalten einer bestimmen Rolle in einer Koordination. Am Beispiel des Shuttlekon-
vois lassen sich zwei Rollen aufzeigen, die Rolle eines Führungsshuttles und die Rolle
eines hinterherfahrenden Shuttles. Da so ein Koordinationsverhalten in mechatronischen
Systemen immer sicherheitskritischen Charakter hat, stellt der MECHATRONIC UML An-
satz zur Analyse der Echtzeit-Koordinationsmuster formale Verifikationstechniken zur
Verfügung.
Wie schon angedeutet, leitet sich das Verhalten der Komponenten durch die Verwendung
der verfeinerten Rollen ab. MECHATRONIC UML baut auf einer Verfeinerungsbeziehung
auf, die garantiert, dass, falls eine Komponente eine Rolle verfeinert, die Verifikation der
Rolle ebenfalls für die Komponente gilt. Als letztes werden Regler in die Zustände der
Statecharts einer Komponente eingebettet. Hierdurch wird die Verbindung zu der Domäne
der Regelungstechnik geschlagen. Im Folgenden werden die bereits skizzierten Schritte
anhand der Modellierung des Konvoiszenarios detailliert beschrieben.
2.4.2 Echtzeit-Koordinationsmuster
In Abbildung 2.19 ist ein Echtzeit Sequenzdiagramm modelliert. Es zeigt die Bildung ei-
nes Shuttlekonvois an einer Weiche [GHHK06]. Hierbei wird die Nachrichteninteraktion
zwischen Komponenten modelliert. Durch die Integration von Zuständen und Zeit ist es
möglich, die Nachrichteninteraktion in eine globale zeitliche und lokale kausale Ordnung
zu bringen.
Durch den Syntheseansatz aus [GB04][GHHK06] können aus diesen Szenarien Rollen
eines Echtzeit-Koordinationsmusters generiert werden, die durch Realtime Statecharts
43
Kapitel 2 Grundlagen
Abbildung 2.19: Echtzeit Sequenzdiagramm
spezifiziert sind. Natürlich können Rollen auch direkt spezifiziert werden. Eine Rolle spe-
zifiziert das Verhalten des Führungsshuttles, die andere Rolle die des hinterherfahrenden
Shuttles (siehe Abbildung 2.20). Zusätzlich wird das Verhalten des Connectors, der das
Kommunikationsmedium darstellt, durch ein Realtime Statechart beschrieben.
Beide Rollen befinden sich initial in dem Zustand noConvoy::default, der die Bedeutung,
von zwei allein, nicht im Konvoibetrieb fahrenden Shuttles, darstellt. Die Rolle rear kann
nun nicht-deterministisch wählen, ob ein Konvoibetrieb aufgenommen werden soll oder
nicht. Für den positiven Fall, dass ein Konvoibetrieb aufgenommen werden soll, sendet die
Rolle eine Nachricht an das andere Shuttle, bzw. Rolle front. Die Rolle front entscheidet
nun ebenfalls nicht-deterministisch, den Vorschlag abzuweisen oder anzunehmen. Im ne-
gativen Fall schalten beide Realtime Statecharts zurück in den Zustand noConvoy::default.
Im positiven Fall schalten beide in den Zustand convoy::default.
Für den Fall, dass das hinterherfahrende Shuttle nicht-deterministisch entscheidet, zu
bremsen, sendet dies dieses Ereignis an das Führungsshuttle. Auch hier kann das Füh-
rungsshuttle den Vorschlag abweisen oder akzeptieren. Wenn der Vorschlag abgelehnt
wird, bleiben beide Shuttles im Konvoizustand, andernfalls wechseln beide Shuttles in
den Zustand noConvoy::default.
Der Connector zwischen beiden Rollen repräsentiert eine Funkverbindung. In diesem Bei-
spiel wird der Connector nicht explizit durch ein Realtime Statechart beschrieben, sondern
nur durch QoS Angaben spezifiziert. In [Hof07] ist ein Verfahren vorgestellt, hieraus au-
tomatisch Connectoren zu synthetisieren. In dem Beispiel wird angenommen, dass Nach-
44
2.4 Mechatronic UML
(a) Echtzeit-Koordinatiosmuster
default
wait
noConvoy
answerdefault
default
/ rearRole.breakConvoyRejected
rearRole.breakConvoyProposal
/ rearRole.convoyProposalRejected
rearRole.convoyProposal /
convoy
/ rearRole.breakConvoy
rearRole.breakConvoyProposal
/ rearRole.startConvoy
wait
noConvoy
convoy
frontRole.convoyProposalRejected /
/ frontRole.convoyProposal
wait
frontRole.breakConvoyProposalRejected /
/ frontRole.breakConvoyProposal
default
frontRole.breakConvoy / frontRole.startConvoy /
a) Rear Role
b) Front Role
{t0}
[1 ≤t0≤1000]
(b) Rollenverhalten
Abbildung 2.20: Echtzeit-Koordinationsmuster für die Konvoikoordination
richten um 1 bis 5 Zeiteinheiten verzögert werden können. Außerdem ist der Connector
nicht zuverlässig, so dass Nachrichten verloren gehen können.
Um die Sicherheitseigenschaften zu überprüfen, müssen diese zuerst spezifiziert werden.
Hierfür kann z.B. TCTL verwendet werden. In diesem Beispiel soll gelten: rear.convoy
implies front.convoy. Befindet sich das hinterherfahrende Shuttle im Konvoimodus, muss
sich auch das Führungsshuttle im Konvoimodus befinden. Andernfalls kann es in einer
Notfallsituation zu einem Unfall kommen, da das Führungsshuttle für die Situation nicht
geeignete Entscheidungen treffen könnte.
In [Gie03, BGHS04, BGH+05b] wurde gezeigt, dass die Eigenschaft erfüllt ist. Nach
der erfolgreichen Verifikation des Echtzeit-Koordinationsmusters können diese nun zu
Komponenten verfeinert werden.
45
Kapitel 2 Grundlagen
2.4.3 Komponenten
Die im letzten Abschnitt vorgestellten Echtzeit-Koordinationsmuster werden bei der Ver-
haltenserstellung der Softwarekomponenten verwendet. Die von MECHATRONIC UML
verwendeten Komponentendiagramme basieren auf denen der UML 2.0. Diskrete Kom-
ponenten werden von kontinuierlichen Komponenten unterschieden. Das Verhalten von
diskreten Komponenten wird durch Realtime Statecharts modelliert, das Verhalten von
kontinuierlichen Komponenten durch Blockdiagramme aus der Domäne der Regelungs-
technik. Dieselbe Unterscheidung wird auch bei Ports gemacht. Die Definition der Kom-
ponenten unterstützt die Verwendung von Interface Statecharts [BGO06] für die Spezifi-
zierung von verschiedenen Ports und Konfigurationen/Zuständen der Komponenten.
Diskrete Komponenten verfeinern einfach nur das Verhalten der Rollen. Der Entwickler
muss lediglich ein Synchronisationsverhalten der beteiligten Rollen modellieren, um das
Verhalten der Rollen zu koordinieren. Danach werden die Rollen als Ports zu den Kom-
ponenten hinzugefügt (siehe Abbildung 2.21).
Eine Komponente spezifiziert ebenfalls, ob noch weitere Komponenten eingebettet sind.
In dem Beispiel sind dies noch die beiden kontinuierlichen Komponenten - eine um die
Geschwindigkeit zu kontrollieren (Velocity Controller) und eine, um den Abstand zum
vorausfahrenden Shuttle zu kontrollieren (Distance Controller). Da die kontinuierlichen
Komponenten typischerweise aus der Regelungstechnik kommen, verdeutlicht dies sehr
deutlich die domänübergreifende Integration [HH06].
Abbildung 2.21: Shuttle Komponente
Während die Rollen der Komponenten hinzugefügt werden, können diese durch den Ent-
wickler verfeinert werden, indem sie z.B. im Verhalten eingeschränkt werden. Im Beispiel
kann der Entwickler z.B. festlegen, dass ein Shuttle nur als rear einem Konvoi beitritt.
46
2.4 Mechatronic UML
isConvoyOk
/ noConvoy
when(convoyUseful)
/ buildConvoy
default
Hwait
when(convoyNotUseful)
/ doBreakConvoy
convoyFront
isConvoyOK
/ convoyOK
noConvoy convoyRear
breakConvoy /
breakConvoy /
/ FrontRole.breakConvoyRejected
FrontRole.breakConvoyProposal
default
default
breakConvoy
FrontRole.breakConvoyProposal
/ FrontRole.breakConvoy
Synchronization
/ RearRole.startConvoy
convoyOk
wait
waitdefault
RearRole.breakConvoyProposalRejected /
RearRole.convoyProposal / isConvoyOK
noConvoy / RearRole.convoyProposalRejected
noConvoy
/ breakConvoy
RearRole.breakConvoy
doBreakConvoy
/ RearRole.breakConvoyProposal default
Convoy
RearRole
FrontRole.startConvoy /
buildConvoy / FrontRole.convoyProposal
FrontRole.convoyProposalRejected / breakConvoy
wait
convoy
noConvoy
FrontRole
d1
d1
d1
{t0}
d1[15 ≤t0]
d1
d1
d1
dc
dc
dcdc
dc
dc
dc
dc
dc
dcdc
Abbildung 2.22: Realtime Statechart der Shuttle Komponente
In Abbildung 2.22 ist das Verhalten der Komponente Shuttle aus Abbildung 2.21 darge-
stellt. Das Realtime Statechart besteht aus drei orthogonalen Zuständen FrontRole,Rear-
Role und Synchronization. Die Zustände FrontRole und RearRole sind Verfeinerungen
des Rollenverhaltens aus Abbildung 2.20 und spezifizieren das Kommunikationsverhal-
ten im Detail, um einen Konvoi zu erzeugen oder aufzulösen. Im Zustand Synchronization
wird das Kommunikationsverhalten und die Initiierung eines Konvois modelliert. Die drei
Unterzustände des Zustandes Synchronization stellen dar, ob sich das Shuttle gerade als
Führungsfahrzeug (convoyFront), als letztes Fahrzeug (convoyRear) oder als allein fah-
rendes Shuttle (noConvoy) verhält.
47
Kapitel 2 Grundlagen
Das ganze Statechart ist eine Verfeinerung beider Rollen und es wurde nur der Nicht-
Determinismus der Rollen aus Abbildung 2.20 durch hinzufügen von Synchronisation
aufgelöst.
Wie schon erwähnt, erfüllen Komponenten in der Domäne der mechatronischen Systeme
eine Menge von Echtzeitbedingungen. In dem Beispiel muss gelten, dass RearRole die
Nachricht startConvoy innerhalb einer bestimmten Zeit verschickt, nachdem sie convo-
yOK empfangen hat.
Um dieses adäquat durch Realtime Statecharts abbilden zu können, muss es möglich sein,
an Transitionen Zeit zu spezifizieren - in der Realität passiert auch keine Aktion in Null-
zeit. Hierfür werden die folgenden Deadline Konstrukte verwendet: In Abbildung 2.22
wird das Deadlineintervall dcund d1verwendet, um eine minimale und maximale Schalt-
zeit einer Transition anzugeben. Zum Beispiel muss das Senden der Nachricht convoy-
ProposalRejected innerhalb der Deadline dcpassieren, nachdem die Nachricht noConvoy
im Zustand FrontRole::noConvoy::wait empfangen wurde. Ein weiteres Beispiel ist der
Wechsel im Statechart Synchronization von noConvoy nach convoyFront, der innerhalb
von d1beendet sein muss.
Für eine Komponente, die mehrere Echtzeit-Koordinationsmuster anwendet, sind die
Verifikationsergebnisse der einzelnen Echtzeit-Koordinationsmuster immer noch erfüllt
[GTB+03]. Aufgrund dieses kompositionellen Ansatzes lassen sich mechatronische Sys-
teme sehr einfach komponentenbasiert entwickeln.
2.4.4 Einbettung hybrider Komponenten
Die Typdefinition der Komponenten aus Abbildung 2.21 spezifiziert, dass die Shuttle
Komponenten zwei verschiedene Unterkomponenten einbettet. Eingebettete Komponen-
ten sind im Kontext von mechatronischen Systemen zur Ressourceneinsparung nicht im-
mer aktiv. Die Aktivierung und Deaktivierung, oder auch Rekonfiguration, wird von Soft-
ware übernommen.
Das Modell der Realtime Statecharts aus Abbildung 2.22 wird dementsprechend erweitert
zu so genannten Hybriden Rekonfigurations Charts. Die Komponenten werden Zuständen
zugeordnet, so dass hier von Zustandskonfigurationen gesprochen wird. Der Velocity Reg-
ler ist aktiv in dem Zustand convoyFront und noConvoy. Beide Regler sind aktiv in dem
Zustand convoyRear, wobei der Wert des Distance Reglers noch als Eingabe für den Velo-
city Regler dient. Das das Modell der Hybriden Rekonfigurations Charts für den weiteren
Verlauf der Arbeit essentiell ist, wird es im Folgenden detailliert beschrieben.
Das klassische hybride Automatenmodell aus Definition 4 ermöglicht keine modulare
Rekonfiguration zur Laufzeit. Dieser Nachteil kann durch den hybriden Rekonfigurations
48
2.4 Mechatronic UML
isConvoyOK
/ convoyOK
/ noConvoy
isConvoyOk
Hwaitdefault
/ doBreakConvoy
when(convoyNotUseful)
after (15 msec)
convoyFront noConvoy
convoyRear
breakConvoy / breakConvoy /
/ buildConvoy
when(convoyUseful)
Synchronization
:Distance Controller
:Velocity Controller
:Velocity Controller:Velocity Controller
d1
d1
d1
d1
d1
d1
d1
d∗
d
X
V
V∗
F∗
F∗
V∗
X
V
V∗
X
V
F∗
Abbildung 2.23: Einbettung von kontinuierlichen Unterkomponenten in ein hybrides Re-
konfigurations Chart
Automaten aus [BGH05a] aufgehoben werden. Wie auch beim hybriden Automaten bet-
tet ein hybrider Rekonfigurations Automat Komponenteninstanzen in die Zuständen ein
und tauscht diese durch einen Zustandswechsel aus. Jedoch bietet der hybride Rekonfi-
gurations Automat zusätzlich die Möglichkeiten, die Struktur und den internen Zustand
der Komponenten durch einen Wechsel der Locations zu modifizieren. Durch diese bei-
den Möglichkeiten erlaubt das Modell eine Rekonfiguration des Systems. Ein weiterer
Vorteil des hybriden Rekonfigurations Automaten gegenüber dem hybriden Automaten
liegt darin, dass die Ports immer in Abhängigkeit von einer Location aktiv sind. Ports, die
innerhalb einer Location keine Signale empfangen, werden in dieser Location auch nicht
mehr dargestellt. Durch diese Möglichkeit der Modellierung wird dem Betrachter sofort
ersichtlich, von welchen Eingangsports der Ausgangsport abhängt.
Um die beschriebenen Vorteile umzusetzen, verwendet der hybride Rekonfigurations Au-
tomat im Gegensatz zum hybriden Automaten ein verändertes kontinuierliches Modell.
In diesem Modell werden die Zustands-, Eingabe- und Ausgabevariablen in Abhängig-
keit der jeweiligen Location angegeben.
Definition 15
Formal ist das kontinuierliche Modell D(l)des hybriden Rekonfigurations-Automaten
durch ein 7 Tupel (Vx(l), V u(l), V y(l), F(l), G(l), C(l), X0(l)) definiert:
•Vx(l): Menge der Zustandsvariablen,
•Vu(l): Menge der Eingabevariablen,
•Vy(l): Menge der Ausgabevariablen,
49
Kapitel 2 Grundlagen
•F(l)⊆EQ(V˙xSVa, V xSVuSVa): beschreibt den Fluss der Zustandsvaria-
blen,
•G(l)⊆EQ(V˙ySVa, V xSVuSVa): bestimmt die Ausgabevariablen,
•C(l)∈COND(Vx): Invariante, welche die Menge der zulässigen Zustände be-
stimmt und
•X0(l): Menge der Anfangszustände.
Ein Nachteil ist, dass durch das Einführen von Zuständen, die den Austausch von Reglern
realisieren, die Zustandsmenge zunimmt. Dies hat zur Folge, dass hybride Rekonfigurati-
ons Automaten sehr umfangreich werden. Des Weiteren kann in einem hybriden Rekon-
figurations Automaten keine Schaltdauer angegeben werden. Automatenmodelle bieten
ebenfalls keine Möglichkeit, hierarchische Zustände zu verwenden. Hybride Rekonfigu-
rations Chart, wie sie im Folgenden eingeführt werden, integrieren alle Konzepte.
Hybride Rekonfigurations Charts [BGH05a] bauen wie schon erwähnt auf dem Konzept
der Realtime Statecharts und der hybriden Rekonfigurations Automaten auf. Mit ihnen ist
es möglich, das Verhalten hybrider Komponenten, die sich durch die Kombination von
diskreten und kontinuierlichen Komponenten auszeichnen, zu modellieren. Sie besitzen
zusätzlich zu allen Eigenschaften der Realtime Statecharts die Möglichkeit, zwischen ato-
maren Umschalttransitionen und nicht-atomaren Umschalttransitionen zu unterscheiden.
Außerdem ist es möglich, in den Zuständen Komponenteninstanzdiagramme einzubetten,
so dass Rekonfiguration ermöglicht wird. Da Rekonfiguration nicht nur allein durch den
Austausch von Komponenteninstanzen erreicht werden kann, erlaubt es das Konzept der
hybriden Rekonfigurations Charts zusätzlich, die interne Struktur und den Zustand der
Komponenten zur Laufzeit zu ändern. In jedem Zustand, ausgenommen Start- und Stop-
zustand, können Komponenteninstanzdiagramme eingebettet werden.
Die Komponenteninstanzdiagramme bestehen aus den Komponenteninstanzen, die in der
Komponente eingebettet sind, deren Verhalten durch das hybride Rekonfigurations Chart
beschrieben wird. Für jede Komponenteninstanz kann angegeben werden, ob sie in ei-
nem Zustand existiert oder nicht. Falls eine hybride bzw. eine diskrete Komponentenin-
stanz in einem Zustand vorhanden ist, wird zusätzlich spezifiziert, in welchem Zustand
sich diese Komponenteninstanz befindet. Daraus ergibt sich ebenfalls, welche Ports aktiv
und welche inaktiv sind. Bei der Einbettung einer kontinuierlichen Komponente in einen
Zustand wird kein interner Zustand spezifiziert. Folglich sind auch alle Ports der konti-
nuierlichen Komponente aktiv. Neben der Einbettung von Komponenteninstanzen wird
zusätzlich spezifiziert, welche Delegations und Assemblys in diesem Zustand aktiv sind.
Durch diese vielfältige Spezifikation wird für jeden Zustand des hybriden Rekonfiguration
Charts ein Komponenteninstanzdiagramm erstellt. Verlässt bzw. betritt die Komponente
einen Zustand, wird bei der Modellierung vorausgesetzt, dass die eingebetteten Kompo-
nenteninstanzen ihren internen Zustand zeitgleich verlassen bzw. betreten.
50
2.4 Mechatronic UML
Die Transitionen des hybriden Rekonfigurations Charts können zusätzlich zu den Tran-
sitionen eines Realtime Statecharts eine Umschaltfunktion besitzen. Diese ermöglicht
es, die Ausgänge der eingebetteten Komponenteninstanzen in einem Zustand auf die
Ausgänge der eingebetteten Komponenteninstanzen in einem anderen Zustand umzu-
schalten. Eine Umschalttransitionen besteht aus einer Funktion ffade und einem Inter-
vall d= [dlow, dup], das die minimale und maximale Dauer des Umschaltens spezifiziert,
sowie der Ports, die ineinander übergeblendet werden. Die Dauer der Umschaltfunkti-
on wird als Deadline für die Umschalttransitionen spezifiziert. Durch das Konzept der
Umschaltfunktion existieren im Gegensatz zum hybriden Rekonfigurations Automaten
keine Zustände, die das Überblenden zwischen zwei Reglern realisieren. Dies führt dazu,
dass ein hybrides Rekonfigurations Chart nicht so komplex ist wie ein hybrider Rekon-
figurations Automat. Des Weiteren ermöglicht ein hybrides Rekonfigurations Chart die
Spezifikation von mehreren Hierarchieebenen.
Abschließend wird die formale Definition eines hybriden Rekonfigurations Chart gege-
ben. Die Definition baut auf der Definition eines hybriden Automaten (siehe Definition 4)
auf.
Definition 16
Ein Hybrides Rekonfigurations Chart wird durch ein 6-Tuple (L, D, I, O, T, S0)
beschrieben. Dabei ist Leine endliche Menge von Locations, Deine Funkti-
on über L, die jedem l∈Lein kontinuierliches Modell zuordnet, D(l) =
(Vx(l), V u(l), V y(l), F(l), G(l), C(l), X0(l)) ist ein kontinuierlicher Block wie in
Definition 15 beschrieben, Iist eine endliche Menge von Eingabesignalen, Oeine
endliche Menge von Ausgabesignalen, Teine endliche Menge von Transitionen und
S0⊆ {(l, x)|l∈L∧x∈X(l)}die Menge der initialen Locations.
Für jede Transition (l, g, gi, a, l0)∈Tgilt, dass l∈Ldie Sourcelocations, g∈
COND(Vx(l)∪Vu(l)) ein kontinuierlicher Guard, gi∈℘(I∪O)der I/O-Guard,
a∈[[Vx(l)→R]→[Vx(l0)→R]] die Aktualisierung kontinuierlicher Daten und
l0∈Ldie Targetlocation ist. Für jedes l∈Lwird gefordert, dass D(l)wohl-definiert ist.
Das Hybride Rekonfigurations Charts erlaubt, dass jeder Location eine eigene Variablen-
menge besitzt. Mit Vxwird die Vereinigung aller Vx(l)beschrieben. Vuund Vywerden
analog bestimmt. Mit Vx(F(l)) werden die Variablenmengen der Locations beschrieben.
Alle zugewiesenen Ausgabevariablen werden analog als provided Ausgabevariablenmen-
ge (Vy(F(l)∪G(l))) und alle Eingabevariablen als required Eingabevariablenmenge
(Vu(F(l)∪G(l))) bezeichnet.
Für eine Einbettung benötigt eine übergeordnete Komponente jedoch nicht alle Infor-
mationen, welche die hybriden Rekonfigurations Charts der eingebetteten Komponenten-
instanzen liefern. Es sind lediglich die nach außen sichtbaren Schnittstellen notwendig.
Diese werden von einem Interface Statechart beschrieben.
51
Kapitel 2 Grundlagen
Definition 17
Ein Interface Statechart für einen hybriden Rekonfigurations Automat M=
(L, D, I, O, T, S0)existiert genau dann, wenn für das kontinuierliche Modell D
folgendes gilt:
•Vy∩Vu=∅,
•alle v∈Vxsind Uhren: ˙v= 1,
•der Seiteneffekt a für jede Transition (l, g, gi, a, l‘) ist beschränkt durch OPconst,
wobei OPconst die Menge der möglichen Konstanten ist,
•das kontinuierliche Verhalten von Vyist unbestimmt.
2.4.5 Anpassung der Softwarestruktur
Echtzeit-Koordinationsmuster spezifizieren die Koordination zwischen unterschied-
lichen mechatronischen Komponenten. Während der Laufzeit können Komponenten
allerdings aktiviert und deaktiviert werden. Um dies auch zu berücksichtigen, muss
ein geeignetes Modell verwendet werden. dass die Echtzeit-Koordinationsmuster ent-
sprechend integriert. So ein Modell modelliert die Strukturanpassung von Software.
Bei Betrachtung wird ein Systemzustand durch eine Konfiguration aus Komponenten
und Echtzeit-Koordinationsmuster charakterisiert. Die Erzeugung und Löschung von
Echtzeit-Koordinationsmustern sowie der Austausch von Komponenten kann also durch
ein Graphtransformationssystem formalisiert werden [Sch06].
Der MECHATRONIC UML Ansatz unterstützt die Spezifikation von Strukturen durch
Klassendiagramme. Strukturänderungen können durch Story Diagramme modelliert
werden. Der Ansatz unterstützt ferner die Verifikation von strukturellen Invarianten
[BBG+06].
Für das Shuttlebeispiel ist ein Klassendiagramm in Abbildung 2.24(a)) dargestellt. Es
stellt die Komponenten des physikalischen Modells dar (Shuttles und Schienenabschnit-
te). Auf ein Schienenstück passt genau ein Shuttle. Die Position eines Shuttles ist durch
die on Assoziation modelliert; die go Assoziation modelliert die physikalische Bewegung
auf einem Schienenstück.
Wie gerade erwähnt findet die Kollisionsvermeidung durch das DistanceCoordination-
Pattern statt. Das DistanceCoordinationPattern wird erzeugt, sobald ein Shuttle sich
einem anderen Shuttle nähert. Die Instanziierungsregel createDC erzeugt das Echtzeit-
Koordinationsmuster, sofern zwei unverbundene Shuttle da sind (siehe Abbildung
2.24(b)).
52
2.4 Mechatronic UML
(a) Klassendiagramm (b) Instanziierungsregel: Erzeugung des Distan-
ceCoordinationPattern
Abbildung 2.24: Klassendiagramm und Instanziierung eines Echtzeit-
Koordinationsmuster
Zwei Regeln sind spezifiziert: (1) goSimple1 (siehe Abbildung 2.25(a)) beschreibt die
Bewegung eines einzelnen Shuttles von einem Schienenstück zum nächsten. (2) goDC1
(siehe Abbildung 2.25(b)) erlaubt dem rear Shuttle sich nur zu bewegen, wenn das front
Shuttle sich auch bewegt.
(a) Ein freies Shuttle bewegt sich (b) Koordinierte Fahrweise zweier Shuttles
Abbildung 2.25: Verhaltensregeln
Abbildung 2.26: Invariante: Keine unkontrollierte Bewegung zweier benachbarter Shutt-
les
Eine in diesem Kontext angewendete Invariante ist, die es gilt zu verifizieren, dass ein
Shuttle nie versucht, ein bereits besetztes Schienenstück zu befahren, ohne sich mit dem
53
Kapitel 2 Grundlagen
anderen Shuttle abgesprochen zu haben. Abbildung 2.26 zeigt diese Invariante als Nega-
tive Anwendungsbedingung.
2.5 Zusammenfassung
In diesem Kapitel wurden die Grundlagen dieser Arbeit beschrieben. Hierzu wurde zuerst
die grundlegende hierarchische Struktur eines mechatronischen System nach Lückel, wie
es in dieser Arbeit aufgefasst wird, diskutiert. Ein Operator-Controler-Modul beschreibt
die Informationsverarbeitung eines mechatronischen System. Es ist in die drei Ebenen
Controller, Reflektorischer Operator und Kognitiver Opertor aufgebaut. Die Software ei-
nes OCMs ist sowohl für die Koordination innerhalb als auch für die Koordination meh-
rerer OCMs verantwortlich. Da die Software komplex und sicherheitskritisch ist, muss
diese verifiziert werden.
Anhand des Vorgehens der modell-basierten Entwicklung, wurden Modelle und Verfah-
ren zur Verifikation von mechatronischen Systemen vorgestellt. Diese sind jedoch für die
komplexen, vernetzten mechatronischen Systeme, wie sie hier beschrieben sind, nicht
alleine anwendbar. Der MECHATRONIC UML Ansatz wird hier als Lösung vorgeschla-
gen. Dieser kombiniert die Techniken aus den verschiedenen Domänen der Softwaretech-
nik und der Regelungstechnik, die es erlauben, solche Modelle adäquat zu modellieren
und zu verifizieren. Die Architektur der Software wird mittels Komponentendiagrammen
und Echtzeit-Koordinationsmustern beschrieben. Zur Spezifikation der komponentenin-
ternen Struktur werden Klassendiagramme verwendet. Das Verhalten wird durch Re-
altime Statecharts und Hybride Rekonfigurations Charts beschrieben. Die dynamischen
Strukturänderungen werden durch Story Pattern beschrieben.
Aufbauend auf den Techniken des MECHATRONIC UML Ansatzes werden nun in den
nächsten Kapiteln Erweiterungen und neue Verfahren für die Modellierung, als auch für
die Verifikation, komplexer, vernetzter mechatronischer Systeme vorgestellt.
54
Kapitel 3
Verifikation eines OCM
In Kapitel 2.1 wurde die Struktur eines mechatronischen Systems (siehe Abbildung 2.1)
beschrieben. Der Fokus dieses Kapitels liegt nun auf der Verifikation eines OCMs, ge-
nauer gesagt, auf der Verifikation des korrekten Zusammenspiels hinsichtlich der hierar-
chischen Rekonfiguration (siehe Abschnitt 2.4.4) zwischen dem Reflektorischen Operator
und dem Controller. In Abbildung 3.1 ist die Aufgabe der Verifikation eines OCM, wie sie
in diesem Kapitel im Folgenden beschrieben wird, skizziert. Hierzu wird zuerst anhand
der in den Grundlagen vorgestellten Modellierungskonzepte der MECHATRONIC UML
(siehe Abschnitt 2.4) informal ein Beispiel eingeführt (siehe Abschnitt 3.1). Danach wird
die syntaktische Verifikation für die hierarchische Rekonfiguration bedingt durch rein lo-
kal relevante Zeitbedingungen für die Rekonfiguration innerhalb eines OCMs beschrieben
(Abschnitt 3.2). Anschließend wird in Abschnitt 3.3 das Beispiel um nicht lokale Eigen-
schaften bezüglich der Zeitbedingungen sowie um nicht-deterministisches Verhalten be-
züglich der Rekonfiguration erweitert. Anhand dieses Beispiels werden die Konzepte zur
Verifikation für die sichere Rekonfiguration in Abschnitt 3.4 erklärt. Das Kapitel schließt
mit einer Zusammenfassung in Abschnitt 3.6.
3.1 Beispiel
Das Feder-Neige-Modul ist ein Teilsystem des in Abschnitt 1.2 vorgestellten Shuttlesys-
tems der Neuen Bahntechnik Paderborn. Das Feder-Neige-Modul ist ein Beispiel für ein
komplexes mechatronisches System. Die Aufgabe des Feder-Neige-Moduls ist es, einen
maximalen Fahrkomfort für die Passagiere eines Shuttles zu ermöglichen. Befährt ein
Shuttle einen Schienenabschnitt, sammelt es Informationen über die Streckenverhältnisse
und sendet diese nach Befahren des Streckenabschnittes an eine Streckenabschnittskon-
trolle. Die Streckenabschnittskontrolle kann diese Information weiteren Shuttles zur Ver-
fügung stellen, so dass diese anhand der Streckeninformationen Unebenheiten ausglei-
chen können und somit der Fahrkomfort erhöht wird. Die Verarbeitung der Streckenin-
formationen sowie das damit verbundene Erreichen des maximalen Fahrkomforts werden
55
Kapitel 3 Verifikation eines OCM
:Sensor[On]:BC[Reference] :Sensor[On]
storage:Storage
:BC[Absolute]
when(next
Segment)
noData? /
Behavior
zRefFailure
Reference Absolute
zRefOK
when(nextSegment)
AbsAvailableAllAvailable
Controller
Reflektorischer Operator
Behavior
data(Vector zRef)? /
Überprüfung der hierarchischen Rekonfiguration
d2
d3
zref
¨zabs
¨zabs
db
dd
Abbildung 3.1: Verifikation eines OCM
vom Feder-Neige-Modul ermöglicht [TMV06]. Der physikalische Aufbau aller relevanten
Teilmodule ist in Abbildung 3.2 dargestellt und wird im Folgenden im Detail beschrieben.
Das Feder-Neige-Modul besteht unter anderem aus einem Aufbau, der über Luftfedern
mit dem Fahrwerk verbunden ist. Zudem enthält das Feder-Neige-Modul verschiedene
Regler, welche die Position der drei hydraulischen Zylinder A,Bund Caufgrund von
Werten der Sensoren regeln. Die Zylinder wiederum beeinflussen aktiv den Aufbau und
damit auch das Fahrwerk [HSE02].
Die Sensoren messen die Streckenverhältnisse und liefern diese Werte als Eingabe für
den jeweiligen Regler. Dieser führt anhand der Eingabewerte Berechnungen durch, um
die Ergebnisse anschließend an die Zylinder weiterzuleiten. Je nach Ergebnis ihrer Be-
rechnung wird die Position der Zylinder verändert, so dass sich das Feder-Neige-Modul
56
3.1 Beispiel
der Schienenumgebung anpassen kann und damit den für die Strecke höchstmöglichen
Fahrkomfort liefert.
ABC
prop.- valves
A/D
controller
D/A
sensors
hydr. pump
car body
hydr. actuators
air springs
to the
actuators
z
y
a
Abbildung 3.2: Schematische Darstellung des Feder-Neige-Moduls
Das verwendete CAE Werkzeug CAMeL [Ric96] ermöglicht die Beschreibung des kom-
pletten kontinuierlichen Parts des Modells durch strikte, hierarchische Blockdiagramme
mit nichtlinearen Gleichungen der Art
˙x=f(x, u, t)und y=g(x, u, t)
wobei xder Zustandsvektor, ˙xdie erste Ableitung des Zustandsvektors, yder Ergebnis-
vektor, uder Eingabevektor und tdie Zeit ist.
Das Feder-Neige-Modul besteht aus drei Reglern. Der Regler Reference stellt den höchs-
ten Komfort zur Verfügung, indem er durch die Vorgabe einer Trajektorie die Bewegung
des Aufbaus beschreibt, um Unebenheiten der Strecke auszugleichen. Um die Stabilität
des Systems zu gewährleisten und um damit Entgleisungen des Shuttles entgegenzuwir-
ken, müssen alle Sensoren immer korrekte Werte liefern (siehe Grundlagenkapitel 2.2).
Falls dies beim Regler Reference nicht mehr der Fall ist, wird der Regler Absolute ver-
wendet, der als Eingabe nur die vertikale Beschleunigung des Aufbaus benötigt. Falls
auch dieser Sensor ausfällt, wird der Regler Robust aktiv, der den geringsten Komfort zur
Verfügung stellt. Dieser Regler benötigt nur die Standardeingabewerte, um Stabilität zu
gewährleisten.
Das Blockdiagramm der Regler ist in Abbildung 3.3 dargestellt. Die Komponente body
control (BC) ist verantwortlich für die übergeordnete Regelung des Feder-Neige-Moduls
57
Kapitel 3 Verifikation eines OCM
und besteht aus den eben beschriebenen drei Reglern. Abhängig von den Eingabesignalen
wird zwischen den Reglern umgeschaltet. Das Referenzsignal ist mit zref und die absolute
Beschleunigung mit ¨zabs bezeichnet. Die Ausgabewerte sind XZ,A,ref , . . . , XZ,C,ref und
geben die Position der hydraulischen Zylinder an.
z
..
z
Zref.
abs.
XZ, A, ref.
XZ, B, ref.
XZ, C, ref.
normal
“reference”
“absolute”
failure
“robust”
body control
common
inputs
switch control
Abbildung 3.3: Blockdiagramm der Regler
Beim Wechsel zwischen zwei Reglern wird zwischen zwei Fällen unterschieden: Atoma-
res Umschalten und nicht-atomares Umschalten. Im ersten Fall findet der Wechsel ganz
normal zwischen zwei Berechnungsschritten statt. Im Beispiel wäre der Wechsel vom
Block normal zum Block failure atomar. Im anderen Fall ist es notwendig, eine Umschalt-
funktion fswitch(t)und eine Umschaltdauer zu spezifizieren [OMT+08]. Im Beispiel wäre
das der Wechsel zwischen dem Regler reference und dem Regler absolut.
3.1.1 Komponenten Struktur
In diesem Abschnitt wird beschrieben, wie sich die Architektur mittels MECHATRO-
NIC UML beschreiben lässt. Abbildung 3.4 zeigt die Architektur. Die Monitor Kompo-
nente koordiniert die Einbettung der Komponenten BC,Sensor, und Storage. Außerdem
kommuniziert sie über das Echtzeit-Koordinationsmuster MonitorRegistration mit einer
Streckenabschnittskontrolle Registry. Die Streckenabschnittskontrolle sendet Informatio-
nen über die kommenden Streckenabschnitte an die Komponente Monitor, die diese dar-
aufhin in der Unterkomponente Storage abspeichert. Die Unterkomponente Sensor liefert
die benötigten Signale.
58
3.1 Beispiel
Monitor
Role
:Sensor
:Registry
Registry
Role
:Monitor
storage : Storage
:BC
Registration
Monitor−
Abbildung 3.4: Die Architektur
3.1.2 Verhalten der Komponenten
Das Verhalten sowie die Einbettung von kontinuierlichem Verhalten einer Komponenten
wird durch ein Hybrides Rekonfigurations Chart beschrieben (siehe Kapitel 2.4). Abbil-
dung 3.5 zeigt das Hybride Rekonfiguration Chart der Komponente BC. Diese besteht
aus den drei Zuständen Robust,Absolute und Reference. Jedem Zustand ist ein konti-
nuierlicher Regel mit verschiedenen Eingangs- und Ausgangssignalen zugeordnet. Die
fett gezeichneten Transitionen zeigen an, das bei diesen Zustandswechseln umgeschal-
tet wird, es sich also um nicht-atomares Umschalten handelt. Die anderen Transitionen
stellen atomares Umschalten dar.
3.1.3 Beschreibung des Interface
Für die Einbettung oder Verknüpfung von hybriden Komponenten werden nicht immer
alle Details der Realisierung einer Komponente benötigt. Es reichen hier die Informa-
tionen über die externen Signale aus, so dass die Kompatibilität analysiert werden kann.
Abbildung 3.6 zeigt das abgeleitete Interface Statechart (siehe Definition 17) der Kom-
ponente BC. Die BC Komponente hat drei mögliche verschiedene externe Zustände mit
unterschiedlichen kontinuierlichen Eingabesignalen.
59
Kapitel 3 Verifikation eines OCM
zAbsFailure
zAbsOK
Robust
Reference
Absolute
zRefOK
zAbsFailure
zAbsOK
zRefFailure
<Abs>
<Ref>
<Rob>
d4
d2
ffade2
ffade1
¨zabs
¨zabs
zref
d1
d3
ffade3
ffade4
Abbildung 3.5: Verhalten der Body Komponente
zRefOK
zAbsFailure
zAbsOK
zRefFailure
zAbsOK
[Robust]
[Absolute]
zAbsFailure
[Reference]
d2
d3
d1
d4
¨zabs
zref
¨zabs
Abbildung 3.6: Interface Statechart der Komponente BC
60
3.2 Verifikation der hierarchischen Rekonfiguration bedingt durch lokale
Zeitbedingungen
Im Folgenden wird die Einbettung der Unterkomponenten innerhalb eines hybriden Re-
konfigurations Charts beschrieben. Diese Einbettung erlaubt es später, die korrekte Ein-
bettung rein syntaktisch zu überprüfen (siehe Abschnitt 3.2).
3.1.4 Einbettung
Durch Zuordnung von Konfigurationen der Untergeordneten Komponenten zu jedem Zu-
stand eines hybriden Rekonfigurations Chart wird die Einbettung realisiert. (siehe Abbil-
dung 3.7). Ein Wechsel zwischen den Zuständen in der Monitor Komponente impliziert
einen Wechsel der Zustände im Interface Statechart der eingebetteten Komponenten.
Das Verhalten der Monitor Komponente ist wie folgt durch das hybride Rekonfigurations
Chart beschrieben (siehe Abbildung 3.7). Der obere orthogonale Zustand besteht aus den
Zuständen AbsAvailable,NoneAvailable,RefAvailable und AllAvailable. Die letzten beiden
repräsentieren, ob die benötigte Referenztrajektorie für den aktuellen Schienenabschnitt
zur Verfügung steht oder nicht.
Die Komponente BC ist jedem Zustand des oberen orthogonalen Zustandes zugeordnet.
So ist z. B. die Komponenteninstanz BC im Zustand Reference dem Zustand AllAvailable
der Komponente Monitor zugewiesen, in dem zref sowie as ¨zabs verfügbar sind.
Die Kommunikation mit der Streckenabschnittskontrolle Registry ist im unteren ortho-
gonalen Zustand in der Abbildung (Abbildung 3.7) modelliert. Der obere orthogonale
Zustand synchronisiert sich mit dem unteren Zustand.
3.2 Verifikation der hierarchischen Rekonfiguration
bedingt durch lokale Zeitbedingungen
Für die Verifikation eines OCMs werden die folgenden zwei Verifikationsverfahren be-
reitgestellt. Als erstes muss das reine Echtzeitkoordinationsverhalten der Software, mo-
delliert durch Komponenten und Echtzeit-Koordinationsmuster, verifiziert werden. Hier-
für wird der in [Gie03][GTB+03][Hir04][BGH+05b] beschriebene Ansatz verwendet und
im Folgenden kurz skizziert. In diesem Zusammenhang wird eine Definition von Verfei-
nerung gegeben, welche die Eigenschaft der deadlock-Freiheit erhält. Weiterhin wird eine
Menge von kompositionellen Bedingungen eingeführt. Diese Grundlagen bilden ein Fra-
mework, welches es erlaubt, komplexe Echtzeitsysteme auf high-level Ebene (siehe Ab-
schnitt 2.4) zu spezifizieren und zu verifizieren. Der Ansatz bezieht sich auf die Notation
von Komponenten und Echtzeit-Koordinationsmustern, wie sie in Kapitel 2.4 eingeführt
wurden. Der Vorteil ist, dass der erörterte Ansatz es erlaubt, ein System zu verifizieren,
61
Kapitel 3 Verifikation eines OCM
:Sensor[Off]:BC[Robust]
storage:Storage
:Sensor[On]:BC[Reference] :Sensor[On]:BC[Absolute]
:BC[Robust] :Sensor[Off]
when(next
Segment)
noData? /
when(nextSegment)
data(Vector zRef)?
registry.sendInfo(zRef) / storage.add(zRef)
when(storage.isEmpty())
Trajectory
Available
/ registry.experience
data(Vector zRef)!
!storage.isEmpty())
when(
when(nextSegment)
data(Vector zRef)? /
sensor.ok
RefAvailable NoneAvailable
sensor.failure
sensor.ok
data(Vector zRef)?
noData?
AbsAvailableAllAvailable
sensor.failure
when(nextSegment)
data(Vector zRef)? /
registry.experience
noData! /
after(20) /
registry.requestInfo
TrajectoryNot
Available
db
ddda
dc
Abbildung 3.7: Einbettung der Untergeordneten Komponenten im Monitor
ohne jemals den gesamten Zustandsraum aufzubauen. Stattdessen kann jede Komponente
und jedes Echtzeit-Koordinationsmuster einzeln durch einen Model Checker verifiziert
werden. Die folgenden fünf Schritte skizzieren den Ablauf der Verifikation:
1. Spezifiziere alle Echtzeit-Koordinationsmuster und ihre Rollen.
2. Verifiziere jedes Echtzeit-Koordinationsmuster einzeln.
3. Spezifiziere die Komponenten durch Verfeinerung der Rollen zu Ports.
4. Verifiziere jede Komponente einzeln.
5. Konstruiere durch Komposition der Echtzeit-Koordinationsmuster und Komponen-
ten das vollständige Modell.
Schritt 5 sichert die korrekte semantische Komposition bei einer korrekten syntaktischen
Komposition zu. Ein zusätzlicher sechster Schritt, der die Verifikation des ganzen Sys-
62
3.2 Verifikation der hierarchischen Rekonfiguration bedingt durch lokale
Zeitbedingungen
tems durchführen würde, ist nicht erforderlich. Dieses Resultat folgt aus Theorem 1 in
[Gie03]. Jedoch ist dieses Theorem nur unter der Annahme gültig, dass lokale Eigen-
schaften für Echtzeit-Koordinationsmuster und Komponenten vorliegen. Abbildung 3.8
zeigt die Überschneidung der Elemente Echtzeit-Koordinationsmuster und Komponenten.
Diese ist immer durch ein wohl definiertes Protokoll, das von beiden Seiten eingehalten
wird, gekennzeichnet. Der Echtzeitcharakter der Protokolle stellt sicher, dass unbegrenzte
gegenseitige Sperreffekte ausgeschlossen werden. In nicht zeitbehafteten Systemen ist ein
ähnlicher Ansatz nicht möglich, da maximale Sperrzeiten nicht explizit angegeben sind
und deshalb zyklische Sperreffekte entstehen können (siehe hierzu [Gie00]).
:Monitor :Registry
Monitor−
Registration
Abbildung 3.8: Verifikation des Echtzeitkoordinationsverhaltens der Software, modelliert
durch Komponenten und Echtzeit-Koordinatiosmuster
Als zweites muss die im letzten Abschnitt beschriebene hierarchische Komponentenstruk-
tur für die Modellierung von diskreten und kontinuierlichen regelungstechnischen Verhal-
ten hinsichtlich der konsistenten Rekonfiguration und der korrekten Echtzeitsynchronisa-
tion hinsichtlich der Rekonfiguration verifiziert werden. Das zweite Verifikationsverfah-
ren kann dabei in das erste integriert werden [GBSO04][GH05b][GH06].
Hierbei werden die in der Einleitung 1.3 beschriebenen Konzepte der Abstraktion und
Verfeinerung eingesetzt. Wie schon angedeutet, ist es das Ziel, den bisherigen komposi-
tionellen Ansatz weiter zu verwenden. Hierzu muss nun geeignet vom hybriden Verhalten
abstrahiert werden. In Abbildung 3.9 ist eine Abstraktion skizziert, die vorgenommen
werden muss. Um diese formal zu beschreiben, wird im Folgenden das Hierarchie- und
Modularitätskonzept von hybriden Rekonfigurations Charts formal eingeführt.
3.2.1 Modularität
In diesem Abschnitt wird das modulare Konzept, welches von dem Verifikationsverfahren
unterstützt wird, beschrieben. Als erstes werden notwendige Bezeichnungen eingeführt.
Eine hierarchische Komponentenstruktur ist durch eine Menge von Komponenteninstan-
zen C1, . . . , Cnund Funktionen sub, sub∗:{1, . . . , n} → ℘({1, . . . , n})beschrieben.
63
Kapitel 3 Verifikation eines OCM
Universität Paderborn
AG Softwaretechnik
Prof. Dr. W. Schäfer
3.4 Abstraktion
Echtzeitsystem
Hybrides
S1
S2
Abstraktion von hybridem Verhalten
Hybrides
System
S1
C1
<D
>
C1
<D
>
S2
<D
1
>
<D
3
>
D
D
D
1
C2
<E
1
>
C3
<E
3
>
D
3
C4
<F
2
>
Modulare Echtzeitverifikation hybrider UML-Komponenten Seite: 41
<E
1
>
<E
3
>
<F
2
>
Abbildung 3.9: Abstraktion
Hierbei ist sub(i)die Indexmenge von allen direkt angrenzenden Komponenten von Ci.
sub∗(i)bildet die transitive Hülle von sub einschließlich des Input-Index i. Das Verhalten
jeder Komponenteninstanz Ciwird durch einen zugehörigen Automaten Mi, der ein hy-
brides Rekonfiguration Chart (siehe Definition 16, Kapitel 2.4.4) repräsentiert, beschrie-
ben. Weiterhin gibt es einen Automaten MI
i, der das zugehörige Interface Statechart (sie-
he Definition 17, Kapitel 2.4.4) repräsentiert. Das Interface eines Automaten Mwird mit
I(M)bezeichnet. Es besteht aus Eingabe- und Ausgabevariablen. Die Parallelausführung
zweier Automaten wird durch kbeschrieben. Das Interface eines einzelnen Automaten M
kann eingeschränkt werden, indem alle Signale zur Synchronisation sowie alle Variablen,
die nicht im Interface vorkommen, versteckt werden. Dies wird mit M|Ibeschrieben.
(siehe [GH05a] für die verwendete Definition der Verfeinerung)
Im Folgenden wird nun das Modularitätskonzept formal definiert. Für jede Blatt-
Komponente Cjmit sub(j) = ∅gilt die Verfeinerung vHY zwischen dem Komponenten-
verhalten Mj, beschrieben durch das hybride Rekonfigurations Chart, und dem abstrakten
Interface Statechart MI
j
MjvHY MI
j.(3.1)
Für jede nicht Blatt-Komponente Ckwird angenommen, dass für MI
kund Mkinklusive
aller Interface Automaten der untergeordneten Komponenten gilt:
(Mkkkl∈sub(k)MI
l)|I(MI
k)vHY MI
k.(3.2)
64
3.2 Verifikation der hierarchischen Rekonfiguration bedingt durch lokale
Zeitbedingungen
Die Bedingung 3.2 gilt, da zwischen dem Verhalten einer Komponente und dem Verhalten
eines Interface Automaten die Verfeinerung
Mk|I(MI
k)vHY MI
k(3.3)
gilt und dass der Einfluss von Mkauf das Verhalten seiner Unterkomponenten Mlmit
l∈sub(k)immer in einer korrekten Einbettung
(Mkkkl∈sub(k)MI
l)|I(Mk)vHY Mk(3.4)
endet.
Die Bedingungen 3.1 und 3.2 stellen jeweils eine lokale Abstraktionsbedingung für jede
Komponente Ckund dem zugehörigen Verhalten Mksowie des Interface Automaten MI
k
dar. Per Induktion über die Baumstruktur kann nun modular gezeigt werden, dass jedes
Komponentenverhalten sowie der Interface Automat durch den vollständigen Baum, be-
stehend aus den direkten und indirekten Unterkomponenten inklusive der Komponenten
selber, abgebildet werden kann.
kl∈sub∗(k)Ml|I(Mk)vHY Mk∧kl∈sub∗(k)Ml|I(MI
k)vHY MI
k(3.5)
Um das beschriebene Modularitätskonzept praktisch anwenden zu können, wird ein ef-
fektiver und effizienter Algorithmus, um die Verfeinerung und Einbettung zu überprüfen,
benötigt. Für allgemeine hybride Systeme, die sich nicht mehr durch die Klasse der rec-
tangular automata, bei denen die analogen Variablen Trajektorien mit teilweise-linearer
Entwicklung und Sprüngen, bedingt durch Re-Initialisierungen, folgen, beschreiben las-
sen, ist die Erreichbarkeit nicht mehr entscheidbar [HKPV98]. Selbst bei der Verwendung
der eingeschränkten Klasse ist die Verifikation durch Model Checking ebenfalls nur für
kleine Beispiele anwendbar [Dor08].
Aufgrund dieser Tatsache werden die Analysen zuerst auf das reine Echtzeitverhalten und
die Analyse, ob rein konsistente Konfigurationen mit wohl-definierten kontinuierlichen
Gleichungen erreicht werden können, beschränkt.
In einem ersten Schritt wird hierfür von dem kontinuierlichen Verhalten eines Automa-
ten Mabstrahiert, indem nur die Uhren betrachtet werden, so dass das Hybride Rekon-
figurations Chart sowie das zugehörige Interface Statechart auf ein Realtime Statechart
abgebildet werden können. Als nächstes kann das Realtime Statechart nach den in
[Hir04][BGHS04] beschriebenen Regeln auf Timed Automata abgebildet werden. Auf
dem Modell der Timed Automata kann nun die Überprüfung der Verfeinerung sowie die
Überprüfung der korrekten Einbettung durchgeführt werden. Für die Timed Automata
müssen hier anstelle von vHY nur vRT sowie die Bedingung De(MR, c)⊆De(MI, c00)
für die Variablenabhängigkeiten überprüft werden.
65
Kapitel 3 Verifikation eines OCM
3.2.2 Überprüfung der Verfeinerung
In vorangegangenen Arbeiten [GBSO04] wurden die Zeitbedingungen in den Interface
Statecharts auf solche eingeschränkt, welche die reine Schaltdauer einer Transition ange-
ben (die Verweildauer in einem Zustand in einem Timed Automaton (siehe [Hir04])).
Definition 18
Sei M= (L, D, I, O, T, S0)ein hybrider Automat. Ein Zustand l0ist ein Umschalt-
Zustand, falls eine Uhr cund Konstanten a0und b0existieren, so dass nur eine einzelne
Transition t∈Tum l0zu verlassen existiert mit t= (l0, a0≤t≤b0, l000)und für alle
Transitionen (l00, g, S, R, l0)∈Tgilt, dass c∈Rund C(l0) = c≤b0. Ein Zustand list
passiv genau dann, wenn CI(l) = true und für alle Transitionen (l, g, S, R, l0)∈T, wobei
l0ein Umschalt-Zustand ist und g=true gilt.
Definition 19
Ein Automat M= (L, D, I, O, T, S0)wird als simpel bezeichnet, falls Mengen von pas-
siven Zuständen Lpund Umschalt-Zustände Lfexistieren, mit L=Lp]Lf.
Aufgrund dieser Annahmen ist es möglich, die Verfeinerung zwischen einem simplen In-
terface Automaten MI= (LI, DI, II, OI, TI, S0I)für ein gegebenes simples Interface
Statechart und dem zugehörigen Komponentenverhalten M= (L, D, I, O, T, S0)durch
reine syntaktische Regeln zu überprüfen. Für Lf⊆Lund LI=LI
p]LI
f, wobei LI
pdie
Menge der passiven Zuständen von LI,LI
fund Lfdie Mengen der Umschalt-Zustände,
map :LI
p→℘(L)eine Abbildungsfunktion zwischen den passiven Zuständen des Inter-
face Automaten und den zugehörigen Zuständen des Hybriden Rekonfigurations Charts
der unterliegenden Komponente sind, kann einfach überprüft werden, ob für die Verfei-
nerung des Echtzeitverhaltens gilt:
1. Für alle Zustände li∈LI
p,l∈map(li)und l0∈Lfwird überprüft, ob für jedes
Paar von Transitionen zwischen passiven Zuständen und Umschalt-Zuständen gilt,
dass bei der Verfeinerung nicht die externen Signale sowie Zeitrestriktionen, wie
vom Interface Automaten vorgegeben, verändert werden:
∀(l, g, S, R, l0),(l0, g0, S0, R0, l00)∈T, ∃(li, g00, S, R, l0
i),(l0
i, g000, S0, R0, l00
i)∈TI:
g0=true ∧g00 =a≤t≤b∧g000 =aI≤t≤bI∧
c(l0) = t≤b∧c(l0
i) = t≤bI∧
aI≥a∧b≥bI∧
l0∈Lf∧l0
i∈LI
f∧
g=true ∧R=R0={t} ∧ l00 ∈map(l00
i)
∀(li, g, S, R, l0
i)∈TI:g=true ∧ ∃(l, g0, S, R0, l0)∈T∧_
(l,g0,S,R0,l0)∈T
g0=true.
66
3.2 Verifikation der hierarchischen Rekonfiguration bedingt durch lokale
Zeitbedingungen
2. Für alle Zustände l, l0∈L\Lfmuss überprüft werden, dass die Transitionen zwi-
schen ihnen zugehörige Transitionen im Interface Automaten haben oder die fol-
gende Abbildung erfüllen:
∀(l, g, S, R, l0)∈T:
(S=∅∧∀li∈LI: (l∈map(li)⇒l0∈map(li))) ∨
(g=true ∧ ∃(li,true, S, R0, l0
i)∈TI) : l0∈map(l0
i).
3. Für alle Zustände l∈Limuss überprüft werden, dass l6∈ Lfund dass sie durch die
initialen Locations des zugehörigen Interface Automaten abgedeckt sind:
∃li∈LI
i:l∈map(li).
Zusätzlich muss für alle l∈Lund li∈Limit l∈map(li)gelten, dass jede Abhängigkeit
zwischen den Eingabe und Ausgabe Variablen D(l)ebenfalls im zugehörigen Interface
Automaten als DI(li)vorkommen.
3.2.3 Überprüfung der korrekten Einbettung
Um die korrekte Einbettung sicherzustellen, muss als erstes die korrekte Echtzeitkoordi-
nation der Umschaltzeiten der Transitionen überprüft werden. Hierbei reicht es aus, die
simplen Interface Statecharts zu betrachten, um zu zeigen, dass ein Hybrides Rekonfi-
guration Chart alleine eine Abstraktion von einem Hybriden Rekonfigurations Chart zu-
sammen mit den Interface Statecharts der Unterkomponenten ist (siehe Bedingung 3.2).
Da auch hier die Erreichbarkeitsfrage nicht entscheidbar und für die meisten praktischen
Systeme auch nicht anwendbar ist, wird in [GBSO04] vorgeschlagen, anstelle der Ana-
lyse des kompletten Zustandsraums statische Analysen, die auf den Transitionsmengen
und Zustandsmengen der Hybriden Rekonfigurations Automaten Miund der Interface
Automaten MI
lmit l∈sub(i)operieren, zu verwenden. Dieses wird im Folgenden for-
malisiert.
Gegeben sei eine Funktion mode :L×sub(i)→Sj∈sub(i)LI
j, so dass für alle l∈Lund
j∈sub(i)gilt, dass mode(l, j)∈LI
j. Weiterhin wird angenommen, dass alle lokalen
Transitionen mit den Eingabe und Ausgabe Variablen ∅markiert sind und dass Lf⊆L
und LI
j=LI
j,p ]LI
j,f mit LI
j,p und Lpalles passive Locations und LI
j,f und Lfalles
Umschaltlocations sind.
1. Für alle Zustände l∈L\Lfund l0∈Lfwird überprüft, dass für jedes Paar von
Transitionen zwischen passiven Locations und Umschaltlocations gilt, dass für jede
67
Kapitel 3 Verifikation eines OCM
zugehörige Komponente j∈sub(i)gilt, dass ein Paar von Transitionen existiert,
das in den vorgegebenen Zeitschranken von Marbeitet:
∀(l, g, S, R, l0),(l0, g0, S0, R0, l00)∈T, ∃(lj, gj, Sj, Rj, l0
j),(l0
j, g0
j, S0
j, R0
j, l00
j)∈TI
j:
g0=a≤t≤b∧g0
j=aI
j≤t≤bI
j∧
c(l0) = t≤b∧c(l0
j) = t≤bI
j∧
aI
j≥a∧b≥bI
j∧
l0∈Lf∧l0
j∈LI
i,f ∧
g0=true ∧R0={t} ⊆ R∧lj=mode(l, j)∧l00
jmode(l00, j)
2. Für alle Zustände l, l0∈L\Lfjeder zugehörigen Komponente j∈sub(i)und alle
Transitionen (l, g, S, R, l0)∈Tmuss überprüft werden, das jede atomare Transition
keine Rekonfiguration hervorruft oder von ihr abgedeckt ist:
(mode(l, j) = mode(l0, j)) ∨(∃(lj,true, Sj, Rj, l0
j)∈TI) : l0
j=mode(l0, j).
3. Für alle initialen Zustände l∈Liund alle zugehörigen Komponenten j∈sub(i)
mit lj=mode(l, j), muss überprüft werden, dass sie alle durch alle initialen Loca-
tions abgedeckt werden:
lj∈LI
j,i.
In [GBSO04][BGO04] wurde gezeigt, dass die Überprüfungen ausreichen um für simple
Interface Statecharts zu zeigen, dass die Bedingung 3.2 erfüllt ist.
In Abbildung 3.10 ist das Verhalten der Monitorkomponenten und der Teil der Interface
Statecharts der eingebetteten BC Komponenten (siehe Abbildung 3.6 und 3.7) dargestellt.
Die Semantik der hybriden Rekonfigurations Charts erfordert, dass eine Transition vom
Zustand AbsAvailable zum Zustand AllAvailable einen Transitionswechsel in der BC Kom-
ponente vom Zustand Absolute zum Zustand Reference bedingt. Für die monitor Kompo-
nenten gilt, dass die Transition innerhalb des Zeitintervalls dbabgeschlossen ist. Für den
implizierten Zustandswechsel in der BC Komponente hingegen gilt, dass dieser innerhalb
des Zeitintervalls d3abgeschlossen sein muss. Dies bedeutet eine konsistente parallele
Ausführung beider Transitionen die erfordert, dass d3⊆dberfüllt ist. Für die Transition
zu AllAvailable und der Transition zum Zustand Reference in der BC Komponente gilt,
dass d2⊆dderfüllt sein muss.
Für einen spezifischen Zustandswechsel eines Hybriden Rekonfigurations Chart gilt, dass
es nur dann in einer inkorrekten Rekonfiguration endet, falls die Abhängigkeit der zu-
gehörigen Zustandskombinationen der Unterkomponenten einen Zyklus enthält. Da die
verwendete Verfeinerungsbeziehung sicherstellt, dass für jede Abhängigkeit zwischen
Eingabe- und Ausgabesignalen von Mdiese ebenfalls im zugehörigen Interface Auto-
maten MIvorkommen, ist es in diesem Falls ausreichend, den Interface Automaten zu
68
3.2 Verifikation der hierarchischen Rekonfiguration bedingt durch lokale
Zeitbedingungen
storage:Storage
:Sensor[On]:BC[Reference] :Sensor[On]:BC[Absolute]
when(next
Segment)
noData? /
when(nextSegment)
AbsAvailableAllAvailable
Behavior
Monitor
data(Vector zRef)? /
Behavior
BC
zRefFailure
Reference Absolute
zRefOK
db
dd
d2
d3
zref
¨zabs
¨zabs
Abbildung 3.10: Schema für die syntaktische Überprüfung bei der korrekten Einbettung
und korrekten Rekonfiguration
betrachten und alle Kombinationen von mode zu betrachten um diese inkorrekten Zu-
standskonfigurationen auszuschließen.
3.2.4 Grenzen des Ansatzes
Der hier vorgestellte Ansatz erlaubt die systematische Entwicklung von mechatronischen
Systemen mit sicheren Rekonfigurationseigenschaften, bei denen eine strikte Hierarchie
mit einer top-down Rekonfiguration zugrunde liegt. Jedoch zeigt dieser Ansatz eine Reihe
von Einschränkungen, welche oftmals bei komplexen mechatronischen Systemen so nicht
mehr angenommen werden können.
Eine Haupteinschränkung ist, dass in einem Interface Statechart nur die Dauer einer Tran-
sition und nicht deren Ausführungszeitpunkt spezifiziert werden kann. Beispiele hierfür
sind Interface Statecharts, bei denen z.B. die Frequenz zwischen Rekonfigurationen mo-
delliert werden soll. In dem hier vorliegenden Beispiel könnte durch die Domäne der Re-
69
Kapitel 3 Verifikation eines OCM
gelungstechnik vorgegeben werden, um die Stabilität des Systems zu beeinflussen, dass
nach dem Umschalten von Zustand Reference zu Zustand Absolute eine Zeitspanne ver-
streichen muss, bevor die BC Komponente es erlaubt, zurück zu dem komfortableren
Reference Zustand erneut zu wechseln.
Eine weitere Restriktion ist die strikte top-down Rekonfiguration. Wenn z.B. ein Sensor
bereits einen Fehler feststellt, muss dieser in den Unterkomponenten behandelt werden.
Der bisherige Ansatz von Interface Statecharts erlaubt dies nicht. Um also auch War-
nungen, Fehler oder ähnliche Signale zu den eingebetteten Komponenten zu propagieren,
müssen die Interface Statecharts um entsprechendes proaktives Verhalten [Woo00][Ge05]
angereichert werden, so dass das Interface Statechart aufgrund dieser Ereignisse entspre-
chende Reaktionen innerhalb einer Zeitspanne anstoßen kann.
Als Beispiel hierfür kann der Fall betrachtet werden, dass die BC Komponente bemerkt,
dass die Referenzdaten ein unerwartetes Problem hervorrufen und dieses an die Monitor
Komponenten propagieren möchte. Dieses kann ebenfalls für das Interface Statechart für
die BC Komponente bedeuten, dass hier eine Deadline spezifiziert werden muss, um den
Zustand Reference zu verlassen um zu einen sicheren Zustand zu wechseln.
Formal kann man diese beiden Fälle wie folgt definieren, um die Interface Automaten zu
erweitern:
Definition 20
Ein Interface Automat Mist komplex, falls es nicht mehr simple, aber immer noch deter-
ministisch ist. Ein Interface Automat Mist proaktiv, falls es autonom entscheiden kann,
dass eine Rekonfiguration erforderlich ist.
3.3 Modellierung hierarchischer Rekonfiguration
bedingt durch proaktives Verhalten
In diesem Abschnitt wird ein Beispiel für die Modellierung von hybriden Systemen mit
proaktivem Verhalten gegeben. Hierzu wird das Beispiel aus Abschnitt 3.1 erweitert. Als
erstes wird das neue Verhalten informal beschrieben. Danach werden die Auswirkungen
des neuen Verhaltens auf das gesamte System beschrieben.
3.3.1 Erweitertes Beispiel
In Abschnitt 3.1 wurde das Feder-Neige Modul beschrieben und die Software modelliert.
Eine Besonderheit der Modellierung war hier die strikte top-down Hierarchie. So war es
für die BC Komponente nicht möglich, die Monitor Komponente direkt über Signale zu
70
3.3 Modellierung hierarchischer Rekonfiguration bedingt durch proaktives Verhalten
beeinflussen. Wenn z.B. ein Fehler in der BC Komponente passiert, während die Kompo-
nente im Reference Zustand ist, muss die BC direkt zum Robust wechseln und gleichzei-
tig die übergeordnete Monitor Komponente informieren, um entsprechend zu reagieren.
Ebenfalls soll ein zu schnelles Hin- und Herschalten vermieden werden, um Stabilitätsei-
genschaften zwischen den Zuständen Absolute und Reference sicherzustellen.
3.3.2 Verhalten der Komponente
In Abbildung 3.11 ist das erweiterte Verhalten der BC Komponente dargestellt. Das Ver-
halten der alten BC Komponente ist nun um proaktives Verhalten erweitert worden. Be-
findet sich die BC Komponente in dem Zustand Reference, kann die Komponente nun
autonom entscheiden, in den Zustand Robust zu wechseln. Dies ist durch eine non-urgent
Transition (gestrichelte Linie), die Nicht-Determinismus modelliert, beschrieben. Im De-
tail ist dies wie folgt modelliert: Solange der Zustand Reference aktiv ist, sendet die BC
Komponente eine Nachricht switchToRobust zu der übergeordneten Monitor Komponente.
Nach Verschicken wechselt die BC Komponente in den Zustand Timeout Zustand. Ist der
Timeout erreicht, wechselt die BC Komponente in den Robust Zustand.
zRefFailure
zAbsFailure
zAbsOK
Robust
Absolute
zAbsFailure
zAbsOK
<Abs>
<Ref>
<Rob>
zRefOK
Reference(Main)
Timeout
Reference
/ switchToRobust
d4
ffade1
¨zabs
¨zabs
zref
d1
ffade4
ffade3
d3
t:= 0
t:= threshold
timer == 50
timer := 0
ffade2
d2
t≥threshold
Abbildung 3.11: Verhalten der BC Komponente
Um das Schaltverhalten zwischen Absolute und Reference zu kontrollieren, wird ein Ti-
mer tverwendet. Jedesmal, wenn der Reference ausgehend vom Zustand Absolute be-
treten wird, wird die Uhr tauf den Wert 0gesetzt. Um ein sofortiges Zurückspringen
71
Kapitel 3 Verifikation eines OCM
und somit Instabilität zu vermeiden, wird eine Bedingung (Schwellwert) t>=threshold
der Transition hinzugefügt. Alle anderen eingehenden Transitionen zum Reference Zu-
stand bekommen als Zuweisung t:=threshold, was bedingt, dass der Schwellwert nicht
berücksichtigt wird.
In Abbildung 3.12 ist das Interface Statechart der sensor Komponente dargestellt. Das
Interface Statechart besteht aus zwei Zuständen, on und off.
/ failure/ ok
On
Off
Abbildung 3.12: Interface Statechart der Komponente Sensor
3.3.3 Einbettung
Das erweiterte Verhalten der Monitor Komponente (ähnlich Abbildung 3.7) ist in Abbil-
dung 3.13 dargestellt. Zusätzlich zum alten Verhalten der Monitor Komponente müssen
nun das proaktive Verhalten und die Zeitangaben der eingebetteten Komponenten berück-
sichtigt werden. In diesem Fall muss das von der BC Komponente verschickte Signal
switchToRobust entsprechend verarbeitet werden.
3.4 Verifikation der hierarchischen Rekonfiguration
bedingt durch proaktives Verhalten
Um das Modularitätskonzept, wie im letzten Abschnitt beschrieben, für die Erweiterung
der Interface Automaten anwenden zu können, müssen die Überprüfungen für die Ver-
feinerung sowie für die korrekte Einbettung erweitert werden. Die Erweiterungen werden
im Folgenden beschrieben.
72
3.4 Verifikation der hierarchischen Rekonfiguration bedingt durch proaktives Verhalten
:BC[Robust]
storage:Storage
:Sensor[On]:BC[Reference]
:Sensor[Off]:BC[Robust]
:Sensor[On]:BC[Absolute]
:Sensor[Off]
registry.sendInfo(zRef) / storage.add(zRef)
when(storage.isEmpty())
Trajectory
Available
/ registry.experience
data(Vector zRef)!
!storage.isEmpty())
when(
when(nextSegment)
data(Vector zRef)? /
RefAvailable NoneAvailable
sensor.failure
sensor.ok
data(Vector zRef)?
noData?
AbsAvailable
registry.experience
noData! /
after(20) /
registry.requestInfo
TrajectoryNot
Available
sensor.ok
bc.switchToRobust
when(nextSegment)
data(Vector zRef)? /
AllAvailable
when(next
sensor.failure
Segment)
noData? /
when(nextSegment)
data(Vector zRef)?







Abbildung 3.13: Einbettung von Verhalten in die Monitor Komponente
3.4.1 Überprüfung der Verfeinerung
Komplexe und proaktive Komponenten können nicht auf ein simples Interface Statechart
abgebildet werden (siehe Definition 20). Deshalb können die bisher beschriebenen Ver-
fahren zur Überprüfung, dass das Verhalten eines Interface Statecharts dem Verhalten
einer Komponente entspricht (siehe Abschnitt 3.2), so nicht angewendet werden.
In [JGGS00] (siehe Verwandte Arbeiten 6.1.2) wird ein Ansatz vorgestellt, der die Ver-
feinerung MvRT MIüberprüft. Jedoch wird hier gefordert, dass MIdeterministisch ist.
Falls das Interface Statechart MIkomplex ist, jedoch nicht proaktiv, kann dieser Ansatz
verwendet werden. For einen deterministischen Automaten MIerhält man den entspre-
chenden Test Automaten MI
twie in [JGGS00] beschrieben und kann entsprechend MkMI
t
auf time stopping deadlocks überprüfen.
Für den Fall, dass das Interface Statechart MIproaktiv ist und deshalb nicht-
deterministisch, lässt sich das Verfahren aus [JGGS00] nicht anwenden. Um hier
73
Kapitel 3 Verifikation eines OCM
einen deterministischen Automaten für einen nicht-deterministischen zu erhalten, lassen
sich ähnliche Verfahren, wie in [Tri04] beschrieben, anwenden. Bei genauerer Betrach-
tung des Ansatzes [JGGS00] stellt man fest, dass bei der on-the-fly Bestimmung des
Kreuzproduktes einfach eine eindeutige Abbildung von einem Zustand in das verfeinerte
Modell existieren muss, die in [JGGS00] durch die deterministischen Eigenschaften von
MIgarantiert wird.
Der hier vorgeschlagene Ansatz nutzt die Abbildung map :LI
p→Lzwischen den pas-
siven Zuständen des Interface Automaten und den zugehörigen Zuständen in der Reali-
sierung aus, um eine geeignete Lösung vorzuschlagen. Für die Abbildung map, die je-
dem Zustand in der Realisierung genau einen Zustand des Interface Automaten zuord-
net (∀l∈L:|{l0|l0∈map(l)}| = 1 und deshalb ist map−1eine Funktion so dass
l0=map−1(l)) und für den Fall, dass keine zwei Transitionen mit der selben Quelle, Mar-
kierung und Ziellocation existieren (∀l, l0∈L, s ⊆I∪O:|{(l, g, S, R, l0)∈T}| ≤ 1),
kann das Kreuzprodukt syntaktisch erstellt werden M0=MI×map Mmit M0=
(L0, D0, I0, O0, T0, S00),MI= (LI, DI, II, OI, TI, SI,0)und M= (L, D, I, O, T, S0)
und LI
fund Lfsind Umschaltzustände von LIoder Lwie folgt:
•L0={(l, l0)∈LI×L} ∪ error,
•D0(l, l0) = DI(l)kD(l0)und D0(error)sind leer,
•I0=II∪I,O0=OI∪O.
•T0=S(l,l0)∈L0\{error},S⊆I0∪O0T0
l,l0,S mit T0
l,l0,S =T0r
l,l0,S ∪T0e1
l,l0,S ∪T0e2
l,l0,S ist die Verei-
nigung der zugehörigen normalen nund fehlerhaften Transitionsmengen (e1,e2).
•S00=S0I×S0
Die Menge der normalen Transitionen T0n
l,l0,S bildet sich durch alle Paare von Tran-
sitionen die durch eine Übereinstimmung sin der Menge {((l, l0), g ∧g0, S, R ∪
R0,(l00, l000))|(l, g, S, R, l00)∈TI∧(l0, g0, S, R0, l000)∈T∧l0=map−1(l)}landen.
Die initiale Menge von fehlerhaften Transitionen T0e1
l,l0,S für l6∈ LI
foder l06∈ Lfbehandelt
das Verhalten, bei dem das Interface Statechart schalten kann, aber nicht die Realisierung:
T0e1
l,l0,S ={((l, l0), g ∧ ¬g00, S, ∅,error)|(l, g, S, R, l00)∈TI∧g00 =W(l0,g0,S,R0,l000 )∈Tg0}.
Analog wird die nächste Menge von fehlerhaften Transitionen bestimmt T0e2
l,l0,S
für l6∈ LI
for l06∈ Lfwobei das Verhalten betrachtet wird, das in der
Realisierung schalten kann, jedoch nicht im Interface Statechart: T0e2
l,l0,S =
{((l, l0), g0∧ ¬g00, S, ∅,error)|(l0, g0, S, R0, l000)∈T∧g00 =W(l,g,S,R,l00 )∈TIg}.
Für l∈LI
fund l06∈ Lfim Gegensatz kann angenommen werden, dass die Bedingungen
einer Transition immer die Form a0≤t≤b0haben. Deshalb ist T0e1
l,l0,S gleich {((l, l0), a ≤
t≤aI, S, ∅,error)|(l, aI≤t≤bI, S, R, l00)∈TI∧(l, a ≤t≤b, S, R, l00)∈T}und
74
3.4 Verifikation der hierarchischen Rekonfiguration bedingt durch proaktives Verhalten
T0e2
l,l0,S ist gleich {((l, l0), bI≤t≤b, S, ∅,error)|(l, aI≤t≤bI, S, R, l00)∈TI∧(l, a ≤
t≤b, S, R, l00)∈T}um inkompatible Zeitbedingungen darzustellen. Im ersten Fall wird
eine zu frühe Terminierung des Umschaltvorgangs überprüft, im zweiten Fall wird eine
zu späte Terminierung überprüft.
Danach kann einfach überprüft werden, ob ein time stopping deadlock besteht oder
der Zustand error in M0erreicht wird. Daraus lässt sich schließen, ob die Verfeine-
rung gilt oder verletzt ist. Aufgrund der Einschränkung, dass niemals zwei Transitionen
mit derselben Quelle, Markierung und Ziellocation in TIexistieren, gilt, dass für jede
t0= (l0, g0, S, R0, l000)∈Tmindestens eine zugehörige Transition t= (l, g, S, R, l00)∈TI
existiert, die in T0n
l,l0,S ist und die Eigenschaft l0=map−1(l)erfüllt.
Eine Abbildung map, die jedem realisierten Zustand mehr als einen Zustand des Inter-
face Automaten zuweist, resultiert nicht in der beabsichtigten Zustandsraumreduzierung
für MIbezüglich Mund deshalb ist diese Restriktion anwendbar für die hier verwendete
Idee. Im Falle, dass zwei Transitionen (l, g, S, R, l0)∈TIund (l, g0, S, R0, l0)∈TImit
derselben Start- und Ziellocation sowie Markierung existieren, müssen zwei Fälle unter-
schieden werden. (1) Falls R=R0können diese einfach vereint werden in einer Regel
(l, g∨g0, S, R, l0)ohne Verhaltensänderung. (2) Andernfalls muss ein zusätzlicher Zustand
l00 und eine zusätzliche Uhr hinzugefügt werden und die erste Regel (l, g, S, R, l0)∈TI
durch die folgenden beiden Regeln ersetzen: (l, g, S, R∪{t}, l00)und (l00,true,∅,∅, l0)und
die Angabe der Invarianten C(l00)mit t≤0um die Annahme zu erfüllen.
Um zu überprüfen, dass der hybride Rekonfigurations Automat von der Komponente BC
eine korrekte Verfeinerung des Interface Statecharts der BC Komponente ist, muss ein
Timed Automata Modell wie oben beschrieben, erstellt werden. Auf diesem Modell kann
dann mittels Model Checking durch den Model Checker UPPAAL [BDL04] die korrekte
Verfeinerung verifiziert werden. Hierzu muss die Eigenschaft A[] not deadlock sowie E<>
BodyControl.Error überprüft werden.
3.4.2 Dynamische Überprüfung der Einbettung
Die dynamische Überprüfung der korrekten Einbettung der Komponenteninstanzen hat
das gleiche Ziel wie die syntaktische Überprüfung. Sie berücksichtigt - im Gegensatz zur
syntaktischen Überprüfung - auch komplexeres Zeitverhalten, das z.B. durch Timeguards
ausgedrückt wird. Die dynamische Überprüfung ist damit für nicht simple, proaktive In-
terface Statecharts geeignet.
In Abbildung 3.14 sind ein Echtzeitsystem und ein hybrides System exemplarisch dar-
gestellt. Die Verifikation des Echtzeitverhaltens jeder einzelnen Komponente wird mit
Hilfe von Model Checking realisiert. Um zu überprüfen, ob die Rekonfiguration nicht zu
Inkonsistenzen führt, müssen weitere Verifikationsschritte durchgeführt werden. Verlässt
75
Kapitel 3 Verifikation eines OCM
bzw. betritt die übergeordnete Komponente ihren Zustand, müssen zeitgleich die einge-
betteten Komponenteninstanzen ihren internen Zustand verlassen bzw. betreten. Dies ist
jedoch nur möglich, wenn sich die spezifizierten Echtzeitangaben, wie Deadlines, Time-
guards und Uhren-Resets nicht gegenseitig ausschließen. Dies wird mittels der dynami-
schen Überprüfung verifiziert.
refAvailable
sensorB.ok
noneAvailable
allAvailable
absAvailable
sensorB.failure
sensorB.ok
sensorB.failure
sensorA.failure
sensorA.ok
sensorA.failure
sensorA.ok
refAvailable
sensorB.ok
noneAvailable
allAvailable
absAvailable
sensorB.failure
sensorB.ok
sensorB.failure
sensorA.failure
sensorA.ok
sensorA.failure
sensorA.ok
refAvailable
sensorB.ok
noneAvailable
allAvailable
absAvailable
sensorB.failure
sensorB.ok
sensorB.failure
sensorA.failure
sensorA.ok
sensorA.failure
sensorA.ok
refAvailable
sensorB.ok
noneAvailable
allAvailable
absAvailable
sensorB.failure
sensorB.ok
sensorB.failure
sensorA.failure
sensorA.ok
sensorA.failure
sensorA.ok
...
Echtzeit - Model Checking
Hybrides Rekonfigurationschart
der übergeordneten Komponente
Interface Statechart der
eingebetteten Komponenteninstanz
Interface Statechart der
eingebetteten Komponenteninstanz
Synchronisierung Synchronisierung Synchronisierung
...
Abbildung 3.14: Dynamische Überprüfung der korrekten Einbettung der
Komponenteninstanzen
Um zu verifizieren, ob eine Komponente korrekt in eine weitere Komponente eingebettet
ist, darf sich das Echtzeitverhalten beider Komponenten nicht gegenseitig ausschließen.
Dies ist der Fall, wenn das spezifizierte Echtzeitverhalten des gesamten Systems keinen
Deadlock enthält. Eine Überprüfung auf Deadlockfreiheit kann erfolgen, wenn das hybri-
de Rekonfigurationschart der übergeordneten Komponente und die Interface Statecharts
der eingebetteten Komponenteninstanzen parallel initialisiert werden und das Verfahren
des Model Checkings mit der Bedingung A[] not deadlock angewandt wird.
Um die dynamische Überprüfung für die korrekte Rekonfiguration zu realisieren, müssen
sowohl das hybride Rekonfigurations Chart sowie das Interface Statechart in ein geeigne-
tes Eingabemodell für einen Model Checker transformiert werden. In [Hir04][BGHS04]
wurde eine Transformation, die Realtime Statecharts auf Timed Automata abbildet, for-
mal beschrieben. Im Folgenden werden diese Transformationsregeln wiederverwendet
und erweitert.
In hybriden Rekonfigurations Charts sind Komponenteninstanzen in Zustände eingebettet.
Während der Transformation können die eingebetteten Instanzen vernachlässigt werden,
da diese durch das Interface Statechart, welches ebenfalls transformiert wird, abgedeckt
76
3.5 Evaluierung
werden. Aufgrund dieser Tatsache können für die Zustände genau dieselben Regeln wie
in [Hir04][BGHS04] angewendet werden.
Neben den Zuständen müssen auch noch die Transitionen abgebildet werden. Im Gegen-
satz zu der Transformation in [Hir04][BGHS04] ist hier eine Transition mit einer Um-
schaltfunktion markiert. Da die Umschaltfunktion jedoch nicht das Echtzeitverhalten be-
einflusst, kann sie ebenfalls vernachlässigt werden. So kann auch hier die Transformation
aus [BGHS04] verwendet werden.
Bei der Modellierung des hybriden Rekonfiguration Charts der übergeordneten Kompo-
nente wird explizit angenommen, dass die eingebetteten Komponenteninstanzen ihren in-
ternen Zustand zeitgleich mit dem Zustand der übergeordneten Komponente verlassen
bzw. betreten. Da die Aktivierung der Transitionen und der Schaltvorgang innerhalb der-
selben Perioden stattfinden, wird bei der Ausführung des Systems das zeitgleiche Ver-
lassen und Betreten von Zuständen erzwungen. Verlässt zum Beispiel die Komponente
Monitor den Zustand NoneAvailable, muss die eingebettete Komponenteninstanz BC den
internen Zustand Robust verlassen.
Um das zeitgleiche Verlassen und Betreten von Zuständen auch beim Model Checking zu
realisieren, ist eine Synchronisierung der Schaltvorgänge notwendig. Die Synchronisie-
rung kann mit Hilfe von Synchronisationskanälen umgesetzt werden. Die übergeordnete
Komponente ist dabei Sender, während die eingebetteten Komponenteninstanzen Emp-
fänger sind. Die Synchronisierung muss genau dann erfolgen, wenn ein Zustand verlas-
sen und betreten wird. Da hybride Rekonfiguration Charts und Interface Statecharts sowie
auch Realtime Statecharts diese Möglichkeit nicht bieten, muss eine Transformation der
Modelle erfolgen. Im Fall, dass mehrere eingebettete Komponenteninstanzen reagieren
müssen, kann eine Kette von committed locations (siehe [BDL04]) verwendet werden. In
Abbildung 3.15 ist ein Ausschnitt aus dem Mapping dargestellt.
3.5 Evaluierung
In [Kud05] wurden die Funktionalitäten zur Modellierung und die Verifikation der rein
syntaktischen Verifikationsverfahren aus [GBSO04] in der Fujaba Realtime Tool Suite1
implementiert. Der in diesem Kapitel vorgestellte Ansatz wurde anhand des eingeführten
Beispiel des Feder-Neige-Moduls evaluiert. Für die Evaluierung wurde der Model Che-
cker UPPAAL [BDL04] verwendet, da dieser bereits in der Fujaba Realtime Tool Suite
integriert wurde [Hir04][BGH+05b].
In Abbildung 3.16 und 3.18 sind die transformierten Timed Automata der Interface
Statecharts BodyControl und des Rekonfigurations Charts Monitor, wie sie von UPPAAL
1http://www.fujaba.de/realtime
77
Kapitel 3 Verifikation eines OCM
SensorBodyControlMonitor













  
!
"#"
$&%
')(+*,.-0/1*325476981:

&;


$
')(<*&,.-0/=*3>+?A@

&


')(<*&,.-0/=*3B54CED
F7G
!IH
J
K L$

')(+*,.-0/1*3B5@

M;
N

$
IO

PMJ
')(+*,.-0/1*3B54QCED
R
P

PM$
')(<*,.-S/=*3254Q6T80:

&;
N
 
O
RU
P
')(<*,.-S/=*3>+?A@
VXWYV

O
VNW
VNWZV
V
')(<*,.-S/=*3>+?A@
VNWZV
G
O
VNWZV
G
VNWYV
[\ 
!
"#"
\$%
J
]"
&%J^
J
J"
%MJ`_
Abbildung 3.15: Synchronisation zwischen Monitor,Sensor und BodyControl
als Eingabe verwendet werden, dargestellt. Der Timed Automaton des Sensors ist in Ab-
bildung 3.17 dargestellt. Für die Verifikation wurde die parallele Ausführung betrachtet
und die Eigenschaft A[] not deadlock überprüft Das Ergebnis der Verifikation war, dass
Robust
t_intern<=50
Absolutet_intern<=0
t_intern<=50
Reference
t_intern<=50
t_intern<=50
Timeout
timer<=50
NoneAvailableAbsAvailable_exit?
t_intern:=0
AbsAvailableNoneAvailable_entry?
t_intern>=20
NoneAvailableAbsAvailable_entry?
AbsAvailableNoneAvailable_exit?
t_intern:=0
RefAvailableAllAvailable_exit?
t_intern:=0
AllAvailableRefAvailable_entry?
t>=threshold
AllAvailableAbsAvailable_exit?
t_intern:=0
t_intern>=20
AllAvailableAbsAvailable_entry?
AbsAvailableAllAvailable_exit?
t_intern:=0
t_intern>=20
AbsAvailableAllAvailable_entry?AllAvailableRefAvailable_exit?
t_intern:=0
t_intern>=20
RefAvailableAllAvailable_entry?
t:=threshold
bc_switchToRobust!
timer:=0
switchNotPossible?
timer==50
Abbildung 3.16: Timed Automaton des Interface Statecharts der BC Komponente
On Off
AllAvailableRefAvailable_exit?
t_intern=0 AllAvailableRefAvailable_entry?
NoneAvailableAbsAvailable_exit?
t_intern:=0
NoneAvailableAbsAvailable_entry?
AbsAvailableNoneAvailable_exit?
t_intern:=0
AbsAvailableNoneAvailable_entry?
RefAvailableAllAvailable_exit?
t_intern:=0
RefAvailableAllAvailable_entry?
reinit?
Abbildung 3.17: Timed Automaton des Interface Statecharts der Sensor Komponente
78
3.6 Zusammenfassung
t_intern<=50 t_intern<=50 t_intern<=0
NoneAvailableRefAvailable
t_intern<=50
AbsAvailable
t_intern<=50
AllAvailable
timer<=51
NoneAvailableAbsAvailable_entry!
NoneAvailableAbsAvailable_entry!
t_intern>=20
NoneAvailableAbsAvailable_exit!
NoneAvailableAbsAvailable_exit!
t_intern:=0
AllAvailableRefAvailable_entry!
t_intern>=20
AllAvailableRefAvailable_entry!
AllAvailableRefAvailable_exit!
AllAvailableRefAvailable_exit!
t_intern:=0
RefAvailableAllAvailable_entry!
RefAvailableAllAvailable_entry!
t_intern>=20
RefAvailableAllAvailable_exit!
RefAvailableAllAvailable_exit!
t_intern:=0
AbsAvailableNoneAvailable_entry!
AbsAvailableNoneAvailable_entry!
AbsAvailableNoneAvailable_exit!
AbsAvailableNoneAvailable_exit!
t_intern:=0
timer:=0
AbsAvailableAllAvailable_entry!
t_intern>=20
AbsAvailableAllAvailable_exit!
t_intern:=0
AllAvailableAbsAvailable_entry!
AllAvailableAbsAvailable_exit!
reinit!
timer==51
bc_switchToRobust?
timer:=0
Abbildung 3.18: Timed Automaton des Monitor Verhaltens
das System deadlock frei ist. Daraus ergibt sich, dass die Einbettung aller Komponenten
korrekt ist. Die Verifikation hat ca. 0.31 Sekunden bei einem Speicherverbrauch von 2092
KB benötigt.2.
3.6 Zusammenfassung
In diesem Kapitel wurde beschrieben, wie sich ein OCM verifizieren lässt. Dabei wur-
de ein bereits vorhandener Ansatz [GBSO04] zur Verifikation der Rekonfiguration von
MECHATRONIC UML Modellen erweitert, der durch zahlreiche Einschränkungen in der
Ausdrucksstärke für die Interface Statecharts für die komplexen mechatronischen Syste-
me nicht anwendbar war. Der neue Ansatz erlaubt nun auch die Modellierung und Veri-
fikation von komplexen Zeitbedingungen (nicht lokale Zeitbedingungen) und proaktivem
Verhalten. Die Konzepte wurden formal definiert und eine experimentelle Evaluierung hat
die Ergebnisse bestätigt.
2Wurde auf einem Pentium 4, 2.4 GHz, 1 GB memory, OS Linux Redhat durchgeführt.
79
Kapitel 3 Verifikation eines OCM
80
Kapitel 4
Verifikation des Verhaltens eines
OCM in der Umwelt
Im vorangegangenen Kapitel wurde beschrieben, wie sich ein einzelnes OCM model-
liert durch statische Konstrukte hinsichtlich Sicherheitseigenschaften verifizieren lässt.
In komplexen, vernetzten mechatronischen Systemen stehen allerdings nur begrenzte
Rechen- und Speicherkapazitäten zur Verfügung. Zusätzlich unterliegt das System zur
Laufzeit einer Evolution abhängig vom gegebenem Kontext bestimmt durch die Umwelt.
Anforderungen an komplexe, mechatronische Systeme sehen deshalb Dynamik vor, d.h.
Steuerungssoftware muss zu Laufzeit ausgetauscht werden können. In Schilling [Sch06]
wurde bereits beschrieben, wie Graphtransformationssysteme zur Beschreibung von dy-
namischen Veränderungen im Kontext von mechatronischen Systemen eingesetzt werden
können. So wurde das in Abbildung 4.1 dargestellte Szenario auf der Basis von Graph-
transformationssystemen beschrieben. Die obere Hälfte des Bildes zeigt einen aktuellen
Systemzustand. Hier fahren zwei Shuttles hintereinander auf zwei verschiedenen Stre-
ckenabschnitten. Dabei wird die Diskretisierung vorgenommen, dass ein Shuttle immer
genau auf einem Streckenabschnitt steht. Die untere Hälfte des Bildes zeigt die koordi-
nierte Bewegung des Shuttles auf den Streckenabschnitten, modelliert durch eine graph-
basierte Regel. Hier wird beschrieben, welche Objekte existieren und wie miteinander
verbunden sind. Im vorliegenden Beispiel existiert eine Instanz des DistanceCoordina-
tionPattern, welches die Verhaltenskoordination zweier verbundener Shuttles realisiert.
4.1 Grenzen des bisherigen Ansatzes
Der von Schilling vorgeschlagene Ansatz [Sch06] zeigt eine Schwäche in der Model-
lierung und Verifikation auf: es wird keine Zeit berücksichtigt. Daraus ergeben sich die
folgenden zwei Probleme:
81
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
s1:Shuttle
t1:Track
at
:Track
next :Track
go
next
at
s2:Shuttle
dc1:DistanceCoordinationPattern
front
rear
go
<<create>>
Regel:
Shuttle Shuttle
Systemzustand:
Abbildung 4.1: Beispiel für ein Graphtransformationssystem
Instanziierungsdauer von Echtzeit-Koordinationsmustern: Es ist nicht mög-
lich, die Instanziierungsdauer eines Echtzeit-Koordinationsmusters zu beschreiben. In
Abbildung 4.1 ist durch die Regel lediglich beschrieben, dass zwei aufeinander folgende
Shuttles das DistanceCoordinationPattern instanziieren müssen. Im Detail aber bedeutet
die Instanziierung eines Echtzeit-Koordinationsmusters das Aktivieren und Deaktivieren
von Softwarekomponenten, welches, ähnlich wie das Umschalten zwischen Reglern, Zeit
benötigt. Neben diesem Zeitaspekt muss auch das aktuelle kontinuierliche Verhalten, wie
z.B. die Geschwindigkeit, des Shuttles berücksichtigt werden. Es ist offensichtlich, dass
ein Shuttle, das 160km
hfährt, ebenfalls rechtzeitig die Aktivierung und Deaktivierung von
Softwarekomponenten vornehmen können muss wie ein Shuttle, das nur 40km
hfährt. D.h.
die Abhängigkeit zwischen der Dauer der Instanziierung einer Softwarekomponente zur
aktuellen Geschwindigkeit muss ebenfalls berücksichtigt werden.
Beschreibung von kontinuierlichen Bewegungen: Bei der in Abbildung 4.2
dargestellten Situation bewegt sich ein Shuttle über aufeinander folgende Streckenab-
schnitte. Hierbei entspricht die Größe eines Streckenabschnitts nun nicht mehr genau der
Größe eines Shuttles, sondern kann beliebig endlich lang sein, um das Modell realitätsge-
treu abzubilden. Falls nun aber mehrere Shuttles hintereinander in die gleiche Richtung
fahren, wäre es möglich, dass diese kollidieren, da sich die Position der Shuttles nicht
diskret bestimmen lässt.
82
4.1 Grenzen des bisherigen Ansatzes
Um eine derartige Situation im Modell auszuschließen, bestünde eine Möglichkeit dar-
in, dafür zu sorgen, dass alle Shuttles mit der gleichen Geschwindigkeit die Streckenab-
schnitte passieren. Wenn es im zugrunde liegenden Modell also möglich ist, Aussagen
über die Zeit zu formulieren, so kann über den Zusammenhang, dass sich die Geschwin-
digkeit aus der Strecke pro Zeit ermitteln lässt, hiermit auch die Eigenschaft, dass die
Shuttles alle die gleiche Geschwindigkeit fahren, formuliert werden. Hiermit ist im Bei-
spiel eine derartige Kollision ausgeschlossen. Um diese Eigenschaften umzusetzen ist die
Idee, die Regeln mit Zeitbedingungen zu versehen sowie Zeitinvarianten für Graphsitua-
tionen zu beschreiben, um kontinuierliche Zeitvorgänge zu modellieren. In Abbildung 4.2
ist die entsprechende Regel mit Zeitbedingung (unten links) sowie die Invariante (unten
rechts) für die Fortbewegung eines Shuttles modelliert.
:Shuttle
:Track
at
<<destroy>>
:Track
next
at
<<create>>
Zeitbehaftete Regel
:Shuttle
:Track
t < 6
Clock : t
Clock : t
t >= 5
Invarianten Regel
RailCab
Shuttle
Abbildung 4.2: Beispiel für ein zeitbehaftetes Graphtransformationssystem
Um eine derartige Situation zu modellieren ist es möglich, auch auf andere Modellarten
zurück zu greifen. So könnte etwa ein Konvoi durch Timed Automata oder Petrinetze
abgebildet werden, bei welchem die Eigenschaft berücksichtigt wird, dass alle Shuttles
die gleiche Geschwindigkeit fahren. Allerdings verfügen diese Modelle nicht direkt über
eine dynamische Struktur, was es schwierig macht, ein entsprechendes Modell für eine
beliebige Anzahl an Shuttles zu erstellen und den zur Laufzeit benötigten Austausch von
Softwarekomponenten zu modellieren.
83
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
Im Folgenden werden nun zuerst die Erweiterungen hinsichtlich der Modellierung in Ab-
schnitt 4.2 beschrieben und anschließend in Abschnitt 4.3 formalisiert. Die Verifikation
des Verhaltens von OCMs in der Umwelt wird in Abschnitt 4.4 beschrieben.
4.2 Modellierung
In diesem Abschnitt wird beschrieben, in welcher Art und Weise Graphtransformations-
systeme erweitert werden, um zeitliche Bestandteile in das bestehende Modell zu integrie-
ren. Als erstes wird das Shuttlebeispiel aufgegriffen, anhand dessen die neuen Konzepte
durchgängig erklärt werden. Ein Vergleich der Modelle der Graphtransformationssysteme
und der Timed Automata zeigt Gemeinsamkeiten und Probleme auf, die sich durch die
dynamische Struktur von Graphtransformationssystemen ergeben und darauf, wie diese
Eigenschaften Einfluss auf die Modellierung von Zeit haben. Die hier gewonnenen Er-
kenntnisse gehen in die Erweiterungen für die Definition eines zeitbehaftetes Graphtrans-
formationssystem ein.
4.2.1 Beispiel
Als Beispiel für ein entsprechendes Modell, welches sowohl über eine dynamische Struk-
tur als auch über eine zeitliche Komponente verfügt, dient das in der Einleitung (siehe
Abschnitt 1.2) beschriebene Shuttlesystem. Dabei wird betrachtet, wie die Fortbewegung
eines Shuttles von Schienenabschnitt zu Schienenabschnitt modelliert werden kann.
Alle diese Komponenten werden im Modell berücksichtigt. Dabei wird die Darstel-
lung dieser Komponenten innerhalb des Beispiels in Form von speziellen UML-Klassen-
Diagrammen und UML-Objekt-Diagrammen vorgenommen. Die hierbei verwendete No-
tation orientiert sich an den von Zündorf [Zün01] vorgestellten Story-Pattern.
Die Bestandteile, z.B. einzelne Shuttle oder die Schienenabschnitte sind in Form von Kno-
ten beschrieben. Verbindungen oder Assoziationen zwischen den Knoten werden durch
gerichtete Kanten dargestellt. Eine solche Assoziation existiert z.B., wenn sich ein Shutt-
le auf einem Schienenabschnitt befindet. Dieses wird durch eine gerichtete Kante zwi-
schen den entsprechenden Knoten abgebildet. Die Abbildung 4.3 zeigt einen Ausschnitt
des Schienensystems mit Shuttlen. Zusätzlich zu den Strukturbeschreibungen sollen auch
zeitliche Abhängigkeiten und Eigenschaften im Modell berücksichtigt werden. Bei einem
realen System ist es wie bereits erwähnt entscheidend, wie lange ein Shuttle zum Über-
fahren eines Schienenabschnitts benötigt, um hierdurch die aktuelle Geschwindigkeit des
Shuttles zu modellieren.
84
4.2 Modellierung
shuttle1 : Shuttle
shuttle2 : Shuttle
track10 : Track track5 : Track
track9 : Track track8 : Track track7 : Track track6 : Track
track1 : Track track2 : Track track3 : Track track4 : Track
next > next > next >next > next >
< next
< next < next
< next < next
at >
at >
Abbildung 4.3: Das durch einen Graphen beschriebene Shuttlesystem
4.2.2 Zeit und Graphtransformationssysteme
In diesem Abschnitt wird beschrieben, wie Graphtransformationssysteme mit zeitlichen
Bedingungen modelliert werden können. Als Referenzmodell für die Beschreibung von
Echtzeit-Verhalten wird das Modell der Timed Automata (siehe Abschnitt 2.3.2) verwen-
det.
Es gibt grundsätzlich verschiedene Möglichkeiten, Zeit innerhalb eines Modells abzubil-
den, so etwa, wie bei [CGP00] beschrieben, in Form von diskreter oder kontinuierlicher
Echtzeit. Die in dieser Arbeit gewählte Form, wie sie bei den Graphtransformationssys-
temen ergänzt wird, orientiert sich an der Art wie sie auch beim Timed Automaton Ver-
wendung findet. Dort wird kontinuierliches Echtzeitverhalten modelliert. Hierzu werden,
wie in Kapitel 2.3.2 beschrieben, einzelne Clocks xi, xj:i, j ∈N+verwendet, die belie-
bige Werte aus den positiven reellen Zahlen annehmen können. Über diese Clocks werden
dann, wie beim Timed Automaton, einzelne Bedingungen in der Form xi−xj∼cfor-
muliert (siehe Definition 3, Abschnitt 2.3.2).
4.2.2.1 Vergleich: Timed Automaton - GTS
Anhand der Überführung eines Graphtransformationssystems in das entsprechende Mo-
dell eines Timed Automaton wird hier ein Vergleich beider Modelle beschrieben. Die
85
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
hierbei auftretenden Probleme geben Hinweise darauf, wie die einzelnen zeitlichen Be-
standteile des Timed Automaton angepasst werden müssen, um diese bei den Graph-
transformationssystemen zu berücksichtigen. Ziel ist es, anhand der Ergebnisse dieses
Vergleiches eine Lösung zu entwickeln, die es ermöglicht nach dem Vorbild des Timed
Automaton zeitliche Bestandteile bei den Graphtransformationssystemen zu ergänzen.
Bei diesen zu ergänzenden Bestandteilen handelt es sich um einzelne Clocks, Guards,
Clockresets sowie Invarianten.
Bei der Überführung steht dabei nicht im Vordergrund, ein möglichst optimales oder voll-
ständiges Verfahren zu entwickeln, vielmehr werden hierdurch Unterschiede zwischen
den beiden Modellen erarbeitet. Das in der Abbildung 4.4 dargestellte System wird nun
: Shuttle
track5 : Track
: Track : Track
<<create>>
next > next >
< next
at >
<<destroy>>
at >
Regel P1
: Shuttle
: Track : Track
next >
at >
Graph G1
: Shuttle
: Track : Track
next >
Graph G2
at >
Abbildung 4.4: Ein Beispiel für ein Graphtransformationssystem mit zwei Graphen G1,
G2und einer Graphtransformationsregel P1
in einen entsprechenden Automaten überführt (siehe Abbildung 4.5). Hierfür werden die
einzelnen Graphen G1und G2in zwei entsprechende Zustände s0und s1eines endlichen
Automaten überführt. Die Anwendung der Graphtransformationsregel P1wird durch eine
Transition p1zwischen diesen beiden Zuständen ausgedrückt.
Nachfolgend wird der Algorithmus 4.1 vorgestellt, der eine entsprechende Zuordnungs-
vorschrift für einen endlichen Automaten M(siehe Kapitel 2.3.1, Abbildung 2.9), mit
M:= (Σ,Q,∆,Q0)beschreibt. Als Ausgang dient ein Graphtransformationssystem
86
4.2 Modellierung
n1e2
n3
e3e1
n2
e2
n1n2
p1
S0S1
Abbildung 4.5: Ein dem Graphtransformationssystem in Abbildung 4.4 entsprechender
Automat
S:= (G,G0,P), mit Gder Menge der Zustände, G0der Menge der Startzustände und
Pder Menge der Graphtransformationsregeln:
Algorithmus 4.1 procedure M=transfer(S)
procedure M=transfer(S)
1: M:= (Σ,Q,∆,Q0)
2: Q,Q0,Σ,∆ = ∅
3: for all gi∈ G do
4: f(gi) = qi
5: Q=Q ∪ qi
6: end for
7: for all g0
i∈ G0do
8: q0
9: f(g0
i) = q0
i
10: Q0=Q0∪q0
11: end for
12: for all m:m:= gj×Pi×gkdo
13: ∆ = ∆ ∪(f(gj)×Pi×f(gk))
14: end for
Σbleibt bei dieser Abbildung leer, worauf nachfolgend noch eingegangen wird.
An dieser Stelle wird auf zwei der Eigenschaften eingegangen, die aufzeigen, weshalb
die Abbildung schwierig, bzw. unvollständig ist. Dabei handelt es sich zum einen um die
Kantenbeschriftungen, die bei den Modellen eine unterschiedliche Bedeutung haben, zum
anderen um den Zeitpunkt, zu dem eine Abbildung wie oben beschrieben vorgenommen
werden kann.
Bei endlichen Automaten hat die Kantenbeschriftungen Σeine andere Bedeutung als die
Transitionen über Graphtransformationsregeln innerhalb von Graphtransformationssys-
temen. Bei einem Automaten entspricht die Beschriftung einer möglichen Eingabe, bei
welcher der Automat seinen Zustand über die entsprechende Kante wechselt. So kann
etwa bei den Kanten des Beispielautomaten aus dem Kapitel 2.3.1, von dem Zustand s0
nach s1gewechselt werden, wenn die Eingabe aerfolgt. Bei Graphtransformationssys-
87
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
temen bezeichnet diese Beschriftung der Kante die Graphtransformation, welche ange-
wendet wird, um vom Wirtsgraphen zum Tochtergraphen zu gelangen. Dabei ist die Vor-
aussetzung für die entsprechende Transition keine Eingabe sondern eine Bedingung, die
im aktuellen Zustand zutreffen muss. Diese Bedingung ist, dass die linke Seite der jewei-
ligen Graphtransformationsregel im Wirtsgraphen auffindbar sein muss. Der Unterschied
liegt hier also darin, dass beim endlichen Automaten die Kanten mit der Eingabe be-
schriftet werden und bei den Graphtransformationssystemen mit dem Namen der Graph-
transformationsregel, über die zwischen den einzelnen Graphen gewechselt wird. Beim
Modell des Automaten wird diese Bedingung in Form einer Eingabe vorgegeben, wäh-
rend bei den Graphtransformationssystemen diese Bedingung einer Struktur entspricht,
deren Vorkommen bei der Analyse überprüft werden muss.
Ein weiterer Unterschied zwischen den beiden Modellen besteht darin, zu welchem Zeit-
punkt die Zustände und Transitionen festgelegt werden. Bei den Automaten geschieht
dies bereits bei der Aufstellung des Modells. Im Gegensatz dazu entstehen die Knoten und
Kanten des Graphtransformationssystems, mit Ausnahme der initialen Startzustände G0,
nicht bei der Erstellung des Modells. Das erstellte Modell eines Graphtransformations-
systems verfügt vor der Erreichbarkeitsanalyse nur über die initialen Graphen und eine
Anzahl an Graphtransformationsregeln. Um daraus den vollständigen Zustandsraum des
Graphtransformationssystems zu erzeugen, ist es notwendig, eine Erreichbarkeitsanalyse
durchzuführen. Vorher wäre es nicht möglich, nach dem oben beschriebenen Vorgehen ei-
ne Abbildung des Graphtransformationssystems auf einen Automaten vorzunehmen. Im
Gegensatz hierzu ist die gesamte Struktur eines Automaten bereits vollständig vorgege-
ben, sobald das Modell formuliert ist. Bei der dort durchgeführten Erreichbarkeitsanalyse
wird dann die Reihenfolge festgelegt, in der die einzelnen Zustände erreicht werden kön-
nen; die Struktur des endlichen Automaten wird hierdurch aber nicht verändert.
Die hier aufgezeigte Eigenschaft, dass die Struktur des endlichen Automaten fest vorge-
geben ist, lässt sich auf die einzelnen Locations bei dem erweiterten Modell des Timed
Automaton übertragen. Die hinzukommenden Bestandteile des Timed Automaton, wel-
che die zeitlichen Eigenschaften in Form von einzelnen Clocks und deren Bedingungen
repräsentieren, sind den fest vorgegebenen Strukturen des Modells des Automaten zu-
geordnet, wie in Abbildung 4.6 dargestellt. Dabei sind den einzelnen Locations die In-
varianten und den Kanten, bzw. Transitionen die Guards und Clock-Resets zugeordnet.
Die Clocks selbst existieren zu jedem Zeitpunkt und Zustand, in dem sich der Timed-
Automaton gerade befindet. Somit sind diese immer dem gesamten Modell des Timed
Automaton zugeordnet.
Im Folgenden werden Zuordnungsvorschriften der Clocks, Guards, Resets und Invarian-
ten beschrieben, die dem Modell der Graphtransformationssysteme die Clocks, Guards,
Resets und Invarianten zuordnen, ohne bereits alle erreichbaren Zustände zu kennen. Da-
bei wird zuerst grundlegend behandelt, wie eine Zuordnung von einzelnen zeitlichen Be-
standteilen, wie diese beim Timed Automaton vorhanden sind, im Fall der Graphtransfor-
88
4.2 Modellierung
a
b
x2≤2x2≤3
x1≤2
x2≥1x2:=0
x1:=0 x1≥2
Clocks: x1 ,x2
x2≤2
Die in Guards, Resets und Invarianten vorkommenden
Clocks werden dem gesamten Automaten zugeordnet
Invarianten werden
Locations zogeordnet
x2≥1x2:=0
Guards und Resets
werden Kanten
zugeordnet
Abbildung 4.6: Zuordnung der zeitlichen Bestandteile zu den festen Strukturen des
Timed Automaton.
mationssysteme vorgenommen wird. Hierbei gibt es verschiedene Aspekte, die betrach-
tet werden müssen, um eine solche Zuordnung zu ermöglichen. Allerdings ist neben der
Frage, wie dies im Modell technisch möglich ist, auch entscheidend für welchen Zweck
entsprechende Eigenschaften formulierbar sind.
Es wird hier mit einer bestimmten Eigenschaft von Graphtransformationssystemen gear-
beitet, nämlich, dass es bei diesen hauptsächlich um Strukturen geht, welche innerhalb
der initialen Graphen und den daraus resultierenden Folgegraphen vorhanden sind. Nach
diesen Strukturen wird eben durch die Graphtransformationsregeln gesucht. Diese Struk-
turen beschreiben Situationen und Zustände, bzw. einen Teil dieser, welche innerhalb des
aktuellen Graphen gelten.
Mit diesen Strukturen werden einzelne zeitliche Eigenschaften verbunden. Dies bedeutet,
dass Graphtransformationsregeln dahingehend erweitert werden, bzw. neue Regeln hin-
zukommen. Diese sollten in der Lage sein, durch ihre Anwendung zeitliche Eigenschaften
zu einem Graphtransformationssystem hinzuzufügen. Zunächst wird hier an einem Bei-
spiel darauf eingegangen, warum diese Lösung gewählt wurde und welche Eigenschaften
hierdurch modellierbar sind.
89
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
Als Eigenschaft soll formuliert werden, dass ein Shuttle mindestens 10 Zeiteinheiten zum
Überfahren eines Schienenabschnittes benötigt. Abbildung 4.7 zeigt diese Regel. Ent-
scheidend für die Information, wie lange das Shuttle auf dem Schienenabschnitt sein soll,
ist die mit einem Kreis markierte Struktur im Wirtsgraphen.
: Shuttle
track5 : Track
: Track : Track
<<create>>
next > next >
< next
at >
<<destroy>>
at >
: Shuttle
: Track : Track
next >
at >
Graph G1
: Shuttle
: Track : Track
next >
Graph G2
at >
c>10
Abbildung 4.7: Zuordnung einer Clock c zu einer Graphtransformationsregel
Um allerdings eine solche Bedingung formulieren zu können ist es notwendig über zu-
gehörige Clocks zu verfügen. Im Beispiel wird die Clock cbenötigt, um über diese die
Bedingung c > 10 formulieren zu können.
4.2.2.2 Clockinstanzen
Die benötigten Clocks stellen im Vergleich zum Timed Automaton eine Besonderheit dar,
denn bei Graphtransformationssystemen ergibt sich die Struktur erst bei der Erreichbar-
keitsanalyse. Ohne eine bereits vorgegebene Struktur ist es nicht möglich, alle Clocks fest-
zulegen, die innerhalb des Graphtransformationssystems benötigt werden. Warum dies
der Fall ist, wird nachfolgend an einem Beispiel illustriert. Dabei handelt es sich um den
Wirtsgraphen Gin Abbildung 4.8, bei welchem die dort abgebildete Regel an den zwei
markierten Stellen angewendet werden kann. Da es möglich ist, dass eine der beiden
Stellen im Wirtsgraphen bereits länger existiert als die andere, werden für die Berück-
sichtigung der zeitlichen Bedingungen c≥3auch entsprechend zwei einzelne Clocks
benötigt.
Um mehrere Clocks innerhalb eines Wirtsgraphen zu ermöglichen, werden von einer
Clock mehrere Instanzen erzeugt. Dabei wird der Name der jeweiligen Clock um die
IDs der einzelnen Knoten des Wirtsgraphen erweitert, auf welchen die Regel angewendet
wird. Entsprechend werden in dem Beispiel aus Abbildung 4.8 zwei Clocks cerzeugt, die
90
4.2 Modellierung
: Shuttle
track5 : Track
: Track : Track
<<create>>
next >
next >
< next
at >
<<destroy>>
at >
Shuttle Track
>
Graph G
>
c>10
Clock:c
Clock:c
clock : Shuttle
: Track
at >
Abgeleitete Regel für Clock c
Reset: c:=10
Track
Shuttle Track
>
ID:1
ID:6
ID:5
ID:4 ID:3
ID:2
ID:7
Shuttle Track
<<destroy>>
Clock:c Clock:c
Clock:c
c>=3
>
x:={c,{1,2},{5}} ; y:={c,{3,4},{7}}
Abbildung 4.8: Der Graph Gverfügt über zwei Stellen, bei denen die Graphtransfor-
mationsregel mit der zeitlichen Bedingung c≥3angewendet werden
kann.
sich hinsichtlich der IDs der Knoten des Wirtsgraphen unterscheiden. Dem Graphen des
Beispiels werden die beiden Clocks xund yzugeordnet, wobei diese über einen Namen
identifiziert werden, sowie über einen Schlüssel, der sich aus den IDs des Wirtsgraphen
zusammen setzt. Um die Zuordnung von einzelnen Clocks mit gleichem Namen und un-
terschiedlichen IDs eindeutig zu machen, werden zusätzlich die Kanten des Wirtsgraphen
bei dem erzeugten Schlüssel mit berücksichtigt:
x:= c[1,5,2], y := c[3,7,4]
Die so erzeugten Clocks werden nachfolgend als Clockinstanzen bezeichnet, um eine
Differenzierung zu den üblichen Clocks zu erlauben.
Weiterhin soll es möglich sein, nur einen Teil der linken Seite einer Anwendungsregel mit
einer zugehörigen Clockinstanz zu verbinden. So etwa, wie es im Beispiel der Abbildung
4.7 dargestellt ist. Dort wird die Clockinstanz c, über welche eine Bedingung formuliert
ist, nur mit zwei der drei Knoten sowie einer der drei Kanten der Regel assoziiert. Um dies
zu ermöglichen werden die Anwendungsregeln erweitert, so dass den einzelnen Elemen-
ten ein entsprechendes Attribut hinzugefügt werden kann, welches angibt, ob ein Knoten
oder eine Kante zu einer Clockinstanz zugehörig ist. Dabei wird wie in Abbildung 4.8 an
jedes Element der Anwendungsregel geschrieben, mit welchen Clockinstanz-Namen das
Element verbunden ist (gelb markiert). In Abbildung 4.8 ist die gesamte linke Seite mit
der Clockinstanz cverbunden.
Aus diesen erweiterten Anwendungsregeln werden dann für die Clockinstanzen weitere
Regeln abgeleitet. Diese sorgen dafür, dass den einzelnen Graphen des Graphtransfor-
mationssystems die entsprechenden Clockinstanzen hinzugefügt werden. Für die Regel
aus dem Beispiel der Abbildung 4.7, zeigt die Darstellung 4.9 auf der rechten Seite die
abgeleitete Clockinstanzregel.
91
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
: Shuttle
track5 : Track
: Track : Track
<<create>>
next >
next >
< next
at >
<<destroy>>
at >
Shuttle Track
>
Graph G
>
c>10
Clock:c
Clock:c
: Shuttle
: Track
at >
Abgeleitete Regel für Clock c
Reset: c:=10
Track
Shuttle Track
>
ID:1
ID:6
ID:5
ID:4 ID:3
ID:2
ID:7
Shuttle Track
<<destroy>>
Clock:c Clock:c
Clock:c
c>=3
>
x:={c,{1,2},{5}} ; y:={c,{3,4},{7}}
Clock:c
Abbildung 4.9: Die Abbildung zeigt auf der linken Seite eine Anwendungsregel mit den
attributierten Elementen, welche der Clock czugehörig sind. Rechts ist
die daraus abgeleitete Clockinstanzregel dargestellt.
Mit Hilfe dieser abgeleiteten Regeln werden die einzelnen Clockinstanzen einem Wirts-
graphen hinzugefügt. Dabei muss noch berücksichtigt werden, dass die Ausführung der
Clockinstanzregel vor den zugehörigen Anwendungsregeln, aus welchen diese abgelei-
tet wurden, geschehen muss. Dies ist der Fall, da es für einzelne Clockinstanzen, welche
durch eine Clockinstanzregel erzeugt werden, entscheidend ist, seit wann diese existie-
ren. Um sicher zu stellen, dass Clockinstanzregeln vor den Anwendungsregeln ausgeführt
werden, wird den Graphtransformationsregeln eine Priorität hinzugefügt. Dabei erhalten
die Clockinstanzregeln eine höhere Priorität als alle anderen Arten von Regeln. Der Me-
chanismus von priorisierten Anwendungsregeln wurde bereits in Definition 10 beschrie-
ben und kann von den bestehenden Modellen der Graphtransformationssysteme direkt
übernommen werden.
4.2.2.3 Clockresets
Eine weiterer Bestandteil, der von dem Modell des Timed Automaton übernommen wird,
sind die so genannten Clockresets. Diese werden bei den Graphtransformationssystemen
ebenfalls mit der Anwendungsregel verknüpft, wobei angegeben wird, welche Clockin-
stanzen durch die Anwendung der erweiterten Regel auf den Wert 0zurück gesetzt wer-
den. Das Vorgehen orientiert sich dabei an der Art und Weise, wie Guards mit Hilfe der
Graphtransformationsregeln hinzugefügt werden. Ein Beispiel zeigt die Abbildung 4.10.
Dort ist die Clockinstanz cmit der Graphtransformationsregel verknüpft und wird durch
einen entsprechenden Reset bei Anwendung auf den Wert 0zurück gesetzt. Dabei werden
für die verwendete Clockinstanz innerhalb des Resets nach dem gleichen Prinzip wie für
die zeitlichen Bedingungen einzelne Clockinstanzregeln abgeleitet.
92
4.2 Modellierung
: Shuttle
track5 : Track
: Track : Track
<<create>>
next >
next >
< next
at >
<<destroy>>
at >
: Shuttle
: Track : Track
next >
at >
Graph G1
: Shuttle
: Track : Track
next >
Graph G2
at >
c>10
Clock:c
Clock:c
Clock:c
clock : Shuttle
: Track
at >
Abgeleitete Regel für Clock c
Reset: c:=10
Abbildung 4.10: Eine um Clockreset erweiterte Graphtransformationsregel. Dabei wird
die Clock cnach Anwendung der Regel auf den Wert 0zurück gesetzt.
4.2.2.4 Invarianten
Hier wird beschrieben, wie die Invarianten des Timed Automaton bei dem Modell des
Graphtransformationssystems übernommen werden. Über diese werden beim Timed-
Automaton zeitliche Bedingungen zu einer Location hinzugefügt. Hier wird ein Ansatz
vorgestellt, der es ermöglicht, diese Invarianten auf die einzelnen Graphen eines Graph-
transformationssystems zu übertragen. Da vor einer Erreichbarkeitsanalyse des Graph-
transformationssystems nicht klar ist, welche Folge-Graphen erreichbar sind, ist eine Zu-
ordnung von Invarianten direkt zu einzelnen Graphen nicht sinnvoll möglich. Um aber
eine Umsetzung von Invarianten zu ermöglichen, wird hierfür wiederum auf Strukturen
zurück gegriffen, nach denen innerhalb eines Graphen durch eine Graphtransformations-
regel gesucht wird. Es werden Anwendungsregeln eingeführt, die nur dem Zweck dienen,
einzelne zeitliche Bedingungen zu einzelnen Graphen hinzuzufügen. Hierzu werden so
genannte Invariantenregeln eingeführt. Diese Regeln verändern die Struktur des Wirtsgra-
phen, auf den sie angewendet werden, nicht, genauso wie die Clockinstanzregeln. Es wird
lediglich ein Matching mit der linken Seite der Anwendungsregel durchgeführt, d.h. die
Regel verfügt über keine rechte Anwendungsseite. Falls eine Invariantenregel anwendbar
ist, wird die mit dieser verbundene zeitliche Bedingung dem Wirtsgraphen hinzugefügt.
Eine mögliche Eigenschaft, die mit Hilfe einer solchen Invariantenregel formuliert wird,
wäre, dass die Verweildauer eines Shuttles auf einem Schienenabschnitt max. 11 Zeitein-
heiten dauern darf (siehe Abbildung 4.11)
Ähnlich wie die Anwendungsregeln mit zeitlicher Bedingung benötigen die Invarianten-
regeln ebenfalls zugehörige Clockinstanzen. Beim Beispiel der Abbildung 4.11 ist dies
die Clock d, von der es innerhalb eines Wirtsgraphen mehrere Instanzen geben kann. Dies
ist der Fall, da es wie bei den normalen Anwendungsregeln mehrere Stellen innerhalb des
Wirtsgraphen geben kann, an denen die Invariantenregeln anwendbar sind.
93
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
: Shuttle
track5 : Track
: Track
next >
< next
at >
: Shuttle
: Track : Track
next >
at >
Graph G1
: Shuttle
: Track : Track
next >
Graph G2
at >
d<11
Clock:d
Clock:d
Clock:d
Abbildung 4.11: Die Regel fügt einem Graphen die Invariante d < 11 hinzu.
Das Vorgehen bei den Invarianten ist äquivalent zu dem der zeitbehafteten Graphtransfor-
mationsregeln. Bei den Invarianten werden ebenfalls einzelne Elemente der linken Seite
der Regel mit den zugehörigen Clockinstanzen der Ungleichungen verknüpft. In der Ab-
bildung 4.11 sind alle Elemente mit der Clockinstanz dverbunden.
4.2.2.5 Zeitbehafteter Graph
Bei den hier betrachteten Erweiterungen spielen bei den Graphen des Graphtransfor-
mationssystems auch die zeitlichen Erreichbarkeitsräume eine Rolle. Dabei werden ein-
zelne Graphen mit Bedingungen über einzelne Clockinstanzen versehen. Ein Beispiel
hierfür ist die Ungleichung der Form d < 11, die über die Invariantenregel in Abbil-
dung 4.11 den einzelnen Graphen hinzugefügt wird. Somit muss das hier verwendete
Modell eines Graphen erweitert werden, um diesen Graphen einzelne zeitliche Erreich-
barkeitsräume hinzuzufügen.
Dabei ist der Fall zu berücksichtigen, dass ein einzelner Graph nicht nur über einen,
sondern auch über mehrere, eventuell disjunkte, zeitliche Erreichbarkeitsräume verfügen
kann. Dies ist der Fall, wenn innerhalb eines solchen erweiterten Graphtransformations-
systems ein Zyklus aus Transitionen zwischen den einzelnen Graphen existiert und durch
den Clockreset einer Graphtransformationsregel zu einem bereits existierenden Graphen
ein weiterer zeitlicher Erreichbarkeitsraum hinzugefügt wird. In Abbildung 4.12 ist ein
Graphtransformationssystem dargestellt, bei dem zwei einzelne Graphen über jeweils
zwei unterschiedliche Erreichbarkeitsräume verfügen.
94
4.3 Semantik
clock : Shuttle
: Track : Track
<<create>>
next >
next >
at >
<<destroy>>
at >
>
Initialer Graph G1
c>10
Clock:c
Clock:c
clock : Shuttle
: Track
at >
Abgeleitete Regel für Clock c
Reset: c:=10
a : A b : B
c : C
Zeitliche Bedingungen: ∅
>
a : A b : B
c : C
Zeitliche Bedingungen: c<=3
Graph G2
P1c<=3
>
Graph G2
a : A b : B
c : C
Zeitliche Bedingungen: c=3
>
a : A b : B
c : C
Zeitliche Bedingungen: c<=3 ∧ c>=3 => c=3
Graph G1
P2c>=3
P2c>=3
P1c<=3
Abbildung 4.12: Die beiden Graphen G1und G2, welche über jeweils zwei unterschied-
liche zeitliche Erreichbarkeitsräume verfügen.
4.3 Semantik
Nachfolgend wird die Semantik der gerade vorgestellten Konzepte beschrieben. Dabei
wird das Modell der Graphtransformationssysteme aus dem Grundlagenkapitel 2.3.4 er-
weitert. Der Abschnitt schließt mit der Definition eines zeitbehafteten Graphen und eines
zeitbehafteten Graphtransformationssystems.
4.3.1 Clockinstanzen
Um Zeit in Graphtransformationssystemen berücksichtigen zu können, müssen zeitliche
Bedingungen und die dort verwendeten Clockinstanzen definiert werden. Die bei den
erweiterten Graphtransformationssystemen verwendeten zeitlichen Bedingungen setzen
sich aus Ungleichungen der Form xi−xj∼dzusammen. xi, xjsind Clockinstanzen,
wobei xi, xj∈R+, sowie ∼∈ {<, ≤} und d∈Z. Jede Clockinstanz ist immer mit min-
destens einem Graphen Gverbunden. Dies bedeutet, dass eine Clockinstanz einen Namen
Mund eine Menge an Knoten und Kanten aus Gzugeordnet hat. Diese Kanten und Kno-
ten müssen dabei anhand einer ID eindeutig in Gidentifizierbar sein. Die Identität einer
solchen Clockinstanz ergibt sich also aus einem Namen und den IDs der zugeordneten
Elemente aus G. Ein Beispiel für einen Graphen sowie den zugehörigen Clockinstanzen
ist in Abbildung 4.13 dargestellt.
95
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
clock : Shuttle
track5 : Track
: Track : Track
<<create>>
next >
next >
< next
at >
<<destroy>>
at >
shuttle2 : Shuttle track2 : Track
>
Graph G
>
c>10
Clock:c
Clock:c
clock : Shuttle
: Track
at >
Abgeleitete Regel für Clock c
Reset: c:=10
Track
shuttle1 : Shuttle track1 : Track
>
ID:1
ID:6
ID:5
ID:4 ID:3
ID:2
ID:7
Shuttle Track
<<destroy>>
Clock:c Clock:c
Clock:c >
x:={c,{1,2},{5}} ; y:={c,{3,4},{7}}
Abbildung 4.13: Zum Wirtsgraphen Gwerden zwei Instanzen x, y der Clockinstanz c
erzeugt. Dabei ergibt sich x:= (c, {1,2},{5})und y:= (c, {3,4},{7}).
Definition 21
Eine Graph-Clockinstanz ist eine Clock x:= (M, N,E), wobei Mder Name der Clock
ist, Ndie Menge der Knoten-IDs und Edie Menge der Kanten-IDs darstellt. xkann dabei,
über die Zuweisungsfunktion V(x), ein Wert aus den reellen positiven Zahlen zugewiesen
werden.
Nachfolgend wird in dieser Arbeit die Zuweisungsfunktion V(x)weg gelassen, um die
Notation abzukürzen und die Clockinstanzen bezüglich der Notation, wie die Clocks der
Clockzones aus Kapitel 2.3.5.3, behandeln zu können. Ähnlich wie bei den Clockzones
existiert auch hier eine Referenzclock x0, die keinem Knoten und keiner Kante zugeord-
net ist. Die hier definierten Clockinstanzen werden bei den zeitlichen Bedingungen zur
Darstellung der Erreichbarkeitsräume verwendet. Innerhalb der Ungleichungen werden
die entsprechenden Clockinstanzen eingesetzt.
Definition 22
Eine zeitliche Bedingung t:= xi−xj∼dmit Clockinstanzen setzt sich zusammen aus
xi, xj, wobei entweder xioder xjder Referenz-Clock x0entsprechen kann. Falls xi, bzw.
xj6=x0, so ist xi, bzw. xjeine Clockinstanz wie in Definition 21 beschrieben. Weiterhin
gilt ∼∈ (<, ≤),i, j ∈ {N+\0}und d∈Z.
Aus einer Menge dieser zeitlichen Bedingungen wird ein zeitlicher Erreichbarkeitsraum
aufgebaut. Hierzu wird eine Anzahl an tivon zeitlichen Bedingungen mit Clockinstanzen
zu einer Menge Tzusammen gefasst. Der eigentliche zeitliche Erreichbarkeitsraum er-
gibt sich, indem ähnlich wie bei den in Kapitel 2.3.5.3 beschriebenen Clockzones die
Konjunktion über alle ti∈Tgebildet wird.
Definition 23
Ein zeitlicher Erreichbarkeitsraum T:= (tl, .., tn)mit l, n ∈N+besteht aus einer Menge
an einzelnen zeitlichen Bedingungen ti, wie diese in Definition 22 definiert sind. Dabei ist
es möglich das T:= ∅ist.
96
4.3 Semantik
4.3.2 Zeitbehaftete Anwendungsregeln
In diesem Abschnitt werden die neuen zeitbehafteten Anwendungsregeln definiert.
Definition 24
Eine Graphtransformationsregel Pt: (Pl, Pr, h, T, Vi, Ei)mit zeitlichen Bedingungen be-
steht aus einem linken Anwendungsteil Plund einem rechten Anwendungsteil Pr. Zusätz-
lich zu einer Graphtransformationsregel, wie in Definition 9 beschrieben, verfügt Ptüber
eine Menge an zeitlichen Bedingungen Tmit Clockinstanzen, wie in Definition 22 defi-
niert. Weiterhin existieren die Zuordnungsfunktionen Viund Ei, welche den Elementen
der linken Seite Plvon PtIDs zuordnen. Viordnet allen Knoten von Pl\d(Pt)ein inner-
halb von Pteindeutiges nkzu und Eiordnet allen Kanten in Pl\d(Pt)ein eindeutiges
ekzu. Dabei gilt nk, ek∈N+. Für jede Clockinstanz xj∈X, mit X:= (x1, .., xn)und
xj:= (M, N,E), die in einem t∈Tverwendet wird (siehe Definition 22), ergeben sich
Nund Ewie folgt: Nwerden alle Elemente aus Viund Ealle Elemente aus Eizugewie-
sen.
In der obigen Definition sind alle Clockinstanzen immer mit dem gesamten Teil der lin-
ken Seite Pl\d(Pt)einer Anwendungsregel verbunden. Diese wird nun im Folgenden,
angelehnt an Abschnitt 4.2.2.2, derart erweitert, dass es auch möglich ist, Clockinstanzen
nur mit einem Teil einer Anwendungsregel zu verknüpfen.
Definition 25
Eine Graphtransformationsregel Pt:= (Pl, Pr, h, T, Vi, Ei, f)mit zeitlichen Bedingun-
gen und einer Anzahl an zugeordneten Clock-Elementen verfügt zusätzlich zu Definition
24 über eine Funktion f, welche den in Tvorkommenden Clockinstanzen die Menge v
und ezuordnet, wobei v⊆Viund e⊆Ei.
4.3.2.1 Resets
Bei den bis hier vorgestellten erweiterten Graphtransformationsregeln fehlen noch die
Resets, bei deren Anwendung einzelne Clockinstanzen zurück gesetzt werden.
Definition 26
Ein Clockinstanz-Reset r:= (xr)besteht aus der zugehörigen Clockinstanz xr, welche
bei Anwendung von rauf den Wert 0zurück gesetzt wird.
Die Graphtransformationsregel aus Definition 25 wird entsprechend um die Clockinstanz-
Resets erweitert.
Definition 27
Eine Graphtransformationsregel Pt:= (Pl, Pr, h, T, Vi, Ei, R, f), welche um Clockin-
stanz-Resets erweitert ist, besteht zusätzlich aus der Menge R. Für alle r∈Rgilt, dass
97
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
rein Clockinstanz-Reset ist. Für die Zuordnungsfunktion fgilt zusätzlich, dass diese den
Clockinstanzen xk, welche in r∈Rvorkommen, ebenfalls einzelne Elemente aus Viund
Eizuordnet.
Dabei gilt der bei einer Anwendung ausgeführte Reset als eine Nachbedingung, welche
mit dem rechten Teil Prder Graphtransformationsregel verbunden wird.
4.3.2.2 Invarianten
Neben den Clockinstanz-Regeln gibt es eine weitere Art von Graphtransformationsregeln,
nämlich die in Abschnitt 4.2.2.4 beschriebenen Invarianten.
Definition 28
Eine Invarianten-Graphtransformationsregel It:= (Il, h, t, Vi, Ei, f)besteht aus einer
linken Seite Il, welche die Vorbedingung darstellt, einem Graphmorphismus hsowie aus
einer zeitlichen Bediungung t:= (x1−x2∼d)mit Clockinstanzen, wie bei Definition 22
definiert. Falls x1, bzw. x2nicht der Referenz-Clock x0entspricht, so wird den Mengen N
und E(der Clockinstanzen x1und x2) das Ergebnis der Funktion f(n)zugewiesen, wobei
gilt, nstammt aus den Knoten und Kanten von Il.
Da der Graphmorphismus h Ilimmer auf Ilselbst abbildet, werden bei der Anwendung
entsprechend keine Kanten oder Knoten entfernt oder hinzugefügt. Eine so definierte In-
variantenregel verfügt über keine rechte Seite. Bei Anwendung dieser Regel wird den
zeitlichen Erreichbarkeitsräumen eines Graphen als Nachbedingung die Ungleichung t
hinzugefügt.
4.3.2.3 Ableitung von Clockinstanzregeln
Um die Clockinstanzen zu einem Graphen Ghinzuzufügen, werden aus den erweiterten
Graphtransformationsregeln aus Definition 27 weitere Regeln abgeleitet. Dabei werden
für jede Clockinstanz xk, die in den Bedingungen Teiner zeitbehafteten Graphtransfor-
mationsregel, in den Clockinstanz-Resets Roder in der jeweiligen Bedingung teiner In-
variantenregel vorkommt, einzelne Graphtransformationsregeln Ctabgeleitet. Diese wer-
den nachfolgend als Clockinstanzregeln bezeichnet und ergeben sich aus der linken Seite
Plder Graphtransformationsregel Pt, bzw. aus der linken Seite Ilder Invariantenregel.
Hierbei werden für eine Clockinstanz xk, die durch die Funktion faus Ptoder Itüber
die IDs zugeordneten Knoten und Kanten verwendet, um die linke Seite der Clockin-
stanzregel Ctherzuleiten. Die einzige Nachbedingung von Ctist, dass dem Graphen G
eine Clockinstanz x0
khinzugefügt wird, falls diese innerhalb von Gnoch nicht existiert.
Dabei werden x0
knicht die Knoten und Kanten IDs zugeordnet, welche die Funktion f
98
4.3 Semantik
liefert, sondern die Knoten- und Kanten-IDs, welche innerhalb des Wirtsgraphen Gbeim
Anwenden der Clockinstanz-Regel im Wirtsgraphen aufgefunden werden (siehe Abbil-
dung 4.13).
Definition 29
Eine Clockinstanzregel Ct:= (M, Cl, h, Ci), welche auf einen Wirtsgraphen Gange-
wendet wird, besteht aus dem Namen Mder Clockinstanz, sowie der linken Seite Clder
Graphtransformationsregel. Clentspricht dabei einer linken Seite Pleiner Graphtrans-
formationsregel, wie in Definition 9 angegeben, mit dem Unterschied, dass die Funktion
d(Ct)des Graphmorphismus hdie leere Menge ∅liefert. Ctverfügt über eine Nachbe-
dingung Ci:= (M, N,E), wobei Cieine Clockinstanz ist und Neine Teilmenge der
Kanten-IDs Vi(v)mit v∈Vund Vaus Clund E ⊆ Ei(e)mit e∈Eund Eaus Cl.
Im Folgenden wird darauf eingegangen, wie aus einer Graphtransformationsregel oder
Invariantenregel mit zeitlicher Bedingung die einzelnen Clockinstanzregeln hergeleitet
werden. Das hier beschriebene Vorgehen findet nach dem Erstellen eines entsprechen-
den initialen Graphtransformationssystems und vor der Durchführung einer Erreichbar-
keitsanalyse statt. Auf das entsprechende Verfahren, um die Clockinstanzregeln auf einen
Wirtsgraphen anzuwenden, wird im nächsten Abschnitt eingegangen.
Eine entsprechende Graphtransformationsregel Pt:= (Pl, Pr, h, T, Vi, Ei, R, f)verfügt
über eine Menge an zeitlichen Bedingungen Tund Clockinstanz-Resets R. Für alle t∈T
gilt t:= (x1−x2∼d)und für alle r∈Rgilt r:= (xr).Xt,r ist die Menge, welche sich
aus der Vereinigung der Clockinstanzen x1, x2und aus allen t∈Tsowie allen xr, die
in den r∈Rvorhanden sind, ergibt. Für jedes x:= (M, N,E)mit x∈Xt,r wird dann
eine Clockinstanz-Regel cj:= (Mj, Cl,j, h, Ci,j)mit j∈N+nach dem im Algorithmus
4.2 beschriebenen Schema hergeleitet, wobei Cl,j := (Vc, Ec). Die Funktion fder In-
variantenregel It:= (Il, h, t, Ei, Vi, f)kann mit Graph Ilanstelle des Graphen Plaus Pt
verwendet werden, um die Clockinstanzregeln der Invarianten analog herzuleiten.
Die bei der Nachbedingung Ci,j := (Mj,Nj,Ej)vorhandenen Mengen Njund Ej, welche
die Knoten- und Kanten-IDs der durch die Regel erzeugten Clockinstanz darstellen, wer-
den erst bei der Anwendung auf einen Wirtsgraphen Gmit den entsprechenden Elementen
gefüllt. Somit sind diese bei der Erstellung der Clockinstanz-Regel immer leer.
4.3.3 Zeitbehafteter Graph & Graphtransformationssystem
4.3.3.1 Zeitbehafteter Graph
Um ein erweitertes Graphtransformationssystem zu analysieren, muss ein zeitbehafteter
Graph definiert werden. Basierend auf diesem können dann Nachfolger- und Vorgänger-
zustände hergeleitet werden. Ein gerichteter und benannter Graph Gwird um die ent-
99
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
Algorithmus 4.2 Schema zur Herleitung einer Clockinstanz-Regel cj:=
(Mj, Cl,j, h, Ci,j),j∈N+
1: Mj=M
2: for all n∈Pldo
3: if f(n)∈ N then
4: Vc=Vc∪n
5: end if
6: end for
7: for all e∈Pldo
8: if f(e)∈ E then
9: Ec=Ec∪e
10: end if
11: end for
12: Ci,j = (M, ∅,∅)
sprechenden Bestandteile erweitert, so dass zeitliche Erreichbarkeitsräume mit diesem
verknüpft werden. Hierzu werden zu GUngleichungen wie in Definition 22 sowie die
dort vorhandenen Clockinstanzen hinzugefügt.
Definition 30
Ein zeitbehafteter Graph Gt:= (G, C, T)ist ein Tripel mit einem gerichteten Graph G,
einer Anzahl an Clockinstanzen Cund einer Menge an zeitlichen Bedingungen Tüber
einzelnen Elementen aus C. Jeder Knoten vaus Gbesitzt eine eindeutige ID niund jede
Kante e∈Eeine entsprechende ID ejmit i, j ∈N+.
Mit Hilfe der oben stehenden Definition 30 wird einem einzelnen Graphen gaus der Men-
ge aller Graphen Geines Graphtransformationssystems, wie in Definition 11 beschrieben,
ein zeitlicher Erreichbarkeitsraum zugewiesen und dieser gleichzeitig über die verwende-
ten IDs der Clockinstanzen mit gverknüpft.
Bei dem im weiteren Verlauf verwendeten Modell ist es möglich, dass ein Graph Gtmeh-
rere zeitliche Erreichbarkeitsräume haben kann. Ein Beispiel hierfür ist das Graphtrans-
formationssystem, welches in Abbildung 4.14 aufgebaut wird. Dort gibt es einen initialen
Graphen G1und zwei zeitbehaftete Graphtransformationsregeln, P1und P2. Ohne bereits
genau darauf einzugehen, wie ein entsprechender Algorithmus zum Aufbau des Graph-
transformationssystems aussieht, ist es möglich, wie in Abbildung 4.12 dargestellt, die
Folgegraphen sowie die zu den Graphen zugehörigen zeitlichen Bedingungen in diesem
einfachen Fall zu erstellen. Dabei ergeben sich, wie in Abbildung 4.12 zu sehen, meh-
rere identische Folgegraphen, welche sich nur in den ihnen zugeordneten zeitlichen Be-
dingungen unterscheiden. So existieren dort die Graphen G1und G2jeweils mit zwei
unterschiedlichen zeitlichen Bedingungen.
100
4.3 Semantik
Somit muss es möglich sein, einem zeitbehafteten Graphen nicht nur eine sondern meh-
rere der zeitlichen Erreichbarkeitsräume zuzuordnen, die durch Bedingungen wie in De-
finition 22 beschrieben aufgebaut werden.
Definition 31
Ein zeitbehafteter Graph Gt:= (G, C, T)mit mehreren zeitlichen Erreichbarkeitsräumen
ist ein Tripel mit einem gerichteten Graph G, einer Anzahl Clockinstanzen Cund einer
Menge T. Dabei ist T:= {Tl, ..., Tn}mit l, n ∈N+. Jedes Ti∈ T besteht dabei aus
einer Menge an zeitlichen Bedingungen über einzelnen Elementen aus C. Jeder Knoten v
aus Gbesitzt eine eindeutige ID niund jede Kante e∈Eeine entsprechende ID ejmit
i, j ∈N+.
clock : Shuttle
: Track : Track
<<create>>
next >
next >
at >
<<destroy>>
at >
Initialer Graph G1
c>10
Clock:c
Clock:c
clock : Shuttle
: Track
at >
Abgeleitete Regel für Clock c
Reset: c:=10
A B
C
c<=3
>
Regel P1
a : A b : B
c : C
clock:c
<<create>>
<<destroy>> A B
C
c>=3
clock:c
<<destroy>>
Regel P2
<<create>>
Abbildung 4.14: Ein Graphtransformationssystem mit einem initialen Startgraphen G1,
sowie zwei zeitbehaftete Graphtransformationsregeln P1und P2.
4.3.3.2 Zeitbehaftetes Graphtransformationssystem
Bisher wurden alle notwendigen Definitionen eines zeitbehafteten Graphen gegeben.
Im Folgenden wird nun darauf aufbauend ein zeitbehaftetes Graphtransformationssys-
tem formal definiert. Zu diesem erweiterten Graphtransformationssystem gehören die
in den vorherigen Abschnitten beschriebenen Bestandteile, welche sich aus einzelnen
zeitbehafteten Graphen Gt:= (G, C, T), aus erweiterten Graphtransformationsregeln
Pt:= (Pl, Pr, h, T, Vi, Ei, R, f)und aus Invariantenregeln It:= (Gl, t)zusammenset-
zen.
101
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
Definition 32
Ein Graphtransformationssystem St:= (Gt,G0
t,Pt,It)mit zeitlichen Bestandteilen be-
steht aus einer potentiell unendlichen Menge an zeitbehafteten Graphen Gt, einer end-
lichen Menge an initialen zeitbehafteten Graphen G0
t, einer endlichen Menge an zeitbe-
hafteten Graphtransformationsregeln Pt, wie diese in Definition 27 definiert sind, sowie
einer endlichen Menge an Invarianten-Regeln It.
Um alle erreichbaren Zustände für das Graphtransformationssystem Stzu berechnen,
muss nun noch beschrieben werden, wie sich aus den Graphtransformationsregeln Ptab-
leitbare Clockinstanzregeln erzeugen lassen.
4.3.3.3 Clockinstanzregeln
Bei dem oben vorgestellten Graphtransformationssystem St:= (Gt,G0
t,Pt,It)fehlen für
eine Erreichbarkeitsanalyse noch die zugehörigen Clockinstanzregeln, welche innerhalb
der Graphtransformationsregeln Ptsowie den Invariantenregeln Itvorkommen. Diese
können, wie im Abschnitt 4.3.2, Definition 29, dargestellt und aus den einzelnen Graph-
transformationsregeln Pt∈ Ptabgeleitet werden.
Um die entsprechenden Clockinstanzregeln Ctzu erhalten, wird für jede Graphtransfor-
mationsregel Pt∈ Ptdas in Abschnitt 4.3.2 (siehe Definition 29) beschriebene Verfahren
zur Ableitung von Clockinstanzregeln angewendet, wobei jede erstellte Clockinstanzregel
cider Menge Cthinzugefügt wird. Es ist möglich, dass identische Regeln mehrfach ab-
geleitet und zu Cthinzugefügt werden. Da Cteine Menge ist, fallen doppelte Vorkommen
weg.
4.4 Erreichbarkeitsanalyse
Auf der Basis des im vorherigen Abschnitt erstellten und erweiterten Modells eines
Graphtransformationssystems der Form St:= (Gt,G0
t,Pt,It)wird hier ein Algorithmus
vorgestellt, mit dem eine Erreichbarkeitsanalyse durchgeführt werden kann. Dabei wer-
den die hierzu verwendeten Operationen schrittweise erarbeitet.
4.4.1 Darstellung durch Clockzones
Der zeitliche Erreichbarkeitsraum eines zeitbehafteten Graphen Gt(siehe Abschnitt 4.3.3)
lässt sich mit Hilfe der Datenstruktur der Clockzones beschreiben. Natürlich ist es auch
102
4.4 Erreichbarkeitsanalyse
möglich, eine andere Datenstruktur zu wählen, um die zeitlichen Bedingungen aus Ka-
pitel 4.3.3 zu beschreiben. Die Entscheidung, bereits an dieser Stelle die Datenstruktur
der Clockzones zu verwenden, begründet sich darin, dass hierdurch die im Folgenden
beschriebenen Algorithmen besser veranschaulicht werden können. Zusätzlich sind die
hier verwendeten zeitlichen Bedingungen, welche in Form von Ungleichungen in Kapi-
tel 4.3.3 definiert wurden, denen sehr ähnlich, die bei der Datenstruktur der Clockzones
verwendet werden.
Aus den erwähnten Gründen erfolgt die Darstellung der zeitlichen Erreichbarkeitsräume
in Form der in Definition 2.3.5.3 vorgestellten Clockzones. Die Definition eines zeitbe-
hafteten Graphen wird entsprechend abgeändert. Somit ergibt sich der hier verwendete
zeitbehaftete Graph Gt:= (G, C, Z), indem die in Definition 31 verwendete Menge T
durch die Menge Zersetzt wird. Bei Thandelt es sich dabei um eine Menge dem Graphen
zugeordneter zeitlicher Erreichbarkeitsräume T, die wiederum aus einzelnen zeitlichen
Bedingungen tbestehen. Dabei wird jedes Tin eine einzelne Clockzone Züberführt.
Diese Überführung ist problemlos möglich, da die zeitlichen Ungleichungen t:= (xi−
xj∼d)sehr stark denen der Clockzones ähneln. Der einzige Unterschied besteht darin,
dass bei den Ungleichungen t∈Tanstelle der einfachen Clockvariablen der Clockzones
die Clockinstanzen aus der Definition 21 verwendet werden. An dieser Stelle wird das
Modell der Clockzones dahingehend angepasst, dass die dort verwendeten Clockvariablen
durch Clockinstanzen ersetzt werden. Die daraus leicht abgeänderte Form der Clockzones
ergibt sich zu:
Definition 33
Eine Clockzone Zmit Clockinstanzen hat eine Anzahl von Clockinstanzen xi, wie diese in
Definition 21 definiert sind. Die einzelnen xikönnen Werte aus R+∪0annehmen, wobei
i∈N+und i > 0. Zusätzlich existiert eine Referenz-Clock x0, die immer den Wert 0
besitzt sowie eine Anzahl von Bedingungen c∈Cin Form von Ungleichungen der Art
xj≺d, d ≺xj, xi−xj≺d, mit i, j ∈N+,d∈Zund ≺∈ {<, ≤}. Die Clockzone ergibt
sich aus der Konjunktion über Bedingungen aus C.
Die Eigenschaften und die Operationen auf den Clockzones ändern sich durch diese Er-
weiterung nicht. Die restlichen Bestandteile lassen sich direkt übernehmen. So entspricht
die Referenzclock x0bei der Datenstruktur der Clockzones der Referenzclock, wie die-
se bei den zeitlichen Bedingungen in Kapitel 4.3.3 definiert wurde. Die Ungleichungen
lassen sich direkt übernehmen. Ein zeitbehafteter Graph mit mehreren zeitlichen Erreich-
barkeitsräumen, wie in Definition 31 dargestellt, wird dann zu einem entsprechenden Gra-
phen Gt:= (G, C, Z)mit mehreren Clockzones Z.
103
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
4.4.2 Zeitbehafteter Folgegraph
Die einzelnen Schritte, um einen Folgegraphen für einen zeitbehafteten Graphen
abzuleiten, werden im Folgenden beschrieben. Ausgangspunkt sind dabei ein zeit-
behafteter Graph Gt:= (G, C, Z), eine zeitbehaftete Graphtransformationsregel
Pt:= (Pl, Pr, h, T, Vi, Ei, R, f, r), die Clockinstanzregeln Cund Invariantenregeln I.
Dabei wird durch den zeitbehafteten Graphen Gteine Anzahl von Zuständen abgebildet,
die sich durch die Kombination des Graphen Gaus Gtmit den einzelnen Clockzones
Z∈ Z ergeben. Ein solcher Zustand ist somit ein Tupel hG, Zi. Weiterhin wird
davon ausgegangen, dass die von der Graphtransformationsregel Ptabgeleiteten Clockin-
stanzregeln in der Menge Centhalten sind sowie, dass die durch diese Regeln erzeugbaren
Clockinstanzen der Menge Cdes zeitbehafteten Graphen Gtbereits hinzugefügt wurden.
Die sich aus der Anwendung der Graphtransformationsregel Ptauf den Graphen Gt
ergebenden Folgezustände können durch die Funktion prod (Kapitel 2.3.5.4) berechnet
werden. Die Funktion liefert die Menge Mder Graphmorphismen m:= (mv, me)
zurück, welche Plaus Ptauf einen Teilgraphen gaus Gabbilden, wobei wiederum Gaus
Gtstammt.
Nach Anwendung der Funktion prod auf einem Graphen Gmüssen dann im Unterschied
zu den ursprünglichen Graphtransformationssystemen weitere Schritte durchgeführt wer-
den, bevor mit Hilfe der einzelnen Graphmorphismen m∈Mdie Tochtergraphen her-
geleitet werden. Zu diesen Schritten gehört die Überprüfung der zeitlichen Bedingungen
t∈Tvon Pt. Bevor allerdings diese Überprüfung stattfinden kann ist es notwendig, die
innerhalb der einzelnen tverwendeten Clockinstanzen zuzuordnen. Warum und in wel-
cher Art dies geschehen muss, ist nachfolgend beschrieben.
4.4.2.1 Zuordnen der Clockinstanzen zu den Regelanwendungen
Bei Clockinstanzen wird unterschieden zwischen Clockinstanzen, die innerhalb von zeit-
behafteten Graphtransformationsregeln, Clockinstanzregeln sowie Invariantenregeln vor-
kommen und denen, wie diese innerhalb der zeitlichen Erreichbarkeitsräume vorhanden
sind. Innerhalb der Graphtransformationsregeln, Clockinstanzregeln sowie Invarianten-
regeln handelt es sich um Clockinstanzen, die mit einzelnen Element-IDs des Graphen
der linken Seite der jeweiligen Graphtransformationsregel Pt, bzw. der Clockinstanzregel
Ctoder Invariantenregel Itverbunden sind. Im Gegensatz dazu sind die Clockinstanzen
der zeitlichen Erreichbarkeitsräume mit den IDs der Elemente des Graphen Gaus Gtver-
bunden, auf den die einzelnen Regeln und Graphroduktionen angewendet werden. Wie
diese Verknüpfung zu den IDs der Elemente aus Gmit Hilfe der Clockinstanzregeln vor-
genommen wird, ist im Kapitel 4.2.2.2 beschrieben.
104
4.4 Erreichbarkeitsanalyse
Damit die mit einer Graphtransformationsregel verbundenen Guards Tund Clockresets
Rinnerhalb einer Graphtransformationsregel Ptverwendet werden können ist es not-
wendig, die dort vorhandenen Clockinstanzen bei der Anwendung von Ptauszutauschen.
Dies bedeutet für jeden Morphismus m, der aus prod(Pt, G)resultiert, eigene Guards Tm
und Clockresets Rmherzuleiten. Hierzu wird die Funktion assign(m, T, R)verwendet,
welche nach dem folgenden Schema arbeitet und das Tupel hTm, Rmizurückliefert.
Dabei müssen die Clockinstanzen aus Ptmit denen dem Graphen Gdurch die Clockin-
stanzregeln hinzugefügten Clockinstanzen ausgetauscht werden. Hierzu muss beim Auf-
suchen der linken Seite Plvon Ptinnerhalb des Wirtsgraphen Geine Zuordnung der
Element-IDs von der linken Seite Plzu den Element-IDs der Stelle min Gvorgenommen
werden, an der Plinnerhalb von Gbei der aktuellen Anwendung erfüllt ist. Ein Beispiel
hierfür zeigt die Abbildung 4.15.
: Shuttle
track5 : Track
: Track : Track
<<create>>
next >
next >
< next
at >
<<destroy>>
at >
Shuttle Track
>
Graph Gt
>
c>10
Clock:c
Clock:c
clock : Shuttle
: Track
at >
Abgeleitete Regel für Clock c
Reset: c:=10
Track
Shuttle Track
>
ID:1
ID:6
ID:5
ID:4 ID:3
ID:2
ID:7
Shuttle Track
Clock:c Clock:c
Clock:c
c>=3
>
Graphproduktion Pt
Clockinstanz von Pt c(1,3,2)
Zuordnung der Ids:
Gt:1 = Pt:1
Gt:5 = Pt:3
Gt:2 = Pt:2
Clockinstanz von Gt c(2,5,1)
Abbildung 4.15: Im Wirtsgraphen Gtwird die Graphtransformationsregel Ptan der rot
umrandeten Stelle angewendet
Diese Zuordnung geschieht, indem Tund Rwie folgt überführt werden. Dabei gilt für
alle t∈T,t:= (xi−xj∼d)ist eine zeitliche Bedingung mit Clockinstanzen xiund xj.
x0beschreibt die Referenz-Clock, welche zu jedem Zeitpunkt den Wert 0besitzt.
Zunächst wird die Funktion graphID(m, x, G, Pl)eingeführt (siehe Anhang A, Algorith-
mus A.1). Diese nimmt eine Zuordnung der Knoten- und Kanten-IDs zu dem Graphmor-
phismus m:= (mv, me), einer Clockinstanz x:= (M, N,E), dem Wirtsgraphen G:=
(VG, Eg, E(s,G), E(t,G), V(i,G), E(i,G))und der linken Seite Pl:= (VP, EP, E(s,P ), E(t,P ),
V(i,P ), E(i,P ))aus Ptvor. Dies geschieht nach dem Vorgehen wie im Beispiel der Abbil-
dung 4.15 aufgezeigt. Der Rückgabewert sind die Knoten- und Kanten-IDs N0,E0aus
dem Wirtsgraphen G.
Mit Hilfe der Funktion graphID wird nachfolgend die Funktion assign formuliert (siehe
Anhang A, Abbildung A.2), mit der die Guards Tund Resets Rzu Tmund Rmüberführt
werden.
105
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
Die hierdurch entstandenen Guards Tmund Clockresets Rmgelten ausschließlich für die
momentane Anwendung der Graphtransformationsregel Ptbezüglich minnerhalb des
Wirtsgraphen G.
4.4.2.2 Erzeugen einer Folge-Clockzone
Bevor für die durch prod hergeleiteten Graphmorphismen mangewendet werden, muss
an dieser Stelle überprüft werden, von welchen Graphzuständen hG, φiaus zusammen
mit den Guards T0eine Clockzone φ0mit Hilfe der Funktion succφ(φ, I, ϕ)aus Kapitel
2.3.5.3 hergeleitet werden kann. Um diese Funktion anwenden zu können, sind die dem
aktuellen Zustand zugehörigen Invarianten Inotwendig.
Diese Invarianten werden hergeleitet, indem die einzelnen Invariantenregeln It∈ I auf
den Wirtsgraphen Gangewendet werden. Dabei kann die Funktion prod aus Kapitel
2.3.5.4 verwendet werden, um die Menge der Morphismen Mherzuleiten. Die Funkti-
on benötigt eine linke und rechte Anwendungsseite Lund R, sowie einen Morphismus
m. Eine Invariantenregel It:= (Il, h, t, Vi, Ei, f)besitzt keine rechte Anwendungsseite
R. Dabei ist bei Itdiese identisch mit Il, also ergibt sich R, L =Ilund m=h. So-
mit kann die Funktion prod verwendet werden um die Menge der Graphmorphismen M
herzuleiten.
Aus diesen Graphmorphismen Mkönnen nach dem gleichen Schema wie in Kapitel
4.4.2.1 beschrieben die einzelnen Ungleichungen hergeleitet werden. Die hierdurch ent-
stehende Menge an Invarianten I, welche aus einzelnen zeitlichen Bedingungen imit
Clockinstanzen besteht, wird der Funktion succφ(φ, I, T0)zusammen mit der Clockzone
φund den Guards T0übergeben. Als Ergebnis liefert succφdie Clockzone φsucc, bei der
es zu überprüfen gilt, ob diese leer ist1.
Falls φsucc einer leeren Clockzone entspricht, wird das Ergebnis verworfen. Ein Folge-
Clockzone kann entsprechend über die Funktion succφnicht hergeleitet werden und somit
die Transition von dem Wirtsgraphen Gaus Gtzu einem Folgegraphen G0nicht über die
Clockzone φan der zu mzugehörigen Stelle vorgenommen werden. Andernfalls wird da-
mit fortgefahren, die Clockresets Rmmit Hilfe der Funktion succ0
φaus Kapitel 2.3.5.3 auf
φsucc anzuwenden, um die Clockzone φ0zu erhalten. Falls eine Clockzone φsucc nicht leer
ist, wird der aus dem Graphmorphismus mherleitbare Graph G0erzeugt. Welche Knoten
vG0und Kanten EG0sich dabei aus mzu G0ergeben, ist in Abschnitt 2.3.4 beschrieben.
Bevor mit Hilfe des so erzeugten Graphen G0und der Clockzone φ0ein Folgezustand
hG0, φ0izu dem zeitbehafteten Folgegraphen G0
thinzugefügt wird, müssen weitere Schrit-
te durchgeführt werden. Hierzu gehört die Erzeugung der Clockinstanzen des Graphen G0
durch die Clockinstanzregeln C, sowie die weitere Überarbeitung der Clockzone φ0. Bei
1Zu leeren Clockzones siehe Kapitel 2.3.5.3.
106
4.4 Erreichbarkeitsanalyse
dieser müssen die Invarianten hinzugefügt werden, welche über die Anwendung der In-
variantenregeln auf G0erzeugbar sind. Zusätzlich müssen alle zeitlichen Bedingungen t
entfernt werden, für die keine Clockinstanzen durch die einzelnen c∈ C innerhalb von G0
erzeugt wurden.
4.4.2.3 Erzeugen der Clockinstanzen des Folgegraphen
Zur Erzeugung der Clockinstanzen Cdurch die Clockinstanzregeln aus Cinnerhalb des
Graphen G0wird eine Funktion C=prodclock(C, G0)eingeführt (siehe Anhang A, Algo-
rithmus A.3).
4.4.2.4 Erzeugen des Folgezustands
Mit Hilfe der so erzeugten Clockinstanzen C, sowie den Invarianten Ides Folgegraphen
G0, wird der Folgezustand hergeleitet. Innerhalb der Menge Ckönnen Clockinstanzen
vorhanden sein, die beim Folgegraphen G0durch die Funktion prodclock neu erzeugt wur-
den. Diese neuen Clockinstanzen ergeben sich, indem alle Clockinstanzen c∈CGdes
Graphen Gaus der Menge Cder Clockinstanzen des Graphen G0entfernt werden. Die
resultierende Menge wird an dieser Stelle mit Cnew =C\CGbezeichnet. Diese hinzuge-
kommenen Clockinstanzen wurden gerade erst erzeugt und müssen entsprechend zu den
bereits existierenden in Relation gesetzt werden. Für die neu hinzugekommenen Clock-
instanzen cnew gilt, dass diese zu den bereits existierenden wie folgt in Relation gesetzt
werden müssen:
Für die Menge der Clockinstanzen Cold =C\Cnew, welche bereits bei dem Vorgän-
ger Graphen Gvorhanden waren, existiert eine Anzahl an Bedingungen innerhalb der
Clockzone φ0. Jede Clockinstanz cold ∈Cold hat dort eine obere Schranke ound untere
Schranke u, für die gilt, dass o∈Z+∪ ∞ und u∈R+. Diese Schranken lassen sich
aus den zeitlichen Bedingungen taus φ0ermitteln. Für die hinzugekommenen Clockin-
stanzen cnew ∈Cnew müssen für jede Clockinstanz aus cold ∈Cold Ungleichungen der Art
cnew −cold ∼ −uund cold −cnew ∼ohinzugefügt werden. ound umüssen dabei zu jedem
cold ermittelt werden. ∼entspricht <oder ≤, je nachdem, welche Art der Ungleichung
bei dem entsprechenden taus φ0ermittelt wurde.
Nachfolgend werden die Invarianten Iauf φ0:= φ0∪Iangewendet und anschließend
alle Bedingungen t= (xi−xj∼d)aus φ0entfernt, für die gilt, dass mindestens eine
Clockinstanz xioder xjnicht in Centhalten ist (siehe Anhang A, Algorithmus A.4).
Zum Abschluss werden mit der Funktion φ0=succ0
φ(φ0, R0), wie in Kapitel 2.3.5.3 be-
schrieben, die Clockresets R0auf φ0angewendet. Die hieraus resultierende Clockzone
107
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
bildet zusammen mit dem Graphen G0in Form des Tupels hG0, φ0ieinen Folgezustand
des zeitbehafteten Folgegraphen G0
t.
4.4.2.5 Zeitbehafteter Folgegraph
Um den gesamten zeitbehafteten Folgegraphen G0
tzu berechnen, werden die hier vor-
gestellten Operationen bzw. Funktionen wie im Algorithmus productionmangewendet
(siehe Anhang A, Algorithmus A.5). Um alle durch Pterzeugbaren Folgegraphen G0
tzu
berechnen, wird die Funktion productionmzum Algorithmus production erweitert (siehe
Anhang A, Algorithmus A.6).
4.4.3 Erreichbares Graphtransformationssystem
Abschließend kann nun beschrieben werden, wie sich mit den angegebenen Funktionen
der gesamte Erreichbarkeitsraum eines zeitbehafteten Graphtransformationssystems er-
zeugen lässt. Ausgangspunkt ist hierfür das zeitbehaftete Graphtransformationssystem
St:= (Gt,G0
t,Pt,It), wobei Gteine Menge an zeitbehafteten Graphen Gt,G0
tdie Menge
der initialen zeitbehafteten Graphen G0
t,Ptdie Menge an zeitbehafteten Graphtransfor-
mationsregeln Ptund Idie Menge der Invariantenregeln darstellt.
4.4.3.1 Erreichbarkeitsanalyse
Nach der Initialisierung und Erzeugung der Clockinstanzregeln Caus den einzelnen
Graphtransformationsregeln Ptwird die folgende Funktion reachGTStaufgestellt (sie-
he Algorithmus 4.3), mit welcher der Zustandsraum des Graphtransformationssystems
aufgebaut wird. Dabei gibt es zwei Mengen Open und Closed, wobei die vorhandenen
Graphen aus Stinitial der Menge Open zugewiesen werden. Der Menge Closed sind alle
Graphen aus Gtzugewiesen, die nicht in der Menge der initialen Graphen G0
tvorhanden
sind.
Dabei arbeitet der Algorithmus wie folgt: Solange noch ein zeitbehafteter Graph Gtin-
nerhalb der Menge Open enthalten ist (Zeile 3), durchlaufe alle Graphen der Menge
Open (Zeile 4) und wende auf jeden Graphen die einzelnen zeitbehafteten Graphtrans-
formationsregeln Ptmit Hilfe der Funktion production an (Zeile 7). Für jeden dar-
aus resultierenden zeitbehafteten Folgegraphen G0
t∈ G0
t(Zeile 8) überprüfe, ob der
in G0
tenthaltene einfache Graph G0bereits in einem zeitbehafteten Graphen Gtmp :=
(Gtmp,Ctmp,Ztmp)der Mengen Open oder Closed vorhanden ist (Zeile 11-15). Falls dies
der Fall ist überprüfe, ob die Menge Z0der Folge-Clockzones des Graphen G0
tnicht iden-
tisch mit der Menge Zfder Clockzones des Graphen Gfist (Zeile 16). Falls dies zutrifft,
108
4.4 Erreichbarkeitsanalyse
Algorithmus 4.3 procedure S0
t=reachGTSt(St, C)
procedure S0
t=reachGTSt(St, C)
1: St:= (Gt,G0,Pt,It)
2: Open =G0
t, Closed =Gt\ G0
t
3: while Open 6=∅do
4: for all Gt∈Open :Gt:= (G, C,Z)do
5: for all Pt∈ Ptdo
6: selfedge =false
7: G0
t=production(Gt, Pt, C, It).*
8: for all G0
t∈ G0
t:G0
t:= (G0,C0,Z0)do
9: found := (Gf,Cf,Zf)
10: found =NULL
11: for all Gtmp ∈Open ∪Closed :Gtmp := (Gtmp,Ctmp,Ztmp)do
12: if G0=Gtmp then
13: found =Gtmp, break
14: end if
15: end for
16: if found 6=NULL ∧ Zf6=Z0then .*
17: Zf=Z0∪ Zf.*
18: Open =Open ∪found . *
19: Closed =Closed \found . *
20: if Gf=Gthen
21: selfedge =true
22: end if
23: end if
24: if found == NULL then
25: Open =Open ∪G0
t
26: end if
27: end for
28: end for
29: if ¬selfedge then
30: Open =Open \Gt
31: end if
32: end for
33: end while
existierte bereits ein zeitbehafteter Graph innerhalb des Graphtransformationssystems,
der sich nur bezüglich der diesem zugeordneten zeitlichen Erreichbarkeitsraum unter-
scheidet. Somit wird dem bereits existierenden Graphen Gfdie Vereinigung beider zeit-
lichen Erreichbarkeitsräume zugewiesen (Zeile 17). Anschließend wird Gfin die Menge
Open verschoben und aus Closed entfernt (Zeile 18 und 19). Die in Zeile 21 zugewiesene
109
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
Variable behandelt einen Sonderfall, nämlich, dass der Mutter- und Tochtergraph iden-
tisch ist. In diesem Fall darf Gtnicht aus der Menge Open in Zeile 30 entfernt werden, da
zu Gtein zeitlicher Erreichbarkeitsraum hinzugekommen ist. Falls kein entsprechender
Graph Gtinnerhalb der Mengen Open ∪Closed aufgefunden wird, so handelt es sich
bei G0
tum einen neuen Graphen, welcher der Menge der offenen Graphzustände Open
zugewiesen wird (Zeile 20-21). Der Algorithmus ist beendet, wenn die Menge Open aller
offenen Graphen leer ist.
Im Vergleich mit dem Algorithmus zur Berechnung der erreichbaren Zustände eines
Graphtransformationssystems ohne zeitliche Bestandteile (siehe Kapitel 2.3.5.4) sind im
Wesentlichen die Zeilen, welche mit einem * am Ende versehen sind, hinzugekommen.
4.4.3.2 Prioritäten
Um die in Kapitel 2.3.4 beschriebenen Prioritäten zu berücksichtigen muss der oben ange-
gebene Algorithmus angepasst werden. Dabei wird davon ausgegangen, dass die zeitbe-
hafteten Graphtransformationsregeln Ptdes zeitbehafteten Graphtransformationssystems
St:= (Gt,G0
t,Pt,It)zusätzlich über eine Priorität r∈N+verfügen.
Hierbei muss die for-Schleife in Zeile 5 der Funktion reachGTStso erweitert werden,
dass alle Graphtransformationsregeln Ptmit gleicher Priorität rin jeweils einer Menge Qr
zusammengefasst werden. Die einzelnen Mengen werden dann mit der for-Schleife der
Zeile 5 abgearbeitet, wobei die Menge mit den Regeln, welche die höchste Priorität rha-
ben, zuerst abgearbeitet wird. Vor jeder Abarbeitung wird überprüft, ob durch mindestens
eine der Regeln Prder vorhergehenden Menge bereits ein oder mehrere Folgegraphen
hergeleitet wurden. Ist dies der Fall, so wird mit dem nächsten Graphen Gtin Zeile 4
fortgefahren.
4.4.3.3 Verifikationsverfahren
Um weitergehende Verifikationsverfahren wie etwa das Model Checking anwenden zu
können ist es notwendig, neben den erreichbaren Zuständen auch die Reihenfolge zu ken-
nen, in der diese erreicht werden. Eine entsprechende Erweiterung kann vorgenommen
werden, indem zu den Zuständen des Graphtransformationssystems zusätzlich die Über-
gänge angegeben werden. Ein solcher Zustand hG, Zisetzt sich zusammen aus einem
Graphen Gsowie einer Clockzone Z. Entsprechend müssen für eine weitere Analyse
die Übergänge hG, Zi×hG0, Z0idem Graphtransformationssystem hinzugefügt werden.
Diese Übergänge können in dem Algorithmus reachGTStbeim Anwenden der Funktion
production in Zeile 7 erzeugt werden. Dabei entstehen aus dem Graphen Gt:= (G, C,Z)
zusammen mit den Folgegraphen G0
tdie einzelnen Übergänge. G0
tsetzt sich dabei wieder-
110
4.4 Erreichbarkeitsanalyse
um aus einer Anzahl an Graphen G0
t:= (G0,C0,Z0)zusammen. Die Übergänge ergeben
sich aus dem Kreuzprodukt hG, Zi × hG0, Z0ifür alle G, Z aus Gt, und für alle G0, Z0der
G0
taus G0
t. Der Algorithmus reachGTStkann hierzu in Zeile 7 um die folgenden Zeilen
ergänzt werden:
for all G0
t∈ G0
t:G0
t:= (G0,C0,Z0do
TR := TR ∪ hG, Zi×hG0, Z0i
end for
TR bildet dabei die Menge der Transition ab, die innerhalb des Graphtransformationssys-
tems vorhanden sind.
4.4.3.4 Optimierung
Um den erzeugten Zustandsraum bei der Erreichbarkeitsanalyse möglichst klein zu hal-
ten, können bestimmte Teilzustände zusammengefasst werden. Dies betrifft die zeitlichen
Erreichbarkeitsräume Z, welche zusammen mit den einzelnen Graphen Geinen Zustand
hG, Zibilden. Dabei kann es vorkommen, dass bei unterschiedlichen Zuständen hG1, Z1i
und hG2, Z2ifür die beiden Clockzones Z1und Z2gilt, dass die eine Teilmenge der ande-
ren ist. Dies ist der Fall, wenn beide die gleichen Clockinstanzen enthalten und zusätzlich
für die aufgespannten Erreichbarkeitsräume gilt, dass Z1in Z2enthalten ist bzw. Z2in Z1
enthalten.
Falls dies der Fall ist und zusätzlich gilt, dass die beiden Graphen G1und G2isomorph
sind, kann der Zustand verworfen werden, bei dem die zugehörige Clockzone eine Teil-
menge der Clockzone des anderen Zustandes darstellt.
Um effizient feststellen zu können, ob eine Clockzone Teilmenge einer anderen ist, kann
mit der Datenstruktur der Difference-Bound-Matrice gearbeitet werden. Jede Clockzone
kann, wie in Kapitel 2.3.5.3 beschrieben, in Form einer Difference-Bound-Matrice dar-
gestellt werden. Jede Difference-Bound-Matrice kann in eine kanonische Form überführt
werden, womit entsprechende Vergleiche effizient möglich sind.
Eine derartige Optimierung macht nur Sinn, wenn keine erweiterten Verifikationsverfah-
ren angewendet werden sollen, für die gilt, dass diese die genaue Abfolge von erreichten
Zuständen kennen müssen. Dieser Fall ist etwa beim Model Checking gegeben. Dort ist
von Interesse, in welcher Reihenfolge die Zustände erreicht werden. Da durch die hier
aufgezeigte Optimierung einzelne Zustände wegfallen können, fallen damit entsprechen-
de Informationen über die logische Abfolge, in der diese erreicht wurden, ebenfalls weg.
111
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
4.5 Evaluierung
Die hier vorstellten Konzepte wurden in [Neu07] prototypisch in dem Werkzeug GROO-
VE2[Ren04, RKS06] umgesetzt. GROOVE ist ein Werkzeug zur Modellierung und Ana-
lyse von Graphtransformationssystemen. GROOVE bietet die Möglichkeit, den komplet-
ten Erreichbarkeitsraum eines Graphtransformationssystems zu erstellen. GROOVE be-
steht aus mehreren Teilwerkzeugen, einem Editor, Generator und Simulator. In dem Edi-
tor werden einzelne Graphtransformationsregeln erstellt, die später das Graphtransfor-
mationssystem aufspannen. Über den Simulator können später alle erreichbaren Zustände
ermittelt werden. Der Generator arbeitet ähnlich dem Simulator, jedoch ohne grafische
Oberfläche.
Das zu Beginn des Kapitels vorgestellte Beispiel (siehe Abschnitt 4.2.1) wurde in GROO-
VE modelliert. Dabei wurde das Beispiel erweitert derart, dass das Schienennetz nun auch
aus Weichen besteht, die zwei Ovale miteinander verbinden. Neben der einfachen Regel,
die eine Shuttlebewegung von einem Schienenabschnitt zum anderen beschreibt, muss
nun auch die Überfahrt einer Weiche mit Zeit beschrieben werden (siehe Abbildung 4.16).
Die vollständigen Regeln sind in Anhang B dargestellt.
Abbildung 4.16: Schienennetz
2http://groove.cs.utwente.nl/groove-home/
112
4.5 Evaluierung
In Abbildung 4.17 ist das aus der Erreichbarkeitsanalyse resultierende Graphtransfor-
mationssystem für das Beispiel dargestellt. Es besteht aus 28 Graphzuständen, 50 Tran-
sitionen zwischen den einzelnen Graphzuständen in Form von Kanten, sowie über 54
zeitliche Erreichbarkeitsräume. Die Analyse3hat 2Sekunden gedauert. Wird noch ein
weiteres Shuttle hinzugefügt, entstehen 165 Graphzustände, 537 Transitionen sowie 869
zeitliche Erreichbarkeitsräume. Bei diesem Szenario dauert die Analyse 7Sekunden.
Eines der größten Probleme bei der Analyse von komplexeren Modellen ist die steigen-
de Anzahl an Clockzones, welche zusammen mit den Graphzuständen einen Zustand des
erweiterten Graphtransformationssystems abbilden. Dies liegt vor allem daran, dass eine
Clockzone mit nClockinstanzen die Größe n2hat. Hier greift die Optimierung, welche
ebenfalls in GROOVE implementiert wurde. Ist diese aktiv, verringert sich die Anzahl
der zeitlichen Erreichbarkeitsräume bei dem Szenario mit drei Shuttles auf 698. Die Ana-
lyse hat hierbei 8Sekunden gedauert. Die erhöhte Analysezeit ist auf die Optimierung
zurückzuführen. Für eine detaillierte Auswertung des Optimierungsverfahrens wird auf
die Arbeit [Neu07] verwiesen.
Abbildung 4.17: Das resultierende Graphtransformationssystem
3Wurde auf einem Pentium 4, 2.4 GHz, 1 GB memory, OS Linux Redhat durchgeführt.
113
Kapitel 4 Verifikation des Verhaltens eines OCM in der Umwelt
4.6 Zusammenfassung
In diesem Kapitel wurden Modellierungs- und Verifikationstechniken für das äußere Ver-
halten eines OCMs in der Umwelt vorgestellt. Bei der Modellierung wurde auf den For-
malismus der Graphtransformationssysteme zurückgegriffen, der hier durch Zeitannota-
tionen angereichert wurde. Die Zeitannotationen basieren auf den Konzepten der Timed
Automata. Da diese aber nicht so einfach übernommen werden können, wurde hierzu
zuerst ein Vergleich beider Modelle diskutiert. Aufgrund dieser Erkenntnis wurden Kon-
zepte zur Modellierung von zeitbehafteten Graphtransformationssystemen definiert. Nach
der formalen Definition eines zeitbehafteten Graphtransformationssystems wurden an-
schließend die Erreichbarkeitsanalyse für ein solches System und Algorithmen hierfür
beschrieben. Am Ende des Kapitels wurde eine Evaluierung des Ansatzes gezeigt.
114
Kapitel 5
Parametrisierte
Koordinationsmuster
In den beiden vorangegangenen Kapiteln wurde beschrieben, wie sich ein OCM model-
lieren und verifizieren lässt. Der Fokus dieses Kapitels steht nun auf der Modellierung
und Verifikation der Koordination von OCMs in vernetzten mechatronischen Systemen.
Hierbei werden die bisher vorgestellten Techniken aus den vorangegangenen Kapiteln
miteinander geschickt verknüpft.
Ein wichtiges Problem bei vernetzten mechatronischen Systemen ist, dass jedes Teilsys-
tem eine potentiell unterschiedliche lokale Sicht haben kann, auf deren Basis jederzeit
Entscheidungen autonom und lokal getroffen werden müssen. Die Logik aller Teilsyste-
me muss dabei auf Basis dieser lokalen Sicht bei einem Teilausfall im Gesamtsystem
so koordiniert reagieren, dass Gefahren ausgeschlossen sind. Im Beispiel der „Neuen
Bahntechnik Paderborn“ (siehe Abschnitt 1.2) müssen die Shuttles trotz möglicher Fehler
immer ein sicheres Fahrmanöver garantieren. Diese Sicherheitseigenschaft muss für das
modellierte Verhalten des Shuttles überprüft werden. Diese Überprüfung muss alle mögli-
chen Situationen betrachten und den Ausschluss der Gefahren durch formale Verifikation
absichern.
Der bisherige MECHATRONIC UML Ansatz stellt das Konzept der Echtzeit-
Koordinationsmuster (siehe Grundlagen 2.4.2) zur Verfügung, um die Koordination
verteilter Komponenten zu modellieren und formal zu verifizieren. Weiter unterstützt
der Ansatz eine Integration der benötigten Steuer- und Regelungsalgorithmen (siehe
Grundlagen 2.4.4).
Ziel dieses Kapitels ist es nun, für Verifikationszwecke eine abstrakte Betrachtung des re-
levanten Werte- und Zeit-kontinuierlichen Verhaltens der Koordinationslogik zu ermög-
lichen. Dabei werden entsprechend benötigte Eigenschaften der unterlagerten Regelung,
die mit klassischen Techniken der Regelungstechnik und Mathematik verifiziert werden
können, als Basis für weitere Betrachtungen verwendet. Darauf aufbauend lässt sich dann
durch formale Verifikationstechniken für Echtzeitsysteme eine Verifikation der benötigten
115
Kapitel 5 Parametrisierte Koordinationsmuster
Sicherheitseigenschaften der Echtzeitkoordination bzgl. der relevanten Fehlerszenarien
erreichen.
Zuerst wird mit dem in den Grundlagen (siehe Kapitel 2.4.1) vorgestellten Ansatz zur
Modellierung der bisherigen Echtzeit-Koordinationsmuster das Beispiel der Konvoiko-
ordination noch einmal kurz beschrieben. Hieran werden anschließend die Grenzen des
bisherigen Ansatzes aufgezeigt (siehe Abschnitt 5.2). Anhand eines erweiterten Beispiels
wird in Abschnitt 5.3 die Idee eine Lösungsidee vorgestellt. Anschließend werden die in
diesem Kapitel neu eingeführten parametrisierten Koordinationsmuster in Abschnitt 5.4
zuerst informal eingeführt und später formalisiert. Abschließend werden die nötigen Ve-
rifikationsschritte für ein parametrisiertes Koordinationsmuster beschrieben. Das Kapitel
schließt mit einer Zusammenfassung in Abschnitt 5.5.
5.1 Beispiel
Mit dem kompositionellen Ansatz aus [GTB+03] ist es möglich, die Kommunikation zwi-
schen Komponenten durch so genannte Echtzeit-Koordinationsmuster (siehe Kapitel 2.4)
zu modellieren. Das Verhalten der Koordinationsmuster wird später bei der Anwendung
zum Verhalten der Komponenten verfeinert.
In Abbildung 5.1 ist ein Echtzeit-Koordinationsmuster dargestellt. Es besteht aus
mehreren Kommunikationspartnern, den so genannten Rollen. Rollen interagieren
über einen Connector, durch den sie verbunden sind. Das Verhalten der Rollen und
des Connectors wird durch Realtime Statecharts realisiert. Weiterhin besitzt eine
Rolle Invarianten, welche eingehalten werden müssen. Das ganze Verhalten eines
Echtzeit-Koordinationsmusters kann durch Constraints eingeschränkt werden.
In dem Beispiel wird die sichere Echtzeitkoordination in einem Konvoi für zwei hinter-
einander herfahrende Shuttles durch ein Echtzeit-Koordinationsmuster beschrieben. Das
Echtzeit-Koordinationsmuster ConvoyCoordination besitzt zwei Rollen, die Rolle shuttle
und die Rolle coordinator und einen Connector, der diese verbindet. Die Eigenschaft, die
das Echtzeit-Koordinationsmuster zu erfüllen hat, ist, dass wenn das hinterherfahrende
Shuttle im Konvoimodus ist, auch das vorherfahrende Shuttle im Konvoimodus sein muss
(shuttle.Convoy implies coordinator.convoy). Wäre das hinterherfahrende Shuttle näm-
lich im Konvoimodus, das vorherfahrende jedoch nicht, würde in einer Notfallsituation
das vorherfahrende Shuttle aufgrund der lokalen Information nicht richtig reagieren und
einen Auffahrunfall verursachen.
In Abbildung 5.2 ist die Anwendung des Echtzeit-Koordinationsmusters gezeigt. Im Bei-
spiel wendet das Shuttle shuttle2 die Rolle shuttle an und das Shuttle shuttle1 übernimmt
die Rolle coordinator.
116
5.2 Grenzen des bisherigen Ansatzes
shuttle coordinator
ConvoyCoordination
shuttle.convoy implies coordinator.convoy
Abbildung 5.1: Echtzeit-Koordinationsmuster ConvoyCoordination
<<Component>>
shuttle2 :Shuttle
shuttle <<Component>>
shuttle1 :Shuttle
coordinator
Abbildung 5.2: Anwendung des Echtzeit-Koordinationsmuster ConvoyCoordination
5.2 Grenzen des bisherigen Ansatzes
Der bisherige MECHATRONIC UML Ansatz stellt die fundamentalen Konzepte zur kom-
positionellen Modellierung und Verifikation zur Verfügung. Jedoch hat der bisherige ME-
CHATRONIC UML Ansatz eine Reihe von Einschränkungen hinsichtlich der zur Beschrei-
bung der Koordination von OCMs verwendeten Echtzeit-Koordinationsmuster. Dies lässt
sich an den folgenden zwei Punkten manifestieren.
Dynamik: Ein Echtzeit-Koordinationsmuster besteht a priori immer aus einer festen
Anzahl von Rollen. Anforderungen an komplexe, mechatronische Systeme sehen jedoch
mehr Dynamik vor. Am Beispiel des Shuttlekonvois ist dies gut zu verdeutlichen. So ist
nachzuvollziehen, dass ein Konvoi, um auch wirklich energieeffizient zu sein, aus mehr
als zwei Shuttles bestehen muss. Dabei ist die Anzahl der Konvoiteilnehmer zum Zeit-
punkt der Instanziierung des Koordinationsmusters unbekannt. Mal muss ein und dasselbe
Koordinationsmuster einen Konvoi der Länge kund im nächsten Moment einen Konvoi
der Länge k+ 1 koordinieren, ohne die Stabilität eines Konvois dabei zu verletzten.
Stabilität: Bei den bisherigen Echtzeit-Koordinationsmustern steht das Koordinations-
verhalten nicht in Verbindung mit dem Werte-kontinuierlichen Verhalten eines OCMs.
Um jedoch die Stabilität eines Shuttlekonvois zu erreichen und damit das „Aufschau-
keln“ und den so genannten Ziehharmonikaeffekt zu vermeiden, muss zusätzlich zur
reinen Echtzeitkoordination das Werte-kontinuierliche Verhalten berücksichtigt werden.
So müssen Brems- und Beschleunigungssituationen, die durch nicht-lineares Verhalten
beschrieben werden, berücksichtigt werden. Eine alleinige Verbindung beider Verhalten
durch das Synchronisationsstatechart innerhalb eines OCMs durch ein Hybrides Rekon-
117
Kapitel 5 Parametrisierte Koordinationsmuster
figurations Chart (siehe Grundlagen 2.4.4) kann dies noch nicht garantieren. Alleine die
Koordination durch einen Konvoiführer, der auch die Werte-kontinuierlichen Vorgaben
hinsichtlich Brems- und Beschleunigungssituationen initial vorgibt sowie bei dynami-
schen Änderungen zur Laufzeit diese neu verteilt, kann dies garantieren.
Durch das im Folgenden erweiterte Konvoibeispiel wird die Idee, wie diese Probleme
durch die Modellierung mit MECHATRONIC UML gefasst werden können, beschrieben.
5.3 Erweitertes Beispiel
Das erweiterte Beispiel setzt auf dem Beispiel aus Abschnitt 5.1 auf. Es wird nun
ein Konvoi der Länge nbetrachtet (siehe Abbildung 5.3). Bei der Verhaltensmodellie-
Abbildung 5.3: Konvoi der Länge n
rung für die Konvoibildung und -fahrt muss neben dem idealisierten fehlerfreien Fall
auch der Ausfall einzelner Systemelemente betrachtet werden. Das modellierte Verhalten
muss hierbei nicht tolerierbare Gefahren ausschließen. Durch Szenarien (siehe Echtzeit-
Sequenzdiagramme, Abschnitt 2.4.2) wurden die folgenden in dem vorliegenden Anwen-
dungsbeispiel identifizierten regulären Abläufe des Systems beschrieben:
(1) n-Shuttles fahren in einem Konvoi,
(2) Shuttle/Konvoi fährt auf ein weiteres Shuttle/Konvoi auf,
(3) n-Shuttles fahren unabhängig,
(4) Konvoi fährt mit Sicherheitsabstand hinter einem andern Konvoi und
(5) Auflösung eines Konvois in zwei unabhängige Konvois bzw. in n-Shuttles.
Anhand der Techniken zur Gefahrenanalyse, die von Tichy in seiner Arbeit vorgestellt
werden [Tic08], konnten die in den Szenarien beobachteten Hazards:
(i) die Kollision von mehreren Shuttles,
(ii) die Kollision eines Shuttles mit einem Gegenstand oder
118
5.3 Erweitertes Beispiel
(iii) die Entgleisung eines Shuttles
genauer analysiert werden. In Abbildung 5.4 ist ein Ausschnitt eines Fehlerbaums darge-
stellt, der den Hazard Kollision mehrerer Shuttles genauer analysiert und beschreibt. Es
ist zu sehen, dass entweder der (a) Ausfall eines einzelnen Shuttles oder der (b) (partielle)
Ausfall des Netzwerks oder gar der (c) Ausfall des Streckenstators zu dem Hazard füh-
ren kann. Die primären Ereignisse, die jeweils die Ursache darstellen, werden hier nicht
genauer beschrieben (grau dargestellt).
Ausfall eines
Shuttles (partieller)Ausfall
des Netzwerks Ausfall
Streckenstator
Kollision mehrerer
Shuttles
≥1
&≥1≥1
Abbildung 5.4: Fehlerbaum
Die Analyse sowie der Fehlerbaum sind nicht vollständig, sondern sollen hier nur an-
deuten, welches Fehlverhalten von dem Protokollverhalten bei einen Konvoi abgedeckt
werden muss, um ein sicheres Konvoimanöver zu garantieren.
5.3.1 Lösungsidee
Um die in Abschnitt 5.2 aufgezählten und im Abschnitt 5.3 am Beispiel verdeutlich-
ten Anforderungen adäquat für die Modellierung und Verifikation umzusetzen, wird im
Folgenden eine Lösungsidee vorgestellt. Um die Komplexität auch hier zu beherrschen,
wird das Zeit-kontinuierliche Verhalten getrennt vom Werte-kontinuierlichen Verhalten
betrachtet. In Abbildung 5.5 ist die Idee der Dekomposition skizziert. Die obere Hälfte
der Abbildung zeigt die Modellierung des Komponentenverbunds eines Shuttlekonvois.
Jede Komponente kommuniziert mit ihrer Nachbarkomponente. In einer Komponente
selber ist das interne, sowohl Zeit-kontinuierliche als auch Werte-kontinuierliche Ver-
halten, skizziert. Der untere Teil der Abbildung zeigt die Dekomposition des Modells.
Der Komponentenverbund wurde in die Kommunikation und die Komponenten (siehe
119
Kapitel 5 Parametrisierte Koordinationsmuster
Kompositioneller Ansatz), aufgeteilt. Weiterhin wurde auch das interne Verhalten de-
komponiert. So ist zu erkennen, dass nun das Zeit-kontinuierliche Verhalten von dem
Werte-kontinuierlichen Verhalten getrennt ist. Dies ermöglicht, wie schon beschrieben,
eine getrennte Verifikation der einzelnen Verhalten, welches im Folgenden beschrieben
wird.
shuttle1: Shuttleshuttle2: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
shuttle3: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
:P :P
shuttle1: Shuttleshuttle2: Shuttle
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
shuttle3: Shuttle
:P :P
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
0
5
10
15
20
25
01234
t [s]
s[m]
µ
max
µ
ist
µ
min
µ
max
µ
ist
µ
min
Abbildung 5.5: Dekomposition der Struktur
Zeit-kontinuierliche Verhalten: Um das Zeit-kontinuierliche Verhalten für eine be-
liebige Anzahl von gleichen Rollen zu modellieren, werden parametrisierte Rollen ver-
wendet. Eine parametrisierte Rolle steht hierbei für eine Menge von Unterrollen, die sich
untereinander synchronisieren können, um nach außen hin als eine Einheit aufzutreten.
In Abbildung 5.6 ist dies schematisch dargestellt. Mparam ist hierbei eine parametrisier-
te Rolle. Bei der Anwendung wird das Verhalten wie in der Abbildung dargestellt. Die
parametrisierte Rolle wird quasi entfaltet. Die einzelnen Unterrollen koordinieren sich
untereinander durch ausgezeichnete Signale. In dem Beispiel ist es das Signal nexti.
Eine Unterrolle kann als Struktur aufgefasst werden. Das Hinzufügen und das Löschen
von einzelnen Unterrollen kann durch zeitbehaftete Graphtransformationssysteme be-
schrieben werden. Diese besitzen die Möglichkeit, strukturdynamische Änderungen mit
Zeitbedingungen zu modellieren (siehe Kapitel 4). Die Integration der Graphtransfor-
mationssysteme geschieht nach dem von Klein [HHG08][Kle08] vorgestellten Ansatz.
120
5.3 Erweitertes Beispiel
!next2!next3?nextn
……………..
?next2
M1M2
M
Mn
Mparam
Parametrisierte Rolle Mparam
Entfaltete parametrisierte Rolle - Koordination der Unterrollen
Abbildung 5.6: Parametrisierte Rolle mit zugehöriger Entfaltung und Koordination der
Unterrollen
Hierbei wird ein gemeinsames Metamodell zur Integration beider Formalismen vorge-
schlagen. Nachdem nun die Idee für die Modellierung des Zeit-kontinuierlichen Verhal-
tens skizziert wurde, wird die Lösungsidee für das Werte-kontinuierliche Verhalten vor-
gestellt.
Werte-kontinuierliche Verhalten: Basis der Lösungsidee sind Fahrprofile, die den
Shuttles, die an einem Konvoi teilnehmen, von einem Leitfahrzeug zugeteilt werden. Im
Normalbetrieb werden diese Fahrprofile ständig der aktuellen Situation angepasst und
zwischen den Fahrzeugen kommuniziert. Ein solches Fahrprofil beinhaltet im Wesentli-
chen einen Bremskorridor, der dem jeweiligen Shuttle vorgibt, wie es sich in den verschie-
denen betrachteten Gefahrensituationen zu verhalten hat. Maßgeblich wird ein Bremskor-
ridor durch die physikalischen Eigenschaften eines Shuttles sowie durch die Position des
Shuttles im Konvoi bestimmt. Um die Gefahr einer Kollision zu vermeiden, werden hier
die diskutierten Ausfälle (a), (b) und (c) betrachtet.
Ein Ausfall eines Shuttles (Ausfallszenario (a)) und der partielle Ausfall des Netzwerks
(Ausfallszenario (b)) ist Abbildung 5.7(a) zu entnehmen. In dem dort betrachteten Szena-
121
Kapitel 5 Parametrisierte Koordinationsmuster
rio fällt Fahrzeug 2aus. Die Fahrzeuge, die sich in dem Konvoi vor Fahrzeug 2befinden,
hier Fahrzeug 1, fahren weiter. Die Fahrzeuge, die sich hinter Fahrzeug 2befinden, hier
Fahrzeug 3, bremsen so stark wie möglich ab.
Abbildung 5.7(b) zeigt das Bremsverhalten bei einem Statorausfall. Um eine Kollision
bei dem Bremsvorgang zu vermeiden, bremsen die Fahrzeuge zeitverzögert, wodurch die
Bremskorridore disjunkt sind und damit keine Kollision auftreten kann.
(a) Bremsverhalten Netzwerkausfall Fahrzeug 2(b) Bremsverhalten Statorausfall
Abbildung 5.7: Mögliches Bremsverhalten
Nachdem nun die Ideen skizziert wurden, werden im Folgenden detailliert der regelungs-
technische Entwurf sowie der Softwaretechnische Entwurf zur Modellierung und Verifi-
kation beschrieben.
5.3.2 Regelungstechnischer Entwurf
Ausgangspunkt für die hier betrachteten Überlegungen ist ein geregeltes Fahrzeug. Dabei
müssen die zwei grundlegenden Fälle der Geschwindigkeitsregelung und der Abstands-
bzw. Positionsregelung unterschieden werden. Ein einzelnes Fahrzeug bzw. das erste
Fahrzeug im Konvoi soll sich mit einer vorgegebenen Geschwindigkeit vsoll bewegen. Die
folgenden Fahrzeuge haben im Konvoi eine auf das Führungsfahrzeug bezogene Positi-
on einzunehmen und einen bestimmten Abstand zum direkt vorausfahrenden Fahrzeug
einzuhalten. Um die Regelungen für die beiden beschriebenen Fälle auszulegen, wur-
de zunächst ein Fahrzeug als Starrkörper mit dem Entwicklungswerkzeug CAMeL-View
[Ric96] modelliert, wobei nur die Längsdynamik berücksichtigt wird. Für die Geschwin-
digkeitsregelung genügt hier ein einfacher PI-Regler mit Anti-Windup (Abbildung 5.8),
122
5.3 Erweitertes Beispiel
um Probleme durch den Integratoranteil zu vermeiden, die sich aus der Begrenzung der
Antriebskraft ergeben. Der Linearantrieb ist im Modell vereinfacht durch ein Verzöge-
rungsglied erster Ordnung mit nachgeschaltetem Begrenzer abgebildet.
Abbildung 5.8: CAMeL-View-Modell eines geschwindigkeitsgeregelten Fahrzeugs
Dieser Geschwindigkeitsregelung ist für die Konvoifahrzeuge ein Abstands- bzw. Positi-
onsregler überlagert, der einerseits die Position des Fahrzeugs bezogen auf die aktuelle
Position des führenden Fahrzeugs regelt, andererseits den Abstand und die Differenzge-
schwindigkeit zum direkt vorausfahrenden Fahrzeug berücksichtigt, um Kollisionen aus-
schließen zu können [HVB+05]. Durch diese Regelungsstrategie kann die Stabilität eines
Konvois auch für längere Konvois garantiert werden. Allerdings ist dafür die Kommuni-
kation jedes Fahrzeugs mit dem direkt vorausfahrenden Fahrzeug und dem Leitfahrzeug
notwendig. Die erforderliche Kommunikationsstruktur ist in Abbildung 5.9 dargestellt.
Sie gliedert die Informationsverarbeitung anhand der im Grundlagenkapitel vorgestellten
Strukturierung mechatronischer Systeme (siehe Abschnitt 2.1) hier in Autonome Mecha-
tronische Systeme (AMS), nämlich den einzelnen Fahrzeugen, und Vernetzte Mechatro-
nische Systeme (VMS), den gesamten Konvoi. Die hier vorgeschlagene Regelung eines
Konvois wurde bereits erfolgreich im RailCab-Projekt umgesetzt und in der Praxis er-
probt [HTBS08]. Die vorgestellte Regelung geht von idealisierten Bedingungen unab-
Abbildung 5.9: Struktur der Informationsverarbeitung im Konvoi
hängig von äußeren Einflüssen, Unterschieden in der Fahrzeugdynamik und den eingangs
erwähnten möglichen Fehlern aus. Um den kollisionsfreien Betrieb des realen Systems
123
Kapitel 5 Parametrisierte Koordinationsmuster
gewährleisten zu können, sind also zusätzliche Überlegungen erforderlich. Der hier vor-
gestellte Ansatz zielt darauf ab, gewisse Grenzen für das Verhalten eines einzelnen Fahr-
zeugs nachzuweisen, die das geregelte System mit Sicherheit nicht überschreitet.
Wir betrachten hier als mögliche Fehler (a) den Ausfall des Antriebsmotors eines Shutt-
les, (b) den Kommunikationsausfall und (c) den streckenseitigen Ausfall des Motors (Sta-
torausfall). Tritt einer dieser Fehler auf, müssen die betroffenen und alle nachfolgenden
Fahrzeuge bis zum Stillstand abgebremst werden1. Für das Bremsen stehen drei Möglich-
keiten zur Verfügung. Die notwendige Bremskraft kann über den Linearantrieb erzeugt
werden. In diesem Fall kann auf ein vorgegebenes Geschwindigkeitsprofil zurückgegrif-
fen werden, das kontrolliertes Bremsen ermöglicht. Zusätzlich existiert eine mechanische
Notbremse, die über Federn Bremsklötze direkt auf die Schienen drückt. Außerdem kön-
nen beide Bremsen gleichzeitig eingesetzt werden. Je nach auftretendem Fehler stehen
allerdings nicht alle drei Möglichkeiten zur Verfügung. Fällt der Linearantrieb strecken-
oder fahrzeugseitig aus, kann nur die mechanische Notbremse eingesetzt werden. Dieser
Fall soll beispielhaft für die Vorausberechnung von Grenzen betrachtet werden, die das
System unter Berücksichtigung der Modellunsicherheiten einhält.
Der tatsächliche Bremsweg hängt bei den mechanischen Notbremsen im Wesentlichen
von den Fahrzeugeigenschaften wie Masse und aktuelle Geschwindigkeit und dem Reib-
koeffizienten µab. Da dieser nicht als exakt bekannt vorausgesetzt werden kann, muss
man auf Minimal- bzw. Maximalwerte zurückgreifen. Ein mechanisch gebremstes Fahr-
zeug wird dann in einem Bereich zwischen dem minimal und maximal möglichen Brems-
weg zum Stehen kommen. In Abbildung 5.10 ist das Ergebnis einer Simulation dieser Si-
tuation dargestellt, bei der der Reibkoeffizient während des Bremsvorgangs bei t= 1,7s
sprungförmig abnimmt. Das Fahrzeug bewegt sich innerhalb der für die Position und Ge-
schwindigkeit vorausberechneten Korridore für µmin und µmax, die ohne exakte Kenntnis
des tatsächlichen Reibkoeffizienten angegeben werden können. Für Bremsvorgänge mit
dem Linearantrieb lassen sich diese Korridore noch genauer vorhersagen, da dann das
Bremsen vom Geschwindigkeitsregler kontrolliert nach einem vorgegebenen Profil ab-
läuft. Auf diese Weise kann jedes Fahrzeug vorausberechnen, in welchen Grenzen es sich
im Fall einer der drei möglichen Notbremsungen bewegen wird. Darauf aufbauend lässt
sich überlagert das Verhalten der Fahrzeuge im Konvoi und im Fehlerfall modellieren und
mit den im Folgenden beschriebenen Verfahren verifizieren.
1Bei Kommunikationsausfall sind auch andere kontrollierte Manöver denkbar, z.B. das autonome Fahren
mit vergrößertem Abstand mit Hilfe von Abstandssensoren. Diese Betrachtungen ändern nichts an dem
vorgestellten Ansatz zur Verifikation des sicheren Verhaltens und werden deshalb nicht näher betrachtet.
124
5.3 Erweitertes Beispiel
0
5
10
15
20
25
0 1 2 3 4
t [s]
-2
0
2
4
6
8
10
1 2 3 4
t [s]
0
s [m]
v [m/s]
µmax
µist
µmin
µmax
µist
µmin
Abbildung 5.10: Bremskorridore bei einer mechanischen Notbremsung
5.3.3 Softwaretechnische Umsetzung
Um nun die neuen Anforderungen, beliebige Anzahl von Rollen sowie Werte-
kontinuierliches Reglerverhalten zu integrieren, wird das Konzept der modell-basierten
Entwicklung mit Echtzeit-Koordinationsmustern erweitert.
Hierzu werden zum einen Abstraktionstechniken eingesetzt, die auf den zugesicherten
Eigenschaften der Regler aufbauen (siehe letzter Abschnitt). Um eine Verifikation durch-
führen zu können wird neben Model Checking das Verfahren der Induktion eingesetzt,
um Verhaltenseigenschaften über die Struktur zu beweisen. Dies wird im Folgenden ange-
deutet. Kontinuierliche Systeme besitzen einen unendlichen Zustandsraum. Dieses macht
eine formale Verifikation durch Model Checking alleine unmöglich, da hier ein endlicher
Zustandsraum benötigt wird. Um dennoch Werte-kontinuierliches, regelungstechnische
Verhalten zu verifizieren, im vorliegenden Fall kontinuierliches Beschleunigungsverhal-
ten, wird dieses durch Abstraktionstechniken auf ein endliches, diskretes System abge-
bildet. Der Abstraktion liegen die zugesicherten Eigenschaften des Reglers zu Grunde.
Dadurch ist es möglich, das Verhalten dieser einzuschränken. In dem Beispiel wird das
Verhalten durch so genannte Bremskorridore beschrieben. Diese geben das minimale und
maximale Beschleunigungsverhalten eines Shuttles an. Hierdurch ist es möglich, bei der
Modellierung das Verhalten der Shuttles weiterhin durch diskrete Zustände zu beschrei-
ben und die formale Verifikation durch Model Checking durchzuführen. Durch z.B. nu-
merische Überprüfung [Pra05][PJ04][PP05] muss nun vorab verifiziert werden, ob sich
die Bremskorridore schneiden oder nicht. Diese Überprüfung kann auch zur Laufzeit bei
Neuverteilung der Profile effizient durchgeführt werden.
Durch geeignete Modellierung des Kommunikationsprotokolls werden diese Eigenschaf-
ten im System umgesetzt. Um mit der beliebigen Anzahl nzurecht zu kommen, werden
hierfür parametrisierte Rollen verwendet. Jedem Shuttle wird ein so genanntes Fahrprofil
125
Kapitel 5 Parametrisierte Koordinationsmuster
pizugeordnet. Dieses beinhaltet u.a. das Verhalten, wie es sich in Notfallsituationen zu
verhalten hat. Insgesamt gibt es nFahrprofile. Für die Fahrprofile gilt die Eigenschaft,
dass piimmer eine Notfallreaktion in einem Konvoi garantiert, die ein Shuttle mit Fahr-
profil pjnicht in Gefahr bringt, wobei i <=j, gelten muss. In Abbildung 5.7(b) hat das
vorausfahrende Shuttle 1das Fahrprofil p2und Shuttle 2und Shuttle 3das Fahrprofil p1.
Dieses Verhalten wird formal über die Struktur des Modells (Konvoiteilnehmer) mittels
Induktion bewiesen. Da das Hinzufügen und Löschen von Unterrollen durch zeitbehafte-
te Graphtransformationssysteme beschrieben wird, kann zur Verifikation der Ansatz aus
Kapitel 4 herangezogen und mit Model Checking geschickt verknüpft werden.
Abbildung 5.11 skizziert die Struktur des ConvoyCoordinator. Die gestrichelten Pfeile
deuten die Abarbeitungsreihenfolge der beteiligten Rollen an, welche durch das Protokoll
realisiert werden muss.
<<Component>>
<<Component>>
coordinator :Coordinator
Shuttle
shuttlen
pi
shuttle2
pi
shuttle1
pi
Abbildung 5.11: Modellierung und Koordination eines multi-Ports – jedem Port und da-
mit Shuttle wird eine Eigenschaft pizugeordnet
In Abbildung 5.12 ist in einem Sequenzdiagramm beispielhaft die Konvoikommunikation
für drei Shuttles modelliert. Hierbei ist der Coordinator als einzelne Komponente model-
liert. Diese kann sich aber als Unterkomponente auf dem Führungsshuttle befinden. Es ist
zu sehen, dass sich zuerst alle Shuttles bei dem Coordinator registrieren. Der Coordinator
berechnet daraufhin eine gültige Profilreihenfolge für die Shuttles und weißt diese ent-
sprechend zu. Periodisch wird nun die Erreichbarkeit aller Shuttles überprüft. Wenn die
Erreichbarkeit ausbleibt, also ein potentieller Netzwerkausfall vorliegt, werden von den
einzelnen Shuttles die entsprechenden Notfallroutinen gefahren, die durch das Profil, das
hierfür das regelungstechnische Verhalten vorgibt, bestimmt ist.
5.4 Parametrisierte Koordinationsmuster
In diesem Abschnitt wird das Konzept der neuen parametrisierten Koordinationsmuster
beschrieben. Hier werden die eben beschriebenen Modellierungskonzepte integriert.
126
5.4 Parametrisierte Koordinationsmuster
shuttle1:Shuttle cc:ConvoyCoordinator
shuttle2:Shuttle
init(id,profile)
buildConvoy(convoyPosition,newProfile)
init(id,profile)
buildConvoy(convoyPosition,newProfile)
ping()
ack
ack
ack ack
ack
ping()
ack
ping()
ping()
ack
emergency
emergency / breakConvoy
shuttle3:Shuttle
init(id,profile)
ack
buildConvoy(convoyPosition,,newProfile)
ack
ping()
ping()
ack
ack
ping()
breakConvoy()
ack
Nachricht1
emergency
ping()
convoyPosition:=calculateConvoyOrder();
newProfile:=calculateProfile():
Abbildung 5.12: Beispielkommunikation für 3Shuttles im Konvoi mit Netzwerkausfall
5.4.1 Informale Beschreibung
Genau wie die einfachen Echtzeit-Koordinationsmuster bestehen die parametrisierten
Koordinationsmuster aus Rollen und Connectoren. Dabei richtet sich die grundsätzliche
Idee der parametrisierten Koordinationsmuster nach den in der UML (siehe [OMG07],
Seite 168ff) beschriebenen Collaborations. In der UML werden die Collaborations ver-
wendet, um die dynamischen Beziehungen zwischen Rollen zu beschreiben. Jedoch ist
dies auf die reine Software bezogen, so dass kontinuierliche Aspekte (Stabilität) sowohl
auf der Ebene der Struktur als auch bei den Constraints, nicht berücksichtigt werden.
Abbildung 5.13 zeigt ein parametrisiertes Koordinationsmuster für die Konvoikoordina-
tion von nShuttles. Ein optionales Modellelement sind die multi-Rollen. Multi-Rollen
127
Kapitel 5 Parametrisierte Koordinationsmuster
werden durch überlappende Quadrate dargestellt und besitzen eine Kardinalität n. Multi-
Rollen sind eine vereinfachte Darstellung für eine Menge von gleichen Rollen, die zum
gleichen Typ einer Komponente gehören. Im vorliegenden Beispiel der Konvoikoordina-
tion besitzt die Rolle shuttle die Kardinalität 1und die coordinator Rolle die Kardinalität
n. Dieses bedingt eine eindeutige Zuordnung jeder „einfachen Rolle“ einer multi-Rolle
zu einem eindeutigen Gegenpart, ähnlich wie bei einer 1zu nAssoziation in Klassendia-
grammen. Weiterhin ist es möglich, multi-Rollen mit Attributen wie {ordered} zu verse-
hen. Hierdurch wird eine Reihenfolge für die Auswertung der Rollen festgelegt. Weiterhin
hat jedes parametrisierte Koordinationsmuster Constraints, die das Verhalten, besonders
das der Profileigenschaften, beschreiben. Das Constraint ∀k,l∧k<l(Sk
pi, Sl
pj)⇒ |i−j| ≤ 1
beschreibt die Eigenschaft, dass die Profilreihenfolge zweier benachbarter Shuttles immer
monoton ist und sich die Profile in ihrem Index niemals um mehr als 1unterscheiden.
ConvoyCoordination
n 1
{ ordered }
Abbildung 5.13: Parametrisiertes Koordinationsmuster
In Abbildung 5.14 ist der Typ Shuttle dargestellt. Die Komponente bettet zwei Unter-
komponenten Coordinator und VelocityControl ein. Das Verhalten der Komponenten ist
wie folgt definiert. Da die Komponente das parametrisierte Koordinationsmuster Convoy-
Coordination anwendet, muss sie sowohl als coordinator als auch als shuttle fungieren.
Der multi-Port ist durch eine Assembly mit der inneren Komponente Coordinator und Ve-
locityControl verbunden, um das obige Verhalten zu realisieren. Die flache Komponente
Coordinator realisiert die Berechnung sowie die Abspeicherung aller Profile im Führungs-
shuttle. Bei der Berechnung der Profile wird die aktuelle Geschwindigkeit benötigt. Die
Komponente VelocityControl bettet eine kontinuierliche Reglerkomponente ein, welche
diese Daten kontinuierlich zur Verfügung stellt.
In Abbildung 5.15 ist die Laufzeit-Instanz von zwei Shuttles dargestellt, welche das para-
metrisierte Koordinationsmuster ConvoyCoordination anwenden.
Das Verhalten bestimmt sich, wie in der Lösungsidee 5.3.1 beschrieben, sowohl durch
zeitbehaftete Graphtransformationssysteme als auch durch parametrisierte Automaten.
Dieses wird im Folgenden beschrieben.
128
5.4 Parametrisierte Koordinationsmuster
<< Component >>
Shuttle
<< Component >>
c: Coordinator
<< Component >>
vc1: VelocityControl
Abbildung 5.14: Der Typ Shuttle
<<Component>>
shuttle2 :Shuttle
shuttle coordinator <<Component>>
shuttle1 :Shuttle
Abbildung 5.15: Laufzeit-Instanz zweier Shuttles, welche das parametrisierte Koordina-
tionsmuster ConvoyCoordination anwenden
5.4.2 Modellierung des Verhaltens eines parametrisierten
Koordinationsmusters
5.4.2.1 Verhalten der Rollen
Wie schon in der im Abschnitt 5.3.1 skizzierten Lösung beschrieben werden, um die
multi-Rollen zu beschreiben, parametrisierte Automaten verwendet.
Die neue parametrisierte Rolle coordinator des parametrisierten Koordinationsmusters
ist in Abbildung 5.16 dargestellt. Die Erweiterungen hinsichtlich der Parameter bezie-
hen sich auf die Synchronisationskanäle nextkund nextFailedk. Über diese Kanäle syn-
chronisieren sich die nRollen untereinander. Die Rolle befindet sich initial im Zustand
WaitForTrigger. Empfängt die Rolle das nextkTriggersignal (initial vom Synchronisa-
tionsstatechart und danach von der Vorgängerrolle), schaltet die Rolle in den Zustand
Idle. Nun beginnt der Kommunikationsaustausch mit der shuttle Rolle. Es wird ein up-
date Signal mit dem aktuellen Profil, welches das Shuttle annehmen soll, sowie der Be-
zugsgeschwindigkeit und der Bezugsposition verschickt. Danach wartet die Rolle in dem
Zustand SentAcknowledge auf die Bestätigung acknowledge des Gegenparts, der Rolle
shuttle. Wird diese empfangen, schaltet die Rolle wieder in den Zustand WaitForTrigger
und sendet dabei das nextk+1 Signal, um die nächste Rolle zu aktivieren. Empfängt die
Rolle kein acknowledge, schaltet die Rolle in den Zustand NextFailed und signalisiert
dies dem Synchronisationsstatechart, um geeignete Routinen zu aktivieren. Weiterhin be-
129
Kapitel 5 Parametrisierte Koordinationsmuster
sitzt die Rolle den Zustand StatorFailure. Dieser wird vom Zustand Idle erreicht, falls die
zugehörige shuttle Rolle dieses Signal propagiert.
Idle SentAcknowledge
WaitForTrigger NextFailed
shuttle.acknowledge(s_act,v_act)
/ shuttle.update(profile,s_ref,v_ref)
shuttle.publishStatorFailure
StatorFailure Stop
? nextFailedk
? nextFailedk
! nextk+1
? nextk
Abbildung 5.16: Das Verhalten einer parametrisierten Rolle coordinator
Die Rolle shuttle (siehe Abbildung 5.17) besteht aus drei Zuständen. Initial befindet sie
sich im Zustand Normal. Spätestens alle 150 Zeiteinheiten muss die Rolle ein update
Signal von der zugehörigen coordinator Rolle empfangen. Dies ist durch eine Selbsttran-
sition am Zustand realisiert. Das Signal beinhaltet das aktuelle Profil profile, die Bezugs-
position und die Bezugsgeschwindigkeit. Die Rolle bestätigt den Erhalt des Signals durch
ein acknowledge Signal, welches die aktuelle Position und die aktuelle Geschwindigkeit
enthält. Falls kein update Signal empfangen wird (z.B. Ausfall des Netzwerks), schaltet
die Rolle nach 150 Zeiteinheiten in den Zustand NetworkFailure. Der Zustand StatorFai-
lure wird nicht-deterministisch erreicht. Dabei wird der Fehler dann an die zugehörige
coordinator Rolle propagiert.
Nachdem nun die Rollen modelliert sind ist die Frage, wie sich diese in die Architektur
integrieren lassen. In Abbildung 5.18 ist hierfür eine hierarchische Architektur, die sich
nach dem kompositionellen Ansatz aus [GTB+03] richtet, vorgeschlagen. Hierbei wird
vorgeschlagen, eine zusätzliche Koordinationsschicht einzufügen. Diese Koordinations-
schicht beinhaltet einen weiteren Automaten, der es ermöglicht, die multi-Ports mit dem
eigentlichen Synchronisationsstatechart zu verbinden. Falls nur ein einfacher Port exis-
tiert, ist ein solcher Automat nicht notwendig.
Eine Shuttle Komponente, welche das parametrisierte Koordinationsmuster ConvoyCoor-
dination anwendet, muss sowohl als coordinator als auch als shuttle agieren. Ein Aus-
schnitt des Synchronisationsstatechart, dass beide Rollen triggern kann, je nachdem, in
welcher sich ein Shuttle befindet, ist in Abbildung 5.19 dargestellt. Die Entscheidung, ob
ein Konvoi erzeugt werden soll und welche Rolle das Shuttle einnimmt, wird vorher durch
den kognitiven Operator (siehe Kapitel 2.1) bestimmt, der Informationen z.B. von einer
130
5.4 Parametrisierte Koordinationsmuster
{timer}
Normal
timer<=150
150<=timer<=150 NetworkFailure
assert: controlledBrake
StatorFailure
assert: mechanicalBrake
0<=timer<150
{timer}
/ coordinator.statorFailure
coordinator.publishStatorFailure
coordinator.update(profile[i],s_ref,v_ref)
/ coordinator.acknowledge(s_act,v_act), currentProfile=profile[i]
Abbildung 5.17: Das Verhalten der Rolle shuttle
synchronization
...
m
1
coordinator
shuttle
<<Component>>
Shuttle
coordinator.adaption
coordinator.role1
coordinator.rolen
shuttle.role
Abbildung 5.18: Hierarchische Architektur
Schienenabschnittskontrolle über die Position und Reihenfolge der Shuttles bekommen
hat. Die Signale ?convoyUseful,?shuttle und ?coordinator werden entsprechend getrig-
gert. Anschließend initiiert das jeweilige Synchronisationsstatechart die entsprechenden
131
Kapitel 5 Parametrisierte Koordinationsmuster
Wait
NoConvoy Init
AddShuttlePort
SafeRestore
Shuttle Init
Default
Default
? convoyUseful ? coordinator
Coordinator
? restoreConvoy
? restoreConvoy
? shuttle
! start
! createPort(shuttle)
! accelerate(profile)
! coordinateShuttle
! coordinateShuttle
Abbildung 5.19: Synchronisationsstatecharts der Komponente Shuttle
Rollen, indem es das Signal start an die Rolle shuttle bzw. das Signal coordinateShuttle
an die Rolle coordinator sendet.
Ein Konvoi wird aufgehoben, wenn ein Fehler festgestellt wurde. Diese werden von den
Rollen festgestellt, wenn z.B. ein Signal nicht in der vorgegebenen Zeit angekommen ist.
Das Synchronisationsstatechart beginnt dann, nach der vorgegebenen Profil zu fahren. Die
Wiederherstellung und weitere Details werden hier nicht betrachtet.
Der neue Automat, in der Abbildung 5.18 als coordinator.adaptation bezeichnet, wird
durch das Synchronisationsstatechart getriggert. Danach hat es die Möglichkeit, die Akti-
on CreatePort(shuttle), getriggert durch das Signal createPort, eine neue Rolle der multi-
Rolle hinzuzufügen. Die neue Rolle wird entsprechend der Strukturregeln (siehe folgen-
der Abschnitt 5.4.3) angelegt. Hierbei wird auch entsprechend der Parameter kinkremen-
tiert. Dieser gibt Auskunft über die Anzahl der Shuttles und somit ist es möglich, immer
die nächste Rolle eines multi-Ports, entsprechend der vorgegebenen Eigenschaft ordered,
anzusprechen (siehe Abbildung 5.20).
In Abbildung 5.21 ist die verfeinerte shuttle Rolle dargestellt. Um dem Verhalten des
Synchronisationsstatecharts zu genügen, konsumiert es das Signal start. Falls ein Fehler
entdeckt wird, propagiert die Rolle ein entsprechendes Signal an das Synchronisations-
statechart.
Nachdem nun das Verhalten komplett modelliert ist, ist die Frage, wie sich die dynami-
schen Strukturänderungen zur Laufzeit modellieren lassen.
132
5.4 Parametrisierte Koordinationsmuster
Wait
IdleFailure
!restoreConvoy
AddPort
/createPort(shuttle)
k++
/createPort(shuttle)
?createPort
?createPort
/createPort(shuttle)
? coordinateShuttle
! nextFailedn+1 ! nextn+1
n==k?n=1:n++
! next1
k:=1
k:=1 ? coordinateShuttle
Abbildung 5.20: Koordinationsstatechart für die multi-Rolle
Wait
{timer}
Normal
timer<=150
150<=timer<=150 NetworkFailure
assert: controlledBrake
StatorFailure
assert: mechanicalBrake
0<=timer<150
{timer}
/ coordinator.statorFailure
coordinator.publishStatorFailure
coordinator.update(profile[i],s_ref,v_ref)
/ coordinator.acknowledge(s_act,v_act), currentProfile=profile[i]
?start
! restoreConvoy
! restoreConvoy
?start
{timer}
Abbildung 5.21: Verfeinerte shuttle Rolle
5.4.3 Modellierung der dynamischen Strukturänderungen
Im Folgenden werden die Regeln, welche die erlaubten Strukturänderungen des parame-
trisierten Koordinationsmusters angeben (siehe 5.3.1), beschrieben. Die erlaubten Struk-
turregeln werden in das Verhalten integriert, wie in [HHG08] beschrieben. Um die Re-
133
Kapitel 5 Parametrisierte Koordinationsmuster
geln zu strukturieren, werden sie in Erweiterungsregeln und Reduzierungsregeln aufge-
teilt. Alle möglichen strukturellen Rekonfigurationsschritte für ein parametrisiertes Ko-
ordinationsmuster werden durch zeitbehaftete Graphtransformationsregeln (siehe Kapitel
4) beschrieben.
5.4.3.1 Erweiterungsregeln
In Abbildung 5.22 ist die initiale Regel, die erste Erweiterungsregel, welche das para-
metrisierte Koordinationsmuster für zwei Shuttles anwendet, dargestellt. Damit ist ein
eindeutiger Startgraph festgelegt. Wenn das parametrisierte Koordinationsmuster das ers-
te Mal angewendet wird, wird bei dem Führungsshuttle ein multi-Port angelegt. Das
hinterherfahrende Shuttle bekommt einen einfachen Port. Die Ports werden durch einen
Connector verbunden. Die Zeitbedingung t > 5(siehe Kapitel 4) gibt an, dass dies min-
destens 5Zeiteinheiten benötigt. Um auch eine Obergrenze für diese Aktion festzulegen,
ist in Abbildung 5.23 eine Invariantenregel (siehe Kapitel 4) dargestellt, die dem Graph-
transformationssystem hinzugefügt wird. Weiterhin wird dem Connector der Stereotyp
lasthinzugefügt. Dieser gibt an, dass das hinterherfahrende Shuttle das letzte im
Konvoi ist. Damit ist markiert, an welcher Stelle neue Shuttles dem Konvoi beitreten kön-
nen.
Natürlich muss bei der Anwendung des parametrisierten Koordinationsmusters auch das
interne Verhalten sowie die interne Komponentenstruktur eines Shuttles rekonfiguriert
werden. Dies ist in der initialen Regel 5.22 ebenfalls angedeutet. Hier wird bei der Er-
zeugung des parametrisierten Koordinationsmusters im Führungsshuttle entsprechend die
Komponente Coordinator aktiviert. Wie die Erzeugung solcher Komponenten in das Ver-
halten von hybriden Rekonfiguration Charts integriert werden kann, ist in [Krä06] be-
schrieben.
: Shuttle
: Coordinator
: VelocityControl
:P
:P
: Shuttle
: VelocityControl :P :P:P ++ :P
:P
:P << last >> ++
t>5
clock:t
clock:t
clock:t
++ ++
++
++
++
++
Abbildung 5.22: Initiale Regel zur Anwendung des parametrisierten
Koordinationsmusters
134
5.4 Parametrisierte Koordinationsmuster
:P
:P:P << last >>
t<7
clock:t
clock:t
clock:t
Abbildung 5.23: Regel zur Erzeugung einer Zeitinvariante
Bei dem parametrisierten Koordinationsmuster gibt es noch eine weitere Erweiterungsre-
gel (siehe Abbildung 5.24). Die zweite Regel beschreibt das Auffahren eines Shuttles auf
einen bereits existierenden Konvoi (siehe Abbildung 5.24). Hierbei wird bei dem neu hin-
zukommenden Shuttle ein shuttle-Port erzeugt. Weiterhin wird ein Connector zum Füh-
rungsfahrzeug erzeugt. Der Stereotyp lastwird entsprechend vom alten Connector
gelöscht und an den neu erzeugten Connector gebunden, um die letzte Position neu zu
markieren. Die Instanzsituation ist in Abbildung 5.25 dargestellt.
: Shuttle
: VelocityControl:P
: Shuttle
: VelocityControl :P
:P
:P
<< create >> ++
:P
: Shuttle
: VelocityControl :P :P
:P
<< last >> --
<< last >> ++
t>5
clock:t
clock:t
clock:t
++
Abbildung 5.24: Ein Shuttle reiht sich hinten in den Konvoi ein
<< Component >>
shuttle1: Shuttle
<< Component >>
vc1: VelcityControl
<< Component >>
shuttle2: Shuttle
<< Component >>
vc2: VelocityControl
<< Component >>
shuttle3: Shuttle
<< Component >>
vc3: VelocityControl
Abbildung 5.25: Instanzsicht nach der Anwendung von Regel aus Abbildung 5.24
5.4.3.2 Reduzierungsregeln
Um das Auflösen eines Konvois zu beschreiben, werden zusätzlich Reduzierungsregeln
benötigt. In Abbildung 5.26 ist dargestellt, wie das letzte Shuttle eines Konvois diesen
verlässt. Dabei werden die Ports vernichtet und der Connector ebenfalls. Um das neue
letzte Shuttle zu markieren, wird nun der Stereotyp lastan den Connector des vor-
herfahrenden Shuttles gebunden.
135
Kapitel 5 Parametrisierte Koordinationsmuster
: Shuttle
: VelocityControl:P
: Shuttle
: VelocityControl :P
:P
:P
<< destroy >> --
:P
: Shuttle
: VelocityControl :P :P
:P
<< last >> ++
<< last >> --
t>5
clock:t
clock:t
clock:t
--
Abbildung 5.26: Letztes Shuttle verlässt den Konvoi
Falls der Konvoi nur noch aus zwei Teilnehmern besteht, muss das parametrisierte Koor-
dinationsmuster entsprechend deinstanziiert werden. Bevor dies jedoch geschieht, muss
die Regel aus Abbildung 5.27 angewendet werden. Hierbei wird die Komponente Coor-
dinator im Führungsshuttle deaktiviert. Ebenfalls wird der Connector und die beteiligten
Ports vernichtet.
: Shuttle
: Coordinator
: VelocityControl
:P
:P
: Shuttle
: VelocityControl :P :P:P -- :P
:P
:P << last >> --
t>5
clock:t
clock:t
clock:t
<<destroy>>
--
--
--
Abbildung 5.27: Konvoi der Länge 2wird aufgelöst
Als letztes wird eine Regel dafür angegeben, dass das Führungsshuttle den Konvoi ver-
lässt. Hierbei muss die Unterkomponente Coordinator des Führungsshuttles an das hinter-
herfahrende Shuttle übertragen werden. Ausserdem muss der multi-Port vernichtet wer-
den. Das hinterherfahrende Shuttle hingegen muss seine einfache shuttle Rolle nun in
einen multi-Port coordinator umwandeln. Die Regel ist in Abbildung 5.28 dargestellt.
Um die Verifikation eines parametrisierten Koordinationsmusters zu beschreiben, wird im
nächsten Abschnitt zuerst eine formale Definition eines parametrisierten Koordinations-
musters vorgenommen.
5.4.4 Formalisierung
Als erstes wird der zur Beschreibung des Verhaltens einer Unterrolle verwendete Forma-
lismus des Timed Automaton zu einem parametrisieren Timed Automaton erweitert.
136
5.4 Parametrisierte Koordinationsmuster
: Shuttle
: Coordinator
: VelocityControl
:P
:P
: Shuttle
:P
-- :P
:P
: Coordinator
: VelocityControl
:P
:P
:P
:P
:P
clock:t
t>5
<<last>> --
clock:t clock:t
++
++
-- --
++
Abbildung 5.28: Führungsshuttle verlässt den Konvoi
Definition 34
Ein parametrisierter Timed-Automaton Aist ein 7-Tupel A:= (Σ,S,S0, X, I, Sig(l, P), T),
wobei Σein endliches Eingabealphabet, Seine endliche Menge an Locations, S0⊆ S
eine endliche Menge von Start-Locations, X:= (x1, .., xn)eine endliche Menge an
Clock-Variablen mit xi∈R+,Ieine Zuordnungsfunktion I→ C(X), welche den ein-
zelnen Locations eine Menge an Ungleichungen zuordnet, die so genannten Invarianten,
Sig(l, P)eine Menge von Signalen, die mit lparametrisiert sind. Pist hierbei eine
spezielle Eigenschaft des Automaten. Tist die Menge der Transitionen. C(X)ist eine
Menge von Bedingungen über Clock-Variablen aus X. Dabei besteht C(X)aus einer
Menge an Ungleichungen der Form xi≺c∨c≺xi, wobei ≺entweder <oder ≤ist und
c∈N+. Für T, die Menge der Transitionen, gilt T⊆ S ×Σ×C(X)×2X×Sig(l, p)×S.
Eine Transition von Location snach s0läßt sich durch ein 6-Tupel (s, a, ϕ, λ, sig, s0)
beschreiben. Dabei ist a∈Σdie Beschriftung der zugehörigen Kante, ϕeine Bedingung,
die erfüllt sein muss damit die Transition schalten kann und λ⊆Xeine Anzahl an
Clockvariablen, die beim Schalten auf 0 zurück gesetzt werden. sig ⊆Sig(l, P)ist ein
durch einen Parameter lgekennzeichnetes Signal, dass den Wert p∈Pübermittelt.
Die parallele Ausführung zweier parametrisierter Automata Aiund Ajist wie folgt defi-
niert:
Definition 35
Gegeben sei ein parametrisierter Timed-Automaton Ai:= (Σi,Si,S0i, Xi, Ii, Sig(li, Pi), Ti)
und ein parametrisierter Timed-Automaton Aj:= (Σj,Sj,S0j, Xj, Ij, Sig(lj, Pj), Tj)
wie in Definition 34 definiert. Jeder Automat Aiund Ajverhält sich lokal wie in
den Grundlagen (Abschnitt 2.3.2) beschrieben. Nur über die parametrisierten Signale
Sig(li, Pi)und Sig(lj, Pj)findet eine Synchronisation statt, wenn i=jist. Dabei wird
Pj:= Pi, falls i≤j
Mit dieser Beschreibung ist es nun möglich, eine Unterrolle zu definieren.
137
Kapitel 5 Parametrisierte Koordinationsmuster
Definition 36
Rl= (A, Ψ) ist eine Unterrolle mit dem Index l, wobei das Verhalten durch einen pa-
rametrisierte Timed Automaton Abeschrieben wird. Ferner besitzt die Unterrolle eine
Menge von lokalen Constraints Ψ.
Hiermit lässt sich nun der Begriff einer multi-Rolle definieren:
Definition 37
Eine multi-Rolle eines parametrisierten Koordinationsmusters Cist definiert als ein 3-
Tupel MRC= (n, Rl, attr)wobei ndie Multiplizität, Rlmit l∈ {1. . . n}die Menge
aller Unterrollen Rollen, attr eine Ordnung auf Rlist.
Definition 38
Mit I(MRC)⊆Σ×Sig(l, p)wird das Interfaceverhalten einer multi-Rolle bezeichnet.
Definition 39
Ein parametrisiertes Koordinationsmuster C= (MR,P,Ψ(P),PC
t,PR
t,PF
t)besteht
aus einer Menge multi-Rollen MR, einer Menge von Profilen P=p1. . . pn, Constraints
über die Profile Ψ(P), einer Menge von zeitbehafteten Erzeugungsregeln sowie Reduzie-
rungsregeln PC
t,PR
tsowie einer Menge von verbotenen Strukturregeln PF
t.
5.4.5 Verifikation
Im Folgenden wird die Verifikation eines wie im letzten Abschnitt formal definierten pa-
rametrisierten Koordinationsmusters beschrieben. Wie eingangs im Kapitel beschrieben,
kommen hier die Techniken des Model Checking, die Analyse von Graphtransformations-
system sowie der Induktion zum Tragen.
Die Korrektheit hinsichtlich der spezifizierten Profileigenschaften einer multi-Rolle wird
induktiv bewiesen. Für die Verifikation eines parametrisierten Koordinationsmusters C
sind die folgenden Schritte notwendig:
1. Verifiziere mittels Model Checking, dass R1
MRC|= Ψ(R)∧ ¬δ
2. Verifiziere Ri
MRC||Ri+1
MRC|=¬δ∧val(Ri
MRC)≤val(Ri+1
MRC), wobei val(Ri
MRC)
die Werte von pliefert, die in der Rolle angenommen werden können
3. Nutze den Ansatz aus Kapitel 4 um mittels Erreichbarkeitsanalyse zu überprüfen,
dass
a) die Zeitbedingungen der Regeln PC
tund PR
teingehalten werden und
b) dass die durch die verbotenen Strukturregeln PF
tbeschriebenen Situationen
nicht auftreten.
138
5.5 Zusammenfassung
4. Verifiziere mittels Model Checking, dass I(MRC
1)|| . . . ||I(MRC
k)|=¬δ(k Anzahl
der multi-Rollen von C) erfüllt ist.
Theorem 1
Ein parametrisiertes Koordinationsmuster erfüllt die hinsichtlich der Profile spezifizierten
Constraints Ψ(P), wenn jeder Verifikationsschritt 1−4erfüllt ist.
Beweis 1
Beweis durch Induktion (Beweisskizze): (1) stellt sicher, das eine einzelne Rolle Rieiner
multi-Rolle hinsichtlich Ψ(Ri)korrekt ist und sie keinen Deadlock enthält (Induktions-
anfang). (2) beweist die Induktionsannahme, dass für zwei benachbarte parametrisierte
Rollen die Profileigenschaft erfüllt ist. Der Induktionsschritt wird durch (3) gezeigt. Das
korrekte Zusammenspiel aller einzeln verifizierten multi-Rollen eines parametrisierten
Koordinationsmusters wird durch die Verifikation der parallelen Komposition aller Inter-
faceverhalten der multi-Rollen gezeigt (4). (q.e.d.)
5.5 Zusammenfassung
In den beiden vorangegangenen Kapiteln wurde beschrieben, wie sich ein OCM model-
lieren und verifizieren lässt. Der Fokus dieses Kapitels steht nun auf der Modellierung
und Verifikation der Koordination von OCMs in vernetzten mechatronischen Systemen.
Hierbei werden die bisher vorgestellten Techniken aus den vorangegangenen Kapiteln
miteinander geschickt verknüpft.
Hierzu wurde zuerst der bisherige kompositionelle Ansatz zur Modellierung und Veri-
fikation der Echtzeit-Koordination vorgestellt. Bei der Anwendung für komplexe, ver-
netzte mechatronische Systeme zeigt dieser Ansatz jedoch einige Einschränkungen, die
auch diskutiert wurden. Dies waren die Punkte Dynamik hinsichtlich der Struktur des
Echtzeit-Koordinationsmusters, die statisch vorgegeben ist, sowie die Stabilität hinsicht-
lich Koordinationsverhalten bezüglich der Regelungstechnik. Basierend auf dem kom-
positionellen Ansatz wurde der neue Ansatz, die parametrisierten Koordinationsmuster,
welche nun zusätzlich dynamische Strukturänderungen als auch Werte-kontinuierliches
Reglerverhalten mit berücksichtigen, vorgestellt. Die parametrisierten Koordinationsmus-
ter wurden zuerst informell eingeführt und danach formal definiert. Am Ende wurden die
Verifikationsschritte, um ein parametrisiertes Koordinationsmuster formal zu verifizieren,
beschrieben.
139
Kapitel 5 Parametrisierte Koordinationsmuster
140
Kapitel 6
Verwandte Arbeiten
In diesem Kapitel werden nun verwandte Arbeiten betrachtet, die sich mit der modell-
basierten Verifikation von komplexen, vernetzten mechatronischen Systemen befassen.
Da es, wie in der Einleitung schon beschrieben, nicht die Verifikationsmethode für solche
Systeme gibt, sondern immer einer geschickten Kombination mehrerer Techniken bedarf,
wird im Folgenden zuerst die Verifikation von Echtzeitsystemen betrachtet (siehe Ab-
schnitt 6.1). Hierbei werden verschiedene Modelle und Verifikationstechniken diskutiert,
die eine effiziente Verifikation dieser Systeme ermöglichen, bzw. die aufzeigen, wo die
Grenzen liegen. Daran anschließend wird im Abschnitt 6.2 die Verifikation von hybriden
Systemen diskutiert. Im Abschnitt 6.3 wird diskutiert, wie sich Architekturen, beschrie-
ben durch hybride Modelle, verifizieren lassen. Bevor das Kapitel in Abschnitt 6.5 mit
einer Zusammenfassung schließt, wird im vorletzten Abschnitt 6.4 die Verifikation von
adaptiven Systemen behandelt.
6.1 Verifikation von Echtzeitsystemen
Farn Wang stellt in einer Übersicht [Wan04] einen Katalog von Modellen, Techniken und
Werkzeugen für die Verifikation von Echtzeitsystemen vor. Weiterhin wird von Giese und
Henkler in [GH06] ein Überblick über Ansätze für die modell-basierte Entwicklung von
software-intensiven Systemen gegeben. Es existiert eine Reihe von Modellierungs- und
Verifikationstechniken für Echtzeitsysteme. Im Folgenden werden drei Projekte aus dieser
Auswahl stellvertretend für die Verifikation von Echtzeitsystemen vorgestellt, welche die
wesentlichen Techniken und Modelle aus der vorliegenden Arbeit abdecken.
6.1.1 Generelle Ansätze
UPPAAL. UPPAAL [BDL04] ist ein Werkzeug für die Modellierung, Validierung und
Verifikation von Echtzeitsystemen, die durch ein Netzwerk von untereinander kommuni-
141
Kapitel 6 Verwandte Arbeiten
zierenden Timed Automata beschrieben sind. Die Modelle erlauben dabei die Verwen-
dung von komplexen Datenstrukturen, wie Array usw. Zur Kodierung der Clocks wird
die Datenstruktur der Difference-Bound-Matrices (DBM) [Dil90] verwendet, die auch
in dieser Arbeit aufgegriffen wurde, um das Zeitmodell bei den zeitbehafteten Graph-
transformationssystem zu verwalten (siehe Kapitel 4). Die Verifikation stellt verschiede-
ne Optionen zur Optimierung des Zustandsraumes zur Verfügung, wie clock-reduction,
convex-hull approximation usw.
HUGO/RT. In Knapp und andere [KMR02] wird das Werkzeug HUGO/RT vorgestellt.
Mit diesem Werkzeug ist es möglich Modelle, beschrieben durch UML state machines,
zu verifizieren. Die zu verifizierenden Eigenschaften werden durch Szenario Diagramme
(Sequenzdiagramme) beschrieben. Um die Verifikation mit UPPAAL oder SPIN durch-
führen zu können, werden von HUGO/RT die UML state machines in Timed Automata
transformiert. Ein UML Sequenzdiagramm wird auf einen Observer Timed Automaton
abgebildet. Die Verifikation findet nun statt, indem Erreichbarkeitsanfragen über den Ob-
server Timed Automaton gestellt werden. Balser und andere stellen in [BBK+04] einen
Ansatz vor, der den interaktiven Verifizierer KIV [BRSS99] anstelle von UPPAAL und
SPIN in die Werkzeugkette integriert. Die Modelle werden weiterhin mit HUGO/RT mo-
delliert, die temporalen Eigenschaften der UML state machines werden nun allerdings mit
KIV überprüft. Dieser Ansatz hat den Vorteil, dass prinzipiell auch UML state machines
mit unendlichem Zustandsraum überprüft werden können, da bei der Verifikation mit KIV
Techniken wie z.B. Induktion verwendet werden. Der Fokus dieses Ansatz liegt auf der
Beschreibung von Verifikationsalgorithmen, hingegen verfolgt der in dieser Arbeit vor-
gestellte ansatz eine durchgängige modellbasierte Entwicklung durch die Integration von
UML basierten Modell- und Verifikationstechniken unter Ausnutzung von vorgegebenen
Architekturen.
IST OMEGA. Das Projekt IST OMEGA [GH04] hat sich zum Ziel gesetzt, den Kor-
rektheitsnachweis für eine auf die speziellen Bedürfnisse eingebetteter Echtzeitsoftware
abgestimmte Teilmenge der UML [DJVP03] durch Integration von Verifikationswerkzeu-
gen wie Model Checker und Theorembeweiser (PVS) und UML CASE Werkzeugen zu
ermöglichen. Dabei wurde die UML um eine Systemzeit (now) und Timerkonzepte er-
gänzt, die durch eine Abbildung auf Communication Extended Timed Automata seman-
tisch fundiert wurde. Im Gegensatz zum MECHATRONIC UML Ansatz ermöglicht der
OMEGA Ansatz nur eine kompositionelle Betrachtung bei semi-automatischen, interak-
tiven Beweisen mit dem Theorembeweiser.
Fazit. Alle hier vorgestellten Werkzeuge und Modelle basieren auf dem Grundmodell
des Timed Automatons. Allerdings erreicht keines der Modelle die Ausdrucksstärke der
142
6.1 Verifikation von Echtzeitsystemen
in dieser Arbeit vorgestellten Verhaltensmodelle der Realtime Statecharts bzw. der Hybri-
den Rekonfigurations Charts [GH06]. Auf Basis der hier vorgestellten Werkzeuge werden
nun im Folgenden Techniken vorgestellt, die zum Einsatz kommen, um die Verifikation
für Echtzeitsysteme, wie in der Einleitung dieser Arbeit beschrieben, überhaupt erst an-
wendbar bzw. effizient zu machen. Diese sind jedoch alleine nicht ausreichend, um dem
domänenübergreifenden Charakter von mechatronischen Systeme gerecht zu werden und
diesen entsprechend zu verifizieren.
6.1.2 Techniken
Abstraktion und Komposition. Es existieren viele Ansätze zur Abstraktion und
Komposition von Echtzeitsystemen. Der von Jensen und anderen [JGGS00] vorgestellte
Ansatz wird später in dieser Arbeit aufgegriffen und deshalb im Folgenden kurz vorge-
stellt. Der Ansatz beschäftigt sich damit, das bei der Verifikation von Echtzeitsystemen,
die mit UPPAAL Timed Automata modelliert wurden, auftretende Problem der Zustands-
raumexplosion durch eine Kombination von Abstraktion und Komposition zu beheben.
Durch die timed simulation werden die für die Abstraktion notwendigen grundlegenden
Eigenschaften zwischen Timed Automata erhalten. Das Problem ist, dass bei dem Timed
Automata Konzept, wie es in UPPAAL verwendet wird, globale Variablen und urgent
Kommunikationskanäle vorkommen. Diese führen dazu, dass eine reine Erhaltung der
timed simulation nicht ausreichend für einen kompositionellen Ansatz ist (siehe Kapitel
3in [JGGS00]). Es wird deshalb ein erweiterter Ansatz, timed ready simulation, vorge-
stellt, der Abstraktion und Komposition unterstützt. Der Test auf timed ready simulation
zwischen Timed Automata wird in UPPAAL durch eine Erreichbarkeitsanalyse durchge-
führt. Angenommen, ≤ist eine Simulationsrelation und M≤Mabs gilt es zu überprüfen.
Hierzu wird nun zuerst ein Test Timed Automaton Tabs für Mabs konstruiert. Im zwei-
ten Schritt wird nun getestet, ob in MkTabs ein so genannter reject Zustand erreicht
werden kann. Ist dies der Fall, gilt M6≤ Mabs, andernfalls M≤Mabs.Tabs wird in der
Form eines Komplementautomaten von Mabs konstruiert. Die Konstruktion eines solchen
Komplementautomaten Tabs ist immer dann möglich, wenn Mabs ein deterministischer Ti-
med Automaton ist. Ein Timed Automaton Tist deterministisch, wenn für alle Zustände
s, s0, s00 von Tgilt: Falls sv
→s0und sv
→s00, dann folgt s0=s00.
Das Problem bei Timed Automata ist, dass sich nicht-deterministische Timed Automata
nicht einfach in deterministische umwandeln lassen. Dies liegt daran, dass die Klasse
der nicht-deterministischen Timed Automata nicht gegen Komplement abgeschlossen ist.
Nicht-deterministsiche Event-Clock Automata, die eine strenge Formulierung der Timed
Automata sind, lassen sich hingegen in deterministische umwandeln [AFH97]. Allerdings
ist diese Einschränkung für die bei mechatronischen Systemen verwendeten Modelle zu
restriktiv, so dass die Idee aus Jensen und anderen [JGGS00] in dieser Arbeit aufgegriffen
und erweitert wurde.
143
Kapitel 6 Verwandte Arbeiten
Counterexample basierte Abstraktion. Clarke und andere beschreiben in
[CGJ+03] eine Technik, um eine obere Abstraktion eines original Modells zu erhalten.
Ist ein Bedingung von dem abstrakten Modell erfüllt, so ist sie auch in dem konkreten
Modell erfüllt. Ist die Eigenschaft in dem abstrakten Modell falsch, so resultiert ein
Gegenbeispiel in einem Verhalten in der Approximation, dass nicht in dem original
Modell vorhanden ist. In diesem Fall muss die Abstraktion verfeinert werden, so dass
das Verhalten, welches durch das Gegenbeispiel beschrieben wird, nicht mehr berück-
sichtigt wird. Clarke und andere stellen in ihrem Beitrag eine effiziente, automatische
Verfeinerungsmethode vor, um aus den Informationen der Gegenbeispiele dies zu
erreichen.
Diese Methode wird von einigen Model Checkern in der Echtzeitdomäne eingesetzt. So
z.B. auch in dem Werkzeug SAL [TK02]. Der Vorteil ist eine geschickte Abstraktion, je-
doch werden das Werte-kontinuierliche Verhalten sowie das Zeit-kontinuierliche Verhal-
ten nicht getrennt voneinander betrachtet, so dass hier die Komplexität nicht ausreichend
reduziert wird. Außerdem ist die Abstraktion von der vorgegebenen Systemarchitektur
abhängig, was zur Folge hat, dass das Verfahren nicht immer eine optimale und damit
effiziente Abstraktion liefert.
6.1.3 Komplexe Ansätze
Nachdem nun grundlegende, verwandte Techniken und Methoden der Abstraktion von
Echtzeitmodellen diskutiert wurden, befasst sich dieser Abschnitt mit komplexen Ansät-
zen zur modell-basierten Entwicklung von Echtzeitsystemen.
Zeitbehaftete Komponentenspezifikation. Metzler und Wehrheim stellen in
[MW07] eine Spezifikationssprache für die Modellierung von zeitbehafteten Kompo-
nentenarchitekturen (timed CSP-OZ) vor. Der Ansatz baut auf vorhandenen Konzepten
von CSP-OZ, bei denen die Schnittstellen der Komponenten bereits durch pre/post
Bedingungen beschrieben werden können, auf. Um jedoch den Anforderungen von
Echtzeitsystemen gerecht zu werden, wird hier der Ansatz um die Modellierung von Zeit
in den Schnittstellen erweitert. Um die Integration von Zeit so einfach wie möglich zu
gestalten, wird hier kein neuer Formalismus, sondern nur ein neuer Datentyp, der die
Zeit repräsentiert, hinzugefügt. Die Semantik wird formal über Timed Automata defi-
niert. Dies hat den Vorteil, dass zu Verifikationszwecken der Model Checker UPPAAL
eingebunden werden kann. Weiterhin werden hierauf Bedingungen für timed simulation
definiert, so dass es auch möglich ist, Kompositionalität o.ä. zu verwenden.
144
6.2 Verifikation von hybriden Systemen
Service orientierte Modellierung und Verifikation. In [EHK+07] wird ein
modell-basierter Ansatz für die Entwicklung von verteilten, eingebetteten Echtzeitsyste-
men beschrieben. Um die Komplexität solcher Systeme in den Griff zu bekommen, wird
ein Service-orientierter Ansatz verfolgt. Dabei werden zu Beginn die Funktionalitäten
des Systems unabhängig voneinander durch Interaktionsdiagramme modelliert und
verifiziert. Ein vorgegebener Prozess, der einer wohl-definierten Verfeinerungsbeziehung
unter den Modellen folgt, erlaubt die schrittweise Entwicklung solcher Systeme. Der
Service-orientierte Ansatz unterstützt die Entwicklung verteilter, eingebetteter Systeme
angefangen von der Anforderungsanalyse bis hin zur Implementierung, Verifikation und
Validierung.
Aufbauend auf den Konzepten wird in [EMK+07][EFF+08] ein Failure Management An-
satz für eingebettete Systeme vorgestellt. Hierbei werden so genannte Interaktionsmuster
für die Kommunikation zwischen Komponenten beschrieben, die entsprechend verifiziert
werden können. Die Interaktionsmuster werden auf Automaten abgebildet, die vom Mo-
del Checker SPIN [AKPM05] verifiziert werden können.
Im nächsten Abschnitt wird nun die Verifikation von hybriden Modellen diskutiert. Die
dabei vorgestellten Ansätze nutzen weiterhin die bereits vorgestellten Techniken aus und
einwickeln entsprechende Lösungen für den hybriden Fall.
6.2 Verifikation von hybriden Systemen
6.2.1 Generelle Ansätze
MATLAB/Simulink1ist der Industriestandard beim Entwurf von Regelungssystemen. Ba-
sierend auf Blockdiagrammen, die via zeit-kontinuierlichen Signalen interagieren, wird
der Entwurf komplexer Werte-kontinuierlicher Systeme ermöglicht. Die Integration von
Stateflow ermöglicht zudem die Modellierung ereignis-diskreten Verhaltens. MATLAB/-
Simulink Modelle sind im Vergleich zu den anderen betrachteten Verfahren nicht formal
hinterlegt. Eine formale Verifikation wird durch zusätzliche Formalisierung, wie zum Bei-
spiel bei dem CheckMate [SRKC00] Ansatz erreicht.
Neben MATLAB/Simulink und Stateflow exisitieren eine Vielzahl von Ansätzen und
Werkzeugen für die Modellierung und Verifikation hybrider Systeme. Hybrid Statecharts
[KP91], Charon [ADE+01], Masaccio [Hen00], HyCharts & HyRoom [GSB98][SPP01]
und HyTech/PHAver [Fre05] adressieren die Modellierung in Form von hybriden State
Charts und Verifikation von komplexen hybriden Systemen.
1http://www.mathworks.com/
145
Kapitel 6 Verwandte Arbeiten
Fazit. Alle existierenden Ansätze unterstützen jedoch keine adäquate Modellierung für
die hier behandelten komplexen, vernetzten mechatronischen Systeme [Bur06][GH06].
Das Hautproblem ist, dass die hier geforderte Dynamik und Modularität der Architektur
von keinem Ansatz geeignet unterstützt wird. Das hat zur Folge, das zur Verifikation im-
mer das gesamte System betrachtet werden muss, da es nicht dekomponiert werden kann
und deshalb die Verifikation trotz Techniken, wie sie im Folgenden vorgestellt werden,
nicht anwendbar ist.
Ein anderer Nachteil der vorhandenen Ansätze ist, dass die Domänen der Regelungs-
technik und der Softwaretechnik nicht sauber in der Modellierung getrennt sind. Hierbei
werden sowohl das Koordinationsverhalten als auch das kontinuierliche Verhalten inner-
halb einer einzigen hybriden Komponente modelliert. Dies erfordert eine enge Zusam-
menarbeit der Disziplinen und lässt sich auch manchmal so gar nicht realisieren. Der hier
verfolgte Ansatz der MECHATRONIC UML erlaubt durch klar definierte Schnittstellen
zwischen den Domänen die getrennte Modellierung des Echtzeit-Koordinationsverhaltens
und der kontinuierlichen Regler und unterstützt durch einen klaren Modularitätsbegriff die
Integration aller Domänen [GHH+08b].
Im Folgenden werden nun anhand dieser Ansätze und Werkzeuge Techniken vorgestellt,
die bei der Verifikation von hybriden Systemen eingesetzt werden, um die Komplexität
teilweise zu vermindern.
6.2.2 Techniken
Approximation. HyTech, 1995 entwickelt, ist ein symbolischer Model Checker für
Hybride Systeme [HHWT95]. Um diese Systeme zu behandeln, benutzt HyTech Hybride
Automaten, mit denen in einem einzigen Formalismus diskrete und kontinuierliche Zu-
standsänderungen formuliert werden können. Das besondere an HyTech ist, dass es auch
eine parametrische Analyse vornimmt. Es wird also nicht nur überprüft ob ein Modell eine
bestimmte Formel (bei HyTech eine CTL-Formel) erfüllt oder nicht, sondern es werden
Bedingungen bzw. Begrenzungen für bestimmte Parameter des Modells berechnet, unter
denen die Korrektheit des Modells garantiert werden kann. Neben dieser großen Stärke
von HyTech gibt es allerdings auch eine große Schwäche [Fre05]: HyTech benutzt keine
exakte Arithmetik. Dies führt dazu, dass die Zahldarstellung irgendwann ungenau wird
und dies führt zu Overflow-Fehlern. Wegen dieser Ungenauigkeit kann HyTech nicht auf
komplexe Systeme angewandt werden, welche eine große Genauigkeit fordern. Weiter-
hin ist HyTech eher für Systeme mit Variablen mit kleinen Änderungsraten geeignet, da
ansonsten der Zustandsraum zu groß wird um ihn noch in vernünftiger Art und Weise zu
behandeln.
HyTech wird seit Ende 1996 nicht mehr weiterentwickelt. PHAVer baut auf HyTech
auf und hat es sich zum Ziel gesetzt, die größten Nachteile von HyTech zu eliminie-
146
6.2 Verifikation von hybriden Systemen
ren [Fre05]. So benutzt PHAVer eine Arithmetik-Bibliothek, welche eine exakte Zahldar-
stellung ermöglicht und damit Overflow Fehler vermeidet. Auf der anderen Seite stellt
PHAVer konservative Verfahren wie Approximationstechniken vor, um die Polyeder-
Darstellung zu vereinfachen. Aufgrund der exakten Arithmetik können nämlich sowohl
die Koeffizienten als auch die Anzahl der Constraints (Gleichungen oder (Ungleichun-
gen), welche die konvexen Polyeder begrenzen, übermäßig groß werden. Daher werden
hier Approximationstechniken eingesetzt, um einerseits die Bits (der Koeffizienten) als
auch die Anzahl der Constraints zu begrenzen.
Prädikat Abstraktion. CHARON / R-CHARON stellt ein hierarchisches, hybri-
des Automatenmodell zur Verhaltensbeschreibung zur Verfügung [ADE+01] [ADI06]
[ADI03] [Iva03] [KSPL06]. Daneben unterstützt CHARON auch das Strukturkonzept der
Hierarchie, um die Komplexität zu beherrschen (ROOM actor diagrams) [AGLS01] und
definiert dabei eine Verfeinerungsbeziehung zischen den eingebetteten Komponenten und
damit Verhaltensmodellen.
Zur Verifikation wird das Programm d/dt verwendet, das auf Prädikatenabstraktion be-
ruht. Das System wird über Prädikate definiert, die das zu untersuchende Verhalten des
Systems wiederspiegeln und die nicht relevanten Systemeigenschaften für diesen Verifi-
kationsschritt wegabstrahieren.
Der Model Checker d/dt untersützt zwei unterschiedliche Verifikationsformen [ADM02].
Es ist möglich, alle erreichbaren Zustände aus dem initialen Zustand zu berechnen. Bei
der Auswertung des Ergebnisses wird festgestellt, ob ein oder mehrere kritische System-
zustände eintreten können. Ist man daran interessiert, ob ein bestimmter Zustand oder eine
Menge von Zuständen erreicht werden kann, so definiert man zusätzlich das Schlüssel-
wort „bad set“. Anschließend führt d/dt eine gezielte Suche im Zustandsraum durch, ob
diese Zustände erreicht werden können. Für jedes System in d/dt muss vorher festgelegt
werden, welche Dimension es haben soll. Die Dimension ist die Anzahl der veränderli-
chen Variablen. Anschließend werden die Differentialgleichungen des Systems mit Hilfe
von Matrizen angegeben.
Dekomposition. Komplexe Systeme, bei denen sowohl diskretes Verhalten als auch
kontinuierliche Daten vorkommen, sind als Ganzes schwer bis gar nicht zu verifizieren.
Metzler stellt in [Met07] einen Dekompositionsansatz vor, der es erlaubt, die komplexen
Strukturen modelliert in CSP-OZ, in kleine, für die Verifikation handhabbare Teile zu
dekomponieren. Die Dekomposition wird durch die Technik des Slicing [BDFW07] be-
stimmt. Dabei wird keine kompositionelle Modellierung vorausgesetzt, sondern anhand
der globalen Eigenschaften wird durch das Slicing eine kompositionelle Aufteilung zur
Verifikation bestimmt. Der Ansatz wurde anhand der Konvoifahrt aus der „Neuen Bahn-
technik Paderborn“ beispielhaft gezeigt.
147
Kapitel 6 Verwandte Arbeiten
Fazit. Die letzten drei vorgestellten Techniken sind effizient anwendbar für kleine hy-
bride Modelle. Allerdings werden durch die Ansätze keine komplexen, vernetzen mecha-
tronischen Architekturen in ihrer Gänze wie dem in dieser Arbeit zu Grunde liegenden
Ansatz unterstützt. In dieser Arbeit wurden die Ideen dieser Techniken aufgegriffen und
in den in dieser Arbeit vorgestellten Ansatz zu Verifikation integriert.
Im Folgenden werden nun Techniken vorgestellt, die sich in der Basis mit der Stabilitäts-
analyse von hybriden Systemen beschäftigen.
6.2.3 Stabilität
Zuerst wird die Lyapunov Stabilitätsanalyse betrachtet. Diese ist in der Regelungstech-
nik eine zentrale Technik zur Überprüfung von regelungstechnischen Stabilitätsverhalten.
Daran anschließend werden spezielle Techniken zur Gewährleistung der Stabilität eines
Konvois, wie sie bei der Modellierung der parametrisierten Koordinationsmuster betrach-
tet wurden, diskutiert.
Lyapunov Stabilitätsanalyse. Stabilität bezeichnet im Allgemeinen, dass ein Sys-
tem auch unter dem Einfluss von Störungen einen begrenzten Bereich nicht verlässt. In
den einzelnen Domänen existieren häufig konkrete Definitionen, die auch eine feinere
Unterteilung des jeweiligen Stabilitätsbegriffes zulassen. Beispielsweise wird in der Re-
gelungstechnik ein lineares zeitinvariantes System dann als stabil bezeichnet, wenn die
Sprungantwort h(t)für t→ ∞ einem endlichen Wert zustrebt. Andernfalls wird es als
instabil bezeichnet. Ein solches System wird als übertragungsstabil bezeichnet, wenn es
auf eine beschränkte Eingangsgröße stets mit einer beschränkten Ausgangsgröße antwor-
tet: |u(t)| ≤ M→ |y(t)| ≤ N(BIBO-Stabilität: Bounded Input - Bounded Output).
In der Stabilitätstheorie nach Lyapunov werden für derartige Systeme Techniken vorge-
schlagen, die eine mathematische Analyse hinsichtlich bestimmter Kriterien ermöglicht
[Föl05][Lud95].
Im Fall einer Reglerumschaltung in mechatronischen Systemen ergeben sich durch die
Umschaltung jeweils neue Reglersysteme. Diese müssen einzeln domänenspezifisch sta-
bil sein. Außerdem muss die Funktion, welche die Regler umschaltet, konvergieren
[LM99][OMT+08]. In [SB03] werden für den Nachweis der Stabilität für die Umschalt-
funktion Multiple Lyapunov Funktionen vorgeschlagen. Dabei wird davon ausgegangen,
das die jeweilige Veränderung am System zusammen mit dem System als Hybrider Au-
tomat mit diskreten Zuständen für die Umschaltung und kontinuierlichen Teilzuständen
für das jeweilige Systemverhalten in einem diskreten Zustand beschreibbar sind. Gemäß
Lyapunov heißt ein System (bzw. dessen Ruhelage) genau dann stabil, wenn es eine ver-
allgemeinerte Energiefunktion gibt, welche bezüglich der möglichen Zustandsverände-
148
6.2 Verifikation von hybriden Systemen
rungen abnimmt. Dieses Prinzip muss auch bei Strukturvariablen, also schaltenden Syste-
men gelten. Ferner müssen die Einflüsse auf das System aus dem Umfeld, vom Benutzer
und aus dem System selbst stets zu einem stabilen Zielsystem führen. Der in dieser Ar-
beit diskutierte MECHATRONIC UML Ansatz adressiert die Problematik der Stabilität
beim Umschalten zwischen Strukturen durch die Erweiterung der klassischen Hybriden
Automaten zu hybriden Rekonfigurations Charts [OMT+08]. Hier werden Umschaltfunk-
tionen, die vorab verifiziert wurden, mit Transitionen, die einen Wechsel der Struktur be-
schreiben, assoziiert. Die Zeit, welche eine Umschaltfunktion benötigt, wird entsprechend
als Deadline in das Modell der hybriden Rekonfigurations Charts übernommen und fließt
damit in die in dieser Arbeit beschriebene Verifikation ein. Dies ermöglicht die formale
Verifikation der Stabilität beim Umschalten zwischen Strukturen.
Konvoi Stabilität. In der Literatur werden verschiedene Konzepte zur Konvoirege-
lung vorgestellt. Diese Ansätze können grundlegend darin unterschieden werden, ob ei-
ne Kommunikation zwischen den einzelnen Fahrzeugen des Konvois möglich ist oder
nicht. In [YEK98] wird eine mögliche Konvoiregelung beschrieben, die ohne Kommu-
nikation arbeitet. Ein weiterer Ansatz zur Konvoiregelung ohne Kommunikation wird in
[HWLL04] beschrieben. Dieser Ansatz zeichnet sich dadurch aus, dass neuronale Netze
zur Regelung genutzt werden. Andere Ansätze wie [BG03] und [ZEA03] setzen explizit
eine Kommunikation zwischen allen Fahrzeugen voraus, um eine bessere Konvoiregelung
zu erreichen. Zlocki und Zambou nutzen WLAN-Standardkomponenten für die Kommu-
nikation innerhalb eines Konvois aus zwei Fahrzeugen [ZZ05]. Die Kommunikationsei-
genschaften sind laut den Autoren hierbei ausreichend. Diesen Ansätzen ist gemein, dass
sie Ausfälle der Kommunikation nicht umfassend betrachten. Vor allem eine geeignete
Modellierung und formale Überprüfung der Kommunikation bzgl. Einhaltung der Sicher-
heit wird nicht durchgeführt.
6.2.4 Barrier certificates
Prajna und andere stellen in [PJ04][Pra05] eine Technik vor, um temporale Eigenschaf-
ten von hybriden Systemen zu verifizieren. Im Gegensatz zum Model Checking wird
hier nicht der Zustandsraum aller erreichbaren Zustände aufgebaut. Um Sicherheitseigen-
schaften, Erreichbarkeitsfragen, Möglichkeiten oder deren Kombination zu verifizieren,
wird das theoretische Konzept der barrier certificates und density functions verwendet.
Ein barrier certificate ist eine Funktion oder eine Menge von Funktionen von Zustän-
den, die Ungleichungen der Funktion selber und deren Ableitungen über den Verlauf be-
schreiben. Im Detail kann durch barrier certificates berechnet werden, ob alle möglichen
Trajektorien von einem definierten Startpunkt in einer sicheren Region enden oder nicht.
Das Konzept der barrier certificates funktioniert ähnlich der Lyapunov Stabilitätsanalyse,
jedoch lassen sich hier neben reinen Stabilitätseigenschaften auch die gerade beschriebe-
149
Kapitel 6 Verwandte Arbeiten
nen Eigenschaften verifizieren. Die Berechnung der barrier certificates basiert auf der
Bestimmung der sum of squares[BKA+07][PP05], die sich effizient berechnen lassen.
6.3 Verifikation von Architekturen beschrieben
durch hybride Modelle
Im Rahmen des Teilprojektbereichs H des AVACS Projektes „Automatic Verificati-
on and Analysis of Complex Systems“ (SFB/TR 14 AVACS2) wird die Verifikation
von hybriden Systemen untersucht. In diesem Rahmen wird ein Großteil der bis-
her beschriebenen Techniken in neuen Techniken und Methoden eingesetzt, die
anhand der Fallstudie ETCS (European Train Control System) evaluiert werden.
[DMO+07][DHO04][PQ08][BBE+04][FH05].
Im Detail werden Verifikationstechniken für untereinander kooperierende Agenten be-
schrieben. Hierzu wurde eine drei Schichten Architektur mit den Ebenen cooperation
layer (kontinuierliche Zeit),control layer (kontinuierliche Zeit) und design layer (diskrete
Zeit) beschrieben. Für jede einzelne Schicht werden eigens hierfür geeignete Verifikati-
onstechniken zur Verfügung gestellt, die für das unterlagerte Zeitmodell geeignet sind.
Die Verifikation umfasst vorverifizierte Entwurfsmuster, die automatische Synthese von
Lyapunov Funktionen, die Erzeugung von Parametereigenschaften sowie definierte Ver-
feinerungsbeziehungen zwischen Modellen im Entwicklungsprozess.
Fazit. Die Techniken und Methoden aus dem AVACS Projekt kommen den in dieser
Dissertation vorgestellten Ansätzen relativ nahe. Jedoch zeigt der AVACS Ansatz im
Vergleich einige Schwächen. So ist die drei Schichtenarchitektur ähnlich der hier vor-
gestellten Architektur eines OCMs (siehe Kapitel 2.1), jedoch ist das Zusammenspiel
der einzelnen Schichten nicht genauer definiert, so dass auch hier keine Vorgehensweise
für eine Verifikation beschrieben ist. Im vorliegenden Ansatz wurden Schnittstellen und
Abstraktionen zwischen den einzelnen Schichten definiert, die eine Verifikation ermög-
lichen. Weiterhin gibt es zwar die Möglichkeit, die Interaktion zwischen Agenten durch
vorab verifizierte Muster zu beschreiben, jedoch ist diese auf eine feste, statische Struk-
tur beschränkt. Durch den graphbasierten Ansatz aus dieser Arbeit ist es möglich, eine
dynamische Struktur zu verifizieren.
2http://www.avacs.org/
150
6.4 Adaptive Systeme
6.4 Adaptive Systeme
Wie in der Einleitung motiviert, sind vernetzte mechatronische Systeme auch dadurch
charakterisiert, dass sie zur Laufzeit ihre Struktur und ihr Verhalten ändern. Hierbei wird
von adaptiven Systemen gesprochen.
Ein wichtiges Problem bei verteilten mechatronischen Systemen ist, dass bei vernetzten
Systemen jedes Teilsystem aufgrund der zur Laufzeit erfolgten Adaption eine potentiell
unterschiedliche lokale Sicht haben kann, auf deren Basis in Notfällen Entscheidungen
autonom und lokal getroffen werden müssen. Deshalb müssen auch hier Techniken und
Methoden entwickelt werden, die hier bei der Verifikation der Sicherheitseigenschaften
verwendet werden können.
Ein weiterer Ansatz, welcher sich mit der Integration von Zeit in das Modell der Graph-
transformationssysteme beschäftigt und somit die Dynamik von zeitlichen Strukturän-
derungen in adaptiven Systemen adressiert, wird von Heckel und anderen in [GVH03]
aufgezeigt. Dort wird Zeit in Anlehnung an Time ER-Netze [GMMP91] modelliert. Ein
maßgeblicher Unterschied liegt darin, dass es die in der vorliegenden Arbeit vorgestell-
ten erweiterten und neu hinzugekommenen Graphtransformationsregeln erlauben, zeit-
liche Eigenschaften und Bedingungen gezielt mit einzelnen Teilgraphen zu verknüpfen.
Dabei können die einzelnen zeitlichen Bedingungen einem Teil der linken Seite einer
Graphtransformationsregel zugeordnet werden, wodurch es möglich ist, komplexe Be-
dingungen, wie sie in mechatronischen Systemen vorkommen, innerhalb einer Regel zu
formulieren.
Fazit. Es gibt eine Reihe von Ansätzen für die Modellierung und Verifikation von struk-
turellen Aspekten von adaptiven Systemen [GVH03] [TGM00] [M´
96] [HIM98] [OMT98]
[KMS92] sowie für die Modellierung und Verifikation des Verhaltens [ZC06] [ADG98]
[KM98] [CPT99]. Jedoch umfasst keiner dieser Ansätze allumfassend beide Aspekte
[BCDW04]. Der in dieser Arbeit verfolge MECHATRONIC UML Ansatz kombiniert beide
Aspekte und unterstützt hierfür ein Verifikationsverfahren und adressiert dabei die Kom-
plexität von mechatronischen Systemen.
6.5 Zusammenfassung
In diesem Kapitel wurden verwandte Arbeiten zum Thema dieser Dissertation diskutiert.
Zuerst wurden Werkzeuge für die Verifikation von Echtzeitsystemen vorgestellt. Daran
anschließend wurden Techniken der Abstraktion, wie sie bei solchen Model Checkern
eingesetzt werden, um die Komplexität von Echtzeitsystemen zu beherrschen, vorgestellt
151
Kapitel 6 Verwandte Arbeiten
und diskutiert. Abschließend wurden komplexe modell-basierte Ansätze zur Verifikation
von Echtzeitsystemen vorgestellt. Die Diskussion dieses Abschnitts hat gezeigt, dass ei-
ne Reihe von einzelnen Techniken für die Verifikation von Echtzeitsystemen existieren,
die in ihrer Theorie gut durchdacht, jedoch für praktische Verifikationsaufgaben im Be-
reich von mechatronischen Systemen alleine effizient nicht anwendbar sind. Gründe sind
hierfür u.a. die fehlende Integration in eine vernetzte, strukturierte modulare und kom-
positionelle Architektur oder das nicht berücksichtigte inhärente domänenübergreifende
Verhalten.
Daran anschließend wurden verwandte Arbeiten zur Verifikation von hybriden Systemen
diskutiert, die sich mit domänenübergreifenden Verhalten beschäftigen. Hier wurden auf-
einander aufbauende Techniken und Methoden vorgestellt, die es erlauben, bestimme Ei-
genschaften wie Erreichbarkeit oder Stabilität hinsichtlich spezifizierter Eigenschaften zu
verifizieren. Allerdings hat die Diskussion gezeigt, dass die Ansätze keine komplexen,
vernetzen mechatronischen Architekturen in ihrer Gänze, wie dem in dieser Arbeit zu
Grunde liegenden Ansatz, unterstützen. In dieser Arbeit wurden die Ideen dieser Techni-
ken aufgegriffen und in den in dieser Arbeit vorgestellten Ansatz zu Verifikation integriert.
Die Verifikation von komplexen Architekturen, beschrieben durch hybride Modelle, wur-
de anhand des AVACS Projekts vorgestellt, welches die vorgestellten Techniken integriert.
Das AVACS Projekt kommt den Ansätzen dieser Arbeit sehr nahe, zeigt jedoch einige
Einschränkungen hinsichtlich der zu verifizierenden Architektur und der Eigenschaften
hinsichtlich der Dynamik.
Abschließend wurde noch auf die Verifikation von adaptiven Systemen eingegangen. Die
Diskussion hat gezeigt, dass bisher keine adäquaten Ansätze, die sowohl Struktur als auch
Verhalten in Verifikationsansätzen behandeln, existieren.
152
Kapitel 7
Zusammenfassung & Ausblick
Beim Entwurf selbstoptimierender, mechatronischer Systeme stellt die eingebettete Soft-
ware einen großen Teil der Wertschöpfung dar. Typischerweise werden Regelungen oder
Steuerungen in Software umgesetzt. Durch die starke Vernetzung selbstoptimierender
Systeme wird Software auch zur nachrichtenbasierten Kommunikation und Koordination
zwischen den einzelnen verteilten selbstoptimierenden Systemen eingesetzt. Diese Kom-
munikation geht über die Aufnahme von System- und Umweltdaten durch Sensorik hin-
aus. Hier werden ggf. komplexe Zustandsinformationen über entsprechende Protokolle
und zugrunde liegende Kommunikationskanäle ausgetauscht, die dann wieder das Ver-
halten bzw. die zugrunde liegenden Berechnungen der einzelnen Komponenten massiv
beeinflussen können. Diese Entwicklung führt zu äußerst komplexer hybrider (diskreter
/ kontinuierlicher) Software. Des Weiteren werden selbstoptimierende, mechatronische
Systeme oftmals in sicherheitskritischen Umgebungen eingesetzt. Hierdurch müssen for-
male Verfahren zur Verifikation der Korrektheit des Systems gegenüber sicherheitskriti-
schen Eigenschaften eingesetzt werden.
Ziel dieser Dissertation war es, Konzepte und Methoden zur Modellierung und Verifika-
tion mechatronischer Systeme zu entwickeln und formal zu beschreiben. Ziel dabei war
es, die besonders durch die Verwendung domänenübergreifender Modelle, wie sie bei
der Modellierung von mechatronischen Systemen vorkommen, entstehenden inhärenten
multi-Paradigmenwechsel [HH06] bei der Modellierung und Verifikation zu berücksichti-
gen. Der hier vorgeschlagene Ansatz zur modell-basierten Entwicklung mechatronischer
Systeme zeichnet sich durch die Integration effizienter Verifikationstechniken, basierend
auf Modellwissen, Abstraktionstechniken, regelbasierten und geschickten Modellierung
aus.
153
Kapitel 7 Zusammenfassung & Ausblick
7.1 Zusammenfassung
In dieser Arbeit wurden zuerst anhand des Vorgehens der modell-basierten Entwicklung
Modelle und Verfahren zur Verifikation von mechatronischen Systemen vorgestellt. Diese
sind jedoch für die komplexen, vernetzten mechatronischen Systeme, wie sie einleitend
beschrieben wurden, nicht alleine anwendbar. Ziel der vorliegenden Arbeit war es, auf-
bauend auf dem vorhandenen Ansatz der MECHATRONIC UML, Erweiterungen und neue
Ansätze zur Modellierung und Verifikation solcher Systeme vorzuschlagen.
In Kapitel 3 wurde zuerst beschrieben, wie sich ein einzelnes OCM verifizieren lässt.
Hierbei wurde beschrieben, wie sich das Zusammenspiel des reflektorischen Operators
mit dem Controller verifizieren lässt. Hierbei mussten die harten Echzeiteigenschaften
des reflektorischen Operators sowie das kontinuierliche Verhalten des Controllers berück-
sichtigt werden. Um das hybride Verhalten verifizieren zu können, wurde ein Modulari-
tätskonzept der Struktur beschrieben, welches auf einer wohl-definierten Verfeinerungs-
beziehung aufbaut und die zur Verifikation nötigen Abstraktionen untersützt.
Im darauf folgenden Kapitel 4 wurde beschrieben, wie sich das äußere Verhalten von
OCMs in der Umwelt modellieren und verifizieren lässt. Motivierend hierfür war eine
möglichst realitätsnahe Beschreibung von Strukturveränderungen. In Schilling [Sch06]
wurde bereits beschrieben, wie Graphtransformationssysteme zur Beschreibung von
dynamischen Veränderungen im Kontext von mechatronischen Systemen eingesetzt
werden können. Dieser Ansatz wurde derart erweitert, dass nun auch Zeitbedingungen
bei der Modellierung und Verifikation berücksichtigt werden. So möchte man z.B.
bei der Beschreibung der Fortbewegung eines Shuttles angeben können, wie lange
ein Shuttle zum Durchfahren eines Schienenabschnitts benötigt oder wie lange die
Instanziierung von Softwarekomponenten dauert, die bei der Anwendung von Echtzeit-
Koordinationsmustern instanziiert werden müssen. Durch untere Schranken (guards)
ist es möglich, eine Mindestzeitdauer festzulegen und diese nach oben hin durch eine
Invariante zu begrenzen, die dadurch das Fortschreiten des Verhaltens garantiert. Hierbei
wurde der Formalismus der Graphtransformationssysteme um Zeitannotationen erweitert.
In Kapitel 5 wurde die Koordination von mehreren OCMs auf der VMS Ebene be-
trachtet. Zwar bietet die MECHATRONIC UML hierfür schon den Ansatz der Echtzeit-
Koordinationsmuster, diese jedoch weisen eine Reihe von Einschränkungen auf. So sind
diese durch eine statische Struktur gekennzeichnet und berücksichtigen kein hybrides Ver-
halten. Die hier neu eingeführten parametrisierten Koordinationsmuster ermöglichen nun
die Integration von kontinuierlichem Verhalten sowie von dynamischen Strukturänderun-
gen.
154
7.2 Ausblick
7.2 Ausblick
Abschließend werden Ausblicke auf weitere Arbeiten gegeben. Im Fachgebiet Software-
technik1und im SFB 614 wird die MECHATRONIC UML stetig weiterentwickelt, um den
neuen Forschungsergebnissen gerecht zu werden.
Wie anfangs in der Zusammenfassung und bei den Konzepten der modell-basierten Ent-
wicklung erwähnt, steht neben der Modellierung und Verifikation auch die Codesynthe-
se aus Modellen im Vordergrund. Um nun auch die neuen parametrisierten Koordinati-
onsmuster zu unterstützen und die hier erreichten Verifikationsergebnisse zu verwenden,
muss die bisherige Codesynthese [Bur06][BGS05] angepasst werden.
Eine nächste Erweiterung wäre, die bereits vorhandene Synthese aus [GHHK06] zur
automatischen Synthese von dynamischen Collaborationen zu erweitern. In diesem
Kontext kann auch untersucht werden, inwiefern sich TSSDs [Kle08][GHH+07] ver-
wenden lassen, um die Constraints der neuen parametrisierten Koordinationsmuster
zu formulieren. Hierbei kann auch untersucht werden, inwiefern sich der Ansatz aus
der Automobilindustrie zur Beschreibung von komplexen Constraints integrieren lässt
[GHS+07a][GHS+07b][GNN+06].
Als letzter Punkt steht nun die Integration von Testverfahren in den Ansatz.
[GHHP07][HH07][GHH08a]. Oftmals ist die Überprüfung eines verifizierten Mo-
dells allein trotz automatischer Codegenerierung nicht immer ausreichend, um die
Konformität des Systems zu seiner Spezifikation zu zeigen. Z.B. werden nachträglich
Veränderungen am Code zur Optimierung vorgenommen oder Legacy Komponenten
werden integriert. Um die Konformität der Software in den oben beschrieben Fällen
dennoch sicherzustellen, ist es erforderlich, den Code zu „verifizieren“. Eine verbreitete
Methode dazu ist der Software-Test. Aufbauend auf vorhandenen Verfahren müssen die
Software-Tests jetzt auch auf komplexe, vernetze mechatronische Systeme erweitert
werden.
1http://www.upb.de/cs/ag-schaefer
155
Kapitel 7 Zusammenfassung & Ausblick
156
Kapitel 8
Literaturverzeichnis
Eigene Veröffentlichungen
[BGH05a] BURMESTER, Sven ; GIESE, Holger ; HIRSCH, Martin: Syntax and Seman-
tics of Hybrid Components / University of Paderborn. Paderborn, Germany,
October 2005 (tr-ri-05-264). – Forschungsbericht
[BGH+05b] BURMESTER, Sven ; GIESE, Holger ; HIRSCH, Martin ; SCHILLING, Da-
niela ; TICHY, Matthias: The Fujaba Real-Time Tool Suite: Model-Driven
Development of Safety-Critical, Real-Time Systems. In: Proc. of the 27th
International Conference on Software Engineering (ICSE), St. Louis, Miss-
ouri, USA, ACM Press, Mai 2005, S. 670–671
[BGH+07] BURMESTER, Sven ; GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin
; TICHY, Matthias ; GAMBUZZA, Alfonso ; MÜCH, Eckehard ; VÖCKING,
Henner: Tool Support for Developing Advanced Mechatronic Systems: Inte-
grating the Fujaba Real-Time Tool Suite with CAMeL-View. In: Proc. of the
29th International Conference on Software Engineering (ICSE), Minneapo-
lis, Minnesota, USA, IEEE Computer Society Press, Mai 2007, S. 801–804
[BGHS04] BURMESTER, Sven ; GIESE, Holger ; HIRSCH, Martin ; SCHILLING, Da-
niela: Incremental Design and Formal Verification with UML/RT in the
FUJABA Real-Time Tool Suite. In: Proc. of the International Workshop on
Specification and Validation of UML Models for Real-Time and Embedded
Systems, SVERTS2004, Satellite Event of the 7th International Conference
on the Unified Modeling Language, UML2004, 2004, S. 1–20
157
Kapitel 8 Literaturverzeichnis
[GH05a] GIESE, Holger ; HIRSCH, Martin: Checking and Automatic Abstraction
for Timed and Hybrid Refinement in Mechtronic UML / Lehrstuhl für Soft-
waretechnik, Universität Paderborn. Paderborn, Germany, December 2005
(tr-ri-03-266). – Forschungsbericht
[GH05b] GIESE, Holger ; HIRSCH, Martin: Modular Verificaton of Safe Online-
Reconfiguration for Proactive Components in Mechatronic UML. In: Proc.
of the International Workshop on Modeling and Analysis of Real-Time
and Embedded Systems (MARTES), Satellite Event of the 8th Internatio-
nal Conference on Model Driven Engineering Languages and Systems, Mo-
DELS/UML2005, 2005, S. 7–26
[GH06] GIESE, Holger ; HIRSCH, Martin: Modular Verificaton of Safe Online-
Reconfiguration for Proactive Components in Mechatronic UML. In:
BRUEL, Jean-Michel (Hrsg.): Satellite Events at the MoDELS 2005 Confe-
rence, Montego Bay, Jamaica, October 2-7, 2005, Revised Selected Papers
Bd. 3844. Springer Verlag, January 2006, S. 67–78
[GHH06a] GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin: Analysis and Mode-
ling of Real-Time with Mechatronic UML taking Clock Drift into Account.
In: Proc. of the International Workshop on Modeling and Analysis of Real-
Time and Embedded Systems (MARTES), Satellite Event of the 9th Interna-
tional Conference on Model Driven Engineering Languages and Systems,
MoDELS/UML2006, Genova, Italy Bd. 343. University of Oslo, October
2006 (Research Report). – ISBN 82–7368–299–4, S. 41–60
[GHH+06c] GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin ; TICHY, Matthias
; VÖCKING, Henner: Modellbasierte Entwicklung vernetzter, mechatroni-
scher Systeme am Beispiel der Konvoifahrt autonom agierender Schienen-
fahrzeuge. In: Proc. of the Fourth Paderborner Workshop Entwurf mecha-
tronischer Systeme Bd. 189, 2006 (HNI-Verlagsschriftenreihe), S. 457–473
[GHH+07] GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin ; KLEIN, Florian ;
SPIJKERMAN, Michael: Monitoring of Structural and Temporal Proper-
ties. In: GEIGER, Leif (Hrsg.) ; GIESE, Holger (Hrsg.) ; ZÜNDORF, Albert
(Hrsg.): Proc. of the 5th International Fujaba Days 2007, Kassel, Germany,
2007, S. 1–4
[GHH08a] GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin: Combining Com-
positional Formal Verification and Testing for Correct Legacy Component
Integration in Mechatronic UML. In: LEMOS, Rogério de (Hrsg.) ; GI-
ANDOMENICO, Felicita D. (Hrsg.) ; GACEK, Cristina (Hrsg.) ; MUCCINI,
Henry (Hrsg.) ; VIEIRA, Marlon (Hrsg.): Architecting Dependable Systems
VBd. 5135, Springer Verlag, Juni 2008 (Lecture Notes in Computer Science
158
(LNCS)), S. 248–272
[GHH+08b] GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin ; ROUBIN, Vladimir
; TICHY, Matthias: Modeling Techniques for Software-Intensive Systems.
In: TIAKO, Dr. Pierre F. (Hrsg.): Designing Software-Intensive Systems: Me-
thods and Principles. Idea Group Publishing, Mai 2008, S. 21–57
[GHHK06] GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin ; KLEIN, Florian: No-
body’s perfect: Interactive Synthesis from Parametrized Real-Time Scena-
rios. In: Proc. of the 5th ICSE 2006 Workshop on Scenarios and State Ma-
chines: Models, Algorithms and Tools (SCESM’06),Shanghai, China, ACM
Press, Mai 2006, S. 67–74
[GHHP07] GIESE, Holger ; HENKLER, Stefan ; HIRSCH, Martin ; PRIESTERJAHN,
Claudia: Model-Based Testing of Mechatronic Systems. In: GEIGER, Leif
(Hrsg.) ; GIESE, Holger (Hrsg.) ; ZÜNDORF, Albert (Hrsg.): Proc. of the 5th
International Fujaba Days 2007, Kassel, Germany, 2007, S. 1–4
[GHS+07a] GEHRKE, Matthias ; HIRSCH, Martin ; SCHÄFER, Wilhelm ; NIGGEMANN,
Oliver ; STICHLING, Dirk ; NICKEL, Ulrich: Verifikation zeitlicher An-
forderungen in automotiven komponentenbasierten Software Systemen. In:
BLEEK, Wolf-Gideon (Hrsg.) ; SCHWENTNER, Henning (Hrsg.) ; ZÜLLIG-
HOVEN, Heinz (Hrsg.): Proc. of the Software Engineering 2007 Conference,
Hamburg, Germany, 27.-30.3.2007 Bd. P-105, Gesellschaft für Informatik,
März 2007 (Lecture Notes in Informatics (LNI)), S. 251–252
[GHS+07b] GEHRKE, Matthias ; HIRSCH, Martin ; SCHÄFER, Wilhelm ; NIGGEMANN,
Oliver ; STICHLING, Dirk ; NICKEL, Ulrich: Typisierung und Verifikation
zeitlicher Anforderungen automotiver Software Systeme. In: CONRAD, Mir-
ko (Hrsg.) ; GIESE, Holger (Hrsg.) ; RUMPE, Bernhard (Hrsg.) ; SCHÄTZ,
Bernhard (Hrsg.): Proc. of the Dagstuhl-Workshop: Model-Based Deve-
lopment of Embedded Systems (MBEES), 15.-18.1.2007, Schloss Dagstuhl,
Germany. Technische Universität Braunschweig, January 2007 (Informatik-
Bericht 2007-1), S. 73–82
[GNN+06] GEHRKE, Matthias ; NAWRATIL, Petra ; NIGGEMANN, Oliver ; SCHÄ-
FER, Wilhelm ; HIRSCH, Martin: Scenario-Based Verification of Auto-
motive Software Systems. In: GIESE, Holger (Hrsg.) ; RUMPE, Bern-
hard (Hrsg.) ; SCHÄTZ, Bernhard (Hrsg.): Proc. of the Dagstuhl-Workshop:
Model-Based Development of Embedded Systems (MBEES), 9.-13.1.2005,
Schloss Dagstuhl, Germany. Technische Universität Braunschweig, Janua-
ry 2006 (Informatik-Bericht 2006-1), S. 35–42
159
Kapitel 8 Literaturverzeichnis
[HG03] HIRSCH, Martin ; GIESE, Holger: Towards the Incremental Model
Checking of Complex RealTime UML Models. In: GIESE, Holger (Hrsg.)
; ZÜNDORF, Albert (Hrsg.): Proc. of the first International Fujaba Days
2003, Kassel, Germany Bd. tr-ri-04-247, University of Paderborn, October
2003 (Technical Report), S. 9–12
[HH06] HENKLER, Stefan ; HIRSCH, Martin: A Multi-Paradigm Modeling Ap-
proach for Reconfigurable Mechatronic Systems. In: Proc. of the Internatio-
nal Workshop on Multi-Paradigm Modeling: Concepts and Tools (MPM06),
Satellite Event of the the 9th International Conference on Model-Driven En-
gineering Languages and Systems MoDELS/UML2006, Genova, Italy Bd.
2006/1. Budapest University of Technology and Economics, October 2006
(BME-DAAI Technical Report Series), S. 15–25
[HH07] HENKLER, Stefan ; HIRSCH, Martin: Compositional Validation of Distri-
buted Real Time Systems. In: GEHRKE, Matthias (Hrsg.) ; GIESE, Holger
(Hrsg.) ; STROOP, Joachim (Hrsg.): Proc. of the 4th Workshop on Object-
oriented Modeling of Embedded Real-Time Systems (OMER 4), Paderborn,
Germany, 30.-31.10.2007 Bd. tr-ri-07-286, University of Paderborn, Octo-
ber 2007, S. 52–56
[HHG08] HIRSCH, Martin ; HENKLER, Stefan ; GIESE, Holger: Modeling Collabora-
tions with Dynamic Structural Adaptation in Mechatronic UML. In: Proc.
of the ICSE 2008 Workshop on Software Engineering for Adaptive and Self-
Managing Systems (SEAMS’08),Leipzig, Germany, ACM Press, Mai 2008,
S. 33–40
[HHKS08] HENKLER, Stefan ; HIRSCH, Martin ; KAHL, Sascha ; SCHMIDT, Alex-
ander: Development of Self-Optimizing Systems: Domain-spanning and
Domain-specific models exemplified by an Air Gap Adjustment System
for Autonomous Vehicles. In: 2008 ASME International Design Enginee-
ring Technical Conferences and Computers and Information in Engineering
Conference. New York, NY, USA, 2008, S. 654–665
[Hir04] HIRSCH, Martin: Effizientes Model Checking von UML-RT Modellen und
Realtime Statecharts mit UPPAAL. Fakultät für Elektrotechnik, Informatik
und Mathematik / Institut für Informatik, Universität Paderborn, Diplomar-
beit, Juni 2004
[OMT+08] OSMIC, Semir ; MÜNCH, Eckehard ; TRÄCHTLER, Ansgar ; HENKLER,
Stefan ; SCHÄFER, Wilhelm ; GIESE, Holger ; HIRSCH, Martin: Safe
Online-Reconfiguration of Self-Optimzing Mechatronic Systems. In: GAU-
SEMEIER, Jürgen (Hrsg.) ; RAMMIG, Franz (Hrsg.) ; SCHÄFER, Wilhelm
(Hrsg.): Selbstoptimierende mechatronische Systeme: Die Zukunft gestalten.
160
7. Internationales Heinz Nixdorf Symposium für industrielle Informations-
technik, 2008, S. 411–426
Literatur
[ACD90] ALUR, Rajeev ; COURCOUBETIS, Costas ; DILL, David: Model-Checking
for Real-Time Systems. In: Proceedings of the 5th Annual Symposium on
Logic in Computer Science, IEEE Computer Society Press, 1990, S. 414–
425
[ADE+01] ALUR, Rajeev ; DANG, Thao ; ESPOSITO, Joel M. ; FIERRO, Rafael B. ;
HUR, Yerang ; IVANCIC, Franjo ; KUMAR, Vijay ; LEE, Insup ; MISHRA,
Pradyumna ; PAPPAS, George J. ; SOKOLSKY, Oleg: Hierarchical Hybrid
Modeling of Embedded Systems. In: EMSOFT ’01: Proceedings of the First
International Workshop on Embedded Software. London, UK : Springer
Verlag, 2001. – ISBN 3–540–42673–6, S. 14–31
[ADG98] ALLEN, Robert ; DOUENCE, Rémi ; GARLAN, David: Specifying and Ana-
lyzing Dynamic Software Architectures. In: Lecture Notes in Computer
Science (LNCS) 1382 (1998), S. 21–36
[ADI03] ALUR, Rajeev ; DANG, Thao ; IVANCIC, Franjo: Progress on Reachability
analysis of Hybrid Systems Using Predicate Abstraction. In: MALER, Oded
(Hrsg.) ; PNUELI, Amir (Hrsg.): HSCC ’03: Proceedings of the 6th Inter-
national Workshop on Hybrid Systems: Computation and Control, Prague,
Czech Republic, April 3-5 Bd. 2623, Springer Verlag, 2003 (Lecture Notes
in Computer Science (LNCS)). – ISBN 3–540–00913–2, S. 4–19
[ADI06] ALUR, Rajeev ; DANG, Thao ; IVAN ˇ
CI ´
C, Franjo: Predicate abstraction for
reachability analysis of hybrid systems. In: Trans. on Embedded Computing
Sys. 5 (2006), Nr. 1, S. 152–199. – ISSN 1539–9087
[ADM02] ASARIN, Eugene ; DANG, Thao ; MALER, Oded: The d/dt Tool for Verifica-
tion of Hybrid Systems. In: CAV ’02: Proceedings of the 14th International
Conference on Computer Aided Verification. London, UK : Springer-Verlag,
2002. – ISBN 3–540–43997–8, S. 365–370
[AFH97] ALUR, Rajeev ; FIX, Limor ; HENZINGER, Thomas A.: Event-clock auto-
mata: a determinizable class of timed automata. In: Theoretical Computer
Science 211 (1997), April, S. 253–273
161
Kapitel 8 Literaturverzeichnis
[AGLS01] ALUR, Rajeev ; GROSU, Radu ; LEE, Insup ; SOKOLSKY, Oleg: Compo-
sitional Refinement of Hierarchical Hybrid Systems. In: Proceedings of the
Fourth International Conference on Hybrid Systems: Computation and Con-
trol (HSCC’01) Bd. 2034, Springer Verlag, 2001 (Lecture Notes in Computer
Science), S. 33–48
[AKPM05] AHLUWALIA, Jaswinder ; KRÜGER, Ingolf H. ; PHILLIPS, Walter ; MEISIN-
GER, Michael: Model-based run-time monitoring of end-to-end deadlines.
In: EMSOFT ’05: Proceedings of the 5th ACM international conference on
Embedded software. New York, NY, USA : ACM, 2005. – ISBN 1–59593–
091–4, S. 100–109
[Bal98] BALZERT, Helmut: Lehrbuch der Software-Technik: Software-Management,
Software-Qualitätssicherung, Unternehmensmodellierung. Heidelberg, Ber-
lin, Oxford : Spektrum Akademischer Verlag, 1998
[BBE+04] BECKER, Bernd ; BEHLE, Markus ; EISENBRAND, Fritz ; FRÄNZLE, Mar-
tin ; HERBSTRITT, Marc ; HERDE, Christian ; HOFFMANN, Joerg ; KRÖ-
NING, Daniel ; NEBEL, Bernhard ; POLIAN, Ilia ; WIMMER, Ralf: Bounded
Model Checking and Inductive Verification of Hybrid Discrete-Continuous
Systems. In: GI/ITG/GMM Workshop: Methoden und Beschreibungsspra-
chen zur Modellierung und Verifikation von Schaltungen und Systemen. Ri-
chard Petersens Plads, Building 321, DK-2800 Kgs. Lyngby : Informatics
and Mathematical Modelling, Technical University of Denmark, DTU, Fe-
bruary 2004
[BBF+01] BÉRARD, B. ; BIDOIT, M. ; FINKEL, A. ; LAROUSSINIE, F. ; PETIT, A. ;
BETRUCCI, L. ; SCHNOEBELEN, Ph. ; MCKENZIE, P.: Systems and Software
Verification. Springer, 2001
[BBG+06] BECKER, Basil ; BEYER, Dirk ; GIESE, Holger ; KLEIN, Florian ; SCHIL-
LING, Daniela: Symbolic Invariant Verification for Systems with Dynamic
Structural Adaptation. In: Proc. of the 28th International Conference on
Software Engineering (ICSE), Shanghai, China, ACM Press, 2006, S. 72–81
[BBK+04] BALSER, Michael ; BÄUMLER, Simon ; KNAPP, Alexander ; REIF, Wolf-
gang ; THUMS, Andreas: Interactive Verification of UML State Machines.
In: DAVIES, Jim (Hrsg.) ; SCHULTE, Wolfram (Hrsg.) ; BARNETT, Michael
(Hrsg.): ICFEM Bd. 3308. Springer Verlag, 2004, S. 434–448
[BCDW04] BRADBURY, Jeremy S. ; CORDY, James R. ; DINGEL, Juergen ; WERME-
LINGER, Michel: A survey of self-management in dynamic software archi-
tecture specifications. In: WOSS ’04: Proceedings of the 1st ACM SIGSOFT
workshop on Self-managed systems. New York, NY, USA : ACM, 2004. –
162
ISBN 1–58113–989–6, S. 28–33
[BDFW07] BRÜCKNER, I. ; DRÄGER, K. ; FINKBEINER, B. ; WEHRHEIM, H.: Sli-
cing Abstractions. In: ARBAB, F. (Hrsg.) ; SIRJANI, M. (Hrsg.): FSEN
2007: IPM International Symposium on Fundamentals of Software Enginee-
ring Bd. 4767, Springer, April 2007 (Lecture Notes in Computer Science). –
ISBN 978–3–540–75697–2, 17–32
[BDL04] BEHRMANN, Gerd ; DAVID, Alexandre ; LARSEN, Kim G.: A Tutorial on
UPPAAL. In: BERNARDO, Marco (Hrsg.) ; CORRADINI, Flavio (Hrsg.):
Formal Methods for the Design of Real-Time Systems: 4th International
School on Formal Methods for the Design of Computer, Communication,
and Software Systems, SFM-RT 2004 Bd. 3185, Springer Verlag, September
2004 (Lecture Notes in Computer Science (LNCS)), S. 200–236
[BG03] BAER, H. ; GERDES, j. C.: Parameter Estimation and Command Modifica-
tion for Longitudinal Control of Heavy Vehicles / University of California.
Berkeley, CA, USA, 2003 (PATH Research Report UCB-ITS-PRR-2003-
16). – Forschungsbericht
[BGO04] BURMESTER, Sven ; GIESE, Holger ; OBERSCHELP, Oliver: Hybrid UML
Components for the Design of Complex Self-optimizing Mechatronic Sys-
tems. In: ARAUJO, Helder (Hrsg.) ; VIEIRA, Alves (Hrsg.) ; BRAZ, Jose
(Hrsg.) ; ENCARNACAO, Bruno (Hrsg.) ; CARVALHO, Marina (Hrsg.): Proc.
of 1st International Conference on Informatics in Control, Automation and
Robotics (ICINCO 2004), Setubal, Portugal, INSTICC Press, August 2004,
S. 222–229
[BGO06] BURMESTER, Sven ; GIESE, Holger ; OBERSCHELP, Oliver: Hybrid UML
Components for the Design of Complex Self-optimizing Mechatronic Sys-
tems. In: BRAZ, J. (Hrsg.) ; ARAÚJO, H. (Hrsg.) ; VIEIRA, A. (Hrsg.) ;
ENCARNACAO, B. (Hrsg.): Informatics in Control, Automation and Robo-
tics I. Springer Verlag, März 2006, S. 281–288
[BGS05] BURMESTER, Sven ; GIESE, Holger ; SCHÄFER, Wilhelm: Model-Driven
Architecture for Hard Real-Time Systems: From Platform Independent Mo-
dels to Code. In: Proc. of the European Conference on Model Driven Archi-
tecture - Foundations and Applications (ECMDA-FA’05), Nürnberg, Germa-
ny, Springer Verlag, November 2005 (LNCS), S. 1–15
[BKA+07] BADAMCHIZADEH, Mohammad-Ali ; KHANMOHAMMADI, Sohrab ;
ALIZADEH, Ghasem ; AGHAGOLZADEH, Ali ; KARIMIAN, Ghader: Using
Sum of Squares Decomposition for Stability of Hybrid Systems. In: IEICE
Transactions 90-A (2007), Nr. 11, S. 2478–2487
163
Kapitel 8 Literaturverzeichnis
[BN03] BROEKMAN, Bart ; NOTENBOOM, Edwin: Testing Embedded Software.
Addison-Wesley, 2003
[BRSS99] BALSER, Michael ; REIF, Wolfgang ; SCHELLHORN, Gerhard ; STENZEL,
Kurt: KIV 3.0 for Provably Correct Systems. In: FM-Trends 98: Proceedings
of the International Workshop on Current Trends in Applied Formal Method.
London, UK : Springer Verlag, 1999, S. 330–337
[BS91] BRZOZOWSKI, J. A. ; SEGER, C. J.: Advances in asynchornous circuit theo-
ry, Part II: Bounded inertial delay model, MOS circuits, design techniques.
Bd. 43. European Association for Theoretical Computer Science, 1991. –
199–263 S.
[Bur06] BURMESTER, Sven: Model-Driven Engineering of Reconfigurable Mecha-
tronic Systems. Fakultät für Elektrotechnik, Informatik und Mathematik /
Institut für Informatik, Universität Paderborn, PhD Dissertation, 2006
[CGJ+03] CLARKE, Edmund ; GRUMBERG, Orna ; JHA, Somesh ; LU, Yuan ; VEITH,
Helmut: Counterexample-guided abstraction refinement for symbolic model
checking. In: J. ACM 50 (2003), Nr. 5, S. 752–794. – ISSN 0004–5411
[CGP00] CLARKE, E. M. ; GRUMBERG, O. ; PELED, D. A.: Model Checking. MIT
Press, 2000
[CPT99] CANAL, Carlos ; PIMENTEL, Ernesto ; TROYA, José M.: Specification and
Refinement of Dynamic Software Architectures. In: WICSA1: Proceedings
of the TC2 First Working IFIP Conference on Software Architecture (WIC-
SA1). Deventer, The Netherlands, The Netherlands : Kluwer, B.V., 1999. –
ISBN 0–7923–8453–9, S. 107–126
[CW96] CLARKE, Edmund M. ; WING, Jeannette M.: Formal methods: state of the
art and future directions. In: ACM Comput. Surv. 28 (1996), Nr. 4, S. 626–
643. – ISSN 0360–0300
[DHO04] DAMM, W. ; HUNGAR, H. ; OLDEROG, E.-R.: On the Verification of Co-
operating Traffic Agents. In: BOER, F.S. de (Hrsg.) ; BONSANGUE, M.M.
(Hrsg.) ; GRAF, S. (Hrsg.) ; ROEVER, W.-P. de (Hrsg.): Proc. FMCO ’03:
Formal Methods for Components and Objects Bd. 3188, 2004 (Lecture No-
tes in Computer Science (LNCS)), 78–110
[Dil90] DILL, D. L.: Timing assumptions and verification of finite-state concur-
rent systems. In: Proceedings of the international workshop on Automatic
verification methods for finite state systems. New York, NY, USA : Springer-
Verlag New York, Inc., 1990. – ISBN 0–387–52148–8, S. 197–212
164
[DJVP03] DAMM, W. ; JOSKO, B. ; VOTINTSEVA, A. ; PNUELI, A.: A Formal Se-
mantics for a UML Kernel Language / OMEGA: Correct Development
of Real-Time Embedded Systems IST-2001-33522. 2003 (IST/33522/WP
1.1/D1.1.2-Part1). – Forschungsbericht. – Version 1.2
[DMO+07] DAMM, Werner ; MIKSCHL, Alfred ; OEHLERKING, Jens ; OLDEROG,
Ernst-Rüdiger ; PANG, Jun ; PLATZER, André ; SEGELKEN, Marc ; WIRTZ,
Boris: Automating Verification of Cooperation, Control, and Design in Traf-
fic Applications. In: JONES, Cliff (Hrsg.) ; LIU, Zhiming (Hrsg.) ; WOOD-
COCK, Jim (Hrsg.): Formal Methods and Hybrid Real-Time Systems Bd.
4700, Springer Verlag, 2007 (Lecture Notes in Computer Science (LNCS)),
S. 115–169
[Dor08] DOROCIAK, Rafal: Hybride Verifikation von Mechatronic UML Modellen
durch Integration des Modelcheckers PHAVer. Fakultät für Elektrotechnik,
Informatik und Mathematik / Institut für Informatik, Universität Paderborn,
Bachelorarbeit, Januar 2008
[DSBB00] DAWSON, D. ; SEWARD, D. ; BRADLEY, D.A. ; BURGE, S.: Mechatronics
and the Design of Intelligent Machines and Systems. Nelson Thornes, 2000.
– ISBN 0748754431
[Dwy02] DWYER, Matthew: Software Model Checking Tutorial, FSE’02. Charleston,
South Carolina, USA, November 2002
[EFF+08] ERMAGAN, Vina ; FARCAS, Claudiu ; FARCAS, Emilia ; KRÜGER, Ingolf H.
; MENARINI, Massimilano: A Service-Oriented Approach to Failure Mana-
gement. In: GIESE, Holger (Hrsg.) ; HUHN, Michaela (Hrsg.) ; NICKEL, Ul-
rich (Hrsg.) ; SCHÄTZ, Bernhard (Hrsg.): Proc. of the Dagstuhl-Workshop:
Model-Based Development of Embedded Systems (MBEES), 7.4.-9.4.2008,
Schloss Dagstuhl, Germany. Technische Universität Braunschweig, April
2008 (Informatik-Bericht 2008-2), S. 102–116
[EHK+07] ERMAGAN, Vina ; HUANG, T.-J. ; KRÜGER, Ingolf ; MEISINGER, Micha-
el ; MENARINI, Massimilano ; MOORTHY, P.: Towards Tool Support for
Service-Oriented Development of Embedded Automotive Systems. In: CON-
RAD, Mirko (Hrsg.) ; GIESE, Holger (Hrsg.) ; RUMPE, Bernhard (Hrsg.)
; SCHÄTZ, Bernhard (Hrsg.): Proc. of the Dagstuhl-Workshop: Model-
Based Development of Embedded Systems (MBEES), 15.-18.1.2007, Schloss
Dagstuhl, Germany. Technische Universität Braunschweig, Januar 2007
(Informatik-Bericht 2007-1), S. 1–24
[EMK+07] ERMAGAN, Vina ; MENARINI, Massimilano ; KRÜGER, Ingolf ; MIZUTANI,
Jun ichi ; OGUCHI, Kentaro ; WEIR, David: Towards Model-Based Failure-
165
Kapitel 8 Literaturverzeichnis
Management for Automotive Software. In: SEAS ’07: Proceedings of the 4th
International Workshop on Software Engineering for Automotive Systems.
Washington, DC, USA : IEEE Computer Society, 2007. – ISBN 0–7695–
2968–2, S. 8
[Fav05] FAVRE, Jean-Marie: Foundations of Model (Driven) (Reverse) Engineering
: Models – Episode I: Stories of The Fidus Papyrus and of The Solarus.
In: BEZIVIN, Jean (Hrsg.) ; HECKEL, Reiko (Hrsg.): Language Engineering
for Model-Driven Software Development. Dagstuhl, Germany : Internatio-
nales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss
Dagstuhl, Germany, 2005 (Dagstuhl Seminar Proceedings 04101). – ISSN
1862–4405
[FGK+04] FRANK, Ursula ; GIESE, Holger ; KLEIN, Florian ; OBERSCHELP, Oliver
; SCHMIDT, Andreas ; SCHULZ, Bernd ; VÖCKING, Henner ; WITTING,
Katrin ; GAUSEMEIER, Jürgen (Hrsg.): Selbstoptimierende Systeme des Ma-
schinenbaus - Definitionen und Konzepte. 1. Auflage. Paderborn, Germany
: Bonifatius GmbH, 2004 (HNI-Verlagsschriftenreihe Band 155)
[FH05] FRÄNZLE, Martin ; HERDE, Christian: Efficient Proof Engines for Bounded
Model Checking of Hybrid Systems. In: Electr. Notes Theor. Comput. Sci.
133 (2005), S. 119–137
[Fre05] FREHSE, Goran: PHAVer: Algorithmic Verification of Hybrid Systems Past
HyTech. In: HSCC, Springer Verlag, 2005 (Lecture Notes in Computer
Science (LNCS)), S. 258–273
[Föl05] FÖLLINGER, Otto: Regelungstechnik. Einführung in die Methoden und ihre
Anwendung. Hüthig, 2005
[GB04] GIESE, Holger ; BURMESTER, Sven: Analysis and Synthesis for Parame-
terized Timed Sequence Diagrams. In: GIESE, Holger (Hrsg.) ; KRÜGER,
Ingolf (Hrsg.): Proc. of the 3rd International Workshop on Scenarios and
State Machines: Models, Algorithms, and Tools (ICSE 2003 Workshop W5S),
Edinburgh, Scotland, IEE, May 2004, S. 43–50
[GBSO04] GIESE, Holger ; BURMESTER, Sven ; SCHÄFER, Wilhelm ; OBERSCHELP,
Oliver: Modular Design and Verification of Component-Based Mechatro-
nic Systems with Online-Reconfiguration. In: Proc. of 12th ACM SIGS-
OFT Foundations of Software Engineering 2004 (FSE 2004), Newport Be-
ach, USA, ACM Press, November 2004, S. 179–188
[Ge05] GAUSEMEIER, Jürgen ; ET al.: Sonderforschungsbereich 614 - Selbstopti-
mierende Systeme des Maschinenbaus, 2. Förderperiode, Finanzierungsan-
trag.. Bd. 1. Universität Paderborn, 2005
166
[GH04] GRAF, Susanne ; HOOMAN, Jozef: Correct Development of Embedded Sys-
tems. In: OQUENDO, Flavio (Hrsg.) ; WARBOYS, Brian (Hrsg.) ; MORRISI-
ON, Ron (Hrsg.): Proceedings of the First European Workshop on Software
Architecture, EWSA2004 Bd. 3047. St Andrews, UK : Springer Verlag, May
21-22 2004 (Lecture Notes in Computer Science (LNCS)), S. 241–249
[GH06] GIESE, Holger ; HENKLER, Stefan: A Survey of Approaches for the Visu-
al Model-Driven Development of Next Generation Software-Intensive Sys-
tems. In: Journal of Visual Languages and Computing Bd. 17, 2006, S.
528–550
[Gie00] GIESE, Holger: Contract-based Component System Design. In: RALPH
H. SPRAGUE, Jr. (Hrsg.): Thirty-Third Annual Hawaii International Confe-
rence on System Sciences (HICSS-33), Maui, Hawaii, USA, IEEE Computer
Press, Januar 2000
[Gie03] GIESE, Holger: A Formal Calculus for the Compositional Pattern-Based
Design of Correct Real-Time Systems. / Lehrstuhl für Softwaretechnik, Uni-
versität Paderborn. Paderborn, Deutschland, July 2003 (tr-ri-03-240). – For-
schungsbericht
[GMMP91] GHEZZI, Carlo ; MANDRIOLI, Dino ; MORASCA, Sandro ; PEZZÈ, Mauro:
A Unified High-Level Petri Net Formalism for Time-Critical Systems. In:
IEEE Trans. Softw. Eng. 17 (1991), Nr. 2, S. 160–172. – ISSN 0098–5589
[GSB98] GROSU, Radu ; STAUNER, Thomas ; BROY, Manfred: A Modular Visual
Model for Hybrid Systems. In: FTRTFT ’98: Proceedings of the 5th Inter-
national Symposium on Formal Techniques in Real-Time and Fault-Tolerant
Systems Bd. 1486. London, UK : Springer Verlag, 1998 (Lecture Notes in
Computer Science (LNCS)). – ISBN 3–540–65003–2, S. 75–91
[GT06] GIESE, Holger ; TICHY, Matthias: Component-Based Hazard Analysis: Op-
timal Designs, Product Lines, and Online-Reconfiguration. In: Proc. of the
25th International Conference on Computer Safety, Security and Reliability
(SAFECOMP), Gdansk, Poland, Springer Verlag, September 2006 (Lecture
Notes in Computer Science (LNCS)), S. 156–169
[GTB+03] GIESE, Holger ; TICHY, Matthias ; BURMESTER, Sven ; SCHÄFER, Wil-
helm ; FLAKE, Stephan: Towards the Compositional Verification of Real-
Time UML Designs. In: Proc. of the 9th European software engineering
conference held jointly with 11th ACM SIGSOFT international symposium
on Foundations of software engineering (ESEC/FSE-11), ACM Press, Sep-
tember 2003, S. 38–47
167
Kapitel 8 Literaturverzeichnis
[GVH03] GYAPAY, Szilvia ; VARRÓ, Dániel ; HECKEL, Reiko: Graph transformation
with time. In: Fundam. Inf. 58 (2003), Nr. 1, S. 1–22. – ISSN 0169–2968
[Hen00] HENZINGER, Thomas A.: Masaccio: A Formal Model for Embedded Com-
ponents. In: Proceedings of the First IFIP International Conference on Theo-
retical Computer Science (TCS) Bd. 1872, 2000 (Lecture Notes in Computer
Science (LNCS)), 549-563
[Her99] HERRMANN, Debra S.: Software Safety and Reliability : Techniques, Ap-
proaches, and Standards of Key Industrial Sectors. IEEE Computer Press,
1999. – ISBN 0769502997
[HHT96] HABEL, Annegret ; HECKEL, Reiko ; TAENTZER, Gabriele: Graph Gram-
mars with Negative Application Conditions. In: Fundamenta Informaticae
26 (1996), Nr. 3/4, S. 287–313
[HHWT95] HENZINGER, Thomas A. ; HO, P.-H. ; WONG-TOI, H.: HyTech: The Next
Generation. In: RTSS ’95: Proceedings of the 16th IEEE Real-Time Systems
Symposium (RTSS ’95). Washington, DC, USA : IEEE Computer Press,
December 1995. – ISBN 0–8186–7337–0, S. 55–65
[HIM98] HIRSCH, Dan ; INVERARDI, Paolo ; MONTANARI, Ugo: Graph grammars
and constraint solving for software architecture styles. In: ISAW ’98: Pro-
ceedings of the third international workshop on Software architecture. New
York, NY, USA : ACM, 1998. – ISBN 1–58113–081–3, S. 69–72
[HKPV98] HENZINGER, Thomas A. ; KOPKE, Peter W. ; PURI, Anuj ; VARAIYA, Pra-
vin: What’s decidable about hybrid automata? In: Journal of Computer and
System Sciences 57 (1998), S. 94–124
[Hof07] HOFFMANN, Thomas: Spezifikation und Synthese von Konnektorverhalten
für Mechatronic UML. Fakultät für Elektrotechnik, Informatik und Mathe-
matik / Institut für Informatik, Universität Paderborn, Bachelorarbeit, Januar
2007
[HOG04] HESTERMEYER, Thorsten ; OBERSCHELP, Oliver ; GIESE, Holger: Struc-
tured Information Processing For Self-optimizing Mechatronic Systems. In:
ARAUJO, Helder (Hrsg.) ; VIEIRA, Alves (Hrsg.) ; BRAZ, Jose (Hrsg.) ;
ENCARNACAO, Bruno (Hrsg.) ; CARVALHO, Marina (Hrsg.): Proc. of 1st
International Conference on Informatics in Control, Automation and Robo-
tics (ICINCO 2004), Setubal, Portugal, INSTICC Press, August 2004, S.
230–237
[HPPS03] HAHN, Gabor ; PHILIPPS, Jan ; PRETSCHNER, Alexander ; STAUNER, Tho-
mas: Prototype-based Tests for Hybrid Reactive Systems. In: Proc. 14th
168
IEEE Intl. Workshop on Rapid System Prototyping (RSP’03), 2003, S. 78–
85
[HSE02] HESTERMEYER, Thorsten ; SCHLAUTMANN, Philipp ; ETTINGSHAUSEN,
Clemens: Active suspension system for railway vehicles-system design and
kinematics. In: Proc. of the 2nd IFAC - Confecence on mechatronic systems.
Berkeley, California, USA, December 2002, S. 9–11
[HTBS08] HENKE, Christian ; TICHY, Matthias ; BÖCKER, Joachim ; SCHÄFER, Wil-
helm: Organization and Control of Autonomous Railway Convoys. In: Pro-
ceedings of the 9th International Symposium on Advanced Vehicle Control,
Kobe, Japan, 2008. – accepted
[HU79] HOPCRAFT, John E. ; ULLMAN, Jeffrey D.: Introduction to Automata Theo-
ry, Languages, and Computation. Addison-Wesley, 1979
[HVB+05] HENKE, Christian ; VÖCKING, Henner ; BÖCKER, Joachim ; FRÖHLEKE,
Norbert ; TRÄCHTLER, Ansgar: Convoy Operation of Linear Motor Driven
Railway Vehicles. In: Proc. of the Fifth International Symposium on Line-
ar Drives for Industry Applications - LDIA2005, Awaji Yumebutai, Hyogo,
Japan, 2005
[HWLL04] HSU, Chun-Fei ; WANG, Wen-June ; LEE, Tsu-Tian ; LIN, Chih-Min: Lon-
gitudinal control of vehicle platoon via wavelet neural network. In: SMC (4),
2004, S. 3811–3816
[IML92] ISERMANN, Rolf ; MATKO, Drago ; LACHMANN, Karl-Heinz: Adaptive
Control Systems. Upper Saddle River, NJ, USA : Prentice-Hall, Inc., 1992.
– ISBN 0130054143
[Iva03] IVANCIC, Franjo: Modeling and Analysis of Hybrid Systems, University of
Pennsylvania, Diss., 2003
[JGGS00] JENSEN, Henrik E. ; GULDSTR, Kim ; GULDSTR, Kim ; SKOU, Arne: Sca-
ling up Uppaal Automatic Verification of Real-Time Systems using Com-
positionality and Abstraction. In: Proceedings of the 6th International
Symposium on Formal Techniques in Real-Time and Fault-Tolerant Systems
(FTRTFT 2000) Bd. 1926. Pune, India : Springer Verlag, September 2000
(Lecture Notes in Computer Science (LNCS)), S. 19–30
[Kle08] KLEIN, Florian: A Model-Driven Approach to Multi-Agent System Design.
Fakultät für Elektrotechnik, Informatik und Mathematik / Institut für Infor-
matik, Universität Paderborn, PhD Dissertation, 2008. – eingereicht
169
Kapitel 8 Literaturverzeichnis
[KM98] KRAMER, J. ; MAGEE, J.: Analysing Dynamic Change in Software Ar-
chitectures: A Case Study. In: CDS ’98: Proceedings of the International
Conference on Configurable Distributed Systems. Washington, DC, USA :
IEEE Computer Society, 1998. – ISBN 0–8186–8451–8, S. 91
[KMR02] KNAPP, A. ; MERZ, S. ; RAUH, C.: Model Checking timed UML State Ma-
chines and Collaborations. 7th International Symposium on Formal Techni-
ques in Real-Time and Fault Tolerant Systems (FTRTFT 2002), Oldenburg,
September 2002, Lecture Notes in Computer Science volume 2469 pages
395-414. Springer-Verlag, 2002
[KMS92] KRAMER, Jeff ; MAGEE, Jeff ; SLOMAN, Morris: Configuring distributed
systems. In: EW 5: Proceedings of the 5th workshop on ACM SIGOPS Eu-
ropean workshop. New York, NY, USA : ACM, 1992, S. 1–5
[Kop97] KOPETZ, Hermann: Real-Time Systems: Design Principles for Distributed
Embedded Applications. Norwell, MA, USA : Kluwer Academic Publishers,
1997. – ISBN 0792398947
[KP91] KESTEN, Yonit ; PNUELI, Amir: Timed and Hybrid Statecharts and Their
Textual Representation. In: Proceedings of the Second International Sympo-
sium on Formal Techniques in Real-Time and Fault-Tolerant Systems Bd.
571. London, UK : Springer Verlag, 1991 (Lecture Notes in Computer
Science (LNCS)), S. 591–620
[Krä06] KRÄMER, Helmer: Laufzeitanpassung von Softwarestrukturen für mecha-
tronische Systeme, University of Paderborn / Fakultät für Elektrotechnik –
Informatik – Mathematik / Fachgebiet Softwaretechnik, Diplomarbeit, Au-
gust 2006
[KSPL06] KRATZ, Fabian ; SOKOLSKY, Oleg ; PAPPAS, George J. ; LEE, Insup: R-
Charon, a Modeling Language for Reconfigurable Hybrid Systems. In:
HSCC, 2006, S. 392–406
[Kud05] KUDAK, Margarete: Modulare Echtzeitverifikation hybrider UML-
Komponenten, University of Paderborn / Fakultät für Elektrotechnik – Infor-
matik – Mathematik / Fachgebiet Softwaretechnik, Diplomarbeit, December
2005
[Lev95] LEVESON, Nancy G.: Safeware : system safety and computers. Addison-
Wesley, 1995. – ISBN 0–201–11972–2
[LHLH01] LÜCKEL, Joachim ; HESTERMEYER, Thorsten ; LIU-HENKE, Xiaobo: Ge-
neralization of the Cascade Principle in View of a Structured Form of Me-
chatronic Systems. In: IEEE/ASME International Conference on Advanced
170
Intelligent Mechatronics (AIM 2001), Villa Olmo, Como, Italy Bd. 1, IEEE
Service Center, Piscataway, 2001, S. 123–128
[LM99] LIBERZON, Daniel ; MORSE, A. S.: Basic problems in stability and design
of switched systems. In: IEEE Control Systems Magazine 19 (1999), S. 59–
70
[Lud95] LUDYK, G.: Theoretische Regelungstechnik 1, Grundlagen, Synthese linea-
rer Regelungssysteme. Berlin / Heidelberg : Springer Verlag, 1995
[M´
96] MÉTAYER, Daniel L.: Software architecture styles as graph grammars. In:
SIGSOFT ’96: Proceedings of the 4th ACM SIGSOFT symposium on Foun-
dations of software engineering. New York, NY, USA : ACM, 1996. – ISBN
0–89791–797–9, S. 15–23
[Met07] METZLER, Björn: Decomposing Integrated Specifications for Verification.
In: DAVIES, Jim (Hrsg.) ; GIBBONS, Jeremy (Hrsg.): IFM Bd. 4591, Sprin-
ger Verlag, 2007 (Lecture Notes in Computer Science (LNCS)), S. 459–479
[MW07] METZLER, Björn ; WEHRHEIM, Heike: Extending a Component Specifi-
cation Language with Time. In: Electron. Notes Theor. Comput. Sci. 176
(2007), Nr. 2, S. 47–67. – ISSN 1571–0661
[Neu07] NEUMANN, Stefan: Modellierung und Verifikation von zeitbehafteten
Graphtransformationssystemen mittels GROOVE, University of Paderborn
/ Fakultät für Elektrotechnik – Informatik – Mathematik / Fachgebiet Soft-
waretechnik, Diplomarbeit, September 2007
[OHG04] OBERSCHELP, Oliver ; HESTERMEYER, Thorsten ; GIESE, Holger: Struk-
turierte Informationsverarbeitung für selbstoptimierende mechatronische
Systeme. In: Proc. of the Second Paderborner Workshop Intelligen-
te Mechatronische Systeme Bd. 145. Paderborn, Germany, 2004 (HNI-
Verlagsschriftenreihe), S. 43–56
[OMG07] OMG ; OBJECT MANAGEMENT GROUP (Hrsg.): UML 2.1.2 Superstructure
Specification. Document: formal/07-11-01. : Object Management Group,
November 2007
[OMT98] OREIZY, Peyman ; MEDVIDOVIC, Nenad ; TAYLOR, Richard N.:
Architecture-based runtime software evolution. In: ICSE ’98: Proceedings
of the 20th international conference on Software engineering. Washington,
DC, USA : IEEE Computer Society, 1998. – ISBN 0–8186–8368–6, S. 177–
186
171
Kapitel 8 Literaturverzeichnis
[PJ04] PRAJNA, Stephen ; JADBABAIE, Ali: Safety Verification of Hybrid Systems
Using Barrier Certificates. In: ALUR, Rajeev (Hrsg.) ; PAPPAS, George J.
(Hrsg.): HSCC Bd. 2993, Springer Verlag, 2004 (Lecture Notes in Computer
Science (LNCS)), 477-492
[PP05] PAPACHRISTODOULOU, Antonis ; PRAJNA, Stephen: A Tutorial on Sum
of Squares Techniques for Systems Analysis. In: Proceedings of the Ameri-
can Control Conference (ACC). Portland, OR, 2005. Bd. 4, IEEE Computer
Press, 2005, S. 2686 – 2700
[PQ08] PLATZER, André ; QUESEL, Jan-David: Logical Verification and Systema-
tic Parametric Analysis in Train Control. In: EGERSTEDT, Magnus (Hrsg.) ;
MISHRA, Bud (Hrsg.): Hybrid Systems: Computation and Control, 10th In-
ternational Conference, HSCC 2008, St. Louis, USA, Proceedings, Springer
Verlag, 2008 (Lecture Notes in Computer Science (LNCS))
[Pra05] PRAJNA, Stephen: Optimization-Based Methods for Nonlinear and Hybrid
Systems Verification. California Institute of Technology, Pasadena, Calofor-
nia, California Institute of Technology, PhD Dissertation, 2005
[Ren04] RENSINK, Arend: The GROOVE Simulator: A Tool for State Space Ge-
neration. In: PFALZ, J. (Hrsg.) ; NAGL, M. (Hrsg.) ; BÖHLEN, B. (Hrsg.):
Applications of Graph Transformations with Industrial Relevance (AGTIVE)
Bd. 3062, Springer Verlag, 2004 (Lecture Notes in Computer Science (LN-
CS)), S. 479–485
[Ric96] RICHERT, Jobst: Integration of Mechatronic Design Tools with CAMeL,
Exemplified by Vehicle Convoy Control Design. In: Proc. of the IEEE Inter-
national Symposium on Computer Aided Control System Design. Dearborn,
Michigan, USA : IEEE Computer Press, 1996, S. 516–523
[RKS06] RENSINK, Arend ; KASTENBERG, Harmen ; STAIJEN, Tom: User Manual
for the GROOVE Tool Set. Department of Computer Science, University of
Twente, 2006
[Roz97] ROZENBERG, Grzegorz: HANDBOOK of GRAPH GRAMMARS and COM-
PUTING by GRAPH TRANSFORMATION, Volume 1: Foundations. World
Scientific, 1997. – ISBN 9810228848
[SB03] SAMAD, T. (Hrsg.) ; BALAS, G. (Hrsg.): Software-Enabled Control: In-
formation Technology for Dynamical Systems. IEEE Press and Wiley-
Interscience, 2003. – 419 S.
[Sch06] SCHILLING, Daniela: Kompositionale Softwareverifikation mechatronischer
Systeme. Fakultät für Elektrotechnik, Informatik und Mathematik / Institut
172
für Informatik, Universität Paderborn, PhD Dissertation, 2006
[SPP01] STAUNER, T. ; PRETSCHNER, A. ; PÉTER, I.: Approaching a Discrete-
Continuous UML: Tool Support and Formalization. In: Proc. UML’2001
workshop on Practical UML-Based Rigorous Development Methods – Coun-
tering or Integrating the eXtremists. Toronto, Canada : Gesellschaft für In-
formatik, October 2001, S. 242–257
[SRKC00] SILVA, B. ; RICHESON, K. ; KROGH, B. ; CHUTINAN, A.: Modeling and
verification of hybrid dynamical system using CheckMate. In: ADPM 2000,
Shaker, 09 2000
[STF96] SHARASHIMA, F. ; TOMIZUKA, M. ; FUKUDA, T.: Mechatronics - „What Is
It, Why, and How?“ An Editorial. In: Transactions on Mechatronics Bd. 1.
IEEE/ASME Transactions on Mechatronics, 1996, S. 1–4
[SW07] SCHÄFER, Wilhelm ; WEHRHEIM, Heike: The Challenges of Building Ad-
vanced Mechatronic Systems. In: FOSE ’07: 2007 Future of Software Engi-
neering. Washington, DC, USA : IEEE Computer Society, 2007, S. 72–84
[TGM00] TAENTZER, Gabriele ; GOEDICKE, Michael ; MEYER, Torsten: Dynamic
Change Management by Distributed Graph Transformation: Towards Con-
figurable Distributed Systems. In: TAGT’98: Selected papers from the 6th
International Workshop on Theory and Application of Graph Transforma-
tions. London, UK : Springer-Verlag, 2000. – ISBN 3–540–67203–6, S.
179–193
[Tic08] TICHY, Matthias: Analyse und Verbesserung der Verlässlichkeit mechatro-
nischer Systeme. Fakultät für Elektrotechnik, Informatik und Mathematik
/ Institut für Informatik, Universität Paderborn, PhD Dissertation, 2008. –
eingereicht
[TK02] TIWARI, Ashish ; KHANNA, Gaurav: Series of Abstractions for Hybrid Au-
tomata. In: TOMLIN, C.J. (Hrsg.) ; GREENSTREET, M.R. (Hrsg.): Procee-
dings of the 5th International Workshop on Hybrid Systems: Computation
and Control (HSCC 2002) Bd. 2289. Stanford, CA, USA : Springer Verlag,
März 2002 (Lecture Notes in Computer Science (LNCS)), S. 465ff
[TMV06] TRÄCHTLER, Ansgar ; MÜNCH, Eckehard ; VÖCKING, Henner: Iterati-
ve Learning and Self-Optimization Techniques for the Innovative Railcab-
System. In: Proceedings of the 32nd Annual Conference of the IEEE Indus-
trial Electronics Society (IECON’06), IEEE Computer Press, 2006. – ISBN
1–4244–0391–X, S. 4683–4688
173
Kapitel 8 Literaturverzeichnis
[Tri04] TRIPAKIS, Stavros: Folk Theorems on the Determinization and Minimizati-
on of Timed Automata. In: Formal Modeling and Analysis of Timed Systems:
First International Workshop, FORMATS 2003, Marseille, France, Septem-
ber 6-7, 2003. Revised Papers, 2004. – ISBN 3–540–21671–5, S. 182 –
188
[Voe03] VOECKING, Henner: Multirate-Verfahren und Umschaltstrategien für ver-
teilte Reglersysteme, Universität Paderborn, Diplomarbeit, 2003
[Wan04] WANG, Farn: Formal Verification of Timed Systems: A Survey and Per-
spective. In: Proceedings of the IEEE Bd. 92, IEEE Computer Press, August
2004, S. 1283–1307
[Win90] WING, Jeannette M.: A Specifier’s Introduction to Formal Methods. In:
Computer 23 (1990), Nr. 9, S. 8–23. – ISSN 0018–9162
[Woo00] WOOLDRIDGE, Michael: Reasoning about Rational Agents. 1st. The MIT
Press, 2000. – 241 S. – ISBN 0262232138
[YEK98] YANAKIEV, Diana ; EYRE, Jennifer ; KANELLAKOPOULOS, Ioannis: Lon-
gitudinal Control of Heavy Duty Vehicles: Experimental Evaluation / Uni-
versity of California. Berkeley, CA, USA, 1998 (California PATH Research
Report UCB-ITS-PRR-98-15). – Forschungsbericht
[ZC06] ZHANG, Ji ; CHENG, Betty H. C.: Model-based development of dynami-
cally adaptive software. In: ICSE ’06: Proceeding of the 28th international
conference on Software engineering. New York, NY, USA : ACM, 2006. –
ISBN 1–59593–375–1, S. 371–380
[ZEA03] ZAMBOU, N. ; ENNING, M. ; ABEL, D.: Längsdynamikregelung eines Fahr-
zeugkonvois mit Hilfe der Modellgestützten Prädikativen Regelung. In: Tele-
matik 2003 Bd. VDI-Berichte 1785. Düsseldorf, Deutschland : VDI-Verlag,
2003
[Zün01] ZÜNDORF, Albert: Rigorous Object Oriented Software Development. Habi-
litation Thesis, University of Paderborn, 2001
[ZZ05] ZLOCKI, A. ; ZAMBOU, N.: Application of WLAN vehicle-to-vehicle com-
munication for automatic guidance of a vehicle driven in platoon. In: Pro-
ceedings of the 2nd International Workshop on Intelligent Transportation
(WIT), März 2005, Hamburg, 2005
174
Anhang A
Algorithmen zu zeitbehaften
Graphtransformationssystemen
In diesem Anhang werden die Algorithmen, die bei der Erreichbarkeitsanalyse für zeitbe-
haftete Graphtransformationssysteme (siehe Abschnitt 4.4) verwendet werden, aufgelis-
tet. Die informelle Beschreibung und Anwendung findet sich in Abschnitt 4.4.
Algorithmus A.1 Der Algorithmus N0,E0=graphID(m, x, G, Pl)
procedure N0,E0=graphID(m, x, G, Pl)
1: N0,E0=∅
2: for all n∈ N do
3: vg=mv(V−1
(i,P )(n))
4: n0=V(i,G)(vg)
5: N0=N0∪n0
6: end for
7: for all e∈ E do
8: eg=me(E−1
(i,P )(e))
9: e0=E(i,G)(eg)
10: E0=E0∪e0
11: end for
175
Anhang A Algorithmen zu zeitbehaften Graphtransformationssystemen
Algorithmus A.2 Der Algorithmus hTm, Rmi=assign(m, T, R, G, Pl)
procedure hTm, Rmi=assign(m, T, R, G, Pl)
1: Tm, Rm=∅
2: for all t∈T:t:= x1−x2∼d, xi= (M1,N1,E1), x2:= (M2,N2,E2)do
3: x0
1, x0
2:= x0
4: t0:= x0
1−x0
2∼d
5: if x16=x0then
6: x0
1:= (M1,N0
1,E0
1)mit N0
1,E0
1:= ∅
7: N0
1,E0
1=graphID(m, x1, G, Pl)
8: end if
9: if x26=x0then
10: x0
2:= (M2,N0
2,E0
2)mit N0
2,E0
2:= ∅
11: N0
2,E0
2=gaphID(m, x2, G, Pl)
12: end if
13: Tm=Tm∪t0
14: end for
15: for all r∈R:r:= x, x = (M, N,E)do
16: N0,E0=∅
17: x0:= (M, N0,E0)
18: r0:= x0
19: Erzeuge x0:= (M, N0,E0)mit N0,E0=∅
20: N0,E0:= graphID(m, x, G, Pl)
21: Rm:= Rm∪r0
22: end for
Algorithmus A.3 Der Algorithmus C=prodclock(C, G)
procedure C=prodclock(C, G)
1: C=∅
2: for all c∈ C :c= (M, Cl, Ci)do
3: for all m=prod(Cl, G) : m= (mv, me)do
4: N,E=∅
5: x= (M, N,E)
6: for all v, e ∈Cldo
7: N:= N(i,G)(mv(v))
8: E:= E(i,G)(me(e))
9: end for
10: C=C∪x
11: end for
12: end for
176
Algorithmus A.4 Der Algorithmus φ=clear(C, φ)
procedure φ=clear(C, φ)
1: for all t∈φ:t= (xi−xj∼d)do
2: if xi/∈C∨xj/∈Cthen
3: φ:= φ\t
4: end if
5: end for
Algorithmus A.5 Der Algorithmus G0
t=productionm(Gt, Pt, C, I, m)
procedure G0
t=productionm(Gt, Pt, C, I, m)
1: Gt:= (G, C,Z); Pt:= (Pl, Pr, T, Vi, Ei, R, f, r), m := (mv, me)
2: hT0, R0i=assign(m, T, R)
3: Z0=∅
4: for all φ∈ Z do
5: φ0=succφ(φ, I, T0)
6: if φ0notempty then
7: φ0=succ0
φ(φ0, R0)
8: Z0=Z ∪ φ0
9: end if
10: end for
11: if Z06=∅then
12: G0=prodpost(m, Pl, Pr)
13: C0=prodclock(C, G0)
14: for all φ0∈ Z0do
15: φ0=φ0∩I(G0)
16: φ0=clear(C0, φ0)
17: φ0=succ0
φ(φ0, R0)
18: end for
19: G0
t= (G0,C0,Z0)
20: end if
Algorithmus A.6 Der Algorithmus G0
t=production(Gt, Pt, C, I)
procedure G0
t=production(Gt, Pt, C, I)
1: Gt:= (G, C,Z); Pt:= (Pl, Pr, T, Vi, Ei, R, f, r)
2: G0
t=∅
3: for all m=prodpre(Pl, G) : m:= (vertex, edge, ID)do
4: G0
t=G0
t∪productionm(Gt, Pt, C, I, m)
5: end for
177
Anhang A Algorithmen zu zeitbehaften Graphtransformationssystemen
178
Anhang B
Regeln zum Shuttlebeispiel aus
Kapitel 4
In diesem Anhang werden die zeitbehafteten Graphtransformationsregeln für das Eva-
luierungsbeispiel aus Kapitel 4.5 beschrieben. Abbildungen B.1,B.2 und B.3 beschrei-
ben jeweils die Clockinstanzen, die im System vorkommen. Um das Fortschreiten eines
Clock:cloc
k1
Abbildung B.1: Clockinstanz clock1
Shuttles zu gewährleisten, müssen noch Invarianten spezifiziert werden. Diese sind in den
Abbildungen B.4, B.5 und B.5 dargestellt.
Abschließend werden noch die Regeln benötigt, die das Forschreiten eines Shuttles so-
wohl auf einem normalen Schienenabschnitt, als auch auf einer Weiche beschreiben. Die-
se Regeln besitzen die angegebenen Zeitguards:
179
Anhang B Regeln zum Shuttlebeispiel aus Kapitel 4
Clock:clock2
Abbildung B.2: Clockinstanz clock2
Clock:clock
3
Abbildung B.3: Clockinstanz clock3
Invariante
:
clock2 <=6
Abbildung B.4: Clockinvariante zum Überfahren einer Weiche
180
Invariante:
clock1<=6
Abbildung B.5: Clockinvariante zum Überfahren eines Schienenabschnittes
Invariante:
clock3 <=3
Abbildung B.6: Clockinvariante zum Überfahren eines Schienenabschnittes
Guard: clock1 >=6
Abbildung B.7: Zeitbehaftete Regel zum Forbewegen von einem Schienenabschnitt zum
nächsten
181
Anhang B Regeln zum Shuttlebeispiel aus Kapitel 4
Guard: clock3 >= 3
Abbildung B.8: Zeitbehaftete Regel zum Forbewegen von einem Schienenabschnitt zum
nächsten
182
G
uard: clock3 >=
6
Abbildung B.9: Zeitbehaftete Regel, um von einer Weiche zu fahren
G
uard: clock2 >=
6
Abbildung B.10: Zeitbehaftete Regel, um von einer Weiche zu fahren
183
Anhang B Regeln zum Shuttlebeispiel aus Kapitel 4
Guard: clock1 >=6
Abbildung B.11: Zeitbehaftete Regel, um auf eine Weiche zu fahren
G
uard: clock2 >=
6
Abbildung B.12: Zeitbehaftete Regel, um von einer Weiche zu fahren
184
Abbildungsverzeichnis
1.1 Die Disziplin Mechatronik ergibt sich aus der Kombination der drei Dis-
ziplinen Softwaretechnik, Mechanik und Elektronik . . . . . . . . . . . . 1
1.2 HybridesVerhalten ............................. 2
1.3 Fallstudie „RailCab – Neue Bahntechnik Paderborn“ (Quelle: NBP) . . . 5
(a) ShuttlesimKonvoi.......................... 5
(b) Zwei Shuttles bei der Bildung eines Konvois . . . . . . . . . . . . 5
1.4 Die einzelnen „Bausteine“ zu einer effizienten Verifikation von mechatro-
nischenSystemen.............................. 6
1.5 Kompositioneller Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . 7
(a) Echtzeit-Koordinationsmuster . . . . . . . . . . . . . . . . . . . . 7
(b) Anwendung des Echtzeit-Koordinationsmusters . . . . . . . . . . . 7
1.6 Abstraktion ................................. 8
1.7 Dekomposition der Struktur und des internen Verhaltens . . . . . . . . . 10
1.8 Beispiel für ein Graphtransformationssystem . . . . . . . . . . . . . . . 11
1.9 Regelbasierte Modellierung der Koordination . . . . . . . . . . . . . . . 11
2.1 Hierarchische Struktur eines mechatronischen Systems nach Lückel . . . 14
2.2 Operator-Controller-Modul . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Generelle Struktur einer Steuerung . . . . . . . . . . . . . . . . . . . . . 17
2.4 EinfacherRegelkreis ............................ 17
2.5 ModelderStrecke.............................. 20
2.6 PID Geschwindigkeitsregler . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Stateflow Diagramm der Shuttlesteuerung . . . . . . . . . . . . . . . . . 21
2.8 Hybrides Modell der Shuttelsteuerung . . . . . . . . . . . . . . . . . . . 21
2.9 Ein endlicher Automat mit den Zuständen s0, s1und zwei Kanten, welche
mit aund bbeschriftetsind.......................... 23
2.10 Ein Timed Automaton, der über zwei Location, drei Invarianten und zwei
Kanten mit jeweils einem Guard und einem Clockreset verfügt. . . . . . 25
2.11HybriderAutomat.............................. 27
2.12 Die Abbildung zeigt zwei Graphen, wobei der rechte im linken Graphen
enthaltenist.................................. 29
2.13 Schematische Darstellung einer Regelanwendung. . . . . . . . . . . . . . 31
185
Abbildungsverzeichnis
2.14 Die Abbildung zeigt oben einen Wirtsgraphen, auf den eine Regel (blau
gestrichelt) angewendet wird und durch das Entfernen von Elementen ein
resultierender Graph mit zwei Dangling-Edges entsteht (grau markierte
Kanten im unteren Graph). . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.15 Problem: Hybrides Model Checking . . . . . . . . . . . . . . . . . . . . 35
2.16 Mächtigkeit des Eingabemodells vs. Effizienz beim Model Checking . . . 35
2.17 Der zeitliche Erreichbarkeitsraum des initialen Zustandes des Automaten
aus Abbildung 2.10. Die grau markierten Bereiche entsprechen der Men-
ge der Werte, welche die Clocks x1und x2annehmen können. . . . . . . 36
2.18 Die Clockzone φ.............................. 38
2.19 Echtzeit Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.20 Echtzeit-Koordinationsmuster für die Konvoikoordination . . . . . . . . . 45
(a) Echtzeit-Koordinatiosmuster . . . . . . . . . . . . . . . . . . . . . 45
(b) Rollenverhalten............................ 45
2.21ShuttleKomponente ............................ 46
2.22 Realtime Statechart der Shuttle Komponente . . . . . . . . . . . . . . . . 47
2.23 Einbettung von kontinuierlichen Unterkomponenten in ein hybrides Re-
konfigurationsChart ............................ 49
2.24 Klassendiagramm und Instanziierung eines Echtzeit-Koordinationsmuster 53
(a) Klassendiagramm .......................... 53
(b) Instanziierungsregel: Erzeugung des DistanceCoordinationPattern . 53
2.25Verhaltensregeln .............................. 53
(a) Ein freies Shuttle bewegt sich . . . . . . . . . . . . . . . . . . . . 53
(b) Koordinierte Fahrweise zweier Shuttles . . . . . . . . . . . . . . . 53
2.26 Invariante: Keine unkontrollierte Bewegung zweier benachbarter Shuttles 53
3.1 VerifikationeinesOCM........................... 56
3.2 Schematische Darstellung des Feder-Neige-Moduls . . . . . . . . . . . . 57
3.3 Blockdiagramm der Regler . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4 DieArchitektur............................... 59
3.5 Verhalten der Body Komponente . . . . . . . . . . . . . . . . . . . . . . 60
3.6 Interface Statechart der Komponente BC .................. 60
3.7 Einbettung der Untergeordneten Komponenten im Monitor . . . . . . . . 62
3.8 Verifikation des Echtzeitkoordinationsverhaltens der Software, modelliert
durch Komponenten und Echtzeit-Koordinatiosmuster . . . . . . . . . . . 63
3.9 Abstraktion ................................. 64
3.10 Schema für die syntaktische Überprüfung bei der korrekten Einbettung
und korrekten Rekonfiguration . . . . . . . . . . . . . . . . . . . . . . . 69
3.11 Verhalten der BC Komponente ....................... 71
3.12 Interface Statechart der Komponente Sensor ................ 72
3.13 Einbettung von Verhalten in die Monitor Komponente . . . . . . . . . . . 73
186
Abbildungsverzeichnis
3.14 Dynamische Überprüfung der korrekten Einbettung der Komponentenin-
stanzen ................................... 76
3.15 Synchronisation zwischen Monitor,Sensor und BodyControl ....... 78
3.16 Timed Automaton des Interface Statecharts der BC Komponente . . . . . 78
3.17 Timed Automaton des Interface Statecharts der Sensor Komponente . . . 78
3.18 Timed Automaton des Monitor Verhaltens . . . . . . . . . . . . . . . . . 79
4.1 Beispiel für ein Graphtransformationssystem . . . . . . . . . . . . . . . 82
4.2 Beispiel für ein zeitbehaftetes Graphtransformationssystem . . . . . . . . 83
4.3 Das durch einen Graphen beschriebene Shuttlesystem . . . . . . . . . . . 85
4.4 Ein Beispiel für ein Graphtransformationssystem mit zwei Graphen G1,
G2und einer Graphtransformationsregel P1................ 86
4.5 Ein dem Graphtransformationssystem in Abbildung 4.4 entsprechender
Automat................................... 87
4.6 Zuordnung der zeitlichen Bestandteile zu den festen Strukturen des
TimedAutomaton. ............................. 89
4.7 Zuordnung einer Clock c zu einer Graphtransformationsregel . . . . . . . 90
4.8 Der Graph Gverfügt über zwei Stellen, bei denen die Graphtransfor-
mationsregel mit der zeitlichen Bedingung c≥3angewendet werden
kann...................................... 91
4.9 Die Abbildung zeigt auf der linken Seite eine Anwendungsregel mit den
attributierten Elementen, welche der Clock czugehörig sind. Rechts ist
die daraus abgeleitete Clockinstanzregel dargestellt. . . . . . . . . . . . . 92
4.10 Eine um Clockreset erweiterte Graphtransformationsregel. Dabei wird die
Clock cnach Anwendung der Regel auf den Wert 0zurück gesetzt. . . . . 93
4.11 Die Regel fügt einem Graphen die Invariante d < 11 hinzu. . . . . . . . . 94
4.12 Die beiden Graphen G1und G2, welche über jeweils zwei unterschiedli-
che zeitliche Erreichbarkeitsräume verfügen. . . . . . . . . . . . . . . . . 95
4.13 Zum Wirtsgraphen Gwerden zwei Instanzen x, y der Clockinstanz cer-
zeugt. Dabei ergibt sich x:= (c, {1,2},{5})und y:= (c, {3,4},{7}). . . 96
4.14 Ein Graphtransformationssystem mit einem initialen Startgraphen G1, so-
wie zwei zeitbehaftete Graphtransformationsregeln P1und P2. . . . . . . 101
4.15 Im Wirtsgraphen Gtwird die Graphtransformationsregel Ptan der rot
umrandeten Stelle angewendet . . . . . . . . . . . . . . . . . . . . . . . 105
4.16Schienennetz ................................112
4.17 Das resultierende Graphtransformationssystem . . . . . . . . . . . . . . 113
5.1 Echtzeit-Koordinationsmuster ConvoyCoordination ............117
5.2 Anwendung des Echtzeit-Koordinationsmuster ConvoyCoordination . . . 117
5.3 Konvoi der Länge n.............................118
5.4 Fehlerbaum .................................119
5.5 Dekomposition der Struktur . . . . . . . . . . . . . . . . . . . . . . . . 120
187
Abbildungsverzeichnis
5.6 Parametrisierte Rolle mit zugehöriger Entfaltung und Koordination der
Unterrollen .................................121
5.7 Mögliches Bremsverhalten . . . . . . . . . . . . . . . . . . . . . . . . . 122
(a) Bremsverhalten Netzwerkausfall Fahrzeug 2............122
(b) Bremsverhalten Statorausfall . . . . . . . . . . . . . . . . . . . . . 122
5.8 CAMeL-View-Modell eines geschwindigkeitsgeregelten Fahrzeugs . . . 123
5.9 Struktur der Informationsverarbeitung im Konvoi . . . . . . . . . . . . . 123
5.10 Bremskorridore bei einer mechanischen Notbremsung . . . . . . . . . . . 125
5.11 Modellierung und Koordination eines multi-Ports – jedem Port und damit
Shuttle wird eine Eigenschaft pizugeordnet ................126
5.12 Beispielkommunikation für 3Shuttles im Konvoi mit Netzwerkausfall . . 127
5.13 Parametrisiertes Koordinationsmuster . . . . . . . . . . . . . . . . . . . 128
5.14 Der Typ Shuttle ...............................129
5.15 Laufzeit-Instanz zweier Shuttles, welche das parametrisierte Koordinati-
onsmuster ConvoyCoordination anwenden.................129
5.16 Das Verhalten einer parametrisierten Rolle coordinator ..........130
5.17 Das Verhalten der Rolle shuttle .......................131
5.18 Hierarchische Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.19 Synchronisationsstatecharts der Komponente Shuttle ...........132
5.20 Koordinationsstatechart für die multi-Rolle . . . . . . . . . . . . . . . . 133
5.21 Verfeinerte shuttle Rolle ..........................133
5.22 Initiale Regel zur Anwendung des parametrisierten Koordinationsmusters 134
5.23 Regel zur Erzeugung einer Zeitinvariante . . . . . . . . . . . . . . . . . 135
5.24 Ein Shuttle reiht sich hinten in den Konvoi ein . . . . . . . . . . . . . . . 135
5.25 Instanzsicht nach der Anwendung von Regel aus Abbildung 5.24 . . . . . 135
5.26 Letztes Shuttle verlässt den Konvoi . . . . . . . . . . . . . . . . . . . . . 136
5.27 Konvoi der Länge 2wirdaufgelöst.....................136
5.28 Führungsshuttle verlässt den Konvoi . . . . . . . . . . . . . . . . . . . . 137
B.1 Clockinstanzclock1.............................179
B.2 Clockinstanzclock2.............................180
B.3 Clockinstanzclock3.............................180
B.4 Clockinvariante zum Überfahren einer Weiche . . . . . . . . . . . . . . . 180
B.5 Clockinvariante zum Überfahren eines Schienenabschnittes . . . . . . . . 181
B.6 Clockinvariante zum Überfahren eines Schienenabschnittes . . . . . . . . 181
B.7 Zeitbehaftete Regel zum Forbewegen von einem Schienenabschnitt zum
nächsten...................................181
B.8 Zeitbehaftete Regel zum Forbewegen von einem Schienenabschnitt zum
nächsten...................................182
B.9 Zeitbehaftete Regel, um von einer Weiche zu fahren . . . . . . . . . . . . 183
B.10 Zeitbehaftete Regel, um von einer Weiche zu fahren . . . . . . . . . . . . 183
B.11 Zeitbehaftete Regel, um auf eine Weiche zu fahren . . . . . . . . . . . . 184
188
Abbildungsverzeichnis
B.12 Zeitbehaftete Regel, um von einer Weiche zu fahren . . . . . . . . . . . . 184
189