Abschlussbericht des Projekts Viprof

Gemeinsamer FuE-Abschlussbericht des Verbundprojekt es

„Durchgängige Virtualisierung der Entwicklung und P ro-

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

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.

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-

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]

6

KarosseriebauUmformprozesse Lackierung Montage

Aufbau Aggregate Fahrwerk …..

Crash

Steifigkeit

Crash

Steifigkeit

Betriebsfestigkeit

Aeroakustik

Betriebsfestigkeit

Aeroakustik

Aerodynamik

......

Aerodynamik

......

Simulationsmethoden Produktentwicklung

Produktlastenheft, Konstruktionsdaten, Stücklisten etc.

Entwicklungsdisziplinen

VirtuelleProduktentwicklung

VirtuelleProzessabsicherung

Umformsimulation Fügesimulation Lackiersimulation

Ergonomiebetrachtung Gießsimulation ......

Simulationsmethoden Prozessabsicherung





Simulationsmethoden Prozessabsicherung

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

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 (Software-Haus)

Koordination des Verbundprojektes, Integration der Lackier-trocknungssimulation VPS/DRY in die Prozesskettensimula-tion

ESI GmbH (Software-Haus)

Integration der Umform- und Fügesimulation in die Prozess-kettensimulation

ARC Solutions GmbH (Dienstleister)

Implementierung von Daten- und Variantenmanagement, Umsetzung des Workflow-Managements

VW AG (Anwender)

Erstellung Lastenheft, Erprobung und Validierung der Pro-zesskettensimulation

ITP Ostfalia HaW (F&E)

Umformsimulation, Mapping zwischen den Prozessen, Ab-gleich OneStep Solver zur inkrementellen Simulation, Er-probung

Professur Virtuelle Fertigungstechnik (VIF) der TU Chemnitz (F&E)

Entwicklung der Referenzprozesse und –modelle

Institut für Wirtschafts-informatik und Quantitative Methoden der TU Berlin (F&E)

Entwicklung Datenarchitektur, Datenmodellierung und -integration, Schnittstellenkonzeption, Datenmapping, Stan-dardisierung der Simulationsdaten

VDC Fellbach (Dienstleister)

Analyse bei den meist mittelständischen Mitgliederfirmen zur Bedarfslage hinsichtlich einer Prozesskettensimulation, Auf-bau Web-Präsenz, Aufbau eines Industriearbeitskreises „Vir-tualisierung“.

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.

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-

zessgrößen in der Prozesskette

IPT CADFEM, ESI,

VW

3 Aufbau Architektur für Daten- und Varian-

tenmanagement

TUB VIF, ARC, VW

4 Kopplung der Prozesssimulationen Um-

formen – Fügen – Lackieren

TUB Alle Partner

5 Implementierung Daten- und Varianten-

management als VIPROF-Module

ARC CADFEM, ESI,

VW, VIF, TUB

6 Bewertung der Ergebnisgüte VW CADFEM, ESI,

IPT

7 Definition von Referenzprozessen und

-modellen für durchgängige Prozesskette

VIF ARC, VW, IPT,

TUB, VDC

8 Erweiterung der Prozesskette mit komp-

lexen Modellen

CADFEM ESI, ARC, IPT

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)

10

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.

3. Aufbau Daten-

architektur

1. Analyse des Ist-Zustandes

2. Untersuchung / Bewertung

Prozessgrößen

4. Kopplung der Prozess-

simulationen

5.Implementierung VIPROF-Module

6. Bewertung Ergebnisgüte

7. Definition Referenzpro-

zesse und -modelle

8. Erweiterung mit komplexen

Modellen

9. Test und Vali-dierung

10. Entwicklung VI-PROF-Modulcockpit

11. Ver-breitung der Er-geb-nisse

12. Projektmanagement

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.

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,

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-

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

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.

16

Software/Format Eigenschaften

FormingSuite/

*.key Sysweld/

*.asc PAMSTAMP/

*.M01 PAMCRASH/

*.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

Gauss-Punkten

Nein Ja Ja Ja

Abhängig von Integ-

rationspunkten

Nein Nein Nein Nein

Bezug Knoten Knoten Element Element

Spannungen Abhängig von

Gauss-Punkten Ja Ja Ja Ja


rationspunkten Ja Nein Ja Ja

Bezug Element Knoten Element Element

Dehnungen Abhängig von

Gauss-Punkten Nein Ja Nein Nein


