Abschlussbericht des Projekts Viprof

Gemeinsamer FuE-Abschlussbericht des Verbundprojektes „Durchgängige Virtualisierung der Entwicklung und Pro- duktion von Fahrzeugen (VIPROF)“ Förderkennzeichen: 02PC1090 bis 1097Autoren: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 (TUChemnitz)Marcel Schulz (TU Berlin)Dr.-Ing. Christoph Runde, Achim Czaykowska (VDC Fellbach)Dr.-Ing. Klaus Mager (Ingenieurbüro Mager, Unternehmensberatung) Januar 2012

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

3.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) ........................................................ 1174 Zusammenfassung der Ergebnisse ................................................................. 121 4.1 Bewertung der Ergebnisse ......................................................................... 121 4.2 Darstellung der durchgängigen Simulationsprozesskette VIPROF anhand eines Anwendungsbeispiels .......................................................... 1245 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 .......................................... 1376 Öffentlichkeitsarbeit ......................................................................................... 139Das 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 vonmorgen“ gefördert und unter der Projektträgerschaft des Karlsruher Instituts fürTechnologie (KIT) durchgeführt. Die Verantwortung für den Inhalt dieser Veröffentli-chung liegt bei den Autoren. 3

1 Einführung, Motivation und ZielstellungWie 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 anVerbrauchseffizienz und CO2-Reduzierung werden zukünftig verstärkt zu weiterenFahrzeugvarianten mit alternativen Antrieben sowie Leichtbaukarosserien führen. DieAbbildung 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 Plattformstrategieverfolgte, 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 reinenModulstrategie, z. B. Modularer Diesel Baukasten oder modularer Vorderwagen etc.,überzugehen. Die Module bilden dabei einen Baukasten mit kombinierbaren Elemen-ten. Die Standardisierung für Produkt und Prozess sichert die konzernweite Kompati- 4

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 beherrschenzu können, müssen vor allem Techniken und Strategien zum Produktdatenmanage-ment weiterentwickelt werden. Weiterhin muss im verstärkten Maße auf eine virtuelleProduktabsicherung 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 disziplinorientierteArbeitsweise und eine fehlende Transparenz erfolgt die belastbare Validierung derHerstellbarkeit 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) immernoch nicht detailliert erfasst und während der Produktentwicklung berücksichtigt.[PIN109] 5

Aufbau Aggregate Fahrwerk ….. Entwicklungsdisziplinen Crash Betriebsfestigkeit Aerodynamik VirtuelleProduktentwicklung Steifigkeit Aeroakustik ...... Simulationsmethoden Produktentwicklung Produktlastenheft, Konstruktionsdaten, Stücklisten etc. Umformsimulation Fügesimulation Lackiersimulation VirtuelleProzessabsicherung Ergonomiebetrachtung Gießsimulation ...... Simulationsmethoden Prozessabsicherung Umformprozesse Karosseriebau Lackierung Montage Abbildung 3: Virtuelle Produktentwicklung und Prozessabsicherung [PIN109]In den letzten Jahren hat neben der Automatisierung in vielen Bereichen der Produk-tionstechnik das Engineering mit CAE-Werkzeugen (Computer Aided Engineering)Einzug gehalten. Für die Entwicklung und Planung von Produkten, Maschinen undAnlagen 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 vielenBereichen 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 einenSeite 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 – verbindenmaximal zwei Glieder der Simulationskette, wie z. B. der SCAI-Mapper zwischen Um-form- und Crash-Simulation. Automatische Verknüpfungen dieser Werkzeuge, diezumeist von unterschiedlichen Herstellern stammen, gibt es kaum. Strategien zurDatenhaltung im Sinne des Produktdatenmanagements befinden sich noch im For-schungsstadium. In der Folge können bisher Änderungen, die sich in einem Bereich 6

ergeben, nur mit hohem Aufwand in anderen Bereichen berücksichtigt werden. Daprozessübergreifende Werkzeuge fehlen, können Fehler in der Produktentwicklungnach 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 wurdeauf die durchgängige Verknüpfung der Simulationen des Umformens, Fügens undLackierens gelegt. Die Auswirkungen der Berücksichtigung der Fertigungshistorie aufdie Produkteigenschaften sollten in der Crash-Simulation bewertet werden.Am Projekt haben die folgenden Partner teilgenommen:Partner / Profil Beitrag im ProjektCADFEM GmbH Koordination des Verbundprojektes, Integration der Lackier-(Software-Haus) trocknungssimulation VPS/DRY in die Prozesskettensimula- tionESI GmbH Integration der Umform- und Fügesimulation in die Prozess-(Software-Haus) kettensimulationARC Solutions GmbH Implementierung von Daten- und Variantenmanagement,(Dienstleister) Umsetzung des Workflow-ManagementsVW AG Erstellung Lastenheft, Erprobung und Validierung der Pro-(Anwender) zesskettensimulationITP Ostfalia HaW Umformsimulation, Mapping zwischen den Prozessen, Ab-(F&E) gleich OneStep Solver zur inkrementellen Simulation, Er- probungProfessur Virtuelle Entwicklung der Referenzprozesse und –modelleFertigungstechnik(VIF) der TU Chemnitz(F&E)Institut für Wirtschafts- Entwicklung Datenarchitektur, Datenmodellierung und -informatik und integration, Schnittstellenkonzeption, Datenmapping, Stan-Quantitative Methoden dardisierung der Simulationsdatender TU Berlin (F&E)VDC Fellbach Analyse bei den meist mittelständischen Mitgliederfirmen zur(Dienstleister) Bedarfslage hinsichtlich einer Prozesskettensimulation, Auf- bau Web-Präsenz, Aufbau eines Industriearbeitskreises „Vir- tualisierung“. 7

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

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

1. Analyse des 12. ProjektmanagementIst-Zustandes2. Untersuchung / Bewertung Prozessgrößen 3. Aufbau 4. Kopplung der Daten- Prozess- architektur simulationen 5.Implementierung 6. Bewertung VIPROF-Module Ergebnisgüte 8. Erweiterung mit komplexen 7. Definition Modellen 11. Ver- Referenzpro- breitung zesse und 9. Test und Vali- der Er- -modelle dierung gebnisse 10. Entwicklung VI- PROF-Modulcockpit Abbildung 4: Pert-Diagramm des Arbeitsplanes (Daten – Prozesse)Entsprechend der Einteilung „Daten“ und „Prozesse“ wurden zu Beginn des Projek-tes die Arbeitsgruppe Daten (VW, ARC, VIF und TUB), die eine Bestandsaufnahmedes PDM-Systems durchführte, und die Arbeitsgruppe Mapping (CADFEM, ESI, VWund 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 demFraunhofer SCAI-Institut, das sich bereit erklärte, projektspezifische Anpassungenam SCAIMapper vorzunehmen.1 Mit dem SCAIMapper können durch Modellinterpolation die Umform- und Crash-Simulation gekop-pelt werden. Diese Software wurde vom Fraunhofer SCAI-Institut und dem ISD der Universität Stutt-gart entwickelt. 10

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 vonVW erhoben. Den Partnern wurden die CAD-Daten und Prozessbeschreibungen fürdie Musterbauteile zur Verfügung gestellt. Abbildung 5: Musterbauteile des VW Touran als Gegenstand der ProzesskettensimulationDie Musterbauteile stammten vom Serienfahrzeug VW Touran GP. Die Teileauswahlsollte eine Crash-relevante Baugruppe, jedoch keine warm umgeformten Bauteilebeinhalten. Die Auswahl fiel auf die Baugruppe B-Säule mit Schwellerverstärkung, danur dort Laserschweißverfahren eingesetzt werden. Der Sitzquerträger ist für dieCrash-Simulation relevant. Um den Schweißverzug zu analysieren, besteht bei VWfü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 schonin Serie befindlichen Fahrzeug keine Schwachstellen auf, die durch die Prozessket-tensimulation hätten aufgedeckt werden können, wie es bei Neukonstruktionen derFall wäre, da alle Teile auskonstruiert und getestet waren. 11

3 Lösungsansätze, durchgeführte Arbeiten und Teiler- gebnisse3.1 Überblick ProzesskettensimulationIm Rahmen der virtuellen Absicherung werden heute fertigungstechnische Einflüsseauf 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 derdurchlaufenen 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önnensich negativ auf die erforderlichen Produkteigenschaften, wie z. B. Form- und Maß-haltigkeit oder das Crash-Verhalten, auswirken. Wechselwirkungen innerhalb derProzesskette Presswerk – Karosseriebau – Lackierung sind beispielsweise:• Blechdicken- und Spannungsverteilung im Bauteil nach dem Tiefziehen,• Entstehung von lokalen Entfestigungen und Spannungen in den Bauteilen durch thermische Fügeverfahren, 12

• 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 bedeutenderwird 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 dieeinzelnen 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 Kapitel3.6 ausführlich dargestellt. Der Bereich der Transformation wird im Abschnitt 3.2.2nä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 starkbeeinflussen. Dazu wird eine Sensitivitätsanalyse (Abschnitt 3.2.3) durchgeführt. An-hand der Ergebnisse kann dann entschieden werden, für welche Ergebnisdaten dieDatenübertragung wirtschaftlich ist.3.2.1 Simulationsprogramme in der ProzessketteIn 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 inkrementellenUmformsimulation aufgrund der notwendigen Methodenplanung und der Entwicklungder Ziehanlage einen hohen Zeitaufwand erfordert, wird diese in der Praxis erstdurchgeführt, wenn der Konstruktionsstand der Karosseriebauteile einen entspre- 13

chenden Reifegrad erreicht hat. Dies hat zur Folge, dass die Simulationsdaten derUmformsimulation 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 dieDurchführung werden nur die CAD-Geometrie und die Werkstoffdaten benötigt. Dergegenüber der inkrementellen Umformsimulation fehlende Werkzeugkontakt führtz. B. zur Einschränkung der Faltenvorhersagbarkeit.Für die Fügesimulation wurde eine Berechnung des Schweißverzugs mit dem WeldPlanner durchgeführt. Die Lacktrocknung wurde mit VPS/DRY und der Crash mitPAM-CRASH simuliert.3.2.2 MappingDie Analyse der Import und Export-Schnittstellen dieser Software zeigten, dass dieerste Herausforderung bei der Übertragung von Daten zwischen den Simulations-programmen unterschiedlicher Hersteller unterschiedliche Schnittstellen sind. DieseSchnittstellen unterscheiden sich in den kompatiblen Formaten, so dass ein Einlesender Ergebnisdaten in die nachfolgende Simulationssoftware in der Regel nicht ohneZwischenschritte möglich ist. Zusätzlich unterscheiden sich auch die FEM-Netze unddie verwendeten Bezugskoordinatensysteme. Abbildung 7: Vernetzung Umformsimulation; Links: Dreieckelemente; rechts: ViereckelementeDie auffälligsten Unterschiede zwischen den FEM-Netzen sind - wie in Abbildung 7zu erkennen ist - die Elementform und die Elementgröße. Die Elemente aller in der 14

Prozesskette betrachteten Simulationen sind Schalenelemente, so dass eine Be-trachtung der Datenübertragung zwischen Schalen- und Volumenelementen nichtstattgefunden 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 Radienfeiner 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 dieSchweißnähte liegen, feiner vernetzt, während die anderen Bauteilbereiche grobvernetzt 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-NetzeZusätzlich zu diesen auf den ersten Blick sichtbaren Unterschieden gibt es weitere inder 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 dieskalaren und tensoriellen Größen pro Integrationspunkt oder pro Knoten abgelegt.Was bedeutet, dass selbst bei identischen Netzen eine Interpolation der Daten vonden Knoten auf die Integrationspunkte oder andersherum erfolgen muss. Bei dentensoriellen Größen gibt es zusätzlich noch Unterschiede in den Bezugskoordinaten-systemen. Einige Formate speichern die Größen im globalen System, andere jeweilsim Elementkoordinatensystem. Dadurch ist für die tensoriellen Größen eine Koordi-natentransformation der Tensoren notwendig. 15

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

koordinatensystem, weil die Simulation auf der CAD-Geometrie aufbaut und dasBauteil im CAD-System in der Gesamtkarosserie eingebaut ist. Die inkrementelleUmformsimulation dagegen verwendet ein Bauteilkoordinatensystem und ein Zieh-koordinatensystem. Die Lage der Bauteile zueinander nach den Umformsimulationenist in Abbildung 10 dargestellt.Das Fügenetz liegt - wie das Netz der inversen Umformsimulation - in Einbaulagevor, weil es auf der CAD-Geometrie aufbauend erstellt wurde. Auch Lacktrocknungs-und Crashsimulation bauen beide auf der Gesamtkarosserie auf, so dass die Netzeebenfalls 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 dasgesamte Netz muss also für alle Mapping-Prozesse erfolgen, in denen Daten derinkrementellen Umformsimulation übertragen werden sollen.Allgemein müssen also für eine Übertragung der Ergebnisgrößen zum einen Koordi-natentransformationen zwischen den unterschiedlichen Koordinatensystemen undzum 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- undSoftware-Recherche durchgeführt. Eine Untersuchung unterschiedlicher Methodenzur Übertragung von Geschichtsvariablen aus der Umform- in die Crashsimulation istzum 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ängigesund damit universelles Werkzeug herausgestellt. Der SCAIMapper hat die Möglich-keit zur automatisierten Lageausrichtung der Bauteile (im Folgenden als „Ein-schwimmen“ bezeichnet), kann die Dateiformate unterschiedlicher Software-Hersteller einlesen und die Interpolation der Daten auf das Zielnetz durchführen 17

[Oeck10, Peetz03, Scho07, Wallm04, Shep68, Wolf09]. Für das Projekt stellte derSCAIMapper alle benötigten Mapping-Funktionen zur Verfügung, so dass er in dieProzesskette als Mappingtool eingebunden wurde.Das Mapping von der Umform- in die Crashsimulation war mit dem SCAIMapperproblemlos 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 vonFormat-Inkompatibilitäten zunächst problematischer. Diese konnten durch Anpas-sungen des SCAIMappers durch den Entwickler beim Fraunhofer SCAI behobenwerden. 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-NetzDie Bewertung der Mapping-Genauigkeit erfolgte zum einen mit den im SCAIMapperverfügbaren Funktionen zur Validierung und zum anderen manuell mit Messpunktenauf 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, zumeinen die Genauigkeitsverluste durch die Interpolation zwischen den Netzen und zumanderen die schlechtere Auflösung des Zielnetzes. Bei der gezeigten B-Säule in Ab-bildung 11 ist zu erkennen, dass Extremwerte aus dem Umformprozess bei der Über- 18

tragung auf das grobe Crashnetz geglättet werden. Es ist daher wichtig, dass bei derWeiterverwendung 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 derMapping-Datei weiter gegeben werden. Abbildung 12: Abweichung der Blechdicke nach dem Mapping der Umformergebnisse (inkrementell) auf das Crash-NetzDie Datenübertragung der skalaren Größen Blechdicke und plastische Dehnungfunktioniert für alle Mappingprozesse in der untersuchten Kette problemlos. DieWerte werden mit Hilfe von Interpolationsalgorithmen [Oeck10, Shep68] auf dasneue Netz übertragen. Die Bewertung der Qualität wurde zunächst mit Hilfe derValidierungsfunktion des SCAIMappers durchgeführt. In Abbildung 12 ist dieDifferenz zwischen Original Blechdickenverteilungen und der gemapptenBlechdickenverteilung auf dem Bauteil aufgetragen. Die Abweichungen sind kleinerals 40 µm. Nur in Bereichen, in denen die Geometrie nicht übereinstimmt – z. B.aufgrund von in der Umformsimulation nicht berechneten Ausschnitten - liegen dieAbweichungen darüber.Die zweite Methode zur Bewertung der Mapping-Qualität besteht in einem Vergleichder Blechdicken an 20 definierten Messpunkten vor und nach dem Mapping-Prozess.Die Messpunkte werden vorrangig in Bauteilbereichen mit großen Veränderungender Blechdicke sowie Netzbereichen mit sehr grober und sehr feiner Diskretisierungplatziert. In Abbildung 13 ist die Lage der Messpunkte auf dem Bauteil dargestellt.An den betrachteten Messpunkten werden die Werte jeweils über die umgebendenElemente gemittelt, um die Empfindlichkeit des Verfahrens gegen singuläre Spitzenmöglichst gering zu halten. In jedem Punkt wird der auf die Ausgangsblechdicke vordem Mappingprozess bezogene relative Fehler berechnet: s − s0 mit: s: Blechdicke nach dem Mapping Frel = ⋅ 100% s0 s0: Blechdicke vor dem Mapping 19

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

Die Abweichung für 84% der Messungen an diesem Bauteil liegt insgesamt unter5%. Die Mapping-Qualität kann damit für die skalare Ergebnisgröße Blechdicke alsgut 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 dieMapping-Genauigkeit als befriedigend oder mangelhaft eingestuft. Diese Punkteliegen alle in Bauteilbereichen mit starker Ausdünnung bzw. Aufdickung oder engenRadien. Große Gradienten in der Blechdicke bei feiner Vernetzung im Ausgangsnetzund deutlich größere Elementkantenlängen im Zielnetz im gleichen Bereich führendurch die in diesen Bereichen dann notwendige Interpolation der Blechdickenwertezu größeren Abweichungen in den Mapping-Ergebnissen. Dies zeigt sich auch imVergleich der Mapping-Ergebnisse für die betrachteten FEM-Netze. Je größer dieUnterschiede in den verwendeten Netzen sind, desto größer sind auch dieAbweichungen.Abbildung 15: Plastische Dehnungen nach der inkrementellen Umformsimulation (unten) und nach dem Mapping auf das Crash-Netz (oben)In der Prozesskette werden zusätzlich zu der Blechdickenverteilung auch dieplastischen Dehnungswerte als Maß für die Werkstoffverfestigung übertragen. BeimMapping der plastischen Dehnungen müssen in Abhängigkeit von der Anzahl derIntegrationspunkte ü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 dieWerte qualitativ richtig übertragen werden. In den blau dargestellten Bereichen sinddie plastischen Dehnungen sehr gering. 21

Abbildung 16: Absolute Abweichung der plastischen Dehnung nach dem Mapping der Umformergebnisse (inkrementell) auf das Crash-NetzIn Abbildung 16 ist die Differenz zwischen den plastischen Dehnungen nach demUmformprozess und den plastischen Dehnungen auf dem Crash-Bauteil nach demMapping-Prozess aufgetragen. Die Abweichungen liegen in den meistenBauteilbereichen mit signifikanten plastischen Dehnungen bei unter 25%.In denBauteilbereichen mit geringen plastischen Dehnungen (blaue Bereiche in Abbildung15), führen bereits geringe Interpolationsfehler zu großen Abweichungen. In diesenBereichen ist aufgrund der geringen plastischen Dehnung kein großer Einfluss aufdie nachfolgenden Simulationsprozesse zu erwarten. Der Einfluss auf dienachfolgenden 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 MappingDie Datenübertragung von tensoriellen Größen ist dagegen schwieriger, da diesoren formatabhängig in unterschiedlichen Koordinatensystemen gespeichert wer-den. Dadurch ist ein Vergleich der Tensoren nicht direkt möglich. In der grafischenDarstellung werden daher in der Regel Vergleichswerte gezeigt. In Abbildung 17 istzu erkennen, dass die Abweichungen des dargestellten skalaren Vergleichswertes 22

nach dem Mapping deutlich größer sind als bei den skalaren Größen Blechdicke undplastische Dehnung. Abbildung 18 zeigt die Differenz der Vergleichsspannungenzwischen 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 Mappinga) 1.Hauptspannungb) 2.Hauptspannung Abbildung 19: 1. und 2. Hauptspannung jeweils nach der Umformsimulation (oben) und nach dem Mapping auf das Crash-Netz (unten) 23

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. DieAbweichungen 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 dergemappten 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 undwie empfindlich die Simulationen auf Abweichungen reagieren.3.2.3 SensitivitätsanalyseDas Ziel der Sensitivitätsanalysen ist es zu ermitteln, welche Ergebnisgrößen einenso großen Einfluss haben, dass sie übertragen werden sollten um eine Genauig-keitssteigerung zu erreichen. Dazu werden sowohl die Umformergebnisse aus derinkrementellen 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 inkrementellenUmformsimulation (PAMSTAMP 2G) berechnet (Abbildung 20 b), als auch mit derinversen Simulation (FormingSuite) (Abbildung 20 c). Die kleinen Bauteile (Abbildung20 c) Schottteil B-Säule, Verstärkung Wagenheberaufnahme und Schottteil Schwellervorn wurden nur mit der inversen Umformsimulation berechnet. Diese Ergebnissewurden in unterschiedlichen Kombinationen in die nachfolgenden Simulationen über-tragen, um zu prüfen ob dadurch die Simulationsergebnisse beeinflusst werden kön-nen. Einen Überblick über die untersuchten Varianten gibt Abbildung 66. 24

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

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 UmformsimulationEin 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 eingesetztenWeldplanner nicht weiter verwendet werden, so dass eine Übertragung hier nichtsinnvoll 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 UmformsimulationDie Ergebnisse der Fügesimulation werden für die mit unterschiedlichen Eingangsda-ten durchgeführten Berechnungen jeweils in eine Mapping-Datei geschrieben und fürdie nachfolgenden Simulationen zur Verfügung gestellt.In der Lacktrocknungssimulation wurden Berechnungen mit den Ergebnissen ausUmform- und/oder Fügesimulationen durchgeführt. Bei der Berücksichtigung von 26

