Parallele numerische Verfahren
zur quantitativen Analyse
logistischer Systeme
Dissertation
zur Erlangung des Grades eines
Doktors der Naturwissenschaften
der Universita¨t Dortmund
am Fachbereich Informatik
von
Markus Fischer
Dortmund
2006
Markus Fischer
Lehrstuhl IV - Modellierung und Simulation
Fachbereich Informatik
Universita¨t Dortmund
44227 Dortmund
Tag der mu¨ndlichen Pru¨fung 24.02.2006
Dekan Prof. Dr. Bernhard Steffen
Gutachter Prof. Dr.-Ing. Heinz Beilner, Prof. Dr. Peter Buchholz
i
Kurzfassung
In der vorliegenden Arbeit wird ein numerisches Verfahren zur Lo¨sung sehr großer Markov-
Ketten vorgestellt und seine prinzipielle Eignung und Performance experimentell untersucht.
Das Verfahren basiert auf hierarchischen und asynchronen Iterationen, nutzt eine hierarchi-
sche Kronecker-Darstellung zur Darstellung der Markov-Kette und ist auf einer parallelen Re-
chenarchitektur mit verteiltem Speicher implementiert. Das Verfahren kann Markov-Ketten mit
897 Millionen Zusta¨nden in 2-3 Tagen auf einem Cluster mit 7 Workstations (Dualprozessoren)
lo¨sen.
Die Effizienz des verteilten, asynchronen Verfahrens im Vergleich zur sequentiellen und synchro-
nen Ausfu¨hrung liegt zwischen 0.5 und 0.75. Wie aus der Theorie bekannt ist, ko¨nnen asynchrone
Iterationen einen numerischen Mehraufwand verursachen, d.h. es sind mehr Schritte bis zum Er-
reichen einer Genauigkeitsschranke no¨tig. Dieser Effekt trat in allen Experimenten auf und trug
zum Effizienzverlust bei.
Eine Messung der Performance (Lo¨sungszeit) des Verfahrens ist prinzipiell einfach. Um Ur-
sachen fu¨r gute und schlechte Performance zu finden, ist es zusa¨tzlich notwendig, einen Ein-
blick in das Laufzeitverhalten des Verfahrens zu erlangen. Das Laufzeitverhalten hat bedingt
durch die Asynchronita¨t in Berechnung und Kommunikation einen dynamischen Charakter. Zur
Ermittlung des Laufzeitverhaltens wurden Messungen auf der Ebene des Netzwerks und des
Programm-Codes vorgenommen, Rohdaten in Logfiles protokolliert und schließlich das Rechen-
und Kommunikationsverhalten a-posteriori graphisch aufbereitet und ausgewertet. Dadurch ist
es mo¨glich, Kommunikations-, Platz- und Zeitengpa¨sse in ihrer Entstehung zu analysieren und
ggf. Hinweise auf bessere Implementierungen zu erhalten. Ansatzpunkte fu¨r eine Verbesserung
sind eine Steuerung der Kommunikation und alternative Realisierungen der Asynchronita¨t und
des Kommunikationspuffers.
Die vorliegende Arbeit ist in einen anwendungsorientierten Sonderforschungsbereich zur “Mo-
dellierung großer Netze in der Logistik” eingebettet. Deswegen ist es ein Ziel dieser Arbeit,
die Integrierbarkeit und Anwendbarkeit des Markov-Ketten-Instrumentariums im Kontext der
quantitativen Analyse logistischer Systeme zu eruieren. Die Anwendbarkeit wird anhand von
Analysen einer Stu¨ckgut-Umschlaghalle, Lieferketten und Prozessen mit ausfallbehafteten Res-
sourcen exemplifiziert.
ii
Danksagung
An dieser Stelle mo¨chte ich allen Menschen danken, die durch Ihre Hilfe zum Gelingen dieser
Arbeit beitrugen. Mein besonderer Dank gilt meinem Doktorvater Prof. Dr.-Ing. Heinz Beilner
fu¨r die Schaffung exzellenter Arbeitsbedingungen und seine Unterstu¨tzung und Lenkung hin zur
Fertigstellung der Dissertation. Des Weiteren danke ich Prof. Dr. Peter Buchholz und Dr. Peter
Kemper, die mich bereits wa¨hrend des Informatik-Studiums an die Thematik der Dissertation
herangefu¨hrt haben und deren Arbeiten das Fundament dieser Dissertation bilden. Ich danke
Prof. Dr. Peter Buchholz fu¨r die U¨bernahme des Zweitgutachtens.
Allen Mitarbeitern des Lehrstuhls IV “Modellierung und Simulation” danke ich fu¨r die freund-
liche und kooperative Arbeitsatmospha¨re. Besonderer Dank gilt Dipl.-Ing. Zenghui Wu fu¨r
die zuverla¨ssige Unterstu¨tzung bei der Implementierung des Analyseverfahrens und Dipl.-Inf.
Ju¨rgen Ma¨ter fu¨r die Kooperation mit einer studentischen Projektgruppe.
iii
Inhaltsverzeichnis
1 Einleitung 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Diskrete ereignis-gesteuerte dynamische Systeme 9
2.1 DEDS Modellbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Stochastische Petri-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Probabilistische Automaten . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Stochastische Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 DEDS Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Markov-Ketten 16
3.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Hierarchiebildung und Komposition . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Numerische Verfahren zur stationa¨ren Analyse . . . . . . . . . . . . . . . . . . . 23
3.4 Beispiele Markov-Ketten Modellbildung . . . . . . . . . . . . . . . . . . . . . . . 24
4 Hierarchische und asynchrone lineare Fixpunkt-Iterationen 26
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Stationa¨re Iterationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Nicht-stationa¨re hierarchische Iterationen . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Stochastische asynchrone Iterationen . . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Verteilte sowie hierarchische und asynchrone Iterationen zur stationa¨ren Ana-
lyse von Markov-Ketten - ASYNC 37
5.1 Einleitung und U¨bersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Konvergenzverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.1 Stationa¨res Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.2 Nicht-stationa¨res hierarchisches Szenario . . . . . . . . . . . . . . . . . . . 41
5.2.3 Stochastisches asynchrones Szenario . . . . . . . . . . . . . . . . . . . . . 45
5.2.4 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Parallele Rechnerarchitektur und Programmmodell . . . . . . . . . . . . . . . . . 50
5.4 Algorithmisches Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4.1 Semantik kommunizierter Vektoren . . . . . . . . . . . . . . . . . . . . . . 53
1
5.4.2 Varianten asynchroner Iterationen . . . . . . . . . . . . . . . . . . . . . . 54
5.4.3 Selektive Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.4 Steuerung der Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5 Lastverteilung und Kommunikationsaufwand . . . . . . . . . . . . . . . . . . . . 58
5.6 Implementierungsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6.1 Software-Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6.2 Anbindung und Verwendung externer Software . . . . . . . . . . . . . . . 63
5.6.3 Asynchrone Kommunikation mit Puffer . . . . . . . . . . . . . . . . . . . 64
6 Messung und Modellierung der Performance von ASYNC 67
6.1 Performance Messung und Auswertung . . . . . . . . . . . . . . . . . . . . . . . . 68
6.1.1 Netzbelastung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.1.2 Messung in ASYNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.1.3 Asynchronita¨t und Lo¨sungszeit . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1.4 Totale vs. partielle Asynchronita¨t . . . . . . . . . . . . . . . . . . . . . . . 77
6.1.5 Effizienz der verteilten Berechnung . . . . . . . . . . . . . . . . . . . . . . 78
6.1.6 Lo¨sung sehr großer Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2 Performance Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2.1 Performance Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7 Verfu¨gbarmachung des ASYNC Instrumentariums 93
7.1 Prozess-orientierte Modellierung mit ProC/B . . . . . . . . . . . . . . . . . . . . 94
7.2 Modell-Transformation von ProC/B nach Petri Netzen . . . . . . . . . . . . . . . 96
7.3 Hierarchische Kronecker-Darstellung der Markov-Kette . . . . . . . . . . . . . . . 98
7.4 Integration APNN-Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8 Modellbildung und Analyse logistischer Systeme 105
8.1 Methodik der Modellbildung und Analyse . . . . . . . . . . . . . . . . . . . . . . 106
8.2 Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.2.1 Stu¨ckgut-Umschlaghalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.2.2 Aggregat-Berechnung fu¨r Lieferketten . . . . . . . . . . . . . . . . . . . . 115
8.2.3 Prozesse mit ausfallbehafteten Ressourcen . . . . . . . . . . . . . . . . . . 118
8.3 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9 Fazit und Ausblick 129
2
Kapitel 1
Einleitung
Fu¨r die modellbasierte Analyse von IT-Systemen wurden in der Vergangenheit zahlreiche Mo-
dellierungsnotationen und korrespondierende Analyseverfahren entwickelt [20]. Hierbei ist die
Interpretation von IT-Systemen als “Diskrete Ereignisgesteuerte Dynamische Systeme” (DEDS )
[36] essentiell. Etablierte Analyseverfahren wie zum Beispiel analytisch-algebraische Techniken
fu¨r Warteschlangen-Netze, analytisch-numerische Techniken fu¨r stochastische Ketten sowie die
Diskrete Ereignisgesteuerte Simulation haben eine gemeinsame Systemsicht: die eines DEDS.
Die modellbasierte DEDS -Analyse ist methodisch so angelegt, dass analytische Modelle wie
Warteschlangen-Netze und stochastische Ketten - die als Eingabe der Analyseverfahren dienen
- nicht direkt durch einen manuellen Modellierer spezifiziert werden mu¨ssen. Es existieren viele
ho¨hersprachliche, ggf. an Anwendungen (IT etc.) adaptierte Modellierungsnotationen, aus de-
nen analytische Modelle automatisiert ableitbar sind. Prominente Vertreter sind Petri-Netze fu¨r
stochastische Ketten und diverse Simulator-Sprachen fu¨r die Diskrete Ereignisgesteuerte Simu-
lation.
Mittlerweile sind IT-Systeme oft in wirtschaftliche Prozesse (Fertigung, Transport, Gescha¨ftspro-
zesse) eingebunden und deswegen als Teilsysteme einer “u¨bergeordneten Welt” zu sehen. Die
Entscheider in der betrieblichen Praxis interessiert weniger die Performance involvierter IT-
Systeme, als vielmehr die Performance von Gescha¨fts- und Fertigungsprozessen. Die Notwen-
digkeit, ausgehend von IT-Systemen Systemgrenzen zu erweitern, macht es erforderlich, die
u¨bergeordnete Welt “systemtheoretisch” zu interpretieren. Ein wichtige Beobachtung ist, dass
logistische Prozesse und Netzwerke wie auch IT-Systeme als DEDS interpretierbar sind, weil auf-
tretende Gro¨ßen diskret sind (Lagerbestand, Liefermenge) und Ereignisse diskret und asynchron
auftreten (Einlagerung, Auftragseingang) [4].
Im Jahr 1998 fo¨rderte die “Deutsche Forschungsgemeinschaft” die Gru¨ndung des interdiszi-
plina¨ren Sonderforschungsbereichs (SFB) 559 “Modellierung großer Netze der Logistik” [15]
an der Universita¨t Dortmund. Zwei Teilprojekte des SFBs untersuchen seitdem, inwieweit das
fu¨r IT-Systeme entwickelte Portfolio an DEDS -Modellierungsnotationen und -Analyseverfahren
nutzbringend in der Planung logistischer Systeme (Lieferketten, Gescha¨ftsprozesse, Logistik-
netzwerke) einsetzbar ist. Die Herausforderung bei der Planung komplexer logistischer Systeme
besteht darin, involvierte Material-, Wert- und Informationsflu¨sse reibungsfrei und im Sinne
individuell festzulegender Performance-Indikatoren optimal zu gestalten [72].
Der SFB 559, insbesondere das Teilprojekt M2 “Effiziente Analyseverfahren”, ist der Orientie-
rungsrahmen der vorliegenden Arbeit. Die in der vorliegenden Arbeit verfolgte Systematik zur
3
Analyse logistischer Systeme ist in die generelle Systematik des SFB 559 eingebettet und in
Abb. 1.1 dargestellt.
L o g i s t i c S y s t e m
P r o C / B  E d i t o r
P r o C / B  M o d e l
T r a f o
T r a f o
A S Y N C
M a r k o v M o d e l
P e t r i  N e t  M o d e l
L o g i s t i c  P e r f o r -m a n c e  I n d i c a t o r
E v a l u a t o r
S i m u l a t i o nM o d e l Q NM o d e l
T r a f o T r a f o
T e c h n i c a lR e s u l t sS i m u l a t i o nE n g i n e Q NS o l v e r
Abbildung 1.1: Systematik zur Analyse logististischer Systeme
Der erste Schritt der Systematik ist, mit der ProC/B -Notation [11] eine Schnittstelle zwi-
schen der Informatik- und Logistik-Doma¨ne zu etablieren. Die ProC/B -Notation unterstu¨tzt
eine objekt- und prozess-orientierte sowie hierarchische Sichtweise bei der Modellierung. Die
ProC/B Notation hat sowohl Konzepte des Prozessketten-Paradigmas von Kuhn [72] adoptiert,
wodurch Anforderungen und Bedarfe der Logistik beru¨cksichtigt sind, als auch Konzepte des
Modellierungs- und Analyse-Tools HIT von Beilner et al [16], wodurch eine hinreichend formale
Beschreibung und eindeutige Interpretation der Modelle als Voraussetzung fu¨r automatisierte
U¨bersetzungen in formale analytische Modelle erreicht wird. Damit sind bekannte Technologien
der modellbasierten DEDS -Analyse via ProC/B -Schnittstelle anwendungsfreundlich verfu¨gbar.
Der zweite Schritt der Systematik ist, die Methodik der modellbasierten DEDS -Analyse auf ihre
Eignung hin zu pru¨fen und (zum Teil voraussehbare) Defizite zu beheben. Wie in Abb. 1.1 dar-
gestellt, integriert die ProC/B -Schnittstelle neben Markov-Ketten-Modellen auch algebraische
(Warteschlangen)-Modelle und simulative Modelle [11].
In der vorliegenden Arbeit wird die Anbindung und Anwendung des Markov-Ketten-Instrumenta-
riums unter Zuhilfenahme von Petri-Netzen [13] als interne Zwischennotation betrachtet (linker
Strang in Abb. 1.1). Dabei werden Markov-Ketten-Lo¨sungsverfahren experimentell untersucht,
die auf asynchronen und hierarchischen, sowie auf verteilt ausgefu¨hrten linearen Iterationen
beruhen.
4
1.1 Motivation
Die interdisziplina¨re Ausrichtung des SFB 559 “Modellierung großer Netze in der Logistik” spie-
gelt sich in der Vernetzung von Methoden- und Anwendungsprojekten wider. Der Beitrag der
vorliegenden Arbeit gliedert sich ebenso in einen Informatik-Beitrag (Methodik) und in einen
Logistik-Beitrag (Anwendung). Der Informatik-Beitrag ist, die Methodik der modellbasierten
DEDS -Analyse im Bereich der Markov-Ketten-Analyse zu verbessern. Der Logistik-Beitrag ist,
die Methodik im Allgemeinen und Speziellen (Markov-Ketten) auf seine Nu¨tzlichkeit und An-
wendbarkeit im Kontext logistischer Systeme hin zu eruieren. Beide Beitra¨ge werden nachfolgend
erla¨utert.
Logistik-Beitrag Im Management komplexer betrieblicher Systeme hat sich ein prozess-
orientierter Ansatz etabliert, der Prozesse bzw. Wertscho¨pfungsketten bereichsu¨bergreifend be-
trachtet [72, 89]. Solch ein Prozess-Management heißt branchenspezifisch Lieferketten-Mana-
gement (Supply Chain Management:SCM) oder Gescha¨ftsprozess-Management (Business Pro-
cess Management:BPM), Logistiknetz-Management [15] etc. Das Prozess-Management hat 4
Funktionen: 1. Prozess-Planung, 2. Prozess-Implementierung (geplante Prozesse in betriebliche
Anwendungssoftware u¨berfu¨hren), 3. Prozess-Ausfu¨hrung (operative Unterstu¨tzung zur Pro-
zessabwicklung) und 4. Prozess-Controlling (Speicherung, Integration und Aufbereitung ent-
scheidungsrelevanter Daten). Das Ziel von Enterprise Resource Planning (ERP) Tools ist, alle
oben aufgeza¨hlten Funktionen zu unterstu¨tzen. Beispielweise geho¨ren zum SAP-Portfolio fu¨r
SCM [8] die Stammdatenerfassung im R/3-Basissystem (datenorientierte Modellierung), SAP-
APO (Adavanced Planner & Optimizer) fu¨r die Planung, SAP-NetWeaver fu¨r die Implemen-
tierung, SAP-LES (Logistics Execution System) fu¨r die Ausfu¨hrung und SAP-BW (Business
Information Warehouse) fu¨r das Controlling.
Prozess-Planung beinhaltet die Planung neuer Prozesse oder die Reorganisation bestehender
Prozesse unter gegebenen Rahmenbedingungen (existierende, unvera¨nderliche Strukturen, ge-
setzliche Richtlinien, Investitionsrahmen). Die Vorgehensweise hierbei ist, Prozesse in geeigneter
Form zu beschreiben/modellieren, entscheidungsrelevante Performance-Indikatoren zu definieren
und qualitative/quantitative Nutzenpotentiale und Engpa¨sse zu identifizieren und zu bewerten.
Die Erstellung eines aussagekra¨ftigen und realita¨tsnahen Prozess-Modells erfordert einen gewis-
sen Aufwand, bietet aber den prinzipiellen Vorteil, teure Messungen an prototypisch implemen-
tierten Prozessen oder riskante Eingriffe an im Betrieb befindlichen Prozessen zu vermeiden. So
ko¨nnen Prozessabla¨ufe im Modell simuliert und “What-If” Szenarien durch Experimentserien
am Modell getestet werden.
Das Modell kann unter zwei Aspekten bewertet werden. Der erste und in der Praxis weit verbrei-
tete Aspekt ist der, dass eine objekt- und prozessorientierte Modellierung Einblicke in betriebli-
che Abla¨ufe gibt, die es z.B. einem Berater bzw. Analysten ermo¨glicht, mit Intuition, Erfahrung
und Grobabscha¨tzungen Verbesserungsmo¨glichkeiten zu identifizieren. “Erfahrung” ist oft in
praxisgetesteten “Best-Practices” dokumentiert. Fu¨r das SCM sind im “Supply Chain Refe-
rence Modell” (SCOR) [41] diverse Referenzprozesse beschrieben. Eine menschliche Bewertung
des Modells sto¨ßt an Grenzen, wenn viele Planungsszenarien zu beru¨cksichtigen sind. Gewo¨hn-
lich treten bei der Dimensionierung und Disposition von Ressourcen viele Planungsszenarien
auf. Eine menschliche Bewertung sto¨ßt ebenfalls an Grenzen, wenn modellierte Prozessabla¨ufe
komplex und/oder dynamisch sind. In diesem Fall ist die Beziehung zwischen steuernden Mo-
dellparametern und den sie verursachten Wirkungen implizit. Der Ausweg ist eine automati-
5
sierte (rechnergestu¨tzte) Bewertung mit formalen bzw. mathematischen Analysetechniken. Eine
Performance Analyse mit formalen Methoden setzt ein ausfu¨hrbares und hinreichend formales
(=eindeutig interpretierbares) Modell voraus.
Ein Beitrag dieser Arbeit ist, dass Leistungs-Indikatoren wie Laufzeiten von Prozessen und Aus-
lastungen eingesetzter Betriebsmittel mit Markov-Ketten ermittelt werden ko¨nnen. Des Wei-
teren werden Leistungsindikatoren in Kombination mit Zuverla¨ssigkeitsmodellen eingesetzter
Betriebsmittel betrachtet.
Informatik Sicht Markov-Ketten sind stochastische Prozesse, die eine spezifische Klasse von
DEDS beschreiben und im Bereich der quantitativen Performance-Modellierung technischer Sy-
steme weit verbreitet sind [3, 20, 36, 91, 49, 50]. Die stationa¨re Analyse von Markov-Ketten
fu¨hrt zu einem linearen Gleichungssystem - ein Berechnungsproblem, fu¨r das prinzipiell vie-
le erprobte numerische Lo¨sungsverfahren existieren [91]. Logistische Systeme induzieren große
Zustandsra¨ume. Ein damit einhergehender hoher Platz- und Rechenaufwand limitiert die An-
wendbarkeit des Markov-Ketten-Instrumentariums und erzwingt Weiterentwicklungen sowohl
im Bereich mathematischer Modelle numerischer Verfahren als auch bei deren algorithmischer
Umsetzung [49, 50]. In dieser Arbeit wird eine algorithmische Umsetzung vorgestellt.
Implementierungen der Lo¨sungsverfahren zielen auf eine effiziente (Platz und Zeit) Ausfu¨hr-
barkeit ab. Lineare Fixpunkt-Iterationen (Jacobi, Gauss-Seidel) mit Erweiterungen sind als nu-
merische Lo¨sungsverfahren fu¨r Markov-Ketten praxisbewa¨hrt und ko¨nnen mit einer hierarchi-
schen Kronecker-Datenstruktur zur platzeffizienten Speicherung der Markov-Kette angewandt
werden [28, 31, 32, 22, 25, 23, 26, 27, 70, 33]. Von großem Interesse ist eine verteilte Implementie-
rung linearer Fixpunkt-Iterationen, die leistungsfa¨hige Rechen- und Platzkapazita¨ten erschließt.
Ein Ergebnis dieser Arbeit ist eine robuste und performante verteilte Implementierung hierarchi-
scher und asynchroner linearer Fixpunkt-Iterationen: ASYNC. Die Abku¨rzung ASYNC verweist
nachfolgend auf das implementierte Lo¨sungsverfahren und hebt seine besondere Eigenschaft -
die Asynchronita¨t in Berechnung und Kommunikation - hervor.
Das theoretische Konvergenzverhalten hierarchischer und asynchroner Erweiterungen linearer
Fixpunkt-Iterationen ist in der Mathematik untersucht worden [7, 9, 14, 19, 21, 38, 63, 62, 64,
73, 76, 82, 95, 92, 93, 94]. Es ist zuna¨chst nicht offensichtlich, welche der bekannten theoretischen
Ergebnisse im Kontext der stationa¨ren Analyse von Markov-Ketten tatsa¨chlich anwendbar sind
und es ermo¨glichen, den Einfluss von Hierarchie und Asynchronita¨t auf die Konvergenzrate zu
bewerten. Das Ergebnis der Recherche ist, dass Konvergenz gesichert ist, aber Aussagen zum
Einfluss von Hierarchie und Asynchronita¨t auf die Konvergenzrate nicht bekannt sind bzw. sehr
schwach sind. Dies rechtfertigt den experimentellen Ansatz dieser Arbeit.
Reale verteilte Implementierungen asynchroner linearer Fixpunkt-Iterationen sind wenig ver-
breitet und der spezielle Einsatz fu¨r die Lo¨sung großer Markov-Ketten mit einer Ausnahme [45]
neu. Ein Grund fu¨r die geringe Verbreitung ko¨nnte der hohe Entwicklungs- und Testaufwand
sein. Verteilte asynchrone Systeme erfordern einen hohen Implementierungsaufwand bei der
Instanziierung und Verwaltung von (sicheren) Prozessen, bei der Realisation von Kommunika-
tionsroutinen mit asynchroner Semantik und funktional-korrekten Kommunikationsprotokollen
sowie beim Testen (Source-Code wird probabilistisch ausgefu¨hrt). In bekannten experimentellen
Studien u¨ber verteilte und asynchrone Iterationen wird die Beschleunigung und Effizienz gemes-
sen, aber Ursachen fu¨r gute oder schlechte Performance nicht weiter analysiert. In dieser Arbeit
wird der inha¨rent-probabilistische Charakter asynchroner Berechnungen und Kommunikation
6
ex-post basierend auf Trace-Informationen analysiert. Eine Visualisierung der zur Laufzeit ge-
sammelten Trace-Informationen gibt Einblick in und das Versta¨ndnis fu¨r das probabilistische
Laufzeitverhalten. Die vorhandene Experimentierumgebung ermo¨glicht, zwischen verschiedenen
ASYNC -Implementierungsvarianten zu wa¨hlen, um beispielsweise den Grad der Asynchronita¨t
einzustellen. Experimente haben gezeigt, dass schwach-asynchrone Iterationen oft die Performan-
ce total-asynchroner Iterationen erreichen oder sogar verbessern, wenn die Last gut balanziert
ist. Des Weiteren wird in dieser Arbeit fu¨r verschiedene Rechen- und Kommunikations-System-
Konfigurationen experimentell untersucht, wo ASYNC Engpa¨sse induziert. Engpa¨sse im Kom-
munikationsmedium konnten durch eine Steuerung der Kommunikation behoben werden.
Asynchronita¨t in Berechnung und Kommunikation bietet eine gewisse Flexibilita¨t in der Im-
plementierung, die offen la¨ßt, wer, wann, was berechnet und kommuniziert. Aus “theoretischer
Sicht” wird dies als Vorteil angesehen, andererseits stellt sich aus praktischer Sicht die Frage,
ob eine vollkommen ungesteuerte Ausfu¨hrung der Berechnung und Kommunikation sinnvoll ist.
Die Asynchronita¨t und Hierarchisierung der Iteration in ASYNC bieten zahlreiche Parameter,
die das stochastische Laufzeitverhalten und die Konvergenz der numerischen Berechnung be-
einflussen und als Steuerparameter zur Erzielung einer verbesserten Konvergenz und Laufzeit
dienen ko¨nnen. Allerdings hat es sich als schwierig herausgestellt, den Einfluss zu bewerten.
Die Aussagekraft beobachtbarer Wirkzusammenha¨nge aus einzelnen Experimenten ist gering,
weil sie bedingt durch die inha¨rente Stochastik des Laufzeitverhaltens nicht reproduzierbar und
somit nicht allgemeingu¨ltig sind.
Eine modellbasierte Performance-Bewertung synchroner und asynchroner Iterationen umfasst
die zeitliche Bewertung asynchroner Iterationen im Zusammenspiel mit theoretischen Abscha¨t-
zungen der Konvergenzrate [19, 35, 84]. In Erga¨nzung dieser Arbeiten wa¨re eine genauere sy-
stemtheoretische Interpretation hierarchischer und asynchroner Iterationen als Voraussetzung fu¨r
eine stochastische Performance-Modellierung hierarchischer und asynchroner Iterationen sinn-
voll. In dieser Arbeit werden stochastische Modelle fu¨r die zeitliche Bewertung hierarchischer
und schwach-asynchrone Iterationen vorgestellt und die schwierige analytische Handhabbarkeit
diskutiert.
Aufgabenbeschreibung ASYNC zielt auf die Beherrschbarkeit großer Markov-Ketten ab.
Es soll gezeigt werden, dass ASYNC die Performance (=Lo¨sungszeit) und die behandelbare Zu-
standsraumgro¨ße bekannter numerischer Lo¨sungsverfahren effizient verbessert. Die Performance
wird anhand von Messungen evaluiert. Daru¨ber hinaus soll die Mo¨glichkeit einer modellbasier-
ten Performance-Bewertung eruiert werden. Es soll bewertet werden, inwieweit das ASYNC -
Instrumentarium zur quantitativen Analyse logistischer Systeme anwendbar und nu¨tzlich ist
und benutzerfreundlich verfu¨gbar gemacht werden kann.
7
1.2 Organisation
Im Kapitel 2 wird die Klasse der Diskreten Ereignis-gesteuerten Dynamischen Systeme (DEDS )
definiert und eine U¨bersicht zu Modellierungsnotationen und Analyseverfahren gegeben. Die
Interpretation logistischer Systeme als DEDS ist der Ausgangspunkt fu¨r ihre modellbasierte
quantitative Analyse.
Das Kapitel 3 fu¨hrt eine spezielle DEDS -Klasse - Markov-Ketten - ein. Eine hierarchische,
Kronecker-Algebra-basierte Darstellung der Markov-Kette, die als platzeffiziente Datenstruktur
zur Speicherung der Markov-Kette dient, wird informal mit Verweisen auf die Originalarbeiten
eingefu¨hrt. Des Weiteren werden etablierte numerische Lo¨sungsverfahren kurz vorgestellt.
Im Kapitel 4 werden hierarchische und asynchrone Erweiterungen von Fixpunkt-Iterationen
anhand mathematischer Modelle definiert und erkla¨rt.
Im Kapitel 5 wird das hier entwickelte numerische Lo¨sungsverfahren zur stationa¨ren Analyse
von Markov-Ketten - nachfolgend mit ASYNC abgeku¨rzt - vorgestellt. Dies beinhaltet: Syner-
gieeffekte zentraler ASYNC -Eigenschaften, die Bewertung bekannter Konvergenzeigenschaften
hinsichtlich der Anwendbarkeit und Nu¨tzlichkeit (Konvergenzraten) im ASYNC -Kontext, Be-
sonderheiten und Alleinstellungsmerkmale der ASYNC -Implementierung, die Berechnung der
Lastverteilung und weitere Implementierungsaspekte wie die Anbindung externer Software und
die Realisierung asynchroner Kommunikation.
Das Kapitel 6 fokussiert auf die Messung und Modellierung der ASYNC -Performance. In Expe-
rimenten wird der Einfluss der Asynchronita¨t auf ASYNC -Lo¨sungszeiten und die Effizienz der
verteilten Berechnung beobachtet. Das dynamische Laufzeitverhalten von ASYNC wird anhand
visualisierter Traces ex-post analysiert. Des Weiteren wird eine systemtheoretische Interpretati-
on von ASYNC entwickelt, die als Grundlage fu¨r eine stochastische Performance-Modellbildung
dient.
Im Kapitel 7 wird die Einbindung von ASYNC in bestehende Software-Werkzeuge vorgestellt.
Die Einbindung unterstu¨tzt die benutzerfreundliche Verfu¨gbarmachung und Anbindung an die
Logistik-Doma¨ne.
Die Nu¨tzlichkeit des ASYNC -Instrumentariums und der begleitenden Modellierungs-Software
fu¨r die Logistik-Doma¨ne wird im Kapitel 8 demonstriert. Hierfu¨r wird das ASYNC -Instrumenta-
rium und die Modellierungs-Software aus der Perspektive von Logistik-Anforderungen bewertet
und die Performance konkreter logistischer Systeme mit ASYNC analysiert.
8
Kapitel 2
Diskrete ereignis-gesteuerte
dynamische Systeme
Die Dynamik vieler technischer Systeme (Computer, Produktion, Logistik) ist durch diskrete
Zusta¨nde gekennzeichnet, wobei Zustandswechsel u¨ber der Zeit durch diskrete und asynchron
eintretende Ereignisse (Aktionen) ausgelo¨st werden [20, 36]. Dynamische Systeme mit diesen
Eigenschaften geho¨ren zur Klasse Diskreter Ereignis-gesteuerter Dynamischer Systeme (DEDS )
[36]. Der Interpretation eines technischen Systems als DEDS liegt somit die Annahme zugrunde,
dass ein Mechanismus im System Ereignisse/Aktionen generiert. Die Reproduktion bekannter
Aspekte dieses Mechanismus in einem Modell, um daraus a priori unbekannte, implizite oder
am realen System nicht messbare Eigenschaften zu ermitteln, ist Gegenstand und Ziel einer
modellbasierten DEDS -Analyse. Eigenschaften beziehen sich auf funktional-logisches System-
verhalten (Auftreten spezifischer Zustandsfolgen, Erreichbarkeit von Zusta¨nden), oder, wenn
das Auftreten von Ereignissen explizit zeitbehaftet ist, auf quantitative Systemeigenschaften
(Aufenthaltsdauer in Zusta¨nden). Viele Systeme beinhalten stochastisch eintretende Ereignisse,
wobei die Zeitdauer bis zum Ereignis-Eintritt stochastisch quantifiziert sein kann. Die modell-
basierte DEDS -Analyse ist methodisch so angelegt, dass die manuelle Modellbildung durch eine
hochsprachliche Notation unterstu¨tzt ist. Die Notation muss hinreichend ausdrucksma¨chtig sein,
um den Ereignis-Mechanismus ada¨quat zu erfassen. Des Weiteren muss die Notation hinreichend
formal und eindeutig sein, um die automatisierte Erzeugung eines konsistenten analytischen Mo-
dells zu unterstu¨tzen. Fu¨r DEDS sind zahlreiche Modellierungsnotationen und korrespondieren-
de Analyseverfahren bekannt [13, 20, 36, 42, 65, 74].
Der Abschnitt 2.1 fu¨hrt in die DEDS -Modellbildung ein. Hierfu¨r werden zuna¨chst stochastisch-
zeitbehaftete Petri-Netze definiert (Abschnitt 2.1.1) und erla¨utert, wie der unterliegende probabi-
listische Automat (Abschnitt 2.1.2) und der unterliegende stochastische Prozess (Abschnitt 2.1.3)
ableitbar sind. Ansa¨tze zur modellbasierten DEDS -Analyse werden im Abschnitt 2.2 rekapitu-
liert.
9
2.1 DEDS Modellbildung
Fu¨r die DEDS Modellbildung sind zahlreiche ho¨hersprachliche Notationen bekannt, unter ihnen
stochastische, zeitbehaftete Petri-Netze (PN )[1, 2, 10, 13, 20, 36], Warteschlangen und deren
Netzwerke (QN ) [20, 36], Kombinationen aus PN s und QN s [10], sowie eine Vielzahl, auf speziel-
le Sichtweisen und Anforderungen von Systemen angepasste Notationen, wie zum Beispiel Ereig-
nisgesteuerte Prozessketten [89], die ProC/B Notation [11, 72] und diverse Simulator-Sprachen
[74]. Die Notationen dienen dem Zweck, bekannte Aspekte des DEDS -Ereignis-Mechanismus
formal oder semi-formal zu beschreiben.
Fu¨r die Bewertung hochsprachlicher Notationen ko¨nnen folgende Kriterien dienen: die Nota-
tion muss in ihrer Syntax hinreichend ma¨chtig sein, um Eigenschaften des Systems ada¨quat
zu beschreiben; sie muss die Beschreibung des Mechanismus auf ein notwendiges Mindestmaß
reduzieren, indem sie zum Beispiel Redundanzen erfasst; sie muss an Denkweisen und spezifi-
schen Anforderungen des jeweiligen Anwendungsgebiets adaptieren, um Akzeptanz zu finden; sie
muss Strukturen (Teilsysteme, Hierarchien), Symmetrien und sonstige Informationen erfassen
und zuga¨nglich machen, aus denen die Analyse Effizienzsteigerungen erzielen kann; sie muss in
ihrer Semantik hinreichend formal und eindeutig interpretierbar sein, um eine automatisierte
Analyse zu ermo¨glichen und sie muss Restriktionen respektieren, die ggf. durch die ausgewa¨hlte
Analysetechnik vorgegeben sind.
Zustandsraumbasierte Analyseverfahren ko¨nnen gewo¨hnlich nicht direkt auf hochsprachlichen
DEDS -Modellen agieren, weil notwendige Zustandsraum-Informationen dort nur implizit verfu¨g-
bar sind. Deswegen ist es notwendig, aus dem hochsprachlichen Modell ein analytisches Mo-
dell abzuleiten, das Zustandsraum-Informationen explizit macht und so als direkte Eingabe fu¨r
das zustandsraumbasierte Analyseverfahren fungiert. Hierbei spielen probabilistische Zustands-
automaten und stochastische Prozesse eine zentrale Rolle. Nachfolgend werden stochastisch-
zeitbehaftete Petri-Netze als eine hochsprachliche Notation detailliert betrachtet, weil sie im
Kontext dieser Arbeit bedeutsam sind (vgl. Abschnitt 7.2). Danach wird erla¨utert, wie aus
stochastisch-zeitbehafteten Petri-Netzen probabilistische Zustandsautomaten (Abschnitt 2.1.2)
und stochastische Prozesse (Abschnitt 2.1.3) ableitbar sind. Dies schafft den U¨bergang von DEDS
zu einer speziellen Klasse stochastischer Prozesse - der Markov-Ketten - die im nachfolgenden
Kapitel eingefu¨hrt werden.
2.1.1 Stochastische Petri-Netze
Petri-Netze (PN ) sind ein verbreiteter Formalismus zur Modellierung von DEDS [1, 2, 10, 13, 20,
36]. Wesentliche PN -Konstrukte sind Stellen (symbolisiert durch Kreise), Transitionen (Recht-
ecke) und Token (kleine Punkte). Eine Stelle repra¨sentiert eine diskrete Variable, deren Zustand
durch die Markierung (=Anzahl der Token) kodiert wird. Eine Stelle modelliert ein atomares
Teilsystem. Die Markierungen u¨ber alle Stellen repra¨sentieren Zusta¨nde des Gesamtsystems.
Ereignisse im DEDS werden durch PN -Transitionen modelliert, die Markierungen ineinander
transformieren und somit Zustandswechsel auslo¨sen. Fu¨r jede PN -Transition wird eine logische
Bedingung auf der Menge der Markierungen definiert, die angibt, wann eine PN -Transition
aktiviert ist. Vorab definierte Regeln priorisieren aktivierte PN -Transitionen und wa¨hlen eine
PN -Transition aus (Konfliktauflo¨sung), die feuert, d.h. die aktuelle Markierung in eine Nach-
folgemarkierung u¨berfu¨hrt. Die Transformation basiert auf der Addition und/oder Subtraktion
von Token auf/von spezifischen Stellen. Es ist vorteilhaft, wenn die Aktivierungsbedingung von
10
der Markierung weniger Stellen abha¨ngt und der Zustandswechsel durch Modifikation (Addi-
tion/Subtraktion) weniger Stellen beschreibbar ist, d.h. wenn im System Voraussetzungen fu¨r
und Auswirkungen von Ereignissen lokal eingrenzbar sind. Anderenfalls ist die Spezifikation des
PN s aufwendig und die Lesbarkeit der graphischen PN -Darstellung schlecht.
Urspru¨nglich wurden PN s zur funktionalen Analyse (Lebendigkeit, Zustandserreichbarkeits-
graph, Invarianten etc) verteilter Systeme eingesetzt. Erweiterungen der urspru¨nglichen PN -
Notation fu¨hren zur vereinfachten Spezifikation von Zustandswechseln im DEDS (Gewichts-
funktion fu¨r Transitionen, Inhibitor-Kanten) und ertu¨chtigen quantitative Leistungsanalysen
durch eine zeitliche Bewertung von PN -Transitionen. Die zeitliche Bewertung durch stochasti-
sche Verteilungen fu¨hrt zu stochastischen PN s, die mit den zuvor erwa¨hnten Erweiterungen zur
Klasse generalisierter, stochastischer PN s [1] fu¨hren, vgl. Def. 2.1.
Definition 2.1 Ein generalisiertes stochastisches Petri-Netz (GSPN) [1] wird formal
durch ein 8-Tupel (P, T, ψ, I,O,H,W,M0) beschrieben. P ist die Menge der Stellen, T ist die
Menge der Transitionen, ψ : T → {0, 1} ist eine Priorita¨tsfunktion, I,O : T → N|P |×|T | sind
Eingabe- und Ausgabefunktion der Transitionen, W : T → R>0 ist eine Gewichtsfunktion fu¨r
Transitionen und M0 : P → N ist eine Funktion zur Festlegung der initialen Markierung der
Stellen. Daraus ableitbar ist TT = {t ∈ T | ψ(t) = 0}, die Menge zeitbehafteter Transitionen.
W (t) erfasst fu¨r t ∈ TT den/die Parameter der stochastischen Verteilung, welche die Lebenszeit
der Transition t (Zeit zwischen Aktivierung und feuern) spezifizieren. W (t) ist zum Beispiel die
Rate einer Exponentialverteilung. Fu¨r zeitlose Transitionen t (ψ(t) = 1) ist W (t) ein relatives
Gewicht. Zeitlose Transitionen haben stets Priorita¨t gegenu¨ber zeitbehafteten Transitionen.
Die GSPN -Erreichbarkeitsmenge RS ist definiert als die kleinste Menge von Markierungen, fu¨r
die M0 ∈ RS gilt und die abgeschlossen ist bezu¨glich aller Transitionen aus T . Es sei T RS
die Menge aller Markierungen, in denen nur zeitbehaftete Transitionen aktiviert sind (tangible
reachable set).
Mehrere GSPN s ko¨nnen konstruktiv zu einem “superposed GSPN ” (SGSPN ) [46, 70] ver-
knu¨pft werden, vgl. Def. 2.2. Die einzelnen GSPN s, nachfolgend als Komponenten des SGSPN
bezeichnet, repra¨sentieren Teilsysteme. Die Strukturinformation kann zur Effizienzsteigerung in
zustandsraumbasierten Analyseverfahren benutzt werden, vgl. Abschnitt 3.2.
Definition 2.2 Ein zusammengesetztes (superposed) GSPN (SGSPN) [46] wird formal
durch ein 9-Tupel (P, T, ψ, I,O,H,W,M0 , φ) beschrieben, wobei (P, T, ψ, I,O,H,W,M0) ein GSPN
ist, vgl. Def. 2.1. φ = {P 1, . . . P J} definiert eine Partition von P mit J Komponenten
(P j , T j, ψj , Ij , Oj ,Hj,W j ,M j0 ), wobei T j = •P j ∪ P j• ist (alle Transitionen die im Vor- oder
Nachbereich mit Stellen aus P j verbunden sind) und ψj , Ij , Oj ,Hj ,W j ,M j0 sind die Restriktio-
nen von ψ, I,O,H,W,M0 auf P j bzw. T j. Die Partition φ klassifiziert die Transitionen wie folgt:
TLj = {t ∈ T j | •t ∪ t• ⊆ P j} ist die Menge lokaler Transitionen, TS = T\(∪Jj=1TLj) ist
die komplementa¨re Menge synchronisierender Transitionen und TT j = {t ∈ T j | ψ(t) = 0}
ist die Menge zeitbehafteter Transitionen, die im Vor- und Nachbereich mit Stellen aus P j
verbunden sind.
Nachfolgend wird ein vielzitiertes PN -Modell aus dem Bereich der Warteschlangensysteme vor-
gestellt, das Analogien zur Stu¨ckgutumschlaghalle - einem logistischen System - besitzt, vgl.
Abschnitt 8.2.1
11
Beispiel 2.3 (Multi-Server Multi-Queue (MSMQ) Anwendung [2]) .
Ein Multi-Server Multi-Queue (MSMQ) Bediensystem besteht aus J > 1 Warteschlangen-Stationen,
die von S Bedienern zirkulierend besucht werden, vgl. Abbildung 2.1 links. Jede Station j (1 ≤
j ≤ J) hat einen Puffer mit endlicher Kapazita¨t Cj. Die Last (Kunden etc) wird durch stations-
spezifische Poisson-Prozesse mit Rate λj generiert. Bei einem Puffer-U¨berlauf gehen Kunden
verloren. Die Kunden haben eine exponentielle Bedienwunschverteilung mit der mittleren Bedi-
enzeit µ−1j . Der U¨bergang eines Bedieners von der Station j zur Station (j mod J) + 1 dauert
im Mittel ω−1j Zeiteinheiten. Wenn bei Ankunft oder nach Beendigung der Bedienung die War-
teschlange leer ist, geht der Bediener zur na¨chsten Warteschlange. Wenn nach der Bedienung
die Warteschlange nicht leer ist, geht der Bediener entweder zur na¨chsten Station oder er bleibt
in der aktuellen Station (Modellvarianten). An einer Station ko¨nnen mehrere Bedienvorga¨nge
simultan stattfinden, sofern S > 1 ist. Die Abbildung 2.1 rechts zeigt das GSPN-Modell einer
einzelnen Station. Das SGSPN-Modell fu¨r die gesamte MSMQ Anwendung besteht aus J GSPN-
Modellen (=Komponenten) einzelner Stationen, die u¨ber zeitbehaftete Transitionen t Sw j und
t Sw j+1 kommunizieren. Die zeitbehafteten Transitionen t Buf und t Proc beschreiben die An-
kunft und die Bearbeitung von Kunden, die Transitionen t Sw j und t Sw j+1 beschreiben die
Ankunft und den Weggang eines Bedieners an Station j. Die Zuordnung eines verfu¨fgbaren Be-
dieners (Token in Stelle p 4) zum wartenden Kunden (Token in Stelle p 2) wird u¨ber die zeitlose
Transition t 4 modelliert.
KUNDEN
BEDIENER
t_Buf
0/0
p_2 t_4
t_4
0/0
p_4
1/1
p_1
t_Proc
0/0
p_5
0/0
p_3
t_Sw_j t_Sw_j+1
Abbildung 2.1: Links: MSMQ Bedienstation mit J = 5 Warteschlangen und S = 3 Bedienern;
Rechts: GSPN -Modell einer einzelnen Bedienstation (Komponente j) mit polling-Bedienung
2.1.2 Probabilistische Automaten
Probabilistisch-zeitbehaftete Automaten sind aus GSPN s bzw. SGSPN s ableitbar. Zuvor sollen
probabilistisch-zeitbehaftete Automaten definiert und in ihrer Wirkungsweise erla¨utert werden.
Definition 2.4 (Probabilistisch-zeitbehafter Automat [36]) .
Ein stochastisch-zeitbehafteter Automat ist ein 6-Tupel der Form
(E ,S,Γ, p, p0, G),
mit der Ereignismenge E = {1, . . . ,m} und dem Zustandsraum S. Dabei ist Γ(x) die Menge
von Ereignissen, die im Zustand x ∈ S aktiviert sind und potentiell eintreten. Wenn ein Ereignis
12
i im vorgehenden Zustand deaktiviert war und im aktuellen Zustand aktiviert wird, erha¨lt es
eine Lebenszeit yi durch die Dichtefunktion {Gi | i ∈ E} “zugewiesen” (Notation: yi ∼ Gi).
Die Transitions-Funktion p : S × E → S bestimmt (hier deterministisch) den Nachfolgezustand
basierend auf dem aktuellen Zustand und dem eingetretenen Ereignis. Die Funktion p0 bestimmt
die Startverteilung des initialen Zustands.
Die Wirkungsweise des probabilistisch-zeitbehafteten Automaten soll nachfolgend genauer erla¨u-
tert werden. Die Wirkungsweise entspricht der eines diskreten ereignis-gesteuerten Simulators [36,
74]: Ausgehend vom aktuellen Zustand x wird das na¨chste Ereignis e′ und der Nachfolgezustand
x′ bestimmt und dabei der Zeitfortschritt protokolliert.
1. Ereignis-Auswahl e′:
Jedes Ereignis i ∈ E ist abha¨ngig vom aktuellen Zustand x entweder aktiviert i ∈ Γ(x)
oder deaktiviert. Es ko¨nnen nur aktivierte Ereignisse eintreten. Als na¨chstes Ereignis wird
das mit der geringsten Lebenszeit ausgewa¨hlt, d.h.
e′ = arg min
i∈Γ(x)
yi.
Die Auswahl ist bei zeitlosen Ereignissen nicht eindeutig. In diesem Fall mu¨ssen Ereignisse
zusa¨tzlich priorisiert werden. Es ist
y∗ , min
i∈Γ(x)
yi.
die Zeitdauer zwischen dem zuletzt beobachteten Ereignis und dem na¨chsten Ereignis.
2. Nachfolgezustand-Auswahl x′: x′ = p(x, e′)
3. Lebenszeit-Aktualisierung y′i:
Wird im Zustand x′ ein Ereignis i aktiviert (vorher deaktiviert) oder ist i gerade eingetreten
(i = e′), so bekommt es “seine” Lebensdauer yi durch die Verteilung Gi “zugewiesen”.
Anderenfalls, war i bereits im Zustand x aktiviert, ist aber nicht eingetreten, so wird die
Lebenszeit um y∗ vermindert, sofern i im Zustand x′ aktiviert bleibt. D.h.
∀i ∈ Γ(x′) y′i ,
{
∼ Gi falls i = e′ oder i /∈ Γ(x)
yi − y∗ falls i 6= e′ und i ∈ Γ(x)
mit
y∗ , min
i∈Γ(x)
yi.
Aus der GSPN -Spezifikation (P, T, ψ, I,O,W,M0) ist die Automat-Spezifikation (E ,S,Γ, p, p0, G)
ableitbar.
• Ereignismenge E : E ist isomorph zur Menge der Transitionen T .
• Zustandsraum S : Im GSPN werden Zusta¨nde durch Markierungen kodiert. Die GSPN -
Erreichbarkeitsmenge RS ist im GSPN implizit spezifiziert und muss durch eine Erreich-
barkeitsanalyse ermittelt werden. Der Zustandsraum S ist isomorph zur Erreichbarkeits-
menge RS.
13
• Zustandsabha¨ngige Menge aktivierter Ereignisse Γ: Fu¨r eine Transition t ∈ T bestimmt die
Eingabe-Inzidenzmatrix I(t) ∈ N|P |×|T |, fu¨r welche Markierungen/Zusta¨nde die Transition
t aktiviert ist. Umgekehrt kann somit fu¨r jede Markierung/Zustand festgelegt werden,
welche Transitionen aktiviert sind.
• Transitionsfunktion p: Fu¨r jede Transition t ∈ T bestimmen die Eingabe- und Ausgabe-
Inzidenzmatrizen I(t) bzw. O(t) die Relation zwischen aktueller Markierung (aktueller
Zustand) und Nachfolge-Markierung. Die Transitionsfunktion p ist somit aus I und O
ableitbar.
• Initiale Zustands-Verteilung p0: Die initiale Zustands-Verteilung p0 entspricht der initialen
Markierungs-Verteilung M0.
• Verteilungen fu¨r Ereignis-Lebenszeiten G: Im GSPN werden die Verteilungen der zeitbe-
hafteten Transitionen durch die Gewichtsfunktion W spezifiziert (oft Rate der Exponen-
tialverteilung). Daraus ist G direkt ableitbar. Zeitlose Transitionen fu¨hren zu Ereignissen
mit Lebenszeit 0.
2.1.3 Stochastische Prozesse
Stochastische Prozesse sind das analytische Modell (= Eingabe) fu¨r zustandsraumbasierte DEDS -
Analysemethoden.
Definition 2.5 Ein stochastischer Prozess ist eine Familie von Zufallsvariablen
{X(t) : t ∈ T } , [X(t0), X(t1), . . .]
in der jede Zufallsvariable X : S → R mit einem Zeitparameter t ∈ T indiziert ist. Der Defini-
tionsbereich S von X ist der Zustandsraum des stochastischen Prozesses. Ein zeit-diskreter
stochastischer Prozess (= stochastische Folge) liegt vor, wenn T ein diskrete Teilmenge von N
ist. Fu¨r T = R+ ist der Prozess zeit-kontinuierlich. Eine stochastische Kette liegt vor,
wenn der Zustandsraum S diskret ist.
Transitionen im GSPN bzw. Ereignisse im probabilistischen Automaten lo¨sen ausgehend vom
Startzustand eine stochastische Zustandsfolge (=Trajektorie) aus. Wenn zeitlose Transitionen
bzw. Ereignisse eliminierbar sind, ist die Realisierung des GSPN bzw. des Automaten ein stocha-
stischer Prozess, genauer ein Generalisierter Semi-Markov-Prozess [36]. “Semi-Markov” bezieht
sich auf die Eigenschaft, dass in die Berechnung der Dichtefunktion von Xtk+1 nur der Zustand
xk und nicht fru¨here Zusta¨nde xk−1, . . . , x0 zu beru¨cksichtigen sind. “Generalisiert” bezieht sich
auf die Eigenschaft, dass die Zeitdifferenz zwischen Ereignissen, also t1 − t0, t2 − t1, . . . durch
eine beliebige Verteilung (implizit) spezifiziert ist.
2.2 DEDS Analyse
Das verbreiteste DEDS Analyseverfahren ist die Diskrete Ereignis-gesteuerte Simulati-
on [74], weil DEDS Modelle ohne Restriktionen einer Simulation zuga¨nglich sind. Der Nachteil
14
der Simulation liegt in der langen Ausfu¨hrungszeit fu¨r Modelle, bei denen quantitative Kennzah-
len mit statistisch abscha¨tzbarer hoher Genauigkeit erforderlich sind. Erschwert wird die simu-
lative Analyse, wenn Ereignisse, die zur gesuchten Kennzahl beitragen, nur niederfrequent auf-
treten (Zeitskalen-Differenzen), weil dann die Aussagekraft der statistischen Ergebnis-Scha¨tzer
sinkt.
Demgegenu¨ber erlauben analytisch-algebraische Verfahren [20] eine sehr zeiteffiziente Ana-
lyse von DEDS -Modellen und sind deswegen sehr gut fu¨r Experiment-Reihen parametrisierter
Modelle (“what-if” Szenarien) geeignet, wie sie zum Beispiel bei Optimierungsaufgaben auf-
treten. Allerdings sind DEDS -Modelle - um analytisch-algebraisch exakt lo¨sbar zu sein - zahl-
reichen Restriktionen unterworfen. Approximative Verfahren, die entweder ein approximatives
DEDS -Modell analytisch-algebraisch exakt oder das origina¨re DEDS -Modell unter Verwendung
approximativer Teillo¨sungen lo¨sen, sind u¨bliche Lo¨sungsansa¨tze.
Analytisch-numerische, Zustandsraum-basierte Verfahren [20, 36, 49] beschra¨nken die
Restriktionen im DEDS -Modell auf das zeitliche Zustandsu¨bergangsverhalten (Markov, Geda¨cht-
nislosigkeit) und erlauben die Abbildung von Synchronisationsmechanismen. Die Anwendbarkeit
numerischer Lo¨sungsverfahren ist hauptsa¨chlich durch die Gro¨ße des Zustandsraums limitiert.
Deswegen zielen die Weiterentwicklungen der Verfahren auf die Behandelbarkeit großer Zu-
standsra¨ume. Im Abschnitt 3.3 werden bekannte Ansa¨tze vorgestellt. Der Nachteil der Verfahren
liegt - trotz sehr leistungsfa¨higer Rechen- und Platzkapazita¨ten sind - in langen Lo¨sungszeiten.
Simulative, analytisch-algebraische und analytisch-numerische Verfahren ko¨nnen sinnvoll mit-
einander kombiniert werden, um ihre jeweiligen Vorzu¨ge zu nutzen. Eine Mo¨glichkeit ist die
Voranalyse dedizierter Teilmodelle mit numerischen Verfahren fu¨r die Spezifikation vereinfachter
Ersatzmodelle (Aggregate) und einer anschließenden Analyse des Gesamtsystems (inkl. Aggre-
gat) mit algebraischen Verfahren oder Simulation. Eine andere Mo¨glichkeit ist die Kopplung von
analytisch-numerischen Verfahren und Simulation im Bereich der Performability-Modellierung [67].
Beide Ansa¨tze werden im Kontext der Modellierung und Analyse logistischer Systeme in den
Abschnitten 8.2.2 und 8.2.3 demonstriert.
15
Kapitel 3
Markov-Ketten
Sofern die DEDS -Modellbildung kein Selbstzweck ist und nicht nur dem Explizieren bekannter
Systemeigenschaften, sondern der Ermittlung der im Modell implizit erfassten Performance-
Eigenschaften dient, unterliegt die DEDS -Modellbildung dem Zielkonflikt zwischen guter ana-
lytischer Behandelbarkeit und Beschreibungsma¨chtigkeit der Modellierungsnotation. Ein Kom-
promiss (neben anderen) ist, bestimmte - sogenannte Markovsche - Annahmen bezu¨glich des
zeitlichen Verhaltens im DEDS zu treffen, die dazu fu¨hren, dass das analytische Modell eine
Markov-Kette ist. Durch die sogenannte Geda¨chtnislosigkeit, einer essentiellen Eigenschaft der
Markov-Kette, wird die analytische Behandelbarkeit des Modells erheblich erleichtert.
Markov-Ketten sind eine Klasse stochastischer Prozesse, die im Bereich der Modellierung und
quantitativen Analyse technischer Systeme weit verbreitet sind [3, 20, 36, 49, 50, 91]. Spezielle
Auspra¨gungen von Markov-Ketten sind (geschlossen) analytisch-algebraisch lo¨sbar, anderenfalls
ist eine analytisch-numerische Lo¨sung mo¨glich.
Der Abschnitt 3.1 fu¨hrt kurz in die Theorie der Markov-Ketten-Modellierung und der stationa¨ren
Analyse ein. Detaillierter wird darauf eingegangen, wie aus probabilistisch-zeitbehafteten Auto-
maten (zeitkontinuierliche) Markov-Ketten ableitbar sind. Markov-Ketten werden durch soge-
nannte Generatormatrizen spezifiziert. Fu¨r Generatormatrizen ist unter bestimmten Umsta¨nden
eine Hierarchie und kompositionelle Darstellung generierbar, vgl. Abschnitt 3.2, von der Ana-
lyseverfahren profitieren ko¨nnen. Fu¨r die stationa¨re Analyse von Markov-Ketten ist ein großes
Portfolio numerischer Verfahren bekannt und erprobt, vgl. Abschnitt 3.3. Im Abschnitt 3.4 wird
die Markov-Ketten Modellbildung fu¨r zwei Systeme exemplifiziert.
16
3.1 Grundlagen
Stochastische Ketten (vgl. Def. 2.5) ko¨nnen hinsichtlich statistischer Eigenschaften involvierter
Zufallsvariablen klassifiziert werden. Im Zielkonflikt zwischen analytischer Handhabbarkeit und
Ausdrucksma¨chtigkeit involvierter Zufallsvariablen stellen Markov-Ketten einen guten Kom-
promiss dar. Zum Vergleich: In unabha¨ngigen stochastischen Ketten sind alle Zufallsvariablen
X(t0), X(t1), . . . unabha¨ngig. Diese Annahme ist sehr restriktiv bzgl. des beschreibbaren System-
verhaltens, resultiert aber in einer einfachen Analyse unabha¨ngiger Zufallsvariablen. Das andere
Extrem tritt ein, wenn alle Zufallsvariablen X(t0), X(t1), . . . voneinander abha¨ngen, hier kann
die Berechnung einer gemeinsamen Verteilungsfunktion u¨ber alle Zufallsvariablen extrem kom-
pliziert sein. Demgegenu¨ber ha¨ngt in Markov-Ketten die Vorhersage des Nachfolgezustands nur
vom aktuellen Zustand ab. Konzeptionell “erfaßt” der aktuelle Zustand alle relevanten Aspekte
der gesamten Historie. Deswegen ist die Berechnung der Verteilungsfunktion involvierter Zu-
fallsvariablen gut behandelbar (s.u.). Die Def. 3.1 beinhaltet eine formale Definition fu¨r zeitkon-
tinuierliche Markov-Ketten.
Definition 3.1 (Zeitkontinuierliche Markov-Ketten) .
Eine zeitkontinuierliche stochastische Kette X(t) ist eine zeitkontinuierliche Markov-Kette,
wenn fu¨r die zu beliebigen Zeitpunkten t0 ≤ t1 ≤ . . . ≤ tk+1 beobachteten Zusta¨nde x0, x1, . . . , xk−1
P [X(tk+1) = xk+1 | X(tk) = xk, X(tk−1) = xk−1, . . . , X(t0) = x0] =
P [X(tk+1) = xk+1 | X(tk) = xk]
gilt, d.h. die stochastische Prognose des Zustands zum Zeitpunkt tk+1 ist
P1: unabha¨ngig von der historischen Zustandsfolge x1, . . . , xk−1,
P2: unabha¨ngig von der Verweildauer im aktuellen Zustand xk.
Die Eigenschaften P1 und P2 dru¨cken die Markov-Ketten Geda¨chtnislosigkeit aus.
Im Abschnitt 2.1.1 und 2.1.2 wurden generalisierte stochastische Petri-Netze (GSPN ) und proba-
bilistische Automaten als Notationen zur DEDS -Modellbildung eingefu¨hrt. Wenn zeitlose Transi-
tionen (in GSPN ) bzw. zeitlose Aktivita¨ten (in Automat) eliminierbar sind, ist die unterliegende
stochastische Kette eine Generalisierte Semi-Markov Kette [36]. Wenn zusa¨tzlich gilt, dass die
Verteilung der Lebenszeit der GSPN -Transitionen (in GSPN ) bzw. die Verteilung der Lebens-
zeit der Ereignisse (in Automat) durch Exponentialverteilungen bestimmt ist, dann ist die einem
GSPN bzw. Automaten unterliegende stochastische Kette eine Markov-Kette. Dieses Resultat
ist wohlbekannt und resultiert aus der sogenannten Geda¨chtnislosigkeit der Exponentialvertei-
lung. Die Geda¨chtnislosigkeit bewirkt, dass die Lebenszeit-Verteilung V eines Ereignisses mit
Rate λ nach einem beliebigen Alter z (Ereignis ist nach z Zeiteinheiten trotz Aktivierung noch
nicht eingetreten, d.h. V > z) stets mit der Verteilung der Lebenszeit zu Beginn der Aktivie-
rung u¨bereinstimmt, d.h. P [V − z ≤ t|y > z] = 1 − exp(−λi t). Deswegen kann man bei der
Ereignis-Lebenszeit Bestimmung zu jedem beliebigen Zeitpunkt auf die Exponentialverteilungen
zuru¨ckgreifen. Ein Mitfu¨hren des Alters aktivierter Ereignisse, was eine analytische Handhabbar-
keit verschlechtert [75], ist nicht notwendig. Deswegen kann die Ereignis-Verteilung und damit
auch die Verteilung des Nachfolgezustands leicht bestimmt werden. Fu¨r die zustandsabha¨ngige
Ereignis-Verteilung E gilt [36]:
P [E = i |X(tk) = xk] =
λi
Λ(xk)
mit Λ(xk) ,
∑
i∈Γ(xk)
λi (3.1)
17
und
P [X(tk+1) = xk+1] =
∑
i∈Γ(xk)
p(xk,i)=xk+1
λi
Λ(xk)
. (3.2)
Die Gl. 3.2 zeigt, dass die Prognose des Nachfolgezustands lediglich vom aktuellen Zustand xk
abha¨ngt. Alle anderen Werte in Gl. 3.2 sind entweder aus xk ableitbar (Menge aktivierter Er-
eignisse Γ(xk), Gesamtrate aktivierter Ereignisse Λ(xk)) und/oder sind expliziter Bestandteil
der Automaten/GSPN -Spezifikation. Des Weiteren verdeutlicht Gl. 3.2, dass die Prognose un-
abha¨ngig von der Verweildauer im aktuellen Zustand xk+1 und damit auch vom Alter aktivierter
Ereignisse ist. Daher sind die Bedingungen P1 und P2 in der Def. 3.1 der Markov-Ketten erfu¨llt.
Die Restriktion der Zeitverbra¨uche auf Exponentialverteilungen vereinfacht nicht nur die analy-
tische Handhabbarkeit, sondern vereinfacht im Vergleich zu Automaten auch die Spezifikation
zeitkontinuierlicher Markov-Ketten.
Definition 3.2 (Homogene, Zeitkontinuierliche Markov-Ketten) .
Eine homogene, zeitkontinuierliche Markov-Kette ist ein 3-Tupel
(S,Q, p0)
mit diskretem Zustandsraum S, Generatormatrix Q ∈ Rn×n (n ist Kardinalita¨t von S) und
initialer Zustandsverteilung p0.
Im Vergleich zum probabilistischen Automaten sind Ereignisse, ihre Lebenszeiten und Ihre Akti-
vierungsbedingung in Def. 3.2 nicht angegeben. Diese Bestandteile der Automaten-Spezifikation
sind in den Eintra¨gen der Generatormatrix Q verdichtet. In der Beschreibung des Zustandsu¨ber-
gangsverhalten einer Markov-Kette wird von auslo¨senden Ereignissen abstrahiert (Informati-
onsverlust). Die Eintra¨ge der Generatormatrix Q ko¨nnen wie folgt definiert bzw. interpretiert
werden:
Definition 3.3 (Generatormatrix Q) .
Die Eintra¨ge der Generatormatrix
Q =



q11 . . . q1n
... . . . ...
qn1 . . . qnn


 ∈ Rn×n
sind durch das Chapman-Kolmogorov-Differentialgleichungssystem
dP(t)
d t = P(t) ·Q mit Transitionsmatrix P(t) =



p11(t) . . . p1n(t)
... . . . ...
pn1(t) . . . pnn(t)


 (3.3)
charakterisiert [20, 36, 91]. Die Eintra¨ge der Transitionsmatrix sind pij(t) , P [X(s + t) =
j|X(s) = i] (∀s ∈ R>0). Dabei ist pij(t) die Wahrscheinlichkeit, dass innerhalb von t Zeitein-
heiten (unabha¨ngig vom absoluten Zeitpunkt s, weil homogen) ein Zustandsu¨bergang von i nach
j stattfindet. Die Randbedingung fu¨r P(t) in t = 0 ist:
pij(0) ,
{
1 j = i
0 j 6= i (keine Transition in Nullzeit).
(3.4)
18
Die skalare Form der Chapman-Kolmogorov-Systems in Gl. 3.3 und die Bedingung 3.4 ergeben
qij =
·pij(0), d.h. der Eintrag qij ist die Rate fu¨r t = 0, mit der ein Zustandsu¨bergang von i
nach j stattfindet bzw. fu¨r i = j die Kette im Zustand i verharrt. Eine andere Interpretation
basiert auf involvierten Ereignissen. Man kann zeigen [36], dass qij (i 6= j) die Summe aller
Raten von Ereignissen ist, die einen Zustandswechsel von i nach j bewirken. qii ist die negative
Summe aller Raten von Ereignissen, die einen Zustandswechsel von i in einen beliebigen anderen
Zustand 6= i bewirken.
Die transiente Analyse von Markov-Ketten fokussiert auf die Berechnung der Wahrschein-
lichkeitsverteilung pi(t) = (pi1(t), . . . , pin(t)) mit pii(t) , P [X(t) = i] der Zusta¨nde 1, . . . , n zum
Zeitpunkt t. Unter Ausnutzung der Transitionsmatrix P(t) kann pi(t) wie folgt berechnet werden
[20, 36, 91]:
pi(t) = pi(0) ·P(t) mit pi(0) = p0.
Die Chapman-Kolmogorov Gl. 3.3 liefert eine geschlossene Darstellung von P(t) gema¨ß P(t) =
exp(Q · t), so dass pi(t) geschlossen darstellbar durch:
pi(t) = pi(0) · exp(Q · t). (3.5)
Allerdings liegt gewo¨hnlich keine explizite Darstellung des Ausdrucks exp(Q · t) in Gl. 3.5 vor.
Die Ableitung von Gl. 3.5 nach t ergibt
dpi(t)
d t = pi(t) ·Q. (3.6)
Die stationa¨re Analyse von Markov-Ketten untersucht das Langzeit-Systemverhalten. Viele
Systeme verhalten sich nach einer hinreichend langen Betriebszeit stationa¨r, d.h. die Wahrschein-
lichkeit fu¨r das Auftreten bestimmter Zusta¨nde ist invariant und unabha¨ngig vom Startzustand.
Die stationa¨re Analyse untersucht den Grenzwertprozess
lim
t→∞
pi(t).
Sofern ein Grenzvektor pi existiert, gilt, dass fu¨r t→∞ die Ableitung dpi(t)/d t gegen 0 konver-
giert, so dass sich Gl. 3.6 im Grenzwertprozess t→∞ zu pi·Q = 0 reduziert. Bedingungen fu¨r die
Existenz und Konsistenz (∑i=1...n pii = 1) des Grenzvektors pi und der Berechnungsansatz sind
in der Prop. 3.4 zusammengefasst. Die Bedingungen fu¨r Existenz und Konsistenz sind anhand
von Klassifikationen der Zusta¨nde der Markov-Kette formulierbar. Dies betrifft insbesondere die
Konzepte der Irreduzibilita¨t, positiver Rekurrenz, Aperiodizita¨t (nur zeitdiskrete Markov-Kette)
und Ergodizita¨t (= positive Rekurrenz und Aperiodizita¨t), vgl. Lehrbu¨cher [20, 36, 91].
Proposition 3.4 (Stationa¨re Verteilung: Existenz, Konsistenz und Berechnung) .
Fu¨r eine irreduzible, zeitkontinuierliche Markov-Kette bestehend aus positiv-rekurrenten Zu-
sta¨nden existiert eine eindeutige und konsistente stationa¨re Wahrscheinlichkeitsverteilung der
Zusta¨nde pi mit pii > 0 und limt→∞ pi(t) = pi, die unabha¨ngig vom Initialvektor pi(0) ist.
Die stationa¨re Wahrscheinlichkeitsverteilung pi ist die Lo¨sung des homogenen, linearen Glei-
chungssystems
x ·Q = 0 (3.7)
erga¨nzt durch die Nebenbedingung ‖x‖1 = 1.
19
Die stationa¨re Analyse einer zeitkontinuierlichen Markov-Kette erfordert also die Lo¨sung ei-
nes wohldefinierten linearen Gleichungssystems. Damit ist die quantitative, stationa¨re und auf
Markov-Ketten basierende Systemanalyse auf ein grundlegendes mathematisches Berechnungs-
problem zuru¨ckgefu¨hrt.
Im Bsp. 3.5 wird das Markov-Ketten-Modell einer Bedienstation mit endlichem Puffer fu¨r an-
kommende Kunden vorgestellt.
Beispiel 3.5 (Markov-Kette einer Bedienstation mit endlichem Puffer) .
Das Ankunftsverhalten der Kunden sei durch einen Poisson-Ankunfsprozess mit der Rate λ >
0 erfasst, die Bedienstation habe einen Puffer mit Kapazita¨t 3 (daru¨ber hinaus ankommende
Kunden werden abgewiesen) und die Bedienzeit der Kunden sei durch eine Exponentialverteilung
mit der Rate µ > 0 approximierbar. Dann hat die Generatormatrix der zeitkontinuierlichen
Markov-Kette folgendes Aussehen:
Q =




−λ λ 0 0
µ −(λ+ µ) λ 0
0 µ −(λ+ µ) λ
0 0 µ −µ




(3.8)
Die spezielle Struktur der Generatormatrix beschreibt einen homogenen, endlichen Geburts- und
Todesprozess. Der Lo¨sungsraum L des linearen Gleichungssystems x · Q = 0 ist in diesem
speziellen Fall geschlossen darstellbar durch
L =
{
r
(
1, λµ,
λ2
µ2 ,
λ3
µ3
)
| mit λ, µ > 0 und r ∈ R
}
.
Der normierte Vektor aus L mit
r =



1−λµ
1−( λµ )4
λ
µ 6= 1
0.25 sonst
ist die stationa¨re Verteilung.
3.2 Hierarchiebildung und Komposition
Die Generatormatrix Q einer Markov-Kette kann durch eine Blockstruktur erga¨nzt werden. Das
unstrukturierte Gleichungssystem in Gl. 3.7 nimmt dann die Form
(pi[1], . . .pi[N ])



Q[1, 1] . . . Q[1, N ]
... . . . ...
Q[N, 1] . . . Q[N,N ]


 = 0 und
N∑
x=1
‖pi[x]‖1 = 1 (3.9)
mit Blockgro¨ßen n(X) , dimQ[X,X] an. Eckige Klammern (“[ ]”) in Gl. 3.9 verweisen auf
bestimmte Teile eines Vektors bzw. auf Blo¨cke innerhalb der Matrix. In einem Block zusammen-
gefasste Zusta¨nde sind per Definition ein Makrozustand, im Beispiel der Gl. 3.9 gibt es N solcher
Makrozusta¨nde. Dadurch entsteht eine zweistufige Hierarchie, die zwischen Intra-Makrozustand
20
Transitionen (Blo¨cke auf Hauptdiagonalen) und Inter-Makrozustand Transitionen (Blo¨cke neben
der Hauptdiagonalen) unterscheidet.
Die Strukturierung der Generatormatrix zielt auf Effizienzsteigerungen im numerischen Lo¨sungs-
verfahren ab. In dieser Arbeit werden die Zeilen und Spalten der Matrix derart permutiert und
in Blo¨cke gruppiert, dass eine platzeffiziente Datenstruktur zur Speicherung der Q-Matrix an-
wendbar ist und verteilte/parallele Rechen- und Platzressourcen erschlossen werden. Der zweite
Aspekt wird im Abschnitt 5.5 betrachtet. Nachfolgend wird auf die Anwendung platzeffizienter
Datenstrukturen fokussiert. Bei der nachfolgenden Einfu¨hrung in diese Thematik werden nur
die wichtigsten Resultate vorgestellt und mit Verweisen auf die Original-Literatur versehen. Ein
konkretes Beispiel fu¨r die Anwendung platzeffizienter Datenstrukturen wird im Abschnitt 7.3
vorgestellt.
Gewo¨hnlich werden Markov-Ketten nicht direkt modelliert, sondern aus einem ho¨hersprachli-
chen Modell abgeleitet. Die grundlegende Idee hierbei ist, die Struktur in Q unter Ausnutzung
im ho¨hersprachlichen Modell hinterlegter und/oder durch Voranalysen ermittelter Struktur-
Informationen zu erzeugen. In den Ansa¨tzen [23, 31] werden explizite und/oder implizite Struk-
tureigenschaften eines ho¨hersprachlichen Modells (hier GSPN bzw. SGSPN ) fu¨r die Hierarchi-
sierung der Markov-Kette verwertet. In [31] werden semi-automatisch hinterlegte Informationen
(Regionenkonzept), erga¨nzt durch die Ergebnisse einer Invariantenanalyse fu¨r eine Hierarchiebil-
dung, bereits auf der Ebene des Petri-Netzes benutzt, ein Zustandsraum erzeugt und die zuvor
ermittelte Hierarchie u¨bertragen. In [23] wird ausgehend von einem komponierten GSPN (=
SGSPN ) eine modulare Kronecker-Darstellung (s.u.) des Zustandsraums erzeugt und dann auf
dem erzeugten Zustandsu¨bergangsmodell eine spezifische Erreichbarkeitsanalyse durchgefu¨hrt,
die zur A¨quivalenzklassenbildung bzw. Hierarchisierung auf der Ebene des Zustandsraums be-
nutzt wird. Der Ansatz aus [31] ist weniger aufwendig, weil kein Zustandsraum exploriert werden
muss. Allerdings wird - mit Ausnahme einiger, spezieller Klassen von Petri-Netzen - eine Ge-
neratormatrix mit nicht erreichbaren Zusta¨nden erzeugt, die in der nachfolgenden numerischen
Analyse gesondert behandelt werden mu¨ssen. In dieser Arbeit wird der Ansatz aus [23] verwen-
det.
Technische Systeme sind aus organisatorischen Gru¨nden oft modular (in Teilsysteme) struk-
turiert. Ein Teilsystem kann sowohl in Interaktion mit seiner Umgebung agieren als auch un-
abha¨ngig von dieser. Datenstrukturen zur Speicherung der Generatormatrix ko¨nnen platzeffi-
zienter gestaltet werden, wenn man die Eigenschaften der modularen Struktur ausnutzt. Die
grundlegende Idee hierbei ist, das Verhalten einzelner Teilsysteme explizit zu beschreiben und
daraus eine generische Beschreibung des gesamten Systems abzuleiten. Viele DEDS -Notationen
ermo¨glichen es, Strukturinformationen u¨ber Teilsysteme zu hinterlegen und schaffen damit die
Voraussetzung fu¨r eine platzeffiziente Speicherung der Generatormatrix. Beispiele sind Stocha-
stic Automata Networks SAN s [91], SGSPN s [46] und die ProC/B [11, 59] Notation. Plateau
hat erkannt, dass die Dynamik von SAN s durch eine Generatormatrix erfassbar ist, die gene-
risch durch kleinere Matrizen (erfassen Dynamik einzelner Automaten bzw. synchronisierender
Transitionen) verknu¨pft mit den Operatoren der Kronecker-Algebra ⊕ und ⊗ darstellbar ist,
vgl. [91], Kapitel 9.
Definition 3.6 (Kronecker Operatoren ⊗ und ⊕ [66]) . Das Kronecker-Produkt von Ma-
21
trizen A ∈ RrA×cA und B ∈ RrB×cB geschrieben als A⊗B ist definiert als
A⊗B =





a1,1 ·B a2,1 ·B . . . a1,cA ·B
a2,1 ·B a2,2 ·B . . . a2,cA ·B... ... . . . ...
arA,1 ·B arA,2 ·B . . . arA,cA ·B





∈ RrA·rB×cA·cB
Die Kronecker-Summe von quadratischen Matrizen basiert auf dem Kronecker-Produkt und der
gewo¨hnlichen Summation von Matrizen. Es ist
A⊕B , A⊗ IrB + IrA ⊗B ∈ RrA·rB×rA·rB
mit Ix als Einheitsmatrix der Dimension x.
Dies fu¨hrt zu modularen Kronecker-Darstellungen der Generatormatrix, die oft sehr platz-
effizient sind. Beispielsweise wird ein SAN bestehend aus zwei unabha¨ngigen Automaten mo-
delliert durch zeitkontinuierliche Markov-Ketten mit Generatormatrix Q1 bzw. Q2 durch die
Generatormatrix Q1 ⊕Q2 erfasst. Der Umgang mit derartigen Datenstrukturen stellt in zwei-
erlei Hinsicht eine Herausforderung dar: Die kompositionelle Darstellung der Generatormatrix
beinhaltet alle potentiellen Zusta¨nde des Systems, u.U. auch Zusta¨nde, die im Ausgangssystem
bedingt durch Synchronisationen zwischen Teilsystemen nicht erreichbar sind. Des Weiteren
mu¨ssen restriktive Strukturierungsmo¨glichkeiten (Interaktion zwischen Teilsystemen), die durch
die Art der angestrebten Komposition (Kronecker) auferlegt sind, akzeptiert werden.
Buchholz hat aufgezeigt, wie Hierachiebildung in der Markov-Kette (s.o.) die Nutzung einer mo-
dularen Kronecker-Darstellung unter Vermeidung nicht-erreichbarer Zusta¨nde ermo¨glicht (Refe-
renzen siehe unten). Eine hierarchische Kronecker-Darstellung der Generatormatrix basiert
auf einer Zerlegung des Zustandsraums S in Makrozusta¨nde S[1], . . . ,S[N ] mit S = S[1] ·∪ . . . ·∪
S[N ]. Hier kann die Partition so gewa¨hlt werden, dass einzelne Blo¨cke Q[·, ·] der Generator-
matrix durch eine modulare Kronecker-Darstellung erfassbar sind. Eine derartige Zerlegung des
Zustandsraums ist nur in wenigen Fa¨llen direkt aus dem hochsprachlichen Modell ableitbar,
siehe Anmerkungen zur Hierarchisierung oben. Das algorithmische Vorgehen fu¨r SAN s ist, die
Zustandsra¨ume S1, . . . ,SJ involvierter Automaten (Strukturinformation im hochsprachlichen
Modell) gema¨ß einer A¨quivalenzrelation (basiert auf Erreichbarkeitskriterium) zu partitionie-
ren (erzeugt lokale Makrozusta¨nde), die dann partiell u¨ber Kreuzproduktbildung zu (globalen)
Makrozusta¨nden “expandieren”:
S =
⋃
X∈Z0
J
×
j=1
Sj [Xj ]. (3.10)
In Gl. 3.10 ist Z0 die Indexmenge der Makrozusta¨nde, “[ ]” referenziert Partitionen und X j
bildet den Index X eines Makrozustands auf den eines lokalen Makrozustands in Komponente
j ab. Es gilt weiterhin ∏Jj=1 |Sj[Xj ]| = dim |S[X]| , n(X). Die Methodik der hierarchischen
Kronecker-Darstellung wurde durch Buchholz und Kemper konzipiert [31, 25, 23, 70, 33] ([33]
ist U¨bersichtsarbeit), implementiert [32] und im Zusammenspiel mit Basisoperationen auf der
Datenstruktur [28] und diversen numerischen Analyserverfahren [29, 22, 24, 26, 27] getestet und
bewertet.
Plateau hat gezeigt, dass die Kronecker-Darstellung mit SAN s vertra¨glich ist, wenn die Automa-
ten u¨ber synchronisierte, zeitbehaftete Transitionen kommunizieren. “Synchron” bedeutet hier,
22
dass mindestens 2 Automaten einvernehmlich eine Zustandstransition auslo¨sen. Erweiterungen
der Strukturierungsmo¨glichkeiten betreffen zeitbehaftete, asynchrone Transitionen und zeitlose
Transitionen [47].
3.3 Numerische Verfahren zur stationa¨ren Analyse
Numerische Verfahren zur stationa¨ren Analyse von Markov-Ketten sind im Bereich der Perfor-
mance-Modellierung etabliert [91]. Die Herausforderung bei der Lo¨sung von Markov-Ketten-
Modellen ist die Gro¨ße des Zustandsraums, trotz vieler Fortschritte bei der Weiterentwick-
lung mathematischer Modelle numerischer Verfahren und deren Umsetzung in algorithmische
Modelle [49, 50]. Reale Systeme induzieren große Zustandsra¨ume. Ein damit einhergehender
hoher Rechen- und Platzaufwand limitiert die Anwendbarkeit des gesamten Markov-Ketten-
Instrumentariums. Algorithmische Modelle, die hohe Rechen- und Platzkapazita¨ten erschließen
(Rechnernetzwerke), sind deswegen sehr interessant.
Mathematische Modelle zur stationa¨ren Analyse von Markov-Ketten resultieren aus einem
breiten “Fundus” konventioneller Verfahren zur Lo¨sung linearer Gleichungssysteme, die (teil-
weise) mit problemspezifischen Anpassungen und Erweiterungen ausgestattet sind. Man unter-
scheidet grob
• direkte Verfahren: Gauss-Elimination und LU -Faktorisierung;
• Fixpunkt-Iterationen: Jacobi (JAC ), Gauss-Seidel (GS ), Jacobi mit Relaxation (JOR)
und Gauss-Seidel mit Relaxation (SOR) [18, 98];
• blockorientierte Fixpunkt-Iterationen: BJAC, BGS, BJOR und BSOR [18, 91];
• blockorientierte Fixpunkt-Iterationen mit Aggregierung- und Disaggregierungsschritten [22,
26, 44, 77, 78, 88, 90]
• sowie projektive Verfahren (CGS, GMRES, Arnoldi) [24, 88, 91].
Direkte Verfahren sind fu¨r kleine Zustandsra¨ume sehr gut anwendbar, aber sonst wegen des
implizit hohen Platzaufwands inpraktikabel. Projektive Verfahren berechnen sukzessive eine
erweiterte Basis des Lo¨sungsraums und generieren aus ihr eine Approximation der Lo¨sung.
Die Effizienz ha¨ngt von der Anzahl notwendiger Schritte ab (GMRES), weil einzelne Schritte
zeitlich teuer sind und die Anzahl der Basisvektoren schrittweise zunimmt und damit auch der
Platzaufwand steigt.
Numerische Lo¨sungsverfahren ko¨nnen eine Blockstruktur, wie sie in Gl. 3.9 angezeigt ist,
auf unterschiedliche Weise nutzen. Blockorientierte Fixpunkt-Iterationen lehnen sich direkt an
einer Blockstruktur an. Verteilt ablaufende Verfahren ko¨nnen die Blockstruktur als Problem-
zerlegung nutzen [29, 55, 45]. Hierarchische Fixpunkt-Iterationen (Abschnitt 4.3) agieren unter-
schiedlich auf Intra-Block-Ebene und Inter-Block-Ebene und betten in Schritte des iterativen
Verfahrens auf Inter-Block-Ebene iterative Verfahren zur Lo¨sung einzelner Blo¨cke ein (=Intra-
Block-Ebene). Fixpunkt-Iterationen mit Aggregierungsschritten alternieren Iterationsschritte im
Original-Lo¨sungsraum und in einem niederdimensionalen (aggregierten) Lo¨sungsraum (=Dimen-
sion durch Makro-Block-Ebene vorgegeben). Wenn die Blockstruktur eine NCD-Struktur der
Generatormatrix [42] widergibt, separieren iterative Verfahren mit Aggregierungsschritten die
23
Behandlung unterschiedlicher Kopplungsgrade in Generatormatrizen, indem in Erga¨nzung zu
starken Zusammenhangskomponenten auf Intra-Block-Ebene auch schwache Zusammenhangs-
komponenten auf Inter-Block-Ebene durch Aggregierungsschritte “behandelt” werden. Dadurch
wird die Konvergenz zur Lo¨sung beschleunigt (Heuristik).
Umsetzungen mathematischer Modelle in algorithmische Modelle zielen auf eine mo¨glichst effi-
ziente (Platz und Zeit) Ausfu¨hrbarkeit im Rechner ab. Hierfu¨r sind platzeffiziente Datenstruk-
turen und die Nutzbarmachung leistungsfa¨higer Rechen- und Platzkapazita¨ten bedeutsam. Die
hierarchische Kronecker-Darstellung der Generatormatrix (vgl. Abschnitt 3.2) hat hierzu einen
substantiellen Beitrag geleistet, weil der Engpass bei der Speicherung der Generatormatrix in
vielen Anwendungen aufgehoben wird und eine Blockstruktur (s.o.) erzeugt wird. Die hierar-
chische Kronecker-Darstellung hat ihre Eignung in Kombination mit (sequentiellen) Fixpunkt-
Iterationen [25], verteilt implementierten Fixpunkt-Iterationen [29, 55], projektiven Verfahren
[24] und iterativen Aggregierungs-, Disaggregierungsverfahren [22, 26] bewiesen.
Parallele Rechnerarchitekturen bieten hohe Rechen- und Platzkapazita¨ten. Die parallele Pro-
grammierung wird durch vorhandene Bibliotheken fu¨r Kommunikationsroutinen (PVM [40, 51],
MPI [40, 48]) erleichtert. Insbesondere projektive Verfahren [17, 71] und auf BJAC basierende
Fixpunkt-Iterationen [17, 55, 71, 83, 29] sind fu¨r verteilte Realisierungen geeignet, weil sie gut
skalierbar sind. In den zitierten Arbeiten ist die Generatormatrix als du¨nbesetzte Matrix im
Arbeitsspeicher [71, 83] oder ausgelagert auf externe Medien [17, 71], oder - wie in dieser Arbeit
realisiert - mit hierarchischer Kronecker-Darstellung im Arbeitsspeicher [29, 55] gespeichert.
In der vorliegenden Arbeit werden hierarchische und asynchrone Erweiterungen blockorientier-
ter Fixpunkt-Iterationen zur stationa¨ren Analyse von Markov-Ketten experimentell untersucht.
Insbesondere asynchrone Iterationen sind auf ihre praktische Eignung hin wenig - im Kontext
der stationa¨ren Analyse von Markov-Ketten noch gar nicht - untersucht worden. Das Grund-
geru¨st bildet eine BJAC -Iteration, die asynchron und verteilt auf parallelen Rechenressourcen
mit verteiltem Speicher ausgefu¨hrt wird. In die Schritte der BJAC -Iteration werden Intra-Block-
Iterationen eingebettet (hierarchische Iteration). Als Basis-Datenstruktur zur Speicherung der
Generatormatrix wird die bereits verfu¨gbare hierarchische Kronecker-Darstellung benutzt.
3.4 Beispiele Markov-Ketten Modellbildung
In diesem Abschnitt werden Zustandsraumgro¨ßen und Blockstrukturen zweier parametrisierter
Markov-Ketten vorgestellt, auf die nachfolgend bei der Berechnung von Lastverteilungen und
Laufzeitexperimenten mehrfach zuru¨ckgegriffen wird.
Das “Flexible Manufacturing System” (FMS) von Ciardo und Trivedi [39] wird in der Litera-
tur oft als Referenzsystem fu¨r die Bewertung von Markov-Ketten Analyseverfahren verwendet,
vgl. [17, 27]. Das FMS-Modell beschreibt eine Produktionslinie bestehend aus 3 Maschinen, an
denen typisierte Bauteile nach einem festen Schema verarbeitet werden. Die Anzahl der Bauteile
im System ist durch die Anzahl der Paletten, die fu¨r den Transport der Bauteile zwischen den
Maschinen beno¨tigt werden, beschra¨nkt. Nachfolgend sei die Anzahl der Bauteile jedes Typs
durch den Modellparameter k festgelegt. Die Tab. 3.1 zeigt die Gro¨ße des Zustandsraums n (=
Gro¨ße Generatormatrix), die Anzahl der Makrozusta¨nde N (= Anzahl Hauptdiagonalblo¨cke in
Generatormatrix) und die Anzahl NZ der Makrozustand-Transitionen (= Anzahl Nebendiago-
nalblo¨cke 6= 0 in Generatormatrix) jeweils in Abha¨ngigkeit von k.
In Stu¨ckgut-Umschlaghallen werden ankommende LKWs an mehreren Terminal abgefertigt.
24
k n N NZ
5 152 712 6 20
10 25 397 658 11 65
15 724 284 864 16 135
Tabelle 3.1: Eigenschaften der FMS Markov-Kette
Jedes Terminal hat eine individuelle Anzahl Rampen, die von den LKWs fu¨r deren Abfertigung
angefahren werden (Rampen beschra¨nken die LKW-Anzahl im Terminal). Sobald ein LKW an
einer von ihm belegten Rampe wartet, wird ein Gabelstapler angefordert. Ein Gabelstapler ist
entweder bereits am Terminal oder er fa¨hrt von einem zentralen Gabelstapler-Pool zum Terminal.
Die Anzahl der Gabelstapler k ist ein Modellparameter. Im Abschnitt 8.2.1 wird das System
und die Modellbildung eingehend erla¨utert. Im Vorgriff darauf zeigt die Tab. 3.2 kennzeichnende
Gro¨ßen zweier Modellvarianten in Abha¨ngigkeit von k. Es wird sich spa¨ter zeigen, dass das SUH1-
Modell mit k = 7 und 1 313 059 781 Zusta¨nden behandelbare Modellgro¨ßen u¨berschreitet, vgl.
Abschnitt 6.1.6. Weil das SUH1-Modell mit k = 6 deutlich kleiner (und behandelbar) ist, wird
noch ein zweites Modell SUH2 betrachtet, in dem das Verhalten der Gabelstapler leicht modifiziert
ist und die Zustandsra¨ume im Vergleich zum SUH1-Modell etwas kleiner sind. Das SUH2-Modell
hat 588 759 872 Zusta¨nde fu¨r k = 7.
SUH1 SUH2
k n N NZ n N NZ
4 30 690 750 126 434 19 106 256 126 434
5 122 189 237 252 1008 67 920 112 252 1008
6 423 807 404 462 2058 211 098 912 462 2058
7 1 313 059 781 792 3828 588 759 872 792 3828
Tabelle 3.2: Eigenschaften der SUH1- und SUH2-Markov-Kette
25
Kapitel 4
Hierarchische und asynchrone
lineare Fixpunkt-Iterationen
In diesem Kapitel werden hierarchische und asynchrone Erweiterungen konventioneller linearer
Fixpunkt-Iterationen definiert und bekannte Konvergenzresultate rekapituliert.
Große lineare Gleichungssysteme werden oft mit Fixpunkt-Iterationen numerisch gelo¨st [98].
Eine Fixpunkt-Iteration berechnet, ausgehend von einer initialen Approximation der Lo¨sung,
sukzessive Approximationen bzw. eine Folge von Iterationsvektoren. Eine neue Approximation
entsteht dadurch, dass eine lineare Abbildung auf bekannte Approximationen angewandt wird.
Fixpunkt-Iterationen unterscheiden sich im Auswahlmechanismus bekannter Approximationen
und anzuwendender Iterations-Operatoren, vgl. Abschnitt 4.1. Mathematische Modelle beschrei-
ben die Struktur der Iterations-Operatoren in einer fu¨r Konvergenzuntersuchungen zuga¨nglichen
Form.
Das Kapitel ist wie folgt strukturiert: Der Abschnitt 4.1 stellt Klassen von Fixpunkt-Iterationen
vor und fu¨hrt in die grundlegenden Konzepte der Konvergenzanalyse ein. Die nachfolgenden
Abschnitte 4.2 bis 4.4 betrachten “Stationa¨re Iterationen”, “Nicht-stationa¨re hierarchische Ite-
rationen” und “Stochastische asynchrone Iterationen”.
4.1 Einleitung
Lineare Fixpunkt-Iterationen ko¨nnen zur Lo¨sung linearer Gleichungssysteme verwendet werden.
Nachfolgend werden nur homogene Systeme der Form
x ·Q = 0
mit Koeffizientenmatrix Q betrachtet. Eine iterative Methode zur Lo¨sung des Systems ist durch
lineare Funktionen
f1(pi(0) |Q), f2(pi(0),pi(1) |Q), . . . , f t(pi(0), . . . ,pi(t− 1) |Q), . . . ∈ Rn×n
definiert, die gema¨ß dem Iterationsschema
pi(t) = f t(pi(0), . . . ,pi(t− 1) |Q) (4.1)
26
ausgehend von einer initialen Approximation pi(0) sukzessive Approximationen pi(1),pi(2), . . .
fu¨r die Lo¨sungsmenge L(Q) des Systems x · Q = 0 generieren. Die Iteration in Gl. 4.1 heißt
stationa¨r, wenn f t unabha¨ngig von t ist, anderenfalls nicht-stationa¨r. Im stationa¨ren Fall ist
pi(t) = f(pi(0), . . . ,pi(t−1) |Q). Die Iteration in Gl. 4.1 ist vom Grad B, wenn in die Berechnung
von pi(t) maximal die letzten B Approximationen einfließen, d.h. fu¨r alle t−B > 0 gilt:
pi(t) = f t(pi(t−B), . . . ,pi(t− 1) |Q). (4.2)
Im Fall nicht-stationa¨rer Iterationen ist gewo¨hnlich ein Pool linearer Abbildungen F =
{f1, . . . fM} a priori bestimmbar, aus dem die in der Iteration angewandten linearen Funktionen
“entnommen” werden. Die Funktion j : N→ [1, . . . ,M ] “modelliert” die Auswahl, so dass Gl. 4.1
in
pi(t) = fj(t)(pi(0), . . . ,pi(t− 1) |Q). (4.3)
u¨bergeht. Die Gl. 4.3 beschreibt eine deterministische, nicht-stationa¨re Iteration, wenn
j eine gewo¨hnliche nicht konstante deterministische Funktion ist. Die Gl. 4.3 beschreibt eine
stochastische nicht-stationa¨re Iteration, wenn j eine Zufallsvariable ist.
Die funktionale Sicht auf die Iteration in den Gleichungen 4.1 bis 4.3 erlaubt, Iterationen hin-
sichtlich der Auswahl bekannter Approximationen und der Auswahl des Iterations-Operators
f∗ zu klassifizieren. In Jacobi-Iterationen fließt nur die aktuelle Approximation ein, in Gauss-
Seidel-Iterationen fließen bereits aktualisierte Teile und (noch) unvera¨nderte Teile der aktuellen
Approximation gemischt ein und in Semi-iterativen Verfahren werden historische Approximatio-
nen gezielt zur Verbesserung der Konvergenzgeschwindigkeit gemischt [98]. Asynchrone Iteratio-
nen (Abschnitt 4.4) mischen a¨hnlich wie Semi-iterative Verfahren bekannte Approximationen,
allerdings in einer unkontrollierten, stochastischen Weise. Des Weiteren werden in asynchronen
Iterationen die Komponenten des Iterationsvektors asynchron aktualisiert.
Die funktionale Sicht der Iteration in den Gleichungen 4.1 bis 4.3 hebt die grundlegende Struk-
tur der Iteration hervor, abstrahiert aber von konkreten Auspra¨gungen der f t-Funktionen, die
Gegenstand der Konvergenzanalyse sind. Aus der linearen Algebra ist bekannt, dass die Menge
mo¨glicher Auspra¨gungen isomorph zur Menge der Matrizen = Rn×n ist. Der Iterations-Operator
kann explizit durch einen algebraischen Ausdruck angegeben werden, der das “mathematische
Modell” fu¨r die Konvergenzanalyse darstellt. Mathematische Modelle resultieren aus einem
Splitting der Koeffizientenmatrix Q = M−N mit nicht-singula¨rer Matrix M, das das System
x ·Q = 0 mit algebraischen Umformungen in eine Fixpunktgleichung x = x ·N ·M−1 u¨berfu¨hrt.
Aus der Fixpunktgleichung ist die Iterationsvorschrift
pi(t+ 1) = pi(t) ·N ·M−1
︸ ︷︷ ︸
T
= pi(t)− pi(t) ·Q
︸ ︷︷ ︸
r(t)
·M−1
mit Iterationsvektor pi(t), Iterations-Operator T , NM−1, und Residualvektor r(t)
direkt ablesbar.
Nachfolgend werden Begrifflichkeiten der Konvergenzanalyse definiert, die in den anschließenden
Abschnitten bedeutsam sind.
Definition 4.1 (Grundlegende Definitionen zur Konvergenzanalyse) .
27
a) Es sei σ(T) , {λ1, . . . , λn} das Spektrum der Eigenwerte von T ∈ Rn×n mit o.B.d.A
|λ1| ≥ |λ2| ≥ . . . ≥ |λn| und zugeho¨rigen Eigenvektoren v1, . . . ,vn (vi · T = λi · vi
fu¨r i = 1, . . . , n), ρ(T) = max{|λ| |λ ∈ σ(T)} ist der Spektralradius von T, d.h. der
betragma¨ßig gro¨ßte Eigenwert von T. Des Weiteren sei γ(T) = max {|λ| |λ ∈ σ(T), |λ| 6=
1} die Magnitude von T. d.h. der betragma¨ßig gro¨ßte Eigenwert von T ungleich 1.
b) Eine Matrix T heißt konvergent bzw. 0-konvergent, wenn der Grenzwert limt→∞ Tt
existiert bzw. gleich 0 ist. Resultiert T aus einem Matrix-Splitting, dann spricht man von
einem konvergenten bzw. 0-konvergenten Splitting.
c) Eine Matrix A heißt M-Matrix, wenn sie in der Form A = sI − P mit s ≥ ρ(P) > 0
und P ≥ 0 ausgedru¨ckt werden kann.
d) Eine M-Matrix A mit A = sI − P hat die Eigenschaft C, wenn s−1P konvergent ist
(weitere Charakterisierungen in [18, 85] 1 ).
e) Ein Splitting Q = M − N heißt [schwach] regula¨r, wenn M−1 ≥ 0 und N ≥ 0
[NM−1 ≥ 0] gilt.
Die Konvergenzrate ist ein Maß fu¨r die Geschwindigkeit, mit der sich der Abstand der Ap-
proximationen pi(t) von der exakten Lo¨sung pi verringert. Der Abstand als Vektor wird mit
Vektornormen ‖ · ‖ : Rn → R skalar quantifiziert. Fu¨r x ∈ Rn und einen positiven Vektor
pi ∈ Rn > 0 (elementweise) ist die Summen-Norm ‖x‖1, die Maximum-Norm ‖x‖∞ und die
projektive Parallelepiped-Norm ‖x‖pi definiert durch
‖x‖1 ,
n∑
i=1
|xi| (4.4)
‖x‖∞ , maxi=1...n |xi| (4.5)
‖x‖pi , maxi=1...n
|xi|
pii
= min {δ > 0 | − δpi ≤ x ≤ δpi}. (4.6)
Eine Distanzfunktion d : Rn × Rn → R bewertet den Abstand zwischen Vektoren basierend
auf Vektornormen, z.B. mit der Maximum-Norm oder der projektiven Parallelepiped-Norm
d(x,pi) ,



‖x− pi‖∞ = maxi=1...n|xi − pii|
‖x‖pi = maxi=1...n
|xi|
pii
.
(4.7)
Die Distanzfunktion kann auch fu¨r kompakte Mengen Π von Vektoren definiert werden. Hier sei
d(x,Π) , inf
pi∈Π
d(x,pi). (4.8)
In Iterationen wird der Abstand des aktuellen Iterationsvektors pi(t) von Lo¨sungen aus L(Q)
durch d(pi(t),L(Q)) bewertet. Eine in der Praxis oft verwendete Distanzfunktion ist die Maximum-
Norm des t-ten Fehlervektors ‖(t)‖∞ oder des t-ten normierten Fehlervektors ‖¯(t)‖∞:
1[18]: Lemma 6.4.11, Theorem 6.4.12 und Lemma 7.6.18 (singular) und [85]: Lemma 1
28
(t) , pi(t)− pi (4.9)
¯(t) , p¯i(t)− pi mit p¯i(t) , 1‖pi(t)‖1 pi(t). (4.10)
Dabei ist pi ein Element aus L(Q). Fu¨r (t) gilt
(t) , pi(t)− pi = (t− 1) ·T = . . . = (0) ·Tt.
und fu¨r eine beliebige Norm ‖ · ‖ ist ‖(t)‖ = ‖(0) ·Tt‖ ≤ ‖(0)‖ · ‖Tt‖. Die mittlere theore-
tische Konvergenzrate ist definiert durch [98]
Rt(T) , −t−1 · log ‖Tt‖. (4.11)
In praktischen Situationen ist Rt(T) oft nicht bekannt und man geht zur asymptotischen
theoretischen Konvergenzrate definiert durch [98]
R∞(T) , limt→∞Rt(T) = − log limt→∞(‖T
t‖)1/t =
{
− log ρ(T) falls ρ(T) < 1
− log γ(T) falls ρ(T) = 1
(4.12)
u¨ber. Die Anzahl der Iterationen, die notwendig ist, um den Fehler (t) relativ zum Startfehler
(0) um einen Faktor  zu vermindern, ist wegen (t) = (0) ·Tt durch
t > − log Rt(T)
≈ − log R∞(T)
mit  = ‖(t)‖‖(0)‖
abscha¨tzbar.
Zur Charakterisierung des Konvergenzverhaltens einer Folge von Iterationsvektoren pi(0),pi(1), . . .
werden oft sogenannte Folgen geschachtelter Level-Mengen {X(k) : X(k) ⊂ Rn} mit
X(k + 1) ⊂ X(k) fu¨r k ≥ 0 betrachtet. Hierbei ist X(k) eine Menge von Punkten, die bzgl.
einer Distanzfunktion einen durch k parametrisierten Abstand unterschreiten. Beispielsweise
beschreiben fu¨r ρ < 1 und C > 0 die Mengen X(k) , {x : d(x,pi) ≤ C · ρk} fu¨r k = 0, 1, . . .
eine Folge geschachtelter Level-Mengen bzgl. einer Lo¨sung pi und einer Distanzfunktion d. Des
Weiteren sei φ : N → N eine schwach steigende Funktion (φ(k + 1) ≥ φ(k) fu¨r k ≥ 0) mit
limk→∞ φ(k) = ∞, die aus einer beliebigen Folge von Iterationsvektoren pi(0),pi(1), . . . eine
Teilfolge derart konstruiert, so dass fu¨r geschachtelte Level-Mengen X(0), X(1), . . .
∀t ≥ φ(k) : pi(t) ∈ X(k) (4.13)
gilt. Konstruktive Konvergenzbeweise werden (grob) nach folgendendem Schema gefu¨hrt: zuerst
wird eine geschachtelte Folge von Level-Mengen und danach eine Teilfolge gema¨ß Bedingung
4.13 konstruiert. In den Level-Mengen werden Vektoren mit aufsteigender Approximationsgu¨te
gruppiert. Die Teilfolge markiert untere Schranken fu¨r die Anzahl von Iterationsschritten, nach
denen der Iterationsprozess einen “messbaren” Fortschritt hin zur Lo¨sung erzielt, also von einer
Level-Menge X(k) in die “bessere” Level-Menge X(k + 1) u¨bergeht. Die theoretische Konver-
genzrate ha¨ngt sowohl von der Konstruktion der Level-Mengen ab (wie “groß” ist der Fortschritt
bei U¨bergang vonX(k) nachX(k+1)) als auch vom Anstieg der durch φ beschriebenen Teilfolge.
29
4.2 Stationa¨re Iterationen
Ein Splitting Q = M − N mit nicht-singula¨rer Matrix M ∈ Rn×n u¨berfu¨hrt das System x ·
Q = 0 in eine Fixpunktgleichung bzw. Fixpunkt-Iteration pi(t + 1) = pi(t) · T. Das Ziel der
Konvergenzanalyse ist es, (mo¨glichst schwache) Bedingungen fu¨r die Koeffizientenmatrix Q und
das Splitting zu finden, die hinreichend (und notwendig) fu¨r Konvergenz sind.
Fu¨r jede Koeffizientenmatrix Q, die eine nicht-singula¨re M-Matrix ist, existiert ein (schwach)
regula¨res Splitting und alle (schwach) regula¨ren Splittings sind stets 0-konvergent [18]2. Der
Banachsche Fixpunktsatz besagt, dass die 0-Konvergenz (Kontraktion) des Iterationsoperators
hinreichend, im Fall nicht-singula¨rer Systeme auch notwendig fu¨r Konvergenz der Iteration ist
[18, 43]3. Dabei wird 0-Konvergenz einer Matrix T oft durch die a¨quivalente Aussage ρ(T) < 1
ersetzt, siehe [43]4.
Fu¨r den Fall eines singula¨ren Systems x · Q = 0 sind die Zusammenha¨nge komplizierter.
Eine wichtige Beobachtung ist, dass jedes Splitting zu einem Iterationsoperator T mit einem
Spektralradius 1 fu¨hrt [79, 80, 94], vgl. Lemma 4.2.
Lemma 4.2 (Spektralradius der Iterationsmatrix fu¨r singula¨res System) .
Voraussetzung: Es sei T = N ·M−1 der Iterationsoperator resultierend aus dem Splitting
Q = M−N (M−1 existiert) des singula¨ren Systems pi ·Q = 0.
Behauptung: Q singula¨r ⇔ ρ(T) = 1.
Beweis: “⇒”: Nach Voraussetzung existiert ein Vektor v 6= 0 mit v·Q = 0. Mit Q = (I−T)·M
und der Existenz von M−1 ist dieser Ausdruck algebraisch a¨quivalent zu v ·T = v.
“⇐”: Es ist v · Q = v · (I − T) ·M = v ·M − v ·T
︸ ︷︷ ︸
=v
·M = 0 fu¨r ein v 6= 0 und damit ist Q
singula¨r.
Dies gilt insbesondere fu¨r Splittings von asynchronen und hierarchischen Iterationen [94]. Itera-
tionsoperatoren mit dieser Eigenschaft sind niemals 0-konvergent (kontrahierend), sondern nur
konvergent oder divergent. Das Theorem 4.3 beinhaltet bekannte Bedingungen, die notwendig
und hinreichend fu¨r die Konvergenz eines Iterationsoperators sind. Fu¨r die Formulierung der
Bedingung 4.3 c) sind mathematische Begrifflichkeiten erforderlich, die dem Bereich der Triago-
nalisierbarkeit linearer Operatoren bzw. der dafu¨r im charakteristischen Polynom enthaltenen
Strukturinformationen [43] und der verallgemeinerten Inversen von singula¨ren linearen Opera-
toren [34] entstammen.
Theorem 4.3 (Charakterisierung konvergenter Iterationsoperatoren) [85]
Eine Matrix T ist genau dann konvergent, wenn
a) ρ(T) = 1 und
b) γ(T) < 1
sowie c) eine der folgenden a¨quivalenten Eigenschaften:
c’) der Elementarteiler [43] zum Eigenwert 1 im charakteristischen Polynom von T ist linear
2Theorem 6.2.3, Bedingungen N45, N46, O47 und P48
3[18]:Theorem 7.3.6 und [43]:Theorem 9.2
4Theorem 8.2
30
c”) rang (I−T)2 = rang (I−T) (bzw. ind (I−T) = 1)
c”’) (I−T)# als Drazin-Inverse [34] existiert und limt→∞ Tt = I− (I−T)(I−T)# [34]5, [18]6
gilt.
4.3 Nicht-stationa¨re hierarchische Iterationen
Nicht-stationa¨re Iterationen haben die Eigenschaft, dass Iterations-Operatoren bzw. lineare Ab-
bildungsvorschriften vom aktuellen Iterationsschritt abha¨ngig sind. Es gibt zahlreiche Ursachen
fu¨r variierende Iterations-Operatoren: die variable Reihenfolge, in der skalare Eintra¨ge oder
Blo¨cke in Gauss-Seidel Iterationen aktualisiert werden; ein variabler Relaxationsparameter; die
variable Auswahl “historischer” Iterationsvektoren in Semi-Iterativen Verfahren und die va-
riable Anzahl innerer Iterationsschritte in hierarchischen Iterationen. Hierarchische Iterationen
betten in jeden a¨ußeren Iterationsschritt eine innere Iteration ein. Da der Typ und die Anzahl
der sogenannten inneren Iterationsschritten variabel ist, verursacht sie einen nicht-stationa¨ren
Iterations-Operator.
Ein a¨ußeres Splitting Q = M −N mit nicht-singula¨rer Matrix M ∈ Rn×n und ein inneres
Splitting M = F−G mit nicht-singula¨rer Matrix F ∈ Rn×n u¨berfu¨hren das Gleichungssystem
pi ·Q = 0 in das innere Iterationsschema
p˜i(t˜+ 1) = pi(t) ·N · F−1 + p˜i(t˜) ·G · F−1
︸ ︷︷ ︸
H
. (4.14)
Hier ist H der innere Iterations-Operator und p˜i der innere Iterationsvektor. Das innere
Iterationsschema wird in ein a¨ußeres Iterationsschema eingebettet, indem der Startvektor der
inneren Iteration p˜i(0) als aktueller Iterationsvektor der a¨ußeren Iteration pi(t) gewa¨hlt wird und
nach q inneren Iterationsschritten der a¨ußere Iterationsvektor durch pi(t+1)← p˜i(q) aktualisiert
wird. Der a¨ußere Iterations-Operator Tq ist explizit und kompakt darstellbar durch
pi(t+ 1) = pi(t) ·

N · F−1
q−1
∑
j=0
Hj + Hq


︸ ︷︷ ︸
Tq
, (4.15)
vgl. Lemma 4.4. Die Auspra¨gung von Tq ha¨ngt von der Anzahl innerer Iterationen ab. Deswegen
ist der Iterations-Operator Tq durch q indiziert.
Lemma 4.4 (Geschlossene Darstellung des hierarchischen Iterations-Operators Tq)
Behauptung: Tq = N · F−1
∑q−1
j=0 Hj + Hq.
Beweis: (Induktion u¨ber q):
Es ist T1 = N · F−1 + H und die Gl. 4.14 zur Beschreibung eines inneren Schritts zeigt, dass
T1 korrekt ist. Der Induktionsschritt ist ebenfalls unter Anwendung von Gl. 4.14 durchfu¨hrbar,
5Theorem 8.2.2
6Lemma 7.6.11
31
denn es gilt:
p˜i(q + 1) = p˜i(0) ·N · F−1 + p˜i(q) ·H
= p˜i(0) ·N · F−1 + p˜i(0) · (N · F−1
q−1
∑
j=0
Hj + Hq) ·H
= p˜i(0) ·

N · F−1
q
∑
j=0
Hj + Hq+1


A¨ußeres und inneres Splitting der Koeffizientenmatrix ko¨nnen explizit durch ein Splitting dar-
gestellt werden. Die Variabilita¨t der inneren Iteration in Form unterschiedlicher Auspra¨gungen
von Tq fu¨hrt zu Multi-Splittings Q = Mq−Nq mit Tq = Nq ·M−1q . Jeder Iterations-Operator
Tq induziert ein (nicht eindeutiges) Splitting Q = Mq −Nq, vgl. Lemma 4.5. Dies verdeutlicht,
dass eine hierarchische Iteration mit fester Anzahl innerer Schritte wieder zu einer stationa¨ren
Iteration mit singula¨rem Splitting Q = M − N degeneriert. Fu¨r q = 1 kann das induzierte
Splitting direkt angegeben werden, es ist M1 = F, N1 = N + G und T1 = (N + G) · F−1, vgl.
Lemma 4.5.
Lemma 4.5 (Induktion eines Splittings aus Iteration-Operator Tq [73]) .
Behauptung: Es existieren Matrizen Mq und Nq mit Tq = Nq ·M−1q und Mq −Nq = Q.
Beweis: Nach Voraussetzung ist M = (I−H) ·F und M−1 existiert. Deswegen ist auch (I−H)
nicht-singula¨r und die Teleskopsummengleichung (I − H)∑q−1j=0 Hj = I − Hq kann u¨berfu¨hrt
werden in
q−1
∑
j=0
Hj = (I−H)−1 · (I−Hq).
Damit kann der Iterations-Operator Tq wie folgt transformiert werden:
Tq = N · F−1
q−1
∑
j=0
Hj + Hq = N · F−1 · (I−H)−1
︸ ︷︷ ︸
M−1
·(I−Hq) + Hq
= N ·M−1 · (I−Hq) + Hq
=
[
N + Hq · (I−Hq)−1 ·M
]
︸ ︷︷ ︸
Nq
·
[
(I−Hq)−1 ·M
]−1
︸ ︷︷ ︸
M−1q
Damit hat man fu¨r Q ein einfaches Splitting aus dem Iterations-Operator Tq induziert bzw.
konstruiert, denn fu¨r die Matrizen Mq und Nq gilt:
Mq −Nq = (I−Hq)−1 ·M − Hq · (I−Hq)−1 ·M−N
= (I−Hq) · (I−Hq)−1 ·M − N
= M−N = Q
Die Matrizen Mq und Nq sind nach [73]7 eindeutig. Fu¨r den Spezialfall q = 1 ist M1 = F,
N1 = N + G und damit T1 = (N + G) · F−1.
7Lemma 2.3
32
Dem durch die Gl. 4.14 und 4.15 beschriebenen mathematischen Modell einer hierarchischen
Iteration liegen globale Splittings zugrunde, die den gesamten Iterationsvektor gleichermaßen
erfassen. Dieses Modell kann fu¨r blockorientierte Varianten hierarchischer Iterationen verfeinert
werden, in denen fu¨r jeden Block eine quasi eigensta¨ndige lokale innere Iteration definierbar
ist. Nachfolgend wird stets ein BJAC -Splitting als a¨ußeres Splitting vorausgesetzt, d.h. es ist
Q = M−N und
M = D (Q[1, 1], . . . ,Q[N,N ]) .
Fu¨r X = 1, . . . , N sind
FX = D(I, . . . ,BX , . . . , I) ∈ Rn×n
GX = D(I−Q[1, 1], . . . ,CX , . . . , I−Q[N,N ]) ∈ Rn×n
blockabha¨ngige innere, lokale Splittings mit Q[X,X] = BX −CX (BX ,CX ∈ Rn(X)×n(X)). Des
Weiteren sei
Qt , {q(t, 1), . . . , q(t,N)} ∈ NN
die Menge der blockabha¨ngigen inneren Iterationsschritte im a¨ußeren Schritt t, HX , GX ·
F−1X ∈ Rn×n der blockabha¨ngige innere Iterationsoperator und EX = D(0, . . . , 0, I,0, . . . , 0) ein
Maskierungsoperator, in der I genau der X-te Hauptdiagonalblock ist. Es ist bekannt, dass der
a¨ußere Iterationsoperator TQt explizit und kompakt darstellbar ist durch
pi(t+ 1) = pi(t) ·


∑
X∈Z0
EX

N · F−1X
q(t,X)−1
∑
j=0
HjX + H
q(t,X)
X




︸ ︷︷ ︸
TQt
. (4.16)
Diese Darstellung kann in eine weniger kompakte Form u¨berfu¨hrt werden, die mehr strukturelle
Informationen preisgibt, siehe Lemma 4.6. Es sei
QX , Q[X,X], HX , CX ·B−1X ∈ Rn(X)×n(X),
K(Qt) ,






Q−11 · (I−H
q(t,1)
1 ) 0 . . . 0
0 Q−12 · (I−H
q(t,2)
2 ) . . . 0... ... . . . ...
0 0 . . . Q−1N · (I−H
q(t,N)
N )






und
L(Qt) =






Hq(t,1)1 0 . . . 0
0 Hq(t,2)2 . . . 0... ... . . . ...
0 0 . . . Hq(N,2)N






.
Dann gilt in kompakter Schreibweise
TQt = N ·K(Qt) + L(Qt). (4.17)
33
Lemma 4.6 (Induktion eines Splittings aus Iterationsoperator TQt [73]) .
Behauptung: Es existieren Matrizen K(Qt) und L(Qt), so dass der Iterations-Operator TQt
darstellbar ist als
TQt = N · K(Qt) + L(Qt).
Beweis: Der Iterations-Operator
Tq = N ·M−1 · (I−Hq) + Hq (4.18)
aus Lemma 4.5 beschreibt den Spezialfall, dass im Schritt t fu¨r alle Blo¨cke die gleiche Anzahl
q = q(t, 1) = . . . = q(t,N) innerer Schritte ausgefu¨hrt wird. Die Darstellung von TQt ist aus der
Struktur von Tq als Verallgemeinerung ableitbar. Da M eine Blockdiagonalmatrix ist, gilt dies
auch fu¨r M−1, F, G und damit auch fu¨r H, Hq und schließlich auch fu¨r M−1 · (I −Hq). Der
X-te Block dieser Matrix ist Q−1X · (I−H
q
X). Variiert man nun q blockweise, so gilt
TQt = N ·D(Q−11 · (I−H
q(t,1)
1 ), . . . ,Q−1N · (I−H
q(t,N)
N ))
︸ ︷︷ ︸
,K(Qt)
+ D(Hq(t,1)1 , . . . ,H
q(t,N)
N )
︸ ︷︷ ︸
,L(Qt)
,
vgl. auch [62], Gleichungen 4-8. Ebenso gilt
K(Qt) = D(B−11 ·
t(t,1)−1
∑
j=0
Hj1, . . . ,B−1N ·
t(t,N)−1
∑
j=0
HjN ),
wenn man die zur Gl. 4.18 a¨quivalente Darstellung
Tq = N · F−1
q−1
∑
j=0
Hj + Hq
von Tq verwendet.
Zusammenfassung: Der Einfluss blockunabha¨ngiger und blockabha¨ngiger innerer Iteratio-
nen auf die Struktur des Iterations-Operators ist analytisch erfassbar. Der jeweilige Iterations-
Operator korrespondiert zu einem Matrix-Splitting der Koeffizientenmatrix Q.
4.4 Stochastische asynchrone Iterationen
Mathematische Modelle asynchroner Fixpunkt-Iterationen sind oft untersucht worden [9, 19,
14, 38, 63, 64, 76, 92]. Asynchronita¨t in Fixpunkt-Iterationen hat zwei Eigenschaften: die Kom-
ponenten des Iterationsvektors ko¨nnen “entkoppelt” - mit individueller Rate - iteriert werden
und Komponenten, die in die Aktualisierung anderer Komponenten einfließen, ko¨nnen unter-
schiedlichen “historischen” Iterationsschritten entstammen (Iteration vom Grad > 1, vgl. Ab-
schnitt 4.1). Asynchrone Iterationen sind wie auch hierarchische Iterationen nicht-stationa¨re
Iterationen, in denen der Iterations-Operator variiert. In hierarchischen Iterationen verursacht
die variable Anzahl innerer Iterationen nicht-stationa¨re Iterations-Operatoren. In asynchronen
Iterationen verursacht die variable Auswahl zu iterierender Komponenten und die variable Aus-
wahl “historischer” Iterationsvektoren einen nicht-stationa¨ren Iterations-Operator.
34
Mathematische Modelle asynchroner Iterationen generalisieren das mathematische Modell einer
gewo¨hnlichen stationa¨ren, synchronen Iteration der Form pi(t+ 1) = pi(t) ·T. Der stochastische
Ru¨ckgriff auf historische Iterationsvektoren wird formal durch Vektoren pi1(t), . . . ,piN (t) mit
pir(t) , (pi[1](τ r1 (t)), . . . ,pi[N ](τ rN (t))
)
∈ Rn, (4.19)
beschrieben. pir(t) “modelliert” eine asynchrone Rekombination der Komponenten des Itera-
tionsvektors pi[1], . . . ,pi[N ]. Per Definition sei pir(t) die “lokale Sicht” auf den globalen Iterations-
vektor, die im Schritt t in die Aktualisierung von pi [r] einfließt. Die asynchrone Rekombination
beitragender Komponenten ist abha¨ngig von einer Familie zeitdiskreter stochastischer Ketten
τ11 (t), . . . , τNN (t). Die Kette τ rs (t) “modelliert” den Ru¨ckgriff auf die beitragende Komponente pi [s]
(“s”=sender) zur Aktualisierung von pi [r] (“r”=receiver). Des Weiteren sei I t ⊆ {1, . . . , N} , Z0
eine Aktualisierungsmenge von Komponentenindizes, die im Schritt t iteriert bzw. aktualisiert
werden. Der synchrone Iterations-Operator T ∈ Rn×n sei blockstrukturiert und die Blockstruk-
tur sei konsistent zur Blockstruktur von Q (vgl. Abschnitt 3.2 zur Notation der Blockstruktur)
und T[r] ∈ Rn×n(r) sei die Submatrix der r-ten Block-Spalte. Damit erha¨lt man das allgemeine
Modell einer asynchronen Iteration nach Bertsekas und Tsitsiklis [19]8
pi[r](t+ 1) =
{
pi[r](t) falls r /∈ I t
pir(t) ·T[r] falls r ∈ I t.
(4.20)
Im Spezialfall einer partiell-asynchronen Iteration ist der Grad B a priori bekannt. In die-
sem Fall kann die Dynamik der pir(t) Vektoren in die Dynamik des Iterations-Operators “ver-
schoben” und dadurch die Dynamik der asynchronen Iteration insgesamt eingegrenzt werden.
Hierfu¨r definiert man einen expandierten Historienvektor p˜i(t) (Def. s.u.) mit statischer Zusam-
mensetzung, der alle zula¨ssigen lokalen Sichten (endlich viele) integriert. Durch Variation des
Iterations-Operators wird die jeweilige Sicht fu¨r den aktuellen Iterationsschritt extrahiert. Die
formale Beschreibung des expandierten Historienvektors ist
p˜i(t) , (pi(t),pi(t− 1), . . . ,pi(t−B)) ∈ Rn·(B+1). (4.21)
Eine Alternative zur Gl. 4.20 ist
p˜i(t+ 1) = p˜i(t) ·TIt,Dt (4.22)
Der nicht-stationa¨re und ebenfalls expandierte Iterations-Operator TIt,Dt ∈ Rn·(B+1)×n·(B+1)
verschiebt (↘) “historische” Komponenten
p˜i(t) = ( pi(t) pi(t− 1) . . . pi(t−B + 1) pi(t−B) )
↘ ↘
p˜i(t+ 1) = ( pi(t+ 1)
︸ ︷︷ ︸
aktualisiert
pi(t) . . . pi(t−B + 2) pi(t−B + 1) )
8Bertsekas und Tsitsiklis betrachten asynchrone iterative Verfahren in einem breiteren Kontext, insbesondere
auch fu¨r nicht-lineare Funktionen. Deswegen verwenden ihre Modelle eine funktionale Notation mit pi[r](t + 1) =
pi[r](t) bzw. pi[r](t + 1) = fr(pir(t)), die von konkreten Eigenschaften von f (linear, nicht-linear etc.) zuna¨chst
abstrahiert.
35
und aktualisiert pi[r](t) in pi(t+ 1) fu¨r alle r ∈ I t.
Im Hinblick auf die Konvergenzanalyse asynchroner Iterationen ist es notwendig, die Menge
prinzipiell mo¨glicher Ausfu¨hrungen asynchroner Iterationen durch gewisse Anforderungen ein-
zuschra¨nken. Nachfolgend ist ein Katalog typischer (parametrisierter) Anforderungen angegeben.
Diese Anforderungen ko¨nnen in Implementierungen asynchroner Iterationen erfu¨llt werden, vgl.
Abschnitte 6.1.3 und 6.1.4.
Bedingung 4.7 (Anforderungen an asynchrone Iterationen) .
“FIFO”: Daten werden nach dem “First-in First-out” Prinzip (keine U¨berholungen) kommu-
niziert, d.h.
∀r, s : τ rs (0) ≤ τ rs (1) ≤ τ rs (2) . . . (4.23)
“progress of inputs” (“admissible delays”): Es wird nicht auf beliebig alte Komponenten
historischer Iterationsvektoren zuru¨ckgegriffen bzw. es werden keine Komponenten beliebig oft
benutzt, d.h.
∀ r, s : lim
t→∞
τ rs (t) =∞ (4.24)
“partial asynchronism” (“regulated delays”): Die asynchrone Iteration ist vom Grad D,
d.h. die Differenz zwischen dem aktuellen Iterationsschritt und dem beitragender, historischer
Komponenten des Iterationsvektors ist nach oben durch D beschra¨nkt:
∃D ∈ N : ∀ r, s, t : t− τ rs (t) ≤ D (4.25)
Die Bedingung 4.25 ist hinreichend fu¨r Bedingung 4.24.
“progress of updates” (“admissible updating sets”): Alle Komponenten des Iterations-
vektors werden unendlich oft aktualisiert , d.h.
∀ s : |{t|s ∈ I t}| =∞ (4.26)
“partial asynchronism” (“regulated updating sets”): Jede Komponente des Iterations-
vektors wird innerhalb von S + 1 Iterationsschritten mindestens einmal aktualisiert, d.h.
∃S ∈ N : ∀ i : i+S∪
t=i
It = {1, . . . , N} (4.27)
Die Bedingung 4.27 ist hinreichend fu¨r Bedingung 4.26.
“data locality”: Fu¨r die Aktualisierung einer Komponenten steht immer die aktuellste Ver-
sion derselben zur Verfu¨gung:
∀ r : r ∈ I t ⇒ τ rr (t) = t (4.28)
Das Szenario einer asynchronen Iteration heißt zula¨ssig, wenn die Bedingungen 4.24 und 4.26
erfu¨llt sind. Ein Szenario heißt reguliert, wenn die Bedingungen 4.25, 4.27 und 4.28 erfu¨llt
sind. B = max(D,S) ist die Asynchronita¨tskonstante [19]. In den Abschnitten 6.1.3 und
6.1.4 wird der Einfluss der Parameter D und S auf die Performance asynchroner Iterationen
experimentell untersucht.
36
Kapitel 5
Verteilte sowie hierarchische und
asynchrone Iterationen zur
stationa¨ren Analyse von
Markov-Ketten - ASYNC
Das Kapitel beschreibt ein neues numerisches Verfahren (ASYNC ) zur stationa¨ren Analyse von
Markov-Ketten. ASYNC basiert auf hierarchischen und asynchronen Erweiterungen einer block-
orientierten Jacobi-Iteration (BJAC ). Das Grundgeru¨st ist eine BJAC -Iteration, die asynchron
und verteilt auf parallelen Rechenressourcen mit verteiltem Speicher ausgefu¨hrt wird. In die
asynchronen Schritte der BJAC -Iteration werden Intra-Block-Iterationen eingebettet (hierar-
chische Iteration). Der Bezeichner ASYNC verweist auf die zentrale Eigenschaft der Implemen-
tierung: die Asynchronita¨t in Berechnung und Kommunikation.
Das Kapitel ist wie folgt strukturiert: im Abschnitt 5.1 “Einleitung und U¨bersicht” werden die
zentralen Eigenschaften von ASYNC bzgl. des mathematischen Modells, des algorithmischen
Modells und der Rechnerarchitektur genannt und ihre Synergieeffekte als Motivation fu¨r deren
Integration erla¨utert. Der Abschnitt 5.2 “Konvergenzverhalten” ist eine kritische Bestandsauf-
nahme bekannter Konvergenzresultate aus der Mathematik hinsichtlich ihrer Anwendbarkeit
und praktischen Nu¨tzlichkeit im Kontext dieser Arbeit. Die eingesetzte parallele Rechnerarchi-
tektur und das damit verbundene parallele Programmmodell werden im Abschnitt 5.3 erla¨utert.
Anschließend werden im Abschnitt 5.4 “Algorithmisches Modell” die Besonderheiten des numeri-
schen Lo¨sungsverfahrens ASYNC und seiner Implementierung angesprochen. Die Voraussetzung
fu¨r eine verteilte Berechnung - die Identifikation von Teilproblemen und die Berechnung einer
Lastverteilung - wird im Abschnitt 5.5 “Lastverteilung und Kommunikation” behandelt und mit
Beispielen unterlegt. Schließlich werden im Abschnitt 5.6 ausgewa¨hlte Implementierungsaspekte
betrachtet.
37
5.1 Einleitung und U¨bersicht
Die essentiellen Eigenschaften von ASYNC sind:
1. Mathematisches Modell: Das Grundgeru¨st von ASYNC ist eine asynchrone und hier-
archische BJAC -Iteration. In die asynchronen BJAC -Schritte sind Intra-Block-Iterationen
(Hierarchie) und “on-the-fly” Aggregierungsschritte eingebettet.
2. Algorithmisches Modell: ASYNC nutzt als Basis-Datenstruktur zur Speicherung der
Generatormatrix eine hierarchische Kronecker-Darstellung, fokussiert auf die verteilte Aus-
fu¨hrung von asynchronen BJAC -Iterationsschritten im verteilten Speicher und nutzt Kom-
munikationsroutinen mit asynchroner Sende- und Empfangssemantik.
3. Rechnerarchitektur: ASYNC zielt auf parallele Rechenarchitekturen mit verteiltem
Speicher ab (Rechner-Netzwerke und -Cluster).
Die Integration dieser Aspekte ist neu und durch zahlreiche Synergieeffekte motiviert:
1. Die Kronecker-Darstellung der Generatormatrix profitiert von einer parallelen Rechner-
architektur, weil leicht verteuerte Rechenoperationen auf der Generatormatrix (bedingt
durch generische Darstellung) bei einer verteilten Ausfu¨hrung zusa¨tzliche Rechenressour-
cen erschließen. Zudem wird in einem Rechnernetzwerk ein großer, wenn auch verteilter
Arbeitsspeicher verfu¨gbar gemacht. Eine Verteilung des Iterationsvektors ist attraktiv, weil
der Platz-Flaschenhals (= Speicherung des Iterationsvektors) behoben wird.
2. Die Kronecker-Darstellung liefert eine Blockstruktur der Generatormatrix, an der block-
orientierte Verfahren adaptieren ko¨nnen. Eine BJAC -Iteration liefert eine Dekomposition
des Berechnungsproblems in Teilproblme, die auf der gegebenen Blockstruktur skalierbar
ist und eine parallele Ausfu¨hrung ermo¨glicht. Zudem reflektiert die Blockstruktur etwaige
NCD-Charakteristika [42] im System, so dass Teilprobleme numerisch gering gekoppelt
sind, ein Umstand, von dem parallele Ausfu¨hrungen profitieren und der Aggregierungs-
schritte motiviert.
3. Eine verteilte Ausfu¨hrung der BJAC -Iteration profitiert von der Kronecker-Darstellung,
weil in jedem verteilten Arbeitsspeicher die vollsta¨ndige Generatormatrix als Duplikat
gehalten werden kann, was Datenabha¨ngigkeiten verringert und gleichzeitig die Kommu-
nikation flexibilisiert, sowie Lastumverteilungen erleichtert.
4. Verteilte, asynchrone Iterationen sind unabha¨ngig von der Verfu¨gbarkeit “aktueller” kom-
munizierter Daten und deswegen geeignet fu¨r Kommunikationsmedien mit geringer bzw.
lastabha¨ngig-schwankender Bandbreite. Das Kommunikationsmedium profitiert von ver-
teilten, asynchronen Iterationen, die zu einer gleichma¨ßigeren Belastung der Kommunika-
tionsressourcen fu¨hren, weil Rechenphasen (geringe Kommunikation) und Kommunikati-
onsphasen nicht streng alternierend, sondern zeitlich u¨berlappend ablaufen.
5. Asynchrone und hierarchische Iterationen sind flexibel ausfu¨hrbar und ko¨nnen an Perfor-
mance-Charakteristika des Kommunikationsmediums (adaptiv) angepasst werden (Stabi-
lita¨t und Robustheit). Dies beinhaltet die Steuerung von Kommunikationsraten und die
Mo¨glichkeit, lokale Iterationen in Abha¨ngigkeit von den verfu¨gbaren kommunizierten Da-
ten selektiv auszufu¨hren.
38
5.2 Konvergenzverhalten
Die grundsa¨tzliche Zielsetzung dieser Arbeit ist die stationa¨re Analyse einer Markov-Kette. Dies
erfordert die Lo¨sung eines linearen Gleichungssystems x · Q = 0 mit der Generatormatrix Q,
vgl. Abschnitt 3.1, insbesondere Proposition 3.4. Die Datenstruktur der Generatormatrix basiert
hier auf einer hierarchischen Kronecker-Darstellung, vgl. Abschnitt 3.2. Diese Darstellung der
Generatormatrix induziert eine Blockstruktur auf der Generatormatrix und das System x·Q = 0
nimmt die Form
(pi[1], . . . ,pi[N ])



Q[1, 1] . . . Q[1, N ]
... . . . ...
Q[N, 1] . . . Q[N,N ]


 = 0
an. Zur Lo¨sung dieses strukturierten Gleichungssystems wird in ASYNC eine Block-Iteration
angewendet. Die Basis-Iteration in ASYNC ist eine BJAC -Iteration. Ein BJAC -Iterationsschritt
erfordert die Lo¨sung N nicht-homogener Gleichungssysteme
pi[c]·Q[c, c] = b[c] mit b[c] , −
∑
r 6=c
pi[r]·Q[r, c] fu¨r alle c ∈ {1, . . . , N} , Z0. (5.1)
Die rechten Seiten b[c] repra¨sentieren eine aggregierte Sicht auf die aktuelle Approximation von
pi. Fu¨r Blo¨cke Q[r, c] 6= 0 beinhalten die rechten Seiten Datenabha¨ngigkeiten. Die Systeme in
Gl. 5.1 werden approximativ durch eine eingebettete Iteration mit q inneren Schritten gelo¨st.
Dieser Ansatz wird als hierarchische Iteration bezeichnet. Wenn q fest ist, liegt eine gewo¨hnliche
stationa¨re Iteration vor (Abschnitt 4.2), anderenfalls eine nicht-stationa¨re hierarchische Iteration
(Abschnitt 4.3). Des Weiteren werden die Systeme in Gl. 5.1 asynchron gelo¨st, vgl. Abschnitt
4.4 “Stochastische asynchrone Iterationen”.
Stationa¨re und nicht-stationa¨re hierarchische Iterationen sowie stochastische asynchrone Itera-
tionen sind in der Mathematik eingehend untersucht worden. In dieser Arbeit soll festgestellt
werden, welche Aussagen zu Konvergenz und Konvergenzraten auf den hier betrachteten Fall
einer Generatormatrix als Koeffizientenmatrix des zu lo¨senden Gleichungssystems u¨bertragbar
sind und so der Bewertung von ASYNC dienen ko¨nnen. Hierfu¨r war es notwendig, den Stand
der Theorie u¨ber die Konvergenz hierarchischer und asynchroner Iterationen zu sichten und im
Kontext dieser Arbeit auf seine Relevanz hin zu pru¨fen. Im Kapitel 4 sind die mit hierarchischen
und asynchronen Iterationen korrespondierenden mathematischen Modelle angegeben. Nachfol-
gend werden fu¨r diese Modelle Konvergenzresultate rekapituliert und einige Experimente zum
Konvergenzverhalten dokumentiert.
5.2.1 Stationa¨res Szenario
Stationa¨re hierarchische Iterations-Operatoren werden durch ASYNC ausgefu¨hrt, wenn die Sy-
steme in Gl. 5.1 iterativ mit einer festen Anzahl innerer Iterationen gelo¨st werden. Das Theo-
rem 4.3 (Seite 30) charakterisiert konvergente stationa¨re Iterations-Operatoren. Jede Generator-
matrix hat die Eigenschaft eine singula¨re M-Matrix mit “Eigenschaft C” zu sein. Dies garantiert
Konvergenz, vgl. Prop. 5.1.
Proposition 5.1 (Konvergenz stationa¨re Iteration) .
Jede Generatormatrix −Q ist eine singula¨re M-Matrix mit der ’Eigenschaft C’ [18]1, weil fu¨r
1Theorem 8.4.2
39
s = 1 und P = ∆tQ + I mit ∆t = max{|q| : q ist Diagonaleintrag in Q} gilt, dass −Q = sI−P,
s ≥ ρ(P) = 1 > 0 und P ≥ 0 (zeilenstochastisch) ist. Nach [18]2 bzw. [85]3 ist eine Matrix genau
dann eine singula¨re M-Matrix mit der ’Eigenschaft C’, wenn ein regula¨res Splitting zu einem
Iterationsoperator T fu¨hrt, fu¨r den die Bedingungen a) und c) aus Theorem 4.3 erfu¨llt sind.
Wenn die Matrix zusa¨tzlich irreduzibel ist, erfu¨llt bereits ein schwach regula¨res Splitting die
Bedingungen a) und c), siehe [91]4. Insbesondere ist das BJAC-Splitting einer M-Matrix stets
regula¨r [85]. Eine Eigenwert-Transformation gema¨ß Tα = (1 − α)I + αT bewirkt schließlich,
dass die Magnitude von Tα echt kleiner als 1 ist [91]5, also die Bedingung b) aus Theorem 4.3
erfu¨llt ist, siehe auch [85]6 und [18]7.
Fu¨r singula¨re Systeme (ρ(T) = 1) wird die asymptotische Konvergenzrate durch die Magnitude
γ(T) des Iterationsoperators T bestimmt [18, 79, 80] 8. Theoretische asymptotische Konvergenz-
raten ko¨nnen gute Abscha¨tzungen fu¨r praktische Konvergenzraten liefern, wie das nachfolgende
Beispiel einer stationa¨ren hierarchischen Iteration verdeutlicht.
Beispiel 5.2 (Vergleich theoretische und praktische Konvergenzrate) .
Eine stationa¨re Iteration sei durch pi(0) = (0.25, 0.25, 0.25, 0.25) und
pi(t+ 1) = pi(t) ·T(λ) mit T(λ) , 11 + λ









1 0 0 0
0 1 λ λ2
1
λ 1 λ 0
0 0 0 λ









(5.2)
(0 < λ ≤ 1) definiert. Der Iterationsoperator T(λ) korrespondiert zu einer hierarchischen BJAC-
JAC-Iteration mit 2 inneren JAC-Iterationen je 2× 2 Block (vgl. Matrix T2 in Beispiel 5.6 im
na¨chsten Abschnitt) angewendet auf die Generatormatrix Q aus Bsp. 3.5 mit µ = 1. Man kann
nachrechnen, dass ρ(T(λ)) = 1 (fu¨r alle 0 < λ ≤ 1) und γ(T(λ)) = (λ + 1)−1 ist. Die letzte
Gleichung zeigt, dass mit der Zunahme von λ die Magnitude γ sinkt und wegen R∞(T(λ)) ,
− log γ(T(λ)) die asymptotische Konvergenzrate steigt.
Die stationa¨re Lo¨sung ist pi = (0.25, 0.25, 0.25, 0.25) (λ = 1) bzw. (1− λ) · (1− λ4) · (1, λ, λ2, λ3)
(0 ≤ λ < 1), vgl. Bsp. 3.5 mit µ = 1. Die Gu¨te der gleichverteilten Startverteilung pi(0) ist so-
mit von λ abha¨ngig und wird zunehmend besser (schlechter) fu¨r λ→ 1 (λ→ 0). Die Kurven in
Abb. 5.2 links (rechts) zeigen log10 ‖(t)‖∞ fu¨r t = 0, 1, 3, 5, 9, 15 (log10 ‖(t)‖∞/ log10 ‖(0)‖∞
fu¨r t = 1, 3, 5, 9, 15) jeweils in Abha¨ngigkeit von λ (logarithmische Skala zur besseren Darstel-
lung). Die Kurven im linken Diagramm zeigen, dass mit Ausnahme des ersten Schritts eine
Zunahme von λ (erho¨ht asymptotische Konvergenzrate) die Effektivta¨t der Iterationsschritte
verbessert (vertikaler Abstand zwischen Kurven wird gro¨ßer). Der fu¨r kleine λ Werte erzielte
2Theorem 6.4.12 Bedingung F13 oder Theorem 7.6.20
3Theorem 1
4Theorem 3.18
5Theorem 3.18
6Theorem 2
7Theorem 7.6.19
8in [18] siehe Abschnitt 7.6
40
Vorteil wird nach wenigen Schritten kompensiert (Kurven fallen zunehmend stark ab). Die Kur-
ven im rechten Diagramm zeigen den Fehler im Verha¨ltnis zum Startfehler. Mit Zunahme von λ
sinkt der relative Fehler schneller (vertikaler Abstand zwischen Kurven wird gro¨ßer), wobei fu¨r
kleine λ-Werte der relative Fehler in den ersten Schritten zuna¨chst besser ist.
–8
–6
–4
–2
0
eps
0.2 0.4 0.6 0.8 1
lambda
–4
–3
–2
–1
eps_rel
0.2 0.4 0.6 0.8 1
lambda
Abbildung 5.1: Links: Logarithmische Norm des Fehlervektors log10 ‖(t)‖∞ fu¨r t = 0, 1, 3, 5, 9, 15
(von oben nach unten) in Abha¨ngigkeit von λ; Rechts: Logarithmische relative Norm des Fehler-
vektors log10 ‖(t)‖∞/ log10 ‖(0)‖∞ fu¨r t = 1, 3, 5, 9, 15 (von oben nach unten) in Abha¨ngigkeit
von λ
Die theoretische (gescha¨tzte) und tatsa¨chliche Anzahl von Iterationen, die notwendig ist, um
einen relativen Fehler  = 0.01 zu erreichen, sind in Tab. 5.2 fu¨r ausgewa¨hlte λ Werte aufgeza¨hlt.
Der gescha¨tzte Wert basiert auf der asymptotischen Konvergenzrate R∞(T(λ)). Die theoretische
Abscha¨tzung ist - von Rundungsfehlern abgesehen - sogar exakt.
λ 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
− log R∞(T(λ)) 48 25 18 14 11 10 9 8 7
real t 49 26 18 14 12 10 9 8 8
Tabelle 5.1: Gescha¨tze und reale Anzahl von Schritten t fu¨r relativen Fehler (t)/(0) ,  < 0.01
5.2.2 Nicht-stationa¨res hierarchisches Szenario
Zur Strukturierung der Konvergenzresultate ist es hilfreich, Szenarien nicht-stationa¨rer, hierar-
chischer Iterationen zu definieren. Spa¨ter wird noch bei der ASYNC -Performance-Modellierung
auf den Szenario-Begriff zuru¨ckgegriffen.
Definition 5.3 (Szenario hierarchische Iteration) .
Die Sequenz Q1,Q2, . . . mit Qt , {q(t, 1), . . . , q(t,N)} ∈ NN spezifiziert zusammen mit dem
Startvektor pi(0) eindeutig die Folge der Iterationsvektoren pi(1),pi(2), . . . bzw. das Szenario
einer hierarchischen BJAC-Iteration. Hierbei ist q(t, c) die Anzahl innerer Schritte zur Lo¨sung
der Systems mit Index c in Gl. 5.1 im a¨ußeren BJAC-Iterationsschritt t.
41
Eine Konvergenzanalyse des mathematischen Modells erfordert es, zwischen folgenden Szenarien
zu unterscheiden.
Beispiel 5.4 (Spezielle Szenarien einer hierarchischen Iteration) .
Aus der Menge mo¨glicher Szenarien (Def. 5.3) sind Szenarien mit folgenden Restriktionen R1,
R2 und R3 ableitbar:
R1: ∀t,X : q(t,X) = const ⇒ stationa¨res Szenario, q ist konstant
R2: ∀t,X, Y : q(t,X) = q(t, Y ) ⇒ nicht-stationa¨r, aber q ist blockunabha¨ngig
R3: ∀t, u,X : q(t,X) = q(u,X) ⇒ stationa¨res Szenario: q ist blockabha¨ngig
Bekannte Ergebnisse zu Konvergenz und Konvergenzraten sind in der nachfolgenden Propositi-
on 5.5 zusammengetragen. Die Ergebnisse sind folgenden Abschnitten zugeordnet: Konvergenz
(a und c ), Konvergenzrate (b und d), nicht-singula¨re Systeme (a und b), singula¨re Systeme (c
und d), stationa¨re Iterationen (R1 und R3) und nicht-stationa¨re Iterationen (R2 und R¯).
Proposition 5.5 (Konvergenz hierarchische BJAC -Iteration) .
Fu¨r hierarchische BJAC-Iterationen (Gl. 4.16 und 4.17) sind folgende Konvergenzaussagen
bekannt:
a: Konvergenz ist garantiert [73]9, wenn Q nicht-singula¨r ist, Q = M−N ein regula¨res
Splitting ist und wenn abha¨ngig von der Erfu¨llung der Restriktionen R1, R2 und R3 (R¯ =
keine Restriktion, vgl. Bsp. 5.4) gilt:
R1,R3: ∀X : M = FX −GX ist schwach regula¨res Splitting
R2, R¯: ∀X : M = FX −GX ist regula¨res Splitting.
b: Die relative Konvergenzrate ist abscha¨tzbar [73]10, wenn a) erfu¨llt ist. Dann gilt:
R1: ρ(Tq) ≤ ρ(Tp) q ≥ p
R2: ρ(Υr) ≤ [ρ(T1)]r mit Υr = TQr · . . . ·TQ1
R3: ρ(TQ) ≤ ρ(TQˆ) mit Q = {q(1), . . . , q(N)}, Qˆ = {qˆ(1), . . . , qˆ(N)}, qˆ(X) ≤ q(X)
R¯: ρ(TQt) ≤ ρ(T1) mit Qt := {q(t, 1), . . . , q(t,N)} und q(t,X) ≥ 1
c: Konvergenz ist garantiert, wenn Q eine singula¨re M-Matrix mit Eigenschaft C
ist, Q = M −N ein regula¨res Splitting und alle M = FX −GX schwach regula¨re
Splittings sind und
R1,R3: ∀X : GX · F−1X hat positive (> 0) Diagonaleintra¨ge [82]11,
R2,R¯: es existiert Norm ‖ · ‖ mit ‖TQt(I−TQt)(I−TQt)#‖ < 1, siehe [82]12.
d: Im Gegensatz zum nicht-singula¨ren Fall ist der Einfluss der Anzahl innerer Iterationen auf
die Magnitude des Iterationsoperators bzw. auf die Konvergenzrate bereits fu¨r stationa¨re
Iterationen unbekannt13.
Die zentrale Botschaft der Proposition 5.5 lautet, dass Konvergenzbedingungen fu¨r hierarchische
Iterationen zur Lo¨sungen singula¨rer Systeme formulierbar und auch in der Praxis erfu¨llbar sind
9Theorem 4.2 und Korollar 4.3, Theorem 6.4, Theorem 7.1, Theorem 7.3
10Korollar 5.2, Theorem 6.4, Theorem 7.2, Theorem 7.3
13Anfrage bei D.B. Szyld
42
(Teil c), aber leider kein analytischer Zusammenhang zwischen der Anzahl innerer Iterationen
und der Konvergenzrate bekannt ist (Teil d). Fu¨r nicht-singula¨re Systeme gilt, dass die theo-
retische Konvergenzrate mit der Zunahme innerer Iterationen q nicht sinkt. Selbst diese - aus
praktischer Sicht wenig verwertbare Aussage - ist nicht auf den singula¨ren Fall u¨bertragbar, wie
das Gegenbeispiel 5.7 zeigt. Zuvor wird im Bsp. 5.6 das Gegenbeispiel konstruiert.
Beispiel 5.6 (Konstruktion einer hierarchischen BJAC -JAC Iteration) .
Ausgehend von der Generatormatrix
−Q =




λ −λ 0 0
−µ λ+ µ −λ
0 −µ λ+ µ −λ
0 0 −µ µ




,
vgl. Bsp. 3.5, einem a¨ußeren BJAC-Splitting Q = M−N mit
M =




λ −λ 0 0
−µ λ+ µ 0 0
0 0 λ+ µ −λ
0 0 −µ µ




,N =




0 0 0 0
0 0 λ 0
0 µ 0 0
0 0 0 0




und einem inneren JAC-Splitting M = F−G mit
F =




λ 0 0 0
0 λ+ µ 0 0
0 0 λ+ µ 0
0 0 0 µ




,G =




0 λ 0 0
µ 0 0 0
0 0 0 λ
0 0 µ 0




,G · F−1
︸ ︷︷ ︸
, H
=












0 λλ+ µ 0 0
µ
λ 0 0 0
0 0 0 λµ
0 0 µλ+ µ 0












.
liefert Gl. 4.15 die Iterations-Operatoren T1,T2 (1 bzw. 2 innere Iterationsschritte) mit
T1 =












0 λλ+ µ 0 0
µ
λ 0
λ
λ+ µ 0
0 µλ+ µ 0
λ
µ
0 0 µλ+ µ 0












,T2













µ
λ+ µ 0 0 0
0 µλ+ µ
λ
λ+ µ
λ2
(λ+ µ)µ
µ2
(λ+ µ)λ
µ
λ+ µ
λ
λ+ µ 0
0 0 0 λλ+ µ













.
Es ist leicht zu verifizieren, dass M−1 ≥ 0, N ≥ 0, F−1 ≥ 0 und H ≥ 0 gilt (a¨ußeres und
inneres Splitting ist regula¨r). T1 hat keine positiven Diagonaleintra¨ge (verletzt hinreichende Be-
dingung c in Proposition 5.5). Eine innere JAC Iteration mit Relaxation (JOR) erzeugt positive
Diagonaleintra¨ge im modifizierten Iterationsoperator
Hω = (1− ω)I + ωH.
43
Wie bereits oben ausgefu¨hrt gibt es auf die Frage, welchen Einfluss q auf die theoretische Kon-
vergenzrate einer BJAC -JAC Iteration zur Lo¨sung eines singula¨ren Gleichungssystems x ·Q = 0
hat, keine allgemeingu¨ltige Antwort. In dieser Arbeit soll jedoch fu¨r das konkrete System aus
Bsp. 3.5 eine Antwort gegeben werden.
Beispiel 5.7 (Einfluss innerer Iterationen auf asymptotische Konvergenzrate) .
Untersuchungsgegenstand ist die BJAC-JAC-Iteration aus Bsp. 5.6. Es sei (willku¨rlich) µ = 1
und fu¨r ein festes aber beliebiges q betrachte man die Familie der Iterationsoperatoren Tq(λ) mit
λ > 0 (zur Interpretation von µ und λ vgl. Bsp. 3.5). Man kann nachrechnen, dass ρ(Tq(λ)) = 1
fu¨r alle zula¨ssigen λ und µ ist (vgl. Bsp. 5.2), so dass die asymptotische Konvergenzrate R∞
durch die Magnitude γ(Tq(λ)) bestimmt wird. Zwischen der Magnitude und q bzw. λ existiert
fu¨r q = 1, 2, 3, 4 und λ > 0 eine analytische Beziehung14:
q = 1 2 3 4
γ(Tq(λ)) =
√
λ
λ+ 1 max
( 1
λ+ 1 ,
λ
λ+ 1
) λ2 + λ+ 1
λ2 + 2λ+ 1 max
( λ2
λ2 + 2λ+ 1 ,
2 · λ
λ2 + 2λ+ 1
)
Die Abb. 5.2 zeigt die asymptotische Konvergenzrate R∞(Tq(λ)) in Abha¨ngigkeit von λ fu¨r
q = 1, 2, 3, 4. Der Abbildung ist zu entnehmen, dass mit Zunahme von q nicht zwangsla¨ufig R∞
q=1
q=2
q=3
q=4
Legend
0.1
0.2
0.3
0.4
0.5
0.6
0.7
AS
YM
PT
O
TI
C_
CO
NV
ER
G
EN
CE
_R
AT
E
0.5 1 1.5 2 2.5 3 3.5 4
LAMBDA
Abbildung 5.2: Asymptotische Konvergenzrate R∞(Tq(λ))
steigt. Im Einzelnen gilt:
14Mit z.B. MapleTM ko¨nnen aufwendige “ha¨ndische” Berechnungen umgangen werden. Fu¨r q > 4 werden die
Ausdru¨cke sehr groß.
44
λ ∈ (0, 1);λ ∈ (1, 2.15) : R∞(T4(λ)) > R∞(T1(λ)) > R∞(T2(λ)) > R∞(T3(λ))
λ = 1 : R∞(T4(λ)) = R∞(T1(λ)) = R∞(T2(λ)) > R∞(T3(λ))
λ ∈ (2.15,∞) : R∞(T1(λ)) > R∞(T4(λ)) > R∞(T2(λ)) > R∞(T3(λ))
Beispielsweise liefert q = 1 (in realer Implementierung sehr preiswert) eine relativ gute (theore-
tische) Konvergenzrate (fu¨r λ ∈ (2.15,∞) relativ am besten), wa¨hrend q = 3 relativ am schlech-
testen abschneidet (fu¨r alle λ).
5.2.3 Stochastisches asynchrones Szenario
In Erga¨nzung zum Szenarien-Begriff fu¨r hierarchische Iterationen kann auch ein Szenario asyn-
chroner Iterationen definiert werden. Die Szenario-Definition und die grundlegenden Anforde-
rungen an asynchrone Iterationen aus Bedingung 4.7 helfen wiederum Konvergenzresultate zu
strukturieren.
Definition 5.8 (Szenario asynchrone Iteration) .
Das Szenario einer asynchronen Iteration ist durch die variable Auswahl zu iterierender Kom-
ponenten modelliert durch zeitdiskrete stochastische Ketten (“Aktualisierungsmengen”)
{It | t ∈ N ∧ I t ⊆ Z0 ∧ It 6= ∅ }
und durch den variablen Ru¨ckgriff auf historische Iterationsvektoren modelliert durch zeitdiskrete
stochastische Ketten (“Verzo¨gerungen”), die nachfolgend in Matrizen subsummiert sind
{Dt | t ∈ N ∧ Dt ,



τ11 (t) . . . τN1 (t)
... . . . ...
τ1N (t) . . . τNN (t)


 ∈ NN×N ∧ ∀t : 0 ≤ τ rs (t) ≤ t}
definiert.
Die Konvergenzanalyse asynchroner Iterationen geht auf Pionierarbeiten von Chazan und Mi-
ranker [38] und Baudet [9] aus den Jahren 1969 bzw. 1978 zuru¨ck.
Chazan und Miranker: Chazan und Miranker [38] haben gezeigt, dass ein kontrahierender
synchroner Iterationoperator ρ(T) < 1 fu¨r ein nicht-singula¨res System notwendig und hinrei-
chend fu¨r Konvergenz der asynchronen Iteration ist, wenn das Szenario die Eigenschaften 4.25,
4.26 und |I t| = 1 (nur eine Komponente wird je Schritt aktualisiert) erfu¨llt.
Baudet: Baudet [9] setzt ebenfalls ρ(T) < 1 voraus, verallgemeinert aber das Chazan-Miranker-
Modell, indem I t frei wa¨hlbar ist und die Bedingung 4.25 durch die schwa¨chere Bedingung 4.24
ersetzt wird. Allerdings mu¨ssen alle Komponenten r, r′, die im Schritt t aktualisiert werden
(r, r′ ∈ It), eine identische “lokale Sicht” auf den Iterationsvektor haben (pir(t) = pir′(t)), d.h.
τ r1 (t) = τ r
′
1 (t) . . . τ rN (t) = τ r
′
N (t). Baudet ermittelt eine untere Schranke fu¨r die asymptotische
Konvergenzrate asynchroner Iterationen aus den Level-Mengen der synchronen Iteration
X(k) , {x : ‖x− pi‖ ≤ ‖x− pi(0)‖ ρ(T )k }.
Die untere Schranke ha¨ngt von ρ(T ) und damit von der asymptotischen Konvergenzrate der
synchronen Iteration ab. Baudet konstruiert aus Trajektorien der asynchronen Iteration Teilfol-
gen (“Baudet-Folgen”) asynchroner Iterationsvektoren, deren Schritte bzgl. obiger Level-Mengen
45
einen “messbaren” Fortschritt in Richtung der Lo¨sung garantieren. Es ist wichtig zu betonen,
dass die Trajektorie - “modelliert” durch die Belegungen der D t und It - im Detail beru¨cksichtigt
wird. Eine aggregierte Sicht auf Trajektorien, wie sie zum Beispiel die Asynchronita¨tskonstante
B darstellt, ist nicht ausreichend. Die Notwendigkeit, einen detaillierten Einblick in den Ablauf
der asynchronen Iteration zu erlangen, hat Casanova [35] motiviert, durch eine stochastische
Modellierung des Szenarios die (implizite) Trajektorie zu ermitteln.
Bertsekas und Tsitsiklis: Bertsekas und Tsitsiklis untersuchen asynchron-iterative Verfah-
ren in einem breiten Anwendungskontext [19]. In Erweiterung zu Baudet erlauben ihre Mo-
delle asynchroner Iterationen unabha¨ngige bzw. individuelle “lokale Sichten” (fu¨r r, r′ ∈ It ist
τ r1 (t) 6= τ r
′
1 (t)) . . . erlaubt). Aus der Vielzahl ihrer Ergebnisse seien nachfolgend 4 mit Verweis
auf die Stellen in [19] zitiert:
1. Analytischer Zusammenhang zwischen Asynchronita¨t und theoretischer asyn-
chroner Konvergenzrate ([19], Abschnitt 1.4.2): Fu¨r eine Klasse von 2 × 2 Matrizen
wird der Einfluss der Asynchronita¨t auf die Konvergenzrate untersucht (wegen kleiner Di-
mension besteht ein analytischer Zusammenhang zwischen Szenario und Konvergenzrate).
Die Asynchronita¨t ist auf die τ rs (t) Variablen beschra¨nkt, d.h. in jedem Schritt werden alle
Komponenten aktualisiert (I t = Z0 fu¨r alle t). Dieser Spezialfall, der auch in [14, 84] be-
trachtet wird, hat die interessante Eigenschaft, dass aufgrund der Konstruktion des expan-
dierten Iterationsoperators TIt,Dt sein Spektralradius nicht steigt, d.h. ρ(TIt,Dt) ≤ ρ(T)
gilt (Eintra¨ge aus T werden in Abha¨ngigkeit von Werten der τ rs (t) Variablen in TIt,Dt
“verteilt” und der Rest mit Nullen aufgefu¨llt).
2. Relation synchrone und asynchrone theoretische Konvergenzrate ([19], Abschnit-
te 6.1 und 6.2): Ein zula¨ssiges Szenario und ρ(T) < 1 sind hinreichend fu¨r asynchrone Kon-
vergenz bzgl. einer (gewichteten) Maximumnorm15. Wenn das Szenario reguliert ist, kann
analog zu Baudet eine untere Schranke fu¨r die theoretische asynchrone Konvergenzrate
in Abha¨ngigkeit von der theoretischen synchronen Konvergenzrate angegeben werden. Die
theoretische asynchrone Konvergenzrate kann im Vergleich zum synchronen Gegenstu¨ck
um den Faktor 2 · B schlechter sein, d.h. asynchrone Iterationen ko¨nnen im Vergleich
zu synchronen Iteration in einem Maße ineffektiver sein, das direkt vom Grad der Asyn-
chronita¨t B abha¨ngt. Es ist wichtig zu betonen, dass sich die theoretische asynchrone
Konvergenzrate verschlechtern kann, aber nicht muss. In den oben zitierten Arbeiten sind
Beispiele angefu¨hrt, in denen die theoretische asynchrone Konvergenzrate im Vergleich
zum synchronen Gegenstu¨ck besser ist. Es ist auch wichtig anzumerken, dass alle Aus-
sagen nur auf theoretische Konvergenzraten zutreffen, die lediglich eine untere Schranke
bzw. Abscha¨tzung (asymptotische Konvergenzrate) fu¨r die tatsa¨chliche Anzahl notwen-
diger Iterationsschritte liefern. Es bleibt anzumerken, dass ρ(T) = 1 die hinreichenden
Bedingungen dieser Konvergenzuntersuchungen nicht erfu¨llt, weil ein synchroner Schritt
“theoretisch” keinen Fortschritt in Richtung der Lo¨sung erzielt.
3. Synchrone n-Schritt Konvergenz (Spektralradius=1) ([19], Abschnitt 7.2) Fu¨r syn-
chrone Iterationen mit ρ(T) = 1 und der Eigenschaft nach (spa¨testens) n = dimT Schrit-
15Ein zula¨ssiges Szenario heißt hier totale Asynchronita¨t (Annahme 6.1.1), ρ(T) < 1 erfu¨llt die “Synchrone
Konvergenzbedingung mit geschachtelten Level-Mengen” (Annahme 6.2.1.a) und die Maximumnorm erfu¨llt die
“Box-Bedingung” (Annahme 6.2.1.b). Damit ist nach Proposition 6.2.1 Konvergenz garantiert.
46
ten einen Fortschritt in Richtung der Lo¨sung zu erzielen, verlangsamt sich die theoretische
asynchrone Konvergenzrate ebenfalls um den Faktor 2 · B16. Bertsekas und Tsitsiklis ge-
ben mehrere Charakterisierungen und Beispiele fu¨r synchrone n-Schritt Konvergenz. Lei-
der sind die Ergebnisse hier nur bedingt verwertbar, weil die Schranken (synchroner und
asynchroner Fall) von der Problemgro¨ße n (hier sehr groß) abha¨ngen.
4. Stochastischer, irreduzibler und aperiodischer synchroner Iterations-Operator
([19], Abschnitt 7.3) Fu¨r den Spezialfall einer stochastischen, irreduziblen und aperiodi-
schen Matrix T mit ρ(T) = 1 ist geometrische Konvergenz garantiert und der (vom Szena-
rio abha¨ngige) Grenzwert limt→∞ pi(t) kann nach oben und unten abgescha¨tzt werden, vgl.
auch die Originalarbeit hierzu von Lubachevsky und Mitra [76] unten. Die Anwendbarkeit
dieses Ergebnisses ist durch starke Annahmen bzgl. T limitiert. Fu¨r eine Power-Iteration
gilt, dass die Annahmen bzgl. T erfu¨llt sind, sofern die (zeitkontinuierliche) Markov-Kette
irreduzibel und ergodisch ist, fu¨r komplexere Iterationen (z.B. BJAC ) gilt dies aber nicht.
Lubachevsky und Mitra: Lubachevsky und Mitra fu¨hren in [76] einen Konvergenzbeweis
fu¨r nicht-negative und irreduzible Iterationsoperatoren T mit ρ(T) = 1 unter der Annahme eines
regulierten Szenarios und Bedingung 4.28. Ihre Hauptaussage ist, dass die Distanzfunktion
d(pi(t)) , max
0≤τ≤B
max
1≤i≤n
pii(t− τ)
pii
− min
0≤τ≤B
min
1≤i≤n
pii(t− τ)
pii
(5.3)
fu¨r t → ∞ geometrisch gegen 0 konvergiert und dass ein c ∈ R (ha¨ngt vom Szenario ab) mit
limt→∞ pi(t) = c · pi existiert. Die Distanzfunktion d basiert nicht auf einzelnen pi(t) Vektoren,
sondern auf einer Folge B aufeinanderfolgender Iterationsvektoren (vgl. a¨ußere Maximum- bzw.
Minimumbildung) - eine “Unscha¨rfe”, die durch die Asynchronita¨t verursacht ist. Zum anderen
basiert die Distanzfunktion auf einer projektiven (Pseudo)-Metrik, vgl. Abb. 5.3.
Lubachevsky und Mitra benutzen die Level-Mengen
X(k) = {x : d(x) ≤ C · (1− σr)k }.
C ist eine Konstante, die (analytisch) von der Lo¨sung pi und vom Startvektor pi(0) abha¨ngt,
σ < 1 ist eine Konstante, die (analytisch) von pi und T abha¨ngt und r , 1+D+(n−1)(S+D)
ist ebenfalls konstant (Definition von D und S vgl. 4.25 und 4.27). Es wird gezeigt, dass die
Folge asynchroner Iterationsvektoren spa¨testens nach r Schritten einen Level-Mengen-U¨bergang
vollzieht, also einen messbaren Fortschritt in Richtung der Lo¨sung erzielt, d.h. es ist
pi(t) ∈ X(k) ∀ t ≥ k · r.
Mit Zunahme der Asynchronita¨t (=Zunahme von D und S) erho¨ht sich r , 1+D+(n−1)(S+D)
- die Anzahl von Schritten, die notwendig ist um einen Level-Mengen-U¨bergang zu vollziehen.
Gleichzeitig steigt die obere Schranke C · (1−σr)k der Distanzfunktion d, d.h. die obere Schran-
ke fu¨r den messbaren Fortschritt hin zur Lo¨sung, der durch den Level-Mengen-U¨bergang erzielt
wird. Im Vergleich zu Baudet [9] nutzt man hier eine aggregierte Sicht auf das Szenario der
asynchronen Iteration (r-Konstante) und betrachtet nicht unmittelbar deren Trajektorie. Die
r-Konstante beeinflußt hier die Konstruktion der Level-Mengen und der Teilfolge, wa¨hrend bei
16Obwohl die Aussage intuitiv erscheint, ist der formale Beweis in Proposition 7.2.3 recht lang.
47
G1
G2
x
S
1.0
y
1.0
0.4
0.6
Abbildung 5.3: Veranschaulichung der projektiven Norm aus [76] in R2. Es sei pi =
(0.6, 0.4) die stationa¨re Verteilung. Die Geraden G1 oder G2 sind alle Punkte, die bzgl. der
projektiven Norm aus [76] den Abstand 0.25 von pi haben, d.h. es ist G1 ∪ G2 = { (x, y) >
(0, 0) |max
( x
0.6 ,
y
0.4
)
− min
( x
0.6 ,
y
0.4
)
= 0.25 }. Im Vergleich dazu ist die Strecke S die Menge
normierter Punkte, deren Abstand von pi bzgl. der Maximum-Norm ≤ 0.25 ist, d.h. es ist
S = { (x, y) |x + y = 1 ∧max (|x− 0.6|, |y − 0.4|) ≤ 0.25 }.
Baudet Level-Mengen ga¨nzlich unabha¨ngig vom Szenario definiert werden. Bei Baudet werden
Level-Mengen u¨ber Spektralradien definiert und man scha¨tzt die relative Verzo¨gerung der asyn-
chronen Iteration im Vergleich zur synchronen Iteration ab. Bei Lubachevsky und Mitra fließen
Eigenschaften des synchronen Iterationsoperators T lediglich u¨ber σ ein, eine Konstante die
aus T vergleichsweise einfach berechenbar ist. Das Lubachevsky-Mitra Resultat ist in seiner
praktischen Anwendbarkeit durch 3 Faktoren limitiert: alle Abscha¨tzungen benutzen die unbe-
kannte Lo¨sung pi, in die Abscha¨tzung fließt die Problemgro¨ße n ein und die Annahmen bzgl. des
synchronen Iterations-Operators (irreduzibel) sind sehr stark. Beispielsweise ist der synchrone
Iterations-Operator einer hierarchischen BJAC -JAC Iteration mit zwei inneren Iterationen T2
(Bsp. 5.6) nicht irreduzibel.
Beidas et al, Strikwerda: stochastische Konvergenzanalyse Beidas und Papavassilo-
poulos [14] und Strikwerda [92] sind Referenzen fu¨r stochastische Konvergenzanalysen asynchro-
ner Iterationen. Dem Ansatz in [14] liegen folgende Annahmen zugrunde: 1. die Asynchronita¨t
ist auf die τ rs (t) Variablen beschra¨nkt (I t = Z0 fu¨r alle t) 2. es gilt Annahme 4.25 und 3.
die zeitdiskreten stochastischen Ketten τ¯ rs (t) , t− τ rs (t) (mit Zustandsraum {1, 2, . . . , D}) sind
Markov-Ketten und voneinander unabha¨ngig. Zur Konvergenzanalyse werden die N 2 vielen zeit-
diskreten Markov-Ketten als eine einzelne zeitdiskrete Markov-Kette {T (t)} interpretiert. Ihr
Zustandsraum ist wegen der Unabha¨ngigkeit gleich dem Kreuzprodukt der τ¯ rs Zustandsra¨ume
und ihre Zustandsu¨bergangswahrscheinlichkeiten das Kronecker-Produkt der Matrizen der Zu-
standsu¨bergangswahrscheinlichkeiten der τ¯ rs -Ketten (wird als gegeben angenommen). Es wird
gezeigt, dass jeder der D · N 2 Zusta¨nde der großen Markov-Kette {T (t)} mit einem explizit
definierbaren “expandierten” Iterationsoperator ∈ Rn·D×n·D korrespondiert, der aus dem syn-
chronen Iterationsoperator T ∈ Rn×n generierbar ist. Es sei Tt der “Zustand” ( , “expandierter”
Iterationsoperator ∈ Rn·D×n·D) der großen Markov-Kette T im Schritt t. Somit erha¨lt man eine
48
stochastische nicht-stationa¨re Iteration
p˜i(t+ 1) = p˜i(t) ·Tt,
in der eine zeitdiskrete Markov-Kette {T (t)} durch ihre Trajektorie die Auswahl des Iterations-
operators Tt “moduliert”.
Moga, Dubois: Experimentelle Konvergenzanalyse Moga und Dubois [84] untersuchen
experimentell den Einfluss der Asynchronita¨t auf die Anzahl notwendiger Iterationsschritte bis
zum Erreichen einer Genauigkeitsschranke. Hierbei betrachten sie eine Menge konvergenter syn-
chroner Iterations-Operatoren T ∈ R2×2 und untersuchen fu¨r jeden einzelnen Operator T den
Einfluss der Asynchronita¨t.
Eine Monte-Carlo Simulation stochastischer Variablen fu¨r Rechen- und Kommunikationszeiten
emuliert eine Ausfu¨hrung der asynchronen Iteration und erzeugt so eine Belegung der Variablen
des asynchronen Szenarios, vgl. Def. 5.8. Hierbei emulieren sie die bekannten Typen asynchro-
ner Iterationen: 1. Asynchronita¨t ist auf Dt beschra¨nkt, 2. Asynchronita¨t ist auf I t beschra¨nkt.
Jedes Szenario definiert eine Folge asynchroner Iterations-Operatoren und somit eine vom Start-
vektor ausgehende Trajektorie von Iterationsvektoren. Fu¨r einen einzelnen synchronen Operator
T ∈ R2×2 werden 100 Szenarien emuliert/simuliert und die mittlere La¨nge der Trajektorien bis
zum Erreichen der Genauigkeitsschranke ermittelt. Diese La¨nge wird mit der deterministischen
Anzahl synchroner Iterationsschritte bis zum Erreichen der Genauigkeitsschranke ins Verha¨lt-
nis gesetzt (=asynchroner Speed-Up). Wenn die Asynchronita¨t auf I t beschra¨nkt ist, stellen
sie fest, dass der asynchrone Speed-Up u¨ber dem betrachteten Definitionsbereich ⊂ R2×2 mit
5162 = 266 256 Matrizen fu¨r eine hohe Anzahl der Matrizen kleiner als 1 ist, also eine asynchrone
Ausfu¨hrung keine Beschleunigung erzielt. Sie beobachten aber auch einen Kulminationspunkt, in
dem der Speed-Up sehr hoch wird und der durch Spektraleigenschaften erkla¨rbar ist (dominan-
ter Eigenwert ist negativ, deswegen oszilliert die synchrone Iteration und konvergiert langsam;
eine asynchrone Ausfu¨hrung verbessert die Spektraleigenschaften).
5.2.4 Diskussion
Die Tab. 5.2.4 stellt zusammenfassend Konvergenzresultate fu¨r hierarchische und asynchrone
Iterationen aus der Literatur mit Referenzen in U¨bersichtsform dar. Ein Iterations-Operator mit
Spektralradius 1 (ρ(T) = 1) verweist auf den hier relevanten Fall: die Lo¨sung eines singula¨ren
Gleichungssystems.
Die Intention mathematischer Modelle fu¨r Fixpunkt-Iteration ist die Ableitung von Konvergenz-
resultaten. Hierbei wird u¨berpru¨ft, inwieweit Struktureigenschaften der Koeffizientenmatrix Q
in Abha¨ngigkeit von der Auswahl des Splittings Q = M −N auf T u¨bertragbar und dann fu¨r
die Bewertung der Konvergenz(rate) nu¨tzlich sind. Hierbei treten zwei Zielkonflikte auf. Der
erste Zielkonflikt ist die Ausdrucksma¨chtigkeit von Splittings, um Eigenschaften der Iteration
(hierarchisch, asynchron) zu erfassen versus der analytischen Handhabbarkeit der resultierenden
generischen Klassen von Iterations-Operatoren. Der zweite Zielkonflikt sind schwache Annah-
men bezu¨glich der Koeffizientenmatrix versus ableitbarer Aussagen zum Iterations-Operator.
Bedingt durch diese Zielkonflikte sind Konvergenzaussagen fu¨r kombiniert asynchrone und hier-
archische Iterationen (= komplexes Splitting bzw. Iterations-Operator) angewendet auf singula¨re
Gleichungssysteme (schwache Annahme bzgl. Koeffizientenmatrix) schwierig.
49
Konvergenz Konvergenzrate
ρ(T) = 1 ρ(T) < 1 ρ(T) = 1 ρ(T) < 1
Iteration Ref Ref Ref Ref
asynchron ⊕ [76, 19, 94] ⊕ [9, 19, 38],[14, 92]2  [76] [19]1 ⊕ [9, 19]1
hierarchisch ⊕ [82] ⊕ [73, 95] 	  [73, 95]1
asy. + hier. ⊕ [7, 93] ⊕ [21, 62] 	 	
Tabelle 5.2: ⊕=”bekannt”; =unter Einschra¨nkungen bekannt bzw. Aussagen schwach;
	=unbekannt; 1theoretische asynchrone Konvergenrate relativ zur theoretischen synchronen
Konvergenzrate; 2stochastische Konvergenzanalyse;
5.3 Parallele Rechnerarchitektur und Programmmodell
Die Abbildung 5.4 skizziert das lokale Rechnernetz am Lehrstuhl Informatik 4, Universita¨t Dort-
mund, das als Laufzeitumgebung fu¨r ASYNC genutzt wird. Das Rechnernetz besteht aus 3
Teilen: zwei Rechner-Cluster (“Compute-Server”) und eine typische IT-Arbeitsumgebung beste-
hend aus heterogenen Arbeitsplatzrechnern, 10 bzw. 100 MBit Ethernet-Verbindungen, File-,
Web- und Print-Servern und sonstiger Peripherie. Die Rechner-Cluster sind fu¨r rechen- und
kommunikationsintensive Anwendungen konzipiert und mit 1 GBit Switches und leistungsfa¨hi-
gen Einzelrechnern (4× SUN Fire V20 mit AMD Opteron Prozessoren, 64 bit, 2.4 GHz, 6 GB
RAM und 6× Xeon Doppelprozessoren, 32 bit, 3.06 GHz, 6 GB RAM) ausgestattet.
1  G B i t  S w i t c h 1  G B i t  S w i t c h1 0 / 1 0 0  M B i t E t h e r n e t / S w i t c h
Abbildung 5.4: Lokales Netzwerk als Rechenressource
Eine verteilte oder parallele Lo¨sung eines Berechnungsproblems erfordert, Teilprobleme (=Last)
zu identifizieren und den Teilproblemen verfu¨gbare Rechenressourcen zuzuordnen (= Last-
verteilung). In ASYNC ist das Berechnungsproblem die Ausfu¨hrung blockorientierter Jacobi
(BJAC ) Iterationsschritte. Die Ausfu¨hrung erfordert die Lo¨sung nicht-homogener Gleichungssy-
steme, die hier die Teilprobleme darstellen, vgl. Gl. 5.1. Die verfu¨gbaren Rechenressourcen seien
formal durch die Indexmenge P = {1, . . . , P} repra¨sentiert. Die Lastverteilung R sei eine Abbil-
dung von P auf disjunkte Teilmengen von Z0 , {1, . . . , N}, der Indexmenge der Teilprobleme.
Definition 5.9 (Lastverteilung) .
50
Die Lastverteilung R ist definiert durch
R(p) = {c | Prozess p ∈ P berechnet pi[c]}
R−1(c) = {p ∈ P | Prozess p berechnet pi[c]}
In ASYNC ha¨lt jeder Prozess p “seine” Komponenten des Iterationsvektors pi [r] (r ∈ R(p))
fu¨r andere Prozesse nicht zugreifbar im lokalen Speicher, vgl. Abb. 5.5 links. Des Weiteren ha¨lt
jeder Prozess eine Kopie der gesamten Generatormatrix im lokalen Arbeitsspeicher. Dies wird
durch die sehr platzeffiziente Datenstruktur der Generatormatrix ermo¨glicht, vgl. Abschnitt 3.2.
Zur Aktualisierung des anteiligen Iterationsvektors (=Iterationsschritt) wird die aktuelle Version
desselben und Daten aus dem Kommunikationspuffer (alles im lokalen Speicher) gelesen. Der
Kommunikationspuffer gewa¨hrleistet eine asynchrone, von der Verfu¨gbarkeit kommunizierter
Daten unabha¨ngige Iteration. Der Inhalt des Kommunikationspuffers wird durch kollaborierende
Prozesse in unregelma¨ßigen Absta¨nden (Asynchronita¨t) aktualisiert. Die Kommunikation basiert
auf asynchronen Sende- und Empfangsroutinen (Message-Passing Paradigma), vgl. Abschnitte
5.6.2 und 5.6.3. Das Berechnungsmodell ist vom Typ Single-Program Multiple-Data, weil
jeder Worker -Prozess das gleiche Programm ausfu¨hrt, aber auf unterschiedlichen Daten (=
Komponenten des Iterationsvektors) rechnet.
i t e r a t e pi [ 1 ]l o c a l  m e m o r y
I t e r - S t e p
i t e r a t e pi [ 2 ]
l o c a l  m e m o r y
I t e r - S t e p
s e n d
s e n dr e c v
r e c v
M e s s a g e - P a s s i n gp r o c e s s 1 c o m m u n i c a t i o n p r o c e s s 2
b u f f e r pi [ 2 ]Q b u f f e r pi [ 1 ]Q
M a s t e r  P r o c e s s
W o r k e r  P r o c e s s  1 W o r k e r  P r o c e s s  P
A g g - S o l v e rA g g - S o l v e r
v e c t o r p [  ]
d a e m o n d a e m o n
Abbildung 5.5: Links: ASYNC Berechnungsmodell; Rechts: Prozess-Typen
Worker -Prozesse realisieren die verteilte, numerische Berechnung, vgl. Abb. 5.5 rechts. Der Ma-
ster -Prozess verantwortet koordinierende und steuerende Funktionen, die eine globale Sicht auf
den Zustand der Berechnung erfordern. Daemon-Prozesse wickeln die Prozess-Kommunikation
ab, hier wesentlich die Kommunikation zwischen Worker -Prozessen. Daru¨ber hinaus realisiert
ein Agg-Solver -Prozess “on-the-fly” Aggregierungsschritte, d.h. Iterationsschritte in einem nie-
derdimensionalen Lo¨sungsraum.
5.4 Algorithmisches Modell
Mit der LastverteilungR (Def. 5.9) kann fu¨r die Gl. 5.1 ein grundlegendes algorithmisches Modell
zur verteilten Ausfu¨hrung von BJAC -Schritten abgeleitet werden. Das algorithmische ASYNC -
51
1. for all p′ ∈ P do in parallel
2. choose c ∈ R(p′)
3. solve pi[c] ·Q[c, c] = b[c]
Abbildung 5.6: ASYNC algorithmischer Rahmen: Block-Jacobi Iteration
Geru¨st in Abb. 5.6 beinhaltet 3 verschachtelte iterative Prozesse und realisiert eine hierarchi-
sche Iteration. Es wird zwischen einer Inter-Block-Iteration (kurz Block-Iteration) und einer
Intra-Block-Iteration unterschieden. Weil die Anzahl der Blo¨cke oft die Anzahl der verfu¨gba-
ren Rechenressourcen u¨bersteigt (|Z0| > |P|) und einzelne Prozesse fu¨r die Iteration mehre-
rer Komponenten des Iterationsvektors verantwortlich sind, kann die Block-Iteration in eine
Inter-Prozess-Iteration und eine Intra-Prozess-Iteration unterteilt werden. Diese Unterteilungen
sind in der Abb. 5.7 veranschaulicht. Auf oberster, Inter-Prozess-Ebene realisiert ASYNC ei-
[1]
[2]
[3]
[4]
Prozess 1
Prozess 2
Inter-Prozess
Iteration/Komm.
(Block-Jacobi)
Intra-Block
Iteration
(JOR etc.)
Iteration
Intra-Prozess
(Block-GS)
Abbildung 5.7: Die Hierarchie der Iterationsprozesse in ASYNC
ne verteilte, asynchrone BJAC Iteration. Auf mittlerer, Intra-Prozess-Ebene ko¨nnen Bereiche
des Iterationsvektors in lokale Blo¨cke strukturiert sein. Wenn die Blo¨cke in Zeile 2 des algo-
rithmischen Modells 5.6 in gleichbleibender Reihenfolge gewa¨hlt werden, realisiert ASYNC eine
Block-Gauss-Seidel (BGS ) Iteration, weil die im lokalen Speicher verfu¨gbaren Komponenten des
Iterationsvektors natu¨rlich ohne kommunikationsbedingte Verzo¨gerungen in Berechnungen ein-
fließen. Die unterste, Intra-Block Iteration resultiert aus der Gro¨ße der Blo¨cke, die eine direkte
Lo¨sung verbietet und eine iterative Lo¨sung (z.B. JOR, SOR) erzwingt. Die Intra-Block-Iteration
ist im Algorithmus 5.6 der 3. Zeile zuzuordnen. In Spezialfa¨llen ko¨nnen einzelne Ebenen kolla-
bieren, z.B. wenn nur eine Rechenressource verfu¨gbar ist (oberste Ebene), jeder Rechenprozess
nur einen Block iteriert (mittlere Ebene) und jeder Block einelementig ist (unterste Ebene).
Die Blockgro¨ße ist durch die Modellstruktur bestimmt, zu Skalaren degenerierte Blo¨cke treten
praktisch nie auf.
Die Rechenprozesse mu¨ssen Daten (Vektoren) austauschen, weil Datenabha¨ngigkeiten bestehen,
die sich in den rechten Seiten b[c] des Gleichungssystems ausdru¨cken. Die rechten Seiten b[c]
sind aggregierte Sichten auf den Kontext der Berechnung von pi [c]. Die Datenabha¨ngigkeit ist
52
hinsichtlich der Datenproduzenten pra¨zisierbar:
b[c] = −
∑
p∈P
bp[c] mit b
p
[c] =
∑
r∈R(p)
r 6=c
pi[r] ·Q[r, c] (5.4)
Der additive Beitrag bp[c] fu¨r b[c] wird per Definition durch den Datenproduzenten p erbracht,
weil Prozess p fu¨r die Berechnung der pi[r] mit r ∈ R(p) verantwortlich ist, vgl. Def. 5.4.
ASYNC ermo¨glicht zu Testzwecken zwischen Varianten der algorithmischen Ausfu¨hrung und
deren Implementierung zu wa¨hlen. Die Auswahl wird im C-Source-Code mit Pra¨prozessor-
Direktiven #define bzw. #undef gesteuert und bleibt zur Laufzeit konstant. Zur Laufzeit wird le-
diglich u¨berpru¨ft, ob die gewa¨hlte C-Source-Code Auspra¨gung zula¨ssig ist. Die Varianten ko¨nnen
wie folgt kategorisiert werden:
• Semantik kommunizierter Vektoren: ASYNC ermo¨glicht wahlweise Teile des Iterati-
onsvektors oder additive Beitra¨ge fu¨r die rechten Seiten der lokal zu lo¨senden Gleichungs-
systeme zu verschicken, vgl. Abschnitt 5.4.1.
• Varianten asynchroner Iterationen: ASYNC implementiert verschiedene Modellva-
rianten asynchroner Iterationen. Die Varianten werden im Abschnitt 5.4.2 erla¨utert und
spa¨ter experimentell untersucht, vgl. Abschnitte 6.1.3 “Asynchronita¨t und Lo¨sungszeit”
und 6.1.4 “Totale vs. Partielle Asynchronita¨t”.
• Selektive Iteration: ASYNC implementiert mehrere Kriterien fu¨r die Auswahlreihenfol-
ge der zu iterierenden Komponenten des Iterationsvektors, vgl. Abschnitt 5.4.3
• Steuerung der Kommunikation: ASYNC implementiert eine bedarfgesteuerte Kom-
munikation, vgl. Abschnitt 5.4.4.
• Steuerung von Kontrollausgaben: ASYNC erzeugt diverse Kontrollausgaben in frei
wa¨hlbarem Umfang auf dem Bildschirm oder fu¨r eine spa¨tere Weiterverarbeitung in Da-
teien. Insbesondere wichtig sind Trace-Dateien, die Informationen zum Laufzeitverhalten
sammeln, vgl. Abschnitt 6.1.
• Realisierung Kommunikation und Kommunikationspuffer: ASYNC nutzt ein Kom-
munikations-Interface, das auf die speziellen Bedu¨rfnisse der verteilten numerischen Be-
rechnung abstellt. Dieses Interface implementiert “Message-Passing”-Funktionalita¨ten, die
wahlweise durch die Kommunikationstools PVM oder MPI angeboten werden. Des Wei-
teren implementiert ASYNC mehrere Kommunikations-Puffer Auspra¨gungen, vgl. Ab-
schnitt 5.6.3.
Nachfolgend werden Varianten na¨her betrachtet, die einen engen Bezug zum mathematischen
Modell haben und festlegen, was, wann, wie berechnet und kommuniziert wird.
5.4.1 Semantik kommunizierter Vektoren
In ASYNC werden wahlweise Vekoren vom Typ bp[c] oder pi[r] kommuniziert. Ein Datenpro-
duzent p kann mittels Vektor-Matrix-Multiplikationen Vektoren bp[c] berechnen und verschicken,
oder alternativ seine in bp[c] enthaltenen Komponenten pi[r] des Iterationsvektors verschicken, vgl.
53
Prozess p: Prozess p:
for all c ∈ Z0 for all c ∈ R(p)
if bp[c] 6= 0 then send b
p
[c] to R−1(c) for all p′ ∈ P\{p}
if ∑
r∈R(p′)
Q[c, r] 6= 0 then send pi[c] to p′
Tabelle 5.3: Variante 1 (links): Datenproduzent p verschickt additiven Beitrag bp[c] fu¨r b[c] an
R−1(c); Variante 2 (rechts): Datenproduzent p verschickt “seinen” Iterationsvektor pi [c] an
alle Konsumenten p′
Tab. 5.3. Die Berechnung der Lastverteilung unterstu¨tzt beide Semantiken kommunizierter Da-
ten und man kann fallbedingt entscheiden, welche Typen von Vektoren zu kommunizieren sind.
Ein mo¨gliches Auswahlkriterium hierfu¨r ist die Ho¨he des Kommunikationsaufwands. Ein weiteres
Auswahlkriterium ist die Frage, ob der Rechenaufwand der Vektor-Matrix-Multiplikationen pro-
duzentenseitig (Variante 1) oder konsumentenseitig (Variante 2) anzusiedeln ist. Fu¨r asynchrone,
entkoppelte Berechnungen ist die Variante 2 effektiver, weil sie u¨berflu¨ssige Berechnungen beim
Produzenten vermeidet. In entkoppelten Berechnungen - wie sie in ASYNC auftreten - kann der
Fall eintreten, dass Vektoren bp[c] berechnet und verschickt werden, ohne dass ein Konsument
sie zwischenzeitlich gelesen und benutzt hat. Die Variante 2 ist nur mit potentiell u¨berflu¨ssi-
ger Kommunikation behaftet, die bei Bedarf (geringe Bandbreite im Kommunikationsmedium)
durch ein “Demand-Driven Messaging” Protokoll (Def. 5.10) vermieden werden kann.
5.4.2 Varianten asynchroner Iterationen
Im Abschnitt 6.1.3 wird der Einfluss von Asynchronita¨t auf Lo¨sungszeiten experimentell un-
tersucht. In Vorbereitung dafu¨r werden an dieser Stelle Varianten schwach-asynchroner Itera-
tionen definiert, vgl. Tab. 5.4. Das Laufzeitverhalten dieser Implementierungs-Varianten wird
dann spa¨ter experimentell untersucht. Alle nutzen Sende-Befehle mit asynchroner Semantik
Variante 1: Variante 2: Variante 3:
repeat repeat repeat
for all c ∈ R(p′) for all c ∈ R(p′) barrier sync
sync b[c] sync b[c] for all c ∈ R(p′)
for all c ∈ R(p′) solve pi[c] ·Q[c, c] = b[c] solve pi[c] ·Q[c, c] = b[c]
solve pi[c] ·Q[c, c] = b[c] asy send pi[c] asy send pi[c]
for all c ∈ R(p′) until convergence until convergence
asy send pi[c]
until convergence
Tabelle 5.4: Schwach-asynchrone Iterationen und ihre Implementierungen (Worker -Prozess p ′)
(asy send), kommunizieren Vektoren vom pi [c]-Typ, nicht vom bp[c]-Typ (vgl. “Semantik kom-
munizierter Vektoren” oben), und lo¨sen ihnen zugeordnete Teilprobleme (solve).
54
Im Pseudo-Code der Worker -Prozesse aus Tab. 5.4 sind keine Befehle zum Datenempfang ein-
gefu¨gt! Es wird angenommen, dass der Datenempfang durch einen separaten “Message-Handler”
realisiert wird. Deswegen mu¨ssen Worker -Prozesse nicht aktiv am Empfang partizipieren und
Empfangsbefehle aufrufen, vgl. Abschnitt 5.6.3. Mit Ausnahme des “sync”-Befehls sind alle
Befehle in dem Sinne atomar, dass Daten, die wa¨hrend ihrer Ausfu¨hrung empfangen werden,
keinen Einfluss auf die Ausfu¨hrung ausu¨ben und erst nach Befehlsende wirksam werden.
Variante 1: Die Variante 1 realisiert eine probabilistische Gauss-Seidel Iteration. In der Imple-
mentierung sind Synchronisations-, Rechen- und Datenversandphase strikt separiert, d.h. jeder
Prozess erreicht zuerst eine Synchronisationsphase, danach lo¨st er die ihm zugeordneten Pro-
bleme “solve pi[c] · Q[c, c] = b[c]” und versendet neu berechnete Vektoren “asy send pi [c]”.
Der Befehl “sync b[c]” realisiert eine abgeschwa¨chte Synchronisation. Der Befehl “sync b[c]”
blockiert bis alle zu b[c] beitragenden pi[·]-Vektoren aus dem aktuellen oder (=Freiheitsgrad bzw.
probabilistischer Einfluss) aus dem vorherigen Iterationsschritt stammen (,Iteration vom Grad
1). Die schwache Asynchronita¨t dieser Variante resultiert aus diesem Freiheitsgrad.
Die strikte Separierung der bedingten Synchronisationsphase und der Rechenphase ist eine nach-
teilige Implementierung, weil zu kommunizierende Daten ggf. “im Vorlauf” synchronisiert wer-
den, ohne dass sie zu diesem Zeitpunkt bereits beno¨tigt werden. Die nachfolgende Variante 2
behebt dieses Defizit. Trotzdem soll in den Messexperimenten im Abschnitt 6.1.3 auch diese -
offensichtlich nachteilige - Variante 1 betrachtet werden, um ihren Nachteil auch in Messexperi-
menten zu belegen.
Variante 2: Die Variante 2 realisiert ebenfalls eine probabilistische Gauss-Seidel Iteration.
In der Implementierung wird jedes Teilproblem c individuell synchronisiert, gelo¨st und das Er-
gebnis verschickt. Dies ist im Vergleich zu Variante 1 vorteilhaft, weil Synchronisationen, die
auf der Aktualita¨t kommunizierter Daten basieren, zeitna¨her an der Nutzung kommunizierter
Daten eingefu¨gt sind. Die Einbettung des Datenversands in lokale Rechenphasen bewirkt eine
gleichma¨ßige Belastung der Kommunikationsressourcen.
Variante 3: Gema¨ß der Eigenschaften einer Gauss-Seidel Iteration werden in Variante 1 und
2 die Komponenten des Iterationsvektors synchron iteriert und Komponenten, die in die Ak-
tualisierung anderer Komponenten einfließen, enstammen dem aktuellen oder vorherigen Itera-
tionsschritt (Iteration vom Grad 1).
In der Variante 3 wird die 2. Bedingung gelockert und eine Iteration vom Grad ∞ zugelassen.
Der Synchronisationspunkt barrier sync blockiert bis alle Prozesse diese Stelle im Source-Code
erreicht und den Befehl aufgerufen haben. Der Synchronisationspunkt gewa¨hrleistet, dass alle
Komponenten des Iterationsvektors mit der selben Rate iteriert werden. Die Beschra¨nkung der
Asynchronita¨t auf die Kommunikationsverzo¨gerungen wird zum Beispiel in [19, 14, 84] betrach-
tet, vgl. auch Abschnitt 4.4.
Die Variante 3 ohne den barrier sync-Synchronisationspunkt ist eine vollsta¨ndig asynchrone
Iteration.
Partielle Asynchronita¨t In der Bedingung 4.7 (Seite 36) ist partielle Asynchronita¨t definiert
basierend auf Aktualisierungsmengen (jede Komponente des Iterationsvektors wird innerhalb
55
von S Schritten mindestens einmal aktualisiert) und basierend auf der “Aktualita¨t” beitra-
gender Komponenten (die Differenz zwischen aktuellem Iterationsschritt und dem beitragender
historischer Komponenten ist durch D beschra¨nkt). In einer Implementierung, in der die parti-
elle Asynchronita¨t des 1.Typs gesteuert werden soll, muss die Information u¨ber die historische
Reihenfolge aktualisierter Komponenten global zugreifbar sein. Wenn beispielsweise eine Kom-
ponente nicht in den letzten S − 1 Schritten aktualisiert wurde, muss die Aktualisierung aller
anderen Komponenten blockiert werden, bis die betreffende Komponente aktualisiert ist. In einer
Architektur mit verteiltem Speicher ist eine korrekte Ermittlung der Reihenfolge lokaler Ereig-
nisse schwierig und es wa¨re ein hoher Koordinationsaufwand no¨tig um sicherzustellen, dass alle
Worker -Prozesse Zugriff auf die gleiche und aktuelle Reihenfolge aktualisierter Komponenten
besitzen (Zugriff ist notwendig um ggf. Komponenten von der Aktualisierung auszuschließen).
Deswegen wird die partielle Asynchronita¨t des 1.Typs in ASYNC nicht unterstu¨tzt. Demge-
genu¨ber wird die partielle Asynchronita¨t des 2.Typs in ASYNC unterstu¨tzt. Vektoren werden
zusammen mit dem Iterationsschritt, in dem sie beim Produzenten berechnet wurden, verschickt.
Der Konsument kann so leicht entscheiden, ob eine lokale Iteration erlaubt ist, oder ob ein wei-
terer Schritt eine maximal erlaubte Iterationsschrittdifferenz u¨berschreiten wu¨rde und deswegen
auf die Aktualisierung der Vektoren im Kommunikationspuffer gewartet werden muss.
5.4.3 Selektive Iteration
Die asynchrone Kommunikation und die Pufferung kommunizierter Daten beim Datenkonsu-
menten entkoppeln lokale Berechnungen und ermo¨glichen erst eine asynchrone Iteration. Die
Entkopplung von Datenproduzenten und -konsumenten innerhalb asynchroner Iterationen flexi-
bilisiert die lokale Auswahl zu lo¨sender Teilprobleme. Die lokale Auswahl wird im algorithmischen
Modell fu¨r ASYNC in Abb. 5.6 durch Zeile 2 repra¨sentiert. Weil die Anzahl der Blo¨cke in der
Generatormatrix gewo¨hnlich die Anzahl verfu¨gbarer Rechenprozesse u¨bersteigt, ist jeder Rechen-
prozess p′ fu¨r die Berechnung mehrerer Teilprobleme aus R(p′) verantwortlich und muss inner-
halb der BJAC -Blockiteration sukzessive Auswahlentscheidungen treffen (choose-Anweisung).
Neben einer vorab definierten statischen Auswahlreihenfolge ko¨nnen auch dynamische Auswahl-
reihenfolgen benutzt werden, die Iterationsschrittdifferenzen zwischen den Teilproblemen, den
Aktualisierungsgrad der in die Lo¨sung lokaler Teilprobleme einfließenden Daten oder die bereits
erzielte Genauigkeit der Lo¨sungen dieser Teilprobleme beru¨cksichtigen. Alle Kriterien sind Heu-
ristiken fu¨r gutes Konvergenzverhalten. Die Beschra¨nkung von Iterationsschrittdifferenzen und
die Adaption von Datenzugriffsraten und -mustern basierend auf dem Aktualisierungsgrad ein-
fließender Daten machen asynchrone Iterationen effektiver, weil lokale Berechnungen auf “alten”
bzw. mehrfach genutzten Vektoren vermieden werden. Diese Form der Selbststeuerung intendiert
“synchronisierte” Ausfu¨hrungen asynchroner Iterationen. Die Adaption der Berechnung an der
bereits erzielten Gu¨te der Teillo¨sungen zielt darauf ab, mehr Rechenkapazita¨t fu¨r Teilprobleme
aufzuwenden, die globale Konvergenz sto¨ren, also den “numerischen Flaschenhals” darstellen.
Die Auswahlkriterien sind im Modul CONTROL implementiert, vgl. Abschnitt 5.6.1.
5.4.4 Steuerung der Kommunikation
Die Semantik des asynchronen Iterierens hat den Vorteil, dass Datenproduzenten und -kon-
sumenten nicht synchronisieren (keine Wartezeiten) und flexibel (selektiv) lokale Iterationen
ausfu¨hren. Die Aufhebung von Synchronisationspunkten in der Kommunikation hat weitreichen-
56
de Konsequenzen fu¨r die verteilte Berechnung. Datenproduzenten (Sender) ko¨nnen entkoppelt
von der Bereitschaft der Datenkonsumenten (Empfa¨nger) Daten propagieren. Dies ist einer-
seits vorteilhaft, weil ungenutzte Rechenzeiten beim Produzenten und Konsumenten vermieden
werden. Andererseits birgt es die Gefahr einer nicht an die Bedarfe der Konsumenten adap-
tierten Datenpropagation. Wenn die Kommunikationsrate die konsumentenseitige Bedarfsrate
u¨bersteigt, mu¨ssen entweder viele nichtempfangene Nachrichten gepuffert werden oder nichtemp-
fangene Nachrichten werden ungelesen u¨berschrieben (=ineffiziente Nutzung der Kommunikati-
onsressourcen). Im umgekehrten Fall versucht ein Konsument oft vergeblich Daten zu empfangen
und ist gezwungen, die Zeit bis zur Verfu¨gbarkeit mehr oder weniger sinnvoll zu u¨berbru¨cken.
Ein Lo¨sungsansatz ist, den Datenfluss durch einfache Regelkreise zu steuern, indem Konsumen-
ten nach Verwendung kommunizierter Daten einen Aktualisierungsbedarf beim Produzenten
anzeigen. Der Konsument steuert somit die Rate, mit der Daten zwischen Produzent und Kon-
sument transferiert werden. Diese einfache Form eines selbststeuernden Regelkreises wird durch
2 Protokolle realisiert.
Definition 5.10 (Demand/Supply Driven Messaging) .
Das Demand Driven Messaging (DDM) Protokoll steuert die Kommunikation aus der Sicht
der Datenkonsumenten. Wenn ein Konsument aktualisierte Daten aus “seinem” Kommunika-
tionspuffer liest, signalisiert er Aktualisierungsbedarf und verschickt eine Anforderung an den
Produzenten. Bei erneutem Zugriff ohne zwischenzeitliche Aktualisierung wird keine weitere An-
forderung initiiert. Das DDM-Protokoll stellt sicher, dass alle kommunizierten Daten in die
Iteration einfließen.
Das DDM-Protokoll kann durch ein Supply Driven Messaging (SDM) sinnvoll erga¨nzt wer-
den, dessen wesentliche Funktion es ist, den wiederholten Versand duplizierter oder “a¨hnlicher”
Daten zu vermeiden und die Reaktionszeit des Produzenten auf Bedarfanzeigen der Konsumen-
ten (siehe DDM) zu verku¨rzen. Nach Empfang einer Bedarfsanzeige vom Konsumenten wird
u¨berpru¨ft, ob die angeforderten Daten seit der letzten Bedarfsanzeige “ausreichend” modifi-
ziert wurden. Im Fall der Kommunikation der bp[c]-Vektoren ist die Anzahl der aktualisierten
pi[·]-Vektoren, die in bp[c] aufsummiert einfließen, ein Grad der Modifikation, vgl. Tab. 5.3 und
Gl. 5.4.
Komponenten des Iterationsvektors, fu¨r die eine Bedarfsanzeige anliegt, ko¨nnen in der selektiven
Iteration (Abschnitt 5.4.3) ho¨her gewichtet werden. Weil Produzenten auch gleichzeitig Konsu-
menten sind, kann bei der Reaktion auf Bedarfsanzeigen der Konflikt auftreten, dass die fu¨r die
Aktualisierung der angefragten Komponente beno¨tigten Daten aus dem Kommunikationspuffer
nicht hinreichend aktuell sind.
Die Methodik in ASYNC dient der Analyse logistischer Systeme. Umgekehrt weist ASYNC
gewisse Analogien zu logistischen Systemen auf. Die asynchrone Kommunikation und asyn-
chrone Iteration arbeitet wie ein logistisches System, in dem Daten produziert (Beschaffung),
verschickt (Transport) und konsumiert (Produktion) werden und in dem Datenkommunika-
tion durch ein dezentrales Steuersystem mit selbststeuernden Regelkreisen (a¨hnlich Kanban-
Fertigungssteuerung) u¨berwacht wird. Im Gegensatz zu Materialflussystemen, in denen die Re-
gelkreise kettenfo¨rmig und Akteure entweder als Produzent oder Konsument agieren, sind hier
die Regelkreise in einen zusammenha¨ngenden Graphen eingebettet und alle Worker -Prozesse
(Akteure) sind gleichzeitig Konsument und Produzent.
57
5.5 Lastverteilung und Kommunikationsaufwand
Bisher wurde eine Lastverteilung R (Def. 5.9) als gegeben angenommen. In diesem Abschnitt
wird nun die Berechnung der Lastverteilung betrachtet. Eine notwendige Bedingung fu¨r gutes
Laufzeitverhalten ist eine effektive (optimale) Lastverteilung, in der eingesetzte Rechenressour-
cen gleichma¨ßig und das Kommunkationsmedium mo¨glichst gering beansprucht werden.
Eine Lastverteilung ist formal die Zuordnung von Teilproblemen aus Z 0 (vgl. Gl. 5.1) zu den
verfu¨gbaren Rechenressourcen aus P. In der durch ASYNC realisierten hierarchischen BJAC -
Iteration ist der Rechenaufwand je Teilproblem durch die Anzahl der Eintra¨ge in den Haupt-
diagonalblo¨cken Q[c, c] determiniert (Notation: nz(Q[c, c])). Der Aufwand zur Kommunikation
eines Vektors pi[·] ist proportional zu dessen Gro¨ße dim pi[·]. Diese quantitative Bewertung kann
durch einen knoten- und kantengewichteten Graphen formal notiert werden. Knoten repra¨sen-
tieren Teilprobleme und Kanten deren Abha¨ngigkeiten. Bei den Kantengewichten (= Kommuni-
kationsaufwand) ist eine Fallunterscheidung hinsichtlich der Semantik kommunizierter Vektoren
notwendig.
Definition 5.11 (Rechenaufwand und -abha¨ngigkeiten) .
Es sei G = (V,E) ein knoten- und kantengewichteter, gerichteter Graph mit
i) V = {1, . . . , N} und Gewicht w(c) = nz(Q[c, c]) fu¨r alle c ∈ V
ii) E = {(r, c) |Q[r, c] 6= 0} mit Gewicht w(r, c) =
{
dim pi[c] Variante 1, vgl. Tab.5.3
dim pi[r] Variante 2, vgl. Tab.5.3
Dabei ist Q[c, c] der c-te Hauptdiagonalblock der Generatormatrix Q, nz(Q[c, c]) die Anzahl der
Eintra¨ge ungleich von Null in Q[c, c] und dim pi [·] die Dimension bzw. Gro¨ße des Teilvektors
pi[·].
Eine Partitionierung des Graphen durch Gruppierung von Knoten in Partitionen repra¨sentiert
eine Lastverteilung. Alle Knoten einer Partition werden von einer Rechenressource bearbeitet.
Die Partitionierung von Graphen unter Nebenbedingungen (gleichma¨ßige Verteilung der Knoten-
gewichte auf Partitionen, Minimierung der Summe der Gewichte von Inter-Partition-Kanten) ist
NP-vollsta¨ndig. In ASYNC sind mit Chaco 2.0 [68] und ParMETIS 17 zwei Tools eingebunden,
die eine Vielzahl heuristischer und graphen-theoretischer Partitionierungsansa¨tze fu¨r knoten-
und kantengewichtete Graphen anbieten. Die Verfahren agieren auf der durch die hierarchische
Kronecker-Struktur bereits vorgegebenen Partitionierung. Dadurch ist die Problemgro¨ße von der
Große des Zustandsraums n (Gro¨ßenordnung 105 − 107) auf die Anzahl der Makrozusta¨nde N
(Gro¨ßenordnung 10 − 103) reduziert. Die vorgegebene Partitionierung stellt bereits eine gute
Dekomposition des Berechnungsproblems dar, sie muss hier lediglich vergro¨bert werden, weil N
gewo¨hnlich die Anzahl der Rechenressourcen u¨bersteigt.
Die Anzahl der Partitionen (= Anzahl der Prozesse) und die Gewichtung der Knotensummen
einzelner Partitionen (= Rechenlast je Prozess) sind Aufrufparameter von Chaco 2.0 und ParME-
TIS. Weil Chaco 2.0 und ParMETIS nur auf ungerichteten Graphen operieren, wird G in einen
ungerichteten Graphen G∗ = (V ∗, E∗) transformiert. Es sei V ∗ = V und E∗ == {{r, c} | (r, c) ∈
E ∨ (c, r) ∈ E} mit w({r, c}) = δrc ·w(r, c) + δcr ·w(c, r). Die Verfahren aus Chaco 2.0 und Par-
METIS konstruieren heuristisch Partitionen, in denen die Anzahl der Kanten (=msg∗) bzw. die
17http://www-users.cs.umn.edu/ karypis/metis/parmetis/index.html
58
Summe der Gewichte von Kanten (=data∗) zwischen Partitionen minimiert wird und die Neben-
bedingung der Balanziertheit eingehalten wird. msg∗ stimmt nicht mit der tatsa¨chlichen Anzahl
von Nachrichten msg u¨berein, weil im ungerichteten Graphen zwei reflexiv gerichtete Kanten
durch eine einzelne ungerichtete Kante ersetzt sind und weil nicht alle ungerichteten Kanten
zwischen Partitionen separate Nachrichten induzieren (Vektoren werden aufsummiert verschickt
(Variante 1) oder ein Vektor fließt in die Berechnung mehrerer Teilprobleme eines Konsumenten
ein (Variante 2). Ebenso verha¨lt es sich mit data∗ und data. Die Partitionierung des Graphen
bzw. die Lastverteilung schafft eine Datenlokalita¨t, in der nicht jede Datenabha¨ngigkeit auch
eine Kommunikation erfordert. Die Techniken aus Chaco 2.0 und ParMETIS beruhen auf der
Annahme, dass Intra-Partition Kanten genau die Datenabha¨ngigkeiten repra¨sentieren, die keine
Kommunikation induzieren. Sie ko¨nnen jedoch nicht beru¨cksichtigen, dass Inter-Partition Kan-
ten zusammengefasst werden ko¨nnen, wenn sie die Kommunikation ein und desselben Vektors
pi[c] repra¨sentieren.
Wie der tatsa¨chliche Kommunikationsaufwand (Anzahl Nachrichten und Datenvolumen je ver-
teiltem BJAC -Schritt) fu¨r eine gegebene Lastverteilung R berechnet wird, ist in der Prop. 5.12
erla¨utert.
Proposition 5.12 (Ermittlung Kommunikationsaufwand) .
Es sei δrc eine Indikatorfunktion mit
δrc ,
{
1 falls Q[r, c] 6= 0
0 sonst.
Es sei msg die Anzahl von Nachrichten je verteiltem BJAC-Schritt. Es gilt:
msg =
∑
c∈Z0
∑
p∈P
δp[c] mit δ
p
[c] ,



0 falls c ∈ R(p)
1− ∏
r∈R(p)
(1− δrc) sonst.
Die Definition von δp[c] garantiert, dass
δp[c] = 1 ⇐⇒ b
p
[c] 6= 0 ∧ c /∈ R(p)
gilt, d.h. δp[c] zeigt genau die Datenabha¨ngigkeiten an, die eine Kommunikation induzieren. Die
Doppelsumme u¨ber der Indexmenge der Teilprobleme Z0 und der involvierten Rechenprozesse P
erfasst alle potentiell auftretenden Datenabha¨ngigkeiten.
Es sei data das durch einen verteilten BJAC-Schritt generierte Datenvolumen. Es gilt:
data =
∑
c∈Z0
∑
p∈P
δp[c] · dim pi[c].
Ein Block Q[r, c] mit Q[r, c] 6= 0, r 6= c und R−1(r) 6= R−1(c) induziert eine Kommunikation,
deren Gro¨ße proportional zu dim pi[r] · Q[r, c] = dim pi[c] ist. Deswegen ist im Graphen aus
Def. 5.11 das Gewicht einer Kante (r, c), die eine Datenabha¨ngigkeit durch Q[r, c] repra¨sentiert,
durch dim pi[c] quantifiziert.
Abschließend soll die Anwendbarkeit und Qualita¨t der durch Chaco 2.0 und ParMETIS er-
mittelten Lastverteilungen untersucht werden. ParMETIS realisiert eine verteilte Variante des
59
Multi-Level-KL Verfahrens, das auch in Chaco 2.0 verfu¨gbar ist. Das Multi-Level-KL Verfahren
aus Chaco 2.0 ist robust, andere Verfahren erzeugen oft Laufzeitfehler oder variieren proble-
mabha¨ngig stark in ihrer Laufzeit. Die Tab. 5.5 dokumentiert die Qualita¨t der Lastverteilungen,
die durch ParMETIS und Chaco 2.0 fu¨r das Markov-Ketten Modell der Stu¨ckgutumschlaghalle
mit den Parameterbelegungen k = 4 . . . 7 berechnet wurden, vgl. Abschnitt 3.4. Die Qualita¨t der
Ergebnisse ist nahezu gleich, weil in ParMETIS und Chaco 2.0 ein Multi-Level-KL Verfahren
angewandt wird, wobei auch Abweichungen auftreten, z.B. fu¨r (P = 6, k = 4), (P = 6, k = 5)
und (P = 8, k = 5). Die Laufzeiten betragen ca. 20 Sekunden (k=4), ca. 100 Sekunden (k=5,
Chaco 2.0) und ca. 70 Sekunden (k=5,ParMETIS mit 2 Rechenprozessen).
k=4 (n=30 690 750) k=5 (n=122 189 237)
Chaco 2.0 ParMETIS Chaco 2.0 ParMETIS
P msg data msg data msg data msg data
2 68 130.8 67 131.3 132 517.6 132 517.6
4 137 261.8 137 256.6 266 1033.0 271 1032.5
6 185 349.9 164 317.1 356 1367.0 285 1158.9
8 208 407.1 205 398.1 396 1541.1 443 1773.9
10 222 430.3 225 429.2 443 1724.2 424 1717.5
k=6 (n=423 807 404) k=7 (n=1 313 059 781)
Chaco 2.0 ParMETIS Chaco 2.0 ParMETIS
P msg data msg data msg data msg data
2 181 1439.3 199 1564.2 318 4416.6 297 4431.6
4 316 2612.0 359 2904.8 586 8448.7 511 7789.5
6 1) 1) 580 4354.8 855 12677.9 1126 15135.4
8 606 4801.9 567 4586.8 969 14408.1 885 13161.3
10 1) 1) 665 5269.0 1189 17427.7 1202 17260.7
Tabelle 5.5: SUH1-Modell: Lastverteilungen fu¨r P=Prozesse (k=Modellparameter; msg=Anzahl
Nachrichten synchroner BJAC -Schritt; data=Datenvolumen [MB] synchroner BJAC -Schritt;)
1) Chaco 2.0 endet fehlerhaft
Die Tab. 5.6 beinhaltet die mit Chaco 2.0 erzielte Qualita¨t der Lastverteilungen fu¨r das FMS-
Modell. Im nachfolgenden Bsp. 5.13 wird fu¨r das FMS-Modell (k = 10) gezeigt, wie eine kon-
k=5 (n=152 712) k=10 (n=25 397 658) k=15 (n=724 284 864)
P msg data msg data msg data
2 6 1.2 10 152.6 14 3875.0
4 10 1.6 29 409.1 42 11615.1
6 14 1.9 37 483.9 68 17985.1
Tabelle 5.6: FMS-Modell: Lastverteilungen fu¨r P=Prozesse (k=Modellparameter; msg=Anzahl
Nachrichten synchroner BJAC -Schritt; data=Datenvolumen [MB] synchroner BJAC -Schritt;)
krete Lastverteilung Kommunikationsabha¨ngigkeiten induziert. Auf dieses Beispiel wird in Ab-
schnitt 6.1.3 zuru¨ckgegriffen.
60
Beispiel 5.13 (FMS-Modell: Datenabha¨ngigkeiten, Lastverteilung, Kommunikation) .
Das FMS-Modell hat fu¨r k = 10 (Modellparameter) N = 11 Makrozusta¨nde. Die Abb. 5.8
links zeigt Datenabha¨ngigkeiten (=), die potentiell bei der verteilten Ausfu¨hrung von BJAC-
Iterationsschritten auftreten. Das Chaco 2.0 Tool berechnet fu¨r P = {1, 2} (2 Prozesse) folgende
Lastverteilung
R(1) = {1, 2, 3, 4, 5, 6, 7, 8, 9} und R(2) = {0, 10},
vgl. Def. 5.9 zur Lastverteilung. Basierend auf der Lastverteilung R sind in Abb. 5.8 rechts Da-
tenabha¨ngigkeiten in Intra- (?) und Inter-Prozess-Abha¨ngigkeiten unterteilt. Letztere induzieren
Kommunikation zwischen den Prozessen und sind nummeriert. Wenn die Semantik kommuni-
zierter Daten “Variante 2” ist (Abschnitt 5.4.1), induziert die verteilte Ausfu¨hrung eines BJAC-
Iterationsschritts 10 Nachrichten (pi [1], . . . ,pi[10]). Blo¨cke mit identischer Nummer induzieren
eine einzelne Nachricht. Der mit den 10 Nachrichten verbundene Kommunikationsaufwand ist
(8 Byte je double-Eintrag):
8Byte ·
10∑
i=1
dimpi[x] = 8Byte · 19 999 122 = 152.6MB.
0 1 2 3 4 5 6 7 8 9 10
0  
1           
2           
3          
4         
5        
6       
7      
8     
9    
10   
2 1 1 1 1 1 1 1 1 1 2
2 ? ?
1 1 ? ? ? ? ? ? ? ? ? 1
1 2 ? ? ? ? ? ? ? ? ? 2
1 3 ? ? ? ? ? ? ? ? 3
1 4 ? ? ? ? ? ? ? 4
1 5 ? ? ? ? ? ? 5
1 6 ? ? ? ? ? 6
1 7 ? ? ? ? 7
1 8 ? ? ? 8
1 9 ? ? 9
2 10 ?
Abbildung 5.8: Links: Datenabha¨ngigkeiten zwischen Blo¨cken (); Lastverteilung mit Intra- (?)
und Inter-Process-Kommunikation (1 . . . 10 verweisen auf Nachrichten) fu¨r das FMS Modell mit
k = 10
5.6 Implementierungsaspekte
5.6.1 Software-Entwurf
Der C-Quellcode der ASYNC -Implementierung ist in 8 Module unterteilt, vgl. Tab. 5.7. Die
Aufrufschnittstellen einzelner C-Funktionen sind in [60] dokumentiert.
LOAD Die wesentliche Funktionalita¨t des Moduls ist die Berechnung und Bewertung der
initialen Lastverteilung, vgl. Abschnitt 5.5. Das Modul greift auf die externen Tools Chaco 2.0,
ParMETIS und APNN-Toolbox zu, siehe unten.
61
Modul Funktionalita¨t
LOAD Berechnung und Bewertung der initialen Lastverteilung
MAIN Konfiguration der verteilten Applikation und Ergebnisaufbereitung
MASTER Master-Prozess: U¨berwachung und Steuerung der verteilten Applikation
WORKER Worker-Prozess: verteilte Ausfu¨hrung der numerischen Berechnung
BUF Puffer-Management fu¨r asynchrone Kommunikation
COM Schnittstelle Kommunikations (Prozess-Konfiguration, Message-Passing, etc)
CONTROL U¨berwachung, Steuerung und Protokollierung von Kommunikation und Iteration
AGGSOLVE Aggregierungs-Disaggregierungsschritte
Tabelle 5.7: Module des Software-Entwurfs im U¨berblick
MAIN Das Modul beinhaltet das eigentliche Hauptprogramm, das den Master -Prozess an-
steuert und das Ergebnis der Berechnung - die stationa¨re Verteilung - fu¨r eine spa¨tere Weiter-
verarbeitung in einer Datei speichert.
MASTER Der Master -Prozess erfu¨llt administrative und koordinierende Funktionen, die ei-
ne globale Sicht auf den Zustand der Berechnung und der verteilten Applikation erfordern. Der
Master -Prozess instanziiert die Worker -Prozesse (s.u.) und versendet Steuerparameter an diese.
Er erfasst das globale Konvergenzverhalten wa¨hrend der Berechnung, lo¨st ‘on-the-fly’ Aggre-
gierungsschritte aus und sorgt fu¨r eine sichere Terminierung der verteilten Applikation. Das
MASTER-Modul benutzt die Module COM und AGGSOLVE und greift auf die APNN-Toolbox zu.
WORKER Die Worker-Prozesse implementieren die in Kapitel 4 vorgestellten mathemati-
schen Modelle hierarchischer und asynchroner Iterationen. Das WORKER-Modul benutzt die Mo-
dule BUFFER, COM und CONTROL und greift auf die APNN-Toolbox zu.
BUF Das Modul realisiert eine Schnittstelle fu¨r die Verwaltung und den Zugriff auf einen
Datenpuffer, der kommunizierte Daten speichert. Die Zugriffsoperationen sind an die Bedu¨rfnis-
se der verteilten Berechnung angepasst und implementieren “Message-Passing”-Funktionen mit
blockierender und nicht-blockierender Semantik. Die Schnittstelle abstrahiert von der konkreten
(technischen) Realisation des Puffers und implementiert Varianten, die durch PVM bzw. MPI
unterstu¨tzt werden. Die gewu¨nschte Variante wird zur Laufzeit statisch ausgewa¨hlt. Im Ab-
schnitt 5.6.3 werden die Varianten im Detail erla¨utert. Das BUF-Modul benutzt das COM-Modul.
COM Das Modul realisiert eine Schnittstelle fu¨r Kommunikationsfunktionen, die auf die spe-
ziellen Bedu¨rfnisse von ASYNC angepasst ist. Die Schnittstelle besitzt Funktionen zur Instanzi-
ierung und Verwaltung von Prozessen und Funktionen zum asynchronen und synchronen Senden
und Empfangen ASYNC -spezifischer Datenobjekte. Die Schnittstelle abstrahiert vom tatsa¨chlich
eingesetzten Kommunikationstool (PVM oder MPI ) und implementiert Funktionen wahlweise
(via Compiler-Direktive) generisch durch PVM - oder MPI -Funktionen. Das zu implementie-
rende Kommunikationstool wird zum Zeitpunkt der Kompilierung ausgewa¨hlt. Das COM-Modul
benutzt PVM oder MPI.
CONTROL Das Modul unterstu¨tzt die Messung und Protokollierung des Laufzeitverhaltens
(Trajektorie der probabilistischen Ausfu¨hrung der Implementierung, Kommunikationszeiten und
62
-umfang) und des Konvergenzverhaltens der Iteration (lokale/globale Genauigkeit der Lo¨sung).
Protokollierte Daten ko¨nnen fu¨r eine ex-post-Analyse in Tabellen und Diagrammen (durch
gnuplot erzeugt) aufbereitet, in einen LaTex-basierten “Laufzeit-Bericht” integriert und via
SLOG-2-Traces visualisiert werden. Des Weiteren implementiert das Modul Auswahlkriterien fu¨r
die selektive asynchrone Iteration.
AGGSOLVE Das Modul spezifiziert einen Agg-Solver -Prozess, der “on-the-fly” Aggregie-
rungs- und Disaggregierungsschritte durchfu¨hrt. Hierfu¨r erha¨lt er von Worker -Prozessen nach
Aufforderung durch den Master -Prozess die Inhalte des aggregierten Systems, lo¨st das aggregier-
te System und schickt die aggregierte Lo¨sung an den Master -Prozess, der wiederum die Lo¨sung
selektiv (Steuerung) an die Worker -Prozesse verteilt.
5.6.2 Anbindung und Verwendung externer Software
ASYNC greift auf Funktionalita¨ten externer Software-Werkzeuge zu, vgl. Tab. 5.8.
Tool Funktionalita¨t Referenz
APNN-Toolbox Datenstruktur Generatormatrix [30]
Chaco 2.0 sequentielle Berechnung Lastverteilung [68]
ParMETIS parallele Berechnung Lastverteilung s.u.
PVM Kommunikationsroutinen (“Message-Passing”) [40, 51]
MPI Kommunikationsroutinen (“Message-Passing”) [40, 48]
Jump-Shot offline Trace-Visualisierung [37]
Tabelle 5.8: Von ASYNC benutzte Funktionalita¨ten externer Software-Werkzeuge
APNN-Toolbox 18 Das Werkzeug bietet einen Petri-Netz-Editor (GUI), funktionale Techni-
ken zur Petri-Netz-Analyse, zahlreiche Verfahren zur Exploration und Erzeugung des Zustands-
raums fu¨r zustandsraumbasierte Analysen, die Methodik fu¨r kompositionelle und hierarchische
Kronecker Datenstrukturen, die der Speicherung der Generatormatrix der Markov-Kette dienen,
und ein breites Spektrum numerischer Analyseverfahren fu¨r Markov-Ketten. Die Implementie-
rung des Editors geht auf C. Tepper zuru¨ck, P. Buchholz und P. Kemper haben die Methodik
der Petri-Netz- und Markov-Ketten Analyse implementiert. ASYNC ist in die APNN-Toolbox
eingebunden und von der graphischen Benutzeroberfla¨che aus aufrufbar, vgl. Abschnitt 7.4.
Chaco 2.0 und ParMETIS Beide Werkzeuge beinhalten Methoden zur Partitionierung
knoten- und kantengewichteter Graphen. Derartige Graphen werden hier zur Beschreibung des
Berechnungs- und Kommunikationsaufwands herangezogen, vgl. Abschnitt 5.5.
Chaco 2.0 verfu¨gt u¨ber ein breites Spektrum sequentieller Methoden. Das Werkzeug ermo¨glicht
es, 7 globale Methoden (verfeinern rekursiv bestehende Partitionen unter Verwendung verschie-
dener Heuristiken) mit 3 lokalen Methoden (lassen Anzahl der Partitionen invariant, aber versu-
chen durch vera¨nderte Zuordnungen einzelner Knoten zu Partitionen die Qualita¨t zu verbessern)
kombiniert anzuwenden. Mit dem Modul LOAD ko¨nnen alle Methoden angesteuert werden. Es
18http://www4.cs.uni-dortmund.de/APNN-TOOLBOX/
63
hat sich aber herausgestellt, dass Chaco 2.0 fu¨r große Graphen (≥ 100 Knoten bzw. Makro-
zusta¨nde der Generatormatrix) instabil ist (Laufzeitfehler) und die Laufzeit verfahrens- und
problemabha¨ngig stark variiert.
ParMETIS 19 implementiert eine verteilte (MPI -basierte) Variante des Multi-Level-KL Verfah-
rens.
PVM und MPI PVM 20 und MPI 21 sind Bibliotheken zur Unterstu¨tzung paralleler Pro-
grammierung, die in Forschung und Praxis weit verbreitet und in Kombination mit verschie-
denen Programmiersprachen (Fortran, C, JAVA) anwendbar sind. Die grundlegende Idee ist
es, eine hardware- und betriebssystemunabha¨ngige Kommunikationsschnittstelle zu etablieren
(sichert Portabilita¨t und Code-Wiederverwertbarkeit), die gebra¨uchliche Funktionalita¨ten der
parallelen Programmierung offeriert. Dies beinhaltet Instanziierung, Management und Verwal-
tung von Prozessen, Datenaustausch mit dem “Message-Passing”-Paradigma (expliziter Aufruf
von Sende- und Empfangsroutinen mit blockierender und nicht-blockierender Kommunikations-
semantik) und verschiedene Synchronisationskonzepte (Broadcast, Barrier, Synchronisation von
Prozessgruppen etc).
MPI II (Message-Passing-Interface) ist ein Standard, der durch gegenwa¨rtig verfu¨gbare MPI -
Distributionen unterstu¨tzt wird, die teilweise frei verfu¨gbar sind. Die Implementierungen unter-
liegen dem Zielkonflikt zwischen hoher Funktionalita¨t und Portabilita¨t. Frei verfu¨gbare Imple-
mentierungen wie zum Beispiel die hier verwendete LAM-MPI 7.0.3 Distribution unterstu¨tzen
ein breites Spektrum von Rechnerarchitekturen, aber nicht die komplette MPI II Funktionalita¨t.
Dies betrifft zum Beispiel die Kommunikationssemantik der “one-sided communication”, bei der
ein Datenproduzent in den Puffer des Konsumenten schreiben kann, ohne dass der Konsument an
der Kommunikation partizipiert, vgl. Abschnitt 5.6.3. Andererseits versuchen Rechnerhersteller
(SUN etc.) durch eigene MPI -Distributionen die Verbreitung ihrer Hardware in zukunftstra¨chti-
gen Anwendungsbereichen wie die des “Grid-Computing” und “Cluster-Computing” voranzu-
treiben, indem sie den MPI II Standard voll unterstu¨tzen, aber natu¨rlich keine Portabilita¨t in
konkurrierende Rechnersysteme zulassen22.
Jump-Shot Das Werkzeug bietet eine leistungsfa¨hige offline-Visualisierung und einfache sta-
tistische Auswertungen von SLOG-2 Traces, vgl. Abschnitt 6.1.
5.6.3 Asynchrone Kommunikation mit Puffer
Um die Abha¨ngigkeit der Datenkonsumenten von der Verfu¨gbarkeit kommunizierter Daten auf-
zuheben und ein asynchrones Voranschreiten der Berechnung zu ermo¨glichen, mu¨ssen zuletzt
empfangene Daten konsumentenseitig gespeichert werden. In ASYNC wird eine asynchrone Ite-
ration durch einen (verteilten) Datenpuffer realisiert. Seine Inhalte (=Vektoren) zeigen Daten-
abha¨ngigkeiten der verteilt ausgefu¨hrten Iteration an. Der Speicherplatz des Puffers ist der fu¨r
die asynchrone Ausfu¨hrung der Iteration erforderliche Mehraufwand.
19http://www-users.cs.umn.edu/ karypis/metis/parmetis/index.html
20http://www.csm.ornl.gov/pvm/pvm home.html
21http://www.mpi-forum.org
22http://www.lam-mpi.org/mpi/implementations/fulllist.php gibt einen guten U¨berblick zu existierenden
MPI-Implementierungen und den jeweiligen Funktionsumfang
64
Der Puffer wird durch das Modul BUF implementiert, vgl. Abschnitt 5.6.1. Die angebotene
Schnittstelle abstrahiert von den technischen Details der Puffer-Realisation. Die physikalische
Verteilung der Puffereintra¨ge im verteilten Speicher, die technische Realisation des Puffers und
die durch Zugriffoperationen (Write,Read) intern aufgerufenen “Message-Passing”-Funktionen
inklusive der Adressierung von Sendern und Empfa¨ngern bleiben der aufrufenden Instanz ver-
borgen. Das Modul unterscheidet 4 Varianten fu¨r die technische Realisation des Puffers, vgl.
Abb. 5.9.
Abbildung 5.9: Kommunikations-Puffer: Varianten der Implementierung
1. One-sided Communication (Active Messaging, Message Handler): Der Produzent
u¨berschreibt nicht-blockierend ausgewa¨hlte Inhalte des Datenpuffers beim Konsumenten,
ohne dass der Konsument an der Kommunikation partizipiert. Dies ist vorteilhaft in Si-
tuationen, in denen der Konsument nicht sta¨ndig die Verfu¨gbarkeit neuer Daten pru¨fen
kann und somit die Gefahr zahlreicher ha¨ngender Nachrichten (=gesendet, aber nicht
empfangen) besteht. Die Schwierigkeit ist, Dateninkonsistenz durch Vermeidung von Zu-
griffskonflikten zu gewa¨hrleisten. Zugriffskonflikte ko¨nnen prinzipiell auf Hardwareebene
(Schaltnetze), Betriebssystemebene und Applikationsebene gelo¨st werden. In PVM wird
der Konflikt pragmatisch gelo¨st. Eine ankommende Nachricht triggert einen “Message
Handler”. Dieser unterbricht die Ausfu¨hrung des Programms nicht und wird erst abge-
arbeitet, wenn das Programm einen PVM -Befehl aufruft und somit die Kontrolle beim
PVM -System liegt. Dieses Konzept hat sich in ASYNC sehr bewa¨hrt und wird vorran-
gig angewendet. Die Wartezeiten der “Message Handler” sind gering, weil im C-Quellcode
zahlreiche PVM Funktionsaufrufe plaziert sind. Der MPI II Standard unterstu¨tzt ver-
schiedene Semantiken der “one-sided communication” bzw. des “remote memory access”,
die Zugriffskonflikte durch unterschiedlich starke Synchronisationsmechanismen lo¨sen. Die
65
am wenigsten synchronisierte Variante (“passive target communication”) ist im Modul BUF
realisiert. Leider ist in der LAM-MPI Distribution die “passive target communication” via
MPI WIN LOCK und MPI WIN UNLOCK nicht implementiert, so dass die MPI II Auspra¨gung
dieser Variante nicht getestet werden konnte.
2. Datenbank in Daemon-Prozessen: Der Datenpuffer ist als Datenbank im Daemon-
Prozess (Abb. 5.5 rechts) des Konsumenten realisiert (wird ab PVM Version 3.4 un-
terstu¨tzt). Der Vorteil des Ansatzes liegt in der Trennung von Worker -Prozess (Berech-
nung) und Daemon-Prozess (Puffer-Management). Nachteilig sind wenig performante Zu-
griffszeiten, weil alle Daten durch “Message-Passing” zum Konsumenten transferiert wer-
den mu¨ssen (verteilter Speicher). MPI II unterstu¨tzt dieses Konzept nicht.
3. Message-Passing mit Kommunikations-Puffer: Die Variante bildet das “Message-
Passing”-Paradigma mit nicht-blockierenden Sende- und Empfangsroutinen unvera¨ndert
ab und erga¨nzt es durch einen konsumentenseitigen Datenpuffer. Wenn ein Konsument
Daten aus dem Datenpuffer liest, wird darin eingebettet u¨berpru¨ft, ob “ha¨ngende” Nach-
richten anliegen und ob Puffereintra¨ge durch diese aktualisiert werden ko¨nnen.
Der Nachteil dieser Variante ist, dass Konsumenten aktiv an der Kommunikation partizi-
pieren mu¨ssen und deswegen die Gefahr einer Ansammlung zahlreicher ha¨ngender Nach-
richten besteht. Die La¨nge der Warteschlange ha¨ngender Nachrichten ist bedingt durch
das unabha¨ngige Agieren der Produzenten und Konsumenten prinzipiell unbeschra¨nkt. In
der Praxis ist dies nachteilig und fu¨hrt zu hoher Speicherplatzanforderung in den Dae-
mon-Prozessen. PVM und MPI unterstu¨tzen diesen Modus.
4. Message-Passing ohne Kommunikations-Puffer: Diese Variante bildet ebenfalls das
“Message-Passing”-Paradigma ab, allerdings ohne Kommunikationspuffer. Konsumenten
rufen blockierende Empfangsroutinen auf, d.h. lokale Berechnungen schreiten synchro-
nisiert mit kommunizierten Daten voran und alle Datenabha¨ngigkeiten sind potentielle
Synchronisationspunkte. PVM und MPI unterstu¨tzen diesen Modus.
66
Kapitel 6
Messung und Modellierung der
Performance von ASYNC
Dieses Kapitel fokussiert auf die Messung und Modellierung der Performance von ASYNC.
Performance ist hier als Lo¨sungszeit bzw. Ausfu¨hrungszeit von ASYNC definiert und wird durch
die Anzahl notwendiger Iterationsschritte und die Zeit der einzelnen Iterationsschritte bestimmt.
Ein Messung der Lo¨sungszeit ist prinzipiell einfach. Um aber die Ursachen fu¨r schwankende
oder ggf. schlechte Lo¨sungszeiten zu finden, ist es notwendig, einen Einblick in den dynamischen
Ablauf der Berechnung und Kommunikation in ASYNC zu erhalten. Die Visualisierung von
Rechen- und Kommunikationsmustern kann hierbei sehr hilfreich sein.
Der Abschnitt 6.1 fu¨hrt in die Performance-Messung und -Visualisierung basierend auf Trace-
Files ein. Anschließend werden Performance-Engpa¨sse durch Messungen auf Netzwerkebene iden-
tifiziert. Zusa¨tzlich wird der Einfluss der Asynchronita¨t auf die Lo¨sungszeit anhand einer Mes-
sung auf der Ebene des ASYNC -Source-Codes bewertet. Danach wird die Qualita¨t der paralle-
len Berechnung mit etablierten Maßen (Beschleunigung bzw. Effizienz) evaluiert. Anhand sehr
großer Markov-Ketten-Modelle werden die Grenzen des ASYNC -Instrumentariums mit den zur
Verfu¨gung stehenden Rechen- und Kommunikationsressourcen aufgezeigt.
Der Abschnitt 6.2 behandelt die Performance-Modellierung von ASYNC unter Beru¨cksichtigung
von stochastischen Modellen fu¨r die zeitliche Bewertung synchroner und asynchroner Iterations-
schritte im Zusammenspiel mit bekannten Konvergenzrate-Resultaten. Hierfu¨r werden Varianten
von synchronen und schwach-asynchronen Iterationen als System interpretiert, korrespondieren-
de stochastische Modelle abgeleitet und ihre analytische Behandelbarkeit untersucht.
67
6.1 Performance Messung und Auswertung
Beim Testen paralleler Programme mu¨ssen oft Ursachen funktionalen Fehlverhaltens (z.B. Pro-
zesse “ha¨ngen”) und schlechter Performance (z.B. kein linearer Speed-up) gefunden werden.
Eine Analyse des Programmablaufs, die auf einer Visualisierung oder statistischen Auswertung
eingetretener Ereignisse und Zusta¨nde basiert, kann hierbei sehr hilfreich sein. Im Vergleich
zu sequentiellen Programmen ist es fu¨r parallele Programme oft schwierig, Verhalten und Per-
formance a priori zu verstehen, wenn die Folge auftretender Ereignisse im Programmablauf
indeterministisch ist. Der Indeterminismus geht hauptsa¨chlich darauf zuru¨ck, dass der inha¨rent
stochastische Charakter der Rechen- und Kommunikationsressourcen auf die Ausfu¨hrung der
Implementierung “durchschla¨gt”. Dieser Effekt wird durch die Aufhebung von Synchronisati-
onspunkten in Kommunikation und Berechnung weiter versta¨rkt.
Die messungsbasierte Analyse paralleler Programme beinhaltet 2 Schritte: 1. Messung interes-
sierender Ereignisse und Speicherung im Trace-File 2. Auswertung (visuell und/oder statistisch)
der im Trace-File aufgezeichneten Ereignisse und Zusta¨nde.
Trace-Files werden wa¨hrend der Programmausfu¨hrung erzeugt. Sie speichern beobachtete Er-
eignisse mit Zeitstempeln ab. Die Herausforderung hierbei ist eine zeit- und platzeffiziente
Aufzeichnung der Ereignisse. Dann ist gewa¨hrleistet, dass die eigentliche Ausfu¨hrung des ge-
messenen “Systems” (Programm-Source-Code, Kommunikation) unbeeinflusst bleibt und große
Datenmengen gespeichert und in der Auswertung effizient aufbereitet werden ko¨nnen. Des Wei-
teren sollten die Trace-Spezifikationssprachen portierbar, skalierbar, (dynamisch) erweiterbar
und leicht erzeugbar (benutzerfreundliche Code-Instrumentation) sein. Prominente Vertreter
von Trace-Spezifikationssprachen, die diesen Anforderungen gerecht werden, sind SLOG-2 [37]
und das Pablo Self-Defining Data Format (SDDF) [87].
Trace-Files ko¨nnen “online” zur Laufzeit oder “offline” visuell oder statistisch ausgewertet wer-
den. Eine online-Analyse ist gewo¨hnlich Bestandteil eines Steuerungsmechanismus in Form
eines einfachen Regelkreises oder eines intelligenteren (z.B. zustandsraumbasierten) Entschei-
ders, der z.B. ein dynamisches Ressourcen-Management realisiert. Eine statistische Auswertung
ermo¨glicht automatisierte online-Entscheider, demgegenu¨ber ist eine visuelle Auswertung fu¨r
menschliche online-Entscheider hilfreich. Autopilot-Virtue [97] ist eine Toolkombination, die ei-
ne visuelle und statistische Auswertung (basierend auf SDDF) online (Schwerpunkt) und off-
line unterstu¨tzt. Autopilot-Virtue ist Bestandteil des Pablo-Tools [87]. XPVM ist ein Tool
zur online- und offline-Visualisierung von Funktionen des Message-Passing Tools PVM (vgl.
Abschnitt 5.6.2) basierend auf SDDF Traces. Jump-Shot [37] bietet eine leistungsfa¨hige offline-
Visualisierung von SLOG-2 Traces, die u.a. mit der MPICH -MPI Distribution generierbar sind.
Daru¨ber hinaus gibt es weitere Werkzeuge, die auf Programm-, Rechen- und Kommunikati-
onsebene ein offline- bzw. online-“Performance Monitoring” mit benutzerdefinierten Metriken
(wenige auch mit adaptiven Steuerungen) unterstu¨tzen.
6.1.1 Netzbelastung
Erste Experimente mit ASYNC haben gezeigt, dass eine ungesteuerte Kommunikation (kein
DDM, vgl. Def. 5.10) bei der Lo¨sung von Markov-Ketten Modellen mit wenigen Millionen Zu-
sta¨nden in Rechnernetzen mit 10- und 100-MBit Verbindungen (mittlerer Teil in Abb. 5.4)
Engpa¨sse und Instabilita¨ten erzeugt [55]. Eine typische Beobachtung sind hohe Speicherplatz-
anforderungen der Daemon-Prozesse (Abb. 5.5 rechts), die vermutlich durch eine hohe Anzahl
68
“ha¨ngender Nachrichten” (=gesendet, aber nicht empfangen) verursacht werden. Generell war
die Performance und die Effektivita¨t der verteilten Berechnung in ASYNC oft nicht zufrieden-
stellend, wobei Engpa¨sse nicht analysierbar und nicht in ihrem Enstehen beobachtet werden
konnten.
In Zusammenarbeit mit J. Ma¨ter und einer studentischen Projektgruppe zur “Entwicklung ei-
nes Java-basierten Frameworks fu¨r verteilte Netzwerk-Messungen” [81] wurden agentenbasierte
Messungen der durch ASYNC verursachten Netzbelastung durchgefu¨hrt. Die Testumgebung war
ein Cisco Catalyst 2900 Switch und 4 SunBlade 100 Rechner (2 GB Arbeitsspeicher, UltraSparc
IIe Prozessor, 500 MHz), wobei 3 Rechner mit einem 100 MBit/s Links und der 4. Rechner
u¨ber ein 10 MBit/s Uplink-Port verbunden waren. Die Testumgebung ist ein Ausschnitt des
mittleren Teils des lokalen Netzwerks in Abb. 5.4. Das zu lo¨sende Markov-Ketten Modell hatte
10 773 430 Zusta¨nde und 126×126 Blo¨cke und ein synchroner BJAC -Iterationsschritt induzierte
einen Kommunikationsaufwand von 92 Nachrichten mit insgesamt 64.9 MB Datenumfang. Das
Ziel des Experiments war zu pru¨fen, ob fu¨r das beschriebene Berechnungsproblem die Band-
breite des Kommunikationsmediums ein Engpass ist. Hierfu¨r wurde der Netzverkehr am Switch
gemessen und die Anzahl u¨bertragener Bits je Zeitintervall (= 10 Sekunden) protokolliert.
Abbildung 6.1: Datendurchsatz gemessen an allen Ports
Die Abb. 6.1 zeigt den Durchsatz fu¨r alle Ports. Es ist zu erkennen, dass die Netzbelastung
anfa¨nglich sehr hoch ist (Spitze), dann folgt von Intervall 29 bis 99 (=700 Sekunden) eine ge-
ringe Belastung und danach folgt ein stochastisches Muster schwankender Belastung, das sich
u¨ber das Zeitfenster in Abb. 6.1 hinaus fortsetzt. Diese Beobachtungen sind leicht erkla¨rbar.
Am Anfang fu¨hrt ASYNC einen synchronen BJAC -Schritt aus, in dem alle Daten (“All-To-
All” Kommunikation) zeitnah verschickt werden. Hierdurch wird das Kommunikationsmedium
kurzzeitig hoch beansprucht. Die zeitliche U¨berlappung von Rechen- und Kommunikationspha-
sen, die im spa¨teren Verlauf der Berechnung bedingt durch die Asynchronita¨t eintritt, ist fu¨r
die Beanspruchung des Kommunikationsmediums vorteilhaft. In Abb. 6.1 ist zu erkennen, dass
69
die Spitzen in der Beanspruchung deutlich geringer sind als am Anfang. Die anfa¨nglich geringe
Belastung des Mediums von Intervall 29 bis 99 ist dadurch zu erkla¨ren, dass durch die initiale
Datenpropagation zuna¨chst nur geringer Bedarf an neuen zu kommunizierenden Daten signali-
siert wird (DDM und SDM sind aktiviert, vgl. Def. 5.10). Die Separierung von Kommunikations-
und Rechenphasen, die am Anfang beobachtbar ist, wird durch die Asynchronita¨t zunehmend
verwischt.
Des Weiteren ist zu erkennen, dass die Belastung des 10 MBit Uplink-Port (blaue bzw. dun-
kelste Linie in Abb. 6.1 bzw. Abb. 6.2) nicht schwankt. Der gemessene Durchsatz von nahezu
100 000 000 Bit je 10 Sekunden ist permanent nahe der Grenz-Kapazita¨t von 10 MBit je Sekunde.
Abbildung 6.2: Datendurchsatz gemessen am kritischen 10 MBit Port
Fazit: Messungen der Netzbelastung haben gezeigt, dass bereits fu¨r Problemgro¨ßen mit etwa
10 Millionen Zusta¨nden und langsamen Rechnern (Kommunikationsrate gering) 10 MBit/s Links
nicht ausreichend sind. Messungen der Netzbelastung geben einen gewissen Einblick in das Ver-
halten von ASYNC auf unterster Ebene. Weil die Enstehung des Kommunikationsmusters eng
an die softwaretechnische Realisation der Kommunikation durch PVM und MPI gekoppelt ist
und ebenfalls sehr vom Verhalten des Programms abha¨ngt, deren Zusta¨nde hier nicht erfasst
werden, kann u¨ber die Ursachen des beobachteten Verhaltens auf Netzebene zuna¨chst keine
Aussage gemacht werden
6.1.2 Messung in ASYNC
Im na¨chsten Schritt wurden Messungen oberhalb der Netzwerkebene in PVM und MPI durch-
gefu¨hrt. PVM und MPI unterstu¨tzen die Erzeugung von Trace-Files in verschiedenen Forma-
ten. Eine visuelle online-Auswertung muss große Datenmengen in graphische Objekte u¨berset-
zen und anzeigen. Der Umgang mit XPVM hat gezeigt, dass XPVM zur online-Visualisierung
durch ASYNC erzeugter Traces (SDDF) nicht ausreichend performant ist. XPVM kann aber
gut zur offline- Animation/Analyse des Ablaufs verwendet werden. Messungen in PVM und
MPI erfassen - wie auch die Messungen auf der Ebene der Netzwerkprotokolle oben - nicht das
Zusammenspiel von Programmausfu¨hrung (Berechnung) und Kommunikation, dessen Analyse
bedeutsam ist. Dies soll nachfolgend erla¨utert werden.
1. Pufferzugriff und -aktualisierung: In ASYNC kann der Zugriff auf gepufferte (kom-
munizierte) Daten von der Kommunikation entkoppelt werden, d.h. Pufferinhalte ko¨nnen
mehrfach ohne zwischenzeitliche Aktualisierung gelesen werden (vermindert Effizienz der
70
Berechnung) oder aber ungelesene Pufferinhalte ko¨nnen u¨berschrieben werden (vermin-
dert Effizienz der Kommunikation). Deswegen ist es fu¨r das Versta¨ndnis des Ablaufs der
Berechnung wichtig, neben der Kommunikation auch das Zugriffsmuster auf den Puffer,
das eng mit dem Ablauf der Berechnung verbunden ist, auswerten zu ko¨nnen.
2. Interaktion Berechnung und Kommunikation: In ASYNC kann die ablauflogische
Reihenfolge (asynchroner) Sendebefehle indeterministisch sein, wenn Daten zustandsab-
ha¨ngig versendet werden. Mo¨gliche Vorbedingungen fu¨r einen Sendebefehl ist das Vorliegen
einer Bedarfsanzeige seitens eines Konsumenten (vgl. “Demand-Driven-Messaging” Ab-
schnitt 5.4) oder eine hinreichende Vera¨nderung der Daten seit dem letzten Versand (vgl.
“Supply-Driven-Messaging” Abschnitt 5.4). Deswegen ist die Entstehung von Kommuni-
kationsmustern (wer, wann, was kommuniziert) nur zusammen mit dem Zustand der Be-
rechnung nachvollziehbar und verifizierbar. Umgekehrt kann die ablauflogische Reihenfol-
ge bearbeiteter Teilprobleme indeterministisch sein, wenn Teilprobleme zustandsabha¨ngig
gewa¨hlt werden. Eine Vorbedingung kann der Aktualisierungsgrad der Pufferinhalte sein
(siehe erster Punkt), von der die Berechnung des Teilproblems abha¨ngt.
3. Synchronisationspunkte: ASYNC bietet eine flexible Experimentierumgebung, in der
zahlreiche Implementierungsvarianten leicht getestet werden ko¨nnen. Ein Unterscheidungs-
merkmal ist der Grad der Asynchronita¨t. So ist es beispielsweise mo¨glich, zustandsabha¨ngi-
ge Synchronisationspunkte zu aktivieren. Eine mo¨gliche Aktivierungsbedingung ist der
Aktualisierungsgrad zu lesender Pufferinhalte. Deswegen ist es fu¨r das Versta¨ndnis be-
obachteter Synchronisationsphasen wiederum wichtig, auch den Zustand der Berechnung
auswerten zu ko¨nnen.
4. Defizite existierender Trace-Generatoren: Auf der Ebene von PVM und MPI tragen
Nachrichten lediglich ein vordefiniertes Attribut - ein sogenanntes “message-tag”. Existie-
rende Trace-Generatoren zeichnen Nachrichten mit dem Wert des “message-tag” auf. In
ASYNC werden weitere Attribute benutzt, die Bestandteil des benutzerdefinierten Daten-
typs der zu versendenden Daten sind (z.B. der Iterationsschritt, in dem Daten berechnet
wurden). Existierende Trace-Generatoren bieten nicht die Mo¨glichkeit, u¨ber das vordefi-
nierte “message-tag” hinaus weitere zu protokollierende Attribute zu definieren.
Das Fazit ist, dass ein Kommunikations-Trace allein fu¨r die Auswertung von ASYNC nicht aus-
reichend informativ ist. Deswegen ist in ASYNC eine eigensta¨ndige Trace-Generierung imple-
mentiert, die sowohl Ereignisse der Berechnung, als auch der Kommunikation erfasst. Die Trace-
Generierung in ASYNC ist mit Pra¨prozessor-Direktiven zum Zeitpunkt der Kompilierung (also
nicht zur Laufzeit) ein- oder ausschaltbar. Zur Laufzeit erzeugt jeder Prozess ein Trace-File mit
einer selbstdefinierten Trace-Spezifikation. Nach Beendigung des Programms liest ein awk-Skript
die lokalen Trace-Files und integriert die Informationen in einer Trace-Datenstruktur. Dabei wer-
den logische Abha¨ngigkeiten zwischen lokal protokollierten Ereignissen erkannt. Zum Beispiel
wird ein Sende-Ereignis dem zugeho¨rigen Empfangsereignis zugeordnet. Danach nutzt das awk-
Skript die eingelesenen Daten fu¨r Statistiken und erzeugt zum Zweck der Trace-Visualisierung
einen textuellen SLOG-2-Trace. Die SDDF-Spezifikationssprache bietet zwar mehr Mo¨glichkeiten
und Flexibilita¨t, es hat sich aber gezeigt, dass diese hier nicht beno¨tigt werden. Des Weiteren
war die Installation und Handhabung des Java-basierten SLOG-2 Viewers Jump-Shot einfacher
als die des SDDF-Pendants Pablo.
71
6.1.3 Asynchronita¨t und Lo¨sungszeit
Um den Einfluss der Asynchronita¨t auf die Lo¨sungszeit zu bewerten, werden 4 Implementie-
rungsvarianten V = 1 . . . 4 mit zunehmender Asynchronita¨t getestet. Die Varianten 1 bis 3 haben
bedingte Synchronisationspunkte, vgl. Tab. 5.4. Die vierte Variante realisiert eine vollsta¨ndig
asynchrone Iteration ohne Synchronisationspunkte. Visuelle und statistische Auswertungen der
durch ASYNC erzeugten Traces geben Einblicke in das dynamische Laufzeitverhalten der Vari-
anten.
Jede Implementierungsvariante lo¨st mit 2 Worker -Prozessen die Markov-Kette des FMS-Modells
(Modellparameter k = 10) fu¨r eine vorgegebene Genauigkeitsschranke (‖‖∞ < 10−6, vgl.
Gl. 4.10). Fu¨r die Interpretation des beobachteten Laufzeitverhaltens ist es sehr hilfreich, die
Lastverteilung fu¨r 2 Prozesse und die damit verbundenen Datenabha¨ngigkeiten des FMS-Modells
zu kennen. Die Lastverteilung und die Datenabha¨ngigkeiten wurden im Bsp. 5.13 vorgestellt.
Die Abb. 6.4-6.6 zeigen visualisierte Traces der ersten drei Implementierungsvarianten. Die
dargestellten Ausschnitte entstammen dem Jump-Shot Viewer. Violette Rechtecke (dunkelster
Grauton) repra¨sentieren Synchronisationsphasen (S-Phasen) an datenabha¨ngigen Synchroni-
sationspunkten, gru¨ne Rechtecke (hellster Grauton) kommunikationsabha¨ngige Rechenphasen
(KAR) und blaue Rechtecke (mittlerer Grauton) kommunikationsunabha¨ngige Rechenphasen
(KUR). Pfeile zeigen Nachrichten mit ihrem Sendezeitpunkt und dem Zeitpunkt der Verfu¨gbar-
keit im Puffer des Empfa¨ngers an. Die Abb. 6.3 verdeutlicht die eingesetzten Symbole fu¨r KARs,
KURs und Nachrichten in beispielhaften Szenarien der 3 Implementierungsvarianten. Zusa¨tzlich
ist fu¨r jede KAR und KUR der Iterationsschritt notiert.
1
1
1
1
1
1
1
1
2
22
2
2
2
2
2
33
3
1
1
1
1 2
2
2
2
K o m m u n i k a t i o n s a b h ä n g i g e  R e c h e n p h a s e  ( K A R )K o m m u n i k a t i o n s u n a b h ä n g i g e  R e c h e n p h a s e  ( K U R )S y n c h r o n i s a t i o n s p h a s e
Varia
nte 1
Varia
nte 2
Varia
nte 3
Abbildung 6.3: Visualisierung Rechen- und Kommunikationsmuster
In Tab. 6.1 sind Lo¨sungszeiten und Auswertungsergebnisse fu¨r V=1 . . . 4 zusammengetragen.
Nachfolgend werden die Ergebnisse genauer betrachtet.
72
V ZeitUSR ZeitCPU Iter ZeitUSR/Iter ZeitCPU/Iter Comp [%] Sync [%]
P=1 P=2 P=1 P=2 P=1 P=2 P=1 P=2 P=1 P=2 P=1 P=2
1 6194 6189 6192 149 149 41.6 41.6 41.5 41.6 71 74 14 19
6343 6335 6340 149 149 42.6 42.6 42.5 42.6 70 71 16 22
2’ 5475 5473 5472 149 149 36.7 36.7 36.7 36.7 79 91 4 0
5394 5390 5392 149 149 36.2 36.2 36.2 36.2 82 85 0 6
2 5655 5650 5647 148 148 38.2 38.2 38.2 38.2 76 92 7 0
5459 5448 5457 148 148 36.9 36.9 36.8 36.9 83 82 0 9
3 5395 5232 5393 150 150 40.0 40.0 34.9 40.0 79 91 3 0
5700 5692 5190 150 150 38.0 38.0 37.9 34.6 82 82 0 9
5830 5819 5603 150 150 38.9 38.9 38.8 34.6 82 87 0 4
4 5148 5144 5144 135 155 38.1 33.2 38.1 33.2 83 90 0 0
5721 5715 5708 148 150 38.7 38.1 38.6 38.1 74 91 0 0
5551 5545 5543 160 145 34.7 38.3 34.7 38.2 82 91 0 0
5309 5297 5307 133 155 39.9 34.3 39.8 34.2 83 90 0 0
Tabelle 6.1: Lo¨sungszeit (Sekunden) vs. Asynchronita¨t: V=Grad der Asynchronita¨t;
Zeit=Lo¨sungszeit (wall-clock); Iter=Anzahl Iterationen bis Genauigkeitsschranke; Comp=Anteil
Dauer Rechenphasen fu¨r Teilprobleme; Sync=Anteil Wartezeiten in Synchronisationspunkten
Variante 1 Die Ausfu¨hrung der Implementierungsvariante 1 ist durch zwei strikt alternierende
Phasen α und β gekennzeichnet. Die α-Phase ist eine Rechenphase, in der zugeordnete Blo¨cke
gelo¨st werden. Die β-Phase ist eine Kommunikations- und S-Phase. Die β-Phase endet bzw. die
na¨chste α-Phase beginnt, sobald alle am Anfang der aktuellen β-Phase initiierten Nachrichten
im Puffer der Empfa¨nger vorliegen, vgl. Abb. 6.4. Insofern ist die β-Phase eine S-Phase, de-
ren Dauer vom Zustand des Kommunikationspuffers abha¨ngt. Die so realisierte Iteration mischt
stochastisch Jacobi- und Gauss-Seidel-Schritte, weil kommunizierte und dann in die Berech-
nung einfließende Vektoren aus dem vorherigen oder aktuellen Iterationsschritt entstammen.
In der Iteration in Abb. 6.4 treten nur Jacobi-Schritte auf. Der Synchronisationsaufwand und
die Lo¨sungszeiten der Variante 1 sind sehr hoch, vgl. Tab. 6.1. Zwischen 14% und 22% der
Gesamtzeit geht in S-Phasen verloren, vgl. Spalte “Sync”.
Abbildung 6.4: Trace-Visualisierung der ASYNC -Implementierungsvariante 1
Variante 2 Der wesentliche Unterschied zu Variante 1 ist, dass die Vektoren sofort nach
ihrer Aktualisierung verschickt werden (nicht bei Variante 2’) und Synchronisationspunkte fu¨r
kommunizierte Vektoren erst unmittelbar vor deren Benutzung positioniert sind. Insofern sind
die oben definierten α- und β-Phasen nun u¨berlappend. In Variante 1 wurden zuerst alle Vektoren
73
aktualisiert (α-Phase) und danach verschickt (Pfeile starten alle am gleichen Punkt) und die β-
Phase endet, wenn alle kommunizierten Vektoren vorliegen sind. Dies ist nachteilig, weil die
Beanspruchung der Kommunikationsressourcen punktuell hoch ist und die Synchronisation mit
kommunizierten Vektoren ggf. nicht zeitnah zur tatsa¨chlichen Benutzung ist.
In Variante 2’ wird der Zugriff auf kommunizierte Vektoren zeitnah synchronisiert, die “Bulk”-
Kommunikation aus Variante 1 bleibt aber bestehen. Die Abb. 6.5 oben zeigt zwei Traces der
Variante 2’. Prozess 1 hat 8 KURs (fu¨r pi[1] bis pi[8]) gefolgt von einer KAR (fu¨r pi[9]). Im oberen
Trace ist zu erkennen, dass Prozess 1 (oben) mit der α-Phase starten kann, obwohl noch eine
Nachricht unterwegs ist. Die Nachricht trifft von α-Phase zu α-Phase zunehmend spa¨ter ein und
nach einigen Schritten muss Prozess 1 vor der KAR synchronisieren. Prozess 2 hat am Ende der
ersten α-Phase eine lange S-Phase (α-Phase hat 2 KARs). Diese wirft Prozess 2 im Vergleich
zu Prozess 1 hinreichend weit zuru¨ck, so dass alle folgenden Nachrichten von Prozess 1 zu
Prozess 2 rechtzeitig eintreffen. Der obere Trace zeigt, dass sich nach einigen Iterationsschritten
ein Zustand einstellt, der durch S-Phasen in Prozess 1 gekennzeichnet ist und stabil bleibt
(auch u¨ber den dargestellten Bereich hinaus). Im zweiten Trace der Variante 2’ stellt sich ein
anderer stabiler Zustand ein, in dem S-Phasen nur in Prozess 2 auftreten. Prozess 2 hat am
Ende der ersten α-Phase eine lange S-Phase. Im Gegensatz zum ersten Experiment wirft diese
den Prozess 2 nicht soweit zuru¨ck, so dass alle weiteren Nachrichten von Prozess 1 zu Prozess 2
rechtzeitig ankommen (S-Phasen in Prozess 2 bleiben) und die Nachricht von Prozess 2 zu
Prozess 1 ist rechtzeitig verfu¨gbar (keine S-Phasen in Prozess 1).
In Abb. 6.5 ist in den beiden unteren Traces der Variante 2 zu erkennen, dass Pfeile nun kei-
nen gemeinsamen Startpunkt haben. Die Beseitigung der Bulk-Kommunikationen verbessert die
Performance (ZeitUSR, ZeitCPU ) leider nicht (vgl. Tab. 6.1), weil Performance-kritische Kommu-
nikation weiterhin eine beschleunigte Ausfu¨hrung verhindert. Was genau “Performance-kritisch”
ist ha¨ngt vom a-priori nicht bekannten Berechnungs- und Kommunikationsmuster ab. Im ersten
Trace treten zuna¨chst keine S-Phasen, dann nur im Prozess 1 auf. Im zweiten Trace ist es um-
gekehrt, der Prozess 2 schreitet zu schnell voran und wird durch S-Phasen ausgebremst. Die
Kommunikation des Vektors pi[10] von Prozess 2 an Prozess 1 bzw. des Vektors pi [9] von Pro-
zess 1 an Prozess 2 ist im ersten bzw. zweiten Trace kritisch, weil diese Vektoren innerhalb der
Iterationsschritte zuletzt berechnet und verschickt werden. Es ist unklar, warum trotz gleichblei-
bender Lastverteilung einmal Prozess 1 und dann Prozess 2 zu schnell ist und ausgebremst wird.
Vorliegende aber hier nicht angefu¨hrte Statistiken zeigen, dass CPU-Zeiten einzelner KARs und
KURs sowohl innerhalb eines Laufs, als auch deren Mittelwerte von Lauf zu Lauf stark (bis zu
10%) schwanken.
Der Anteil der Synchronisationsphasen sinkt im Vergleich zu Variante 1 deutlich und liegt nun
zwischen 4% und 9%, vgl. Tab. 6.1.
Die Dynamik in der zeitlichen Ausfu¨hrung bewirkt (noch) keine indeterministische Numerik, d.h.
die Anzahl notwendiger Schritte ist stets 149 (Variante 2’) und 148 (Variante 2), vgl. Tab. 6.1.
Die S-Phasen verhindern eine dynamische Rekombination in KARs einfließender kommunizier-
ter Vektoren, d.h. einfließende Vektoren entstammen stets in gleicher Weise dem aktuellen oder
vorherigen Iterationsschritt. Damit ist die Folge der berechneten Iterationsvektoren determini-
stisch.
74
Abbildung 6.5: Trace-Visualisierungen der ASYNC -Implementierungsvariante 2’ (1. und 2. Trace
von oben) und 2 (3. und 4. Trace von oben)
Variante 3 In den Varianten 1 und 2 synchronisiert die Berechnung mit der Aktualita¨t kom-
munizierter Daten und alle KARs und KURs mu¨ssen mit gleicher Rate ausgefu¨hrt werden. In
Variante 3 werden KARs und KURs ebenfalls mit gleicher Rate ausgefu¨hrt, es sind aber nun
Synchronisationspunkte (Barrieren) in den Source-Code integriert und kommunizierte Daten
ko¨nnen beliebig alt sein.
Die Abb. 6.6 zeigt, dass Prozess 2 (unten im oberen Trace) schneller ist und durch S-Phasen
ausgebremst wird. Die α-Phasen starten prozessu¨bergreifend zeitlich synchron. Des Weiteren
zeigt Abb. 6.6, dass die Bandbreite des Kommunikationsmediums (1 GBit Switch) ausreicht, um
Vektoren ohne große Verzo¨gerungen zu transferieren. Die ausbleibende Dynamik in den U¨ber-
tragungszeiten fu¨hrt wie oben zu einer deterministischen numerischen Ausfu¨hrung, die Anzahl
notwendiger Schritte ist stets gleich 150, vgl. Spalte “Iter” in Tab. 6.1.
Die Performance der Variante 3 ist im Vergleich zu Variante 2 etwas schlechter, vgl. Spalten
“ZeitUSR” und “ZeitCPU” in Tab. 6.1. Fu¨r Prozesse mit S-Phasen gilt ZeitUSR > ZeitCPU ,
weil durch die Art der S-Phasen Implementierung keine CPU-Zeit verbraucht wird (bei Va-
riante 1 und Variante 2 findet in S-Phasen ein “Polling” neuer Nachrichten statt, das CPU-
Zeit verbraucht). Trotz gleichbleibendem numerischen Aufwand und S-Phasen ohne Einfluss
auf die CPU-Zeit schwanken die CPU-Zeiten einzelner Prozesse recht stark. Die Ursache fu¨r
die Schwankungen ist unklar. Um den Grund fu¨r die Schwankungen einzugrenzen, wurden
Messungen an dedizierten Source-Code-Blo¨cken durchgefu¨hrt. Dabei zeigte sich, dass Vektor-
Matrix-Multiplikationen, die zahlreiche Zeigeroperationen und natu¨rlich arithmetische Opera-
tionen beinhalten, schwankende CPU-Zeit Verbra¨uche verursachen.
Die Barriere-Synchronisation hat bei erho¨htem Kommunikationsaufwand eine schlechte Perfor-
mance. Die Abb. 6.6 zeigt unten einen Trace mit 4 Worker -Prozessen, wobei jeweils 2 Prozesse
auf einem Cluster laufen und die beiden Cluster u¨ber das langsame Lehrstuhl-Netzwerk verbun-
den sind, vgl. Abb. 5.4. Der Kommunikationsaufwand steigt von 10 Nachrichten mit 153 MB
auf 29 Nachrichten mit 409 MB je Iterationsschritt, vgl. Tab. 5.6. Die Abb. 6.6 zeigt, dass in
allen Prozessen lange S-Phasen auftreten. Der Anteil der S-Phasen liegt zwischen 32% (2. Pro-
zess von unten) und 70% (oberster Prozess). Wiederholungen dieser und a¨hnlicher Experimente
besta¨tigten diese Beobachtung. Auffa¨llig ist, dass keine Nachrichten u¨ber S-Phasen hinweg auf-
treten. Die Implementierung der Barriere-Synchronisation lo¨st ein “Message-Passing” aus, mit
75
Abbildung 6.6: Trace-Visualisierung der ASYNC -Implementierungsvariante 3 mit 2 Prozessen
(oben) und 4 Prozessen (unten)
dem Prozesse das Erreichen einer Barriere signalisieren. Im hier verwendeten Kommunikations-
Tool PVM scheinen diese Signale keine ho¨here Priorita¨t zu erhalten als die Kommunikation, die
durch Sende- und Empfangsbefehle ausgelo¨st wird. Dies heisst die Performance der Barriere-
Synchronisation (=ku¨rzeste Prozess-S-Phase) ha¨ngt von der aktuellen Last der sonstigen Kom-
munikation ab. Im Experiment mit 4 Prozessen kann dies wie folgt quantifiziert werden: die
erste Barriere-Synchronisation am Start der Iteration (noch keine konkurrierende Kommunika-
tion) beno¨tigt 0.925 ms, die folgenden Barriere-Synchronisationen beno¨tigen im Mittel 10 s. Die
ersten Einzelwerte lauten 9.91 s, 10.19 s, 9.93 s, 10.31 s ...
Variante 4 Diese Variante entha¨lt keine Synchronisationspunkte. Die Folge der Iterationsvek-
toren ist indeterministisch und die Anzahl notwendiger Iterationsschritte bis zum Erreichen der
Genauigkeitsschranke variiert, vgl. Tab. 6.1. Der durch Asynchronita¨t ggf. erforderliche numeri-
sche Mehraufwand in Form zusa¨tzlicher Iterationsschritte ist im Beispiel sehr moderat bzw. tritt
nicht auf. Die probabilistische Anzahl der Schritte weicht nur unwesentlich von der Anzahl in
den Varianten 1 bis 3 ab. Im nachfolgenden Abschnitt 6.1.5 wird ein Beispiel betrachtet, in dem
Asynchronita¨t einen numerischen Mehraufwand auslo¨st. Auf der anderen Seite kann die Asyn-
chronita¨t keinen signifikanten Performance-Gewinn im Vergleich zu Variante 2 erzielen, weil der
Synchronisations-Mehraufwand dort gering ist. Die mittlere USER-Zeit (ZeitUSR) u¨ber alle 4
La¨ufe ist 5496 s (Variante 2) und 5432 s (Variante 4).
Fazit Eine a-posteriori visuelle und statistische Auswertung von ASYNC -Traces verdeutlicht
Rechen- und Kommunikationsmuster und gestattet auf diese Weise Einblicke in die indetermini-
stischen ASYNC -Abla¨ufe. Implementierungsvarianten mit schwacher Asynchronita¨t erreichen -
mit Ausnahme der stark synchronisierten Variante 1 - die selbe Performance wie eine vollsta¨ndig
asynchrone Implementierung unter der Bedingung, dass die Lastverteilung gut balanziert ist.
76
Diese Bedingung ist hier erfu¨llt und deswegen sind Blockierungen in bedingten Synchronisa-
tionspunkten kurz. Schwache Asynchronita¨t verhindert hier ein “Durchschlagen” des inha¨rent
stochastischen Charakters der Rechen- und Kommunikationsressourcen auf die Numerik und so
ist die Anzahl auszufu¨hrender Iterationsschritte deterministisch. In den beobachteten ASYNC -
Abla¨ufen stellen sich nach einigen Iterationsschritten stationa¨re Rechen- und Kommunikations-
muster ein. Trotz gleichbleibendem Experimentierumfeld ist das Muster nicht reproduzierbar,
Synchronisationsphasen treten zum Beispiel in unterschiedlichen Prozessen auf.
Doppelprozessoren sind fu¨r ASYNC sehr vorteilhaft, weil Worker - und Daemon-Prozesse nicht
um Rechenressourcen konkurrieren.
6.1.4 Totale vs. partielle Asynchronita¨t
In den Gl. 4.25 und 4.27 (Seite 36) wurden 2 Konstanten D und S definiert, die als Gradmesser der
Asynchronita¨t interpretierbar sind. Die D-Konstante legt grob gesprochen fest, wie alt - gemessen
in Iterationsschrittdifferenzen - kommunizierte Vektoren sein du¨rfen, um beim Konsumenten
verwendet werden zu du¨rfen. ASYNC kann die D-Konstante kontrollieren, in dem ggf. schnelle
Worker -Prozesse solange “ausgebremst” werden bis hinreichend aktuelle Daten vorliegen.
Nachfolgend soll der Einfluss der D-Konstante auf Lo¨sungszeiten experimentell untersucht wer-
den. Hierfu¨r werden die Markov-Ketten des SUH2-Modells mit dem Parameter k=5 (67 920 112
Zusta¨nde) und des FMS-Modells mit dem Parameter k=10 (25 397 658 Zusta¨nde) fu¨r Genauig-
keitsschranken ‖‖∞ < 10−9 bzw. ‖‖∞ < 10−6 (vgl. Gl. 4.10) mit 7 bzw. 2 Worker -Prozessen
gelo¨st.
In Tab. 6.2 sind alle Messwerte aufgelistet. Die Spalte “Zeit” verweist auf die USER-Lo¨sungszeit
und die Spalte “NA” gibt den numerischen Aufwand gemessen in der Summe der Iterationsschrit-
te aller beteiligter Worker -Prozesse an. Fett gedruckte Werte sind Mittelwerte u¨ber jeweils 3
Experimente.
1. Numerischer Aufwand vs. Asynchronita¨t : Eine Schlussfolgerung aus der Theorie
zum Konvergenzverhalten asynchroner Iterationen ist, dass mit Zunahme der Asynchro-
nita¨t die Effektivita¨t der Iterationen sinken kann, vgl. Abschnitt 5.2.3. Das SUH2-Modell
zeigt dieses Verhalten. Mit Zunahme von D, insbesondere im total asynchronen Szenario
(D =∞), steigt die Gesamtzahl der Schritte, vgl. Spalte “NA” in Tab. 6.2. Demgegenu¨ber
ist beim FMS-Modell der numerische Aufwand wenig sensitiv bzgl. D, im total-asynchronen
Szenario sinkt der numerische Aufwand sogar.
2. Deterministischer numerischer Aufwand : Fu¨r alle partiell-asynchronen Abla¨ufe (D
endlich) ist der numerische Aufwand sehr deterministisch, vgl. “Iterationen”-Spalten in
Tab. 6.2. Dies ist insofern erstaunlich, als dass sich die Iteration bis zum Erreichen der
D-Schranke wie eine total asynchrone Iteration verha¨lt, fu¨r die der numerische Aufwand
schwankt (siehe D = ∞ Experimente). Die transiente stochastische Beeinflussung des
numerischen Aufwands hat geringen Einfluss auf den Gesamtaufwand.
3. Lo¨sungszeit vs. Asynchronita¨t : In den Experimenten ist die Lo¨sungszeit wenig sensitiv
gegenu¨ber der Wahl von D. Die total-asynchrone Iteration erzielt trotz Wegfall potentieller
Synchronisationspunkte keine Vorteile, was durch einen erho¨hten numerischen Aufwand
(SUH2-Modell) oder eine geringe Sensitivita¨t bzgl. der Asynchronita¨t (FMS-Modell) bedingt
ist.
77
SUH2-Modell FMS-Modell
D Iterationen Zeit NA Iterationen Zeit NA
p=1 p=2 p=3 p=4 p=5 p=6 p=7 [s] [iter] p=1 p=2 [s] [iter]
1 210 209 210 210 210 210 210 3235 1469 144 145 2934 289
1 210 209 210 210 210 210 210 3169 1469 144 145 2945 289
1 210 209 210 210 210 210 210 3157 1469 144 145 2939 289
3187 1469 2939 289
5 211 206 211 211 211 211 211 3117 1472 141 146 3094 287
5 210 205 210 210 210 210 210 3120 1465 141 146 3066 287
5 212 207 212 212 212 212 212 3160 1479 141 146 3064 287
3132 1472 3075 287
10 214 204 214 214 211 212 214 3096 1483 138 148 2787 286
10 214 204 214 214 211 214 214 3097 1485 139 149 2831 288
10 214 204 214 214 212 214 214 3103 1486 138 148 2815 286
3099 1485 2811 286
15 216 201 216 216 208 211 216 3033 1484 136 151 2938 287
15 216 201 216 216 208 210 216 3036 1483 136 151 2955 287
15 216 201 216 216 209 209 216 3053 1483 136 151 2904 287
3041 1483 2932 287
∞ 231 203 248 360 175 178 233 3227 1628 126 150 3031 276
∞ 236 204 249 371 177 180 238 3261 1655 130 150 3128 280
∞ 225 185 223 347 194 199 220 3312 1593 126 151 3076 277
3267 1625 3078 278
Tabelle 6.2: Lo¨sungszeit und numerischer Aufwand (NA) vs. Grad der Asynchronita¨t gemessen
durch die Konstante D
Fazit Aus den vorliegenden Experimen-Ergebnissen la¨ßt sich keine Empfehlung fu¨r die Wahl
der D-Konstante ableiten. In den dokumentierten (und nicht-dokumentierten) Experimenten
erzielt eine total asynchrone Iteration keine signifikanten Performance-Vorteile gegenu¨ber ei-
ner partiell asynchronen Iteration, obwohl in allen Experimenten das DDM -Protokoll (Ab-
schnitt 5.4.4) aktiviert ist (Kommunikation nur bei Bedarf). Ohne DDM -Protokoll werden in
total asynchronen Iterationen Performance-Verschlechterungen durch schnell iterierende Wor-
ker -Prozesse riskiert, die mit hoher Rate und u¨ber Bedarf Vektoren propagieren.
6.1.5 Effizienz der verteilten Berechnung
Die Beschleunigung und die Effizienz sind etablierte Maße zur Bewertung der Qualita¨t paralleler
Berechnungen.
Definition 6.1 (Beschleunigung und Effizienz) Es sei T (1) die Laufzeit einer 1-Prozess-
Lo¨sung und T (p) mit p > 1 die Laufzeit einer verteilten p-Prozess-Lo¨sung. Dann ist
S(p) , T (1)T (p)
die Beschleunigung (speed-up) und
E(p) , S(p)p
78
die Effizienz der verteilten/parallelen Lo¨sung des Berechnungsproblems. Des Weiteren sei T cpui (p)
mit i ≤ p die CPU-Zeit von Prozess i innerhalb einer p-Prozess-Lo¨sung.
Dieser Abschnitt dokumentiert ASYNC -Laufzeitexperimente zur Messung von Beschleunigung
und Effizienz. In Tab. 6.3 sind Lo¨sungszeiten T (p), Beschleunigung S(p) und Effizienz E(p) in
Abha¨ngigkeit von der Anzahl verteilt ablaufender Worker -Prozesse p angegeben. Fett gedruckte
Werte sind Mittelwerte u¨ber Experimente mit gleichem p-Wert. Des Weiteren ist in Tab. 6.3 die
Anzahl ausgefu¨hrter Iterationsschritte je Prozess p (= numerischer Aufwand) aufgefu¨hrt.
Gelo¨st wird das SUH1-Modell mit dem Parameter k=5 (= 122 189 237 Zusta¨nde, vgl. Abschnitt 3.4)
fu¨r eine feste Genauigkeitsschranke (‖‖∞ < 10−7, vgl. Gl. 4.10). Hierfu¨r wird ein Rechner-
Cluster mit 6 Rechnern benutzt, vgl. Abschnitt 5.3, insb. Abb. 5.4 rechts. Die Gro¨ße des SUH1-
Modells ist nahe am Platzlimit einer 1-Prozess-Lo¨sung. Der virtuelle Arbeitsspeicher pro Prozess
ist unter dem Linux-Betriebssystem unabha¨ngig von der Gro¨ße des Arbeitsspeichers (hier 6 GB)
gegenwa¨rtig auf 3 GB beschra¨nkt1, ein einzelner ASYNC -Prozess beno¨tigt etwa 2.2 GB. Das
na¨chst gro¨ßere SUH1-Modell mit k = 6 kann wegen des Platzlimits nicht durch einen einzelnen
ASYNC -Prozess gelo¨st werden und ist deswegen zur Bewertung der Beschleunigung ungeeignet,
vgl. Abschnitt 6.1.6 zur Bewertung des Platzaufwands sehr großer Modelle.
p T (p)
p∑
i=1
T cpui (p) Iter S(p) E(p)
[s] [s] p=1 p=2 p=3 p=4 p=5 p=6
1 50 140 50 135 197
2 34064 68102 1.47 0.74
34 263 68 516 237 320 1.46 0.73
33 925 67 791 237 314 1.48 0.74
34 004 68 000 236 314 1.47 0.74
4 19205 76702 2.61 0.65
19 415 77 520 230 301 292 336 2.58 0.65
18 931 75 633 223 300 300 384 2.65 0.66
19 268 76 953 220 309 300 342 2.60 0.65
6 14254 85363 3.52 0.59
14 805 88 698 227 364 270 326 317 445 3.39 0.56
13 809 82 683 238 337 265 311 311 386 3.63 0.61
14 147 84 710 235 348 265 326 293 414 3.54 0.59
Tabelle 6.3: Beschleunigung und Effizienz der verteilten numerischen Analyse mit ASYNC
1. CPU-Zeit vs. USER-Zeit : Bei allen Worker -Prozessen erreicht die CPU-Zeit nahezu
die USER-Zeit (T (p) ≈ p−1 ·∑pi=1 T
cpu
i (p) ), weil Worker -Prozess und Daemon-Prozess
wegen der Doppelprozessoren nicht um Rechenressourcen konkurrieren. Praktisch bedeu-
tet dies, dass der durch den Daemon-Prozess geleistete Mehraufwand zur Abwicklung
der Kommunikation keinen Einfluss auf die USER-Lo¨sungszeit hat und so ASYNC sehr
von den Doppelprozessoren profitiert. In fru¨heren Messungen auf Singleprozessoren wur-
1Anfrage bei “Informatik-Rechner-Betriebsgruppe”, Fachbereichs Informatik, Uni Dortmund
79
de festgestellt, dass Daemon-Prozesse 10%-20% der insgesamt aufzubringenden CPU-Zeit
beanspruchen [52].
2. Stochastik : Schwankungen der Beschleunigung und in der Anzahl ausgefu¨hrter Iterati-
onsschritte (= numerischer Aufwand) verdeutlichen den dynamischen Charakter der asyn-
chronen Iteration und Kommunikation. Die beobachte Schwankungsintensita¨t (= Verha¨lt-
nis langsamste zu schnellste Lo¨sungzeit T (p)) betra¨gt 1.001 (p = 2) 1.026 (p = 4) 1.072
(p = 6). Eine Zunahme von p bewirkt mehr Kommunikationsabha¨ngigkeiten und damit
mehr stochastische Einflussgro¨ßen.
3. Beschleunigung und Effizienz : ASYNC erzielt keine lineare Beschleunigung, weil
die Asynchronita¨t in der verteilten Berechnung einen signifikanten numerischen Mehrauf-
wand erzeugt. Der durch die Kommunikation verursachte Mehraufwand wird hauptsa¨chlich
durch Daemon-Prozesse geleistet. Weil die Daemon-Prozesse hier u¨ber eigene Rechenres-
sourcen verfu¨gen, hat die von ihnen konsumierte CPU-Zeit keinen Einfluss auf die USER-
Zeiten der Worker -Prozesse und damit auch keinen Einfluss auf die gemessene Beschleu-
nigung2. Dass die Asynchronita¨t fu¨r einen erho¨hten, in Iterationsschritten gemessenen
numerischen Aufwand verantwortlich ist, kann man gut fu¨r p = 1 und p = 2 sehen. Die
Erho¨hung des CPU-Zeit Aufwands von 50 135 fu¨r p = 1 auf 68 102 (+35.8%) fu¨r p = 2
wird durch die Erho¨hung des numerischen Aufwands von c.a. 40% ausgelo¨st. Die mittlere
Anzahl von Iterationsschritten u¨ber alle Prozesse steigt von 197 fu¨r p = 1 auf 277 fu¨r p = 2.
Die Erho¨hung des CPU-Zeit Aufwands von 50 135 fu¨r p = 1 auf 76 702 (+53%) fu¨r p = 4
und 85 363 (+70.3%) fu¨r p = 6 wird hauptsa¨chlich - aber nicht ausschließlich - durch den
numerischen Mehraufwand (49.6% bzw. 60.1% - Scha¨tzung auf Iterationsschritten, s.o.)
erzeugt. Obwohl der vermehrte Kommunikationsaufwand hauptsa¨chlich durch die Dae-
mon-Prozesse getragen wird, verursacht er auch in den Worker -Prozessen eine Erho¨hung
der CPU-Zeit.
Nachfolgend wird das FMS-Modell mit dem Parameter k=11 (54 682 992 Zusta¨nde) fu¨r eine feste
Genauigkeitsschranke (‖‖∞ < 10−9, vgl. Gl. 4.10) gelo¨st und experimentell untersucht, welche
Beschleunigung ASYNC im Vergleich zur konventionellen SOR-Iteration erzielt. Des Weiteren
wird der Einfluss von Aggregierungs-/Disaggregierungsschritten (AD-Schritte) betrachtet. Die
Ergebnisse sind in Tab. 6.4 notiert.
1. Einfluss AD-Schritte : Die Einbettung von AD-Schritten in die SOR-Iteration fu¨hrt zu
einer deutlichen Reduktion der Lo¨sungszeit (Exp. 1+2), weil sich die Anzahl auszufu¨hren-
der Iterationsschritte von 1 020 auf 170 vermindert. Demgegenu¨ber bleiben AD-Schritte
in der synchronen BSOR-Iteration mit 4 inneren Schritten je Block nahezu ohne Wirkung
(Exp. 3+4, entspricht ASYNC mit p=1). Ebenso verha¨lt es sich mit ASYNC und p=5
(Exp. 5+6).
2. ASYNC -Beschleunigung gegenu¨ber SOR-Iteration : Die sequentielle BSOR-Iteration
in Exp. 3 ist deutlich schneller als die SOR-Iteration in Exp. 2. Allerdings kann die Lo¨sungs-
zeit von 8 964 Sekunden der SOR+AD-Iteration durch keine ASYNC -Variante unterboten
werden. Sogar die Lo¨sungszeit der 5-Prozess-Lo¨sung ist mit 10 309 Sekunden (ohne AD)
bzw. 10 090 Sekunden (mit AD) deutlich ho¨her.
2Ansonsten wa¨ren die Werte fu¨r die Beschleunigung schlechter als die hier angegebenen.
80
Exp Verfahren T (p)
p∑
i=1
T cpui (p) Iter
[s] [s]
1 SOR 50 880 50 880 1 020
2 SOR+AD 8964 8 964 170
3 ASYNC p=1 (=BSOR) 27 980 27 989 384
4 ASYNC+AD p=1 (=BSOR+AD) 27 419 27 424 367
5 ASYNC p=5 10 309 51 799 321-480
6 ASYNC+AD p=5 10 090 50 650 339-461
Tabelle 6.4: Performance: Methodenvergleich und Einfluss von AD-Schritten
Fazit Die Konvergenzrate synchroner und asynchroner Block-Iterationen ist im betrachteten
Beispiel (FMS-Modell) wenig sensitiv gegenu¨ber eingebetteten AD-Schritten. Aus diesem Grund
kann die durch AD-Schritte deutlich verminderte Lo¨sungszeit einer SOR+AD-Iteration durch
keine ASYNC -Variante (mit/ohne AD, sequentielle/verteilte Lo¨sung) erreicht werden.
6.1.6 Lo¨sung sehr großer Modelle
Die Lo¨sung sehr großer Markov-Ketten Modelle erfordert leistungsfa¨hige Rechen-, Platz- und
Kommunikationsressourcen. ASYNC ermo¨glicht Modelle mit mehreren 100 Millionen Zusta¨nden
verteilt zu lo¨sen. Mit Ausnahme der Arbeit von Bell [17] ist bisher nicht u¨ber die Lo¨sung derartig
großer Modelle berichtet worden.
Bell lo¨st ebenfalls große Markov-Ketten verteilt und iterativ auf einem Rechner-Cluster (verteil-
ter Speicher), die Realisierung unterscheidet sich jedoch in mehreren Punkten von ASYNC. Bell
betrachtet eine konventionelle Jacobi-Fixpunkt-Iteration und ein klassisches projektives Verfah-
ren (hier: hierarchische und asynchrone Erweiterung einer BJAC -Iteration) und bei Bell sind
die Lo¨sungsverfahren Disk-basiert implementiert, d.h. die Generatormatrix wird vollsta¨ndig im
Festplattenspeicher gehalten und wird bei Bedarf nur partiell in den Arbeitsspeicher geladen
(hier: alle Daten inklusive der Generatormatrix ko¨nnen im Arbeitsspeicher gehalten werden).
Das gro¨ßte behandelbare Modell in [17] ist das FMS-Modell mit k=15 (724 Millionen Zusta¨nde).
Die Lo¨sung mit einer geringen Genauigkeitsschranke erfordert 292 Stunden (eine “u¨bliche” Ge-
nauigkeitsschranke wird nicht erreicht). In der vorliegenden Arbeit konnte ein etwas gro¨ßeres
Modell mit 897 Millionen Zusta¨nden in 55 Stunden gelo¨st werden, vgl. Tab. 6.5. Das FMS-Modell
ermo¨glicht einen Performance-Vergleich. Leider kann ASYNC das FMS-Modell mit k=13 . . . 15
nicht lo¨sen, weil die gegebene Blockstruktur der Generatormatrix sehr imbalanziert ist, ins-
besondere einen sehr großen Block aufweist, der 20% (k=13), 19% (k=14) bzw. 18% (k=15)
der Gesamtgro¨ße ausmacht. Das FMS-Modell mit k=12 wird in [17] in c.a. 79 Stunden gelo¨st
(u¨bliche Genauigkeitsschranke, Jacobi-Iteration, 26 Prozesse). ASYNC beno¨tigt fu¨r das glei-
che Modell c.a. 8 Stunden (u¨bliche Genauigkeitsschranke, 6 Worker -Prozesse, vgl. Tab. 6.5).
Beim Performance-Vergleich ist allerdings zu beachten, dass unterschiedliche Abbruchkriterien
angewendet werden (Bell normiert den Residualvektor mit der Maximum-Norm des Iterations-
vektors, hier wird der Residualvektor mit der 1-Norm des Iterationsvektors normiert) und dass
die Laufzeitumgebung unterschiedlich ist. Bell benutzt ein Rechner-Cluster mit deutlich mehr
Einzelrechnern (26 Dualprozessoren, hier: 6 Dualprozessoren), dafu¨r haben seine Einzelrechner
eine geringere Rechenleistung und weniger Arbeitsspeicher und die maximal verfu¨gbare Band-
81
breite des Kommunikationsmediums ist geringer (100 Mbit/s vs. 1Gbit/s).
Nachfolgend wird aufgezeigt, wo mit den hier zur Verfu¨gung stehenden Rechen- und Platzres-
sourcen Engpa¨sse bei der ASYNC -Anwendung auftreten.
Zeit-Engpass Die Lo¨sung des SUH1-Modells (k=6) mit 6 Worker -Prozessen beno¨tigt fu¨r eine
Genauigkeitsschranke von ‖‖∞ < 10−7 (vgl. Gl. 4.10) 44 900 Sekunden bzw. 12, 5 Stunden, vgl.
Tab. 6.5. Die Beantwortung der Frage, ob derartige Lo¨sungszeiten akzeptabel sind oder nicht,
wird stets auch subjektiv beeinflusst sein. Eine Lo¨sungszeit von 12, 5 Stunden ist akzeptabel,
wenn eine Berechnung ausserhalb der gewo¨hnlichen Arbeitszeiten, in denen Rechen-, Platz und
Kommunikationsressourcen weniger beansprucht sind, ausgefu¨hrt werden kann. Bei einer Akzep-
tanzbetrachtung ist des Weiteren zu beru¨cksichtigen, dass mit einer Genauigkeitsschranke von
10−7 ein vergleichsweise schwaches Abbruchkriterium gesetzt ist. Legt man den u¨blichen Richt-
wert von 10−9 als Schranke zugrunde, gelangt man fu¨r das SUH1-Modell bereits zu Lo¨sungszeiten
von knapp 20 Stunden.
Die Lo¨sung des SUH2-Modells (k=7) mit 6 Worker -Prozessen beno¨tigt fu¨r eine Genauigkeits-
schranke von ‖‖∞ < 10−9 63 560 Sekunden bzw. 17, 7 Stunden. Der numerische Aufwand ge-
messen in der Anzahl der Iterationsschritte ist trotz verscha¨rfter Genauigkeitsschranke geringer
als der numerische Aufwand fu¨r das SUH1-Modell, vgl. Tab. 6.5. Deswegen ist die Lo¨sungszeit
fu¨r das SUH2-Modell trotz gro¨ßerem Zustandsraum nahezu unvera¨ndert.
Das gro¨ßte gelo¨ste Modell in dieser Arbeit ist das SUH3-Modell mit 896 958 393 Zusta¨nden, vgl.
Tab. 6.5.
Modell n p ‖‖∞ T (p)
p∑
i=1
T cpui (p)
SUH1 k=6 423 807 404 6 10−7 12:28:20 74:40:01
SUH2 k=7 588 759 872 6 10−9 17:39:20 105:43:30
SUH3 k=7 896 958 393 14 10−9 55:27:00 608:29:26
FMS k=12 111 414 940 6 10−9 8:15:32
Tabelle 6.5: Lo¨sungszeiten (USER und CPU) fu¨r sehr große Modelle
Die Lo¨sung des SUH3-Modells mit 14 Worker -Prozessen beno¨tigt fu¨r eine u¨bliche Genauig-
keitsschranke gut 55 Stunden. Im Unterschied zu allen anderen Experimenten, die in dieser
Arbeit dokumentiert sind, war es hier erforderlich, die Anzahl innerer Iterationsschritte (vgl.
Abschnitt 4.3) von 4 auf 6 heraufzusetzen. Fu¨r 4 innere Schritte stagnierte die hierarchische
ASYNC -Iteration bei geringer Genauigkeit.
Insgesamt werden wa¨hrend der Lo¨sung 1 167 228 Vektoren mit einem Datenvolumen von 8.4496 TB
(Tera Bytes) transferiert, vgl. Tab. 6.6. Dies ergibt eine durchschnittliche Gro¨ße von 7.59 MB je
Vektor. Die durchschnittliche Gro¨ße kann unabha¨ngig von der Lastverteilung u¨ber die mittlere
Blockgro¨ße in der Generatormatrix (hier Dimension =896 958 393/792 = 1 132 523) gescha¨tzt
werden. Die Scha¨tzung liefert 8.64 MB je Vektor (jeder double-Eintrag beno¨tigt 8 Bytes).
Platz-Engpass In Tab. 6.7 ist der durchschnittliche Platzaufwand je Prozess (Spalte Total)
fu¨r das SUH1-Modell mit den Parametern k=6 und k=7 angegeben. Die Haupttreiber des Platz-
aufwands in den Prozessen sind der anteilige Iterationsvektor (It-Vek), die anteiligen Elemente
82
i data [TB] msg Iter T cpui (14) [s]
1 0.471283 60399 1181 182575
2 0.582539 72289 912 182534
3 0.647370 96658 1309 186497
4 0.628352 76490 1288 186241
5 0.778952 113684 1103 187715
6 0.515213 62157 759 188318
7 0.751338 107682 950 122691
8 0.729364 114305 971 122114
9 0.775837 99771 930 161088
10 0.533634 70584 877 162575
11 0.669291 111510 1278 178835
12 0.754863 101648 1749 184893
13 0.367509 47691 393 88569
14 0.244060 32360 226 55921
∑ 8.449600 1167228 - 2190566
Tabelle 6.6: Statistiken zur 14-Prozess-Lo¨sung des SUH3-Modells mit 896 958 393 Zusta¨nden
der Hauptdiagonalen der Generatormatrix Q ( Dg-Vek), der lokale Empfangspuffer (Puf) und
diverse Vektoren fu¨r Zwischenresultate (Rest). Aufgefu¨hrt sind jeweils Mittelwerte u¨ber die
beteiligten Worker -Prozesse. Einzelne Worker -Prozesse ko¨nnen demnach mehr Platz beno¨tigen
als hier angegeben.
Mit den zur Verfu¨gung stehenden Rechen- und Platzressourcen (10 Rechner mit 6 GB Ar-
beitsspeicher und 3 GB Platzlimit je Prozess, vgl. Abschnitt 5.3) kann das SUH1-Modell mit
k = 6 ab p = 4 Worker -Prozessen gelo¨st werden. Leider ist das SUH1-Modell mit k = 7 nicht
behandelbar, da der durchschnittliche Platzaufwand je Worker -Prozess fu¨r p = 12 3.13 GB
betra¨gt. Durch eine Erho¨hung der Prozessanzahl p kann der Platzaufwand je Worker -Prozess
unter 3 GB gedru¨ckt werden. Damit unterschreitet man zwar das Platzlimit je Prozess, sto¨ßt
aber an die Grenze des Arbeitsspeichers. Beispielsweise fu¨r p = 18 und 6 Rechner beno¨tigt
man 3 · 2.69GB = 8.07GB > 6GB. Ein Erho¨hung der Anzahl der Rechner auf 9 wu¨rde dieses
Problem lo¨sen, erzwingt aber Rechner aus beiden Rechner-Cluster zu nutzen. In diesem Fall
tritt jedoch ein Engpass im Inter-Cluster-Netzwerk auf, siehe Abschnitt zu “Kommunikation-
Engpass” unten.
Kommunikation-Engpass Bereits bei Modellen mit wenigen Millionen Zusta¨nden kommt
es zu Engpa¨ssen und Instabilita¨ten, wenn man Netzwerke mit 10 Mbit/s- und 100 Mbit/s-
Verbindungen einsetzt, vgl. Abschnitt 6.1.1.
Fu¨r die Berechnungen mit ASYNC stehen zwei Rechner-Cluster zur Verfu¨gung, die u¨ber das
10/100 MBit/s Netzwerk verbunden sind, vgl. Abb. 5.4. Wenn fu¨r die Lo¨sung sehr großer Modelle
Rechner aus beiden Clustern genutzt werden (lo¨st u.U. den Platzengpass, s.o.) wird das Netz-
werk zum Engpass. Die Daemon-Prozesse beanspruchen zunehmend viel Speicher fu¨r ha¨ngende
Nachrichten. Beispielsweise fu¨r das SUH1-Modell mit k=6 erreicht nach etwa 10 Iterationen
(25 Minuten) der erste Daemon-Prozess das 3 GB Platzlimit und abgewiesene Speicherplatzan-
forderungen fu¨hren zum Absturz.
83
SUH1 k=6 SUH1 k=7
p It-Vek Dg-Vek Puf Rest Total It-Vek Dg-Vek Puf Rest Total
1 3.16 3.16 0.00 0.02 6.34 9.78 9.78 0.00 0.03 19.59
2 1.58 1.58 0.73 0.02 3.92 4.89 4.89 2.10 0.03 11.91
4 0.79 0.79 0.70 0.02 2.30 2.45 2.45 2.29 0.03 7.22
6 0.53 0.53 1.05 0.02 2.13 1.63 1.63 2.06 0.03 5.35
8 0.40 0.40 0.59 0.02 1.41 1.22 1.22 1.80 0.03 4.27
10 0.32 0.32 0.64 0.02 1.30 0.98 0.98 1.70 0.03 3.69
12 0.26 0.26 0.63 0.02 1.17 0.82 0.82 1.46 0.03 3.13
18 0.18 0.18 0.46 0.02 0.84 0.54 0.54 1.58 0.03 2.69
SUH2 k=6 SUH2 k=7
p It-Vek Dg-Vek Puf Rest Total It-Vek Dg-Vek Puf Rest Total
1 1.57 1.57 0.00 0.02 3.16 4.39 4.39 0.00 0.02 8.80
6 0.26 0.26 0.35 0.02 0.89 0.73 0.73 1.59 0.02 3.07
Tabelle 6.7: Platzaufwand [GB] je Prozess fu¨r sehr große Modelle
Innerhalb eines Rechner-Clusters mit 1 GBit/s Switch (vgl. Abb. 5.4 rechts und links) ko¨nnen
sehr große Modelle mit c.a. 0.5×109 Zusta¨nden verteilt gelo¨st werden, vgl. z.B. das SUH2-Modell
mit k = 7 (588 759 872 Zusta¨nde) und 6 Worker -Prozessen. Die durch ASYNC verursachte
Bandbreite beansprucht das Kommunikationsmedium ada¨quat. Engpa¨sse treten fu¨r sehr kleine
Modelle (0.5×106 Zusta¨nde) und Modelle mit nahezu 1×109 Zusta¨nden auf. Bei kleinen Modellen
ist bedingt durch die kurzen Rechenzeiten die Iterationsrate und damit auch die Rate, mit der
Kommunikationen initiiert werden, extrem hoch. Es ist pragmatisch, bei kleinen Modellen einen
sequentiellen Lo¨ser anzuwenden, der gewo¨hnlich nur wenige Minuten beno¨tigt.
6.2 Performance Modellierung
Die Messung und Modellierung der Performance von ASYNC zielt auf eine Reduktion der
Lo¨sungszeit ab. Weil ASYNC ein iteratives Lo¨sungsverfahren implementiert, ha¨ngt die Lo¨sungs-
zeit von der Anzahl und der Dauer auszufu¨hrender Iterationsschritte ab. Eine modellbasierte
Performance-Bewertung von ASYNC macht es deswegen notwendig, mathematische Modelle (er-
fassen Konvergenzrate) und algorithmische Modelle (erfassen Zeit einzelner Iterationsschritte)
integrativ zu analysieren.
Die Abb. 6.7 zeigt das Konzept einer integrativen Performance- und Konvergenzanalyse. Der
Ausgangspunkt ist ein Performance-Modell, das zwei Aufgaben erfu¨llt (angedeutet durch ausge-
hende Pfeile 4 und 5): es liefert eine Scha¨tzung des Zeitverbrauchs time(t) einzelner Iterations-
schritte t und das (implizite) Szenario einer asynchronen Iteration (vgl. Def. 5.8). Das Szenario
einer hierarchischen Iteration (= Anzahl innerer Iterationsschritte, vgl. Def. 5.3) und die Asyn-
chronita¨tskonstante B (vgl. Bed. 4.7) parametrisieren das Performance-Modell, weil die Anzahl
innerer Iterationen (bestimmt Rechenphasendauer, vgl. Abschnitt 6.1.3 und Kommunikationsra-
te) und die Asynchronita¨tskonstante (verursacht bedingte Synchronisationspunkte falls B <∞)
die Dauer der Iterationsschritte beeinflussen. Der Interpretation des hierarchischen Szenarios
als a-priori bekannter Parameter liegt die Annahme zugrunde, dass die Anzahl innerer Iterati-
onsschritte nicht durch die (a-priori unbekannte) Numerik gesteuert wird (Abbruch u¨ber lokale
Genauigkeitsschranken).
84
S c e n a r i oH i e r a r c h i c a lI t e r a t i o n
A s y n c h r o n o u sM e a s u r e  B
P e r f o r m a n c eM o d e l
S c e n a r i oA s y n c h r o n o u sI t e r a t i o n
t i m e ( t )E s t i m a t e
C o n v e r g e n c eM o d e l
C o n v .  R a t eE s t i m a t e
E x e c u t i o nT i m eE s t i m a t e
4
3
2
5
9
6
1 8
7
Abbildung 6.7: Konzept Performance-Modellierung hierarchischer und asynchroner Iterationen
Casanova [35] sowie U¨resin und Dubois [96] sind Referenzen fu¨r eine integrative Performance-
Bewertung asynchroner Iterationen. Casanova nutzt mathematische Modelle und Resultate von
Baudet [9], U¨resin und Dubois greifen auf Resultate von Bertsekas und Tsitsiklis [19] zuru¨ck,
vgl. auch Abschnitt 5.2.3.
Baudet sowie Bertsekas und Tsitsiklis geben fu¨r unterschiedliche Varianten asynchroner Iteratio-
nen eine theoretische asynchrone Konvergenzrate in Abha¨ngigkeit von (impliziten) theoretischen
synchronen Konvergenzrate an, vgl. Abschnitt 5.2.3. Ihre Kernaussage ist, dass mit Zunahme
der Synchronita¨t in asynchronen Iterationen die theoretische asynchrone Konvergenzrate steigt.
Die Crux hierbei ist, dass die Aussage sehr schwach ist, die Abscha¨tzung der theoretischen asyn-
chronen Konvergenzrate basiert auf der theoretischen synchronen Konvergenzrate, die selbst nur
eine Abscha¨tzung der realen Konvergenzrate ist.
Casanova sowie U¨resin und Dubois konstruieren stochastische Modelle zur Bewertung der Aus-
fu¨hrungszeit time(t) einzelner oder mehrere asynchroner Iterationsschritte. Die asynchronen
Schritte sind so konstruiert, dass theoretische Ergebnisse zur Konvergenz anwendbar sind, nach
denen gema¨ß der mathematischen Modelle die asynchrone Iteration spa¨testens einen Fortschritt
hin zur Lo¨sung erzielt. Wenn man die Art und Weise der “Konstruktion” der asynchronen Schrit-
te genauer betrachtet, stellt man fest, dass sie sehr spezifische Typen asynchroner Iterationen
verwenden. Die Spezifik liegt in “versteckter” Synchronita¨t oder auch in Eigenschaften, die in
realen Implementierungen asynchroner Iterationen nicht sinnvoll, teilweise sogar nicht erfu¨ll-
bar sind. Beispielsweise lassen U¨resin und Dubois keine Kommunikationsverzo¨gerungen zu und
schra¨nken die Auswahlreihenfolge zu iterierender Komponenten ein (“Age-Scheduling”). Casa-
nova fu¨hrt bedingte Synchronisationspunkte ein und separiert Berechnung und Kommunikation
strikt, was aus praktischer Sicht keinen Sinn macht (keine gleichma¨ßige Belastung des Kommuni-
kationsmediums). Durch diese Restriktionen erfu¨llen die betrachteten (a)synchronen Iterationen
Anforderungen der mathematischen Modelle bzgl. dem Szenario der asynchronen Iteration, vgl.
Abb. 6.7. Im Gegensatz zu U¨resin und Dubois erlaubt Casanova Kommunikationszeiten. Dies
hat zur Folge, dass sein stochastisches Performance-Modell nicht analytisch behandelbar ist,
weil es gewisse Zufallsvariablen beinhaltet, deren Charakteristik implizit ist. Deswegen muss er
die implizite Charakteristik durch ein Simulationsmodell quantifizieren, dessen Erstellung sehr
aufwendig und dessen Auswertung in einigen Punkten unklar ist.
Im nachfolgenden Abschnitt wird eine im Vergleich zu Casanova sowie U¨resin und Dubois ande-
re Vorgehensweise gewa¨hlt. Es werden ausschlielich praxisrelevante Implementierungen schwach
asynchroner Iterationen betrachtet, die keinen Restriktionen unterliegen, die durch mathema-
85
tische Modelle oder die analytische Behandelbarkeit erzwungen werden. Fu¨r die schwach asyn-
chronen Iterationen werden stochastische Modelle zur zeitlichen Bewertung der Iterationsschrit-
te entwickelt und hinsichtlich ihrer analytischen Behandelbarkeit kategorisiert. Dann werden
die schwach asynchronen Iterationen zunehmend “entsynchronisiert” und im Detail untersucht,
warum die Asynchronita¨t die analytische Behandelbarkeit erschwert.
6.2.1 Performance Modelle
Eine stochastische Performance-Modellierung verteilt ablaufender synchroner und asynchroner
Iterationen ist in 3 Schritte unterteilbar:
1. Modellparameter : Definition stochastischer Variablen, die a-priori bekannte Zeitver-
bra¨uche in der Iteration erfassen.
2. Modellbildung : Konstruktion eines analytischen Modells, das einen Zusammenhang
zwischen den Modellparametern und der interessierenden Performance-Gro¨ße (= stocha-
stische Variable) herstellt.
3. Modellanalyse : Berechnung charakterisierender Gro¨ßen (Verteilungsfunktion, Momente
etc) der stochastischen Performance-Variable.
Nachfolgend soll verdeutlicht werden, dass die Konstruktion analytischer stochastischer Modelle
bereits fu¨r schwach-asynchrone Iterationen aufwendig ist. Hierzu sind in Tab. 6.8 Implemen-
tierungsvarianten fu¨r Worker -Prozesse aufgefu¨hrt, welche als Fortsetzung der Varianten aus
Tab. 5.4 anzusehen sind.
Variante 4: Variante 5: Variante 6:
repeat repeat repeat
barrier sync barrier sync barrier sync
for all c ∈ R(p) for all c ∈ R(p) for all c ∈ R(p)
solve pi[c] ·Q[c, c] = b[c] solve pi[c] ·Q[c, c] = b[c] solve pi[c] ·Q[c, c] = b[c]
put pi[c] for all c ∈ R(p) asy send pi[c]
asy send pi[c]
for all c ∈ R(p) for all c ∈ R(p)
sync b[c] sync b[c]
until convergence until convergence until convergence
Tabelle 6.8: Modelle asynchroner Iterationen und ihre Implementierungen (Prozess p)
Notation und Annahmen fu¨r die Algorithmen in Tab. 6.8: Es seien R die Lastver-
teilung und R(p) die Blo¨cke, die Prozess p zugeordnet sind. Ein repeat - until Schleifen-
durchlauf sei per Definition ein Iterationsschritt. Der “barrier sync”-Befehl realisiert einen
Synchronisationspunkt, der blockiert, bis alle Prozesse den “barrier sync”-Befehl aufrufen.
“solve pi[c] ·Q[c, c] = b[c]” verweist auf die iterative Lo¨sung eines Blocks mit Index c. Danach
86
startet die Kommunikation via Zugriff auf den geteilten Speicher mit “put pi [c]” (nur Vari-
ante 4) bzw. mit den asynchronen Sendebefehlen “asy send pi [c]” (Varianten 5 und 6). Der
“sync b[c]”-Befehl realisiert eine datenabha¨ngige Synchronisation und blockiert bis alle zu b[c]
beitragenden, kommunizierten pi[·]-Vektoren aus dem aktuellen oder aus dem vorherigen Itera-
tionsschritt stammen, vgl. Gl. 5.1.
Die Befehle “barrier sync”, “solve..” und “sync..” sind zeitbehaftet, die restlichen zeitlos. Der
Zeitverbrauch fu¨r “solve..” ist a-priori abscha¨tzbar, die Dauer der Synchronisationsphasen in
“barrier sync” und “sync..” ist durch die implizte Dynamik des Ablaufs bestimmt und damit
implizit.
Die Algorithmen in Tab. 6.8 enthalten keine Befehle zum Empfangen von Daten. Es wird ange-
nommen, dass der Daten-Empfang durch einen separaten “Message-Handler” ausgefu¨hrt wird,
so dass die Worker -Prozesse nicht aktiv am Empfang partizipieren mu¨ssen, vgl. Abschnitt 5.6.3
zur “Asynchronen Kommunikation mit Puffer”, insbesondere “One-sided”-Kommunikation. Dies
bedeutet, dass ein Daten-Empfang nebenla¨ufig zu allen Befehlen im Algorithmus mo¨glich ist.
1. Modellparameter : Es ist |P| die Anzahl der Worker -Prozesse und N die Anzahl der
Blo¨cke (zu lo¨senden Teilprobleme). Es seien I1, . . . , IN unabha¨ngige kontinuierliche und
nicht-negative Zufallsvariablen, die Zeitintervalle einzelner innerer Iterationsschritte im
“solve..”-Befehl erfassen. Es wird angenommen, dass “solve..”-Befehle immer mit q in-
neren Schritte ausgefu¨hrt werden, vgl. Abschnitt 4.3 zu “Modellen hierarchischer Iteratio-
nen”. Des Weiteren seien
C1→1, . . . , CN→1, . . . . . . C1→|P|, . . . , CN→|P|
N · |P|-viele unabha¨ngige kontinuierliche und nicht-negative Zufallsvariablen, die den Zeit-
verbrauch fu¨r Nachrichten mit “Block-Index → Empfa¨nger-Prozess-Index” erfassen.
2. Modellkonstruktion : Es sei I die Ausfu¨hrungszeit eines verteilten, synchronen Iterati-
onsschritts (repeat - until Schleifendurchlauf). Ein Performance-Modell fu¨r I basiert auf
Summationen involvierter Zufallsvariablen (Zeitverbra¨uche werden sequentiell verursacht)
und Maximumbildung involvierter Zufallsvariablen (langsamster Prozess oder langsam-
ste Nachricht bestimmt Ausfu¨hrungszeit). Die Gl. 6.1 bis 6.3 repra¨sentieren stochastische
Modelle der Implementierungsvarianten aus Tab. 6.8 zur Bewertung von I.
I = max
p∈P
q
∑
c∈R(p)
Ic (6.1)
I = max
p∈P

q
∑
c∈R(p)
Ic + max
c∈R(p)
p′ 6=p
Cc→p′

 (6.2)
I = max
p∈P
max
l=1...|R(p)|
(
q
l∑
i=1
IRi(p) + maxp′ 6=p CRl(p)→p′
)
(6.3)
Das Modell 6.1 hat eine einfache Strukur, weil keine Kommunikationsverzo¨gerungen auf-
treten. Die Maximumbildung u¨ber P selektiert den langsamsten Prozess, dessen Iterati-
onsdauer durch die Summe der Ic-Variablen gegeben ist.
Die Beru¨cksichtigung des stochastischen Einflusses zeitbehafteter Kommunikation macht
stochastische Modelle komplexer, vgl. Gl. 6.2 und 6.3.
87
Die Maximumbildung u¨ber P in Gl. 6.2 selektiert den “kritischen Prozess”, der die Itera-
tionsdauer bestimmt. Hierfu¨r betrachtet man analog zu Variante 4 fu¨r jeden Prozess p den
Zeitverbrauch in den “solve..”-Anweisungen und addiert die maximale Kommunikations-
zeit der durch p initiierten Nachrichten an Prozesse p′ 6= p.
In Variante 5 werden alle Daten gleichzeitig verschickt, demgegenu¨ber sind in Variante 6
die Startzeitpunkte in die Berechnungen (“solve..”) eingebettet und somit unterschied-
lich. Deswegen sind in Gl. 6.3 Maximumbildungen und die Summation im Vergleich zu
Gl. 6.2 modifiziert. Die innere Maximumbildung vor der Klammer bestimmt die Zeitdauer
von Prozess p fu¨r die Ausfu¨hrung von l-vielen “solve..”-Anweisungen vermehrt um die
maximale Kommunikationszeit der durch p initiierten Nachrichten an Prozesse p ′ 6= p.
Dabei verweise Ri(p) auf das i-te Element der Menge R(p). Die Reihenfolge der Elemente
in R(p) bzw. die Reihenfolge der “solve..”-Anweisungen beeinflusst I. Die a¨ußere Maxi-
mumbildung selektiert wiederum den “kritischen Prozess”.
3. Modellanalyse : Aus der Wahrscheinlichkeitsrechnung bekannte Zusammenha¨nge ermo¨gli-
chen die stochastischen Modelle in Gl. 6.1 bis 6.3 zu analysieren, vgl. etwa [61]. Die in
Gl. 6.1 bis 6.3 involvierten Zufallsvariablen sind durch Summen- und Maximumoperatoren
verknu¨pft. Die Dichtefunktion der Summe unabha¨ngiger Zufallsvariablen ist die Faltung
der individuellen Dichtefunktionen der Zufallsvariablen [61]. Die Verteilungsfunktion des
Maximums u¨ber Zufallsvariablen ist das Produkt der individuellen Verteilungsfunktionen
der Zufallsvariablen [61].
Analyse Gleichung 6.1 Bei der Analyse sind 3 Fa¨lle (a),(b) und (c) zu unterscheiden:
(a) 1 Block je Prozess (∀p ∈ P : |R(p)| = 1).
In diesem Fall vereinfacht sich Gl. 6.1 zu
I = max(q · I1, . . . , q · IN )
und die Verteilungsfunktion von I ist
FI(x) = P [q · Ic ≤ x|∀c = 1 . . . N ] =
N∏
j=1
FIj (
x
q ).
(b) max. 2 Blo¨cke je Prozess (∀p ∈ P : |R(p)| ≤ 2).
Es sei 2 ·N = |P| und der Prozess 1 lo¨se die Blo¨cke 1 und 2 usw. bis Prozess p lo¨se
die Blo¨cke 2 · p− 1 und 2 · p. Dann nimmt die Gl. 6.1 folgende Form an:
I = max(q · (I1 + I2), . . . , q · (I2p−1 + I2p)).
Ein Szenario mit 2 Prozessen ist in Abb. 6.8 veranschaulicht.
Die Dichtefunktion von I1 + I2 fI1+I2 ist die Faltung von fI1 und fI1 . Somit gilt
FI(x) = P [q · (I1 + I2) ≤ x] · . . . · P [q · (I2p−1 + I2p) ≤ x] (6.4)
=
∫ x
q
0
fI1+I2(z) dz · . . .
=
∫ x
q
0
∫ z
0
fI1(k) · fI2(z − k) dk dz · . . . (6.5)
88
I 1 I 1 I 2 I 2
I 3 I 3 I 4 I 4
m a x ( 2  ( I 1 + I 2 ) ,  2  ( I 3 +  I 4 ) ) =  2  ( I 3 + I 4 )
Abbildung 6.8: Visualisierter Trace mit 2 Prozessen, Barrieren-Synchronisation und zeitloser
Kommunikation
Die Frage nach der analytischen Behandelbarkeit der Faktoren (=Fla¨chenintegrale)
in Gl. 6.5 ist nur in Abha¨ngigkeit von fI1 und fI2 zu beantworten. Falls die I∗ Va-
riablen exponentiell verteilt sind, ist fI1+I2 und FI1+I2 analytisch (= Dichte- und
Verteilungsfunktion der Hypoexponetialverteilung mit zwei Phasen). Es ist vermut-
lich realistischer anzunehmen, dass die I∗ Variablen normal verteilt sind, weil ein in-
nerer Iterationsschritt zahlreiche stochastisch-zeitbehaftete Operationen additiv ein-
schließt. Wenn I1 und I2 durch eine Normalverteilung mit m1 , E[I1], m2 , E[I2]
und V [I1] = V [I2] = 1 gegeben sind, dann ist die Faltung der Dichtefunktionen von
I1 und I2 (inneres Integral in Gl. 6.5) analytisch ausfu¨hrbar und liefert
∫ ∞
−∞
fI1(k) · fI2(z − k) dk =
1
2√pi exp(−
1
4z
2 + z 12(m1 −m2)−
1
4(m
2
1 −m22 − 2m1m2)
(6.6)
Die Integralgrenzen in Gl. 6.6 laufen nun von −∞ bis∞, weil I∗ auch negative Werte
annehmen kann (Normalverteilung). Die rechte Seite von Gl. 6.6 eingesetzt in Gl. 6.5
ergibt
FI(x) =
1
2√pi exp(−
1
4(m
2
1−m22−2m1m2))
∫ x
q
0
exp(−14z
2+z 12(m1−m2)) dz·. . . (6.7)
Der Integrand in Gl. 6.7 ist eine Exponentialfunktion mit quadratischer innerer Funk-
tion. Hier ist eine Stammfunktion nicht geschlossen darstellbar, vgl. Verteilungsfunk-
tion der Normalverteilung [61].
(c) >2 Blo¨cke je Prozess
Die Aufgabe ist nun die Berechnung von Wahrscheinlichkeiten der Form
P [I1 + I2 + I3 ≤
x
q ],
innerhalb von Gl. 6.4. Ab diesem Punkt muss man auf das Instrumentarium charak-
teristischer Funktionen zuru¨ckgreifen. Die charakteristische Funktion (bzw. Laplace-
Transformierte) der Summe endlich vieler unabha¨ngiger Zufallsvariablen ist gleich
dem Produkt der charakteristischen Funktionen dieser Zufallsvariablen [61]. Dies be-
deutet hier, wenn fu¨r I1, I2 und I3 charakteristische Funktionen bekannt sind, ist auch
die charakteristische Funktion fu¨r I1 + I2 + I3 als Produkt dieser charakteristischen
Funktionen berechenbar. Andererseits gilt: durch die charakteristische Funktion ist
auch die Verteilungsfunktion eindeutig bestimmt [61]3. Dies bedeutet hier, dass mit
3Satz von Levy, siehe Satz 4.5.1 in [61]
89
der charakteristischen Funktion fu¨r I1+I2+I3 die Verteilung von I1+I2+I3 eindeutig
definiert ist. Ob eine Verteilung von I1 +I2 +I3 geschlossen berechenbar ist, kann nur
fu¨r konkrete Verteilungen von I1, I2 und I3 bzw. der durch sie definierten charakteri-
stischen Funktionen beantwortet werden. Wenn die Verteilungsfunktion von ∑c∈R Ic
bekannt ist, kann die Verteilungsfunktion fu¨r I (Maximum) definiert werden.
Analyse Gleichung 6.2 Die Verteilungsfunktion der maximalen Kommunikationsverzo¨-
gerung (innere Maximumbildung) ist das Produkt der Verteilungsfunktionen FCc→p′ . Damit
ist die charakteristische Funktion der maximalen Kommunikationsverzo¨gerung definiert
und es kann wie im Fall 3c beschrieben vorgegangen werden.
Analyse Gleichung 6.3 Die Gl. 6.3 ist strukturell identisch zu Gl. 6.2. Man hat eine
Maximumbildung u¨ber Zufallsvariablen, die durch eine Summe definiert sind. Der erste
Summand ist eine Summe dedizierter I∗ Zufallsvariablen und der zweite Summand ist das
Maximum u¨ber dedizierte C∗ Zufallsvariablen. Deswegen ist die Analyse von Gl. 6.3 analog
zu der von Gl. 6.2.
Ein Fazit: Fu¨r synchronisierte Varianten asynchroner Iterationen aus Tab. 6.8 ko¨nnen stochasti-
sche Performance-Modelle fu¨r I aufgestellt werden, vgl. Gl. 6.1 bis 6.3. Die Verteilungsfunktion
FI ist in jedem Fall definierbar, ob sie auch geschlossen angegeben werden kann, ha¨ngt von
den Verteilungs- und Dichtefunktionen der involvierten Zufallsvariablen fu¨r die zeitliche Bewer-
tung der Rechen- und Kommunikationszeiten ab. Vorbedingung fu¨r alle Analyseansa¨tze ist die
Unabha¨ngigkeit involvierter Zufallsvariablen.
Nun soll der Frage nachgegangen werden, wie sich eine “Entsynchronisation” der Implemen-
tierungen aus Tab. 6.8 auf die analytische Behandelbarkeit korrespondierender stochastischer
Modelle auswirkt. Aus der Theorie der Warteschlangen-Netze ist bekannt, das Synchronisations-
Mechanismen die analytische Behandelbarkeit erschweren und deren Aufhebung aus der Sicht
der Analyse wu¨nschenswert ist. Andererseits kann - wie nachfolgend gezeigt wird - eine Auf-
hebung von Synchronisationspunkten neue stochastische Einflussgro¨ßen einfu¨hren und so die
Analyse erschweren. Konkret besteht die betrachtete “Entsynchronisation” in der Aufhebung
der Barrieren-Synchronisation im “barrier sync”-Befehl. Diese Modifikation bewirkt, dass die
Varianten 5 und 6 im “sync b[c]”-Befehl bis zu unterschiedlichen absoluten Zeiten synchronisie-
ren, vgl. gestrichelte Linien in Abb. 6.9.
Die Variante 4 hat keine Synchronisationspunkte und alle Prozesse iterieren mit individueller
Rate. Dies verletzt die Bedingung der “regulated updating sets” (vgl. Bedingung 4.7, Gl. 4.27
auf S. 36). Diese Bedingung ist jedoch essentiell fu¨r die Bewertung der Konvergenzrate, vgl. zum
Beispiel Abschnitt 5.2.2, Absatz 2 auf S. 46. Deswegen wird fu¨r Variante 4 kein stochastisches
Modell vorgestellt.
1. Modellparameter : Es sei Tp(t) der absolute Startzeitpunkt von Iteration t im Prozess p
und es sei Dp(t) die Zeitdauer des Schritts t im Prozess p, vgl. Abb. 6.9. Die Parameter P,
N , I∗ und C∗→∗ sind bereits im Absatz “Modellparameter” auf Seite 87 definiert worden.
2. Modellkonstruktion : Die Gl. 6.8 und 6.9 repra¨sentieren stochastische Modelle der Im-
plementierungsvarianten 5 und 6 ohne Barrieren-Symchronisation (vgl. Tab. 6.8) zur Be-
90
T ( t ) T ( t + 1 )
T 1 ( t )
T 2 ( t )
T 3 ( t )
T 1 ( t + 1 )
T 2 ( t + 1 )
T 3 ( t + 1 )
P r o z e s s  1
P r o z e s s  2
P r o z e s s  3
Abbildung 6.9: Visualisierter Trace mit 3 Prozessen ohne Barrieren-Synchronisation
wertung von Dp(t).
Dp(t) = max
(
A, max
p′ 6=p
(
Tp′(t)− Tp(t) + B
)
)
und (6.8)
Dp(t) = max
(
A, max
p′ 6=p
(
Tp′(t)− Tp(t) + B
)
)
mit (6.9)
A , q
∑
c∈R(p)
Ic und
B ,



q ∑
c∈R(p′)
Ic + max
c∈R(p′)
Cc→p fu¨r Gl. 6.8
max
l=1...|R(p′)|
(
q
l∑
i=1
IRi(p′) + CRl(p′)→p
)
fu¨r Gl. 6.9
Die stochastische Modellierung muss zwei Fa¨lle in der algorithmischen Ausfu¨hrung asyn-
chroner Iterationen unterscheiden:
(a) Ein Prozess p empfa¨ngt alle Nachrichten vor Erreichen des “sync b[c]”-Befehls. In
diesem Fall ist der Aufruf des “sync b[c]”-Befehls zeitlos und Dp(t) ha¨ngt allein
von den I∗-Variablen ab. Dies wird durch den A-Term in Gl. 6.8 und 6.9 erfasst. Im
Beispiel-Trace aus Abb. 6.9 zeigt Prozess 1 im t-ten Schritt dieses Verhalten.
(b) Anderenfalls wirdDp(t) durch die Dynamik der “Umgebung” von Prozess p bestimmt,
vgl. B-Term. Die innere Maximumbildung u¨ber p′ 6= p in den Gl. 6.8 und 6.9 selektiert
mit dem B-Term den aus Sicht von Prozess p “kritischen Prozess”. Ein Prozess p ′ ist
kritisch, wenn er die Ausfu¨hrungszeit von Prozess p bestimmt. Im Beispiel-Trace aus
Abb. 6.9 ist aus der Sicht von Prozess 2 der Prozess 1 kritisch und aus der Sicht von
Prozess 3 der Prozess 2. Die B-Terme a¨hneln Gl. 6.2 und 6.3, die ebenfalls “kritische
Prozesse” selektieren. Der wesentliche Unterschied ist der Zusatz der T∗(t)-Variablen.
Die Korrektur durch die Differenz Tp′(t)−Tp(t) beru¨cksichtigt unterschiedliche Start-
zeitpunkte des aktuellen Schritts t in den Prozessen p und p′.
Die a¨ußere Maximumbildung max(A, . . . B) in Gl. 6.8 und 6.9 selektiert aus zwei nebenla¨ufi-
gen “Prozessen” (lokale Berechnung, Berechnung und Kommunikation der Umgebung) den
Prozess, der die lokale Performance im Schritt t bestimmt.
91
3. Modellanalyse : Die Analysis der stochastischen Modelle 6.8 und 6.9 wird durch den
Umstand erschwert, dass die Werte der involvierten Tp(t)-Variablen implizit sind. T (t) ,
(T1(t), . . . , T|P|(t)) ist als ein |P|-dimensionaler zeitdiskreter stochastischer Prozess inter-
pretierbar, vgl. auch gestrichelte Linie Abb. 6.9. Seine kontinuierlichen Zusta¨nde kodieren
eine “Zeitinformation”, von der die Dynamik einzelner Iterationsschritte und damit auch
Dp(t) abha¨ngt. In die Gleichungen 6.8 und 6.9 gehen Zeit-Differenzen ein. Der (|P| − 1)-
dimensionale zeitdiskrete stochastische Prozess
∆(t) , (T2(t)− T1(t), . . . , T|P|(t)− T1(t)
)
kodiert die gleiche Zeitinformation. Aus ∆(t) sind sowohl Zeit-Differenzen Tp′(t) − Tp(t)
beliebiger Prozesse p und p′, als auch alle absoluten Zeiten Tp(1), Tp(2), . . . direkt ableitbar.
Eine weitere wichtige Beobachtung ist, dass der stochastische Prozess T (t) bzw. ∆(t) ein
Markov-Prozess ist. Die Verteilung der Zufallsvariablen Tp(t+ 1) ha¨ngt nur vom Zustand
x ∈ R|P| der Zufallsvariablen T (t) ab, denn
P[Tp(t+ 1) < y] = P [Tp(t) +Dp(t) < y] = P [Dp(t) < y − xp |T (t) = x]. (6.10)
In Gl. 6.10 sei xp die p-te Komponente des Zustand-Vektors x. Es ist wichtig anzumerken,
dass die bedingte Verteilung von Dp(t) rechts in Gl. 6.10 von der Bedingung T (t) = x
abha¨ngt und nicht nur etwa von Tp(t) = xp, weil in die Gl. 6.8 und 6.9 und damit auch in
die Verteilung von Dp(t) die Information u¨ber T (t) eingeht.
Wegen der Beziehung T (t + 1) = T (t) + D(t) mit D(t) , (D1(t), . . . , D|P|(t)) ist T als
ein Prozess mit “Zuwa¨chsen” interpretierbar. In der Theorie der zustandskontinuierlichen
Markov-Prozesse sind Prozesse mit unabha¨ngigen Zuwa¨chsen bedeutsam, weil sie analy-
tisch behandelbar sind [61]. Leider sind die Zufallsvariablen Dp(0), Dp(1), . . . hier nicht
unabha¨ngig, weil die Dp(t)-Verteilung von T (t) =
∑t−1
i=1 D(t) abha¨ngt.
Ein Fazit: Eine “Entsynchronisation” der schwach-asynchronen Iterationen aus Tab. 6.8 durch
Aufhebung der Barrieren-Synchronisation fu¨hrt zu stochastischen Modellen, die von einem Markov-
Prozess abha¨ngen, dessen Charakteristik wiederum durch implizite Systemgro¨ßen beeinflusst
wird. Eine analytische Lo¨sung ist nicht bekannt.
92
Kapitel 7
Verfu¨gbarmachung des ASYNC
Instrumentariums
Das ASYNC -Instrumentarium ist u¨ber die APNN-Notation (Petri-Netze) der APNN-Toolbox
und u¨ber die ProC/B -Schnittstelle benutzerfreundlich verfu¨gbar. Die ProC/B -Schnittstelle eta-
bliert eine anwendungsspezifische Schnittstelle fu¨r die Modellierung und Analyse logistischer
Systeme, vgl. Abb. 1.1. Durch automatisierte U¨bersetzer ist es mo¨glich, ProC/B -Modelle auf
Petri-Netz-Modelle in der APNN-Notation abzubilden. Aus diesen kann das analytische Modell
fu¨r ASYNC - die Markov-Kette - abgeleitet werden. Die Ansteuerung von ASYNC ist in die
graphische Benutzeroberfla¨che der APNN-Toolbox integriert.
Dieses Kapitel ist wie folgt strukturiert: im Abschnitt 7.1 wird die prozess-orientierte Model-
lierung mit der ProC/B -Notation eingefu¨hrt. Der Abschnitt 7.2 erla¨utert die Abbildung von
ProC/B -Modellen auf Petri-Netz-Modelle in der APNN-Notation. Mit bereits verfu¨gbaren Ver-
fahren kann aus der APNN-Notation eine Markov-Kette mit hierarchischer Kronecker-Algebra
generiert werden, vgl. Abschnitt 3.2. Im Abschnitt 7.3 wird diese spezifische Markov-Ketten-
Darstellung anhand einer konkreten Systemmodellierung exemplifiziert. Schließlich wird im Ab-
schnitt 7.4 die Ansteuerung von ASYNC u¨ber die graphische Benutzeroberfla¨che anhand eines
Anwendungsfalls erla¨utert.
93
7.1 Prozess-orientierte Modellierung mit ProC/B
Auf Prozessketten basierende Notationen wie zum Beispiel Ereignisgesteuerte Prozessketten [89]
oder UML-Aktivita¨tsdiagramme [69] haben sich in der Praxis als Beschreibungsmittel betrieb-
licher Abla¨ufe etabliert. Die Praxis der prozess-orientierten Modellierung technischer Systeme
wird durch zahlreiche Forschungsaktivita¨ten begleitet, die u.a. zur Gru¨ndung des Arbeitskreises
“Gescha¨ftsprozessmanagement mit Ereignisgesteuerten Prozessketten” in der Gesellschaft fu¨r
Informatik (GI)1 und des SFBs zur “Modellierung großer Netze in der Logistik” [15] fu¨hrten.
Letzterer hat die Entwicklung der ProC/B -Notation vorangetrieben.
Die ProC/B -Notation [11] unterstu¨tzt eine objekt- und prozess-orientierte sowie hierarchische
Sichtweise bei der Modellierung und hat sowohl Konzepte des Prozessketten-Paradigmas von
Kuhn [72] adoptiert, wodurch Anforderungen und Bedarfe des Anwendungsfeldes beru¨cksichtigt
sind, als auch Konzepte des Modellierungs- und Analyse-Tools HIT von Beilner [16], wodurch
eine hinreichend formale Beschreibung und eindeutige Interpretation des Modells als Vorausset-
zung fu¨r eine automatisierte U¨bersetzung in ein Leistungsmodell erreicht wird. Ein Alleinstel-
lungsmerkmal der ProC/B -Notation ist, dass sie synergetisch prozess- und objektfluss-orientierte
Sichtweisen verzahnt, so dass Nachteile einer rein objektfluss-orientierten Sichtweise (zeitlicher
Aspekt wird nur indirekt abgebildet) und prozess-orientierten Sichtweise (statische Aufbaustruk-
tur wird nur indirekt abgebildet) aufgehoben sind. Das ProC/B -Tool [11] bietet eine graphisch-
basierten Editor zur ProC/B -Modellbildung.
In diesem Abschnitt werden die Konzepte der ProC/B -Notation erla¨utert. ProC/B -Beispielmo-
dellierungen werden im Kapitel 8.2 behandelt.
Die ProC/B -Notation unterscheidet Konstrukte zur Modellierung von Systemstruktur und -
verhalten. Das zentrale “strukturierende” Konstrukt ist die Funktionseinheit (FE). Eine FE
repra¨sentiert ein modulares Teilsystem. Jede FE inkludiert Modellelemente einschließlich FEs
(hierarchische Aufbaustruktur durch Enthaltensein-Hierarchie), die gemeinsam eine klar definier-
te Funktionalita¨t anbieten. Die Funktionalita¨t einer FE wird u¨ber extern nutzbare Schnittstellen
(Dienste) angeboten. Eine FE beinhaltet Prozess-Ketten (PK), PK-Interfaces, Attribute und
unterliegende, “geschachtelte” FEs, vgl. Tabelle 7.1. Jede FE macht seine Funktionalita¨t durch
aufrufbare Dienste zuga¨nglich. Ein Dienst ist formal und im Detail durch eine PK-Spezifikation
definiert und kann u¨ber das PK-Interface aufgerufen werden. Die-PK Spezifikation definiert
eine inhaltlich abgeschlossene, zeitbehaftete und sachlogische Folge von Aktivita¨ten in Form
von PK-Elementen (PKE), die bei Dienstaufruf auszufu¨hren sind. Die einer FE zugeordneten PKs
lo¨sen somit ein Verhalten aus, das FE intern Zustandsa¨nderungen oder FE extern bestimmte
Reaktionen herbeifu¨hrt. Hierbei wird ein hierarchisches Sichtenkonzept realisiert, bei dem eine
FE nach außen sichtbare PK-Interfaces kapselt, die formale Implementierung der jeweiligen
Dienste durch die PK bleibt fu¨r die aufrufende Instanz verborgen. Sie registriert bei Dienstaufruf
via dem PK-Interface lediglich eine Zeitverzo¨gerung und/oder Werte von Ru¨ckgabeparame-
tern. Die Verhaltensmodellierung ist durch eine (ablauf/prozess)-orientierte Sichtweise gepra¨gt
und beinhaltet hierfu¨r ga¨ngige Konstrukte fu¨r die Instanziierung von Prozessen, Nebenla¨ufig-
keit, Synchronisation, boolsche und probabilistische Verzweigung und Zusammenfu¨hrung von
Prozessen (Konnektoren) und Schleifen.
Die PK-Spezifikation beinhaltet die Disposition (Zuordnung) von Ressourcen zu Aktivita¨ten, de-
ren Ausfu¨hrung Ressourcen erfordert. In der Nomenklatur der ProC/B -Notation ausgedru¨ckt
1http://epk.et-inf.fho-emden.de/index.php
94
ProC/B Element Symbol Semantik
Funktionseinheit (FE) modulares Systemteil (Komponenten-Semantik)
FE-Gesamtheit modelliert hierarchische Aufbaustruktur
Server aktive Ressource (Zeitverbrauch), Bedienstation-Semantik
Counter passive Ressource (Mengenverbrauch), Semaphor-Semantik
Prozess-Kette (PK) diverse ablauflogische Anordnung Aktivita¨ten (=PKE) im Prozess
Quelle  virtuelle oder aktive Prozess-Erzeugung (Lastquelle)
Senke ⊗ virtuelle oder aktive Prozess-Terminierung
PK-Interface Kringel Aufrufschnittstelle fu¨r PK
PK-Element (PKE) Basis PK-Baustein (Aktivita¨t)
Delay-PKE statischer/stochastischer Zeitverbrauch im Prozess
Code-PKE auszufu¨hrender HIT Programm-Code [16]
Loop-PKE kapselt PKEs in Schleife, boolsche/stochast. Abbruchbedingung
AND-SPLIT-Konnektor Prozess-Aufsplittung (“fork”)
AND-JOIN-Konnektor Prozess-Synchronisation
AND-Konnektor Kombination AND-SPLIT/JOIN-Konnektor
OR-SPLIT-Konnektor stochastische/boolsche Prozessverzweigung (“branch”)
OR-JOIN-Konnektor Prozesszusammenfu¨hrung (“join”)
PK-Konnektor a¨hnlich AND-Konnektor, erlaubt Erzeugung neuer Prozesse
FE-Variable textuell Variable mit Geltungsbereich in FE
PK-Parameter textuell Aufrufparameter fu¨r PK (=Geltungsbereich)
Tabelle 7.1: ProC/B Modellelemente (Auswahl): Graphische Darstellung und Semantik
ko¨nnen PKEs (=Aktivita¨ten) unter Zuhilfenahme vordefinierter und parametrisierter Ressour-
cen wie zum Beispiel Server (aktive Ressource mit Bedienstation-Semantik und Zeitverbrauch)
oder Counter (passive Resource mit Semaphor-Semantik), oder alternativ durch Dienste selbst-
definierter FEs ausgefu¨hrt werden. Dabei kann in beiden Fa¨llen die Zeit bzw. der Umfang der
Inanspruchnahme dynamisch quantifiziert werden. So wird neben der Struktur-Hierarchie ei-
ne Verhalten-Hierarchie ermo¨glicht, die auf Dienstaufrufen basiert (Aufruf-Hierarchie) und die
Spezifikation zur Ausfu¨hrung einzelner PKEs (=Aktivita¨ten) verfeinert (beinhaltet Konzept der
Selbsta¨hnlichkeit). Die Struktur-Hierarchie ist durch Server bzw. Counter abgeschlossen, die
keine unterliegenden FEs enthalten du¨rfen.
Aus der “Last-Ressourcen Sicht” agieren FEs, Server und Counter als “Ressourcen”. PKs de-
finieren das Interaktionsmuster zur Auferlegung der Last (=Verhalten) und sind innerhalb der
FEs von der Ressourcenbeschreibung deutlich abgegrenzt (Sichtenkonzept).
Eine Modellbildung logistischer Systeme mit Petri-Netzen ist prinzipiell mo¨glich [54, 57]. Jedoch
hat die Erfahrung im Umgang mit Gestaltern logistischer Systeme gezeigt, dass eine anwen-
dungsspezifische Notation wie ProC/B zu erheblich ho¨herer Akzeptanz einer modellbasierten
Systemanalyse fu¨hrt und Systemgestalter befa¨higt, Wissen und Informationen u¨ber logistische
Systeme in den Prozess der Modellbildung einzubringen. Im nachfolgenden Abschnitt 7.2 wird
verdeutlicht, dass Petri-Netze insofern bedeutsam sind, als sie als Bindeglied zwischen ProC/B
und analytischen Modellen fungieren.
95
7.2 Modell-Transformation von ProC/B nach Petri Netzen
Eine u¨bliche Methodik der modellbasierten Analyse besteht darin, die manuelle Modellbildung
durch eine hochsprachliche Notation zu unterstu¨tzen, die in ihrer Semantik hinreichend formal
und eindeutig ist, um aus ihr automatisiert ein analytisches Modell ableiten zu ko¨nnen, das als
Eingabe der Analyseverfahren dient. Das hier angestrebte analytische Modell ist eine Markov-
Kette mit hierarchischer Kronecker-Algebra (vgl. Abschnitt 3.2). P. Buchholz und P. Kemper ha-
ben bereits Abbildungen von SGSPN s in dieses analytische Modell konzipiert und implementiert
[33, 32]. Deswegen ist es naheliegend, auf eine vergleichsweise aufwendige Re-Implementierung
dieser Methodik speziell fu¨r ProC/B zu verzichten und anstelle dessen ProC/B -Modelle zuna¨chst
auf SGSPN s abzubilden und dann auf die verfu¨gbare Methodik zuru¨ckzugreifen. Dieses Vorgehen
ist in der Abb. 7.1 dargestellt. Das gestrichelte Rechteck zeigt, wie GSPN s eingesetzt werden, um
Logistisches
System
ProC/B
Editor
ProC/B
Modell
Markov
Kette
ASYNC
stationaere
Verteilung
Evaluator
Resultat
Performance
Trafo
PN
Modell
Trafo
Abbildung 7.1: Modellbildung logistischer Systeme und die Anbindung von ASYNC
die Lu¨cke zwischen der hochsprachlichen ProC/B Modellbildung und dem analytischen Modell
zu schließen. Die APNN-Toolbox integriert die Methodik, die in Abb. 7.1 rechts vom ProC/B -
Modell dargestellt ist. Das ProC/B -Toolset unterstu¨tzt die ProC/B -Modellbildung logistischer
Systeme und die Ansteuerung verschiedener Analysewerkzeuge (linker Teil Abb. 7.1).
Der konzeptionelle Entwurf und die Implementierung der Abbildung von ProC/B -Modellen auf
GSPN -Modelle wurden in Kooperation mit P. Kemper, C. Tepper und Z. Wu realisiert [58, 59].
Der Definitionsbereich der Abbildung ist eine wohldefinierte Teilmenge von ProC/B -Modellen.
Er resultiert aus Vorgaben des angestrebten analytischen Modells (Markov-Kette) und Ein-
schra¨nkungen des Analyseverfahrens (Gro¨ße behandelbarer Zustandsraum). So mu¨ssen alle Zeit-
verbra¨uche im ProC/B -Modell durch Exponentialverteilungen spezifiziert sein und datenabha¨ngi-
ges Verhalten (Prozess-Parameter, Variablen und deren Manipulation und Abfrage, boolscher
AND-Konnektor etc.) kann nicht oder nur sehr eingeschra¨nkt abgebildet werden. In Tab. 7.2 wird
aufgeza¨hlt, welche Auspra¨gungen von ProC/B -Konstrukten durch die Abbildung unterstu¨tzt
werden, nur bedingt (approximativ) abbildbar sind oder nicht behandelt werden ko¨nnen.
Die grundlegende Idee der Abbildung ist, fu¨r alle Konstrukte der ProC/B -Notation (siehe
Tab. 7.1) verhaltensa¨quivalente Petri-Netz Beschreibungen zu definieren (=lokale Ersetzung)
und diese gema¨ß ihrer ablauflogischen Reihenfolge korrekt zu verknu¨pfen. Auf die Details der
Abbildung soll nicht weiter eingegangen werden und es sei hierfu¨r auf [58, 59] verwiesen.
Es sei angemerkt, dass durch die Abbildung auf PN s nicht nur analytische Markov-Ketten
Modelle erschlossen, sondern auch ein breites Spektrum von Analyseverfahren (Invarianten etc),
die direkt auf PN s agieren.
Ein Defizit der Abbildung ist, dass kein strukturiertes SGSPN -Modell, sondern lediglich ein
GSPN automatisiert generierbar ist. Eine Strukturierung in Komponenten muss manuell vorge-
nommen werden.
Technisch ist die APNN-Toolbox an das ProC/B -Instrumentarium durch U¨bersetzer angebun-
den, die mehrstufig u¨ber 4 Schnittstellen ProC/B -Modelle in Petri-Netz-Modelle (GSPN ) u¨ber-
96
ProC/B Element Abbildbarkeit auf Petri-Netz
FE Strukturierungselement ohne Einfluss auf Modell-Dynamik
Server ⊕ “Random” Bediendisziplin, Mehrbediener
⊗ “Infinite Server” Semantik durch Mehrbediener approximiert
	 FCFS, PS Bediendisziplin, Bedienpriorita¨ten, zustandsabh. Bediengeschwindigkeit
Counter ⊕ ein- und mehrdimensionale Za¨hler mit konstanter (In/De)krementierung
	 dynamische, datenabha¨ngige Za¨hlermanipulation
Quelle ⊕ Poisson-artige und singula¨re Prozesserzeugung (auch “bulk”-Prozesse)
	 boolsche (datenabha¨ngige) Prozesserzeugung
Senke ⊗ “offene” Prozesse werden via Kurzschluss durch “geschlossene Prozesse” ersetzt
PK beinhaltet (potentiell) alle unten beschriebene Konstrukte
PK-Interface 	 alle Typen von Aufrufparametern
Delay-PKE ⊕ konstante Verzo¨gerung mit Markov’schen Zeitverbrauch
⊗ “Infinite Server” Semantik durch Mehrbediener approximiert
	 datenabha¨ngige Zeitverbra¨uche
Code-PKE ⊕ HiSlang Code [16] zur Addition/Subtraktion von Konstanten auf/von FE-Variable
	 sonstiger HiSlang Code [16]
Loop-PKE ⊕ Endlosschleife, boolsche Abbruchbedingung (Test auf FE-Variablen Werte)
probabilistische Abbruchbedingung (geometrische Verteilung der Durchla¨ufe)
⊗ boolsche Abbruchbedingung durch probabilistische Abbruchbedingung approxim.
	 komplexe boolsche Ausdru¨cke als Abbruchbedingung
AND-Konnektor ⊕ “Fork”-Operator zur Erzeugung von Parallel-Prozessen
⊗ “Join-Operator” rekombiniert+synchronisiert jeweils terminierte Parallel-Prozesse,
die aus u.U. verschiedenen “Fork” hervorgehen (“Min-Match” Semantik)
OR-Konnektor ⊕ probabilistischer “Branch”-Operator, boolsche Variante fu¨r einfache Ausdru¨cke
wie Test auf FE-Variablen Werte
	 komplexe boolsche Ausdru¨cke fu¨r “Branch”-Auswahl
PK-Konnektor ⊕ Synchronisation, Erzeugung und Replikation von Prozessen
FE-Variable ⊕ Integer-Variablen mit endlichem Definitionsbereich (auch mehrdimensional)
	 Variablen 6= Integer-Typ
PK-Parameter 	 alle Auspra¨gungen
Tabelle 7.2: ProC/B Modellelemente (Auswahl) und ihre Abbildbarkeit auf Petri Netze: Aus-
pra¨gungen von ProC/B -Konstrukten, die ohne Einschra¨nkung abbildbar sind (= ⊕) , bedingt
(approximativ) abbildbar sind (= ⊗) und nicht behandelbar sind (= 	).
setzen. Ein Parser liest eine textuelle Spezifikationen des ProC/B -Modells (1. Schnittstelle) und
erzeugt eine C++ Datenstruktur (2. Schnittstelle), die auf einem C++ Klassendiagramm fu¨r
ProC/B -Modellkonstrukte basiert. Die Konzeption des Parsers und der Schnittstellen geht auf
A. van Almsick und F. Bause zuru¨ck, die Implementierung wurde durch M. Eickhoff, D. Ko¨pp
und D. Sawitzki geleistet. Die ProC/B C++ Datenstruktur wird danach in eine Petri-Netz
C++ Datenstruktur (3. Schnittstelle) u¨bersetzt. Die Konzepte dieser Abbildung wurden oben
rekapituliert. Ein Parser der APNN-Toolbox liest die Petri-Netz C++ Datenstruktur aus und
erzeugt die APNN-Notation (4. Schnittstelle) - das textuelle Austauschformat fu¨r Petri-Netze
der APNN-Toolbox. Die Konzeption und Implementierung dieses Parsers geht auf P. Kemper
und C. Tepper zuru¨ck.
97
7.3 Hierarchische Kronecker-Darstellung der Markov-Kette
In diesem Abschnitt wird fu¨r das SGSPN -Modell des MSMQ-Systems (Abb. 2.1, Bsp. 2.3 ) ei-
ne hierarchische Kronecker-Darstellung der Markov-Kette (Abschnitt 3.2) schrittweise explizit
dargestellt. Das MSMQ-System ist zwar kein logistisches System, es ist aber wegen der geringen
Modellgro¨ße gut geeignet, die Konzepte der Kronecker-Darstellung zu exemplifizieren.
Das SGSPN -Modell ist wie folgt parametrisiert: J = 4 Stationen (=Komponenten), S = 1
Bediener und Cj = 1 , (1 ≤ j ≤ J) als Kapazita¨ten der Wartera¨ume der einzelnen Stationen.
Die lokalen Zustandsra¨ume Sj ko¨nnen vollsta¨ndig isoliert von der Umgebung oder in partieller
Isolation unter Ausnutzung maximaler Kapazita¨ten der Stellen des GSPN s, welche aus globalen
Invarianten resultieren, generiert werden [70]. Im letzteren Fall haben die S j jeweils nj = 5
Zusta¨nde (zeitlose Zusta¨nde sind bereits eliminiert), die zugeho¨rigen Markierungen der Stellen
und aktivierte Transitionen sind in Tab. 7.3 aufgefu¨hrt.
Zustand M(p 1) M(p 2) M(p 3) M(p 4) M(p 5) t Buf t Proc t Sw j t Sw j+1
0 1 0 0 0 0 × ×
1 0 1 0 0 0 ×
2 1 0 0 0 1 × × ×
3 0 0 1 0 0 × ×
4 0 1 0 0 1 × ×
Tabelle 7.3: Zusta¨nde aus Sj , zugeho¨rige Markierungen M(p∗) der Stellen p∗ und aktivierte
Transitionen t∗ (×) fu¨r das GSPN -Modell aus Abb. 2.1.
Die Matrix Qjl in Gl. 7.1 erfasst alle Raten der Zustandu¨berga¨nge in Sj, die durch lokale,
zeitbehaftete Transitionen tBuf , tProc ∈ TLj des GSPN -Modells ausgelo¨st werden. Mit der
Reihenfolge der Zusta¨nde, wie sie in der Tab. 7.3 aufgelistet sind, hat die Matrix Qjl folgende
Eintra¨ge:
Qjl = λj[






· 1 · · ·
· · · · ·
· · · · 1
· · · · ·
· · · · ·






−Djt Buf] + µj[






· · · · ·
· · · · ·
· · · · ·
· · 1 · ·
· · · · ·






−Djt Proc]
=
0 1 2 3 4
0 −λj λj · · ·
1 · · · · ·
2 · · −λj · λj
3 · · µj −µj ·
4 · · · · ·
,


Qjl [0, 0] Q
j
l [0, 1]
Qjl [1, 0] Q
j
l [1, 1]

 . (7.1)
Die Blockstruktur von Qjl bzw. die Partitionierung von S j in sogenannte lokale A¨quivalenzklas-
sen Sj[·] bzw. lokale Makrozusta¨nde (LMZ )
Sj = Sj[0] .∪ Sj [1] mit Indexmenge Zj = {0, 1} (7.2)
resultiert aus einer A¨quivalenzrelation, die u¨ber das Erreichbarkeitskriterium 7.3 definiert ist [23].
Zwei Zusta¨nde s1, s2 ∈ Sj geho¨ren genau dann einer A¨quivalenzlasse an, wenn sie in Kombination
98
mit den gleichen Zusta¨nden env ihrer Umgebung ENV j , ×Ji=1
i6=j
Si erreichbar sind, d.h. wenn
∀env ∈ ENV j : (s1, env) ist erreichbar ⇔ (s2, env) ist erreichbar (7.3)
gilt. Die lokalen Zusta¨nde 2 und 4 aus Sj [1] (fu¨r alle j) repra¨sentieren genau die Zusta¨nde,
in denen der Bediener in Komponente j ist (genau eine der Stellen p 3, p 4 und p 5 hat ein
Token). Die Zusta¨nde 0 und 1 ko¨nnen bei Abwesenheit des Bedieners eintreten. Die Anzahl
der A¨quivalenzklassen ist minimal. Zusta¨nde aus Sj[0] und Sj[1] ko¨nnen nicht zusammengefasst
werden, weil der Bediener immer in genau einer Warteschlange residiert.
Die globalen A¨quivalenzklassen S[·] des globalen Zustandsraums S bzw. die globalen Ma-
krozusta¨nde (GMZ ) sind das Kreuzprodukt lokaler A¨quivalenzklassen bzw. LMZ s, wobei aus
der Menge kombinatorisch mo¨glicher Kreuzprodukte stets nur GMZ s erzeugt werden, die aus-
schließlich erreichbare Zusta¨nde beschreiben. Potentiell ko¨nnen somit 24 = 16 GMZ entstehen,
im Beispiel sind es nur N = 4 GMZ s. Weil der Bediener immer in genau einer Warteschlange
residiert, ist Sj[1] genau einmal in GMZ s involviert. Die GMZ definieren somit die Verteilung
der S Bediener (Population) u¨ber den J Komponenten. Rein kombinatorisch gibt es hierfu¨r
(J+S−1
S
)
Mo¨glichkeiten. Fu¨r die Benennung von GMZ ist es hilfreich, Indexmengen fu¨r lokale
Makrozusta¨nde (Zj>0) und globale Makrozusta¨nde (Z0) zu definieren. Jeder GMZ X ∈ Z0 ist
als Kreuzprodukt von J = 4 LMZ s
Z0 = Z1 ×Z2 ×Z3 ×Z4,
und somit als ein 4-Tupel X = (X1, X2, X3, X4) identifizierbar. Im Beispiel ist Z0 = {0, 1, 2, 3}
(⇒ N = 4) und Zj = {0, 1} fu¨r j = 1 . . . 4 und die GMZ s ausgedru¨ckt durch die Indizes
involvierter LMZ s
Z0 = { (1 0 0 0)
︸ ︷︷ ︸
GMZ Index 0
, (0 1 0 0)
︸ ︷︷ ︸
GMZ Index 1
, (0 0 1 0)
︸ ︷︷ ︸
GMZ Index 2
, (0 0 0 1)
︸ ︷︷ ︸
GMZ Index 3
}.
Alternativ sind GMZ s durch explizite Angabe involvierter Zusta¨nde lokaler Zustandsra¨ume Sj
beschreibbar
GMZ Index S1 S2 S3 S4 Zusta¨nde
0 2 . . . 4 0 . . . 1 0 . . . 1 0 . . . 1 3 · 2 · 2 · 2 = 24
1 0 . . . 1 2 . . . 4 0 . . . 1 0 . . . 1 2 · 3 · 2 · 2 = 24
2 0 . . . 1 0 . . . 1 2 . . . 4 0 . . . 1 2 · 2 · 3 · 2 = 24
3 0 . . . 1 0 . . . 1 0 . . . 1 2 . . . 4 2 · 2 · 2 · 3 = 24
bzw.
S = S[0] ∪ S[1] ∪ S[2] ∪ S[3]
= S1[1] × S2[0]× S3[0]× S4[0] ∪
S1[0] × S2[1]× S3[0]× S4[0] ∪
S1[0] × S2[0]× S3[1]× S4[0] ∪
S1[0] × S2[0]× S3[0]× S4[1]. (7.4)
Die Generatormatrix Ql lokaler Transitionen ist wie Q blockstrukturiert und es sei
Ql ,




Ql[0, 0] Ql[0, 1] Ql[0, 2] Ql[0, 3]
Ql[1, 0] Ql[1, 1] Ql[1, 2] Ql[1, 3]
Ql[2, 0] Ql[2, 1] Ql[2, 2] Ql[2, 3]
Ql[3, 0] Ql[3, 1] Ql[3, 2] Ql[3, 3]




∈ R96×96. (7.5)
99
Fu¨r die generische Beschreibung der Matrizen Ql[·, ·] ko¨nnen die Operatoren der Kronecker-
Algebra verwendet werden, vgl. Def. 3.6 auf S. 21. Lokale Transitionen im GSPN definieren
Zustandsu¨berga¨nge, bei denen Start- und Zielzustand entweder im selben LMZ sind (GMZ
bleibt unvera¨ndert) oder einen LMZ -U¨bergang induzieren (GMZ a¨ndert sich in genau einer
Komponente). Im Beispiel vera¨ndern sich bei einem GMZ -U¨bergang jedoch stets genau 2 in-
volvierte LMZ s, z.B. (1 0 0 0) → (0 1 0 0). Demzufolge ko¨nnen U¨berga¨nge zwischen GMZ s nicht
durch lokale Transitionen ausgelo¨st werden und alle Nicht-Diagonalblo¨cke in Ql sind gleich 0. Die
Hauptdiagonalblo¨cke, welche Zustandsu¨berga¨nge innerhalb von LMZ s erfassen, haben folgende
Gestalt:
Ql[0, 0] = Q1l [1, 1] ⊕Q2l [0, 0] ⊕Q3l [0, 0] ⊕Q4l [0, 0]
=


−λ1 0 λ1
µ1 −µ1 0
0 0 0

⊕
(
−λ2 λ2
0 0
)
⊕
(
−λ3 λ3
0 0
)
⊕
(
−λ4 λ4
0 0
)
∈ R24×24
Ql[1, 1] = Q1l [0, 0] ⊕Q2l [1, 1] ⊕Q3l [0, 0] ⊕Q4l [0, 0]
=
(
−λ1 λ1
0 0
)
⊕


−λ2 0 λ2
µ2 −µ2 0
0 0 0

⊕
(
−λ3 λ3
0 0
)
⊕
(
−λ4 λ4
0 0
)
∈ R24×24
Ql[2, 2] = Q1l [0, 0] ⊕Q2l [0, 0] ⊕Q3l [1, 1] ⊕Q4l [0, 0]
=
(
−λ1 λ1
0 0
)
⊕
(
−λ2 λ2
0 0
)
⊕


−λ3 0 λ3
µ3 −µ3 0
0 0 0

⊕
(
−λ4 λ4
0 0
)
∈ R24×24
Ql[3, 3] = Q1l [0, 0] ⊕Q2l [0, 0] ⊕Q3l [0, 0] ⊕Q4l [1, 1]
=
(
−λ1 λ1
0 0
)
⊕
(
−λ2 λ2
0 0
)
⊕
(
−λ3 λ3
0 0
)
⊕


−λ4 0 λ4
µ4 −µ4 0
0 0 0

 ∈ R24×24
Diese Darstellung zeigt, dass nur 5 Eintra¨ge (Hauptdiagonaleintra¨ge nicht mitgeza¨hlt) die Ma-
trizen Ql[0, 0] . . .Ql[3, 3] mit 52 Eintra¨gen generieren. Diese Matrizen erzeugen generisch die
Matrix Ql[1, 1] =
0
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
B
@
· λ4 λ3 · · · · · λ2 · · · λ1 · · · · · · · · · · ·
· · · λ3 · · · · · λ2 · · · λ1 · · · · · · · · · ·
· · · λ4 · · · · · · λ2 · · · λ1 · · · · · · · · ·
· · · · · · · · · · · λ2 · · · λ1 · · · · · · · ·
µ2 · · · · λ4 λ3 · · · · · · · · · λ1 · · · · · · ·
· µ2 · · · · · λ3 · · · · · · · · · λ1 · · · · · ·
· · µ2 · · · · λ4 · · · · · · · · · · λ1 · · · · ·
· · · µ2 · · · · · · · · · · · · · · · λ1 · · · ·
· · · · · · · · · λ4 λ3 · · · · · · · · · λ1 · · ·
· · · · · · · · · · · λ3 · · · · · · · · · λ1 · ·
· · · · · · · · · · · λ4 · · · · · · · · · · λ1 ·
· · · · · · · · · · · · · · · · · · · · · · · λ1
· · · · · · · · · · · · · λ4 λ3 · · · · · λ2 · · ·
· · · · · · · · · · · · · · λ3 · · · · · λ2 · ·
· · · · · · · · · · · · · · · λ4 · · · · · · λ2 ·
· · · · · · · · · · · · · · · · · · · · · · · λ2
· · · · · · · · · · · · µ2 · · · · λ4 λ3 · · · · ·
· · · · · · · · · · · · · µ2 · · · · · λ3 · · · ·
· · · · · · · · · · · · · · µ2 · · · · λ4 · · · ·
· · · · · · · · · · · · · · · µ2 · · · · · · · ·
· · · · · · · · · · · · · · · · · · · · · λ4 λ3 ·
· · · · · · · · · · · · · · · · · · · · · · · λ3
· · · · · · · · · · · · · · · · · · · · · · · λ4
· · · · · · · · · · · · · · · · · · · · · · · ·
1
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
A
100
Abschließend sollen die Matrizen Qjt (t ∈ TS = {Sw 1, Sw 2, Sw 3, Sw 4}) betrachtet werden.
Transitionen aus TS bewirken Zustandsu¨berga¨nge in mindestens zwei Komponenten des SGSPN s.
Beispielsweise Sw 2∈ TS induziert einen U¨bergang in Komponente 2 (Ankunft Bediener) und
in Komponente 1 (Abgang Bediener). Der Zustand in Komponente 3 und 4 bleibt unvera¨ndert
und man setzt Q3Sw 2 = In3 und Q4Sw 2 = In4 (n3 = n4 = 5).
Q1Sw 2 =
0 1 2 3 4
0 · · · · ·
1 · · · · ·
2 1 · · · ·
3 · · · · ·
4 · 1 · · ·
,


Q1Sw 2[0, 0] Q1Sw 2[0, 1]
Q1Sw 2[1, 0] Q1Sw 2[1, 1]

 (7.6)
Q2Sw 2 =
0 1 2 3 4
0 · · 1 · ·
1 · · · 1 ·
2 · · · · ·
3 · · · · ·
4 · · · · ·
,


Q2Sw 2[0, 0] Q2Sw 2[0, 1]
Q2Sw 2[1, 0] Q2Sw 2[1, 1]

 . (7.7)
Es sei QSw 2[X,Y ] der (additive) Beitrag von Transition Sw 2∈ TS zu Q[X,Y ], der alle U¨berga¨nge
von GMZ X ∈ Z0 nach Y ∈ Z0 erfasst. Im Beispiel ist
QSw 2[X,Y ]
{
6= 0 falls X = 0 und Y = 1
= 0 sonst,
weil die Transition Sw 2 nur einen U¨bergang vom GMZ mit Index 0 in den GMZ mit Index 1
erzeugt. Die Matrix QSw 2[0, 1] ∈ R24×24 hat die folgende Gestalt:
QSw 2[0, 1] = ω1· Q1Sw 2[1, 0] ⊗ Q2Sw 2[0, 1] ⊗ Q3Sw 2[0, 0] ⊗ Q4Sw 2[0, 0]
= ω1·


1 0
0 0
0 1

 ⊗
(
1 0 0
0 1 0
)
⊗
(
1 0
0 1
)
⊗
(
1 0
0 1
)
.
A¨hnlich verha¨lt es sich mit den restlichen Transitionen Sw j aus TS, sie induzieren folgende
GMZ U¨berga¨nge ( Sw j−→):
(1 0 0 0)
︸ ︷︷ ︸
GMZ 0
Sw 2−→ (0 1 0 0)
︸ ︷︷ ︸
GMZ 1
︸ ︷︷ ︸
⇒QSw 2[0,1]6=0
Sw 3−→ (0 0 1 0)
︸ ︷︷ ︸
GMZ 2
Sw 4−→ (0 0 0 1)
︸ ︷︷ ︸
GMZ 4
Sw 1−→ (2 1 1 1)
︸ ︷︷ ︸
GMZ 0
.
Sie beschreiben Zustandstransitionen auf der oberen Ebene der hierarchischen Darstellung. Auf
gleiche Weise werden die Matrizen QSw 1, QSw 3 und QSw 4 erzeugt, in denen jeweils genau der
Anteil QSw 1[3, 0], QSw 3[1, 2] und QSw 4[2, 3] ein Block mit Eintra¨gen ungleich 0 ist.
101
Die Gesamtdarstellung der hierarchischen und strukturierten Generatormatrix in ihrer allgemei-
nen Form aus Gl. 3.9 nimmt fu¨r das Beispiel die Form
Q =




Ql[0, 0] QSw 2[0, 1] 0 0
0 Ql[1, 1] QSw 3[1, 2] 0
0 0 Ql[2, 2] QSw 4[2, 3]
QSw 1[3, 0] 0 0 Ql[3, 3]




+ D (7.8)
an. Die nicht explizit angegebene Diagonalmatrix D erzeugt die “passenden” Diagonaleintra¨ge.
7.4 Integration APNN-Toolbox
Das gesamte ASYNC -Instrumentarium ist in die APNN-Toolbox integriert und von der graphi-
schen Benutzeroberfla¨che aus aufrufbar. Die Ansteuerung des ASYNC -Instrumentariums ist in
4 Schritte unterteilt: 1. Generierung Markov-Kette, 2. Vorbereitung und Einrichtung des nu-
merischen Lo¨sers, 3. Aufruf des numerischen Lo¨sers und 4. Auswertung der Ausfu¨hrung des
numerischen Lo¨sers und Aufbereitung der Markov-Ketten Analyseergebnisse. Alle Schritte sind
einzeln und sequentiell in obiger ablauflogischer Reihenfolge von einer graphischen Benutze-
roberfla¨che aus aufrufbar, vgl. Abb. 7.2, Fenster oben. Auf oberster Ebene sind die Schritte
Abbildung 7.2: APNN-Toolbox : ASYNC -Ansteuerung (Generierung der Markov-Kette)
durch Shell-Skripte implementiert, die ihrerseits Ansteuerungen und Aufrufe ausfu¨hrbarer Pro-
grammdateien beinhalten. Informationen, die in den Shell-Skripten beno¨tigt werden, mu¨ssen -
unterstu¨tzt durch eine graphische Benutzeroberfla¨che - spezifiziert werden. Im Einzelnen bein-
haltet dies:
102
1. Generierung Markov-Kette: Das Shell-Skript kapselt alle Programmaufrufe zur Ge-
nerierung der Markov-Kette (hierarchische Kronecker-Darstellung) aus der Spezifikation
eines Petri-Netzes in der “Abstract Petri Net Notation”. Es wurde von P. Buchholz und
P. Kemper implementiert, vgl. Abschnitte 2.1.1, 3.2, 7.2 und 7.3. Die Abb. 7.2 zeigt un-
ten die zugeho¨rige Benutzerschnittstelle, u¨ber die voreingestellte Werte gewo¨hnlich un-
vera¨ndert u¨bernommen werden ko¨nnen.
2. Vorbereitung numerischer Lo¨ser: Das Shell-Skript pru¨ft die Vollsta¨ndigkeit und Kon-
sistenz der Dateien, die die Markov-Kette beschreiben. Das Shell-Skript erzeugt diverse
Ansteuerungsdateien zur Berechnung der Lastverteilung und fu¨r den numerischen Lo¨ser
und ruft benutzerdefiniert Chaco 2.0 oder ParMETIS zur Berechnung der Lastverteilung
auf, vgl. Abschnitt 5.5. Desweiteren konfiguriert das Skript eines der Kommunikations-
Tools (PVM oder MPI ). Die Abb. 7.3 links unten zeigt die zugeho¨rige Benutzerschnitt-
stelle. Ein Bestandteil der Benutzerschnittstelle dient der Spezifikation der Rechner, die
fu¨r die verteilte Ausfu¨hrung des numerischen Lo¨sers benutzt werden sollen, vgl. Abb. 7.3
rechts unten.
3. Aufruf numerischer Lo¨ser: Das Shell-Skript testet die Verfu¨gbarkeit von PVM bzw.
MPI und liest Parameter des numerischen Lo¨sers ein. Die Belegung der Parameter er-
fordert teilweise eine Neuu¨bersetzung des Quellcodes. Der Aufruf des numerischen Lo¨sers
resultiert in der Berechnung einer (approximativen) stationa¨ren Verteilung, die in einer
Datei gespeichert wird. Des Weiteren werden Informationen zum Laufzeitverhalten und
u¨ber den dynamischen Ablauf des Algorithmus in Dateien abgelegt, vgl. Modul CONTROL
in Abschnitt 5.6.1.
4. Auswertung: Das Shell-Skript ruft ein Evaluator-Programm auf (von P. Kemper), das
aus der zuvor berechneten stationa¨ren Verteilung die Durchsa¨tze der Transitionen und die
Tokenpopulationen der Stellen des Petri-Netzes ermittelt, vgl. Abschnitt 2.1.1. Des Wei-
teren ruft das Shell-Skript ein Programm auf, dass aus den protokollierten Informationen
zum Laufzeitverhalten und zum dynamischen Ablauf des Algorithmus unter Zuhilfenah-
me von gnuplot und LaTex ein postscript-Dokument erzeugt, indem alle Informationen
integriert und fu¨r eine ex-post Analyse geeignet aufbereitet sind.
103
Abbildung 7.3: APNN-Toolbox : ASYNC -Ansteuerung (Vorbereitung numerischer Lo¨ser)
104
Kapitel 8
Modellbildung und Analyse
logistischer Systeme
In diesem Kapitel wird die Anwendbarkeit und Nu¨tzlichkeit des ASYNC -Instrumentariums
und der begleitenden Modellierungs-Software aus der Perspektive der Logistik-Doma¨ne unter-
sucht und bewertet. Der Ausgangspunkt ist die Interpretation logistischer Systeme als DEDS
und deren Modellierung mit der ProC/B -Notation. Ein Alleinstellungsmerkmal der ProC/B -
Notation ist, dass sie Anforderungen (prozess-orientierter) logistischer Systeme beru¨cksichtigt,
die Ableitung von formalen Performance-Modellen erlaubt und ein breites Spektrum von DEDS -
Analyseverfahren erschließt. Insbesondere werden Markov-Ketten als analytisches Modell zur
Performance-Analyse logistischer Systeme erschlossen. Das Markov-Ketten-Instrumentarium wird
u¨ber den Zwischenschritt der Petri-Netz Modellwelt erreicht.
Das Kapitel ist wie folgt strukturiert: im Abschnitt 8.1 wird die Methodik der Modellbildung
und Analyse logistischer Systeme eingefu¨hrt und im Abschnitt 8.2 anhand konkreter Beispiele
demonstriert. Fu¨r eine Stu¨ckgut-Umschlaghalle wird der Durchsatz bedienter LKWs, die Aus-
lastung involvierter Ressourcen und die Wahrscheinlichkeit kritischer Systemzusta¨nde fu¨r un-
terschiedliche Modell-Konfigurationen in einer Analyse-Serie bewertet, vgl. Abschnitt 8.2.1. Fu¨r
ein Teilsystem einer Lieferkette (Ein- und Auslagerungsprozesse am Lager) werden die Attribute
eines Aggregats (Fluss-a¨quivalenter Bediener) quantifiziert, vgl. Abschnitt 8.2.2. Schließlich wer-
den Prozesse mit ausfallbehafteten Ressourcen betrachtet und ein parametrisiertes Zuverla¨ssig-
keitsmodell hinsichtlich der Frage bewertet, mit welcher Rate eingesetzte Ressourcen gewartet
werden mu¨ssen (Modellparameter), um ihre Verfu¨gbarkeit zu maximieren. Im Abschnitt 8.3
werden Einsichten und Erfahrungen, die bei der Modellierung und Markov-Ketten-Analyse ge-
wonnen wurden, resu¨miert und diskutiert.
105
8.1 Methodik der Modellbildung und Analyse
Logistische Systeme Die Logistik bescha¨ftigt sich mit der Gestaltung der Material-, Wert-
und Informationsflu¨sse innerhalb unterschiedlicher Unternehmensbereiche wie Beschaffung, La-
gerung, Produktion und Transport [4]. Hierbei hat sich ein prozess-orientierter Ansatz
etabliert, der nicht auf einzelne, oft ku¨nstlich isolierte Unternehmensbereiche fokussiert, son-
dern Prozesse logistischer Systeme bereichsu¨bergreifend betrachtet. Die Planung neuer oder
die Reorganisation bestehender logistischer Systeme zielt auf eine Optimierung logistischer
Kennzahlen wie Durchlaufzeiten, Liefertreue, Kapazita¨tsauslastung, Besta¨nde und Kosten ab.
Obwohl die Planung vielen Randbedingungen unterliegt (existierende, unvera¨nderliche Struktu-
ren, gesetzlich festgelegte Richtlinien, dokumentierte “Best-Practices”) ergeben sich insbesonde-
re bei der Dimensionierung und Disposition von Betriebsmitteln zahlreiche Freiheitsgrade bzw.
Planungsszenarien. Fu¨r die Optimierung mu¨ssen Planungsszenarien bewertet werden. Eine mo-
dellbasierte Bewertung vermeidet teure Eingriffe in existierende Systeme (Messung) bzw. eine
zeitaufwendige, prototypische Implementierung neuer Systeme.
Modellbildung Vorhandene Software mit graphischen Benutzeroberfla¨chen zur Modellbil-
dung, Fortschritte in der Analysemethodik und die Verfu¨gbarkeit hoher Rechenkapazita¨ten
fo¨rdern die Akzeptanz einer rechnergestu¨tzten und modellbasierten Systemanalyse mit formalen
Methoden in der Industrie. In der betrieblichen Praxis ist nicht nur die modellbasierte Ermitt-
lung logistischer Kennzahlen, sondern auch deren Optimierung bedeutsam. Gegenwa¨rtig werden
logistische Systeme oft durch statische Modelle abgebildet. Dies hat aus Sicht der Optimierungs-
verfahren den Vorteil, dass Auswertungen der Zielfunktion (=Analysen des statischen Modells
mit variierenden Attributwerten) einfach und preiswert sind. Allerdings wird die komplexe Dyna-
mik logistischer Systeme nicht ada¨quat durch statische Funktionen beschrieben. Erst dynamische
Modelle erlauben eine realita¨tsnahe Modellbildung.
Im Vorfeld der eigentlichen Modellbildung mu¨ssen typische Systemeigenschaften identifiziert
werden. Logistische Systeme sind oft als diskrete ereignis-gesteuerte dynamische Syste-
me (DEDS ) interpretierbar, weil auftretende Gro¨ßen diskret sind (Lagerbestand, Bestellmenge)
und Ereignisse diskret und asynchron auftreten (Einlagerung, Auftragseingang), vgl. Kapitel
2. Die Akzeptanz dieser Interpretation wird u.a. durch das “Handbuch Logistik” [4] belegt, in
dem auf bedientheoretische Ansa¨tze und Diskrete Ereignis-gesteuerte Simulation (die beide ei-
ne DEDS -Interpretation voraussetzen) als ga¨ngige Techniken zur Analyse logistischer Systeme
verwiesen wird. Eine DEDS -Interpretation ist in verwandten technischen Systemen, wie zum
Beispiel Rechen- und Telekommunikationssystemen [20, 36] und Fertigungssystemen [3] weit
verbreitet.
Fu¨r die Reproduktion logistischer Systeme (Lieferketten, Gescha¨ftsprozesse etc.) in Modellen
sind zahlreiche hochsprachliche Notationen bekannt, die durch eine objekt-orientierte, prozess-
orientierte und/oder hierarchische Methodik (mit Anleihen aus UML [69]) an Bedarfe und Denk-
weisen des jeweiligen Anwendungsgebiets adaptieren. UML (Unified Modeling Language) Ak-
tivita¨tsdiagramme [69], EPCTM (Event-driven Process Chains, IDS-Scheer) [89], Process Dia-
grams (Casewise Inc. und TIBCO), Rational RequisiteProTM (IBM), Rational Rose Use Case
DiagramsTM (Rational) und einige mehr haben sich in der Praxis als Beschreibungsmittel be-
trieblicher Abla¨ufe etabliert und sind in kommerziellen Tools fu¨r BPR/M (Business Process
Reengineering/Management), ERP (Enterprise Resource Planning) und WFM (Workflow Ma-
nagement) verfu¨gbar, vgl. etwa das ARIS-ToolsetTM (IDS-Scheer), MS VisioTM (Microsoft) und
106
Corporate Modeler (Casewise Inc.). Basierend auf dem Prozessketten-Paradigma von Kuhn [72]
(Fraunhofer Institut fu¨r Materialfluss und Logistik, Dortmund) ist ein MS-VisioTM basiertes
Tool und das ProC/B -Toolset (Informatik Lehrstuhl iV, Dortmund, vgl. Abschnitt 7.1) entstan-
den. Alle Tools ermo¨glichen eine graphische Modellbildung und unterstu¨tzen damit das Expli-
zieren von Konzepten zur Planung, zum Management und zur Steuerung logistischer Abla¨ufe.
Die Ableitung eines formalen Leistungsmodells, das eine rechnergestu¨tzte Berechnung logisti-
scher Kennzahlen ermo¨glicht, ist mit Ausnahme des ARIS-ToolsetTM (nur Simulation) und des
ProC/B -Toolset nicht mo¨glich. Eine Gartner-Studie1 resu¨miert, dass Simulationsmodelle in Zu-
kunft versta¨rkt eingesetzt werden.
Die ProC/B-Notation aus Abschnitt 7.1 ist durch Konzepte des Prozessketten-Paradigmas
von Kuhn [72] inspiriert (graphische Darstellung etc), wodurch sie Anforderungen des Anwen-
dungsfeldes beru¨cksichtigt. Die ProC/B -Notation adoptiert daru¨ber hinaus einige Konzepte des
Modellierungs- und Analyse-Tools HIT von Beilner [16], wodurch eine hinreichend formale Be-
schreibung und eindeutige Interpretation des Modells als Voraussetzung fu¨r eine automatisierte
U¨bersetzung in ein Performance-Modell erreicht wird. Die ProC/B -Notation unterstu¨tzt die
Methodik der objekt- und prozessorientierten sowie hierarchischen Modellbildung. Diese Me-
thodik wurde bereits Mitte der siebziger Jahre in HIT angeregt, sie fand aber erst durch die
Verbreitung UML-basierter Modellierungstools breite Anwendung, zuerst im Informatik-Bereich
(Software-Entwurf, Datenbanken), spa¨ter auch im betriebswirtschaftlichen Bereich. Ein Allein-
stellungsmerkmal der ProC/B -Notation ist, dass sie synergetisch prozessorientierte und objekt-
flussorientierte Sichtweisen verzahnt, so dass Nachteile einer rein objektflussorientierten Sichtwei-
se (zeitlicher Aspekt wird nur indirekt abgebildet) und prozessorientierten Sichtweise (statische
Aufbaustruktur des Systems wird nur indirekt abgebildet) aufgehoben sind. Zudem realisiert die
ProC/B -Notation ga¨ngige Konzepte der Hierarchiebildung in Struktur- und Verhaltensmodellie-
rung, vgl. Abschnitt 7.1. Das ProC/B -Tool [11] erga¨nzt die aus HIT importierte Methodik durch
eine neue graphische Modellierungsumgebung und neue syntaktische Konstrukte, die aus spe-
zifischen Anforderungen der Logistik-Doma¨ne resultieren. Im Unterschied zur rein deskriptiven
Modellbildung, deren Intention nur das Explizieren von Informationen ist, ohne dabei implizite
Logistikkennzahlen des modellierten Systems ermitteln zu ko¨nnen, ist die Ausdrucksma¨chtigkeit
der ProC/B -Notation im Vergleich zu der von UML- Aktivita¨tsdiagrammen eingeschra¨nkt. Zum
Beispiel erlaubt die ProC/B Notation keine asynchronen Dienstaufrufe.
Analyse Eine ga¨ngige Methodik der rechnergestu¨tzten, modellbasierten Analyse ist, die ma-
nuelle Modellbildung durch eine hochsprachliche Notation wie zum Beispiel ProC/B zu un-
terstu¨tzen, die in ihrer Semantik hinreichend formal und eindeutig ist, um aus ihr automatisiert
ein analytisches Modell ableiten zu ko¨nnen, das als Eingabe des Analyseverfahrens fungiert.
Die ProC/B -Modellbildung zielt nicht auf ein spezifisches analytisches Modell bzw. Analysever-
fahren ab und es existieren U¨bersetzer in die HIT-, Warteschlangennetzwerk- und Petri-Netz-
Modellwelt [11], vgl. Abb. 1.1.
In der vorliegenden Arbeit wird lediglich die Abbildung auf PN s betrachtet, weil sie die Voraus-
setzung fu¨r die Anbindung des Markov-Ketten Instrumentariums schafft, vgl. Abschnitt 7.2. PN s
sind als Mittler zwischen einer prozess-orientierten Notation wie ProC/B und Markov-Ketten
gut geeignet, weil ga¨ngige Ablaufkonzepte von Prozessen (Nebenla¨ufigkeit, Synchronisation, boo-
lesche/probabilistische Verzweigung und Vereinigung) und deren Dynamik (geteilte Ressourcen,
1http://mediaproducts.gartner.com/reprints/idsscheer/119964.html
107
Indeterminismus) gut beschreibbar sind. Konzeptionell markieren Token instanziierte Prozessob-
jekte. PN -Stellen haben zwei Funktionen, sie zeigen den aktuellen Zustand der Prozessobjekte an
(Aufenthaltsort, Bearbeitungsstufe etc.) und bilden den Zustand der Ressourcen ab (Verfu¨gbar-
keit etc.). Alternativ ist das Farbenkonzept der Token fu¨r die Zustandskodierung anwendbar.
Dies ist insbesondere dann interessant, wenn Farben lediglich als Speicher von Informationen
dienen, deren Visualisierung durch Stellen das Versta¨ndnis der Prozessabla¨ufe behindert, z.B. bei
Schleifen. Gewo¨hnlich existieren mehrere Token gleichzeitig, um Nebenla¨ufigkeit, mehrfach in-
stanziierte Prozessobjekte etc. abzubilden. PN -Transitionen modellieren Aktionen der Prozesse
und Zustandsvera¨nderungen der Ressourcen (Benutzung↔Freigabe, Ausfall↔Reparatur).
8.2 Anwendungsbeispiele
In den nachfolgenden Unterabschnitten werden drei Anwendungsbeispiele logistischer Systeme
vorgestellt, anhand derer die Anwendbarkeit und Nu¨tzlichkeit des ASYNC -Instrumentariums
untersucht werden soll.
8.2.1 Stu¨ckgut-Umschlaghalle
Die Stu¨ckgut-Umschlaghalle ist ein zentraler Bestandteil eines Gu¨terverkehrszentrums (GVZ).
Ein GVZ etabliert eine Schnittstelle fu¨r den Warenumschlag zwischen unterschiedlichen Verkehrs-
tra¨gern (Verkehrstra¨gerwechsel), die Verkehrs- und Dienstleistungsunternehmen zur Gewinnung
von Synergien zusammenfu¨hrt, vgl. auch [4]. Ein GVZ ist als ein Knoten innerhalb eines gro¨ßeren
logistischen Netzwerks interpretierbar. Deswegen ist die Modellierung und Analyse von GVZs
eine wichtige Aufgabe innerhalb des SFB 559 “Modellierung großer Netze in der Logistik”.
Nicht-simulative Analysetechniken sind hierfu¨r anwendbar und nu¨tzlich, vgl. [5, 53, 54, 57].
Systembeschreibung In einer Stu¨ckgut-Umschlaghalle werden Gu¨ter von LKWs angeliefert
und abgeholt und bei Bedarf zwischengelagert. Der LKW-Abfertigungsbereich ist organisato-
risch in Terminals unterteilt. Jedes Terminal hat mehrere Rampen, die von LKWs fu¨r deren
Abfertigung angefahren werden. Sobald ein LKW an einer von ihm belegten Rampe wartet,
wird ein Gabelstapler angefordert. Ein Gabelstapler ist entweder bereits am Terminal oder er
fa¨hrt von einem zentralen Gabelstapler-Pool zum Terminal, vgl. Abb. 8.1. Sobald ein Gabel-
stapler verfu¨gbar ist, startet der eigentliche LKW-Umschlagprozess. Hierfu¨r wird zusa¨tzlich zum
Gabelstapler Personal (=aktive Ressource) beansprucht, um Frachtpapiere zu pru¨fen und den
Umschlag zu steuern und zu u¨berwachen. Das Personal ist jedem Terminal exklusiv zugeordnet.
Nach dem Umschlag verla¨ßt der LKW die Rampe. Der benutzte Gabelstapler ist daru¨ber hin-
aus noch fu¨r eine gewisse Zeit nicht verfu¨gbar (Einsatzplanung, Fahrt zum Pool bzw. na¨chsten
Einsatzort). Hierbei sind zwei Fa¨lle zu unterscheiden. Der Gabelstapler bleibt im aktuellen
Terminal, wenn dort bereits ein neuer LKW auf seine Abfertigung wartet, anderenfalls fa¨hrt
der Gabelstapler in einen zentralen Pool, um dort auf zuku¨nftige Einsa¨tze zu warten. Weil die
Gabelstapler-Einsatzplanung im zentralen Pool erfolgt, mu¨ssen Gabelstapler zum Pool zuru¨ck
kehren und ko¨nnen nicht direkt ein neues Terminal anfahren. Die Einsatzplanung der Gabelstap-
ler ist somit lastabha¨ngig gesteuert, vgl. Abb. 8.1. Bei der Analyse des Systems wird ein System
mit insgesamt 5 Terminals betrachtet. In der Abb. 8.1 sind aus Gru¨nden der U¨bersichtlichkeit
nur 2 Terminals dargestellt, die prinzipielle Organisation der Abla¨ufe bleibt von der Erho¨hung
108
L a g e r
T e r m i n a l  1 T e r m i n a l  2
Abbildung 8.1: Struktur der Stu¨ckgutumschlaghalle mit 2 Terminals und 5 Rampen je Terminal
der Anzahl der Terminals unberu¨hrt.
Die Tab. 8.1 gibt eine U¨bersicht der System-Parameter. Nach Kuhn [72] sind “Ressourcen”
(knappe) logistische Betriebsmittel, “Prozesse” systemu¨bergreifende Verkettungen sachlich zu-
sammenha¨ngender Aktivita¨ten einzelner Systeme und “Strukturen” sind Anordnungen der Be-
triebsmittel einschließlich der Aufbau-Organisation des Systems. Systemparameter sind als Gro¨ßen
zu interpretieren, die a-priori bekannt sind und interessierende Zielgro¨ßen beeinflussen. Typi-
scherweise quantifizieren Systemparameter a-priori bekannte Zeitverbra¨uche und Dimensionie-
rungen eingesetzter Ressourcen.
Ressourcen Gabelstapler (1. . .7 je nach Modellvariante),
Terminal (5),
Rampen je Terminal (5),
Personal je Terminal (1)
Prozesse Ankunft und Abfertigung der LKWs am Terminal
(siehe Abb. 8.2, Prozesse Truck0 und Truck1)
Gabelstapler Disposition (siehe Abb. 8.2, Prozess ForkLift)
Struktur Anordnungstruktur, vgl. Abb. 8.1
Systemparameter Dimensionierung der Betriebsmittel
Fahrzeiten der Gabelstapler
Be- und Entladezeit der LKWs
Systemlast LKW-Ankunftsprozesse an Terminals
Fragestellung Durchsatz bedienter LKWs, Auslastung Personal und
Wahrscheinlichkeit kritischer Systemzusta¨nde
Tabelle 8.1: Systembeschreibung der Stu¨ckgutumschlaghalle
Modellbildung Die Stu¨ckgut-Umschlaghalle a¨hnelt einem komplexen Bediensystem, in dem
unabha¨ngige Ankunftstro¨me (=LKWs an Terminals) an Bedienstationen mit endlichem Warte-
raum (=Rampen je Terminal) von Bedienern (Gabelstapler) verarbeitet werden, die zwischen
den Bedienstationen lastgesteuert und zeitbehaftet zirkulieren. Jeder Gabelstapler-Bedienprozess
beansprucht geschachtelt eine weitere aktive Ressource (=Personal). Aufgrund des komplexen
109
Verhaltens der Bediener und des eigentlichen Bedienprozesses ist eine analytisch-algebraische
Lo¨sung des gesamten Systems nicht mo¨glich.
Der Modellbildung liegen folgende System-Annahmen zugrunde:
1. Gro¨ße Lager: Das Lager als Ressource ist ausreichend dimensioniert, und es treten keine
Engpa¨sse bzw. Wartezeiten beim Zugriff auf. Deswegen ist das Lager im Modell nicht
erfasst.
2. LKW-Ankunft Das Ankunftsverhalten der LKWs an den Terminals ist unabha¨ngig
voneinander. Deswegen initieren die Quellen im Modell unabha¨ngig voneinander LKW-
Objekte. Die Zwischenankunftszeiten der LKWs ko¨nnen durch eine Exponentialvertei-
lung approximiert werden, d.h. der LKW-Ankunftsprozess ist ein stochastischer Poisson-
Prozess [20]. Wenn alle Rampen belegt sind (es sind 5 Rampen vorhanden), werden an-
kommende LKWs in einen separaten Bereich umgeleitet. Diese LKWs werden im Modell
nicht betrachtet, weil der Durchsatz von LKWs ermittelt werden soll, die an der Stu¨ckgut-
Umschlaghalle abgefertigt werden.
3. LKW-Typen: Alle LKWs haben die gleiche Auspra¨gung und werden nicht hinsichtlich
ihrer Ladungsmenge, Ladungstyp, Umschlagzeit etc. unterschieden.
4. Gabelstapler-Routing: Gabelstapler fahren Terminals an, wenn dort mindestens ein
LKW auf seine Bedienung wartet. Wenn LKWs an mehreren Terminals warten, wird ein
Terminal stochastisch-gleichverteilt ausgewa¨hlt (lastabha¨ngig-stochastisches Routing).
5. Relation Gabelstapler-LKW: Es wird nur ein Gabelstapler zur Abfertigung eines
LKWs eingesetzt.
Die Abb. 8.2 zeigt das ProC/B -Modell der Stu¨ckgut-Umschlaghalle. Das Modell besteht aus
2 Prozess-Ketten (PK), die das Verhalten der LKWs an 2 Terminals beschreiben (gelbe Stra¨nge)
und eine PK, die das Verhalten der Gabelstapler erfasst (gru¨ner Strang). Zwecks besserer Les-
barkeit sind in Abb. 8.3 beide PKs zusa¨tzlich separat und vergro¨ßert angegeben.
Die Gabelstapler-PK beinhaltet einen o¨ffnenden, boolschen OR-Konnektor, der die lastabha¨ngige
Einsatzplanung der Gabelstapler an Terminals modelliert. Das Code-PKE vor dem OR-Konnektor
berechnet eine boolsche Funktion fu¨r das nachfolgende boolsche Routing am OR-Konnektor.
Hierfu¨r wird die globale Variable T gelesen, u¨ber die die LKW-PKs ihre Gabelstapler-Anfragen
kommunizieren. Die Variable T speichert die Anzahl wartender LKWs. Der HIT-Code [16] der
Code-PKE und die Deklaration von T ist links unten im Modell angegeben, vgl. Abb. 8.2.
Gabelstapler- und LKW-Prozesse kommunizieren u¨ber die globale Variable T und synchronisie-
ren an AND-Konnektoren. Der erste AND-Konnektor (links) synchronisiert die Ankunft des Ga-
belstaplers am Terminal mit dem Start des LKW-Umschlagprozesses. Der zweite AND-Konnektor
(rechts) synchronisiert die Beendigung des LKW-Umschlagprozesses mit der Freigabe und der
Einsatzplanung der Gabelstapler. Beide Synchronisationspunkte liegen im Rumpf einer Schleife
mit boolscher Abbruchbedingung, deren Start bzw. Ende durch Loop-PKEs links bzw. rechts der
AND-Konnektoren angezeigt ist. Die Schleife wird abgebrochen, wenn T = 0 erfu¨llt ist (kein
LKW wartet am Terminal).
Weil die Gabelstapler unvera¨nderlich und permanent existieren, werden sie in der Quelle ein-
malig erzeugt und verlassen nie eine Endlosschleife, deren Start direkt nach der Quelle und
110
deren Ende direkt vor der Senke liegt, vgl. Abb. 8.3 unten. Ebenso ist der LKW-Strom kurz-
geschlossen, vgl. Abb. 8.3 oben. Dadurch wird erreicht, dass LKWs im Fall einer U¨berbelegung
der Rampen in einen separaten Bereich abgewiesen und dort separat bearbeitet werden (nicht
im Modell-Fokus).
In der Tab. 8.2 sind alle ProC/B -Konstrukte der LKW-PK in ihrer ablauflogischen Reihenfolge
angegeben.
Modell-Konstrukt Bezeichner Bedeutung
Quelle - erzeugt einmalig (zur Zeit 0) 5 LKW-Prozesse
PK-Interface Trucks Prozessname
Loop-PKE Start a¨ußere Schleife fu¨r permanente LKW-Prozess-Objekte
Delay-PKE Arrival modelliert Zwischenankunftszeiten der LKWs
Code-PKE Register Za¨hler-Inkrementierung, signalisiert Gabelstapler-Bedarf
AND-Konnektor - Synchronisation mit Gabelstapler-Prozess
Code-PKE UpdateWIP Za¨hler-Dekrementierung: kein Gabelstapler-Bedarf
PKE.Server ReqStaff Anforderung Personal (=aktive Ressource)
Delay-PKE Handling Verbringen der Ladung
AND-Konnektor - Synchronisation mit Gabelstapler-Prozess: Freigabe Gabelstapler
Loop-PKE Fin siehe Loop-PKE oben
Senke - markiert PK Ende
Tabelle 8.2: LKW-Prozess-Kette und involvierte ProC/B -Konstrukte
Modell-Konstrukt Bezeichner Bedeutung/Aktivita¨t
Quelle - erzeugt einmalig (zur Zeit 0) 2 Gabelstapler-Prozesse
PK-Interface ForkLift Prozessname und -variablen
Loop-PKE Start a¨ußere Schleife fu¨r permanente Gabelstapler-Prozess-Objekte
Code-PKE Disposition Routing Gabelstapler zu Terminal festlegen
OR-Konnektor - Routing Gabelstapler zu Terminal ausfu¨hren
Delay-PKE Dispatch Fahrt zum Terminal
Loop-PKE Start Start innere Schleife fu¨r mehrfache LKW-Bedienung am Terminal
AND-Konnektor - Synchronisation mit LKW-Prozess: Start LKW-Umschlag
AND-Konnektor - Synchronisation mit LKW-Prozess: Ende LKW-Umschlag
Delay-PKE LocDispatch Ru¨stzeit nach LKW-Bedienung
Loop-PKE Fin Ende/Fortsetzung innere Schleife fu¨r mehrfache LKW-Bedienung
Delay-PKE Dispatch Fahrt zum Pool
Loop-PKE Fin siehe Loop-PKE oben
Senke - markiert PK Ende
Tabelle 8.3: Gabelstapler-Prozess-Kette und involvierte ProC/B -Konstrukte
Ein kritischer Systemzustand sei die Situation, dass mindestens 4 Gabelstapler (von maxi-
mal 7) ausgehend vom Terminal 1 gleichzeitig Ladung verbringen wollen. Im ProC/B -Modell aus
Abb. 8.2 bedeutet dies, dass mindestens 4 Prozesse gleichzeitig im Delay-PKE “Handling” sind.
Im realen System ist dieser Zustand als kritischer Zustand einzustufen, wenn man annimmt,
dass sich Gabelstapler gegenseitig behindern. Der ProC/B -Modellbildung liegt die Annahme
zugrunde, dass Gabelstapler unabha¨ngig voneinander Ladung verbringen und einen zustandsu-
nabha¨ngigen Zeitverbrauch beno¨tigen. Deswegen ist die Modellbildung unter der Annahme des
geschilderten kritischen Systemszustands eigentlich nur eine Approximation. Trotzdem soll die
111
AT 0
5
AT 0
2
Trucks1
()
ForkLift
(INDEX:INT,
DEMAND:BOOL,
DEST:INT)
LOOP −−>
Start
LOOP −−>
Start
DELAY
Arrival
(negexp(1.0))
DELAY
Dispatch
(negexp(50))
CODE
Register
(T[1]:=T[1]+1)
T:INT[1..2]=[0,0]
CODE
UpdateWIP
(T[1]:=T[1]−1)
Staff0.
request
ReqStaff0
(negexp(6.0))
DELAY
Handling
(negexp(10.0))
<−− ENDLOOP
(until FALSE)
Fin
LOOP −−>
Start
<−− ENDLOOP
(until T[1]=0)
Fin
DELAY
LocDispatch
(negexp(10.0))
<−− ENDLOOP
(until FALSE)
Fin
DELAY
Dispatch
(negexp(50))
AT 0
5
Trucks2
()
LOOP −−>
Start
DELAY
Arrival
(negexp(1.2))
DELAY
Dispatch
(negexp(50))
CODE
Register
(T[2]:=T[2]+1)
CODE
UpdateWIP
(T[2]:=T[2]−1)
DELAY
Handling
(negexp(10.0))
<−− ENDLOOP
(until FALSE)
Fin
LOOP −−>
Start
<−− ENDLOOP
(until T[2]=0)
Fin
DELAY
LocDispatch
(negexp(10.0))
DELAY
Dispatch
(negexp(50))
CODE
Disposition
Staff1.
request
ReqStaff1
(negexp(6.0))
DELAY
Wait
(negexp(50))
Staff1
request
(amount:REAL)
Staff0
request
(amount:REAL)
{
DATA.DEMAND:=FALSE;
DATA.index:=1;
  LOOP
   IF  T[DATA.index]>0 THEN 
     DATA.DEMAND:=TRUE; 
   END IF;
   DATA.index:=DATA.index+1;
  END LOOP UNTIL DATA.index=3;
IF DATA.DEMAND THEN
  LOOP
    DATA.DEST:=randint(1,2);
  END LOOP UNTIL T[DATA.DEST]>0;
END  IF;
}
DATA.DEST=1
DATA.DEST=2
ELSE
Abbildung
8.2:ProC/B
M
odellderStu¨ckgutum
schlaghalle
112
AT 0
5 Trucks1
()
LOOP −−>
Start
DELAY
Arrival
(negexp(1.0))
CODE
Register
(T[1]:=T[1]+1)
CODE
UpdateWIP
(T[1]:=T[1]−1)
Staff0.
request
ReqStaff0
(negexp(6.0))
DELAY
Handling
(negexp(10.0))
<−− ENDLOOP
(until FALSE)
Fin
Staff0
request
(amount:REAL)
AT 0
2 ForkLift
(INDEX:INT,
DEMAND:BOOL,
DEST:INT)
{
DATA.DEMAND:=FALSE;
DATA.index:=1;
  LOOP
   IF  T[DATA.index]>0 THEN 
     DATA.DEMAND:=TRUE; 
   END IF;
   DATA.index:=DATA.index+1;
  END LOOP UNTIL DATA.index=3;
IF DATA.DEMAND THEN
  LOOP
    DATA.DEST:=randint(1,2);
  END LOOP UNTIL T[DATA.DEST]>0;
END  IF;}
DELAY
LocDispatch
(negexp(10.0))
DELAY
LocDispatch
(negexp(10.0))
LOOP −−>
Start
CODE
Disposition
DELAY
Dispatch
(negexp(50))DATA.DEST=1
LOOP −−>
Start
DELAY
Dispatch
(negexp(50))DATA.DEST=2
LOOP −−>
Start
<−− ENDLOOP
(until T[1]=0)
Fin
<−− ENDLOOP
(until T[2]=0)
Fin
DELAY
Dispatch
(negexp(50))
DELAY
Dispatch
(negexp(50))
<−− ENDLOOP
(until FALSE)
Fin
Abbildung 8.3: Prozess-Sichten des SUH1-Modells: LKW-Prozess-Kette (oben) und
Gabelstapler-Prozess-Kette (unten)
vorliegende ProC/B -Modellbildung beibehalten werden und anhand dieser die Wahrscheinlich-
keit fu¨r das Auftreten dieses kritischen Systemzustands bewertet werden.
Analyseergebnisse Der LKW-Durchsatz und die Personal-Auslastung jeweils in Abha¨ngig-
keit vom Terminal (Spalten 1..5) und in Abha¨ngigkeit von der Anzahl eingesetzter Gabelstapler
(Zeilen) k ist in den Tabellen 8.4 und 8.5 angegeben. Der LKW-Durchsatz und die Personal-
Auslastung ist mit ASYNC berechnet. Die Werte in eckigen Klammern geben Konfidenzinter-
valle einer simulativen Auswertung an.
Die LKW-Durchsa¨tze erreichen mit Zunahme von k die Werte 0.4, 0.5, 0.6, 0.8 bzw. 1.0. Diese
Grenzwerte sind durch die LKW-Ankunftsraten je Terminal festgelegt (im Modell vorgegeben).
Der maximal mo¨gliche LKW-Durchsatz wird bereits fu¨r k = 4 Gabelstapler erreicht.
113
LKW-Durchsatz an Terminals
k 1 2 3 4 5
1 0.369 [0.368,0.370] 0.444 [0.442,0.443] 0.512 [0.510,0.511] 0.634 [0.631,0.633] 0.743 [0.737,0.739]
2 0.399 [0.399,0.401] 0.499 [0.498,0.500] 0.597 [0.595,0.598] 0.792 [0.792,0.795] 0.983 [0.982,0.985]
3 0.400 [0.399,0.404] 0.499 [0.496,0.501] 0.600 [0.593,0.599] 0.798 [0.796,0.803] 0.996 [0.992,0.999]
4 0.400 [0.399,0.405] 0.500 [0.494,0.500] 0.600 [0.594,0.600] 0.799 [0.796,0.804] 0.998 [0.993,1.001]
7 0.400 [0.399,0.405] 0.500 [0.493,0.500] 0.600 [0.595,0.602] 0.800 [0.795,0.804] 0.999 [0.992,1.002]
Tabelle 8.4: LKW-Durchsatz an Terminals
Personal-Auslastung [%]
k 1 2 3 4 5
1 7.9 9.7 11.3 14.3 16.7
2 8.0 10.0 11.9 15.8 19.7
3 8.0 10.0 12.0 16.0 19.9
4 8.0 10.0 12.0 16.0 20.0
7 8.0 10.0 12.0 16.0 20.0
Tabelle 8.5: Personal-Auslastung an Terminals
Die Personal-Auslastung steigt erwartungsgema¨ß mit Zunahme von k, weil der LKW-Durchsatz
steigt. Die Personal-Auslastung ist auch bei maximaler Belastung (k ≥ 4) moderat, vgl. Tab. 8.4.
Alle Performance-Ergebnisse, die mit ASYNC ermittelt wurden, sind durch Petri-Netz Simu-
lationen verifizierbar. Hierfu¨r wurde ein Java-basierter Petri-Netz Simulator benutzt, der in
der APNN-Toolbox bereits verfu¨gbar ist. Die Konfidenzintervalle der simulativen Bewertung in
Tab. 8.4 sind auf ein Konfidenz-Level von 90% bezogen. Die numerisch ermittelten Werte liegen
im Konfidenzintervall oder, mit wenigen Ausnahmen bedingt durch die stochastische Ungenau-
igkeit der Simulation, knapp daneben. Sofern es die Gro¨ße des Zustandsraums zula¨sst, wurden
auch konventionelle sequentielle numerische Lo¨ser zur Validierung der ASYNC -Ergebnisse be-
nutzt.
Neben der Validierung der Performance-Ergebnisse ermo¨glicht die simulative Auswertung einen
Effizienzvergleich der Methoden. Die Simulationszeiten schwanken zwischen 100 Sekunden und
900 Sekunden, wobei die Simulationszeit mit zunehmender Anzahl der Gabelstapler k sinkt.
Demgegenu¨ber steigen die ASYNC -Lo¨sungszeiten2 mit zunehmendem k, weil die Zustandsraum-
gro¨ße steigt, vgl. Tab. 8.6. ASYNC schneidet im Methodenvergleich fu¨r Modelle mit k ≥ 4 (>
k: 1 2 3 4 5 6 7
Zeit [s] ASYNC : 17 1 025 412 1 606 6 089 18 650 63 560
Tabelle 8.6: ASYNC -Lo¨sungszeiten
20 Millionen Zusta¨nde) trotz verteilter Lo¨sung deutlich schlechter ab. Die Lo¨sungszeiten liegen
deutlich u¨ber denen der Simulation (100 Sekunden - 900 Sekunden). Eine simulative Auswertung
der LKW-Durchlaufzeiten und Gabelstapler-Auslastungen ist effizienter, weil Ereignisse, die zur
Bewertung dieser Performance-Kennzahlen beitragen, hochfrequent auftreten.
2Fu¨r k=1,2 wurden 2 Worker -Prozesse und fu¨r k=3,..,7 wurden 6 Worker -Prozesse verwendet.
114
Erfahrungsgema¨ß ko¨nnen numerische Lo¨ser mit der Simulation konkurrieren, wenn seltene Ereig-
nisse wie zum Beispiel kritische Systemzusta¨nde (Paket-Verlustraten in mobiler Kommunikation
oder Ausfall von Ressourcen) zu bewerten sind. Hierfu¨r sei X(t) die Anzahl von Gabelstaplern,
die zum Zeitpunkt t ausgehend vom Terminal 1 gleichzeitg Ladung verbringen. Oben wurde
erla¨utert, warum X(t) ≥ 4 einen kritischen Systemzustand beschreibt. Das Ziel ist die stati-
ona¨re Wahrscheinlichkeit limt→∞ P [X(t) ≥ 4] fu¨r einen kritischen Systemzustand zu bewerten.
In Tab. 8.7 sind die durch ASYNC ermittelten Wahrscheinlichkeiten fu¨r k = 4 . . . 7 eingesetzte
Gabelstapler angegeben. Erwartungsgema¨ß steigen die Wahrscheinlichkeiten mit zunehmender
Anzahl eingesetzter Gabelstapler.
k 0..3 4 5 6 7
limt→∞ P [X(t) ≥ 4] 0 3.526 × 10−8 6.406 × 10−8 7.994 × 10−8 8.804 × 10−8
Tabelle 8.7: Wahrscheinlichkeiten fu¨r das Auftreten kritischer Systemzusta¨nde
Fu¨r alle k-Werte wurden PN -Simulationen durchgefu¨hrt und nach 15000 Sekunden abgebrochen.
Nach 15000 Sekunden konnte fu¨r alle k-Werte noch kein vertrauenswu¨rdiges Konfidenzintervall
ermittelt werden. Demgegenu¨ber liefert ASYNC mit 2 Worker -Prozessen exakte Resultate in
deutlich weniger als 15000 Sekunden fu¨r Modellkonfigurationen mit k ≤ 5, vgl. Tab. 8.6.
8.2.2 Aggregat-Berechnung fu¨r Lieferketten
Dekomposition und Aggregierung (DA) [42] ist ein bekannter Ansatz, um den Aufwand einer
modellbasierten Analyse technischer Systeme zu reduzieren. Die grundlegende Idee hierbei ist,
dedizierte Teilmodelle in Isolation von ihrer Umgebung vorzuanalysieren, daraus Attribute ei-
ner vereinfachten Beschreibung abzuleiten (=Aggregat) und schließlich Teilmodelle durch ihre
Aggregate zu ersetzen. DA zielt daruf ab, die Dynamik des Gesamtmodells zu vereinfachen (klei-
nere Zustandsra¨ume), um Simulationszeiten zu verku¨rzen oder zustandsraumbasierte Analysen
zu ermo¨glichen, oder die Struktur derart zu modifizieren, dass sie einer analytisch-algebraischen
Analyse zuga¨nglich ist (keine Synchronisationsmechanismen). Der Preis der Modellreduktion ist,
dass ein Aggregat nur bestimmte Eigenschaften des Teilmodells exakt imitiert. Somit wird in
der Interaktion des Aggregats mit seiner Umgebung in diese ein Aggregierungsfehler induziert,
der durch die vereinfachte Konstruktion des Aggregats verursacht ist und Analyseergebnisse
verfa¨lschen kann.
Ein weit verbreiteter Aggregat-Typ ist der Fluss-a¨quivalente Bediener. Seine Konstruktion ba-
siert auf der Annahme, dass die Aufenthaltsdauer einer Entita¨t (Kunde, Prozessobjekt etc)
im Teilmodell nur von der aktuellen Entita¨t-Population im Teilmodell abha¨ngt. Es abtrahiert
vom Aufenthaltsort und vom Zustand der Entita¨ten. In die Sprache der ProC/B -Welt u¨ber-
setzt bedeutet dies: die Dauer eines FE-Dienstaufrufs bzw. der Fortschritt eines Prozess-Objekts
durch die PK ha¨ngt nur von der Anzahl der Prozess-Objekte ab, die aktuell in der PK residieren,
der genaue Aufenthaltsort der Prozess-Objekte in der FE (z.B. im PKE oder am Konnektor)
wird ignoriert. Die in der ProC/B -Notation vorliegende hierarchische Strukturierung der Mo-
delle in Teilmodelle (FE), deren Interaktion u¨ber wohldefinierte Schnittstellen beschrieben ist
(FE-Dienste), unterstu¨tzt den DA-Ansatz sehr gut.
Nachfolgend wird die numerische Voranalyse eines ProC/B -Teilmodells und die Ableitung eines
“Fluss-a¨quivalenter Bediener”-Aggregats demonstriert. Das Ziel der Voranalyse ist es, seriell fu¨r
115
alle Prozess-Objekt-Populationen des ProC/B -Teilmodells mittlere Durchlaufzeiten zu ermit-
teln. Rein technisch ist ein Fluss-a¨quivalenter Bediener vollsta¨ndig durch Funktionen beschrieben
(je FE-Dienst), die Prozess-Objekt-Populationen auf Bediengeschwindigkeiten abbildet. Hierfu¨r
wird das stationa¨re Verhalten der Teilmodelle im Kurzschluss betrachtet. Kurzschluss heisst,
dass terminierte Prozess-Objekte zeitlos an den Startpunkt im ProC/B -Teilmodell gelenkt wer-
den, wodurch eine konstante Population erreicht wird. In die Sprache der ProC/B -Welt u¨bersetzt
bedeutet dies: es wird eine ru¨ckfu¨hrende Verbindung zwischen Senke und Quelle implementiert.
Systembeschreibung Lieferketten (engl. supply chains) beschreiben alle Aktivita¨ten, die zwi-
schen einer Kundenbestellung und daraufhin gelieferten Produkten, Dienstleistungen oder In-
formationen auftreten. Dies umfasst Prozesse involvierter Akteure wie Zulieferer (Beschaffung
von Rohmaterialien oder vorgefertigter Teilprodukte), Produzenten (Produktion, Zusammen-
bau), Zwischenha¨ndler (Lagerhaltung) und Ha¨ndler (Auftragsbearbeitung, Verkauf) und deren
Verknu¨pfung und Steuerung durch Transport- und Lenkungsprozesse [4]. Hybride, auf Markov-
Ketten (Aggregat-Berechnung) und Warteschlangen basierende quantitative Bewertungen von
Lieferketten sind in [6] dokumentiert. Nachfolgend wird lediglich die Lagerhaltung innerhalb
einer Lieferkette betrachtet und fu¨r diese ein Aggregat berechnet.
Das zu aggregierende Teilsystem besteht aus einem Ein- und einem Auslagerungsprozess. Beide
Prozesse beanspruchen jeweils simultan die Ressourcen “Personal” und “Gabelstapler”. Die
Anzahl der ein- bzw. auszulagernden Teile kann variieren. Die Tab. 8.8 gibt eine U¨bersicht
der System-Parameter.
Ressourcen Gabelstapler und Personal
Prozesse Ein- und Auslagerung, vgl. Abb 8.4
Prozesse Put und Get
Struktur keine (es wird nur ein Teilsystem betrachtet)
Systemparameter Anzahl Ein- und Auslagerungsprozesse
Systemlast Rate und Umfang der Ein- und Auslagerungsprozesse
Fragestellung mittlere Dauer Ein- und Auslagerungsprozesse
Tabelle 8.8: Systembeschreibung Ein- und Auslagerung
Modellbildung Die Abb. 8.4 zeigt das ProC/B -Modell mit zwei Prozess-Ketten (PK) jeweils
eine fu¨r die Einlagerung (oben) und fu¨r die Auslagerung (unten). Der Modellbildung liegen
folgende System-Annahmen zugrunde:
1. Gro¨ße und Bestand Lager: Das Lager als Ressource ist ausreichend dimensioniert und
es treten keine Engpa¨sse bzw. Wartezeiten beim Zugriff auf. Deswegen ist das Lager bzw.
sein Bestand im Modell nicht erfasst.
2. Start Ein- bzw. Auslagerungsprozess: Ein- und Auslagerungen treten unabha¨ngig
voneinander auf. Deswegen initieren die Quellen im Modell unabha¨ngig voneinander Prozess-
Objekte. Die Zwischenankunftszeiten der Ein- und Auslagerungen ko¨nnen durch eine Ex-
ponentialverteilung approximiert werden, d.h. der Ankunftsprozess ist ein stochastischer
Poisson-Prozess [20].
116
3. Ladungsmenge: Die variable Ladungsmenge ist durch eine (diskrete) geometrische Ver-
teilung [20] approximierbar. Im Modell in Abb. 8.4 ist die Abbruchbedingung der Schleife
probabilistisch und die Anzahl der stochastisch-vielen Schleifendurchla¨ufe modelliert die
Ladungsmenge. In der Put-PK ist die Abbruchbedingung der Schleife mit der Wahrschein-
lichkeit 0.8, in der Get-PK mit der Wahrscheinlichkeit 0.6 erfu¨llt.
Put
()
Get
()
GS.
change
GS_anfordern1
([−1])
GS.
change
GS_anfordern2
([−1])
DELAY
verbringen1
(negexp(2.0))
DELAY
abholen1
(negexp(3.0))
GS.
change
GS_freigeben1
([+1])
GS.
change
GS_freigeben2
([+1])
EVERY negexp(2.0)
1
EVERY negexp(1.0)
1
GS
INIT=[2],
MAX=[2]
change
(amount:INT[])
DELAY
verbringen2
(negexp(2.0))
DELAY
abholen2
(negexp(3.0))
Personal
INIT=[4],
MAX=[4]
change
(amount:INT[])
Personal.
change
P_anfordern1
([−1])
Personal.
change
P_anfordern2
([−1])
Personal.
change
P_freigeben1
([1])
Personal.
change
P_freigeben2
([1])
LOOP −−>
Palettenschleife1
<−− ENDLOOP
(until prob=0.2)
Pal_schleife1
LOOP −−>
Palettenschleife2
<−− ENDLOOP
(until prob=0.4)
Pal_Schleife2
DELAY
Fahre1
(negexp(10.0))
DELAY
Fahre3
(negexp(11.0))
DELAY
Fahre2
(negexp(5.0))
DELAY
Fahre4
(negexp(6.0))
0.9
0.9
0.1
0.1
Store3
Abbildung 8.4: ProC/B Modell Ein- und Auslagerung
In der Tab. 8.9 sind alle ProC/B -Konstrukte der LKW-PK in ihrer ablauflogischen Reihenfolge
angegeben.
Die Abb. 8.5 zeigt das Petri-Netz aus der APNN-Toolbox, das automatisiert aus dem ProC/B -
Modell in Abb. 8.4 generiert wurde. Das Petri-Netz hat insgesamt 32 Stellen und 64 Transitionen
(28 sind sichtbar). An diesem Beispiel wird der Vorteil einer automatisierten Abbildung deutlich.
Eine direkte Modellierung eines fehlerfreien Petri-Netz Modells dieser Gro¨ße dauert 1-2 Stunden.
Demgegenu¨ber ist das (relativ kleine) ProC/B -Modell aus Abb. 8.4 gut in 20 Minuten erstellbar
und kann binnen Sekunden automatisiert in ein Petri-Netz u¨bersetzt werden.
Analyseergebnisse Die Abb. 8.6 zeigt die mittlere Dauer der Einlagerung (links) und der
Auslagerung in Abha¨ngigkeit ausgewa¨hlter Prozess-Objekt Populationen (hier von (1, 1) bis
(5, 5). Erwartungsgema¨ß steigt die Dauer fu¨r beide Prozesse mit Zunahme der Population
(=Last). Aus den visualisierten Werten in Abb. 8.6 sind die populationsabha¨ngigen Bedienraten
des Fluss-a¨quivalenten Bedieners (= Attribute des Aggregats) nach dem “Gesetz von Little”
direkt ableitbar. Das berechnete Aggregat des ProC/B -Modells fu¨r die Ein- und Auslagerung
kann in ein u¨bergeordnetes Modell eingebettet werden.
117
Modell-Konstrukt Bezeichner Bedeutung
Quelle - erzeugt Einlagerungs-Prozesse
PK-Interface Put Prozessname
PKE.Counter P anfordern Personal anfordern
Delay-PKE Fahre1 Personal fa¨hrt zum Einsatzort
Loop-PKE Palettenschleife1 Beginn Schleife fu¨r Ladungsmenge
OR-Konnektor - 10% der Ladungsmenge beno¨tigt
keinen Gabelstapler
PKE.Counter GS anfordern1 Gabelstapler anfordern
Delay-PKE verbringen1/2 Ladung einlagern
PKE.Counter GS freigeben1 Gabelstapler freigeben
OR-Konnektor - s.o.
Loop-PKE Pal Schleife1 Ende Schleife fu¨r Ladungsmenge
Delay-PKE Fahre2 Personal verla¨ßt Einsatzort
PKE.Counter P freigeben1 Personal frei geben
Senke - markiert PK Ende
Tabelle 8.9: Einlagerung-Prozess-Kette und involvierte ProC/B -Konstrukte
3/3
Env_Put
4/4
Personal_Ctr
0/0
Personal_Diff
0/0
P_anfordern1
0/0
Fahre1
0/0
LOOP_217
0/0
Oder_Kon_94o
2/2
GS_Ctr
0/0
GS_Diff
0/0
GS anfordern1
0/0
verbringen1
0/0
GS_freigeben1
0/0
GS_Diff
2/2
GS_Ctr
0/0
Oder_Kon_113s
0/0
ENDLOOP_226
0/0
Fahre2
0/0
P_freigeben1
0/0
Personal_Diff
4/4
Personal_Ctr
0/0
Senke_Env_Put
3/3
Env_Put
0/0
verbringen2
4/4
Env_Get
0/0
P_anfordern2
0/0
Personal_Diff
4/4
Personal_Ctr
0/0
Fahre3
0/0
LOOP_231
0/0
Oder_Kon_147o
0/0
GS_anfordern2
0/0
GS_Diff
2/2
GS_Ctr
0/0
abholen1
0/0
GS_freigeben2
0/0
GS_Diff
2/2
GS_Ctr
0/0
Oder_Kon_156s
0/0
ENDLOOP_245
0/0
Fahre4
0/0
P_freigeben2
0/0
Personal_Diff
4/4
Personal_Ctr
0/0
Senke_Env_Get
4/4
Env_Get
0/0
abholen2
Quelle_Put P_anfordern1 Fahre1 LOOP_217
GS_anfordern1verbringen1GS_freigeben1Oder_Kon_113s
ENDLOOP_226 Fahre2 P_freigeben1 Senke_Env_Put verbringen2
Oder_K n_94ot
Quelle_Get P_anfordern2 Fahre3 LOOP_231
GS_anfordern2abholen1GS_freigeben2Oder_Kon_156sENDLOOP_245
Fahre4 P_freigeben2 Senke_Env_Get abholen2
Oder_Kon_147ot
Abbildung 8.5: Petri-Netz Modell Ein- und Auslagerung
8.2.3 Prozesse mit ausfallbehafteten Ressourcen
Die Performance logistischer Systeme ist abha¨ngig von der Last, die den Systemen durch ihre
Umwelt auferlegt wird. Die Performance ist ebenfalls abha¨ngig von der Anzahl verfu¨gbarer
Ressourcen, die zur Verarbeitung der Last beansprucht werden. In vielen technischen Systemen
sind Ressourcen ausfall-, ersetzungs- und wartungsbedingt nicht permanent verfu¨gbar.
Der Ansatz der “Performability”-Modellierung [67] beru¨cksichtigt diesen Umstand und zielt dar-
auf ab, implizite Performance-Charakteristika im Zusammenspiel mit impliziten Zuverla¨ssigkeits-
Charakteristika modellbasiert zu bewerten. Das Akronym “Performability” deutet an, dass
118
1
2
3
4
5
6
#Put
1
2
3
4
5
6
#Get
0
5
10
15
T
1
2
3
4
5
6
#Put
1
2
3
4
5
6
#Get
0
5
10
15
20
T
Abbildung 8.6: Mittlere Aufenthaltszeit Ein- und Auslagerungsprozesse
Aspekte der “Dependability” (Zuverla¨ssigkeit) und der “Performance” integrativ untersucht
werden. Das Gesamtmodell ist in zwei sich wechselseitig beeinflussende Modelle unterteilbar: ein
Performance-Modell (P-Modell) und ein Zuverla¨ssigkeits-Modell (Z-Modell).
Die Modell-Interaktion dru¨ckt sich darin aus, dass die Performance Rc von der Ressourcen-
Verfu¨gbarkeit c ∈ C abha¨ngt. Die Menge C beschreibt alle mo¨glichen Ressourcen-Konfigurationen.
Jede Konfiguration c kodiert eindeutig, welche Ressourcen verfu¨gbar sind und welche nicht.
Wenn beispielsweise Gabelstapler an 4 verschiedenen Orten agieren, beschreibt c = (2, 2, 2, 10)
die Konfiguration, in der an den ersten drei Orten 2 Gabelstapler und am vierten Ort 10 Ga-
belstapler verfu¨gbar sind. Umgekehrt ha¨ngt die Verfu¨gbarkeit auch von der Systemlast ab, die
im P-Modell definiert ist. Beispielsweise steigt die Ausfallrate benutzter Maschinen mit erho¨hter
Beanspruchung. Die wechselseitige Beeinflussung dru¨ckt sich somit im zeitlichen Verhalten aus.
Die Kopplung von P- und Z-Modellen fu¨hrt zu sehr großen Zusta¨ndsra¨umen des “Performability”-
Modells, weil gewo¨hnlich die Gro¨ßen der beiden Teilmodelle faktoriell eingehen. Die wechselseiti-
ge Beeinflussung dru¨ckt sich im zeitlichen Verhalten, nicht aber in eingeschra¨nkter Erreichbarkeit
von Zusta¨nden aus. Die Zusta¨nde des Z-Modells (= Ressourcen-Konfigurationen) sind weitestge-
hend unabha¨ngig von den Zusta¨nden des P-Modells erreichbar. Beispielsweise kann eine Maschi-
ne gewo¨hnlich in jedem Zustand der “beanspruchenden Umgebung” (P-Modell) ausfallen und
in einen Zustand “nicht verfu¨gbar” wechseln. Umgekehrt sind die Zusta¨nde des P-Modells (=
Aufenthaltsort, Bearbeitungsstufe etc. der Prozessobjekte) weitestgehend unabha¨ngig von den
Zusta¨nden des Z-Modells. Solange der Zustand des Z-Modells die prinzipielle Operationalita¨t
der Prozessabla¨ufe nicht einschra¨nkt, bleiben alle Zusta¨nde des P-Modells erreichbar, lediglich
das zeitliche Verhalten (Prozess-Dauer etc.) variiert.
Die Gro¨ße des Performability-Modell-Zustandsraums macht eine numerische, zustandsraumba-
sierte Analyse unmo¨glich. Zeitskalenunterschiede zwischen P- und Z-Modell rechtfertigen eine
Analyse, die auf einer Zeitskalen-Dekomposition basiert. Die Zeitskalen-Dekomposition beruht
auf der Annahme, dass Transitionen zwischen Ressourcen-Konfigurationen (Fehler treten sel-
ten auf, Wartungsraten sind gering) hinreichend lang sind im Verha¨ltnis zu Transitionen im
P-Modell (Bedienraten an den Ressourcen). Unter dieser Annahme erreicht das System zwi-
schen Ressourcen-Konfigurationen Transitionen einen quasi-stationa¨ren Zustand. Somit kann
fu¨r alle Ressourcen-Konfigurationen c ∈ C unabha¨ngig voneinander eine stationa¨re Performan-
ce Rc ermittelt werden. Typischerweise werden P-Modelle simulativ oder analytisch-algebraisch
119
hinsichtlich Rc bewertet. Anschließend werden die bedingten stationa¨ren Performance-Maße Rc
zu einer unbedingten stationa¨ren Performance-Kennzahl R = ∑c∈C pc · Rc aggregiert. Hierbei
ist pc die stationa¨re Wahrscheinlichkeit fu¨r die Ressourcen-Konfiguration c. Unter der verein-
fachenden Annahme, dass das zeitliche Verhalten des Z-Modells unabha¨ngig vom P-Modell ist,
sind die pc-Werte durch eine stationa¨re Analyse des Z-Modells ermittelbar. Die Anwendung von
Markov-Ketten ist im Kontext der Zuverla¨ssigkeitsanalyse weit verbreitet, vgl. etwa [67].
Nachfolgend wird ein einfaches Z-Modell fu¨r Gabelstapler innerhalb eines Lagers vorgestellt
und numerisch analysiert. In [12] wird dieses Z-Modell im Zusammenspiel mit einer simulativen
Auswertung eines ProC/B -Performance-Modells betrachtet und insbesondere untersucht, wie
der Aufwand der Simulation durch eine Steuerung basierend auf den pc-Werten reduziert werden
kann.
Systembeschreibung Die Abbildung 8.7 zeigt eine Lager-Organisation im Zusammenspiel
mit einer Produktions-Linie. Die schematische Darstellung der Abla¨ufe soll verdeutlichen, dass
L a g e r  2
? ?? ? ? ? ? ? ? ?? ? ? ? ? ?P r o d u k t i o n s - L i n i e
L a g e r  1
L a g e r  4
L a g e r  2
L a g e r  3
R e p a r a t u r -M e c h a n i k e r W a r t u n g s -M e c h a n i k e r
Abbildung 8.7: Lagerstruktur mit 4 Puffern und 10 bzw. 2 Gabelstaplern je Puffer
ein- und ausgehende Material- bzw. Gu¨terflu¨sse u¨ber 4 Lager abgewickelt werden. Jedem La-
ger ist eine feste Anzahl ausfallbehafteter Gabelstapler statisch zugeordnet, vgl. Abb. 8.7. Ein
Reparatur-Mechaniker ist fu¨r alle Gabelstapler zusta¨ndig und repariert ausgefallene Gabelstap-
ler. Ein Wartungs-Mechaniker ist ebenfalls fu¨r alle Gabelstapler zusta¨ndig und fu¨hrt in vorab
definierten Zeitabsta¨nden Wartungen an Gabelstaplern durch. Nach einer Wartung ist die zu
erwartende Zeit bis zum Auftreten eines Fehlers “zuru¨ckgesetzt” (Annahme: perfekte Wartung)
und wa¨hrend der Wartung sind Gabelstapler nicht betriebsbereit.
Die Tab. 8.10 za¨hlt die System-Parameter auf, die Zuverla¨ssigkeitsaspekte betreffen. Die Frage-
120
stellung lautet, welche Wartungsrate hinsichtlich der Verfu¨gbarkeit der Gabelstapler optimal ist.
Eine hohe Verfu¨gbarkeit der Gabelstapler ist notwendig fu¨r performante Material- und Gu¨ter-
flu¨sse (=Prozesse im P-Modell). Ein hoher Wartungsaufwand vermindert die Wahrscheinlichkeit
fu¨r fehlerbedingte Nichtverfu¨gbarkeit, allerdings auf Kosten einer erho¨hten Nichtverfu¨gbarkeit
verursacht durch Wartung. Insofern ist die Fragestellung nicht trivial. Des Weiteren soll die
Auslastung der Mechaniker in Abha¨ngigkeit von der Wartungsrate ermittelt werden.
Ressourcen Reparatur-Mechaniker, Wartungs-Mechaniker
Prozesse Gabelstapler-Zyklen:
verfu¨gbar → in Reparatur → verfu¨gbar
verfu¨gbar → in Wartung → verfu¨gbar
Struktur Anordnungstruktur vgl. Abb. 8.7
Systemparameter Anzahl Mechaniker
Ausfallzeit, Reparaturzeit und Wartungszeit fu¨r Gabelstapler
Wartungsrate
Systemlast Wartungsrate und Ausfallzeit
Fragestellung Auslastung Wartungs- und Reparatur-Mechaniker sowie
Verfu¨gbarkeit Gabelstapler jeweils in Abh. von Wartungsrate
Tabelle 8.10: Systembeschreibung der Lagerhaltung aus Abb. 8.7
Modellbildung Die ProC/B -Schnittstelle etabliert eine Schnittstelle zur Modellierung und
Analyse logistischer Systeme, vgl. Kapitel 7. In den vorherigen Abschnitten 8.2.1 und 8.2.2
wurde demonstriert, wie ausgehend von ha¨ndisch-erstellten ProC/B -Modellen, Petri-Netze bzw.
Markov-Ketten automatisch erzeugt werden ko¨nnen und somit ASYNC anwendbar wird. In
leichter Abwandlung dieser Methodik wird nun ein Z-Modell direkt als Petri-Netz modelliert, weil
die ProC/B -Notation fu¨r die Beschreibung von Zuverla¨ssigkeitsaspekten defizita¨r ist. Dennoch
hat die ProC/B -Notation eine große Bedeutung bei der Modellierung des Systems aus Abb. 8.7,
sie beschra¨nkt sich aber auf die P-Modellbildung (hier nicht betrachtet, vgl. [12] fu¨r Details).
Bevor die Defizite na¨her erla¨utert werden, soll das Petri-Netz Z-Modell vorgestellt werden, vgl.
Abb. 8.8 (von F. Bause aus [12]) und Abb. 8.9. In der Modellbildung wird angenommen, dass
die Ausfallzeit (=Zeit bis zum Auftreten eines Fehlers), die Reparaturzeit und die Wartungszeit
durch je eine Erlang-2 Verteilung [20] beschreibbar sind. Das Modell besteht aus 3 Teilen (von
unten nach oben):
Verfu¨gbarkeit und Reparatur (Stellen p1, . . . , p6, Transitionen t1, . . . , t5) Die Stellen p1
und p2 modellieren verfu¨gbare Gabelstapler und die Transitionen t1 und t2 modellieren
die Ausfallzeit. Ein Token auf der Stelle p3 zeigt einen ausgefallenen Gabelstapler an. Ein
Token auf der Stelle p6 zeigt einen verfu¨gbaren Reparatur-Mechaniker an. Die Transitionen
t4 und t5 modellieren die Reparaturzeit.
Wartungsrate und -Triggerung (Stellen p11, . . . , p13, Transitionen t9, . . . , t13) Die Tran-
sitionen t9 und t10 modellieren die Wartungsrate. Ein Token auf der Stelle p13 aktiviert
die Transitionen t11 und t12, die in Nullzeit alle Token der Stellen p1 und p2 auf die Stelle
p7 verschieben. Ein neuer Wartungszyklus beginnt (Transition t13 ist aktiviert), sobald die
Markierung der Stellen p1 und p2 leer ist (alle in Wartung).
121
p13
xx
xxxx
p4t4 t3
p3
t2
p2t1p1
t13
p11
t5
x
x x
x
x
x
x
p6
xxx
x
x
t8
t9
x x
p5
p12
t10 t11
t12
p7p10
t6
p8t7p9
Abbildung 8.8: Petri-Netz Zuverla¨ssigkeitsmodell
Ausfu¨hrung der Wartung (Stellen p7, . . . , p10, Transitionen t6, . . . , t8) Die Token auf der
Stelle p7 repra¨sentieren Gabelstapler, die gewartet werden, sobald ein Wartungs-Mechaniker
verfu¨gbar ist. Ein Token auf der Stelle p10 zeigt einen verfu¨gbaren Wartungs-Mechaniker
an. Die Wartungszeit wird durch die Transitionen t7 und t8 modelliert.
Das Modell ist wie folgt quantifiziert: die Ausfallzeit (Transitionen t1 und t2) betra¨gt 20000 Mi-
nuten, die Reparaturzeit 2000 Minuten und die Wartungszeit 80 Minuten (jeweils Mittelwerte
einer Erlang-2-Verteilung). Wie bereits oben angemerkt, erfasst das Z-Modell Gabelstapler an
4 verschiedenen Lokationen mit 10 (Lager 1) und 2 (Lager 2 bis Lager 4) Gabelstaplern.
Das Ausfall-, Wartungs- und Reparaturverhalten ist fu¨r alle Gabelstapler identisch. Deswegen
kann es kompakt durch ein farbiges Petri-Netz modelliert werden. Die Kanten-Annotation “x”
in Abb. 8.8 zeigt farbige Stellen-Markierungen und korrespondierende Transitions-Modi an.
Die Abb. 8.9 zeigt das Petri-Netz, wie es in der APNN-Toolbox modelliert ist. Das Petri-Netz
in Abb. 8.9 ist trotz einer vera¨nderten graphischen Darstellung (keine Farben, zusa¨tzliche Mess-
Stellen und “fusion”-Stellen) verhaltensa¨quivalent zum Petri-Netz in Abb. 8.8. Das Petri-Netz
hat insgesamt 37 Stellen und 62 Transitionen (30 Transitionen sind sichtbar). In Abb. 8.9 sind 4
strukturell identische Teilnetze zu erkennen. Sie erfassen das Verhalten der Gabelstapler an den
Lagern. Links oben ist ein kleines Teilnetz, das die Wartungsrate modelliert. Die Transitionen
Sync1 bis Sync4 synchronisieren betriebsbereite Gapelstapler mit dem Start der Wartungsphase.
122
Sync1
Fail1 Fail2 Repair1 Repair2
2/2
p1
0/0
p2
0/0
p3
0/0
p4 2/2
p1
Tick1 Tick2
1/1
Tick1
0/0
Tick2
0/0
branch
0/0
Maint1
0/0
Maint2Maint1 Maint20/0
MtFin
1/1
Tick1
0/0
branch
Sync2
Fail1 Fail2 Repair1 Repair2
2/2
p1
0/0
p2
0/0
p3
0/0
p4
2/2
p1
0/0
Maint1
0/0
Maint2Maint1 Maint2 0/0
MtFin
0/0
branch
1/1
Tick1
Sync3
Fail1 Fail2 Repair1 Repair2
2/2
p1
0/0
p2
0/0
p3
0/0
p4
2/2
p1
0/0
Maint1
0/0
Maint2Maint1 Maint2 0/0
MtFin
0/0
branch
1/1
Tick1
Sync4
Fail1 Repair1 Repair2
10/10
p1
0/0
p3
0/0
p4
10/10
p1
0/0
Maint1
0/0
Maint2Maint1 Maint20/0
MtFin
0/0
branch
1/1
Tick1
1/1
MaintServer1
1/1
RepairServer1
1/1
MaintServer1
1/1
RepairServer1
1/1
MaintServer1
1/1
RepairServer1
1/1
MaintServer1
1/1
RepairServer110/10
Eval4
0/0
p2 Fail2
2/2
Eval3
2/2
Eval2
2/2
Eval1
Abbildung 8.9: Petri-Netz Zuverla¨ssigkeitsmodell aus APNN-Toolbox
Die Token-Population in den Mess-Stellen Eval1 bis Eval4 repra¨sentiert die Verteilung verfu¨gba-
rer Gabelstapler am Lager. Die Auslastung der Mechaniker ist an den Stellen MaintServ1 bzw.
RepairServer1 messbar.
Bestimmte Eigenschaften des Petri-Netzes ko¨nnen mit der ProC/B -Notation nicht “direkt” ab-
gebildet werden. Im Petri-Netz in Abb. 8.8 haben die Transitionen t1 und t11 sowie t2 und t12
gemeinsame Eingangs-Stellen p1 bzw. p2. Es existieren Petri-Netz Markierungen, in denen die
Transitionen t1 und t11 bzw. t2 und t12 simultan aktiviert sind (Petri-Netz Terminologie: es
treten Konflikte auf). Im vorliegenden Petri-Netz wird der Konflikt durch den Umstand auf-
gehoben, dass die zeitlosen Transitionen t11 und t12 per Definition ho¨herpriorisiert sind. Dieses
Konstrukt garantiert, dass alle betriebsbereiten Gabelstapler gewartet werden. Implizit sind
jedoch nur zeitbehaftete Transitionen in den (asymmetrischen) Konflikt involviert, denn ak-
tivierte Transitionen t1 bzw. t2 sind in Markierungen deaktiviert, die einer Feuerung von t10
(ebenfalls zeitbehaftet) nachfolgen. Derartige Konflikte mit zeitbehafteten Transitionen bzw.
allgemein mit zeitbehafteten Aktivita¨ten ko¨nnen nicht “direkt” durch ProC/B -Konstrukte ab-
gebildet werden. Ein OR-SPLIT-Konnektor bildet zwar einen Konflikt in der Auswahl einer
Prozessverzweigung ab, die Auswahl ist jedoch zwingend zeitlos. Das Verhalten der restlichen
ProC/B -Konstrukte beschreibt keine Konfliktsituationen. Dies ist auch daran zu erkennen, dass
korrespondierende verhaltensa¨quivalente Petri-Netz Modelle keine Transitionen mit gemeinsa-
men Eingangs-Stellen besitzen. Mit CODE-PKEs ko¨nnen textuell HIT-Befehle in ProC/B -Modelle
eingefu¨gt werden. Dadurch ist es prinzipiell mo¨glich, auch zeitbehaftete Konflikte zu modellie-
ren, allerdings schra¨nkt dieses Vorgehen die automatisierte Abbildbarkeit von ProC/B -Modellen
auf Petri-Netz Modelle ein. Der U¨bersetzer kann origina¨re ProC/B -Konstrukte auswerten und
u¨bersetzen, die ausdrucksstarke HIT-Syntax wird jedoch nur sehr eingeschra¨nkt unterstu¨tzt.
Deswegen ist es im betrachteten Fall notwendig, die ProC/B -Schnittstelle bei der Modellierung
von Zuverla¨ssigkeitsaspekten zu umgehen und anstelle dessen Petri-Netz Modelle zu erstellen.
Trotz dieses Defizits ko¨nnen andere Zuverla¨ssigkeitsaspekte, wie zum Beispiel ausfallbehaftete
123
aktive Ressourcen oder Timeout-Mechanismen fu¨r unsichere Dienste auch ohne HIT-Code in
ProC/B abgebildet werden, vgl. [56].
Die vorgestellte Modellbildung ist somit hybrid und es liegt ein Petri-Netz Z-Modell (s.o.) und ein
ProC/B P-Modell (hier nicht betrachtet, Details in [12]) vor. Der hybride Ansatz tra¨gt dem Um-
stand Rechnung, dass es nicht eine universal anwendbare und ada¨quate Modellierungs-Notation
gibt, sondern Notationen ggf. im Hinblick auf gewisse Defizite in ihrer Ausdrucksma¨chtigkeit
oder im Hinblick auf durch die Analyse auferlegte Restriktionen sinnvoll kombiniert werden
ko¨nnen und mu¨ssen.
Analyseergebnisse Das Untersuchungsziel ist die Bestimmung der Auslastung der Mechani-
ker und die Verfu¨gbarkeit der Gabelstapler in Abha¨ngigkeit von der Wartungsrate. Die ASYNC -
Lo¨sungszeit der Markov-Kette mit 12 246 960 Zusta¨nden ist sehr sensitiv bzgl. der eingestellten
Wartungsrate. Die Lo¨sungszeit mit 2 Worker-Prozessen liegt zwischen 810 Sekunden (Wartungs-
rate 20 000−1 Minuten) und 17 067 Sekunden (100−1 Minuten).
Die Abb. 8.10 zeigt die Auslastung der Mechniker. Die Auslastung wurde fu¨r Wartungsraten
von 20 000−1, 10 000−1, 8 000−1, 6 000−1, 4 000−1, 2 000−1, 1 000−1 , 500−1, 250−1 und 100−1
Sekunden−1 ermittelt und fu¨r dazwischenliegende Werte linear approximiert. Erwartungsgema¨ß
fa¨llt die Auslastung des Reparatur-Mechanikers mit Zunahme der Wartungsrate, ebenso steigt
die Auslastung des Wartungs-Mechanikers mit Zunahme der Wartungsrate. Fu¨r sehr kleine War-
tungsraten geht die Grenzauslastung des Reparatur-Mechanikers gegen 0.57. Die mittlere Aus-
lastung beider Mechaniker wird fu¨r eine Wartungsrate von etwa 2 000−1 Sekunden−1 minimal,
vgl. mittlere Kurve in Abb. 8.10.
Repair Mechanic
Maintenance Mechanic
Mean
Legend
0
0.2
0.4
0.6
0.8
Utilization
0.002 0.004 0.006 0.008 0.01
Maintenance Rate
Abbildung 8.10: Verfu¨gbarkeits-Verteilung Gabelstapler in Abha¨ngigkeit von Wartungs-Rate
Die Abb. 8.11 zeigt exemplarisch die Verteilung der verfu¨gbaren Gabelstapler im Lager 1 in
Abha¨ngigkeit von der Wartungsrate (0..10 Gabelstapler sind verfu¨gbar, vgl. Abb. 8.7). Das Mon-
tonieverhalten der Verteilungen variiert deutlich mit der Wartungsrate. Fu¨r die Werte 10 000−1,
8 000−1 und 6 000−1 ist wird das Maximum der Verteilung fu¨r weniger als 10 Gabelstapler er-
124
100 250 500 1 000 2 000 4 000 6 000 8 000 10 000 20 000
2.3402 6.478 8.2274 8.8179 8.8249 8.4096 8.0818 7.8588 7.7013 7.3234
Tabelle 8.11: Kehrwert Wartungsrate (oben) und mittlere Anzahl verfu¨gbarer Gabelstapler (un-
ten) im Lager 1
reicht, fu¨r die Werte 4 000−1, 2 000−1 1 000−1 und 500−1 ist die Verteilung im betrachteten
Ausschnitt streng monoton steigend und erreicht ihr Maximum bei 10 Gabelstaplern. Bei einer
Wartungsrate von etwa 250−1 kippt das Monotonierverhalten recht schnell und die Verteilung
fu¨r eine Wartungsrate von 100−1 ist streng monoton fallend. Bei einer Wartungsrate von 100−1
tritt das “Worst-Case”-Szenario (kein Gabelstapler verfu¨gbar) sogar mit der ho¨chsten Wahr-
scheinlichkeit ein.
0
2000
4000
6000
8000
10000
Maintenance Rate
0
2
4
6
8
10
Fork-Lift Availability
0
0.1
0.2
0.3
0.4
0.5
Probability
Abbildung 8.11: Verfu¨gbarkeits-Verteilung Gabelstapler in Abha¨ngigkeit von Wartungs-Rate
In Tab. 8.11 ist die mittlere Anzahl verfu¨gbarer Gabelstapler im Lager 1 angegeben. Obwohl
die Wahrscheinlichkeit dafu¨r, dass alle Gabelstapler verfu¨gbar sind, bei einer Wartungsrate von
1 000−1 am ho¨chsten ist (rechter Peak in Abb. 8.11), ist die mittlere Verfu¨gbarkeit dort nicht
maximal. Der Mittelwert wird bei einer Wartungsrate von etwa 2000−1 maximal.
Zusammen mit den Verfu¨gbarkeits-Verteilungen der Gabelstapler an den anderen Lagern (hier
nicht dargestellt) erha¨lt man die Verteilung u¨ber allen Ressourcen-Konfigurationen C (pc-Werte,
s.o.). Diese Verteilung ist hinsichtlich der Durchlaufzeiten involvierter Ein- und Auslagerungs-
prozesse (erfasst im P-Modell) fu¨r eine Wartungsrate von c.a. 5 000−1 optimal, Details siehe [12].
Die Abweichung ist ein Indiz dafu¨r, dass die Gabelstapler im Lager 1 keinen Engpass darstellen,
weil die optimale Performance der Prozesse bei einer - aus der Sicht der Gabelstapler im Lager
1 - nicht optimlen Einstellung der Wartungsrate erzielt wird.
Die Analyse des P-Modells im Zusammenspiel mit den obigen Ergebnissen der Z-Modell-Analyse
125
wird an dieser Stelle nicht weiter betrachtet, weil das P-Modell einer numerischen Analyse nicht
zuga¨nglich ist. Die Ergebnisse einer simulativen Auswertung des P-Modells basierend auf den
Ergebnissen der Z-Modell-Analyse sind in [12] dokumentiert.
8.3 Diskussion
Es ist gelungen, die Methodik der Markov-Ketten-Analyse benutzerfreundlich in die ProC/B -
Modellierungsumgebung zu integrieren. Nachfolgend werden die Erfahrungen und Einsichten, die
bei der Modellierung und Analyse logistischer Systeme mit Markov-Ketten gewonnen wurden,
zusammenfasst.
Bedeutung von Petri-Netzen PN s und diverse Erweiterungen, die auf eine tokenbasierte
Modellierung ga¨ngiger Ablaufkonzepte abzielen (u.a. Aktivita¨tsdiagramme in UML 2), sind in
der Modellbildung prozess-orientierter technischer Systeme verbreitet [65] und haben sich auch
in dieser Arbeit bewa¨hrt. Auch wenn eine Modellbildung logistischer Systeme mit PN s prin-
zipiell mo¨glich ist [54, 57], hat die Erfahrung im Umgang mit Gestaltern logistischer Systeme
gezeigt, dass eine anwendungsspezifische Notation wie ProC/B zu einer erheblich ho¨heren Ak-
zeptanz einer modellbasierten Systemanalyse fu¨hrt und Systemgestalter befa¨higt, Wissen und
Informationen u¨ber logistische Systeme in den Prozess der Modellbildung einzubringen. Eine
direkte Gegenu¨berstellung verhaltensa¨quivalenter ProC/B - und PN -Modelle verdeutlicht, dass
eine ProC/B -Notation prozess-orientierter Abla¨ufe erheblich kompakter und suggestiver ist, vgl.
Abb. 8.4 (ProC/B -Modell von Lagerprozessen) und Abb. 8.5 (PN -Modell).
Die Methodik, zuerst ProC/B -Modelle ha¨ndisch zu erstellen und dann daraus PN s automati-
siert zu generieren, muss abgewandelt werden, wenn die ProC/B -Notation bzgl. der Beschreibung
gewisser Systemeigenschaften defizita¨r ist. Im Abschnitt 8.2.3 wurden bestimmte Zuverla¨ssig-
keitsaspekte identifiziert, deren Abbildung in ProC/B problematisch ist. Hier ist eine direkte
(manuelle) PN -Modellierung besser. Ansonsten erfu¨llen PN s als interne Zwischen-Notation eine
bedeutsame Vermittlungsfunktion zwischen der ProC/B -Welt und der Markov-Ketten-Welt.
Endlicher Zustandsraum In dieser Arbeit werden nur Markov-Ketten mit endlichem Zu-
standsraum betrachtet. Deswegen muss die Kapazita¨t eingesetzter Ressourcen endlich, die An-
zahl gleichzeitig existierender Prozess-Objekte beschra¨nkt und die Anzahl in Prozesse involvier-
ter Aktivita¨ten ebenfalls endlich sein. Es hat sich gezeigt, dass logistische Systeme ha¨ufig mit
offener Systemlast modelliert werden, in denen die Anzahl instanziierter und gleichzeitig exi-
stierender Prozess-Objekte nicht beschra¨nkt ist. Ein Grund hierfu¨r ist, dass obere Schranken
nicht bekannt sind bzw. einer Beschra¨nkung im Modell kein Einfluss auf die interessierenden
Analyseergebnisse beigemessen wird. Andererseits ist in logistischen Systemen die Population
der Prozess-Objekte endlich, insbesondere in Situationen, in denen die Systemlast durch den Sy-
stemzustand kontrolliert wird (Abweisung bzw. Umleitung von Prozessen, Kanban-Steuerung)
oder in denen Aktivita¨ten unter Zuhilfenahme endlicher Ressourcen ausgefu¨hrt werden. Insofern
ist eine Modellierung mit endlicher Population - wie sie hier vorausgesetzt wird - in vielen Fa¨llen
realita¨tsna¨her.
Stochastisches Modell vs. Determinimus Logistische Systeme weisen oft gemischt stocha-
stisches und deterministisches Verhalten auf. Beispiele sind Lastgeneratoren, die durch (ideali-
126
siert deterministische) Fahrpla¨ne getriggert sind, Reparaturzeiten und Lieferzeiten, die vertrag-
lich zugesichert sind und getaktetes Verhalten in Fertigungslinien. Die Abbildung des Determi-
nismus in einem rein stochastischen Modell - wie es Markov-Ketten sind - kann nur approximativ
erfolgen. Hierdurch wird die Anwendbarkeit des Markov-Ketten-Instrumentariums sehr einge-
schra¨nkt. Fu¨r stochastische Modelle spricht der Umstand, das Determinimus im System oft eine
idealisierte Annahme darstellt und die Annahme stochastischen Verhaltens eigentlich ada¨quater
wa¨re (z.B. Fahrpla¨ne).
Stochastik im zeitlichen Verhalten In Markov-Ketten sind Zeitverbra¨uche durch Exponen-
tialverteilungen spezifiziert. Die Erfahrung im Umgang mit logistischen Systemen zeigt, dass die
Exponentialverteilung oft “zu stochastisch” ist und anstelle dessen Verteilungen mit geringerem
Variationskoeffizienten ada¨quater sind. Bekanntlich ko¨nnen weniger stochastische Zeitverbra¨uche
durch Phasenverteilungen approximiert werden, die aus Exponentialverteilungen konstruierbar
sind. Allerdings fu¨hrt dies zu zusa¨tzlichen Zusta¨nden. Beliebige Verteilungen fu¨hren zur Klasse
(Generalisierter) Semi-Markov Prozesse, die prinzipiell auch analysierbar sind, allerdings wird
die Erweiterung der Modellklasse durch einen erheblichen Mehraufwand bei der analytischen
Betrachtung erkauft, weil der unterliegende stochastische Prozess partiell nicht geda¨chtnislos
ist.
Gro¨ße Zustandsraum Obwohl ASYNC leistungsfa¨hige Rechen- und Platzressourcen er-
schließt, u¨berschreitet der Zustandsraum logistischer Systeme oft die Grenzen, innerhalb derer
eine numerische Analyse des Zustandsraums praktizierbar ist. Deswegen liegt das Hauptein-
satzgebiet von ASYNC in der Voranalyse dedizierter Teilmodelle, zum Beispiel mit dem Ziel,
vereinfachte Beschreibungen fu¨r diese abzuleiten, vgl. Abschnitt 8.2.2 zur Aggregat-Berechnung.
In logistischen Systemen existieren zahlreiche “Treiber” großer Zustandsra¨ume. Ein Treiber ist
die Diversifikation von Prozess-Objekt-Auspra¨gungen. Wenn neben der essentiellen Kodierung
von Ressourcenzusta¨nden und Aufenthaltsorten der Prozess-Objekte auch (als Faktor eingehen-
de) Merkmale einzelner Prozess-Objekte im Zustandsraum kodiert werden mu¨ssen, ist die Gro¨ße
des Zustandsraums oft nicht behandelbar.
Eine a¨hnliche Zustandsraumexplosion tritt ein, wenn das Verhalten der Prozess-Objekte nicht
geda¨chtnislos ist, z.B. wenn Prozess-Objekte repetitiv Teilprozesse durchlaufen (Prozess-Objekt
merkt sich Anzahl der Schleifendurchla¨ufe) oder bei der Aufspaltung und Rekombination von
Prozessen (erzeugte Teilprozesse merken sich Zusammengeho¨rigkeit). In diesen Fa¨llen muss
zustands- bzw. datenabha¨ngiges Verhalten durch Randomisierung approximiert werden (pro-
babilistische Anzahl von Schleifendurchla¨ufen im ProC/B -Modell in Abb. 8.4).
Ein weiterer Treiber fu¨r große Zustandsra¨ume sind strukturierte Systeme, in denen die Zu-
standsra¨ume der Teilsysteme faktoriell zur Gro¨ße des gesamten Zustandsraums beitragen. Dies
trifft zum Beispiel fu¨r Systeme mit ausfallbehafteten Resourcen zu, vgl. Abschnitt 8.2.3.
Performance-Modellierung versus Performance-Messung Die Performance-Modellie-
rung spielt im (Gescha¨fts)-Prozess-Management, wie es gegenwa¨rtig in der betrieblichen Praxis
anzutreffen ist, nur eine untergeordnete Rolle. Der Versuch, Prozesse kontinuierlich zu verbes-
sern und vera¨nderten Rahmenbedingungen anzupassen, basiert auf der Erfassung bzw. Mes-
sung der Performance-Daten am realen System sowie einer geeigneten Aufbereitung entschei-
dungsrelevanter Mess-Daten in Data Warehouses oder Process Warehouses. In der Terminologie
127
unterstu¨tzender Software werden hierfu¨r Business-Warehouse (BW) Lo¨sungen und Business-
Intelligence (BI) Lo¨sungen verwendet. Ein BW ist eine Datenbank (Daten-Modellierung), in der
beobachtete Abla¨ufe (sogenannte Bewegungsdaten) und Performance-relevante Zusatzinforma-
tionen (was passiert wann und wo) gespeichert werden. BI ist grob gesagt eine Umschreibung aller
Aktivita¨ten, die eine Analyse und Aufbereitung der Informationen aus dem BW fu¨r menschliche
Entscheider umfasst. Dies beinhaltet sogenannte Data-Mining- und Process-Mining-Techniken,
mit denen eine Prozess-Sicht und prozessorientierte Performance-Kennzahlen aus dem BW re-
konstruiert bzw. extrahiert wird.
Eine Messung interessierender Performance-Kennzahlen wird also durch den Umstand begu¨nstigt,
dass Prozesse in logistischen Systemen zunehmend IT-gestu¨tzt ablaufen, so dass die Erfassung
bzw. das Abgreifen von Daten kostengu¨nstig und automatisiert mo¨glich ist.
Eine Performance-Modellierung wird durch die Vorgabe erschwert, dass hauptsa¨chlich die Per-
formance kundennaher Prozesse (B2C und B2B) interessiert und fu¨r das Management ent-
scheidungsrelevant ist. Die Performance derartiger “Top-Level” Prozesse ha¨ngt nicht nur von
der Organisation der Gescha¨ftsprozesse selbst, sondern insbesondere auch von der Performance
unterliegender IT-Integrations-Ebenen (Web-services etc.) und von der Performance der IT-
Systeme ab. Die Beru¨cksichtigung aller Aspekte (IT, IT-Integration, Gescha¨ftsprozesse) in ei-
nem Performance-Modell fu¨hrt zwangsla¨ufig zu sehr großen, gegenwa¨rtig nicht behandelbaren
Modellen.
Eine Performance-Modellierung ist interessant, wenn die Performance nicht messbar ist (Planung
neuer Systeme) oder ein “Trial-and-Error” Ansatz basierend auf BW und BI risikobehaftet ist,
weil die Ursache-Wirkungs-Beziehungen unklar sind.
128
Kapitel 9
Fazit und Ausblick
Durch die Kombination einer asynchronen und hierarchischen Block-Jacobi-Iteration mit einer
Kronecker-Darstellung der Generatormatrix und der Nutzung einer parallelen Rechnerarchitek-
tur mit verteiltem Speicher (Rechner-Cluster/Netzwerk) ko¨nnen Markov-Ketten-Modelle mit
nahezu 1 Milliarde Zusta¨nden gelo¨st werden. Diese Leistungsfa¨higkeit wird durch Synergieeffek-
te dieser speziellen Konstellation ermo¨glicht:
1. Die Kronecker-Darstellung der Generatormatrix profitiert von einer parallelen Rechnerar-
chitektur, weil verteuerte Rechenoperationen auf der Generatormatrix (bedingt durch das
generische Datenformat) bei einer verteilten Ausfu¨hrung der Iterationsschritte zusa¨tzliche
Rechenressourcen erschließen. Zudem wird in einem Rechnernetzwerk ein großer, wenn
auch verteilter Arbeitsspeicher verfu¨gbar gemacht. Eine Verteilung des Iterationsvektors
ist vorteilhaft, weil der Platz-Flaschenhals (= Speicherung des Iterationsvektors) behoben
wird.
2. Die Kronecker-Darstellung liefert eine Blockstruktur der Generatormatrix, an der blockori-
entierte numerische Lo¨sungsverfahren adaptieren ko¨nnen. Des Weiteren ist die Blockstruk-
tur eine geeignete Dekomposition des Berechnungsproblems, auf dem ein verteiltes Lo¨sungs-
verfahren aufsetzen kann.
3. Eine verteilte Block-Jacobi-Iteration profitiert von der Kronecker-Darstellung, weil in je-
dem Arbeitsspeicher die vollsta¨ndige Generatormatrix als Duplikat gehalten werden kann,
wodurch Datenabha¨ngigkeiten verringert und gleichzeitig die Kommunikation flexibilisiert
wird.
4. Verteilte, asynchrone Iterationen sind unabha¨ngig von der Verfu¨gbarkeit “aktueller” kom-
munizierter Daten und deswegen geeignet fu¨r Kommunikationsmedien mit geringer bzw.
lastabha¨ngig-schwankender Bandbreite. Umgekehrt profitiert das Kommunikationsmedi-
um von verteilten, asynchronen Iterationen, die zu einer gleichma¨ßigen Belastung des Me-
diums fu¨hren, weil Rechenphasen (geringe Belastung) und Kommunikationsphasen (hohe
Belastung) nicht alternierend, sondern zeitlich u¨berlappend ablaufen.
5. Asynchrone und hierarchische Iterationen sind flexibel ausfu¨hrbar und ko¨nnen an Perfor-
mance-Charakteristika des Kommunikationsmediums angepasst werden.
129
Weitere Ergebnisse der vorliegenden Arbeit nach Themen sortiert lauten:
Engpass-Analyse Experimente mit ASYNC auf Kommunikationsressourcen, dessen theore-
tische Bandbreite auf 10 MBit/s limitiert ist, haben gezeigt, dass bereits fu¨r kleine Markov-
Ketten-Modelle mit wenigen Millionen Zusta¨nden eine vollsta¨ndig entkoppelte Kommunikation
Engpa¨sse und Instabilita¨ten in der Berechnung erzeugt. Diese ko¨nnen vermieden werden, wenn
als Datenkonsumenten agierende Rechner bei Zugriff aus kommunizierte Daten ihren Aktualisie-
rungsbedarf beim Produzenten anmelden. In diesem Fall ist die Rate, mit der Daten ausgetauscht
werden, durch den Konsumenten partiell gesteuert, vgl. Def. 5.10, S. 57. Messungen auf der Ebe-
ne eines Kommunikationsnetzwerks haben gezeigt, dass bei Markov-Ketten-Modellen mit mehr
als 10 Millionen und einer Verteilung auf 4 Rechner der Kommunikationsaufwand bereits so
hoch ist, dass eine 10 MBit/s-Verbindung trotz konsumenten-gesteuerter Kommunikation nicht
ausreichend Kapazita¨t bietet, vgl. Abschnitt 6.1.1. Erfreulicherweise sind verfu¨gbare 1 GBit/s-
Verbindungen (Switch im Rechner-Cluster) fu¨r alle behandelbaren Problemgro¨ßen ausreichend.
Das gro¨ßte gelo¨ste Markov-Ketten-Modell hat knapp 897 Millionen Zusta¨nde. Die ASYNC -
Lo¨sung mit 14 Worker -Prozessen auf 7 Dualprozessoren beno¨tigt etwas u¨ber 55 Stunden, vgl.
Tab. 6.5. Wa¨hrend der ASYNC -Lo¨sung werden 1.2 Millionen Vektoren mit einem Datenvolumen
von insgesamt 8.5 Tera Bytes transferiert, vgl. Tab. 6.6. Es sind wenigstens 14 Worker -Prozesse
notwendig, um den Platzaufwand je Prozess auf unter 3 GB zu dru¨cken (durch Betriebssystem
vorgegebene Platzschranke).
Das zweitgro¨ßte gelo¨ste Modell hat 424 Millionen Zusta¨nde (SUH1-Modell mit k=6, vgl. Tab. 3.2)
und verursacht einen Platzaufwand je Prozess von 6.34 GB in einer 1-Prozess-Konfiguration und
2.30 GB in einer 4-Prozess-Konfiguration, vgl. Tab. 6.7. Dieses Modell ist fu¨r eine 1-Prozess-
Konfiguration zu gross (s.o.). Das SUH1-Modell mit k=7 hat bereits 1.3 Milliarden Zusta¨nde und
erzeugt einen Platzengpass. Eine Erho¨hung der Anzahl verfu¨gbarer Rechner von aktuell 6 auf 18
(mindestens) wu¨rde den Platzengpass beheben. Mo¨glicherweise verlagert sich dann der Engpass
wieder auf das Kommunikationsmedium, weil je Iterationsschritt ca. 28 GB Daten transferiert
werden mu¨ssen.
Auswertung des dynamischen Laufzeitverhaltens ASYNC bietet eine Experimentier-
umgebung, in der unterschiedliche Varianten asynchroner Iterationen zu Testzwecken auswa¨hlbar
sind, vgl. Tab. 5.4. In Trace-Dateien ko¨nnen zur Laufzeit Ereignisse und Zusta¨nde protokolliert
werden. Die statistische und visuelle Auswertung dieser Trace-Dateien ist sehr hilfreich und
gibt Einblick in den dynamischen Ablauf von Berechnung und Kommunikation, vgl. Abb. 6.3.
Experimente mit dem FMS-Modell haben gezeigt, dass schwach asynchrone Iterationen die Per-
formance total asynchroner Iterationen erreichen ko¨nnen, wenn die Last gut balanziert ist und
wenig Datenabha¨ngigkeiten (verursachen potentiell Synchronisation) bestehen, vgl. Tab. 6.1.
Die Visualisierung von Trace-Dateien hat gezeigt, dass sich nach einigen Iterationsschritten sta-
tiona¨re Rechen- und Kommunikationsmuster einstellen, die in wiederholten Ausfu¨hrungen nicht
reproduzierbar sind.
Beschleunigung und Effizienz ASYNC erreicht durch die Verteilung der Berechnung eine
aus praktischer Sicht akzeptable Effizienz zwischen 0.5 bis 0.75. Beispielsweise erreicht ASYNC
fu¨r das SUH1-Modell im Vergleich zu einer ASYNC -1-Prozess-Lo¨sung eine Beschleunigung von
1.47 (2 Prozesse), 2.61 (4 Prozesse) und 3.52 (6 Prozesse), vgl. Tab. 6.3. ASYNC kann schon
130
allein deswegen keine (optimalen) lineare Beschleunigung erzielen, weil die Asynchronita¨t in
der verteilten Berechnung einen signifikanten numerischen Mehraufwand gemessen an Iterati-
onsschritten bewirkt. Beispielsweise erho¨ht sich der numerische Aufwand beim U¨bergang von
einer 1-Prozess-Lo¨sung auf eine 2-Prozess-Lo¨sung um ca. 36%. Zudem ist jede gemessene Be-
schleunigung als stochastische Variable zu interpretieren, weil das Rechen- und Kommunika-
tionsmuster stochastisch ist (hat Einfluss auf die Effektivita¨t asynchroner Iterationen). In der
6-Prozess-Lo¨sung werden Beschleunigungen zwischen 3.39 (schlechteste) und 3.63 (beste) bei
unvera¨nderter Experimentumgebung gemessen.
Asynchronita¨t und Lo¨sungszeit In den Experimenten erbringen total asynchrone Itera-
tionen keine signifikante Performance-Vera¨nderung im Vergleich zu schwach asynchronen Ite-
rationen. Diese Aussage basiert auf Experimenten, in denen das FMS-Modell mit verschiedenen
Implementierungsvarianten schwach asynchroner Iteration gelo¨st wird (vgl. Tab. 6.1) und in
denen das SUH2-Modell mit partiell asynchronen Iterationen gelo¨st wird (vgl. Tab. 6.2).
Implementierung Fu¨r ASYNC ist eine Kommunikationsschnittstelle entwickelt worden, die
Funktionalita¨ten fu¨r verteilt und asynchron auszufu¨hrende Iterationsschritte bietet. Dies bein-
haltet Sende- und Empfangsbefehle mit asynchroner Semantik neben anderen, vgl. Abschnitt 5.6.1.
Die fu¨r eine asynchrone Berechnung notwendige Unabha¨ngigkeit von der Verfu¨gbarkeit kommu-
nizierter Daten wird durch eine Pufferung gewa¨hrleistet. Hierfu¨r sind unterschiedliche technische
Puffer-Realisationen verfu¨gbar, vgl. Abschnitt 5.6.3. Die Kommunikationsschnittstelle abstra-
hiert von allen technischen Details, insbesondere auch davon, ob die Funktionalita¨t auf PVM
oder wahlweise auf MPI aufsetzt, vgl. Abschnitt 5.6.2. So ist eine maximale Flexibilita¨t und
Portabilita¨t garantiert.
Modellbasierte Performance-Bewertung synchroner und asynchroner Iterationen
Stochastische Modelle zur zeitlichen Bewertung asynchroner Iterationen im Zusammenspiel mit
theoretischen Abscha¨tzungen der Konvergenzrate sind problematisch. Eine analytische Behan-
delbarkeit stochastischer Performance-Modelle und gewisse Anforderungen mathematischer Mo-
dell erzwingen, asynchrone Iterationen mit vielen Restriktionen zu betrachten. Bereits schwach-
asynchrone Iterationen fu¨hren zu komplexen stochastischen Modellen, vgl. Abschnitt 6.2.1.
Anwendbarkeit und Nu¨tzlichkeit Performance-Kennzahlen logistischer Systeme ko¨nnen
basierend auf Markov-Ketten und dem numerischen Lo¨sungsverfahren aus ASYNC ermittelt
werden. ASYNC ist benutzerfreundlich in die APNN-Toolbox integriert und kann von der graphi-
schen Benutzeroberfla¨che aus aufgerufen werden, vgl. Abschnitt 7.4. Die entwickelte Anbindung
des Markov-Ketten-Instrumentariums an das ProC/B -Modellierungs-Interface via automatisier-
ter Modellu¨bersetzer ermo¨glicht logistische Systeme einfach mit ASYNC zu analysieren, vgl. Ab-
schnitt 7.2. Die Anwendbarkeit und Nu¨tzlichkeit des ASYNC -Instrumentariums wird durch 3
Anwendungsbeispiele demonstriert. Dies beinhaltet die Bewertung von Performance-Kennzahlen
(Durchsatz bedienter LKWs, Auslastung involvierter Ressourcen) und die Risikoabscha¨tzung fu¨r
kritische Systemzusta¨nde in einer Stu¨ckgutumschlaghalle, die Berechnung eines Aggregats fu¨r
Lager-Prozesse in einer Lieferkette und eine Zuverla¨ssigkeitsanalyse von Prozessen mit ausfall-
behafteten Ressourcen, vgl. Abschnitt 8.2.
131
Steuerung Die Asynchronita¨t und Hierarchisierung der ASYNC -Iteration bieten zahlreiche
Parameter, die das stochastische Laufzeitverhalten und die Konvergenz der numerischen Be-
rechnung beeinflussen und als Steuerparameter zur Erzielung einer verbesserten Konvergenz
und Laufzeit dienen ko¨nnen. Allerdings hat es sich als schwierig herausgestellt, den Einfluss zu
bewerten. Die Aussagekraft beobachtbarer Wirkzusammenha¨nge aus einzelnen Experimenten
ist gering, weil sie - bedingt durch die inha¨rente Stochastik des Laufzeitverhaltens - nicht repro-
duzierbar und somit nicht allgemeingu¨ltig sind. Auch der Test von einfachen “Reinforcement-
Learning”-Strategien, um beispielsweise ein optimales Aufwand-Nutzen Verha¨ltnis fu¨r innere
Iterationen in der hierarchischen Iteration zu “lernen”, hat keinen signifikanten Vorteil erbracht.
Lediglich eine Steuerung in der ASYNC -Kommunikation konnte erfolgreich zur Vermeidung von
Engpa¨ssen im Kommunikationsmedium angewendet werden.
Ausblick Aus praktischer Perspektive wa¨re der Test noch gro¨ßerer Rechner-Cluster oder an-
derer paralleler Rechnerarchitekturen interessant. Eine Portierung von ASYNC auf andere, noch
leistungsfa¨higere Architekturen sollte einfach mo¨glich sein und die Lo¨sung noch gro¨ßerer Markov-
Ketten-Modelle erlauben. Auch wenn Rechenzeiten von mehreren Tagen einen Zeitengpass in
der Lo¨sung anzeigen, so lag der unmittelbare Engpass im zur Verfu¨gung stehenden Arbeitsspei-
cher (3 GB je Prozess). Abhilfe ko¨nnen hier platzeffiziente (symbolische, u.U. approximative)
Darstellungen fu¨r die Diagonaleintra¨ge in der Generatormatrix (hier explizit gespeichert) oder
des Iterationsvektors schaffen, die bekannt sind, in dieser Arbeit fu¨r die hierarchische und asyn-
chrone BJAC -Iteration aber nicht implementiert wurden.
ASYNC realisiert die verteilte und asynchrone Ausfu¨hrung einer hierarchischen BJAC -Iteration,
in der die Intra-Block-Lo¨sung eine (einfache) SOR-Iteration ist. Daru¨ber hinaus gibt es zahlreiche
weitere blockorientierte und hierarchische Fixpunkt-Iterationen, die bereits mit mehr “sophisti-
cated” problemspezifischen Anpassungen kombiniert wurden (z.B. Auswahl des Verfahrens zur
Intra-Block-Lo¨sung). In diesem Punkt ko¨nnte ASYNC erweitert werden.
Es wa¨re interessant, Problem-Instanzen zu identifizieren, fu¨r die Asynchronita¨t im Vergleich zu
synchronen oder schwach asynchronen Ausfu¨hrungen iterativer Verfahren einen Performance-
Vorteil erzielt, der in den hier betrachteten Problem-Instanzen durch einen numerischen Mehr-
aufwand (Anzahl notwendiger Iterationen) verhindert wird.
132
Literaturverzeichnis
[1] M. Ajmone Marsan, G. Balbo, and G. Conte. A class of generalized stochastic Petri nets for the
performance analysis of multiprocessor systems. ACM Transaction on Computer Systems, 2(1),
1984.
[2] M. Ajmone Marsan, G. Balbo, G. Conte, S. Donatelli, and G. Franceschinis. Modelling with genera-
lized stochastic Petri nets. Wiley, New York, USA, 1995.
[3] T. Altiok. Performance Analysis of Manufacturing Systems. Springer, 1997.
[4] D. Arnold, H. Isermann, A. Kuhn, and H. Tempelmeier. Handbuch Logistik. VDI Verlag, 2002.
[5] M. Arns, M. Fischer, and P. Kemper. Anwendung nicht-simulativer Techniken zur Analyse eines
dezentralen Gu¨terverkehrszentrums. Technischer Bericht 03017, SFB 559, ISSN 1612-1376, 2003.
[6] M. Arns, M. Fischer, P. Kemper, and C. Tepper. Supply chain modelling and its analytical evaluation.
Journal of the Operational Research Society, 53:885–894, 2002.
[7] J. M. Bahi. Asynchronous iterative algorithms for nonexpansive linear systems. J. of Parallel and
Distributed Computing, 60:92–112, 2000.
[8] H. Bartsch and P. Birkenbach. Supply Chain Management with SAP ’Advanced Planning Optimiza-
tion’ package. Galileo Press, 2001.
[9] G.M. Baudet. Asynchronous iterative methods. J. ACM, 25:226–244, 1978.
[10] F. Bause. Queueing petri nets - a formalism for the combined qualitative and quantitative analysis
of systems. 5th Int. Workshop on Petri Nets and Performance Models, pages 14–23, 1993.
[11] F. Bause, H. Beilner, M. Fischer, P. Kemper, and M. Vo¨lker. The ProC/B toolset for the modelling
and analysis of process chains. In T. Field, P.G. Harrison, J. Bradley, and U. Harder, editors,
Computer Performance Evaluation, Modelling Techniques and Tools, Springer LNCS 2324, pages
51–70, 2002.
[12] F. Bause, H. Buchholz, M. Fischer, and P. Kemper. Hybrid performability analysis of logistic
networks. In Parallel and Distributed Simulation, IEEE Computer Society, pages 131–138, 2004.
[13] F. Bause and P. Kritzinger. Stochastic Petri Nets - An Introduction to the Theory. Vieweg, 1996.
[14] F.B. Beidas and G.P. Papavassilopoulos. Convergence analysis of asynchronous linear iterations with
stochastic delays. Parallel Computing, 19:281–302, 1993.
[15] H. Beilner, R. Jansen, E. Jehle, A. Kuhn, and M. ten Hompel (Vorstand). SFB 559 ‘Mo-
dellierung großer Netze in der Logistik’ der Deutschen Forschungsgemeinschaft. im Internet:
http://www.sfb559.uni-dortmund.de/index.php, seit 1998.
[16] H. Beilner, J. Ma¨ter, and C. Wysocki. The hierarchical evaluation tool HIT. 7th Int. Conference on
Modelling Techniques and Tools for Computer Performance Evaluation, 1994.
133
[17] A. Bell. Disk-based and distributed generation and analysis of large stochastic models. GI/Dagstuhl
Research Seminar on Validation of Stochastic Systems, 2002.
[18] A. Berman and R. J. Plemmons. Nonnegative Matrices in the Mathematical Science. SIAM, 1994.
[19] D.P. Bertsekas and D. Tsitsiklis. Parallel and Distributed Computing - Numerical Methods. Prentice-
Hall, 1989.
[20] G. Bolch, S. Greiner, H. Meer de, and K. Trivedi. Queueing networks and Markov chains. J. Wiley,
1998.
[21] R. Bru, V. Migallo´n, J. Penade´s, and D.B. Szyld. Parallel, synchronous and asynchronous two-stage
multisplitting methods. Electronic Transaction on Numerical Analysis, 3:24–38, 1995.
[22] P. Buchholz. An adaptive aggregation/disaggregation algorithm for hierarchical markovian models.
J. of Operational Research, 116(3):545–564, 1999.
[23] P. Buchholz. Hierarchical structuring of superposed GSPNs. IEEE Transactions on Software Engi-
neering, 25(2):166–181, 1999.
[24] P. Buchholz. Projections methods for the analysis of stochastic automata networks. 3rd Int. Work-
shop on the Numerical Solution of Markov Chains (NSMC’99), in [86], pages 149–168, 1999.
[25] P. Buchholz. Structured analysis approaches for large Markov chains. Applied Numerical Mathema-
tics, 31(4):375–404, 1999.
[26] P. Buchholz. Multilevel solutions for structured Markov chains. SIAM J. Matrix Anal. Appl.,
22(2):342–357, 2000.
[27] P. Buchholz. An adaptive decomposition approach for the analysis of stochastic Petri nets. Perfor-
mance Evaluation, 56:23–52, 2004.
[28] P. Buchholz, G. Ciardo, S. Donatelli, and P. Kemper. Complexity of Kronecker operations and
sparse matrices with applications to the solution of Markov chain models. INFROMS Journal on
Computing, 12(3):203–222, 2000.
[29] P. Buchholz, M. Fischer, and P. Kemper. Distributed steady state analysis using Kronecker algebra.
3rd Int. Workshop on the Numerical Solution of Markov Chains (NSMC’99), in [86], pages 76–95,
1999.
[30] P. Buchholz, M. Fischer, P. Kemper, and C. Tepper. New features in the APNN-Toolbox. In
P. Kemper (ed.), editor, Tools at Int. Multiconference on Measurement, Modelling and Evaluation
of Computer-Communication Systems, Technical Report 760, University of Dortmund, pages 62–68,
2001.
[31] P. Buchholz and P. Kemper. On generating a hierarchy for GSPN analysis. ACM Performance
Evaluation Review, 26(2):5–14, 1998.
[32] P. Buchholz and P. Kemper. A toolbox for the analysis of discrete event dynamic systems. In
N. Halbwachs and D. Peled, editors, Computer Aided Verification, volume 1633 of Springer LNCS,
pages 483–486, 1999.
[33] P. Buchholz and P. Kemper. Kronecker based matrix representations for large Markov models. In
Validation of Stochastic Systems, volume 2925 of Springer LNCS, pages 256–295, 2004.
[34] S.L. Campbell and C.D. Meyer. Generalized Inverse of Linear Transformation. Dover (reprint),
New York, USA, 1991.
[35] H. Casanova, M.G. Thomason, and J.D. Dongarra. Stochastic performance prediction for iterative
algorithms in distributed environments. J. of Parallel and Distributed Computing, 58:68–91, 1999.
[36] C. Cassandras and S. Lafortune. Introduction to Discrete Event Systems. Kluwer, 1999.
134
[37] A. Chan, B. Gropp, and R. Lusk. Performance visualization of parallel programs.
http://www-unix.mcs.anl.gov/perfvis/, 2000.
[38] D. Chazan and W. Miranker. Chaotic relaxation. Linear Algebra and its Application, 2:199–222,
1969.
[39] G. Ciardo and K. S. Trivedi. A decomposition approach for stochastic reward net models. Perfor-
mance Evaluation, 18(3):37–59, 1993.
[40] Y. Cotronis and J. Dongarra (Eds.). Recent Advances in Parallel Virtual Machine and Message
Passing Interface. Springer LNCS 2131, 2001.
[41] Supply Chain Council. SCOR: Supply-Chain Reference Model. Version 4.0, 2000.
[42] P. J. Courtois. Decomposability: Queueing and Computer System Applications. Academic Press,
1977.
[43] C. G. Cullen. Matrices and Linear Transformations. Dover Publications, N.Y., 1990.
[44] T. Dayar and W.J. Stewart. Comparison of partitioning techniques for two-level iterative solvers on
large, sparse Markov chains. SIAM J. Scientific Computing, 21(5):1691–1705, 2000.
[45] N.J. Dingle and W.J. Knottenbelt. Distributed solution of large markov models using asynchronous
iterations and graph partitioning. In 18th UK Performance Engineering Workshop (UKPEW 2002),
pages 27–34, 2002.
[46] S. Donatelli. Superposed generalized stochastic petri nets: definition an efficient solution. In R. Va-
lette, editor, Application and Theory of Petri Nets, LNCS 815, pages 258–277. Springer, 1994.
[47] S. Donatelli and P. Kemper. Integrating synchronization with priority into a kronecker representa-
tion. Performance Evaluation, 44:73–96, 2001.
[48] J. Dongarra, S. Huss-Ledermann, S.W. Otto, M. Snir, and D.W. Walker. MPI - The Complete
Reference. MIT Press, 1996.
[49] W.J. Stewart (Ed). Numerical Solution of Markov Chains. Marcel Dekker, 1990.
[50] W.J. Stewart (Ed). Computations with Markov Chains. Kluwer, 1995.
[51] A. Geist et. al. PVM - Parallel Virtual Machine. MIT Press, 1994.
[52] M. Fischer. Numerische Verfahren zur quantitativen Analyse von ProC/B und Petri-Netz Modellen.
Technischer Bericht 03012, SFB 559, ISSN 1612-1376, 2003.
[53] M. Fischer and C. Dilling. Analytisch-numerische Techniken zur Lagerbestandanalyse unter Beru¨ck-
sichtigung einer zeitlich variierenden Last. Technischer Bericht 03013, SFB 559, ISSN 1612-1376,
2003.
[54] M. Fischer and P. Kemper. Modelling and analysis of a freight terminal with stochastic Petri nets.
Proc. of 9th IFAC Symposium Control in Transportation Systems 2000, 2:295–300, 2000.
[55] M. Fischer and P. Kemper. Distributed numerical Markov chain analysis. Euro PVM/MPI Confe-
rence, in [40], pages 272–279, 2001.
[56] M. Fischer and P. Kemper. Perspectives on performability evaluation in the ProC/B toolset. Proc.
6th Int. Workshop on Performability Modeling of Computer and Communication Systems, pages
35–38, 2003.
[57] M. Fischer, P. Kemper, and Ch. Mo¨ller. Markov-Ketten Analyse des Umschlag-Terminals eines
Gu¨terverkehrszentrums mit Petri-Netzen. DHF-Journal, 4:18–22, 2000.
[58] M. Fischer, P. Kemper, C. Tepper, and Z. Wu. Abbildung von ProC/B nach Petri netzen - version
2. Technischer Bericht 03011, SFB 559, ISSN 1612-1376, 2003.
135
[59] M. Fischer and C. Tepper. GSPNs to support aggregation in the ProC/B toolset. In P. Kemper
(ed): Workshop on Stochastic Petri nets and related formalisms, Technischer Bericht 780, Universita¨t
Dortmund, Fachbereich Informatik, pages 26–46, 2003.
[60] M. Fischer and Z. Wu. ASYNC Software-Entwurf
. http://ls4-www.informatik.uni-dortmund.de/home/fischer/PhD/Design/index.html, 2002.
[61] M. Fisz. Wahrscheinlichkeitsrechnung und mathematische Statistik. Verlag der Wissenschaften,
Berlin, 1989.
[62] A. Frommer and D.B. Szyld. Asynchronous two-stage iterative methods. Numerische Mathematik,
69:141–153, 1994.
[63] A. Frommer and D.B. Szyld. Asynchronous iterations with flexible communication for linear systems.
J. Calculateurs Paralleles, 210:421–429, 1998.
[64] A. Frommer and D.B. Szyld. On asynchronous iterations. J. of Computational and Applied Mathe-
matics, 23:201–216, 2000.
[65] C. Girault and R. Valk. Petri Nets for Systems Engineering - A Guide to Modeling, Verification,
and Applications. Springer, 2003.
[66] A. Graham. Kronecker Products and Matrix Calculus with Applications. J. Wiley and Sons, 1981.
[67] B.R. Haverkort, R. Marie, G. Rubino, and K. Trivedi. Performability Modelling - Techniques and
Tools. J. Wiley and Sons, 2001.
[68] B. Hendrickson and R. Leland. The Chaco user’s Guide, Version 2.0. Technical Report SAND94–
2692, Sandia Nat. Lab., 1995.
[69] M. Jeckle, C. Rupp, J. Hahn, B. Zengler, and S. Queins. UML 2 glasklar. Hanser, 2004.
[70] P. Kemper. Numerical analysis based on superposed GSPNs. IEEE Transactions of Software Engi-
neering, 22(9):615–628, 1996.
[71] W.J. Knottenbelt and P.G. Harrison. Distributed disk-based solution techniques for large Markov
models. 3rd Int. Workshop on the Numerical Solution of Markov Chains (NSMC’99), in [86], pages
58–75, 1999.
[72] A. Kuhn. Prozessketten in der Logistik: Entwicklungstrends und Umsetzungsstrategien. Verlag
Praxiswissen, 1995.
[73] P. J. Lanzkron, D.J. Rose, and D.B. Szyld. Convergence of nested classical iterative methods for
linear systems. Numerische Mathematik, 58:685–702, 1991.
[74] A.M. Law and W.D. Kelton. Simulation Modeling and Analysis. McGraw-Hill, 2000.
[75] C. Lindemann. Performance Modelling with Deterministic and Stochastic Petri Nets. Wiley, 1998.
[76] B. Lubachevsky and D. Mitra. A chaotic asynchronous algorithm for computing the fixed point of
a nonnegative matrix of unit spectral radius. J. of the ACM, 33(1):130–150, 1986.
[77] I. Marek and P. Mayer. Convergence analysis of an iterative aggregation/disaggregation method for
computing the probability vector of stochastic matrices. Numerical Linear Algebra with Applications,
5(4):253–274, 1998.
[78] I. Marek and D.B. Szyld. Local convergence of the (exact and inexact) iterative aggregation method
for linear systems and Markov operators. Numerische Mathematik, 69(1):61–82, 1994.
[79] I. Marek and D.B. Szyld. Comparison theorems for the convergence factor of iterative methods for
singular matrices. Linear Algebra and its Applications, 316:67–87, 2000.
136
[80] I. Marek and D.B. Szyld. Comparison of convergence of general stationary iterative methods for
singular matrices. SIAM Journal on Matrix Analysis and Applications (to appear), 2002.
[81] J. Ma¨ter and Studenten. Projektgruppe: Entwicklung eines Java-basierten Frameworks fu¨r verteilte
Netzwerk-Messungen
. http://ls4-www.informatik.uni-dortmund.de/QM/MA/jm/Toplehre/PG422/PG422.html, 2003.
[82] V. Migallo´n, J. Penade´s, and D.B. Szyld. Block two stage methods for singular systems and Markov
chains. Numerical Linear Algebra with Applications, 3:413–426, 1996.
[83] V. Migallo´n, J. Penade´s, and D.B. Szyld. Experimental study of parallel iterative solutions of
Markov chains with block partitions. 3rd Int. Workshop on the Numerical Solution of Markov
Chains (NSMC’99), in [86], pages 96–110, 1999.
[84] A.C. Moga and M. Dubois. Performance of asynchronous linear iterations with random delays. Proc.
of 10th Int. Parallel Processing Symposium (IPPS), pages 625–630, 1996.
[85] M. Neumann and R.J. Plemmons. Convergent nonegative matrices and iterative methods for consi-
stent linear systems. Numerische Mathematik, 31:265–279, 1978.
[86] B. Plateau, W.J. Stewart, and M. Silva (Eds.). Numerical Solution of Markov Chains. Prensas
University Press, 1999.
[87] D. Reed and Pablo Research Group. Pablo tool. http://www-pablo.cs.uiuc.edu/, 2003.
[88] Y. Saad. Projection Methods for the Numerical Solution of Markov Chain Models. in [49], 1990.
[89] A.W. Scheer. ARIS - Modellierungsmethoden, Metamodelle, Anwendungen. Springer, 2001.
[90] P.J. Schweitzer. A Survey of Aggregation-Disaggregation in Large Markov Chains. in [49], 1990.
[91] W. J. Stewart. Introduction to the numerical solution of Markov-chains. Princeton, 1994.
[92] J. C. Strikwerda. A probabilistic analysis of asynchronous iteration. Linear Algebra and its Appli-
cation (to appear), 349:125–154, 2002.
[93] Y. Su and A. Bhaya. Convergence of pseudocontractions and applications to Two-stage and asyn-
chronous multisplitting for singular M-matrices. SIAM J. of Matrix Analysis and Applications,
22(3):948–964, 2001.
[94] D.B. Szyld. The mystery of asynchronous iterations convergence when the spectral radius is one.
Research Report 98-102, Dept. of Mathematics, Temple Uni, Philadelphia, 1998.
[95] D.B. Szyld and M. T. Jones. Two stage and multisplitting methods for the parallel solution of linear
systems. SIAM Journal on Matrix Analysis and Applications, 13:671–679, 1992.
[96] A. U¨resin and M. Dubois. Effects of asynchronism on the convergence rate of iterative algorithms.
Journal of parallel and distributed computing, 34:66–81, 1996.
[97] J.S. Vetter and D.A. Reed. Real-time performance monitoring, adaptive control, and interactive
steering of computational grids. Int. Journal of High Performance Computing Applications, pages
357–366, 2000.
[98] D. M. Young. Iterative Solution of Large Linear Systems. Dover (unabridged republication of
Academic Press publication in 1971), 2003.
137