Der gemeinsame Abschlussbericht des Verbundprojektes "viprof" beschreibt die Entwicklung einer durchgängigen, digitalisierten und kooperativen Entwicklungs- und Produktionsplanung in der Automobilindustrie, um den Herausforderungen des globalen Wettbewerbs zu begegnen. Das Projekt konzentrierte sich auf die Verknüpfung der Simulationen für Umformen, Fügen und Lackieren, um die Effekte der Fertigungshistorie auf die Produkteigenschaften in der Crash-Simulation zu bewerten. Gefördert durch das Bundesministerium für Bildung und Forschung beinhaltete das Vorhaben die Zusammenarbeit verschiedener Partner und zielte auf die Verbesserung von Datenmanagement und Prozessintegration ab.

1. Gemeinsamer FuE-Abschlussbericht des Verbundprojektes
„Durchgängige Virtualisierung der Entwicklung und Pro-
duktion von Fahrzeugen (VIPROF)“
Förderkennzeichen: 02PC1090 bis 1097
Autoren:
Dr.-Ing. Cord Steinbeck-Behrens, Tobias Menke (CADFEM GmbH)
Jochen Steinbeck, Matthias Schroeder, Hongzhi Duan (ESI GmbH)
Alexander Hoffmann, Uwe Brylla (ARC Solutions GmbH)
Dr.-Ing. Steffen Kulp, Sebastian Pinner (Volkswagen AG)
Prof. Dr.-Ing. Martin Rambke, Lena Leck (Ostfalia HaW)
Prof. Dr.-Ing. Birgit Awiszus, Dr.-Ing. Susanne Bolick, Jeannette Katzenberger (TU
Chemnitz)
Marcel Schulz (TU Berlin)
Dr.-Ing. Christoph Runde, Achim Czaykowska (VDC Fellbach)
Dr.-Ing. Klaus Mager (Ingenieurbüro Mager, Unternehmensberatung)
Januar 2012

2. Inhaltsverzeichnis
1 Einführung, Motivation und Zielstellung ............................................................... 4
2 Ablauf des Vorhabens ......................................................................................... 9
3 Lösungsansätze, durchgeführte Arbeiten und Teilergebnisse ........................... 12
3.1 Überblick Prozesskettensimulation .............................................................. 12
3.2 Datenübertragung in der Prozesskette (Ostfalia HaW) ................................ 13
3.2.1 Simulationsprogramme in der Prozesskette .......................................... 13
3.2.2 Mapping ................................................................................................. 14
3.2.3 Sensitivitätsanalyse ............................................................................... 24
3.3 Teilprozesskette Umformen und Fügen (ESI) .............................................. 29
3.3.1 Simulation der Bauteilerzeugung mittels Umformen .............................. 29
3.3.2 Methode der Neuvernetzung ................................................................. 30
3.3.3 Untersuchte Baugruppe ......................................................................... 33
3.3.4 Sensitivität der Datenübergabe in Relation zur Netzfeinheit .................. 34
3.3.5 Simulation des Schweißverzugs mit dem Weld Planner ........................ 37
3.3.6 Sensitivität des Schweißverzugs hinsichtlich der aus der
Fertigungshistorie übertragenen Größen ............................................... 38
3.3.7 Schweißverzugssimulation mit der Methode der Neuvernetzung .......... 42
3.4 Simulation der Lacktrocknung in der Prozesskette (CADFEM) .................... 43
3.4.1 Ergebnisse der Sensitivitätsanalyse ...................................................... 44
3.4.2 Untersuchung von Einflüssen des Bake-Hardening-Effektes ................ 49
3.4.3 Zusammenfassung der Ergebnisse von CADFEM ................................ 53
3.5 Abgleich der Simulationsprozesskette an Praxisbeispielen (VW) ................ 55
3.5.1 Katalog gewerkespezifischer Eingangsgrößen ...................................... 55
3.5.2 Übertragung von Simulationsdaten mit XML-Konverter ......................... 56
3.5.3 Vergleich OneStep- und inkrementelle Umformsimulation .................... 61
3.5.4 Bewertung der Prozesskettensimulation................................................ 66
3.5.5 Validierung der Prozesskettensimulation ............................................... 73
3.5.6 Modulcockpit.......................................................................................... 76
3.6 Strukturierte Ablage heterogener Daten im Kontext von
Wiederverwendbarkeit und Weiterverwendbarkeit (TU Berlin) .................... 78
3.6.1 Allgemeines ........................................................................................... 78
3.6.2 Konversion............................................................................................. 79
3.6.3 Das VIPROF-XML-Datenformat ............................................................ 82
3.6.4 Funktionsweise und Begrenzungen des XML-Konverters ..................... 89
2

3. 3.7 Entwicklung einer systemübergreifenden Datenablage im PDM-System
zur Realisierung einer durchgängigen Simulationsprozesskette
(TU Chemnitz, ARC Solutions GmbH) ......................................................... 92
3.7.1 Problemstellung und Ziele ..................................................................... 92
3.7.2 Durchgängiges Datenmanagement ....................................................... 93
3.7.3 Entwicklung von Datenablagestrukturen................................................ 96
3.7.4 Ableitung von Referenzprozessketten zur Datenablage ...................... 105
3.7.5 Automatisierung von Referenzprozessketten mittels Workflows ......... 108
3.7.6 Kopplung der Prozesssimulation Umformen – Fügen – Lackieren ...... 113
3.7.7 VIPROF Modulcockpit zur Erhöhung der Transparenz im
Entwicklungsprozess ........................................................................... 114
3.8 Perspektiven des Mittelstands (VDC) ........................................................ 117
4 Zusammenfassung der Ergebnisse ................................................................. 121
4.1 Bewertung der Ergebnisse ......................................................................... 121
4.2 Darstellung der durchgängigen Simulationsprozesskette VIPROF
anhand eines Anwendungsbeispiels .......................................................... 124
5 Ausblick ........................................................................................................... 131
5.1 Ausblick Volkswagen ................................................................................. 131
5.2 Transfer der Ergebnisse von CADFEM...................................................... 132
5.3 Transfer der Ergebnisse von ESI für Zulieferer mit VisualDSS .................. 134
5.4 Ausblick der ARC Solutions GmbH ............................................................ 136
5.5 Ausblick der Ostfalia HaW ......................................................................... 136
5.6 Datentechnischer Ausblick der TU Berlin ................................................... 137
5.7 Ausblick Professur Virtuelle Fertigungstechnik .......................................... 137
6 Öffentlichkeitsarbeit ......................................................................................... 139
Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesmi-
nisteriums für Bildung und Forschung im Programm „Management und Virtualisie-
rung der Produktentstehung” im Rahmenkonzept „Forschung für die Produktion von
morgen“ gefördert und unter der Projektträgerschaft des Karlsruher Instituts für
Technologie (KIT) durchgeführt. Die Verantwortung für den Inhalt dieser Veröffentli-
chung liegt bei den Autoren.
3

4. 1 Einführung, Motivation und Zielstellung
Wie auch andere Branchen, die sich im globalen Wettbewerb befinden, ist die Auto-
mobilindustrie mit ihren komplexen Produkten steigenden Kundenanforderungen,
einem hohen Kostendruck, kürzer werdenden Produktlebenszyklen und einer Zu-
nahme an Produktvarianten ausgesetzt. Gerade die steigenden Anforderungen an
Verbrauchseffizienz und CO2-Reduzierung werden zukünftig verstärkt zu weiteren
Fahrzeugvarianten mit alternativen Antrieben sowie Leichtbaukarosserien führen. Die
Abbildung 1 verdeutlicht, dass der Trend der kontinuierlichen Zunahme der Fahr-
zeugsegmente von 1985 bis heute ungebrochen ist. [PINSB11]
Abbildung 1: Anstieg der Fahrzeugsegmente seit 1985 [PINSB11]
Um die mannigfaltigen Anforderungen zu erfüllen, sind neue Strategien in der Pro-
duktentwicklung erforderlich. Dazu zählen u.a. verschiedene Strategien zur Gleichtei-
lenutzung in der Pkw-Karosserie. Während man früher eine reine Plattformstrategie
verfolgte, setzt man heute schon verstärkt auf Module (Lenkung, Motor, Getriebe,
Interieur), die über verschiedene Fahrzeugklassen eingesetzt werden. Für die Zu-
kunft wird das Ziel verfolgt, diese Strategie weiter auszubauen und zu einer reinen
Modulstrategie, z. B. Modularer Diesel Baukasten oder modularer Vorderwagen etc.,
überzugehen. Die Module bilden dabei einen Baukasten mit kombinierbaren Elemen-
ten. Die Standardisierung für Produkt und Prozess sichert die konzernweite Kompati-
4

5. bilität ab. Somit soll ein maximales Maß an Synergien erzielt werden (siehe Abbil-
dung 2). [PINSB11]
Abbildung 2: Übergang von der Plattform zur Modulstrategie [PINSB11]
Um die Komplexität, die aus dieser Strategie erwächst, zukünftig noch beherrschen
zu können, müssen vor allem Techniken und Strategien zum Produktdatenmanage-
ment weiterentwickelt werden. Weiterhin muss im verstärkten Maße auf eine virtuelle
Produktabsicherung entlang der Prozesskette gesetzt werden.
Die Absicherung der Produkteigenschaften erfolgt entsprechend der Entwicklungs-
disziplinen (Aufbau, Aggregate, Fahrwerk, etc.) mit unterschiedlichen Simulations-
methoden. Eine virtuelle Absicherung der Herstellbarkeit entlang der Produktions-
prozesskette (Einzelteil, Karosseriebau, Lackierung) findet nachfolgend in den Pla-
nungsbereichen statt (siehe Abbildung 3). Durch die vornehmlich disziplinorientierte
Arbeitsweise und eine fehlende Transparenz erfolgt die belastbare Validierung der
Herstellbarkeit in der Regel erst nach der maßgeblichen Produktgestaltung. Weiter-
hin ist ein prozessübergreifender Ergebnistransfer (Umformung, Fügen, Lackierung)
auf Grund fehlender Schnittstellen und methodischen Unterschieden in den Prozess-
simulationen bisher nicht möglich. Darüber hinaus werden fertigungstechnische Ein-
flüsse auf die Produkteigenschaften (insbesondere die Crash-Performance) immer
noch nicht detailliert erfasst und während der Produktentwicklung berücksichtigt.
[PIN109]
5

6. Aufbau Aggregate Fahrwerk …..
Entwicklungsdisziplinen
Crash Betriebsfestigkeit Aerodynamik
Virtuelle
Produktentwicklung
Steifigkeit Aeroakustik ......
Simulationsmethoden Produktentwicklung
Produktlastenheft, Konstruktionsdaten, Stücklisten etc.
Umformsimulation Fügesimulation Lackiersimulation
Virtuelle
Prozessabsicherung Ergonomiebetrachtung Gießsimulation ......
Simulationsmethoden Prozessabsicherung
Umformprozesse Karosseriebau Lackierung Montage
Abbildung 3: Virtuelle Produktentwicklung und Prozessabsicherung [PIN109]
In den letzten Jahren hat neben der Automatisierung in vielen Bereichen der Produk-
tionstechnik das Engineering mit CAE-Werkzeugen (Computer Aided Engineering)
Einzug gehalten. Für die Entwicklung und Planung von Produkten, Maschinen und
Anlagen sind leistungsfähige Methoden und Softwareapplikationen entstanden. Ge-
rade kritische Bereiche, wie z. B. Festigkeitsbetrachtungen, Umformtechnik, thermi-
sche Belastungen oder Schweißanwendungen, sind inzwischen durch Simulations-
werkzeuge abgedeckt, mit denen virtuell Optimierungen vorgenommen werden kön-
nen. Somit sind CAE-Technologien nicht als Neuerung zu betrachten, da sie in vielen
Bereichen der Produktentstehung als Einzelanwendung bereits integriert sind. Je-
doch handelt es sich meist um isolierte Insellösungen, die einen bestimmten Prob-
lembereich behandeln, und nicht um durchgängige Planungsinstrumente. [PIN109]
Es fehlt insbesondere eine auf der Informations- und Kommunikationstechnologie
(IKT) basierte Verknüpfung zwischen der Konstruktion und Entwicklung auf der einen
Seite und der Fertigungsplanung auf der anderen Seite. Bisher können Daten zwi-
schen den Simulationsprogrammen für einzelne Prozesse meistens nur von Hand
übertragen werden. Übertragungs-Tools – wenn überhaupt vorhanden – verbinden
maximal zwei Glieder der Simulationskette, wie z. B. der SCAI-Mapper zwischen Um-
form- und Crash-Simulation. Automatische Verknüpfungen dieser Werkzeuge, die
zumeist von unterschiedlichen Herstellern stammen, gibt es kaum. Strategien zur
Datenhaltung im Sinne des Produktdatenmanagements befinden sich noch im For-
schungsstadium. In der Folge können bisher Änderungen, die sich in einem Bereich
6

7. ergeben, nur mit hohem Aufwand in anderen Bereichen berücksichtigt werden. Da
prozessübergreifende Werkzeuge fehlen, können Fehler in der Produktentwicklung
nach wie vor erst spät aufgedeckt werden und verursachen hohe Kosten. [PIN109]
Daher bestand das Ziel des Projekts „VIPROF“ in der Verknüpfung von Produktent-
wicklung und Fertigungstechnik zu einer durchgängigen, digitalisierten und koope-
rativen Entwicklungs- und Produktionsplanung. Ein besonderer Schwerpunkt wurde
auf die durchgängige Verknüpfung der Simulationen des Umformens, Fügens und
Lackierens gelegt. Die Auswirkungen der Berücksichtigung der Fertigungshistorie auf
die Produkteigenschaften sollten in der Crash-Simulation bewertet werden.
Am Projekt haben die folgenden Partner teilgenommen:
Partner / Profil Beitrag im Projekt
CADFEM GmbH Koordination des Verbundprojektes, Integration der Lackier-
(Software-Haus) trocknungssimulation VPS/DRY in die Prozesskettensimula-
tion
ESI GmbH Integration der Umform- und Fügesimulation in die Prozess-
(Software-Haus) kettensimulation
ARC Solutions GmbH Implementierung von Daten- und Variantenmanagement,
(Dienstleister) Umsetzung des Workflow-Managements
VW AG Erstellung Lastenheft, Erprobung und Validierung der Pro-
(Anwender) zesskettensimulation
ITP Ostfalia HaW Umformsimulation, Mapping zwischen den Prozessen, Ab-
(F&E) gleich OneStep Solver zur inkrementellen Simulation, Er-
probung
Professur Virtuelle Entwicklung der Referenzprozesse und –modelle
Fertigungstechnik
(VIF) der TU Chemnitz
(F&E)
Institut für Wirtschafts- Entwicklung Datenarchitektur, Datenmodellierung und -
informatik und integration, Schnittstellenkonzeption, Datenmapping, Stan-
Quantitative Methoden dardisierung der Simulationsdaten
der TU Berlin (F&E)
VDC Fellbach Analyse bei den meist mittelständischen Mitgliederfirmen zur
(Dienstleister) Bedarfslage hinsichtlich einer Prozesskettensimulation, Auf-
bau Web-Präsenz, Aufbau eines Industriearbeitskreises „Vir-
tualisierung“.
7

8. Literatur:
[PIN109] Pinner, S. et al.: Durchgängige Virtualisierung der Entwicklung
und Produktion von Fahrzeugen, Fachtagung Digitales Enginee-
ring, Fraunhofer Wissenschaftstage, 16.-18. Juni, Magdeburg,
2009.
[PINSB11] Pinner, S.; Steinbeck-Behrens, C.: Übersicht Prozesskettensimu-
lation. 2. VIPROF Industriearbeitskreis, 22. November, Stuttgart,
2011.
8

9. 2 Ablauf des Vorhabens
Das Vorhaben war in 12 Arbeitspakete (AP) eingeteilt, die in Tabelle 1 aufgeführt
sind. Ein Pert-Diagramm des Arbeitsplans mit einer Kennzeichnung der mehr daten-
oder mehr prozessbezogenen Arbeitspakete ist in Abbildung 4 gezeigt.
AP Titel Federführung Mitarbeit
1 Analyse des Ist-Zustandes VW Alle Partner
2 Untersuchung und Bewertung der Pro- IPT CADFEM, ESI,
zessgrößen in der Prozesskette VW
3 Aufbau Architektur für Daten- und Varian- TUB VIF, ARC, VW
tenmanagement
4 Kopplung der Prozesssimulationen Um- TUB Alle Partner
formen – Fügen – Lackieren
5 Implementierung Daten- und Varianten- ARC CADFEM, ESI,
management als VIPROF-Module VW, VIF, TUB
6 Bewertung der Ergebnisgüte VW CADFEM, ESI,
IPT
7 Definition von Referenzprozessen und VIF ARC, VW, IPT,
-modellen für durchgängige Prozesskette TUB, VDC
8 Erweiterung der Prozesskette mit komp- CADFEM ESI, ARC, IPT
lexen Modellen
9 Test und Validierung VW CADFEM, ESI,
ARC, VIF
10 Entwicklung VIPROF-Modulcockpit ARC VW, IPT, VIF, TUB
11 Verbreitung der Projektergebnisse VDC Alle Partner
12 Projektmanagement CADFEM Alle Partner
Tabelle 1: Übersicht der Arbeitspakete und der Verantwortlichkeiten
(IPT = Institut für Produktionstechnik der Ostfalia HaW,
VIF = Professur Virtuelle Fertigungstechnik, TU Chemnitz,
TUB = Institut für Wirtschaftsinformatik und Quantitative Methoden der TU Berlin)
9

10. 1. Analyse des 12. Projektmanagement
Ist-Zustandes
2. Untersuchung
/ Bewertung
Prozessgrößen
3. Aufbau 4. Kopplung der
Daten- Prozess-
architektur simulationen
5.Implementierung 6. Bewertung
VIPROF-Module Ergebnisgüte
8. Erweiterung
mit komplexen
7. Definition Modellen
11. Ver-
Referenzpro-
breitung
zesse und 9. Test und Vali- der Er-
-modelle dierung geb-
nisse
10. Entwicklung VI-
PROF-Modulcockpit
Abbildung 4: Pert-Diagramm des Arbeitsplanes (Daten – Prozesse)
Entsprechend der Einteilung „Daten“ und „Prozesse“ wurden zu Beginn des Projek-
tes die Arbeitsgruppe Daten (VW, ARC, VIF und TUB), die eine Bestandsaufnahme
des PDM-Systems durchführte, und die Arbeitsgruppe Mapping (CADFEM, ESI, VW
und IPT), die sich mit dem SCAIMapper1 und den Sensitivitätsanalysen (AP 2) be-
fasste, gegründet. Die Arbeitsgruppe Mapping verständigte sich darauf, den SCAI-
Mapper im VIPROF-Projekt einzusetzen. Das IPT stand hierzu im Kontakt mit dem
Fraunhofer SCAI-Institut, das sich bereit erklärte, projektspezifische Anpassungen
am SCAIMapper vorzunehmen.
1
Mit dem SCAIMapper können durch Modellinterpolation die Umform- und Crash-Simulation gekop-
pelt werden. Diese Software wurde vom Fraunhofer SCAI-Institut und dem ISD der Universität Stutt-
gart entwickelt.
10

11. Als Anwendungspartner lieferte die VW AG geeignete Musterbauteile (siehe Abbil-
dung 5) zur Bestandsaufnahme von Daten und Prozessen und zur späteren Validie-
rung der Prozessverkettung. Die notwendigen Bauteil- und Prozessdaten wurden von
VW erhoben. Den Partnern wurden die CAD-Daten und Prozessbeschreibungen für
die Musterbauteile zur Verfügung gestellt.
Abbildung 5: Musterbauteile des VW Touran
als Gegenstand der Prozesskettensimulation
Die Musterbauteile stammten vom Serienfahrzeug VW Touran GP. Die Teileauswahl
sollte eine Crash-relevante Baugruppe, jedoch keine warm umgeformten Bauteile
beinhalten. Die Auswahl fiel auf die Baugruppe B-Säule mit Schwellerverstärkung, da
nur dort Laserschweißverfahren eingesetzt werden. Der Sitzquerträger ist für die
Crash-Simulation relevant. Um den Schweißverzug zu analysieren, besteht bei VW
für die gewählte Baugruppe eine Messeinrichtung.
Die Verwendung von Teilen des Serienfahrzeuges Touran hatte einerseits den Vor-
teil, dass umfangreiche Daten und Prozesserfahrungen vorlagen, die an die Koope-
rationspartner weitergegeben werden konnten. Andererseits traten bei diesem schon
in Serie befindlichen Fahrzeug keine Schwachstellen auf, die durch die Prozessket-
tensimulation hätten aufgedeckt werden können, wie es bei Neukonstruktionen der
Fall wäre, da alle Teile auskonstruiert und getestet waren.
11

12. 3 Lösungsansätze, durchgeführte Arbeiten und Teiler-
gebnisse
3.1 Überblick Prozesskettensimulation
Im Rahmen der virtuellen Absicherung werden heute fertigungstechnische Einflüsse
auf die Produkteigenschaften noch nicht detailliert erfasst und während der Produkt-
entwicklung berücksichtigt. Die Herstellungsprozesse haben jedoch einen umfangrei-
chen Einfluss auf die Produkteigenschaften und müssen in der Simulation berück-
sichtigt werden, denn die Produkteigenschaften resultieren aus der Summe der
durchlaufenen Prozesse, welche sich gegenseitig überlagern und beeinflussen. Der-
artige Einflussgrößen für den Bereich Karosseriebau sind in Abbildung 6 dargestellt.
Abbildung 6: Einflussgrößen der Fertigungsprozesse
auf die Produkteigenschaften [PIN209]
Besonders Eigenspannungen und Verzug bedingen sich gegenseitig und können
sich negativ auf die erforderlichen Produkteigenschaften, wie z. B. Form- und Maß-
haltigkeit oder das Crash-Verhalten, auswirken. Wechselwirkungen innerhalb der
Prozesskette Presswerk – Karosseriebau – Lackierung sind beispielsweise:
• Blechdicken- und Spannungsverteilung im Bauteil nach dem Tiefziehen,
• Entstehung von lokalen Entfestigungen und Spannungen in den Bauteilen durch
thermische Fügeverfahren,
12

13. • Induzierung thermischer Spannungen in die Karosserie durch hohe Temperaturen
im Lacktrockner (lokal unterschiedliche Wärmekapazitäten bedingt durch die
Blechdickenverteilung in den Bauteilen).
Zukünftige Karosseriekonzepte werden - getrieben vom Leichtbau - immer komple-
xer. Als Beispiel sei hier der zunehmende Einsatz an pressgehärteten Strukturbautei-
len oder der immer häufiger eingesetzte Materialmix in heutigen Automobilkarosse-
rien genannt. Moderne Materialien, wie z. B. Mehrphasenstähle, besitzen Eigen-
schaften, die vorrangig von der Fertigungshistorie abhängig sind. Umso bedeutender
wird es zukünftig sein, die aus den durchlaufenen Herstellungsprozessen resultie-
rende Fertigungshistorie der Bauteile und Baugruppen bei der Simulation der Pro-
dukteigenschaften durch Kopplung der Simulationstools zu berücksichtigen. [PIN209]
3.2 Datenübertragung in der Prozesskette (Ostfalia HaW)
Um das Ziel einer durchgängigen Prozesskette erreichen zu können, müssen die
einzelnen Simulationen miteinander verbunden werden. Die dafür notwendige Da-
tenübertragung besteht aus den zwei Teilbereichen Konversion und Transformation.
Der Bereich der Konversion wird in diesem Kapitel nur angerissen; er wird in Kapitel
3.6 ausführlich dargestellt. Der Bereich der Transformation wird im Abschnitt 3.2.2
näher erläutert.
Da der Zeitaufwand für die Datenübertragung wirtschaftlich bleiben sollte, ist es sinn-
voll zu ermitteln, welche Ergebnisdaten die nachfolgenden Simulationen wie stark
beeinflussen. Dazu wird eine Sensitivitätsanalyse (Abschnitt 3.2.3) durchgeführt. An-
hand der Ergebnisse kann dann entschieden werden, für welche Ergebnisdaten die
Datenübertragung wirtschaftlich ist.
3.2.1 Simulationsprogramme in der Prozesskette
In diesem Projekt wurden entlang der Prozesskette Simulationsprogramme der Soft-
warepartner ESI GmbH und CADFEM GmbH eingesetzt.
Die Umformsimulation wurde mit einem in der Automobilindustrie etablierten inkre-
mentellen Solver (PAM-STAMP) durchgeführt. Da der Einsatz der inkrementellen
Umformsimulation aufgrund der notwendigen Methodenplanung und der Entwicklung
der Ziehanlage einen hohen Zeitaufwand erfordert, wird diese in der Praxis erst
durchgeführt, wenn der Konstruktionsstand der Karosseriebauteile einen entspre-
13

14. chenden Reifegrad erreicht hat. Dies hat zur Folge, dass die Simulationsdaten der
Umformsimulation im frühen Entwicklungsprozess bei der Auslegung der Produktei-
genschaften, insbesondere bei der Crash-Berechnung, nicht zur Verfügung stehen.
Aus diesem Grund wird im Projekt VIPROF zusätzlich ein One-Step-Solver (For-
mingSuite) als alternative Simulationsmethode für die frühe Produktentwicklungspha-
se eingesetzt. Bei der inversen Simulation (One-Step-Simulation) wird die Geome-
trieänderung in einem Schritt rückwärts vom Bauteil zur Platine berechnet. Für die
Durchführung werden nur die CAD-Geometrie und die Werkstoffdaten benötigt. Der
gegenüber der inkrementellen Umformsimulation fehlende Werkzeugkontakt führt
z. B. zur Einschränkung der Faltenvorhersagbarkeit.
Für die Fügesimulation wurde eine Berechnung des Schweißverzugs mit dem Weld
Planner durchgeführt. Die Lacktrocknung wurde mit VPS/DRY und der Crash mit
PAM-CRASH simuliert.
3.2.2 Mapping
Die Analyse der Import und Export-Schnittstellen dieser Software zeigten, dass die
erste Herausforderung bei der Übertragung von Daten zwischen den Simulations-
programmen unterschiedlicher Hersteller unterschiedliche Schnittstellen sind. Diese
Schnittstellen unterscheiden sich in den kompatiblen Formaten, so dass ein Einlesen
der Ergebnisdaten in die nachfolgende Simulationssoftware in der Regel nicht ohne
Zwischenschritte möglich ist. Zusätzlich unterscheiden sich auch die FEM-Netze und
die verwendeten Bezugskoordinatensysteme.
Abbildung 7: Vernetzung Umformsimulation;
Links: Dreieckelemente; rechts: Viereckelemente
Die auffälligsten Unterschiede zwischen den FEM-Netzen sind - wie in Abbildung 7
zu erkennen ist - die Elementform und die Elementgröße. Die Elemente aller in der
14

15. Prozesskette betrachteten Simulationen sind Schalenelemente, so dass eine Be-
trachtung der Datenübertragung zwischen Schalen- und Volumenelementen nicht
stattgefunden hat. Bei den Schalenelementen gibt es Dreieck- und Viereckelemente.
Weiterhin ist in Abbildung 8 zu erkennen, dass die Netze abhängig von der Simulati-
on unterschiedlich fein sind. Die Netze der Umformsimulationen sind in den Radien
feiner vernetzt, weil die Geometrie der Radien nur mit kleinen Elementen ausrei-
chend genau diskretisiert werden kann und zusätzlich in diesen Bereichen die stärk-
sten Verformungen auftreten. Bei der Fügesimulation sind die Bereiche, in denen die
Schweißnähte liegen, feiner vernetzt, während die anderen Bauteilbereiche grob
vernetzt sind. Die Vernetzung für die Crash-Simulation und die Lacktrockungssimula-
tion ist gleichmäßig grob, weil in diesen Simulationen die gesamte Karosserie be-
rechnet wird und bei einer feineren Vernetzung der Zeitaufwand zu groß wäre.
a) Umformsimulation b) Fügesimulation c) Crash-Simulation
Abbildung 8: FEM-Netze
Zusätzlich zu diesen auf den ersten Blick sichtbaren Unterschieden gibt es weitere in
der Elementdefinition. Schalenelemente haben, wie in Abbildung 9 dargestellt ist,
Gauss- und Integrationspunkte. Die „Gauss-Punkte“ sind Integrationspunkte (Gauss-
Quadratur) in der Elementebene, während mit der Bezeichnung „Integrationspunkte“
in der Regel Integrationspunkte über der Elementdicke gemeint sind. Wie viele Integ-
rationspunkte für die Berechnung benötigt werden, hängt von dem Simulationsver-
fahren und dem simulierten Prozess ab. Weiterhin werden abhängig vom Format die
skalaren und tensoriellen Größen pro Integrationspunkt oder pro Knoten abgelegt.
Was bedeutet, dass selbst bei identischen Netzen eine Interpolation der Daten von
den Knoten auf die Integrationspunkte oder andersherum erfolgen muss. Bei den
tensoriellen Größen gibt es zusätzlich noch Unterschiede in den Bezugskoordinaten-
systemen. Einige Formate speichern die Größen im globalen System, andere jeweils
im Elementkoordinatensystem. Dadurch ist für die tensoriellen Größen eine Koordi-
natentransformation der Tensoren notwendig.
15

16. Software/Format FormingSuite/ Sysweld/ PAMSTAMP/ PAMCRASH/
Eigenschaften *.key *.asc *.M01 *.pc
Koordinatensystem Fahrzeug Fahrzeug Werkzeug Fahrzeug
Knoten pro Element 3 (3)4 (3)4 (3)4
Gauss-Punkte 1 (1)4 1 1
Integrationspunkte über der Dicke 3 5 5 5
Blechdicke Abhängig von Nein Ja Ja Ja
Gauss-Punkten
Abhängig von Integ- Nein Nein Nein Nein
rationspunkten
Bezug Knoten Knoten Element Element
Spannungen Abhängig von Ja Ja Ja Ja
Gauss-Punkten
Abhängig von Integ- Ja Nein Ja Ja
rationspunkten
Bezug Element Knoten Element Element
Dehnungen Abhängig von Nein Ja Nein Nein
Gauss-Punkten
Abhängig von Integ- Nein Nein Nein Nein
rationspunkten
Bezug Element Knoten Element Element
Plastische Abhängig von Ja Ja Ja Ja
Vergleichs- Gauss-Punkten
dehnung Abhängig von Integ- Ja Nein Ja Ja
rationspunkten
Bezug Element Knoten Element Element
Tabelle 2: Eigenschaften bzw. Standardeinstellungen
der im Projekt eingesetzten Formate
Abbildung 9: Integrations- und Gauss-Punkte
Darüber hinaus werden die Bauteile abhängig von dem simulierten Prozess in unter-
schiedlichen Koordinatensystemen beschrieben. In der im Projekt VIPROF aufgebau-
ten Prozesskette liegen die Bauteile in der inversen Umformsimulation im Fahrzeug-
16