Blechdicken, Spannungen und plastischen Dehnungen aus dem Umformprozesskonnten an dieser Baugruppe jedoch keine Auswirkungen auf das Beulverhalten derBaugruppe festgestellt werden. Da die betrachtete Baugruppe aus einem Fahrzeugstammt, 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.4zu 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 mitder Berücksichtigung von Blechdicken und plastischen Dehnungen aus Umform- undFügesimulation die Art des Bauteilversagens in der Simulation näher an der Realitätliegt, 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 Baugruppekeine Verbesserung. Die Ergebnisse der Crash-Simulation werden wiederum durchdie Übertragung der Blechdicken und plastischen Dehnungen positiv beeinflusst. Zu-sätzlich kann es sinnvoll sein den aus der Lacktrocknung resultierenden Bake-Hardening-Effekt in die Crashsimulation zu übertragen.Literatur[Zöll04] Zöller, A.; Frank, T. & Haufe, A.: Berücksichtigung von Blechumformer- gebnissen in der Crashberechnung, 3. LS-DYNA Anwenderforum, 2004, B-I-1bis B-I-12[Cafo03] Cafolla, J.; Hall, R. W.; Norman, D. P. & Mc Gregor, I. J.: Forming to Crash Simulation in Full Vehicle Models, 4th European LS-Dyna Users Conference, 2003, 4, E-II-17 - E-II-26 27

[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.; DOttavio, M.; Kröplin, B.; Wolf, K.; Post, P.; Peetz, J.-V. & Scholl, U.: Kriterien zur Bewertung des Map- pings von Umform- auf Crashsimulation, 3. LS-DYNA Anwenderforum, DYNAmore GmbH, 2004, D - I - 1 bis D - I - 11[Shep68] Shepard, D.: A two-dimensional interpolation function for irregularly- spaced data, Proceedings of the 1968 23rd ACM national conference, 1968, 517 - 524[Wolf09] Wolf, K.; Schilling, R.; Lüthjens, J.; Hunkel, M.; Wallmersperger, T.; Jankowski, U.; Sihling, D.; Wiegand, K.; Zöllner, A. & Heuse, M.: Coupled FEM Calculations - A CAE Tool to Improve Crash-Relevant Automotive Body Components by Local Hardening, 7th European LS-DYNA Conference, DYNAmore GmbH, 2009 28

3.3 Teilprozesskette Umformen und Fügen (ESI)3.3.1 Simulation der Bauteilerzeugung mittels UmformenDie Simulation der Herstellung von Bauteilen aus Feinblech mittels Tiefziehen darfals etablierter Stand der Technik angesehen werden. In diesem Projekt wurde dazudas 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 jedochweniger die Herstellbarkeit des Bauteils, sondern die Darstellung der durchgängigenProzesskette und Betrachtung der auftretenden Sensitivitäten.Zur Überprüfung der Herstellbarkeit hat sich die Simulation der Hauptumformstufebewä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 sichheute schon in erster Näherung virtuell überprüfen lässt.Betrachtet man nicht mehr den einzelnen Herstellprozess, sondern die gesamteHerstellprozesskette, so stehen das virtuelle Bauteil und dessen Verbaubarkeit imFokus. Eine Übertragung der Bauteileigenschaften nur aus der Hauptumformstufeauf die CAD-Form des Bauteils ist machbar, führt jedoch in nicht beschriebenen Be-reichen zu biegeschlaffen Zonen. Diese entsprechen dann dem Ausgangszustanddes Bleches ohne Änderung der Blechdicke und Kaltverfestigung. Im Projekt wurdendaher alle erforderlichen Nachformoperationen und Beschnitte mitgeführt, und somitvollständig umgeformte Bauteile erzeugt (Abbildung 22). Abkanten Verprägen Abbildung 22: Nachformoperationen zur Erstellung virtueller Bauteile 29

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 sogenanntekompensierte 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 zuumgehen, ist die Vernachlässigung des Aufsprungs, d.h. es wird das Ergebnis nachder letzten Umformstufe ohne Rückfederungsrechnung übertragen. Dies bedeutetein Verbleiben der Eigenspannungen im Bauteil, sofern diese übertragen werden. Dadie Entlastungsrechnung in der Regel nicht zu plastischen sondern nur elastischenEffekten führt, ist der Fehler bei einer Vernachlässigung der Spannungsseite, d.h.der Übertragung von Blechdicken und plastischen Dehnungen, eher als gering anzu-sehen. 1. und 2. 1. Torsion am Kopf 2. Aufsprung in der Zarge 3. unterschiedlicher Beschnitt Abbildung 23: Abbildungsfehler bei der Datenübertragung (Mapping)3.3.2 Methode der NeuvernetzungUm der Problematik des Aufsprungs zu begegnen wurde im Projekt die Methode derNeuvernetzung entwickelt. Neben der Übertragung der physikalischen Eigenschaftendes umgeformten Bauteils, wie Kaltverfestigung, Blechdickenänderung und optionalder Eigenspannungen, wird mittelfristig in der Betrachtung der Prozesskette auch dieBerücksichtigung der Gestaltänderung eine Rolle spielen. Gestaltänderung ist hierder Unterschied zwischen der CAD-Geometrie des Bauteils nach der Umformungund dem virtuellen Bauteil nach der Umformung. Abbildung 24 verdeutlicht die dreidenkbaren Varianten zur Übertragung der Herstellungshistorie, die abstrahiert aufbeliebige Kopplungen zwischen Gewerken übertragbar sind. 30

CAD Ziehanlage CAD Daten CAD A PAM- ohne Entlastung AUTOSTAMP Netz umgeformt Umformsimulation PAM- Netz entlastet AUTOSTAMP Rückfederung PANEL SHOP entlastet CAD B Mapping Mapping Mapping Sysweldnetz Sysweldnetz Sysweldnetz CAD A CAD A entlastet a) b) c) Neuvernetzung SYSWELD SYSWELD SYSWELD Route 1 Route 2 Schweißsimulation Schweißsimulation Schweißsimulation SYSWELD SYSWELD SYSWELD Spannen Schweiß Verzug Schweiß Verzug SYSWELD Schweiß Verzug Abbildung 24: Übertragung der Umformhistorie in die Schweißsimulation: a) und b) ohne Berücksichtigung der Gestaltänderung und c) mit GestaltänderungAls Referenzprozess lässt sich heute mit einer überschaubaren Methode die aktuelleBauteilgeometrie 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 werdenund damit können auch die Daten ohne Abbildungsfehler übertragen werden.Zur Darstellung der Methode wurde im Projekt das Programm PanelShop der FirmaiCapp 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 dieLage des aufgefederten Bauteils zu bringen (Abbildung 25). Diese aktualisierte Bau-teilgeometrie wird dann mit dem Eingangsnetz für Gewerk B neu vernetzt und an- 31

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 NeuvernetzungAlternativ wurde im Programm PAM-STAMP 2G ein Mapping von Netz B auf Netz Abetrachtet. 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 vertikalerProjektionsrichtung zu Verzerrungen (Abbildung 26). Eine Verbesserung würde hiereine 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 Netzein Fahrzeuglage befinden, kann der Aufsprung durch die Lagerbedingungen zu einerVerschiebung eines Bauteils führen. 32

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

jeweils in rot dargestellt Hauptbauteile Säule B innen Verstärkung Säule B Verstärkung Stegblech innen Schweller innen Verstärkung A-Säule nur als CAD-DatenZusatzbauteile eingefügt Schottteil Säule B Verstärkung Schottteil Schweller vorn Wagenheberaufnahme Abbildung 27: Untersuchte Schweiß-Baugruppe3.3.4 Sensitivität der Datenübergabe in Relation zur NetzfeinheitFü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 unterschiedlicheNetzausprägungen hinsichtlich der Feinheit und betrachteter Teilbereiche. Dies zeigtAbbildung 28 mit dem Netz aus der Umformung mit verfeinerten Radienbereichen,dem Schweißnetz mit Nahtbereichen und dem typischen 5 mm Crashnetz. Umformen Schweißen Crash Abbildung 28: Unterschiedliche Netzausprägungen 34

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 dasSchweiß- und Crashnetz gemappt.Für die betrachteten Bauteile ergab sich eine gute Übertragbarkeit der Blechdickenund mit kleineren Verlusten auch der plastischen Dehnungen (Abbildung 30). Einedeutliche Abnahme der oberen Spannungswerte und damit verbundene Nivellierungder 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 CrashIm Projekt wurden in erster Linie die Übertragung der Blechdicken und plastischenFormänderungen betrachtet. Die Eigenspannungen schienen nicht nur wegen derVerluste 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 Vorspannungensind. 35

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