rationspunkten Nein Nein Nein Nein


Plastische

Vergleichs-

dehnung

Abhängig von

Gauss-Punkten Ja Ja Ja Ja


rationspunkten Ja Nein Ja Ja


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-

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

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-

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:

%1000

0 ⋅−

=s

ssFrel

mit: s: Blechdicke nach dem Mapping

s0: Blechdicke vor dem Mapping

20

P1P2

P3

P4P5

P6P7

P9

P8

P10

P13P14P15

P16P17

P20

P18P11P12 P19+

++

++

++++

++++

+++

++

++

P1P2

P3

P4P5

P6P7

P9

P8

P10

P13P14P15

P16P17

P20

P18P11P12 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.

0

2

4

6

8

10

12

14

16

18

20

rel. Fehler Umformen inkrementell

-> Fügenetz

rel. Fehler Umformen invers

-> Fügenetz

rel. Fehler Umformen inkrementell

-> Crashnetz

rel. Fehler Umformen invers

-> Crashnetz

Anz

ahl M

essp

unkt

e

≥ 10%

5 - 10%

≤ 5%

Abbildung 14: Relativer Fehler beim Mapping der Blechdickenverteilung

auf Füge- und Crashnetz

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.

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

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)

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.

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) Schottteil B-Säule

Verstärkung Wagenheberaufnahme

Schottteil Schweller

B-Säule innen

Verstärkung Stegblech Schweller

Verstärkung B-Säule innen

Sitzquerträger

Abbildung 20: Bauteilumfang

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

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

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

29

3.3 Teilprozesskette Umformen und Fügen (ESI)

3.3.1 Simulation der Bauteilerzeugung mittels Umfor men

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

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.

3. �� unterschiedlicher Beschnitt

1. und 2.

2. �� Aufsprung in der Zarge

1. �� Torsion am Kopf

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.

31

CAD Daten

PAM-AUTOSTAMP

Umformsimulation

PAM-AUTOSTAMP

Rückfederung

SYSWELD

Schweißsimulation

SYSWELD

Schweiß Verzug

SYSWELD

Schweißsimulation

SYSWELD

Schweiß Verzug

SYSWELD

Schweißsimulation

SYSWELD

Schweiß Verzug

MappingSysweldnetz

CAD A CAD A

CAD B

ohne Entlastung

entlastet

MappingSysweldnetz

PANEL SHOP

Netz umgeformt

MappingSysweldnetz

entlastet

SYSWELD

Spannen

a) b) c)

Netz entlastet

CAD A

Ro

ute

2

Ro

ute

1

Neu

vern

etzu

ng

CAD Ziehanlage

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-

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.

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).

34

Hauptbauteile

Zusatzbauteile

Säule B innen Verstärkung Säule B Verstärkung Stegblech innen Schweller innen

Verstärkung A-Säulenur als CAD-Dateneingefügt

jeweils in rot dargestellt

Schottteil Säule B Verstärkung Schottteil Schweller vornWagenheberaufnahme

Abbildung 27: Untersuchte Schweiß-Baugruppe

3.3.4 Sensitivität der Datenübergabe in Relation zu r 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

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.

36

Stamp

Weld

Crash

Abbildung 30: Einfluss der Netzausprägung auf die Übertragung der Vergleichs-

spannungen vom Tiefziehen zum Schweißen und zum Crash

37

Stamp

Weld

Crash

Abbildung 31: Verluste bei der Übertragung von Spannungstensoren

3.3.5 Simulation des Schweißverzugs mit dem Weld Pl anner

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.

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

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 Nebenbauteile0 WeldPlanner nur CAD nur CAD - -1a WeldPlanner PAM-STAMP 2G nur CAD x -1b WeldPlanner PAM-STAMP 2G nur CAD - x1c WeldPlanner PAM-STAMP 2G nur CAD x x2a WeldPlanner FTI FormingSuite nur CAD x -2b WeldPlanner FTI FormingSuite nur CAD - x2c WeldPlanner FTI FormingSuite nur CAD x x3a WeldPlanner PAM-STAMP 2G FTI FormingSuite x x3b WeldPlanner FTI FormingSuite FTI FormingSuite x x4 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.

40

Mit beiden Größen Nur Blechdicken Nur plastische Dehnung

Verschiebungen in y-Richtung

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.

Alle Bauteile invers simuliert

Verschiebungen in y-Richtung