17. koordinatensystem, weil die Simulation auf der CAD-Geometrie aufbaut und das
Bauteil im CAD-System in der Gesamtkarosserie eingebaut ist. Die inkrementelle
Umformsimulation dagegen verwendet ein Bauteilkoordinatensystem und ein Zieh-
koordinatensystem. Die Lage der Bauteile zueinander nach den Umformsimulationen
ist in Abbildung 10 dargestellt.
Das Fügenetz liegt - wie das Netz der inversen Umformsimulation - in Einbaulage
vor, weil es auf der CAD-Geometrie aufbauend erstellt wurde. Auch Lacktrocknungs-
und Crashsimulation bauen beide auf der Gesamtkarosserie auf, so dass die Netze
ebenfalls im Fahrzeugkoordinatensystem liegen.
Abbildung 10: Bauteillage inkrementelle Umformsimulation (rot)
und Fügesimulation (grün)
In der betrachteten Prozesskette sind alle Netze außer dem der inkrementellen Um-
formsimulation in der Einbaulage definiert. Eine Koordinatentransformation für das
gesamte Netz muss also für alle Mapping-Prozesse erfolgen, in denen Daten der
inkrementellen Umformsimulation übertragen werden sollen.
Allgemein müssen also für eine Übertragung der Ergebnisgrößen zum einen Koordi-
natentransformationen zwischen den unterschiedlichen Koordinatensystemen und
zum anderen Interpolationen der Daten zwischen den Elementen, Knoten, Integrati-
ons- und Gauss-Punkten erfolgen.
Um diese Funktionen nicht neu entwickeln zu müssen wurde eine Literatur- und
Software-Recherche durchgeführt. Eine Untersuchung unterschiedlicher Methoden
zur Übertragung von Geschichtsvariablen aus der Umform- in die Crashsimulation ist
zum Beispiel in [Zöll04] dargestellt. Neben den herstellerinternen Methoden [Cafo03]
hat sich der SCAIMapper, durch seine Möglichkeit unterschiedliche Formate einzule-
sen, für die Kopplung von Umform- und Crashsimulation als herstellerunabhängiges
und damit universelles Werkzeug herausgestellt. Der SCAIMapper hat die Möglich-
keit zur automatisierten Lageausrichtung der Bauteile (im Folgenden als „Ein-
schwimmen“ bezeichnet), kann die Dateiformate unterschiedlicher Software-
Hersteller einlesen und die Interpolation der Daten auf das Zielnetz durchführen
17

18. [Oeck10, Peetz03, Scho07, Wallm04, Shep68, Wolf09]. Für das Projekt stellte der
SCAIMapper alle benötigten Mapping-Funktionen zur Verfügung, so dass er in die
Prozesskette als Mappingtool eingebunden wurde.
Das Mapping von der Umform- in die Crashsimulation war mit dem SCAIMapper
problemlos möglich, was jedoch noch keine Aussage über die Eignung für die ande-
ren Prozesse zuließ, da der Mapper genau für diese Anwendung entwickelt wurde.
Das Einlesen der Netze der Füge- und Lacktrocknungssimulation war aufgrund von
Format-Inkompatibilitäten zunächst problematischer. Diese konnten durch Anpas-
sungen des SCAIMappers durch den Entwickler beim Fraunhofer SCAI behoben
werden. In Abbildung 11 sind die Mapping-Ergebnisse von der inkrementellen Um-
formsimulation auf alle in der Prozesskette eingesetzten Netze dargestellt.
a) b)
c) d)
Abbildung 11: Darstellung der Blechdicke im Mappingprozess: a) Bauteil Übersicht B-
Säule mit Umformergebnissen, b) Umformnetz, c) Fügenetz, d) Lacktrocknungs- und
Crash-Netz
Die Bewertung der Mapping-Genauigkeit erfolgte zum einen mit den im SCAIMapper
verfügbaren Funktionen zur Validierung und zum anderen manuell mit Messpunkten
auf den virtuellen Bauteilen. In Abbildung 11 ist zu erkennen, dass die Mapping-
Ergebnisse nur so genau sein können wie es die Netzgröße des Zielnetzes zulässt.
Das heißt, dass zwei Effekte die Qualität der Mapping-Ergebnisse beeinflussen, zum
einen die Genauigkeitsverluste durch die Interpolation zwischen den Netzen und zum
anderen die schlechtere Auflösung des Zielnetzes. Bei der gezeigten B-Säule in Ab-
bildung 11 ist zu erkennen, dass Extremwerte aus dem Umformprozess bei der Über-
18

19. tragung auf das grobe Crashnetz geglättet werden. Es ist daher wichtig, dass bei der
Weiterverwendung der Ergebnisse nach dem Mapping beachtet wird, dass mögli-
cherweise kritische Werte durch die geglätteten Ergebnisse verloren gegangen sind.
In kritischen Bauteilbereichen sollten diese Informationen daher zusätzlich zu der
Mapping-Datei weiter gegeben werden.
Abbildung 12: Abweichung der Blechdicke nach dem Mapping der
Umformergebnisse (inkrementell) auf das Crash-Netz
Die Datenübertragung der skalaren Größen Blechdicke und plastische Dehnung
funktioniert für alle Mappingprozesse in der untersuchten Kette problemlos. Die
Werte werden mit Hilfe von Interpolationsalgorithmen [Oeck10, Shep68] auf das
neue Netz übertragen. Die Bewertung der Qualität wurde zunächst mit Hilfe der
Validierungsfunktion des SCAIMappers durchgeführt. In Abbildung 12 ist die
Differenz zwischen Original Blechdickenverteilungen und der gemappten
Blechdickenverteilung auf dem Bauteil aufgetragen. Die Abweichungen sind kleiner
als 40 µm. Nur in Bereichen, in denen die Geometrie nicht übereinstimmt – z. B.
aufgrund von in der Umformsimulation nicht berechneten Ausschnitten - liegen die
Abweichungen darüber.
Die zweite Methode zur Bewertung der Mapping-Qualität besteht in einem Vergleich
der Blechdicken an 20 definierten Messpunkten vor und nach dem Mapping-Prozess.
Die Messpunkte werden vorrangig in Bauteilbereichen mit großen Veränderungen
der Blechdicke sowie Netzbereichen mit sehr grober und sehr feiner Diskretisierung
platziert. In Abbildung 13 ist die Lage der Messpunkte auf dem Bauteil dargestellt.
An den betrachteten Messpunkten werden die Werte jeweils über die umgebenden
Elemente gemittelt, um die Empfindlichkeit des Verfahrens gegen singuläre Spitzen
möglichst gering zu halten. In jedem Punkt wird der auf die Ausgangsblechdicke vor
dem Mappingprozess bezogene relative Fehler berechnet:
s − s0 mit: s: Blechdicke nach dem Mapping
Frel = ⋅ 100%
s0 s0: Blechdicke vor dem Mapping
19

20. P1 +
P2 +
+ P6
+ P7 + P13 + P20
+ P8 + P14
+ P15
P3 + +P10
P9 + P16
P4 + +P11 + P17
P5 +
+P12 + P18
+ + P19
Abbildung 13: Lage der 20 Messpunkte für die Ergebnisgröße Blechdicke
auf der Bauteilgeometrie
Abbildung 14 zeigt die Auswertung des relativen Fehlers beim Mapping der Blech-
dicke auf die unterschiedlichen Zielnetze an den 20 Messpunkten. Abweichungen
bis maximal 5% werden dabei als gut bewertet und grün dargestellt. In gelb
gestellt und als befriedigend bewertet werden Abweichungen im Bereich von 5%
bis 10%. Während Messpunkte mit einem relativen Fehler über 10% als mangel-
haft eingestuft und rot dargestellt werden.
20
18
16
14
Anzahl Messpunkte
12
≥ 10%
10 5 - 10%
≤ 5%
8
6
4
2
0
rel. Fehler rel. Fehler rel. Fehler rel. Fehler
Umformen inkrementell Umformen invers Umformen inkrementell Umformen invers
-> Fügenetz -> Fügenetz -> Crashnetz -> Crashnetz
Abbildung 14: Relativer Fehler beim Mapping der Blechdickenverteilung
auf Füge- und Crashnetz
20

21. Die Abweichung für 84% der Messungen an diesem Bauteil liegt insgesamt unter
5%. Die Mapping-Qualität kann damit für die skalare Ergebnisgröße Blechdicke als
gut bewertet werden. Dieses Ergebnis stimmt mit der Aussage von Abbildung 12 gut
überein.
An insgesamt sechs Messpunkten (P2, P4, P7, P10, P14 und P15) wurde die
Mapping-Genauigkeit als befriedigend oder mangelhaft eingestuft. Diese Punkte
liegen alle in Bauteilbereichen mit starker Ausdünnung bzw. Aufdickung oder engen
Radien. Große Gradienten in der Blechdicke bei feiner Vernetzung im Ausgangsnetz
und deutlich größere Elementkantenlängen im Zielnetz im gleichen Bereich führen
durch die in diesen Bereichen dann notwendige Interpolation der Blechdickenwerte
zu größeren Abweichungen in den Mapping-Ergebnissen. Dies zeigt sich auch im
Vergleich der Mapping-Ergebnisse für die betrachteten FEM-Netze. Je größer die
Unterschiede in den verwendeten Netzen sind, desto größer sind auch die
Abweichungen.
Abbildung 15: Plastische Dehnungen nach der inkrementellen Umformsimulation (un-
ten) und nach dem Mapping auf das Crash-Netz (oben)
In der Prozesskette werden zusätzlich zu der Blechdickenverteilung auch die
plastischen Dehnungswerte als Maß für die Werkstoffverfestigung übertragen. Beim
Mapping der plastischen Dehnungen müssen in Abhängigkeit von der Anzahl der
Integrationspunkte über der Bauteildicke mehrere Werte übertragen werden.
Abbildung 15 zeigt die plastischen Dehnungen nach dem Umformprozess (unten)
und die nach dem Mapping auf ein Crashnetz (oben). Es ist zu erkennen, dass die
Werte qualitativ richtig übertragen werden. In den blau dargestellten Bereichen sind
die plastischen Dehnungen sehr gering.
21

22. Abbildung 16: Absolute Abweichung der plastischen Dehnung nach dem Mapping
der Umformergebnisse (inkrementell) auf das Crash-Netz
In Abbildung 16 ist die Differenz zwischen den plastischen Dehnungen nach dem
Umformprozess und den plastischen Dehnungen auf dem Crash-Bauteil nach dem
Mapping-Prozess aufgetragen. Die Abweichungen liegen in den meisten
Bauteilbereichen mit signifikanten plastischen Dehnungen bei unter 25%.In den
Bauteilbereichen mit geringen plastischen Dehnungen (blaue Bereiche in Abbildung
15), führen bereits geringe Interpolationsfehler zu großen Abweichungen. In diesen
Bereichen ist aufgrund der geringen plastischen Dehnung kein großer Einfluss auf
die nachfolgenden Simulationsprozesse zu erwarten. Der Einfluss auf die
nachfolgenden Prozesse wird in Kapitel 3.2.2 untersucht und bewertet.
Abbildung 17: Vergleichsspannungen in Pa auf dem Umformnetz (unten)
und Crash-Netz (oben) nach dem Mapping
Die Datenübertragung von tensoriellen Größen ist dagegen schwieriger, da die
soren formatabhängig in unterschiedlichen Koordinatensystemen gespeichert wer-
den. Dadurch ist ein Vergleich der Tensoren nicht direkt möglich. In der grafischen
Darstellung werden daher in der Regel Vergleichswerte gezeigt. In Abbildung 17 ist
zu erkennen, dass die Abweichungen des dargestellten skalaren Vergleichswertes
22

23. nach dem Mapping deutlich größer sind als bei den skalaren Größen Blechdicke und
plastische Dehnung. Abbildung 18 zeigt die Differenz der Vergleichsspannungen
zwischen den Netzen nach der Übertragung der Umformergebnisse auf das Crash-
Netz.
Abbildung 18: Differenz der Vergleichsspannungen in Pa zwischen Umformnetz und
Crash-Netz nach dem Mapping
a) 1.Hauptspannung
b) 2.Hauptspannung
Abbildung 19: 1. und 2. Hauptspannung jeweils nach der Umformsimulation (oben)
und nach dem Mapping auf das Crash-Netz (unten)
23

24. In Abbildung 19 sind die 1. und 2. Hauptspannung an der äußeren Oberfläche der B-
Säule dargestellt. Es ist zu erkennen, dass lokale Maxima und Minima bei der Über-
tragung auf das deutlich gröber vernetzte Crash-Netz stark geglättet werden. Die
Abweichungen entstehen durch die Interpolation der Größen auf das gröbere Netz.
Das Mapping von tensoriellen Größen scheint - soweit es anhand der skalaren Ver-
gleichsspannung beurteilt werden kann - im Rahmen der durch das Zielnetz vorge-
gebenen maximalen Auflösung ausreichend genau zu sein. Die Interpretation der
gemappten Daten in den nachfolgenden Simulationen führt jedoch teilweise zu Ab-
weichungen, so dass im Einzelfall geprüft werden muss, ob die Daten von der nach-
folgenden Simulation richtig interpretiert werden. In der Sensitivitätsanalyse wird ge-
prüft, ob das Übertragen von Spannungen in die Folgesimulationen sinnvoll ist und
wie empfindlich die Simulationen auf Abweichungen reagieren.
3.2.3 Sensitivitätsanalyse
Das Ziel der Sensitivitätsanalysen ist es zu ermitteln, welche Ergebnisgrößen einen
so großen Einfluss haben, dass sie übertragen werden sollten um eine Genauig-
keitssteigerung zu erreichen. Dazu werden sowohl die Umformergebnisse aus der
inkrementellen als auch aus der inversen Umformsimulation in alle Folgesimulationen
übertragen.
Es wurden zunächst für alle Bauteile der Baugruppe (Abbildung 20 a) Umformsimula-
tionen durchgeführt. Die Hauptbauteile B-Säule innen, Verstärkung B-Säule, Verstär-
kung Stegblech Schweller und Sitzquerträger wurden sowohl mit der inkrementellen
Umformsimulation (PAMSTAMP 2G) berechnet (Abbildung 20 b), als auch mit der
inversen Simulation (FormingSuite) (Abbildung 20 c). Die kleinen Bauteile (Abbildung
20 c) Schottteil B-Säule, Verstärkung Wagenheberaufnahme und Schottteil Schweller
vorn wurden nur mit der inversen Umformsimulation berechnet. Diese Ergebnisse
wurden in unterschiedlichen Kombinationen in die nachfolgenden Simulationen über-
tragen, um zu prüfen ob dadurch die Simulationsergebnisse beeinflusst werden kön-
nen. Einen Überblick über die untersuchten Varianten gibt Abbildung 66.
24

25. a) Baugruppe b) Umformsimulation (inkrementell)
B-Säule innen
Verstärkung Stegblech Schweller
Verstärkung B-Säule innen
Sitzquerträger
c) Umformsimulation (invers) B-Säule innen
Schottteil B-Säule
Verstärkung Stegblech Schweller
Verstärkung Wagenheberaufnahme
Verstärkung B-Säule innen
Schottteil Schweller
Sitzquerträger
Abbildung 20: Bauteilumfang
25

26. Die Fügesimulation wurde dazu mit unterschiedlichen Eingangsdaten durchgeführt:
1. Standard Eingangsdaten inkl. Ausgangsblechdicken
2. Standard Eingangsdaten und Blechdicken aus der Umformsimulation
3. Standard Eingangsdaten und plastische Dehnungen aus der Umformsimulation
4. Standard Eingangsdaten, Blechdicken und plastische Dehnungen aus der
Umformsimulation
Ein Vergleich der Ergebnisse dieser Fügesimulationen hat gezeigt, dass nur bei Be-
rücksichtigung von Blechdicken aus der Umformsimulation die in Abbildung 21 dar-
gestellte Verdrehungsrichtung der Baugruppe richtig vorhergesagt werden kann.
Weiterhin führt das Weitergeben der plastischen Dehnungen zu geringen Verbesse-
rungen. Die Spannungen können von dem für die Fügesimulation eingesetzten
Weldplanner nicht weiter verwendet werden, so dass eine Übertragung hier nicht
sinnvoll ist. In Kapitel 3.3 werden diese Ergebnisse weiterführend beschrieben.
a) b)
c)
Abbildung 21: a) Verdrehungsrichtung im Versuch, b) Simulationsergebnis ohne Um-
formergebnisse, c) Simulationsergebnis mit Blechdicken und plastischen Dehnungen
aus der Umformsimulation
Die Ergebnisse der Fügesimulation werden für die mit unterschiedlichen Eingangsda-
ten durchgeführten Berechnungen jeweils in eine Mapping-Datei geschrieben und für
die nachfolgenden Simulationen zur Verfügung gestellt.
In der Lacktrocknungssimulation wurden Berechnungen mit den Ergebnissen aus
Umform- und/oder Fügesimulationen durchgeführt. Bei der Berücksichtigung von
26

27. Blechdicken, Spannungen und plastischen Dehnungen aus dem Umformprozess
konnten an dieser Baugruppe jedoch keine Auswirkungen auf das Beulverhalten der
Baugruppe festgestellt werden. Da die betrachtete Baugruppe aus einem Fahrzeug
stammt, welches bereits beulfrei produziert wird, war das aber auch nicht zu erwar-
ten. Da während des Trocknungsprozesses im Ofen die Werkstoffe auf Temperatu-
ren erhitzt werden bei denen der Bake-Hardening-Effekt auftreten kann, ist es sinn-
voll die dadurch auftretende Verfestigung in die nachfolgende Crash-Simulation wei-
ter zu geben. Weiterführende Informationen zur Lacktrocknungssimulation und zur
Übertragung des Bake-Hardening-Effekts in die Crashsimulation sind in Kapitel 3.4
zu finden.
Die Crash-Simulation wurde ohne und mit den Ergebnissen der Umform- und Füge-
simulation durchgeführt. Anhand der Ergebnisse der Crash-Simulation wird die ge-
samte Prozesskette bewertet. Die Ergebnisse der Crashsimulation zeigen, dass mit
der Berücksichtigung von Blechdicken und plastischen Dehnungen aus Umform- und
Fügesimulation die Art des Bauteilversagens in der Simulation näher an der Realität
liegt, als ohne Berücksichtigung der Fertigungshistorie. Die Ergebnisse der Crashsi-
mulation werden in Kapitel 3.5 ausführlich dargestellt.
Zusammenfassend ist für die Datenübertragung zwischen den Prozessen festzuhal-
ten, dass die Übertragung von Blechdicken und plastischen Dehnungen in die Füge-
simulation zu genaueren Simulationsergebnissen führt. Die Übertragung von Ergeb-
nissen in die Lacktrocknungssimulation zeigt dagegen für die betrachtete Baugruppe
keine Verbesserung. Die Ergebnisse der Crash-Simulation werden wiederum durch
die Übertragung der Blechdicken und plastischen Dehnungen positiv beeinflusst. Zu-
sätzlich kann es sinnvoll sein den aus der Lacktrocknung resultierenden Bake-
Hardening-Effekt in die Crashsimulation zu übertragen.
Literatur
[Zöll04] Zöller, A.; Frank, T. & Haufe, A.: Berücksichtigung von Blechumformer-
gebnissen in der Crashberechnung, 3. LS-DYNA Anwenderforum,
2004, B-I-1bis B-I-12
[Cafo03] Cafolla, J.; Hall, R. W.; Norman, D. P. & Mc Gregor, I. J.: ''Forming to
Crash'' Simulation in Full Vehicle Models, 4th European LS-Dyna Users
Conference, 2003, 4, E-II-17 - E-II-26
27

28. [Oeck10] Oeckerath, A. & Wolf, K.: Improved Product Design Using Mapping In
Manufacturing Process Chains, 9. LS-DYNA Forum, DYNAmore GmbH,
2010
[Peetz03] Peetz, J.-V.; Post, P.; Scholl, U.; Wang, Y.; Wolf, K.; D39Ottavio, M.;
Kröplin, B. & Waedt, M.: Verbesserung der Crashvorhersage von Ka-
rosseriebauteilen durch Einbeziehung von Ergebnissen aus der Um-
formsimulation., Symposium 16Simulation in der Produkt- und Prozess-
entwicklung 17, 2003, 171-178
[Scho07] Scholl, U.: SCAIMapper Kopplung von Umform- und Crashsimulation
6. LS-DYNA Anwenderforum, DYNAmore GmbH, 2007, 6., H-II-1-H-II-6
[Wallm04] Wallmersperger, T.; Waedt, M.; D'Ottavio, M.; Kröplin, B.; Wolf, K.;
Post, P.; Peetz, J.-V. & Scholl, U.: Kriterien zur Bewertung des Map-
pings von Umform- auf Crashsimulation, 3. LS-DYNA Anwenderforum,
DYNAmore GmbH, 2004, D - I - 1 bis D - I - 11
[Shep68] Shepard, D.: A two-dimensional interpolation function for irregularly-
spaced data, Proceedings of the 1968 23rd ACM national conference,
1968, 517 - 524
[Wolf09] Wolf, K.; Schilling, R.; Lüthjens, J.; Hunkel, M.; Wallmersperger, T.;
Jankowski, U.; Sihling, D.; Wiegand, K.; Zöllner, A. & Heuse, M.:
Coupled FEM Calculations - A CAE Tool to Improve Crash-Relevant
Automotive Body Components by Local Hardening,
7th European LS-DYNA Conference, DYNAmore GmbH, 2009
28

29. 3.3 Teilprozesskette Umformen und Fügen (ESI)
3.3.1 Simulation der Bauteilerzeugung mittels Umformen
Die Simulation der Herstellung von Bauteilen aus Feinblech mittels Tiefziehen darf
als etablierter Stand der Technik angesehen werden. In diesem Projekt wurde dazu
das Programm PAM-STAMP 2G der ESI Group verwendet. Ziel der Umformsimulati-
on für sich betrachtet, ist die Überprüfung der Herstellbarkeit des Bauteils und au-
ßerdem die virtuelle Erprobung der gewählten Methode, sowie deren Optimierung.
Darüber hinaus ist es möglich, z. B. den Aufsprung des Bauteils durch virtuelle Über-
biegung des Werkzeugs zu reduzieren. Im Vordergrund des Projektes stand jedoch
weniger die Herstellbarkeit des Bauteils, sondern die Darstellung der durchgängigen
Prozesskette und Betrachtung der auftretenden Sensitivitäten.
Zur Überprüfung der Herstellbarkeit hat sich die Simulation der Hauptumformstufe
bewährt. Die Simulation weiterer Nachform- und Schnittstufen wird bisher von Auto-
mobilherstellern als wenig Nutzen bringend angesehen. Dies ist für Zulieferer anders,
denn diese müssen das Bauteil in einer vorgegebenen Toleranz anfertigen, die sich
heute schon in erster Näherung virtuell überprüfen lässt.
Betrachtet man nicht mehr den einzelnen Herstellprozess, sondern die gesamte
Herstellprozesskette, so stehen das virtuelle Bauteil und dessen Verbaubarkeit im
Fokus. Eine Übertragung der Bauteileigenschaften nur aus der Hauptumformstufe
auf die CAD-Form des Bauteils ist machbar, führt jedoch in nicht beschriebenen Be-
reichen zu biegeschlaffen Zonen. Diese entsprechen dann dem Ausgangszustand
des Bleches ohne Änderung der Blechdicke und Kaltverfestigung. Im Projekt wurden
daher alle erforderlichen Nachformoperationen und Beschnitte mitgeführt, und somit
vollständig umgeformte Bauteile erzeugt (Abbildung 22).
Abkanten
Verprägen
Abbildung 22: Nachformoperationen zur Erstellung virtueller Bauteile
29

30. Ein weiterer wesentlicher Aspekt, der sich nur sinnvoll mit einem über alle Umform-
stufen erstellten Bauteil betrachten lässt, ist die Rückfederung. Auch für sogenannte
kompensierte Bauteile verbleibt nach der Entlastung durch die Werkzeuge ein Auffe-
derungseffekt. Dieser führt bei der üblichen Methode der Datenübertragung zu Abbil-
dungsfehlern zwischen der aufgesprungenen Umformgeometrie und der Zielgeomet-
rie, einem Netz basierend auf CAD-Daten und Lage (Abbildung 23). Ein Weg dies zu
umgehen, ist die Vernachlässigung des Aufsprungs, d.h. es wird das Ergebnis nach
der letzten Umformstufe ohne Rückfederungsrechnung übertragen. Dies bedeutet
ein Verbleiben der Eigenspannungen im Bauteil, sofern diese übertragen werden. Da
die Entlastungsrechnung in der Regel nicht zu plastischen sondern nur elastischen
Effekten führt, ist der Fehler bei einer Vernachlässigung der Spannungsseite, d.h.
der Übertragung von Blechdicken und plastischen Dehnungen, eher als gering anzu-
sehen.
1. und 2.
1. Torsion am Kopf
2. Aufsprung in der Zarge
3. unterschiedlicher Beschnitt
Abbildung 23: Abbildungsfehler bei der Datenübertragung (Mapping)
3.3.2 Methode der Neuvernetzung
Um der Problematik des Aufsprungs zu begegnen wurde im Projekt die Methode der
Neuvernetzung entwickelt. Neben der Übertragung der physikalischen Eigenschaften
des umgeformten Bauteils, wie Kaltverfestigung, Blechdickenänderung und optional
der Eigenspannungen, wird mittelfristig in der Betrachtung der Prozesskette auch die
Berücksichtigung der Gestaltänderung eine Rolle spielen. Gestaltänderung ist hier
der Unterschied zwischen der CAD-Geometrie des Bauteils nach der Umformung
und dem virtuellen Bauteil nach der Umformung. Abbildung 24 verdeutlicht die drei
denkbaren Varianten zur Übertragung der Herstellungshistorie, die abstrahiert auf
beliebige Kopplungen zwischen Gewerken übertragbar sind.
30

31. CAD Ziehanlage CAD Daten
CAD A
PAM-
ohne Entlastung AUTOSTAMP Netz umgeformt
Umformsimulation
PAM-
Netz entlastet
AUTOSTAMP
Rückfederung
PANEL SHOP
entlastet
CAD B
Mapping Mapping Mapping
Sysweldnetz Sysweldnetz Sysweldnetz
CAD A CAD A entlastet
a) b) c)
Neuvernetzung
SYSWELD
SYSWELD SYSWELD
Route 1
Route 2
Schweißsimulation
Schweißsimulation Schweißsimulation
SYSWELD
SYSWELD SYSWELD Spannen
Schweiß Verzug Schweiß Verzug
SYSWELD
Schweiß Verzug
Abbildung 24: Übertragung der Umformhistorie in die Schweißsimulation: a) und b)
ohne Berücksichtigung der Gestaltänderung und c) mit Gestaltänderung
Als Referenzprozess lässt sich heute mit einer überschaubaren Methode die aktuelle
Bauteilgeometrie des entlasteten Bauteils aus Gewerk A in ein Gewerk B überführen.
Das Eingangsnetz für Gewerk B kann also auf Basis von Bauteil A generiert werden
und damit können auch die Daten ohne Abbildungsfehler übertragen werden.
Zur Darstellung der Methode wurde im Projekt das Programm PanelShop der Firma
iCapp verwendet. Aus dem Lageunterschied der Netze zwischen der letzten Um-
formstufe und nach der Entlastungsrechnung wird ein Verschiebungsfeld ermittelt,
dass PanelShop nutzt, um die CAD-Bauteilgeometrie zu überbiegen und damit in die
Lage des aufgefederten Bauteils zu bringen (Abbildung 25). Diese aktualisierte Bau-
teilgeometrie wird dann mit dem Eingangsnetz für Gewerk B neu vernetzt und an-
31

32. schließend die Herstellungshistorie aus Gewerk A ohne Abbildungsfehler darauf
übertragen (gemappt). Damit ist ein wesentliches Modul für die End to End Prozess-
kettensimulation verfügbar, das der Gestaltabweichung in adäquater Weise Rech-
nung trägt.
+ +
CAD Bauteil Umformnetz Verschiebungsfeld CAD Bauteil
„entlastet“
Abbildung 25: Mit PanelShop (Fa. iCapp) generierte CAD-Daten des entlasteten
Bauteils als Basis zur Neuvernetzung
Alternativ wurde im Programm PAM-STAMP 2G ein Mapping von Netz B auf Netz A
betrachtet. Dies war jedoch nicht zielführend, da in PAM-STAMP bisher nur eine li-
neare Projektion implementiert ist. Diese führt für einen Bauteilbereich mit vertikaler
Projektionsrichtung zu Verzerrungen (Abbildung 26). Eine Verbesserung würde hier
eine Projektion unter Berücksichtigung der jeweiligen Elementnormalen ergeben.
Dies sollte aber durch ein vorheriges Einschwimmen von Netz A zu B ergänzt wer-
den. So wie es auch im SCAIMapper möglich ist. Denn selbst wenn sich beide Netze
in Fahrzeuglage befinden, kann der Aufsprung durch die Lagerbedingungen zu einer
Verschiebung eines Bauteils führen.
32

33. Abbildung 26: Mögliche Projektionsfehler
bei linearer Projektion von Netz A auf Netz B
3.3.3 Untersuchte Baugruppe
Von der untersuchten Schweiß-Baugruppe „Seitenwandrahmen vorn“ wurden drei
Hauptbauteile für die inkrementelle Umformsimulation ausgewählt und drei Zusatz-
bauteile mit geringer Umformung wurden mittels Onestep-Simulation betrachtet. Hin-
zu kommen für die Schweißung noch zwei Gewindeplatten und ein weiteres Bauteil,
um den Zusammenbau mit dem Serienstand vergleichbar zu machen (Abbildung 27).
33

34. jeweils in rot dargestellt
Hauptbauteile
Säule B innen Verstärkung Säule B Verstärkung Stegblech
innen Schweller innen
Verstärkung A-Säule
nur als CAD-Daten
Zusatzbauteile eingefügt
Schottteil Säule B Verstärkung Schottteil Schweller vorn
Wagenheberaufnahme
Abbildung 27: Untersuchte Schweiß-Baugruppe
3.3.4 Sensitivität der Datenübergabe in Relation zur Netzfeinheit
Für das VIPROF-Projekt wurde die durchgängige Verwendung von Netzen mit Scha-
lenelementen festgelegt. Diese haben dann noch unterschiedliche Elementformulie-
rungen, sind aber im Wesentlichen durch vier Knoten bestimmbar. Trotzdem existie-
ren je nach physikalischem Schwerpunkt der einzelnen Gewerke unterschiedliche
Netzausprägungen hinsichtlich der Feinheit und betrachteter Teilbereiche. Dies zeigt
Abbildung 28 mit dem Netz aus der Umformung mit verfeinerten Radienbereichen,
dem Schweißnetz mit Nahtbereichen und dem typischen 5 mm Crashnetz.
Umformen Schweißen Crash
Abbildung 28: Unterschiedliche Netzausprägungen
34