Stamp Weld Crash Abbildung 31: Verluste bei der Übertragung von Spannungstensoren3.3.5 Simulation des Schweißverzugs mit dem Weld PlannerMit dem Programm Weld Planner wurde das Fügen der Baugruppe „Seiten-wandrahmen vorn“ hinsichtlich des auftretenden Verzuges simuliert. Abbildung 32verdeutlicht die Lage der Nähte und die beiden eingesetzten Schweißverfahren. AlsLagerbedingung 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 imCAD festgelegt. Die virtuelle Schweißung beschränkt sich beim Weld Planner auf dieEinbringung der Prozesswärme an den jeweiligen Fügestellen und in der vom An-wender vorgegebenen Schweißreihenfolge. Sie gibt wesentliche Hinweise zur Opti-mierung der Schweißnahtlage und Reihenfolge. 37

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

zum Vergleich noch der Schweißverzug auf Basis der CAD-Daten ohne Fertigungs-historie einbezogen. Untersucht wurden die in Tabelle 3 aufgeführten Varianten. Variante Simulationtool Software Blechdicke plastische Dehnung Haupbauteile Nebenbauteile 0 WeldPlanner nur CAD nur CAD - - 1a WeldPlanner PAM-STAMP 2G nur CAD x - 1b WeldPlanner PAM-STAMP 2G nur CAD - x 1c WeldPlanner PAM-STAMP 2G nur CAD x x 2a WeldPlanner FTI FormingSuite nur CAD x - 2b WeldPlanner FTI FormingSuite nur CAD - x 2c WeldPlanner FTI FormingSuite nur CAD x x 3a WeldPlanner PAM-STAMP 2G FTI FormingSuite x x 3b WeldPlanner FTI FormingSuite FTI FormingSuite x x 4 WeldPlanner PAM-STAMP 2G nur CAD x x Neuvernetzung Tabelle 3: Varianten des Mappings der Herstellungshistorie aus der UmformungIm Folgenden werden wesentliche Ergebnisse beispielhaft aufgezeigt. Der Vergleichdes Übertragens einzelner Ergebnisgrößen, wie dem Blechdickenverlauf und derplastischen Dehnung, ergab, dass die alleinige Übertragung der plastischen Deh-nungen nicht sinnvoll ist. Während die alleinige Übertragung der Blechdicke für einegute Ergebnisübereinstimmung mit den Messungen hinreichend sein kann. DiesesPhänomen lässt sich mit dem dominanten Einfluss der Blechdicke auf die Steifigkeitdes 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 dieAbbildung 34. 39

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

Da der betrachtete Schweiß-Zusammenbau einem Serienstand entspricht, ist derauftretende 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ürdie richtige Vorhersage des Schweißverzugs wurde mit der Variante 0 (Tabelle 3)betrachtet. Eine Gegenüberstellung der Messergebnisse mit der Simulation desSchweiß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übervon der Variante mit Übernahme der Blechdicken und plastischen Formänderungenfü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) undUmformhistorie (rechts); Verschiebungen in Y-Richtung (normal zur Ansichtsrichtung) 41

3.3.7 Schweißverzugssimulation mit der Methode der NeuvernetzungDie Notwendigkeit der Untersuchung des Einflusses der Auffederung am Ende derUmformung verdeutlicht Abbildung 37. Die in Tabelle 3 aufgeführte Variante derNeuvernetzung 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 dieErgebnisse des entlasteten Bauteils aus der Umformung darauf übertragen. Aufgabenstellung:CAD-Bauteilgeometrie Übertragen der Umformergebnisse (Spannungen, plastische Dehnungen, Blechdickenverteilung) aus dem Umformen auf ein entsprechendes Modell für eine Fügesimulation thermisch oder mechanisch Werkzeugentwurf Route 1 Geometrisch passendes Mapping mit Eigenspannungen im Modell Route 1 Umformsimulation Route 2 Mappen des entlasteten Bauteils mit geometrischer Abweichung Route 2Rückfederungsrechnung Simulation des Fügens Route 3 Mappen des entlasteten Bauteils auf ein Route 3 Neuvernetzung kongruentes, dediziertes Netz zum Fügen. Im Fügen ist ggf. ein Spannvorgang erfoderlich Abbildung 37: Mögliche Vorgehensweisen zum Übertragen der Herstellungshistorie in die nachfolgende FügesimulationDer Unterschied der in Abbildung 38 dargestellten Ergebnisse für Route 1 und 2 istrelativ 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ügenaufgrund der Lageabweichung gespannt werden muss, so ist der Verzug für diesesBauteil aus der Baugruppe sogar geringer ausfallend. Daraus ergibt sich die Frage,wie sich das Verhalten anderer Baugruppen mit dieser erweiterten Betrachtungswei-se darstellt. Da dies im Projekt nicht weiter geklärt werden konnte, soll an dieser Stel-le die Fortführung der Untersuchung der vorgeschlagenen Methode der Neuver-netzung im Rahmen anderer Förderprogramme angeregt werden. 42

Die darüber hinaus interessierende Fragestellung ist, ob die Route 1 bei zusätzlicherBerücksichtigung der Spannungstensoren eine hinreichende Lösung darstellen könn-te. Wäre so der Aufwand der Neuvernetzung vermeidbar? Nicht zuletzt ließe sichauch die Variante der direkten Projektion des Fügenetzes auf das aufgefederte Um-formnetz verbessern und damit eine einfachere Lösung schaffen. Min: 0,003 Min: 0,003 Min: 0,001 Max: 0,932 Max: 0,946 Max: 0,596 Route 1 Route 2 Route 3 Abbildung 38: Ergebnis der Neuvernetzung mittels Flächenrückführung Verformung [mm] in Normalenrichtung unter RPS Spannbedingungen3.4 Simulation der Lacktrocknung in der Prozesskette (CADFEM)Als wichtige Voraussetzung und als Bestandteil der betrachteten Prozesskette kanndas Trocknungsmodul des VirtualPaintShop® (VPS/DRY) von CADFEM genanntwerden. Es hat sich bei Firmen wie AUDI und BMW im Bereich der lackiergerechtenKonstruktion etabliert, um eine Simulation der Lacktrocknung von Autokarosserien ingroßen Trocknungsöfen durchzuführen. Zwischen den einzelnen Lackierschritten istjeweils eine Trocknung des Lackes erforderlich, wobei die Bauteile aufgeheizt undanschließ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 wasserbasiertenLacken 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/DRYkönnen kritische Stellen von Bauteilelackierungen ausgemacht sowie die Lackier-und Trocknungsvorgänge entsprechend vorausgeplant und optimiert werden. 43

Im Projekt VIPROF wurde die Lacktrocknungssimulation in die Prozesskette mit auf-genommen, um den Einfluss vorgelagerter Fertigungsschritte auf das Verhalten derKarosserie im Trocknungsofen zu überprüfen. Auch der Einfluss von Effekten, die beider Lacktrocknung auftreten, wie z. B. des Bake-Hardening-Effektes, auf das Crash-Verhalten waren von Interesse.3.4.1 Ergebnisse der SensitivitätsanalyseCADFEM hat eine Sensitivitätsanalyse der Lacktrocknung durch eine begleitendeEigenwertanalyse vorgenommen, um die Sensitivität des Ofenprozesses bezüglichEinflü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 dieVPS/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 sowiedurch Betrachtung halber Modelle mit Symmetriebedingungen vorgenommen, wie inAbbildung 39 gezeigt. Die Berechnungsvarianten sollten Rückschlüsse erlauben, wiestark Spannungen und Dehnungen aus der Vorgeschichte das Berechnungsergebnisbei der Trocknung beeinflussen. Abbildung 39: Entkerntes Halbmodell für die begleitende EigenwertanalyseDas Vorgehen zur Durchführung des mechanischen Verfahrens der begleitendenEigenwertanalyse (engl. mode tracking) zur Erkennung von Beulgefahren ist in Ab-bildung 40 gezeigt. Die Analyse beruht darauf, dass sich unter der thermischen Lastder Aufheizung und Abkühlung im Ofen der Spannungszustand von Blechen undStrukturen verändert, was einen Einfluss auf die Eigenfrequenzen der Bauteile hat. 44

Temperatur- Mechanische Berech- Vorgespannte berechnung nung mit Temperatur- Modal- in VPS/DRY randbedingungen analyse „Mode Tracking“ Abbildung 40: Begleitende Eigenwertanalyse zum Erkennen einer BeulgefahrEine 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 sowieAbschnitt 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 kenntman aus der Spannung einer Saite eines Musikinstrumentes. Durch Änderung derSpannung in der Saite wird das Instrument gestimmt. Bei Biege- oder Druckspan-nungen sinkt die Eigenfrequenz. Im Falle eines Stabilitätsproblems kann das Systemausgelenkt werden, ohne dass es nach Wegnahme der Last – hier in Form der inho-mogen verteilten Temperaturdehnungen – in die vorherige Lage zurückkehrt. EineEigenfrequenz 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 Interessesind sprunghafte Änderungen, da dann die Gefahr plastischer Verformungen durchBeulen der Struktur besteht. Solche sprunghaften Änderungen sind beispielhaft füreine Blechwanne in Abbildung 41 anhand eines Aufheizvorganges gezeigt. Im Pro-jekt wurde die Methodik der begleitenden Eigenwertanalyse verfeinert und automati-siert. 45

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 dasVerhalten 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 überdas 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, wiein 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ührenkö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 essich um ein ausgereiftes Serienfahrzeug handelt. Da die Berücksichtigung der Um-formhistorie aber rechentechnisch die Simulation weder vergrößert noch verlangsamtist 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 Blechdickeals Modellfehler ausgeschlossen werden. 46

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 einemvirtuellen Teststand (siehe Abbildung 43), mit dem Sensitivitäten hinsichtlich derÜbertragung von Ergebnissen aus vorgelagerten Prozesssimulationen aufgezeigtwerden können. Anhand der unten fixierten und oben künstlich belasteten B-Säulekö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 gezeigtwerden. Zunächst diente dies zur Verifikation der Vorgehensweise. Gleichzeitig zeigtes aber auch die Anwendbarkeit bei anderen Belastungen auf. 47

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üfstandzeigt 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 derEigenfrequenzen würden auf Beulen oder Durchschlagen hindeuten. Diese Ergeb-nisse wurden für ein nichtlineares Materialgesetz erzielt, das die elastische und dieplastische Fließgrenze beinhaltet. Durch diese Nichtlinearität kann eine Verfestigungaus der Umformsimulation bzw. eine Änderung der Fließgrenze berücksichtigt wer-den. 48

Abbildung 44: Begleitende Eigenwertanalyse der B-Säule im virtuellen Prüfstand mit steigender Belastung (Dargestellt sind die Verläufe von Eigenfrequenzen über denLastschritten, jeweils für ein Modell mit und ohne Berücksichtigung der Blechdicken- verteilung.)3.4.2 Untersuchung von Einflüssen des Bake-Hardening-EffektesDie Ausprägung des Bake-Hardening-Effektes (Reckalterung) hat einen Einfluss aufdie Crash-Eigenschaften der Karosserie. Wie stark dieser Effekt ausgeprägt ist wirdvom Ofenprozess bei der Lacktrocknung mitbestimmt. Daher lag es nahe, in derTrocknungssimulation VPS/DRY die Festigkeitssteigerung im Trocknungsofen durchden Bake-Hardening-Effekt zu untersuchen. Bei dem mit Bake Hardening bezeichne-ten Effekt findet im Trockner bei Temperaturen über 170-180° im Metallgefüge eine CKohlenstoffdiffusion an freie Gitterversatzstellen sehr viel schneller statt, als beiRaumtemperatur. 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-Effektkann dann aus der Trocknungssimulation VPS/DRY in das Crash-Modell übertragenwerden.Aus Materialdatenblättern ist bekannt, dass z. B. für die Stahlsorte CPW800 derBake-Hardening-Status erfüllt wird, wenn eine Haltezeit von 20 Minuten bei über170° erreicht wird. Die Zugfestigkeit des Werkstof fes kann von einem Wert von C800 MPa im Mittel um 70 MPa erhöht werden. Die Erhöhung ist abhängig von der 49

Verweilzeit des Materials auf einem Temperaturniveau. Während sich in Simulatio-nen unterhalb dieses Temperaturniveaus keine so stark ausgeprägten inhomogenenVerteilungen der Haltezeit zeigten, änderte sich die ungleiche Verteilung für Tempe-raturen über 175° deutlich, wie aus Abbildung 45 a m Außenblech der B-Säule er- Ckennbar.Abbildung 45: Darstellung der Haltezeit in Sekunden auf einem bestimmten Tempe- raturniveau zur Untersuchung der Einflüsse von Bake-HardeningFerner zeigt Abbildung 45, dass sich gerade in den Punkten der Lasteinleitung beiden Scharnieren eine geringere Haltezeit auf den jeweils betrachteten Temperaturni-veaus einstellt. Dies ergibt sich aufgrund der Wärmekapazität der an diesen Stellenangebrachten, 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 ausVPS/DRY geschrieben werden. Eine knotenbasierte Datenablage wurde für dieTemperaturen als Funktion der Zeit realisiert, da die Temperatur als Freiheitsgrad der 50

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. DieHaltezeit muss nicht notwendigerweise abgelegt werden, da diese aus den Tempera-turergebnissen nur abgeleitet wird. 1100 Spannung (BH0) Spannung (BH1) 1050 Spannung (BH2) 1000 Spannung (BH3) Spannung (BH4) 950 Spannung (BH5) 900 Spannung (BH6) Spannung (BH7) 850 Spannung (BH8) 800 Spannung (BH9) Spannung (BH10) 750 0 0,2 0,4 0,6 0,8 1 1,2 Abbildung 46: Unterschiedliche Bake-Hardening-Zustände, die aus verschiedenen Haltezeiten und Temperaturniveaus resultierenUm den Einfluss im Rahmen des Projektes exemplarisch aufzuzeigen wurde dieAusprägung des Bake-Hardening-Effektes linear abhängig zur Haltezeit oberhalbeines 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 sichunter diesen Annahmen Spannungs-Dehnungs-Kurven wie in Abbildung 46 gezeigt.BH0 Steht dabei für Material ohne Bake-Hardening-Effekt, BH10 für den voll ausge-prägten Effekt. 51

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

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 dasZielnetz, 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 vonMaterialanhäufungen im Bereich von angeschweißten Scharnieren eine zu geringeReckalterung 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 Prozessenin der mechanischen Analyse unter der Temperaturlast im Ofen berücksichtigt. Diefür die Berücksichtigung der plastischen Vergleichsformänderung verwendete INIS-TATE-Funktion von ANSYS kann aber auch dazu verwendet werden. So kann wie inAbbildung 49 gezeigt der Spannungszustand aus einer Teillösung in eine weitereTeillösung übertragen werden. Richtig ist ein solches Vorgehen, falls keine geschlos-sene Lösung der beiden Lastschritte möglich oder gewollt ist und die Konfigurationnach dem ersten Lastschritt die Startkonfiguration des folgenden Lastschrittes ist. Abbildung 49: Mechanik-Simulation von Be- und Entlastung mit INISTATE3.4.3 Zusammenfassung der Ergebnisse von CADFEMIm 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 eineMotivation, das zugrunde liegende FE-Modell mit den Einflüssen aus der Herstellungzu verbessern. 53