Hauptbauteile inkrementell und Zusatzbauteile invers simuliert

Abbildung 35: Schweißverzüge der inkrementellen und inversen Simulation der Um-

formung im Vergleich

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)

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:Übertragen der Umformergebnisse (Spannungen, plastische Dehnungen, Blechdickenverteilung) ausdem Umformen auf ein entsprechendes Modell füreine Fügesimulation thermisch oder mechanisch

Route 1 Geometrisch passendes Mapping mitEigenspannungen im Modell

Route 2 Mappen des entlasteten Bauteilsmit geometrischer Abweichung

Route 3 Mappen des entlasteten Bauteils auf einkongruentes, dediziertes Netz zum Fügen.Im Fügen ist ggf. ein Spannvorgangerfoderlich

CAD-Bauteilgeometrie

Werkzeugentwurf

Umformsimulation

Simulation des FügensRückfederungsrechnung

Route 1

Route 2

NeuvernetzungRoute 3

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.

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.

Route 3

Min: 0,001Max: 0,596

Min: 0,003Max: 0,946

Min: 0,003Max: 0,932

Route 1 Route 2 Abbildung 38: Ergebnis der Neuvernetzung mittels Flächenrückführung

Verformung [mm] in Normalenrichtung unter RPS Spannbedingungen

3.4 Simulation der Lacktrocknung in der Prozesskett e (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.

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.

45

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.

Temperatur-

berechnung

in VPS/DRY

Mechanische Berech-

nung mit Temperatur-

randbedingungen

Vorgespannte

Modal-

analyse

„Mode Tracking“

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.

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.

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.

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-Hardenin g-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°C im Metallgefüge eine

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°C erreicht wird. Die Zugfestigkeit des Werkstof fes kann von einem Wert von

800 MPa im Mittel um 70 MPa erhöht werden. Die Erhöhung ist abhängig von der

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°C deutlich, wie aus Abbildung 45 a m Außenblech der B-Säule er-

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

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.

750

800

850

900

950

1000

1050

1100

0 0,2 0,4 0,6 0,8 1 1,2

Spannung (BH0)

Spannung (BH1)

Spannung (BH2)

Spannung (BH3)

Spannung (BH4)

Spannung (BH5)

Spannung (BH6)

Spannung (BH7)

Spannung (BH8)

Spannung (BH9)

Spannung (BH10)

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.

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 °C als

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.

Umformsimulation FügesimulationLacktrocknungs-

simulationCrashsimulation

XML-Konverter

Format_1 Fo rmat_2 Format_3

Mapping Mapping Mapping

XML XML XML Format_4

Abbildung 48: Ergebnisübertragung durch Mapping oder innerhalb eines XML-

basierten Datenträgernetzes

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.

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.

55

3.5 Abgleich der Simulationsprozesskette an Praxisb eispielen

(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.

56

Eingangsdaten Umformsimulation Fügesimulation Lacktrocknungs- simulation

Geometriedaten Bauteile (.igs) und Ziehanlagen (.igs)

Bauteile (.igs) Crashnetz, Schweiß-punktinformationen

Bauart/Abmessungen des Trockners

Prozessdaten Blechhalterhub

Blechhalterkraft

Reibwert und Reibwertverteilung

Sickenersatzkräfte

Blechdicke …

Position der Schweißpfade

Mechanische Randbedingungen

Typ Schweißpro-zess

Prozesszeiten …

Positionierung/ Maße der Düsen

Temperaturen (Ofen/Karosserie)

Vorschub-Geschwindigkeit …

Materialdaten E-Modul

Querkontraktion

Dichte

Anisotropiewerte

Fließkurve

…

E-Modul

Querkontraktion

Thermischer Aus-dehnungskoeff.

Fließkurve

…

E-Modul

Querkontraktion

Thermischer Ausdeh-nungskoeff.

Fließkurve

…

Tabelle 4: Katalog gewerkespezifischer Eingangsgrößen

3.5.2 Übertragung von Simulationsdaten mit XML-Konv erter

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.

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.

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.

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]

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]

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 Umformsi mulation 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.

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]

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-

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]

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]

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.

67

Abbildung 66: Bewertung der Prozesskettensimulation anhand von Crash-

Simulationen [PIN309]

3.5.4.1 Mapping von Umform- auf Crash-Simulation (V arianten 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).

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]

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-

formsimulation

ESI PAM-STAMP

Inverse Umformsimu-

lation