35. Um die Sensitivität der Datenübertragung in Relation zur Netzausprägung zu unter-
suchen, wurden die wesentlichen drei Mappinggrößen: Blechdicke, plastische Deh-
nung und Spannungstensor in PAM-STAMP 2G jeweils vom Umformnetz auf das
Schweiß- und Crashnetz gemappt.
Für die betrachteten Bauteile ergab sich eine gute Übertragbarkeit der Blechdicken
und mit kleineren Verlusten auch der plastischen Dehnungen (Abbildung 30). Eine
deutliche Abnahme der oberen Spannungswerte und damit verbundene Nivellierung
der Spannungen zu niedrigeren Niveaus zeigte sich bei der Übertragung der Span-
nungstensoren. Abbildung 30 zeigt dies anhand der Gegenüberstellung der Ver-
gleichsspannungen nach dem Mapping. Deutlicher noch wird dies über eine Betrach-
tung der Histogramme, die die statistische Verteilung der Spannungen auf den jewei-
ligen Netzen darstellt (Abbildung 31).
Stamp Weld Crash Stamp Weld Crash
Abbildung 29: Einfluss der Netzausprägung auf die Übertragung der Blechdicken
(links) und plastischen Dehnungen (rechts) vom Tiefziehen zum
Schweißen und zum Crash
Im Projekt wurden in erster Linie die Übertragung der Blechdicken und plastischen
Formänderungen betrachtet. Die Eigenspannungen schienen nicht nur wegen der
Verluste bei der Übertragung der Spannungstensoren für den betrachteten Zusam-
menbau nicht relevant zu sein, sondern auch weil dieser mit MAG- und Laser-
Linienschweißungen robust verbunden wurde. Interessanter wäre die Berücksichti-
gung der Eigenspannungen für die Untersuchung von punktgeschweißten Zusam-
menbauten, die bekannterweise sensibler gegenüber eingebrachten Vorspannungen
sind.
35

36. Stamp
Weld
Crash
Abbildung 30: Einfluss der Netzausprägung auf die Übertragung der Vergleichs-
spannungen vom Tiefziehen zum Schweißen und zum Crash
36

37. Stamp
Weld
Crash
Abbildung 31: Verluste bei der Übertragung von Spannungstensoren
3.3.5 Simulation des Schweißverzugs mit dem Weld Planner
Mit dem Programm Weld Planner wurde das Fügen der Baugruppe „Seiten-
wandrahmen vorn“ hinsichtlich des auftretenden Verzuges simuliert. Abbildung 32
verdeutlicht die Lage der Nähte und die beiden eingesetzten Schweißverfahren. Als
Lagerbedingung nach der Abkühlung wurden die von VW bereitgestellten RPS-
Punkte verwendet (Abbildung 33). Das Referenzpunktesystems (RPS) umfasst u.a.
die Maßbezüge und Positionierungen für Bauteile und Schweißgruppen und wird im
CAD festgelegt. Die virtuelle Schweißung beschränkt sich beim Weld Planner auf die
Einbringung der Prozesswärme an den jeweiligen Fügestellen und in der vom An-
wender vorgegebenen Schweißreihenfolge. Sie gibt wesentliche Hinweise zur Opti-
mierung der Schweißnahtlage und Reihenfolge.
37

38. Abbildung 32: Laserschweißnähte (a) und MAG-Schweißnähte (b) der Baugruppe
Abbildung 33: RPS-Spannpunkte der Messaufnahme
3.3.6 Sensitivität des Schweißverzugs hinsichtlich der aus der Fertigungshis-
torie übertragenen Größen
In der Sensitivitätsanalyse zum Schweißverzug wurde der Einfluss des Übertragens
unterschiedlicher Ergebnisgrößen und des Einsatzes verschiedener Berechnungs-
methoden zur Simulation des Tiefziehens verglichen. Neben der Simulation mit dem
inkrementellen Berechnungsprogramm PAM-STAMP 2 G wurde der inverse Ein-
schrittlöser (Onestep-Solver) FTI FormingSuite eingesetzt. Betrachtet wurden jeweils
die drei Hauptbauteile, die entweder inkrementell oder invers simuliert wurden. Die
Zusatzbauteile wurden für die Umformung jeweils nur invers berechnet. Dazu wurde
38

39. zum Vergleich noch der Schweißverzug auf Basis der CAD-Daten ohne Fertigungs-
historie einbezogen. Untersucht wurden die in Tabelle 3 aufgeführten Varianten.
Variante Simulationtool Software Blechdicke plastische Dehnung
Haupbauteile Nebenbauteile
0 WeldPlanner nur CAD nur CAD - -
1a WeldPlanner PAM-STAMP 2G nur CAD x -
1b WeldPlanner PAM-STAMP 2G nur CAD - x
1c WeldPlanner PAM-STAMP 2G nur CAD x x
2a WeldPlanner FTI FormingSuite nur CAD x -
2b WeldPlanner FTI FormingSuite nur CAD - x
2c WeldPlanner FTI FormingSuite nur CAD x x
3a WeldPlanner PAM-STAMP 2G FTI FormingSuite x x
3b WeldPlanner FTI FormingSuite FTI FormingSuite x x
4 WeldPlanner PAM-STAMP 2G nur CAD x x
Neuvernetzung
Tabelle 3: Varianten des Mappings der Herstellungshistorie aus der Umformung
Im Folgenden werden wesentliche Ergebnisse beispielhaft aufgezeigt. Der Vergleich
des Übertragens einzelner Ergebnisgrößen, wie dem Blechdickenverlauf und der
plastischen Dehnung, ergab, dass die alleinige Übertragung der plastischen Deh-
nungen nicht sinnvoll ist. Während die alleinige Übertragung der Blechdicke für eine
gute Ergebnisübereinstimmung mit den Messungen hinreichend sein kann. Dieses
Phänomen lässt sich mit dem dominanten Einfluss der Blechdicke auf die Steifigkeit
des Zusammenbaus erklären. Die Beulsteifigkeit kann je nach Geometrie bis in die 2.
oder 3. Potenz von der Blechdicke abhängig sein. Dies dokumentiert beispielhaft die
Abbildung 34.
39

40. Verschiebungen in y-Richtung
Mit beiden Größen Nur Blechdicken Nur plastische Dehnung
Abbildung 34: Übertragung unterschiedlicher Größen. Hauptbauteile und Zusatzbau-
teile invers simuliert
Eine Gegenüberstellung der untersuchten drei Hauptbauteile mit inkrementeller und
inverser Simulation zeigt, dass für den betrachteten Fall der Verzug basierend auf
der inversen Umformung etwas stärker ist, als der der inkrementellen Simulation
(Abbildung 35). Dies ist damit zu erklären, dass die inverse Umformung, wie von
Volkswagen berichtet, zum Teil geringere Umformgrade erzielt. Die Richtung und der
Trend des Verzugs sind bei beiden Methoden identisch.
Verschiebungen in y-Richtung
Hauptbauteile inkrementell und Alle Bauteile invers simuliert
Zusatzbauteile invers simuliert
Abbildung 35: Schweißverzüge der inkrementellen und inversen Simulation der Um-
formung im Vergleich
40

41. Da der betrachtete Schweiß-Zusammenbau einem Serienstand entspricht, ist der
auftretende Verzug sehr gering und damit eine Aussage über die Güte der Ergebnis-
se nur eingeschränkt möglich. Auf der Grundlage der von Volkswagen durchgeführ-
ten Vergleichsstudie zur Güte inverser Simulationen kann angenommen werden,
dass die Resultate in der vorliegenden Form repräsentativ sind. So dass in der frü-
hen Phase Onestep-Simulationen zur Planung der Schweißmethode mit ausreichen-
der Genauigkeit eingesetzt werden können.
Die Frage nach der Notwendigkeit der Berücksichtigung von Umformergebnissen für
die richtige Vorhersage des Schweißverzugs wurde mit der Variante 0 (Tabelle 3)
betrachtet. Eine Gegenüberstellung der Messergebnisse mit der Simulation des
Schweißverzugs ohne Berücksichtigung der Fertigungshistorie ergab für diese Bau-
gruppe abweichende Resultate hinsichtlich des Verzugs und der Verdrillungsrichtung
(Abbildung 36). Beide Ergebnisgrößen des Schweißverzugs wurden demgegenüber
von der Variante mit Übernahme der Blechdicken und plastischen Formänderungen
für die betrachteten Bauteile dem Messergebnis vergleichbar dargestellt. Die Ver-
messung der Schweißbaugruppe bei VW (Abbildung 72) ergab eine gute Übereins-
timmung mit der Simulationsvariante mit Berücksichtigung der vollständigen Ferti-
gungshistorie sowie nur der Blechdicke (siehe Kapitel 3.5.5.1, Abbildung 72 und Ab-
bildung 73).
Abbildung 36: Schweißverzug mit Basis CAD-Daten (links), Blechdicken (mitte) und
Umformhistorie (rechts); Verschiebungen in Y-Richtung (normal zur Ansichtsrichtung)
41

42. 3.3.7 Schweißverzugssimulation mit der Methode der Neuvernetzung
Die Notwendigkeit der Untersuchung des Einflusses der Auffederung am Ende der
Umformung verdeutlicht Abbildung 37. Die in Tabelle 3 aufgeführte Variante der
Neuvernetzung wurde im Rahmen des VIPROF-Projektes entwickelt und exempla-
risch untersucht. Basierend auf der aufgesprungenen Bauteilgeometrie (siehe Ab-
schnitt 3.3.2) wurde ein neues Netz für die Schweißverzugssimulation erstellt und die
Ergebnisse des entlasteten Bauteils aus der Umformung darauf übertragen.
Aufgabenstellung:
CAD-Bauteilgeometrie Übertragen der Umformergebnisse (Spannungen,
plastische Dehnungen, Blechdickenverteilung) aus
dem Umformen auf ein entsprechendes Modell für
eine Fügesimulation thermisch oder mechanisch
Werkzeugentwurf
Route 1 Geometrisch passendes Mapping mit
Eigenspannungen im Modell
Route 1
Umformsimulation
Route 2 Mappen des entlasteten Bauteils
mit geometrischer Abweichung
Route 2
Rückfederungsrechnung Simulation des Fügens
Route 3 Mappen des entlasteten Bauteils auf ein
Route 3
Neuvernetzung kongruentes, dediziertes Netz zum Fügen.
Im Fügen ist ggf. ein Spannvorgang
erfoderlich
Abbildung 37: Mögliche Vorgehensweisen zum Übertragen der Herstellungshistorie
in die nachfolgende Fügesimulation
Der Unterschied der in Abbildung 38 dargestellten Ergebnisse für Route 1 und 2 ist
relativ gering, was auf die im Projekt gewählte Vernachlässigung der Spannungs-
tensoren beim Mapping zurückzuführen ist. Betrachtet man aber das deutlich abwei-
chende Ergebnis der Methode der Neuvernetzung, bei der das Bauteil beim Fügen
aufgrund der Lageabweichung gespannt werden muss, so ist der Verzug für dieses
Bauteil aus der Baugruppe sogar geringer ausfallend. Daraus ergibt sich die Frage,
wie sich das Verhalten anderer Baugruppen mit dieser erweiterten Betrachtungswei-
se darstellt. Da dies im Projekt nicht weiter geklärt werden konnte, soll an dieser Stel-
le die Fortführung der Untersuchung der vorgeschlagenen Methode der Neuver-
netzung im Rahmen anderer Förderprogramme angeregt werden.
42

43. Die darüber hinaus interessierende Fragestellung ist, ob die Route 1 bei zusätzlicher
Berücksichtigung der Spannungstensoren eine hinreichende Lösung darstellen könn-
te. Wäre so der Aufwand der Neuvernetzung vermeidbar? Nicht zuletzt ließe sich
auch die Variante der direkten Projektion des Fügenetzes auf das aufgefederte Um-
formnetz verbessern und damit eine einfachere Lösung schaffen.
Min: 0,003 Min: 0,003 Min: 0,001
Max: 0,932 Max: 0,946 Max: 0,596
Route 1 Route 2 Route 3
Abbildung 38: Ergebnis der Neuvernetzung mittels Flächenrückführung
Verformung [mm] in Normalenrichtung unter RPS Spannbedingungen
3.4 Simulation der Lacktrocknung in der Prozesskette (CADFEM)
Als wichtige Voraussetzung und als Bestandteil der betrachteten Prozesskette kann
das Trocknungsmodul des VirtualPaintShop® (VPS/DRY) von CADFEM genannt
werden. Es hat sich bei Firmen wie AUDI und BMW im Bereich der lackiergerechten
Konstruktion etabliert, um eine Simulation der Lacktrocknung von Autokarosserien in
großen Trocknungsöfen durchzuführen. Zwischen den einzelnen Lackierschritten ist
jeweils eine Trocknung des Lackes erforderlich, wobei die Bauteile aufgeheizt und
anschließend über eine vorgegebene Zeitdauer auf einem bestimmten Temperatur-
niveau gehalten werden. Mit VPS/DRY kann das Aushärten von Lacken auf Wasser-
basis in diesem thermischen Trocknungsvorgang simuliert werden. Denn im Gegen-
satz zu lösemittelbasierten Lacken, die selbst nachtrocknen, ist bei wasserbasierten
Lacken eine Vernetzung nur durch Aufheizung möglich. Lackanteile, die beim Trock-
nen nicht aushärten, können später nicht nachhärten. Falls im Trockner die Mindest-
temperatur und -haltezeit unterschritten oder eine obere Grenztemperatur und
-haltezeit überschritten werden, sind Qualitätsmängel zu erwarten. Mit VPS/DRY
können kritische Stellen von Bauteilelackierungen ausgemacht sowie die Lackier-
und Trocknungsvorgänge entsprechend vorausgeplant und optimiert werden.
43

44. Im Projekt VIPROF wurde die Lacktrocknungssimulation in die Prozesskette mit auf-
genommen, um den Einfluss vorgelagerter Fertigungsschritte auf das Verhalten der
Karosserie im Trocknungsofen zu überprüfen. Auch der Einfluss von Effekten, die bei
der Lacktrocknung auftreten, wie z. B. des Bake-Hardening-Effektes, auf das Crash-
Verhalten waren von Interesse.
3.4.1 Ergebnisse der Sensitivitätsanalyse
CADFEM hat eine Sensitivitätsanalyse der Lacktrocknung durch eine begleitende
Eigenwertanalyse vorgenommen, um die Sensitivität des Ofenprozesses bezüglich
Einflüssen aus dem Umform- und dem Fügeprozess zu bewerten. Dicken, Spannun-
gen und Dehnungen aus dem Umformen und Fügen wurden in verschiedenen Zu-
sammenstellungen in der Trocknungssimulation VPS/DRY berücksichtigt. Für die
VPS/DRY Simulation wurden gleichmäßig vernetzte Crash-Netze der VW AG ver-
wendet. Vereinfachungen an den Karosseriemodellen zur Beschleunigung der Be-
rechnungen in der Mechanik wurden durch Weglassen von Türen und Klappen sowie
durch Betrachtung halber Modelle mit Symmetriebedingungen vorgenommen, wie in
Abbildung 39 gezeigt. Die Berechnungsvarianten sollten Rückschlüsse erlauben, wie
stark Spannungen und Dehnungen aus der Vorgeschichte das Berechnungsergebnis
bei der Trocknung beeinflussen.
Abbildung 39: Entkerntes Halbmodell für die begleitende Eigenwertanalyse
Das Vorgehen zur Durchführung des mechanischen Verfahrens der begleitenden
Eigenwertanalyse (engl. mode tracking) zur Erkennung von Beulgefahren ist in Ab-
bildung 40 gezeigt. Die Analyse beruht darauf, dass sich unter der thermischen Last
der Aufheizung und Abkühlung im Ofen der Spannungszustand von Blechen und
Strukturen verändert, was einen Einfluss auf die Eigenfrequenzen der Bauteile hat.
44

45. Temperatur- Mechanische Berech- Vorgespannte
berechnung nung mit Temperatur- Modal-
in VPS/DRY randbedingungen analyse
„Mode Tracking“
Abbildung 40: Begleitende Eigenwertanalyse zum Erkennen einer Beulgefahr
Eine Herleitung und Erläuterung dieses Sachverhaltes findet man der Literatur z. B.
bei W. Rust, Nichtlineare Finite-Elemente-Berechnungen, Vieweg + Teubner Verlag,
Abschnitt 3.2.3 Modalanalyse (Eigenfrequenzanalyse) und Stabilitätsprobleme sowie
Abschnitt 3.4.4 Begleitende Eigenwertanalyse. Die folgenden Absätze enthalten An-
lehnungen und Zitate aus dem genannten Buch.
Ein Beispiel für den Einfluss des Spannungszustandes auf die Eigenfrequenz kennt
man aus der Spannung einer Saite eines Musikinstrumentes. Durch Änderung der
Spannung in der Saite wird das Instrument gestimmt. Bei Biege- oder Druckspan-
nungen sinkt die Eigenfrequenz. Im Falle eines Stabilitätsproblems kann das System
ausgelenkt werden, ohne dass es nach Wegnahme der Last – hier in Form der inho-
mogen verteilten Temperaturdehnungen – in die vorherige Lage zurückkehrt. Eine
Eigenfrequenz zu diesem Verformungsmuster wird zu Null.
Werden Eigenwerte begleitend zur Last aufgetragen, erlaubt der Verlauf der Eigen-
werte Rückschlüsse auf das Stabilitätsverhalten, wenn sich zwei Kurven eines Unter-
suchten Bereiches kreuzen oder zu Null werden.
Als begleitende Eigenwertanalyse ermittelt CADFEM die Veränderung der Eigenfre-
quenzen unter der Temperaturlast im Trocknungsofen. Von besonderem Interesse
sind sprunghafte Änderungen, da dann die Gefahr plastischer Verformungen durch
Beulen der Struktur besteht. Solche sprunghaften Änderungen sind beispielhaft für
eine Blechwanne in Abbildung 41 anhand eines Aufheizvorganges gezeigt. Im Pro-
jekt wurde die Methodik der begleitenden Eigenwertanalyse verfeinert und automati-
siert.
45

46. Abbildung 41: Begleitende Eigenwertanalyse (rechts) bei einem stark zum Beulen
neigenden Bauteil (nicht VW-Touran)
Da die Steifigkeiten einer Struktur und die Wärmekapazität durch die Blechdicken-
verteilung beeinflusst werden, hat CADFEM die Einflüsse des Umformens auf das
Verhalten der Karosserie beim Trocknen nach der Lackierung untersucht. Aus One-
step-Berechnungen bei Volkswagen wurden Blechdicken in die Lacktrock-
nungssimulation VPS-DRY importiert. Der Transfer erfolgte exemplarisch auch über
das vereinbarte Zwischenformat (M01) unter Verwendung des SCAIMappers.
Aus den Untersuchungen an den Musterbauteilen des VW Touran ist festzuhalten,
dass im Verlauf der Eigenwerte während des Trocknungsvorgangs zwar Unterschie-
de zwischen konstanter und variabler Blechdicke ausgemacht werden konnten, wie
in Abbildung 42 gezeigt, dass diese Unterschiede jedoch nicht signifikant waren.
Damit sind in der B-Säule keine kritischen Bauteile enthalten, die zum Beulen führen
könnten. Außerdem nimmt die Beulneigung durch Übertragung von Blechdickenver-
teilungen aus der Umformsimulation nicht zu. Damit konnten bei den Untersuchun-
gen am VW Touran keine Beulgefahren identifiziert werden, was daran liegt, dass es
sich um ein ausgereiftes Serienfahrzeug handelt. Da die Berücksichtigung der Um-
formhistorie aber rechentechnisch die Simulation weder vergrößert noch verlangsamt
ist es ratsam die Dicken zu berücksichtigen. Bei Neukonstruktionen ist zu erwarten,
dass mehr Beulneigungen bestehen. Die Biegesteifigkeit ist in der dritten Potenz ab-
hängig von der Blechdicke. Damit kann bei festgestellter Beulneigung die Blechdicke
als Modellfehler ausgeschlossen werden.
46

47. Abbildung 42: Begleitende Eigenwertanalyse während der Trocknungssimulation der
B-Säule unter Verwendung konstanter Blechdicken (links) und bei Übertragung der
Blechdickenverteilung aus dem Umformen (rechts)
Das unkritische Verhalten der B-Säule gegenüber Beulen zeigte sich auch auf einem
virtuellen Teststand (siehe Abbildung 43), mit dem Sensitivitäten hinsichtlich der
Übertragung von Ergebnissen aus vorgelagerten Prozesssimulationen aufgezeigt
werden können. Anhand der unten fixierten und oben künstlich belasteten B-Säule
können die Einflüsse von linearem vs. nichtlinearem Materialgesetz bzw. von kons-
tanten vs. variablen Blechdicken aus der Umformsimulation untersucht werden. In-
dem sehr hohe Belastungen bis in den Bereich der Plastizität aufgegeben werden,
kann der Einfluss der Umformhistorie auf die begleitende Eigenwertanalyse gezeigt
werden. Zunächst diente dies zur Verifikation der Vorgehensweise. Gleichzeitig zeigt
es aber auch die Anwendbarkeit bei anderen Belastungen auf.
47

48. Abbildung 43: Sensitivitätsanalyse der B-Säule im „virtuellen Teststand“. Ein Ang-
riffspunkt ist gelagert, auf den anderen werden steigende Belastungen aufgebracht,
bis sich Auswirkungen in der begleitenden Eigenwertanalyse zeigen.
Die Ergebnisse einer zunehmenden Belastung der B-Säule im virtuellen Prüfstand
zeigt Abbildung 44, wobei die Kurven für konstante bzw. variable Dicke nahe beiei-
nander liegen. Dies zeigt einen gewissen, aber im vorliegenden Fall nicht gravieren-
den Einfluss der Blechdicken auf die Eigenfrequenzen. Größere Veränderungen der
Eigenfrequenzen würden auf Beulen oder Durchschlagen hindeuten. Diese Ergeb-
nisse wurden für ein nichtlineares Materialgesetz erzielt, das die elastische und die
plastische Fließgrenze beinhaltet. Durch diese Nichtlinearität kann eine Verfestigung
aus der Umformsimulation bzw. eine Änderung der Fließgrenze berücksichtigt wer-
den.
48

49. Abbildung 44: Begleitende Eigenwertanalyse der B-Säule im virtuellen Prüfstand mit
steigender Belastung (Dargestellt sind die Verläufe von Eigenfrequenzen über den
Lastschritten, jeweils für ein Modell mit und ohne Berücksichtigung der Blechdicken-
verteilung.)
3.4.2 Untersuchung von Einflüssen des Bake-Hardening-Effektes
Die Ausprägung des Bake-Hardening-Effektes (Reckalterung) hat einen Einfluss auf
die Crash-Eigenschaften der Karosserie. Wie stark dieser Effekt ausgeprägt ist wird
vom Ofenprozess bei der Lacktrocknung mitbestimmt. Daher lag es nahe, in der
Trocknungssimulation VPS/DRY die Festigkeitssteigerung im Trocknungsofen durch
den Bake-Hardening-Effekt zu untersuchen. Bei dem mit Bake Hardening bezeichne-
ten Effekt findet im Trockner bei Temperaturen über 170-180° im Metallgefüge eine
C
Kohlenstoffdiffusion an freie Gitterversatzstellen sehr viel schneller statt, als bei
Raumtemperatur. Durch den Ofenprozess wird somit eine Festigkeitssteigerung er-
zielt und die Fließgrenze ohne Gefügeumwandlung hinaufgesetzt. Diese Festigkeits-
steigerung kann mit Hilfe von VPS/DRY bewertet werden. Der Bake-Hardening-Effekt
kann dann aus der Trocknungssimulation VPS/DRY in das Crash-Modell übertragen
werden.
Aus Materialdatenblättern ist bekannt, dass z. B. für die Stahlsorte CPW800 der
Bake-Hardening-Status erfüllt wird, wenn eine Haltezeit von 20 Minuten bei über
170° erreicht wird. Die Zugfestigkeit des Werkstof fes kann von einem Wert von
C
800 MPa im Mittel um 70 MPa erhöht werden. Die Erhöhung ist abhängig von der
49

50. Verweilzeit des Materials auf einem Temperaturniveau. Während sich in Simulatio-
nen unterhalb dieses Temperaturniveaus keine so stark ausgeprägten inhomogenen
Verteilungen der Haltezeit zeigten, änderte sich die ungleiche Verteilung für Tempe-
raturen über 175° deutlich, wie aus Abbildung 45 a m Außenblech der B-Säule er-
C
kennbar.
Abbildung 45: Darstellung der Haltezeit in Sekunden auf einem bestimmten Tempe-
raturniveau zur Untersuchung der Einflüsse von Bake-Hardening
Ferner zeigt Abbildung 45, dass sich gerade in den Punkten der Lasteinleitung bei
den Scharnieren eine geringere Haltezeit auf den jeweils betrachteten Temperaturni-
veaus einstellt. Dies ergibt sich aufgrund der Wärmekapazität der an diesen Stellen
angebrachten, relativ massiven Scharniere. Ist die Verfestigung aufgrund des unvoll-
ständig ausgeprägten Bake-Hardening-Effektes hier geringer, könnte sich dies also
überproportional auf die Steifigkeit der gesamten Konstruktion auswirken.
In Kooperation mit VW wurden für verschiedene Stähle Excel-Dateien mit Fließkur-
ven für die Simulation hinterlegt. Abhängig von verschiedenen Bake-Hardening-
Zuständen (0% bis 100%) ergeben sich unterschiedliche Spannungs-Dehnungs-
Diagramme. Der Bake-Hardening-Status, der mit der Material-ID verknüpft wird, wur-
de im LS-DYNA Format verfügbar gemacht. Ergebnisdateien können direkt aus
VPS/DRY geschrieben werden. Eine knotenbasierte Datenablage wurde für die
Temperaturen als Funktion der Zeit realisiert, da die Temperatur als Freiheitsgrad der
50

51. Simulation an den Knoten ermittelt wurde und so kein Informationsverlust entsteht.
Für die Haltezeiten sind die Ergebnisse elementbasiert abgelegt, weil die Umrech-
nung der Haltezeit in einen Bake-Hardening-Status auf Elementebene erfolgte. Die
Haltezeit muss nicht notwendigerweise abgelegt werden, da diese aus den Tempera-
turergebnissen nur abgeleitet wird.
1100 Spannung (BH0)
Spannung (BH1)
1050
Spannung (BH2)
1000 Spannung (BH3)
Spannung (BH4)
950
Spannung (BH5)
900 Spannung (BH6)
Spannung (BH7)
850
Spannung (BH8)
800 Spannung (BH9)
Spannung (BH10)
750
0 0,2 0,4 0,6 0,8 1 1,2
Abbildung 46: Unterschiedliche Bake-Hardening-Zustände, die aus verschiedenen
Haltezeiten und Temperaturniveaus resultieren
Um den Einfluss im Rahmen des Projektes exemplarisch aufzuzeigen wurde die
Ausprägung des Bake-Hardening-Effektes linear abhängig zur Haltezeit oberhalb
eines definierten Temperaturniveaus angenommen. Weiterhin wurde die mittlere Ver-
festigung aufgrund des Bake-Hardening proportional zur Ausprägung des Bake-
Hardening-Effektes ansteigend angenommen. In 10 Stufen unterteilt ergeben sich
unter diesen Annahmen Spannungs-Dehnungs-Kurven wie in Abbildung 46 gezeigt.
BH0 Steht dabei für Material ohne Bake-Hardening-Effekt, BH10 für den voll ausge-
prägten Effekt.
51

52. Abbildung 47: Unterschiedliche Materialeigenschaften aufgrund verschiedener Tem-
peraturniveaus im Trocknungsofen
Abbildung 47 zeigt die Verteilung der unterschiedlichen Materialkennungen am Ver-
stärkungsblech der B-Säule mit den Temperaturgrenzen 170, 175 und 180 ° als C
Basis zur Ermittlung der Haltezeit. Dargestellt ist jeweils das Ausgangsnetz der
VPS/DRY Simulation und ein verfeinertes Netz für spätere Anwendungen. In der Si-
mulation wurden die unterschiedlichen Bake-Hardening-Bereiche durch verschiedene
Materialkennungen abgebildet. Die Übergabe des Bake-Hardening-Status an die
Crash-Simulation kann in Form einer virtuellen plastischen Vergleichsformänderung
oder einer je nach Status zugewiesenen Spannungs-Dehnungs-Kurve erfolgen. Häu-
fig wird es so sein, das VPS/DRY und die Crash-Simulation das gleiche Netz ver-
wenden und so nur eine Übertragung der Ergebnisse erforderlich ist. Im Projekt VIP-
ROF war es sinnvoll für spätere Detailuntersuchungen ein feineres Netz zu verwen-
den. Da die Ausgangsbasis und Lage für das Netz aber identisch war, ist der Ergeb-
nisübertrag auf die Neuvernetzung sogar innerhalb von VPS/DRY automatisiert mög-
lich.
M app ing M apping Map pin g
Lacktrocknungs-
Umformsimulation Fügesimulation Crashsimulation
simulation
Format_1 XM L Fo rm at_2 XM L Form at_3 XM L Forma t_4
XML-K onverter
Abbildung 48: Ergebnisübertragung durch Mapping oder innerhalb eines XML-
basierten Datenträgernetzes
52

53. Die Ergebnisübertragung kann aber auch über einen XML-basierten Mapping-
Prozess erfolgen, der momentan noch manuell gestützt wird. Vom Kooperations-
partner TU Berlin wurde ein sog. XML-Konverter programmiert, der die Ausgabefor-
mate der im VIPROF-Projekt eingesetzten Simulationsprogramme (vorzugsweise
.M01-Format) einheitlich in das XML-Format überführen kann (siehe Abbildung 48).
So können Bauteileigenschaften mit Berücksichtigung des Bake-Hardening auf das
Zielnetz, z. B. für eine Crash-Simulation oder einen virtuellen 3-Punkt-Biegeversuch,
übertragen werden. Der Bake-Hardening-Effekt kann in der Simulation durch Variati-
on der Haltetemperatur in seiner Robustheit bewertet werden, um z. B. im Fall von
Materialanhäufungen im Bereich von angeschweißten Scharnieren eine zu geringe
Reckalterung zu vermeiden oder um herauszufinden, ob eine unvollständige Ausprä-
gung des Bake-Hardening-Effektes bezüglich der Anforderungen aus der Crash-
Simulation toleriert werden kann.
Im VIPROF-Projekt wurden keine tensoriellen Größen aus vorgelagerten Prozessen
in der mechanischen Analyse unter der Temperaturlast im Ofen berücksichtigt. Die
für die Berücksichtigung der plastischen Vergleichsformänderung verwendete INIS-
TATE-Funktion von ANSYS kann aber auch dazu verwendet werden. So kann wie in
Abbildung 49 gezeigt der Spannungszustand aus einer Teillösung in eine weitere
Teillösung übertragen werden. Richtig ist ein solches Vorgehen, falls keine geschlos-
sene Lösung der beiden Lastschritte möglich oder gewollt ist und die Konfiguration
nach dem ersten Lastschritt die Startkonfiguration des folgenden Lastschrittes ist.
Abbildung 49: Mechanik-Simulation von Be- und Entlastung mit INISTATE
3.4.3 Zusammenfassung der Ergebnisse von CADFEM
Im Teilvorhaben von CADFEM ist ein Verfahren entstanden, mit dem die Beulnei-
gung von Baugruppen oder einzelnen Blechen unter Berücksichtigung der Umform-
historie und im Zusammenhang mit der ganzen Karosserie identifiziert werden kann.
Der Bedarf, den Ort einer Beulneigung belastbarer vorhersagen zu können, ist eine
Motivation, das zugrunde liegende FE-Modell mit den Einflüssen aus der Herstellung
zu verbessern.
53