Zur Definition von Ampelkriterien für die Lacktrocknungssimulation innerhalb desModul-Cockpits ist sowohl ein Erreichen der geforderten Prozesstemperaturen, alsauch das Einhalten der Haltedauern für diese Temperaturen erforderlich. Alle direktaus der Temperatur ableitbaren Kriterien können ähnlich, einfacher oder komplexerwie das sog. Einbrennfenster des jeweiligen Lackes (siehe Abbildung 50) bestimmtwerden. Eine Klassifizierung in „Anforderungen erfüllt“ oder „nicht erfüllt“ ist damitmöglich. Die Methoden zur Automatisierung der begleitenden Eigenwertanalyse unddamit die weitgehend automatisierte Identifikation der Beulneigung stellen dies auchfü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 untersuchten 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ägtenBake-Hardening-Effektes aus der Lacktrocknung gezeigt. Dieser Effekt hat einen Ein-fluss auf das Crash-Verhalten. Ein Export von inhomogenen Bake-Hardening-Verteilungen aus der Trocknungssimulation wurde erfolgreich durchgeführt. 54

3.5 Abgleich der Simulationsprozesskette an Praxisbeispielen (VW)Volkswagen hat in das Projekt die Anforderungen eines Automobilherstellers an dasSimulationsdatenmanagement eingebracht und war an der Durchführung von Sensi-tivitätsanalysen und der Erarbeitung eines XML-basierten Datenaustauschformates2beteiligt.3.5.1 Katalog gewerkespezifischer EingangsgrößenUm die Kopplung von Daten und Prozessen vorzubereiten, wurde von Volkswagenein 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 Simulationsstufennotwendigen Eingangsdaten. Tabelle 4 zeigt einen groben Auszug aus dem Katalog,der im Verlauf des Vorhabens detailliert wurde. Abbildung 51: Kategorisierung des Kataloges gewerkespezifischer Eingangsgrößen2 Die Extensible Markup Language (Abk. XML; engl. für erweiterbare Auszeichnungssprache) erlaubtdie Beschreibung beliebiger Daten. Sie stellt einen Standard zur Modellierung von strukturierten Datenin Form einer Baumstruktur dar, der vom World Wide Web Consortium (Abk. W3C) definiert wird. 55

Eingangsdaten Umformsimulation Fügesimulation Lacktrocknungs- simulationGeometriedaten Bauteile (.igs) und Bauteile (.igs) Crashnetz, Schweiß- Ziehanlagen (.igs) punktinformationen Bauart/Abmessungen des TrocknersProzessdaten Blechhalterhub Position der Positionierung/ Maße Schweißpfade der Düsen Blechhalterkraft Mechanische Temperaturen Reibwert und Randbedingungen (Ofen/Karosserie) Reibwertverteilung Typ Schweißpro- Vorschub- Sickenersatzkräfte zess Geschwindigkeit Blechdicke … … Prozesszeiten …Materialdaten E-Modul E-Modul E-Modul Querkontraktion Querkontraktion Querkontraktion Dichte Thermischer Aus- Thermischer Ausdeh- Anisotropiewerte dehnungskoeff. nungskoeff. Fließkurve Fließkurve Fließkurve … … … Tabelle 4: Katalog gewerkespezifischer Eingangsgrößen3.5.2 Übertragung von Simulationsdaten mit XML-KonverterZusammen mit den Kooperationspartnern ARC Solutions GmbH, TU Berlin und TUChemnitz 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 dasDatenträgernetz wurde das standardisierte XML-Format avisiert. Mit dem Datenträ-gernetz sollte eine durchgängige Übertragung von Ergebnisdaten aus den einzelnenSimulationsstufen bis hin zur Crash-Simulation gelingen sowie eine Ankopplung andas PDM von VW.3 Das lizenzkostenfreie JT-Format unterstützt unterschiedlichste Repräsentationen von CAD-Geometrien und erlaubt eine 3D-Visualisierung. 56

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 dasXML-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 inDarmstadt ein Konverter zur Übertragung von VIPROF-XML-Daten in das JT-Formatentwickelt. Durch Übertragung von XML- in das JT-Format können auch lizenzfreieStandard-Viewer genutzt werden, da direkt binäre JT-Files ohne Nutzung des JT-Toolkits von Siemens erzeugt werden. Dies erlaubt zudem eine Unabhängigkeit vonzukü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-Konverterintegriert werden (siehe Abbildung 54), so dass kein separates Mapping-Tool mehrerforderlich wäre. Ob mit oder ohne diese beiden Ausbaustufen können die Ergeb-nisse zwischen den Simulationsstufen nahezu automatisch übertragen werden. 57

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 viaXML-Konverter erfolgen. 58

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

• 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 imKontext des Digital Mock-up des Gesamtfahrzeuges darstellbar und auswertbar, wiein Abbildung 58 gezeigt. Abbildung 58: Visualisierung der FEM-Daten im VisMockup [PIN110] 60

Zu dem im Unterauftrag von VW vom Fraunhofer IGD entwickelten Konverter zurGenerierung von JT-Dateien aus dem VIPROF-XML-Format hat VW eine GUI prog-rammiert, mit der Ergebnisgrößen auf verschiedene Weise gemäß Benutzervorgabendargestellt 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 alsBaugruppe darstellbar. Sie können im Kontext ihrer Umgebung oder des Gesamt-fahrzeuges gezeigt werden. Die Unabhängigkeit der JT-basierten Visualisierung vonLizenzkosten kommt auch der Nutzbarkeit durch mittelständische Lieferanten entge-gen. Die Vorteile der Visualisierung im JT-Format sind in Abbildung 59 zusammenge-fasst.Abbildung 59: Visualisierung von CAE-Ergebnissen im CAD-Gesamtfahrzeugkontext [PIN111]3.5.3 Vergleich OneStep- und inkrementelle Umformsimulation mit Benchmark OneStep-SolverUm in der frühen Produktentwicklungsphase, d.h. zu einem Zeitpunkt, bei dem nochkeine 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 Prozessketteeinzubeziehen. Sie benötigt lediglich die CAD-Geometrie des Bauteils sowie die Ma-terialdaten. Durch eine Rückrechnung der umgeformten Geometrie auf die ebenePlatine werden die plastischen Dehnungen und die Blechdickenverteilung berechnet. 61

Auch eine Abschätzung der erforderlichen Platinengröße gelingt mit einem OneStep-Solver. [PIN209]Von Interesse war die mit einem OneStep-Solver erreichbare Genauigkeit, verglichenmit der Realität und der inkrementellen Umformsimulation. Um die Ergebnisqualitätvon OneStep-Solvern der Umformsimulation beurteilen zu können hat Volkswageneinen Praxisabgleich von Simulationsergebnissen vorgenommen. Für die folgendendrei OneStep-Solver wurde ein Benchmark durchgeführt.• FTI-FormingSuite 7.2• ESI PAM-TFA for Catia V5• AutoForm Onestep for Catia 1.1Als Bewertungsgrundlage für den Benchmark wurde die Ergebnisgröße Blechdickegewä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. Umdie Blechdicke am realen Bauteil zu erfassen, wurde ein Ultraschallmessgerät einge-setzt. Es wurden fünf Crash-relevante Strukturbauteile mit einem breiten Spektrumvon Nennblechdicken und unterschiedlichen Werkstoffen untersucht. An den realenBauteilen wurden in kritischen und unkritischen Bereichen Messpunkte definiert. Wiein Abbildung 60 dargestellt, wurden Abweichungen der Ergebnisgröße bewertet (grü-ner Bereich falls relativer Fehler ≤ 5%, gelb falls 5-10%, rot falls >20%). [PIN209] Abbildung 60: Bewertungskriterien des Benchmarks [PIN209] 62

Ebenfalls untersucht wurde der Einfluss der Rückhaltekraft am Bauteilrand, wobeidiese 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 dieOneStep-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 Messpunktesentsprechend 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 diebetrachteten Solver in Abbildung 62 dargestellt. Es wird ersichtlich, dass die Ergeb- 63

nisqualität der OneStep-Solver in Bezug auf die berechneten Blechdicken an die derinkrementellen 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 Zeitenzwischen 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 dieOneStep-Simulation ein qualitativ gutes Ergebnis (siehe Abbildung 63), welches esplausibel erscheinen lässt, in der frühen Entwicklungsphase die OneStep-Ergebnissein nachfolgende Simulationen entlang der Prozesskette zu übertragen, anstatt mitkonstanten Blechdicken weiter zu rechnen. Betrachtet man hingegen die Ergebnis-größe plastische Vergleichsdehnung werden größere Abweichungen, insbesondereim 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 derFall, da dieser Effekt durch die OneStep-Methode nicht abgebildet wird. Gegenüberder inkrementellen Umformsimulation liefert die OneStep-Simulation in Bereichengrößerer Ziehtiefen um den Faktor zwei geringere plastische Vergleichsdehnungen.Da die plastische Vergleichsdehnung ein Maß für die Kaltverfestigung des Blech-werkstoffes ist, fallen die Ergebnisverbesserungen bei der Crashsimulation mit Um-formhistorie aus der OneStep-Simulation nur ca. halb so groß aus wie die Ergebnis-verbesserungen der Crashsimulation mit Umformhistorie aus der inkrementellen Um-formsimulation (siehe Abbildung 65). [PIN311] 64

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

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 genauereninkrementellen Berechnung einen erheblichen Zeitvorteil aufweist: Während eineOneStep-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 ProzesskettensimulationZur 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 desFahrzeuges analysiert wird. Ein Crash-Modell für die Variantenrechnungen wurdeaufgebaut. Betrachtet wurden nur die definierten Musterbauteile im Seitencrash, dadie 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-Auswerteprotokollsvon VW anhand des Crash-Ergebnisses bewertet. Damit waren die Auswirkungenunterschiedlicher Einflüsse auf das Berechnungsergebnis erfassbar, und nicht zuletztkonnte das Verhältnis von Aufwand zu Nutzen hinsichtlich einzubeziehender Pro-zesssimulationen beurteilt werden. 66

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

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

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

(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 geringe plastische Vergleichsdehnungen liefert, hat sich in der Crash-Simulation unter Berücksichtigung der Umformhistorie bestätigt. Die Ergebnisse mit Berück- sichtigung der OneStep-Ergebnisse zeigen im Vergleich zu den Crash- Simulationen mit inkrementeller Umformhistorie den Einfluss der um die Hälfte reduzierten plastischen Vergleichsdehnung (Kaltverfestigung). Daraus leitet sich die Empfehlung ab, die OneStep-Simulation für Bauteile mit sehr großen Ziehtie- fen nicht einzusetzen.3.5.4.2 Mapping von Umform- über Füge- auf Crash-Simulation (Varianten 3, 4 und 5)Volkswagen hat Schweißverzugssimulationen der B-Säule auf Basis von Daten vonESI durchgeführt und einen Praxisabgleich der Simulationsvarianten mit und ohneUmformhistorie 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 Blechdickenund die plastischen Dehnungen aus der inkrementellen Umformsimulation in dieSchweißverzugssimulation übertragen, zeigt sich ein signifikanter Einfluss. Am Kopfder B-Säule stellen sich die richtigen Verzugswerte und die richtige Drehrichtung ein(siehe Abbildung 70) [PIN310]. Werden nur die Blechdicken oder nur die plastischenVergleichsdehnungen übertragen, weichen die vorhergesagten Verzugswerte stärkerab. Die Verbesserung der Ergebnisqualität der Schweißverzugssimulation konnteauch mit Berücksichtigung der Umformhistorie (Blechdicken und plastische Ver-gleichsdehnungen) aus der OneStep-Simulation erzielt und im Praxisabgleich bestä-tigt werden (siehe Abbildung 71). [PIN311] 70

Abbildung 70: Auswirkungen der Berücksichtigung der Historie aus der inkrementellen 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 dieCrash-Simulation erscheint wenig sinnvoll, da die Einflüsse im Bereich der numeri-schen Streuung des Crash-Modells liegen. Die Schweißprozesse (Laser- und Wie-derstands-Punkt-Schweißen) führen nicht zu großflächig signifikanten Änderungen 71

der Blechdicken und plastischen Vergleichsdehnungen, so dass diese Größen direktaus dem Umformen in die Crash-Simulation weitergeleitet werden können.Die Erkenntnis, dass die Übertragung von Blechdickenverteilung und Verfestigungsinnvoll 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 mehrAufwand investiert werden. Anders sieht dieser Sachverhalt aus, wenn man anstelledes 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 einensignifikanteren Einfluss auf das Simulationsergebnis haben.3.5.4.3 Mapping von Umform- über Füge- auf Lacktrocknungssimulation (Va- rianten 6, 7 und 8)Ähnlich wie bei der Fügesimulation die Verfestigung einen untergeordneten Einflussauf das Simulationsergebnis hat, ist dies auch in der Ofensimulation der Fall. Dieswurde in einem Vergleich zwischen elastischem Materialverhalten und plastischemVerhalten 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 virtuellenPrüfstand aufgebracht, die auf jeden Fall zum Beulen führen. Bei Berücksichtigungder 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 vorgegebenenOfenlasten so unkritisch gegenüber Beulverhalten, dass hier der Einfluss auf dieBeulneigung nicht quantifiziert werden konnte. Dies war auf den Reifegrad der ver-wendeten Serienbauteile zurückzuführen. [CSB11]3.5.4.4 Mapping von Umform- über Lacktrocknungs- auf Crash-Simulation (Va- rianten 9 und 10)Die Sensitivitätsanalyse vom Umformen auf die Lacktrocknung zeigte, dass die Über-tragung der Blechdickenverteilung einen geringen Einfluss auf die Eigenwerte derBauteile hat. Bei den plastischen Vergleichsdehnungen konnte kein Einfluss festges-tellt werden. In der begleitenden Eigenwertanalyse von CADFEM, die Beulgefahrenaufdecken soll, ergaben sich nur geringe Unterschiede in den Eigenwerten zwischenden Ausgangs- und den umgeformten Blechdicken. Hierbei muss beachtet werden, 72

dass es sich bei den Musterbauteilen des VW-Touran um ausgereifte Serienteilehandelt. 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 desUmformens einen vernachlässigbaren Einfluss [CSB11].Die Übertragung der Blechdickenverteilung kann einen Einfluss auf die Lacktrock-nung haben, da sich durch unterschiedliche Blechdicken die Wärmeleitung verändert[CSB11].3.5.4.5 Mapping von Lacktrocknungs- auf Crash-Simulation (Variante 11)Da sich durch den Trocknungsprozess sowohl die Blechdicken als auch die plasti-schen Vergleichsdehnungen der Versuchsteile nicht änderten, war eine Übertragungdieser Ergebnisgrößen aus der Lacktrocknungssimulation in die Crash-Simulationnicht notwendig. Bei Bauteilen aus Bake-Hardening-Materialien hat es sich jedochals sinnvoll erwiesen, die mit der Lacktrocknungssimulationssoftware von CADFEMerrechneten 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 Prozesskettensimulation3.5.5.1 Validierung durch Messung des SchweißverzugsVolkswagen 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 dieaus der Konstruktion festgelegten Blechdicken erhalten und ein spannungs- unddehnungsfreier Anfangszustand vorliegt. Andererseits das „Kopplungs-Modell“, wobeihier die Blechdicken und die plastischen Dehnungen aus der Umformsimulation imGesamtmodell als Anfangsbedingungen vorliegen. Die Ergebnisse dieser zwei Va-rianten der Schweißverzugssimulation werden nachfolgend vorgestellt und mit deman der realen Baugruppe ermittelten Schweißverzug verglichen. Die Messergebnissedes Verzuges in y-Richtung sind in Abbildung 72 dargestellt. Für eine statistischeAbsicherung wurden mehrere Schweißbaugruppen vermessen. Die berechnete Ver-drehung aus den Simulationsmodellen zeigt Abbildung 73. [PIN310] 73

Y +0,0 Y -0,1 Y +0,5 Y -0,2 Y +0,5 z -y x Abbildung 72: Messergebnisse des y-Verzuges an der B-Säule (in mm) und Verdrehungsrichtung [PIN310] a) b) z x z x y y -0,1 0,0 Abbildung 73: Verzug in y-Richtung der B-Säule: CAD-Modell (a) und Kopplungs-Modell (b) [PIN310]Es zeigt sich deutlich der Einfluss der Umformhistorie auf das Ergebnis der Schweiß-verzugssimulation. Während die B-Säule des „CAD-Modelles“ sich weitestgehend inpositive 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 amKopf der B-Säule im Vergleich mit der Praxismessung. Erst mit Berücksichtigung derUmformhistorie (Blechausdünnung und plastische Dehnungen) wird die am Kopf derB-Säule auftretende Verzugsrichtung in der Schweißverzugssimulation entsprechendder Praxismessung richtig berechnet. [PIN310] 74