Forming Suite 8.1

Strukturverhalten: Max. Intrusion

Verbesserung um

4 mm

Verbesserung um

2 mm

Überlebensraum:

Verbesserung um

6 mm

Verbesserung um

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

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-Si mulation (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]

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

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 Lacktroc knungssimulation (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- au f 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,

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-Simul ation (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ßverzug s

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]

74

x-y

z

Y +0,5

Y -0,1Y +0,0

Y -0,2

Y +0,5

Abbildung 72: Messergebnisse des y-Verzuges an der B-Säule (in mm)

und Verdrehungsrichtung [PIN310]

xy

z

0,0

-0,1

xy

z

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]

a) b)

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]

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]

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.

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 Konte xt von Wie-derverwendbarkeit und Weiterverwendbarkeit (TU Berl in)

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.

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.

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

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-

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.

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

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.

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).

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).

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).

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-

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-Konve rters

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-

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.

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.

92

3.7 Entwicklung einer systemübergreifenden Datenabl age im PDM-System zur Realisierung einer durchgängigen Sim ulati-

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

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].

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.

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].

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-

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

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.

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

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

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.

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).

103

Abbildung 99: Verknüpfung von Simulationsprogrammen über ein PDM-System

Abbildung 100: Produktstruktur

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

105

Fortschritt im Entwicklungsprozess ist dadurch jederzeit von allen Prozessbeteiligten

einsehbar und nachvollziehbar.

3.7.4 Ableitung von Referenzprozessketten zur Daten ablage

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

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

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

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 mit tels 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-

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.

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.

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.

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-

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üg en – 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

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 Transpar enz 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

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

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).

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-

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.

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

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

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-

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).

123

Stand des Simulationsdatenhan d-

lings zu Beginn des Vorhabens

Stand des Simulationsdatenhand -

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

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 Simulationsprozes skette 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

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).

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

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).

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

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

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.

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-

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

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

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-

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 Database

RailRailRailRailRAILRAILRAILRAIL

ASSEMBLYASSEMBLYASSEMBLYASSEMBLY

RailRailRailRailRAILRAILRAILRAIL

ASSEMBLYASSEMBLYASSEMBLYASSEMBLY

VisualDSS web client

DecisionMaking Tool

Abbildung 131: Simulationsprozess- und Datenmanagement in VisualDSS

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.

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-

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.

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-

semeldungen z. B. im

Newsletter Kompetenz-

netze Deutschland

VDC Fellbach

16.-18.06.

2009

Titel:

Magdeburg Fachtagung Digitales En-

gineering, Fraunhofer Wis-

senschaftstage

Pinner (VW) et al.

Durchgängige Virtualisierung der Entwicklung und Produktion von Fahrzeu-

gen

16.-18.06.

2009

Titel:

Veröffentlich-

ung

12. IFF-Wissenschaftstage ARC Solutions

Projektstand und Ergebnisse zum VIPROF-Projekt

Herbstaus-

gabe 2009

Titel:

Veröffentlich-

ung

ProduktDatenJournal Nr. 2

/ 2009, S. 39 – 43,

ISBN/ISSN: 1436-0403

Awiszus, Bolick (VIF),

Brylla (ARC Solutions), Pin-

ner (VW), Schulz (TU Berlin)

Produktdatenmanagement in der Entwicklung und Produktion von Fahrzeu-

gen, Heft 2, S. 39 – 43, ISSN 1436-0403

19.11.2009

Titel:

Leipzig ANSYS Conference und

27. CADFEM Users´ Meet-

ing

Pinner (VW) et al.

Einsatz inverser Solver innerhalb der Prozesskettensimulation im Bereich

Karosseriebau

19.11.2009

Titel:

Leipzig CAE-Forum auf dem 27.

CADFEM Users´ Meeting

Kulp (VW)

Impulsvortrag: Integrierte Prozesskettensimulation bei der Karosseriehers-

tellung im Projekt VIPROF

140


19.11.2009

Titel:

Leipzig CAE-Forum auf dem 27.

CADFEM Users´ Meeting

Knick (CADFEM), Kulp (VW)

„Paint Drying Simulation as part of the Body-in-White Manufacturing

Processes in the VIPROF Project“

30.03.2010

Titel:

Darmstadt 16. JT-User Group Treffen,

Fraunhofer IGD

Pinner (VW)

Universelle Visualisierung von Simulations-Ergebnisdaten im JT-Format