54. Zur Definition von Ampelkriterien für die Lacktrocknungssimulation innerhalb des
Modul-Cockpits ist sowohl ein Erreichen der geforderten Prozesstemperaturen, als
auch das Einhalten der Haltedauern für diese Temperaturen erforderlich. Alle direkt
aus der Temperatur ableitbaren Kriterien können ähnlich, einfacher oder komplexer
wie das sog. Einbrennfenster des jeweiligen Lackes (siehe Abbildung 50) bestimmt
werden. Eine Klassifizierung in „Anforderungen erfüllt“ oder „nicht erfüllt“ ist damit
möglich. Die Methoden zur Automatisierung der begleitenden Eigenwertanalyse und
damit die weitgehend automatisierte Identifikation der Beulneigung stellen dies auch
für die Verformung der Karosserie im Trocknungsprozess in Aussicht.
Abbildung 50: KTL-Einbrennfenster (beispielhaft für DuPont)
Als Ergebnis der Sensitivitätsanalyse Umformen Lackieren ist festzuhalten, dass
• ein gewisser Einfluss der Übertragung der Blechdicken aus dem Umformen auf
den Verlauf der Eigenwerte besteht. Im Projekt konnte jedoch kein Einfluss auf
die Beulanfälligkeit der untersuchten Bauteile nachgewiesen werden.
• mit der Übertragung der plastischen Vergleichsdehnungen konnte an den unter-
suchten Bauteilen keine Änderung des Verhaltens identifiziert werden, da die Be-
lastung mit den inhomogen verteilten Temperaturdehnungen die Fließgrenze
nicht erreicht hat.
Für nachgelagerte Prozesse wurde die Bedeutung der Kopplung der Lackiersimu-
lation an die Prozesskette anhand der Übertragung des inhomogen ausgeprägten
Bake-Hardening-Effektes aus der Lacktrocknung gezeigt. Dieser Effekt hat einen Ein-
fluss auf das Crash-Verhalten. Ein Export von inhomogenen Bake-Hardening-
Verteilungen aus der Trocknungssimulation wurde erfolgreich durchgeführt.
54

55. 3.5 Abgleich der Simulationsprozesskette an Praxisbeispielen
(VW)
Volkswagen hat in das Projekt die Anforderungen eines Automobilherstellers an das
Simulationsdatenmanagement eingebracht und war an der Durchführung von Sensi-
tivitätsanalysen und der Erarbeitung eines XML-basierten Datenaustauschformates2
beteiligt.
3.5.1 Katalog gewerkespezifischer Eingangsgrößen
Um die Kopplung von Daten und Prozessen vorzubereiten, wurde von Volkswagen
ein Katalog gewerkespezifischer Eingangsgrößen aufgestellt. Dazu wurde eine Struk-
tur erarbeitet, die eine Kategorisierung in Materialdaten, Geometriedaten und Pro-
zessparameter vorsieht. Diese Struktur ist in Abbildung 51 gezeigt. Der Katalog wur-
de prozessspezifisch aufgebaut und umfasst die für die einzelnen Simulationsstufen
notwendigen Eingangsdaten. Tabelle 4 zeigt einen groben Auszug aus dem Katalog,
der im Verlauf des Vorhabens detailliert wurde.
Abbildung 51: Kategorisierung des Kataloges gewerkespezifischer Eingangsgrößen
2
Die Extensible Markup Language (Abk. XML; engl. für erweiterbare Auszeichnungssprache) erlaubt
die Beschreibung beliebiger Daten. Sie stellt einen Standard zur Modellierung von strukturierten Daten
in Form einer Baumstruktur dar, der vom World Wide Web Consortium (Abk. W3C) definiert wird.
55

56. Eingangsdaten Umformsimulation Fügesimulation Lacktrocknungs-
simulation
Geometriedaten Bauteile (.igs) und Bauteile (.igs) Crashnetz, Schweiß-
Ziehanlagen (.igs) punktinformationen
Bauart/Abmessungen
des Trockners
Prozessdaten Blechhalterhub Position der Positionierung/ Maße
Schweißpfade der Düsen
Blechhalterkraft
Mechanische Temperaturen
Reibwert und
Randbedingungen (Ofen/Karosserie)
Reibwertverteilung
Typ Schweißpro- Vorschub-
Sickenersatzkräfte
zess Geschwindigkeit
Blechdicke …
… Prozesszeiten
…
Materialdaten E-Modul E-Modul E-Modul
Querkontraktion Querkontraktion Querkontraktion
Dichte Thermischer Aus- Thermischer Ausdeh-
Anisotropiewerte dehnungskoeff. nungskoeff.
Fließkurve Fließkurve
Fließkurve
… …
…
Tabelle 4: Katalog gewerkespezifischer Eingangsgrößen
3.5.2 Übertragung von Simulationsdaten mit XML-Konverter
Zusammen mit den Kooperationspartnern ARC Solutions GmbH, TU Berlin und TU
Chemnitz war Volkswagen an der Konzeption des Datenmodells und eines Datenträ-
gernetzes beteiligt, mit dem Simulationsdaten zwischen den einzelnen Prozessstufen
übertragen und auch visualisiert werden können. Eine Anlehnung an das Produktda-
tenmanagement (PDM) der VW AG wurde angestrebt, das mit dem System CON-
NECT auf Basis von TEAMCENTER bewerkstelligt wird. Das bevorzugte Datenaus-
tauschformat in CONNECT ist *.JT3 (Jupiter Tessellation) für eine Software-
unabhängige Visualisierung im PDM-System. Als einheitliches Datenformat für das
Datenträgernetz wurde das standardisierte XML-Format avisiert. Mit dem Datenträ-
gernetz sollte eine durchgängige Übertragung von Ergebnisdaten aus den einzelnen
Simulationsstufen bis hin zur Crash-Simulation gelingen sowie eine Ankopplung an
das PDM von VW.
3
Das lizenzkostenfreie JT-Format unterstützt unterschiedlichste Repräsentationen von CAD-
Geometrien und erlaubt eine 3D-Visualisierung.
56

57. Zur Anbindung an TEAMCENTER/CONNECT wurde von der TU Berlin ein sog.
XML-Konverter programmiert, der die Ausgabeformate der im VIPROF-Projekt ein-
gesetzten Simulationsprogramme (vorzugsweise .M01-Format) einheitlich in das
XML-Format überführen kann. Diese Ausbaustufe 1 ist in Abbildung 52 gezeigt.
Unabhängig von der Anzahl unterschiedlicher Datenformate ist nur eine XML-
Schnittstelle zu TEAMCENTER/CONNECT erforderlich. Somit gelingt eine Standar-
disierung von Simulationsdaten zur Integration in das PDM-System.
Innerhalb von TEAMCENTER/CONNECT können .JT-Dateien aus XML zur Visuali-
sierung generiert werden. Im Auftrag von VW wurde dazu vom Fraunhofer IGD in
Darmstadt ein Konverter zur Übertragung von VIPROF-XML-Daten in das JT-Format
entwickelt. Durch Übertragung von XML- in das JT-Format können auch lizenzfreie
Standard-Viewer genutzt werden, da direkt binäre JT-Files ohne Nutzung des JT-
Toolkits von Siemens erzeugt werden. Dies erlaubt zudem eine Unabhängigkeit von
zukünftigen Änderungen seitens Siemens. Unabhängig von der Anzahl unterschied-
licher Datenformate ist nur eine Visualisierung innerhalb des PDM-Systems notwen-
dig. [PIN110]
Abbildung 52: Ausbaustufe 1: Anbindung der einzelnen Simulationsstufen an TEAM-
CENTER/CONNECT mit einem XML-Konverter [PIN110]
In Ausbaustufe 2 könnte das Mapping-Tool um eine XML-Schnittstelle erweitert wer-
den, wie in Abbildung 53 gezeigt. Dies wurde aber im Vorhaben nicht mehr realisiert.
In Ausbaustufe 3 könnte der Mapping-Prozess sogar ganz in den XML-Konverter
integriert werden (siehe Abbildung 54), so dass kein separates Mapping-Tool mehr
erforderlich wäre. Ob mit oder ohne diese beiden Ausbaustufen können die Ergeb-
nisse zwischen den Simulationsstufen nahezu automatisch übertragen werden.
57

58. Abbildung 53: Ausbaustufe 2: Anbindung Mapping-Tool [PIN110]
Abbildung 54: Ausbaustufe 3: Ergebnisübertragung innerhalb eines XML-basierten
Datenträgernetzes [PIN110]
Im Projekt letztlich realisiert wurde der in Abbildung 55 gezeigte Prototyp der Pro-
zesskettensimulation. Über den XML-Konverter gelingt die Übertragung von Simula-
tionsergebnissen aller Stufen in das Produktdatenmanagement. Die Ergebnisüber-
tragung zwischen den Simulationsstufen erfolgt vorzugsweise über den SCAI-
Mapper, kann aber prinzipiell auch durch Abruf von Informationen aus dem PDM via
XML-Konverter erfolgen.
58

59. Abbildung 55: Realisierter Prototyp der Kopplung der Simulationsstufen [PIN110]
Volkswagen hat einen Unterauftrag an das Fraunhofer IGD, Darmstadt, zur Entwick-
lung eines Konverters zur Generierung von JT-Dateien aus dem VIPROF-XML-
Format für Simulationsergebnisse der Umformsimulation vergeben. Für die Visuali-
sierung wurden u.a. die folgenden Möglichkeiten geschaffen:
• Falschfarbendarstellung von Blechdicke, plastischer Vergleichsdehnung, Ver-
gleichsspannungen (von Mises) mit einstellbarem Farbintervall. Die Darstellung
der Ergebnisgrößen (Minimal-Wert = „blau“, Maximal-Wert = „rot“) kann in „true
color“ mit kontinuierlichem oder auch mit diskretem Farbübergang erfolgen. Die
Farbskalierung wird beim Schreiben des JT-Files erzeugt.
• Gruppierung von Bauteilen (siehe Abbildung 56). Unterschiedliche JT-Dateien
können als Baugruppe dargestellt werden. Die Bauteile können separat ein- und
ausgeblendet werden.
Abbildung 56: Gruppierung von Bauteilen als
Möglichkeit der Visualisierung von CAE-Daten in JT-Viewern [PIN110]
59

60. • Die erzeugten JT-Geometrien repräsentieren das ursprüngliche FEM Netz. Das
Ein- und Ausblenden des FEM-Netzes in der JT-Visulisierung ist möglich
(Abbildung 57).
Abbildung 57: Darstellung des FEM-Netzes im JT-Viewer [PIN111]
Durch die Visualisierung von CAE-Daten im JT-Format sind die FEM-Ergebnisse im
Kontext des Digital Mock-up des Gesamtfahrzeuges darstellbar und auswertbar, wie
in Abbildung 58 gezeigt.
Abbildung 58: Visualisierung der FEM-Daten im VisMockup [PIN110]
60

61. Zu dem im Unterauftrag von VW vom Fraunhofer IGD entwickelten Konverter zur
Generierung von JT-Dateien aus dem VIPROF-XML-Format hat VW eine GUI prog-
rammiert, mit der Ergebnisgrößen auf verschiedene Weise gemäß Benutzervorgaben
dargestellt werden können, z. B. mit fließender oder diskreter Farbanzeige, mit An-
gaben von Dickenänderungen in mm oder % usw. Verschiedene CAE-Teile sind als
Baugruppe darstellbar. Sie können im Kontext ihrer Umgebung oder des Gesamt-
fahrzeuges gezeigt werden. Die Unabhängigkeit der JT-basierten Visualisierung von
Lizenzkosten kommt auch der Nutzbarkeit durch mittelständische Lieferanten entge-
gen. Die Vorteile der Visualisierung im JT-Format sind in Abbildung 59 zusammenge-
fasst.
Abbildung 59: Visualisierung von CAE-Ergebnissen im CAD-Gesamtfahrzeugkontext
[PIN111]
3.5.3 Vergleich OneStep- und inkrementelle Umformsimulation mit Benchmark
OneStep-Solver
Um in der frühen Produktentwicklungsphase, d.h. zu einem Zeitpunkt, bei dem noch
keine Angaben zu Fertigungsprozessen, wie z. B. CAD-Daten zu Umformwerkzeu-
gen, vorliegen, dennoch eine Aussage zur Herstellbarkeit von Bauteilen zu erhalten,
ist es sinnvoll, die inverse Umformsimulation (OneStep-Solver) in die Prozesskette
einzubeziehen. Sie benötigt lediglich die CAD-Geometrie des Bauteils sowie die Ma-
terialdaten. Durch eine Rückrechnung der umgeformten Geometrie auf die ebene
Platine werden die plastischen Dehnungen und die Blechdickenverteilung berechnet.
61

62. Auch eine Abschätzung der erforderlichen Platinengröße gelingt mit einem OneStep-
Solver. [PIN209]
Von Interesse war die mit einem OneStep-Solver erreichbare Genauigkeit, verglichen
mit der Realität und der inkrementellen Umformsimulation. Um die Ergebnisqualität
von OneStep-Solvern der Umformsimulation beurteilen zu können hat Volkswagen
einen Praxisabgleich von Simulationsergebnissen vorgenommen. Für die folgenden
drei OneStep-Solver wurde ein Benchmark durchgeführt.
• FTI-FormingSuite 7.2
• ESI PAM-TFA for Catia V5
• AutoForm Onestep for Catia 1.1
Als Bewertungsgrundlage für den Benchmark wurde die Ergebnisgröße Blechdicke
gewählt, da diese eine hohe Relevanz für das Mapping entlang der Prozesskette be-
sitzt und am Ziehteil der Praxis sowie am Ziehteil der Simulation gut messbar ist. Um
die Blechdicke am realen Bauteil zu erfassen, wurde ein Ultraschallmessgerät einge-
setzt. Es wurden fünf Crash-relevante Strukturbauteile mit einem breiten Spektrum
von Nennblechdicken und unterschiedlichen Werkstoffen untersucht. An den realen
Bauteilen wurden in kritischen und unkritischen Bereichen Messpunkte definiert. Wie
in Abbildung 60 dargestellt, wurden Abweichungen der Ergebnisgröße bewertet (grü-
ner Bereich falls relativer Fehler ≤ 5%, gelb falls 5-10%, rot falls >20%). [PIN209]
Abbildung 60: Bewertungskriterien des Benchmarks [PIN209]
62

63. Ebenfalls untersucht wurde der Einfluss der Rückhaltekraft am Bauteilrand, wobei
diese Kraft beim Umformen schrittweise erhöht wurde (siehe Abbildung 61).
Abbildung 61: Untersuchung Einfluss Rückhaltekraft am Bauteilrand bei Benchmark-
teil 3 (Abschlussblech). Aufgetragen ist die bewertete Zahl der Messpunkte über der
Rückhaltekraft für die Solver A, B und C. [PIN209]
Als Resultat ist festzuhalten, dass diese Rückhaltekräfte am Bauteilrand für die
OneStep-Simulation notwendig sind, um den Einfluss der Ankonstruktion nähe-
rungsweise in der One-Step Simulation zu berücksichtigen und realistische Ergeb-
nisse zu erzielen. Es zeigte sich eine relativ gute Übereinstimmung der mit den One-
Step Solvern berechneten Blechdicken mit den gemessenen Werten der Realität.
[PIN209]
Außerdem wurden die Ergebnisse der drei OneStep-Solver mit inkrementellen Simu-
lationsergebnissen verglichen. Um eine Gütekennzahl für den Vergleich der Ergeb-
nisqualität zu erhalten wurden den Solvern für jedes Ergebnis eines Messpunktes
entsprechend der einzelnen Wertebereiche folgende Punkte vergeben:
• grün = 1 Punkt,
• gelb = 0,5 Punkte,
• rot = 0 Punkte.
Die Ergebnisqualität in Form der Gütekennzahl als Summe dieser Punkte ist für die
betrachteten Solver in Abbildung 62 dargestellt. Es wird ersichtlich, dass die Ergeb-
63

64. nisqualität der OneStep-Solver in Bezug auf die berechneten Blechdicken an die der
inkrementellen Umformsimulation heranreicht, so dass ein Mapping der OneStep-
Ergebnisse auf nachfolgende Simulationen sinnvoll erscheint. Die Berechnungszei-
ten der OneStep-Solver waren, in Abhängigkeit der Bauteilkomplexität, mit Zeiten
zwischen 3 s und 6 min recht moderat. [PIN209]
Abbildung 62: Vergleich der Ergebnisgüte der OneStep-Solver [PIN209]
Wird die Blechdickenverteilung für die B-Säule des Touran betrachtet, liefert die
OneStep-Simulation ein qualitativ gutes Ergebnis (siehe Abbildung 63), welches es
plausibel erscheinen lässt, in der frühen Entwicklungsphase die OneStep-Ergebnisse
in nachfolgende Simulationen entlang der Prozesskette zu übertragen, anstatt mit
konstanten Blechdicken weiter zu rechnen. Betrachtet man hingegen die Ergebnis-
größe plastische Vergleichsdehnung werden größere Abweichungen, insbesondere
im Flankenbereich, zu den Ergebnissen der inkrementellen Simulation sichtbar
(Abbildung 64). Während die Biegeeffekte in den Radien gut wiedergegeben werden,
ist dies für Flächen in Ziehrichtung aufgrund der Biegung-Rückbiegung weniger der
Fall, da dieser Effekt durch die OneStep-Methode nicht abgebildet wird. Gegenüber
der inkrementellen Umformsimulation liefert die OneStep-Simulation in Bereichen
größerer Ziehtiefen um den Faktor zwei geringere plastische Vergleichsdehnungen.
Da die plastische Vergleichsdehnung ein Maß für die Kaltverfestigung des Blech-
werkstoffes ist, fallen die Ergebnisverbesserungen bei der Crashsimulation mit Um-
formhistorie aus der OneStep-Simulation nur ca. halb so groß aus wie die Ergebnis-
verbesserungen der Crashsimulation mit Umformhistorie aus der inkrementellen Um-
formsimulation (siehe Abbildung 65). [PIN311]
64

65. Abbildung 63: Vergleich der Ergebnisgröße Blechdicke aus inkrementeller
und OneStep-Umformsimulation [PIN311]
Abbildung 64: Vergleich der Ergebnisgröße plastische Vergleichsdehnung aus in-
krementeller und OneStep-Umformsimulation [PIN311]
65

66. Abbildung 65: Vergleich der Barriere-Crash-Simulation unter Berücksichtigung der
inkrementellen oder der OneStep-Umformsimulation
(Dargestellt ist die Verbesserung der max. Intrusionen an der B-Säule in [mm].)
[PIN311]
Schließlich ist zu beachten, dass die OneStep-Simulation gegenüber der genaueren
inkrementellen Berechnung einen erheblichen Zeitvorteil aufweist: Während eine
OneStep-Berechnung weniger als eine Minute dauert, benötigt die inkrementelle Um-
formsimulation mehrere Stunden. Ein weiterer Vorteil für die Anwendung in der frü-
hen Produktentwicklungsphase ist, dass für die OneStep-Simulation keine Werk-
zeugwirkflächen benötigt werden. [PIN209]
3.5.4 Bewertung der Prozesskettensimulation
Zur Bewertung der Prozesskettensimulation hat VW eine Untersuchungsmatrix auf-
gestellt (siehe Abbildung 66), in der die Kopplung verschiedener Prozesssimulatio-
nen in ihrer Auswirkung auf das Crash-Verhalten als wichtige Produkteigenschaft des
Fahrzeuges analysiert wird. Ein Crash-Modell für die Variantenrechnungen wurde
aufgebaut. Betrachtet wurden nur die definierten Musterbauteile im Seitencrash, da
die Berechnungen für die Gesamtkarosserie viel zu umfangreich gewesen wären.
Entsprechende Mappings für die bis zu 11 Varianten wurden vorbereitet. Alle Varian-
ten wurden miteinander verglichen und mit Hilfe des Standard-Auswerteprotokolls
von VW anhand des Crash-Ergebnisses bewertet. Damit waren die Auswirkungen
unterschiedlicher Einflüsse auf das Berechnungsergebnis erfassbar, und nicht zuletzt
konnte das Verhältnis von Aufwand zu Nutzen hinsichtlich einzubeziehender Pro-
zesssimulationen beurteilt werden.
66

67. Abbildung 66: Bewertung der Prozesskettensimulation anhand von Crash-
Simulationen [PIN309]
3.5.4.1 Mapping von Umform- auf Crash-Simulation (Varianten 1 und 2)
Als weiterer Vergleich der beiden Solver-Varianten wurde im Rahmen einer globalen
Sensitivitätsanalyse ein Mapping der Onestep- und der inkrementellen Umformsimu-
lation auf die Crash-Simulation durchgeführt und ausgewertet (entsprechend den
Varianten 1 und 2 in Abbildung 66). Die Auswirkungen werden durch die Ergebnis-
größen „Eindringtiefe“ und „Größe des Überlebensraums“ aus der Crash-Simulation
bewertet. Betrachtet wird dabei ein Seitenaufprall als Pfahl- und als Barriere-Crash.
Diese gemäß der Euro-NCAP-Vorschrift durchgeführten Crash-Simulationen sind in
Abbildung 67 gezeigt. Neben den Musterbauteilen der B-Säule wurde mit dem Sitz-
querträger ein zusätzliches Bauteil einbezogen (siehe Abbildung 68). [PIN210]
Mit der maximalen Eindringtiefe (Intrusion) und dem Überlebensraum wurden Krite-
rien definiert, mit denen verschiedene Varianten der Berücksichtigung der Ferti-
gungshistorie bewertet werden können (siehe Abbildung 69).
67

68. Abbildung 67: Crashmodell für globale Sensitivitätsanalysen im Seitenaufprall
(links: Pfahl-Crash, rechts: Barriere-Crash) [PIN210]
Abbildung 68: Sitzquerträger für Crash-Simulation [PIN210]
Abbildung 69: Kriterien zur Bewertung unterschiedlicher gekoppelter
Berechnungsvarianten [PIN210]
68

69. Gegenüber der Referenz ohne Berücksichtigung der Umformhistorie (Blechausdün-
nung und plastische Dehnung) zeigten sich beim Mapping der Umformergebnisse
aus der inkrementellen Simulation Verbesserungen im Crash-Verhalten. Auch das
Mapping der Umformhistorie aus der Onestep-Simulation verbesserte die Vorhersa-
ge des Crash-Verhaltens. Die Ergebnisse tendierten deutlich in Richtung der Crash-
Ergebnisse mit Umformhistorie aus der inkrementellen Simulation. Die Auswertung
der Crash-Simulation unter Berücksichtigung der Umformhistorie ergab die in Tabelle
5 gezeigten Ergebnisse, wobei erneut deutlich wird, dass die Crashergebnisse mit
inverser Umformsimulation zwischen den Ergebnissen ohne Berücksichtigung der
Historie und denen der inkrementellen Umformsimulation liegen, was auf die halb so
großen plastischen Vergleichsdehnungen aus der OneStep-Simulation zurückzufüh-
ren ist. [PIN311]
Ergebnisgrößen bei Pfahl-Crash Inkrementelle Um- Inverse Umformsimu-
formsimulation lation
ESI PAM-STAMP Forming Suite 8.1
Strukturverhalten: Max. Intrusion Verbesserung um Verbesserung um
4 mm 2 mm
Überlebensraum: Verbesserung um Verbesserung um
6 mm 3 mm
Tabelle 5: Ergebnisverbesserung der Crash-Vorhersage mit Umformhistorie [PIN311]
Für die Kopplung von der Umform- zur Crash-Simulation wurden folgende Aussagen
abgeleitet bzw. relevante Ergebnisgrößen identifiziert [PIN311]:
• Die Auswertung der Crash-Berechnungen hat gezeigt, dass die Blechausdün-
nung und die plastische Dehnung den größten Einfluss auf das Crash-Ergebnis
haben. Diese Größen sollten in die Crash-Simulation übertragen werden.
• Die jeweils einzelne Übertragung von Blechausdünnung und plastischen Deh-
nungen ist nicht zielführend. Durch Mapping der Ausdünnung ohne die zugehöri-
ge Werkstoffverfestigung wird die Bauteilstruktur „künstlich“ geschwächt und die
Crash-Ergebnisse verschlechtern sich. Das Mapping der plastischen Dehnungen
69

70. (als Maß für die Verfestigung) ohne die zugehörige Materialausdünnung führt zu
einer künstlichen Verbesserung des Crash-Verhaltens in der Simulation.
• Ein Mapping von Spannungen erscheint wenig sinnvoll, da die Einflüsse im Be-
reich des Grundrauschens des Crash-Modells liegen.
• Die Feststellung, dass die OneStep-Methode in Bereichen hoher Ziehtiefe zu ge-
ringe plastische Vergleichsdehnungen liefert, hat sich in der Crash-Simulation un-
ter Berücksichtigung der Umformhistorie bestätigt. Die Ergebnisse mit Berück-
sichtigung der OneStep-Ergebnisse zeigen im Vergleich zu den Crash-
Simulationen mit inkrementeller Umformhistorie den Einfluss der um die Hälfte
reduzierten plastischen Vergleichsdehnung (Kaltverfestigung). Daraus leitet sich
die Empfehlung ab, die OneStep-Simulation für Bauteile mit sehr großen Ziehtie-
fen nicht einzusetzen.
3.5.4.2 Mapping von Umform- über Füge- auf Crash-Simulation (Varianten 3, 4
und 5)
Volkswagen hat Schweißverzugssimulationen der B-Säule auf Basis von Daten von
ESI durchgeführt und einen Praxisabgleich der Simulationsvarianten mit und ohne
Umformhistorie im Messlabor der VW AG anhand mehrerer realer Schweißbaugrup-
pen der B-Säule durchgeführt (siehe auch Kapitel 3.5.5.1). Werden die Blechdicken
und die plastischen Dehnungen aus der inkrementellen Umformsimulation in die
Schweißverzugssimulation übertragen, zeigt sich ein signifikanter Einfluss. Am Kopf
der B-Säule stellen sich die richtigen Verzugswerte und die richtige Drehrichtung ein
(siehe Abbildung 70) [PIN310]. Werden nur die Blechdicken oder nur die plastischen
Vergleichsdehnungen übertragen, weichen die vorhergesagten Verzugswerte stärker
ab. Die Verbesserung der Ergebnisqualität der Schweißverzugssimulation konnte
auch mit Berücksichtigung der Umformhistorie (Blechdicken und plastische Ver-
gleichsdehnungen) aus der OneStep-Simulation erzielt und im Praxisabgleich bestä-
tigt werden (siehe Abbildung 71). [PIN311]
70

71. Abbildung 70: Auswirkungen der Berücksichtigung der Historie aus der inkrementel-
len Umformsimulation in der Schweißverzugssimulation [PIN310]
Abbildung 71: Vergleich Auswirkungen der Historie aus der inkrementellen Umform-
simulation (oben) und OneStep (unten) in der Schweißverzugssimulation [PIN311]
Auch ein Mapping von Spannungen oder Verzügen aus dem Fügeprozess in die
Crash-Simulation erscheint wenig sinnvoll, da die Einflüsse im Bereich der numeri-
schen Streuung des Crash-Modells liegen. Die Schweißprozesse (Laser- und Wie-
derstands-Punkt-Schweißen) führen nicht zu großflächig signifikanten Änderungen
71

72. der Blechdicken und plastischen Vergleichsdehnungen, so dass diese Größen direkt
aus dem Umformen in die Crash-Simulation weitergeleitet werden können.
Die Erkenntnis, dass die Übertragung von Blechdickenverteilung und Verfestigung
sinnvoll ist, von Spannungen dagegen nicht, kommt dem Übertragungsprozess ent-
gegen: Während die Blechdicken und Verfestigungen als skalare Größe leicht über-
tragen werden können, müsste in die Übertragung der Spannungstensoren mehr
Aufwand investiert werden. Anders sieht dieser Sachverhalt aus, wenn man anstelle
des verwendeten Schweißverzugssimulationstools Weld Planner (Nutzung von Fü-
gestellenersatzmodellen) ein transientes Schweißverzugssimulationstool verwendet
(z. B. mit SYSWELD). Hier können die Eigenspannungszustände durchaus einen
signifikanteren Einfluss auf das Simulationsergebnis haben.
3.5.4.3 Mapping von Umform- über Füge- auf Lacktrocknungssimulation (Va-
rianten 6, 7 und 8)
Ähnlich wie bei der Fügesimulation die Verfestigung einen untergeordneten Einfluss
auf das Simulationsergebnis hat, ist dies auch in der Ofensimulation der Fall. Dies
wurde in einem Vergleich zwischen elastischem Materialverhalten und plastischem
Verhalten mit sehr niedriger Fließgrenze gezeigt. Es waren praktisch keine Unter-
schiede in der Beulneigung bei den mechanischen Belastungen im Ofen zu erken-
nen. Zur Verifikation des Vorgehens wurden noch Belastungen in einem virtuellen
Prüfstand aufgebracht, die auf jeden Fall zum Beulen führen. Bei Berücksichtigung
der Blechdicken konnte man den Einfluss der Blechdicke in den ermittelten Eigenfre-
quenzen der begleitenden Eigenwertanalyse zwar erkennen, aber alle im Projekt un-
tersuchten Blechteile einschließlich des Seitenrahmens waren bei den vorgegebenen
Ofenlasten so unkritisch gegenüber Beulverhalten, dass hier der Einfluss auf die
Beulneigung nicht quantifiziert werden konnte. Dies war auf den Reifegrad der ver-
wendeten Serienbauteile zurückzuführen. [CSB11]
3.5.4.4 Mapping von Umform- über Lacktrocknungs- auf Crash-Simulation (Va-
rianten 9 und 10)
Die Sensitivitätsanalyse vom Umformen auf die Lacktrocknung zeigte, dass die Über-
tragung der Blechdickenverteilung einen geringen Einfluss auf die Eigenwerte der
Bauteile hat. Bei den plastischen Vergleichsdehnungen konnte kein Einfluss festges-
tellt werden. In der begleitenden Eigenwertanalyse von CADFEM, die Beulgefahren
aufdecken soll, ergaben sich nur geringe Unterschiede in den Eigenwerten zwischen
den Ausgangs- und den umgeformten Blechdicken. Hierbei muss beachtet werden,
72

73. dass es sich bei den Musterbauteilen des VW-Touran um ausgereifte Serienteile
handelt. Bei Neukonstruktionen ist zu erwarten, dass mehr Beulneigungen bestehen,
was den Einsatz der Methode der begleitenden Eigenwertanalyse rechtfertigt.
[CSB11]
Ebenfalls hatten die Verfestigung und die Änderung der Fließgrenze aufgrund des
Umformens einen vernachlässigbaren Einfluss [CSB11].
Die Übertragung der Blechdickenverteilung kann einen Einfluss auf die Lacktrock-
nung haben, da sich durch unterschiedliche Blechdicken die Wärmeleitung verändert
[CSB11].
3.5.4.5 Mapping von Lacktrocknungs- auf Crash-Simulation (Variante 11)
Da sich durch den Trocknungsprozess sowohl die Blechdicken als auch die plasti-
schen Vergleichsdehnungen der Versuchsteile nicht änderten, war eine Übertragung
dieser Ergebnisgrößen aus der Lacktrocknungssimulation in die Crash-Simulation
nicht notwendig. Bei Bauteilen aus Bake-Hardening-Materialien hat es sich jedoch
als sinnvoll erwiesen, die mit der Lacktrocknungssimulationssoftware von CADFEM
errechneten Bake-Hardening-Zustände der Bauteile mit den zugehörigen modifizier-
ten Fließkurven in der Crash-Simulation zu berücksichtigen. [CSB11]
3.5.5 Validierung der Prozesskettensimulation
3.5.5.1 Validierung durch Messung des Schweißverzugs
Volkswagen hat einen Praxisabgleich der Schweißverzugssimulation (ESI-
WELDPLANNER) für die gewählte Musterbaugruppe (siehe auch Kapitel 3.3.5, Ab-
bildung 32) durchgeführt. Es wurden zwei Simulationsvarianten der Baugruppe un-
tersucht. Einerseits das sog. „CAD-Modell“, wobei hier alle Einzelkomponenten die
aus der Konstruktion festgelegten Blechdicken erhalten und ein spannungs- und
dehnungsfreier Anfangszustand vorliegt. Andererseits das „Kopplungs-Modell“, wobei
hier die Blechdicken und die plastischen Dehnungen aus der Umformsimulation im
Gesamtmodell als Anfangsbedingungen vorliegen. Die Ergebnisse dieser zwei Va-
rianten der Schweißverzugssimulation werden nachfolgend vorgestellt und mit dem
an der realen Baugruppe ermittelten Schweißverzug verglichen. Die Messergebnisse
des Verzuges in y-Richtung sind in Abbildung 72 dargestellt. Für eine statistische
Absicherung wurden mehrere Schweißbaugruppen vermessen. Die berechnete Ver-
drehung aus den Simulationsmodellen zeigt Abbildung 73. [PIN310]
73