3.5.5.2 Validierung mit 3-Punkt-BiegeversuchVolkswagen 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 derPraxis 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 Umformhistoriemit Blechdicken und plastischen Dehnungen berücksichtigt wurde, zeigte eine sehrgute Übereinstimmung des Biegeverhaltens und des Kraftverlaufs, wie aus Abbildung75 erkennbar. Die Übertragung von Eigenspannungen aus der Umformsimulationhatte keinen Einfluss auf das Ergebnis. [PIN311] 75

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, indemunbehandeltes Material mit einer vorbehandelten Charge aus dem Trocknungsofenverglichen wurde. Die Ergebnisse zeigten, dass eine Berücksichtigung des Bake-Hardening-Effektes in der Simulationsprozesskette sinnvoll ist. [PIN311]3.5.6 ModulcockpitUm 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 relevanteEinzelteil muss die Herstellbarkeit gegeben sein, bevor es durch eine „grüne Ampel“für den nächsten Fertigungsprozess freigegeben wird (siehe Abbildung 76). [PIN109] Abbildung 76: Reifegrad-Cockpit für die simulationsbasierte Herstellungsbewertung [PIN109] 76

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 jeweiligenLack dem sog. Einbrennfenster (siehe Abschnitt 3.4, Abbildung 50) entnommen undin den Workflow aufgenommen werden. Analog dieser Vorgehensweise wurden auchfür die anderen Simulationsgewerke Ampelkriterien für die Herstellbarkeit definiert.Literatur:[PIN109] Pinner, S. et al.: Durchgängige Virtualisierung der Entwicklung und Produktion von Fahrzeugen, Fachtagung Digitales Enginee- ring, Fraunhofer Wissenschaftstage, 16.-18. Juni, Magdeburg, 2009.[PIN209] Pinner, S. et al.: Einsatz inverser Solver innerhalb der Prozess- kettensimulation im Bereich Karosseriebau, ANSYS Conference & 27. CADFEM Users‘ Meeting, Leipzig, 2009.[PIN309] Pinner, S. et al.: Integrierte Prozesskettensimulation bei der Ka- rosserieherstellung im Projekt VIPROF, ANSYS Conference & 27. CADFEM Users‘ Meeting, Leipzig, 2009.[PIN110] Pinner, S.: Universelle Visualisierung von Simulations-Ergebnis- daten im JT-Format. 16. JT User Group Treffen, Fraunhofer IGD, 30. März, Darmstadt, 2010.[PIN210] Pinner, S.: Lieferantenintegration am Beispiel der Prozesskette Umformen-Fügen-Lackieren, VIPROF Industriearbeitskreis Pro- zesskettensimulation, 08. Juni, Fellbach bei Stuttgart, 2010.[PIN 310] Pinner, S. et al.: Prozesskettensimulation im Karosseriebau am Beispiel der Kopplung von Umform- und Fügesimulation, 15. Internationale Konferenz für Simulation und Berechnung - SIM- VEC, 16. - 17. November, Baden-Baden, 2010. 77

[PIN111] Pinner, S.: Visualisierung von CAE-Ergebnisdaten im JT-Format. Fachkonferenz „Berechnung im Produktprozess“, 10. Februar, Braunschweig, 2011.[PINSB11] Pinner, S.; Steinbeck-Behrens, C.: Übersicht Prozesskettensimu- lation. 2. VIPROF Industriearbeitskreis, 22. November, Stuttgart, 2011.[PIN311] Pinner, S.: Prozesskettensimulation im Karosseriebau. 2. VIP- ROF Industriearbeitskreis, 22. November, Stuttgart, 2011.[CSB11] Steinbeck-Behrens, C.; Menke, T.: Lackiersimulation in der Pro- zesskette. 2. VIPROF Industriearbeitskreis, 22. November, Stutt- gart, 2011.3.6 Strukturierte Ablage heterogener Daten im Kontext von Wie- derverwendbarkeit und Weiterverwendbarkeit (TU Berlin)3.6.1 AllgemeinesTeilprozesse 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 diesemeist mit viel Handarbeit – also das Transformieren der Daten von Hand, um sie Fol-geprozessen zugänglich zu machen – verbunden. Dieser Umstand verhindert jedochmaß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 unterschiedlichen Datenformate lesen können.2. Die verschiedenen Programme der einzelnen Teilprozessschritte müssen die unterschiedlichen Daten auf die gleiche Art interpretieren. 78

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 dasInstitut 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.2behandelt.3.6.2 KonversionUm 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 alsPeer-to-Peer-Strategie bezeichnet und durch Abbildung 77 visualisiert. Abbildung 77: Peer-to-Peer-StrategieDiese Strategie ermöglicht es, jedes beliebige Datenformat aus jedem beliebigenanderen in nur einem Konversionsschritt zu erzeugen. Hierbei sind die Verluste anInformationen 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 inAbhängigkeit von der Anzahl der Formate quadratisch. Diese Strategie scheint sichbei einer geringen Anzahl von Datenformaten zu empfehlen. 79

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 Fallnur zweier existierender Datenformate identisch mit derPeer-to-Peer-Strategie ist. Abbildung 78: Ring-StrategieInnerhalb 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 schnellVorteile 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 Konversionsschrittenotwendig sind, bis das Zielformat erreicht ist. Die Konvertierungsverluste entwickelnsich bei dieser Strategie eher unvorteilhaft, da im schlechtesten anzunehmenden Falllediglich die Schnittmenge aller Formate verbleibt, die mit steigender Anzahl derFormate überproportional abnimmt. Innerhalb dieser Strategie entfallen ebenfalls dieKosten für die Definition eines Intermediärformates, sodass die Gesamtkosten derKonvertierung dieser Strategie überproportional zur Anzahl der Konverter steigt, sichjedoch flacher gestaltet als bei der Peer-to-Peer-Strategie.Die Konversion mittels Überführung jeden Datenformates in ein generisches Daten-format wird als Intermediär-Strategie bezeichnet und durch Abbildung 79 visualisiert. Abbildung 79: Intermediär-Strategie 80

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*nKonverter (n = Anzahl der Datenformate) notwendig – ein Konverter zur Überführungeines proprietären Datenformates in das generische Datenformat und einer in dieGegenrichtung. Im Gegensatz zu den beiden vorhergenannten Strategien ist hierbeijedoch eine Intermediärformat zu definieren, was Kosten verursacht. Diese Kostensind jedoch einmalig und amortisieren sich mit steigender Anzahl der Formate. DasZielformat einer Konversion ist in maximal zwei Schritten erreichbar (Datenformat A Intermediärformat Datenformat B), wobei die Ausführungskosten für diesen Fallgleich 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 KonversionsstrategienDie Peer-to-Peer-Strategie (rot) zeigt einen steileren Kostenanstieg als dieRing-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 durchdie Definition eines Intermediärformats, ist jedoch nur linear Abhängig von der Anzahlder Datenformate, sodass ein Punkt n* existiert, ab dem die Intermediär-Strategie derRing- und Peer-to-Peer-Strategie kostenmäßig überlegen ist. Dieser Punkt n* ist sehrniedrig, weil Tools und Methoden sehr heterogen sind, was sich ungünstig auf dieKonvertierungsverluste der Ring-Strategie auswirkt und weil die Definition einesIntermediärformats effizient und kostengünstig möglich ist, sodass der Fixkostenan- 81

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 datenverarbeitendenProzesses – die Intermediär-Strategie zu bevorzugen.Bei der Verwendung der Intermediär-Strategie ist, wie bereits mehrfach erwähnt einIntermediärformat zu definieren. XML bildet ein solches Intermediärformat, welchesbedingt durch seine Struktur gewisse Vor- und Nachteile mit sich bringt. XML ist einoffener, lizenzfreier Standard, der eine gewisse Popularität erreicht hat und somitsoftware- und entwicklungsseitig gut unterstützt wird. Seine Popularität lässt sich mitder 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 vonXML sind die Daten, ähnlich wie in einer Datenbank, frei modellierbar, solange mansich innerhalb gewisser Grenzen bewegt. Hieraus resultiert dann eine strukturierteSpeicherung 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 essich problemlos an andere Systeme anbinden. XML wird text- und dateibasiert ge-speichert, sodass die Informationen über jegliche Art von Netz verteilbar ist – XMLalso plattformunabhängig ist. XML ist Unicode-fähig, also internationalisierbar undarbeitet mit beliebigen Zeichensätzen zusammen. Als Nachteile für XML sind seinhöherer Speicherbedarf und die langsamere Verarbeitung zu nennen. Beide Nachtei-le sind jedoch zu vernachlässigen, da zum einen Speicherplatz immer günstiger wirdund Prozessoren immer schneller und zum Anderen, bedingt durch die text- bzw.dateibasierte Speicherung von XML, XML gut komprimierbar ist, sodass die Vorteileden Nachteilen überwiegen.3.6.3 Das VIPROF-XML-DatenformatIm Rahmen des Projektes musste folglich eine Informationsanalyse aller am Prozessbeteiligter Daten vorgenommen werden, um in Folge dessen ein XML-Datenformatzu definieren, welches die benötigten Informationen aufnehmen kann. Abbildung 81zeigt den Simulationsprozess und seine verwendeten Programme, aus denen sichdie notwendigen Informationen ergeben. 82

Abbildung 81: Simulationsprozess inkl. der verwendeten SimulationstoolsDie Abbildung 82 zeigt am Beispiel des Datenformates der ESI GmbH die im Prozessanfallenden Daten. Abbildung 82: M01-Datenformat der ESI GmbH 83

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 Bauteilzu 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 innerhalbder 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 imRaum – mittels x-, y- und z-Koordinate.In den Elementdaten wurden die einzelnen Elemente spezifiziert. Dies geschiehtebenfalls 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 vonElementmatrizen über das Volumen.Die Attributinformationen enthalten ein Kürzel für das simulierte Attribut (z. B. THICfür die Dicke), die Anzahl der Ergebniswerte je Element, ihre Abhängigkeit vomGauß- bzw. den Integrationspunkten (dies hat Einfluss auf die tatsächliche Anzahlder Ergebniswerte) und das Einheitensystem der Ergebniswerte spezifiziert durch dieFaktoren für den Weg, die Masse und die Zeit. 84

Die Attributwerte enthalten Informationen über das ihnen zugehörige Element – inForm der eindeutigen Elementidentifikationsnummer – und die Ergebniswerte derSimulation.Diese Informationen (Metainformationen, Knotendaten, Elementdaten, Attributinfor-mationen und Attributwerte) lagen jedoch, je nach Datenformat, nicht in derselben Artund 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 Metadatenund 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 XSDInnerhalb der Metainformationen waren nun Informationen über das Bauteil, seinName, das Datum der Simulation, die Anzahl der Knoten und Elemente innerhalb derSimulationsdatei, die Anzahl der simulierten Attribute (z. B. Dicke), das verwendeteEinheitensystem und die Rotationsmatrix zu finden. Darüber hinaus enthält dieserInformationsblock nun auch alle Metainformationen über die simulierten Attribute, wieihren Namen, die Anzahl der Ergebniswerte, ihre Abhängigkeiten von Gauß- und In-tegrationspunkten und ihr Einheitensystem. Hinzugekommen ist ein eventuell vor-handener oder notwendiger Referenzwert für das Simulationsattribut (z. B. eine Refe-renzdicke). 85

Die XML-Simulationsdaten enthalten nun alle anderen Informationen der ursprüngli-chen Informationsblöcke, wobei hier zwei Blöcke alle Informationen aufnehmen (wiein Abbildung 84 zu sehen).Abbildung 84: Simulationsdaten des VIPROF-XML-Datenformates in Form einer XSDDies sind zum Einen der Knotenblock, der alle Informationen über die Knoten enthält(eindeutige Knotenidentifikationsnummer und die Koordinaten im Raum) und zumAnderen 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ürdie Zugehörigkeit eines Elements zu einem bestimmten Part und die Simulationswer-te in Form von Namen und Ergebniswerten). 86

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