Apr. 2010 Karlsruhe

(Ausstellung)

Karlsruher Arbeitsgesprä-

che

ARC Solutions, Ostfalia HaW

04.05.2010

Titel:

Fellbach Internationale Konferenz

„Neuere Entwicklungen in

der Blechumformung“

Awiszus, Bolick (VIF),

Leck (Ostfalia HaW), Brylla

(ARC Solutions), Pinner (VW)

Durchgängige Simulationsprozessketten in der Fahrzeugentwicklung

Tagungsband S. 65 – 84, ISBN 978-3-88355-378-8

08.06.2010 Fellbach Kick-off Veranstaltung In-

dustriearbeitskreis VIP-

ROF

Vorträge zu den Teilvorhaben

aller VIPROF-Partner

22.-23.06.

2010

Titel:

Bonn 1st Conference on Multi-

physics Simulation

Leck/Rambke (Ostfalia HaW),

Awiszus (VIF), Pinner (VW),

Knick (CADFEM)

End-to-end Virtualization of the Development and Production of Vehicles

02.07.2010 Bekannt-

machung

Informationsnetzwerk

XING

ESI

16.-17.11.

2010

Titel:

Baden-Baden SIMVEC (15. Internat. VDI-

Konferenz für Simulation

und Berechnung)

Pinner (VW), Awiszus (VIF),

Vogel (ESI), Leck und Ramb-

ke (Ostfalia HaW)

Prozesskettensimulation im Karosseriebau am Beispiel der Kopplung von

Umform- und Fügesimulation

16.-17.11.

2010

Titel:

Baden-Baden SIMVEC (15. Internat. VDI-

Konferenz für Simulation

und Berechnung)

Knick / Steinbeck-Behrens

(CADFEM), Kulp / Pinner

(VW)

Integration der Lackiersimulation in den Herstellungsprozess von Karosse-

rien im Forschungsprojekt VIPROF

10.02.2011

Titel:

Braunschweig Fachkonferenz „Berech-

nung im Produktprozess“

Pinner (VW)

Visualisierung von CAE-Ergebnisdaten im JT-Format

141


16.-17.03.

2011

Titel:

Landshut PAM-STAMP Forum 2011 Pinner (VW), Schroeder (ESI)

Simulation der Prozesskette im Karosseriebau mittels Kopplung der Ferti-

gungsverfahren

17.05.2011

Titel:

Seeheim Siemens PLM Connection

Deutschland

Brylla (ARC Solutions), Pin-

ner (VW)

Durchgängige Prozessketten für CAE-Simulation in der Fahrzeugentwick-

lung unterstützt mit Teamcenter

26.05.2011

Titel:

Aschaffenburg PAM-CRASH Forum 2011 Pinner (VW), Schroeder (ESI)

Einfluss der Fertigungsprozesskette im Karosseriebau auf das Crashverhal-

ten

28.-29.06.

2011

Titel:

Berlin INPRO-

Innovationsakademie

Bohling / Pinner / Theilen

(VW)

Digitale Planung im Automobilbau - Einsatzfeld für innovative Simulations-

technik

Herbstaus-

gabe 2011

Titel:

München Infoplaner Ausgabe

02/2011 (CADFEM Fir-

menzeitschrift)

Pinner (VW), Steinbeck-

Behrens (CADFEM)

Der Prozess steht im Fokus – Fertigungsprozesse gemäß den Prozessket-

ten simulieren

Nov. 2011 Veröffentlich-

ung

Artikel zu VIPROF im Wirt-

schaftsjournal

ARC Solutions

15.-16.11.

2011

Titel:

München NAFEMS European Confe-

rence: Simulation Process

and Data Management

(SDM)

Hoffmann / Brylla (ARC Solu-

tions), Awiszus / Bolick (VIF)

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 Industriearbeitskreis VIP-ROF

Vorträge aller VIPROF-Partner zu den Projektergeb-nissen

14.-15.02.

2012

Titel:

Bad Boll 32. EFB-Kolloquium

Blechverarbeitung

Pinner / Stühmeyer / Heyn

(VW), Menke / Gotthold

(CADFEM)

Verbesserte Bauteilauslegung durch Prozesskettensimulation

20.11.2012 (geplant)

Baden-Baden SIMVEC - Berechnung, Simulation und Erprobung im Fahrzeugbau

Volkswagen, CADFEM

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.

Technology

Abschlussbericht des Projekts Viprof