74. Y +0,0 Y -0,1
Y +0,5
Y -0,2 Y +0,5
z
-y
x
Abbildung 72: Messergebnisse des y-Verzuges an der B-Säule (in mm)
und Verdrehungsrichtung [PIN310]
a) b)
z x z x
y y
-0,1
0,0
Abbildung 73: Verzug in y-Richtung der B-Säule:
CAD-Modell (a) und Kopplungs-Modell (b) [PIN310]
Es zeigt sich deutlich der Einfluss der Umformhistorie auf das Ergebnis der Schweiß-
verzugssimulation. Während die B-Säule des „CAD-Modelles“ sich weitestgehend in
positive y-Richtung verzieht, stellt sich an der B-Säule des „Kopplungs-Modelles“
teilweise ein negativer y-Verzug ein. Noch deutlicher wird der Einfluss der Umform-
historie auf das Simulationsergebnis bei Betrachtung der Verdrehungsrichtung am
Kopf der B-Säule im Vergleich mit der Praxismessung. Erst mit Berücksichtigung der
Umformhistorie (Blechausdünnung und plastische Dehnungen) wird die am Kopf der
B-Säule auftretende Verzugsrichtung in der Schweißverzugssimulation entsprechend
der Praxismessung richtig berechnet. [PIN310]
74

75. 3.5.5.2 Validierung mit 3-Punkt-Biegeversuch
Volkswagen hat einen 3-Punkt-Biegeversuch für die B-Säule aufgebaut, wie in Abbil-
dung 74 gezeigt. Darauf wurden die B-Säule und die Verstärkung der B-Säule zer-
störend geprüft, um den Einfluss der Umformhistorie in der Crash-Simulation in der
Praxis zu validieren. Zur Kalibrierung des Simulationsmodells wurde eine ARAMIS-
Berasterung vorgesehen. Verschiedene Varianten mit und ohne Umformhistorie, d.h.
mit / ohne Blechausdünnung und mit / ohne plastischer Vergleichsdehnung sowie mit
/ ohne Eigenspannungen, wurden berechnet und verglichen. [PIN311]
Abbildung 74: Schematischer Aufbau des 3-Punkt-Biegeversuches bei VW zum Pra-
xisabgleich der Simulation eines Seitencrashs an der B-Säule [nach PIN311]
Der Vergleich der Versuchsergebnisse mit der Simulation, in der die Umformhistorie
mit Blechdicken und plastischen Dehnungen berücksichtigt wurde, zeigte eine sehr
gute Übereinstimmung des Biegeverhaltens und des Kraftverlaufs, wie aus Abbildung
75 erkennbar. Die Übertragung von Eigenspannungen aus der Umformsimulation
hatte keinen Einfluss auf das Ergebnis. [PIN311]
75

76. Abbildung 75: Vergleich Simulation und Biegeversuch an der B-Säule [PIN311]
Weiterhin wurden Bauteile aus einem Material mit ausgeprägtem Bake-Hardening-
Effekt getestet, um Ergebnisse aus der Trocknungssimulation zu validieren, indem
unbehandeltes Material mit einer vorbehandelten Charge aus dem Trocknungsofen
verglichen wurde. Die Ergebnisse zeigten, dass eine Berücksichtigung des Bake-
Hardening-Effektes in der Simulationsprozesskette sinnvoll ist. [PIN311]
3.5.6 Modulcockpit
Um Transparenz entlang der Prozesskette zu schaffen, wurde ein Modulcockpit rea-
lisiert. Damit kann der Reifegrad einer Produktentwicklung jederzeit abgefragt wer-
den. Jeder relevante Prozess muss erst abgesichert sein bzw. für jedes relevante
Einzelteil muss die Herstellbarkeit gegeben sein, bevor es durch eine „grüne Ampel“
für den nächsten Fertigungsprozess freigegeben wird (siehe Abbildung 76). [PIN109]
Abbildung 76: Reifegrad-Cockpit für die simulationsbasierte Herstellungsbewertung
[PIN109]
76

77. Die Definition von Ampelkriterien wird nachfolgend beispielhaft für die Lacktrock-
nungssimulation erläutert. Für eine ausreichende Lacktrocknung ist sowohl das Er-
reichen der geforderten Prozesstemperaturen, als auch das Einhalten der Halte-
dauern für diese Temperaturen erforderlich. Diese Kriterien können für den jeweiligen
Lack dem sog. Einbrennfenster (siehe Abschnitt 3.4, Abbildung 50) entnommen und
in den Workflow aufgenommen werden. Analog dieser Vorgehensweise wurden auch
für die anderen Simulationsgewerke Ampelkriterien für die Herstellbarkeit definiert.
Literatur:
[PIN109] Pinner, S. et al.: Durchgängige Virtualisierung der Entwicklung
und Produktion von Fahrzeugen, Fachtagung Digitales Enginee-
ring, Fraunhofer Wissenschaftstage, 16.-18. Juni, Magdeburg,
2009.
[PIN209] Pinner, S. et al.: Einsatz inverser Solver innerhalb der Prozess-
kettensimulation im Bereich Karosseriebau, ANSYS Conference
& 27. CADFEM Users‘ Meeting, Leipzig, 2009.
[PIN309] Pinner, S. et al.: Integrierte Prozesskettensimulation bei der Ka-
rosserieherstellung im Projekt VIPROF, ANSYS Conference &
27. CADFEM Users‘ Meeting, Leipzig, 2009.
[PIN110] Pinner, S.: Universelle Visualisierung von Simulations-Ergebnis-
daten im JT-Format. 16. JT User Group Treffen, Fraunhofer IGD,
30. März, Darmstadt, 2010.
[PIN210] Pinner, S.: Lieferantenintegration am Beispiel der Prozesskette
Umformen-Fügen-Lackieren, VIPROF Industriearbeitskreis Pro-
zesskettensimulation, 08. Juni, Fellbach bei Stuttgart, 2010.
[PIN 310] Pinner, S. et al.: Prozesskettensimulation im Karosseriebau am
Beispiel der Kopplung von Umform- und Fügesimulation, 15.
Internationale Konferenz für Simulation und Berechnung - SIM-
VEC, 16. - 17. November, Baden-Baden, 2010.
77

78. [PIN111] Pinner, S.: Visualisierung von CAE-Ergebnisdaten im JT-Format.
Fachkonferenz „Berechnung im Produktprozess“, 10. Februar,
Braunschweig, 2011.
[PINSB11] Pinner, S.; Steinbeck-Behrens, C.: Übersicht Prozesskettensimu-
lation. 2. VIPROF Industriearbeitskreis, 22. November, Stuttgart,
2011.
[PIN311] Pinner, S.: Prozesskettensimulation im Karosseriebau. 2. VIP-
ROF Industriearbeitskreis, 22. November, Stuttgart, 2011.
[CSB11] Steinbeck-Behrens, C.; Menke, T.: Lackiersimulation in der Pro-
zesskette. 2. VIPROF Industriearbeitskreis, 22. November, Stutt-
gart, 2011.
3.6 Strukturierte Ablage heterogener Daten im Kontext von Wie-
derverwendbarkeit und Weiterverwendbarkeit (TU Berlin)
3.6.1 Allgemeines
Teilprozesse heutiger Simulationsprozessketten sind weitestgehend ungekoppelt,
d.h., dass einzelne Teilprozesse keine datentechnische Verbindung mit ihren Nach-
folgern/ Vorgänger besitzen. Dies ist durch Inkompatibilität der innerhalb der einzel-
nen Teilprozessschritte verwendeten Datenformate und ihrer verarbeitenden Prog-
ramme untereinander zu begründen. Sollte doch eine Verbindung bestehen, ist diese
meist mit viel Handarbeit – also das Transformieren der Daten von Hand, um sie Fol-
geprozessen zugänglich zu machen – verbunden. Dieser Umstand verhindert jedoch
maßgeblich die Durchgängigkeit der Prozesskette und ist deshalb zu beseitigen.
Wenn nun Daten eines Teilprozessschrittes von Programmen eines folgenden Teil-
prozessschrittes verwendet werden sollen, gilt es zwei grundlegende Problemstel-
lungen zu beheben. Dies sind:
1. Die verschiedenen Programme der einzelnen Teilprozessschritte müssen die un-
terschiedlichen Datenformate lesen können.
2. Die verschiedenen Programme der einzelnen Teilprozessschritte müssen die un-
terschiedlichen Daten auf die gleiche Art interpretieren.
78

79. Die Lösungen für diese Problemstellungen sind zu 1.) Konversion – also die Überfüh-
rung eines Datenformates in ein anderes mittels Datenkonverter – und zu 2.) Trans-
formation – also die Anpassung der Bedeutung eines Datenformates auf eine ande-
res mittels z. B. Mapping. Die Problemstellung 2 und ihre Lösung wurde durch das
Institut für Produktionstechnik der Ostfalia Hochschule für angewandte Wissenschaf-
ten Wolfenbüttel von Herrn Prof. Dr.-Ing. M. Rambke bearbeitet und in Abschnitt 3.2
behandelt.
3.6.2 Konversion
Um Durchgängigkeit innerhalb der Prozesskette mittels Konversion, also die Über-
führung eines Datenformates in ein anderes, zu realisieren, existieren zwei sich teil-
weise überdeckende Lösungsansätze:
1. Das Herstellen der Durchgängigkeit innerhalb der Prozesskette durch Überfüh-
rung der verschiedenen Datenformate ineinander.
2. Das Herstellen der Durchgängigkeit innerhalb der Prozesskette durch Überfüh-
rung der verschiedenen Datenformate in ein generisches Format.
Die Konversion mittels Überführung jeden Datenformates in jedes andere wird als
Peer-to-Peer-Strategie bezeichnet und durch Abbildung 77 visualisiert.
Abbildung 77: Peer-to-Peer-Strategie
Diese Strategie ermöglicht es, jedes beliebige Datenformat aus jedem beliebigen
anderen in nur einem Konversionsschritt zu erzeugen. Hierbei sind die Verluste an
Informationen bei dieser Konvertierung als eher gering zu betrachten, die Kosten ei-
ner Konvertierung entwickelt sich konstant und ist damit eher günstig, jedoch – kon-
stante Kosten unterstellt – wachsen die Kosten für den Konverterbau quadratisch,
die Anzahl der Konverter innerhalb dieser Strategie beträgt dann n*(n-1), mit n = An-
zahl der Datenformate. Da bei dieser Strategie die Definition eines Intermediärforma-
tes entfällt, entwickelt sich der Gesamtkostenverlauf der Peer-to-Peer-Strategie in
Abhängigkeit von der Anzahl der Formate quadratisch. Diese Strategie scheint sich
bei einer geringen Anzahl von Datenformaten zu empfehlen.
79

80. Aus dieser Strategie und seiner Nachteile, lässt sich eine weitere Strategie ableiten,
die in Abbildung 78 zu sehen ist, als Ring-Strategie bezeichnet wird und für den Fall
nur zweier existierender Datenformate identisch mit der
Peer-to-Peer-Strategie ist.
Abbildung 78: Ring-Strategie
Innerhalb dieser Strategie werden Konverter erzeugt, die ein Datenformat in ein an-
deres übertragen. Hierdurch ergibt sich ein solcher Ring an Konvertern. Dieser Stra-
tegie ist es von Vorteil, das die Anzahl der Konverter linear mit der Anzahl der Daten-
formate steigt, somit also auch die Kosten für den Konverterbau n betragen, mit n =
Anzahl der Datenformate. Dies bringt gegenüber der Peer-to-Peer-Strategie schnell
Vorteile mit sich, steht jedoch dem Fakt entgegen, dass die Anzahl der Konvertie-
rungsschritte und damit die Kosten der Konvertierung auf durchschnittlich n/2 (n =
Anzahl der Datenformate) sinken, da im Mittel genauso viele Konversionsschritte
notwendig sind, bis das Zielformat erreicht ist. Die Konvertierungsverluste entwickeln
sich bei dieser Strategie eher unvorteilhaft, da im schlechtesten anzunehmenden Fall
lediglich die Schnittmenge aller Formate verbleibt, die mit steigender Anzahl der
Formate überproportional abnimmt. Innerhalb dieser Strategie entfallen ebenfalls die
Kosten für die Definition eines Intermediärformates, sodass die Gesamtkosten der
Konvertierung dieser Strategie überproportional zur Anzahl der Konverter steigt, sich
jedoch flacher gestaltet als bei der Peer-to-Peer-Strategie.
Die Konversion mittels Überführung jeden Datenformates in ein generisches Daten-
format wird als Intermediär-Strategie bezeichnet und durch Abbildung 79 visualisiert.
Abbildung 79: Intermediär-Strategie
80

81. Innerhalb der Intermediär-Strategie wird jedes Datenformat in ein generisches Daten-
format überführt und zurück. Demnach sind innerhalb dieser Strategie lediglich 2*n
Konverter (n = Anzahl der Datenformate) notwendig – ein Konverter zur Überführung
eines proprietären Datenformates in das generische Datenformat und einer in die
Gegenrichtung. Im Gegensatz zu den beiden vorhergenannten Strategien ist hierbei
jedoch eine Intermediärformat zu definieren, was Kosten verursacht. Diese Kosten
sind jedoch einmalig und amortisieren sich mit steigender Anzahl der Formate. Das
Zielformat einer Konversion ist in maximal zwei Schritten erreichbar (Datenformat A
Intermediärformat Datenformat B), wobei die Ausführungskosten für diesen Fall
gleich dem Doppelten des Durchschnitts einer Ausführung betragen. Konvertierungs-
verluste innerhalb der Intermediär-Strategie sind konstant, da sich Fehler nicht po-
tenzieren können. Der Gesamtkostenverlauf verhält sich für diese Strategie linear,
jedoch mit größerem Achsenabschnitt, was durch die Definition eines Intermediär-
formats bedingt ist.
Die Kostenverläufe sind folgend, in Abhängigkeit von der Anzahl der Formate, dar-
gestellt (Rot = Peer-to-Peer, Grün = Ring, Blau = Intermediär) (Siehe Abbildung 80).
Abbildung 80: Gesamtkostenverlauf der Konversionsstrategien
Die Peer-to-Peer-Strategie (rot) zeigt einen steileren Kostenanstieg als die
Ring-Strategie (grün), was durch die Vielzahl der notwendigen Konverter zu begrün-
den ist. Die Intermediär-Strategie (blau) besitzt höhere Anfangskosten, bedingt durch
die Definition eines Intermediärformats, ist jedoch nur linear Abhängig von der Anzahl
der Datenformate, sodass ein Punkt n* existiert, ab dem die Intermediär-Strategie der
Ring- und Peer-to-Peer-Strategie kostenmäßig überlegen ist. Dieser Punkt n* ist sehr
niedrig, weil Tools und Methoden sehr heterogen sind, was sich ungünstig auf die
Konvertierungsverluste der Ring-Strategie auswirkt und weil die Definition eines
Intermediärformats effizient und kostengünstig möglich ist, sodass der Fixkostenan-
81

82. teil der Intermediär-Strategie entlastet wird. Bei der Konversion von Daten ist also –
eine gewisse Anzahl von Datenformaten vorausgesetzt bzw. das Erreichen einer ge-
wissen Anzahl von Datenformaten über den Lebenszyklus des datenverarbeitenden
Prozesses – die Intermediär-Strategie zu bevorzugen.
Bei der Verwendung der Intermediär-Strategie ist, wie bereits mehrfach erwähnt ein
Intermediärformat zu definieren. XML bildet ein solches Intermediärformat, welches
bedingt durch seine Struktur gewisse Vor- und Nachteile mit sich bringt. XML ist ein
offener, lizenzfreier Standard, der eine gewisse Popularität erreicht hat und somit
software- und entwicklungsseitig gut unterstützt wird. Seine Popularität lässt sich mit
der Beteiligung namhafter Firmen – u.a. Intel, IBM, Oracle und Microsoft – am Stan-
dard begründen. XML ist ein sehr flexibles Austauschformat, welches über die ver-
schiedensten Kanäle verteilbar ist, z. B. E-Mail, FTP und CD-ROM. Innerhalb von
XML sind die Daten, ähnlich wie in einer Datenbank, frei modellierbar, solange man
sich innerhalb gewisser Grenzen bewegt. Hieraus resultiert dann eine strukturierte
Speicherung von Daten, welche die Lesbarkeit der Daten durch andere Anwendun-
gen, und mit etwas Mühe und entsprechendem Sprachverständnis sogar die Lesbar-
keit durch den Menschen garantiert. Da XML, wie bereits erwähnt, offen ist, lässt es
sich problemlos an andere Systeme anbinden. XML wird text- und dateibasiert ge-
speichert, sodass die Informationen über jegliche Art von Netz verteilbar ist – XML
also plattformunabhängig ist. XML ist Unicode-fähig, also internationalisierbar und
arbeitet mit beliebigen Zeichensätzen zusammen. Als Nachteile für XML sind sein
höherer Speicherbedarf und die langsamere Verarbeitung zu nennen. Beide Nachtei-
le sind jedoch zu vernachlässigen, da zum einen Speicherplatz immer günstiger wird
und Prozessoren immer schneller und zum Anderen, bedingt durch die text- bzw.
dateibasierte Speicherung von XML, XML gut komprimierbar ist, sodass die Vorteile
den Nachteilen überwiegen.
3.6.3 Das VIPROF-XML-Datenformat
Im Rahmen des Projektes musste folglich eine Informationsanalyse aller am Prozess
beteiligter Daten vorgenommen werden, um in Folge dessen ein XML-Datenformat
zu definieren, welches die benötigten Informationen aufnehmen kann. Abbildung 81
zeigt den Simulationsprozess und seine verwendeten Programme, aus denen sich
die notwendigen Informationen ergeben.
82

83. Abbildung 81: Simulationsprozess inkl. der verwendeten Simulationstools
Die Abbildung 82 zeigt am Beispiel des Datenformates der ESI GmbH die im Prozess
anfallenden Daten.
Abbildung 82: M01-Datenformat der ESI GmbH
83

84. Innerhalb der Informationsanalyse wurden hierbei folgende Informationsblöcke identi-
fiziert, die im Rahmen der XML-Definition berücksichtigt werden mussten:
• Metainformationen (Daten, die die eigentlichen Informationen beschreiben)
• Knotendaten (Daten, die ein Netz aufspannen, aus welchem Elemente definiert
werden können)
• Elementdaten (Daten, die Elemente auf einem Netz erzeugen und ihrerseits simu-
lierbare Eigenschaften aufnehmen können)
• Attributinformationen (Daten, die die zu simulierenden Eigenschaften der Elemen-
te beschreiben)
• Attributwerte (Daten, die die Simulationsergebnisse beschreiben)
Innerhalb der Metainformationen waren seinerseits Informationen über das Bauteil
zu finden, sein Name und das Datum der Simulation. Darüber hinaus waren Informa-
tionen über die Daten zu finden, wie die Anzahl der Knoten und Elemente innerhalb
der Simulationsdatei, die Anzahl der simulierten Attribute (z. B. Dicke), Informationen
über das verwendete Einheitensystem und Informationen über die Rotationsmatrix.
In den Knotendaten wurden einzelne Knoten definiert. Hierzu wurde für jeden Kno-
ten eine eindeutige Identifikationsnummer vergeben, sowie die Lage des Knotens im
Raum – mittels x-, y- und z-Koordinate.
In den Elementdaten wurden die einzelnen Elemente spezifiziert. Dies geschieht
ebenfalls mit Hilfe einer eindeutigen Identifikationsnummer, seine Lage im Raum –
diesmal jedoch nicht nur Koordinaten, sondern durch die ihn aufspannenden Knoten
-, seinen Materialeigenschaften in Form einer eindeutigen Materialidentifikations-
nummer, der Anzahl der Gaußpunkte – Stützstellen zur Integration der Ansatzfunk-
tionen für die Berechnung von Elementmatrizen über die Fläche – und Integrations-
punkte – Stützstellen zur Integration der Ansatzfunktionen für die Berechnung von
Elementmatrizen über das Volumen.
Die Attributinformationen enthalten ein Kürzel für das simulierte Attribut (z. B. THIC
für die Dicke), die Anzahl der Ergebniswerte je Element, ihre Abhängigkeit vom
Gauß- bzw. den Integrationspunkten (dies hat Einfluss auf die tatsächliche Anzahl
der Ergebniswerte) und das Einheitensystem der Ergebniswerte spezifiziert durch die
Faktoren für den Weg, die Masse und die Zeit.
84

85. Die Attributwerte enthalten Informationen über das ihnen zugehörige Element – in
Form der eindeutigen Elementidentifikationsnummer – und die Ergebniswerte der
Simulation.
Diese Informationen (Metainformationen, Knotendaten, Elementdaten, Attributinfor-
mationen und Attributwerte) lagen jedoch, je nach Datenformat, nicht in derselben Art
und Weise, und am selben Ort bzw. im selben Block vor, waren jedoch in allen Da-
tenformaten enthalten und fanden somit Einzug in das XML-Datenformat.
Dieses XML-Datenformat teilt sich nun in zwei grundlegende Blöcke: die Metadaten
und die Simulationsdaten.
Die XML-Metadaten enthalten, wie in Abbildung 83 zu sehen, nun alle Informatio-
nen, die die eigentlichen Daten näher beschreiben.
Abbildung 83: Metainformationen des VIPROF-XML-Datenformates in Form einer
XSD
Innerhalb der Metainformationen waren nun Informationen über das Bauteil, sein
Name, das Datum der Simulation, die Anzahl der Knoten und Elemente innerhalb der
Simulationsdatei, die Anzahl der simulierten Attribute (z. B. Dicke), das verwendete
Einheitensystem und die Rotationsmatrix zu finden. Darüber hinaus enthält dieser
Informationsblock nun auch alle Metainformationen über die simulierten Attribute, wie
ihren Namen, die Anzahl der Ergebniswerte, ihre Abhängigkeiten von Gauß- und In-
tegrationspunkten und ihr Einheitensystem. Hinzugekommen ist ein eventuell vor-
handener oder notwendiger Referenzwert für das Simulationsattribut (z. B. eine Refe-
renzdicke).
85

86. Die XML-Simulationsdaten enthalten nun alle anderen Informationen der ursprüngli-
chen Informationsblöcke, wobei hier zwei Blöcke alle Informationen aufnehmen (wie
in Abbildung 84 zu sehen).
Abbildung 84: Simulationsdaten des VIPROF-XML-Datenformates in Form einer XSD
Dies sind zum Einen der Knotenblock, der alle Informationen über die Knoten enthält
(eindeutige Knotenidentifikationsnummer und die Koordinaten im Raum) und zum
Anderen der Elementblock, der alle Elementinformationen vorhält (Elementidentifika-
tionsnummer, die Anzahl der Gauß- und Integrationspunkte, die Identifikationsnum-
mern der das Element aufspannenden Knoten, die Materialeigenschaften durch An-
gabe einer eindeutigen Materialidentifikationsnummer, eine Identifikationsnummer für
die Zugehörigkeit eines Elements zu einem bestimmten Part und die Simulationswer-
te in Form von Namen und Ergebniswerten).
86

87. Abbildung 85: Beispiel-VIPROF-XML-Datei
Die Abbildung 85 zeigt nun dieselben Informationen bgzl. der proprietäre Daten wie
Abbildung 82, jedoch in Form einer XML-Datei.
Hieraus gestaltet sich nun ein Prozessablauf wie in Abbildung 86 zu sehen. Hierbei
wird im Anschluss an einer der Teilsimulationen (z. B. Umformen) das proprietäre
Datenformat (z. B. M01) mittels SCAIMapper des Fraunhofer SCAI für den nächsten
Simulationsschritt aufbereitet. Parallel dazu werden die proprietären Daten in das
VIPROF-XML-Format konvertiert, diese wiederum in das JT-Format, und beide Da-
teien (XML und JT) werden im PDM-System vorgehalten. Die ursprünglichen proprie-
tären Daten werden nicht mehr benötigt und somit verworfen. Wesentliche Bestand-
teile dieser Lösung, nebst ihrer Funktion sind:
• Der SCAIMapper: Ein vom Fraunhofer SCAI entwickeltes Programm zur Verbin-
dung und Anpassung der Daten vieler auf dem Markt erhältlicher FEM-
Programme und ihrer Netze unter- bzw. aufeinander.
• Der VIPROF-XML-Konverter: Ein im Rahmen des Projektes „Virtuelle Produktion
und Fertigung von Fahrzeugen“ erzeugtes Programm zur Konversion der im Pro-
jekt anfallenden proprietären Daten und deren Rücktransformation (dies jedoch
mit Einschränkungen, die später beleuchtet werden).
87

88. • Der JT-Konverter: Ein vom Fraunhofer IGD und der Volkswagen AG entwickeltes
Programm zur Konversion der im Projekt erzeugten XML-Daten mittels JT und
deren Visualisierung über das frei erhältliche Programm „JT2Go“
Abbildung 86: Ablauf des Simulationsprozesses mit Unterstützung durch das
XML-Datenformat
Diese Daten müssen nun im PDM/SDM-System abgelegt werden. Hierzu sind die
Datengrößen zu untersuchen, um Aufschluss darüber zu erhalten, inwiefern das nun
resultierende Datenaufkommen wirtschaftlich händelbar ist. Ausgehend von den
proprietären Daten, den XML-Daten sowie deren JT-Visualisierung ergeben sich fol-
gende Szenarien:
• Szenario 1 – Ablage der proprietären Daten und deren XML-Repräsentation so-
wie der JT-Visualisierung: Innerhalb dieses Szenarios sind zum einen die urs-
prünglichen Daten im PDM/SDM-System abgelegt und deren XML. Die Visualisie-
rung der einzelnen Ergebnisse ist mit wenigen hundert Kilobyte zu vernachlässi-
gen, sodass mit einem Datenaufkommen von ca. 225% ggü. der ursprünglichen
Datengröße zu rechnen ist. Dies macht ein Datenzuwachs von 125%. Dies ist da-
tentechnisch die schlechteste Variante, da zum einen Redundanzen herrschen,
und zum zweiten das erhöhte Datenaufkommen unwirtschaftlich erscheint.
• Szenario 2 – Ablage der XML-Daten sowie der JT-Visualisierung: Innerhalb die-
ses Szenarios sind ausschließlich die XML-Daten im PDM/SDM-System abgelegt
und deren Visualisierung. Durch die Einsparung der proprietären Daten ist mit ei-
88

89. nem Datenaufkommen von ca. 125% ggü. der ursprünglichen Datengröße zu
rechnen ist. Dies macht ein Datenzuwachs von 25%. Dies ist datentechnisch die
ideale Variante, da keine Redundanzen herrschen, und die Daten direkt verarbei-
tet werden können.
• Szenario 3 – Ablage der XML-Daten in komprimierter Form sowie der JT-
Visualisierung: Innerhalb dieses Szenarios sind die XML-Daten ggü. Szenario 2 in
komprimierter Form (z. B. als zip-Datei) im PDM/SDM-System abgelegt und de-
ren Visualisierung. Durch die Komprimierung der XML-Daten ist mit einem Daten-
aufkommen von ca. 105% ggü. der ursprünglichen Datengröße zu rechnen ist.
Dies macht ein Datenzuwachs von 5%. Dies ist datentechnisch die optimale Va-
riante, bei der die Daten jedoch nicht direkt verarbeitet werden können, sondern
vorher dekomprimiert werden müssen.
3.6.4 Funktionsweise und Begrenzungen des XML-Konverters
3.6.4.1 Funktionsweise
Der im Rahmen des Projektes entwickelte XML-Konverter ist in der Lage, Daten nach
Maßgabe der ESI GmbH und der CADFEM GmbH bzw. ANSYS Inc. zu konvertieren;
Abbildung 87 zeigt die möglichen Konversionsroutinen (gelb = Datenformat ESI
GmbH, blau = Datenformat CADFEM GmbH bzw. ANSYS Inc.).
Abbildung 87: XML-Konverter inkl. seiner Konversionsroutinen
Hierbei ist der XML-Konverter in der Lage nicht nur aus den proprietäre Daten XML
zu erzeugen, sondern ebenso aus den XML-Daten das ursprüngliche, proprietäre
Datenformat zu generieren. Um aus den proprietären Daten ein einheitliches XML-
Datenformat erzeugen zu können, sind Anpassungen an den ursprünglichen Infor-
89

90. mationen vorzunehmen, um innerhalb des XML Homogenität bzgl. der Information zu
erreichen. Hierzu war es notwendig Anpassungen zwischen den Daten des CAD-
FEM-Formates vorzunehmen, wo Programme, die dieses Datenformat erzeugten,
vereinzelt im Aufbau zu unterscheiden waren. Der XML-Konverter erkennt nun den
unterschiedlichen, strukturellen Aufbau, passt diesen an und konvertiert folgend in
das XML-Format. Eine weitere Anpassung nimmt der XML-Konverter im Bereich der
Elemente vor. Elemente innerhalb der proprietären Daten (sowohl der ESI GmbH als
auch der CADFEM GmbH bzw. der ANSYS Inc.) werden – so die Beschränkungen
innerhalb des Projektes – als Viereckselemente abgelegt, haben also vier Knoten,
die ein solches Element aufspannen. Eine solche Definition lässt es jedoch zu, auch
Dreieckselemente abzulegen, wofür es jedoch zwei potentiell zu unterscheidende
Möglichkeiten gibt:
• Die Dreieckselemente werden mit vier Knoten abgelegt, wobei der letzte, nicht
vorhandene Knoten, mit „0“ belegt wird.
• Die Dreieckselemente werden mit vier Knoten abgelegt, wobei der letzte Knoten
identisch dem Vorletzten ist, als zwei Knoten übereinander liegen und so ein
Dreieckselement aufspannen.
Der XML-Konverter erkennt beide Ablagemöglichkeiten und passt die Daten aufei-
nander an. Eine Weitere Anpassung nimmt der XML-Konverter im Bereich der Simu-
lationswerte vor. So gibt es Programme am Markt, die ihre Simulationsergebnisse
elementbasiert abspeichern, also an einem Punkt innerhalb des Elementes ablegen.
Andere wiederum speichern ihre Ergebnisse knotenbasiert ab, d.h., dass jeder Kno-
ten nun ein solches Simulationsergebnis erhält. Dies macht einen Unterschied je
Element von 3 Ergebniswerten. Der XML-Konverter erkennt diese unterschiedlichen
Ansätze und erzeugt aus den vier Knotenwerten einen Elementwert per Mittelung.
Bei einer Rücktransformation ist dies natürlich problematisch, da eine reine Kopie
des XML-Elementwertes auf die Knoten einen Informationsverlust darstellt, der nicht
wirtschaftlich zu vertreten ist, eine Abspeicherung der Knotendaten, z. B. in Form
eines Kommentars aber ebenfalls nicht in Frage kommt, da so die XML-Daten um ein
vielfaches größer werden würden – selbst kleinere Dateien haben 70.000 Elemente,
sodass hierbei 210.000 zusätzliche Werte als Kommentar zu speichern sind. Der
XML-Konverter nimmt bei der Rücktransformation – also der Überführung von Ele-
mentwerten zu Knotenwerten – alle an einen Knoten grenzenden Elemente und mit-
telt die Elementwerte nun auf den Knoten. Studien haben gezeigt, dass die Abwei-
chungen der Ursprungswerte von diesem Rücktransformationswert marginal und
damit vernachlässigbar sind.
90