• 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-DatenformatDiese Daten müssen nun im PDM/SDM-System abgelegt werden. Hierzu sind dieDatengrößen zu untersuchen, um Aufschluss darüber zu erhalten, inwiefern das nunresultierende Datenaufkommen wirtschaftlich händelbar ist. Ausgehend von denproprietä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 sowie 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 datentechnisch 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 dieses Szenarios sind ausschließlich die XML-Daten im PDM/SDM-System abgelegt und deren Visualisierung. Durch die Einsparung der proprietären Daten ist mit ei- 88

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 verarbeitet 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 deren 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-Konverters3.6.4.1 FunktionsweiseDer im Rahmen des Projektes entwickelte XML-Konverter ist in der Lage, Daten nachMaßgabe der ESI GmbH und der CADFEM GmbH bzw. ANSYS Inc. zu konvertieren;Abbildung 87 zeigt die möglichen Konversionsroutinen (gelb = Datenformat ESIGmbH, blau = Datenformat CADFEM GmbH bzw. ANSYS Inc.). Abbildung 87: XML-Konverter inkl. seiner KonversionsroutinenHierbei ist der XML-Konverter in der Lage nicht nur aus den proprietäre Daten XMLzu erzeugen, sondern ebenso aus den XML-Daten das ursprüngliche, proprietäreDatenformat zu generieren. Um aus den proprietären Daten ein einheitliches XML-Datenformat erzeugen zu können, sind Anpassungen an den ursprünglichen Infor- 89

mationen vorzunehmen, um innerhalb des XML Homogenität bzgl. der Information zuerreichen. 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 denunterschiedlichen, strukturellen Aufbau, passt diesen an und konvertiert folgend indas XML-Format. Eine weitere Anpassung nimmt der XML-Konverter im Bereich derElemente vor. Elemente innerhalb der proprietären Daten (sowohl der ESI GmbH alsauch der CADFEM GmbH bzw. der ANSYS Inc.) werden – so die Beschränkungeninnerhalb des Projektes – als Viereckselemente abgelegt, haben also vier Knoten,die ein solches Element aufspannen. Eine solche Definition lässt es jedoch zu, auchDreieckselemente abzulegen, wofür es jedoch zwei potentiell zu unterscheidendeMö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 Simulationsergebnisseelementbasiert 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 jeElement von 3 Ergebniswerten. Der XML-Konverter erkennt diese unterschiedlichenAnsätze und erzeugt aus den vier Knotenwerten einen Elementwert per Mittelung.Bei einer Rücktransformation ist dies natürlich problematisch, da eine reine Kopiedes XML-Elementwertes auf die Knoten einen Informationsverlust darstellt, der nichtwirtschaftlich zu vertreten ist, eine Abspeicherung der Knotendaten, z. B. in Formeines Kommentars aber ebenfalls nicht in Frage kommt, da so die XML-Daten um einvielfaches größer werden würden – selbst kleinere Dateien haben 70.000 Elemente,sodass hierbei 210.000 zusätzliche Werte als Kommentar zu speichern sind. DerXML-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 unddamit vernachlässigbar sind. 90

3.6.4.2 BegrenzungenDie unterschiedliche Ablage der Daten innerhalb der proprietären Datenformatebringt jedoch auch Begrenzungen mit sich, die der XML-Konverter nicht in der Lageist zu kompensieren. So werden die Simulationsergebnisse, die in einem Elementabgespeichert sind und durchaus auch Richtungswerte sein können (z. B. für dieplastische Dehnung) in unterschiedlichen Koordinatensystemen abgespeichert. Esexistieren 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 derSCAIMapper innerhalb der Prozesskette Anwendung findet. Ebenso problematischist 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 einenKnotenwert zu berechnen. Dabei bleibt unberücksichtigt, welche Größe die einzelnenElemente 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 desProjektes jedoch nicht weiter ausgeführt.Daraus ergibt sich, dass, bedingt durch die unterschiedliche Speicherung bestimmterDaten, eine Transformation von einem Datenformat über XML in ein anderes nichtmöglich ist. Der XML-Konverter erkennt das Ursprungsformat und lässt eine Rück-transformation nur in diese kompatiblen Datenformate zu. 91

3.7 Entwicklung einer systemübergreifenden Datenablage im PDM-System zur Realisierung einer durchgängigen Simulati- onsprozesskette (TU Chemnitz, ARC Solutions GmbH)3.7.1 Problemstellung und ZieleDie Basis für die Schaffung einer durchgängigen Simulationsprozesskette ist dieKenntnis aller ablaufenden Prozesse sowie aller Ein- und Ausgabedaten, die von denSimulationsprogrammen genutzt werden. Zu Beginn des Projektes erfolgte deshalbin einer Ist-Analyse die Ermittlung aller notwendigen Prozesse und Daten/Attributeder Teilgewerke. Dazu wurden Befragungen durchgeführt, vorhandene Prozessbe-schreibungen ausgewertet und die einzelnen Simulationsprogramme untersucht.Für die Abbildung der Prozesse wurden unterschiedliche Modellierungsmethoden aufihre 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 allenEin- 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 Zahlvon 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 dieErgebnisdaten 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 einheitlicheDatenablage gewährleistet ist. Die Datenbeschaffung für nachfolgende Prozesse isterheblich erschwert und daher sehr zeitaufwendig und kostenintensiv. Schnittstellenzwischen Simulationsprogrammen und Produktdatenmanagementsystemen (PDM-Systemen) sind in der Regel nicht vorhanden. Lediglich die Ablage von Konstrukti-ons- und Fertigungsdaten in PDM-Systemen ist heute realisiert. Ferner fehlt momen-tan eine automatische Steuerung und Kontrolle der Prozessabläufe. Hier bietet sich 92

der Einsatz eines Workflowsystems an, mit dessen Hilfe eine Übersicht über den Ar-beitsfortschritt gegeben werden kann. Die Ergebnisse der Ist-Analyse sind inAbbildung 88 zusammengefasst. Abbildung 88: Ergebnisse der Ist-AnalyseAls 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 DatenmanagementIn 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 bietetsich der Einsatz eines Produktdatenmanagementsystems an. Es bildet eine Integra-tionsplattform für alle eingesetzten Datenerzeugungssysteme (PPS-Systeme, CAX-Systeme, diverse Applikationen, Projektmanagementsysteme, Officesysteme undSimulationsprogramme), was allen Daten über den gesamten Produktentwicklungs-prozess entspricht [VDI2219]. 93

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

Nach der Auswertung der einzelnen Kriterien stellte sich das PDM-SystemTeamcenter 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 TeamcenterEin weiterer Vorteil ist das Modul Teamcenter for Simulation, das für die Speicherungund Verwaltung von Simulationsdaten entwickelt wurde. Es bietet ein umfassendesDatenmodell 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 virtuellenPrototypen leicht auffindbar und wiederverwendbar sind [TEAM09]. 95

Das System gehört zu den meist verkauften Systemen auf dem Markt und seineKonzeption ist sowohl für Großunternehmen als auch für Mittelständler interessant.Haupteinsatzgebiet ist der Produktentwicklungsbereich. Hier können alle erzeugtenDaten 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 besitztentsprechende Export- und Importfunktionen und eine Workflowkomponente, die eserlaubt den Prozess der Bearbeitung und Weiterleitung der Daten zu steuern und zukontrollieren [VDI02]. Das System ist individuell anpassbar und durch dieangebotenen Forschungs- und Lehrlizenzen stellte sich das System für die geplantenArbeiten als besonders geeignet heraus.3.7.3 Entwicklung von DatenablagestrukturenBei der Entwicklung einer geeigneten Datenablagestruktur für unterschiedliche Pro-duktdaten musste besonders auf Flexibilität geachtet werden. Zum einen bestand dieAnforderung unterschiedliche Datenformate abzulegen und zum anderen musste dieStruktur verschiedene Bauteilvarianten, wie sie in der Automobilindustrie häufig vor-kommen, abbilden können. So ist es zum Beispiel erforderlich zu einem Bauteil dieCAD-Daten, die FEM-Daten, die Fertigungsgeometrien oder die von realen Bauteilengescannte Daten (siehe Abbildung 91) zusammen abspeichern zu können. Abbildung 91: Verschiedene Varianten eines BauteilsSchnell zeigte sich, dass das zu entwickelnde Datenmodell in Teamcenter nicht aus-schließlich aus einer Struktur bestehen kann, sondern mehrere, sich einander ergän- 96

zende und miteinander kombinierbare Strukturen, beinhalten muss. Hierfür wurdenunterschiedliche Strukturen auf der Basis von produkt- und fertigungsspezifischenGrundstrukturen entwickelt.Die folgenden vier neuen Datenablagestrukturen für die Speicherung von diversenBauteilvarianten 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 Entwicklungssichtstrukturiert 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 erstenZeichnung 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 Nutzersichtbar ist. In Abbildung 92 ist die Entwicklungsproduktstruktur des VIPROF-Demonstrators dargestellt. Abbildung 92: Entwicklungsproduktstruktur des VIPROF-Demonstrators 97

Im Projekt wurden als Betrachtungsumfang das Seitenteil aus dem Fahrzeug TouranGP2 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-DemonstratorsDie dritte Struktur, die TPR-Struktur (Technologieprozessreihenfolgestruktur) istebenfalls gemäß der Montagereihenfolge strukturiert. Sie beinhaltet allerdings die inder Produktion zum Einsatz kommenden Technologien. Der Bearbeiter kann somitfeststellen, welche Technologien in welcher Reichenfolge bei der Produkt- und Bau-teilfertigung eingesetzt werden. Abbildung 94 verdeutlicht dies für das Presswerk. Inder Struktur enthalten ist die im VIPROF-Projekt betrachtete B-Säule. Diese wirddurch einzelne nacheinander ablaufende Operationen (OP) hergestellt. Hinter jederOperation sind die jeweiligen Verlinkungen auf die entsprechenden Simulationsdatenzu finden. Weiterhin sind der Methodenplan, die zum Herstellungsschritt gehörendePlatine und eine Verlinkung zu den entsprechenden Konstruktionsdaten vorhanden.Auf den Strukturaufbau für Simulationsdaten, welcher ansatzweise ebenfalls in Ab-bildung 94 dargestellt ist, wird im weiteren Verlauf dieses Berichtes näher eingegan-gen. 98

Abbildung 94: Technologieprozessreihenfolgestruktur des VIPROF-DemonstratorsAlle 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) nurZugriff auf die für sie bestimmte Struktur und die darin enthaltenen sowie verlinktenDaten. Abbildung 95: Beispiel einer Verknüpfung der einzelnen Strukturen untereinanderIn Abbildung 95 wird beispielhaft dargestellt, wie die Verknüpfung der einzelnenStrukturen untereinander erfolgen kann. Es ist ersichtlich, dass jeweils der letzte Ar-beitsschritt in einer Reihe von Operationen aus der TPR-Struktur mit der FPS-Struktur verlinkt ist. Dies entspricht dem Bauteil, wie es bei der Fahrzeugherstellung 99

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 undkonstruiert) einfach miteinander vergleichen, da solche Bauteile meistens erst nacheinem der letzten Operationsschritte übereinstimmen. Zum Beispiel wird bei einemBauteil mit Flansch, dieser erst nach dem Fügen (Falzen) geschlossen, wodurch sichbis zu diesem Operationsschritt das reale Bauteil von dem fertig konstruierten Bauteilunterscheidet.Die vierte Struktur, die SDM-Struktur (Simulationsdatenmanagementstruktur), wurdespezielle 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 speichernund so eine konsistente Datenbasis für alle Teilprozesse aufzubauen. Dazu wurdezunä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 Relationenmiteinander 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 zueinem Bauteil. Ein Item besteht aus drei wesentlichen Bestandteilen, dem Datasetzur Erfassung physischer Daten (z. B. CAD-Daten, MS-Office-Dokumente), demFormular zur Bereitstellung der Item-spezifischen Attribute und der Item Revision zurVerwaltung von Änderungsständen. Die Item Revision ist dem Item untergeordnetund beinhaltet ebenfalls Datasets und Formulare. Ein Item kann mehrere Revisionenbesitzen. Abbildung 96 veranschaulicht diese Struktur. Abbildung 96: Allgemeine Datenablagestruktur von Teamcenter 100

Mit den genannten Items und ihren Unterordnern lassen sich die Bauteilgeometrienproblemlos in Teamcenter hinterlegen. Für die Ablage von Simulationsdaten wirdallerdings ein Konzept benötigt, welches zum Ersten die gegebenen Standards desPDM-Systems verwendet, zum Zweiten die Anbindung und einheitliche Ablage vonDaten 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 vierItemtypen zur Verfügung (Abbildung 97). Abbildung 97: Itemtypen für die Ablage von SimulationsdatenMit dem Itemtyp Item wird die Bauteilgeometrie verwaltet. Das Analyse-Item spei-chert Parameter zur jeweiligen Simulation, wie zum Beispiel die Simulationsart oderdas verwendete Werkzeug. Im Model-Item werden die Inputdaten für die Simulationabgelegt und unter dem Result-Item können die Ergebnisse gespeichert werden. ImVIPROF-Projekt werden lediglich die ersten drei Objekte verwendet. Die Ergebnissewerden direkt am Analyse-Objekt angehängt, wodurch auf das Result-Item verzichtetwerden kann.Zusätzlich zu den Standarditemtypen für die Simulationsdaten wurde für das ProjektVIPROF eine Struktur entwickelt (siehe Abbildung 98), die sich am Ablauf einerComputersimulation mit den drei Schritten Preprocessing (Input), Solving, Postpro-cessing (Output) orientiert. 101

Abbildung 98: Aufbau der Ablagestruktur für SimulationsdatenDas Preprocessing bei einer Simulation beinhaltet die Dateneingabe. Daher enthältdieser 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 gleichnamigenOrdner können Daten zur Programm- und Solverversion, als auch Daten zum Bear-beiter gespeichert werden. Das Postprocessing bezeichnet die Nachbearbeitung vonErgebnissen 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 derStrukturmanager und zum anderen die Fertigungsprozessplanung verwendet. ImStrukturmanager wird ein Fahrzeug mitsamt der Geometrie im Aufbau zusammen-gestellt (Abbildung 100). 102

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

In der Fertigungsprozessplanung hingegen werden alle an einem Fahrzeugprojektausgeführten Prozesse abgebildet (Abbildung 101). Weiterhin werden die Inputdatenfür die Simulation und deren Ergebnisse bereitgestellt. Eine genauere Erläuterungder 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 inTeamcenter abgebildet werden. Dadurch lassen sich zu jeder Zeit alle im Systembefindlichen 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 automatisiertenSpeicherung 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 Schnittstellenverwirklicht, sodass weitere Simulationstools zu jedem späteren Zeitpunkt angebun-den werden können. Weiterhin sind über ein im PDM-System enthaltenes Workflow-system alle Teilprozesse voll- bzw. teilautomatisiert miteinander verbunden. Der 104

