Verfahren zur Unterstützung der Arbeitsabläufe bei der Crash

Transcrição

Verfahren zur Unterstützung
der Arbeitsabläufe bei der
Crash-Simulation im Fahrzeugbau
Von der Fakultät Informatik, Elektrotechnik
Informationstechnik der Universität Stuttgart
zur Erlangung der Würde eines Doktors
der Naturwissenschaften (Dr. rer. nat.) genehmigte Abhandlung
vorgelegt von
Norbert Frisch
aus Hermannstadt
Hauptberichter:
Mitberichter:
Prof. Dr. T. Ertl
Prof. Dr. D. Roller
Tag der mündlichen Prüfung:
3.02.2004
Insititut für Visualisierung und Interaktive Systeme
Universität Stuttgart
2004
2
Kurzfassung
Der starke internationale Wettbewerb in der Automobilindustrie zwingt die Unternehmen
zu immer kürzeren Produktzyklen bei gleichzeitiger Reduzierung der Kosten bei der Fahrzeugentwicklung. Die passive Sicherheit ist dabei ein Thema von zunehmender Bedeutung
in der Karosserieentwicklung. Die Optimierung der passiven Sicherheit erfolgt heute vor
allem mit Hilfe von Crash-Simulationen am Rechner.
Im Rahmen der vorliegenden Arbeit wurden Verfahren zur Vorbereitung (Preprocessing) und Steuerung von Crash-Simulationen entwickelt. Damit lassen sich CrashSimulationen effizienter und bereits in der frühen Phase der Karosserieentwicklung
durchführen, in der Änderungen noch mit wenig Aufwand verbunden sind.
Die Forschungsarbeiten wurden im Rahmen der BMBF-Verbundprojekte AutoBench
und AutoOpt und in enger Zusammenarbeit mit dem Automobilhersteller BMW realisiert.
Ziel war die Entwicklung von Softwareprototypen zur Unterstützung der Berechnungsingenieure bei der Durchführung von Crash-Simulationen.
Zunächst werden Techniken zur Erkennung, Visualisierung und Beseitigung der bei der
Diskretisierung des CAD-Modells entstandenen Netzinkonsistenzen präsentiert. Ergänzt
werden diese Verfahren durch einen Algorithmus zur Gitterrelaxation, der die Gleichmäßigkeit der Finiten Elemente nach der Beseitigung von Netzinkonsistenzen wiederherstellt. Anschließend wird ein Verfahren zur Flanscherkennung beschrieben, welches als Grundlage für
weitere Algorithmen dient. Darauf aufbauend wird eine Vorgehensweise zur automatischen
Definition von Schweißpunktlinien auf Flanschen vorgestellt.
Ein breites Spektrum von Änderungen der Geometrie von Bauteilen durch Verformung
bietet die sogenannte Free-Form Deformation. Im Rahmen dieser Arbeit wurde dieses Verfahren weiterentwickelt und hinsichtlich Benutzerfreundlichkeit und Effizienz angepasst. In
Verbindung mit der Flanscherkennung wurde darauf aufbauend ein iterativer Algorithmus
zur Justierung des Abstandes von Flanschen entwickelt. Damit können außerdem Durchdringungen von Finiten Elementen auf Flanschen behoben werden. Beim sogenannten Massentrimm geht es schliesslich um die vereinfachte Darstellung von nichttragenden Teilen.
Dies vereinfacht den Berechnungsaufwand, da weniger Finite Elemente bei der Simulation
berücksichtigt werden müssen.
Durch die in dieser Arbeit entwickelten Preprocessing-Verfahren lässt sich das FiniteElemente-Netz für die Simulation aufbereiten, und es können Änderungen und Ergänzun-
4
gen am Netz vorgenommen werden. So kann z.B. die Auswirkung kleiner Änderungen auf
das Simulationsverhalten rasch untersucht werden, und durch Ergänzung eines noch unvollständigen Finite-Elemente Modells lassen sich bereits in der frühen Entwicklungsphase
Erkenntnisse über das Crashverhalten gewinnen.
Die hier vorgestellten Verfahren wurden innerhalb einer Anwendung zur Visualisierung und Modellierung von Finite-Elemente-Modellen realisiert. Zusätzlich wurde diese
Anwendung an die Integrationsumgebung CAE-Bench angebunden. CAE-Bench bietet eine
Web-basierte Benutzerführung und eine einheitliche Bedienoberfläche für die verschiedenen
Anwendungen bei der Crash-Simulation. Es wurde ein spezielles Java-Applet entwickelt,
welches in die CAE-Bench Web-Seite eingebettet wird. Dieses Applet kommuniziert mit der
Anwendung über CORBA und mit der CAE-Bench Web-Seite mit Hilfe von Java und Javascript Methodenaufrufen. Eine weitere CORBA-Schnittstelle der Anwendung ermöglicht
den Abruf und die Visualisierung von Zwischenergebnissen der laufenden Simulation. So
lässt sich frühzeitig Einfluss auf die Simulation nehmen, ein Vorgehen, das als Simulation
Steering bezeichnet wird.
Die vorliegende Arbeit kombiniert Ansätze aus den verschiedenen Bereichen der Informatik, z.B. aus dem Bereich der geometrischen Algorithmen, der Computergraphik, der
Visualisierung und der geometrischen Modellierung, sowie aus dem Bereich der Benutzerschnittstellen und der Web-basierten und Middleware-Technologien. Durch die Beiträge
dieser Arbeit wird eine schnelle und frühzeitige Durchführung von Crash-Simulationen unterstützt. Dies führt durch Simultaneous Engineering zu einer signifikanten Verkürzung der
Entwicklungszeiten bei der Fahrzeugkonstruktion.
Inhaltsverzeichnis
1 Einführung
13
1.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2
Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3
Beiträge dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.4
Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2 Grundlagen
21
2.1
Arbeitsabläufe bei der Karosserie-Entwicklung . . . . . . . . . . . . . . . .
21
2.2
Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3
Finite-Elemente-Simulation . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4
Grundlagen der Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.5
Grundlagen der Computergraphik . . . . . . . . . . . . . . . . . . . . . . .
31
2.5.1
Die Graphik-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.5.2
Beleuchtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.5.3
Texturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Visualisierung von Finite-Elemente-Modellen . . . . . . . . . . . . . . . . .
36
2.6.1
Verwendete Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.6.2
Beschleunigung des Bildaufbaus . . . . . . . . . . . . . . . . . . . .
38
2.6.3
Wiederverwertung von Bildspeicherinhalten . . . . . . . . . . . . .
39
2.6.4
Verwendung von Texturen . . . . . . . . . . . . . . . . . . . . . . .
41
Effiziente Distanzbestimmung mit Hilfe von Bounding Volumes . . . . . . .
42
2.6
2.7
6
INHALTSVERZEICHNIS
3 Perforationen und Penetrationen
45
3.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.2
Erkennung und Visualisierung von Perforationen . . . . . . . . . . . . . . .
46
3.3
Beseitigung von Perforationen . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.4
Gitterrelaxation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.5
Erkennung und Visualisierung von Penetrationen . . . . . . . . . . . . . .
52
3.6
Beseitigung von Penetrationen . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.7
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4 Erkennen von Flanschen
59
4.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.2
Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.3
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5 Automatische Definition von Schweißpunktverbindungen
65
5.1
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.2
Szenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.3
Szenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.4
Szenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.5
Zeitverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6 Veränderung von Bauteilen mittels Free-Form Deformation
77
6.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
6.2
Grundlagen der Free-Form-Deformation . . . . . . . . . . . . . . . . . . . .
78
6.3
Grundlagen der B-Splines . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
6.4
Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.5
Explizite Berechnung der Verschiebungen . . . . . . . . . . . . . . . . . . .
90
6.6
Überlegungen zur Bearbeitung von FE-Modellen mittels DMFFD . . . . .
94
6.7
Verwendung eines temporären Kontrollgitters . . . . . . . . . . . . . . . .
95
6.8
Verwendung von B-Splines über uniformem Knotenvektor . . . . . . . . . .
97
INHALTSVERZEICHNIS
6.9
Verwendung eines lokalen FFD-Volumens . . . . . . . . . . . . . . . . . . .
7
98
6.10 Die Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.11 Justierung des Abstandes von Flanschen . . . . . . . . . . . . . . . . . . . 106
6.12 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7 Massentrimm
113
8 Integration
117
8.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.2
CORBA Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.3
Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.4
Vorbereitende Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.5
Anbindung des Visualisierungstools an den FE-Solver . . . . . . . . . . . . 124
8.6
8.5.1
Schnittstellengestaltung mit Hinblick auf zeitliche Kohärenz . . . . 124
8.5.2
Besonderheiten beim Verbindungsaufbau . . . . . . . . . . . . . . . 125
Einbettung des Visualisierungstools in die Integrationsplattform . . . . . . 126
9 Gesamtbetrachtung der Prozesskette
131
10 Zusammenfassung und Ausblick
135
Abstract
137
8
INHALTSVERZEICHNIS
Abbildungsverzeichnis
1.1
Einfluß der Datenauflösung auf das Simulationsergebnis . . . . . . . . . . .
14
1.2
Das Visualisierungstool für Finite-Elemente-Modelle CrashViewer . . . . .
17
2.1
Zusammenwirken von Daten und Simulation [35] . . . . . . . . . . . . . . .
22
2.2
Entwicklung von Crash-Simulation in der Industrie nach [37] . . . . . . . .
23
2.3
Die Prozesskette in der CAE-Simulation nach [86] . . . . . . . . . . . . . .
24
2.4
Simulationszyklus beim Karosserieentwurf . . . . . . . . . . . . . . . . . .
25
2.5
Typen von finiten Elementen bei der Crash-Simulation. . . . . . . . . . . .
27
2.6
Der Simulations- und Visualisierungszyklus . . . . . . . . . . . . . . . . . .
29
2.7
Die Graphik-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.8
Darstellung einer Kugel, links mit und rechts ohne Beleuchtungseffekte. . .
33
2.9
Richtungen und Winkel bei der Beleuchtungsberechnung . . . . . . . . . .
34
2.10 Schattierung am Beispiel zweier Dreiecke . . . . . . . . . . . . . . . . . . .
35
2.11 Anwendung einer Textur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.12 Bildbasierte Translation parallel zur Bildebene . . . . . . . . . . . . . . . .
40
2.13 Bildbasierte Translation senkrecht zur Bildebene . . . . . . . . . . . . . . .
40
2.14 Verwendung von Texturen bei der Visualisierung von finiten Elementen . .
41
2.15 Bounding-Volume-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.1
Skizze: Entstehung von Perforationen und Penetrationen . . . . . . . . . .
45
3.2
Visualisierung und Beseitigung einer Perforation . . . . . . . . . . . . . . .
47
3.3
Symmetrische Perforation . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
10
ABBILDUNGSVERZEICHNIS
3.4
vollständige vs. nicht vollständige Trennung durch Perforation . . . . . . .
49
3.5
Knoten mit Projektionen auf mehrere Elemente . . . . . . . . . . . . . . .
49
3.6
Beispielskizze zur Relaxation . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.7
Skizze: Umbrella-Operator . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.8
Gitterrelaxation (Beispiel) . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.9
Umgebung eines Elements, in der Penetrationen auftreten können . . . . .
54
3.10 Ungleichmäßige Verteilung der Penetrationskräfte . . . . . . . . . . . . . .
54
3.11 Mehrfache Penetration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.12 Praxisbeispiel mit mehreren Perforationen . . . . . . . . . . . . . . . . . .
56
3.13 Farbliche Visualisierung der Perforationen auf dem zu verändernden Bauteil
56
3.14 Ansicht nach Behebung der Perforationen
. . . . . . . . . . . . . . . . . .
56
3.15 Verschiebung eines einzelnen, vom Benutzer spezifizierten Netzknotens, zur
Behandlung von Sonderfällen. . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.16 Detailansicht vor und nach der Gitterrelaxation . . . . . . . . . . . . . . .
57
3.17 Visualisierung der Bauteilabstände, vor und nach der Beseitigung der Penetrationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.1
Skizze Flanscherkennung: Nachbarschaftssuche, Baumdiagramm . . . . . .
62
4.2
Ringförmig geschlossener Flansch mit ungleichmäßiger Breite . . . . . . . .
63
4.3
Flansch gegeben durch zwei überlappende Bleche . . . . . . . . . . . . . .
63
4.4
Flansch mit Unebenheiten (Sicken) . . . . . . . . . . . . . . . . . . . . . .
64
5.1
Sicken und Lücken erschwerden die Flanscherkennung . . . . . . . . . . . .
67
5.2
Randfindung für Schweißpunktlinien
. . . . . . . . . . . . . . . . . . . . .
70
5.3
Schritte beim Anlegen einer Schweißpunktlinie . . . . . . . . . . . . . . . .
70
5.4
Anwendungsbeispiel für Szenario 1 . . . . . . . . . . . . . . . . . . . . . .
71
5.5
Skizze: Suche der Flansch-Enden . . . . . . . . . . . . . . . . . . . . . . .
72
5.6
73
5.7
74
5.8
Skizze: Flanschkriterium Gitterausrichtung . . . . . . . . . . . . . . . . . .
75
11
5.9
Skizze: Ungeeignete Elemente . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.1
Verformung eines Zylinders durch Free-Form Deformation . . . . . . . . . .
78
6.2
Beispiele von Bézier Kurven und deren Basisfunktionen . . . . . . . . . . .
80
6.3
2D-Prinzip der FFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
6.4
Lineare Präzision (Beispiel) . . . . . . . . . . . . . . . . . . . . . . . . . .
82
6.5
Inkonsistentes Deformationsverhalten bei Bézier-Splines . . . . . . . . . . .
84
6.6
B-Splines mit n + 1-fachen Endknoten . . . . . . . . . . . . . . . . . . . .
86
6.7
B-Splines über uniformem Knotenvektor . . . . . . . . . . . . . . . . . . .
86
6.8
Muti-Resolution-Ansatz nach Kobbelt . . . . . . . . . . . . . . . . . . . . .
91
6.9
Verschiebung der Kontrollpunkte bei DMFFD (Beispiel) . . . . . . . . . .
93
6.10 Relevante Kontrollpunkte bei der DMFFD-Verschiebung eines Objektpunktes 94
6.11 Deformationsverhalten und Anordung der Kontrollpunkte bei Ein-PunktVerschiebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.12 Beschränkung der Deformation auf eine Dimension (Beispiel). . . . . . . . 101
6.13 Verschieben eines Bereiches unter Beibehaltung seiner Form . . . . . . . . 103
6.14 Benutzerschnittstelle für DMFFD . . . . . . . . . . . . . . . . . . . . . . . 105
6.15 Beseitigung von Perforationen und übergroßen Bauteilabständen . . . . . . 109
6.16 Beseitigung von Perforationen durch Justierung des Abstandes auf einem
längeren Flansch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.1
Visualisierung von vier strukturlosen Massen durch 3D-Glyphen . . . . . . 115
7.2
Visualisierung eines Bauteils zusammen mit dessen Trägheitseigenschaften.. 115
8.1
Die CORBA Client-Server Architektur . . . . . . . . . . . . . . . . . . . . 119
8.2
Die Benutzeroberfläche von COVISE . . . . . . . . . . . . . . . . . . . . . 121
8.3
Der PamServer simuliert ein CORBA-fähiges PAM-CRASH
8.4
Zusammenspiel der Komponenten bei der Crash-Visualisierung . . . . . . . 127
8.5
Anbindung des Visualisierungstools an CAE-Bench . . . . . . . . . . . . . 129
8.6
CAE-Bench Web Seite mit eingebettetem Java Applet . . . . . . . . . . . . 130
. . . . . . . . 122
10.1 Verkürzung der Entwicklungszeiten in der Karosserieentwicklung . . . . . . 135
12
Kapitel 1
Einführung
1.1
Einleitung
Kein Werkzeug und kein wissenschaftliches Instrument hat in der Geschichte der Menschheit einen so gewaltigen technischen Wandel in einer so kurzen Zeit bewirkt wie der Computer. Für die Numerische Simulation und das Wissenschaftliche Rechnen ist insbesondere die
Leistungsfähigkeit des Computers ausschlaggebend, dazu die Kommunikationsgeschwindigkeit und die weltweite Vernetzung.
Die Leistungssteigerung lässt sich auch für die Zukunft vorhersagen: Das sogenannte
Moore’sche Gesetz besagt, dass sich die Rechenleistung von Computern durch deren Weiterentwicklung alle 18 Monate verdoppeln wird. Mit dem stetigen Wachstum der verfügbaren
Rechenleistung nimmt die Komplexität der rechnergestützt lösbaren Problemstellungen zu.
Die Leistung von 3D-Graphikhardware wächst derzeit sogar noch schneller als die Rechenleistung des Hauptprozessors und übertrifft damit das Moore’sche Gesetz. Die Entwicklung neuer, effizienter Algorithmen trägt zusätzlich zur Steigerung der Leisungsfähigkeit von Computern bei. Auch die Parallelisierung, d.h. die Aufteilung der Berechnung auf
mehrere Prozessoren, ermöglicht in vielen Fällen eine Beschleunigung der Berechnung. Der
große Leistungszuwachs der Graphikprozessoren ist nicht zuletzt auch der guten Parallelisierbarkeit von Graphikroutinen zu verdanken.
Trotz dieser raschen Entwicklung der Rechnerkapazität gibt es viele Anwendungsgebiete, deren Bedarf an Rechenleistung auch in absehbarer Zukunft nicht gedeckt sein wird.
Rechnergestützte Simulationen beispielsweise liefern um so genauere Ergebnisse, je feiner
das Ausgangsproblem diskretisiert ist. Besonders bei chaotischen Systemen, etwa beim
Wetter, wo kleinste Änderungen der Eingabeparameter eine bedeutende Änderung des
Ergebnisses bewirken können, ist eine möglichst detaillierte Aufstellung der Anfangsparameter erforderlich, wie das Beispiel aus Abbildung 1.1 zeigt.
14
Einführung
Abbildung 1.1: Einfluß der Datenauflösung auf das Simulationsergebnis: Wettersimulation,
links mit 120km und rechts mit 60km Auflösung der Ausgangsdaten [28]
Für jede Wetterprognose müssen dabei ungefähr 250 Millionen Unbekannte berechnet
werden. Erst seit etwa zwei Jahrzehnten sind Großrechner so leistungsfähig, dass die Wetterberechnungen weniger Zeit erfordern als die Wetterentwicklung selbst dauert: Erst seit
dieser Zeit ist eine realistische numerische Wetterprognose also überhaupt möglich. Dies
ist nur eine von vielen Anwendungsmöglichkeiten von rechnerbasierter Simulation realer
Vorgänge.
Ist eine Simulation durchgeführt, stellt sich die Frage nach der Auswertung der Ergebnisse. Meist bietet eine Visualisierung der Ergebnisse die besten Voraussetzungen für deren
Auswertung, da der Mensch visuelle Information am effizientesten verarbeiten kann. Simulation wird erst durch ihre Visualisierung, dreidimensional oder als Animation, interessant.
Milliarden von Zahlen, welche die klimatische Entwicklung in den nächsten hundert Jahren beschreiben, bleiben langweilig und sind auch für Experten nur begrenzt aussagefähig.
Aber die sichtbar gemachte globale Erwärmung, das sichtbar gemachte Ozonloch, rüttelt
die Öffentlichkeit und die Politiker auf, gibt auch dem Fachmann neue Einsichten, liefert
ihm Ideen und wirft neue Fragen auf [29].
Die dreidimensionale, interaktive Visualisierung ermöglicht die visuelle Vermittlung
umfangreicher Informationen und die Wahrnehmung komplexer Zusammenhänge. Die
Möglichkeit, dreidimensionale Objekte interaktiv zu rotieren, verbessert den dreidimensionalen Eindruck beträchtlich, besonders bei der üblichen, zweidimensionalen Darstellung
am Bildschirm. Durch interaktive Rotation kann zudem rasch ein Eindruck von der gesamten äußeren Form und Beschaffenheit eines Objektes vermittelt werden.
3D-Visualisierung erfordert neben Rechenleistung meist auch eine beträchtliche Graphikleistung des Rechners, speziell wenn es sich um große Datensätze handelt und wenn
Interaktivität erwünscht wird. Interaktivität bedeutet hier, dass der Benutzer verschiedene
Parameter, den Blickpunkt oder die Farbzuordnung verändern kann, wobei das Resultat
dieser Änderungen mit nur geringer Verzögerung angezeigt wird. Je nach Anwendungsart
1.2 Szenario
15
beträgt die akzeptable Verzögerung (“Antwortzeit”) zwischen einer zehntel Sekunde im
Falle von flüssigen Animationen und einigen Sekunden bei nur gelegentlicher Veränderungen der Darstellungsparameter. Um die Interaktivität zu gewährleisten, wurde auch im
Rahmen der vorliegenden Arbeit großer Wert auf die Effizienz der Algorithmen und deren
Implementation gelegt.
1.2
Szenario
Das Thema der hier vorgestellten Arbeit ist im Berech der Automobilentwicklung angesiedelt. Beim Entwurf und der Entwicklung von Automobilen ist numerische Simulation heute
eine der wichtigsten Technologien. Crash-Simulation, Umformtechnik, Analysen von Stabilität und Schwingungsverhalten der Karosserie und anderer Baugruppen sind nur einige
Anwendungsfelder, in denen numerische Simulation den Entwicklungszyklus von Automobilen substantiell verkürzt hat.
Speziell die Crash-Simulation ist für die vorliegende Arbeit von Bedeutung. Die
Durchführung einer Crashsimulation, einschließlich Vorbereitung und Auswertung, ist eine Kette von Arbeitsschritten. Dabei sind eine Vielzahl von Ingenieuren aus mehreren
Abteilungen und eine Vielfalt an Software-Werkzeugen beteiligt.
Wurde ursprünglich die Fahrzeuggeometrie auf dem Papier entworfen, so werden nun
schon seit geraumer Zeit sämtliche Bauteile des Fahrzeugs mit Hilfe von CAD-Software
am Computer entwickelt. Die so erstellten Entwürfe können leichter verändert, in einer
Datenbank verwaltet und durch andere Computerprogramme weiterverwendet werden. So
können die CAD-Daten beispielsweise als Ausgangsdaten für die Werkzeugentwicklung
oder für die Erkennung von Inkonsistenzen und Montageproblemen dienen. Ebenso dienen
die CAD-Daten als Input für die Simulationen von Zusammenstößen, wie sie bei Verkehrsunfällen vorkommen. Crash-Simulationen sind äußerst hilfreich wenn es darum geht, die
passive Sicherheit von Fahrzeugen zu erhöhen.
Unter passiver Sicherheit versteht man den Schutz vor Verletzungen bei einem Unfall. Aktive Sicherheit hingegen dient der Vermeidung von Unfällen. Ursprünglich galt das
Bestreben der Fahrzeugentwickler einzig der Erhöhung der aktiven Sicherheit, z.B. durch
Verbesserungen an Fahrwerk, Bremsen, Lenkung, Beleuchtung. Fehler des Fahrzeuglenkers
sind jedoch nicht auszuschließen, und mit zunehmendem Verkehrsaufkommen wurde klar,
dass neben der aktiven auch die passive Sicherheit der Fahrzeuge erhöht werden muss.
Bereits in den 1960er Jahren begannen die Entwickler verschiedener Automobilfirmen sich
zu überlegen, wie man die Verletzungsgefahr bei einem Unfall mindern könnte. Wichtigste Ergebnisse dieser Überlegungen sind der Sicherheitsgurt, diverse Verbesserungen an
Karosserie und Fahrgastzelle, sowie die Einführung des Airbags.
Zur Überprüfung der passiven Sicherheit werden sogenannte Crash-Tests durchgeführt.
Dabei wird unter genau festgelegten Bedingungen ein Unfall nachgestellt und dessen Aus-
16
Einführung
wirkungen auf die Insassen analysiert. Die Rolle der Insassen wird hierbei durch spezielle
Puppen, Dummies genannt, übernommen.
Um die Schwachstellen eines Modells noch vor der Serienfertigung zu beseitigen, werden für die Crash-Tests eigens angefertigte Prototypen verwendet. Die Herstellung dieser
Prototypen ist zeitaufwändig und teuer, was besonders wegen der Beschränkung auf eine
einmalige Verwendung ins Gewicht fällt.
Crash-Simulationen am Computer hingegen sind preisgünstiger und schneller, denn sie
benötigen keine realen Prototypen. Waren sie in der Anfangszeit die Crash-Simulationen
noch recht ungenau, können heute die realen Crash-Tests auf die vom Gesetzgeber vorgeschriebene Mindestanzahl beschränkt werden. Diese Entwicklung ist vor allem der stetig
wachsenden Rechenleistung zu verdanken, welche für Simulationen zur Verfügung steht.
Die Crash-Simulation am Computer wird mit Hilfe der Finite-Elemente-Methode
(FEM) durchgeführt. Dazu müssen die im CAD-Format vorliegenden Geometriedaten diskretisiert werden, also in ein möglichst gleichmäßiges Gitter von kleinen Elementen zerlegt
werden. Diese sogenannten finiten Elemente sind aus numerischen Gründen größtenteils
Vierecke, wenn es um die Darstellung von Blechteilen geht. Je feiner das Gitter ist, also je
kleiner und damit zahlreicher die finiten Elemente sind, umso genauer sind die Ergebnisse
der Simulation, und umso größer ist der Bedarf an Rechnerleistung.
Die Finite-Elemente-Simulation ist ein iterativer Prozess. Die kurze Zeit des Aufpralls
wird hierzu in bis zu eine Million Intervalle unterteilt. Das Ergebnis nach einem Zeitschritt
stellt dabei den Input für den nächsten Zeitschritt dar. Diese Daten umfassen unter anderem die Geschwindigkeiten, die auftretenden Kräfte und andere physikalische Parameter
für jedes der finiten Elemente.
Kleinere Elemente erfordern kleinere und damit mehr Zeitschritte. Ein Zeitschritt muss
kleiner sein als die Zeit, die eine Schwingung, z.B. eine Schallwelle benötigt, um das kleinste Element zu traversieren. Damit ist klar, dass für eine Steigerung der Genauigkeit nicht
nur mehr Elemente, sondern auch mehr Zeitschritte in die Berechnung einbezogen werden müssen. Die wachsende Rechnerleistung und Parallelisierung ermöglichen eine immer
feinere Auflösung des Problemraumes bei gleichzeitiger Verkürzung der Rechenzeiten. Neben der Verbesserung der Genauigkeit führt dies auch zu einer wachsenden Größe der
Datensätze, die den Input und den Output der Simulation darstellen.
Für die Vorbereitung und Auswertung dieser Daten, dem sogenannten Pre- und Postprocessing, stellt die Datenmenge eine Herausforderung dar. Durch die fortgeschrittene
Entwicklung der Graphik-Hardware und durch verbesserte Algorithmen ist heute dennoch
eine interaktive, dreidimensionale Visualisierung der gesamten Fahrzeuggeometrie erreichbar.
Das Visualisierungstool CrashViewer (Abb. 1.2), das im Rahmen dieser Arbeit weiterentwickelt wurde, kann sowohl die Eingabe- als auch die Ausgabedaten der CrashSimulation dreidimensional interaktiv darstellen. Für Eingabedaten gibt es eine Reihe von
1.3 Beiträge dieser Arbeit
17
Abbildung 1.2: Das Visualisierungstool für Finite-Elemente-Modelle CrashViewer
Editiermöglichkeiten, auf die noch eingegangen wird. Ausgabedaten können animiert dargestellt werden, wobei eine Sequenz von etwa 50 Zeitschritten Einblick in den Crash-Ablauf
bietet. Dabei können diverse physikalische Parameter durch Farben und Zusatzgeometrie
visualisiert werden.
Basierend auf CrashViewer entstand das kommerzielle Tool FEMod der Firma
science+computing, das CrashViewer ablöst und auch in einer prototypischen Version der
Universität Stuttgart für Forschungszwecke zur Verfügung steht. Die Arbeiten an CrashViewer wurden weitestgehend im Rahmen des BMBF Projektes Autobench durchgeführt.
Die Beteiligung der Universität Stuttgart am Nachfolgeprojekt AutoOpt basiert schon auf
dem FEMod Prototypen.
1.3
Beiträge dieser Arbeit
Die vorliegende Arbeit liefert eine Reihe von Beiträgen zur Unterstützung der Arbeitsabläufe bei der Crash-Simulation. Durch die beschleunigten Arbeitsläufe wurde ein signifikanter Beitrag zur Verkürzung der Entwicklungszeiten neuer Fahrzeugmodelle geleistet.
Die Neuentwicklungen dieser Arbeit umfassen verschiedene Algorithmen für das Preprocessing, sowie die Einbettung des Visualisierungstools in eine Integrationsumgebung.
Außerdem wurde anhand eines Prototypen der Betrieb des Visualisierungstools in einer
Virtual-Reality-Umgebung untersucht.
18
Einführung
Unter Preprocessing versteht man die Aufbereitung der Karosseriedaten für die CrashSimulation. Beim Diskretisieren der CAD-Daten erhält man ein Finite-Elemente-Netz,
welches Inkonsistenzen wie Perforationen und Penetrationen enthalten kann. Besonders
in frühen Konstruktionsphasen sind auch ganze Bauteile zu verändern, zu ersetzen oder
miteinander zu verbinden.
Im Bereich des Preprocessing wurde ein Algorithmus zum automatischen Generieren
von Schweißpunktverbindungen entwickelt. Dazu wurde eine Methode zur Erkennung von
Flanschen sowie eine Methode zum Bestimmen der Mittellinie längs des Flansches bereitgestellt. Auf dieser Mittellinie oder auf einem Abschnitt davon können dann automatisch
äquidistante Schweißpunkte generiert werden.
Das automatische Setzen von Schweißpunkten bedeutet eine Reduzierung des Arbeitsaufwandes um ein Vielfaches beim Definieren von Schweißverbindungen. Anstatt die Position eines jeden Schweißpunktes mit der Computermaus anzugeben, reicht es nun, auf den
Flansch zu zeigen, der verschweißt werden soll. Auch ein vollautomatisches Verschweißen
sämtlicher Flansche ist möglich.
Ferner wurde aufbauend auf dem Verfahren zur Flanscherkennung im Rahmen der Arbeit von Rose [26] eine Methode zum automatischen Generieren von Klebeverbindungen
entwickelt. Im Gegensatz zu den Schweißpunktverbindungen handelt es sich bei Klebeverbindungen nicht um punktförmige, sondern um Flächenverbindungen.
Ein weiteres Feature ist der Austausch von Bauteilen. Einzelne Bauteile können durch
Varianten ersetzt werden, um deren Crash-Verhalten zu testen oder weil die endgültige
Version erst zu einem späteren Zeitpunkt vorliegt. Beim Austausch von Bauteilen können
die Schweißpunktverbindungen soweit wie möglich wiederverwendet werden. Wo eine Wiederverwendung nicht möglich ist, wird der betreffende Schweißpunkt visuell hervorgehoben,
so dass der Konstrukteur über die weitere Vorgehensweise entscheiden kann.
Bauteile, deren Geometrie für die Berechnung unwesentlich ist, weil sie keine tragende
Rolle spielen, können in einer symbolischen Form (als Glyph) visualisiert werden. Das Gewicht und die Trägheitseigenschaften dieser Bauteile werden im Rahmen des sogenannten
Massentrimms auf umliegende Bauteile verteilt. Auch hierfür wurden im Rahmen dieser
Arbeit Beiträge geleistet.
Ebenfalls im Preprocessing-Bereich wurde das Erkennen, die Visualisierung und das
Beseitigen von Perforationen sowie von Penetrationen realisiert. Um eventuelle Verzerrungen des FE-Netzes nach dem Beseitigen der Perforationen zu eliminieren wurde zudem ein
Algorithmus zur Gitterrelaxation entwickelt.
Im Laufe der Zeit wurde der Bedarf an einer größeren Vielfalt von Deformationsmöglichkeiten für Bauteile immer deutlicher. Die einfachste Vorgehensweise, die Neupositionierung
einzelner Knoten, bietet zwar ein Maximum an Flexibilität. In vielen Fällen ist es jedoch
sehr aufwendig, durch Neupositionierung einzelner Knoten die gewünschte Bauteil-Form
zu erhalten.
1.4 Gliederung der Arbeit
19
In der Regel ist das gleichzeitige Verschieben mehrerer Netzknoten sinnvoll, wobei
ein stetiger Übergang zur undeformierten Region wünschenswert ist. Dieser Anforderung
wurde durch die Implementierung von sogenannter Direkter Manipulation von Frei-Form
Deformationen (Direct Manipulation of Free-Form Deformation, DMFFD) entsprochen.
Das Spline-basierte Verfahren wurde an die problemspezifischen Anforderungen angepasst.
Gleichzeitig wurde die Performanz und Benutzerfreundlichkeit dieses Verfahrens gesteigert.
Zur Benutzerfreundlichkeit trägt dabei auch eine Benutzerschnittstelle bei, welche einfach
zu bedienen ist und gleichzeitig optimale Genauigkeit und Flexibilität bietet.
Die Erhöhung der Benutzerfreundlichkeit ist auch Zweck der Integrationsumgebung
CAE-Bench. Die Integrationsumgebung stellt eine Web-basierte Benutzerschnittstelle dar,
mit deren Hilfe die verschiedenen an der Crash-Simulation beteiligten Programme koordiniert und gesteuert werden können. CAE-Bench reduziert den Einarbeitungsaufwand für
die Bedienung der verschiedenen Programme und koordiniert den Datenaustausch zwischen
diesen Programmen, was dem Benutzer viel Arbeit abnimmt.
Für die Integration des Visualisierungstools wurde ein Java Applet entwickelt, welches
in die CAE-Bench Web-Seite eingebettet ist, und so die Steuerung der Visualisierungapplikation basierend auf dem CORBA-Protokoll ermöglicht. Weiterhin wurde eine CORBASchnittstelle definiert und implementiert, welche das direkte Einlesen von Ergebnissen und
sogar von Zwischenergebnissen aus dem FE-Simulationsprogramm ermöglicht. Diese Vorgehensweise ist schneller als der herkömmliche Weg über ein zentrales Dateisystem und
ermöglicht es, den Benutzer von der Verwaltung der Ergebnisdateien zu befreien.
Die Erkenntnisse aus der Integration des Visualisierungstools wurden in [23] veröffentlicht. In den Publikationen [25] und [26] wird u.a. die Flanscherkennung und das automatische Erzeugen von Schweißpunktlinien behandelt. In [26] wird außerdem die Erkennung,
Visualisierung und Behebung von Bauteildurchdringungen beschrieben. In [71] geht es um
die Visualisierung und Manipulation spezieller Elemente wie strukturlose Massen. Das Editieren von FE-Netzen durch DMFFD sowie die automatische Korrektur von Flanschen ist
Thema von [24].
Im Rahmen der Forschungsarbeit wurden zwei Studienarbeiten betreut. Jenz Künzl
behandelte die Visualisierung und Beseitigung initialer Durchdringungen bei FiniteElemente-Gittern. Thomas Piekarski beschäftigte sich mit der Anpassung des CrashViewers
zur immersiven Visualisierung.
1.4
Gliederung der Arbeit
Im ersten Kapitel erhält der Leser eine Einführung in die Thematik und das Umfeld
dieser Arbeit. Außerdem wird hier ein Überblick über die Beiträge der Arbeit vermittelt.
Das zweite Kapitel vermittelt grundlegende Informationen zum besseren Verständnis dieser Arbeit. Hier wird ein Einblick in die Arbeitsabläufe bei der Crash-Simulation
20
Einführung
gewährt, angefangen von der Vorverarbeitung der Daten, über die eigentliche Simulation,
bis hin zur Visualisierung und Auswertung des Simulationsergebnisses.
Kapitel 3 stellt Verfahren zur rechnerunterstützten Beseitigung von Inkonsistenzen des
Finite-Elemente-Modells vor, speziell Perforationen (Durchdringungen) und Penetrationen
(Eindringungen) zwischen Bauteilen, sowie ein Verfahren zur anschließenden Relaxation
(Entzerrung) des Finite-Elemente-Netzes. Die Beseitigung von Netzinkonsistenzen ist Voraussetzung für eine fehlerfreie Durchführung der Crash-Simulation.
Kapitel 4 behandelt die automatische Erkennung von Bauteilflanschen. Der hier beschriebene Algorithmus dient als Grundlage für die Ergebnisse aus den folgenden beiden
Kapiteln, sowie für verwandte Forschungsarbeiten.
Thema von Kapitel 5 ist die automatische Platzierung von Schweißpunktlinien entlang
von Flanschen. Die effiziente Definition von Verbindungselementen ist hilfreich, um bereits
in der frühen Entwicklungsphase ein simulationsfähiges Fahrzeugmodell aufzubauen.
In Kapitel 6 wird DMFFD, ein Spline-basiertes Verfahren zur Verformung beliebiger durch Polygone dargestellter Objekte, aufgegriffen und dessen Weiterentwicklung
vorgestellt. Damit lassen sich kleine Veränderungen der Bauteilgeometrie in der FiniteElemente-Darstellung auf einfache und intuitive Weise durchführen. Basierend auf der
Flansch-Erkennung wurde zudem ein Verfahren zur automatischen Anpassung von FlanschAbständen entwickelt, das auch zur Beseitigung von Perforationen angewendet werden
kann.
In Kapitel 7 geht es um den Massentrimm, ein Verfahren, bei dem nichttragende Teile
auf ihre Trägheitseigenschaften reduziert werden, um Rechner-Resourcen zu sparen. Im
Mittelpunkt steht dabei die aussagekräftige Visualisierung der strukturlosen Massen.
Kapitel 8 handelt von der Einbettung der gesamten Anwendung in eine Web-basierte
Integrationsplattform mit Hilfe eines Java-Applets und CORBA Middleware. Ziel hierbei
ist eine bessere Führung des Benutzers durch den Arbeitsablauf der Crash-Simulation,
sowie ein effizienterer Datenaustausch zwischen den beteiligten Anwendungen.
Kapitel 9 liefert eine Gesamtbetrachtung der Arbeitsabläufe bei der Crash-Simulation,
und zeigt die in dieser Arbeit entwickelten Algorithmen und Verfahren im Kontext dieser
Prozeßkette. Kapitel 10 fasst schließlich die wichtigsten Ergebnisse zusammen und bietet
einen Ausblick auf zukünftige Entwicklungen.
Kapitel 2
Grundlagen
2.1
Arbeitsabläufe bei der Karosserie-Entwicklung
Die zunehmende Komplexität und die steigenden Anforderungen bei neuen KraftfahrzeugModellen beschäftigen ein ganzes Heer von Entwicklungsingenieuren in der Automobilindustrie und deren Zulieferern. Dennoch ist eine ständige Weiterentwicklung und Optimierung
des Entwicklungsprozesses unabdingbar, um im internationalen Wettbewerb bestehen zu
können. Die Konkurrenz schläft nicht, und die Zeit bis zur Marktreife eines neuen Fahrzeugmodells kann entscheidend sein für dessen Erfolg.
Eine Möglichkeit, die Effizienz der Entwicklung zu erhöhen, ist die Einführung der Simulationstechnik. Um die Verbesserungspotentiale dieser Technik auszuschöpfen, müssen
die Arbeitsabläufe im Entwicklungsprozess dieser neuen Methodik optimal angepasst werden (siehe Abb. 2.1). Weitere Voraussetzungen sind eine optimale Datenverwaltung, sowie
die Verfügbarkeit geeigneter Simulationsverfahren.
Der Produktentwicklungsprozess besteht aus Sicht der Simulationstechnik aus 3 Phasen:
• der Konzeptphase,
• der Serienentwicklung und
• der Fahrzeugerprobung.
In der Konzeptphase können durch Einsatz der Simulation gravierende Fehler vermieden
werden, die später kaum noch korrigiert werden können. Leider fehlen zu diesem Zeitpunkt
oft noch viele erforderliche Fahrzeugdaten. Dr. D. Chang von General Motors erläuterte
auf der PAM ’96 den Bedarf an frühzeitigen Simulationen wie folgt: An engineer making
an analysis to check for a wrong design is like a doctor doing an autopsy.
Korrekturen, die in einer späten Entwicklungsphase vorgenommen werden, beeinflussen
einen Großteil der bis dahin entwickelten Komponenten, Spezifikationen und Prototypen
22
Grundlagen
Visualisierung
Visualisierung
Akustik
Wärmebilanz
Festigkeit
Fahrdynamik
Umformen
Festigkeit
Dynamik
Montagesim.
Steifigkeit
Crash
Crash
Komfort
Visualisierung
Visualisierung
Umformsim.
Aerodynamik
Abtastdaten
Strak
Struktur
Klimatisierung
Kollisionen
Ergonomie
Simulationsergebnisse
Simulationsmodelle
Konstruktion
Geometrie
Design, Konzept
Materialdaten
Versuchsdaten
Konstruktion
Gesetze
Lastkollektive
Fahrzeugparameter
Abnahmekriterien
Virtueller Prototyp
Abbildung 2.1: Zusammenwirken von Daten und Simulation [35]
sowie der erbrachten Ingenieursleistungen. Die Kosten und der Zeitverlust, die damit verbunden sind, steigen überproportional zur vor der Korrektur bereits verstrichenen Zeit im
Entwicklungsprozess. Aus diesem Grund ist es für ein Unternehmen sehr wichtig, so früh
wie möglich über abgesicherte Entwicklungskonzepte zu verfügen.
Im Verlauf der Serienentwicklung erfolgt, aufbauend auf den Ergebnissen der Konzeptphase und unter Einsatz geeigneter Simulationsverfahren, die Optimierung der geforderten
Funktionalität. Wesentlich ist hier ein effektives Datenmanagement, das alle erforderlichen
Daten für die unterschiedlichen Simulationsverfahren einheitlich bereitstellt. Bei günstigstem Verlauf sollte dann nur eine Testserie erforderlich sein.
Während der Fahrzeugerprobung kann die Simulation unter der Voraussetzung, dass
sie auch hier in die Abläufe optimal integriert ist, helfen, die Ursachen von festgestellten
Mängeln schneller und besser zu ermitteln und gezielt Lösungswege zu finden. Dem Datenmanagement der benötigten Daten (Geometriedaten, Fahrzeugdaten, Technologiedaten
und Simulationsdaten) kommt dabei die entscheidende Bedeutung zu, die jeweils benötigten Daten zum richtigen Zeitpunkt in der notwendigen Qualität verfügbar zu machen.
Bestimmende Eigenschaften einer Automobilkarosserie sind die Form und die funktionellen Eigenschaften, wie Steifigkeit, Crash-Verhalten und die Akustik. Die Form eines
Autos ist sehr wichtig für den kommerziellen Erfolg eines konkreten Entwurfs. Zum anderen werden die funktionalen Eigenschaften wie Gewicht (Kraftstoffverbrauch) und die
Sicherheit der Passagiere immer bedeutender.
Die Funktionalität einer Automobilkarosserie wird in der Regel anhand von Prototypen
getestet. Die Verkürzung der Entwicklungszeiten zwingt alle Hersteller, mehr und mehr auf
2.1 Arbeitsabläufe bei der Karosserie-Entwicklung
23
rechnerbasierte Entwicklungen (virtual car) zu vertrauen. Entsprechende Schlüsselwörter
sind:
• CAS (computer aided styling) für die Entwicklung der äußeren Gestalt der Karosserie;
• CAD (computer aided design) für die Konstruktion der Bauteile, ihren Zusammenbau
und ihre Eigenschaften;
• CAE (computer aided engineering) für die Entwicklung der funktionellen Eigenschaften der Karosserie. Numerische Simulation ist die wesentliche Technologie des CAE.
• CAM (computer aided manufacturing) für den Herstellungsprozess;
CAE, die rechnerbasierte Entwicklung der funktionalen Eigenschaften, basiert auf
numerischer Simulation. Crash-Simulation, Strukturmechanik, Akustiksimulation und
Strömungssimulation sind einige der Simulationsdisziplinen, die wichtig für die Entwicklung
einer Automobilkarosserie sind. Abbildung 2.2 zeigt die Entwicklung der Crash-Simulation
in der Automobilindustrie seit 1983, als die ersten numerischen Tests durchgeführt wurden. Heute ist Crash-Simulation eine etablierte Technologie mit guter Übereinstimmung
zwischen Simulation und Experiment. Crash-Simulation wird nicht nur verwendet zur Analyse einzelner Probleme, die sich in Prototypencrashs gezeigt haben, sondern auch um das
Crash-Verhalten eines neuen Modells vorherzusagen. Daher wird Crash-Simulation heute
eingesetzt, um Karosserien mit verbesserten Eigenschaften in kürzerer Zeit zu entwickeln.
Die weitaus meisten Versuche im Rahmen der passiven Sicherheit sind als Voraussetzung
für eine Zulassung im Straßenverkehr international vereinbart und gesetzlich vorgeschrieben. Hinzu kommt, dass sich mit der experimentellen Simulation nicht selten unerwartete
Schwachstellen aufdecken und nicht erfassbare Effekte überprüfen lassen. Nachteilig bei
Abbildung 2.2: Entwicklung von Crash-Simulation in der Industrie nach [37]
24
Grundlagen
realen Tests ist jedoch der Umstand, dass Testobjekte erst als Prototypen oder Muster
vorliegen müssen, um experimentell überprüft werden zu können. Das bedeutet nicht nur
hohe Erstellungskosten, sondern auch einen hohen Zeitaufwand, der mit den immer kürzer
werdenden Entwicklungszeiten neuer Fahrzeugtypen und -plattformen unvereinbar ist.
Daher entwickelte sich die rechnerische Simulation in den letzten zwei Jahrzehnten vom
Nachrechen- und Überprüfungsinstrumentarium zum heute entscheidenden und anerkannten Auslegungswerkzeug in der Fahrzeugentwicklung, von der Konzeptphase bis hin zur
Serienentwicklung, mit einem hohen Maß an Zuverlässigkeit und Simulationsgüte. Dies gilt
auch und insbesondere für die rechnerische Simulation der Crash-Mechanik, die sich sowohl
auf die statische und dynamische Berechnung der Fahrzeug-Deformationsstrukturen und
der Komponenten des Insassenschutz-Systems, als auch auf die Simulation des Bewegungsund Belastungsverhaltens von Insassen, Fußgängern und Zweiradfahrern bezieht.
Innerhalb der Crash-(Mechanik-)Simulation werden Rechenmodelle eingesetzt, die als
Mehrkörper-Systeme (MKS) oder als Finite-Elemente-Methode (FEM) formuliert sind.
Grundsätzlich lässt sich feststellen, dass zur Berechnung von Deformations- und Kontaktstrukturen und von Airbags Programme auf der Basis der Finite-Elemente-Methode angewandt werden, während zur Insassensimulation überwiegend Mehrkörper-Systeme ihre
programmtechnische Anwendung finden [50].
Um numerische Simulation einzusetzen, muss eine ganze Prozesskette durchgeführt werden. Basierend auf dem CAD Modell mit einer Oberflächenspezifikation (durch rationale
Splinefunktionen) für alle Bauteile der Karosserie muss ein numerisches Gitter für die gesamte Karosserie generiert werden. Dieser Vorgang heißt Vernetzung, das Ergebnis ist das
Finite-Elemente-Netz.
Anschließend werden die Materialeigenschaften für die einzelnen Bauteile spezifiziert
und Komponenten, wie Barrieren, Dummies und Rückhaltesystem (Airbags, Sitzgurte, ...)
hinzugefügt. Numerische Simulation wird für Front-, Rück- und Seitencrash durchgeführt.
Abbildung 2.3: Die Prozesskette in der CAE-Simulation nach [86]
2.2 Preprocessing
25
Im Anschluss an die numerische Simulation werden Standardauswertungen durchgeführt
und einzelne Details mit modernen Visualisierungsmethoden (z.B. VR-Visualisierung) im
Detail analysiert (siehe Abbildung 2.3).
2.2
Preprocessing
Unter Preprocessing versteht man das Vorbereiten eines FE-Modells für die Simulation,
speziell für die Crash-Simulation. Dazu gehört z.B. die Approximation der CAD-Geometrie
durch finite Elemente, und die Beseitigung eventueller Inkonsistenzen wie Penetrationen,
Perforationen und Lücken im Finite-Elemente-Modell.
Crash-Simulationen werden bereits frühzeitig parallel zur Karosserieentwicklung durchgeführt. Eine solche Vorgehensweise wird als Simultaneous Engineering [70] bezeichnet.
Im frühen Entwicklungsstadium sind Korrekturen am Fahrzeug mit weniger Aufwand
verbunden (Abb. 2.4). Weil dabei noch nicht alle Bauteildaten und Verbindungselemente
zur Verfügung stehen ist es notwendig, einige Bauteile der vorherigen Fahrzeugversion an
CAD-Entwurf
Vernetzung (Meshing)
Preprocessing, z.B.:
Beseitigung von Inkonsistenzen
Anpassen der Geometrie
Ersetzen von Bauteilen
Definition von Verbindungselementen
Massentrimm
Simulation (Finite Elemente Methode)
Auswertung (Postprocessing)
Echter Crash-Test an Prototypen
Serienproduktion
Abbildung 2.4: Position des Preprocessing im Simulationszyklus für den Karosserieentwurf.
Durch die Möglichkeit der direkten Bearbeitung des Finite-Elemente-Modells hinsichtlich
Crash-Simulation entfällt in vielen Fällen der Umweg über die CAD-Daten.
26
Grundlagen
die Vorgaben der neuen Version anzupassen. Weiterhin müssen Verbindungselemente definiert werden, falls dies noch nicht durch die Konstruktionsabteilung durchgeführt wurde.
Wurden vor einigen Jahren solche Modifikationen noch manuell, u.a. durch Editieren der
Modell-Datei im ASCII-Format durchgeführt, so gibt es heute – auch durch die Beiträge
der vorliegenden Arbeit – eine Reihe von Möglichkeiten, das Finite-Elemente-Modell als
3D-Darstellung interaktiv und automatisiert zu bearbeiten.
2.3
Finite-Elemente-Simulation
Die in der vorliegenden Arbeit vorgestellten Entwicklungen werden derzeit in Verbindung
mit Finite-Elemente-Modellen verwendet, auch wenn in einigen Fällen, z.B. bei der später
vorgestellten Integrationsumgebung, eine Verallgemeinerung möglich ist. An dieser Stelle
soll daher das Funktionsprinzip der Finite-Elemente-Methode schematisch erläutert werden, unter besonderer Berücksichtigung der aktuellen Entwicklungen in der Automobilindustrie. Für einen tieferen Einblick wird auf die Fachliteratur verwiesen [41, 75].
Die Methode der finiten (endlichen) Elemente ist ein rechnerorientiertes numerisches
Verfahren, mit dem sich Dehnungen, Verformungen und mechanische Spannungen an komplexen, analytisch nicht geschlossen berechenbaren Bauteilen unter Belastung ermitteln
lassen [50].
Dabei werden die Bauteile gedanklich durch ein idealisiertes Modell aus finiten Elementen ersetzt. In der Karosserieberechnung, bei der die meisten Baugruppen als membranartige Strukturen aufgefasst werden können, kommen hauptsächlich finite Elemente in Form
von Schalen bzw. Platten (Shells und Tools) zum Einsatz.
Diese 2D-mannigfaltigen Elemente sind aus numerischen Gründen größtenteils Vierecke,
die durch gemeinsame Knoten verbunden sind. Ebenfalls aus numerischen Gründen sollten
finite Elemente möglichst gleichseitig und gleichwinklig sein.
Einige spezielle Bauteile werden durch 1D-mannigfaltige Elemente, also stabförmige
Elemente (Beams) oder durch (3D-mannigfaltige) Volumenelemente abgebildet (Abbildung
2.5). Die Elemente sind durch eine Anzahl von Knoten und deren Positionen definiert.
Bei sogenannten linearen Elementen bestimmen jeweils zwei Knoten eine geradlinige Kante. Einige Simulationscodes arbeiten zusätzlich mit Elementen höherer Ordung, bei der
zusätzliche Knoten auf den Kanten und im Elementinneren möglich sind.
Das elastische Verhalten der Elemente lässt sich über Gleichgewichtsaussagen aus dem
Arbeitssatz mathematisch formulieren, indem das Produkt aus den äußeren Kräften an den
Rändern eines Elements und den äußeren Verschiebungen der Kraftangriffspunkte gleichgesetzt wird mit dem Produkt aus der verallgemeinerten inneren Kräftegruppe und der
inneren Verformung. Die Deformation im Bauteil ist über Materialgesetze in der Steifigkeitsmatrix der Elemente mit der berechneten Spannung verknüpft.
2.3 Finite-Elemente-Simulation
Balkenelement (Beam)
27
Schalenelemente (Shells)
Volumenelemente (Solids)
Abbildung 2.5: Typen von finiten Elementen bei der Crash-Simulation.
Die Vorgehensweise bei der FEM-Berechnung ist zunächst durch die Zerlegung komplizierter Strukturen in geometrisch einfache Elemente und die Festlegung der Knotenkoordinaten (Netz-Generierung) gekennzeichnet. Danach wird ein Verschiebungsansatz vorgegeben, der das Elementverformungsverhalten aus den unbekannten Knotenverschiebungen
mathematisch darstellt.
Die Gleichgewichtsbedingungen an den Elementknoten führen zu einem Gleichungssystem, aus dessen Lösung sich die Knotenverschiebungen bestimmen lassen. Daraus können
schließlich die Dehnungen und mit Hilfe der Materialeigenschaften in der Steifigkeitsmatrix
die Spannungen im Bauteil ermittelt werden. Damit wird eine Berechnung komplizierter
Strukturen ermöglicht, die allerdings nur eine Näherung hinsichtlich des Verhaltens des
realen Bauteils darstellt. Der klassischen Elastomechanik liegen zwei Linearisierungsbedingungen zugrunde. Zum einen die sich infolge der Beanspruchung einstellenden, kleinen
Verformungen, so dass Verformungen höherer Ordnung vernachlässigt werden können (geometrische Linearisierung). Zum anderen wird ein linearer Zusammenhang zwischen Spannung und Dehnung, ausgedrückt durch das Hook’sche Gesetz, unterstellt (physikalische
Linearisierung).
Bei der unfall- oder versuchsbedingten Verformung von Deformationsstrukturen treten
aber sowohl Verformungen im nichtlinearen Bereich als auch, wegen der plastischen Verformungen, nichtlineare Spannungs/Dehnungs-Zusammenhänge auf. Um derartige Nichtlinearitäten zu berücksichtigen, werden nach den einzelnen, linear durchgeführten Rechen-
28
Grundlagen
schritten Korrekturberechnungen durchgeführt. Die Berechnung wird also abschnittsweise
linear vorgenommen, wobei nach jedem Deformationsschritt eine neue Steifigkeitsmatrix
aufgestellt werden muss.
Da diese Vorgehensweise mit einem relativ hohen Rechenaufwand verbunden ist, konnte
sich die FEM-Berechnung erst relativ spät mit der Einführung leistungsfähiger Computer
und entsprechender Software durchsetzen. Die ursprünglich Ende der siebziger Jahre für
den Flugzeugbau entwickelte Finite-Elemente-Methode wird heute im gesamten ingenieurtechnischen Bereich angewandt.
Verbindungen zwischen verschiedenen Bauteilen wurden im Finite-Elemente-Modell
durch Netzknoten modelliert, welche allen an dieser Stelle miteinander verbundenen Bauteilen zugeordnet sind. Diese Vorgehensweise hatte zwei entscheidende Nachteile. Wurde ein
Bauteil verändert, musste im Prinzip das gesamte Modell neu vernetzt werden. Darüberhinaus war der Prozess der Gittergenerierung zu komplex für automatische Tools, insbesondere wenn es um die Platzierung der bauteilverbindenden Knoten geht. Eine manuelle
Vorbereitung und Nachbearbeitung war daher in der Regel notwendig.
Eine unabhängige Vernetzung der einzelnen Bauteile ist daher vorzuziehen. Das unabhängige Vernetzen der Bauteile erlaubt dann auch, für die Untersuchung von Konstruktionsvarianten Bauteile schnell auszutauschen, ohne die Netzübergänge in aufwändiger
Handarbeit an vorhandene Strukturen anpassen zu müssen.
Ein Ziel des BMBF Projektes Autobench (1998 - 2001) war es, die beteiligten Tools auf
den Umgang mit unabhängig vernetzten Bauteilen vorzubereiten. Die nun inkompatiblen
Bauteilgitter machen die Verwendung von speziellen Verbindungselementen notwendig.
Solche Verbindungselemente können punktförmig, linienförmig oder flächig sein. Die Verbindungselemente spiegeln die Realität wider. So sind punktförmige Verbindungen meist
Schweißpunkte, Nieten oder Schrauben. Linienförmige Verbindungen sind in der Regel
Schweißlinien, während flächige Verbindungen meist durch Verklebung realisiert werden.
Neben den Simulationstools müssen auch die Visualisierungstools und Gittereditoren
an die inkompatiblen Gitter und die Verbindungselemente angepasst werden. Diese Anpassungen werden später im Detail behandelt.
2.4
Grundlagen der Visualisierung
Ein Bild sagt mehr als tausend Worte, sagt ein Sprichwort. Tatsächlich nimmt der Mensch
rund 80% der Informationen mit den Augen auf. Der Sehsinn eignet sich daher am besten,
um komplexe Sachverhalte wahrzunehmen. Ziel der Visualisierung ist es, Informationen so
aufzubereiten, dass sie schnell und korrekt visuell wahrgenommen werden.
Da die wissenschaftliche Visualisierung auch bei der vorliegenden Arbeit eine Rolle
spielt, speziell die Visualisierung von Finite-Elemente-Modellen, soll hier ein kurzer Ein-
2.4 Grundlagen der Visualisierung
29
blick in dieses wichtige Forschungsgebiet gegeben werden. Für umfangreichere Informationen sei der interessierte Leser auf die vielfältige Fachliteratur zu diesem Thema verwiesen,
z.B. [8, 72, 61, 5].
Bekannte Arten von Visualisierungen sind z.B. Landkarten, Diagramme, Skizzen, medizinische Röntgenbilder oder die in der Einleitung erwähnten Wetterkarten. In Wissenschaft
und Technik spielt die Visualisierung eine wichtige Rolle, etwa bei der Auswertung von statistischen Erhebungen und Simulationen.
Abbildung 2.6: Der Simulations- und Visualisierungszyklus
Bei Simulationen werden in der Regel physikalische Phänomene auf physikalische Modelle abgebildet, die dann als mathematische Problemstellung formuliert werden und mit
numerischen Verfahren gelöst werden. Das Ergebnis der numerischen Berechnung stellt den
Input für die Visualisierung dar (Abbildung 2.6).
Aufgrund der hohen Verarbeitungsgeschwindigkeit moderner Rechenanlagen handelt
es sich dabei meist um große Datenmengen. Ohne eine Visualisierung der Berechnungsergebnisse wäre es schwierig bis unmöglich, Erkenntnisse aus der Berechnung zu erhalten.
Hamming formulierte diese Tatsache im Jahr 1962 folgendermaßen: The purpose of computing is insight, not numbers.
Bevor die eigentliche Visualisierung stattfindet, werden in der Regel die Daten gefiltert.
Dabei werden die uninteressanten und die redundanten Daten- und Wertebereiche entfernt.
Damit reduziert sich die Information, die durch den Rechner weiterverarbeitet und schließlich durch den Betrachter wahrgenommen werden muss auf das tatsächlich benötigte Maß.
Anschließend werden diese Daten auf Geometrieelemente, wie z.B. Linien, Flächen, Farben abgebildet. Dabei ist es oft hilfreich, wenn die geometrische Darstellung einen Bezug
zur Realität hat, der Betrachter also Bezugspunkte und gewohnte Elemente wiederfindet.
Eine naturgetreue (“photographische”) Wiedergabe ist dabei nicht notwendig, vielmehr
sollen aus der Geometrie Rückschlüsse auf die zugrundeliegenden Daten und auf mögliche
Zusammenhänge gezogen werden. Für die Darstellung der Geometrie sind daher einfache
Renderingverfahren ausreichend, da hierbei mehr Wert auf Interaktivität als auf Photorealismus gelegt wird.
30
Grundlagen
Abhängig von der Art der Daten, gegeben durch Dimension des Datenbereiches und
der einzelnen Werte gibt es verschiedene Visualisierungsverfahren. Ein häufiger Fall ist z.B.
die Simulation und Visualisierung von Stömungen. Hierbei handelt es sich in der Regel um
dreidimensionale Datenbereiche, wobei die Daten selbst als dreidimensionale Vektoren die
Richtung und Geschwindigkeit der Strömung an je einem Punkt des Raumes angeben.
Die Datenpunkte können hierbei entweder gleichmäßig auf einem kartesischen Gitter, nach
verschiedenen Kriterien strukturiert, oder auch unstrukturiert angeordnet sein.
Grundsätzlich um uniforme Gitter handelt es sich bei Volumendatensätzen wie sie z.B.
in der Medizin durch tomographische Verfahren entstehen. Die Daten selbst sind hierbei
skalare Werte. Sie sind abhängig von den Materialeigenschaften an der jeweiligen Position
und lassen so z.B. Rückschlüsse auf die Art des Gewebes zu.
Aufgrund deren vielfältigen Anwendungsmöglichkeiten gibt es heute eine Vielfalt von
effizienten und qualitativ hochwertigen Verfahren sowohl für die Strömungsvisualisierung,
z.B. Particle Tracing und Line Integral Convolution, als auch für die Volumenvisualisierung.
Bei der in der vorliegenden Arbeit behandelten Visualisierung von Finite-ElementeModellen handelt es sich um einen dreidimensionalen Datenbereich. Darin werden zum
einen die finiten Elemente selbst, basierend auf den Koordinaten der Elementknoten
und auf der Topologieinformation, dargestellt. Zum anderen werden zusätzlich Knoten-,
Element- und Bauteil-bezogene Daten dargestellt. So wird ein jedes Bauteil unterschiedlich eingefärbt, um die Bauteile besser voneinander unterscheiden zu können. Je nach Anwendung werden weitere Daten farblich oder als zusätzliche dreidimensionale Geometrie
visualisiert.
Bei der Auswertung einer Visualisierung durch den Betrachter gibt es in Hinblick auf
die Interaktivität mehrere Möglichkeiten:
• Keine Interaktion (Movie Mode): Simulation und Visualisierung laufen auf zuvor
definierte Weise ohne Benutzereingriff ab. Der Betrachter sieht sich die resultierenden
Bilder oder Videos an.
• Interaktives Postprozessing: Die Simulation läuft ohne Interaktion ab, das Ergebnis
wird jedoch interaktiv visualisiert. Dabei können z.B. Blickwinkel oder Visualisierungsparameter interaktiv verändert werden.
• Simulationsüberwachung (Tracking): Der Benutzer greift in die laufende Simulation
ein, etwa indem er Parameter verändert. In die Visualisierung wird jedoch nicht
eingegriffen.
• Interactive Steering: Der Benutzer nimmt sowohl Einfluss auf die Simulation als auch
auf die Visualisierung. Dieses Szenario spielt auch in der vorliegenden Arbeit eine
Rolle, wobei in Kapitel 8 näher darauf eingegangen wird.
2.5 Grundlagen der Computergraphik
2.5
2.5.1
31
Grundlagen der Computergraphik
Die Graphik-Pipeline
Auch wenn einfache Visualisierungen, wie Diagramme, Karten, Skizzen, von Hand dargestellt werden können, so ist bei der wissenschaftlichen Visualisierung die Unterstützung
durch die Computergraphik sehr hilfreich und meist unumgänglich. Daher soll an dieser
Stelle kurz erläutert werden, wie aus (dreidimensionalen) Geometriedaten (zweidimensionale) Bilder am Bildschirm entstehen.
Die einfachsten Strukturen der Computergraphik sind Linien und Dreiecke, gegeben
durch deren End- bzw. Eckpunkte (Vertizes). Alle anderen Objekte, wie Polygone und
Kurven, können daraus zusammengesetzt bzw. approximiert werden. Um einen dreidimensionalen Körper darzustellen, ist es ausreichend, seine Oberfläche zu modellieren - es sei
denn, sein innerer Aufbau ist von besonderem Interesse.
Abbildung 2.7: Die Graphik-Pipeline
Bei der Darstellung (Rendering) einer Szene werden sequentiell mehrere Operationen
durchgeführt. Diese Sequenz wird durch die Graphik-Pipeline, auch bekannt als RenderingPipeline, realisiert (Abb. 2.7).
Sämtliche Objekte, welche in der Szene dargestellt werden sollen, werden zuerst aus dem
lokalen Objektkoordinatensystem, in ein einheitliches Weltkoordinatensystem transformiert.
In der Regel werden für diese Modellierungstransformation Translationen und Rotationen
angewendet, welche jedes Objekt an die gewünschte Position bringen. Der von OpenGL
und anderen Systemen bereitgestellte Matrix Stack unterstützt dabei die Modellierung und
die effiziente Darstellung hierarchisch aufgebauter Szenen.
Um Translationen ebenso wie andere Transformationen durch Multiplikation mit einer
Matrix darstellen zu können, werden die dreidimensionalen Objektkoordinaten (x, y, z) um
32
Grundlagen
eine vierte Dimension w = 1 zu homogenen Koordinaten erweitert. Der Wert w wird nur
durch nicht-affine Transformationen wie der perspektivischen Transformation verändert.
Nach der Modellierungstransformation wird mit Hilfe der Viewing Transformation, welche die aktuelle Position des Betrachtes bzw. der Kamera berücksichtigt, die Szene in das
Betrachterkoordinatensystem (Viewing Koordinaten) transformiert. In diesem System befindet sich das Auge bzw. die Kamera im Ursprung, die Blickrichtung stimmt mit der
z-Achse überein.
An diesem Punkt der Graphik-Pipeline befindet sich der sichtbare Teil der Szene im
Inneren eines Pyramidenstumpfes, dem Viewing Frustum. Aus numerischen Gründen ist
dieses Vomumen nach vorne und nach hinten begrenzt durch zwei Ebenen, die Far Clipping
Plane und die Near Clipping Plane.
Die nächste Stufe der Pipeline, die perspektivische Transformation, transformiert das
Viewing Frustum in den Einheitswürfel. Zuvor muss jedoch die Beleuchtung für jeden
Vertex oder für jedes Dreieck berechnet werden. Nach der nicht-affinen perspektivischen
Transformation sind Winkel verändert und die Beleuchtungsberechnung damit nicht mehr
möglich. Nach der perspektivischen Transformation werden außerdem die Koordinaten
durch Division mit w homogenisiert.
Nachdem nun der sichtbare Teil der Szene durch einen Einheitswürfel begrenzt ist,
kann an dieser Stelle recht einfach die unsichtbare Geometrie eliminiert werden. Damit
erspart man sich weitere Operationen auf dieser Geometrie, die für das endgültige Bild
irrelevant ist. Doch bereits in Weltkoordinaten können Objekte, die vollständig außerhalb
des Viewing Frustums liegen, weggelassen werden.
Aus der dreidimensionalen Szene entsteht nun durch Ignorieren der z-Koordinate eine
2D-Abbildung. Dies entspricht einer orthogonalen Parallelprojektion. Die 2D-Abbildung
wird in Gerätekoordinaten transformiert, so dass sie den zur Verfügung stehenden Bildschirm (Viewport) ausfüllt. Die z-Koordinate wird allerdings nicht verworfen, sondern für
die Verdeckungsberechnung im Rahmen der Rasterisierung verwendet.
Bei der Rasterisierung werden schließlich aus Dreiecken und Linien Bildpunkte (Pixel),
welche aufgrund der Architektur heutiger Displays in einem Raster angeordnet sind. Mit
Hilfe des z-Buffers wird hierbei für jeden Pixel Tiefeninformation mitgespeichert. Pixel von
verdeckten Objekten werden so gar nicht erst gesetzt.
Durch die Pipeline-Archiektur wird eine Parallelisierung des Renderings erleichtert.
Die Vertizes stellen einen Datenstrom dar, der durch die Pipeline fließt. Die verschiedenen
Abschnitte der Pipeline sind dabei möglichst gleichmäßig ausgelastet.
Moderne Hardware bietet zusätzlich zu der Graphik Pipeline die Möglichkeit, die Transformation der Vertixes und die Schattierung der Pixel durch den Anwendungsentwickler
selbst zu programmieren. Die sogenannten Vertex Programme, untreffend auch Vertex Shader genannt, ermöglichen die Implementierung einer Vielfalt an neuen Spezialeffekten in
Echtzeit, so z.B. die Animation einer Wasseroberfläche, Bewegungsunschärfe und viele
33
mehr. Allerdings ist es nicht möglich, mit Vertex Programmen Vertices zu entfernen oder
hinzuzufügen, allein die Vertex-Koordinaten können berechnet werden.
Die freie Programmierung der Pixeleinfärbung durch Pixel Shader ermöglicht die Implementierung spezieller Beleuchtungsschemata und Texturierungen, sowie weitere Spezialanwendungen. Bei Vertex Programmen und Pixel Shadern gibt es derzeit noch bedeutende
Einschränkungen, z.B. hinsichtlich Programmlänge, Verzweigungen und der assemblerähnlichen Syntax, doch bieten sie ein großes Maß an zusätzlicher Flexibilität und erschließen
völlig neue Anwendungsfelder für die Graphikhardware.
2.5.2
Beleuchtung
Die Beleuchtung spielt eine bedeutende Rolle in der Computergraphik. Sie steigert den
Realismus der Szene und trägt wesentlich zur Vermittlung des dreidimensionalen Eindrucks
bei (Abb. 2.8).
Abbildung 2.8: Darstellung einer Kugel, links mit und rechts ohne Beleuchtungseffekte.
Eine möglichst realitätsnahe Beleuchtung basiert auf einem globalen Beleuchtungsmodell, bei dem Reflexion und andere Effekte zwischen Objekten berücksichtigt werden. Ein
solches Modell erfordert viel Rechenaufwand und ist daher für interaktive Anwendungen
auf heutiger Hardware nur beschränkt geeignet.
Für interaktive Anwendungen – und nur um solche handelt es sich in der vorliegenden
Arbeit – ist ein lokales Beleuchtungsmodell vorzuziehen. Bei einem solchen Modell wird nur
das Licht einer oder mehrerer Lichtquellen berücksichtigt, nicht jedoch die Lichtstrahlung
anderer beleuchteter Objekte. Bei Bedarf könnten noch zusätzliche Beleuchtungseffekte
angewendet werden, wie z.B. Shadow Maps zur Darstellung von Schatten.
Für die Berechnung der Beleuchtung auf einem Punkt der Objektoberfläche gibt es
verschiedenen Ansätze, von denen das Phong-Modell [10] am weitesten verbreitet ist. Ver-
34
Grundlagen
~ Richtung des
Abbildung 2.9: Richtungen und Winkel bei der Beleuchtungsberechnung. L:
~
~
~
~ . V~ : zeigt
einfallenden Lichts. N : Oberflächennormale. R: Spiegelbild von L bezüglich N
zum Betrachter.
einfacht ausgedrückt, addiert Phong den Einfluß einer ambienten Beleuchtung, welche aus
allen Richtungen gleichmäßig strahlt, zu dem richtungsabhängigen Einfluß einer diffusen
und einer spekularen Komponente. Die Abhängigkeit von der Richtung der Lichteinstrahlung wird durch eine Multiplikation der diffusen Lichtintensität mit cos θ, dem Winkel
zwischen Lichteinstrahlung und Oberflächennormale, berücksichtigt. Die spekulare Komponente wiederum sorgt für Glanzlichter auf der Oberfläche. Dabei spielen die Oberflächeneigenschaften und cosn α, der Winkel zwischen Blickrichtung und gespiegelter Lichtrichtung
eine Rolle (Abb. 2.9). Je größer der Wert n ist, umso kleiner und schärfer ist das Glanzlicht.
Bei der Darstellung eines Objekts wird die Beleuchtung nur an einer begrenzten Zahl
von Punkten der Oberfläche berechnet. Zur Schattierung (Shading) der gesamten Oberfläche sind die folgenden drei Vorgehensweisen gebräuchlich:
• Flat Shading: Die gesamte Fläche eines Dreiecks erhält eine einheitliche Schattierung.
Die dazu benötigte Flächennormale lässt sich eindeutig bestimmen. Die Kanten der
Dreiecke sind bei Flat Shading deutlich zu erkennen. Gekrümmte, glatte Oberflächen
wirken somit kantig.
• Gouraud Shading: Die Beleuchtung wird für die Netzknoten (Vertizes) berechnet, und
die Schattierung im Inneren jedes Dreiecks wird durch Interpolation der Farbwerte
an dessen Ecken bestimmt. Je nachdem, ob an den gemeinsamen Vertizes benachbarter Dreiecke eine gemeinsame Normale oder für jedes Dreieck eine eigene Normale
gegeben ist, resultiert ein weicher Schattierungsverlauf oder eine scharfe Objektkante
an der Grenze der Dreiecke. Gouraud Shading wird von der aktuellen Hardware unterstützt und ist derzeit – trotz einer gewissen Ungenauigkeit – das meistverbreitete
Schattierungsverfahren.
• Phong Shading: Für jeden Bildpunkt des gerasterten Objekts wird durch Interpolation die Normale bestimmt und damit die Beleuchtung berechnet. Dieses Verfahren ist
genauer als Gouraud Shading und hier ist z.B. gewährleistet, dass eventuelle Glanzlichter auch innerhalb eines Dreiecks dargestellt werden. Da Phong Shading sehr
35
Abbildung 2.10: Flat Shading, Gouraud Shading und Phong Shading am Beispiel zweier
Dreiecke.
rechenintensiv ist und von der Hardware nicht unterstützt wird, ist dieses Verfahren
weniger verbreitet.
Abbildung 2.10 zeigt die Auswirkung dieser drei Schattierungsverfahren für zwei benachbarte Dreiecke.
2.5.3
Texturen
Erstmals von Catmull [11] im Jahr 1974 erwähnt, sind Texturen heute in der Computergraphik ein weitverbreitetes Mittel zur Darstellung von Oberflächenstrukturen. Die heute
übliche Hardwareunterstützung ermöglicht die Verwendung von Texturen fast ohne Geschwindigkeitseinbußen, da dieser Vorgang parallel im Rahmen der Rasterisierung abläuft.
Texturen können verwendet werden, um Oberflächendetails darzustellen, die sonst
nur mit viel zusätzlicher Geometrie und zusätzlichem Modellierungsaufwand, also mit
Performanz-Einbußen erreicht werden können. Eine Textur ist eine ein-, zwei-, oder dreidimensionale Tabelle von Farb-, Transparenz- und/oder Luminanzwerten. Als zweidimensionale Textur kann eine normale Pixelmap verwendet werden, um ein Bild oder ein sich
wiederholendes Muster aufzutragen.
Eindimensionale Texturen können z.B. eine Farbtabelle enthalten, während dreidimensionale Texturen für die Volumenvisualisierung gut geeignet sind. Durch Multi-Texturing
können mehrere Texturen in einem Durchgang logisch verknüpft und auf der Oberfläche
dargestellt werden. Vor einigen Jahren noch ein Merkmal von High-End-Graphikhardware,
werden 3D- und Multi-Texturen heute durch gängige PC-Karten unterstützt.
Um Texturen auf einer Oberfläche darzustellen, werden den Vertizes der Oberfläche
Texturkoordinaten zugeordnet. Bei der Rasterisierung der Flächen werden dann durch Interpolation für jeden Pixel die entsprechenden Farb- und Transparenzwerte aus der Textur
36
Grundlagen
Abbildung 2.11: Anwendung einer 2D-Textur (links) auf eine Kugel.
übernommen. In Abbildung 2.11 ist ein Beispiel für die Anwendung einer zweidimensionalen Textur zu sehen.
2.6
Visualisierung von Finite-Elemente-Modellen
Finite Elemente können relativ einfach auf die Grundelemente der Computergraphik,
nämlich Punkte (Vertizes), Linien und Dreiecke abgebildet werden. Anders als Kurven
und gekrümmte Flächen aus der CAD-Welt benötigen finite Elemente keine Tesselierung,
also keine Approximation von Kurven/Flächen durch stückweise lineare Geometrie, da dies
bereits beim Erzeugen des FE-Gitters geschehen ist.
Dennoch bedarf es bei der Visualisierung von Finite-Elemente-Modellen einer wohlüberlegten Vorgehensweise, einerseits um die recht großen Datenmengen interaktiv zu visualisieren, andererseits um den speziellen Eigenschaften der finiten Elemente Rechnung zu
tragen [51]. Auch wenn jedes Polygon aus Dreiecken besteht, sollen die größtenteils viereckigen finiten Elemente ihre Eigenschaft als Vierecke auch in der internen Datenrepräsentation
bewahren, schon allein um die Visualisierung des FE-Netzes zu ermöglichen.
2.6.1
Verwendete Werkzeuge
Als Basis für die 3D-Darstellung der Daten wurde die OpenGL [93] Graphikbibliothek
gewählt. OpenGL ist, zum Unterschied von anderen Graphik-APIs, auf allen gängigen Plattformen verfügbar und wird von der heutigen Graphikhardware weitgehend unterstützt. Ersteres ist entscheidend für die Portierbarkeit der darauf aufbauenden Software, letzteres ist wichtig für eine optimale Performanz. Durch Hardware-Unterstützung
kann die Visualisierung um Größenordnungen schneller dargestellt werden, als bei reinen
Software-Lösungen. Insbesondere wegen der großen Datenmengen und der Forderung von
Interaktivität ist eine effiziente Nutzung der Graphik-Hardware unabdingbar.
2.6 Visualisierung von Finite-Elemente-Modellen
37
Für die Entwicklung größerer Software-Projekte ist eine modulare Vorgehensweise
nötig, damit der Programmcode nicht unüberschaubar wird. Objektorientierte Sprachen
unterstützen einen modularen Programmaufbau, durch die Bereitstellung von Objekten
und deren Instanzen, durch Abstraktion von der Implementierung und durch Datenkapselung. Durch Vererbung von Objekten lassen sich zudem leicht Erweiterungen durchführen.
Andererseits haben objektorientierte Sprachen einen gewissen Overhead, wodurch die
Ausführung des Programms unter Umständen etwas verzögert wird.
Die im Rahmen der vorliegenden Arbeit entwickelten Visualisierungstools wurden mit
Hilfe der Programmiersprache C++ implementiert. C++ [84] ist eine objektorientierte Erweiterung der Sprache C [42], einer Sprache die schon in den 70er Jahren für die Programmierung des Betriebssystems Unix entwickelt wurde. Die objektorientierte Erweiterung
C++ ermöglicht gleichzeitig übersichtlichen und effizienten Programmcode.
Da das Graphik-API OpenGL nicht objektorientiert arbeitet, wurde eine objektorientierte Erweiterung in Form eines Szenengraph-API’s verwendet. Ein Szenengraph ist eine
Datenstruktur, mit deren Hilfe sich die Objekte, die dargestellt (gerendert) werden sollen, in einer Baumstruktur organisieren lassen. Bei der Traversierung des Szenengraphen
werden dann für jeden Knoten dieser Baumstruktur entspechende OpenGL-Funktionen
aufgerufen, welche die gewünschte dreidimensionale Darstellung der Szene veranlassen.
Prinzipiell wäre es zwar möglich und in einigen Fällen sogar effizienter, die OpenGLFunktionen auch ohne Szenengraph direkt aufzurufen. Doch bei komplexen Szenen wird
diese Vorgehensweise schnell unübersichtlich, was schließlich auch negative Auswirkungen
auf die Effizienz und die Wartbarkeit des Programmcodes haben kann.
Die Wahl des Szenengraph-API fällt nicht leicht. Eine Reihe von proprietären
Szenengraph-Varianten ist auf dem Markt erhältlich, wobei jede Variante Vor- und Nachteile hat. OpenInventor [90] z.B. bietet viele Features wie Manipulatoren und TiefenSortierung von transparenten Objekten, ist jedoch bei größeren Szenen nicht hinreichend
schnell. Performer [79] wiederum ist für große Datensätze ausgelegt, bietet aber wenig Funktionalität. Die Wahl fiel schließlich auf Cosmo3D [80], das in Verbindung mit dem Aufsatz
OpenGL Optimizer [81] eine Optimierung der Darstellungsgeschwindigkeit zusammen mit
einer Reihe von nützlichen Szenengraph-Objekten und Features bietet.
In letzter Zeit wird außerdem an Open-Source-Szenengraphen entwickelt, wie OpenSG
und OpenScenegraph. Da die Entwicklung der proprietären Szenengraphen in letzter Zeit sehr langsam voranschreitet oder stagniert und wegen deren Einschränkung
auf wenige Plattformen, wurde bei der vorliegenden Arbeit durch eine SzenengraphAbstraktionsschicht der möglichst einfache Austausch des zugrundeliegenden Szenengraphen ermöglicht. So kann, sobald eine geeignetere Szenengraph-Variante einsatzbereit ist,
ein Umstieg erfolgen.
38
2.6.2
Grundlagen
Beschleunigung des Bildaufbaus
Aufgrund der großen Datenmengen, die zu visualisieren sind, ist eine effiziente Struktur des
Szenengraphen besonders wichtig. Zum einen gilt es festzustellen, welche Teile der Szene
durch andere verdeckt oder außerhalb des Darstellungsbereiches sind. Solche unsichtbaren
Objekte können mit Unterstützung des OpenGL Optimizer entdeckt und bei der Darstellung der Szene weggelassen werden, ein Vorgang, der als Culling bezeichnet wird. Weiterhin macht es Sinn, identische Daten zusammenzufassen. Durch die Möglichkeit, Objekte
(Knoten) im Szenengraph mehrfach zu referenzieren, kann viel Arbeitsspeicher eingespart
werden. Dieses Vorgehen ist insbesondere bei Post-Processing Daten interessant, wo für
alle Zeitschritte die Netztopologie gleich bleibt, während die Koordinaten der Knoten von
Zeitschritt zu Zeitschritt variieren.
Da im Durchschnitt jeweils vier finite Elemente einen Gitterknoten gemeinsam haben,
ist es sinnvoll, wenn jedes Element nur einen Verweis auf dessen Knoten bzw. dessen Koordinaten enthält und nicht eine Kopie derselben [53, 82]. Beim Rendering wird normalerweise
jedoch jedes Element einzeln bearbeitet, d.h. insbesondere, dass alle Knoten des Elements
zu transformieren sind, also deren Position am Bildschirm berechnet werden muss, auch
wenn das eigentlich schon beim Rendern eines Nachbarelements geschehen ist.
Eine Möglichkeit der Optimierung besteht darin, viereckige Elemente zu Streifen zusammenzufassen, den sogenannten Quadstrips. Wenn vorher für n Elemente 4n Knoten
transformiert wurden, so sind es nun nur noch 2n + 2. Allerdings benötigt das Finden von
Viereck-Streifen einige Zeit. Mit OpenGL ist eine effiziente Verwendung von Quadstrips
gewährleistet, für die darüberliegende Cosmo3D-Schnittstelle mußte jedoch eine eigene Erweiterung realisiert werden.
Seit OpenGL Version 1.2 gibt es sogenannte Vertex Arrays, die es ermöglichen, Listen
von Knoten, bei Bedarf auch Listen von Normalen, Texturkoordinaten oder Farbwerten
und dazu eine Liste von Knotenindizes anzugeben. Die Knoten können dann über diese
Indizes angesprochen werden, und brauchen nicht mehrmals transformiert werden. Bei einer
SGI Octane2 mit V8 Graphik-Board wurde so eine Steigerung der Framerate um 100%
erreicht. Je nach verwendeter Hardware kann die Beschleunigung unterschiedlich groß sein
oder auch gar nicht auftreten, z.B. wenn Vertex-Transformationen nicht den Flaschenhals
in der Rendering-Pipeline [21] darstellen.
Die Cosmo3D Klasse csQuadSet wurde in der vorliegenden Arbeit abgeleitet und einige
Methoden durch eigene ersetzt, um die Verwendung von Vertex Arrays durch Cosmo3D zu
gewährleisten. Ab der seit kurzem verfügbaren Version 1.3 ist die Verwendung von Vertex
Arrays durchgehend in Cosmo3D implementiert. Während der Verwendung von Texturen
werden in den hier beschriebenen Visualisierungstools derzeit jedoch keine Vertex Arrays
verwendet, weil den Texturkoordinaten andere Listen von Indizes zugeordnet sind, als den
Knoten und den Normalen. Zumindest im Falle der Visualisierung von Preprocessing-Daten
ließe sich allerdings das Index-Set vereinheitlichen.
39
Eine weitere Möglichkeit, den Bildaufbau bei großen Datensätzen zu beschleunigen, ist
die Simplifizierung (Vereinfachung) der Geometrie. Bei diesem Verfahren wird die komplexe darzustellende Geometrie, bestehend aus einer großen Anzahl von Dreiecken bzw.
Knoten, durch eine andere, einfachere Geometrie ersetzt, welche die erstere möglichst gut
approximiert. Da das simplifizierte Modell auch weniger Information enthält wie das Original, sollte der Grad der Simplifizierung nur so groß sein, dass eine interaktive Darstellung,
z.B. mit 10 Bildern pro Sekunde möglich ist. Weiterhin sollte die vereinfachte Geometrie
nur während der Benutzerinteraktion verwendet werden. Sobald keine Aktualisierung des
Ausgabebereiches (rendering area) ansteht, kann die Originalgeometrie dargestellt werden.
Der Vorgang der Simplifizierung benötigt jedoch auch Zeit. Diese Zeit kann bei großen
Modellen – und nur hier ist eine Simplifizierung sinnvoll – im Minutenbereich liegen. Daher
lohnt der Aufwand im Allgemeinen nur, wenn eine länger dauernde Interaktion bevorsteht.
Außerdem ist eine Visualisierung der Gitterstruktur oder anderer Knoten- oder Elementgebundenen Information nicht oder nur sehr umständlich auf dem simplifizierten Modell
zu erreichen.
2.6.3
Wiederverwertung von Bildspeicherinhalten
Ohne lange Vorbereitungszeit kommen Verfahren aus, die pixelbasiert arbeiten. Ihr Anwendungsbreich ist jedoch begrenzt. So kann bei der Manipulation eines Teils der Szene, etwa
eines einzelnen Bauteils, unter Umständen auf die laufende Aktualisierung der gesamten
Szene verzichtet werden. Der unmodifizierte Teil der Szene kann einmal gerendert und als
Pixel-Bild plus Tiefen-Puffer (Z-Buffer) in den Hauptspeicher kopiert werden. Während der
Interaktion wird dann laufend der Bildschirminhalt aus dem Speicher aufgefrischt, und nur
der sich verändernde Teil der Szene, z.B. das eine Bauteil, muss tatsächlich neu gerendert
werden. Bei einigen Graphik Architekturen ist der Datenpfad zu langsam, der für das Wiederbeschreiben des Z-Buffers benötigt wird, weshalb sich dieses Verfahren hier nicht lohnt.
So sind unter den SGI-Architekturen nur die Varianten IMPACT und IR (InfiniteReality)
dafür geeignet. Moderne PC-Graphikkarten haben damit jedoch keine Probleme.
Ein anderes pixelbasiertes, zur schnellen Vorschau von Translationen einsetzbare Verfahren wurde im Rahmen der vorliegenden Arbeit untersucht und beruht auf Kopieren und
Zoomen der Rendering-Area. Dabei werden die Pixel-Daten innerhalb des Bildspeichers bewegt, außerdem wird der Z-Buffer nicht benötigt, wodurch dieses Verfahren auf praktisch
allen aktuell eingesetzten Graphiksystemen verwendbar ist. Zwar hat diese Darstellung
mit Hilfe der OpenGL Pixeloperationen nur Vorschaucharakter, und die Interaktionen, für
die dieses Verfahren angewandt werden kann, sind im wesentlichen auf Translationen in
Blickrichtung oder parallel zur Bildebene beschränkt. Dies sind jedoch sehr häufige Interaktionen, und ein sofortiges Feedback über das Ausmaß der Translation ist dabei oft
wünschenswerter als eine verzögerte Detaildarstellung.
Beim Translieren in der Bildebene wird das Bild um einen Betrag verschoben, der dem
visuellen Effekt der Translation entspricht (Abb. 2.12). Beim Translieren in Blickrichtung
40
Grundlagen
Abbildung 2.12: Translation parallel zur Bildebene, mit Orthogonalprojektion. Links: Ausgangszustand. Mitte: Vorschau zur Interaktionszeit durch Verschieben des Bildes. Rechts:
Neu gerendertes Bild nach Beenden der Interaktion.
Abbildung 2.13: Translation in Richtung des Betrachters, perspektivische Projektion.
Links: Ausgangszustand. Mitte: Vorschau zur Interaktionszeit durch Zoomen des Bildes.
Rechts: Neu gerendertes Bild nach Beenden der Interaktion.
wird das Bild verkleinert oder vergrößert mit Hilfe von OpenGL Pixel-Zoom-Operationen,
so dass das neue Bild optisch dem entspricht, das bei einem erneuten Rendern der Szene
entstanden wäre (Abb. 2.13). Beim “Hineinzoomen” muss dabei eine gewisse Bildunschärfe
in Kauf genommen werden. Bei den anderen Operationen wird der Bildbereich nur noch
teilweise ausgefüllt. Daher sind diese Pixel-basierten Operationen nur für Translationen
mit geringem bis mäßigem Ausmaß geeignet. In allen anderen Fällen wird die Szene neu
gerendert.
Die durch die Pixel-Operationen entstandenen Bilder entsprechen, abgesehen von den
unausgefüllten Bereichen am Rand der Rendering Area bzw. der Unschärfe beim Hineinzoomen, exakt den Bildern die beim Rendern der Szene nach der Translation entstehen
würden, sofern bei der Darstellung eine Orthogonalprojektion verwendet wird. Bei perspektivischen Projektionen kann nur für eine (frei wählbare) Ebene parallel zur Bildebene
eine exakte Übereinstimmung erreicht werden. Bei den meisten Anwendungen ist die per-
41
spektivische Verzerrung nicht allzu groß, so dass eine gute Approximation erreicht wird.
Eine minimale Abweichung wird erreicht, wenn die Referenz-Ebene vom Betrachter etwa
so weit entfernt ist wie die meisten sichtbaren Objekte. Als Heuristik kann die Position der
Ebene durch einen Punkt festgelegt werden, der in der Mitte zwischen dem Zentrum der
die Szene umschließenden Kugel und deren Oberfläche in Betrachterrichtung liegt.
2.6.4
Verwendung von Texturen
Bei der Visualisierung von Finite-Elemente-Strukturen können Texturen auf vielfältige
Weise eingesetzt werden. Kuschfeldt et al. [52, 53] beschreiben die Verwendung von Texturen zur effizienten Visualisierung der FE-Gitterstruktur. Dabei wird jedem Element dieselbe (Luminanz-Alpha-)Textur in Form eines schwarzen Quadrats auf transparentem Hintergrund zugewiesen. So werden die Elementkonturen schwarz eingefärbt, während innerhalb
der Elemente die Bauteilfarbe unverändert bleibt (Abb. 2.14 links).
Mit Hilfe einer eindimensionalen Textur können außerdem diverse Parameter farblich
visualisiert werden [82]. Durch Transparenz-Texturen in Verbindung mit Alpha-Tests und
entsprechender Einstellung der Texturmapping-Methode können Teile der Geometrie ausgeblendet werden, um den Blick auf die interessanten Bereiche freizugeben. Das Ausblenden erfolgt während der Rasterisierung, es sind also keine geometrischen Berechnungen
(Schnitte) notwendig. Dadurch ist eine interaktive Ändernug der Visualisierungsparameter
möglich. Weitere Anwendungen eindimensionaler Texturen sind z.B. die Visualisierung von
Unterschieden im Crashverhalten zweier Karosserievarianten [83], ebenso wie die visuelle
Darstellung von Abständen zwischen benachbarten Bauteilen (Abb. 2.14 rechts).
Abbildung 2.14: Verwendung von Texturen bei der Visualisierung von finiten Elementen.
Links: Visualisierung der Finite-Elemente-Struktur mit Hilfe von 2D Luminanz-AlphaTexturen. Rechts: Unterschiede im Crash-Verhalten, visualisiert mit Hilfe von 1D Farbtexturen.
42
2.7
Grundlagen
Effiziente Distanzbestimmung
Bounding Volumes
mit
Hilfe
von
Wegen der Komplexität der zu visualisierenden Geometriedaten ist ein effizientes Verfahren
zur Bestimmung von Abständen unentbehrlich. Speziell wenn es um die Frage geht, welches
das einem bestimmten Punkt nächstliegende Element ist, müsste im Normalfall der Abstand sämtlicher Elemente zu dem gegebenen Punkt bestimmt werden. Bei einer Problemstellung wie der Distanzvisualisierung, wo es nötig ist, zu jedem Netzknoten den Abstand
zum nächstliegenden Bauteil zu bestimmen, wäre der Aufwand O(n2 ), also proportional
zu dem Quadrat der Knoten- bzw. der Elementanzahl n und damit nicht praktikabel.
Eine Verringerung des Aufwandes von O(n2 ) auf O(log2 (n)2 ) lässt sich erreichen, indem
man eine Methode verwendet, die ihre Ursprünge im Raytracing [88] und in der Kollisionserkenung [31] hat. Es handelt sich hierbei um eine hierarchische Struktur von Bounding
Volumes (BVs). Ein Bounding Volume ist eine einfache, konvexe Hilfsgeometrie, die ein
komplexeres Objekt vollständig umschließt. Für diese einfache Hilfsgeometrie lässt sich
schnell herausfinden, ob ein Punkt, eine Linie (z.B. ein Lichtstrahl bei Raytracing), ein
anderes Objekt bzw. dessen Bounding Volume vollständig außerhalb liegt oder nicht. Liegt
der Punkt, die Linie usw. vollständig außerhalb des Bounding Volumes eines Objekts,
so gilt dies mit Sicherheit auch für das Objekt selbst, welches vollständig vom Bounding
Volume umschlossen ist. In diesem Fall braucht das umschlossene Objekt nicht näher untersucht werden, und man spart die aufwändige Untersuchung des komplexen umschlossenen
Objektes. Im zweiten Fall muss das Objekt näher untersucht werden, und der Aufwand
ist derselbe wie beim herkömmlichen Verfahren ohne BVs, zuzüglich des Overheads zur
Untersuchung des Bounding Volumes.
Als Bounding Volumes können z.B. Kugeln oder Quader verwendet werden. Kugeln
lassen sich schnell auf Durchdringung testen. Für die Effizienz ist es jedoch auch wichtig,
dass das Bounding Volume eng am umschlossenen Objekt anliegt, um dieses möglichst gut
zu approximieren und so die Zahl der unnötigen Tests gering zu halten. Für viele Arten von
Objekten lässt sich mit einem Quader (Box) ein besseres Ergebnis erreichen. Quader sind
schnell auf Durchdringung zu testen, wenn ihre Kanten parallel zu den Koordinatenachsen
sind. Man spricht dann von Axes-Aligned Bounding Boxes (AABB). Noch besser an das
umschlossene Objekt angepasst sind die sogenannten Oriented Bounding Boxes (OBB)
[31]. Hier ist allerdings der Test auf Durchdringung aufwändiger. In der Praxis hat sich
das AABB-Verfahren bewährt.
Lässt sich das umschlossene Objekt in räumlich getrennte Teile oder Teilobjekte zerlegen, so können diese gruppiert und auf tieferer Ebene wiederum von Bounding Volumes
umschlossen werden. Die so entstandene Bounding-Volume-Hierarchie bietet mit jedem Level eine genauere Anpassung an das Objekt, auch wenn die einzelnen Volumen nicht am
Objekt ausgerichtet sind. Wenn eine Durchdringung auf oberstem Level festgestellt wird,
muss noch nicht das gesamte Objekt untersucht werden, sondern es können die Volumen
der nächsten Hierarchiestufe untersucht werden usw. bis entweder keine Durchdringung
2.7 Effiziente Distanzbestimmung mit Hilfe von Bounding Volumes
43
Abbildung 2.15: Sechs Level einer Bounding-Volume-Hierarchie für ein mit finiten Elementen modelliertes Bauteil
festgestellt wird oder bis zur letzten Hierarchiestufe, wo jedes Bounding Volume nur noch
wenige, leicht zu untersuchende Teilobjekte enthält (Abb. 2.15).
Im Fall der finiten Elemente Modelle ergibt sich, wie anfangs erwähnt, häufig die Notwendigkeit, zu einem Bauteil, zu einem Knoten oder zu einem beliebigen Punkt das nächstliegende Bauteil oder Element eines anderen Bauteils zu finden. So muss etwa bei der
Validierung von Verbindungselementen möglichst schnell eine Bestimmung der dem Verbindungselement nächstliegenden finiten Elemente erfolgen. Auch bei der Erkennung von
Perforationen und Penetrationen im nächsten Kapitel spielt die effiziente Distanzbestimmung eine Schlüsselrolle.
44
Grundlagen
Kapitel 3
Perforationen und Penetrationen
3.1
Motivation
Obwohl Bauteile aus Blech eine gewisse Materialdicke haben, wird diese Dicke bei der
Vernetzung und bei der Visualisierung vernachlässigt. Dadurch können die Bauteile aus
Blech durch zweidimensionale finite Elemente dargestellt und als Dreiecke und Vierecke
visualisiert werden. Dargestellt wird dabei die mittlere Fläche des Bauteils. Schneidet sich
die mittlere Fläche eines Bauteils mit der eines anderen Bauteils, spricht man von Perforation. Im Gegensatz dazu spricht man von Penetration, wenn sich zwei Bauteile nicht
perforieren, aber ihre mittleren Flächen sich näher kommen als die mittlere Blechdicke der
zwei Bauteile (Abb. 3.1).
CAD
Bauteil A
Perforation
FE Netz
Penetration
Bauteil B
Abbildung 3.1: Entstehung von Perforationen und Penetrationen durch Diskretisierung von
CAD Daten
Penetrationen führen zu abstoßenden Kräften zwischen Bauteilen in der Anfangsphase der Simulation. Dies beeinträchtigt das Simulationsergebnis. Die abstoßenden Kräfte
führen allerdings nach eingen Zeitschritten zu einer Behebung der Penetrationen. Außerdem hat der FE-Solver mittlerweile eigene Routinen zur Erkennung und Beseitigung von
46
Penetrationen vor der Simulation. Perforationen hingegen werden vom Solver nicht beseitigt und bleiben bis ans Ende der Berechnung bestehen. Perforationen müssen daher in
jedem Fall behoben werden, bevor das Modell an die Simulation übergeben wird.
3.2
Erkennung und Visualisierung von Perforationen
Zum Erkennen von Perforationen zwischen zwei Bauteilen muss für jedes finite Element
des einen Bauteils festgestellt werden, ob es irgend ein Element des anderen Bauteils perforiert. Um alle Perforationen des gesamten Modells zu finden, muss jedes Bauteil gegen
jedes andere getestet werden. Durch die Verwendung von Bounding-Volume-Hierarchien
(siehe Abschnitt 2.7) wird erreicht, dass nur Elemente, die einigermaßen nahe beieinander
liegen, auf Perforation getestet werden. Sind zwei Elemente hingegen relativ weit voneinander entfernt, sind ihre umschließenden Volumen schon auf höherer Ebene disjunkt und
es brauchen keine weiteren Untersuchungen durchgeführt zu werden.
Schneiden sich zwei kleinste Bounding Volumes der beiden Hierarchien, wird jedes finite
Element des einen BVs mit jedem Element des anderen auf Schnitt getestet. Da viereckige
Elemente durch zwei Dreiecke dargestellt werden können, reicht es, einen Schnittalgorithmus für Dreiecke zu implementieren.
Zwei Dreiecke perforieren, wenn mindestens eine Kante des einen Dreiecks die Fläche des
anderen schneidet. Um dies festzustellen, wird erst der Schnittpunkt jeder Kanten-Gerade
des einen Dreiecks mit der Ebene des anderen Dreiecks bestimmt, sofern er existiert, und
festgestellt, ob der Schnittpunkt innerhalb der Kante liegt (siehe auch [58, 57]). Wenn das
der Fall ist, wird festgestellt, ob der Schnittpunkt auch innerhalb des anderen Dreiecks
liegt. Dazu können die baryzentrischen Koordinaten des Schnittpunktes relativ zu dem
betreffenden Dreieck bestimmt werden. Befinden sich alle drei baryzentrischen Koordinaten
innerhalb des Intervalls [0, 1], so liegt der Punkt innerhalb des Dreiecks.
Eine schnellere Methode um festzustellen, ob ein Punkt innerhalb eines Dreiecks liegt,
wird in [33] beschrieben. Dabei wird das Dreieck auf eine der drei Koordinatenebenen
projiziert, indem die x-, y- oder z-Koordinaten der Knoten gleich Null gesetzt werden. Es
wird dabei diejenige Projektionsrichtung gewählt, bei der die projizierte Dreiecksfläche am
größten ist, was mit Hilfe der Dreiecksnormalen festgestellt werden kann. Dann wird ein
Strahl vom zu testenden Punkt in eine der zwei verbleibenden Achsenrichtungen angenommen und auf Schnittpunkte mit den Dreieckskanten in der Ebene untersucht (Crossings Test). Durch Koordinatenvergleich kann in vielen Fällen vorausgesagt werden, ob
ein Schnittpunkt existiert, ohne ihn tatsächlich berechnen zu müssen. Ist die Anzahl der
Schnittpunkte ungerade, befindet sich der Punkt innerhalb des Dreiecks, andernfalls befindet er sich außerhalb.
Auch wenn auf diese Weise festgestellt wird, dass ein Dreieck ∆1 ein Dreieck ∆2 nicht
perforiert, d.h. dass keine der Kanten von ∆1 das Dreieck ∆2 perforiert, muss umgekehrt
3.3 Beseitigung von Perforationen
47
getestet werden, ob ∆2 das Dreieck ∆1 perforiert. Es kann also vorkommen, dass ein Bauteil
B1 ein Bauteil B2 perforiert, aber nicht umgekehrt, weil nur die Kanten auf Perforation
untersucht werden. Um festzustellen, ob zwei Bauteile perforieren ist also prinzipiell ein
beidseitiger (symmetrischer) Check notwendig.
Auf diese Weise kann festgestellt werden, welches die Kanten und damit die Knotenpaare sind, die an einer Perforation beteiligt sind. Diese Information ist hinreichend für die
Visualisierung der Perforationen, nicht jedoch für deren Behebung.
Die Visualisierung der Perforationen kann durch Einfärben der an der Perforation beteiligten Knoten erfolgen. Das einfache Einfärben durch Zuweisen eines Farbwertes zu einem
Vertex ist jedoch nicht optimal. OpenGL erzeugt dabei je nach Einstellung entweder einen
Farbverlauf anstelle der gewünschten scharfen Abgrenzung, oder aber die zugehörigen Dreiecke werden vollständig eingefärbt. Ausserdem ist bei der Vielzahl von Bauteilfarben die
Markierungsfarbe nicht immer gut sichtbar.
Eine brauchbare Visualisierung wurde durch die Verwendung von eindimensionalen
Farbtexturen, wie sie auch bei der Visualisierung von Penetrationen und Bauteilabständen
verwendet werden, erreicht. Zwar stellen die verschiedenen Farben, anders als z.B. bei
der Distanzvisualisierung, keine bestimmten Zahlenwerte dar, jedoch sind die markierten
Knoten durch die klar abgegrenzten Farbbänder auf den ersten Blick sichtbar (Abb. 3.2
links).
Abbildung 3.2: Visualisierung (links) und Beseitigung (rechts) einer Perforation. Die Farbmarkierung wurde hier zur Verdeutlichung beibehalten.
3.3
Beseitigung von Perforationen
Für das Beheben von Penetrationen muss das FE-Netz eines oder beider an der Perforation
beteiligten Bauteile modifiziert werden. Dabei soll die äußere Form soweit wie möglich
48
erhalten bleiben.
Bei dem hier vorgestellten Verfahren werden im ersten Schritt nur die perforierenden
Knoten verschoben. Ein Relaxationsalgorithmus wird anschließend ausgeführt, um eventuelle Verzerrungen der finiten Elemente auszugleichen.
Um die Perforationen zu beheben, werden die Knoten, welche auf der “falschen“ Seite
liegen auf die perforierte Oberfläche des anderen Bauteils projiziert und in Projektionsrichtung noch ein kleines Stück weiterverschoben. Damit liegen die Knoten dann auf der
“richtigen“ Seite und können durch die später erläuterte Penetrationsbehebung (Abschnitt
3.6) weiterbehandelt werden (Abb. 3.2 rechts).
Welches die “richtige“ Seite für einen Knoten ist, muss vor dessen Verschiebung festgestellt werden. Dabei gibt es zwei Vorgehensweisen:
1. Benutzerdefiniert: Während der Benutzer die zu depenetrierenden Bauteile mit der
Maus anwählt, achtet er darauf, je nach Einstellung entweder immer eine perforierende oder immer eine nicht-perforierende Region anzuwählen. Ausgehend vom dem
Mauszeiger nächstliegenden Bauteilknoten werden dann iterativ die Nachbarknoten
untersucht bis zum Rand der Perforation. Damit legt der Benutzer fest, welches die
perforierende Region ist und welche Region nicht verändert werden muss.
2. Automatisch: Die Anzahl der Knoten auf jeder Seite wird ermittelt, und es wird davon
ausgegangen, dass die kleinere Region die Perforation darstellt. Der Vorteil hierbei
ist, dass keine Benutzerinteraktion nötig ist. Somit kann dieses Verfahren auch bei
der automatischen Perforationsbehebung des gesamten Modells eingesetzt werden,
wo der Benutzer nicht einzelne Bauteile auswählen muss. Ein seltener Fall, wo die
automatische Entscheidung nicht möglich ist, zeigt Abb. 3.3.
Abbildung 3.3: Links: symmetrische Perforation (Schnittansicht), bei der es unmöglich ist
automatisch zu entscheiden welcher Bereich als der perforierende betrachtet wird. Mitte
und rechts: zwei mögliche Beseitigungen der Perforation.
Beide Vorgehensweisen sind jedoch nur für die Fälle praktikabel, bei denen die perforierenden Regionen vollständig durch das perforierte Bauteil separiert sind (Abb. 3.4
links). Ist dies nicht der Fall (Abb. 3.4 rechts), müssen andere Wege gegangen werden.
Hierbei kann die Tatsache ausgenutzt werden, dass die Knotenverweise jedes Elements
einen konsistenten Richtungssinn haben. Sind die Knoten eines Elements beispielsweise
im Uhrzeigersinn nummeriert, so trifft dies auch auf das Nachbarelement zu. Damit haben die finiten Elemente auch konsistente Normalenrichtungen. So kann der Benutzer bei
der Auswahl der Bauteile gleichzeitig eine von zwei Bauteilseiten festlegen, und damit die
gewünschte Deperforationsrichtung (basierend auf der Flächennormalen) angeben.
3.3 Beseitigung von Perforationen
49
Abbildung 3.4: Links: vollständige Trennung des perforierenden Bereiches durch das perforierte Bauteil. Rechts: der perforierende Bereich ist nicht vollständig abgegrenzt.
Oft perforieren zwei Bauteile an Flanschen, also an relativ parallelen Flächen mit z.B.
weniger als 45◦ Abweichung. Die Perforation aus Abb. 3.3 beispielsweise gilt damit auch
noch als relativ parallel, anders als die Perforationen aus Abb. 3.4. Für die Deperforierung
von Flanschen empfiehlt sich der in Verbindung mit Flanscherkennung und Free-Form Deformation angewandte Algorithmus zur Anpassung von Flanschen (siehe Abschnitt 6.11).
Es kann vorkommen, dass ein perforierender Knoten sich auf zwei oder mehrere verschiedene Elemente des anderen Bauteils gleichzeitig projizieren lässt (Abb. 3.5). Hier kann
die Verschiebungsrichtung durch Mitteln der Projektionsrichtungen bestimmt werden, oder
es kann eine durch den Benutzer angegebende Richtung bevorzugt werden. Diese Richtung
kann z.B. die Normale an der Fläche unter dem Mauszeiger sein. Für ein Maximum an
Flexibilität wurde dem Benutzer zudem die Möglichkeit gegeben, einzelne Knoten auf die
andere Seite des perforierten Bauteils zu verschieben.
Abbildung 3.5: Verschieben eines Knotens, der Projektionen auf mehrere Elemente besitzt
Im gegenteiligen Fall, wenn ein perforierender Knoten auf kein Element des perforierten
Bauteils projiziert werden kann, wird die Projektion auf die nächstliegende Kante als Verschiebungsrichtung verwendet. Gibt es auch diese Projektion nicht, so ist die Verbindungsgerade zum nächstliegenden Knoten des perforierten Bauteils als Richtung anzunehmen.
50
Schlussfolgernd kann gesagt werden, dass die Beseitigung von Perforationen ein komplexes Themengebiet mit vielen Sonderfällen ist. Eine vollständige Automatisierung ist
zwar möglich, doch ist für ein optimales Ergebnis ein gewisses Maß an Benutzerinteraktion
nötig.
3.4
Gitterrelaxation
Da bei der Beseitigung von Perforationen einzelne Netzknoten unter Umständen um ein
beträchtliches Maß verschoben werden, kann es zu Verzerrungen des Netzes kommen. Das
bedeutet, dass es starke Abweichungen einzelner Elemente von der idealen gleichseitigen,
gleichwinkligen Elementform gibt. Die Gitterrelaxation hat das Ziel, die Gleichmäßigkeit
des Gitters wiederherzustellen (Abb. 3.6).
Abbildung 3.6: Beispielskizze zur Relaxation. Links: Ausgangssituation. Mitte: Zwei Knoten wurden verschoben, dadurch sind Elemente verzerrt. Rechts: Relaxiertes Gitter.
Das Relaxationsproblem ist dem Problem der Glättung von Netzen sehr ähnlich. In
beiden Fällen liefert ein Energieminimierungsansatz gute Ergebnisse. Die Minimierung
der Membranenergie1 zur Flächenglättung [44, 48] führt in diskretisierter Form zu einer
iterativen Anwendung des Umbrella-Operators (Abb. 3.7):
n
1X
Pi − P = P M − P
U (P ) =
n i=1
(3.1)
Hier sind Pi die n Nachbarknoten eines Knotens P, und PM ist der Mittelpunkt (Baryzentrum) der Nachbarknoten.
Die Anwendung des Umbrella-Operators stellt eine Verschiebung des Punktes P in
Richtung des Schwerpunkts PM seiner Nachbarknoten dar. Das Ausmaß der Verschiebung
in jedem Iterationsschritt kann durch einen Faktor λ ∈ (0, 1] geregelt werden. Die neue
Position P 0 eines jeden Knotens P nach einem Iterationsschritt ist damit:
P 0 = P + λU (P ) = (1 − λ)P + λPM
1
Taubin [85] erzielte mit einem Filteransatz aus der Signalverarbeitung äquivalente Ergebnisse.
(3.2)
3.4 Gitterrelaxation
51
P
1
P2
P
P
0
...
P n−1
Abbildung 3.7: Nachbarschaft des Knotens P und Verbildlichung des Umbrella-Operators
Das physikalische Äquivalent des Umbrella-Operators entspricht einer Verbindung der
Knoten durch Federn. Jede Kante stellt also eine Feder dar, welche bestrebt ist, diese Kante
zu verkürzen. Ziel ist es, die Energie dieses Federsystems zu minimieren.
Die Federkraft F~i einer Kante P Pi ist proportional zu deren Länge |Pi −P |, in Anlehnung
an das Federgesetz von Hook:
F~ =
n
X
i=1
F~i =
n
X
i=1
k(Pi − P )
(3.3)
k ist hier die Federkonstante. Für k = n1 ist dieser Ausdruck gleich dem Umbrella-Operator.
Aufgrund der kleinen Änderung der Ferderlänge kann die Federkraft innerhalb eines Iterationsschrittes als konstant angesehen werden. Die Knotenverschiebung pro Iterationsschritt
ist proportional zur Kraft (Grundgesetz der Mechanik) und wird wie in (3.2) berechnet. λ
repräsentiert hierbei eigentlich ein Produkt mehrerer konstanter Werte wie Masse, Federkonstante usw.
Bei der iterativen Verschiebung der Knoten nach (3.2) wird das Problem der globalen
Energieminimierung in eine Reihe von lokalen Problemen umgewandelt, da nicht alle Knoten des Netzes auf einmal, sondern immer nur eine beschränkte Nachbarschaft betrachtet
werden muss. Bei der Netzrelaxation soll, anders als bei der Glättung, die äußere Form des
Netzes möglichst erhalten bleiben. Es kommen daher einige Randbedingungen hinzu: Knoten dürfen nur auf der ursprünglichen Fläche verschoben werden. Knoten auf den Rändern
und auf scharfen Kanten (feature lines) sollen nur entlang von diesen verschoben werden.
Eckknoten, d.h. Randknoten, wo der Rand einen gewissen Winkel bildet, werden gar nicht
verschoben, also “eingefroren“.
Um den Randbedingungen gerecht zu werden, wird nach jeder Verschiebung eines Knotens dieser sogleich auf die ursprüngliche Fläche, bzw. bei Rändern und Kanten auf diese
projiziert. Um Schwingungen zu vermeiden, ist es außerdem wichtig, den Verschiebungsfaktor λ nicht zu groß zu wählen und bei der Berechnung sämtlicher Knotenpositionen
die Positionen der Knoten aus dem vergangenen Iterationsschritt zu verwenden. Die neuen
Knotenpositionen werden also erst im nächsten Iterationsschritt verwendet, so dass alle
Berechnungen eines Iterationsschritts auf denselben Daten stattfinden.
52
Abbildung 3.8: Gitterrelaxation (Beispiel). Links: Ausgangszustand. Rechts: Nach der Relaxation.
Ob ein Knoten bei der Relaxation verschoben werden muss, oder ob das Netz an dieser Stelle hinreichend relaxiert ist, hängt vom Verhältnis zwischen größtem und kleinstem
Abstand zu seinen Nachbarknoten ab. Bei Viereck-Elementen gelten auch solche Knoten als Nachbarknoten, die nicht durch eine Elementkante sondern durch eine Diagonale
benachbart sind. Das ist wichtig, weil sonst die Gleichseitigkeit, nicht aber die Gleichwinkligkeit der Elemente angestrebt
würde. Da die Diagonale eines idealen, also quadratischen
√
Viereck-Elements um 2 länger ist als die Elementkante, müssen die Abstände entsprechend gewichtet werden. Abbildung 3.8 zeigt ein Ergebnis des entwickelten Verfahrens.
3.5
Erkennung und Visualisierung von Penetrationen
Das Erkennen und Visualisieren von Penetrationen basiert auf dem Verfahren zur Visualisierung von Bauteil-Abständen (distance-mapping) [26, 82]. Dabei wird für jeden Knoten
des Modells oder der ausgewählten Bauteile der kleinste Abstand zum nächstliegenden
Bauteil berechnet. Um nicht den Abstand jedes Knotens zu jedem Element berechnen zu
müssen, wird die Bounding Volume Hierarchie aus Abschnitt 2.7 verwendet.
Der Mindestabstand jedes Knotens wird anschließend in eine Texturkoordinate einer
eindimensionalen (RGBA-)Textur umgerechnet. Die eindimensionale Textur enthält eine Anzahl von Farbwerten, welche die verschiedenen Bereiche von Abständen darstellen.
Abstände, die unter einem gegebenen Mindestwert liegen, werden in der Regel durch die
Farbe rot repräsentiert. Sämtliche Farben können aber auch interaktiv durch den Benutzer
verändert werden. Der letzte Wert dieser Farbtabelle ist im Normalfall transparent, hat
also einen Alpha-Wert von 0.
Dieses Vorgehen hat zur Folge, dass für jeden Punkt auf der Oberfläche eines Bauteils
der Abstand zum nächstliegenden Bauteil durch Farbe visualisiert wird. Regionen, für die
ein Mindestabstand unterschritten ist, sind rot dargestellt. Regionen, für die der Abstand
größer ist als der interessierende Maximalwert, werden nicht farblich markiert. In einem
bestimmten Textur-Modus (GL MODULATE) können die nicht interessierenden Bereiche
auch ganz ausgeblendet werden, ohne dass Geometrieberechnungen nötig sind.
3.6 Beseitigung von Penetrationen
53
Wie zu Beginn dieses Kapitels erwähnt, sind Penetrationen Bereiche, wo sich zwei
Bauteile näher kommen als ein Betrag d, der die mittlere Blechdicke darstellt. Um Penetrationen zu visualisieren, muss einfach der Mindestwert bei der Abstandsvisualisierung
dem Betrag d gleichgesetzt werden.
3.6
Beseitigung von Penetrationen
Penetrationen führen zu abstoßenden Kräften zwischen Bauteilen. Daher ist es naheliegend, die perforierenden Knoten und die perforierten Elemente entsprechend der abstoßenden Kräfte zu verschieben (Abb 3.9). Da diese Kräfte jedoch von den zu verändernden
Knotenpositionen abhängen, empfiehlt sich ein iteratives Vorgehen.
Zu berücksichtigen ist hierbei die Tatsache, dass einige, vom Benutzer festgelegte Bauteile nicht verändert werden dürfen. Nach jeder Iteration wird die Penetrationserkennung
erneut durchgeführt, da durch die Veränderungen zeitweilig auch neue Penetrationen hinzukommen können.
In jeder Iteration werden die penetrierenden Knoten und die penetrierten Elemente
entsprechend der abstoßenden Kräfte um einen kleinen Betrag voneinander weggeschoben.
Bei den penetrierten Elementen wird dabei die abstoßende Kraft auf die für das Beseitigen
der Penetration mindestens nötige Anzahl von Knoten gleichmäßig verteilt. Viereckige
Elemente werden dabei wie zwei Dreieckselemente behandelt.
Folgende drei Fälle sind zu unterscheiden:
• Hat der penetrierende Knoten eine Projektion auf die Oberfläche des penetrierten
Elements, wird die abstoßende Kraft allen drei Knoten zugeordnet, die dem betroffenen Dreieck entsprechen.
• Hat der penetrierende Knoten keine Projektion auf die Oberfläche des nächstliegenden penetrierten Elements, jedoch eine Projektion auf eine Elementkante (wie in
Abb. 3.9), wird die abstoßende Kraft den beiden Knoten dieser Kante zugeordnet. Da
Viereck-Elemente wie zwei Dreiecke behandelt werden, gilt hier die erste Diagonale
ebenfalls als Kante.
• Treffen die ersten beiden Fälle nicht zu, so muss der penetrierende Knoten in der
Nähe eines Elementknotens liegen, um eine Penetration hervorzurufen. Die abstoßende Kraft wird dann diesem einen nächstliegenden Elementknoten zugeordnet.
Eine weitere Schwierigkeit ergibt sich aus der diskreten Struktur des Problems. Sind in der
Realität die Kontaktkräfte kontinuierlich über eine Fläche verteilt, so wirken diese Kräfte
beim Finite-Elemente-Modell nur zwischen einzelnen Knoten und Elementen. Die Folgen
lassen sich anhand eines Beispiels verdeutlichen.
54
Element
d
Knoten
F
Abbildung 3.9: Knoten und Kanten, deren
Abstand zu einem Element kleiner als die
Blechdicke d ist, penetrieren und werden
abgestoßen. Bei der Abstandsberechnung
wird nur das dem Knoten nächstliegende
Element eines Bauteils berücksichtigt.
2
1
2
1
0
1
2
1
2
Abbildung 3.10: Beispiel für eine ungleichmäßige Verteilung der penetrierenden Knoten auf penetrierte Elemente. Die
Zahlen stellen die Anzahl der penetrierenden Knoten für jedes Element des einen
Bauteils dar.
Gegeben seien zwei ebene, parallele Bauteile mit unterschiedlichem FE-Gitter, deren
Abstand zueinander weniger als die mittlere Blechdicke d beträgt, so dass eine Penetration
über die gemeinsame parallele Fläche vorliegt. Durch die verschiedenen FE-Gitter ist es
sehr wahrscheinlich, dass die Projektion der Knoten auf die Elemente des jeweils anderen
Bauteils nicht gleichmäßig ist. Vielmehr wird es einige Elemente geben, die von mehreren
Knoten des anderen Bauteils penetriert werden, während andere Elemente vielleicht von
keinem Knoten penetriert werden (Abb. 3.10).
Würden nun die penetrierenden Knoten und die penetrierten Elemente entsprechend
der abstoßenden Kräfte voneinander wegbewegt, würde aufgrund der ungleichmäßigen Verteilung der Kräfte die ursprünglich ebene Fläche der Bauteile verbeult, also uneben werden.
Eine Idee zur Lösung dieses Problems besteht darin, den Betrag der Kräfte zu vereinheitlichen, z.B. durch Normierung der Kraftvektoren, so dass allein deren Richtung zählt. Bei
mehreren Kräften Fi ist jeweils nur die maximale Komponente dieser Kräfte in jeder der
6 Hauptrichtungen (~ex , ~ey , ~ez , −~ex , −~ey , −~ez ) zu berücksichtigen, und diese Maxima sind
dann zu addieren:


 
min((Fi )x )
max((Fi )x )
(3.4)
F = max((Fi )y ) − min((Fi )y )
min((Fi )z )
max((Fi )z )
Das Ergebnis dieser Vorgehensweise ist, dass bei Kräftekomponenten in die gleiche Richtung nur die größte Kraft in diese Richtung berücksichtigt wird, bei Kräftekomponenten in
entgegengesetzte Richtungen jedoch der Differenzbetrag gebildet wird. Letzteres ist wichtig, damit z.B. gleiche Kräfte in entgegengesetzte Richtungen sich aufheben.
3.7 Ergebnisse
55
Abbildung 3.11: Mehrfache Penetration, bei der entgegengesetzte Kräfte auf den dazwischenliegenden Knoten wirken.
Kräfte in entgegengesetzte Richtungen treten z.B. auf, wenn ein Knoten sich zwischen
zwei anderen Bauteilen befindet und diese penetriert (Abb 3.11). Bei der Behebung der
Penetration mit einem Bauteil würde der Knoten in Richtung des anderen verschoben und
könnte dies in ungünstigen Fällen perforieren. Durch die Skalierung der Kräfte auf einen
einheitlichen Betrag werden Perforationen verhindert und das Ausmaß der bestehenden
Penetrationen wird nicht vergrößert.
Um den Betrag der Verschiebung eines Knotens zu erhalten, wird die resultierende Kraft
aus Ausdruck (3.4) mit einem konstanten Faktor δ multipliziert. Wurden die Kraftvektoren
vor deren Komposition nach (3.4) normiert, so entspricht δ der in einem Iterationsschritt
maximal möglichen Knotenverschiebung in eine Hauptrichtung. In der Praxis hat sich ein
d
Wert von δ = 20
bewährt. Penetrationen zweier veränderbarer Bauteile sind damit nach
höchstens 10 Iterationen behoben. Mehrfache Penetrationen, wo z.B. mehrere Blechschichten nahe beieinander liegen, können eine etwas größere Anzahl von Iterationen erfordern.
Gibt es mehrere Bauteile, die nicht verändert werden dürfen, kann eine Penetrationsbehebung unter Umständen unmöglich sein. Für diese Fälle ist es sinnvoll, die maximal
durchzuführende Anzahl von Iterationen von vorneherein zu begrenzen.
3.7
Ergebnisse
Mit der hier vorgestellten Visualisierung und Beseitigung von Perforationen und Penetrationen, gemeinsam mit der Gitterrelaxation, wurde dem Berechnungsingenieur ein Werkzeug zur Behebung einer bedeutenden Kategorie von Netzinkonsistenzen zur Hand gegeben. Durch die Verwendung effizienter Algorithmen, z.B. der Bounding-Volume-Hierarchie,
ist ein interaktives Arbeiten gewährleistet. Der Anwender sieht also ohne wahrnehmbare
Verzögerung das Ergebnis seiner Aktionen.
Zur besseren Veranschaulichung sollen nun die vorgestellten Algorithmen anhand eines
Beispiels aus der Praxis vorgeführt werden. Dafür wurde ein Bauteil gewählt, das mehrere
Durchdringungen mit einem anderen Teil aufweist (Abb. 3.12). Das später vorgestellte
Verfahren zur Justierung des Abstandes von Flanschen (Abschnitt 6.11) wäre hier nur
beschränkt einsetzbar, da die Durchdringungen nicht nur an Flanschen auftreten.
56
Abbildung 3.12: Ausgangszustand: mehrere Perforationen (zwei Ansichten des selben FEModells)
Abbildung 3.13: Farbliche Visualisierung der Perforationen auf dem zu verändernden Bauteil.
Abbildung 3.14: Ansicht nach Behebung der Perforationen
In einem ersten Schritt werden die Perforationen farblich hervorgehoben (Abb. 3.13).
Dieser Schritt ist optional. Der Bereich mit perforierenden Netzknoten ist rot eingefärbt.
Damit die perforierende Region auch von der anderen Seite (rechts im Abb. 3.13) gut
zu erkennen ist, wird die Umgebung um die Perforation ebenfalls gekennzeichnet. Dabei
wurde ein kontrastreiches Farbspektrum wie bei der Visualisierung der Penetrationen verwendet, mit dem Unterschied, dass hier die Farben allein der Lokalisierung dienen, also
keine bestimmten Distanzwerte darstellen.
Sind die perforierenden Stellen bekannt oder gut sichtbar wie in diesem Beispiel, kann
die Behebung der Perforationen auch direkt angegangen werden. Zur Perforationsbehebung
wählt der Benutzer erst das perforierende Bauteil, welches verändert werden soll. Anschliessend wird das zweite, d.h. das perforierte Bauteil angegeben, in Bezug auf welches die
Perforation behoben werden soll. Der damit gestartete Algorithmus beseitigt sämtliche
3.7 Ergebnisse
57
Abbildung 3.15: Verschiebung eines einzelnen, vom Benutzer spezifizierten Netzknotens,
zur Behandlung von Sonderfällen.
Abbildung 3.16: Nach der Verschiebung eines einzelnen Knotens (Abb. 3.15) ist eine Elementkante verkürzt (links, Pfeil) und somit das Gitter verzerrt. Durch die Gitterrelaxation
wurde die Gleichmäßigkeit des Gitters soweit wie möglich wieder hergestellt (rechts).
Abbildung 3.17: Visualisierung der Bauteilabstände, vor und nach der Beseitigung der
Penetrationen. Rote Bereiche (oben) kennzeichnen Penetrationen.
58
Perforationen des angegebenen Bauteils, sofern dies in eindeutiger Weise möglich ist (Abb.
3.14). Gelegentlich kann es notwendig sein, dass der Benutzer einzelne Netzknoten angibt,
welche zwecks Beseitigung der Perforation verschoben werden sollen (Abb. 3.15).
Wenn perforierende Elemente einen Winkel um die 90◦ bilden, wie in Abb. 3.15, kann
es bei der Beseitigung der Durchdringungen zu Verzerrungen einzelner Elemente kommen.
Eine Gitterrelaxation, wie in Abschnitt 3.4 beschrieben, ist in solchen Fällen sinnvoll.
Abbildung 3.16 zeigt die Auswirkung des Relaxationsalgorithmus anhand dieses Beispiels.
Da bei der Perforationsbehebung eine möglichst geringe Veränderung des perforierenden
Bauteils vorgenommen wird, beträgt der Abstand zum anderen Bauteil stellenweise weniger
als die mittlere Blechdicke. Eine Erkennung und Behebung von Penetrationen, dargestellt
in Abb. 3.17, wird daher durchgeführt.
Nachdem die Perforationen und Penetrationen erfolgreich beseitigt wurden, kann nun
das weitere Preprocessing angegangen werden. Dies kann z.B. in der Definition von Verbindungselementen bestehen, wobei die in den nächsten Kapiteln beschriebene Flanscherkennung und automatische Definition von Schweißpunkten eine Rolle spielt.
Kapitel 4
Erkennen von Flanschen
4.1
Motivation
Die Einführung unabhängig vernetzter Bauteile in der Crash-Simulation (um 1999) erforderte zugleich ein schlüssiges Konzept für die Verbindung von Bauteilen. Waren im global
vernetzten Modell die Bauteile durch gemeinsame Knoten verbunden, ist das heutige Vorgehen mehr an die realen Bedingungen angelehnt. So werden Flansche, die früher bei der
Berechnung vernachlässigt wurden, jetzt ebenfalls durch finite Elemente abgebildet.
Flansche sind Bereiche eines Bauteils, welche die Verbindung mit einem anderen Bauteil erleichtern. Flansche bilden eine zu dem anderen Bauteil parallele Fläche. Dadurch
wird eine hinreichend große Kontaktfläche gebildet, auf welcher Verbindungselemente wie
Schrauben, Nieten, Schweißpunkte oder Kleber angebracht werden können.
Mit der Einführung unabhängig vernetzter Bauteile wurden spezielle Finite Elemente
zur Darstellung von Verbindungen eingeführt.
Anfangs wurden alle Verbindungen durch Schweißpunkte (spotwelds, point links) realisiert. Im CrashViewer wurde die Visualisierung und die Manipulation einzelner Schweißpunkte durch [49] implementiert.
Inzwischen wurden auch andere Verbindungsarten für die Simulation entwickelt. So
werden Klebeverbindungen durch flächige Verbindungselemente (surface links) dargestellt,
während Schweißnähte entlang von Bauteilkanten und Schweißlinien auf Flanschen durch
linienförmige Verbindungselemente (line links) dargestellt werden.
Da es mühsam ist, die Verbindungselemente im Finite-Elemente-Modell einzeln zu definieren, ist es naheliegend, diesen Vorgang zu automatisieren. Hilfreich ist dabei die Tatsache, dass Verbindungselemente meistens auf Flanschen positioniert werden. Im Rahmen
der vorliegenden Arbeit wurde deshalb ein Algorithmus zur Erkennung von Flanschen entwickelt. Dieser Algorithmus kann dafür verwendet werden, Schweißpunktlinien, Schweißlinien und Klebeverbindungen mit minimalem Aufwand zu definieren. Das erspart dem
60
Benutzer viel Arbeit, da er nicht jedes einzelne Element der Verbindung definieren muss,
sondern den ganzen Flansch schnell mit einem anderen Bauteil verbinden kann.
Eine vollautomatische Definition von Verbindungen für das gesamte Modell ist ebenfalls möglich. In Abschnitt 6.11 wird darüberhinaus die Flanscherkennung zusammen mit
Freiform-Deformation zum Anpassen von Bauteil-Abständen und zur Perforationsbeseitigung verwendet.
4.2
Vorgehensweise
Um ein Verfahren zur Flanscherkennung zu entwickeln, wurden die Eigenschaften, die Flansche charakterisieren, in algorithmisch verwertbare Formulierungen gefasst:
1. Ein finites Element kann nur dann zu einem Flansch gehören, wenn der Winkel zwischen der Normale des Elements und der Normalen des nächstliegenden Elements des
zu verbindenden Bauteils einen bestimmten Wert γ nicht überschreitet. Dies folgt aus
der Tatsache, dass die Oberfläche an Flanschen nahezu parallel zu dem anderen Bauteil ist. Der Wert des Winkels γ ist durch den Benutzer einstellbar und hängt von
der weiteren Verwendung des Ergebnisses der Flanscherkennung ab.
2. Ein finites Element kann nur dann zu einem Flansch gehören, wenn der Abstand
zu dem zweiten Bauteil einen bestimmten Wert d nicht überschreitet. Der Grund
hierfür ist, dass bei einem zu großen Abstand eine Bauteilverbindung technisch nicht
machbar ist. Auch der Wert d ist durch den Benutzer einstellbar und vom Kontext
der Flanscherkennung abhängig. Der Abstand wird dabei an allen Knoten sowie in
der Mitte des potentiellen Flanschelementes gemessen, um eine hinreichende Aussagefähigkeit zu erhalten. Der Bauteilabstand d bei der Flanscherkennung hat in der
Regel nichts zu tun mit dem Bauteilabstand bei der Penetrationsbehandlung.
3. Ein Flansch besteht aus einer Mindestanzahl n von zusammenhängenden finiten Elementen. Ein Element allein stellt also noch keinen Flansch dar, auch wenn die ersten
beiden Bedingungen erfüllt sind.
4. Flansche haben eine längliche Form. Da Flansche sich entlang von Bauteilrändern erstrecken, ist die Länge des Flansches wesentlich länger als dessen Breite. Ein Flansch
ist also in der Regel bandförmig. Änderungen der Breite im Flanschverlauf sind eher
selten. Der Benutzer kann eine maximale Flanschbreite w angeben, die bei Zweideutigkeiten dazu verwendet wird, die Längsrichtung des Flansches zu bestimmen.
5. Durch die Bandform mit relativ geringer Breite ergibt sich bei der Vernetzung eine
regelmäßige Struktur des Finite-Elemente-Netztes auf der Oberfläche des Flansches.
Dreiecke sind eher selten, und die Viereckelemente sind an den Rändern des Flansches
ausgerichtet. Ausnahmen sind allerdings möglich.
4.2 Vorgehensweise
61
6. Flansche können Lücken und Sicken enthalten. Diese stellen eine Unterbrechung des
Flanschverlaufes dar. Eine Möglichkeit besteht darin, die einzelnen Teile als unabhängige Flansche zu behandeln. In Abschnitt 5.2 wird eine Vorgehensweise gezeigt, welche es ermöglicht, die Flanscherkennung über Sicken und Lücken hinweg
fortzusetzen.
Punkt 1 und 2 lassen sich einfach Element für Element überprüfen. Bei der Überprüfung
der Normalenabweichung wird dabei aus Effizienzgründen mit cos(γ) verglichen, da der
Cosinus des Winkels unmittelbar durch das Skalarprodukt der Normalen erhalten wird.
Das nächstliegende Element für 1 und 2 wird hier mit Hilfe der Bounding Volume Hierarche
effizient gefunden.
Aus Punkt 3 lässt sich folgern, dass ausgehend von einem Flanschelement durch Nachbarschaftssuche alle anderen Elemente des Flansches gefunden werden können. Das erste
Flanschelement kann durch den Benutzer angegeben werden, z.B. implizit beim Mausklick
auf den Flansch der bearbeitet werden soll. Ist keine Benutzerinteraktion erwünscht, so wie
beim vollautomatischen Verbinden sämtlicher Flansche, werden alle Elemente untersucht,
sofern sie noch nicht durch Nachbarschaftssuche als zu einem Flansch zugehörig markiert
wurden.
Die Nachbarschaftssuche wurde von einem Algorithmus zum Durchsuchen von Bäumen
nach [77] abgeleitet. Ein Baum ist ein spezieller, azyklischer Graph und besteht aus Knoten,
die durch Zweige so verbunden sind, dass eine hierarchische Struktur entsteht. Die Wurzel
des Baums wird hierbei als höchste Ebene, oder Level 0 bezeichnet. Alle anderen Knoten
sind Kinder je eines Knotens der nächsthöheren Ebene. Knoten ohne Kinder werden Blätter
genannt.
Im Fall der Flanschsuche ist die Wurzel das Startelement. Die Kinder eines jeden Knotens sind die Nachbarelemente dieses Knotens, sofern sie noch nicht als Nachbarn eines
anderen Elements bereits im Baum enthalten sind, und sofern sie die Flanscheigenschaften
(Punkt 1 und 2) erfüllen (Abb. 4.1). Durch die Nachbarschaftsbeziehungen sind somit sämtliche Elemente eines Flansches in einem Baum angeordnet. Durch Markieren der bereits
bearbeiteten Elemente wird sichergestellt, dass es im Baum keine Duplikate gibt.
Bei der Durchsuchung eines Baums gibt es zwei Varianten: die Tiefensuche (depth
first) und die Breitensuche (breadth first). Bei der Tiefensuche wird bei jeder Verzweigung
erst der Pfad bis zu den Blättern (= Knoten ohne weitere Verzweigungen) verfolgt, bevor
der nächste Zweig bearbeitet wird. Bei der Breitensuche werden erst alle Knoten einer
Ebene bearbeitet, bevor die nächste Ebene und schließlich die Blätter bearbeitet werden.
Die Tiefensuche kann rekursiv oder mit Hilfe einer Stapel-Struktur (Stack) implementiert
werden. Die Breitensuche kann mit Hilfe einer Warteschlange (FIFO-Queue) implementiert
werden.
In einigen Anwendungsfällen können beide Varianten hergenommen werden, um den
Baum zu durchsuchen. Bei den verschiedenen Anwendungen der Flanscherkennung, die
hier vorgestellt werden, ist die Breitensuche von Vorteil.
62
18
12
6
2
7
13
19
24
14
8
3
1
5
11
17
23
20
15
9
4
10
16
22
27
21
Startelement
Nachbarn
1. Ordnung
Nachbarn
2. Ordnung
u.s.w.
1
2
3
6
7
8
12
13
14
18
19
20
9
4
5
10
11
16
17
22
23
26
15
25
21
24
25
...
26
... ...
Abbildung 4.1: Flanscherkennung: Links: Progressive Nachbarschaftssuche. Rechts: Zugehöriger Baum. Jeder Knoten des Baumes stellt ein Flanschelement dar.
Die längliche Form und die gleichmäßige Gitterstruktur (Punkt 4 und 5) werden bei
der automatischen Positionierung von Schweißpunkten (Kapitel 5) genutzt, um z.B. die
Mittellinie zu berechnen, auf welcher die Schweißpunkte liegen werden. Für die Justierung
des Flanschabstandes spielen diese beiden Eigenschaften keine Rolle.
4.3
Ergebnisse
Im vorherigen Abschnitt wurde die Vorgehensweise bei der Erkennung von Flanschen theoretisch erläutert. An dieser Stelle soll anhand von einigen Beispielen aus der Praxis ein
Eindruck von der Formenvielfalt der Flansche vermittelt werden.
Abbildung 4.2 zeigt einen ringförmig geschlossenen Flansch mit ungleichmäßiger Breite.
Zudem stellt dieser Flansch die Verbindung zu mehr als einem, nämlich zu drei weiteren
Bauteilen her. Zur besseren Veranschaulichung ist der Flanschbereich heller dargestellt und
mit einer gestrichelten Linie umgeben.
Der ringförmige Flansch wird vom Erkennungsalgorithmus, ausgehend von einem
Startelement, in beide Richtungen abgearbeitet. Der Algorithmus terminiert, sobald alle Flanschelemente als besucht markiert sind. Die sich im Flanschverlauf ändernde Breite
stellt ebenfalls kein Problem dar, weil die Nachbarschaftssuche in alle möglichen Richtungen verläuft.
4.3 Ergebnisse
63
Abbildung 4.2: Ringförmig geschlossener Flansch mit ungleichmäßiger Breite
Je nach Anwendung kann entweder der gesamte Flansch betrachtet werden, oder diejenigen Bereiche (Elemente) herausgefiltert werden, die sich in direkter Nachbarschaft zu
einem bestimmten anderen Bauteil befinden. Letzteres ist wichtig für die Definition von
Verbindungselementen, da sich an der Verbindungsstelle kein weiteres Bauteil zwischen
den verbundenen Teilen befinden darf. Dies wird aber in jedem Fall bei der Erzeugung von
Verbindungselementen überprüft.
Abbildung 4.3 zeigt einen Flansch, der einfach durch zwei überlappende Bleche gegeben
ist. Zur Veranschaulichung ist in dieser Abbildung eines der Bleche transparent dargestellt.
Es gibt hier keinen speziellen, abgewinkelten Flanschbereich. Der Flansch wird allein
durch die Fläche definiert, auf der sich die beiden Teile nahe kommen. Aufgrund der ele-
Abbildung 4.3: Flansch gegeben durch zwei überlappende Bleche
64
Abbildung 4.4: Flansch mit Unebenheiten (Sicken)
mentweisen Prüfung wird auch hier der Flansch richtig erkannt.
Abbildung 4.4 stellt einen Flansch mit Unebenheiten (Sicken) dar. An solchen Stellen
besteht eine erhöhte Winkelabweichung zwischen Flansch und darunterliegendem Bauteil.
Die für Flansche zulässige Winkelabweichung ist durch den Benutzer einstellbar. Ähnliches
gilt für den Abstand der einzelnen Flanschknoten zum darunterliegenden Bauteil.
Der hier abgebildete Flansch wird allerdings auch unter Beibehaltung der ursprünglichen (Default-)Einstellungen erkannt. Bei noch größeren Unebenheiten können die zulässigen Werte für Abstand und Winkelabweichung erhöht werden. Allerdings sollten diese
Werte nur so hoch wie nötig sein, da sonst in einigen Fällen zusätzliche Elemente fälschlicherweise als zum Flansch gehörend eingestuft werden. Diese Gefahr ist insbesondere dann
gegeben, wenn auch andere Bereiche des Flanschbauteiles relativ parallel und nahe zum
anderen Bauteil liegen – so wie es in diesem Beispiel der Fall ist.
In einigen Fällen gibt es außerdem Unterbrechungen im Flanschverlauf, so dass der
Flansch in mehrere Teile unterteilt wird. In einem solchen Fall kann entweder jeder
Teilflansch als eigenständiger Flansch behandelt werden, oder es werden sämtliche Flansche mit Bezug zu einem zweiten Bauteil erkannt. Ist jedoch nicht nur ein Startpunkt für
die Flanschsuche gegeben, sondern zwei Punkte auf dem Flansch, so kann der Algorithmus erweitert werden, so dass auch Unterbrechungen im Flanschverlauf sinnvoll behandelt
werden. Mehr dazu ist in Abschnitt 5.2 zu lesen, wo das Erzeugen von Schweisspunktlinien
entlang von Flanschen beschrieben wird.
Kapitel 5
Automatische Definition von
Schweißpunktverbindungen
5.1
Überblick
Nachdem in Kapitel 4 ein Verfahren zur Flanscherkennung präsentiert wurde, soll hier als
erste Anwendung die automatische Platzierung von Schweißpunkten vorgestellt werden.
Das Verfahren besteht im Wesentlichen aus folgenden Schritten:
1. Suche einen zusammenhängenden Elemente-Pfad minimaler Länge, welcher den
Flanschverlauf approximiert.
2. Suche für jedes Element des Pfades die nächstliegenden beiden Flanschränder in Form
von Elementkanten. Eliminiere Duplikate.
3. Bestimme die Mittelpunkte für die jeweils 4 Knoten der Paare von Elementkanten, welche im vorigen Schritt als Flanschränder gefunden wurden. Die Sequenz der
Mittelpunkte ergibt einen Polygonzug, welcher die Mittellinie des Flansches approximiert.
4. Teile die Mittellinie in Segmente gleicher Länge entsprechend dem gewünschten Abstand zwischen den Schweißpunkten. Platziere die neuen Schweißpunkte entsprechend
auf der Mittellinie.
Eine Idee, die Schweißpunktlinien durch Spline-Kurven zu modellieren, wurde wieder verworfen. Zwar wurde durch [49] die Definition gerader Schweißpunktlinien durch Angabe
der Endpunkte realisiert. Dieses Verfahren auf gekrümmte Schweißpunktlinien auszudehnen würde jedoch einen zu großen Aufwand für den Benutzer bedeuten, der dann eine
größere Anzahl von Kontrollpunkten positionieren müsste.
66
Automatische Definition von Schweißpunktverbindungen
Stattdessen wurde verucht, den Aufwand für den Benutzer zu minimieren. Bei der
Definition von Schweißpunktlinien gibt es drei Anwendungsszenarien:
1. Der Benutzer legt einen Anfangs- und einen Endpunkt auf dem Flansch fest.
Gewünscht ist eine Reihe von Schweißpunkten entlang der Flanschmittellinie, begrenzt durch die beiden vorgegebenen Punkte. Das mit dem Flansch zu verbindende
Bauteil wird mit einem dritten Mausklick festgelegt.
2. Der Benutzer legt die beiden zu verbindenden Bauteile fest. Bei der Spezifikation des
ersten Bauteils klickt er auf einen Flansch und wählt so ein Element des Flansches
aus, von wo aus die Suche gestartet wird.
3. Für einige oder alle Bauteile werden sämtliche Flansche detektiert und durch Schweißpunkte mit den entsprechenden Partnerbauteilen verbunden.
Im Folgenden werden diese drei Szenarien vorgestellt. Dabei wird auch die Anpassung
des Flanscherkennungsverfahrens an die unterschiedlichen Szenarien beschrieben.
5.2
Szenario 1
Beim Szenario 1 werden mit der Angabe von Anfangs- und Endpunkt auch implizit zwei
Flanschelemente festgelegt, welche diese zwei Punkte beinhalten. Diese zwei Flanschelemente dienen als Start- und Zielelement bei der Suche eines kürzesten Pfades von jeweils
benachbarten Elementen. Durch den kürzesten Pfad erhält man eine erste Information
über den Flanschverlauf. Es gibt im Allgemeinen mehrere gleichlange Pfade, die ein Startelement mit einem Zielelement verbinden, und dabei die Eigenschaft besitzen, dass kein
kürzerer Pfad von Elementen zwischen Start und Ziel existiert.
Bei der Suche eines kürzesten Pfades wird ein Algorithmus verwendet, wie er in Kapitel 4 beschrieben ist. Dabei ist das Startelement die Wurzel des baumförmigen Graphen.
Dieser wird solange durchsucht (Breitensuche), bis das Zielelement gefunden ist. Es werden also zuerst die (Kanten-)Nachbarn des Startelements nach dem Zielelement durchsucht,
dann deren Nachbarn, sofern es sich um Flanschelemente handelt, usw.
Im Zuge dieser Baumsuche wird jedem Kind eines Knotens ein Zeiger auf den Knoten
zugeordnet. Das heißt, jedes Element enthält einen Zeiger auf dessen Vorgängerelement.
Der Weg zur Wurzel des Baumes, also zum Startelement, lässt sich damit zurückverfolgen.
So kann am Ende der Suche, wenn das Zielelement gefunden wurde, eindeutig ein kürzester
Pfad zum Startelement ermittelt werden. Dabei wird ausgehend vom Zielelement der jedem Element zugeordnete Zeiger verwendet, um das jeweilige Vorgängerelement zu erhalten. Der so gefundene Elementpfad wird in Form einer Liste für die weitere Verarbeitung
bereitgestellt.
5.2 Szenario 1
67
Enthält der Flansch jedoch Lücken oder Sicken (Abb. 5.1), kann eventuell kein durchgehender Pfad von Flanschelementen zwischen den gegebenen Punkten gefunden werden.
Auf Lücken und Sicken können bzw. sollen keine Schweißpunkte gesetzt werden. Dennoch
soll auf dem restlichen Flansch eine Verbindung definiert werden.
Abbildung 5.1: Sicken und Lücken erschwerden die Flanscherkennung. Schweißpunkte, als
rote Quader visualisiert, dürfen nicht auf Sicken oder Lücken positioniert werden.
In diesem Fall hat es sich als sinnvoll erwiesen, eine minimale Anzahl von Nicht-FlanschElementen zuzulassen, um einen durchgehenden Pfad zu erhalten. In der späteren Verarbeitung wird an diesen Stellen die Schweißpunktlinie unterbrochen.
Um bei der Suche nach dem Zielelement Lücken und Sicken falls nötig zu überspringen, werden die Nicht-Flansch-Elemente unter den angetroffenen Nachbarelementen in eine
eigene Liste eingetragen. In dieser Liste befinden sich somit all diejenigen Elemente, die
unmittelbar an den Flansch angrenzen, zumindest wenn sie sich innerhalb des aktuell erreichten Suchradius befinden.
Falls es keine weiteren Flanschelemente gibt, also wenn der gesamte Baum erfolglos
durchsucht wurde, wird die Liste der an den Flansch angrenzenden Elemente verwendet,
um die Suche fortzuführen. So ist sichergestellt, dass in jedem Fall ein Pfad gefunden wird.
In vereinfachter Form sieht der Programmcode wie folgt aus:
/** Methode findPath liefert kürzesten Pfad zwischen start und target **/
list<Elements> findPath(Element start, Element target)
{
Element element;
// derzeit bearbeitetes Element
fifoQueue<Elements> fifo;
// für Flanschelemente
list<Elements> reserve;
// für Nicht-Flansch-Elemente
bool targetReached = false;
// terminiert die while-Schleife
fifo.add(start);
// Wurzel des durchsuchten Baumes
while (not targetReached) {
// Ziel wird sicher gefunden
element = fifo.retrieve();
// nächster Knoten des Baumes
for (all neighbour of element) { // Durchsuche Nachbarschaft
if (element == target) {
// Ziel wurde erreicht
targetReached = true;
// Abbruch der while-Schleife
neighbour.previous = element; // um den Weg zurückzuverfolgen
68
break;
}
if (neighbour.unvisited) {
neighbour.markVisited();
neighbour.previous = element;
if (neighbour.isFlange)
fifo.add(neighbour);
else
reserve.add(neighbour);
}
}
if (fifo.isempty)
fifo.consume(reserve);
}
list<Elements> result;
for (element = target;
element != start;
element = element.previous)
result.append(element);
return result;
// Abbruch der For-Schleife
// wenn bereits besucht: ignorieren
// merke den Rückweg
// speichere Nachbarn
// bis zum nächstgrößeren Suchradius
// Reserve-Elemente,
// falls Flansch unterbrochen ist
// auf dem Flansch kein Weg zum Ziel
// fahre mit Reserve-Elementen fort
// für den gefundenen Pfad
// Rückverfolgung des Pfades
// vom Ziel- zum Startelement
// Richtung des Pfades unwichtig
}
Der so gefundene Pfad ist in der Regel nicht eindeutig, aber es ist sichergestellt, dass
kein kürzerer Pfad zwischen Start und Ziel existiert. Durch die ringförmige Suche um
das Startelement herum würde ein potentiell existierender kürzerer Pfad früher gefunden.
Somit kann die Existenz eines kürzeren Pfades ausgeschlossen werden.
Obwohl es Bereiche geben kann, wo der Pfad quer zum Flansch verläuft, ist der Pfad
größtenteils am Flanschverlauf ausgerichtet. Jeder Querschnitt des Flansches zwischen
Start und Ziel schneidet den Pfad. Diese Kontinuität des Pfades ermöglicht es, eine durchgehende Mittellinie zu bestimmen.
Die Mittellinie, die hier gesucht wird, ist der geometrische Ort aller Punkte, die von den
Flanschrändern in Längsrichtung gleichweit entfernt sind. Die Entfernung sollte dabei auf
der Flanschoberfläche gemessen werden. Eine direkte Entfernungsmessung würde fehlschlagen, wenn z.B. sich noch ein anderer Rand in der Nähe befindet. Die Länge der Mittellinie
wird beschränkt durch die benutzerdefinierten Endpunkte der Schweißpunktlinie.
In den Fachpublikationen findet man verschiedene Algorithmen zum Bestimmen der
Mittellinie eines Polygons (z.B. [13]). Doch entweder arbeiten diese Algorithmen auf Pixeldarstellungen von Polygonen, oder sie erfordern vollkommen ebene Polygone. Außerdem
weisen die so gefundenen Mittellinien Verzweigungen auf, und sind deshalb als Basis für
die Generierung von Schweißpunktlinien ungeeignet.
Bei dem hier vorgestellten neuen Verfahren zur Bestimmung der Mittellinie wird die
5.2 Szenario 1
69
vorwiegend regelmäßige Gitterstruktur auf Flanschen ausgenutzt. Da die finiten Elemente
größtenteils viereckig und am Flanschverlauf ausgerichtet sind, lassen sich die zu einem
Element nächsten Ränder durch eine Suche in vier Richtungen ermitteln. Die vier Richtungen sind durch die Elementkanten bestimmt, und werden solange verfolgt, bis entweder
a. ein Rand des Flansches, also ein Nicht-Flansch-Element,
b. ein Dreieck-Element, oder
c. die als Flanschbreite maximal anzunehmende Anzahl von Elementen
erreicht wird.
Bei einem regelmäßigen Vierecksgitter wäre Abbruchkriterium a hinreichend. Dreiecke
und andere Unregelmäßigkeiten können zu einer unerwünschten Richtungsänderung der
elementweisen Randsuche führen. Deshalb wurden die Abbruchkriterien b und c eingeführt.
Die richtungsgebundene Suche führt zu vier idealerweise geradlinigen Pfaden von Elementen. Diese Pfade sind nicht zu verwechseln mit dem Elementpfad zwischen Start- und
Zielelement, welcher nicht richtungsgebunden ist.
Von den vier richtungsgebundenen Elementpfaden werden jeweils zwei gegenüberliegende aneinandergefügt. So erhält man zwei Elementpfade φ1 und φ2 , von denen der kürzere
quer zur Flanschrichtung verläuft. Diese Pfade sind in etwa senkrecht aufeinander und
haben als gemeinsames Element das Ausgangselement der Suche.
Die vier Knoten (K1 , ..., K4 ) an den gegenüberliegenden Enden des kürzeren Elementpfades liegen also auf den längsverlaufenden Flanschrändern. Der Schwerpunkt
3 +K4
S = K1 +K2 +K
der vier Knoten bildet somit einen Stützpunkt der Mittellinie.
4
War jedoch bei dem Zustandekommen beider Pfade (also bei jeweils mindestens einem
der Teilpfade) Abruchkriterium b oder c erfüllt, kann keine Aussage über die Flanschrichtung gemacht werden. So kann beispielsweise an einer scharfen (z.B. 90◦ ) Richtungsänderung des Flansches im Allgemeinen kein Stützpunkt der Mittellinie gefunden werden, da
hier ein Längs- und ein Querrand des Flansches gegenüberliegen (Abb. 5.2). Derartige
Stellen treten aber nur vereinzelt auf und können übersprungen werden, da die Mittellinie
auch bei einigen fehlenden Stützpunkten noch hinreichend genau approximiert wird.
Das Finden der nächsten gegenüberliegenden Ränder erfolgt auf die beschriebene Weise
für alle Elemente des (nichtgerichteten) Elementpfades zwischen Start- und Zielelement,
letztere eingeschlossen. An Stellen, wo dieser Pfad quer zur Flanschrichtung verläuft, werden allerdings mehrmals dieselben Randelemente gefunden, was unnötigerweise zu mehrfachen gleichen Stützpunkten der Mittellinie führen würde. Diese Duplikate sind aber problemlos zu eliminieren.
Ist die Mittellinie im Bereich zwischen Start- und Zielelement gefunden (Abb. 5.3),
müssen noch die genauen Endpunkte ermittelt werden. Dies geschieht indem die beiden
Punkte, die der Benutzer auf der Flanschoberfläche angegeben hat, auf die Mittellinie
70
Legende:
Randfindung
erfolgreich
Legende:
Mausklicks
Randfindung
nicht erfolgreich
der
+ Stützpunkt
Mittellinie
Elementpfad
+
Mittellinie
Schweißpunkte
Abbildung 5.2: Aufgrund der Vielfalt von
Flanschformen ist es in Ausnahmefällen
sinnvoll, die Randerkennung abzubrechen
und die Mittellinie an solchen Stellen zu
interpolieren.
Abbildung 5.3: Zwischenschritte des Verfahrens zum automatischen Positionieren
einer Schweißpunktlinie.
projiziert werden. Dabei kann es nötig sein, die Mittellinie um einen kleinen Betrag durch
lineare Extrapolation zu verlängern.
Bei der anschließenden Verteilung der Schweißpunkte auf der Mittellinie soll einerseits der gewünschte Abstand zwischen den Schweißpunkten möglichst eingehalten werden, andererseits sollen zwei Schweißpunkte falls möglich genau an den Enden der Mittellinie platziert werden. Letzteres ist im Allgemeinen nur realisierbar, wenn der tatsächliche
Schweißpunktabstand etwas größer oder etwas kleiner als der gewünschte ist. Daher hat
der Benutzer drei Optionen:
a. der angegebene Betrag stellt den mindestens erforderlichen Abstand dar;
b. der angegebene Betrag stellt den höchstens erforderlichen Abstand dar;
c. der angegebene Abstand soll genau eingehalten werden, dafür endet die Schweißpunktlinie im Allgemeinen vor dem angegebenen Endpunkt.
Abbildung 5.4 zeigt ein Anwendungsbeispiel dieses Szenarios. Der Abstand zwischen
den Schweißpunkten wurde dabei so eingestellt, dass er in etwa dem Abstand zwischen
den Sicken auf dem Flansch entspricht. So wurde vermieden, dass Schweißpunkte auf den
Sicken positioniert werden.
5.3 Szenario 2
71
Abbildung 5.4: Anwendungsbeispiel für Szenario 1
5.3
Szenario 2
Bei Szenario 2 klickt der Benutzer auf einen Flansch und auf ein damit zu verbindendes
Bauteil. Die Schweißpunktlinie soll sich über die gesamte Länge des Flansches erstrecken.
Auch hier wird das Flanschelement, welches durch den ersten Klick festgelegt wurde,
als Startelement für die Flanschsuche verwendet. Da es jedoch in diesem Szenario kein
Zielelement gibt, muss das Suchverfahren geändert werden.
Um eine Schweißpunktlinie über die gesamte Länge des Flansches zu erzeugen, ist ein
entsprechender Elementpfad, der sich über die gesamte Länge erstreckt, hilfreich. Gesucht
sind also zwei Elemente an unterschiedlichen Enden des Flansches.
Beim Betrachten der Suchprozedur aus Szenario 1 stellt man fest, dass beim Nichtfinden
des Zielelementes, z.B. wegen Unterbrechung des Flansches, dasjenige Element als letztes
in der FIFO-Warteschlange übrigbleibt, welches am weitesten vom Startelement entfernt
ist. Auf dieser Erkenntnis basiert das Verfahren von Szenario 2, wo es darum geht, den
gesamten Flansch und nicht nur einen Abschnitt davon mit Schweißpunkten zu versehen.
Allerdings gilt hier die Einschränkung, dass der Flansch nicht durch Sicken oder Lücken
unterbrochen sein darf. Der Grund ist verständlich: da es kein Zielelement gibt, würde
die Suche sämtliche Elemente des Bauteils in nicht sinnvoller Reihenfolge erfassen und der
gefundene Pfad wäre nicht brauchbar. Allerdings ist diese Einschränkung unwesentlich, da
die einzelnen Segmente des Flansches nacheinander verbunden werden können. Durch die
vereinfachte Handhabung – es muss nur irgendwo auf den Flansch geklickt werden, die
Enden werden automatisch bestimmt – ist dies schnell vollbracht.
Allerdings ist auf die beschriebene Weise nur das eine, vom Startelement entfernteste
Flanschelement, zu finden. Benötigt werden jedoch zwei Elemente an gegenüberliegenden
Enden des Flansches.
72
Legende:
Startelement für
Gesamtpfad
Startelemente für
jede Region
Querpfad zwecks
Flanschtrennung
Pfade zu den
Flansch−Enden
Abbildung 5.5: Der Flansch wird in zwei Teile getrennt, um seine Enden zu bestimmen.
Die Lösung, die hierfür erarbeitet wurde, sieht folgendermaßen aus: Man teile den
Flansch an der Stelle des Startelements in zwei Abschnitte, und suche für jeden Abschnitt
das entfernteste Element. Daraus ergeben sich zwei Teilpfade, die zu einem Gesamtpfad
zusammengefügt werden (Abb. 5.5).
Die Teilung des Flansches erfolgt hierbei durch einen Streifen von Elementen quer zur
Flanschrichtung, welcher das Startelement enthält. Dabei wird das Verfahren verwendet,
welches schon bei Szenario 1 für die Bestimmung der nächsten Ränder (für die Mittellinie)
eingesetzt wurde. Es werden also in die vier durch die Elementkanten gegebenen Richtungen
die Flanschränder gesucht. Auch hier wird vorausgesetzt, dass weder das Startelement, noch
ein Element des Querstreifens ein Dreieck ist. Nur gelegentlich ist diese Voraussetzung nicht
erfüllt. Dann wird der Benutzer aufgefordert, an eine andere Stelle des Flansches zu klicken.
Die Elemente des Querstreifens werden als besucht markiert. Somit werden sie nicht
in die Suche einbezogen und es ist gewährleistet, dass die Suche nicht in den anderen
Abschnitt übergreift. Als sekundäre Startelemente für die beiden Suchen in den Teilflanschen werden diejenigen zwei Nachbarelemente (von insgesamt vier Nachbarelementen) des
ursprünglichen Flanschelements verwendet, welche nicht zum Querstreifen gehören.
Das automatische Verbinden von ringförmig geschlossenen Flanschen ist ebenfalls
möglich. In Abbildung 5.6 ist ein solches Beispiel dargestellt. Hier verschmelzen die beiden
Suchregionen zu einer einzigen. Die erste Suche liefert hier schon das gewünschte Ergebnis,
weil der gefundene Pfad zum entferntesten Element rundherum verläuft. Da nach der ersten
Suche alle Elemente als besucht markiert sind, wird die zweite Suche, die normalerweise
der zweiten Region gilt, sofort beendet.
Ähnlich verhält es sich, wenn das Startelement, auf das der Benutzer geklickt hat, am
5.4 Szenario 3
73
Abbildung 5.6: Anwendungsbeispiel für Szenario 2
Ende des Flansches liegt. Auch hier beschränkt sich die Suche auf eine Region, das andere
Flanschende ist bereits durch das Startelement gegeben.
In allen anderen Fällen gibt es zwei Suchregionen, und damit zwei Teilpfade. Diese
Teilpfade bilden zusammen mit dem Startelement einen Gesamtpfad, welcher die gesamte
Länge des Flansches abdeckt.
Das weitere Vorgehen ist dann gleich wie bei Szenario 1. Von jedem Pfadelement aus
werden die nächsten Längsränder des Flansches gesucht, damit wird die Mittellinie bestimmt und darauf werden die Schweißpunkte äquidistant positioniert.
In seltenen Fällen könnte es vorkommen, dass ein Flansch sich teilt und damit mehr
als zwei Enden hat. Auch in diesem Fall wird der Flansch beim Startelement in zwei
Regionen geteilt. Gefunden wird jeweils das vom Startelement am weitesten entfernte Ende
jeder Region. Damit erstreckt sich die Schweißpunktlinie entlang der längsten Zweige jeder
Region. Die kürzeren Zweige bleiben unverschweißt. Ein weiterer Klick auf die kürzeren
Zweige reicht jedoch aus, um diese ebenfalls zu bearbeiten.
5.4
Szenario 3
In diesem Szenario werden Flansche nicht durch den Benutzer angeklickt. Stattdessen werden alle oder eine Teilmenge der Bauteile des Modells miteinander an sämtlichen Flanschen
verbunden. Dies ist besonders in der frühen Entwicklungsphase sinnvoll, wenn die Verbindungsinformationen noch nicht verfügbar sind.
74
Abbildung 5.7: Anwendungsbeispiel für Szenario 3: Vollautomatisches Verbinden sämtlicher
Bauteile durch Schweißpunktlinien.
In Abbildung 5.7 ist ein Beispielergebnis für dieses Szenario zu sehen. Aus Gründen der
Übersichtlichkeit sind hier nur vier Bauteile dargestellt.
Da in diesem Szenario kein ausgewiesenes Startelement existiert, werden sämtliche Elemente aller zu verbindenden Bauteile auf ihre Flanscheigenschaft hin untersucht. Wird ein
Flanschelement gefunden, wird der Rest des zugehörigen Flansches wie in Szenario 2 detektiert. Die Elemente der bereits erkannten Flansche werden im Zuge der Suche markiert
und scheiden damit als Startelemente für weitere Flansche aus.
Ob ein Element zu einem Flansch gehört, wird in diesem Szenario allerdings etwas genauer überprüft. Die Bedingungen betreffend Normalenabweichung und Abstand, welche
bei Szenario 1 und 2 elementweise getestet wurden, sind hier in einigen Fällen nicht ausreichend. Diese Bedingungen würden nämlich auch von mehreren Elementen des mit dem
Flansch zu verbindenden Bauteils erfüllt.
Bei Szenario 1 und 2 wurde durch den Benutzer festgelegt, welches Bauteil den Flansch
enthält und welches damit verbunden wird. In Szenario 3 muss algorithmisch festgestellt
werden, auf welchem der beiden Bauteile der Flansch zu suchen ist.
Für dieses dritte Testkriterium des Flanschelements wird die Tatsache ausgenutzt, dass
das Finite-Elemente-Gitter in der Regel an den Flanschrändern ausgerichtet ist. Deshalb
wird von jedem potentiellen viereckigen Flanschelement aus wie bei Szenario 1 und 2 eine
Suche nach den nächsten Rändern ausgeführt. Ist das Gitter nicht an den Flanschrändern
ausgerichtet, sind beide an den Elementkanten ausgerichtete Pfade kürzer als die maximal
anzunehmende Flanschbreite (Abb. 5.8). Dies ist ein Indiz dafür, dass sich das betreffende
Element nicht auf dem Flansch, sondern auf dem gegenüberliegenden Bauteil befindet.
Tatsächlich kann es auch auf Flanschen Elemente geben, bei denen die Identifizierung
der Ränder und damit der Längsrichtung fehlschlägt (Abb. 5.9). Das bedeutet, dass dieses
75
Flansch
B zu
au
te ver
il b
oh in
ne de
Fl nde
an s
sc
h
5.4 Szenario 3
Abbildung 5.8: Bestimmung des Flansch-Bauteils durch Ermittlung naheliegender Ränder
Legende:
untersuchtes
Element
Querpfad
Längspfad
ungeeignete
Elemente
Abbildung 5.9: Prüfung des Gitterverlaufs in Bezug auf potentiellen Flansch. Einige Elemente sind ungeeignet für den Test, im Prizip genügt aber bereits ein einziges geeignetes
Element.
dritte Flanschkriterium bei einigen Elementen nicht erfüllt ist, obwohl sie zum Flansch
gehören. Es reicht hier jedoch aus, wenn das Kriterium schon für ein einziges Element
erfüllt ist. Dies Element kann dann als Startelement verwendet werden, um durch Nachbarschaftssuche den restlichen Flansch zu erkennen.
Wird bei einem Bauteil A ein Flansch erkannt und mit einem Bauteil B verbunden, so
kann es dennoch passieren, dass bei Bauteil B an der bereits verbundenen Stelle ebenfalls
ein Flansch erkannt wird. Schließlich können auch zwei Flansche miteinander verbunden
76
werden. Da der Flansch aber bereits als besucht markiert und verschweißt ist, werden
keine neuen Schweißpunkte erzeugt. An Stellen, wo ein angegebener Mindestabstand zu
vorhandenen Schweißpunkten unterschritten ist, werden in keinem Fall neue Schweißpunkte
gesetzt.
5.5
Zeitverhalten
Der Rechenaufwand bei der automatischen Definition von Schweißpunktlinien ist im Wesentlichen linear abhängig von der Anzahl der zu bearbeitenden Elemente. Bei Szenario 1
und 2 wird jeweils nur ein Flansch pro Benutzerinteraktion bearbeitet. Da die Anzahl der
Elemente eines Flansches sich in übersichtlichem Rahmen bewegt (Größenordnung 100,
Obergrenze etwa 1000 Elemente), liegt die Antwortzeit auf den heute üblichen Arbeitsplatzrechnern unterhalb der vom Benutzer wahrnehmbaren Zeit von einer Zehntelsekunde.
Und von dieser Zeit wird, außer bei sehr kleinen Datensätzen, der Großteil für die Aktualisierung des Bildes durch Neurendern der Szene benötigt.
Bei Szenario 3 müssen sämtliche Bauteile und deren Elemente betrachtet werden. Daher kann die Antwortzeit bei der Verschweißung kompletter Modelle im Minutenbereich
liegen, und das obwohl die Bounding Volume Hierarchie für die Bestimmung der jeweils
nächsten Elemente und Bauteile verwendet wird. In Anbetracht der Tatsache, dass für
eine komplette Rohkarosserie über 6000 Schweißpunkte gesetzt werden, ist das jedoch eine
durchaus akzeptable Zeit.
Auf der mid-range Workstation SGI Octane2 mit 400 MHz R12k Prozessor dauerte die
komplette Verschweißung einer Rohkarosserie 45 Sekunden. Dabei wurden 248 694 finite
Elemente in 285 Bauteilen untersucht, und 6829 Schweißpunkte wurden in Abständen um
50mm gesetzt.
Kapitel 6
Veränderung von Bauteilen mittels
Free-Form Deformation
6.1
Motivation
Verformungen von Bauteilen des Finite-Elemente-Modells sind einerseits notwendig, um
Inkonsistenzen wie Penetrationen, Perforationen und Lücken zu beseitigen. Andererseits
dienen Deformationen dazu, schnell und einfach neue Bauteilgeometrien zu erhalten, um
das Crash-Verhalten zu optimieren (vgl. 2.1).
Insbesondere in der frühen Entwicklungsphase eines neuen Fahrzeugs stehen außerdem
noch nicht alle Bauteile als CAD-Daten zur Verfügung. Um in dieser frühen Phase bereits
FE-Simulationen durchführen zu können, werden FE-Bauteildaten des Vorgängermodells
an die bereits vorhandenen Daten des neuen Modells angepasst, so dass ein berechenbares
Gesamtmodell entsteht.
Um einen effizienten Arbeitsablauf zu gewährleisten und so die Entwicklungszeiten
zu verkürzen, soll der Berechnungsingenieur, der die Simulation durchführt, verschiedene
Anpassungen des FE-Modells selbst durchführen können. Der zeitaufwändige Zyklus über
den zuständigen Konstrukteur, um die CAD-Daten entsprechend zu verändern und das
Bauteil neu zu vernetzen, entfällt damit.
Eine Gruppe von Modifikation der FE-Modelle, die Behebung von Penetrationen und
Perforationen durch automatische Bauteilumformungen, ist in Kapitel 3 beschrieben. Insbesondere bei Perforationen ist eine vollautomatische Behandlung jedoch nicht immer
möglich. Auch für dieses Problem stellt die flexiblere Modifikation des FE-Modells eine
Lösung dar.
Die flexibelste Modifikation eines als FE-Netz dargestellten Bauteils ist das freie Verschieben einzelner Netzknoten. Oft sollen jedoch größere Regionen bearbeitet werden. In
78
Veränderung von Bauteilen mittels Free-Form Deformation
vielen Fällen ist dabei ein möglichst fließender (stetiger) Übergang zwischen deformierter und nicht deformierter Region gewünscht. Die einzelnen Knoten werden in der Regel
um geringe Beträge verschoben. Dennoch ist es für den Benutzer mühsam, eine größere
Anzahl von Knoten exakt zu positionieren. Hierfür wurde in dieser Arbeit ein Verfahren
eingesetzt, das Modifikationen auf beliebig großen Regionen mit geringem Benutzeraufwand durchführen kann. Dazu wurde das sogenannte Free-Form-Deformation Verfahren
weiterentwickelt und an die speziellen Bedürfnisse der FE-Modellierung angepasst.
6.2
Grundlagen der Free-Form-Deformation
Free-Form-Deformation (FFD) stellt ein generelleres geometrisches Verfahren zur Simulation von Deformationsvorgängen an Festkörpern dar [94]. Im Gegensatz zum achsbasierten
Ansatz von Barr [6] stellt die von Sederberg und Parry entwickelte FFD-Methode [76] ein
raumbasiertes Verfahren dar, mit dem polygonale oder durch Kontrollpunkte beschreibbare
geometrische 3D-Modelle in Analogie zu Freiformflächen deformiert werden können.
Die Grundidee der FFD ist es, zu deformierende, flexible Objekte vollständig mit einem geometrisch einfach zu beschreibenden Volumen zu umhüllen, in dem jeder ObjektKnotenpunkt eine eindeutige, parametrisch bestimmbare Position besitzt. Nach der Deformation des umgebenden Volumens kann über die Kenntnis der Deformationsparameter
sowie der initialen Parametrisierung der Objekt-Knotenpunkte auf deren neue Position im
Raum geschlossen werden. Anstelle der direkten Verformung von Objekten erfolgt also eine
Verformung des Raumes, der diese Objekte umgibt (Abb. 6.1).
Abbildung 6.1: Verformung eines Zylinders durch Free-Form Deformation
Der von Sederberg und Parry vorgeschlagene Hüllkörper wird in allgemeiner Form durch
ein Spat repräsentiert, wobei zur Vereinfachung stets ein Quader, als Spezialfall des Spats,
6.2 Grundlagen der Free-Form-Deformation
79
verwendet wird. Durch diesen Quader lässt sich ein lokales kartesisches Koordinatensystem
definieren, dessen Ursprung in einem Eckpunkt liegt und dessen Koordinatenachsen durch
die anliegenden Quaderkanten gegeben sind. Das Quadervolumen bildet den Deformationsbereich als FFD-Block (auch FFD-Volumen genannt), über den sich Objektpunktkoordinaten leicht in lokale Koordinaten überführen lassen.
Ein FFD-Block zeichnet sich dadurch aus, dass er wiederum in einzelne Teilvolumen
gegliedert ist, wobei diese zusätzliche Unterteilung die lokalen Ausmaße der Deformation bzgl. der im FFD-Block befindlichen Objekte vorgibt. Aus dieser Unterteilung ergibt
sich, als wesentliche Komponente der Free-Form Deformation, eine initiale Gitterstruktur
(lattice) mit einfacher Topologie.
Ein kartesisches FFD-Gitter besteht aus sechsseitigen Gitterzellen, wobei jede Seite
durch eine rechteckige Gitterfläche mit vier Gitterkanten und vier Gitterknoten beschrieben
wird und jeder Gitterknoten maximal mit sechs Nachbarknoten verbunden ist. Je enger
die Knoten beieinander liegen, desto genauer kann eine Deformation modelliert werden.
Betrachtet man ein 3D Koordinatensystem mit dem Ursprung X0 und den drei durch
~ T~ , U
~ gegebenen Achsen, so beschreibt dieses Koordinatensystem ein
ihre Basisvektoren S,
Volumen, das sich aus l × m × n Gitterzellen zusammensetzt. Die lokalen Koordinaten
s, t, u eines Objekt-Knotenpunktes P in diesem Koordinatensystem ergeben sich durch
~ + tT~ + uU
~ wobei 0 ≤ s, t, u ≤ 1
P = X 0 + sS
(6.1)
mittels dreier linearer Gleichungen:
s=
t=
u=
~ )(P − X0 )
(T~ × U
~ )S
~
(T~ × U
~ ×U
~ )(P − X0 )
(S
~ ×U
~ )T~
(S
(6.2)
~ × T~ )(P − X0 )
(S
~ × T~ )U
~
(S
Der eigentliche Deformationsansatz von Sederberg und Parry basiert auf den geometrischen
Zusammenhängen von Splinekurven bzw. deren Erweiterung auf den dreidimensionalen
Raum [19]. Als Basisfunktionen dienen dabei Bernsteinpolynome n-ten Grades
µ ¶
n i
s (1 − s)n−i = s Bi−1,n−1 + (1 − s)Bi,n−1
(6.3)
Bi,n (s) =
i
mit 0 ≤ s ≤ 1 und i ∈ {0, ..., n}. Diese Polynome besitzen die Eigenschaft, dass sie immer
zwischen den Werten 0 und 1 liegen und ihre Summe über alle n stets 1 ergibt:
0 ≤ Bi,n (s) ≤ 1
n
X
Bi,n (s) = 1
i=0
(6.4)
(6.5)
80
Die darauf aufbauenden, nach ihrem Erfinder benannten Bézier-Splines wurden bereits
in den 1960-er Jahren in der Automobilindustrie angewendet, um Kurven und Flächen
mathematisch zu beschreiben. Heute sind diese und andere Arten von Splines aus dem
Computer Aided Design nicht mehr wegzudenken. Der Begriff Spline stammt ursprünglich
aus dem Schiffsbau, wo mit elastischen Stäben aus Holz, Metall oder Kunststoff, Splines
genannt, der Schiffsrumpf modelliert wurde.
Zur Bestimmung der Lage eines Punktes P auf einer Bézierkurve vom Grad n sind n+1
Bernsteinpolynome Bi,n und Kontrollpunkte Ki (0 ≤ i ≤ n) erforderlich:
P (s) =
n
X
Bi,n (s)Ki
(6.6)
i=0
Die Kontrollpunkte sind, je nach Anwendung, meist Punkte in 2 oder in 3 . Die
resultierende Kurve ist dann, entsprechend den Kontrollpunkten, zwei- oder dreidimensional. Die Stetigkeit einer allgemeinen Bézier-Kurve vom Grad n ist C n−1 . Für die meisten
praktischen Anwendungen, wie auch bei der FFD, wird daher der Spline-Grad n = 3 angenommen, oft reicht auch ein Grad von n = 2. Abbildung 6.2 zeigt zwei Bézier-Kurven
und Bernsteinpolynome unterschiedlichen Grades.
Bernstein-Bézier-Splines 2. Grades
Bernstein-Bézier-Splines 3. Grades
Basisfunktionen:
Bernstein-Polynome
1
0.25
0.5
0.75
Basisfunktionen:
Bernstein-Polynome
1
1
0.25
Bézier-Kurve und Kontrollpunkte
3
0.5
0.75
1
Bézier-Kurve und Kontrollpunkte
3
4
4
Abbildung 6.2: Beispiele von Bézier Kurven und deren Basisfunktionen
Durch einen Tensorproduktansatz erhält man den Ausdruck für die Punkte einer sogenannten Bézierfläche:
P (s, t) =
n X
m
X
i=0 j=0
Bi,n (s)Bj,m (t)Ki,j mit 0 ≤ s, t ≤ 1
(6.7)
81
Bezierflächen mit dreidimensionalen Kontrollpunkten können beispielsweise für die Beschreibung von räumlichen Objekten verwendet werden. Mit zweidimensionalen Kontrollpunkten werden diese und andere Splines zum “Warping“ von Pixelbildern [92] verwendet
(Abb. 6.3). Dies stellt eine Art zweidimensionale Variante des FFD-Verfahrens dar.
Abbildung 6.3: 2D-Prinzip der FFD: Deformation des Raumes mit Verschiebung der darin
enthaltenen (Objekt-)Punkte
Sederberg und Parry nutzten diesen Zusammenhang zur Beschreibung von Punkten im
3D-Raum mittels trivariater Béziervolumen. Die Position eines Punktes P ergibt sich aus
der Summe der Tensorprodukte dreier Bernsteinpolynome und den zugehörigen Kontrollpunkten, die durch ihre kartesischen Koordinaten gegeben sind.
P (s, t, u) =
l
m X
n X
X
i=0 j=0 k=0
Bi,n (s)Bj,m (t)Bk,l (u)Ki,j,k mit 0 ≤ s, t, u ≤ 1
(6.8)
Das Produkt Bi,n (s)Bj,m (t)Bk,l (u) wird kurz als Bi,j,k (s, t, u) geschrieben:
n,m,l
P (s, t, u) =
X
Bi,j,k (s, t, u)Ki,j,k
(6.9)
i,j,k=0
oder in Matrix-Schreibweise:
P = BK
(6.10)
mit der Matrix der Basisfunktionen B und der Kontrollpunktmatrix K.
Um ein Objekt durch FFD zu verformen, müssen für jeden Vertex bzw. für jeden
relevanten Punkt P des Objekts dessen Spline-Parameter s, t und u bestimmt werden.
Aufgrund der regelmäßigen Anordnung der Kontrollpunkte in einem kartesischen Gitter ist
82
die Bestimmung der Spline-Parameter einfach, solange Bézier-Splinefunktionen verwendet
werden. Bézier-Splines besitzen nämlich die Eigenschaft der linearen Präzision (vgl. [19]):
n
X
i
Bi,n (s) = s
n
i=0
(6.11)
Mit anderen Worten: Sind die Kontrollpunkte äquidistant auf einer Geraden angeordnet,
so läuft P (s) linear mit s die Kurve entlang (Abb. 6.4). Für das FFD-Verfahren hat dies
Spline-Kurve mit linearer Präzision
Spline-Kurve ohne lineare Präzision
Abbildung 6.4: Lineare Präzision (Beispiel): Die farbigen Segmente sind Bilder gleichlanger
Intervalle des Parameterbereiches.
die Bedeutung, dass die Spline-Parameter s, t und u eines Punktes P im Bézier-Volumen
sich durch lineare Interpolation bestimmen lassen (vgl. Beziehung (6.3)).
0
Werden einige Kontrollpunkte Ki,j,k durch den Benutzer an neue Positionen Ki,j,k
verschoben, ergibt sich für einen Punkt P des eingebetteten Objekts eine Verschiebung zu der
neuen Position P 0 :
n,m,l
0
P (s, t, u) =
X
n,m,l
0
Bi,j,k (s, t, u)Ki,j,k
i,j,k=0
= P (s, t, u) +
=
X
Bi,j,k (s, t, u)(Ki,j,k + ∆Ki,j,k )
i,j,k=0
n,m,l
X
Bi,j,k (s, t, u)∆Ki,j,k
(6.12)
i,j,k=0
Aus Beziehung (6.12) folgt, dass es für die Berechnung einer Verformung ausreichend ist,
diejenigen Spline-Basisfunktionen Bi,j,k zu berechnen, für die ∆Ki,j,k 6= ~0 gilt. Basisfunktionen Bi,j,k (s, t, u) müssen also nur dann ausgewertet werden, wenn der entsprechende
Kontrollpunkt Ki,j,k bewegt wird.
Zusammenfassend kann das Verfahren der Free-Form Deformation in folgende Schritte
gegliedert werden:
1. Überlagerung einer regelmäßigen 3D Gitterstruktur in Form eines lokalen kartesischen Koordinatensystems über einen spat- bzw. quaderförmigen Ausschnitt des 3DRaumes, in dem sich das zu deformierende Objekt vollständig befindet.
83
2. Überführung der Objekt-Knotenpunkt in das lokale Koordinatensystem des FFDGitters.
3. Deformation des FFD-Blocks durch Verschiebung von Kontrollpunkten.
4. Berechnung der neuen Koordinaten für die betroffenen Objektknoten anhand der
Kontrollpunktverschiebungen.
Durch das FFD-Verfahren erschließt sich dem Benutzer eine große Palette von Möglichkeiten zur Bearbeitung dreidimensionaler Objekte. Speziell im Automobilbau, wo Splines
eine lange Tradition haben, ist es naheliegend, auch Finite-Elemete-Modelle mit der Splinebasierten FFD-Methode zu bearbeiten.
Mit dem FFD-Verfahren kann Spline-basierte Modellierung durchgeführt werden, selbst
wenn das modellierte Objekt nicht mit Hilfe von Splines beschrieben wird. Im Rahmen
dieser Arbeit wurden somit die Vorteile von Spline-Funktionen, wie z.B. deren Stetigkeit,
erstmals bei der Bearbeitung von FE-Datensätzen angewendet.
Das ursprüngliche FFD Verfahren nach Sederberg und Parry hat allerdings einige Nachteile:
1. Die große Anzahl von Kontrollpunkten ist schwer zu überschauen und verdeckt die
Sicht auf das eigentliche Objekt, das es zu editieren gilt.
2. Oft liegen einige Kontrollpunkte im Inneren eines zu bearbeitenden Objekts und sind
somit schwer zugänglich.
3. Die Auswirkungen einer Kontrollpunktverschiebung sind schwer nachvollziehbar.
Die für eine vorgegebene Änderung am Objekt notwendigen KontrollpunktManipulationen sind nicht klar ersichtlich.
4. Die verwendeten Bernstein-Bézier-Splinefunktionen besitzen nicht die Eigenschaft der
lokalen Kontrolle. Jede Verschiebung eines Kontrollpunktes kann auf dem gesamten
Objekt (ungewünschte) Veränderungen bewirken.
5. Eine größere Auflösung des Kontroll(punkt)gitters für die Modellierung von Details
erfordert eine Erhöhung des Spline-Polynomgrades (n, m, l) oder eine Aufteilung des
FFD-Volumens in mehrere sogenannte Hyperpatches. Letzteres ist problematisch,
weil spezielle Vorkehrungen zur Bewahrung der Stetigkeit an den Übergängen getroffen werden müssen, denn:
6. Am Rand eines FFD-Blocks ist kein stetiger Übergang zur benachbarten (d.h. von
der Deformation nicht betroffenen) Umgebung gegeben.
7. Am Rand eines FFD-Blocks ist das Deformationsverhalten ein anderes als im Inneren
des FFD-Blocks (Abb. 6.5).
84
8. Es muss immer das gesamte Objekt in das FFD-Volumen eingebettet werden, auch
wenn nur ein Teil davon verändert werden soll. Der Grund liegt in der fehlenden
Stetigkeit an der Oberfläche des FFD-Blocks und in der fehlenden lokalen Kontrolle.
Abbildung 6.5: Beispiel für inkonsistentes Deformationsverhalten bei Bézier-Splines und
dessen Auswirkung auf FFD: Für eine vorgegebene Verschiebung eines Punktes des
schwarz dargestellten Bauteils sind ungleiche Kontrollpunktverschiebungen notwendig, in
Abhängigkeit davon, ob sich das Bauteil in Randnähe befindet oder im Inneren. Darüberhinaus ist die resultierende Form des Bauteils in den beiden Fällen unterschiedlich. Dieses
unterschiedliche Verhalten der FFD in Randnähe ist nicht sinnvoll und für den Benutzer
nicht nachvollziehbar.
Die Probleme 1 bis 5 wurden später durch verwandte Arbeiten (z.B. DMFFD, siehe
Abschnitt 6.4) gelöst. Durch die in der vorliegenden Arbeit vorgestellten Anpassungen des
FFD-Verfahrens wurden die Schwachstellen 6 bis 8 ebenfalls beseitigt. Hierbei spielen BSplines eine wichtige Rolle und sollen deshalb im folgenden Abschnitt etwas näher erläutert
werden.
6.3
Grundlagen der B-Splines
B-Splines wurden erstmals im 19. Jahrhundert verwendet, als N. Lobachevsky einige spezielle B-Splines durch Faltungen von Wahrscheinlichkeitsverteilungen erhielt [67].
I.J.Schoenberg [73] verwendete B-Splines für die Glättung statistischer Daten. Gordon
und Riesenfeld [30, 69] schlugen erstmals die Verwendung von B-Splines im Bereich der
6.3 Grundlagen der B-Splines
85
Computer-basierten geometrischen Modellierung vor. Ein bedeutender Name auf dem Gebiet der B-Splines ist de Boor, der wertvolle Ergebnisse über die Eigenschaften dieser
Funktionen erarbeitete [16, 17, 18].
B-Splines können als eine Verallgemeinerung der Bézier-Splines betrachtet werden. Ist
für einen gegebenen Grad n die Anzahl der Kontrollpunkte gleich n + 1, so ist die B-SplineKurve mit einer Bézier-Kurve identisch. Diese Feststellung gilt allerdings nur, insofern es
sich um B-Splines handelt, bei denen sichergestellt ist, dass die Positionen der beiden
äußeren Kontrollpunkte mit den Endpunkten der Kurve übereinstimmen. Man sagt dann,
dass die Kurve die Endpunkte interpoliert. Diese häufig verwendete Kategorie von B-SplineKurven besitzt entweder n-fache äußere Kontrollpunkte, oder der Knotenvektor weist n + 1
gleiche Knoten an beiden Enden auf.
Der Knotenvektor ist eine nichtfallende Folge von reellen Zahlen (s0 , ..., sh+2n ). h stellt
hier die Anzahl der Spline-Segmente dar. Während Bézier-Kurven immer aus einem Segment bestehen, kann eine B-Spline-Kurve beliebig viele Segmente enthalten. Die Segmente
einer allgemeinen B-Spline-Kurve haben an den Übergängen dieselbe Stetigkeit C n−1 wie
die gesamte Kurve.
Die Form eines Kurvensegments wird dabei von n + 1 Kontrollpunkten bestimmt. Jeder
Kontrollpunkt hat einen lokal begrenzten Einfluss (auf höchstens n + 1 Kurvensegmente).
Ausgehend von den Basisfunktionen 0-ten Grades
(
1 falls si ≤ s < si+1 ,
Ni,0 (s) =
0 sonst
(6.13)
werden die Basisfunktionen n-ten Grades rekursiv definiert:
Ni,n (s) =
si+n+1 − s
s − si
Ni,n−1 (s) +
Ni+1,n−1 (s)
si+n − si
si+n+1 − si+1
(6.14)
mit i ∈ {0, ..., p}, p = h + n − 1. Man bemerkt, dass Basisfunktionen niedrigeren Grades
Ni,n−1 zur Berechnung zweier Basisfunktionen nächsthöheren Grades Ni−1,n und Ni,n verwendet werden. Zur effizienten Berechnung der Basisfunktionen nach (6.14) empfiehlt sich
daher ein Aufbewahren der Zwischenergebnisse.
Mit den h + n = p + 1 Basisfunktionen Ni,n und ebensovielen Kontrollpunkten Ki wird
ein Punkt P der B-Spline-Kurve ähnlich wie bei Bézier-Kurven bestimmt:
P (s) =
p
X
Ni,n (s)Ki
(6.15)
i=0
Der Spline-Parameter s läuft hierbei, anders als bei Bézier-Kurven, zwischen den Werten sn und sn+h des Knotenvektors. Es gilt
Ni,n (s) 6= 0 ⇔ s ∈ (si , si+n )
(6.16)
86
Grad 2, 4 Segmente, nicht-uniform
1
Grad 3, 4 Segmente, nicht-uniform
1
Basisfunktionen
1
2
3
Basisfunktionen
4
1
Knotenvektor mit 3-fachen Endknoten
3
2
3
4
Knotenvektor mit 4-fachen Endknoten
3
4
B-Spline-Kurve und Kontrollpunkte
4
Abbildung 6.6: B-Splines über einem Knotenvektor mit n+1-fachen Endknoten
Grad 2, 4 Segmente, uniform
1
-2
Basisfunktionen
1
-1
2
3
4
5
6
Uniformer Knotenvektor
Grad 3, 4 Segmente, uniform
1
-3
-2
-1
Basisfunktionen
1
2
3
4
5
6
7
Uniformer Knotenvektor
Abbildung 6.7: B-Splines über einem uniformen Knotenvektor
6.4 Verwandte Arbeiten
87
Für ein s ∈ (si+n , si+n+1 ) müssen zur Berechnung des entsprechenden Kurvenpunktes
P (s) bloß die n + 1 Basisfunktionen Ni bis Ni+n berechnet werden. Die restlichen Basisfunktionen sind gleich Null für s ∈ (si+n , si+n+1 ), und brauchen also nicht berechnet zu
werden. Daraus folgt, dass allein die Positionen der n + 1 Kontrollpunkte Ki bis Ki+n für
die Position von P (s) von Bedeutung sind, womit die Eigenschaft der lokalen Kontrolle
nachgewiesen ist. Liegt der Kurvenpunkt P (s) genau an einer Segment-Grenze, d.h. s = s i
mit i ∈ {n, h + n}, ist seine Lage sogar von nur n Kontrollpunkten abhängig.
Abbildung 6.6 zeigt Beispiele von B-Spline-Kurven, bei deren Knotenvektoren die äußeren n+1 Knoten zusammenfallen. Abbildung 6.7 zeigt im Gegensatz dazu B-Spline-Kurven,
die auf einem Knotenvektor mit gleichmäßig verteilten Knoten definiert sind. Hier stimmen die Enden der B-Spline-Kurve, anders als beim ersten Beispiel, nicht mit den äußeren
Kontrollpunkten überein.
6.4
Verwandte Arbeiten
Das FFD-Verfahren hat einen weiten Einsatzbereich, da es die Bearbeitung von Objekten
weitgehend unabhängig von deren interner Repräsentation erlaubt. Daher wurde dieses
Verfahren von zahlreichen Forschern aufgegriffen und verbessert.
Die sogenannte Extended Free-Form Deformation (EFFD) von Coquillart [15] erlaubt
durch die Verwendung unterschiedlich geformter (z.B. prismatischer oder zylindrischer)
Gitterzellen eine größere Vielfalt bei der Wahl der Gittertopologien des FFD-Bereiches.
Das EFFD-Verfahren lässt sich an beabsichtigte Deformationen anpassen, wobei es gegenüber der herkömmlichen FFD-Methode allerdings etwas an Flexibilität und Stabilität
verliert [94].
MacCracken und Joy [56] erweitern das Verfahren auf Gitter beliebiger Topologie. Dabei
wird eine an die Catmull-Clark Unterteilung angelehnte Technik zum Verfeinern des Gitters
verwendet.
Sowohl bei der FFD-Methode als auch bei der EFFD-Methode gestaltet sich die gezielte Deformation eines Objektes durch die vielen Kontrollpunkte recht schwierig. Für eine
intuitive Deformation eignen sich diese Verfahren somit schlecht.
Eine Erweiterung der FFD durch Hsu et al. [38] erlaubt die direkte Manipulation von
Objekten (Direct Manipulation of FFD, DMFFD). Das DMFFD-Verfahren hat den entscheidenden Vorteil, dass der Benutzer das Spline-Kontrollgitter nicht bearbeiten, und
auch nicht sehen muss. Er hat eine wesentlich direktere und intuitivere Kontrolle über das
bearbeitete Objekt.
Ein oder mehrere Objektpunkte können bei dem DMFFD-Verfahren mit Hilfe einer
geeigneten Benutzerschnittstelle selektiert und an die gewünschte Position verschoben wer-
88
den1 . Die notwendige Bestimmung des Kontrollpunktversatzes erfolgt ausgehend von den
neuen Positionen der Objektpunkte durch Lösen eines linearen Gleichungssystems.
Je nach Anzahl der constraints, also der festgelegten Randbedingungen in Form von
Punktverschiebungen, kann das Gleichungssystem unter- oder überbestimmt sein. Dann
wird die beste Lösung (im Sinne von kleinsten quadratischen Abweichungen) durch Ermitteln einer pseudoinversen Matrix [89] ermittelt. Im unterbestimmten Fall gilt es, die
kleinstmöglichen Verschiebungen der Kontrollpunkte zu ermitteln. Bei einem überbestimmten System, also wenn es eine große Zahl von Randbedingungen gibt, können die Randbedingungen nicht genau eingehalten werden. Dann wird die Kontrollpunkt-Konfiguration
ermittelt, bei der die quadratischen Abweichungen von der Zielvorgabe insgesamt am kleinsten sind.
Hsu et al. verwenden B-Splines [66] anstelle von Bézier-Splines. Anders als bei der Verwendung von Bézier-Splines ist bei B-Splines die Anzahl der Kontrollpunkte nicht an den
Grad der Spline-Funktionen gebunden. So kann das FFD-Gitter verfeinert werden, ohne
den Spline-Grad zu erhöhen. Jeder Kontrollpunkt beeinflusst nur einen genau festgelegten
Bereich. Somit ist die Eigenschaft der lokalen Kontrolle gegeben (vgl. Abschnitt 6.3).
Die von Hsu et al. verwendeten B-Splines haben jedoch, wie bei den meisten Arbeiten
in diesem Bereich, sogenannte mehrfache Kontrollpunkte an den Rändern. Wie bei der
Verwendung von Bézier-Splines liegen dadurch die äußeren Kontrollpunkte auf der Hülle
des FFD-Blocks. Das Deformationsverhalten ist damit ebenfalls uneinheitlich, weil ortsabhängig, und es gibt keinen stetigen Übergang zur Umgebung des FFD-Blocks. Auch aus
diesem Grund wird bei Hsu et al., wie bei den anderen verwandten Arbeiten, ein FFDVolumen verwendet, welches das gesamte Objekt umschließt.
B-Splines mit mehrfachen Kontrollpunkten besitzen im Allgemeinen nicht die Eigenschaft der linearen Präzision (vgl. Beziehung (6.11) in Abschnitt 6.2). Deshalb muss für
jeden verschobenen Objektpunkt eine Gleichung dritten Grades (bzw. vom Grad n der
Spline-Basisfunktionen) gelöst werden, um die Spline-Parameter (s, t, u) des Punktes zu
bestimmen.
In [20] wird ein Verfahren beschrieben, das die lineare Präzision von B-Splines erzielt,
indem die Kontrollpunkte gewichtet werden. Speziell bei n-fachen Kontrollpunkten wären
jedoch unendlich große Gewichte nötig. Außerdem würden die Gewichte zu einem uneinheitlichen Verhalten der Deformation beitragen.
Hu et al. [39] ermitteln mit Hilfe der Lagrange Funktion explizite Ausdrücke für die Verschiebung der Kontrollpunkte, so dass die Lösung eines Gleichungssystems durch Berechnen
der Pseudoinversen Matrix entfällt. Außerdem werden in [39] einige nützliche Eigenschaften der DMFFD bewiesen. Insbesondere wird gezeigt, dass jede mehrfache Randbedingung
1
Die selektierten Punkte müssen nicht mit den Knoten (Vertices) der Objektdarstellung übereinstimmen. Prinzipiell ist es für DMFFD auch nicht erforderlich, dass die angegebenen Punkte auf der Objektoberfläche liegen. Für den Benutzer ist es jedoch einfacher und intuitiver, Punkte auf der Objektoberfläche
anzugeben.
6.4 Verwandte Arbeiten
89
(multiple point constraint) zu dem gleichen Ergebnis führt wie eine sequentielle Bearbeitung von entsprechend vielen einfachen Randbedingungen (single point constraints). Dieses
Ergebnis wird in der vorliegenden Arbeit aufgegriffen, um die Bedienung durch den Benutzer möglichst einfach zu gestalten.
Gain und Dodgson [27] zerlegen die DMFFD in eine Sequenz von kleinen Deformationen, um die Selbst-Überschneidung des verformten Objekts zu verhindern. Eine SelbstÜberschneidung wäre in der Tat nicht mehr durch FFD zu beheben, wenn das FFDVolumen, das zu der Verformung mit Selbst-Überschneidung geführt hat, nach der Deformation verworfen wird.
Bei der von Gain und Dodgson durchgeführten Zerlegung einer großen Deformation in
eine Reihe von kleineren Teilschritten wird vor jedem dieser Teilschritte ein neues, undeformiertes FFD-Volumen angenommen. Dadurch werden Objektoberflächen, die sich nach
einem oder mehreren Teilschritten nahe kommen, in Richtung der Deformation mitverschoben, so dass es zu keiner Überschneidung kommen kann.
Die genaue Bestimmung der Schrittweite ist jedoch sehr rechenintensiv. Daher entwickelten Gain und Dodgson ein Näherungsverfahren, das im Zweifelsfall übervorsichtig
entscheidet. Bei der Methode von Gain und Dodgson ist außerdem das Ergebnis der schrittweisen Deformation nachweislich ein anderes, als bei der normalen Deformation. Das ist
verständlich, wenn man bedenkt, dass im einen Fall eine Überschneidung auftreten kann
und im anderen nicht. Dennoch ist das von einer zur anderen Deformation unterschiedliche
Verhalten für den Benutzer schwer nachzuvollziehen.
Bei der Modellierung von FE-Modellen durch DMFFD, wie sie in der vorliegenden
Arbeit vorgestellt wird, kommt es aufgrund der relativ kleinen Veränderungen, die durchgeführt werden müssen, nicht zu Selbstüberschneidungen. Führt dennoch eine Deformation
zu Überschneidungen, so kann sie rückgängig gemacht werden und durch den Benutzer in
mehreren Schritten ausgeführt werden.
Noble und Clapworthy [62] verwenden ein FFD-Verfahren basierend auf der Veränderung der Gewichte von NURBS (Non-Uniform Rational B-Splines) [66]. Zwar steigen damit
die Einflussmöglichkeiten des Benutzers auf das Ergebnis der Deformation, doch ist auch
hier der Benutzer durch die Fülle von Einflussmöglichkeiten schnell überfordert.
Tong et al. [87] betrachten die ursprünglich ebenen Polygone des zu bearbeitenden Objektes als getrimmte B-Spline Flächen. Bei der Deformation werden dann nicht nur die
Vertices der Objekt-Polygone verschoben, sondern die als Spline-Flächen beschriebenen
Polygone werden selbst deformiert. Die so erhaltenen Flächenbeschreibungen entsprechen
dem Industriestandard STEP. Sie erlauben eine genauere Darstellung des Objekts, und
können durch Tesselierung wieder in ein Polygonnetz umgewandelt werden, das nun an
den gekrümmten Stellen feiner ist. So wird eine bessere Approximierung der gewünschten Deformation erreicht als bei der normalen FFD, wo nur die Positionen der bereits
vorhandenen Objektknoten neu bestimmt werden.
90
Eine spezielle Hardware zur Beschleunigung von Free-Form Deformation stellt Chua
und Neumann in [14] vor. Die Hardware stellt eine 3D-Erweiterung der bereits zum Standard gehörenden 1D- und 2D-Evaluatoren [93] für Splines dar. Allerdings handelt es sich
bei der Arbeit von Chua und Neumann um theoretische Überlegungen, die bislang nicht
in reale Hardware umgesetzt wurden.
Durch die zunehmende Programmierbarkeit der Graphik Hardware ließe sich ein entsprechender 3D-Evaluator allerdings schon mit heutiger Hardware realisieren. Hierfür könnte die in [55] vorgestellte Vertex Engine verwendet werden, die bereits in kommerzieller
Graphik-Hardware verfügbar ist. Der zukünftige OpenGL-Standard 2.0 [1] wird solche
programmierbare Hardware ebenfalls unterstützen.
Eine effiziente Implementierung vorausgesetzt, ist das FFD und das DMFFD Verfahren jedoch auch ohne Spezial-Hardware für die meisten Anwendungen hinreichend schnell.
Bei der im Rahmen dieser Arbeit entwickelten DMFFD-Variante können einige 10000 Objektpunkte gleichzeitig bewegt werden, ohne dass es signifikante Verzögerungen (größer als
0.1s) gibt.
FFD-ähnliche Verfahren wurden ebenfalls in [92] dargestellt. Hier geht es unter anderem
um das Verzerren von Pixel-Bildern, wobei ein zweidimensionales Kontrollpunkt-Gitter und
Catmull-Rom-Splines [12] zum Einsatz kommen.
Anstelle von Pixel-Bilder können auch Voxel-basierte Volumendarstellungen manipuliert werden, wie in [54]. Westermann et al. benutzt hierfür Hardware-Unterstützung in [91],
und Rezk-Salama et al. [68] stellen weitere Performance-Optimierungen vor.
Kobbelt et al. [48, 46, 47, 45] entwickeln ein grundsätzlich verschiedenes Verfahren zur
Deformation von 3D-Objekten. Dabei wird ein Bereich des Objektes markiert und verschoben. Um den verschobenen Bereich herum wird durch den Benutzer eine Region definiert,
welche verändert werden darf, und die durch Energieminimierungsfunktionen (vgl. Abschnitt 3.4) einen stetigen Übergang zwischen dem verschobenen und dem unveränderten
Bereich erzeugt (Abb. 6.8).
Realisiert wurde dieses Verfahren bislang allerdings nur für Objekte, die durch Dreiecksnetze beschrieben sind. Außerdem ist eine hierarchische Repräsentation des Netzes
mit mehreren Auflösungsstufen notwendig, damit Details trotz dem glättenden Effekt der
Energieminimierung erhalten bleiben.
6.5
Explizite Berechnung der Verschiebungen
Für ein dreidimensionales Tensorprodukt mit B-Spline-Graden p, q, r und n × m × l
Kontrollpunkten Ki,j,k stellt sich das FFD-Volumen Q(s, t, u) wie folgt dar:
n,m,l
Q(s, t, u) =
X
i,j,k=0
Ri,j,k (s, t, u)Ki,j,k
(6.17)
6.5 Explizite Berechnung der Verschiebungen
91
Abbildung 6.8: Anwendungsbeispiele von Kobbelts Multi-Resolution-Ansatz aus [48]
mit der vereinfachenden Bezeichnung Ri,j,k (s, t, u) = Ni,p (s)Nj,q (t)Nk,r (u).
Nun soll dieses Volumen so deformiert werden, dass ein Punkt S mit Spline-Parametern
(sS , tS , uS ) an eine neue Position T bewegt wird. Diese single-point-constraint genannte
Aufgabenstellung kommt in der Praxis häufig vor, und kann durch sequentielle Anwendung,
wie Hu et al. [39] gezeigt haben, auch dazu verwendet werden um sogenannte multiple-pointconstraints, also die gleichzeitige Erfüllung mehrerer Startpunkt-Zielpunkt-Bedingungen zu
bewerkstelligen.
Es ist klar, dass der Benutzer durch die manuelle Verschiebung von Kontrollpunkten
eine Verformung nur sehr ungenau durchführen kann. Das DMFFD Verfahren hingegen
erreicht nicht nur eine exakte Neupositionierung ein oder mehrerer gegebener Punkte, sondern führt diese Aufgabe in optimaler, klar definierter Weise aus, nämlich so, dass die
Gesamtverformung minimal ist. Als Maß dient hierbei die Summe der Quadrate aller Kontrollpunktverschiebungen; diese Summe gilt es zu minimieren. Während Hsu et al. [38]
für jede DMFFD Operation ein Gleichungssystem durch Berechnung der Pseudoinversen Matrix lösen, geben Hu et al. [39] hierfür explizite Lösungsausdrücke mit Hilfe des
Lagrange-Optimierungsverfahrens an.
y
x
z
Die gewünschten Kontrollpunktverschiebungen δi,j,k = (δi,j,k
, δi,j,k
, δi,j,k
)T sollen gewähr-
92
leisten, dass
n,m,l
T =
X
n,m,l
(Ki,j,k + δi,j,k )Ri,j,k (sS , tS , uS ) = S +
i,j,k=0
X
δi,j,k Ri,j,k (sS , tS , uS )
(6.18)
i,j,k=0
Für eine Ein-Punkt-Verschiebung ist das Gleichungssystem unterbestimmt, es gibt eine
große Anzahl von Lösungen. Eine denkbare, jedoch nicht sehr nützliche Lösung ist, alle
Kontrollpunkte um den gleichen Vektor (T − S) zu verschieben. Eine andere Lösung wäre,
nur den einen zu S nächstliegenden Kontrollpunkt so zu verschieben, dass der Punkt S an
die Position von T gelangt. Eine sinnvollere Lösung ist jedoch, mehrere P
Kontrollpunkte zu
2
verschieben, und dabei die Summe der Quadrate der Verschiebungen n,m,l
i,j,k=0 kδi,j,k k zu
minimieren.
Die entsprechende Lagrange Funktion L kann wie folgt geschrieben werden:
n,m,l
n,m,l
L=
X
i,j,k=0
kδi,j,k k2 + λ(T − S −
X
δi,j,k Ri,j,k (sS , tS , uS ))
(6.19)
i,j,k=0
mit dem Lagrange-Multiplikator λ = (λx , λy , λz )T . Für das gesuchte Minimum von L gilt
∂L
∂L
∂L
= ∂λ
= ∂λ
= 0, was zu der bereits bekannten Beziehung (6.18) führt. Für das
∂λx
y
z
gesuchte Minimum von L gilt außerdem ∂δ∂L
= ∂δ∂L
= ∂δ∂L
= 0. Durch Lösen dieser
y
x
z
i,j,k
i,j,k
i,j,k
Gleichungen resultiert
λ
(6.20)
δi,j,k = Ri,j,k (sS , tS , uS )
2
Mit Hilfe von (6.18) erhält man
Pn,m,l
T −S
2
i,j,k=0 Ri,j,k (sS , tS , uS )
=
λ
δi,j,k
=
2
Ri,j,k (sS , tS , uS )
(6.21)
Daraus ergibt sich der gesuchte explizite Ausdruck für die Verschiebungsvektoren der Kontrollpunkte
Ri,j,k (sS , tS , uS )
(T − S)
δi,j,k = Pn,m,l
2
R
(s
,
t
,
u
)
S
S
S
i,j,k=0 i,j,k
(6.22)
Damit lässt sich die Verschiebung der Kontrollpunkte einfach und effizient berechnen.
Abbildung 6.9 zeigt beispielhaft eine Ein-Punkt-Deformation mit B-Splines 4. Grades.
Betrachtet man den Ausdruck (6.22) genauer, so bemerkt man folgendes:
• maximal (p + 1) × (q + 1) × (r + 1) Terme δi,j,k sind ungleich ~0. (p, q, r := Splinegrade)
• nur (maximal (p + 1) × (q + 1) × (r + 1)) Kontrollpunkte in einer Umgebung des
Startpunktes S werden verschoben
6.5 Explizite Berechnung der Verschiebungen
93
Abbildung 6.9: Beispiel für die Verschiebung der Kontrollpunkte und die Verformung des
Raumes durch DMFFD. Das Kontrollgitter ist hier durch weiße Linien dargestellt, Startbzw. Zielpunkt sowie die Verschiebungsrichtung werden durch den 3D-Zeiger angezeigt.
• die Verschiebung eines Kontrollpunktes ist größer, wenn sich der Kontrollpunkt näher
am Startpunkt S befindet
• die Richtung aller Kontrollpunkt-Verschiebungen entspricht immer der Richtung des
Vektors (T − S)
Durch die Verschiebung der Kontrollpunkte wird, wie bereits erwähnt, nicht nur der
Startpunkt S an die Position T gebracht. Die Punkte P des im FFD-Volumen eingebetteten Objekts werden, sofern sie in einer bestimmten Umgebung von S liegen, ebenfalls
verschoben. So entsteht ein stetiger Übergang zwischen der verformten Region um den
Startpunkt S und dem von S weiter entfernt liegenden und nicht verformten Bereich des
Objekts.
Für einen Objektpunkt P mit Spline-Koordinaten (sP , tP , uP ) wird die neue Position
P daher wie folgt berechnet:
0
n,m,l
P
0
= P+
X
Ri,j,k (sP , tP , uP )δi,j,k
i,j,k=0
= P+
Pn,m,l
i,j,k=0
Ri,j,k (sP , tP , uP )Ri,j,k (sS , tS , uS )
(T − S)
Pn,m,l
2
i,j,k=0 Ri,j,k (sS , tS , uS )
(6.23)
Dabei brauchen nur diejenigen Terme der Summe im Zähler berücksichtigt zu werden, für welche Ri,j,k (sP , tP , uP ) 6= 0 und Ri,j,k (sS , tS , uS ) 6= 0. Da bekannt ist, welche der
94
V
Legende:
Startpunkt
verschobener Kontrollpunkt
V
Objektknoten (Vertex)
Kontrollpunkte mit Einfluss auf V
verschobene Kp. mit Einfluss auf V
Region beeinflusst durch die
selben Kontrollpunkte
Abbildung 6.10: Relevante Kontrollpunkte bei der DMFFD-Verschiebung eines Objektpunktes (Grad n = 2). Nur die zu den vier Kontrollpunkten ° gehörenden Basisfunktionen müssen bei der Verschiebung eines Objektpunktes neu berechnet werden.
Basisfunktionen Ri,j,k (sS , tS , uS ) gleich Null sind, brauchen die entsprechenden Ausdrücke
Ri,j,k (sP , tP , uP ) nicht berechnet zu werden. Bei der Berechnung von P 0 sind also nur die
Basisfunktionen Ri,j,k (...), von Bedeutung, deren entsprechende Kontrollpunkte Ki,j,k sowohl die Position von S, als auch die Position von P beeinflussen (Abb. 6.10). Je weiter
der Punkt P von S entfernt ist, umso weniger Basisfunktionen müssen berechnet werden,
und umso weniger aufwändig ist somit die Berechnung von dessen neuer Position P 0 .
6.6
Überlegungen zur Bearbeitung von FE-Modellen
mittels DMFFD
Bei der Implementierung des DMFFD Verfahrens zur Deformation von Finite-ElementeModellen spielten folgende Überlegungen eine Rolle:
6.7 Verwendung eines temporären Kontrollgitters
95
1. Finite Elemente dürfen nicht allzu sehr deformiert werden, um die Genauigkeit der
FE-Simulation nicht zu gefährden.
2. Das Deformationsverhalten soll nicht von der Vorgeschichte, also von vorhergehenden
Deformationen abhängen. Auch soll keine zusätzliche Information, etwa das zugehörige Kontrollgitter, dauerhaft gespeichert werden müssen.
3. Das Deformationsverhalten soll unabhängig von der räumlichen Position des Startpunktes sein.
Die Forderung von Punkt 1 ist erfüllt, solange die Deformation, d.h. der Abstand zwischen Startpunkt S und Zielpunkt T , relativ klein ist, beziehungsweise wenn der Einflussbereich, bestimmt durch die Dichte der Kontrollpunkte, hinreichend groß ist, so dass
sich die Deformation auf eine große Anzahl von Elementen verteilt. Da für das Preprocessing zumeist geringfügige Modifikationen ausreichen, ist die Verzerrung von Elementen
kein großes Problem. Falls nötig, kann mit dem Relaxationsalgorithmus aus Abschnitt 3.4
die Verzerrung der Elemente verringert werden.
Für die Zukunft gibt es dennoch Überlegungen, die Neuvernetzung der deformierten
Region durchzuführen, was größere Änderungen des FE-Modells ermöglichen würde. Weiterhin könnte die maximal zulässige Verformung vorab bestimmt werden, um Durchdringungen mit anderen Bauteilen oder eine zu große Elementverzerrung zu verhindern. Dieses
Vorgehen würde besonders in Verbindung mit einem haptischen Eingabegerät von Vorteil
sein.
Die Forderungen 2 und 3 sind nicht FE-spezifisch. Ihre Erfüllung ist deshalb auch in
anderen Anwendungsgebieten von Nutzen, insbesondere da sich bis jetzt keine anderen Arbeiten auf diesem Gebiet damit beschäftigen. In den folgenden Abschnitten werden Anpassungen des DMFFD Verfahrens vorgestellt, welche neben der Erfüllung obiger Forderungen
noch weitere Vorteile mit sich bringen.
6.7
Verwendung eines temporären Kontrollgitters
Bei den in Abschnitt 6.4 erwähnten FFD-verwandten Arbeiten werden Deformationen
sequentiell auf ein und demselben Kontrollgitter vorgenommen. Das Kontrollgitter wird
immer verzerrter und unregelmäßiger. Beim einfachen FFD verliert der Benutzer angesichts
der vielen Kontrollpunkte schnell den Überblick. Bei DMFFD braucht sich der Benutzer
zwar nicht mit dem Kontrollgitter zu beschäftigen, jedoch weist ein FFD-Volumen, dessen
Kontrollpunkte bereits verschoben wurden, ein anderes Verhalten auf als im Falle eines
regelmäßigen, unveränderten Gitters.
Der Grund liegt darin, dass die ursprünglichen Spline-Parameter (sP , tP , uP ) eines Objektpunktes P zusammen mit dem Kontrollgitter beibehalten werden. Es wird also die
96
Position von Objektpunkten geändert, ohne die Spline-Parameter dieser Punkte zu aktualisieren.
Für den Benutzer ist die Änderung im Deformationsverhalten nicht nachvollziehbar. Bei
der Implementierung der hier vorgestellten Ergebnisse wurde deshalb dazu übergegangen,
für jede FFD-Operation ein neues, unverzerrtes Kontrollgitter zu verwenden. Damit ist das
Verhalten der DMFFD vollkommen unabhängig von den vorhergehenden Deformationen.
Es spielt also keine Rolle mehr, ob ein Objekt durch DMFFD in die aktuelle Form gebracht
wurde, oder ob es schon beim Erstellen oder beim Einlesen diese Form hatte. Damit wird die
Bearbeitung für den Benutzer einfacher, weil das Ergebnis der DMFFD nun vorhersehbarer
ist.
Es gibt zwar Argumente, die für eine Beibehaltung des Kontrollgitters über mehrere
Operationen hinweg folgende Argumente gesprochen hätten:
• Die Spline-Parameter (sP , tP , uP ) jedes Objektpunktes P brauchen nicht für jede
FFD-Operation neu berechnet zu werden, auch wenn P bereits durch vorhergehende
DMFFD Operationen verschoben wurde. Wenn die verwendeten Spline-Funktionen
die Eigenschaft der linearen Präzision aufweisen, ist die Neuberechnung dieser SplineParameter jedoch nicht aufwändig.
• Die Zusammensetzung von DMFFD durch schrittweise Verschiebung eines Startpunktes bildet über der Menge der DMFFDs eine kommutative Gruppe. Dies bringt
insbesondere die folgenden Eigenschaften mit sich:
• Die DMFFD-Verschiebung eines Startpunktes S an eine Position T1 , und anschließend dessen Verschiebung an eine Position T2 , führt zu der gleichen Verformung des
manipulierten Objekts, wie wenn der Startpunkt S direkt an seine Endposition T 2
verschoben worden wäre. Diese Eigenschaft ist jedoch zur Deformation von Objekten
nicht zwingend nötig. Vielmehr widerspiegelt sie die Abhängigkeit des Deformationsverhaltens von der Vorgeschichte.
• Jede DMFFD-Operation kann rückgängig gemacht werden, indem der Punkt mit der
Position T zurück in die Ausgangslage S gebracht wird. Wird das Kontrollgitter nicht
beibehalten, ist jedoch ein rückgängigmachen dennoch möglich, wenn die ursprünglichen Koordinaten der Objektknoten im Speicher aufbewahrt werden. Bei Objekten,
die durch finite Elemente dargestellt sind, ist die Anzahl der Knoten nicht so gross,
dass zeitliche oder speichermäßige Grenzen überschritten würden.
Ergänzend sei hier noch angemerkt, dass in bestimmten Fällen die Umkehrbarkeit der
DMFFD auch nach Verwerfen des Kontrollgitters, zumindest annähernd, besteht. Ist das
FFD-Volumen in Deformationsrichtung (T − S) gemessen relativ gross, dann ist die Invertierbarkeit der DMFFD näherungsweise gegeben, weil in diesem Fall für kleine Deformationen die Änderung der Spline-Parameter vernachlässigbar ist, d.h. (sS , tS , uS ) ≈ (sT , tT , uT )
und damit auch (sP , tP , uP ) ≈ (sP 0 , tP 0 , uP 0 ). Das Ersetzen des FFD-Volumens und des
6.8 Verwendung von B-Splines über uniformem Knotenvektor
97
Kontrollgitters fällt also kaum ins Gewicht, wenn das Ausmaß der Deformation verglichen
mit dem FFD-Volumen sehr klein ist.
Wenn beispielsweise die Deformation eines Bleches orthogonal zu dessen Oberfläche
geschieht, so ist die dritte Dimension des FFD-Volumens, gegeben durch die Deformationsrichtung, relativ frei wählbar, und somit lassen sich die Voraussetzungen für die Invertierbarkeit erreichen. In der vorliegenden Arbeit hat sich allerdings das Rückgängigmachen
der DMFFD-Operationen durch das Aufbewahren der ursprünglichen Koordinaten als hinreichend erwiesen.
Da jeder Nachteil der obigen Liste umgangen werden kann, gibt es für eine Beibehaltung des Kontrollgitters also keinen zwingenden Grund. In Verbindung mit weiteren,
im Folgenden vorgestellten Modifizierungen des DMFFD-Verfahrens ergibt sich zudem ein
großes Potential für Vereinfachung und Performanzsteigerung.
6.8
Verwendung von B-Splines über uniformem Knotenvektor
Es wurde bereits erwähnt, dass bei der FFD-Methode B-Splines den Bézier-Splines vorzuziehen sind, da erstere die Eigenschaft der lokalen Kontrolle besitzen. Entsprechend werden
B-Splines auch in verschiedenen FFD-bezogenen Arbeiten verwendet (vgl. Abschnitt 6.4).
Die dort verwendeten B-Splines interpolieren jedoch die äußeren Kontrollpunkte. Ein geringer Vorteil davon ist, dass die äußeren Kontrollpunkte sich exakt auf der Außenhülle
des FFD-Volumens befinden. Speziell beim DMFFD-Verfahren, wo die Kontrollpunkte den
Benutzer nicht interessieren, ist dies allerdings bloß für die Implementierung, und nicht bei
der Nutzung des Verfahrens von Bedeutung.
Ein Nachteil bei interpolierten Randknoten ist das uneinheitliche Deformationsverhalten in Randnähe. Außerdem ist die Forderung nach der linearen Präzision nicht erfüllt,
was die Berechnung der Spline-Parameter für sämtliche zu verschiebende Objektpunkte
erschwert, insbesondere wenn diese nach jeder Deformation aufgrund eines neuen Kontrollgitters aktualisiert werden müssen.
Diese beiden Nachteile können vermieden werden, wenn B-Splines über gleichmäßigem
(uniformem) Knotenvektor verwendet werden. Das bedeutet hier, dass sämtliche Knoten
(s0 , ..., sh+2n ) äquidistant zu deren Nachbarknoten liegen. Insbesondere gibt es keine zwei
Knoten an derselben Position2 .
B-Splines über uniformem Knotenvektor bieten ein gleichmäßiges (d.h. ortsunabhängiges) Deformationsverhalten und die Eigenschaft der linearen Präzision. Bei regelmäßig auf
2
Einige Autoren bezeichenen im Gegensatz dazu einen Knotenvektor auch dann als gleichmäßig (uniform), wenn an den Enden n + 1 Knoten dieselbe Position haben, d.h. wenn die äußeren Kontrollpunkte
interpoliert werden
98
einer Geraden angeordneten Kontrollpunkten einer B-Spline-Kurve über uniformem Knotenvektor entspricht dabei ein Spline-Kurvensegment, also die Abbildung des Parameterbereiches [si , ss+1 ], n ≤ i ≤ n + h, der Strecke zwischen zwei benachbarten Kontrollpunkten.
Diese Strecke wird linear, d.h. mit gleichmäßiger Geschwindigkeit bezogen auf den SplineParameter s durchlaufen.
Da für die Definition von h Spline-Segmenten h + n Kontrollpunkte verwendet werden,
und bei der obigen Aufstellung jedes Segment den Raum zwischen zwei benachbarten
Kontrollpunkten ausfüllt, liegen die äußeren Kontrollpunkte nicht auf dem Bild der BSpline-Funktion. Bei der Verwendung von B-Splines über uniformem Knotenvektor bei der
FFD liegen somit die äußeren Kontrollpunkte (zumindest für Spline-Grad n ≥ 2) außerhalb
des FFD-Volumens. Das FFD-Volumen ist in jeder Dimension um n − 1 KontrollpunktAbstände kleiner als die Hülle des Kontrollgitters.
Bei einem regelmäßigen FFD-Kontrollgitter ist das Abbild P (s, t, u) eines Parameterwertes (s, t, u) wegen der linearen Präzision linear abhängig von s, t und u. Die für das
FFD-Transformieren eines Punktes P benötigten Spline-Parameter sP , tP und uP lassen
sich somit durch lineare Interpolation bestimmen und es entfällt das aufwändige Lösen von
Gleichungen n-ten Grades.
6.9
Verwendung eines lokalen FFD-Volumens
Die Eigenschaft der lokalen Kontrolle und das ortsunabhängige Deformationsverhalten wurde in der vorliegenden Arbeit für eine weitere Vereinfachung genutzt: Es reicht nun aus,
das FFD-Volumen auf die tatsächlich deformierte Region zu beschränken. Da das Kontrollgitter nach jeder Deformation verworfen wird, muss nur der Bereich, welcher von der
aktuellen DMFFD-Operation betroffen ist, von dem FFD-Volumen eingeschlossen sein.
Um die Bedienung möglichst einfach zu halten, werden in der vorliegenden Arbeit bloß
DMFFD-Operationen betrachtet, die durch das Verschieben eines einzelnen Objektpunktes
definiert sind (single-point constraints). Dies stellt keine signifikante Einschränkung dar,
weil die Forderung nach dem gleichzeitigen Verschieben mehrerer gegebener Objektpunkte
durch das sequentielle Verschieben der einzelnen Punkte erfüllt werden kann.
Für eine Ein-Punkt-Deformation (single point constraint) wird ein FFD-Volumen mit
(3n + 1) × (3m + 1) × (3l + 1) Kontrollpunkten verwendet, wobei n, m, l die Spline-Grade
in der jeweiligen Dimension darstellen. Meist werden Splines gleichen Grades in allen drei
Dimensionen verwendet, so dass n = m = l. In diesem Fall sind insgesamt (3n + 1)3
Kontrollpunkte nötig.
Prinzipiell könnte man mit nur (3n)3 Kontrollpunkten auskommen. In diesem Fall befindet sich der Startpunkt genau auf einer Spline-Segmentgrenze. Dadurch verringert sich
die Anzahl der von Null verschiedenen Basisfunktionen, und damit auch die Anzahl der
6.9 Verwendung eines lokalen FFD-Volumens
99
relevanten Kontrollpunkte. Diese Variante wurde in der vorliegenden Arbeit ebenfalls implementiert. Sie hat sich aber als weniger geeignet erwiesen, weil damit die Krümmung
einer deformierten Ebene ungleichmäßiger ausfällt, als bei der Variante mit (3n + 1)3 Kontrollpunkten (Abb. 6.11).
Von den 3n+1 Kontrollpunkten in jeder Dimension werden nur n+1 durch die DMFFD
verschoben, gemäß Beziehung (6.22). Da sich ein verschobener Kontrollpunkt auf n + 1
Spline-Segmente auswirkt, sind in jeder Richtung noch weitere n Kontrollpunkte nötig
(das ergibt insgesamt die oben erwähnten 3n + 1 Kontrollpunkte) um ein FFD-Volumen zu
definieren, das die deformierte Region exakt begrenzt. Die in dieser Arbeit verwendeten BSplines über gleichmäßigem Knotenvektor gewährleisten einen stetigen Übergang zwischen
deformierter und nicht-deformierter Region.
Neben der einfacheren Berechnung hat ein lokal begrenztes FFD-Volumen den Vorteil,
dass es optimal an die anstehende Deformation angepasst ist. Der Detaillierungsgrad der
Deformation, bedingt durch den Kontrollpunktabstand bzw. durch die Größe des bearbeiteten Bereiches, lässt sich so stufenlos einstellen. Frühere oder spätere FFD-Operationen
sind nun vollkommen unabhängig, da jede Operation ihr eigenes Kontrollgitter hat.
Die optimale Anpassung des FFD-Volumens an eine einzige Ein-Punkt-Deformation
impliziert auch, dass jedes FFD-Volumen um den jeweiligen Startpunkt herum zentriert
ist. Für die Berechnung der Deformation bedeutet dies, dass die Spline-Parameter des
Startpunktes S konstant sind: (sS , tS , uS ) = ( 21 , 21 , 12 ). Damit sind auch die Basisfunktionen
Ri,j,k (sS , tS , uS ) aus Beziehung (6.22) und (6.23) konstant und müssen also nicht erneut
berechnet werden.
Für den Benutzer bedeutet das Zentrieren des FFD-Volumens um den Startpunkt herum, dass das Deformationsverhalten auch keine geringfügigen Unterschiede in Abhängigkeit
des gewählten Startpunktes aufweist. Beim herkömmlichen DMFFD-Verfahren ist die Lage des Startpunktes in Bezug auf das Kontrollgitter dem Zufall überlassen. Solange sich
der Startpunkt in einer bestimmten Zelle des Kontrollgitters befindet, ist der deformierte
Bereich zwar gleich, die Kontrollpunktverschiebungen δi,j,k (s. Beziehung (6.22)) ändern
sich jedoch mit den Spine-Parametern (sS , tS , uS ), und damit verändert sich ebenfalls
die Deformationscharakteristik. Durch ein lokales und temporäres FFD-Volumen, das immer um den Startpunkt zentriert ist, lassen sich diese Unzulänglichkeiten vermeiden und
ein konsistentes Deformationsverhalten ist sichergestellt, unabhängig von der Position des
Startpunktes.
Nach dem Zentrieren des FFD-Volumens um den Startpunkt stellt sich die Frage nach
dessen Ausrichtung. Bei einem würfelförmigen Volumen ist die Ausrichtung weniger relevant, weil hier die Region signifikanter Änderung annähernd sphärisch ist. Dann kann ein
achsenparalleles Volumen verwendet werden. Soll jedoch die Krümmung der Deformation
in einer Dimension geringer ausfallen, müssen die Ausmaße des FFD-Volumens in dieser
Dimension vergrößert werden. Bei Bedarf kann so die Deformation auf nur eine Dimension
des FFD-Volumens beschränkt werden (Abb. 6.12).
100
Abbildung 6.11: Deformationsverhalten und Anordung der Kontrollpunkte bei Ein-PunktVerschiebungen. Oben: Grad 2, 63 Kontrollpunkte. Mitte: Grad 2, 73 Kontrollpunkte. Unten: Grad 3, 103 Kontrollpunkte.
6.9 Verwendung eines lokalen FFD-Volumens
101
Abbildung 6.12: Beschränkung der Deformation auf eine Dimension (Beispiel).
Soll ein nicht-achsenparalleles Volumen verwendet werden, ist dessen Ausrichtung an
der Deformationsrichtung (S - T ), gegeben durch Startpunkt S und Zielpunkt T , sinnvoll.
Der übrige Freiheitsgrad, gegeben durch die Rotation um (S - T ), wird vom Benutzer
festgelegt. Eine automatische Festlegung nach diversen Kriterien entspricht in der Regel
nicht dem Wunsch des Benutzers.
Die räumliche Region, die von einer Ein-Punkt-DMFFD-Verschiebung mit kartesischem
Kontrollpunktgitter betroffen ist, entspricht in ihrer Form einem Quader (vgl. Abb. 6.11,
rechte Spalte). Die Region, in der wahrnehmbare Verschiebungen der Objektpunkte stattfinden, ähnelt jedoch eher einem Ellipsoid. Bei würfelförmigem FFD-Volumen wird das
Ellipsoid zu einer Kugel.
In Abbildung 6.11 ist ein ursprünglich ebenes Bauteil nach einer Verschiebung mit
Startpunkt in der Mitte des Bauteils. Die Ränder des Bauteils liegen auf der Grenze des
FFD-Volumens, also des deformierten Bereiches. Farblich markiert sind rechts die Regionen, wo Objektpunktverschiebungen größer als 1% der Startpunktverschiebung stattfinden.
Hier sieht man deutlich, dass der Bereich der signifiganten Veränderungen rund ist, der
Rest der quadratischen Deformationsregion wird kaum verändert.
Es wurde gezeigt, dass bei der Verschiebung eines Punktes von der Ausgangsposition
S an die neue Position T durch das DMFFD-Verfahren alle betroffenen Objektknoten
entlang der gleichen Richtung (T − S) bewegt werden (Beziehung (6.22) in Abschnitt
6.5). Je weiter ein Objektknoten vom Startpunkt S entfernt ist, um so geringer ist seine
Verschiebung durch DMFFD.
Wenn nun, wie oben erwähnt, ein an (T − S) ausgerichtetes FFD-Volumen verwendet
wird, so ist die Deformation achssymmetrisch und annähernd rotationssymmetrisch, mit
102
der Symmetrieachse (T − S). Statt mit Hilfe eines Spline-Tensorprodukts N i (s)Nj (t)Nk (u)
lässt sich eine DMFFD-Operation daher mit Spline-Funktionen über eindimensionalem
Parametergebiet Ni (s) beschreiben. Beziehung (6.22) wird damit zu
wobei sS =
folglich
1
.
2
Ni (sS )
(T − S)
δi = P n
2
i=0 Ni (sS )
(6.24)
Die neue Position P 0 eines durch DMFFD verschobenen Punktes P ist
0
P =P+
n
X
δi Ni (sP )
(6.25)
i=0
Der Spline-Parameter sP des Punktes P wird nun in Abhängigkeit des Abstandes zwischen
Punkt P und Startpunkt S, sowie abhängig vom Radius r in Richtung (P − S) der nun
ellipsoidalen Deformationsregion wie folgt berechnet:
sP =
r − |P − S|
2r
(6.26)
Durch die Verwendung von eindimensionalen Spline-Funktionen an Stelle von Tensorprodukten vereinfacht sich die Berechnung, da nun weniger Spline-Basisfunktionen berechnet werden müssen. Darüberhinaus ist die resultierende sphärische oder ellipsoidale
Deformationsregion sinnvoller als eine Würfel- oder Quader-förmige, weil auch bei letzteren die Region, in der signifikante Veränderungen stattfinden, annähernd sphärisch bzw.
ellipsoidal ist.
Um die Eigenschaft der linearen Präzision zu gewährleisten, musste bei der DMFFD
mit Tensorprodukten ein fester Abstand zwischen den Kontrollpunkten bestehen. Dadurch
war es nicht möglich, ein unsymmetrisches FFD-Volumen zu benutzen, also eine DMFFDOperation mit unterschiedlichem Aktionsradius in entgegengesetzte Richtungen.
Bei Verwendung von eindimensionalen Spline-Funktionen nach Beziehung (6.25) ist
der Radius r prinzipiell für jede räumliche Richtung frei definierbar. In der Praxis ist
eine Festlegung von maximal sechs Werten für den Radius entlang von drei orthogonalen
Hauptachsen, jeweils in positiver und negativer Richtung, sinnvoll.
Mit einem solchen unsymmetrischen Deformationsbereich eröffnen sich neue Möglichkeiten. So ist es nun möglich, den häufig vorkommenden Fall der Streckung oder Stauchung
eines Bauteils innerhalb eines durch zwei parallele Ebenen gegebenen Bereiches durchzuführen.
Dazu wird der Startpunkt auf eine der beiden Ebenen gelegt. Der Deformationsradius
zur anderen Ebene hin entspricht dem Abstand zwischen den beiden Ebenen. Die Radien
in die verbleibenden 5 Hauptrichtungen werden auf sehr große Werte gesetzt, so daß in
diesen Richtungen keine Verformung stattfindet.
6.10 Die Benutzerschnittstelle
103
Durch ein Verschieben des Startpunktes zur anderen Ebene hin wird das Bauteil zwischen den beiden Ebenen gestaucht, bei umgekehrter Verschiebung wird das Bauteil gedehnt. Der Halbraum jenseits des Startpunktes wird dabei nicht verformt, aber mit dem
Startpunkt mitverschoben.
Für die meisten Anwendungen ist eine lineare Dehnung oder Stauchung am sinnvollsten.
Um diese zu gewährleisten wird der Spline-Grad auf n = 1 gesetzt.
Durch die Verwendung von eindimensionalen Spline-Funktionen mit abstandsabhängigem Spline-Parameter wird auch ein weiteres Anwendungsszenario erschlossen: das Verschieben (Translatieren) eines Bereiches, gegeben durch eine zusammenhängende Menge
von benachbarten Objektknoten (Abb. 6.13).
r2
r1
Abbildung 6.13: Verschieben eines Bereiches unter Beibehaltung seiner Form, mit Splineförmigem Übergang zur unveränderten Umgebung.
Im Prinzip lässt sich dieses Problem auch als Mehr-Punkt-DMFFD betrachten und
iterativ lösen. Unter Verwendung eindimensionaler Spline-Funktionen gelangt man jedoch
schneller zu einer Lösung, da keine Iteration nötig ist. Die gegebene Objektregion wird
einfach entsprechend den Vorgaben verschoben, und die restlichen Objektknoten nach Beziehung (6.25) bewegt. Da jetzt nicht nur ein einziger Startpunkt S, sondern eine Menge
von Punkten Si (i = 1, ..., imax ) verschoben wird, ist Beziehung (6.26) entsprechend anzupassen:
sP =
6.10
r − min(|P − Si |)
2r
(6.27)
Die Benutzerschnittstelle
Hsu et al. [38], die Erfinder des DMFFD-Verfahrens, zählten den Entwurf einer geeigneten
Schnittstelle zu den noch ungelösten Aufgaben. In der Tat ist es schwierig, eine intuitiv zu bedienende Benutzerschnittstelle zu entwerfen, welche auch die Spezifikation von
mehrfachen Bedingungen (multiple point constraints) erlaubt.
Nachdem Hu et al. [39] gezeigt haben, dass sich mehrfache Bedingungen durch eine
Sequenz von einfachen Bedingungen darstellen lassen, lässt sich die Benutzerschnittstelle
104
entsprechend vereinfachen. Die Definition einer Ein-Punkt-Bedingung ist für den Benutzer
einfacher, und selbst eine Sequenz solcher Bedingungen bleibt für den Benutzer überschaubar, weil er visuelles Feedback über die Auswirkung der einzelnen Punktverschiebungen
erhält.
Beobachtet man die Auswirkung einer Ein-Punkt-DMFFD-Operation auf eine Objektoberfläche, so kann man eine Ähnlichkeit mit der Verformung eines Bleches mit einem
Gummihammer feststellen. Die in der vorliegenden Arbeit entwickelte Benutzerschnittstelle nutzt diese Ähnlichkeit zwischen Realität und DMFFD-Modellierung. Durch die Metapher des Gummihammers kann der Benutzer mit geringem Einarbeitungsaufwand Bauteile
auf ähnliche Weise bearbeiten, wie es bei realen Bauteilen der Fall ist.
Bei der Arbeit am virtuellen Objekt hat der Benutzer zusätzlich die Möglichkeit, Werkzeugparameter vorab einzustellen, und so die Genauigkeit der Bearbeitung zu gewährleisten. So kann z.B. das Ausmaß der Verformung, also die Kraft des virtuellen Hammers,
einfach und dennoch genau festgelegt werden. Um nicht aufwändig Werte in Dialogfelder
anzugeben oder ungenau mit der Maus den Startpunkt zu verschieben, wird ein anderer
Weg gegangen. Mit der Maus wird der Startpunkt angegeben, das Ausmaß der Verformung
wird dabei jedoch durch Drücken einer Taste angegeben, oder vorab durch einen Button
festgelegt. So kann z.B. die Taste “1“ eine Verschiebung um 1 mm bedeuten, usw., wobei
dieser Wert zwecks Flexibilität noch zusätzlich mit einem einstellbaren Skalierungsfaktor
multipliziert wird.
Die Verschiebung geschieht dabei immer vom Betrachter weg, wie das auch bei einem
realen Hammer der Fall ist. Auf Wunsch kann durch Drücken einer Hilfstaste die Verschiebung umgekehrt werden, so dass sich der Startpunkt also in Richtung des Betrachters
veschiebt. Entspricht das Ergebnis nicht den Erwartungen, kann die Operation rückgängig
gemacht werden. Zu diesem Zweck werden vor der Durchführung einer DMFFD-Operation
die Koordinaten der Objektknoten aufbewahrt, so dass der Ausgangszustand wieder hergestellt werden kann.
Die Richtung, entlang welcher der Startpunkt verschoben wird, entspricht im Regelfall der Oberflächennormalen am Startpunkt. Bei Bedarf kann die Verschiebungsrichtung
frei definiert werden, sei es durch Festlegung zweier Objektpunkte mit Hilfe der Maus,
sei es durch Aufbewahren einer Oberflächennormalen für die weitere Verwendung, oder
aufwändiger, aber am flexibelsten, durch die zahlenmäßige Angabe der Normalen.
Bei der Dehnung oder Stauchung eines Bauteils ist es oft nötig, dass die Verformungsrichtung auf der Oberfläche des Bauteils liegt. Eine solche Verformungsrichtung kann durch
die Angabe zweier Punkte oder durch die Projektion einer vorher spezifizierten Richtung
auf die Bauteiloberfläche angegeben werden.
Weiterhin kann der Aktionsradius der DMFFD festgelegt werden, sowie der SplineGrad, abhängig von den in Abschnitt 6.9 beschriebenen Anwendungsszenarien. Sofern der
Anwender es wünscht, wird der Deformationsbereich und die Deformationsrichtung jeweils
6.10 Die Benutzerschnittstelle
105
Abbildung 6.14: Benutzerschnittstelle für DMFFD
an der aktuellen Position des Mauszeigers dreidimensional dargestellt. Durch dieses visuelle Feedback lässt sich das Ergebnis der DMFFD-Operation gut abschätzen, so dass
unerwünschte Ergebnisse vermieden werden.
Abbildung 6.14 zeigt die Benutzeroberfläche zur Anwendung der DMFFD. Zu sehen ist,
links, ein 3D-Zeiger, welcher Startpunkt und Deformationsrichtung anzeigt. Außerdem wird
mit roten Linien die zu deformierende Region markiert. Die im Bild zu sehende Perforation
wurde durch eine einzige DMFFD-Operation behoben. Das linke Bauteil, das hier unter
dem Zeiger zu sehen ist, wurde hierbei allerdings, um seine ebene Form zu erhalten, nicht
verändert. Stattdessen wurde es ausgeblendet, und eine DMFFD-Operation in umgekehrter
Richtung am darunterliegenden Bauteil wurde ausgeführt.
106
6.11
Justierung des Abstandes von Flanschen
Das DMFFD-Verfahren hat einen breiten Einsatzbereich. Durch mehrfache Anwendung
und Festlegung des Aktionsradius – falls nötig auf einen sehr kleinen Wert – kann prinzipiell
jede Art von Verformung erzeugt werden. Eine vielfache Anwendung kann jedoch mühsam
sein. Daher empfiehlt es sich, häufig wiederkehrende Aufgaben zu automatisieren. Damit
wird der Einsatzbereich der DMFFD noch erweitert.
Eine häufig auftretende Anforderung ist das Verändern des Abstandes zwischen Bauteilen. Ein Grund dafür kann in der Veränderung eines von zwei benachbarten Bauteilen durch
den Konstrukteur liegen. Ein anderer häufiger Grund ist die Diskretisierung der Bauteilgeometrie im Rahmen der Vernetzung. Dadurch kann es zu den in Kapitel 3 besprochenen
Penetrationen und Perforationen kommen. Doch auch ohne Durchdringungen kann es sein,
dass der Bauteilabstand zu klein ist, oder aber zu groß, z.B. um an der betreffenden Stelle
Verbindungselemente zu definieren.
Wo zwei Bauteile verbunden werden, hat in der Regel mindestens eines der beiden
Teile einen Flansch. Dieser Flansch kann mit Hilfe des Vorgehens aus Kapitel 4 und 5
erkannt werden. Der Algorithmus bedarf allerdings einiger Modifikationen. Ging es bisher
darum, die Mittellinie eines Flansches zu bestimmen, so ist nun die Menge aller Elemente,
und schließlich die Menge bestehend aus deren Knoten gefragt. Diese Knoten gilt es zu
verschieben, um den Abstand anzupassen.
Der modifizierte Algorithmus ist einfacher als der Algorithmus für die automatische
Definition von Schweißpunktlinien. Dort musste ein Pfad aus Elementen gebildet werden,
welcher längs zum Flansch verlief. Hier kann in ähnlicher Weise, ausgehend von einem
Startelement, die Menge aller benachbarten Flanschelemente bestimmt werden. Als vereinfachter Programmcode sieht der Algorithmus wie folgt aus:
/*** Methode flangeElements liefert alle Elemente eines Flansches ***/
list<Elements> flangeElements(Element startElement) {
// startElement sollte zum Flansch gehören
if (startElement.isNotFlange())
return empty_list;
list<Elements> resultList;
// resultList enthält alle bereits gefundenen Flanschelemente
resultList.add(startElement);
for (int index = 0; index < resultList.length(); index++) {
Element element = resultList[index];
// prüfe Nachbarn der bereits gefundenen Flanschelemente
for (each neighbour of element)
if (neighbour.notChecked()) {
if (neighbour.isFlange())
resultList.append(neighbour); // neues Element ggf. eintragen
6.11 Justierung des Abstandes von Flanschen
107
neighbour.markAsChecked(); // und stets als besucht markieren
}
}
return resultList;
}
Wie in Kapitel 4, Abbildung 4.1, können auch hier die Flansch-Elemente als Knoten eines Baumgraphen betrachtet werden. Ausgehend von der Wurzel des Baumes, dem
Startelement, wird der Graph in breadth-first Art traversiert, und alle gefundenen Flanschelemente in eine Liste eingetragen. Je weiter ein Element vom Startelement entfernt ist, um
so später ist es in der Liste zu finden. Eine Rückverfolgung des Pfades zum Startelement,
wie bei der Bestimmung der Mittellinie in Kapitel 5, ist hier nicht nötig.
Nachdem die Liste aller Flanschelemente aufgestellt wurde, soll nun der Abstand des
Flansches zum benachbarten Bauteil gemessen werden. Der Abstand kann nur an endlich
vielen Stellen gemessen werden, und es ist sinnvoll, ihn zumindest an den Knoten des
Flansches zu messen, weil es die Knoten sind, die verschoben werden können und die
Form des Flansches bestimmen. Deshalb wird im nächsten Schritt die Menge aller Knoten
bestimmt, die zu mindestens einem Flanschelement gehören.
Speziell bei stark gekrümmten Bauteilen kann es unzureichend sein, den Abstand bloß
an den Flanschknoten zu messen und zu korrigieren. Optional können daher auch die Elementmittelpunkte und sogar die Kantenmittelpunkte berücksichtigt werden. Alternativ
oder zusätzlich können auch die Abstände an den entsprechenden Knoten des Nachbarbauteils berücksichtigt werden. Zwar werden schließlich nur Elementknoten des Flansches
verschoben, doch als Startpunkt für das DMFFD-Verfahren kann jeder Punkt dienen.
Allerdings konvergiert der Justierungsalgorithmus langsamer, wenn die Anzahl der zu
berücksichtigenden Abstände steigt. Um die Anforderungen der Praxis zu widerspiegeln,
und um das Verfahren zu beschleunigen, kann festgelegt werden, ob der Abstand mindestens, höchstens, oder genau dem gewünschten Betrag entsprechen soll. Dabei kann auch
die erlaubte Abweichung vom gewünschten Wert, also die Toleranz, angegeben werden.
Für diejenigen Punkte, welche das Abstandskriterium nicht erfüllen, wird durch Projektion eine Verschiebungsrichtung ermittelt. Auf dieser Projektionsgeraden soll der betreffende Punkt dann so weit verschoben werden, bis das Abstandskriterium erfüllt ist.
Solange nur die Abstände gemessen an den Knoten der Flanschelemente berücksichtigt
werden, könnte man sich prinzipiell daraus beschränken, diese Knoten zu verschieben, ganz
ohne Free-Form Deformation. Ein Grund für die Anwendung der DMFFD ist jedoch, dass
ein kontinuierlicher Übergang zwischen der deformierten und der unveränderten Region
erzeugt wird. Es werden also auch einige Knoten außerhalb des Flansches verschoben. Eine
anschließende Gitterrelaxation ist daher in der Regel nicht notwendig. Auch der Flansch
selbst bleibt relativ glatt, denn es findet eine Mittelung der unterschiedlichen Verschiebungsanforderungen statt, bedingt durch überlappende FFD-Volumen bei der Behandlung
naheliegender Punkte.
108
Für ein optimales Ergebnis werden die Abstände der betreffenden Punkte schrittweise
angepasst. Durch die überlappenden FFD-Volumen bei naheliegenden Punkten kann es
zu widersprüchlichen Anforderungen kommen. Durch eine wiederholte Verschiebung der
Punkte in kleinen Schritten werden die Anforderungen dennoch erfüllt.
Die Justierung des Abstandes von Flanschen kann auch als multi-constraint DMFFDProblem angesehen werden, und durch Lösen eines linearen Gleichungssystems behandelt
werden. Aufgrund der Vielzahl von zu berücksichtigenden Punkten ist dies Gleichungssystem jedoch überbestimmt. Die Abstandskriterien können damit nur dann vollständig
erfüllt werden, wenn ein extrem feines Kontrollgitter verwendet wird. Mit einem solchen
Gitter ist jedoch der deformierte Bereich recht klein, und naheliegende FE-Knoten werden
nicht mehr mitbewegt um einen stetigen Übergang zu erhalten.
Das iterative Anwenden unabhängiger DMFFD Operationen mit lokalem und temporärem Kontrollgitter, wie in dieser Arbeit beschrieben, gewährleistet hingegen eine
Lösung nach einer endlichen Anzahl von Iterationen und eine flexible Größe des verformten
Bereiches. Als iteratives Verfahren ist es mit einem gewissen Berechnungsaufwand verbunden und kann deshalb bei einer großen Anzahl zu berücksichtigender Punkte bei großem
Deformationsbereich einige Sekunden in Anspruch nehmen. Doch es darf nicht vergessen
werden, dass es sich bei der herkömmlichen Methode, dem Lösen eines überbestimmten
Gleichungssystems, ebenfalls um ein iteratives Verfahren handelt.
Abbildung 6.15 zeigt ein Ergebnis des hier vorgestellten Verfahrens zur Justierung des
Abstandes von Flanschen. Durch das Anpassen des Abstandes zwischen dem Flansch und
dem darunterliegenden Bauteil werden gleichzeitig auch Perforationen, Penetrationen und
übergroße Abstände beseitigt.
In Abbildung 6.16 ist ein weiteres Anwendungsbeispiel zu sehen. Im Ausgangszustand
existieren mehrere große Perforationen entlang des relativ langen Flansches. Prüfkriterium
ist hier der Abstand der Knoten, sowie der Element- und Kantenmittelpunkte des Flansches
bezüglich des anderen Bauteiles.
Nach einer Iteration ist bereits der Großteil der Perforationen beseitigt. Nach zwei
Iterationen sind sämtliche Perforationen verschwunden. Für Flansche ist dies Verfahren
somit in der Regel schneller und zuverlässiger als die Beseitigung von Perforationen aus
Abschnitt 3.3.
Einige weitere Iterationen können angewandt werden, um den Abstand des Flansches
zum anderen Bauteil auf einen gewünschten Wert zu bringen. Alternativ kann jetzt, nach
der Beseitigung der Perforationen, der Bauteilabstand mit Hilfe des Verfahrens zur Behebung der Penetrationen (Abschnitt 3.6) angepaßt werden.
6.12 Zusammenfassung
109
Spalt
Perforation
vorher
nachher
Abbildung 6.15: Beseitigung von Perforationen und übergroßen Bauteilabständen durch
Justierung des Abstandes von Flanschen.
6.12
Zusammenfassung
Das als Direct Manipulation of Free-Form Deformation bekannte Verfahren wurde im Rahmen dieser Arbeit untersucht und weiterentwickelt, um den Anforderungen nach Bedienbarkeit und Effizienz zu entsprechen. Im Wesentlichen wurden dazu folgende Änderungen
durchgeführt:
• Die Deformation des Objektes wird explizit berechnet, anstatt ein Gleichungssystem
iterativ zu lösen. Dazu wurden die Ergebnisse von Hu et al. [39] verwendet.
• Jeder Deformation liegt nun ein neues, undeformiertes Kontrollgitter zugrunde. Das
Verhalten der DMFFD ist jetzt unabhängig von vorhergegangenen Deformationen.
• Anstelle der in bisherigen Arbeiten verwendeten Bézier- bzw. B-Splines mit interpolierten Kontrollpunkten an den Enden werden hier B-Splines über uniformem
Knotenvektor verwendet. Damit wird der Unterschied im Deformationsverhalten im
Randbereich des FFD-Volumens eliminiert. Neben dem zeitlichen ist damit auch das
räumliche Deformationsverhalten gleichmäßig. Durch die lineare Präzision der verwendeten Spline-Funktionen ist die Berechnung weniger aufwändig, das Verfahren
wird schneller.
110
Abbildung 6.16: Beseitigung von Perforationen durch Justierung des Abstandes auf einem
längeren Flansch. Oben: Ausgangszustand. Mitte: Nach einer Iteration. Unten: Nach zwei
Iterationen
• Das FFD-Volumen kann jetzt, aufgrund der vorhergehenden Änderungen, auf den
tatsächlich deformierten Bereich beschränkt werden.
• Das FFD-Volumen wird um den Startpunkt herum zentriert. Dadurch wird die Berechnung der Kontrollpunktverschiebungen wesentlich vereinfacht und damit schneller. Darüberhinaus ist damit die letzte Quelle für Ungleichmäßigkeiten im Deformationsverhalten eliminiert, weil die Position des Startpunktes relativ zum Kontrollgitter
nun konstant ist.
• Der Radius des Deformationsbereiches kann nun in den drei Hauptrichtungen des
quaderförmigen FFD-Volumens frei angegeben werden, unabhängig von früheren oder
6.12 Zusammenfassung
111
späteren DMFFD-Operationen, und ohne dass der Benutzer Kontrollpunkte einfügen
oder entfernen muss.
• Die Verwendung eindimensionaler Spline-Fuktionen anstelle des Tensorprodukts
bringt zusätzliche Vereinfachung und Flexibilität.
• Die Benutzerschnittstelle erlaubt mit Hilfe der Gummihammer-Metapher ein schnelles und genaues Bearbeiten des Objekts.
• Für verschiedene Anwendungen, wie das Anpassen des Abstandes von Flanschen,
kann das DMFFD-Verfahren automatisch und iterativ angewendet werden.
In der vorliegenden Arbeit wurde dieses verbesserte DMFFD-Verfahren für die Bearbeitung von Karosseriebauteilen in FE-Repräsentation verwendet. Das Verfahren lässt sich
jedoch für jede Art von Objekten anwenden, welche durch ein Polygonnetz repräsentiert
sind. Für Objekte, welche im Gegensatz dazu durch Spline-Flächen oder ähnliches dargestellt sind, ist eine DMFFD-Modellierung ohnehin nicht notwendig. Hier ist eine direkte
Bearbeitung der Spline-Flächen, z.B. durch Verschiebung von deren Kontrollpunkten, sinnvoller.
112
Kapitel 7
Massentrimm
Bei der Crash-Simulation nach der FE-Methode wird das Fahrzeug, genauer die einzelnen
Bauteile, durch ein Gitter aus linearen Elementen dargestellt. Nichttragende Teile, zum
Beispiel Batterie, Kabelbaum, diverse Aggregate und Betriebsflüssigkeiten brauchen nicht
durch finite Elemente dargestellt zu werden. Durch das Vernachlässigen der Geometrie von
nichttragenden Teilen werden also Rechnerressourcen gespart.
Bis jetzt sind solche nichttragenden Teile durch den Berechnungsingenieur im Rahmen
des Massentrimms auf die benachbarte Bauteile “verschmiert” worden, d.h. die Masse der
umliegenden Teile wurde anteilmäßig erhöht. So wurde das Fehlen der nichttragenden Teile
im Modell näherungsweise kompensiert. Da nun das Simulationsprogramm die Möglichkeit
bietet, nichttragende Teile als speziellen Elementtyp in der Eingabedatei zu spezifizieren,
wird die Simulation genauer. Außerdem entfällt das zeitaufwändige und fehlerträchtige
Verschmieren der Masse von Hand. Die neuen Elemente werden als strukturlose Massen
(nonstructural masses) bezeichnet.
Für die Simulation relevant sind bei den strukturlosen Massen allein die Masse und
die Bauteile, auf welche diese Masse verteilt wird. Will man die strukturlosen Massen
jedoch visualisieren, so ist es notwendig, zumindest deren Position, also den Schwerpunkt
des nichttragenden Teils zu kennen. Ferner ist es wünschenswert, dass die Visualisierung
einen Hinweis gibt auf die Bauteilform, die der strukturlosen Masse zugrundeliegt. Da
aber weder Geometrie noch Schwerpunkt bei der Simulationsberechnung verwendet wird,
ist es erstrebenswert, diese Information möglichst kompakt zu speichern. Eine Möglichkeit
wäre, die Geometrie als Bounding Box vereinfacht darzustellen. Bei einem Teil wie dem
Kabelbaum wäre dies jedoch nachteilhaft, da hier die Bounding Box sehr groß ist und
praktisch das gesamte Fahrzeug umschließt.
In Absprache mit den Konstruktionsingenieuren wurde deshalb vereinbart, Informationen über die Trägheitseigenschaften abzuspeichern. Von Interesse sind dabei die Hauptträgheitsmomente und die Hauptträgheitsachsen. Daraus kann der Konstruktionsingenieur
Rückschlüsse ziehen über die Art des dargestellten Teils und dessen Einfluss auf das CrashVerhalten. Hauptträgheitsmomente und -achsen können in dem Trägheitstensor kompakt
114
Massentrimm
abgespeichert werden. Der Trägheitstensor ist eine symmetrische 3x3 Matrix, es sind also
nur 6 Werte abzuspeichern [32]. Der Trägheitstensor ist für die meisten Bauteile bereits
bekannt, kann aber auch ohne großen Aufwand berechnet werden. Die Hauptträgheitsmomente erhält man, indem man die Eigenwerte des Trägheitstensors berechnet. Die Eigenvektoren des Trägheitstensors sind die Hauptträgheitsachsen.
Zusammen mit dem Schwerpunkt (xs , ys , zs ) des nichttragenden Bauteils sind also 9
Fließkommawerte zu speichern, welche allein der Visualisierung dienen und nicht in die
Simulation eingehen. Diese Werte werden als Zeichenkette kodiert in einem Textfeld abgespeichert, so dass sie die Simulation nicht beeinflussen, bei der Visualisierung mit crashViewer jedoch ausgewertet und editiert werden können.
Die Hauptträgheitsachsen eines Körpers stellen die Hauptachsen des sogenannten
Trägheitsellipsoids dar. Daher liegt es nahe, das Trägheitsellipsoid als Glyph zur Visualisierung der strukturlosen Massen heranzuziehen.
Die Darstellung durch ein Ellipsoid bringt jedoch einige Nachteile mit sich. Insbesondere sind bei der Darstellung eines Ellipsoids am Bildschirm die Hauptachsen nicht immer
leicht zu erkennen. Außerdem benötigt eine ansprechende Darstellung des Ellipsoids am
Bildschirm eine feine Tesselierung, was den Bildaufbau verlangsamt.
Daher wird hier das Trägheitsellipsoid nur bei Bedarf angezeigt. Im Regelfall wird hingegen ein dreidimensionales Achsenkreuz für die Visualisierung der Trägheitseigenschaften
verwendet. Das Kreuz wird dargestellt durch drei längliche, zueinander senkrechte Quader. Die Orientierung der Quader stimmt mit den Hauptträgheitsachsen überein. Die Quaderlänge ist proportional zu den Hauptträgheitsmomenten. Der Mittelpunkt der Quader
befindet sich im Schwerpunkt des nichttragenden Bauteils (Abbildung 7.1).
Zusätzlich zu den Trägheitsachsen wird auch die Masse des dargestellten Bauteils visualisiert. Dies geschieht durch eine Kugel deren Mitte dem Bauteilschwerpunkt entspricht,
und deren Volumen zu der dargestellten Masse proportional ist. Diese Kugel benötigt keine feine Darstellung, da es allein auf das Volumen ankommt. Durch das Kugelvolumen
lässt sich sehr intuitiv die Masse visualisieren. Auch hier zeigt sich, dass es sinnvoll ist,
auf die Darstellung des Trägheitsellipsoids zu verzichten, da sich die beiden Geometrien
gegenseitig verdecken würden.
Neben der Visualisierung der im Datensatz vorhandenen strukturlosen Massen hat der
Benutzer die Möglichkeit, neue strukturlose Massen anzulegen. Die Parameter der neuen oder bereits vorhandenen Massen, nämlich Schwerpunkt, Trägheitstensor und Masse
können interaktiv editiert werden. Die Bauteile, auf welche die Masse verschmiert werden
soll, können spezifiziert werden und werden visuell hervorgehoben. Für Testzwecke kann
auch im crashViewer die Masse auf die betreffenden Bauteile verschmiert werden. Auch
können die Trägheitseigenschaften eines beliebigen Bauteils berechnet und visualisiert werden (Abbildung 7.2).
Massentrimm
115
Abbildung 7.1: Visualisierung von vier strukturlosen Massen durch 3D-Glyphen. Für die
jeweils selektierte Masse werden die betroffenen Bauteile als Drahtgitter visualisiert.
Abbildung 7.2: Visualisierung eines Bauteils zusammen mit dessen Trägheitseigenschaften..
116
Massentrimm
Kapitel 8
Integration
8.1
Motivation
Bei der Karosserieentwicklung werden eine Vielzahl von Software-Tools eingesetzt: BauteilDatenbanken, Vernetzer, Pre- und Postprocessing-Tools, Finite-Elemente-Solver, LoadBalancing usw. Jedes dieser Tools besitzt eine unterschiedliche Benutzerschnittstelle;
Eingabe- und Ergebnisdaten werden über ein gemeinsames Dateisystem ausgetauscht.
Der Berechnungsingenieur, welcher die Crash-Simulationen durchführt, muss daher mit
der Bedienung einer großen Anzahl von Anwendungen vertraut sein. Darüberhinaus muss
er sich um die Verwaltung der Dateien kümmern, welche von einer Anwendung erzeugt
wurden und als Eingabe für die nächste Anwendung dienen.
Speziell bei der Visualisierung von Ergebnissen der Crash-Simulation spielt noch ein
anderer Aspekt eine Rolle: Weil die Crash-Simulation eine beträchtliche Zeit in Anspruch
nimmt, ist es wünschenswert, schon während der Simulation die bereits berechneten Ergebnisse untersuchen zu können. So kann eine Simulation vorzeitig abgebrochen werden,
um Zeit zu sparen, sobald sich abzeichnet, dass keine neuen Erkenntnisse zu erwarten
sind. Dieses Steuern der Simulation in Abhängigkeit von den Zwischenergebnissen wird
als Simulation Steering bezeichnet. Simulation und Visualisierung werden integriert, die
Visualisierung wird nicht mehr nach, sondern während der Simulation ausgeführt [40, 65].
Der eingesetzte FE-Solver PAM-CRASH erlaubt, Zwischenergebnisse in eine Datei zu
schreiben. Dazu muss der Benutzer eine kleine Textdatei anlegen, welche ein bestimmtes
Schlüsselwort enhält. Das aktuelle Zwischenergebnis wird dann nach dem Beenden des
laufenden Simulationsschrittes, also nach einigen Minuten, in einer Datei bereitgestellt.
Diese Datei kann dann zur Visualisierung durch eine entsprechende Anwendung eingelesen
werden.
Weil diese Vorgehensweise für den Benutzer recht aufwändig ist, wurde in Zusammenarbeit mit dem Hersteller des Simulationscodes, der ESI Group, eine Schnittstelle entworfen
118
Integration
und realisiert, welche eine direkte Kommunikation zwischen Simulation und Visualisierung
ermöglicht. Die Kommunikation kann sowohl lokal als auch über ein Netzwerk erfolgen; sie
basiert auf dem objektorientierten CORBA-Protokoll.
Durch die direkte Kommunikation zwischen Simulation und Visualisierung wird die
Vorgehensweise bei der Crash-Simulation vereinfacht und die Effizienz gesteigert. Eine effiziente Crash-Simulation ermöglicht eine Verkürzung der Entwicklungszeiten neuer Fahrzeugmodelle und stellt somit einen wichtigen Wettbewerbsvorteil in dem stark umkämpften
Automobilmarkt dar.
Doch nicht nur Simulation und Visualisierung wurden im Rahmen der vorliegenden
Arbeit zusammengeführt. Das prototypische Pre- und Postprocessingtool der Universität
Stuttgart CrashViewer, heute als FEMod weiterentwickelt, wurde in die von BMW in
Auftrag gegebene, Web-basierte Integrationsumgebung CAE-Bench eingebettet. Bei dieser EAI (Enterprise Application Integration) spielt CORBA eine bedeutende Rolle, ebenso
wie ein spezielles, im Rahmen der vorliegenden Arbeit entwickeltes Java Applet, das in die
CAE-Bench Web-Seiten eingebettet wird. Das Java Applet gewährleistet die Kommunikation zwischen der Integrationsplattform auf der einen und dem Visualisierungstool auf der
anderen Seite.
8.2
CORBA Grundlagen
CORBA, die Common Object Request Broker Architecture wurde von der Object Management Group1 (OMG), einem Standardisierungsgremium mit mehr als 700 Mitgliedern,
1991 in der ersten Version definiert. CORBA [63] war eine Antwort auf die starke Zunahme von Hardware- und Software-Produkten: Ziel war es, eine Middleware zu schaffen,
welche eine orts-, plattform- und implementations-unabhängige Kommunikation zwischen
Applikationen erlaubt.
Wirklich interessant geworden ist CORBA seit der Verabschiedung der Version 2.0 im
Dezember 1994. Diese Version brachte das Kommunikationsprotokoll IIOP, welches den
Informationsaustausch zwischen Object Request Brokern (ORBs) verschiedener Hersteller
und vor allem auch über das Internet ermöglicht.
ORBs sind die technischen Implementationen des Standards CORBA. Ein ORB
ermöglicht es einem Client, eine Meldung transparent an ein Serverobjekt zu senden, wobei das Serverobjekt auf derselben oder einer anderen Maschine laufen kann. Der ORB ist
dafür zuständig, das Serverobjekt zu finden, dort die Funktion aufzurufen, die Parameter
zu übergeben und das Resultat an den Client zurückzureichen. Dadurch wird die bereits
erwähnte nahtlose Interoperabilität zwischen Applikationen erreicht, welche in einem völlig
heterogenen Umfeld betrieben werden können.
1
http://www.omg.org
8.2 CORBA Grundlagen
119
Bisher wurde in einem heterogenen Umfeld typischerweise jede Schnittstelle spezifisch
programmiert. Dabei müssen Plattform, Betriebssystem, Programmiersprache und anderes
in Betracht gezogen werden. Bei Änderungen ist die Anpassung solcher Schnittstellen entsprechend schwerfällig. Bei CORBA-basierenden Systemen ist dies anders. Es besteht eine
strikte Trennung zwischen der Schnittstellendefinition eines Objektes und deren Implementation. Beim CORBA-Vorgehen wird zunächst die öffentliche Schnittstelle eines Objektes
(d.h. die Funktionen) in der Interface Definition Language (IDL) definiert.
Plattform A,
Sprache X
Plattform B,
Sprache Y
IDL
Methoden−Aufruf, Parameter
Ergebnis
Corba Stubs
Corba−Client
Corba Skeletons
et
rn−ORBl
e
t r co
InInteoto OP
P r II
Objekt Impl.
Corba−Server
Corba Services
(Naming Service,
Event Service...)
Abbildung 8.1: Die CORBA Client-Server Architektur
IDL ist eine implementations-unabhängige Beschreibungssprache. Die IDL-Schnittstelle
kann mit Hilfe eines IDL-Compilers für eine Vielzahl von Programmiersprachen auf Stubs
und Skeletons abgebildet werden. Stubs sind Client- und Skeletons sind Server-seitige,
computergenerierte Programmgerüste.
Anschließend wird dieses Programmgerüst ausprogrammiert, und zwar sowohl für den
Client als auch für den Server-Teil. Dabei kann der Client beispielsweise in Java implementiert werden, während der Server in C++ programmiert wird (Abbildung 8.1). Für weitere
Einzelheiten sei auf die vielfältige Literatur zu diesem Thema verwiesen [7, 59, 78, 34, 9].
Die wichtigsten Vorteile von CORBA sind, kurzgefasst, die folgenden:
• Hardware-, Betriebssystem- und Sprachunabhängigkeit: Sie gewährleisten die Portierbarkeit und die Wiederverwendbarkeit des erstellten Programmcodes
• Offenheit: Durch den ORB können Programme verschiedener Hersteller zusammenarbeiten.
• Verteilungstransparenz: CORBA-Objekte greifen auf entfernten Objekte mit den gleichen Mechanismen wie auf lokale Objekte zu. Für den Client bleibt der Aufenthaltsort
des Objektes in der Regel unbekannt.
120
Integration
• Objektorientierung: Objekte sind die grundlegenden Einheiten der Architektur. Dabei ist ein Objekt eine beliebige identifizierbare Einheit.
• Effizienz: Es sind effiziente Implementationen möglich, die z.B. im Falle rein lokaler
Kommunikation dem traditionellen Funktionsaufruf nur unwesentlich nachstehen.
Der Funktionsumfang von CORBA kann durch die Verwendung von CORBA Services
erweitert werden. Der wichtigste ist der Naming Service. Er stellt eine Art Datenbank
dar, bei der CORBA-Server-Objekte angemeldet werden können, um von CORBA-ClientObjekten auf einfache Weise referenziert zu werden.
Als Client-Objekt wird ein Objekt bezeichnet, welches Methoden eines anderen aufruft.
Ein Server-Objekt ist eines, dessen Methoden aufgerufen werden. CORBA-Objekte können
daher Server und Client in einem darstellen, wenn sie in ihrer CORBA/IDL-Schnittstelle
Methoden zum Aufruf durch andere Objekte bereitstellen, sowie ihrerseits Methoden der
CORBA/IDL-Schnittstelle anderer Objekte aufrufen.
8.3
Verwandte Arbeiten
Eine Reihe von Forschungsaktivitäten beschäftigen sich mit der CORBA-basierten
Software-Integration. TENT (TEstbed for Numerical Turbines) [74, 43, 64, 22] ist eine
vom Deutschen Zentrum für Luft- und Raumfahrt (DLR) und der Fraunhofergesellschaft
entwickelte Integrationsumgebung. TENT wird im Bereich der Strömungssimulation eingesetzt, wo es eine in Java implementierte graphische Benutzerschnittstelle zur Steuerung
der eingesetzten Softwarekomponenten bietet. Verbindungen zwischen Softwarekomponenten werden graphisch dargestellt und können editiert werden, ähnlich wie z.B. bei den
Visualisierungsanwendungen AVS/Express [4] oder IRIS Explorer [60].
Für Datentransfers und für die Kommunikation zwischen Komponenten wird CORBA
verwendet. Anders als CAE-Bench ist TENT nicht Web-basiert. Die Einbindung einer PDM
(Product Data Management) Datenbank ist bislang nicht möglich. Kein Ersatz für CAEBench ist TENT auch wegen seines verschiedenen Konzepts und seiner unterschiedlichen
Zielsetzung.
Ebenfalls aus der Strömungsvisualisierung stammt COVISE (COllaborative Visualization and Simulation Environment) [36]. Ähnlich wie TENT erlaubt COVISE das graphische
Verwalten von Datenflüssen zwischen Anwendungsmodulen (Abb. 8.2). In C++ implementiert wird anstelle von CORBA ein proprietärer COVISE Request Broker (CRB) verwendet,
was die Portabilität etwas einschränkt. COVISE bietet insbesondere auch Unterstützung
für Virtual Reality Darstellungen, z.B. in der CAVE.
Mit dem Benchmarking von CORBA-Implementationen beschäftigte sich das Team um
Virgine Amar. Sie erarbeiteten außerdem Ansätze zur Integration von STEP und CORBA [96, 95, 3, 2].
8.4 Vorbereitende Arbeiten
121
STEP ist ein internationaler Standard für die menschen- und maschinenlesbare Darstellung von Produktdaten. Die Anwendungsgebiete liegen u.a. im CAD-, Produktions-, und
Ingenieurbereich. Während CORBA eine plattformunabhängige Netzwerkkommunikation
ist, stellt STEP eine Art plattformunabhängiger Produktdatenbeschreibung dar.
STEP sollte ursprünglich auch als einheitliches Datenmodell im Rahmen des AutoBench
Projekts [86] verwendet werden. Die Datenbeschreibungen der AutoBench Partner erwiesen
sich jedoch als zu komplex und zu verschieden, um sie auf eine einheitliche STEP Beschreibung zu bringen. Außerdem hätte die Verwendung von STEP Performance-Einbußen mit
sich gebracht.
8.4
Vorbereitende Arbeiten
In der frühen Projektphase war noch nicht klar, ob CORBA sich für den Transfer großer
Datenmengen eignet, wie sie bei der Anbindung des Visualisierungstools an den FE-Solver
anfallen. Es zeigte sich jedoch, dass große Datenmengen durchaus effizient übertragen werden können. Voraussetzung ist allerdings, dass die Daten in großen Blöcken, also mit wenigen CORBA-Methodenaufrufen, übertragen werden. Je kleiner die Übertragungseinheit
Abbildung 8.2: Die Benutzeroberfläche von COVISE
122
Integration
ist, um so mehr Overhead fällt bei der CORBA-Kommunikation an. Tabelle 8.4 macht dies
deutlich.
Verbindung
Blockgröße
Local
100Mb LAN
10Mb LAN
Internet2
0 Bytes1
.27 ms
.37 ms
1.64 ms
2.00 ms
CORBA (Orbacus ORB)
1 kB
8 kB
128 kB
3.5 MB/s 18.2 MB/s 51.2 MB/s
1.6 MB/s
5.7 MB/s
9.6 MB/s
363 kB/s
846 kB/s
796 kB/s
37 kB/s
72 kB/s
355 kB/s
1 MB
32.1 MB/s
8.8 MB/s
780 kB/s
358 kB/s
TCP
8 kB
99.2 MB/s
10.2 MB/s
820 kB/s
381 kB/s
Tabelle 8.1: CORBA Transferraten für verschiedene Datenmengen, verglichen mit einer
entsprechenden TCP/IP Verbindung.
Zu Beginn der Arbeiten, als der FE-Solver PAM-CRASH noch keine CORBA Schnittstelle hatte, wurde für Testzwecke eine Software namens PamServer entwickelt. PamServer
ist eine eigenständige Anwendung, die über das Dateisystem mit einem laufenden PAMCRASH Simulationsprozess kommuniziert oder die Ergebnisse einer kompletten Simulation
einliest, und nach außen hin einen CORBA Server mit entsprechender Schnittstelle darstelllt (Abb. 8.3).
FE Solver
(PAM−CRASH)
(Child−)
PamServer
z.B.
shutdown
Postproc Datei
Daten−Puffer
Signal
Datei
Corba−Server
Int
ern
et
Current
State
Viewer
Methoden−
Aufruf
Ergebnis
(Daten)
Corba
Client
PAM−File−Interface (PamServer)
Abbildung 8.3: Der PamServer simuliert ein CORBA-fähiges PAM-CRASH
1
2
Reiner Methodenaufruf in Millisekunden.
Beispielwerte, gemessen im deutschen Wissenschaftsnetz zwischen Erlangen und St. Augustin bei Bonn
8.4 Vorbereitende Arbeiten
123
Ziel des PamServer ist es, die Implementierung eines CORBA-Clients im Visualisierungstool zu ermöglichen und zu testen, noch bevor PAM-CRASH eine CORBASchnittstelle besitzt. So konnte die Machbarkeit des Vorhabens demonstriert werden, und
zur Implementierung einer CORBA-Schnittstelle in PAM-CRASH übergegangen werden.
Das wesentliche Merkmal des PamServers ist, dass er eine CORBA-Schnittstelle für eine
nicht CORBA-fähige Anwendung bereitstellt. PamServer ist also ein CORBA-Wrapper für
diese Anwendung. Zusätzlich kann der PamServer Cache-Funktionalität bereitstellen, so
dass er Daten, die vor kurzem benötigt wurden, oder die voraussichtlich bald benötigt
werden, im Speicher bereit hält.
Die Ergebnisdaten von PAM-CRASH können nur mit einer proprietären Softwarebibliothek, der DAISY-Libray, gelesen werden. PamServer liest die Daten mit Hilfe dieser
Bibliothek von der Festplatte, entweder gleich beim Start des PamServers oder, je nach
Konfiguration, erst wenn eine Anfrage (CORBA-Request) eintrifft.
Die CORBA-Schnittstelle des PAM-Servers ist an die Schnittstelle der DAISYBibliothek angelehnt, da beide Schnittstellen einem ähnlichen Zweck dienen. Der Datentransfer geschieht durch eine Gruppe von Methoden, welche Felder von Fließkommawerten
oder ganzen Zahlen zurückliefern oder Informationen über die Eigenschaften des Datensatzes. So können beispielsweise die Koordinaten aller Knoten zu einem bestimmten Simualtionszeitschritt mit einem Methodenaufruf übertragen werden, ebenso die Liste aller
Knoten, die Liste aller Elemente eines Typs, sowie Topologieinformationen, aus denen hervorgeht, aus welchen Knoten jedes Element besteht. Außerdem kann vorab die Anzahl der
Elemente und Knoten erfragt werden, um der anfragenden Anwendung die Möglichkeit zu
geben, den nötigen Speicherplatz bereitzustellen.
Das Visualisierungstool liest in der Regel alle oder eine Auswahl der Zeitschritte, welche
PAM-CRASH abgespeichert hat. Diese Zeitschritte können dann in Form einer dreidimensionalen, animierten Geometrie mit Hilfe des Visualisierungstools dargestellt und analysiert
werden.
Je nach Konfiguration schreibt der FE-Solver PAM-CRASH zusätzlich verschiedene Variablen für jeden Knoten oder für jedes Element in die Ergebnisdatei, z.B. Beschleunigungen, Kräfte usw. Diese können ebenfalls über die CORBA-Schnittstelle des PAM-Servers
übertragen werden.
Während dem Simulationslauf konnten bisher Befehle an PAM-CRASH nur mittels
einer Signal-Datei übergeben werden. Eine Datei, welche beispielsweise aus dem Wort
“QUIT” besteht, veranlasst das vorzeitige Beenden der Simulation. Eine Signal-Datei,
welche den Inhalt “PLOT” hat, bewirkt das Schreiben des aktuellen Zeitschrittes und
den dazugehörigen Ergebnissen in eine Datei.
Normalerweise speichert PAM-CRASH Zwischenergebnisse (Zeitschritte, states), auch
wegen den großen Datenmengen, nur in relativ großen Zeitintervallen ab. Für die Auswertung am Ende der Simulation sind diese Zeitintervalle ausreichend. Wenn man jedoch den
124
Integration
aktuellen Stand der laufenden Simulation beurteilen will, wird ein aktueller Zeitschritt in
einer eigenen Datei abgelegt.
Der PamServer kann über seine CORBA Schnittstelle die Anforderung nach dem aktuellen Zeitschritt (current state) entgegennehmen. Er schreibt dann ein entsprechendes
Signal und wartet bis die Datei mit dem gewünschten Zwischenergebnis abgelegt wurde.
Anschliessend wird diese Datei so behandelt, als wäre sie ein eigenes Simulationsergebnis
mit nur einem Zeitschritt. Dazu wird ein eigener PamServer gestartet.
Das Starten eines neuen PamServers für jede Ergebnisdatei ist vor allem deshalb sinnvoll, um auf neue Anfragen aktuelle Zeitschritte liefern zu können, während gleichzeitig
noch frühere Anfragen mit konsistenen Daten versorgt werden. Das heißt, eine Anwendung, die begonnen hat, einen Zeitschritt einzulesen, muss auch weiterhin die Daten dieses
Schrittes erhalten, selbst wenn es inzwischen einen neuen aktuellen Zeitschritt gibt, der
vielleicht bereits an eine andere Anwendung übertragen wird.
8.5
Anbindung des Visualisierungstools an den FESolver
Die Erfahrungen mit dem PamServer waren positiv und brachten wertvolle Erkenntnisse
hinsichtlich einer direkten Anbindung des Visualisierungstools an den FE-Solver. Dennoch
gibt es einige Aspekte, die bei der direkten Anbindung zusätzlich zu beachten sind, oder
aufgrund der gewonnenen Erkenntnisse verbesert wurden.
8.5.1
Schnittstellengestaltung
Kohärenz
mit
Hinblick
auf
zeitliche
Wie beim PamServer gilt auch hier, dass ein konkurrierender Zugriff auf das aktuelle Zwischenergebnis möglich sein muss. Nun wird jedoch nicht ein neuer Prozess gestartet, sondern nur ein neuer Thread, um die Übertragung des Zwischenergebnisses zu gewährleisten.
Voraussetzung für dieses Vorgehen ist, dass sämtliche State-spezifischen Informationen atomar, d.h. mit einem einzigen CORBA-Methodenaufruf, übertragen werden können. Dazu
wurde eine entsprechende Datenstruktur PamState definiert, welche alle dazu notwendigen
Daten beinhaltet:
typedef sequence<float> floatseq; // ein Feld aus Fließkommazahlen
struct PamState { // beinhaltet alle Daten eines PAM-CRASH Zeitschrittes
// Zeitpunkt dieses Simulationsschrittes
float
time;
8.5 Anbindung des Visualisierungstools an den FE-Solver
125
// Koordinaten aller Knoten zu dem Zeitpunkt time
floatseq coords;
// Zusätzliche Variablen, falls angefordert, sonst leer
floatseq var;
};
Der folgende Ausschnitt zeigt die wichtigesten Methoden der CORBA-Schnittstelle zwischen Visualisierungstool und FE-Solver:
interface PamJob {
// Get Initial Geometry
void cGetParams(out long cNumNodes, out long cNumBeams...);
long
cGetNumMaterials()
raises (PamJobException);
floatseq cGetCoordsInitState()
longseq
cGetMatLabels()
longseq
cGetNodeLabels()
longseq
cGetBeamLabels()
longseq
cGetShellLabels()
longseq
cGetToolLabels()
longseq
cGetSolidLabels()
longseq
cGetBeams()
longseq
cGetShells()
longseq
cGetTools()
longseq
cGetSolids()
// Get DAISY States
long
cGetNumofDsyStates()
long
cGetNumCurrentDsyState();
PamState cGet1DsyState(inout PamVar cVar, in boolean cCoor,
in long cState);
// ...
};
Die erste Gruppe von Methoden (Abschnitt Initial Geometry) liefert Daten, die im
zeitlichen Verlauf der Simulation gleich bleiben. Die zweite Gruppe von Methoden (Abschnitt DAISY States) liefert die eigentlichen Ergebnisse der Simulation. Durch die atomare
Übertragung aller zu einem Zeitschritt gehörenden Daten wird deren zeitliche Kohärenz
sichergestellt.
8.5.2
Besonderheiten beim Verbindungsaufbau
Bevor eine CORBA Kommunikation stattfinden kann, müssen die vorhandenen CORBA
Server-Objekte durch den ORB auffindbar sein. Dazu benötigt der ORB Information über
126
Integration
Adresse und Port des Rechners, und die eindeutige ID eines jeden Objektes. Aus diesen
Informationen generiert der ORB eine Objekt-Referenz, welche wie ein Zeiger für lokale
und entfernte Objekte in gleicher Weise verwendet werden kann.
Für die Übermittlung der Information zum Auffinden der Server-Objekte gibt es verschiedene Möglichkeiten:
1. Die Information wird in eine Zeichenkette umgewandelt und an die Clientapplikation übermittelt. Die Übermittlung erfolgt auf herkömmliche Weise, z.B. über ein
gemeinsames Dateisystem, FTP, Email, usw.
2. Jedes Server-Objekt meldet sich bei dem CORBA Naming Service an, der von den
CORBA Client Objekten abgefragt werden kann. Voraussetzung ist, dass ein CORBA
Nameserver permanent läuft und erreichbar ist. Die Referenz des Nameservers wird
erstmalig wie bei Punkt 1 übermittelt.
3. Verschiedene proprietäre Mechanismen: Die CORBA Implementation Visibroker beispielsweise stellt einen sogenannten Smart Agent zur Verfügung. Wie der Naming
Service dient auch der Smart Agent dem Auffinden von CORBA Objekten, letzterer
ist jedoch wesentlich einfacher zu handhaben.
Variante 1 ist relativ umständlich und eher für Testzwecke oder seltene Verwendung
geeignet. Variante 2 wird in der Praxis häufig verwendet. Jedoch ist auch hier eine entsprechende Konfiguration auf Clientseite nötig, und vor allem ist, wie auch bei Variante 3,
die ständige Verfügbarkeit einer zentralen Komponente unabdingbar.
Jede zentrale Komponente stellt wiederum eine Gefahr für die Verfügbarkeit des Gesamtsystems dar. Selbst wenn der Nameserver einwandfrei seinen Dienst tut ist ein Problem mit dem zugrundeliegenden Rechnersystem nicht vollständig auszuschließen. Auch
muss damit gerechnet werden, dass eine CORBA-Serverapplikation sich beim Beenden
nicht ordnungsgemäß abmeldet, und so die Information des Nameservers inakurat wird.
Aus diesen Gründen wurde bei bei der Anbindung des Visualisierungstools an den
FE-Solver ein anderer Weg gewählt: Eine bereits vorhandene zentrale Komponente, das
Job Management System Codine, verwaltet die CORBA Referenzen der PAM-CRASH
Jobs. Da Codine bereits Informationen über die aktuellen Jobs hat, bereitet das Verwalten
einer CORBA Referenz, dargestellt durch eine Zeichenkette, keinen großen Aufwand. Die
Integrationsplattform CAE-Bench, die mit Codine kommuniziert, übermittelt die CORBA
Referenz an das Visualisierungstool (Abbildung 8.4).
8.6
Einbettung des Visualisierungstools in die Integrationsplattform
In Abschnitt 2.1 wurde bereits dargestellt, dass die CAE Prozesskette eine Vielzahl von
Prozessen und verschiedene Tools umfasst, die zusammenarbeiten müssen. Traditionell
8.6 Einbettung des Visualisierungstools in die Integrationsplattform
127
wird jedes dieser Tools separat gestartet und hat eine eigenständige Umgebung. Die Abarbeitung dieser Kette ist für den Berechnungsingenieur zeitaufwändig.
Die Web-basierte Integrationsplattform CAE-Bench dient dazu, die Arbeitsabläufe bei
der Crash-Simulation zu automatisieren, die anfallenden Daten zu verwalten, und so den
Entwicklungsprozess zu beschleunigen. Außerdem wird mit Hilfe der Integrationsplattform
eine einheitliche Bedienoberfläche für alle an der Crash-Simulation beteiligten Anwendungen bereitgestellt. Dies reduziert den Einarbeitungsaufwand und trägt damit zur Zeit- und
Kostenersparnis bei.
Die zentrale Software-Komponente von CAE-Bench hat einerseits Zugriff auf die Bauteildatenbank (PDM, Product Data Management), andererseit stellt sie einen Web Server
zur Verfügung. Über diesen können die dynamisch erstellten CAE-Bench Web Seiten vom
Benutzer in einem normalen Web-Browser geladen werden. Die Web Seiten enthalten kontextabhängige Informationen und Bedienelemente in Zusammenhang mit den aktuellen
Arbeitsabläufen. Durch Einbetten von Javascript Code in die Web Seiten wird ein Teil der
CAE-Bench Funktionalität auf Client-Seite, also beim Benutzer, ausgeführt.
Mit CAE-Bench werden Kommandozeilen-orientierte Benutzerschnittstellen von Anwendungen und Stapelverarbeitungsprozesse auf eine Web-basierte, und daher graphische
und einheitliche Bedienoberfläche abgebildet. Einige Anwendungen, speziell Visualisierungstools, haben bereits eine graphische Oberfläche, welche insbesondere das 3D-Fenster,
Visualisierung
PAM−CRASH
FE−Solver
launch,...
Corba
Client
Corba
Server
Befehle
Corba
Client
FE−Daten
Corba ID
launch,...
Codine
CAE−Bench
Corba Layer
GUI im Web−Browser
Job Management
Berechnungsumgebung
Benutzerumgebung
Abbildung 8.4: Zusammenspiel der Komponenten bei der Crash-Visualisierung
128
Integration
in dem das Ergebnis der Visualisierung dargestellt wird, umfasst. Auch die Bedienung solcher Tools lässt sich mit CAE-Bench vereinheitlichen. Hierzu kommen zwei Möglichkeiten
in Frage:
1. die gesamte Oberfläche des Visualisierungstools in eine CAE-Bench Web-Seite einbetten
2. das Visualisierungstool wie bisher in einem eigenen Fenster laufen lassen, und über
CAE-Bench ansteuern
Die erste Variante würde ein Umschreiben der gesamten Anwendung als Browser-Plugin
oder als Java 3D Anwendung erfordern. Die zweite Variante hat hingegen den Vorteil, dass
die Anwendung auch unabhängig von CAE-Bench ausgeführt, bedient und weiterentwickelt
werden kann.
Bezüglich der Kommunikation zwischen Visualisierungstool und CAE-Bench fiel die
Entscheidung zugunsten von CORBA, als plattformunabhängige, objektorientierte Middleware. In diesem Zusammenhang wurde, nach der Schnittstelle zu PAM-CRASH, eine
CORBA Schnittstelle des Visualisierungstools zu CAE-Bench realisiert.
Hierbei bieten sich wiederum zwei Möglichkeiten an:
1. das Visualisierungstool kommuniziert direkt mit der zentralen CAE-Bench WebServer Komponente
2. das Visualisierungstool kommuniziert mit der Client-seitigen CAE-Bench Komponente, also mit der Web-Seite, welche die Benutzeroberfläche darstellt.
Bei der ersten Variante müsste für jeden Benutzer eine eigene Visualisierungs-Sitzung
verwaltet werden. Die CAE-Bench Web-Seite enthält bereits die nötigen benutzerspezifischen Informationen. Somit fiel die Entscheidung zugunsten der zweiten Variante, welche
gleichzeitig ein sinnvolles modulares Design im Sinne der Client-Server-Technologie darstellt.
Allerdings ist es nicht möglich, mit einer Web-Seite direkt über CORBA zu kommunizieren. Diese Funktion übernimmt daher ein im Rahmen der vorliegenden Arbeit entwickeltes
Java Applet, welches in die CAE-Bench Web-Seiten eingebettet wird. Das Java Applet
beinhaltet sowohl einen CORBA Client, als auch einen CORBA Server. Durch den Server
kann das Visualisierungstool sich bei dem Applet anmelden und seine CORBA Referenz
bekanntgeben. Die dazu benötigte CORBA-Referenz des Applets wird beim Aufruf des Visualisierungstools aus dem Applet heraus als Kommandozeilenparameter übermittelt. So
lässt sich auch hier der Einsatz eines Nameservers oder anderer umständlicher Prozeduren
vermeiden.
Als CORBA Client kann das Applet Methoden der CORBA/IDL Schnittstelle des
Visualisierungstools aufrufen und so Befehle übergeben und Informationen abrufen. Somit
8.6 Einbettung des Visualisierungstools in die Integrationsplattform
129
stellt das Applet eine Art Fernsteuerung dar; das Visualisierungstool muss dabei nicht
unbedingt auf dem gleichen Rechner laufen. Das Java Applet hat eine eigene graphische
Benutzeroberfläche und kann daher auch unabhängig von CAE-Bench benutzt werden.
In CAE-Bench eingebettet, wird das Java Applet über Javascript Methoden der CAEBench Web Seite angesprochen, ein Mechanismus, der als LiveConnect bezeichnet wird.
So stellt das Applet das Bindeglied zwischen CAE-Bench und dem Visualisierungstool dar
(Abbildung 8.5).
Damit eine CORBA Verbindung mit einem Java Applet möglich ist, muss noch ein weiterer Aspekt beachtet werden: Jedes Applet läuft in einer sogenannten Sandbox, d.h. es darf
normalerweise keine Operationen ausführen, welche die Systemsicherheit gefährden könnten. Erst wenn ein Applet als vertrauenswürdig eingestuft ist, etwa weil es signiert ist, oder
weil der Benutzer dem Applet bestimmte Rechte eingeräumt hat, ist eine Kommunikation
möglich.
Bei früheren Java-fähigen Web Browsern wurden die Rechte des Applets vom Browser
verwaltet, und die Mechanismen der Rechtevergabe waren uneinheitlich, und mussten bei
der Implementierung des Applets berücksichtigt werden. Aktuell werden die Rechte von
der Java Laufzeitumgebung verwaltet, also unabhängig vom verwendeten Web Browser.
Sofern das Applet in eine CAE-Bench Web Seite eingebettet ist, dient es vor allem der
Kommunikation zwischen CAE-Bench und Visualisierungstool. Die graphische Oberfläche
des Applets wird nicht zwingend benötigt und kann auf Wunsch auch versteckt werden.
Jedoch kann das Applet auch zur Anzeige von Informationen verwendet werden: Nachdem
das Visualisierungstool als Prozess aus dem Applet heraus gestartet wird, kann dieses
Web Browser / Web Seite
CAE-Bench
Web Server
HTTP
HTML &
JavaScript
LiveConnect
Visualisierungstool
PDMDatenbank
Java Applet
CORBA
Abbildung 8.5: Anbindung des Visualisierungstools an CAE-Bench mit Hilfe eines Java
Applets
130
Integration
die Konsolenausgabe (stdout, stderr) des Tools abfragen und in einem Textfeld innerhalb
des Applets anzeigen (Abbildung 8.6). Damit wird kein zusätzliches Konsolenfenster mehr
benötigt.
Abbildung 8.6: Java-Applet (unten im Bild), eingebettet in eine CAE-Bench Web-Seite zur
Steuerung des Arbeitsablaufes bei der Crash-Simulation.
Kapitel 9
Gesamtbetrachtung der Prozesskette
In den vorigen Kapiteln wurden die verschiedenen, im Rahmen der vorliegenden Arbeit entwickelten Komponenten vorgestellt. An dieser Stelle soll nun anhand einer Beispielsitzung
ein Gesamtbild der Arbeitsabläufe bei der Crash-Simulation vermittelt werden.
Die Durchführung einer Crash-Simulation kann, in groben Zügen, wie folgt ablaufen:
• Der Berechnungsingenieur wählt in CAE-Bench die gewünschten Bauteile (Versionen), die in der PDM-Datenbank zur Verfügung stehen.
• Die Bauteile werden von einem speziellen Tool (Hypermesh) vernetzt und zu einem
Gesamtfahrzeug-Modell zusammengesetzt.
• Falls verfügbar, werden Verbindungselemente aus der Datenbank in CAE-Bench eingelesen.
• Das Visualisierungstool (FEMod, früher CrashViewer) wird aus der Integrationsumgebung heraus gestartet. Das Fahrzeugmodell und die Verbindungselemente werden
geladen, auf Konsistenz geprüft, und dargestellt.
• Preprocessing wird durchgeführt. Dies impliziert z.B.:
– Der Berechnungsingenieur kann ein Bauteil in der 3D-Darstellung markieren
und weitere Informationen zu diesem Bauteil bei CAE-Bench anfordern. Die
Bauteil-ID wird dazu mit Hilfe der CORBA-Verbindung vom Visualisierungstool
an CAE-Bench gereicht
– Stellt sich bei der 3D-Visualisierung heraus, dass ein Bauteil durch eine andere Version ersetzt werden soll, kann dies mit Hilfe der Integrationsumgebung
veranlasst werden. CAE-Bench bereitet daraufhin eine Liste kompatibler Bauteilvarianten vor, aus welcher ein neues Bauteil ausgewählt werden kann. Das
132
neue Bauteil wird dann in das Visualisierungstool geladen, und ersetzt die alte Variante. Verbindungselemente können dabei, falls gewünscht, übernommen
werden. Entstehen beim Ersetzen inkonsistente Verbindungselemente, werden
diese automatisch markiert und können durch den Benutzer korrigiert werden.
– Auf ähnliche Art können Bauteile des Fahrzeugmodells entfernt werden, wenn
sie für das Simulationsergebnis nicht signifikant sind, oder neue Bauteile und
Bauteilgruppen via CAE-Bench hinzugefügt werden, um die Simultionsgenauigkeit zu erhöhen.
– Weitere Preprocessing Operationen können durchgeführt werden, wie z.B. das
Beseitigen von Perforationen und Penetrationen, das Definieren neuer Verbindungselemente, oder das Verändern von Bauteilen.
– Im Rahmen des Massentrimms werden schliesslich die strukturlosen Massen aus
der PDM-Datenbank mit Hilfe der Integrationsumgebung dem Fahrzeugmodell
im Visualisierungstool hinzugefügt. Diejenigen Bauteile, deren Geometrie bei
der Crash-Simulation von geringer Bedeutung ist, können mit Hilfe des Visualisierungstools in strukturlose Massen umgewandelt werden. Das beschleunigt die
Simulation und reduziert die anfallenden Datenmengen.
• Im Anschluss an das Preprocessing wird das Fahrzeugmodell aus dem Visualisierungstool mittels CAE-Bench abgespeichert und die Finite-Elemente-Simulation wird gestartet. Das Scheduling und Monitoring des laufenden Simulationsprozesses geschieht
mit Hilfe der speziellen Job Management Software Codine.
• Während der Simulation kann das aktuelle Zwischenergebnis abgerufen und visualisiert werden. Sind keine neuen Ergebnisse zu erwarten, kann die Simulation vorzeitig
beendet werden und mit veränderten Ausgangsdaten neu aufgesetzt werden.
• Nach erfolgreicher Simulation wird das Ergebnis ausgewertet. Dazu werden die gespeicherten Schritte der Simulation dreidimensional animiert dargestellt. Lokale Größen
wie Beschleunigungen und Kräfte können mit Hilfe von Farben auf der Bauteiloberfläche oder mit Hilfe von Zusatzgeometrie visualisiert werden. All dies kann sowohl
am Arbeitsplatzrechner geschehen als auch in einer Virtual-Reality-Umgebung.
• Erfüllt das Ergebnis der Simulation die Sicherheitskriterien, können die Fahrzeugprototypen für die gesetzlich vorgeschriebenen realen Crash-Tests erstellt werden.
Verlaufen diese Tests erfolgreich, und dies ist nach den durchgeführten Simulationen
zu erwarten, so kann mit der Serienproduktion begonnen werden.
• Entspricht das Ergebnis der Crash-Simulation nicht den Sicherheitsanforderungen,
wird der Simulationszyklus erneut durchlaufen: kleinere Änderungen werden durch
den Berechnungsingenieur direkt am FE-Modell durchgeführt, für weitreichendere
Modifikationen wird die CAD-Abteilung beauftragt. Anschliessend wird die Simulation erneut durchgeführt und ausgewertet. Je früher die Unzulänglichkeiten des
133
Fahrzeugmodells entdeckt werden, desto einfacher und damit billiger ist die Korrektur. Besonders kostspielig sind Schwachstellen, die erst beim realen Crash-Test
deutlich werden. Aufgrund der guten Simulationsgenauigkeit sind diese Fälle heute
eher selten.
Ein Ziel der zukünftigen Entwicklung besteht darin, die Anzahl der Simulationen zu
reduzieren, indem das Modell schneller gegen die endgültige Version konvergiert. Ein vielversprechender Ansatz besteht darin, Informationen aus den bereits durchgeführten Simulationen so auszuwerten, dass die Ergebnisse zukünftiger Simulation zumindest teilweise
vorausgesagt werden können. Der Berechnungsingenieur soll zu diesem Zweck verstärkt
durch rechnergestütztes Data Mining und Data Management unterstützt werden.
134
Kapitel 10
Zusammenfassung und Ausblick
In dieser Arbeit wurde eine Reihe von neuen Verfahren erarbeitet, welche den Berechnungsingenieur bei der Durchführung von Crash-Simulationen unterstützen. Die hier vorgestellten Verfahren liefern einen wichtigen Beitrag zur Verkürzung der Zeit für die Vorbereitung
und Auswertung einer Crash-Simulation (Abb. 10.1). Zum anderen wird die Qualität der
Crash-Simulation durch verbesserte Aufbereitung der Daten (Preprocessing) gesteigert.
So wird insbesondere beim automatischen Setzen von Schweißpunkten entlang von Flan-
Abbildung 10.1: Verkürzung der Entwicklungszeiten in der Karosserieentwicklung
136
Zusammenfassung und Ausblick
schen dem Ingenieur viel Routinearbeit abgenommen. Die rechnerunterstützte Visualisierung und Beseitigung von Perforationen bietet wiederum völlig neue Möglichkeiten zur
Korrektur fehlerhafter Eingabedaten für die Crash-Simulation.
Ebenfalls neu ist die Möglichkeit der Modifizierung der Bauteilgeometrie direkt am
Finite-Elemente Modell, wodurch sich eine Vereinfachung der Prozesskette ergibt. Der Umweg über die CAD-Abteilung und die Neuvernetzung des geänderten Bauteils ist nun nicht
mehr nötig.
Die Unterstützung des Massentrimms durch Visualisieren, Editieren und Berechnen
der strukturlosen Massen direkt innerhalb der 3D-Darstellung des FE-Modells stellt sowohl eine quantitative als auch eine qualitative Verbesserung dieses Vorgangs dar, d.h. der
Massentrimm wird effizienter und fehlerfreier durchgeführt.
Einen wichtigen Beitrag zur effizienten und fehlerfreien Durchführung von CrashSimulationen stellt auch die Integrationsplattform dar. Die CORBA-basierte Anbindung
des Visualisierungs- und Modellierungstools an CAE-Bench und an PAM-CRASH erlaubt
nun eine einheitliche und einfache Benutzerführung.
Basierend auf den bisherigen Erfahrungen können für die Zukunft bereits einige Weiterentwicklungen vorhergesehen werden. Durch die zunehmende Rechenleistung, sowie durch
neue und verbesserte Algorithmen werden auch in Zukunft immer mehr Routineaufgaben
bei der Crash-Simulation automatisch durchgeführt.
Durch die verbesserte Rechenleistung wird der Zeitaufwand für die eigentliche Simulation immer weiter gesenkt. Mit Hilfe mit einer intelligenten automatischen Auswertung
bisheriger Simulationen (Data Mining) könnte die Neuberechnung der Simulation auf die
geänderten Bereiche beschränkt werden. So würde aus dem heutzutage noch mehrere Stunden oder gar Tage dauerndenden Vorgang ein interaktives Verfahren, das Zusammenhänge
zwischen Karosseriebeschaffenheit und Crashverhalten sofort verdeutlicht.
Im Bereich des Preprocessing sind für die Zukunft ebenfalls einige Weiterentwicklungen,
im Großen sowie im Detail, denkbar. Beispielsweise könnte kontextsensitive Information
über die Art des gerade bearbeiteten Bauteils in das Preprocessing einfließen. Diese Information würde in einer erweiterten Bauteildatenbank bereitgehalten. Insbesondere Bauteilverbindungen können so schneller und qualitativ hochwertiger durchgeführt werden. Aber
auch im Bereich der Geometriemodifikationen könnte aus der unendlichen Vielfalt der
Möglichkeiten die Gruppe der sinnvollen Änderungen vorweg ausgefiltert werden. Damit
verringert sich der Aufwand beim Editieren des Modells.
Ein nächster Schritt wäre die automatische Anpassung der Fahrzeugkarosserie, um die
gewünschten Eigenschaften zu erhalten. Voraussetzung hierfür ist allerdings, dass es gelingt,
noch mehr Expertenwissen vom Menschen auf den Rechner abzubilden. Expertensysteme
und künstliche Intelligenz sind zwar keine neuen Fachgebiete, den großen Durchbruch hat es
bislang jedoch nicht gegeben. Dennoch besteht die Hoffnung, mit Hilfe neuer Technologien,
z.B. neuronale Netze oder genetische Algorithmen, das Anwendungsgebiet maschineller
Rechenleistung zu erweitern.
Abstract
This research elaborates new approaches to support car body developers in preparing the
input and analyzing the output of car crash simulations. The presented work is based on
a visualization software tool, which allows a virtual-reality-like user interaction. Several
features were implemented to facilitate various kinds of modifications on the finite element
data used as input for the crash simulations. Further, the visualization software was embedded into a new, web-based integration environment, by means of a Java applet and by
using CORBA middleware.
Most of the research presented here was supported by the BMBF (Bundesministerium
für Bildung und Forschung, Federal Ministry for Education and Research). The research
was done in the context of the two projects AutoBench and AutoOpt. Participants of
these projects are the University of Stuttgart and the Fraunhofer-Gesellschaft (FHG), three
german car manufacturers, like BMW, and various software suppliers of the automotive
industry.
The features described in this text were implemented within a protoypical visualization
tool called CrashViewer. Already in the prototype stage, the tool was heavily used at
the car body design department of the car manufacturer BMW. Especially the automatic
recognition of flanges and the automatic generation of spotweld lines found broad approval.
Recently, the visualization tool prototype was transformed into a commercial product by
the company science+computing and is currently sold under the name FEMod.
Scenario
In the automotive industry crash safety is a major concern when designing a new car. The
increasing pace at which new products are brought on the market requires a continuous
improvement of the development cycle, in order to stay competitive.
Evaluating the crash behaviour of a car body is a difficult task. The traditional approach
consists in crash tests. These tests are expensive and time-consming especially due to the
car prototypes being built for each test.
138
Abstract
A modern approach consists in crash simulations performed on the computer. The
simulations are cheaper and faster than the real tests. Only a small number of real tests
are performed for validating the simulation results and due to the legal requirements.
Car crash simulations are based on the widely used Finite Elements Method (FEM). In
order to use this approach, the CAD geometry data must be discretized, i.e. transformed
into small elements, called the finite elements. In the prevalent case of plate components,
for numerical reasons, the finite elements are mostly quadrilaterals.
Before the finite element mesh can be used for crash simulations, a variety of modifications may be necessary. Eventually, inconsistencies like penetrations and perforations need
to be eliminated, component links need to be defined and so on. The research presented
here led to various features of the visualization tool in order to support the simulation
engineer in pre-processing the FE data. Furthermore, the integration environment optimizes the workflow, relieving the engineer of routine activities and providing a uniform user
interface for the several software tools involved in the workflow.
Penetrations and Perforations
Penetrations and Perforations are mesh inconsistencies caused by the discretization of
initially non-penetrating smooth surfaces from the CAD geometry data. Another possible
cause is the incompatibility of neighbouring components, e.g. when testing a new version
of a component.
Plate components are represented geometrically as a median surface with no thickness.
The plate thickness, however, is a known parameter of the component and is taken into
account within the crash simulation. Penetrations are regions where two components are
closer to each other than the average of their plate thickness. Penetrations lead to initial
forces within the FE model. They can falsify the simulation result.
Perforations are locations where the medial surfaces of two components intersect each
other. Penetrations are at latest removed during the simulation run after some timesteps
due to the repelling forces, while perforations persist throughout the simulation run. Therefore, the absence of perforations is a precondition for the crash simulation. Moreover, the
penetration removal algorithm works only on perforation-free data.
Perforations and penetrations can be efficiently detected by using a bounding volume
hierarchy. The hierarchy eliminates the need of testing each finite element against each
other, which is computationally very expensive (O(n2 )). By grouping the elements spatially
in bounding volumes, only those element pairs have to be tested, which are contained in
overlapping bounding volumes on the lowest level of the hierarchy. At the higher levels, only
those branches with overlapping volumes need to be descended further. The complexity is
therefore O(log(n)2 ).
Abstract
139
Penetrations and perforations are visualized by color mapping on the material surface.
Color mapping can be done by using textures, which are a feature of modern graphics hardware, so that no additional geometry needs to be rendered and the graphics performance
is not affected.
Penetration removal is performed by an iterative procedure. The directions of the repelling forces are established, before the penetrating nodes and the penetrated elements
are moved in opposite directions by a small amount. The movement has to be done by
small amounts, because the directions of the forces acting on the mesh may vary, and removing the penetration at once may produce penetrations or even perforations with other
elements.
When removing perforations, the perforating nodes are projected onto the perforated
surface and then moved some small amount further in the direction of projection. This
transforms the perforation into a penetration which can be removed by the penetration
removal algorithm mentioned before.
Situations exist, where it can not automatically be determined in which direction the
perforating node has to be moved or which part of the intersecting component lies on the
wrong side. In these cases, the user gives supplementary information by clicking with the
mouse in order to specify a surface normal along which the perforating node is moved,
respectively a point which is known to be on the wrong side.
Perforation removal may sometimes lead to some distortions in the mesh. Though the
shape of the component is still okay, some finite elements might be stretched or squeezed
becoming irregular. For numerical reasons, irregular elements are undesirable in the simulation input. Therefore, a mesh relaxation algorithm was implemented. The mesh relaxation
algorithm moves the mesh nodes within the surface iteratively, as if the neighbouring nodes
were connected by arcs of equal length. To obtain not only edges of similar length, but
also similar angles, the element diagonals also have to be considered as being connected
through arcs. Since corner nodes are not moved and nodes on an edge are just moved along
that edge, the shape of the car component is nearly preserved during mesh relaxation.
Connecting Car Components
Connections between car components can be realized within the FE model through FE
mesh nodes which belong to several car components. With this approach, however, a change
in one car component requires to completely remesh the whole model.
In order to avoid this problem, a transition took place towards independently meshed
assembly parts a few years ago. This way, only those components modified since the meshing
of the FE model need to be remeshed. The remeshing of the whole model due to some minor
changes is not necessary anymore.
140
Abstract
To assemble the components, special link elements have been introduced. The prevalent
link type is the point link, which usually is realized by a spotweld.
In the early development stage, the CAD component data do not provide link information. For performing crash simulation in this early stage, it is necessary to define links
manually. A way to define links consists in editing the data file manually, since the data file
is in human-readable ASCII format. A much more comfortable way is provided by the FE
visualization and modification tool FEMod. The user can point with the mouse to locate
the desired spotweld position and create a new spotweld or delete an existing one.
In most of the cases, links are placed along special regions called flanges. Flanges are
regions where two components are (quite) parallel to each other and close to each other.
Components are usually connected through spotweld lines along flanges.
Within the scope of this dissertation, a flange recognition functionality was developed,
which allows to connect two car components by automatically generating and positioning
a set of point links. This way, the user is released from the task of defining each point
link one by one. The algorithm can also be used to automatically place surface links, like
adhesive bondings, along a flange.
The flange detection algorithm is based on a kind of breadth-first graph search. Starting
from a given point, a growing neighbourhood of flange elements is collected using a FIFO
queue. Flange element criteria are based on the distance to the other component, which is
going to be connected, as well as on the surface normal deviation at the connection point,
which is a measure for the parallelism of the two surfaces. When a second user-specified
flange element is encountered, a shortest path between the start and the target element
can be reconstructed. In this case, only the desired part of the flange is linked. When
no target element is given, the flange is sought in both longitudinal directions until the
farthest elements are found. In this case, the whole flange will be linked.
In order to compute the positions of the link elements, the middle line of the flange
must be computed first, which can be done based on the previously computed element
path. Hereby, the semi-regular structure of the FE mesh is exploited, observing that the
edges of the flange’s finite elements are usually aligned with the flange. Therefore, the
quadrilateral elements of the path can be used to start searching in four directions for the
nearest flange borders. The two nearest flange borders define a segment of the middle line.
In the rare cases where the nearest flange borders cannot be found this way, e.g. when a
triangular element or a sharp turn of the flange lead to ambiguities, this part of the middle
line can be successfully interpolated through a straight line.
Free-Form Deformations of the FE Mesh
Besides the penetration and perforation removal, sometimes a more general mesh editing
feature is desired. This is the case when the influence on crash behavior of some alternative
Abstract
141
geometry is going to be examined. Another example is the adaptation of non-matching
parts in an early development stage, in order to start a crash simulation.
The highest level of flexibility in mesh editing is granted by the independent positioning
of arbitrary mesh nodes. This approach, however, is only feasible for very small corrections,
because it is laborious and imprecise.
Free-Form Deformation (FFD), in contrast, is a spline-based approach for deforming
three-dimensional objects. The object is embedded in a spline volume, which can be deformed by means of spline control points. The embedded object is deformed accordingly,
taking advantage of the spline’s continuity properties, in order to obtain a smooth deformation. Handling the large number of control points in such a spline volume represents a
drawback of this approach. The Direct Manipulation of FFD (DMFFD) approach eliminates the problem by computing the control point positions automatically. The user does
not even need to see the control points. He can specify one or several points on the object
and new positions for these points. The object then deforms in such a way, that the given constraints are fulfilled, i.e. the specified points move to their new positions while the
surface deforms smoothly.
Within the scope of this research, the DMFFD approach has been adapted and improved
for better performance and usability. The new approach was implemented and tested within
the visualisation tool. Through the use of a certain spline type, it was possible to embed
only the region under deformation, instead of the whole object (i.e. the car component or
car model), within the spline volume. This reduces the computational cost, and it was also
a precondition for the deformation operations to become independent from each other.
In the traditional DMFFD, the whole sequence of deformations is performed on the
same, more and more distorted, global mesh. With the local FFD approach presented in
this work, each single point constraint is performed independently, and the special spline
type (B-splines over a uniform knot vector, without multiple knots at the ends) grants a
smooth transition to the undeformed region. Due to the local mesh, there is no dependance
on previous deformations that were performed on the object, therefore each deformation
has a similar behaviour. Furthermore, the spline control mesh must not be preserved or
saved to file.
It can be shown that every deformation described by a multiple point constraint is also
achievable by sequencially applying a series of single-point constrained deformations. The
goal to keep the user interface simple can therefore be achieved by focusing on single-point
constraints.
The effect of a single point constraint is a smooth bump, similar to the effect of hitting
the real plate component with a soft rubber hammer. This fact has been exploited in order
to keep the user interface intuitive and simple. The user can specify with the mouse cursor
the point to be “hit“, and press a key, e.g. 1 to 9, in order to exactly define the desired
deformation amount. This user interface design facilitates fast and precise interaction.
142
Abstract
The deformation direction by default is the local normal at the hit point, but any other
direction can be specified as deformation direction, e.g. by saving the normal of an arbitrary point, or by sequentially specifying two arbitrary points of the model. Deformation
directions which are tangential to the surface are also possible. They can be specified for
example by projecting a previously determined direction onto the surface under the cursor.
Mass Trim
During a crash simulation, the geometry of some components, like the battery or the wires,
has no significant influence. Only the weight and the position of their mass matters. To
reduce the data amount, and to simplify and accelerate the simulation and visualization this
way, such components are not represented geometrically. Instead, their mass is distributed
among the surrounding components, so that the center of mass remains unchanged.
In the present research, a visualization approach for unstructured masses has been
elaborated. The non-structural mass is hereby represented through a glyph consisting of a
sphere and three bars. The sphere position visualizes the center of the mass, the volume
of the sphere is proportional to the mass amount. The bars´ orientation show the main
inertia axes. The corresponding moments of inertia are proportional to the bar length. A
text label displayed near the glyph shows the actual data values of the nonstructural mass.
Furthermore, functionality for distributing the mass among other components is provided. Also, a (structural) component can be converted into a non-structural mass. The
inertia properties are then automatically computed.
Integration Platform
The engineer performing crash simulations has to deal with a multitude of software tools.
He has to select the appropriate model and/or component versions from the PDM (Product
Data Management) database, he has to mesh the CAD data with some meshing tool, and
he has to make corrections and modifications on the mesh using one ore more other tools.
Then, he performs the simulation with the finite element solver, and he analyses the results
with some visualization tool(s). Each of these tools has a different user interface, requiring
some accomodation or learning process. Each tool reads and writes several files in various
file formats.
A solution for the problems described above is possible by means of an integration
platform, which provides a uniform user interface for several tools and manages the data
transfer between them. A web-based integration platform called CAE-Bench is currently
employed at BMW and other car manufacturers. The embedding of the FE visualization
Abstract
143
tool into this integration platform was realized within the scope of the research presented
here.
The adaptation of the visualization tool to the web-based user interface of the integration platform was achieved by means of a Java applet. The Java applet is embedded into
web pages generated by the CAE-Bench server. The embedding web page communicates
through Javascript with the applet. The Java applet passes the commands and parameters
to the visualization tool using the CORBA (Common Object Request Broker) protocol.
Information from the visualization tool are also passed back to CAE-Bench via the applet. An appropriate IDL (Interface Definition Language) interface has been defined and
implemented in both the applet and the visualization tool.
CORBA, as an object-oriented, platform and language independent protocol for interapplication (client/server) communication, is used to perform communication locally as
much as over a network, like the internet. A so-called IDL (Interface Definition Language)
compiler transforms the interface definition into machine-generated program code for both
the client and the server. IDL compilers are available for a multitude of programming
languages. This way, CORBA assures significant portability and interoperability.
Besides the user interface, the data transfer between the simulation and the visualization
tool is also realized with CORBA. Although the simulation writes intermediate results to
a file (about one per hour), the CORBA connection allows fast and transparent access to
the latest results, without the detour via disk files. The access to the running simulation
makes it possible to early recognize if the simulation will not lead to valuable results, and
to abort the simulation in this case. This feature is called steering of the simulation.
144
Abstract
Literaturverzeichnis
[1] 3Dlabs Inc. Ltd. OpenGL 2.0 white papers.
http://www.3dlabs.com/support/developer/ogl2.
[2] Virginie Amar and Alain Zarli. Linking STEP and CORBA standards for applications
interoperability. In Distributed Applications and Interoperable Systems (DAIS), pages
169–184, 1997.
[3] Virginie Amar, Alain Zarli, Philippe Debras, and Patrice Poyet. Distributing STEP
models with CORBA. In Proceedings of International Symposium on Global Engineering Networking, pages 79–96, 1997.
[4] AVS. Advanced Visual Systems Web Page. http://www.avs.com.
[5] Chandrajit L. Bajaj, editor. Data Visualization Techniques. Wiley, 1999.
[6] Alan H. Barr. Global and local deformations of solid primitives. In Computer Graphics,
volume 18, pages 21–30. ACM SIGGRAPH, 1986.
[7] Fintan Bolton. Pure Corba. Sams, 2001.
[8] Ken W. Brodlie. Scientific Visualization. Springer, 1992.
[9] Gerald Brose, Andreas Vogel, and Keith Duddy. Java Programming with CORBA.
John Wiley & Sons, 2001.
[10] Phong Bui-Tuong. Illumination for Computer Generated Pictures. CACM, 18(6):311–
317, 1975.
[11] Edwin Catmull. A subdivision algorithm for Computer Display of Curved Surfaces.
PhD thesis, Computer Science Department, University of Utah, Salt Lake City, Dezember 1974. Report UTEC-CSc-74-133.
[12] Edwin Catmull and Raphael Rom. A class of local interpolating splines. Computer
Aided Geometric Design, pages 317–326, 1974.
146
LITERATURVERZEICHNIS
[13] Francis Chin, Jack Snoeyink, and Cao An Wang. Finding the Medial Axis of a Simple
Polygon in Linear Time. In Proceedings of the 6th Annual International Symposium
on Algorithms and Computation (ISAAC 95), pages 382–391, 1995. Lecture Notes in
Computer Science 1004.
[14] Clint Chua and Ulrich Neumann. Hardware-accelerated free-form deformation. In
Proceedings of the ACM SIGGRAPH/EUROGRAPHICS workshop on Graphics hardware, pages 33–39. ACM Press, 2000.
[15] Sabine Coquillart. Extended free-form deformation: a sculpturing tool for 3d geometric
modeling. In Proceedings of the 17th annual conference on Computer graphics and
interactive techniques, pages 187–196. ACM Press, 1990.
[16] Carl de Boor. On calculating with B-splines. Journal of Approximation Theory, 6:50–
62, 1972.
[17] Carl de Boor. A practical guide to splines. Springer-Verlag, New York, 1978.
[18] Carl de Boor and Klaus Höllig. B-splines without divided differences. In Geometric Modelling – Algorithms and New Trends, pages 21–27. Society for Industrial and
Applied Mathematies (SIAM), 1987.
[19] Gerald Farin. Curves and Surfaces for Computer Aided Geometric Design. Academic
Press, 4th edition, 1997.
[20] Gerald Farin and Daniel Jung. Linear precision of rational Bezier curves. Computer
Aided Geometric Design, 12:431–433, 4 1995.
[21] James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. Computer
Graphics – Principles and Practice. Addison-Wesley, 1992.
[22] Tomas Forkert, Hans-Peter Kersken, Andreas Schreiber, Martin Strietzel, and Klaus
Wolf. The Distributed Engineering Framework TENT. In Proceedings of Vector and
Parallel Processing - VECPAR 2000, pages 38–46, 2000.
[23] Norbert Frisch and Thomas Ertl. Embedding Visualisation Software into a Simulation Environment. In Proceedings of the Spring Conference on Computer Graphics,
Bratislava, pages 105–113, 2000.
[24] Norbert Frisch and Thomas Ertl. Deformation Of Finite Element Meshes Using Directly Manipulated Free-Form Deformation. In Proceedings of Seventh ACM Symposium
on Solid Modeling and Applications 2002, pages 249–256, 2002.
[25] Norbert Frisch, Dirc Rose, Ove Sommer, and Thomas Ertl. Pre-processing of Car
Geometry Data for Crash Simulation and Visualization. In Proceedings of WSCG’01,
pages 25–32, 2001.
147
[26] Norbert Frisch, Dirc Rose, Ove Sommer, and Thomas Ertl. Visualization and Preprocessing of Independent Finite Element Meshes for Car Crash Simulations. The
Visual Computer, 18(4):236–249, 2002.
[27] James E. Gain and Neil A. Dodgson. Preventing self-intersection under free-form
deformation. IEEE Transactions on Visualization and Computer Graphics, 7(4):289–
298, 2001.
[28] Gesellschaft für Mathematik und Datenverarbeitung. Der GMD Spiegel: Perspektiven
der Informationstechnik, volume Ausgabe 3/4. GMD, 1998.
http://www.gmd.de/de/gmd-spiegel.html.
[29] Gesellschaft für Mathematik und Datenverarbeitung. Der GMD Spiegel, Schwerpunkt Simulation, volume Ausgabe 1/2. GMD, 2000. http://www.gmd.de/de/gmdspiegel.html.
[30] William R. Gordon and Richard F. Riesenfeld. B-Spline curves and surfaces. Computer
Aided Geometric Design, 1974.
[31] S. Gottschalk, M. C. Lin, and D. Manocha. OBBTree: a hierarchical structure for rapid
interference detection. In Proceedings of the 23rd annual conference on Computer
graphics and interactive techniques, pages 171–180. ACM Press, 1996.
[32] Dietmar Gross, Werner Hauger, Walter Schnell, and Peter Wriggers. Technische Mechanik, Band 3: Kinetik. Springer Verlag, 1999.
[33] Paul S. Heckbert, editor. Graphics Gems IV, chapter I.4. Point in Polygon Strategies.
Academic Press, 1994.
[34] Michi Henning and Steve Vinoski.
Addison-Wesley, 2001.
Advanced CORBA Programming with C++.
[35] Ewald Hessel. Simulation in der Fahrzeugtechnik. ASIM Nachrichten, deutschsprachige Ergänzung zu SNE EUROSIM Simulation News Europe, pages 3–4, November
1999.
[36] Hochleistungsrechenzentrum Stuttgart HLRS. Covise Web Page.
http://www.hlrs.de/organization/vis/covise.
[37] Michael Holzner, Touraj Gholami, and Horst-Uwe Mader. Virtuelles Crashlabor: Zielsetzung, Anforderungen und Entwicklungsstand. In VDI Berichte 1411: Berechnungen
im Automobilbau, Tagung Würzburg. VDI Gesellschaft Fahrzeug und Verkehrstechnik
Düsseldorf, September 1998.
[38] William M. Hsu, John F. Hughes, and Henry Kaufman. Direct manipulation of freeform deformations. Computer Graphics, 26:177–184, 1992.
148
[39] Shi-Min Hu, Hui Zhang, Chew-Lan Tai, and Jia Gua. Direct manipulation of FFD:
efficient explicit solutions and decomposible multiple point constrains. The Visual
Computer, 17(6):370–379, August 2001. Springer.
[40] Christopher Johnson, Steven G. Parker, Charles Hansen, Gordon L. Kindlmann, and
Yarden Livnat. Interactive Simulation and Visualization. Computer, 32(12):59–65,
1999.
[41] Michael Jung and Ulrich Langer. Methode der finiten Elemente für Ingenieure. Teubner Verlag, 2001.
[42] Brian W. Kernighan and Dennis M. Ritchie. The C Programming Language. Prentice
Hall, 1988.
[43] H.-P. Kersken, A. Schreiber, R. Heinrich, E. Kügeler, A. Mack, J. Neumann, and
R. Schäfer. TENT – Eine Softwareintegrationsumgebung für multidisziplinäre Simulationen. In DGLR Jahrestagung, 2002.
[44] Leif Kobbelt. Discrete Fairing. In Proceedings of the Seventh IMA Conference on the
Mathematics of Surfaces, pages 101–130, 1997.
[45] Leif Kobbelt. Discrete fairing and variational subdivision for freeform surface design.
The Visual Computer, 16(3-4):142–158, 2000.
[46] Leif Kobbelt, Thilo Bareuther, and Hans-Peter Seidel. Multiresolution shape deformations for meshes with dynamic vertex connectivity. Computer Graphics Forum,
19(3):C249–C260, 2000.
[47] Leif Kobbelt, Stephan Bischoff, Kolja Kähler, Robert Schneider, Mario Botsch, Christian Rössl, and Jens Vorsatz. Geometric modeling based on polygonal meshes. Research Report MPI-I-2000-4-002, Max-Planck-Institut für Informatik, 2000.
[48] Leif Kobbelt, Swen Campagna, Jens Vorsatz, and Hans-Peter Seidel. Interactive multiresolution modeling on arbitrary meshes. In Computer Graphics, volume 32, pages
105–114. ACM SIGGRAPH, 1998.
[49] Jan Kraheberger. Interaktive Aufbereitung von vorvernetzten Bauteilgeometrien für
die Fahrzeugberechnung. Diplomarbeit, Lehrstuhl für Graphische Datenverarbeitung,
IMMD IX, Universität Erlangen, Oktober 1998.
[50] Florian Kramer. Passive Sicherheit von Kraftfahrzeugen. Vieweg Verlag, 1998.
[51] Sven Kuschfeldt. Effiziente Visualisierungsverfahren zur besseren Erfassung von
Crash-Simulationen im Fahrzeugbau. PhD thesis, Universität Erlangen, 1998.
149
[52] Sven Kuschfeldt, Thomas Ertl, and Michael Holzner. Efficient visualization of physical
and structural properties in crash-worthiness simulations. In Yagel, R. and Hagen, H.,
editor, Visualization ’97 Proceedings, pages 487–490. IEEE Computer Society Press,
1997.
[53] Sven Kuschfeldt, Michael Holzner, Ove Sommer, and Thomas Ertl. Efficient Visualization of Crash-Worthiness Simulations. IEEE Computer Graphics and Applications,
18:60–55, 1998.
[54] Apostolos Lerios, Chase D. Garfinkle, and Marc Levoy. Feature-based volume metamorphosis. In Proceedings of the 22nd annual conference on Computer graphics and
[55] Erik Lindholm, Mark J. Kligard, and Henry Moreton. A user-programmable vertex engine. In Proceedings of the 28th annual conference on computer graphics and
[56] Ron MacCracken and Kenneth I. Joy. Free-form deformations with lattices of arbitrary
topology. In Proceedings of the 23rd annual conference on Computer graphics and
[57] Gerhard Merziger and Thomas With. Repetitorium der höheren Mathematik. Binomi,
1995.
[58] Michael E. Mortenson. Computer Graphics Handbook – Geometry and Mathematics.
Industrial Press Inc., 1990.
[59] Thomas J. Mowbray and Raphael C. Malveau. CORBA Design Patterns. John Wiley
& Sons, 1997.
[60] NAG. IRIS Explorer Web Page. http://www.nag.co.uk/Welcome− IEC.html.
[61] Gregory M. Nielson, Hans Hagen, and Heinrich Müller. Scientific Visualization: Overviews, Methodologies, and Techniques. IEEE Computer Society, 1997.
[62] Robert A. Noble and Gordon J Clapworthy. Direct Manipulation of Surfaces using
NURBS-Based Free-Form Deformations. In Proceedings of the International Conference on Information Visualization, pages 238–243, 1999.
[63] Object Management Group. Common Object Request Broker Architecture: Core
Specification. Technical report, OMG, 2002.
[64] Volker Padur and Andreas Schreiber. TENT - Eine Integrations- und Testumgebung
für Simulation und Visualisierung. In Proceedings of the 12th Conference on Simulation and Visualization (SimVis), 2001.
150
[65] Steven G. Parker, Christopher Johnson, and David Beazley. Computational Steering Software Systems and Strategies. IEEE Computational Science & Engineering,
4(4):50–59, 1997.
[66] Les Piegl and Wayne Tiller. The NURBS Book. Springer, 2nd edition, 1997.
[67] Alfred Renyi. Wahrscheinlichkeitsrechnung. VEB Deutscher Verlag der Wissenschaften, 1962.
[68] Christof Rezk-Salama, Michael Scheuering, Grzegorz Soza, and Günther Greiner. Fast
volumetric deformation on general purpose hardware. In Proceedings of the ACM SIGGRAPH/EUROGRAPHICS workshop on on Graphics hardware, pages 17–24. ACM
Press, 2001.
[69] Richard F. Riesenfeld. Applications of B-spline Approximation to Geometric Problems
of Computer-Aided Design. PhD thesis, Syracuse Univ., 1973.
[70] Dieter Roller. CAD – Effiziente Anpassungs- und Variantenkonstruktion. Springer,
1995.
[71] Dirc Rose, Norbert Frisch, Thomas Rühr, and Thomas Ertl. Interaktive Visualisierung
neuer Elemente im virtuellen Automobil-Crashversuch. In Tagungsband SimVis ’02,
Magdeburg, pages 215–223, 2002.
[72] Lawrence J. Rosenblum, editor. Scientific Visualization: Advances and Challenges.
Academic Press, 1994.
[73] I.J. Schoenberg. Contributions to the problem of approximation of equidistant data
by analytic functions. Quarterly of Applied Mathematics, 4:45–99, 1946.
[74] Andreas Schreiber. The Integrated Simulation Environment TENT. Concurrency and
Computation: Practice and Experience Vol. 14, Grid Computing environments Special
Issue 13-14, 2002.
[75] Hans Rudolf Schwarz. Methode der finiten Elemente. Teubner Verlag, 1991.
[76] Thomas W. Sederberg and Scott R. Parry. Free-Form Deformation of Solid Geometric
Models. Computer Graphics, pages 151–160, August 1986.
[77] Robert Sedgewick. Algorithms in C++, Parts 1-4. Addison-Wesley, 1998.
[78] John Siegel. Quick Corba 3. John Wiley & Sons, 2001.
[79] Silicon Graphics Inc. OpenGL Performer. http://www.sgi.com/software/performer.
[80] Silicon Graphics Inc. Cosmo3D Programmer’s Guide, 1997.
151
[81] Silicon Graphics Inc. OpenGL Optimizer Programmer’s Guide: An Open API for
Large-Model Visualization, 1998. http://www.sgi.com/software/optimizer.
[82] Ove Sommer and Thomas Ertl. Geometry and Rendering Optimization for the Interactive Visualization of Crash-Worthiness Simulations. In Proceedings of the Visual
Data Exploration and Analysis Conference in IT&T/SPIE Electronic Imaging, pages
124–134, Januar 2000.
[83] Ove Sommer and Thomas Ertl. Comparative Visualization of Instabilities in CrashWorthiness Simulations. In Procceedings of EG/IEEE TCVG Symposium on Visualization VisSym ’01, pages 319–328,364, 2001.
[84] Bjarne Stroustroup. The C++ Programming Language. Addison-Wesley, 1997.
[85] Gabriel Taubin. A signal processing approach to fair surface design. In Computer
Graphics, volume 29, pages 351–358. ACM SIGGRAPH, 1995.
[86] Clemens-August Thole (Hrsg.). AUTOBENCH: Integrierte Entwicklungsumgebung
für virtuelle Automobil-Prototypen. GMD, Juli 2001.
http://www.gmd.de/publications/report/0145.
[87] Ruofeng Tong, Kazufumi Kaneda, and Hideo Yamashita. B-spline free-form deformation of polygonal object as trimmed Bézier surfaces. The Visual Computer, 18(8):493–
510, 2002.
[88] Hank Weghorst and Donald P. Greenberg. Improved Computational Methods for Ray
Tracing. ACM Transactions on Graphics (TOG), 3(1):52–69, 1984.
[89] Eric Weisstein. Concise Encyclopeida of Mathematics. CRC Press, 2003.
[90] Josie Wernecke. The Inventor Mentor. Addison-Wesley, 1994.
http://www.sgi.com/software/inventor.
[91] Rüdiger Westermann and Thomas Ertl. Efficiently using graphics hardware in volume
rendering applications. In Proceedings of the 25th annual conference on Computer
graphics and interactive techniques, pages 169–177. ACM Press, 1998.
[92] George Wolberg. Digital Image Warping. IEEE Computer Society, 1990.
[93] Mason Woo, Jackie Neider, Tom Davis, and Dave Shreiner. OpenGL Programming
Guide. Addison-Wesley, 1999.
[94] Stefan Zachov. Modellierung von Weichgewebe - Simulation von Deformation und
Destruktion - Neue Möglichkeiten in der computergestützten Chirurgie. Shaker Verlag,
1998.
152
[95] A. Zarli, V.Amar, F. Diard, M. Marache, and P. Poyet. Bridging the gap between
STEP, CORBA and virtual reality technology for the next Building Industry applications generation. In Proceedings of the 4th International Conference on Concurrent
Enterprising (ICE), pages 219–229, 1997.
[96] Alain Zarli and Virginie Amar. Integrating STEP and CORBA for applications interoperability in the future virtual enterprises computer-based infrastructures. In
Proceedings of IASTED International Conference on Intelligent Information Services,
pages 309–315, 1997.
Danksagung
An dieser Stelle möchte ich mich bei all jenen bedanken, die mich während der Arbeiten
zu dieser Dissertation unterstützt haben. In erster Linie möchte ich meinem Doktorvater,
Prof. Dr. Thomas Ertl danken. Er hat mich in dieser Zeit geduldig motiviert, beraten und
ermutigt.
Bei meiner Frau Anca möchte ich mich bedanken für ihre moralische Unterstützung.
Sie hat mir viel Kraft gegeben.
Es war die Uni Erlangen, an der diese Arbeit begonnen wurde. Vielen Dank an die
damaligen Kollegen, Matthias Hopf, Christian Teitzel, Kai Horman, Katja Daubert, um nur
einige zu nennen. Es war eine schöne Zeit und ich werde die gemeinsamen Küchendienste
nicht vergessen.
Ich wohnte noch in München, als Martin Schulz mich über die zu besetzende Promotionsstelle benachrichtigte. Ich bin ihm dankbar für diesen Hinweis, ohne den meine
Dissertation wohl nicht entstanden wäre.
Nach neun Monaten in Erlangen ging es dann nach Stuttgart. Vielen Dank dem gesamten Team, das von Erlangen nach Stuttgart zog, für die gute Gesellschaft.
In Stuttgart kamen dann weitere Kollegen hinzu. Insbesondere an Dirc Rose, Martin
Rotard, Simon Stegmaier und Kathrin Bidmon vielen Dank für die angenehme Zusammenarbeit.
Dank gebührt auch Herrn Horst-Uwe Mader von der Firma BMW, der mit seiner
freundlichen Art das Feedback und die Bedürfnisse der Anwender übermittelte und so
die Praxistauglichkeit meiner Arbeit sicherstellte.
Ulrike Ritzmann, Hermann Kreppein und Martin Schmidt ebenfalls vielen Dank für
die rasche Hilfe bei diversen technischen Problemen. Ove Sommer danke ich für die gute
Zusammenarbeit und für seine Hilfsbereitschaft. Für die Beiträge ihrer Studienarbeiten
danke ich Thomas Piekarski und Jens Künzl. Schließlich danke ich auch allen anderen, die
mich unterstützt haben, und die hier nicht namentlich erwähnt sind.

Verfahren zur Unterstützung der Arbeitsabläufe bei der Crash

Transcrição

Documentos relacionados

Aufgabenbeschreibung Simulator - Institut für Wissenschaftliches

SPS-Programmierer / in

7.¨Ubung ” Nebenläufige und verteilte Programmierung“

Aktueller Kursflyer - Food

plecs workshop

Gottes Wirken in meinem Leben

Frauenleiden intim (März 2013)

Mediengestalter/in Digital und Print (Konzeption u. Visualisierung)

Knoten für jedes FW-Mitglied - Kreisfeuerwehrverband Hersfeld

PDF / 33 kB - Forschungszentrum Jülich