91. 3.6.4.2 Begrenzungen
Die unterschiedliche Ablage der Daten innerhalb der proprietären Datenformate
bringt jedoch auch Begrenzungen mit sich, die der XML-Konverter nicht in der Lage
ist zu kompensieren. So werden die Simulationsergebnisse, die in einem Element
abgespeichert sind und durchaus auch Richtungswerte sein können (z. B. für die
plastische Dehnung) in unterschiedlichen Koordinatensystemen abgespeichert. Es
existieren also Tools, die ihre Ergebnisse ausgehend von einem globalen Null-
punkt/Koordinatenursprung abspeichern und andere, die dies in einem lokalen Koor-
dinatensystem tun, wo also der Nullpunkt innerhalb des Elements zu finden ist. Dar-
über hinaus existieren mehrere Möglichkeiten diesen lokalen Nullpunkt zu definieren.
Diesen Umstand zu beheben, ist der XML-Konverter nicht in der Lage, weshalb der
SCAIMapper innerhalb der Prozesskette Anwendung findet. Ebenso problematisch
ist die bereits weiter oben besprochene Überführung von Knotendaten auf Element-
daten und deren Rücktransformation. Wie besprochen werden bei der Rücktransfor-
mation die am Knoten angrenzenden Elemente benutzt, um mit deren Hilfe einen
Knotenwert zu berechnen. Dabei bleibt unberücksichtigt, welche Größe die einzelnen
Elemente besitzen und daraus folgend auch ihr Einfluss auf den resultierenden Kno-
tenwert, d.h. ob größere Elemente mehr Einfluss auf den Knotenwert haben sollten.
Dieser Umstand ist ersten Vermutungen nach zu berücksichtigen, im Rahmen des
Projektes jedoch nicht weiter ausgeführt.
Daraus ergibt sich, dass, bedingt durch die unterschiedliche Speicherung bestimmter
Daten, eine Transformation von einem Datenformat über XML in ein anderes nicht
möglich ist. Der XML-Konverter erkennt das Ursprungsformat und lässt eine Rück-
transformation nur in diese kompatiblen Datenformate zu.
91

92. 3.7 Entwicklung einer systemübergreifenden Datenablage im
PDM-System zur Realisierung einer durchgängigen Simulati-
onsprozesskette (TU Chemnitz, ARC Solutions GmbH)
3.7.1 Problemstellung und Ziele
Die Basis für die Schaffung einer durchgängigen Simulationsprozesskette ist die
Kenntnis aller ablaufenden Prozesse sowie aller Ein- und Ausgabedaten, die von den
Simulationsprogrammen genutzt werden. Zu Beginn des Projektes erfolgte deshalb
in einer Ist-Analyse die Ermittlung aller notwendigen Prozesse und Daten/Attribute
der Teilgewerke. Dazu wurden Befragungen durchgeführt, vorhandene Prozessbe-
schreibungen ausgewertet und die einzelnen Simulationsprogramme untersucht.
Für die Abbildung der Prozesse wurden unterschiedliche Modellierungsmethoden auf
ihre Einsatzfähigkeit geprüft. Als besonders geeignet für die Modellierung der zu be-
trachtenden Prozessketten hat sich die Methode der ereignisgesteuerten Prozessket-
ten herauskristallisiert. Mit dieser Methode ist es möglich den Prozessablauf mit allen
Ein- und Ausgabedaten, den ausführenden Stellen und die genutzten Anwendungs-
systeme in einem Modell darzustellen.
Nach der Modellierung der Ist-Prozesse wurde eine Schwachstellenanalyse durchge-
führt. Die Analyse der Ist-Prozesse zeigte die unabhängige Arbeitsweise der einzel-
nen Teilbereiche. Der Simulationsbereich ist charakterisiert durch eine große Zahl
von verschiedenen Werkzeugen, die eine Vielzahl verschiedener Datenformate nut-
zen. Somit ist der Datenaustausch zwischen den unterschiedlichen Werkzeugen er-
schwert. Schnittstellen zwischen den Simulationssystemen sind meist nur unter hers-
tellereigenen Systemen vorhanden. Aufgrund der fehlenden Verbindung werden die
Ergebnisdaten der vorangegangenen Simulationen nicht berücksichtigt.
Es wurde ersichtlich, dass die meisten Simulationsdaten in verschiedenen Dateisys-
temen abgelegt werden und somit keine durchgängige, konsistente und einheitliche
Datenablage gewährleistet ist. Die Datenbeschaffung für nachfolgende Prozesse ist
erheblich erschwert und daher sehr zeitaufwendig und kostenintensiv. Schnittstellen
zwischen Simulationsprogrammen und Produktdatenmanagementsystemen (PDM-
Systemen) sind in der Regel nicht vorhanden. Lediglich die Ablage von Konstrukti-
ons- und Fertigungsdaten in PDM-Systemen ist heute realisiert. Ferner fehlt momen-
tan eine automatische Steuerung und Kontrolle der Prozessabläufe. Hier bietet sich
92

93. der Einsatz eines Workflowsystems an, mit dessen Hilfe eine Übersicht über den Ar-
beitsfortschritt gegeben werden kann. Die Ergebnisse der Ist-Analyse sind in
Abbildung 88 zusammengefasst.
Abbildung 88: Ergebnisse der Ist-Analyse
Als Aufgaben für die Realisierung einer durchgängigen Simulationsprozesskette wur-
den daher die Realisierung einer vollständigen Datenablage, die Definition von Refe-
renzprozessketten zum Datenmanagement und deren Automatisierung über Work-
flows definiert.
3.7.2 Durchgängiges Datenmanagement
In einem Produktentwicklungsprozess fallen eine Vielzahl verschiedener Daten
(Abbildung 89) an, die durch die unterschiedlichsten Systeme, zum Beispiel CAD-
Systeme und Simulationsprogramme, erzeugt werden.
Ziel war die Integration aller dieser Daten in einem einheitlichen System. Dafür bietet
sich der Einsatz eines Produktdatenmanagementsystems an. Es bildet eine Integra-
tionsplattform für alle eingesetzten Datenerzeugungssysteme (PPS-Systeme, CAX-
Systeme, diverse Applikationen, Projektmanagementsysteme, Officesysteme und
Simulationsprogramme), was allen Daten über den gesamten Produktentwicklungs-
prozess entspricht [VDI2219].
93

94. Abbildung 89: Beispiele für produktbeschreibende Daten
im Produktentwicklungsprozess
Auf dem Markt gibt es eine Vielzahl von PDM-Systemen, die verschiedene Ausstat-
tungsmerkmale aufweisen. Unterschiede gibt es hinsichtlich:
• der Ausprägungen der einzelnen Funktionskomponenten,
• des Umfangs der Workflowkomponente,
• der vorhandenen Schnittstellen,
• der genutzten Softwareplattform,
• der Art der Architektur,
• der Systembedienbarkeit und -stabilität,
• des Bekanntheitsgrades,
• der Herstellerbetreuung,
• des Preis-Leistungsverhältnisses.
Für das durchgängige Datenmanagement musste aus dem großen Angebot ein ge-
eignetes PDM-System ausgewählt werden. Dazu wurde im Vorfeld eine entspre-
chende Anforderungsanalyse durchgeführt. Neben den generellen Anforderungen,
die an die Einführung und den Betrieb von PDM-Systemen inkl. Workflowfunktionali-
tät gestellt werden, kamen spezielle Anforderungen für die durchgängige Datenabla-
ge, die bei der Auswahl Priorität besaßen, hinzu. Anhand des entwickelten Anforde-
rungskataloges erfolgte die Auswahl des PDM-Systems.
94

95. Nach der Auswertung der einzelnen Kriterien stellte sich das PDM-System
Teamcenter Engineering der Siemens PLM Software als besonders geeignet heraus
(Abbildung 90). Das Basismodul von Teamcenter umfasst grundlegende PDM-
Funktionen wie
• Teile- und Dokumentenmanagement,
• Metadatenverwaltung,
• Produktstruktur- und Konfigurationsmanagement,
• Suchfunktionalitäten,
• Änderungsmanagement,
• Klassifizierung,
• Anwendungsintegration,
• Archivierungs- und Backupmechanismen,
• Benutzerverwaltung, Authentifizierung und Zugriffsverwaltung,
• Customizing,
• Einbau- und Verwendungsnachweise sowie
• Workflowfunktionalität.
Abbildung 90: Funktionen Teamcenter
Ein weiterer Vorteil ist das Modul Teamcenter for Simulation, das für die Speicherung
und Verwaltung von Simulationsdaten entwickelt wurde. Es bietet ein umfassendes
Datenmodell zur Verwaltung von auf Computer-Aided Engineering (CAE)
basierender Geometrie, vernetzten Modellen, ausführungsfertigen Decks,
Ergebnissen und Berichten, sodass die passenden Daten für die virtuellen
Prototypen leicht auffindbar und wiederverwendbar sind [TEAM09].
95

96. Das System gehört zu den meist verkauften Systemen auf dem Markt und seine
Konzeption ist sowohl für Großunternehmen als auch für Mittelständler interessant.
Haupteinsatzgebiet ist der Produktentwicklungsbereich. Hier können alle erzeugten
Daten und Dokumente von verschiedenen Anwendungssystemen abgebildet werden,
wie beispielsweise Office-Dokumente, Ideen- und Produktbeschreibungen,
Anforderungen, Pflichtenhefte, CAX-Daten, Stücklisten, Zeichnungen,
Änderungsanweisungen, Service-Bulletins und Layoutpläne. Teamcenter besitzt
entsprechende Export- und Importfunktionen und eine Workflowkomponente, die es
erlaubt den Prozess der Bearbeitung und Weiterleitung der Daten zu steuern und zu
kontrollieren [VDI02]. Das System ist individuell anpassbar und durch die
angebotenen Forschungs- und Lehrlizenzen stellte sich das System für die geplanten
Arbeiten als besonders geeignet heraus.
3.7.3 Entwicklung von Datenablagestrukturen
Bei der Entwicklung einer geeigneten Datenablagestruktur für unterschiedliche Pro-
duktdaten musste besonders auf Flexibilität geachtet werden. Zum einen bestand die
Anforderung unterschiedliche Datenformate abzulegen und zum anderen musste die
Struktur verschiedene Bauteilvarianten, wie sie in der Automobilindustrie häufig vor-
kommen, abbilden können. So ist es zum Beispiel erforderlich zu einem Bauteil die
CAD-Daten, die FEM-Daten, die Fertigungsgeometrien oder die von realen Bauteilen
gescannte Daten (siehe Abbildung 91) zusammen abspeichern zu können.
Abbildung 91: Verschiedene Varianten eines Bauteils
Schnell zeigte sich, dass das zu entwickelnde Datenmodell in Teamcenter nicht aus-
schließlich aus einer Struktur bestehen kann, sondern mehrere, sich einander ergän-
96

97. zende und miteinander kombinierbare Strukturen, beinhalten muss. Hierfür wurden
unterschiedliche Strukturen auf der Basis von produkt- und fertigungsspezifischen
Grundstrukturen entwickelt.
Die folgenden vier neuen Datenablagestrukturen für die Speicherung von diversen
Bauteilvarianten stellen ein Ergebnis des VIPROF-Projektes dar:
• EPS-Struktur (Entwicklungsproduktstruktur)
• FPS-Struktur (Fertigungsproduktstruktur)
• TPR-Struktur (Technologieprozessreihenfolgestruktur)
• SDM-Struktur (Simulationsdatenmanagementstruktur).
Die EPS-Struktur (Entwicklungsproduktstruktur) dient zur Ablage von reinen CAD-
Daten. Mit ihr werden Einzelteile und Baugruppen allein aus der Entwicklungssicht
strukturiert dargestellt. Somit sieht der Bearbeiter oder Konstrukteur alle Konstrukti-
onsteile in Form des Zusammenbaus unabhängig von der späteren Füge- und Ferti-
gungsreihenfolge. Da bei der Bauteilkonstruktion die Entwicklung nicht mit der ersten
Zeichnung abgeschlossen ist, können im PDM-System Revisionen zu Ablage unter-
schiedlicher Entwicklungsstände genutzt werden. Wurde keine andere Regel verein-
bart, gilt die letzte Revision stets als die Arbeitsversion, welche für andere Nutzer
sichtbar ist. In Abbildung 92 ist die Entwicklungsproduktstruktur des VIPROF-
Demonstrators dargestellt.
Abbildung 92: Entwicklungsproduktstruktur des VIPROF-Demonstrators
97

98. Im Projekt wurden als Betrachtungsumfang das Seitenteil aus dem Fahrzeug Touran
GP2 ausgewählt. Dabei wurde im Bereich des Fahrzeugaufbaus die B-Säule inklusi-
ve der Verstärkung und der Gewindeplatten betrachtet und im Bereich des Fahr-
zeugunterbaus das Bodenteil sowie der Sitzquerträger berücksichtigt.
Die gleichen Bauteile lassen sich erneut in der FPS-Struktur (Fertigungsprodukt-
struktur) wiederfinden. Hierbei erfolgt die Strukturierung nicht wie bei der EPS-
Struktur gemäß einer Stückliste, sondern rein nach der eigentlichen Montagereihen-
folge, wie sie bei der Herstellung eines Fahrzeuges durchlaufen wird. Die FPS-
Struktur (siehe Abbildung 93) stellt somit die Fertigungssicht dar.
Abbildung 93: Fertigungsproduktstruktur des VIPROF-Demonstrators
Die dritte Struktur, die TPR-Struktur (Technologieprozessreihenfolgestruktur) ist
ebenfalls gemäß der Montagereihenfolge strukturiert. Sie beinhaltet allerdings die in
der Produktion zum Einsatz kommenden Technologien. Der Bearbeiter kann somit
feststellen, welche Technologien in welcher Reichenfolge bei der Produkt- und Bau-
teilfertigung eingesetzt werden. Abbildung 94 verdeutlicht dies für das Presswerk. In
der Struktur enthalten ist die im VIPROF-Projekt betrachtete B-Säule. Diese wird
durch einzelne nacheinander ablaufende Operationen (OP) hergestellt. Hinter jeder
Operation sind die jeweiligen Verlinkungen auf die entsprechenden Simulationsdaten
zu finden. Weiterhin sind der Methodenplan, die zum Herstellungsschritt gehörende
Platine und eine Verlinkung zu den entsprechenden Konstruktionsdaten vorhanden.
Auf den Strukturaufbau für Simulationsdaten, welcher ansatzweise ebenfalls in Ab-
bildung 94 dargestellt ist, wird im weiteren Verlauf dieses Berichtes näher eingegan-
gen.
98

99. Abbildung 94: Technologieprozessreihenfolgestruktur des VIPROF-Demonstrators
Alle einzelnen Strukturen sind, soweit erforderlich, miteinander verknüpft. Dieses set-
zen von Links bzw. Referenzieren auf eine andere Struktur unterstützt die Redun-
danzfreiheit und verhindert das mehrfache Abspeichern von identischen Daten. Den-
noch haben die unterschiedlichen Arbeitsbereiche (z. B. Konstruktion, Fertigung) nur
Zugriff auf die für sie bestimmte Struktur und die darin enthaltenen sowie verlinkten
Daten.
Abbildung 95: Beispiel einer Verknüpfung der einzelnen Strukturen untereinander
In Abbildung 95 wird beispielhaft dargestellt, wie die Verknüpfung der einzelnen
Strukturen untereinander erfolgen kann. Es ist ersichtlich, dass jeweils der letzte Ar-
beitsschritt in einer Reihe von Operationen aus der TPR-Struktur mit der FPS-
Struktur verlinkt ist. Dies entspricht dem Bauteil, wie es bei der Fahrzeugherstellung
99

100. eingebaut wird. Zusätzlich dazu ist ebenfalls eine Verlinkung aus der EPS-Struktur
(das reine CAD-Bauteil) in die FPS-Struktur zu finden. Wird aus beiden Strukturen
(EPS und TPR) in die FPS-Struktur verlinkt, lassen sich die Bauteile (simuliert und
konstruiert) einfach miteinander vergleichen, da solche Bauteile meistens erst nach
einem der letzten Operationsschritte übereinstimmen. Zum Beispiel wird bei einem
Bauteil mit Flansch, dieser erst nach dem Fügen (Falzen) geschlossen, wodurch sich
bis zu diesem Operationsschritt das reale Bauteil von dem fertig konstruierten Bauteil
unterscheidet.
Die vierte Struktur, die SDM-Struktur (Simulationsdatenmanagementstruktur), wurde
spezielle für die Ablage von Simulationsdaten in einem Produktdatenmanagement-
system entwickelt. Das Ziel bestand darin, alle während des Produktentwicklungs-
prozesses anfallenden Simulationsdaten innerhalb eines PDM-Systems zu speichern
und so eine konsistente Datenbasis für alle Teilprozesse aufzubauen. Dazu wurde
zunächst das Standarddatenmodell von Teamcenter analysiert.
Grundsätzlich lassen sich in einem PDM-System jegliche Arten von Daten ablegen.
Um Teamcenter jedoch mit Daten zu füllen, werden verschiedene „Container“ benö-
tigt. Dabei basiert Teamcenter auf unterschiedlichen Objekten, die durch Relationen
miteinander verbunden und so Abhängigkeiten abgebildet werden können. Der stan-
dardisierte Ansatz zur Speicherung von Daten in einem PDM-System ist das Item
(Objekt). Es dient als Sammelcontainer für alle relevanten Dokumente und Daten zu
einem Bauteil. Ein Item besteht aus drei wesentlichen Bestandteilen, dem Dataset
zur Erfassung physischer Daten (z. B. CAD-Daten, MS-Office-Dokumente), dem
Formular zur Bereitstellung der Item-spezifischen Attribute und der Item Revision zur
Verwaltung von Änderungsständen. Die Item Revision ist dem Item untergeordnet
und beinhaltet ebenfalls Datasets und Formulare. Ein Item kann mehrere Revisionen
besitzen. Abbildung 96 veranschaulicht diese Struktur.
Abbildung 96: Allgemeine Datenablagestruktur von Teamcenter
100

101. Mit den genannten Items und ihren Unterordnern lassen sich die Bauteilgeometrien
problemlos in Teamcenter hinterlegen. Für die Ablage von Simulationsdaten wird
allerdings ein Konzept benötigt, welches zum Ersten die gegebenen Standards des
PDM-Systems verwendet, zum Zweiten die Anbindung und einheitliche Ablage von
Daten unterschiedlicher Simulationstools ermöglicht und zum Dritten alle im Entwick-
lungsprozess entstehenden Datenvarianten unterstützt. Dazu werden im PDM-
System verschiedene Objekte erzeugt, die alle erforderlichen Daten aufnehmen kön-
nen. Pro Simulationstyp ist im Projekt ein gesondertes Datenobjekt vorgesehen, wo-
bei es sich um die Umform-, die Füge-, die Lackier- und die Crashsimulation handelt.
Auch für die Speicherung von Simulationsdaten stehen in Teamcenter bereits vier
Itemtypen zur Verfügung (Abbildung 97).
Abbildung 97: Itemtypen für die Ablage von Simulationsdaten
Mit dem Itemtyp Item wird die Bauteilgeometrie verwaltet. Das Analyse-Item spei-
chert Parameter zur jeweiligen Simulation, wie zum Beispiel die Simulationsart oder
das verwendete Werkzeug. Im Model-Item werden die Inputdaten für die Simulation
abgelegt und unter dem Result-Item können die Ergebnisse gespeichert werden. Im
VIPROF-Projekt werden lediglich die ersten drei Objekte verwendet. Die Ergebnisse
werden direkt am Analyse-Objekt angehängt, wodurch auf das Result-Item verzichtet
werden kann.
Zusätzlich zu den Standarditemtypen für die Simulationsdaten wurde für das Projekt
VIPROF eine Struktur entwickelt (siehe Abbildung 98), die sich am Ablauf einer
Computersimulation mit den drei Schritten Preprocessing (Input), Solving, Postpro-
cessing (Output) orientiert.
101

102. Abbildung 98: Aufbau der Ablagestruktur für Simulationsdaten
Das Preprocessing bei einer Simulation beinhaltet die Dateneingabe. Daher enthält
dieser Ordner auch alle benötigten Inputdaten, wie zum Beispiel einzelne Geo-
metrien, Materialdaten, Maschinenkonfigurationen sowie weitere notwendige Einga-
beparameter. Während des Solving wird die Simulation berechnet. Im gleichnamigen
Ordner können Daten zur Programm- und Solverversion, als auch Daten zum Bear-
beiter gespeichert werden. Das Postprocessing bezeichnet die Nachbearbeitung von
Ergebnissen einer Simulation. Daher werden in diesem Bereich alle Outputdaten ab-
gelegt. Es handelt sich dabei um die Ergebnisdaten in unterschiedlichen Speicher-
formaten (M01, XML, JT), die Endgeometrien sowie Protokolle oder Ergebnisberich-
te.
Das PDM-System fungiert somit als ein Bindeglied zu den einzelnen Simulations-
softwaresystemen (Abbildung 99). Auf diese Weise kann eine vollständige Datenab-
lage entlang der Prozesskette gewährleistet werden.
Für die Umsetzung der entwickelten Strukturen in Teamcenter werden zum einen der
Strukturmanager und zum anderen die Fertigungsprozessplanung verwendet. Im
Strukturmanager wird ein Fahrzeug mitsamt der Geometrie im Aufbau zusammen-
gestellt (Abbildung 100).
102

103. Abbildung 99: Verknüpfung von Simulationsprogrammen über ein PDM-System
Abbildung 100: Produktstruktur
103

104. In der Fertigungsprozessplanung hingegen werden alle an einem Fahrzeugprojekt
ausgeführten Prozesse abgebildet (Abbildung 101). Weiterhin werden die Inputdaten
für die Simulation und deren Ergebnisse bereitgestellt. Eine genauere Erläuterung
der Beziehungen zwischen den einzelnen Objekten erfolgt in Abschnitt 4.
Abbildung 101: Fertigungsprozessstruktur mit Beispiel „Umformprozess der B-Säule“
Für die Verwaltung unterschiedlicher Varianten wird kein separates Datenmodell ein-
gesetzt. Eine Variante zu einem simulierten Bauteil wird identisch zum Original abge-
legt. Anhand von Laderegeln kann eine unterschiedliche Variantenkonfiguration in
Teamcenter abgebildet werden. Dadurch lassen sich zu jeder Zeit alle im System
befindlichen Varianten und die dazugehörigen Simulationen in Teamcenter anzeigen.
Zusammenfassend lässt sich sagen, dass die Kopplung der einzelnen Simulations-
programme an ein PDM-System viele Vorteile bietet. Neben der automatisierten
Speicherung und Weiterleitung von Ein- und Ausgangsdaten der einzelnen Prozess-
schritte, wird zusätzlich die Fertigungshistorie in den nachfolgenden Simulations-
schritten berücksichtigt. Eine solche Kopplung wurde mittels offener Schnittstellen
verwirklicht, sodass weitere Simulationstools zu jedem späteren Zeitpunkt angebun-
den werden können. Weiterhin sind über ein im PDM-System enthaltenes Workflow-
system alle Teilprozesse voll- bzw. teilautomatisiert miteinander verbunden. Der
104

105. Fortschritt im Entwicklungsprozess ist dadurch jederzeit von allen Prozessbeteiligten
einsehbar und nachvollziehbar.
3.7.4 Ableitung von Referenzprozessketten zur Datenablage
Ziel des Projektes war die Gestaltung einer durchgängigen Simulationsprozesskette,
die einen Datenaustausch zwischen den Einzelprozessen erlaubt. Dazu wurden Re-
ferenzprozesse entwickelt, welche die durchgängige Prozesskettensimulation unters-
tützen und standardisieren sollen.
Die erstellten Referenzprozessketten wurden in einer Modelldatenbank abgelegt, die
nach unterschiedlichen Detaillierungsstufen unterteilt ist. Dabei wurden Übersichts-
modelle, Grobmodelle, Detailmodelle und Workflowmodelle unterschieden. Der
Überblicksprozess veranschaulicht die gesamte durchgängige Prozesskette mit den
Hauptfunktionen. Jede Funktion wird durch hinterlegte Grobmodelle beschrieben, die
den Ablauf verdeutlichen. Diesen wiederum sind Detailmodelle hinterlegt, die die ein-
zelnen Arbeitsschritte dokumentieren. Auf der untersten Ebene werden die zu auto-
matisierenden Prozesse als Workflowmodelle für die Nutzung in einem Workflowsys-
tem abgelegt. Abbildung 102 veranschaulicht die Struktur der erstellten Modelldaten-
bank.
Abbildung 102: Struktur der Modelldatenbank
Eine Aufgabe der Prozesskettenmodellierung ist es, alle möglichen Pfade für die
Prozesskette abzubilden. Falls in einigen Teilgewerken die entsprechenden Zielgrö-
ßen nicht erreicht werden können, müssen entsprechende Rücksprünge definiert
werden. Abbildung 103 zeigt mögliche festgelegte Rücksprungvarianten, die in den
105

106. Referenzprozessketten teilweise Berücksichtigung finden. Diese Referenzprozess-
ketten bilden die Basis für die Steuerung des Gesamtprozesses.
Abbildung 103: Festgelegte Prozessvarianten
Ein weiterer Schwerpunkt lag auf der Festlegung einer einheitlichen standardisierten
Datenablage von einzelnen Simulationssystemen. Hierfür wurden die in diesem Zu-
sammenhang ablaufenden Prozesse analysiert. Abbildung 104 erläutert den kreis-
laufähnlichen Ablauf des Simulationsprozesses bei der Datenbereitstellung und Da-
tenablage. Weiterhin wird der Zusammenhang zwischen den unterschiedlichen
Strukturen, welche im Abschnitt 3.7.3 erläutert wurden, verdeutlicht.
Abbildung 104: Simulationsprozessablauf mit Datenbereitstellung und Datenablage
106

107. Zunächst werden die CAD-Daten von einem Konstrukteur entwickelt und in der EPS-
Struktur abgelegt. Es folgt die Festlegung der Fertigungsreihenfolge in der FPS-
Struktur und die Technologieauslegung in der TPR-Struktur. Zur Absicherung einzel-
ner Technologien kommen verschiedene Simulationen zum Einsatz. Die Ergebnisse
der Simulation werden anschließend zurück in das PDM-System und somit in die
entsprechenden Strukturen geladen. Dabei werden eine automatische Formatum-
wandlung und das Mapping durchgeführt.
Für die Durchführung dieser Simulationen wurden ebenfalls die entsprechenden Pro-
zessketten analysiert. Die Analyse ergab, dass für alle im Projekt betrachteten Simu-
lationen der Ablauf gleich abläuft. Entsprechend wurde der in Abbildung 105 darge-
stellte Referenzprozess für die Durchführung einer Simulation festgelegt.
Abbildung 105: Referenzprozesskette für das SDM in VIPROF
Der Prozess beginnt mit der Vergabe der Simulationsaufgabe an den Planer. Dessen
Aufgabe ist die Beschaffung aller für die Simulation notwendigen Eingabedaten und
deren Ablage im PDM-System. Anschließend wählt er einen Berechner (Simulanten)
für die Aufgabe aus und übermittelt ihm die Arbeitsaufgabe. Im nächsten Schritt führt
der Berechner die eigentliche Simulation durch. Nach Abschluss der Arbeiten legt er
die relevanten Simulationsergebnisse im PDM-System ab. Beim Einlesen der Daten
erfolgt eine automatische Datenkonvertierung, die für die Datenübertragung zwi-
schen den Systemen notwendig ist. Anschließend führt der Planer einen Freigabe-
prozess durch, bei dem er über die Güte der Simulationsergebnisse entscheidet. Die
107

108. Bewertung wird mit Hilfe einer Statusampel im PDM-System dargestellt. Um diesen
Referenzprozess jeweils standardisiert ablaufen zu lassen, bietet sich eine Automati-
sierung mittels eines Workflows an.
3.7.5 Automatisierung von Referenzprozessketten mittels Workflows
Hauptziel der Workflowfunktion ist die schnelle Abarbeitung von Aufgaben in einer
vorgegebenen Reihenfolge. Es werden Aufgaben vom Workflowmanagementsystem
vergeben und an die entsprechenden Bearbeiter weitergeleitet, welche sie anschlie-
ßend bearbeiten. Dieser Vorgang erfolgt oftmals in mehreren Stufen, bis die entspre-
chende Zielstellung erreicht ist. Insbesondere für sich wiederholende, strukturierte
Prozesse, wie zum Beispiel Freigabe-, Datenablage- und Archivierungsprozesse so-
wie Statuswechsel, kommen automatisierte Prozesse zum Einsatz. Das Workflow-
managementsystem übernimmt dabei die Koordinationsaufgabe und stellt so die zeit-
lich-sachlogische Reihenfolge der auszuführenden Funktionen sicher [MÜHL05].
Die Workflowkomponente in einem PDM-System stellt eine Umgebung zur Erzeu-
gung von Workflowmodellen sowie deren Ausführung bereit. Entsprechend der Auf-
gaben werden die zwei Komponenten Modellierung (Buildtime) und Ausführung
(Runtime) unterschieden (Abbildung 106) [WFMC99].
Abbildung 106: Komponenten eines Workflowsystems
Die Modellierungskomponente dient der grafischen Beschreibung von Prozessen
und deren Automatisierung. In der Definitionsphase werden hier die Abfolge der Auf-
108

109. gaben festgelegt und die Bearbeiter über das Rollenmodell zugeordnet. Weiterhin
müssen für jede Aktion die genutzten Anwendungssysteme und Datenobjekte defi-
niert werden. Anschließend erfolgt die Automatisierung der Prozesse über die Defini-
tion von Handlern. Unter einem Handler versteht man kleine Steuerungsprogramme,
die die Aktionen steuern. Die Beschreibung muss so erfolgen, dass sie von der Aus-
führungskomponente umgesetzt werden kann. Für die Instanziierung und Steuerung
der Prozesse steht die Ausführungskomponente zur Verfügung. Sie startet, steuert
und protokolliert den Workflow. Dabei kann jeder Workflowprozess mehrfach für un-
terschiedliche Objekte gestartet werden. Die Ausführungskomponente ist dabei als
ein Service definiert, der eine Laufzeitumgebung zur Ausführung einer Workflowin-
stanz zur Verfügung stellt. Sie regelt auch die Interaktion mit den Anwendern. Die
Anweisungen entsprechend dem gestarteten Workflow werden den Anwendern in so
genannten Eingangskörben als Tätigkeitslisten oder offenen Tasks zur Verfügung
gestellt. Sie dienen der Kommunikation mit dem Anwender, der hier seine Arbeits-
aufgaben abrufen und erledigte Aufgaben dem Workflow übergeben kann.
[WFMC99]
Es existieren unterschiedliche Prozessarten, die sich hinsichtlich ihrer Strukturier-
theit, Komplexität und Veränderlichkeit unterscheiden. So gibt es zum Beispiel Pro-
zesse, deren Ablauf genau vorbestimmt ist, und es gibt Prozesse, deren Ablauf sich
nur teilweise oder gar nicht vorhersagen lässt. Diese Tatsache spiegelt sich in unter-
schiedlichen Automatisierungsgraden von Workflows wider.
Abbildung 107 veranschaulicht die unterschiedlichen Grundprinzipien der Automati-
sierung. Die Ausführung von Workflows kann manuell, vollständig automatisch oder
teilautomatisch, d.h. mit einer Benutzerinteraktion, ausgeführt werden. Der Nutzer
wählt dabei beispielsweise den nächsten Bearbeiter aus. Das Workflowsystem über-
nimmt hingegen die Kontrolle der Informationsverteilung.
109

110. Abbildung 107: Grundprinzip Workflow: Automatisierungsgrad
Auf Basis der modellierten Referenzprozessketten werden die Workflows abgeleitet
und mit Hilfe des im PDM-System integrierten Workflowsystems implementiert. Der
oben beschrieben Simulationsreferenzprozess wurde entsprechend voll- bzw. teilau-
tomatisch umgesetzt. Alle Teilprozesse in denen Entscheidungen getroffen oder fall-
spezifische Daten beschafft werden müssen laufen teilautomatisch ab. Das heißt,
diese Prozesse werden durch den Workflow gesteuert, die eigentliche Abarbeitung
erfolgt jedoch durch den Mitarbeiter. Entscheidungen wie die Auswahl des Planers
und des Berechners, die Beschaffung der Inputdaten, die Durchführung der Simulati-
on, die Ablage der Outputdaten sowie die Entscheidungen der endgültigen Freigabe
werden durch den jeweiligen Bearbeiter durchgeführt und vom Workflow gesteuert
und kontrolliert. Die Datenkonvertierung als auch das Setzen des Status kann an-
schließend wieder automatisch durch den Workflow erfolgen. Die verschiedenen Au-
tomatisierungsgrade des Simulationsreferenzprozesses sind in Abbildung 108 veran-
schaulicht zusammengefasst.
110

111. Abbildung 108: Übersicht der voll- und teilautomatisierten SDM-Prozesse
Im Projekt wurden mehrere Workflows implementiert, welche auf den von der TU
Chemnitz modellierten Referenzprozessketten basieren und den realen Prozessab-
lauf abbilden.
Im Teamcenter Modul Workflow Designer lassen sich einzelne Prozessschritte anle-
gen, ausführende Personen zuweisen oder auch allgemein nur bestimmte Nutzer-
gruppen. Mit Hilfe von Action- und Rulehandlern können viele Abläufe so implemen-
tiert werden, dass sie automatisch vom System abgearbeitet werden. Solche Pro-
zessschritte können zum Beispiel der Ex- und Import von Dateien, Konvertierungen
oder Statuszuweisungen sein. Für den Bereich der Umformsimulation zeigt Abbil-
dung 109 den Workflow wie er von ARC Solutions in Teamcenter implementiert wur-
de.
111

112. Abbildung 109: Workflowablauf für Umformsimulation
Im Einzelnen ist der Ablauf wie folgt umgesetzt worden. Nachdem ein Objekt in
Teamcenter ausgewählt und der Workflow gestartet wurde, wird der Status Rot dem
Objekt zugewiesen. Einem Status können unterschiedliche Berechtigungen ange-
hangen werden. In diesem Beispiel können von nun an keine Änderungen mehr an
den übergebenen Objekten vorgenommen werden. Die Objekte sind für die weitere
Bearbeitung gesperrt. Damit wird sichergestellt, dass nur Änderungen von den am
Prozess beteiligten Personen durchgeführt werden. Im nachfolgenden Schritt Um-
formsimulation ausführen wurde definiert, an wen die Aufgabe vergeben wird. In die-
sem Fall an den Berechner. Es ist auch möglich statt eine vorher definierte Person
oder Gruppe automatisiert zuzuweisen, dies erst zur Laufzeit des Prozesses manuell
durch den Planer vergeben zu lassen. Auch im folgenden Prozessschritt Umformsi-
mulation überprüfen wurde ein Anwender als auszuführende Person definiert. Hier
erhält der Planer die Aufgabe die Ergebnisse der Simulation zu verifizieren und dies
in einem Formular zu dokumentieren. Der Workflowschritt Check Prüfformular wird
nun vom System ausgeführt. Dafür wurde ein Actionhandler implementiert, welcher
das angehängte Formular nach einem Attribut durchsucht und dieses auswertet.
Nach entsprechendem Inhalt des Attributes wird ein neuer Status vergeben (z. B.
Rot, Gelb, Grün). Im letzten Prozessschritt wird dieser Status gesetzt. Der Workflow
für das Umformen ist in diesem Fall dann abgeschlossen. Als Ergebnis erhält man
das Start-Objekt der Simulation mit Ergebnisfiles und Status. Die sich anschließen-
112

113. den Workflows für das Fügen und Lackieren werden vergleichbar wie der Umform-
prozess manuell vom Planer ausgelöst. Im einfachsten Fall unterscheiden sich die
Prozessschritte nicht. Es ist allerdings in allen Workflows möglich anhand von zu im-
plementierenden Handlern weitere Schritte zu automatisieren oder den Gesamtpro-
zess noch detaillierter abzubilden. Eine ausführlichere Erläuterung des Workflowab-
laufes wird in Abschnitt 4 vorgenommen.
Zusammenfassend bedeutet dies, dass alle Teilprozesse innerhalb des Workflows so
miteinander gekoppelt werden können, dass sie wie ein zusammenhängender Ablauf
des Gesamtprozesses wirken. Einzelne Prozessschritte werden somit weitestgehend
automatisiert miteinander verbunden und ausgeführt. Manuelle Übertragungen ent-
fallen und der Gesamtprozess wird effizienter. Durch die Vergabe eines Status nach
jedem Teilprozess kann nachvollzogen werden, ob die Simulation erfolgreich war
oder Anpassungsbedarf, zum Beispiel in Form einer Konstruktionsänderung, besteht.
Der Status orientiert sich dabei am Ampelsystem mit den Farben Rot, Gelb und
Grün. Das Workflowsystem übernimmt auf diese Weise die Steuerung der gesamten
Simulationsprozesskette.
Die Entwicklung der konsistenten Datenablage und deren Automatisierung mittels
Workflows ist eine Voraussetzung für die Realisierung einer durchgängigen Simulati-
onsprozesskette. Sie ermöglicht eine vollständige Datenablage aller anfallenden Da-
ten und damit eine Verfügbarkeit in allen Bereichen. Durch die Bildung von Refe-
renzprozessketten und deren Automatisierung wurde eine durchgehend standardi-
sierte Datenablage realisiert. Somit leisten die durchgeführten Arbeiten einen ent-
scheidenden Beitrag zu einer durchgängigen, digitalisierten und kooperativen Ent-
wicklungs- und Produktionsplanung.
3.7.6 Kopplung der Prozesssimulation Umformen – Fügen – Lackieren
Eines der Ziele des Projektes war es die verschiedenen Simulationen für das Um-
formen, Fügen und Lackieren miteinander zu verbinden und die Ergebnisdaten des
Vorgängerprozesses im jeweiligen Prozessschritt wiederzuverwenden. Hierfür muss-
ten Schnittstellen und vor allem ein einheitliches Datenformat erstellt werden. In Ab-
sprache mit den weiteren Projektpartnern wurde sich auf XML als einheitliches Da-
tenformat geeinigt, welches zur Übertragung der Simulationsergebnisse dienen soll.
Erweitert durch eine visuelle Darstellung als JT lassen sich so nachhaltig alle Ergeb-
nisse sinnvoll ablegen und weiterverwenden. Für beide Formate wurden spezielle
Konverter implementiert (vgl. Kapitel 3.5.2, 3.6.3 und 3.6.4). Beide Konverter wurden
durch ARC Solutions in den Gesamtprozess integriert und mittels implementierter
113

114. Skripte so eingebettet, dass der Ablauf dieser Konverter vom Anwender unbemerkt
im Hintergrund von statten geht. Dazu wurde in der Teamcenter Applikation CAE
Manager eine Toolkonfiguration erstellt, welche es ermöglicht den Datenim- und Ex-
port sowie die Konvertierungen automatisiert umsetzen zu lassen. Hierfür wurden
Definitionen erstellt, die festlegen, welche Daten aus welchen Teamcenter Objekten
gebraucht, welche Programme mit welchen Parametern gestartet und welche Skripte
ausgeführt werden sollen. Ebenfalls wurden die Skripte, die den Ablauf der Konverter
managen erstellt. Als Ergebnis hat man eine Konfiguration pro Simulationsart
(Abbildung 110), welche manuell vom Anwender oder per Workflow gesteuert ausge-
führt werden. Eine ausführlichere Erläuterung wird in Abschnitt 4 gegeben.
Abbildung 110: Menu mit Konfigurationen für die Simulationen
3.7.7 VIPROF Modulcockpit zur Erhöhung der Transparenz im Entwicklungs-
prozess
Im VIPROF-Projekt wird zur Bewertung der Simulationsergebnisse auf ein Ampelsys-
tem gesetzt. Die Farben Rot, Gelb und Grün signalisieren ob eine Simulation erfolg-
reich war, ob sie mit Mängeln genehmigt wurde oder ob sie nicht erfolgreich war. Für
eine bessere Transparenz dieser Ergebnisbewertung innerhalb eines Fahrzeugpro-
jektes, in dem alle Simulationsergebnisse aufgeführt werden, sollte ein Modulcockpit
114

115. entwickelt werden. In diesem Cockpit soll es möglich sein möglichst auf einen Blick
den derzeitigen Stand im Entwicklungsprozess eines Fahrzeuges zu erkennen. Ab-
bildung 111 zeigt eine mögliche Umsetzung eines solchen Cockpits in Teamcenter.
Abbildung 111: Layoutbeispiel für Modulcockpit
Da im PDM-System noch kein vergleichbares Modul existiert musste eine völlig neue
Applikation modelliert werden. Dabei wird die Struktur des jeweiligen Fahrzeugpro-
jektes pro Simulationsart dargestellt. Die Simulationsart wird in Reitern abgebildet.
Jeder Reiter zeigt den derzeitigen Stand der Simulation anhand des Ampelsystems.
Damit kann zu jeder Zeit während des Entwicklungsprozesses eine Einsicht in den
aktuellen Entwicklungsstand gegebenen werden. Über einen Viewer im rechten Teil
der Applikation können bereits vorhandene Ergebnisse visualisiert werden.
Literatur
[MÜHL05] zur Mühlen, M.; Hansmann, H.: Workflowmanagement. In: Becker. J.;
Kugeler, M.; Rosemann, M.: Prozessmanagement. Ein Leitfaden zur
Prozessorientierten Organisationsgestaltung. 3. Auflage, Berlin u.a.:
Springer-Online, 2005, S. 373-407. ISBN 3 540 23493 4
115

116. [TEAM09] Teamcenter 8: Handbuch zu Teamcenter for Simulation, Veröffentli-
chungsnummer PLM00040 C, Siemens Product Lifecycle Management
Software Inc., Stand: 2009.
[VDI02] Verein Deutscher Ingenieure: VDI-Richtlinie 2219: Informationsverarbei-
tung in der Produktentwicklung Einführung und Wirtschaftlichkeit von
EDM/PDM-Systemen, Düsseldorf 2002.
[VDI2219] VDI-Gesellschaft Entwicklung Konstruktion Vertrieb (EKV): VDI-
Richtlinie 2219: Informationsverarbeitung in der Produktentwicklung -
Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen, 11.2002.
[WFMC99] Workflow Management Coalition (Hrsg.): WfMC Terminology & Glos-
sary v3.0 (WfMC-TC-1011), 1999, verfügbar unter
http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf.
(Stand Dezember 2011).
116

117. 3.8 Perspektiven des Mittelstands (VDC)
Die im Projekt VIPROF erzielten Ergebnisse wurden unter Berücksichtigung der An-
forderungen des Projektpartners Volkswagen, aber auch einiger, nicht im Projekt-
konsortium vertretenen, Firmen erarbeitet. Volkswagen stellte das Anwendungssze-
nario und ist somit das erste Unternehmen, das als Anwender von den VIPROF-
Arbeitsergebnissen profitieren kann. Eine wichtige Funktion dieses Verfahrens liegt
darin, dass auf diese Weise die Praxisrelevanz des Vorhabens gesichert wird.
Die Rolle der Automobilindustrie als Erstanwender, so genannte „early Adopter“, hat
sich hier wie in so vielen Bereichen der Virtuellen Techniken erneut gezeigt. Damit
hat diese Industrie gleichzeitig eine wichtige Rolle als Vorreiter und Vorbild für ande-
re Unternehmen innerhalb und außerhalb der Branche. Diesen Transfer zu unterstüt-
zen, war wiederum Aufgabe des Projektpartners Virtual Dimension Centers (VDC) in
Fellbach (siehe Abbildung 112).
Abbildung 112: Virtual Engineering im Überblick
Virtuelle Techniken sind heute aus der fertigenden Industrie kaum mehr wegzu-
denken. Schon vor vielen Jahren ist erkannt worden, dass es ein grundsätzliches
Problem der Produktentwicklung ist, dass die Zeitpunkte der Kostenfestlegung und
der Kostenentstehung teils weit auseinanderliegen [Munroe]. Festgelegt werden die
Kosten eines Produkts vor allem während der Entwicklung, wohingegen die Kosten
schwerpunktmäßig in der Produktion entstehen. Materialkosten, Arbeitskosten und
Gemeinkosten bilden hier die größten Positionen. Gleichzeitig ist bekannt, dass nicht
unerhebliche Kosten dadurch entstehen können, dass erst spät im Entwicklungs-
prozess Änderungen am Produkt vorgenommen werden müssen. So kann sich bei-
117

118. spielsweise erst spät herausgestellt haben, dass es Probleme bei der Fertigbarkeit
gibt: Das Produkt oder Teile lassen sich nur unter großem Aufwand oder gar nicht
wie geplant herstellen. Die zugehörige Faustregel geht davon aus, dass die Ände-
rungskosten exponentiell mit dem Projektfortschritt ansteigen [Visintin].
Natürlich ist es so, dass auf der anderen Seite der Kenntnisstand ja gerade erst mit
dem Projektfortschritt ansteigt. Darüber hinaus gilt: je komplexer das Produkt ist, des-
to höher werden Änderungskosten angesetzt [Aberdeen]. Wie existentiell wichtig das
Thema für die Wirtschaft ist, lässt sich auch daran ablesen, in welchem Umfang die
Anzahl Produktrückrufen in den letzten Jahren gestiegen ist. Von 139 Produkt-
Rückrufen in der EU im Jahr 2003 stieg der Wert auf 2244 im Jahr 2010 [Rapex].
In genau dieser Problematik kommen Virtuelle Techniken zum Einsatz. Zielsetzung
des Einsatzes Virtueller Techniken ist es, möglichst viele Produkteigenschaften und
-funktionen schön möglichst früh im Produktentwicklungsprozess überprüfen und be-
urteilen zu können. Nach Möglichkeit wird dabei kein Bereich ausgespart: Design,
Ergonomie, physikalische Eigenschaften, Logik, Fertigbarkeit oder Montierbarkeit
können zu den überprüften Eigenschaften zählen. Simulation und Visualisierung
kommen zum Einsatz. Ein stringentes Produktdatenmanagement sorgt dafür, dass
sämtliche Prozess-Schritte mit Daten aus vorhergehenden Überprüfungen versorgt
werden.
Damit wird klar, dass Virtuelle Techniken nicht nur allein für die Automobilindustrie
und deren Zulieferer relevant sind: Überall dort, wo in der fertigenden Industrie komp-
lexe Produkte mit hohem Aufwand entwickelt werden, muss frühzeitig im Entwick-
lungsprozess überprüft und beurteilt werden. Der Maschinenbau zählt somit auch zu
den potentiellen Anwendungsfeldern virtueller Techniken.
Neben den klassischen ingenieurtechnischen Feldern, die den Maschinenbau in der
Vergangenheit stark prägten, gewinnt das Design immer mehr an Bedeutung. Das
Design umfasst nicht nur die technisch-funktionale sowie Benutzer-gerechte Gestal-
tung, sondern mittlerweile eben auch eine ansprechende und wiedererkennbare
Form- und Farbgebung. Dahinter steckt die Bestrebung, das Design neben der
Technologie als Differenzierungsmerkmal zu nutzen. Durchdachtes Design zur Stei-
gerung der Kundenzufriedenheit und hervorragendes Design als Qualitätsanmutung
werden künftig eine größere Rolle spielen. Einhergehend steigt die Produktkomplexi-
tät erneut, ebenso wie die Qualitätsanforderungen.
118

119. Das Virtual Dimension Center (VDC) Fellbach hat innerhalb des Projekts VIPROF
eine Umfrage unter Maschinenbau-Unternehmen durchgeführt. Konkret ging es um
die Fragestellung, inwiefern Prozesse des Umformens, Fügens oder Lackierens im
Unternehmen durchgeführt werden, wer diese Prozesse auslegt und ob Simulations-
werkzeuge zur Unterstützung eingesetzt werden. Dabei traten folgende Ergebnisse
zu Tage:
• Die Prozesse Umformen und Fügen sind weit verbreitet (86%). Lackiert wird sel-
tener, dann aber häufiger ausgelagert (50%).
• Es gibt selten eine Personalunion (29%) derjenigen, die Umform-, Füge- und La-
ckierprozesse auslegen. Darüber hinaus arbeiten diejenigen, die dieses durchfüh-
ren, ebenso selten in der gleichen Organisationseinheit (29%).
• Querschnittsveranwortliche im Prozess sind häufig (29%) nicht benannt worden.
Abstimmungstreffen werden in der Regel erst vor dem oder beim Anlauf oder
nach Problemen abgehalten.
• 71% der Firmen führen Simulationen durch, vor allem, um Zeit und Kosten zu
sparen (67%) und die Qualität zu steigern (50%).
• 57% der Unternehmen nutzen dazu Stand-Alone-Produkte.
• Die Simulationsergebnisse werden aber zumeist nicht im Prozess weiterverwen-
det, da dieses nicht notwendig, technisch nicht möglich oder organisatorisch nicht
vorgesehen ist.
• Weiteres Optimierungspotenzial der Prozesse Umformen-Fügen-Lackieren ist zu
signifikanten Anteilen nicht bekannt (25-50%).
Mit diesen Antworten ergeben sich hinsichtlich der Relevanz der VIPROF-Ergebnisse
für den Maschinebau folgende Schlussfolgerungen: die Anwendungsbereiche Um-
formen und Fügen besitzen die größere Bedeutung. Interesse an Simulationstechni-
ken ist vorhanden, aber auch eine Unsicherheit bezüglich möglicher Einsatzpotenzia-
le. Zur Unterstützung des Maschinenbaus zählen somit nicht nur technische Lösun-
gen, sondern auch und insbesondere organisatorische Hilfestellungen.
Literatur
[Munroe] The design determines the Cost, Munroe & Associates,
http://www.leandesign.com/leandesign.html
[Visintin] Visintin, Gabi: Return on Investment bei VR- und Simulationslösungen.
In: cad-cam, Carl-Hander-Verlag, 2003
119

120. [Aberdeen] The transition from 2D drafting to 3D modeling benchmark report, Aber-
deen Group, Boston, 2006
[Rapex] Rapex:
http://ec.europa.eu/consumers/dyna/rapex/rapex_archives_en.cfm
Weiterführende Literatur
• Belker, Reinhard: Virtuelle Produkt- und Produktionsentwicklung, Siemens AG,
Siemens Transportation, Krefeld 2008
• Decker R.; Bödeker, M.; Franke, K.: Potentiale und Grenzen von Virtual Reality-
Technologien auf industriellen Anwendermärkten. Possibilities of virtual reality
technologies, University Bielefeld. IM Information Management & Consulting
(2002) Band 17
• Engel, C.; Menzer, M.; Nienstedt, D.: GPM Deutsche Gesellschaft für Projektma-
nagement e.V. (Hrsg.) / PA Consulting Group (Hrsg.): Projektmanagementstudie
2006. Ergebnisse der Projektmanangementstudie "Konsequente Berücksichti-
gung weicher Faktoren", Frankfurt / München, 2006
• Grimm, Sebastian: Icido Virtual Reality. Risikominimierung mit Virtual Reality, Eu-
roMold, Demat: Frankfurt 2009
• Jansen, A.; Stein, B.; Müller, C.; Ehlbeck, I.: SIKEBA - Software-Einführung in
KMU - eine Bestandsaufnahme. URL:
http://www.bao.de/docdown/vortrag_workshop_sikeba.pdf (21.08.2008)
• Klocke, F.: Vorsprung durch Virtual Reality; Eine Studie über den industriellen
Einsatz von VR. Aachen: Fraunhofer-Institut für Produktionstechnologie IPT, 2003
• Leston, J.; Ring, K.; Kyra, E.: Virtual reality. Business applications, markets and
opportunities. London: Ovum Ltd. 1996
• Runde, C.: Konzeption und Einführung von Virtueller Realität als Komponente der
Digitalen Fabrik in Industrieunternehmen. Heimsheim : Jost-Jetter Verlag, 2007
• Runde, C. ; Westkämper, E. ; Kunst, S.: Ein Modell zur Wirtschaftlichkeitsbewer-
tung des Einsatzes von Virtual Reality für Aufgaben in der Digitalen Fabrik. In:
Gausemeier, J.: Augmented & Virtual Reality in der Produktentstehung : 5. Pa-
derborner Workshop, 31. Mai und 1. Juni 2006, Paderborn
120

121. 4 Zusammenfassung der Ergebnisse
4.1 Bewertung der Ergebnisse
Der Ausgangspunkt zu Beginn des Vorhabens entsprach der in Abbildung 113 ge-
zeigten Vorgehensweise bei den Automobilherstellern. Die Simulationen der Einzel-
prozesse Umformen, Fügen und Lackieren waren bisher nicht verknüpft. Ergebnisse
aus einer gewerkespezifischen Auslegung flossen kaum in die darauffolgenden Ge-
werke ein. Allein in die Crash-Simulation wurden bereits in einigen wenigen Fällen
plastische Formänderungen in der Blechebene und Blechdickenänderungen halbau-
tomatisch weitergereicht (in Abbildung 113 durch den vertikalen Pfeil angedeutet).
Die gängige Praxis in nachgeschalteten Prozesssimulationen war vielmehr, dass Ma-
terialeigenschaften aus dem ursprünglichen Zustand übernommen und konstante
Blechdicken angesetzt wurden. Denn in den Hauptprozessen kamen bisher nur Insel-
lösungen für die Simulation von Teilbereichen zum Einsatz, die keine datentechni-
sche Kopplung nutzten.
Abbildung 113: Stand der Technik zu Beginn des Vorhabens zum Ergebnistransfer
aus der Prozesssimulation in die Produktsimulation
Weiterhin bestand eine große Herausforderung darin, dass für die Durchführung der
etablierten inkrementellen Umformsimulation ein hoher Modellierungs- und Berech-
nungsaufwand erforderlich ist und diese deshalb erst zu einem relativ späten Zeit-
121

122. punkt im Produktentwicklungsprozess durchgeführt wird. Für die Absicherung der
Herstellbarkeit neu entwickelter Produkte bedeutete dies, dass die Produktentwick-
lung mit der Fertigungsplanung nur mangelhaft verknüpft ist, so dass eine Prozess-
absicherung erst zu einem sehr späten Zeitpunkt nach der Beschaffungsfreigabe er-
folgen kann (siehe Abbildung 114 oben), wenn ein neues Produkt schon weitgehend
entwickelt ist. Hier haben insbesondere der Test und die erfolgreiche Einbindung so
genannter Einschrittverfahren in die Prozesskette den Weg zu einem früheren Ein-
satz der Umformsimulation eröffnet. Auf diese Weise können das Produkt eher abge-
sichert und der zugehörige Prozess früher optimiert werden.
Stand der
Technik:
Ziel des VIP-
ROF-Projektes:
Abbildung 114: Vergleich von Ausgangssituation und Zielsetzung des VIPROF-
Projektes
Weiterhin konnten standardisierte und konsistente Schnittstellen zwischen den Pro-
zessen geschaffen werden, mit denen die Entwicklungszeit verkürzt und die Pro-
zessabsicherung bereits in einem sehr frühen Stadium der Produktentwicklung be-
gonnen werden kann. Mit diesem virtuellen Simultaneous Engineering (siehe Abbil-
dung 114 unten) können Planungsfehler frühzeitig aufgedeckt und die Produktquali-
tät erhöht werden. Ein weitgehend paralleler Ablauf von Produktentwicklung und
Prozessabsicherung stärkt die Robustheit des Gesamtprozesses.
Ein großer Fortschritt wurde dabei in der einheitlichen Ablage der Simulationsdaten
im standardisierten XML-Format und der Entwicklung der dazu notwendigen Über-
führungsroutinen erzielt (siehe Abbildung 115).
122

123. Stand des Simulationsdatenhand- Stand des Simulationsdatenhand-
lings zu Beginn des Vorhabens lings, wenn die VIPROF-Ergebnisse
bei VW implementiert sein werden
Abbildung 115: Vorteile der gewerkeübergreifenden Übertragung und Ablage von
Simulationsdaten
Damit wird es möglich, die im Rahmen des Simulationsprozesses anfallenden Daten
standardisiert abzulegen, in ihnen zu suchen und Teilbereiche zu extrahieren. Darü-
ber hinaus kann aus den XML-Daten eine für alle frei zugängliche Visualisierung ge-
neriert werden, die weitergegeben werden kann, ohne Know-how bzgl. Konstruk-
tionsdetails preisgeben zu müssen – dies war bei der ursprünglichen Visualisierung,
die innerhalb der proprietären Programme stattfand, der Fall. Außerdem arbeitet der
Prozess nun effektiver im Hinblick auf Datenhandling und ermöglicht für die Zukunft
die Erweiterung der Prozesskette um weitere Simulationstools bzw. -anbieter und
deren einfache Kopplung, sofern diese das XML-Format unterstützen. Der XML-
Konverter hilft, die im Projekt anfallenden proprietären Daten automatisiert zu über-
führen. Dies vereinfacht die Arbeit innerhalb des Prozesses und erhöht auch seine
Qualität, da ein manueller Eingriff bei der Transformation, und damit eine potenzielle
Fehlerquelle, entfällt. Ebenso unterstützt der XML-Konverter den Konstrukteur und
Berechner bei der Rücktransformation der ursprünglichen Daten aus dem XML, um
eventuell notwendige Neusimulationen starten zu können.
Der wissenschaftlich-technische Stand zum Ende des Vorhabens besteht in der Ver-
knüpfung von Produktentwicklung und Fertigungstechnik zu einer durchgängigen,
digitalisierten und kooperativen Entwicklungs- und Produktionsplanung. Es gelingt
eine frühzeitige Absicherung der fertigungsgerechten Produktgestaltung mittels
• Durchgängiger Prozesskettensimulation
• Berücksichtigung der Fertigungshistorie
123

124. • Integration der Simulationsdaten ins PDM-System
• Datenübertragung inkl. Mapping durch offene Schnittstellen
• Prozessautomatisierung mit Hilfe von Workflows
Die Verkettung wird zur Erhöhung der Produktqualität beitragen. Weitere Vorteile
sind, dass der Reifegrad der Produktentwicklung jederzeit abrufbar ist und dass Ab-
hängigkeiten vom Erfahrungsschatz einzelner Mitarbeiter reduziert werden können.
4.2 Darstellung der durchgängigen Simulationsprozesskette
VIPROF anhand eines Anwendungsbeispiels
Die Durchgängigkeit der Prozesskettensimulation und die nahezu automatische Da-
tenübertragung wurden im Projekt anhand eines prototypischen Demonstrators
nachgewiesen, der im PDM-System TEAMCENTER realisiert wurde. Die ARC Solu-
tions GmbH hat über den Ablauf des entstandenen Workflows einen Bildschirmfilm
verfasst, aus dem im Folgenden Ausschnitte zur Verdeutlichung des Vorgehens ge-
zeigt werden.
In diesem Projekt werden zwei Rollen betrachtet, an denen die Durchgängigkeit der
Prozesskette gezeigt wird. Das ist zum einen die Rolle des Planers, welcher die für
eine Simulation nötigen Inputdaten zusammenstellt, Strukturen verwaltet, die Pro-
zesskette startet und die entstehenden Ergebnisse bewertet. Zum anderen ist es die
Rolle des Berechners (Simulanten), der die Simulation ausführt und die Ergebnisse
abspeichert.
Des Weiteren werden im PDM-System mehrere Strukturen abgebildet, welche für die
Datenhaltung und die Transparenz von großer Bedeutung sind. Die Wichtigsten sind
die Produktstruktur, mit deren Hilfe die Geometriedaten des betreffenden Fahrzeuges
verwaltet werden (Abbildung 100) und eine Fertigungsprozessstruktur.
Letztere dient dazu die bei der Fertigung eines Fahrzeuges auftretenden Prozesse
zu unterteilen und die dabei verwendeten und anfallenden Daten transparent abzu-
bilden. Es werden Prozesse und Operationen unterschieden. Die Abbildung 101
zeigt ein Beispiel für den Prozess des Umformens der B-Säule eines Fahrzeuges.
Dieser Prozess kann in drei Operationen unterteilt werden. Operation 10 entspricht
dem „Zuführen der Platine zur Maschine“, Operation 20 ist das eigentliche „Tiefzie-
hen“ und Operation 30 beschreibt die „Abfuhr“ des fertig umgeformten Bauteiles aus
124

125. der Maschine. In allen Operationen sind jeweils die dafür genutzten Daten verknüpft,
wie zum Beispiel die Ziehanlage oder das Material beim „Tiefziehen“. Zusätzlich hat
der Planer bereits die Zielbauteilgeometrie der B-Säule aus der Produktstruktur in
Operation 30 der Fertigungsprozessstruktur verlinkt.
Beide Strukturen werden in diesem Projekt vom Planer erstellt und gepflegt. Nach
Abschluss der Simulation werden die Ergebnisse in die Fertigungsprozessstruktur
verknüpft, da somit für alle folgenden Anwender und Prozesse die größtmögliche
Transparenz erreicht wird. Es ist leicht erkennbar, wie weit der Fertigungsprozess
fortgeschritten ist und welche Daten verwendet wurden bzw. welche noch fehlen.
Dazu erzeugt der Planer ein Analyse-Objekt (Erläuterung siehe Kapitel 3), unter wel-
chem alle genutzten und anfallenden Daten, dieser Simulation, abgelegt werden
(Abbildung 116).
Abbildung 116: Analyse-Objekt
Im Teamcentermodul CAE-Manager kann dieses Objekt weiter bearbeitet werden.
Hier existieren drei Reiter (Abbildung 117).
Abbildung 117: CAE-Manager
Im Reiter Analyse wird das Analyse-Objekt mit all seinen Anhängen angezeigt. Unter
dem Reiter Produkt werden alle Inputdaten, zum Beispiel die Geometriedaten, zu
dieser Analyse gesammelt. Der Reiter Modell gibt die sogenannte CAE-Struktur wie-
der. Im VIPROF-Projekt ist dies ein 1:1 Abbild der Inputdaten unter einem anderen
Item-Typ. Diese beiden Reiter sind zu Beginn der Analyse noch leer. Der Planer ers-
tellt nun ein sogenanntes Inputdeck, in dem alle benötigten Daten zusammengestellt
werden. Diese Daten und Objekte beschafft er sich aus den anderen Strukturen, wie
zum Beispiel der Fertigungsprozessstruktur und fügt sie dem Reiter Produkt im CAE-
Manager hinzu (Abbildung 118).
125

126. Abbildung 118: Inputdeck im CAE-Manager
Auf Knopfdruck erstellt Teamcenter automatisch die dazugehörige CAE-Struktur im
Reiter Modell. In diesem Beispiel entspricht die CAE-Struktur 1:1 dem Inputdeck
(Abbildung 119).
Abbildung 119: CAE-Struktur im CAE-Manager
Es ist ebenso möglich anhand von zu definierenden Regeln eine komplexere CAE-
Struktur erstellen zu lassen. Teamcenter verknüpft im selben Schritt alle Objekte so
miteinander, dass sie mit dem Analyse-Objekt über spezielle Relationen verbunden
sind (Abbildung 120).
Abbildung 120: Analyse-Objekt mit verknüpften Modell und Inputdeck
126

127. Anschließend startet der Planer den Workflow Umformsimulation und hängt diesem
das Analyse-Objekt an (Abbildung 121).
Abbildung 121: Starten des Workflow „Umformsimulation“
Dieses Objekt erhält zuerst den Status Rot (Abbildung 122). Durch einen Status kön-
nen bestimmte Rechte an das Objekt gekoppelt werden. Zum Beispiel nur Lese-,
Schreib-, Änderungs- oder Löschrechte usw., welche für jeden einzelnen Status defi-
niert werden können. Im weiteren Verlauf (Ablauf des Workflowprozesses in Abbil-
dung 109) wird das Analyse-Objekt mit allen bereits angehängten Inputdaten dem
Berechner zugestellt.
Abbildung 122: Analyse-Objekt mit Status „Rot“
In der Taskbox des Berechners befindet sich die Aufgabe zusammen mit einer Be-
schreibung und dem angehängten Simulationsobjekt (Abbildung 123).
127

128. Abbildung 123: Taskbox des Berechners mit Aufgabenbeschreibung
Von hier ausgehend kann der Berechner nochmals überprüfen, ob alle relevanten
Daten zur Verfügung stehen, und anschließend das Simulationsobjekt an den CAE
Manager senden. Im CAE Manager wurde bereits eine Konfiguration für das nun
auszuführende Simulationstool erstellt. Mit dieser Konfiguration lässt sich definieren,
welche Daten aus Teamcenter zur weiteren Verwendung exportiert, welche Werk-
zeuge über Skripte gestartet und welche Ergebnisdaten wieder nach Teamcenter
importiert werden sollen. Diese Konfiguration wählt der Berechner nun aus und das
ausgewählte Analyse-Objekt wird mit der entsprechenden Konfigurationsdefinition
verarbeitet. Im Hintergrund werden die Daten (Geometrie, Beschnittkurven, Material-
datei, Umformmaschine,…) exportiert und ein Simulationswerkzeug gestartet. Lässt
sich die Simulation komplett automatisiert durchführen ist kein Eingreifen des An-
wenders notwendig. Andernfalls wird der Berechner die Simulation manuell ausfüh-
ren. Es entsteht ein Simulationsergebnis, welches im selben Verzeichnis abgelegt
wird wie die Eingangsdaten. Durch Beendigung des Simulationstools wird der Pro-
zess fortgesetzt. Die Konvertierung erstellt aus dem Ergebnis-File des Simulations-
programms ein XML und daraus zusätzlich ein JT zur Visualisierung der Ergebnisse.
Beide werden anhand von Skripten automatisch ausgeführt. Im Anschluss erfolgt der
128

129. Import der entstandenen Ergebnisse nach Teamcenter, wobei diese an das Aus-
gangs-Analyse-Objekt gehängt werden (Abbildung 124).
Abbildung 124: Simulationsergebnisse angehängt an Analyse-Objekt
Der Berechner hat jetzt die Möglichkeit die Ergebnisse zu verifizieren und seine Auf-
gabe abzuschließen. Dadurch wird der Workflow fortgesetzt, die Aufgabe verschwin-
det aus der Taskbox des Berechners und wird an den Planer weitergeleitet. In seiner
Taskbox befinden sich nun eine Prüfaufgabe mit Analyse-Objekt samt Ergebnissen
und zusätzlich ein Prüfformular. In diesem kann der Planer einen Status für die Simu-
lation vergeben. Der Status orientiert sich an den Ampelfarben rot, gelb, grün
(Abbildung 125). Der Planer überprüft die Simulationsergebnisse. Sind sie in Ord-
nung vergibt er den Status grün, bei Fehlern oder Problemen setzt er den Status auf
rot, gibt es Klärungsbedarf wie mit dem Bauteil weiterverfahren werden soll wird der
Status gelb gesetzt.
Abbildung 125: Prüfbericht mit Statusvergabe
129

130. Nach Vergabe des Status beendet der Planer diese Aufgabe und der Workflow ist in
diesem Fall ebenfalls beendet. Das Analyse-Objekt hat nun den entsprechenden
Status als Ampelsymbol erhalten (Abbildung 126) und kann vom Planer in die Ferti-
gungsprozessstruktur (Abbildung 127) eingebunden werden.
Abbildung 126: Analyse-Objekt mit Status „grün“
Abbildung 127: Analyse-Objekt in Fertigungsprozessstruktur
Diese Abfolge der Arbeitsschritte wiederholt sich für alle nachfolgenden Simulatio-
nen. Es fügt sich lediglich als Zwischenschritt das Mapping der Simulationsnetze,
durch den SCAIMapper, ein. Dies wurde in Kapitel 3.2.2 bereits ausführlich beschrie-
ben.
130

131. 5 Ausblick
Volkswagen wird die Projektergebnisse im eigenen Unternehmen ggf. unter Einbe-
ziehung von Zulieferern verwerten. Dazu erfolgt eine Integration des gewerkeüber-
greifenden Simulationsdatenmanagements (SDM) in TEAMCENTER / CONNECT.
Auch die ARC Solutions GmbH wird weitere Anwendungen mit TEAMCENTER auf
Basis der Projektergebnisse realisieren. Die Software-Anbieter CADFEM und ESI
werden das SDM sowie Workflows zur Abbildung der Prozesskettensimulation mit
eigenen Tools umsetzen und vermarkten. Dabei werden auch Lösungen für den Mit-
telstand erarbeitet, die ohne TEAMCENTER auskommen. Die Hochschulen werden
die Projektergebnisse für Forschung und Lehre nutzen.
5.1 Ausblick Volkswagen
Künftig sollen bei Volkswagen die Simulationsergebnisse gewerkeübergreifend über-
tragen und konsequent abgelegt werden, damit sie in einem System verfügbar sind,
wie in Abbildung 128 gezeigt. Auch Materialdaten sollen über die Ressourcen-
verwaltung von TEAMCENTER mit abgelegt werden, damit sich die Simulationen
darauf verlinken können. Bei VW soll eine weltweite Vernetzung von Fahrzeug-
projekten entstehen, damit an den verschiedenen Standorten einheitliche Produkt-
und Fertigungsdaten vorliegen.
Abbildung 128: Gewerkeübergreifende Übertragung
von Simulationsergebnissen bei VW
Zur Verwertung der Projektergebnisse soll das Simulationsdatenmanagement aber
nicht komplett in das Produktdatenmanagement übernommen werden, da die Daten-
haltung sonst zu unübersichtlich würde. Vielmehr wird ein separater File-Server für
die Simulationsdaten vorgesehen. Bestimmte Simulationsstände werden dann im
Produktdatenmanagement archiviert, so dass der Stand einer Produkt- oder Fahr-
131

132. zeugentwicklung zu jedem Zeitpunkt abrufbar ist. Zugleich kann daraus eine Doku-
mentation für Folgeprojekte oder zu Kontrollzwecken bzw. für Revisionen generiert
werden.
Mit dem VIPROF-Projekt und der weiteren Integration der Projektergebnisse wird
dem Management von Volkswagen ein Reifegrad-Cockpit zur Verfügung gestellt, um
die Herstellung simulationsbasiert bewerten zu können. Zudem soll jeder Planer und
Konstrukteur Simulationsergebnisse im Gesamtfahrzeugkontext in 3D analysieren
können. Nachdem bisher die Synchronisation zwischen Produktion und Entwicklung
nicht durch IT-Systeme unterstützt wurde, kann der Fahrzeugentwicklungs- und
-planungsprozess unter Nutzung der Ergebnisse des VIRPOF-Projektes synchron
und in kontinuierlichem Austausch erfolgen. Die Transparenz des Planungsstandes,
die zuvor mangels einer zusammenfassenden Übersicht über den Planungsstand
eines Fahrzeuges nicht gegeben war, ist jetzt für Führungskräfte und Management
jederzeit im Reifegrad-Cockpit einsehbar.
5.2 Transfer der Ergebnisse von CADFEM
CADFEM sieht eine Verwertungsmöglichkeit der VIPROF-Ergebnisse in einer Koope-
ration mit der Firma V-Collab, die eine kollaborative Lösung zur Visualisierung von
CAD- und CAE-Daten anbietet. Damit können Simulationsergebnisse komprimiert
und im Simulationsdatenmanagement von ANSYS abgelegt werden. Mit der Soft-
ware DIGIMAT besteht die Möglichkeit, inhomogene Verteilungen von faserverstärk-
tem Material aus dem Spritzguss abzubilden, um die Herstellhistorie zu berücksichti-
gen. Dieses Vorgehen wird in Abbildung 129 illustriert.
Abbildung 129: Analyse von fasergefüllten Polymerbauteilen
durch integrative Simulation mit DIGIMAT
132

133. Eine weitere Verwertung der Projektergebnisse für die kommerzielle Anwendung
plant CADFEM in Form einer Schnittstelle zwischen der FTI-Blechumformsimulation
und der ANSYS Workbench. Motiviert durch die Erkenntnisse aus dem VIPROF-
Projekt und durch die Verbreitungsmöglichkeiten im Zusammenhang mit dem Projekt
wurde bei CADFEM eine Erweiterung für die ANSYS Workbench entwickelt. Die
Blechumformsimulation mit dem FTI One-Step Löser wurde in einem ANSYS-
Workbench-Projekt als Lösungskomponente integriert. Die Geometrie der Bauteile
wird aus der Workbench Umgebung als Eingangsgröße verwendet. Die Blechdicken
und die plastischen Vergleichsformänderungen können in andere Analysesysteme
aus der Workbench übertragen werden. Werden mehrere Simulationen in einem
ANSYS-Workbench-Projekt miteinander verbunden, können damit alle verbundenen
Daten in diesem Berechnungsprojekt verwaltet werden. Dieser in ANSYS V14 integ-
rierte Workflow für strukturdynamische oder thermische Analysen ist in Abbildung
130 gezeigt.
Abbildung 130: Geplante kommerzielle Verwertung der Ergebnisse des VIPROF-
Projektes durch ein Interface zwischen der FTI-Blechumformsimulation und der
ANSYS Workbench
Die FTI Simulation an sich ist im Vergleich mit vielen anderen Struktursimulationen
einfach zu handhaben. Durch die Integration in die ANSYS Workbench ist die Ver-
knüpfung mit Eingangsdaten und Folgerechnungen automatisiert verfügbar. Dies
macht die Methode zum einen attraktiv für einen größeren Kreis von Anwendern. Die
133

134. Berücksichtigung der Umformhistorie erzeugt so nur verhältnismäßig wenig zusätzli-
chen Bearbeitungsaufwand. Zum anderen ermöglicht diese Automatisierung eine
weitreichendere Analyse der Prozess- und Designparameter in Sensitivitätsanalysen,
Optimierungen und Robust Design Bewertungen.
5.3 Transfer der Ergebnisse von ESI für Zulieferer mit VisualDSS
Die in VIPROF erstmalig in dieser Breite aufgenommene Themenstellung der soge-
nannten „End to End“ Prozesskette, stieß bei allen Vorträgen vor unseren Kunden
und auch im Industriearbeitskreis auf lebhaftes Interesse der Beteiligten. Dies zeigt
aus Sicht von ESI den Bedarf für Informationstage und vor Ort Demonstrationen der
im Rahmen des Projektes erstellten Methodik, z. B. an Hand der TEAMCENTER Lö-
sung oder in unserem Falle des VisualDSS Demonstrators.
Weiterhin scheint der von Volkswagen demonstrierte neue Weg der 3D-CAE-
Visualisierung mittels JT-Format sehr erfolgversprechend zu sein. Im Bereich des
CAD und der virtuellen Fabrik ist das JT-Format bereits gesetzter Standard der deut-
schen Automobilindustrie. Die Vorteile der Weitergabe von CAE-Ergebnissen ohne
Know-how-Abfluss, gekoppelt mit der kostenfreien Viewer Lösung JT2Go kann hier
nicht stark genug betont werden. So dass auch hier eine Fortsetzung der Thematik
„JT for CAE“ angeregt wird.
Die im Prinzip vorgestellte Methode der Neuvernetzung, hat ebenfalls das Potential
im Rahmen der industriellen Forschungsförderung (AIF) einen nicht unwesentlichen
Beitrag zur Optimierung der „End to End“ Fertigungssimulationskette zu leisten. Denn
über das Ausschwimmen zweier Bauteile, wie es z. B. im SCAIMapper möglich ist,
hinaus, ist die akkurate Übergabe der Geometrieform von einem Gewerk zum näch-
sten eine deutliche Verbesserung.
ESI hat in der letzten Projektphase begonnen die Ergebnisse des Projektes in das
eigene SDM Produkt VisualDSS zu übertragen (Abbildung 131). Das Ziel ist es, ei-
nen Demonstrator zu realisieren, der es erlaubt die VIPROF Ergebnisse im Mittels-
tand, der keine TEAMCENTER Installation einsetzt, hinreichend plausibel vorzustel-
len.
Der Vertrieb einer SDM-Lösung stellt gegenüber den schon erklärungsbedürftigen
Einzelprodukten, wie der inkrementellen Umformsimulation, dem transienten
Schweißen oder dem Crash noch eine Steigerung an Komplexität dar. Denn norma-
134

135. lerweise ist die Zielgruppe der technischen Käufer einem Gewerk, wie dem Schwei-
ßen zuzuordnen. Hier sind nun aber mindestens alle betroffenen Gewerke, die IT-
Abteilung und das obere Management involviert. Daher scheint die Bewerbung ei-
nes solchen Produktes ohne einen adäquaten Live-Demonstrator nicht wirklich emp-
fehlenswert. Der VisualDSS-Demonstrator wurde basierend auf den im VIPROF-
Projekt gemeinsam mit Volkswagen und den Projektpartnern erarbeiteten Richtlinien
und Vorgaben generiert und hat damit eine im automobilen Umfeld anerkannte Refe-
renz als Grundlage.
Eine Live-Demonstration der von ESI auf die typischen Gewerke Umformen, Fügen
und Crash-Simulation reduzierten Prozesskette begegnet der Zielgruppe typischer
Systemlieferanten sehr gut. Denn diese betrachten schon heute die notwendigen
Komponenten- und Systemeigenschaften, z. B. der Türen oder des Vorderwagens in
Relation zu geforderten Crash- oder NVH-Vorgaben. Die Zielgruppe für eine Vi-
sualDSS Vorstellung ist die Geschäftsführung, da diese über die Einführung der Ver-
kettung der Arbeitsabläufe befähigt wird die Unternehmensabläufe im Modulcockpit
online zu überschauen und anschließend zu optimieren. Natürlich sind die unter-
schiedlichen Gewerke bei der Umsetzung umfassend einzubinden. Doch die über-
greifende Integration der Arbeitsabläufe lässt sich gerade mit der im VIPROF-Projekt
entwickelten Methodik auch über anfängliche Bedenken hinweg zu einem positiven
Ergebnis führen. Denn die Integration in das Simulationsdaten- und ablaufmanage-
ment vereinfacht die Unternehmensabläufe mittelfristig erheblich. Ein Zusatznutzen
ist sicherlich die revisionssichere, auditfähige Handhabung aller Daten und Prozesse
ohne auf die Papierform zurückgreifen zu müssen.
Business Processes VisualDSS web client
Rail
RAIL
ASSEMBLY
Decision
VisualDSS Database Making Tool
Abbildung 131: Simulationsprozess- und Datenmanagement in VisualDSS
135

136. 5.4 Ausblick der ARC Solutions GmbH
Das durch das VIPROF-Projekt erworbene Knowhow und der Vorsprung in der An-
wendung der neuen Teamcenter Module sollen dazu genutzt werden, weitere Team-
center Lizenzen in neuen Anwenderumfeldern (CAE) zu vertreiben. Außerdem soll
das Dienstleistungsangebot im Bereich Implementierung und Konfiguration um CAE
Anwendungen in Teamcenter erweitert werden. In beiden Bereichen werden gute
Marktchancen erwartet.
Hinsichtlich einer CAE-Applikationsintegration inklusive Formatkonvertierung kann
als Ergebnis des VIPROF-Projektes eine zusammengehörige Applikation samt For-
matkonvertierung angeboten werden. Hierfür wird die Umsetzung des Modulcockpits
weiterverfolgt, um einen komplett transparenten Lösungsansatz zu bieten.
Die Integration von Simulationsdaten in Teamcenter und das damit erarbeitete Wis-
sen kann als zusätzliche Entscheidungshilfe für von ARC Solutions vertriebene CAE
Werkzeuge (NX) dienen. Die Betreuung, Implementierung und Konfiguration von
Schnittstellen für diese Anwendungen sind weitere positive Aspekte.
5.5 Ausblick der Ostfalia HaW
An der Ostfalia HaW werden die Ergebnisse des Projekts VIPROF in die Ausbildung
von Studierenden einfließen. In der Vorlesung „Blechbearbeitung im Fahrzeugbau“
(Bachelorstudiengang Maschinenbau) wird u.a. die Entwicklungsprozesskette thema-
tisiert und entsprechend mit den Projektergebnissen ergänzt. Im Weiterbildungsstu-
diengang für Ingenieure und Ingenieurinnen, dem „Master Automotive Produktion“
werden die Projektergebnisse im Rahmen der Vorlesung „Umformsimulation in der
Produktentstehungsphase“ eingebunden.
Das Institut für Produktionstechnik der Ostfalia HaW (IPT) wird die VIPROF-
Ergebnisse auch weiterhin mit Hilfe des Vereins „Netzwerk Digitale Fabrik“ - im
Rahmen von kontinuierlichen Veranstaltungen - kleinen und mittelständischen Unter-
nehmen näherbringen.
In den nächsten drei Jahren soll am IPT mit den im Projekt erworbenen Kompeten-
zen die Integration der Warmumformung (Presshärten) in die Prozesskette entwickelt
werden. Ein Forschungsantrag wurde in der Förderlinie ProfilNT des BMBF gestellt.
136

137. Durch die durchgängige Virtualisierung der gesamten Prozesskette ist eine Basis für
zukünftige Forschungsarbeiten bezüglich neuer Produktentwicklungsmethoden ge-
schaffen worden. Die Forschungsergebnisse bilden die Grundlage für eine Ausdeh-
nung der Prozesskette in weitere Simulationsbereiche. Zum Beispiel könnte am IPT
mit den bestehenden Kompetenzen eine Erweiterung der Prozesskette auf den Be-
reich der Montagesimulation mit dem Ziel eines vollständigen Schlusses der gesam-
ten Fertigungskette untersucht werden.
5.6 Datentechnischer Ausblick der TU Berlin
In Zukunft könnten Mappingfunktionalitäten in den XML-Konverter eingebettet wer-
den. Sollten z. B. die Funktionalität des SCAIMappers Einzug in den XML-Konverter
finden, und darüber hinaus XML- und JT-Konverter zusammengelegt werden, findet
eine Verdichtung der am Prozess beteiligten Tools statt. Dies vermindert Fehlerquel-
len bzw. hilft diese schneller zu finden, senkt den Koordinationsaufwand des
PDM/SDM zwischen den beteiligten Tools und erhöht damit die Qualität des Prozes-
ses und seiner Outputs.
Das XML-Format kann künftig um weitere Bestandteile erweitert werden. So könnten
Bereiche für Materialdaten geschaffen bzw. Strukturen definiert werden, die beste-
hende Elemente sogenannten Parts (also Elementgruppen) zuordnet. Dies erhöht
die Flexibilität des Datenformates und den Benutzerkreis des XML-Formats.
Bei steigendem Datenaufkommen, z. B. durch Einlagerung neuer Daten in das XML-
Datenformat bzw. Abspeicherung ganzer Fahrzeugkarosserien und detaillierten Si-
mulationsergebnissen können die Daten Größen annehmen, die nicht oder nur
schwer handhabbar sind. Eine Modularisierung der Daten in einzelne Bestandteile
und damit einzelnen Dateien, die dann in einer Datei, z. B. einem Manifest, zusam-
mengeführt werden, erhöht die Flexibilität und vermindert die Last bei der Verarbei-
tung der Daten, da nur die Daten bearbeitet werden, die notwendig sind, alle anderen
bleiben unberührt.
5.7 Ausblick Professur Virtuelle Fertigungstechnik
Die Professur für Virtuelle Fertigungstechnik schätzt die Ergebnisse dieses Projektes
als positiv und insgesamt sehr gelungen ein. Es erfolgten bereits einige Publikatio-
137

138. nen in einschlägigen Zeitschriften sowie auf nationalen und internationalen Tagun-
gen. Eine weitere Veröffentlichung ist für 2012 auf dem ProSTEP iViP Symposium
geplant.
Als Professur der Technischen Universität Chemnitz wird angestrebt, die guten Pro-
jektergebnisse im Rahmen der Forschungs- und Lehraufgaben einzusetzen. Dabei
kann besonders die Vorlesung Produktdatentechnologie sowie die Vorlesung Simula-
tion in der Umformtechnik für Studierende aktualisiert und modernisiert werden.
Die Vorlesung Produktdatentechnologie wird um den Teil der Ablage von Simulati-
onsdaten in einem PDM-System ergänzt. Weiterhin kann die Steuerung des Daten-
austauschs zwischen verschiedenen Simulationsprogrammen über Workflows ge-
zeigt werden. In den vorlesungsbegleitenden Praktika bekommen die Studierenden
die Möglichkeit an einem Beispiel diese Funktionen direkt am PDM-System anzu-
wenden.
Den Studierenden der Vorlesung Simulation in der Umformtechnik können verschie-
dene Wege aufgezeigt werden Simulationsdaten abzulegen und unter Einbeziehung
von Simulationsergebnissen aus vorgelagerten Simulationen genauere Gesamter-
gebnisse zu erzielen. Dabei sollen die im VIPROF-Projekt entwickelten Schnittstellen
und der Konverter Anwendung finden. Eine solche Arbeitsweise zeigt den Studieren-
den besonders stark die Wichtigkeit von Teamarbeit und häufiger Kommunikation bei
einer abteilungsübergreifenden Projektbearbeitung.
Zusätzlich sollen aufbauend auf den Ergebnissen aus dem Projekt zukünftige For-
schungsvorhaben und Industrieprojekte beantragt werden.
138

139. 6 Öffentlichkeitsarbeit
Zur Information über das Projekt wurde die Projekt-Homepage www.projekt-viprof.de
eingerichtet. Während der Projektlaufzeit wurde der Industriearbeitskreis "Virtualisie-
rung" zum Erfahrungs- und Informationsaustausch gegründet. Der Arbeitskreis war
offen für Interessenten außerhalb des Projektkonsortiums.
Von Partnern des VIPROF-Projektes wurden im Projekt die folgenden Verbreitungs-
aktivitäten unternommen:
Datum Ort / Beitrag Veranstaltung Autoren
Jahr 2009 Fellbach VDC-Newsletter und Pres- VDC Fellbach
semeldungen z. B. im
Newsletter Kompetenz-
netze Deutschland
16.-18.06. Magdeburg Fachtagung Digitales En- Pinner (VW) et al.
2009 gineering, Fraunhofer Wis-
senschaftstage
Titel: Durchgängige Virtualisierung der Entwicklung und Produktion von Fahrzeu-
gen
16.-18.06. Veröffentlich- 12. IFF-Wissenschaftstage ARC Solutions
2009 ung
Titel: Projektstand und Ergebnisse zum VIPROF-Projekt
Herbstaus- Veröffentlich- ProduktDatenJournal Nr. 2 Awiszus, Bolick (VIF),
gabe 2009 ung / 2009, S. 39 – 43, Brylla (ARC Solutions), Pin-
ISBN/ISSN: 1436-0403 ner (VW), Schulz (TU Berlin)
Titel: Produktdatenmanagement in der Entwicklung und Produktion von Fahrzeu-
gen, Heft 2, S. 39 – 43, ISSN 1436-0403
19.11.2009 Leipzig ANSYS Conference und Pinner (VW) et al.
27. CADFEM Users´ Meet-
ing
Titel: Einsatz inverser Solver innerhalb der Prozesskettensimulation im Bereich
Karosseriebau
19.11.2009 Leipzig CAE-Forum auf dem 27. Kulp (VW)
CADFEM Users´ Meeting
Titel: Impulsvortrag: Integrierte Prozesskettensimulation bei der Karosseriehers-
tellung im Projekt VIPROF
139

140. Datum Ort / Beitrag Veranstaltung Autoren
19.11.2009 Leipzig CAE-Forum auf dem 27. Knick (CADFEM), Kulp (VW)
CADFEM Users´ Meeting
Titel: „Paint Drying Simulation as part of the Body-in-White Manufacturing
Processes in the VIPROF Project“
30.03.2010 Darmstadt 16. JT-User Group Treffen, Pinner (VW)
Fraunhofer IGD
Titel: Universelle Visualisierung von Simulations-Ergebnisdaten im JT-Format
Apr. 2010 Karlsruhe Karlsruher Arbeitsgesprä- ARC Solutions, Ostfalia HaW
(Ausstellung) che
04.05.2010 Fellbach Internationale Konferenz Awiszus, Bolick (VIF),
„Neuere Entwicklungen in Leck (Ostfalia HaW), Brylla
der Blechumformung“ (ARC Solutions), Pinner (VW)
Titel: Durchgängige Simulationsprozessketten in der Fahrzeugentwicklung
Tagungsband S. 65 – 84, ISBN 978-3-88355-378-8
08.06.2010 Fellbach Kick-off Veranstaltung In- Vorträge zu den Teilvorhaben
dustriearbeitskreis VIP- aller VIPROF-Partner
ROF
22.-23.06. Bonn 1st Conference on Multi- Leck/Rambke (Ostfalia HaW),
2010 physics Simulation Awiszus (VIF), Pinner (VW),
Knick (CADFEM)
Titel: End-to-end Virtualization of the Development and Production of Vehicles
02.07.2010 Bekannt- Informationsnetzwerk ESI
machung XING
16.-17.11. Baden-Baden SIMVEC (15. Internat. VDI- Pinner (VW), Awiszus (VIF),
2010 Konferenz für Simulation Vogel (ESI), Leck und Ramb-
und Berechnung) ke (Ostfalia HaW)
Titel: Prozesskettensimulation im Karosseriebau am Beispiel der Kopplung von
Umform- und Fügesimulation
16.-17.11. Baden-Baden SIMVEC (15. Internat. VDI- Knick / Steinbeck-Behrens
2010 Konferenz für Simulation (CADFEM), Kulp / Pinner
und Berechnung) (VW)
Titel: Integration der Lackiersimulation in den Herstellungsprozess von Karosse-
rien im Forschungsprojekt VIPROF
10.02.2011 Braunschweig Fachkonferenz „Berech- Pinner (VW)
nung im Produktprozess“
Titel: Visualisierung von CAE-Ergebnisdaten im JT-Format
140

141. Datum Ort / Beitrag Veranstaltung Autoren
16.-17.03. Landshut PAM-STAMP Forum 2011 Pinner (VW), Schroeder (ESI)
2011 Simulation der Prozesskette im Karosseriebau mittels Kopplung der Ferti-
Titel: gungsverfahren
17.05.2011 Seeheim Siemens PLM Connection Brylla (ARC Solutions), Pin-
Deutschland ner (VW)
Titel: Durchgängige Prozessketten für CAE-Simulation in der Fahrzeugentwick-
lung unterstützt mit Teamcenter
26.05.2011 Aschaffenburg PAM-CRASH Forum 2011 Pinner (VW), Schroeder (ESI)
Titel: Einfluss der Fertigungsprozesskette im Karosseriebau auf das Crashverhal-
ten
28.-29.06. Berlin INPRO- Bohling / Pinner / Theilen
2011 Innovationsakademie (VW)
Titel: Digitale Planung im Automobilbau - Einsatzfeld für innovative Simulations-
technik
Herbstaus- München Infoplaner Ausgabe Pinner (VW), Steinbeck-
gabe 2011 02/2011 (CADFEM Fir- Behrens (CADFEM)
menzeitschrift)
Titel: Der Prozess steht im Fokus – Fertigungsprozesse gemäß den Prozessket-
ten simulieren
Nov. 2011 Veröffentlich- Artikel zu VIPROF im Wirt- ARC Solutions
ung schaftsjournal
15.-16.11. München NAFEMS European Confe- Hoffmann / Brylla (ARC Solu-
2011 rence: Simulation Process tions), Awiszus / Bolick (VIF)
and Data Management
(SDM)
Titel: Durchgängige Prozessketten für CAE-Simulation in der Fahrzeugentwicklg.
unterstützt mit Teamcenter-Ergebnisse aus dem BMBF-Projekt VIPROF
22.11.2011 Fellbach Abschlussveranstaltung Vorträge aller VIPROF-
Industriearbeitskreis VIP- Partner zu den Projektergeb-
ROF nissen
14.-15.02. Bad Boll 32. EFB-Kolloquium Pinner / Stühmeyer / Heyn
2012 Blechverarbeitung (VW), Menke / Gotthold
(CADFEM)
Titel: Verbesserte Bauteilauslegung durch Prozesskettensimulation
20.11.2012 Baden-Baden SIMVEC - Berechnung, Volkswagen, CADFEM
(geplant) Simulation und Erprobung
im Fahrzeugbau
141

142. Zur Verbreitung der Projektergebnisse wurde ein VIPROF-Film erarbeitet, an dessen
Drehbuch alle Partner mitgewirkt haben. Neben dem Technologietransfer dient der
Film dem Aufzeigen der Kompetenzfelder der Partner und der Generierung von Kon-
takten und Aufträgen für Leistungen zur Prozesskettensimulation. Gleichwohl handelt
es sich weniger um einen Werbe-, sondern mehr um einen Informationsfilm. Der Film
wird auf der Projektseite www.projekt-viprof.de, auf den Internetseiten der Partner
und bei Veranstaltungen der Partner veröffentlicht.
Weiterhin wurde vom Projektpartner ARC Solutions ein Bildschirmfilm erstellt, der die
Nutzung der Prozesskette in TEAMCENTER als Workflow zeigt.
142