Fortschritt im Entwicklungsprozess ist dadurch jederzeit von allen Prozessbeteiligteneinsehbar und nachvollziehbar.3.7.4 Ableitung von Referenzprozessketten zur DatenablageZiel 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, dienach unterschiedlichen Detaillierungsstufen unterteilt ist. Dabei wurden Übersichts-modelle, Grobmodelle, Detailmodelle und Workflowmodelle unterschieden. DerÜberblicksprozess veranschaulicht die gesamte durchgängige Prozesskette mit denHauptfunktionen. Jede Funktion wird durch hinterlegte Grobmodelle beschrieben, dieden 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 ModelldatenbankEine Aufgabe der Prozesskettenmodellierung ist es, alle möglichen Pfade für dieProzesskette abzubilden. Falls in einigen Teilgewerken die entsprechenden Zielgrö-ßen nicht erreicht werden können, müssen entsprechende Rücksprünge definiertwerden. Abbildung 103 zeigt mögliche festgelegte Rücksprungvarianten, die in den 105

Referenzprozessketten teilweise Berücksichtigung finden. Diese Referenzprozess-ketten bilden die Basis für die Steuerung des Gesamtprozesses. Abbildung 103: Festgelegte ProzessvariantenEin weiterer Schwerpunkt lag auf der Festlegung einer einheitlichen standardisiertenDatenablage 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 unterschiedlichenStrukturen, welche im Abschnitt 3.7.3 erläutert wurden, verdeutlicht. Abbildung 104: Simulationsprozessablauf mit Datenbereitstellung und Datenablage 106

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 Ergebnisseder Simulation werden anschließend zurück in das PDM-System und somit in dieentsprechenden 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 VIPROFDer Prozess beginnt mit der Vergabe der Simulationsaufgabe an den Planer. DessenAufgabe ist die Beschaffung aller für die Simulation notwendigen Eingabedaten undderen 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ührtder Berechner die eigentliche Simulation durch. Nach Abschluss der Arbeiten legt erdie relevanten Simulationsergebnisse im PDM-System ab. Beim Einlesen der Datenerfolgt eine automatische Datenkonvertierung, die für die Datenübertragung zwi-schen den Systemen notwendig ist. Anschließend führt der Planer einen Freigabe-prozess durch, bei dem er über die Güte der Simulationsergebnisse entscheidet. Die 107

Bewertung wird mit Hilfe einer Statusampel im PDM-System dargestellt. Um diesenReferenzprozess jeweils standardisiert ablaufen zu lassen, bietet sich eine Automati-sierung mittels eines Workflows an.3.7.5 Automatisierung von Referenzprozessketten mittels WorkflowsHauptziel der Workflowfunktion ist die schnelle Abarbeitung von Aufgaben in einervorgegebenen Reihenfolge. Es werden Aufgaben vom Workflowmanagementsystemvergeben 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, strukturierteProzesse, 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 WorkflowsystemsDie Modellierungskomponente dient der grafischen Beschreibung von Prozessenund deren Automatisierung. In der Definitionsphase werden hier die Abfolge der Auf- 108

gaben festgelegt und die Bearbeiter über das Rollenmodell zugeordnet. Weiterhinmü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 Steuerungder Prozesse steht die Ausführungskomponente zur Verfügung. Sie startet, steuertund protokolliert den Workflow. Dabei kann jeder Workflowprozess mehrfach für un-terschiedliche Objekte gestartet werden. Die Ausführungskomponente ist dabei alsein Service definiert, der eine Laufzeitumgebung zur Ausführung einer Workflowin-stanz zur Verfügung stellt. Sie regelt auch die Interaktion mit den Anwendern. DieAnweisungen entsprechend dem gestarteten Workflow werden den Anwendern in sogenannten Eingangskörben als Tätigkeitslisten oder offenen Tasks zur Verfügunggestellt. 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 sichnur 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 oderteilautomatisch, d.h. mit einer Benutzerinteraktion, ausgeführt werden. Der Nutzerwählt dabei beispielsweise den nächsten Bearbeiter aus. Das Workflowsystem über-nimmt hingegen die Kontrolle der Informationsverteilung. 109

Abbildung 107: Grundprinzip Workflow: AutomatisierungsgradAuf Basis der modellierten Referenzprozessketten werden die Workflows abgeleitetund mit Hilfe des im PDM-System integrierten Workflowsystems implementiert. Deroben 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 Abarbeitungerfolgt jedoch durch den Mitarbeiter. Entscheidungen wie die Auswahl des Planersund des Berechners, die Beschaffung der Inputdaten, die Durchführung der Simulati-on, die Ablage der Outputdaten sowie die Entscheidungen der endgültigen Freigabewerden durch den jeweiligen Bearbeiter durchgeführt und vom Workflow gesteuertund kontrolliert. Die Datenkonvertierung als auch das Setzen des Status kann an-schließend wieder automatisch durch den Workflow erfolgen. Die verschiedenen Au-tomatisierungsgrade des Simulationsreferenzprozesses sind in Abbildung 108 veran-schaulicht zusammengefasst. 110

Abbildung 108: Übersicht der voll- und teilautomatisierten SDM-ProzesseIm Projekt wurden mehrere Workflows implementiert, welche auf den von der TUChemnitz 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, Konvertierungenoder Statuszuweisungen sein. Für den Bereich der Umformsimulation zeigt Abbil-dung 109 den Workflow wie er von ARC Solutions in Teamcenter implementiert wur-de. 111

Abbildung 109: Workflowablauf für UmformsimulationIm Einzelnen ist der Ablauf wie folgt umgesetzt worden. Nachdem ein Objekt inTeamcenter ausgewählt und der Workflow gestartet wurde, wird der Status Rot demObjekt zugewiesen. Einem Status können unterschiedliche Berechtigungen ange-hangen werden. In diesem Beispiel können von nun an keine Änderungen mehr anden übergebenen Objekten vorgenommen werden. Die Objekte sind für die weitereBearbeitung gesperrt. Damit wird sichergestellt, dass nur Änderungen von den amProzess 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 Personoder Gruppe automatisiert zuzuweisen, dies erst zur Laufzeit des Prozesses manuelldurch den Planer vergeben zu lassen. Auch im folgenden Prozessschritt Umformsi-mulation überprüfen wurde ein Anwender als auszuführende Person definiert. Hiererhält der Planer die Aufgabe die Ergebnisse der Simulation zu verifizieren und diesin einem Formular zu dokumentieren. Der Workflowschritt Check Prüfformular wirdnun vom System ausgeführt. Dafür wurde ein Actionhandler implementiert, welcherdas 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 Workflowfür das Umformen ist in diesem Fall dann abgeschlossen. Als Ergebnis erhält mandas Start-Objekt der Simulation mit Ergebnisfiles und Status. Die sich anschließen- 112

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 dieProzessschritte 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 somiteinander gekoppelt werden können, dass sie wie ein zusammenhängender Ablaufdes Gesamtprozesses wirken. Einzelne Prozessschritte werden somit weitestgehendautomatisiert miteinander verbunden und ausgeführt. Manuelle Übertragungen ent-fallen und der Gesamtprozess wird effizienter. Durch die Vergabe eines Status nachjedem Teilprozess kann nachvollzogen werden, ob die Simulation erfolgreich waroder Anpassungsbedarf, zum Beispiel in Form einer Konstruktionsänderung, besteht.Der Status orientiert sich dabei am Ampelsystem mit den Farben Rot, Gelb undGrün. Das Workflowsystem übernimmt auf diese Weise die Steuerung der gesamtenSimulationsprozesskette.Die Entwicklung der konsistenten Datenablage und deren Automatisierung mittelsWorkflows ist eine Voraussetzung für die Realisierung einer durchgängigen Simulati-onsprozesskette. Sie ermöglicht eine vollständige Datenablage aller anfallenden Da-ten und damit eine Verfügbarkeit in allen Bereichen. Durch die Bildung von Refe-renzprozessketten und deren Automatisierung wurde eine durchgehend standardi-sierte Datenablage realisiert. Somit leisten die durchgeführten Arbeiten einen ent-scheidenden Beitrag zu einer durchgängigen, digitalisierten und kooperativen Ent-wicklungs- und Produktionsplanung.3.7.6 Kopplung der Prozesssimulation Umformen – Fügen – LackierenEines der Ziele des Projektes war es die verschiedenen Simulationen für das Um-formen, Fügen und Lackieren miteinander zu verbinden und die Ergebnisdaten desVorgä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 spezielleKonverter implementiert (vgl. Kapitel 3.5.2, 3.6.3 und 3.6.4). Beide Konverter wurdendurch ARC Solutions in den Gesamtprozess integriert und mittels implementierter 113

Skripte so eingebettet, dass der Ablauf dieser Konverter vom Anwender unbemerktim Hintergrund von statten geht. Dazu wurde in der Teamcenter Applikation CAEManager eine Toolkonfiguration erstellt, welche es ermöglicht den Datenim- und Ex-port sowie die Konvertierungen automatisiert umsetzen zu lassen. Hierfür wurdenDefinitionen erstellt, die festlegen, welche Daten aus welchen Teamcenter Objektengebraucht, welche Programme mit welchen Parametern gestartet und welche Skripteausgeführt werden sollen. Ebenfalls wurden die Skripte, die den Ablauf der Konvertermanagen 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 Simulationen3.7.7 VIPROF Modulcockpit zur Erhöhung der Transparenz im Entwicklungs- prozessIm 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üreine bessere Transparenz dieser Ergebnisbewertung innerhalb eines Fahrzeugpro-jektes, in dem alle Simulationsergebnisse aufgeführt werden, sollte ein Modulcockpit 114

entwickelt werden. In diesem Cockpit soll es möglich sein möglichst auf einen Blickden 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 ModulcockpitDa im PDM-System noch kein vergleichbares Modul existiert musste eine völlig neueApplikation 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 denaktuellen Entwicklungsstand gegebenen werden. Über einen Viewer im rechten Teilder Applikation können bereits vorhandene Ergebnisse visualisiert werden.Literatur[MÜHL05] zur Mühlen, M.; Hansmann, H.: Workflowmanagement. In: Becker. J.; Kugeler, M.; Rosemann, M.: Prozessmanagement. Ein Leitfaden zur Prozessorientierten Organisationsgestaltung. 3. Auflage, Berlin u.a.: Springer-Online, 2005, S. 373-407. ISBN 3 540 23493 4 115

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

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 liegtdarin, dass auf diese Weise die Praxisrelevanz des Vorhabens gesichert wird.Die Rolle der Automobilindustrie als Erstanwender, so genannte „early Adopter“, hatsich hier wie in so vielen Bereichen der Virtuellen Techniken erneut gezeigt. Damithat 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) inFellbach (siehe Abbildung 112). Abbildung 112: Virtual Engineering im ÜberblickVirtuelle Techniken sind heute aus der fertigenden Industrie kaum mehr wegzu-denken. Schon vor vielen Jahren ist erkannt worden, dass es ein grundsätzlichesProblem der Produktentwicklung ist, dass die Zeitpunkte der Kostenfestlegung undder Kostenentstehung teils weit auseinanderliegen [Munroe]. Festgelegt werden dieKosten eines Produkts vor allem während der Entwicklung, wohingegen die Kostenschwerpunktmäßig in der Produktion entstehen. Materialkosten, Arbeitskosten undGemeinkosten bilden hier die größten Positionen. Gleichzeitig ist bekannt, dass nichtunerhebliche Kosten dadurch entstehen können, dass erst spät im Entwicklungs-prozess Änderungen am Produkt vorgenommen werden müssen. So kann sich bei- 117

spielsweise erst spät herausgestellt haben, dass es Probleme bei der Fertigbarkeitgibt: Das Produkt oder Teile lassen sich nur unter großem Aufwand oder gar nichtwie 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 mitdem Projektfortschritt ansteigt. Darüber hinaus gilt: je komplexer das Produkt ist, des-to höher werden Änderungskosten angesetzt [Aberdeen]. Wie existentiell wichtig dasThema für die Wirtschaft ist, lässt sich auch daran ablesen, in welchem Umfang dieAnzahl 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. Zielsetzungdes 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 Montierbarkeitkönnen zu den überprüften Eigenschaften zählen. Simulation und Visualisierungkommen zum Einsatz. Ein stringentes Produktdatenmanagement sorgt dafür, dasssämtliche Prozess-Schritte mit Daten aus vorhergehenden Überprüfungen versorgtwerden.Damit wird klar, dass Virtuelle Techniken nicht nur allein für die Automobilindustrieund 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 zuden potentiellen Anwendungsfeldern virtueller Techniken.Neben den klassischen ingenieurtechnischen Feldern, die den Maschinenbau in derVergangenheit stark prägten, gewinnt das Design immer mehr an Bedeutung. DasDesign umfasst nicht nur die technisch-funktionale sowie Benutzer-gerechte Gestal-tung, sondern mittlerweile eben auch eine ansprechende und wiedererkennbareForm- und Farbgebung. Dahinter steckt die Bestrebung, das Design neben derTechnologie als Differenzierungsmerkmal zu nutzen. Durchdachtes Design zur Stei-gerung der Kundenzufriedenheit und hervorragendes Design als Qualitätsanmutungwerden künftig eine größere Rolle spielen. Einhergehend steigt die Produktkomplexi-tät erneut, ebenso wie die Qualitätsanforderungen. 118

Das Virtual Dimension Center (VDC) Fellbach hat innerhalb des Projekts VIPROFeine Umfrage unter Maschinenbau-Unternehmen durchgeführt. Konkret ging es umdie Fragestellung, inwiefern Prozesse des Umformens, Fügens oder Lackierens imUnternehmen durchgeführt werden, wer diese Prozesse auslegt und ob Simulations-werkzeuge zur Unterstützung eingesetzt werden. Dabei traten folgende Ergebnissezu 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-Ergebnissefür den Maschinebau folgende Schlussfolgerungen: die Anwendungsbereiche Um-formen und Fügen besitzen die größere Bedeutung. Interesse an Simulationstechni-ken ist vorhanden, aber auch eine Unsicherheit bezüglich möglicher Einsatzpotenzia-le. Zur Unterstützung des Maschinenbaus zählen somit nicht nur technische Lösun-gen, sondern auch und insbesondere organisatorische Hilfestellungen.Literatur[Munroe] The design determines the Cost, Munroe & Associates, http://www.leandesign.com/leandesign.html[Visintin] Visintin, Gabi: Return on Investment bei VR- und Simulationslösungen. In: cad-cam, Carl-Hander-Verlag, 2003 119

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

4 Zusammenfassung der Ergebnisse4.1 Bewertung der ErgebnisseDer 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. Ergebnisseaus einer gewerkespezifischen Auslegung flossen kaum in die darauffolgenden Ge-werke ein. Allein in die Crash-Simulation wurden bereits in einigen wenigen Fällenplastische 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 konstanteBlechdicken 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 ProduktsimulationWeiterhin bestand eine große Herausforderung darin, dass für die Durchführung deretablierten inkrementellen Umformsimulation ein hoher Modellierungs- und Berech-nungsaufwand erforderlich ist und diese deshalb erst zu einem relativ späten Zeit- 121

punkt im Produktentwicklungsprozess durchgeführt wird. Für die Absicherung derHerstellbarkeit 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 weitgehendentwickelt ist. Hier haben insbesondere der Test und die erfolgreiche Einbindung sogenannter 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 derTechnik:Ziel des VIP-ROF-Projektes: Abbildung 114: Vergleich von Ausgangssituation und Zielsetzung des VIPROF- ProjektesWeiterhin 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 undProzessabsicherung stärkt die Robustheit des Gesamtprozesses.Ein großer Fortschritt wurde dabei in der einheitlichen Ablage der Simulationsdatenim standardisierten XML-Format und der Entwicklung der dazu notwendigen Über-führungsroutinen erzielt (siehe Abbildung 115). 122

Stand des Simulationsdatenhand- Stand des Simulationsdatenhand- lings zu Beginn des Vorhabens lings, wenn die VIPROF-Ergebnisse bei VW implementiert sein werden Abbildung 115: Vorteile der gewerkeübergreifenden Übertragung und Ablage von SimulationsdatenDamit wird es möglich, die im Rahmen des Simulationsprozesses anfallenden Datenstandardisiert 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 derProzess nun effektiver im Hinblick auf Datenhandling und ermöglicht für die Zukunftdie Erweiterung der Prozesskette um weitere Simulationstools bzw. -anbieter undderen 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 seineQualität, da ein manueller Eingriff bei der Transformation, und damit eine potenzielleFehlerquelle, entfällt. Ebenso unterstützt der XML-Konverter den Konstrukteur undBerechner bei der Rücktransformation der ursprünglichen Daten aus dem XML, umeventuell 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 gelingteine frühzeitige Absicherung der fertigungsgerechten Produktgestaltung mittels• Durchgängiger Prozesskettensimulation• Berücksichtigung der Fertigungshistorie 123

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

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 hatder Planer bereits die Zielbauteilgeometrie der B-Säule aus der Produktstruktur inOperation 30 der Fertigungsprozessstruktur verlinkt.Beide Strukturen werden in diesem Projekt vom Planer erstellt und gepflegt. NachAbschluss der Simulation werden die Ergebnisse in die Fertigungsprozessstrukturverknüpft, da somit für alle folgenden Anwender und Prozesse die größtmöglicheTransparenz erreicht wird. Es ist leicht erkennbar, wie weit der Fertigungsprozessfortgeschritten 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-ObjektIm Teamcentermodul CAE-Manager kann dieses Objekt weiter bearbeitet werden.Hier existieren drei Reiter (Abbildung 117). Abbildung 117: CAE-ManagerIm Reiter Analyse wird das Analyse-Objekt mit all seinen Anhängen angezeigt. Unterdem Reiter Produkt werden alle Inputdaten, zum Beispiel die Geometriedaten, zudieser 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 anderenItem-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 zusammengestelltwerden. Diese Daten und Objekte beschafft er sich aus den anderen Strukturen, wiezum Beispiel der Fertigungsprozessstruktur und fügt sie dem Reiter Produkt im CAE-Manager hinzu (Abbildung 118). 125

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

Anschließend startet der Planer den Workflow Umformsimulation und hängt diesemdas 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 demBerechner zugestellt. Abbildung 122: Analyse-Objekt mit Status „Rot“In der Taskbox des Berechners befindet sich die Aufgabe zusammen mit einer Be-schreibung und dem angehängten Simulationsobjekt (Abbildung 123). 127

Abbildung 123: Taskbox des Berechners mit AufgabenbeschreibungVon hier ausgehend kann der Berechner nochmals überprüfen, ob alle relevantenDaten zur Verfügung stehen, und anschließend das Simulationsobjekt an den CAEManager senden. Im CAE Manager wurde bereits eine Konfiguration für das nunauszufü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 Teamcenterimportiert werden sollen. Diese Konfiguration wählt der Berechner nun aus und dasausgewählte Analyse-Objekt wird mit der entsprechenden Konfigurationsdefinitionverarbeitet. Im Hintergrund werden die Daten (Geometrie, Beschnittkurven, Material-datei, Umformmaschine,…) exportiert und ein Simulationswerkzeug gestartet. Lässtsich 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 abgelegtwird wie die Eingangsdaten. Durch Beendigung des Simulationstools wird der Pro-zess fortgesetzt. Die Konvertierung erstellt aus dem Ergebnis-File des Simulations-programms ein XML und daraus zusätzlich ein JT zur Visualisierung der Ergebnisse.Beide werden anhand von Skripten automatisch ausgeführt. Im Anschluss erfolgt der 128

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-ObjektDer 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 seinerTaskbox befinden sich nun eine Prüfaufgabe mit Analyse-Objekt samt Ergebnissenund 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 aufrot, gibt es Klärungsbedarf wie mit dem Bauteil weiterverfahren werden soll wird derStatus gelb gesetzt. Abbildung 125: Prüfbericht mit Statusvergabe 129

Nach Vergabe des Status beendet der Planer diese Aufgabe und der Workflow ist indiesem Fall ebenfalls beendet. Das Analyse-Objekt hat nun den entsprechendenStatus 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 FertigungsprozessstrukturDiese Abfolge der Arbeitsschritte wiederholt sich für alle nachfolgenden Simulatio-nen. Es fügt sich lediglich als Zwischenschritt das Mapping der Simulationsnetze,durch den SCAIMapper, ein. Dies wurde in Kapitel 3.2.2 bereits ausführlich beschrie-ben. 130

5 AusblickVolkswagen 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 aufBasis der Projektergebnisse realisieren. Die Software-Anbieter CADFEM und ESIwerden das SDM sowie Workflows zur Abbildung der Prozesskettensimulation miteigenen Tools umsetzen und vermarkten. Dabei werden auch Lösungen für den Mit-telstand erarbeitet, die ohne TEAMCENTER auskommen. Die Hochschulen werdendie Projektergebnisse für Forschung und Lehre nutzen.5.1 Ausblick VolkswagenKü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 Simulationendarauf 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 VWZur Verwertung der Projektergebnisse soll das Simulationsdatenmanagement abernicht komplett in das Produktdatenmanagement übernommen werden, da die Daten-haltung sonst zu unübersichtlich würde. Vielmehr wird ein separater File-Server fürdie Simulationsdaten vorgesehen. Bestimmte Simulationsstände werden dann imProduktdatenmanagement archiviert, so dass der Stand einer Produkt- oder Fahr- 131

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

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

Berücksichtigung der Umformhistorie erzeugt so nur verhältnismäßig wenig zusätzli-chen Bearbeitungsaufwand. Zum anderen ermöglicht diese Automatisierung eineweitreichendere Analyse der Prozess- und Designparameter in Sensitivitätsanalysen,Optimierungen und Robust Design Bewertungen.5.3 Transfer der Ergebnisse von ESI für Zulieferer mit VisualDSSDie in VIPROF erstmalig in dieser Breite aufgenommene Themenstellung der soge-nannten „End to End“ Prozesskette, stieß bei allen Vorträgen vor unseren Kundenund auch im Industriearbeitskreis auf lebhaftes Interesse der Beteiligten. Dies zeigtaus Sicht von ESI den Bedarf für Informationstage und vor Ort Demonstrationen derim 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 desCAD und der virtuellen Fabrik ist das JT-Format bereits gesetzter Standard der deut-schen Automobilindustrie. Die Vorteile der Weitergabe von CAE-Ergebnissen ohneKnow-how-Abfluss, gekoppelt mit der kostenfreien Viewer Lösung JT2Go kann hiernicht 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 Potentialim Rahmen der industriellen Forschungsförderung (AIF) einen nicht unwesentlichenBeitrag 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 daseigene 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ürftigenEinzelprodukten, wie der inkrementellen Umformsimulation, dem transientenSchweißen oder dem Crash noch eine Steigerung an Komplexität dar. Denn norma- 134

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 Richtlinienund 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ügenund Crash-Simulation reduzierten Prozesskette begegnet der Zielgruppe typischerSystemlieferanten sehr gut. Denn diese betrachten schon heute die notwendigenKomponenten- und Systemeigenschaften, z. B. der Türen oder des Vorderwagens inRelation 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 Modulcockpitonline 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-Projektentwickelten Methodik auch über anfängliche Bedenken hinweg zu einem positivenErgebnis führen. Denn die Integration in das Simulationsdaten- und ablaufmanage-ment vereinfacht die Unternehmensabläufe mittelfristig erheblich. Ein Zusatznutzenist sicherlich die revisionssichere, auditfähige Handhabung aller Daten und Prozesseohne auf die Papierform zurückgreifen zu müssen. Business Processes VisualDSS web client Rail RAIL ASSEMBLY Decision VisualDSS Database Making Tool Abbildung 131: Simulationsprozess- und Datenmanagement in VisualDSS 135

5.4 Ausblick der ARC Solutions GmbHDas 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 solldas Dienstleistungsangebot im Bereich Implementierung und Konfiguration um CAEAnwendungen in Teamcenter erweitert werden. In beiden Bereichen werden guteMarktchancen erwartet.Hinsichtlich einer CAE-Applikationsintegration inklusive Formatkonvertierung kannals Ergebnis des VIPROF-Projektes eine zusammengehörige Applikation samt For-matkonvertierung angeboten werden. Hierfür wird die Umsetzung des Modulcockpitsweiterverfolgt, 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 CAEWerkzeuge (NX) dienen. Die Betreuung, Implementierung und Konfiguration vonSchnittstellen für diese Anwendungen sind weitere positive Aspekte.5.5 Ausblick der Ostfalia HaWAn der Ostfalia HaW werden die Ergebnisse des Projekts VIPROF in die Ausbildungvon 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 derProduktentstehungsphase“ eingebunden.Das Institut für Produktionstechnik der Ostfalia HaW (IPT) wird die VIPROF-Ergebnisse auch weiterhin mit Hilfe des Vereins „Netzwerk Digitale Fabrik“ - imRahmen 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 entwickeltwerden. Ein Forschungsantrag wurde in der Förderlinie ProfilNT des BMBF gestellt. 136

Durch die durchgängige Virtualisierung der gesamten Prozesskette ist eine Basis fürzukü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 IPTmit 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 BerlinIn Zukunft könnten Mappingfunktionalitäten in den XML-Konverter eingebettet wer-den. Sollten z. B. die Funktionalität des SCAIMappers Einzug in den XML-Konverterfinden, und darüber hinaus XML- und JT-Konverter zusammengelegt werden, findeteine Verdichtung der am Prozess beteiligten Tools statt. Dies vermindert Fehlerquel-len bzw. hilft diese schneller zu finden, senkt den Koordinationsaufwand desPDM/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önntenBereiche für Materialdaten geschaffen bzw. Strukturen definiert werden, die beste-hende Elemente sogenannten Parts (also Elementgruppen) zuordnet. Dies erhöhtdie 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 nurschwer handhabbar sind. Eine Modularisierung der Daten in einzelne Bestandteileund 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 anderenbleiben unberührt.5.7 Ausblick Professur Virtuelle FertigungstechnikDie Professur für Virtuelle Fertigungstechnik schätzt die Ergebnisse dieses Projektesals positiv und insgesamt sehr gelungen ein. Es erfolgten bereits einige Publikatio- 137

nen in einschlägigen Zeitschriften sowie auf nationalen und internationalen Tagun-gen. Eine weitere Veröffentlichung ist für 2012 auf dem ProSTEP iViP Symposiumgeplant.Als Professur der Technischen Universität Chemnitz wird angestrebt, die guten Pro-jektergebnisse im Rahmen der Forschungs- und Lehraufgaben einzusetzen. Dabeikann 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 Studierendendie 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 Einbeziehungvon Simulationsergebnissen aus vorgelagerten Simulationen genauere Gesamter-gebnisse zu erzielen. Dabei sollen die im VIPROF-Projekt entwickelten Schnittstellenund der Konverter Anwendung finden. Eine solche Arbeitsweise zeigt den Studieren-den besonders stark die Wichtigkeit von Teamarbeit und häufiger Kommunikation beieiner abteilungsübergreifenden Projektbearbeitung.Zusätzlich sollen aufbauend auf den Ergebnissen aus dem Projekt zukünftige For-schungsvorhaben und Industrieprojekte beantragt werden. 138

6 ÖffentlichkeitsarbeitZur Information über das Projekt wurde die Projekt-Homepage www.projekt-viprof.deeingerichtet. Während der Projektlaufzeit wurde der Industriearbeitskreis "Virtualisie-rung" zum Erfahrungs- und Informationsaustausch gegründet. Der Arbeitskreis waroffen 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 AutorenJahr 2009 Fellbach VDC-Newsletter und Pres- VDC Fellbach semeldungen z. B. im Newsletter Kompetenz- netze Deutschland16.-18.06. Magdeburg Fachtagung Digitales En- Pinner (VW) et al.2009 gineering, Fraunhofer Wis- senschaftstageTitel: Durchgängige Virtualisierung der Entwicklung und Produktion von Fahrzeu- gen16.-18.06. Veröffentlich- 12. IFF-Wissenschaftstage ARC Solutions2009 ungTitel: Projektstand und Ergebnisse zum VIPROF-ProjektHerbstaus- Veröffentlich- ProduktDatenJournal Nr. 2 Awiszus, Bolick (VIF),gabe 2009 ung / 2009, S. 39 – 43, Brylla (ARC Solutions), Pin- ISBN/ISSN: 1436-0403 ner (VW), Schulz (TU Berlin)Titel: Produktdatenmanagement in der Entwicklung und Produktion von Fahrzeu- gen, Heft 2, S. 39 – 43, ISSN 1436-040319.11.2009 Leipzig ANSYS Conference und Pinner (VW) et al. 27. CADFEM Users´ Meet- ingTitel: Einsatz inverser Solver innerhalb der Prozesskettensimulation im Bereich Karosseriebau19.11.2009 Leipzig CAE-Forum auf dem 27. Kulp (VW) CADFEM Users´ MeetingTitel: Impulsvortrag: Integrierte Prozesskettensimulation bei der Karosseriehers- tellung im Projekt VIPROF 139

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

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

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

Abschlussbericht des Projekts Viprof

by Virtual Dimension Center (VDC) Fellbach on Jul 31, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics