Abschlussbericht des Projekts Viprof

  • Published on
    24-Jan-2015

  • View
    1.113

  • Download
    0

DESCRIPTION

Das Ziel des Vorhabens Viprof bestand in der Verknpfung von Produktentwicklung und Fertigungstechnik zu einer durchgngigen, digitalisierten und kooperativen Entwicklungs- und Produktionsplanung. Die erforderlichen CAE-Systeme wurde bergreifend integriert und eine fertigungsgerechte Konstruktion von Bauteilen ermglicht, die bisher aufgrund organisatorischer und prozessualer Unzulnglichkeiten nicht realisiert werden konnte. Informationen ber das Produkt- und Anlagenverhalten standen in einem frhen Stadium der Produkt- und Prozessentwicklung zur Verfgung. Der gesamte Produktionsprozess wurde in einer durchgngigen Prozesskettensimulation abgebildet, wobei sich das Projekt auf die Kopplung der Prozesse Umformen, Fgen und Lackieren beschrnkte.

Transcript

  • 1. Gemeinsamer FuE-Abschlussbericht des VerbundprojektesDurchgngige Virtualisierung der Entwicklung und Pro- duktion von Fahrzeugen (VIPROF) Frderkennzeichen: 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 (Ingenieurbro Mager, Unternehmensberatung)Januar 2012

2. Inhaltsverzeichnis1 Einfhrung, Motivation und Zielstellung ............................................................... 42 Ablauf des Vorhabens ......................................................................................... 93 Lsungsanstze, durchgefhrte Arbeiten und Teilergebnisse ........................... 123.1 berblick Prozesskettensimulation .............................................................. 123.2 Datenbertragung in der Prozesskette (Ostfalia HaW) ................................ 133.2.1 Simulationsprogramme in der Prozesskette .......................................... 133.2.2 Mapping ................................................................................................. 143.2.3 Sensitivittsanalyse ............................................................................... 243.3 Teilprozesskette Umformen und Fgen (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 Sensitivitt der Datenbergabe in Relation zur Netzfeinheit .................. 34 3.3.5 Simulation des Schweiverzugs mit dem Weld Planner ........................ 37 3.3.6 Sensitivitt des Schweiverzugs hinsichtlich der aus der Fertigungshistorie bertragenen Gren ............................................... 38 3.3.7 Schweiverzugssimulation mit der Methode der Neuvernetzung .......... 423.4 Simulation der Lacktrocknung in der Prozesskette (CADFEM) .................... 433.4.1 Ergebnisse der Sensitivittsanalyse ...................................................... 443.4.2 Untersuchung von Einflssen des Bake-Hardening-Effektes ................ 493.4.3 Zusammenfassung der Ergebnisse von CADFEM ................................ 533.5 Abgleich der Simulationsprozesskette an Praxisbeispielen (VW) ................ 553.5.1 Katalog gewerkespezifischer Eingangsgren ...................................... 553.5.2 bertragung von Simulationsdaten mit XML-Konverter ......................... 563.5.3 Vergleich OneStep- und inkrementelle Umformsimulation .................... 613.5.4 Bewertung der Prozesskettensimulation................................................ 663.5.5 Validierung der Prozesskettensimulation ............................................... 733.5.6 Modulcockpit.......................................................................................... 763.6 Strukturierte Ablage heterogener Daten im Kontext vonWiederverwendbarkeit und Weiterverwendbarkeit (TU Berlin) .................... 783.6.1 Allgemeines ........................................................................................... 783.6.2 Konversion............................................................................................. 793.6.3 Das VIPROF-XML-Datenformat ............................................................ 823.6.4 Funktionsweise und Begrenzungen des XML-Konverters ..................... 89 2 3. 3.7 Entwicklung einer systembergreifenden Datenablage im PDM-System zur Realisierung einer durchgngigen Simulationsprozesskette (TU Chemnitz, ARC Solutions GmbH) ......................................................... 92 3.7.1 Problemstellung und Ziele ..................................................................... 92 3.7.2 Durchgngiges 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 Fgen Lackieren ...... 113 3.7.7 VIPROF Modulcockpit zur Erhhung 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 durchgngigen 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 fr 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 fr Bildung und Forschung im Programm Management und Virtualisie-rung der Produktentstehung im Rahmenkonzept Forschung fr die Produktion vonmorgen gefrdert und unter der Projekttrgerschaft des Karlsruher Instituts frTechnologie (KIT) durchgefhrt. Die Verantwortung fr den Inhalt dieser Verffentli-chung liegt bei den Autoren.3 4. 1 Einfhrung, 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, krzer werdenden Produktlebenszyklen und einer Zu-nahme an Produktvarianten ausgesetzt. Gerade die steigenden Anforderungen anVerbrauchseffizienz und CO2-Reduzierung werden zuknftig verstrkt zu weiterenFahrzeugvarianten mit alternativen Antrieben sowie Leichtbaukarosserien fhren. 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 erfllen, sind neue Strategien in der Pro-duktentwicklung erforderlich. Dazu zhlen u.a. verschiedene Strategien zur Gleichtei-lenutzung in der Pkw-Karosserie. Whrend man frher eine reine Plattformstrategieverfolgte, setzt man heute schon verstrkt auf Module (Lenkung, Motor, Getriebe,Interieur), die ber verschiedene Fahrzeugklassen eingesetzt werden. Fr 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 fr Produkt und Prozess sichert die konzernweite Kompati- 4 5. bilitt 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 Komplexitt, die aus dieser Strategie erwchst, zuknftig noch beherrschenzu knnen, mssen vor allem Techniken und Strategien zum Produktdatenmanage-ment weiterentwickelt werden. Weiterhin muss im verstrkten Mae 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 mageblichen Produktgestaltung. Weiter-hin ist ein prozessbergreifender Ergebnistransfer (Umformung, Fgen, Lackierung)auf Grund fehlender Schnittstellen und methodischen Unterschieden in den Prozess-simulationen bisher nicht mglich. Darber hinaus werden fertigungstechnische Ein-flsse auf die Produkteigenschaften (insbesondere die Crash-Performance) immernoch nicht detailliert erfasst und whrend der Produktentwicklung bercksichtigt.[PIN109] 5 6. Aufbau AggregateFahrwerk ..Entwicklungsdisziplinen Crash BetriebsfestigkeitAerodynamik VirtuelleProduktentwicklung Steifigkeit Aeroakustik ...... Simulationsmethoden Produktentwicklung Produktlastenheft, Konstruktionsdaten, Stcklisten etc. Umformsimulation Fgesimulation Lackiersimulation VirtuelleProzessabsicherung Ergonomiebetrachtung Giesimulation ...... Simulationsmethoden ProzessabsicherungUmformprozesse KarosseriebauLackierung MontageAbbildung 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. Fr die Entwicklung und Planung von Produkten, Maschinen undAnlagen sind leistungsfhige Methoden und Softwareapplikationen entstanden. Ge-rade kritische Bereiche, wie z. B. Festigkeitsbetrachtungen, Umformtechnik, thermi-sche Belastungen oder Schweianwendungen, sind inzwischen durch Simulations-werkzeuge abgedeckt, mit denen virtuell Optimierungen vorgenommen werden kn-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 Insellsungen, die einen bestimmten Prob-lembereich behandeln, und nicht um durchgngige Planungsinstrumente. [PIN109]Es fehlt insbesondere eine auf der Informations- und Kommunikationstechnologie(IKT) basierte Verknpfung zwischen der Konstruktion und Entwicklung auf der einenSeite und der Fertigungsplanung auf der anderen Seite. Bisher knnen Daten zwi-schen den Simulationsprogrammen fr einzelne Prozesse meistens nur von Handbertragen werden. bertragungs-Tools wenn berhaupt vorhanden verbindenmaximal zwei Glieder der Simulationskette, wie z. B. der SCAI-Mapper zwischen Um-form- und Crash-Simulation. Automatische Verknpfungen 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 knnen bisher nderungen, die sich in einem Bereich 6 7. ergeben, nur mit hohem Aufwand in anderen Bereichen bercksichtigt werden. Daprozessbergreifende Werkzeuge fehlen, knnen Fehler in der Produktentwicklungnach wie vor erst spt aufgedeckt werden und verursachen hohe Kosten. [PIN109]Daher bestand das Ziel des Projekts VIPROF in der Verknpfung von Produktent-wicklung und Fertigungstechnik zu einer durchgngigen, digitalisierten und koope-rativen Entwicklungs- und Produktionsplanung. Ein besonderer Schwerpunkt wurdeauf die durchgngige Verknpfung der Simulationen des Umformens, Fgens undLackierens gelegt. Die Auswirkungen der Bercksichtigung der Fertigungshistorie aufdie Produkteigenschaften sollten in der Crash-Simulation bewertet werden.Am Projekt haben die folgenden Partner teilgenommen:Partner / ProfilBeitrag im ProjektCADFEM GmbH Koordination des Verbundprojektes, Integration der Lackier-(Software-Haus) trocknungssimulation VPS/DRY in die Prozesskettensimula-tionESI GmbHIntegration der Umform- und Fgesimulation in die Prozess-(Software-Haus) kettensimulationARC Solutions GmbHImplementierung von Daten- und Variantenmanagement,(Dienstleister) Umsetzung des Workflow-ManagementsVW AG Erstellung Lastenheft, Erprobung und Validierung der Pro-(Anwender)zesskettensimulationITP Ostfalia HaWUmformsimulation, 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 fr Wirtschafts- Entwicklung Datenarchitektur, Datenmodellierung und -informatik undintegration, Schnittstellenkonzeption, Datenmapping, Stan-Quantitative Methoden dardisierung der Simulationsdatender TU Berlin (F&E)VDC FellbachAnalyse bei den meist mittelstndischen Mitgliederfirmen zur(Dienstleister) Bedarfslage hinsichtlich einer Prozesskettensimulation, Auf-bau Web-Prsenz, Aufbau eines Industriearbeitskreises Vir-tualisierung.7 8. Literatur:[PIN109] Pinner, S. et al.: Durchgngige Virtualisierung der Entwicklung und Produktion von Fahrzeugen, Fachtagung Digitales Enginee- ring, Fraunhofer Wissenschaftstage, 16.-18. Juni, Magdeburg, 2009.[PINSB11]Pinner, S.; Steinbeck-Behrens, C.: bersicht Prozesskettensimu- lation. 2. VIPROF Industriearbeitskreis, 22. November, Stuttgart, 2011.8 9. 2 Ablauf des VorhabensDas Vorhaben war in 12 Arbeitspakete (AP) eingeteilt, die in Tabelle 1 aufgefhrtsind. Ein Pert-Diagramm des Arbeitsplans mit einer Kennzeichnung der mehr daten-oder mehr prozessbezogenen Arbeitspakete ist in Abbildung 4 gezeigt.APTitelFederfhrungMitarbeit1 Analyse des Ist-ZustandesVW Alle Partner2 Untersuchung und Bewertung der Pro-IPTCADFEM, ESI,zessgren in der ProzessketteVW3 Aufbau Architektur fr Daten- und Varian- TUB VIF, ARC, VWtenmanagement4 Kopplung der Prozesssimulationen Um- TUBAlle Partnerformen Fgen Lackieren5 Implementierung Daten- und Varianten-ARCCADFEM, ESI,management als VIPROF-ModuleVW, VIF, TUB6 Bewertung der Ergebnisgte VW CADFEM, ESI,IPT7 Definition von Referenzprozessen und VIFARC, VW, IPT,-modellen fr durchgngige Prozesskette TUB, VDC8 Erweiterung der Prozesskette mit komp- CADFEM ESI, ARC, IPTlexen Modellen9 Test und Validierung VW CADFEM, ESI,ARC, VIF10Entwicklung VIPROF-ModulcockpitARCVW, IPT, VIF, TUB11Verbreitung der ProjektergebnisseVDCAlle Partner12ProjektmanagementCADFEM Alle PartnerTabelle 1: bersicht der Arbeitspakete und der Verantwortlichkeiten(IPT = Institut fr Produktionstechnik der Ostfalia HaW, VIF = Professur Virtuelle Fertigungstechnik, TU Chemnitz,TUB = Institut fr Wirtschaftsinformatik und Quantitative Methoden der TU Berlin)9 10. 1. Analyse des 12. ProjektmanagementIst-Zustandes2. Untersuchung / Bewertung Prozessgren3. Aufbau4. Kopplung derDaten- Prozess-architektursimulationen 5.Implementierung 6. BewertungVIPROF-ModuleErgebnisgte8. Erweiterungmit komplexen 7. Definition Modellen11. Ver- Referenzpro-breitungzesse und9. Test und Vali- der Er- -modelledierunggeb-nisse 10. Entwicklung VI- PROF-Modulcockpit Abbildung 4: Pert-Diagramm des Arbeitsplanes (Daten Prozesse)Entsprechend der Einteilung Daten und Prozesse wurden zu Beginn des Projek-tes die Arbeitsgruppe Daten (VW, ARC, VIF und TUB), die eine Bestandsaufnahmedes PDM-Systems durchfhrte, und die Arbeitsgruppe Mapping (CADFEM, ESI, VWund IPT), die sich mit dem SCAIMapper1 und den Sensitivittsanalysen (AP 2) be-fasste, gegrndet. Die Arbeitsgruppe Mapping verstndigte sich darauf, den SCAI-Mapper im VIPROF-Projekt einzusetzen. Das IPT stand hierzu im Kontakt mit demFraunhofer SCAI-Institut, das sich bereit erklrte, projektspezifische Anpassungenam SCAIMapper vorzunehmen.1Mit dem SCAIMapper knnen durch Modellinterpolation die Umform- und Crash-Simulation gekop-pelt werden. Diese Software wurde vom Fraunhofer SCAI-Institut und dem ISD der Universitt Stutt-gart entwickelt. 10 11. Als Anwendungspartner lieferte die VW AG geeignete Musterbauteile (siehe Abbil-dung 5) zur Bestandsaufnahme von Daten und Prozessen und zur spteren Validie-rung der Prozessverkettung. Die notwendigen Bauteil- und Prozessdaten wurden vonVW erhoben. Den Partnern wurden die CAD-Daten und Prozessbeschreibungen frdie Musterbauteile zur Verfgung 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-Sule mit Schwellerverstrkung, danur dort Laserschweiverfahren eingesetzt werden. Der Sitzquertrger ist fr dieCrash-Simulation relevant. Um den Schweiverzug zu analysieren, besteht bei VWfr die gewhlte 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 htten aufgedeckt werden knnen, wie es bei Neukonstruktionen derFall wre, da alle Teile auskonstruiert und getestet waren.11 12. 3 Lsungsanstze, durchgefhrte Arbeiten und Teiler-gebnisse3.1 berblick ProzesskettensimulationIm Rahmen der virtuellen Absicherung werden heute fertigungstechnische Einflsseauf die Produkteigenschaften noch nicht detailliert erfasst und whrend der Produkt-entwicklung bercksichtigt. Die Herstellungsprozesse haben jedoch einen umfangrei-chen Einfluss auf die Produkteigenschaften und mssen in der Simulation berck-sichtigt werden, denn die Produkteigenschaften resultieren aus der Summe derdurchlaufenen Prozesse, welche sich gegenseitig berlagern und beeinflussen. Der-artige Einflussgren fr den Bereich Karosseriebau sind in Abbildung 6 dargestellt.Abbildung 6: Einflussgren der Fertigungsprozesse auf die Produkteigenschaften [PIN209]Besonders Eigenspannungen und Verzug bedingen sich gegenseitig und knnensich 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 durchthermische Fgeverfahren,12 13. Induzierung thermischer Spannungen in die Karosserie durch hohe Temperaturenim Lacktrockner (lokal unterschiedliche Wrmekapazitten bedingt durch dieBlechdickenverteilung in den Bauteilen).Zuknftige Karosseriekonzepte werden - getrieben vom Leichtbau - immer komple-xer. Als Beispiel sei hier der zunehmende Einsatz an pressgehrteten Strukturbautei-len oder der immer hufiger eingesetzte Materialmix in heutigen Automobilkarosse-rien genannt. Moderne Materialien, wie z. B. Mehrphasensthle, besitzen Eigen-schaften, die vorrangig von der Fertigungshistorie abhngig sind. Umso bedeutenderwird es zuknftig sein, die aus den durchlaufenen Herstellungsprozessen resultie-rende Fertigungshistorie der Bauteile und Baugruppen bei der Simulation der Pro-dukteigenschaften durch Kopplung der Simulationstools zu bercksichtigen. [PIN209]3.2 Datenbertragung in der Prozesskette (Ostfalia HaW)Um das Ziel einer durchgngigen Prozesskette erreichen zu knnen, mssen dieeinzelnen Simulationen miteinander verbunden werden. Die dafr notwendige Da-tenbertragung besteht aus den zwei Teilbereichen Konversion und Transformation.Der Bereich der Konversion wird in diesem Kapitel nur angerissen; er wird in Kapitel3.6 ausfhrlich dargestellt. Der Bereich der Transformation wird im Abschnitt 3.2.2nher erlutert.Da der Zeitaufwand fr die Datenbertragung wirtschaftlich bleiben sollte, ist es sinn-voll zu ermitteln, welche Ergebnisdaten die nachfolgenden Simulationen wie starkbeeinflussen. Dazu wird eine Sensitivittsanalyse (Abschnitt 3.2.3) durchgefhrt. An-hand der Ergebnisse kann dann entschieden werden, fr welche Ergebnisdaten dieDatenbertragung 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) durchgefhrt. Da der Einsatz der inkrementellenUmformsimulation aufgrund der notwendigen Methodenplanung und der Entwicklungder Ziehanlage einen hohen Zeitaufwand erfordert, wird diese in der Praxis erstdurchgefhrt, wenn der Konstruktionsstand der Karosseriebauteile einen entspre-13 14. chenden Reifegrad erreicht hat. Dies hat zur Folge, dass die Simulationsdaten derUmformsimulation im frhen Entwicklungsprozess bei der Auslegung der Produktei-genschaften, insbesondere bei der Crash-Berechnung, nicht zur Verfgung stehen.Aus diesem Grund wird im Projekt VIPROF zustzlich ein One-Step-Solver (For-mingSuite) als alternative Simulationsmethode fr die frhe Produktentwicklungspha-se eingesetzt. Bei der inversen Simulation (One-Step-Simulation) wird die Geome-trienderung in einem Schritt rckwrts vom Bauteil zur Platine berechnet. Fr dieDurchfhrung werden nur die CAD-Geometrie und die Werkstoffdaten bentigt. Dergegenber der inkrementellen Umformsimulation fehlende Werkzeugkontakt fhrtz. B. zur Einschrnkung der Faltenvorhersagbarkeit.Fr die Fgesimulation wurde eine Berechnung des Schweiverzugs mit dem WeldPlanner durchgefhrt. 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 mglich ist. Zustzlich unterscheiden sich auch die FEM-Netze unddie verwendeten Bezugskoordinatensysteme. Abbildung 7: Vernetzung Umformsimulation; Links: Dreieckelemente; rechts: ViereckelementeDie aufflligsten Unterschiede zwischen den FEM-Netzen sind - wie in Abbildung 7zu erkennen ist - die Elementform und die Elementgre. Die Elemente aller in der14 15. Prozesskette betrachteten Simulationen sind Schalenelemente, so dass eine Be-trachtung der Datenbertragung zwischen Schalen- und Volumenelementen nichtstattgefunden hat. Bei den Schalenelementen gibt es Dreieck- und Viereckelemente.Weiterhin ist in Abbildung 8 zu erkennen, dass die Netze abhngig 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 zustzlich in diesen Bereichen die strk-sten Verformungen auftreten. Bei der Fgesimulation sind die Bereiche, in denen dieSchweinhte liegen, feiner vernetzt, whrend die anderen Bauteilbereiche grobvernetzt sind. Die Vernetzung fr die Crash-Simulation und die Lacktrockungssimula-tion ist gleichmig grob, weil in diesen Simulationen die gesamte Karosserie be-rechnet wird und bei einer feineren Vernetzung der Zeitaufwand zu gro wre.a) Umformsimulation b) Fgesimulation c) Crash-SimulationAbbildung 8: FEM-NetzeZustzlich 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, whrend mit der Bezeichnung Integrationspunktein der Regel Integrationspunkte ber der Elementdicke gemeint sind. Wie viele Integ-rationspunkte fr die Berechnung bentigt werden, hngt von dem Simulationsver-fahren und dem simulierten Prozess ab. Weiterhin werden abhngig vom Format dieskalaren und tensoriellen Gren 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 Gren gibt es zustzlich noch Unterschiede in den Bezugskoordinaten-systemen. Einige Formate speichern die Gren im globalen System, andere jeweilsim Elementkoordinatensystem. Dadurch ist fr die tensoriellen Gren eine Koordi-natentransformation der Tensoren notwendig. 15 16. Software/Format FormingSuite/ Sysweld/ PAMSTAMP/ PAMCRASH/ Eigenschaften*.key *.asc*.M01 *.pc KoordinatensystemFahrzeugFahrzeug WerkzeugFahrzeug Knoten pro Element 3 (3)4 (3)4(3)4 Gauss-Punkte 1 (1)4 1 1 Integrationspunkte ber der Dicke3 55 5 BlechdickeAbhngig von NeinJa JaJa Gauss-Punkten Abhngig von Integ-NeinNein NeinNein rationspunkten BezugKnotenKnoten Element Element Spannungen Abhngigvon JaJa JaJa Gauss-Punkten Abhngig von Integ-JaNein JaJa rationspunkten BezugElement Knoten Element Element Dehnungen Abhngig von NeinJa NeinNein Gauss-Punkten Abhngig von Integ-NeinNein NeinNein rationspunkten BezugElement Knoten Element Element PlastischeAbhngig von JaJa JaJa Vergleichs- Gauss-Punkten dehnung Abhngig von Integ-JaNein JaJa rationspunkten BezugElement Knoten Element Element Tabelle 2: Eigenschaften bzw. Standardeinstellungen der im Projekt eingesetzten Formate Abbildung 9: Integrations- und Gauss-PunkteDarber hinaus werden die Bauteile abhngig von dem simulierten Prozess in unter-schiedlichen Koordinatensystemen beschrieben. In der im Projekt VIPROF aufgebau-ten Prozesskette liegen die Bauteile in der inversen Umformsimulation im Fahrzeug-16 17. koordinatensystem, weil die Simulation auf der CAD-Geometrie aufbaut und 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 Fgenetz 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 Fgesimulation (grn)In der betrachteten Prozesskette sind alle Netze auer dem der inkrementellen Um-formsimulation in der Einbaulage definiert. Eine Koordinatentransformation fr dasgesamte Netz muss also fr alle Mapping-Prozesse erfolgen, in denen Daten derinkrementellen Umformsimulation bertragen werden sollen.Allgemein mssen also fr eine bertragung der Ergebnisgren 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 mssen wurde eine Literatur- undSoftware-Recherche durchgefhrt. Eine Untersuchung unterschiedlicher Methodenzur bertragung von Geschichtsvariablen aus der Umform- in die Crashsimulation istzum Beispiel in [Zll04] dargestellt. Neben den herstellerinternen Methoden [Cafo03]hat sich der SCAIMapper, durch seine Mglichkeit unterschiedliche Formate einzule-sen, fr die Kopplung von Umform- und Crashsimulation als herstellerunabhngigesund damit universelles Werkzeug herausgestellt. Der SCAIMapper hat die Mglich-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 durchfhren17 18. [Oeck10, Peetz03, Scho07, Wallm04, Shep68, Wolf09]. Fr das Projekt stellte derSCAIMapper alle bentigten Mapping-Funktionen zur Verfgung, so dass er in dieProzesskette als Mappingtool eingebunden wurde.Das Mapping von der Umform- in die Crashsimulation war mit dem SCAIMapperproblemlos mglich, was jedoch noch keine Aussage ber die Eignung fr die ande-ren Prozesse zulie, da der Mapper genau fr diese Anwendung entwickelt wurde.Das Einlesen der Netze der Fge- und Lacktrocknungssimulation war aufgrund vonFormat-Inkompatibilitten zunchst 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-Sule mit Umformergebnissen, b) Umformnetz, c) Fgenetz, d) Lacktrocknungs- undCrash-NetzDie Bewertung der Mapping-Genauigkeit erfolgte zum einen mit den im SCAIMapperverfgbaren 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 knnen wie es die Netzgre des Zielnetzes zulsst.Das heit, dass zwei Effekte die Qualitt der Mapping-Ergebnisse beeinflussen, zumeinen die Genauigkeitsverluste durch die Interpolation zwischen den Netzen und zumanderen die schlechtere Auflsung des Zielnetzes. Bei der gezeigten B-Sule in Ab-bildung 11 ist zu erkennen, dass Extremwerte aus dem Umformprozess bei der ber-18 19. tragung auf das grobe Crashnetz geglttet werden. Es ist daher wichtig, dass bei derWeiterverwendung der Ergebnisse nach dem Mapping beachtet wird, dass mgli-cherweise kritische Werte durch die gegltteten Ergebnisse verloren gegangen sind.In kritischen Bauteilbereichen sollten diese Informationen daher zustzlich zu derMapping-Datei weiter gegeben werden.Abbildung 12: Abweichung der Blechdicke nach dem Mapping derUmformergebnisse (inkrementell) auf das Crash-NetzDie Datenbertragung der skalaren Gren Blechdicke und plastische Dehnungfunktioniert fr alle Mappingprozesse in der untersuchten Kette problemlos. DieWerte werden mit Hilfe von Interpolationsalgorithmen [Oeck10, Shep68] auf dasneue Netz bertragen. Die Bewertung der Qualitt wurde zunchst mit Hilfe derValidierungsfunktion des SCAIMappers durchgefhrt. 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 darber.Die zweite Methode zur Bewertung der Mapping-Qualitt besteht in einem Vergleichder Blechdicken an 20 definierten Messpunkten vor und nach dem Mapping-Prozess.Die Messpunkte werden vorrangig in Bauteilbereichen mit groen Vernderungender 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 singulre Spitzenmglichst 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 20. P1 + P2 + + P6 + P7 + P13+ P20 + P8 + P14+ P15P3 ++P10P9 + P16 P4 + +P11 + P17P5 ++P12 + P18++ P19Abbildung 13: Lage der 20 Messpunkte fr die Ergebnisgre 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 grn dargestellt. In gelbgestellt und als befriedigend bewertet werden Abweichungen im Bereich von 5%bis 10%. Whrend Messpunkte mit einem relativen Fehler ber 10% als mangel-haft eingestuft und rot dargestellt werden.20181614Anzahl Messpunkte12 10%105 - 10% 5% 8 6 4 2 0rel. Fehlerrel. Fehler rel. Fehler rel. Fehler Umformen inkrementellUmformen invers Umformen inkrementell Umformen invers-> Fgenetz -> Fgenetz -> Crashnetz-> Crashnetz Abbildung 14: Relativer Fehler beim Mapping der Blechdickenverteilung auf Fge- und Crashnetz 20 21. Die Abweichung fr 84% der Messungen an diesem Bauteil liegt insgesamt unter5%. Die Mapping-Qualitt kann damit fr die skalare Ergebnisgre Blechdicke alsgut bewertet werden. Dieses Ergebnis stimmt mit der Aussage von Abbildung 12 gutberein.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 Ausdnnung bzw. Aufdickung oder engenRadien. Groe Gradienten in der Blechdicke bei feiner Vernetzung im Ausgangsnetzund deutlich grere Elementkantenlngen im Zielnetz im gleichen Bereich fhrendurch die in diesen Bereichen dann notwendige Interpolation der Blechdickenwertezu greren Abweichungen in den Mapping-Ergebnissen. Dies zeigt sich auch imVergleich der Mapping-Ergebnisse fr die betrachteten FEM-Netze. Je grer dieUnterschiede in den verwendeten Netzen sind, desto grer sind auch dieAbweichungen.Abbildung 15: Plastische Dehnungen nach der inkrementellen Umformsimulation (un-ten) und nach dem Mapping auf das Crash-Netz (oben)In der Prozesskette werden zustzlich zu der Blechdickenverteilung auch dieplastischen Dehnungswerte als Ma fr die Werkstoffverfestigung bertragen. BeimMapping der plastischen Dehnungen mssen in Abhngigkeit 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 22. Abbildung 16: Absolute Abweichung der plastischen Dehnung nach dem Mappingder 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), fhren bereits geringe Interpolationsfehler zu groen Abweichungen. In diesenBereichen ist aufgrund der geringen plastischen Dehnung kein groer 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 Datenbertragung von tensoriellen Gren ist dagegen schwieriger, da diesoren formatabhngig in unterschiedlichen Koordinatensystemen gespeichert wer-den. Dadurch ist ein Vergleich der Tensoren nicht direkt mglich. In der grafischenDarstellung werden daher in der Regel Vergleichswerte gezeigt. In Abbildung 17 istzu erkennen, dass die Abweichungen des dargestellten skalaren Vergleichswertes22 23. nach dem Mapping deutlich grer sind als bei den skalaren Gren 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 undCrash-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 24. In Abbildung 19 sind die 1. und 2. Hauptspannung an der ueren Oberflche der B-Sule dargestellt. Es ist zu erkennen, dass lokale Maxima und Minima bei der ber-tragung auf das deutlich grber vernetzte Crash-Netz stark geglttet werden. DieAbweichungen entstehen durch die Interpolation der Gren auf das grbere Netz.Das Mapping von tensoriellen Gren scheint - soweit es anhand der skalaren Ver-gleichsspannung beurteilt werden kann - im Rahmen der durch das Zielnetz vorge-gebenen maximalen Auflsung ausreichend genau zu sein. Die Interpretation dergemappten Daten in den nachfolgenden Simulationen fhrt jedoch teilweise zu Ab-weichungen, so dass im Einzelfall geprft werden muss, ob die Daten von der nach-folgenden Simulation richtig interpretiert werden. In der Sensitivittsanalyse wird ge-prft, ob das bertragen von Spannungen in die Folgesimulationen sinnvoll ist undwie empfindlich die Simulationen auf Abweichungen reagieren.3.2.3 SensitivittsanalyseDas Ziel der Sensitivittsanalysen ist es zu ermitteln, welche Ergebnisgren einenso groen 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 Folgesimulationenbertragen.Es wurden zunchst fr alle Bauteile der Baugruppe (Abbildung 20 a) Umformsimula-tionen durchgefhrt. Die Hauptbauteile B-Sule innen, Verstrkung B-Sule, Verstr-kung Stegblech Schweller und Sitzquertrger 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-Sule, Verstrkung Wagenheberaufnahme und Schottteil Schwellervorn wurden nur mit der inversen Umformsimulation berechnet. Diese Ergebnissewurden in unterschiedlichen Kombinationen in die nachfolgenden Simulationen ber-tragen, um zu prfen ob dadurch die Simulationsergebnisse beeinflusst werden kn-nen. Einen berblick ber die untersuchten Varianten gibt Abbildung 66.24 25. a) Baugruppe b) Umformsimulation (inkrementell) B-Sule innen Verstrkung Stegblech Schweller Verstrkung B-Sule innen Sitzquertrgerc) Umformsimulation (invers) B-Sule innenSchottteil B-Sule Verstrkung Stegblech SchwellerVerstrkung Wagenheberaufnahme Verstrkung B-Sule innenSchottteil Schweller SitzquertrgerAbbildung 20: Bauteilumfang 25 26. Die Fgesimulation wurde dazu mit unterschiedlichen Eingangsdaten durchgefhrt: 1. Standard Eingangsdaten inkl. Ausgangsblechdicken2. Standard Eingangsdaten und Blechdicken aus der Umformsimulation3. Standard Eingangsdaten und plastische Dehnungen aus der Umformsimulation4. Standard Eingangsdaten, Blechdicken und plastische Dehnungen aus der UmformsimulationEin Vergleich der Ergebnisse dieser Fgesimulationen hat gezeigt, dass nur bei Be-rcksichtigung von Blechdicken aus der Umformsimulation die in Abbildung 21 dar-gestellte Verdrehungsrichtung der Baugruppe richtig vorhergesagt werden kann.Weiterhin fhrt das Weitergeben der plastischen Dehnungen zu geringen Verbesse-rungen. Die Spannungen knnen von dem fr die Fgesimulation eingesetztenWeldplanner nicht weiter verwendet werden, so dass eine bertragung hier nichtsinnvoll ist. In Kapitel 3.3 werden diese Ergebnisse weiterfhrend beschrieben.a)b)c)Abbildung 21: a) Verdrehungsrichtung im Versuch, b) Simulationsergebnis ohne Um-formergebnisse, c) Simulationsergebnis mit Blechdicken und plastischen Dehnungenaus der UmformsimulationDie Ergebnisse der Fgesimulation werden fr die mit unterschiedlichen Eingangsda-ten durchgefhrten Berechnungen jeweils in eine Mapping-Datei geschrieben und frdie nachfolgenden Simulationen zur Verfgung gestellt.In der Lacktrocknungssimulation wurden Berechnungen mit den Ergebnissen ausUmform- und/oder Fgesimulationen durchgefhrt. Bei der Bercksichtigung von 26 27. 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 whrend 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. Weiterfhrende Informationen zur Lacktrocknungssimulation und zurbertragung 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 Fge-simulation durchgefhrt. Anhand der Ergebnisse der Crash-Simulation wird die ge-samte Prozesskette bewertet. Die Ergebnisse der Crashsimulation zeigen, dass mitder Bercksichtigung von Blechdicken und plastischen Dehnungen aus Umform- undFgesimulation die Art des Bauteilversagens in der Simulation nher an der Realittliegt, als ohne Bercksichtigung der Fertigungshistorie. Die Ergebnisse der Crashsi-mulation werden in Kapitel 3.5 ausfhrlich dargestellt.Zusammenfassend ist fr die Datenbertragung zwischen den Prozessen festzuhal-ten, dass die bertragung von Blechdicken und plastischen Dehnungen in die Fge-simulation zu genaueren Simulationsergebnissen fhrt. Die bertragung von Ergeb-nissen in die Lacktrocknungssimulation zeigt dagegen fr die betrachtete Baugruppekeine Verbesserung. Die Ergebnisse der Crash-Simulation werden wiederum durchdie bertragung der Blechdicken und plastischen Dehnungen positiv beeinflusst. Zu-stzlich kann es sinnvoll sein den aus der Lacktrocknung resultierenden Bake-Hardening-Effekt in die Crashsimulation zu bertragen.Literatur[Zll04] Zller, A.; Frank, T. & Haufe, A.: Bercksichtigung von Blechumformer- gebnissen in der Crashberechnung, 3. LS-DYNA Anwenderforum, 2004, B-I-1bis B-I-12[Cafo03] Cafolla, J.; Hall, R. W.; Norman, D. P. & Mc Gregor, I. J.: Forming to Crash Simulation in Full Vehicle Models, 4th European LS-Dyna Users Conference, 2003, 4, E-II-17 - E-II-26 27 28. [Oeck10]Oeckerath, A. & Wolf, K.: Improved Product Design Using Mapping InManufacturing Process Chains, 9. LS-DYNA Forum, DYNAmore GmbH,2010[Peetz03] Peetz, J.-V.; Post, P.; Scholl, U.; Wang, Y.; Wolf, K.; D39Ottavio, M.;Krplin, 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 Crashsimulation6. LS-DYNA Anwenderforum, DYNAmore GmbH, 2007, 6., H-II-1-H-II-6[Wallm04] Wallmersperger, T.; Waedt, M.; DOttavio, M.; Krplin, 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.; Lthjens, J.; Hunkel, M.; Wallmersperger, T.;Jankowski, U.; Sihling, D.; Wiegand, K.; Zllner, A. & Heuse, M.:Coupled FEM Calculations - A CAE Tool to Improve Crash-RelevantAutomotiveBodyComponents byLocal Hardening,7th European LS-DYNA Conference, DYNAmore GmbH, 2009 28 29. 3.3 Teilprozesskette Umformen und Fgen (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 fr sich betrachtet, ist die berprfung der Herstellbarkeit des Bauteils und au-erdem die virtuelle Erprobung der gewhlten Methode, sowie deren Optimierung.Darber hinaus ist es mglich, 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 durchgngigenProzesskette und Betrachtung der auftretenden Sensitivitten.Zur berprfung der Herstellbarkeit hat sich die Simulation der Hauptumformstufebewhrt. Die Simulation weiterer Nachform- und Schnittstufen wird bisher von Auto-mobilherstellern als wenig Nutzen bringend angesehen. Dies ist fr Zulieferer anders,denn diese mssen das Bauteil in einer vorgegebenen Toleranz anfertigen, die sichheute schon in erster Nherung virtuell berprfen lsst.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, fhrt 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 mitgefhrt, und somitvollstndig umgeformte Bauteile erzeugt (Abbildung 22).AbkantenVerprgenAbbildung 22: Nachformoperationen zur Erstellung virtueller Bauteile 29 30. Ein weiterer wesentlicher Aspekt, der sich nur sinnvoll mit einem ber alle Umform-stufen erstellten Bauteil betrachten lsst, ist die Rckfederung. Auch fr sogenanntekompensierte Bauteile verbleibt nach der Entlastung durch die Werkzeuge ein Auffe-derungseffekt. Dieser fhrt bei der blichen Methode der Datenbertragung 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 Vernachlssigung des Aufsprungs, d.h. es wird das Ergebnis nachder letzten Umformstufe ohne Rckfederungsrechnung bertragen. Dies bedeutetein Verbleiben der Eigenspannungen im Bauteil, sofern diese bertragen werden. Dadie Entlastungsrechnung in der Regel nicht zu plastischen sondern nur elastischenEffekten fhrt, ist der Fehler bei einer Vernachlssigung 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 BeschnittAbbildung 23: Abbildungsfehler bei der Datenbertragung (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, Blechdickennderung und optionalder Eigenspannungen, wird mittelfristig in der Betrachtung der Prozesskette auch dieBercksichtigung der Gestaltnderung eine Rolle spielen. Gestaltnderung 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 31. CAD ZiehanlageCAD DatenCAD APAM-ohne EntlastungAUTOSTAMPNetz umgeformt UmformsimulationPAM-Netz entlastet AUTOSTAMP Rckfederung PANEL SHOPentlastetCAD B MappingMappingMappingSysweldnetzSysweldnetz Sysweldnetz CAD ACAD A entlasteta)b)c)Neuvernetzung SYSWELDSYSWELDSYSWELD Route 1Route 2Schweisimulation SchweisimulationSchweisimulation SYSWELDSYSWELDSYSWELDSpannenSchwei Verzug Schwei Verzug SYSWELD Schwei Verzug Abbildung 24: bertragung der Umformhistorie in die Schweisimulation: a) und b)ohne Bercksichtigung der Gestaltnderung und c) mit GestaltnderungAls Referenzprozess lsst sich heute mit einer berschaubaren Methode die aktuelleBauteilgeometrie des entlasteten Bauteils aus Gewerk A in ein Gewerk B berfhren.Das Eingangsnetz fr Gewerk B kann also auf Basis von Bauteil A generiert werdenund damit knnen 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 fr Gewerk B neu vernetzt und an-31 32. schlieend die Herstellungshistorie aus Gewerk A ohne Abbildungsfehler daraufbertragen (gemappt). Damit ist ein wesentliches Modul fr die End to End Prozess-kettensimulation verfgbar, das der Gestaltabweichung in adquater Weise Rech-nung trgt. ++ CAD Bauteil UmformnetzVerschiebungsfeld CAD BauteilentlastetAbbildung 25: Mit PanelShop (Fa. iCapp) generierte CAD-Daten des entlastetenBauteils als Basis zur NeuvernetzungAlternativ wurde im Programm PAM-STAMP 2G ein Mapping von Netz B auf Netz Abetrachtet. Dies war jedoch nicht zielfhrend, da in PAM-STAMP bisher nur eine li-neare Projektion implementiert ist. Diese fhrt fr einen Bauteilbereich mit vertikalerProjektionsrichtung zu Verzerrungen (Abbildung 26). Eine Verbesserung wrde hiereine Projektion unter Bercksichtigung der jeweiligen Elementnormalen ergeben.Dies sollte aber durch ein vorheriges Einschwimmen von Netz A zu B ergnzt wer-den. So wie es auch im SCAIMapper mglich ist. Denn selbst wenn sich beide Netzein Fahrzeuglage befinden, kann der Aufsprung durch die Lagerbedingungen zu einerVerschiebung eines Bauteils fhren.32 33. Abbildung 26: Mgliche Projektionsfehler bei linearer Projektion von Netz A auf Netz B3.3.3 Untersuchte BaugruppeVon der untersuchten Schwei-Baugruppe Seitenwandrahmen vorn wurden dreiHauptbauteile fr die inkrementelle Umformsimulation ausgewhlt und drei Zusatz-bauteile mit geringer Umformung wurden mittels Onestep-Simulation betrachtet. Hin-zu kommen fr die Schweiung noch zwei Gewindeplatten und ein weiteres Bauteil,um den Zusammenbau mit dem Serienstand vergleichbar zu machen (Abbildung 27).33 34. jeweils in rot dargestellt Hauptbauteile Sule B innen Verstrkung Sule B Verstrkung Stegblech innen Schweller innenVerstrkung A-Sulenur als CAD-DatenZusatzbauteileeingefgt Schottteil Sule B VerstrkungSchottteil Schweller vornWagenheberaufnahmeAbbildung 27: Untersuchte Schwei-Baugruppe3.3.4 Sensitivitt der Datenbergabe in Relation zur NetzfeinheitFr das VIPROF-Projekt wurde die durchgngige 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 unterschiedlicheNetzausprgungen hinsichtlich der Feinheit und betrachteter Teilbereiche. Dies zeigtAbbildung 28 mit dem Netz aus der Umformung mit verfeinerten Radienbereichen,dem Schweinetz mit Nahtbereichen und dem typischen 5 mm Crashnetz. Umformen SchweienCrash Abbildung 28: Unterschiedliche Netzausprgungen34 35. Um die Sensitivitt der Datenbertragung in Relation zur Netzausprgung zu unter-suchen, wurden die wesentlichen drei Mappinggren: Blechdicke, plastische Deh-nung und Spannungstensor in PAM-STAMP 2G jeweils vom Umformnetz auf dasSchwei- und Crashnetz gemappt.Fr 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 Gegenberstellung 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 WeldCrash Stamp WeldCrashAbbildung 29: Einfluss der Netzausprgung auf die bertragung der Blechdicken(links) und plastischen Dehnungen (rechts) vom Tiefziehen zumSchweien und zum CrashIm Projekt wurden in erster Linie die bertragung der Blechdicken und plastischenFormnderungen betrachtet. Die Eigenspannungen schienen nicht nur wegen derVerluste bei der bertragung der Spannungstensoren fr den betrachteten Zusam-menbau nicht relevant zu sein, sondern auch weil dieser mit MAG- und Laser-Linienschweiungen robust verbunden wurde. Interessanter wre die Bercksichti-gung der Eigenspannungen fr die Untersuchung von punktgeschweiten Zusam-menbauten, die bekannterweise sensibler gegenber eingebrachten Vorspannungensind. 35 36. Stamp Weld CrashAbbildung 30: Einfluss der Netzausprgung auf die bertragung der Vergleichs- spannungen vom Tiefziehen zum Schweien und zum Crash 36 37. Stamp WeldCrashAbbildung 31: Verluste bei der bertragung von Spannungstensoren3.3.5 Simulation des Schweiverzugs mit dem Weld PlannerMit dem Programm Weld Planner wurde das Fgen der Baugruppe Seiten-wandrahmen vorn hinsichtlich des auftretenden Verzuges simuliert. Abbildung 32verdeutlicht die Lage der Nhte und die beiden eingesetzten Schweiverfahren. AlsLagerbedingung nach der Abkhlung wurden die von VW bereitgestellten RPS-Punkte verwendet (Abbildung 33). Das Referenzpunktesystems (RPS) umfasst u.a.die Mabezge und Positionierungen fr Bauteile und Schweigruppen und wird imCAD festgelegt. Die virtuelle Schweiung beschrnkt sich beim Weld Planner auf dieEinbringung der Prozesswrme an den jeweiligen Fgestellen und in der vom An-wender vorgegebenen Schweireihenfolge. Sie gibt wesentliche Hinweise zur Opti-mierung der Schweinahtlage und Reihenfolge. 37 38. Abbildung 32: Laserschweinhte (a) und MAG-Schweinhte (b) der Baugruppe Abbildung 33: RPS-Spannpunkte der Messaufnahme3.3.6 Sensitivitt des Schweiverzugs hinsichtlich der aus der Fertigungshis-torie bertragenen GrenIn der Sensitivittsanalyse zum Schweiverzug wurde der Einfluss des bertragensunterschiedlicher Ergebnisgren 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-schrittlser (Onestep-Solver) FTI FormingSuite eingesetzt. Betrachtet wurden jeweilsdie drei Hauptbauteile, die entweder inkrementell oder invers simuliert wurden. DieZusatzbauteile wurden fr die Umformung jeweils nur invers berechnet. Dazu wurde38 39. zum Vergleich noch der Schweiverzug auf Basis der CAD-Daten ohne Fertigungs-historie einbezogen. Untersucht wurden die in Tabelle 3 aufgefhrten Varianten. Variante Simulationtool SoftwareBlechdicke plastische Dehnung Haupbauteile Nebenbauteile 0WeldPlannernur CADnur CAD-- 1a WeldPlannerPAM-STAMP 2G nur CADx- 1b WeldPlannerPAM-STAMP 2G nur CAD-x 1c WeldPlannerPAM-STAMP 2G nur CADxx 2a WeldPlannerFTI FormingSuite nur CADx- 2b WeldPlannerFTI FormingSuite nur CAD-x 2c WeldPlannerFTI FormingSuite nur CADxx 3a WeldPlannerPAM-STAMP 2G FTI FormingSuite xx 3b WeldPlannerFTI FormingSuite FTI FormingSuite xx4 WeldPlannerPAM-STAMP 2G nur CADxxNeuvernetzungTabelle 3: Varianten des Mappings der Herstellungshistorie aus der UmformungIm Folgenden werden wesentliche Ergebnisse beispielhaft aufgezeigt. Der Vergleichdes bertragens einzelner Ergebnisgren, wie dem Blechdickenverlauf und derplastischen Dehnung, ergab, dass die alleinige bertragung der plastischen Deh-nungen nicht sinnvoll ist. Whrend die alleinige bertragung der Blechdicke fr einegute Ergebnisbereinstimmung mit den Messungen hinreichend sein kann. DiesesPhnomen lsst sich mit dem dominanten Einfluss der Blechdicke auf die Steifigkeitdes Zusammenbaus erklren. Die Beulsteifigkeit kann je nach Geometrie bis in die 2.oder 3. Potenz von der Blechdicke abhngig sein. Dies dokumentiert beispielhaft dieAbbildung 34.39 40. Verschiebungen in y-RichtungMit beiden Gren Nur BlechdickenNur plastische DehnungAbbildung 34: bertragung unterschiedlicher Gren. Hauptbauteile und Zusatzbau-teile invers simuliertEine Gegenberstellung der untersuchten drei Hauptbauteile mit inkrementeller undinverser Simulation zeigt, dass fr den betrachteten Fall der Verzug basierend aufder inversen Umformung etwas strker ist, als der der inkrementellen Simulation(Abbildung 35). Dies ist damit zu erklren, 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: Schweiverzge der inkrementellen und inversen Simulation der Um-formung im Vergleich40 41. Da der betrachtete Schwei-Zusammenbau einem Serienstand entspricht, ist derauftretende Verzug sehr gering und damit eine Aussage ber die Gte der Ergebnis-se nur eingeschrnkt mglich. Auf der Grundlage der von Volkswagen durchgefhr-ten Vergleichsstudie zur Gte inverser Simulationen kann angenommen werden,dass die Resultate in der vorliegenden Form reprsentativ sind. So dass in der fr-hen Phase Onestep-Simulationen zur Planung der Schweimethode mit ausreichen-der Genauigkeit eingesetzt werden knnen.Die Frage nach der Notwendigkeit der Bercksichtigung von Umformergebnissen frdie richtige Vorhersage des Schweiverzugs wurde mit der Variante 0 (Tabelle 3)betrachtet. Eine Gegenberstellung der Messergebnisse mit der Simulation desSchweiverzugs ohne Bercksichtigung der Fertigungshistorie ergab fr diese Bau-gruppe abweichende Resultate hinsichtlich des Verzugs und der Verdrillungsrichtung(Abbildung 36). Beide Ergebnisgren des Schweiverzugs wurden demgegenbervon der Variante mit bernahme der Blechdicken und plastischen Formnderungenfr die betrachteten Bauteile dem Messergebnis vergleichbar dargestellt. Die Ver-messung der Schweibaugruppe bei VW (Abbildung 72) ergab eine gute bereins-timmung mit der Simulationsvariante mit Bercksichtigung der vollstndigen Ferti-gungshistorie sowie nur der Blechdicke (siehe Kapitel 3.5.5.1, Abbildung 72 und Ab-bildung 73). Abbildung 36: Schweiverzug mit Basis CAD-Daten (links), Blechdicken (mitte) undUmformhistorie (rechts); Verschiebungen in Y-Richtung (normal zur Ansichtsrichtung)41 42. 3.3.7 Schweiverzugssimulation mit der Methode der NeuvernetzungDie Notwendigkeit der Untersuchung des Einflusses der Auffederung am Ende derUmformung verdeutlicht Abbildung 37. Die in Tabelle 3 aufgefhrte 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 fr die Schweiverzugssimulation 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 fr eine Fgesimulation thermisch oder mechanischWerkzeugentwurf Route 1 Geometrisch passendes Mapping mit Eigenspannungen im ModellRoute 1Umformsimulation Route 2 Mappen des entlasteten Bauteils mit geometrischer AbweichungRoute 2Rckfederungsrechnung Simulation des Fgens Route 3 Mappen des entlasteten Bauteils auf einRoute 3Neuvernetzungkongruentes, dediziertes Netz zum Fgen. Im Fgen ist ggf. ein Spannvorgang erfoderlich Abbildung 37: Mgliche Vorgehensweisen zum bertragen der Herstellungshistorie in die nachfolgende FgesimulationDer Unterschied der in Abbildung 38 dargestellten Ergebnisse fr Route 1 und 2 istrelativ gering, was auf die im Projekt gewhlte Vernachlssigung der Spannungs-tensoren beim Mapping zurckzufhren ist. Betrachtet man aber das deutlich abwei-chende Ergebnis der Methode der Neuvernetzung, bei der das Bauteil beim Fgenaufgrund der Lageabweichung gespannt werden muss, so ist der Verzug fr 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 geklrt werden konnte, soll an dieser Stel-le die Fortfhrung der Untersuchung der vorgeschlagenen Methode der Neuver-netzung im Rahmen anderer Frderprogramme angeregt werden. 42 43. Die darber hinaus interessierende Fragestellung ist, ob die Route 1 bei zustzlicherBercksichtigung der Spannungstensoren eine hinreichende Lsung darstellen knn-te. Wre so der Aufwand der Neuvernetzung vermeidbar? Nicht zuletzt liee sichauch die Variante der direkten Projektion des Fgenetzes auf das aufgefederte Um-formnetz verbessern und damit eine einfachere Lsung schaffen. Min: 0,003Min: 0,003 Min: 0,001 Max: 0,932Max: 0,946 Max: 0,596Route 1 Route 2 Route 3 Abbildung 38: Ergebnis der Neuvernetzung mittels Flchenrckfhrung 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 ingroen Trocknungsfen durchzufhren. Zwischen den einzelnen Lackierschritten istjeweils eine Trocknung des Lackes erforderlich, wobei die Bauteile aufgeheizt undanschlieend ber eine vorgegebene Zeitdauer auf einem bestimmten Temperatur-niveau gehalten werden. Mit VPS/DRY kann das Aushrten von Lacken auf Wasser-basis in diesem thermischen Trocknungsvorgang simuliert werden. Denn im Gegen-satz zu lsemittelbasierten Lacken, die selbst nachtrocknen, ist bei wasserbasiertenLacken eine Vernetzung nur durch Aufheizung mglich. Lackanteile, die beim Trock-nen nicht aushrten, knnen spter nicht nachhrten. Falls im Trockner die Mindest-temperatur und -haltezeit unterschritten oder eine obere Grenztemperatur und-haltezeit berschritten werden, sind Qualittsmngel zu erwarten. Mit VPS/DRYknnen kritische Stellen von Bauteilelackierungen ausgemacht sowie die Lackier-und Trocknungsvorgnge entsprechend vorausgeplant und optimiert werden.43 44. Im Projekt VIPROF wurde die Lacktrocknungssimulation in die Prozesskette mit auf-genommen, um den Einfluss vorgelagerter Fertigungsschritte auf das Verhalten derKarosserie im Trocknungsofen zu berprfen. 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 SensitivittsanalyseCADFEM hat eine Sensitivittsanalyse der Lacktrocknung durch eine begleitendeEigenwertanalyse vorgenommen, um die Sensitivitt des Ofenprozesses bezglichEinflssen aus dem Umform- und dem Fgeprozess zu bewerten. Dicken, Spannun-gen und Dehnungen aus dem Umformen und Fgen wurden in verschiedenen Zu-sammenstellungen in der Trocknungssimulation VPS/DRY bercksichtigt. Fr dieVPS/DRY Simulation wurden gleichmig vernetzte Crash-Netze der VW AG ver-wendet. Vereinfachungen an den Karosseriemodellen zur Beschleunigung der Be-rechnungen in der Mechanik wurden durch Weglassen von Tren und Klappen sowiedurch Betrachtung halber Modelle mit Symmetriebedingungen vorgenommen, wie inAbbildung 39 gezeigt. Die Berechnungsvarianten sollten Rckschlsse erlauben, wiestark Spannungen und Dehnungen aus der Vorgeschichte das Berechnungsergebnisbei der Trocknung beeinflussen. Abbildung 39: Entkerntes Halbmodell fr die begleitende EigenwertanalyseDas Vorgehen zur Durchfhrung 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 Abkhlung im Ofen der Spannungszustand von Blechen undStrukturen verndert, was einen Einfluss auf die Eigenfrequenzen der Bauteile hat.44 45. Temperatur-Mechanische Berech- Vorgespannteberechnung nung mit Temperatur- Modal-in VPS/DRY randbedingungenanalyseMode Tracking Abbildung 40: Begleitende Eigenwertanalyse zum Erkennen einer BeulgefahrEine Herleitung und Erluterung 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 Stabilittsprobleme sowieAbschnitt 3.4.4 Begleitende Eigenwertanalyse. Die folgenden Abstze enthalten An-lehnungen und Zitate aus dem genannten Buch.Ein Beispiel fr 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 Stabilittsproblems kann das Systemausgelenkt werden, ohne dass es nach Wegnahme der Last hier in Form der inho-mogen verteilten Temperaturdehnungen in die vorherige Lage zurckkehrt. EineEigenfrequenz zu diesem Verformungsmuster wird zu Null.Werden Eigenwerte begleitend zur Last aufgetragen, erlaubt der Verlauf der Eigen-werte Rckschlsse auf das Stabilittsverhalten, wenn sich zwei Kurven eines Unter-suchten Bereiches kreuzen oder zu Null werden.Als begleitende Eigenwertanalyse ermittelt CADFEM die Vernderung 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 freine Blechwanne in Abbildung 41 anhand eines Aufheizvorganges gezeigt. Im Pro-jekt wurde die Methodik der begleitenden Eigenwertanalyse verfeinert und automati-siert.45 46. Abbildung 41: Begleitende Eigenwertanalyse (rechts) bei einem stark zum Beulen neigenden Bauteil (nicht VW-Touran)Da die Steifigkeiten einer Struktur und die Wrmekapazitt durch die Blechdicken-verteilung beeinflusst werden, hat CADFEM die Einflsse 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 whrend 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-Sule keine kritischen Bauteile enthalten, die zum Beulen fhrenknnten. Auerdem 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 Bercksichtigung der Um-formhistorie aber rechentechnisch die Simulation weder vergrert noch verlangsamtist es ratsam die Dicken zu bercksichtigen. Bei Neukonstruktionen ist zu erwarten,dass mehr Beulneigungen bestehen. Die Biegesteifigkeit ist in der dritten Potenz ab-hngig von der Blechdicke. Damit kann bei festgestellter Beulneigung die Blechdickeals Modellfehler ausgeschlossen werden.46 47. Abbildung 42: Begleitende Eigenwertanalyse whrend der Trocknungssimulation der B-Sule unter Verwendung konstanter Blechdicken (links) und bei bertragung derBlechdickenverteilung aus dem Umformen (rechts)Das unkritische Verhalten der B-Sule gegenber Beulen zeigte sich auch auf einemvirtuellen Teststand (siehe Abbildung 43), mit dem Sensitivitten hinsichtlich derbertragung von Ergebnissen aus vorgelagerten Prozesssimulationen aufgezeigtwerden knnen. Anhand der unten fixierten und oben knstlich belasteten B-Suleknnen die Einflsse 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 Plastizitt aufgegeben werden,kann der Einfluss der Umformhistorie auf die begleitende Eigenwertanalyse gezeigtwerden. Zunchst diente dies zur Verifikation der Vorgehensweise. Gleichzeitig zeigtes aber auch die Anwendbarkeit bei anderen Belastungen auf.47 48. Abbildung 43: Sensitivittsanalyse der B-Sule 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-Sule im virtuellen Prfstandzeigt Abbildung 44, wobei die Kurven fr 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. Grere Vernderungen derEigenfrequenzen wrden auf Beulen oder Durchschlagen hindeuten. Diese Ergeb-nisse wurden fr ein nichtlineares Materialgesetz erzielt, das die elastische und dieplastische Fliegrenze beinhaltet. Durch diese Nichtlinearitt kann eine Verfestigungaus der Umformsimulation bzw. eine nderung der Fliegrenze bercksichtigt wer-den. 48 49. Abbildung 44: Begleitende Eigenwertanalyse der B-Sule im virtuellen Prfstand mit steigender Belastung (Dargestellt sind die Verlufe von Eigenfrequenzen ber denLastschritten, jeweils fr ein Modell mit und ohne Bercksichtigung der Blechdicken-verteilung.)3.4.2 Untersuchung von Einflssen des Bake-Hardening-EffektesDie Ausprgung des Bake-Hardening-Effektes (Reckalterung) hat einen Einfluss aufdie Crash-Eigenschaften der Karosserie. Wie stark dieser Effekt ausgeprgt 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 Metallgefge eine CKohlenstoffdiffusion an freie Gitterversatzstellen sehr viel schneller statt, als beiRaumtemperatur. Durch den Ofenprozess wird somit eine Festigkeitssteigerung er-zielt und die Fliegrenze ohne Gefgeumwandlung 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 Materialdatenblttern ist bekannt, dass z. B. fr die Stahlsorte CPW800 derBake-Hardening-Status erfllt wird, wenn eine Haltezeit von 20 Minuten bei ber170 erreicht wird. Die Zugfestigkeit des Werkstof fes kann von einem Wert vonC800 MPa im Mittel um 70 MPa erhht werden. Die Erhhung ist abhngig von der 49 50. Verweilzeit des Materials auf einem Temperaturniveau. Whrend sich in Simulatio-nen unterhalb dieses Temperaturniveaus keine so stark ausgeprgten inhomogenenVerteilungen der Haltezeit zeigten, nderte sich die ungleiche Verteilung fr Tempe-raturen ber 175 deutlich, wie aus Abbildung 45 a m Auenblech der B-Sule er- Ckennbar.Abbildung 45: Darstellung der Haltezeit in Sekunden auf einem bestimmten Tempe- raturniveau zur Untersuchung der Einflsse 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 Wrmekapazitt der an diesen Stellenangebrachten, relativ massiven Scharniere. Ist die Verfestigung aufgrund des unvoll-stndig ausgeprgten Bake-Hardening-Effektes hier geringer, knnte sich dies alsoberproportional auf die Steifigkeit der gesamten Konstruktion auswirken.In Kooperation mit VW wurden fr verschiedene Sthle Excel-Dateien mit Fliekur-ven fr die Simulation hinterlegt. Abhngig von verschiedenen Bake-Hardening-Zustnden (0% bis 100%) ergeben sich unterschiedliche Spannungs-Dehnungs-Diagramme. Der Bake-Hardening-Status, der mit der Material-ID verknpft wird, wur-de im LS-DYNA Format verfgbar gemacht. Ergebnisdateien knnen direkt ausVPS/DRY geschrieben werden. Eine knotenbasierte Datenablage wurde fr dieTemperaturen als Funktion der Zeit realisiert, da die Temperatur als Freiheitsgrad der 50 51. Simulation an den Knoten ermittelt wurde und so kein Informationsverlust entsteht.Fr 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. 1100Spannung (BH0) Spannung (BH1) 1050 Spannung (BH2) 1000Spannung (BH3) Spannung (BH4)950 Spannung (BH5)900Spannung (BH6) Spannung (BH7)850 Spannung (BH8)800Spannung (BH9) Spannung (BH10)7500 0,20,40,60,8 1 1,2 Abbildung 46: Unterschiedliche Bake-Hardening-Zustnde, die aus verschiedenen Haltezeiten und Temperaturniveaus resultierenUm den Einfluss im Rahmen des Projektes exemplarisch aufzuzeigen wurde dieAusprgung des Bake-Hardening-Effektes linear abhngig zur Haltezeit oberhalbeines definierten Temperaturniveaus angenommen. Weiterhin wurde die mittlere Ver-festigung aufgrund des Bake-Hardening proportional zur Ausprgung 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 fr Material ohne Bake-Hardening-Effekt, BH10 fr den voll ausge-prgten Effekt.51 52. Abbildung 47: Unterschiedliche Materialeigenschaften aufgrund verschiedener Tem-peraturniveaus im TrocknungsofenAbbildung 47 zeigt die Verteilung der unterschiedlichen Materialkennungen am Ver-strkungsblech der B-Sule mit den Temperaturgrenzen 170, 175 und 180 alsCBasis zur Ermittlung der Haltezeit. Dargestellt ist jeweils das Ausgangsnetz derVPS/DRY Simulation und ein verfeinertes Netz fr sptere 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 Vergleichsformnderungoder einer je nach Status zugewiesenen Spannungs-Dehnungs-Kurve erfolgen. Hu-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 fr sptere Detailuntersuchungen ein feineres Netz zu verwen-den. Da die Ausgangsbasis und Lage fr das Netz aber identisch war, ist der Ergeb-nisbertrag auf die Neuvernetzung sogar innerhalb von VPS/DRY automatisiert mg-lich.M app ingM apping Map pin g Lacktrocknungs-UmformsimulationFgesimulationCrashsimulationsimulation Format_1XM L Fo rm at_2XM LForm at_3XM LForma t_4XML-K onverter Abbildung 48: Ergebnisbertragung durch Mapping oder innerhalb eines XML-basierten Datentrgernetzes52 53. Die Ergebnisbertragung kann aber auch ber einen XML-basierten Mapping-Prozess erfolgen, der momentan noch manuell gesttzt 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 berfhren kann (siehe Abbildung 48).So knnen Bauteileigenschaften mit Bercksichtigung des Bake-Hardening auf dasZielnetz, z. B. fr 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 vonMaterialanhufungen im Bereich von angeschweiten Scharnieren eine zu geringeReckalterung zu vermeiden oder um herauszufinden, ob eine unvollstndige Auspr-gung des Bake-Hardening-Effektes bezglich der Anforderungen aus der Crash-Simulation toleriert werden kann.Im VIPROF-Projekt wurden keine tensoriellen Gren aus vorgelagerten Prozessenin der mechanischen Analyse unter der Temperaturlast im Ofen bercksichtigt. Diefr die Bercksichtigung der plastischen Vergleichsformnderung verwendete INIS-TATE-Funktion von ANSYS kann aber auch dazu verwendet werden. So kann wie inAbbildung 49 gezeigt der Spannungszustand aus einer Teillsung in eine weitereTeillsung bertragen werden. Richtig ist ein solches Vorgehen, falls keine geschlos-sene Lsung der beiden Lastschritte mglich 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 Bercksichtigung der Umform-historie und im Zusammenhang mit der ganzen Karosserie identifiziert werden kann.Der Bedarf, den Ort einer Beulneigung belastbarer vorhersagen zu knnen, ist eineMotivation, das zugrunde liegende FE-Modell mit den Einflssen aus der Herstellungzu verbessern. 53 54. Zur Definition von Ampelkriterien fr die Lacktrocknungssimulation innerhalb desModul-Cockpits ist sowohl ein Erreichen der geforderten Prozesstemperaturen, alsauch das Einhalten der Haltedauern fr diese Temperaturen erforderlich. Alle direktaus der Temperatur ableitbaren Kriterien knnen hnlich, einfacher oder komplexerwie das sog. Einbrennfenster des jeweiligen Lackes (siehe Abbildung 50) bestimmtwerden. Eine Klassifizierung in Anforderungen erfllt oder nicht erfllt ist damitmglich. Die Methoden zur Automatisierung der begleitenden Eigenwertanalyse unddamit die weitgehend automatisierte Identifikation der Beulneigung stellen dies auchfr die Verformung der Karosserie im Trocknungsprozess in Aussicht.Abbildung 50: KTL-Einbrennfenster (beispielhaft fr DuPont)Als Ergebnis der Sensitivittsanalyse UmformenLackieren ist festzuhalten, dass ein gewisser Einfluss der bertragung der Blechdicken aus dem Umformen aufden Verlauf der Eigenwerte besteht. Im Projekt konnte jedoch kein Einfluss aufdie Beulanflligkeit der untersuchten Bauteile nachgewiesen werden. mit der bertragung der plastischen Vergleichsdehnungen konnte an den unter-suchten Bauteilen keine nderung des Verhaltens identifiziert werden, da die Be-lastung mit den inhomogen verteilten Temperaturdehnungen die Fliegrenzenicht erreicht hat.Fr nachgelagerte Prozesse wurde die Bedeutung der Kopplung der Lackiersimu-lation an die Prozesskette anhand der bertragung des inhomogen ausgeprgtenBake-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 durchgefhrt.54 55. 3.5Abgleich der Simulationsprozesskette an Praxisbeispielen (VW)Volkswagen hat in das Projekt die Anforderungen eines Automobilherstellers an dasSimulationsdatenmanagement eingebracht und war an der Durchfhrung von Sensi-tivittsanalysen und der Erarbeitung eines XML-basierten Datenaustauschformates2beteiligt.3.5.1 Katalog gewerkespezifischer EingangsgrenUm die Kopplung von Daten und Prozessen vorzubereiten, wurde von Volkswagenein Katalog gewerkespezifischer Eingangsgren 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 fr 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 Eingangsgren2Die Extensible Markup Language (Abk. XML; engl. fr 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 56. Eingangsdaten Umformsimulation FgesimulationLacktrocknungs-simulationGeometriedatenBauteile (.igs) undBauteile (.igs)Crashnetz, Schwei-Ziehanlagen (.igs)punktinformationenBauart/Abmessungendes TrocknersProzessdatenBlechhalterhub Position der Positionierung/ Mae Schweipfade der DsenBlechhalterkraft MechanischeTemperaturenReibwert und Randbedingungen(Ofen/Karosserie)Reibwertverteilung Typ Schweipro-Vorschub-Sickenersatzkrfte zess GeschwindigkeitBlechdickeProzesszeiten Materialdaten E-ModulE-ModulE-ModulQuerkontraktionQuerkontraktionQuerkontraktionDichte Thermischer Aus- Thermischer Ausdeh-Anisotropiewerte dehnungskoeff. nungskoeff. Fliekurve FliekurveFliekurve Tabelle 4: Katalog gewerkespezifischer Eingangsgren3.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 Prozessstufenbertragen und auch visualisiert werden knnen. 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) fr eine Software-unabhngige Visualisierung im PDM-System. Als einheitliches Datenformat fr dasDatentrgernetz wurde das standardisierte XML-Format avisiert. Mit dem Datentr-gernetz sollte eine durchgngige bertragung von Ergebnisdaten aus den einzelnenSimulationsstufen bis hin zur Crash-Simulation gelingen sowie eine Ankopplung andas PDM von VW.3Das lizenzkostenfreie JT-Format untersttzt unterschiedlichste Reprsentationen von CAD-Geometrien und erlaubt eine 3D-Visualisierung. 56 57. Zur Anbindung an TEAMCENTER/CONNECT wurde von der TU Berlin ein sog.XML-Konverter programmiert, der die Ausgabeformate der im VIPROF-Projekt ein-gesetzten Simulationsprogramme (vorzugsweise .M01-Format) einheitlich in dasXML-Format berfhren kann. Diese Ausbaustufe 1 ist in Abbildung 52 gezeigt.Unabhngig 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 knnen .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 knnen auch lizenzfreieStandard-Viewer genutzt werden, da direkt binre JT-Files ohne Nutzung des JT-Toolkits von Siemens erzeugt werden. Dies erlaubt zudem eine Unabhngigkeit vonzuknftigen nderungen seitens Siemens. Unabhngig 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 knnte 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 knnte der Mapping-Prozess sogar ganz in den XML-Konverterintegriert werden (siehe Abbildung 54), so dass kein separates Mapping-Tool mehrerforderlich wre. Ob mit oder ohne diese beiden Ausbaustufen knnen die Ergeb-nisse zwischen den Simulationsstufen nahezu automatisch bertragen werden.57 58. Abbildung 53: Ausbaustufe 2: Anbindung Mapping-Tool [PIN110] Abbildung 54: Ausbaustufe 3: Ergebnisbertragung innerhalb eines XML-basiertenDatentrgernetzes [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 Ergebnisber-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 59. Abbildung 55: Realisierter Prototyp der Kopplung der Simulationsstufen [PIN110]Volkswagen hat einen Unterauftrag an das Fraunhofer IGD, Darmstadt, zur Entwick-lung eines Konverters zur Generierung von JT-Dateien aus dem VIPROF-XML-Format fr Simulationsergebnisse der Umformsimulation vergeben. Fr die Visuali-sierung wurden u.a. die folgenden Mglichkeiten geschaffen:Falschfarbendarstellung von Blechdicke, plastischer Vergleichsdehnung, Ver- gleichsspannungen (von Mises) mit einstellbarem Farbintervall. Die Darstellung der Ergebnisgren (Minimal-Wert = blau, Maximal-Wert = rot) kann in true color mit kontinuierlichem oder auch mit diskretem Farbbergang erfolgen. Die Farbskalierung wird beim Schreiben des JT-Files erzeugt.Gruppierung von Bauteilen (siehe Abbildung 56). Unterschiedliche JT-Dateien knnen als Baugruppe dargestellt werden. Die Bauteile knnen separat ein- und ausgeblendet werden.Abbildung 56: Gruppierung von Bauteilen als Mglichkeit der Visualisierung von CAE-Daten in JT-Viewern [PIN110]59 60. Die erzeugten JT-Geometrien reprsentieren das ursprngliche FEM Netz. DasEin- und Ausblenden des FEM-Netzes in der JT-Visulisierung ist mglich(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 61. 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 Ergebnisgren auf verschiedene Weise gem Benutzervorgabendargestellt werden knnen, z. B. mit flieender oder diskreter Farbanzeige, mit An-gaben von Dickennderungen in mm oder % usw. Verschiedene CAE-Teile sind alsBaugruppe darstellbar. Sie knnen im Kontext ihrer Umgebung oder des Gesamt-fahrzeuges gezeigt werden. Die Unabhngigkeit der JT-basierten Visualisierung vonLizenzkosten kommt auch der Nutzbarkeit durch mittelstndische 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 BenchmarkOneStep-SolverUm in der frhen 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 bentigt lediglich die CAD-Geometrie des Bauteils sowie die Ma-terialdaten. Durch eine Rckrechnung der umgeformten Geometrie auf die ebenePlatine werden die plastischen Dehnungen und die Blechdickenverteilung berechnet.61 62. Auch eine Abschtzung der erforderlichen Platinengre gelingt mit einem OneStep-Solver. [PIN209]Von Interesse war die mit einem OneStep-Solver erreichbare Genauigkeit, verglichenmit der Realitt und der inkrementellen Umformsimulation. Um die Ergebnisqualittvon OneStep-Solvern der Umformsimulation beurteilen zu knnen hat Volkswageneinen Praxisabgleich von Simulationsergebnissen vorgenommen. Fr die folgendendrei OneStep-Solver wurde ein Benchmark durchgefhrt. FTI-FormingSuite 7.2 ESI PAM-TFA for Catia V5 AutoForm Onestep for Catia 1.1Als Bewertungsgrundlage fr den Benchmark wurde die Ergebnisgre Blechdickegewhlt, da diese eine hohe Relevanz fr 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 Ultraschallmessgert einge-setzt. Es wurden fnf 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 Ergebnisgre bewertet (gr-ner Bereich falls relativer Fehler 5%, gelb falls 5-10%, rot falls >20%). [PIN209]Abbildung 60: Bewertungskriterien des Benchmarks [PIN209] 62 63. Ebenfalls untersucht wurde der Einfluss der Rckhaltekraft am Bauteilrand, wobeidiese Kraft beim Umformen schrittweise erhht wurde (siehe Abbildung 61).Abbildung 61: Untersuchung Einfluss Rckhaltekraft am Bauteilrand bei Benchmark-teil 3 (Abschlussblech). Aufgetragen ist die bewertete Zahl der Messpunkte ber der Rckhaltekraft fr die Solver A, B und C. [PIN209]Als Resultat ist festzuhalten, dass diese Rckhaltekrfte am Bauteilrand fr dieOneStep-Simulation notwendig sind, um den Einfluss der Ankonstruktion nhe-rungsweise in der One-Step Simulation zu bercksichtigen 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 Realitt.[PIN209]Auerdem wurden die Ergebnisse der drei OneStep-Solver mit inkrementellen Simu-lationsergebnissen verglichen. Um eine Gtekennzahl fr den Vergleich der Ergeb-nisqualitt zu erhalten wurden den Solvern fr jedes Ergebnis eines Messpunktesentsprechend der einzelnen Wertebereiche folgende Punkte vergeben: grn = 1Punkt, gelb = 0,5Punkte, rot= 0Punkte.Die Ergebnisqualitt in Form der Gtekennzahl als Summe dieser Punkte ist fr diebetrachteten Solver in Abbildung 62 dargestellt. Es wird ersichtlich, dass die Ergeb- 63 64. nisqualitt 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 Abhngigkeit der Bauteilkomplexitt, mit Zeitenzwischen 3 s und 6 min recht moderat. [PIN209]Abbildung 62: Vergleich der Ergebnisgte der OneStep-Solver [PIN209]Wird die Blechdickenverteilung fr die B-Sule des Touran betrachtet, liefert dieOneStep-Simulation ein qualitativ gutes Ergebnis (siehe Abbildung 63), welches esplausibel erscheinen lsst, in der frhen Entwicklungsphase die OneStep-Ergebnissein nachfolgende Simulationen entlang der Prozesskette zu bertragen, anstatt mitkonstanten Blechdicken weiter zu rechnen. Betrachtet man hingegen die Ergebnis-gre plastische Vergleichsdehnung werden grere Abweichungen, insbesondereim Flankenbereich, zu den Ergebnissen der inkrementellen Simulation sichtbar(Abbildung 64). Whrend die Biegeeffekte in den Radien gut wiedergegeben werden,ist dies fr Flchen in Ziehrichtung aufgrund der Biegung-Rckbiegung weniger derFall, da dieser Effekt durch die OneStep-Methode nicht abgebildet wird. Gegenberder inkrementellen Umformsimulation liefert die OneStep-Simulation in Bereichengrerer Ziehtiefen um den Faktor zwei geringere plastische Vergleichsdehnungen.Da die plastische Vergleichsdehnung ein Ma fr die Kaltverfestigung des Blech-werkstoffes ist, fallen die Ergebnisverbesserungen bei der Crashsimulation mit Um-formhistorie aus der OneStep-Simulation nur ca. halb so gro aus wie die Ergebnis-verbesserungen der Crashsimulation mit Umformhistorie aus der inkrementellen Um-formsimulation (siehe Abbildung 65). [PIN311] 64 65. Abbildung 63: Vergleich der Ergebnisgre Blechdicke aus inkrementellerund OneStep-Umformsimulation [PIN311]Abbildung 64: Vergleich der Ergebnisgre plastische Vergleichsdehnung aus in-krementeller und OneStep-Umformsimulation [PIN311] 65 66. Abbildung 65: Vergleich der Barriere-Crash-Simulation unter Bercksichtigung der inkrementellen oder der OneStep-Umformsimulation (Dargestellt ist die Verbesserung der max. Intrusionen an der B-Sule in [mm].)[PIN311]Schlielich ist zu beachten, dass die OneStep-Simulation gegenber der genauereninkrementellen Berechnung einen erheblichen Zeitvorteil aufweist: Whrend eineOneStep-Berechnung weniger als eine Minute dauert, bentigt die inkrementelle Um-formsimulation mehrere Stunden. Ein weiterer Vorteil fr die Anwendung in der fr-hen Produktentwicklungsphase ist, dass fr die OneStep-Simulation keine Werk-zeugwirkflchen bentigt 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 fr die Variantenrechnungen wurdeaufgebaut. Betrachtet wurden nur die definierten Musterbauteile im Seitencrash, dadie Berechnungen fr die Gesamtkarosserie viel zu umfangreich gewesen wren.Entsprechende Mappings fr 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 Einflsse auf das Berechnungsergebnis erfassbar, und nicht zuletztkonnte das Verhltnis von Aufwand zu Nutzen hinsichtlich einzubeziehender Pro-zesssimulationen beurteilt werden. 66 67. Abbildung 66: Bewertung der Prozesskettensimulation anhand von Crash- Simulationen [PIN309]3.5.4.1 Mapping von Umform- auf Crash-Simulation (Varianten 1 und 2)Als weiterer Vergleich der beiden Solver-Varianten wurde im Rahmen einer globalenSensitivittsanalyse ein Mapping der Onestep- und der inkrementellen Umformsimu-lation auf die Crash-Simulation durchgefhrt und ausgewertet (entsprechend denVarianten 1 und 2 in Abbildung 66). Die Auswirkungen werden durch die Ergebnis-gren Eindringtiefe und Gre des berlebensraums aus der Crash-Simulationbewertet. Betrachtet wird dabei ein Seitenaufprall als Pfahl- und als Barriere-Crash.Diese gem der Euro-NCAP-Vorschrift durchgefhrten Crash-Simulationen sind inAbbildung 67 gezeigt. Neben den Musterbauteilen der B-Sule wurde mit dem Sitz-quertrger ein zustzliches Bauteil einbezogen (siehe Abbildung 68). [PIN210]Mit der maximalen Eindringtiefe (Intrusion) und dem berlebensraum wurden Krite-rien definiert, mit denen verschiedene Varianten der Bercksichtigung der Ferti-gungshistorie bewertet werden knnen (siehe Abbildung 69). 67 68. Abbildung 67: Crashmodell fr globale Sensitivittsanalysen im Seitenaufprall(links: Pfahl-Crash, rechts: Barriere-Crash) [PIN210] Abbildung 68: Sitzquertrger fr Crash-Simulation [PIN210]Abbildung 69: Kriterien zur Bewertung unterschiedlicher gekoppelterBerechnungsvarianten [PIN210] 68 69. Gegenber der Referenz ohne Bercksichtigung der Umformhistorie (Blechausdn-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 Bercksichtigung der Umformhistorie ergab die in Tabelle5 gezeigten Ergebnisse, wobei erneut deutlich wird, dass die Crashergebnisse mitinverser Umformsimulation zwischen den Ergebnissen ohne Bercksichtigung derHistorie und denen der inkrementellen Umformsimulation liegen, was auf die halb sogroen plastischen Vergleichsdehnungen aus der OneStep-Simulation zurckzufh-ren ist. [PIN311]Ergebnisgren bei Pfahl-Crash Inkrementelle Um- Inverse Umformsimu- formsimulationlationESI PAM-STAMPForming Suite 8.1Strukturverhalten: Max. IntrusionVerbesserung um Verbesserungum 4 mm2 mmberlebensraum:Verbesserung um Verbesserungum 6 mm3 mmTabelle 5: Ergebnisverbesserung der Crash-Vorhersage mit Umformhistorie [PIN311]Fr die Kopplung von der Umform- zur Crash-Simulation wurden folgende Aussagenabgeleitet bzw. relevante Ergebnisgren identifiziert [PIN311]: Die Auswertung der Crash-Berechnungen hat gezeigt, dass die Blechausdn-nung und die plastische Dehnung den grten Einfluss auf das Crash-Ergebnishaben. Diese Gren sollten in die Crash-Simulation bertragen werden. Die jeweils einzelne bertragung von Blechausdnnung und plastischen Deh-nungen ist nicht zielfhrend. Durch Mapping der Ausdnnung ohne die zugehri-ge Werkstoffverfestigung wird die Bauteilstruktur knstlich geschwcht und dieCrash-Ergebnisse verschlechtern sich. Das Mapping der plastischen Dehnungen 69 70. (als Ma fr die Verfestigung) ohne die zugehrige Materialausdnnung fhrt zueiner knstlichen Verbesserung des Crash-Verhaltens in der Simulation. Ein Mapping von Spannungen erscheint wenig sinnvoll, da die Einflsse im Be-reich des Grundrauschens des Crash-Modells liegen. Die Feststellung, dass die OneStep-Methode in Bereichen hoher Ziehtiefe zu ge-ringe plastische Vergleichsdehnungen liefert, hat sich in der Crash-Simulation un-ter Bercksichtigung der Umformhistorie besttigt. Die Ergebnisse mit Berck-sichtigung der OneStep-Ergebnisse zeigen im Vergleich zu den Crash-Simulationen mit inkrementeller Umformhistorie den Einfluss der um die Hlftereduzierten plastischen Vergleichsdehnung (Kaltverfestigung). Daraus leitet sichdie Empfehlung ab, die OneStep-Simulation fr Bauteile mit sehr groen Ziehtie-fen nicht einzusetzen.3.5.4.2 Mapping von Umform- ber Fge- auf Crash-Simulation (Varianten 3, 4und 5)Volkswagen hat Schweiverzugssimulationen der B-Sule auf Basis von Daten vonESI durchgefhrt und einen Praxisabgleich der Simulationsvarianten mit und ohneUmformhistorie im Messlabor der VW AG anhand mehrerer realer Schweibaugrup-pen der B-Sule durchgefhrt (siehe auch Kapitel 3.5.5.1). Werden die Blechdickenund die plastischen Dehnungen aus der inkrementellen Umformsimulation in dieSchweiverzugssimulation bertragen, zeigt sich ein signifikanter Einfluss. Am Kopfder B-Sule 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 strkerab. Die Verbesserung der Ergebnisqualitt der Schweiverzugssimulation konnteauch mit Bercksichtigung der Umformhistorie (Blechdicken und plastische Ver-gleichsdehnungen) aus der OneStep-Simulation erzielt und im Praxisabgleich best-tigt werden (siehe Abbildung 71). [PIN311]70 71. Abbildung 70: Auswirkungen der Bercksichtigung der Historie aus der inkrementel-len Umformsimulation in der Schweiverzugssimulation [PIN310]Abbildung 71: Vergleich Auswirkungen der Historie aus der inkrementellen Umform- simulation (oben) und OneStep (unten) in der Schweiverzugssimulation [PIN311]Auch ein Mapping von Spannungen oder Verzgen aus dem Fgeprozess in dieCrash-Simulation erscheint wenig sinnvoll, da die Einflsse im Bereich der numeri-schen Streuung des Crash-Modells liegen. Die Schweiprozesse (Laser- und Wie-derstands-Punkt-Schweien) fhren nicht zu groflchig signifikanten nderungen 71 72. der Blechdicken und plastischen Vergleichsdehnungen, so dass diese Gren direktaus dem Umformen in die Crash-Simulation weitergeleitet werden knnen.Die Erkenntnis, dass die bertragung von Blechdickenverteilung und Verfestigungsinnvoll ist, von Spannungen dagegen nicht, kommt dem bertragungsprozess ent-gegen: Whrend die Blechdicken und Verfestigungen als skalare Gre leicht ber-tragen werden knnen, msste in die bertragung der Spannungstensoren mehrAufwand investiert werden. Anders sieht dieser Sachverhalt aus, wenn man anstelledes verwendeten Schweiverzugssimulationstools Weld Planner (Nutzung von F-gestellenersatzmodellen) ein transientes Schweiverzugssimulationstool verwendet(z. B. mit SYSWELD). Hier knnen die Eigenspannungszustnde durchaus einensignifikanteren Einfluss auf das Simulationsergebnis haben.3.5.4.3 Mapping von Umform- ber Fge- auf Lacktrocknungssimulation (Va-rianten 6, 7 und 8)hnlich wie bei der Fgesimulation 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 Fliegrenze 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 virtuellenPrfstand aufgebracht, die auf jeden Fall zum Beulen fhren. Bei Bercksichtigungder Blechdicken konnte man den Einfluss der Blechdicke in den ermittelten Eigenfre-quenzen der begleitenden Eigenwertanalyse zwar erkennen, aber alle im Projekt un-tersuchten Blechteile einschlielich des Seitenrahmens waren bei den vorgegebenenOfenlasten so unkritisch gegenber Beulverhalten, dass hier der Einfluss auf dieBeulneigung nicht quantifiziert werden konnte. Dies war auf den Reifegrad der ver-wendeten Serienbauteile zurckzufhren. [CSB11]3.5.4.4 Mapping von Umform- ber Lacktrocknungs- auf Crash-Simulation (Va-rianten 9 und 10)Die Sensitivittsanalyse 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 73. 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 Fliegrenze aufgrund desUmformens einen vernachlssigbaren Einfluss [CSB11].Die bertragung der Blechdickenverteilung kann einen Einfluss auf die Lacktrock-nung haben, da sich durch unterschiedliche Blechdicken die Wrmeleitung verndert[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 Ergebnisgren 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-Zustnde der Bauteile mit den zugehrigen modifizier-ten Fliekurven in der Crash-Simulation zu bercksichtigen. [CSB11]3.5.5 Validierung der Prozesskettensimulation3.5.5.1 Validierung durch Messung des SchweiverzugsVolkswagen hat einen Praxisabgleich der Schweiverzugssimulation (ESI-WELDPLANNER) fr die gewhlte Musterbaugruppe (siehe auch Kapitel 3.3.5, Ab-bildung 32) durchgefhrt. 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 Schweiverzugssimulation werden nachfolgend vorgestellt und mit deman der realen Baugruppe ermittelten Schweiverzug verglichen. Die Messergebnissedes Verzuges in y-Richtung sind in Abbildung 72 dargestellt. Fr eine statistischeAbsicherung wurden mehrere Schweibaugruppen vermessen. Die berechnete Ver-drehung aus den Simulationsmodellen zeigt Abbildung 73. [PIN310] 73 74. Y +0,0 Y -0,1Y +0,5 Y -0,2 Y +0,5z -yxAbbildung 72: Messergebnisse des y-Verzuges an der B-Sule (in mm) und Verdrehungsrichtung [PIN310] a)b)z x zxyy-0,10,0 Abbildung 73: Verzug in y-Richtung der B-Sule:CAD-Modell (a) und Kopplungs-Modell (b) [PIN310]Es zeigt sich deutlich der Einfluss der Umformhistorie auf das Ergebnis der Schwei-verzugssimulation. Whrend die B-Sule des CAD-Modelles sich weitestgehend inpositive y-Richtung verzieht, stellt sich an der B-Sule des Kopplungs-Modellesteilweise ein negativer y-Verzug ein. Noch deutlicher wird der Einfluss der Umform-historie auf das Simulationsergebnis bei Betrachtung der Verdrehungsrichtung amKopf der B-Sule im Vergleich mit der Praxismessung. Erst mit Bercksichtigung derUmformhistorie (Blechausdnnung und plastische Dehnungen) wird die am Kopf derB-Sule auftretende Verzugsrichtung in der Schweiverzugssimulation entsprechendder Praxismessung richtig berechnet. [PIN310]74 75. 3.5.5.2 Validierung mit 3-Punkt-BiegeversuchVolkswagen hat einen 3-Punkt-Biegeversuch fr die B-Sule aufgebaut, wie in Abbil-dung 74 gezeigt. Darauf wurden die B-Sule und die Verstrkung der B-Sule zer-strend geprft, 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 Blechausdnnung 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-Sule [nach PIN311]Der Vergleich der Versuchsergebnisse mit der Simulation, in der die Umformhistoriemit Blechdicken und plastischen Dehnungen bercksichtigt 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 76. Abbildung 75: Vergleich Simulation und Biegeversuch an der B-Sule [PIN311]Weiterhin wurden Bauteile aus einem Material mit ausgeprgtem 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 Bercksichtigung 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. fr jedes relevanteEinzelteil muss die Herstellbarkeit gegeben sein, bevor es durch eine grne Ampelfr den nchsten Fertigungsprozess freigegeben wird (siehe Abbildung 76). [PIN109] Abbildung 76: Reifegrad-Cockpit fr die simulationsbasierte Herstellungsbewertung [PIN109]76 77. Die Definition von Ampelkriterien wird nachfolgend beispielhaft fr die Lacktrock-nungssimulation erlutert. Fr eine ausreichende Lacktrocknung ist sowohl das Er-reichen der geforderten Prozesstemperaturen, als auch das Einhalten der Halte-dauern fr diese Temperaturen erforderlich. Diese Kriterien knnen fr den jeweiligenLack dem sog. Einbrennfenster (siehe Abschnitt 3.4, Abbildung 50) entnommen undin den Workflow aufgenommen werden. Analog dieser Vorgehensweise wurden auchfr die anderen Simulationsgewerke Ampelkriterien fr die Herstellbarkeit definiert.Literatur:[PIN109] Pinner, S. et al.: Durchgngige 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. Mrz, Darmstadt, 2010.[PIN210] Pinner, S.: Lieferantenintegration am Beispiel der Prozesskette Umformen-Fgen-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 Fgesimulation, 15. Internationale Konferenz fr Simulation und Berechnung - SIM- VEC, 16. - 17. November, Baden-Baden, 2010. 77 78. [PIN111]Pinner, S.: Visualisierung von CAE-Ergebnisdaten im JT-Format.Fachkonferenz Berechnung im Produktprozess, 10. Februar,Braunschweig, 2011.[PINSB11] Pinner, S.; Steinbeck-Behrens, C.: bersicht Prozesskettensimu-lation. 2. VIPROF Industriearbeitskreis, 22. November, Stuttgart,2011.[PIN311]Pinner, S.: Prozesskettensimulation im Karosseriebau. 2. VIP-ROF Industriearbeitskreis, 22. November, Stuttgart, 2011.[CSB11] Steinbeck-Behrens, C.; Menke, T.: Lackiersimulation in der Pro-zesskette. 2. VIPROF Industriearbeitskreis, 22. November, Stutt-gart, 2011.3.6 Strukturierte Ablage heterogener Daten im Kontext von Wie-derverwendbarkeit und Weiterverwendbarkeit (TU Berlin)3.6.1 AllgemeinesTeilprozesse heutiger Simulationsprozessketten sind weitestgehend ungekoppelt,d.h., dass einzelne Teilprozesse keine datentechnische Verbindung mit ihren Nach-folgern/ Vorgnger besitzen. Dies ist durch Inkompatibilitt der innerhalb der einzel-nen Teilprozessschritte verwendeten Datenformate und ihrer verarbeitenden Prog-ramme untereinander zu begrnden. Sollte doch eine Verbindung bestehen, ist diesemeist mit viel Handarbeit also das Transformieren der Daten von Hand, um sie Fol-geprozessen zugnglich zu machen verbunden. Dieser Umstand verhindert jedochmageblich die Durchgngigkeit 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 mssen die un- terschiedlichen Datenformate lesen knnen.2. Die verschiedenen Programme der einzelnen Teilprozessschritte mssen die un- terschiedlichen Daten auf die gleiche Art interpretieren. 78 79. Die Lsungen fr diese Problemstellungen sind zu 1.) Konversion also die berfh-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 Lsung wurde durch dasInstitut fr Produktionstechnik der Ostfalia Hochschule fr angewandte Wissenschaf-ten Wolfenbttel von Herrn Prof. Dr.-Ing. M. Rambke bearbeitet und in Abschnitt 3.2behandelt.3.6.2 KonversionUm Durchgngigkeit innerhalb der Prozesskette mittels Konversion, also die ber-fhrung eines Datenformates in ein anderes, zu realisieren, existieren zwei sich teil-weise berdeckende Lsungsanstze:1. Das Herstellen der Durchgngigkeit innerhalb der Prozesskette durch berfh- rung der verschiedenen Datenformate ineinander.2. Das Herstellen der Durchgngigkeit innerhalb der Prozesskette durch berfh- rung der verschiedenen Datenformate in ein generisches Format.Die Konversion mittels berfhrung jeden Datenformates in jedes andere wird alsPeer-to-Peer-Strategie bezeichnet und durch Abbildung 77 visualisiert.Abbildung 77: Peer-to-Peer-StrategieDiese Strategie ermglicht 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 gnstig, jedoch kon-stante Kosten unterstellt wachsen die Kosten fr den Konverterbau quadratisch,die Anzahl der Konverter innerhalb dieser Strategie betrgt dann n*(n-1), mit n = An-zahl der Datenformate. Da bei dieser Strategie die Definition eines Intermedirforma-tes entfllt, entwickelt sich der Gesamtkostenverlauf der Peer-to-Peer-Strategie inAbhngigkeit von der Anzahl der Formate quadratisch. Diese Strategie scheint sichbei einer geringen Anzahl von Datenformaten zu empfehlen. 79 80. Aus dieser Strategie und seiner Nachteile, lsst sich eine weitere Strategie ableiten,die in Abbildung 78 zu sehen ist, als Ring-Strategie bezeichnet wird und fr 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 fr den Konverterbau n betragen, mit n =Anzahl der Datenformate. Dies bringt gegenber 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 fr die Definition eines Intermedirformates, 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 berfhrung jeden Datenformates in ein generisches Daten-format wird als Intermedir-Strategie bezeichnet und durch Abbildung 79 visualisiert. Abbildung 79: Intermedir-Strategie80 81. Innerhalb der Intermedir-Strategie wird jedes Datenformat in ein generisches Daten-format berfhrt und zurck. Demnach sind innerhalb dieser Strategie lediglich 2*nKonverter (n = Anzahl der Datenformate) notwendig ein Konverter zur berfhrungeines proprietren Datenformates in das generische Datenformat und einer in dieGegenrichtung. Im Gegensatz zu den beiden vorhergenannten Strategien ist hierbeijedoch eine Intermedirformat 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 IntermedirformatDatenformat B), wobei die Ausfhrungskosten fr diesen Fallgleich dem Doppelten des Durchschnitts einer Ausfhrung betragen. Konvertierungs-verluste innerhalb der Intermedir-Strategie sind konstant, da sich Fehler nicht po-tenzieren knnen. Der Gesamtkostenverlauf verhlt sich fr diese Strategie linear,jedoch mit grerem Achsenabschnitt, was durch die Definition eines Intermedir-formats bedingt ist.Die Kostenverlufe sind folgend, in Abhngigkeit von der Anzahl der Formate, dar-gestellt (Rot = Peer-to-Peer, Grn = Ring, Blau = Intermedir) (Siehe Abbildung 80). Abbildung 80: Gesamtkostenverlauf der KonversionsstrategienDie Peer-to-Peer-Strategie (rot) zeigt einen steileren Kostenanstieg als dieRing-Strategie (grn), was durch die Vielzahl der notwendigen Konverter zu begrn-den ist. Die Intermedir-Strategie (blau) besitzt hhere Anfangskosten, bedingt durchdie Definition eines Intermedirformats, ist jedoch nur linear Abhngig von der Anzahlder Datenformate, sodass ein Punkt n* existiert, ab dem die Intermedir-Strategie derRing- und Peer-to-Peer-Strategie kostenmig berlegen ist. Dieser Punkt n* ist sehrniedrig, weil Tools und Methoden sehr heterogen sind, was sich ungnstig auf dieKonvertierungsverluste der Ring-Strategie auswirkt und weil die Definition einesIntermedirformats effizient und kostengnstig mglich ist, sodass der Fixkostenan- 81 82. teil der Intermedir-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 Intermedir-Strategie zu bevorzugen.Bei der Verwendung der Intermedir-Strategie ist, wie bereits mehrfach erwhnt einIntermedirformat zu definieren. XML bildet ein solches Intermedirformat, welchesbedingt durch seine Struktur gewisse Vor- und Nachteile mit sich bringt. XML ist einoffener, lizenzfreier Standard, der eine gewisse Popularitt erreicht hat und somitsoftware- und entwicklungsseitig gut untersttzt wird. Seine Popularitt lsst sich mitder Beteiligung namhafter Firmen u.a. Intel, IBM, Oracle und Microsoft am Stan-dard begrnden. XML ist ein sehr flexibles Austauschformat, welches ber die ver-schiedensten Kanle 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 Mhe und entsprechendem Sprachverstndnis sogar die Lesbar-keit durch den Menschen garantiert. Da XML, wie bereits erwhnt, offen ist, lsst essich problemlos an andere Systeme anbinden. XML wird text- und dateibasiert ge-speichert, sodass die Informationen ber jegliche Art von Netz verteilbar ist XMLalso plattformunabhngig ist. XML ist Unicode-fhig, also internationalisierbar undarbeitet mit beliebigen Zeichenstzen zusammen. Als Nachteile fr XML sind seinhherer Speicherbedarf und die langsamere Verarbeitung zu nennen. Beide Nachtei-le sind jedoch zu vernachlssigen, da zum einen Speicherplatz immer gnstiger 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 bentigten Informationen aufnehmen kann. Abbildung 81zeigt den Simulationsprozess und seine verwendeten Programme, aus denen sichdie notwendigen Informationen ergeben.82 83. 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 84. Innerhalb der Informationsanalyse wurden hierbei folgende Informationsblcke identi-fiziert, die im Rahmen der XML-Definition bercksichtigt werden mussten: Metainformationen (Daten, die die eigentlichen Informationen beschreiben) Knotendaten (Daten, die ein Netz aufspannen, aus welchem Elemente definiertwerden knnen) Elementdaten (Daten, die Elemente auf einem Netz erzeugen und ihrerseits simu-lierbare Eigenschaften aufnehmen knnen) 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. Darber 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), Informationenber das verwendete Einheitensystem und Informationen ber die Rotationsmatrix.In den Knotendaten wurden einzelne Knoten definiert. Hierzu wurde fr 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 Gaupunkte Sttzstellen zur Integration der Ansatzfunk-tionen fr die Berechnung von Elementmatrizen ber die Flche und Integrations-punkte Sttzstellen zur Integration der Ansatzfunktionen fr die Berechnung vonElementmatrizen ber das Volumen.Die Attributinformationen enthalten ein Krzel fr das simulierte Attribut (z. B. THICfr die Dicke), die Anzahl der Ergebniswerte je Element, ihre Abhngigkeit vomGau- bzw. den Integrationspunkten (dies hat Einfluss auf die tatschliche Anzahlder Ergebniswerte) und das Einheitensystem der Ergebniswerte spezifiziert durch dieFaktoren fr den Weg, die Masse und die Zeit.84 85. Die Attributwerte enthalten Informationen ber das ihnen zugehrige 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 Blcke: die Metadatenund die Simulationsdaten.Die XML-Metadaten enthalten, wie in Abbildung 83 zu sehen, nun alle Informatio-nen, die die eigentlichen Daten nher beschreiben. Abbildung 83: Metainformationen des VIPROF-XML-Datenformates in Form einerXSDInnerhalb 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. Darber hinaus enthlt dieserInformationsblock nun auch alle Metainformationen ber die simulierten Attribute, wieihren Namen, die Anzahl der Ergebniswerte, ihre Abhngigkeiten von Gau- und In-tegrationspunkten und ihr Einheitensystem. Hinzugekommen ist ein eventuell vor-handener oder notwendiger Referenzwert fr das Simulationsattribut (z. B. eine Refe-renzdicke). 85 86. Die XML-Simulationsdaten enthalten nun alle anderen Informationen der ursprngli-chen Informationsblcke, wobei hier zwei Blcke 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 enthlt(eindeutige Knotenidentifikationsnummer und die Koordinaten im Raum) und zumAnderen der Elementblock, der alle Elementinformationen vorhlt (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 frdie Zugehrigkeit eines Elements zu einem bestimmten Part und die Simulationswer-te in Form von Namen und Ergebniswerten).86 87. Abbildung 85: Beispiel-VIPROF-XML-DateiDie Abbildung 85 zeigt nun dieselben Informationen bgzl. der proprietre 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 proprietreDatenformat (z. B. M01) mittels SCAIMapper des Fraunhofer SCAI fr den nchstenSimulationsschritt aufbereitet. Parallel dazu werden die proprietren 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 ursprnglichen proprie-tren Daten werden nicht mehr bentigt und somit verworfen. Wesentliche Bestand-teile dieser Lsung, nebst ihrer Funktion sind: Der SCAIMapper: Ein vom Fraunhofer SCAI entwickeltes Programm zur Verbin-dung und Anpassung der Daten vieler auf dem Markt erhltlicher FEM-Programme und ihrer Netze unter- bzw. aufeinander. Der VIPROF-XML-Konverter: Ein im Rahmen des Projektes Virtuelle Produktionund Fertigung von Fahrzeugen erzeugtes Programm zur Konversion der im Pro-jekt anfallenden proprietren Daten und deren Rcktransformation (dies jedochmit Einschrnkungen, die spter beleuchtet werden). 87 88. Der JT-Konverter: Ein vom Fraunhofer IGD und der Volkswagen AG entwickeltesProgramm zur Konversion der im Projekt erzeugten XML-Daten mittels JT undderen Visualisierung ber das frei erhltliche Programm JT2GoAbbildung 86: Ablauf des Simulationsprozesses mit Untersttzung durch dasXML-DatenformatDiese Daten mssen nun im PDM/SDM-System abgelegt werden. Hierzu sind dieDatengren zu untersuchen, um Aufschluss darber zu erhalten, inwiefern das nunresultierende Datenaufkommen wirtschaftlich hndelbar ist. Ausgehend von denproprietren Daten, den XML-Daten sowie deren JT-Visualisierung ergeben sich fol-gende Szenarien: Szenario 1 Ablage der proprietren Daten und deren XML-Reprsentation so-wie der JT-Visualisierung: Innerhalb dieses Szenarios sind zum einen die urs-prnglichen Daten im PDM/SDM-System abgelegt und deren XML. Die Visualisie-rung der einzelnen Ergebnisse ist mit wenigen hundert Kilobyte zu vernachlssi-gen, sodass mit einem Datenaufkommen von ca. 225% gg. der ursprnglichenDatengre zu rechnen ist. Dies macht ein Datenzuwachs von 125%. Dies ist da-tentechnisch die schlechteste Variante, da zum einen Redundanzen herrschen,und zum zweiten das erhhte Datenaufkommen unwirtschaftlich erscheint. Szenario 2 Ablage der XML-Daten sowie der JT-Visualisierung: Innerhalb die-ses Szenarios sind ausschlielich die XML-Daten im PDM/SDM-System abgelegtund deren Visualisierung. Durch die Einsparung der proprietren Daten ist mit ei- 88 89. nem Datenaufkommen von ca. 125% gg. der ursprnglichen Datengre zurechnen ist. Dies macht ein Datenzuwachs von 25%. Dies ist datentechnisch dieideale Variante, da keine Redundanzen herrschen, und die Daten direkt verarbei-tet werden knnen. Szenario 3 Ablage der XML-Daten in komprimierter Form sowie der JT-Visualisierung: Innerhalb dieses Szenarios sind die XML-Daten gg. Szenario 2 inkomprimierter Form (z. B. als zip-Datei) im PDM/SDM-System abgelegt und de-ren Visualisierung. Durch die Komprimierung der XML-Daten ist mit einem Daten-aufkommen von ca. 105% gg. der ursprnglichen Datengre 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 knnen, sondernvorher dekomprimiert werden mssen.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 nachMagabe der ESI GmbH und der CADFEM GmbH bzw. ANSYS Inc. zu konvertieren;Abbildung 87 zeigt die mglichen 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 proprietre Daten XMLzu erzeugen, sondern ebenso aus den XML-Daten das ursprngliche, proprietreDatenformat zu generieren. Um aus den proprietren Daten ein einheitliches XML-Datenformat erzeugen zu knnen, sind Anpassungen an den ursprnglichen Infor- 89 90. mationen vorzunehmen, um innerhalb des XML Homogenitt 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 proprietren Daten (sowohl der ESI GmbH alsauch der CADFEM GmbH bzw. der ANSYS Inc.) werden so die Beschrnkungeninnerhalb des Projektes als Viereckselemente abgelegt, haben also vier Knoten,die ein solches Element aufspannen. Eine solche Definition lsst es jedoch zu, auchDreieckselemente abzulegen, wofr es jedoch zwei potentiell zu unterscheidendeMglichkeiten gibt: Die Dreieckselemente werden mit vier Knoten abgelegt, wobei der letzte, nichtvorhandene Knoten, mit 0 belegt wird. Die Dreieckselemente werden mit vier Knoten abgelegt, wobei der letzte Knotenidentisch dem Vorletzten ist, als zwei Knoten bereinander liegen und so einDreieckselement aufspannen.Der XML-Konverter erkennt beide Ablagemglichkeiten 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 erhlt. Dies macht einen Unterschied jeElement von 3 Ergebniswerten. Der XML-Konverter erkennt diese unterschiedlichenAnstze und erzeugt aus den vier Knotenwerten einen Elementwert per Mittelung.Bei einer Rcktransformation ist dies natrlich 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 grer werden wrden selbst kleinere Dateien haben 70.000 Elemente,sodass hierbei 210.000 zustzliche Werte als Kommentar zu speichern sind. DerXML-Konverter nimmt bei der Rcktransformation also der berfhrung 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 Rcktransformationswert marginal unddamit vernachlssigbar sind.90 91. 3.6.4.2 BegrenzungenDie unterschiedliche Ablage der Daten innerhalb der proprietren 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 knnen (z. B. fr 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 Mglichkeiten 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 berfhrung von Knotendaten auf Element-daten und deren Rcktransformation. Wie besprochen werden bei der Rcktransfor-mation die am Knoten angrenzenden Elemente benutzt, um mit deren Hilfe einenKnotenwert zu berechnen. Dabei bleibt unbercksichtigt, welche Gre die einzelnenElemente besitzen und daraus folgend auch ihr Einfluss auf den resultierenden Kno-tenwert, d.h. ob grere Elemente mehr Einfluss auf den Knotenwert haben sollten.Dieser Umstand ist ersten Vermutungen nach zu bercksichtigen, im Rahmen desProjektes jedoch nicht weiter ausgefhrt.Daraus ergibt sich, dass, bedingt durch die unterschiedliche Speicherung bestimmterDaten, eine Transformation von einem Datenformat ber XML in ein anderes nichtmglich ist. Der XML-Konverter erkennt das Ursprungsformat und lsst eine Rck-transformation nur in diese kompatiblen Datenformate zu.91 92. 3.7 Entwicklung einer systembergreifenden Datenablage imPDM-System zur Realisierung einer durchgngigen Simulati-onsprozesskette (TU Chemnitz, ARC Solutions GmbH)3.7.1 Problemstellung und ZieleDie Basis fr die Schaffung einer durchgngigen 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 durchgefhrt, vorhandene Prozessbe-schreibungen ausgewertet und die einzelnen Simulationsprogramme untersucht.Fr die Abbildung der Prozesse wurden unterschiedliche Modellierungsmethoden aufihre Einsatzfhigkeit geprft. Als besonders geeignet fr die Modellierung der zu be-trachtenden Prozessketten hat sich die Methode der ereignisgesteuerten Prozessket-ten herauskristallisiert. Mit dieser Methode ist es mglich den Prozessablauf mit allenEin- und Ausgabedaten, den ausfhrenden Stellen und die genutzten Anwendungs-systeme in einem Modell darzustellen.Nach der Modellierung der Ist-Prozesse wurde eine Schwachstellenanalyse durchge-fhrt. Die Analyse der Ist-Prozesse zeigte die unabhngige Arbeitsweise der einzel-nen Teilbereiche. Der Simulationsbereich ist charakterisiert durch eine groe 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 bercksichtigt.Es wurde ersichtlich, dass die meisten Simulationsdaten in verschiedenen Dateisys-temen abgelegt werden und somit keine durchgngige, konsistente und einheitlicheDatenablage gewhrleistet ist. Die Datenbeschaffung fr 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 Prozessablufe. Hier bietet sich92 93. 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 fr die Realisierung einer durchgngigen Simulationsprozesskette wur-den daher die Realisierung einer vollstndigen Datenablage, die Definition von Refe-renzprozessketten zum Datenmanagement und deren Automatisierung ber Work-flows definiert.3.7.2 Durchgngiges 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. Dafr bietetsich der Einsatz eines Produktdatenmanagementsystems an. Es bildet eine Integra-tionsplattform fr alle eingesetzten Datenerzeugungssysteme (PPS-Systeme, CAX-Systeme, diverse Applikationen, Projektmanagementsysteme, Officesysteme undSimulationsprogramme), was allen Daten ber den gesamten Produktentwicklungs-prozess entspricht [VDI2219].93 94. Abbildung 89: Beispiele fr produktbeschreibende Datenim ProduktentwicklungsprozessAuf dem Markt gibt es eine Vielzahl von PDM-Systemen, die verschiedene Ausstat-tungsmerkmale aufweisen. Unterschiede gibt es hinsichtlich: der Ausprgungen der einzelnen Funktionskomponenten, des Umfangs der Workflowkomponente, der vorhandenen Schnittstellen, der genutzten Softwareplattform, der Art der Architektur, der Systembedienbarkeit und -stabilitt, des Bekanntheitsgrades, der Herstellerbetreuung, des Preis-Leistungsverhltnisses.Fr das durchgngige Datenmanagement musste aus dem groen Angebot ein ge-eignetes PDM-System ausgewhlt werden. Dazu wurde im Vorfeld eine entspre-chende Anforderungsanalyse durchgefhrt. Neben den generellen Anforderungen,die an die Einfhrung und den Betrieb von PDM-Systemen inkl. Workflowfunktionali-tt gestellt werden, kamen spezielle Anforderungen fr die durchgngige Datenabla-ge, die bei der Auswahl Prioritt besaen, hinzu. Anhand des entwickelten Anforde-rungskataloges erfolgte die Auswahl des PDM-Systems.94 95. 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, Suchfunktionalitten, nderungsmanagement, Klassifizierung, Anwendungsintegration, Archivierungs- und Backupmechanismen, Benutzerverwaltung, Authentifizierung und Zugriffsverwaltung, Customizing, Einbau- und Verwendungsnachweise sowie Workflowfunktionalitt.Abbildung 90: Funktionen TeamcenterEin weiterer Vorteil ist das Modul Teamcenter for Simulation, das fr die Speicherungund Verwaltung von Simulationsdaten entwickelt wurde. Es bietet ein umfassendesDatenmodell zur Verwaltung von auf Computer-Aided Engineering (CAE)basierender Geometrie, vernetzten Modellen, ausfhrungsfertigen Decks,Ergebnissen und Berichten, sodass die passenden Daten fr die virtuellenPrototypen leicht auffindbar und wiederverwendbar sind [TEAM09]. 95 96. Das System gehrt zu den meist verkauften Systemen auf dem Markt und seineKonzeption ist sowohl fr Grounternehmen als auch fr Mittelstndler interessant.Haupteinsatzgebiet ist der Produktentwicklungsbereich. Hier knnen alle erzeugtenDaten und Dokumente von verschiedenen Anwendungssystemen abgebildet werden,wie beispielsweise Office-Dokumente, Ideen- und Produktbeschreibungen,Anforderungen, Pflichtenhefte, CAX-Daten,Stcklisten,Zeichnungen,nderungsanweisungen, Service-Bulletins und Layoutplne. 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 fr die geplantenArbeiten als besonders geeignet heraus.3.7.3 Entwicklung von DatenablagestrukturenBei der Entwicklung einer geeigneten Datenablagestruktur fr unterschiedliche Pro-duktdaten musste besonders auf Flexibilitt geachtet werden. Zum einen bestand dieAnforderung unterschiedliche Datenformate abzulegen und zum anderen musste dieStruktur verschiedene Bauteilvarianten, wie sie in der Automobilindustrie hufig vor-kommen, abbilden knnen. 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 knnen. Abbildung 91: Verschiedene Varianten eines BauteilsSchnell zeigte sich, dass das zu entwickelnde Datenmodell in Teamcenter nicht aus-schlielich aus einer Struktur bestehen kann, sondern mehrere, sich einander ergn-96 97. zende und miteinander kombinierbare Strukturen, beinhalten muss. Hierfr wurdenunterschiedliche Strukturen auf der Basis von produkt- und fertigungsspezifischenGrundstrukturen entwickelt.Die folgenden vier neuen Datenablagestrukturen fr 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 unabhngig von der spteren Fge- und Ferti-gungsreihenfolge. Da bei der Bauteilkonstruktion die Entwicklung nicht mit der erstenZeichnung abgeschlossen ist, knnen im PDM-System Revisionen zu Ablage unter-schiedlicher Entwicklungsstnde genutzt werden. Wurde keine andere Regel verein-bart, gilt die letzte Revision stets als die Arbeitsversion, welche fr andere Nutzersichtbar ist. In Abbildung 92 ist die Entwicklungsproduktstruktur des VIPROF-Demonstrators dargestellt. Abbildung 92: Entwicklungsproduktstruktur des VIPROF-Demonstrators97 98. Im Projekt wurden als Betrachtungsumfang das Seitenteil aus dem Fahrzeug TouranGP2 ausgewhlt. Dabei wurde im Bereich des Fahrzeugaufbaus die B-Sule inklusi-ve der Verstrkung und der Gewindeplatten betrachtet und im Bereich des Fahr-zeugunterbaus das Bodenteil sowie der Sitzquertrger bercksichtigt.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 Stckliste, 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 fr das Presswerk. Inder Struktur enthalten ist die im VIPROF-Projekt betrachtete B-Sule. 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 gehrendePlatine und eine Verlinkung zu den entsprechenden Konstruktionsdaten vorhanden.Auf den Strukturaufbau fr Simulationsdaten, welcher ansatzweise ebenfalls in Ab-bildung 94 dargestellt ist, wird im weiteren Verlauf dieses Berichtes nher eingegan-gen. 98 99. Abbildung 94: Technologieprozessreihenfolgestruktur des VIPROF-DemonstratorsAlle einzelnen Strukturen sind, soweit erforderlich, miteinander verknpft. Dieses set-zen von Links bzw. Referenzieren auf eine andere Struktur untersttzt die Redun-danzfreiheit und verhindert das mehrfache Abspeichern von identischen Daten. Den-noch haben die unterschiedlichen Arbeitsbereiche (z. B. Konstruktion, Fertigung) nurZugriff auf die fr sie bestimmte Struktur und die darin enthaltenen sowie verlinktenDaten.Abbildung 95: Beispiel einer Verknpfung der einzelnen Strukturen untereinanderIn Abbildung 95 wird beispielhaft dargestellt, wie die Verknpfung 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 Fahrzeugherstellung99 100. eingebaut wird. Zustzlich 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 Fgen (Falzen) geschlossen, wodurch sichbis zu diesem Operationsschritt das reale Bauteil von dem fertig konstruierten Bauteilunterscheidet.Die vierte Struktur, die SDM-Struktur (Simulationsdatenmanagementstruktur), wurdespezielle fr die Ablage von Simulationsdaten in einem Produktdatenmanagement-system entwickelt. Das Ziel bestand darin, alle whrend des Produktentwicklungs-prozesses anfallenden Simulationsdaten innerhalb eines PDM-Systems zu speichernund so eine konsistente Datenbasis fr alle Teilprozesse aufzubauen. Dazu wurdezunchst das Standarddatenmodell von Teamcenter analysiert.Grundstzlich lassen sich in einem PDM-System jegliche Arten von Daten ablegen.Um Teamcenter jedoch mit Daten zu fllen, werden verschiedene Container ben-tigt. Dabei basiert Teamcenter auf unterschiedlichen Objekten, die durch Relationenmiteinander verbunden und so Abhngigkeiten abgebildet werden knnen. Der stan-dardisierte Ansatz zur Speicherung von Daten in einem PDM-System ist das Item(Objekt). Es dient als Sammelcontainer fr 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 nderungsstnden. 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 101. Mit den genannten Items und ihren Unterordnern lassen sich die Bauteilgeometrienproblemlos in Teamcenter hinterlegen. Fr die Ablage von Simulationsdaten wirdallerdings ein Konzept bentigt, welches zum Ersten die gegebenen Standards desPDM-Systems verwendet, zum Zweiten die Anbindung und einheitliche Ablage vonDaten unterschiedlicher Simulationstools ermglicht und zum Dritten alle im Entwick-lungsprozess entstehenden Datenvarianten untersttzt. Dazu werden im PDM-System verschiedene Objekte erzeugt, die alle erforderlichen Daten aufnehmen kn-nen. Pro Simulationstyp ist im Projekt ein gesondertes Datenobjekt vorgesehen, wo-bei es sich um die Umform-, die Fge-, die Lackier- und die Crashsimulation handelt.Auch fr die Speicherung von Simulationsdaten stehen in Teamcenter bereits vierItemtypen zur Verfgung (Abbildung 97). Abbildung 97: Itemtypen fr 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 fr die Simulationabgelegt und unter dem Result-Item knnen die Ergebnisse gespeichert werden. ImVIPROF-Projekt werden lediglich die ersten drei Objekte verwendet. Die Ergebnissewerden direkt am Analyse-Objekt angehngt, wodurch auf das Result-Item verzichtetwerden kann.Zustzlich zu den Standarditemtypen fr die Simulationsdaten wurde fr 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 102. Abbildung 98: Aufbau der Ablagestruktur fr SimulationsdatenDas Preprocessing bei einer Simulation beinhaltet die Dateneingabe. Daher enthltdieser Ordner auch alle bentigten Inputdaten, wie zum Beispiel einzelne Geo-metrien, Materialdaten, Maschinenkonfigurationen sowie weitere notwendige Einga-beparameter. Whrend des Solving wird die Simulation berechnet. Im gleichnamigenOrdner knnen 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 vollstndige Datenab-lage entlang der Prozesskette gewhrleistet werden.Fr 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 103. Abbildung 99: Verknpfung von Simulationsprogrammen ber ein PDM-System Abbildung 100: Produktstruktur103 104. In der Fertigungsprozessplanung hingegen werden alle an einem Fahrzeugprojektausgefhrten Prozesse abgebildet (Abbildung 101). Weiterhin werden die Inputdatenfr die Simulation und deren Ergebnisse bereitgestellt. Eine genauere Erluterungder Beziehungen zwischen den einzelnen Objekten erfolgt in Abschnitt 4.Abbildung 101: Fertigungsprozessstruktur mit Beispiel Umformprozess der B-SuleFr 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 dazugehrigen Simulationen in Teamcenter anzeigen.Zusammenfassend lsst 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 zustzlich die Fertigungshistorie in den nachfolgenden Simulations-schritten bercksichtigt. Eine solche Kopplung wurde mittels offener Schnittstellenverwirklicht, sodass weitere Simulationstools zu jedem spteren Zeitpunkt angebun-den werden knnen. Weiterhin sind ber ein im PDM-System enthaltenes Workflow-system alle Teilprozesse voll- bzw. teilautomatisiert miteinander verbunden. Der104 105. 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 durchgngigen Simulationsprozesskette,die einen Datenaustausch zwischen den Einzelprozessen erlaubt. Dazu wurden Re-ferenzprozesse entwickelt, welche die durchgngige Prozesskettensimulation unters-ttzen 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. Derberblicksprozess veranschaulicht die gesamte durchgngige 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 fr 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 mglichen Pfade fr dieProzesskette abzubilden. Falls in einigen Teilgewerken die entsprechenden Zielgr-en nicht erreicht werden knnen, mssen entsprechende Rcksprnge definiertwerden. Abbildung 103 zeigt mgliche festgelegte Rcksprungvarianten, die in den105 106. Referenzprozessketten teilweise Bercksichtigung finden. Diese Referenzprozess-ketten bilden die Basis fr die Steuerung des Gesamtprozesses. Abbildung 103: Festgelegte ProzessvariantenEin weiterer Schwerpunkt lag auf der Festlegung einer einheitlichen standardisiertenDatenablage von einzelnen Simulationssystemen. Hierfr wurden die in diesem Zu-sammenhang ablaufenden Prozesse analysiert. Abbildung 104 erlutert den kreis-laufhnlichen Ablauf des Simulationsprozesses bei der Datenbereitstellung und Da-tenablage. Weiterhin wird der Zusammenhang zwischen den unterschiedlichenStrukturen, welche im Abschnitt 3.7.3 erlutert wurden, verdeutlicht. Abbildung 104: Simulationsprozessablauf mit Datenbereitstellung und Datenablage106 107. Zunchst 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 anschlieend zurck in das PDM-System und somit in dieentsprechenden Strukturen geladen. Dabei werden eine automatische Formatum-wandlung und das Mapping durchgefhrt.Fr die Durchfhrung dieser Simulationen wurden ebenfalls die entsprechenden Pro-zessketten analysiert. Die Analyse ergab, dass fr alle im Projekt betrachteten Simu-lationen der Ablauf gleich abluft. Entsprechend wurde der in Abbildung 105 darge-stellte Referenzprozess fr die Durchfhrung einer Simulation festgelegt. Abbildung 105: Referenzprozesskette fr das SDM in VIPROFDer Prozess beginnt mit der Vergabe der Simulationsaufgabe an den Planer. DessenAufgabe ist die Beschaffung aller fr die Simulation notwendigen Eingabedaten undderen Ablage im PDM-System. Anschlieend whlt er einen Berechner (Simulanten)fr die Aufgabe aus und bermittelt ihm die Arbeitsaufgabe. Im nchsten Schritt fhrtder 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 fr die Datenbertragung zwi-schen den Systemen notwendig ist. Anschlieend fhrt der Planer einen Freigabe-prozess durch, bei dem er ber die Gte der Simulationsergebnisse entscheidet. Die107 108. 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 fr 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 auszufhrenden Funktionen sicher [MHL05].Die Workflowkomponente in einem PDM-System stellt eine Umgebung zur Erzeu-gung von Workflowmodellen sowie deren Ausfhrung bereit. Entsprechend der Auf-gaben werden die zwei Komponenten Modellierung (Buildtime) und Ausfhrung(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 109. gaben festgelegt und die Bearbeiter ber das Rollenmodell zugeordnet. Weiterhinmssen fr jede Aktion die genutzten Anwendungssysteme und Datenobjekte defi-niert werden. Anschlieend 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-fhrungskomponente umgesetzt werden kann. Fr die Instanziierung und Steuerungder Prozesse steht die Ausfhrungskomponente zur Verfgung. Sie startet, steuertund protokolliert den Workflow. Dabei kann jeder Workflowprozess mehrfach fr un-terschiedliche Objekte gestartet werden. Die Ausfhrungskomponente ist dabei alsein Service definiert, der eine Laufzeitumgebung zur Ausfhrung einer Workflowin-stanz zur Verfgung stellt. Sie regelt auch die Interaktion mit den Anwendern. DieAnweisungen entsprechend dem gestarteten Workflow werden den Anwendern in sogenannten Eingangskrben als Ttigkeitslisten oder offenen Tasks zur Verfgunggestellt. 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, Komplexitt und Vernderlichkeit 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 lsst. Diese Tatsache spiegelt sich in unter-schiedlichen Automatisierungsgraden von Workflows wider.Abbildung 107 veranschaulicht die unterschiedlichen Grundprinzipien der Automati-sierung. Die Ausfhrung von Workflows kann manuell, vollstndig automatisch oderteilautomatisch, d.h. mit einer Benutzerinteraktion, ausgefhrt werden. Der Nutzerwhlt dabei beispielsweise den nchsten Bearbeiter aus. Das Workflowsystem ber-nimmt hingegen die Kontrolle der Informationsverteilung. 109 110. 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 mssen laufen teilautomatisch ab. Das heit,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 Durchfhrung der Simulati-on, die Ablage der Outputdaten sowie die Entscheidungen der endgltigen Freigabewerden durch den jeweiligen Bearbeiter durchgefhrt und vom Workflow gesteuertund kontrolliert. Die Datenkonvertierung als auch das Setzen des Status kann an-schlieend wieder automatisch durch den Workflow erfolgen. Die verschiedenen Au-tomatisierungsgrade des Simulationsreferenzprozesses sind in Abbildung 108 veran-schaulicht zusammengefasst. 110 111. Abbildung 108: bersicht der voll- und teilautomatisierten SDM-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, ausfhrende Personen zuweisen oder auch allgemein nur bestimmte Nutzer-gruppen. Mit Hilfe von Action- und Rulehandlern knnen viele Ablufe so implemen-tiert werden, dass sie automatisch vom System abgearbeitet werden. Solche Pro-zessschritte knnen zum Beispiel der Ex- und Import von Dateien, Konvertierungenoder Statuszuweisungen sein. Fr den Bereich der Umformsimulation zeigt Abbil-dung 109 den Workflow wie er von ARC Solutions in Teamcenter implementiert wur-de.111 112. Abbildung 109: Workflowablauf fr UmformsimulationIm Einzelnen ist der Ablauf wie folgt umgesetzt worden. Nachdem ein Objekt inTeamcenter ausgewhlt und der Workflow gestartet wurde, wird der Status Rot demObjekt zugewiesen. Einem Status knnen unterschiedliche Berechtigungen ange-hangen werden. In diesem Beispiel knnen von nun an keine nderungen mehr anden bergebenen Objekten vorgenommen werden. Die Objekte sind fr die weitereBearbeitung gesperrt. Damit wird sichergestellt, dass nur nderungen von den amProzess beteiligten Personen durchgefhrt werden. Im nachfolgenden Schritt Um-formsimulation ausfhren wurde definiert, an wen die Aufgabe vergeben wird. In die-sem Fall an den Berechner. Es ist auch mglich 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 berprfen wurde ein Anwender als auszufhrende Person definiert. Hiererhlt der Planer die Aufgabe die Ergebnisse der Simulation zu verifizieren und diesin einem Formular zu dokumentieren. Der Workflowschritt Check Prfformular wirdnun vom System ausgefhrt. Dafr wurde ein Actionhandler implementiert, welcherdas angehngte Formular nach einem Attribut durchsucht und dieses auswertet.Nach entsprechendem Inhalt des Attributes wird ein neuer Status vergeben (z. B.Rot, Gelb, Grn). Im letzten Prozessschritt wird dieser Status gesetzt. Der Workflowfr das Umformen ist in diesem Fall dann abgeschlossen. Als Ergebnis erhlt mandas Start-Objekt der Simulation mit Ergebnisfiles und Status. Die sich anschlieen-112 113. den Workflows fr das Fgen und Lackieren werden vergleichbar wie der Umform-prozess manuell vom Planer ausgelst. Im einfachsten Fall unterscheiden sich dieProzessschritte nicht. Es ist allerdings in allen Workflows mglich anhand von zu im-plementierenden Handlern weitere Schritte zu automatisieren oder den Gesamtpro-zess noch detaillierter abzubilden. Eine ausfhrlichere Erluterung des Workflowab-laufes wird in Abschnitt 4 vorgenommen.Zusammenfassend bedeutet dies, dass alle Teilprozesse innerhalb des Workflows somiteinander gekoppelt werden knnen, dass sie wie ein zusammenhngender Ablaufdes Gesamtprozesses wirken. Einzelne Prozessschritte werden somit weitestgehendautomatisiert miteinander verbunden und ausgefhrt. 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 Konstruktionsnderung, besteht.Der Status orientiert sich dabei am Ampelsystem mit den Farben Rot, Gelb undGrn. Das Workflowsystem bernimmt auf diese Weise die Steuerung der gesamtenSimulationsprozesskette.Die Entwicklung der konsistenten Datenablage und deren Automatisierung mittelsWorkflows ist eine Voraussetzung fr die Realisierung einer durchgngigen Simulati-onsprozesskette. Sie ermglicht eine vollstndige Datenablage aller anfallenden Da-ten und damit eine Verfgbarkeit in allen Bereichen. Durch die Bildung von Refe-renzprozessketten und deren Automatisierung wurde eine durchgehend standardi-sierte Datenablage realisiert. Somit leisten die durchgefhrten Arbeiten einen ent-scheidenden Beitrag zu einer durchgngigen, digitalisierten und kooperativen Ent-wicklungs- und Produktionsplanung.3.7.6 Kopplung der Prozesssimulation Umformen Fgen LackierenEines der Ziele des Projektes war es die verschiedenen Simulationen fr das Um-formen, Fgen und Lackieren miteinander zu verbinden und die Ergebnisdaten desVorgngerprozesses im jeweiligen Prozessschritt wiederzuverwenden. Hierfr 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. Fr 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 114. 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 ermglicht den Datenim- und Ex-port sowie die Konvertierungen automatisiert umsetzen zu lassen. Hierfr wurdenDefinitionen erstellt, die festlegen, welche Daten aus welchen Teamcenter Objektengebraucht, welche Programme mit welchen Parametern gestartet und welche Skripteausgefhrt 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-fhrt werden. Eine ausfhrlichere Erluterung wird in Abschnitt 4 gegeben. Abbildung 110: Menu mit Konfigurationen fr die Simulationen3.7.7 VIPROF Modulcockpit zur Erhhung der Transparenz im Entwicklungs-prozessIm VIPROF-Projekt wird zur Bewertung der Simulationsergebnisse auf ein Ampelsys-tem gesetzt. Die Farben Rot, Gelb und Grn signalisieren ob eine Simulation erfolg-reich war, ob sie mit Mngeln genehmigt wurde oder ob sie nicht erfolgreich war. Freine bessere Transparenz dieser Ergebnisbewertung innerhalb eines Fahrzeugpro-jektes, in dem alle Simulationsergebnisse aufgefhrt werden, sollte ein Modulcockpit114 115. entwickelt werden. In diesem Cockpit soll es mglich sein mglichst auf einen Blickden derzeitigen Stand im Entwicklungsprozess eines Fahrzeuges zu erkennen. Ab-bildung 111 zeigt eine mgliche Umsetzung eines solchen Cockpits in Teamcenter.Abbildung 111: Layoutbeispiel fr ModulcockpitDa im PDM-System noch kein vergleichbares Modul existiert musste eine vllig 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 whrend des Entwicklungsprozesses eine Einsicht in denaktuellen Entwicklungsstand gegebenen werden. ber einen Viewer im rechten Teilder Applikation knnen bereits vorhandene Ergebnisse visualisiert werden.Literatur[MHL05] zur Mhlen, 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 4115 116. [TEAM09]Teamcenter 8: Handbuch zu Teamcenter for Simulation, Verffentli-chungsnummer PLM00040 C, Siemens Product Lifecycle ManagementSoftware Inc., Stand: 2009.[VDI02] Verein Deutscher Ingenieure: VDI-Richtlinie 2219: Informationsverarbei-tung in der Produktentwicklung Einfhrung und Wirtschaftlichkeit vonEDM/PDM-Systemen, Dsseldorf 2002.[VDI2219] VDI-Gesellschaft Entwicklung Konstruktion Vertrieb (EKV): VDI-Richtlinie 2219: Informationsverarbeitung in der Produktentwicklung -Einfhrung und Wirtschaftlichkeit von EDM/PDM-Systemen, 11.2002.[WFMC99]Workflow Management Coalition (Hrsg.): WfMC Terminology & Glos-sary v3.0(WfMC-TC-1011), 1999,verfgbarunterhttp://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf.(Stand Dezember 2011). 116 117. 3.8 Perspektiven des Mittelstands (VDC)Die im Projekt VIPROF erzielten Ergebnisse wurden unter Bercksichtigung 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 fr ande-re Unternehmen innerhalb und auerhalb der Branche. Diesen Transfer zu unterstt-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 grundstzlichesProblem der Produktentwicklung ist, dass die Zeitpunkte der Kostenfestlegung undder Kostenentstehung teils weit auseinanderliegen [Munroe]. Festgelegt werden dieKosten eines Produkts vor allem whrend der Entwicklung, wohingegen die Kostenschwerpunktmig in der Produktion entstehen. Materialkosten, Arbeitskosten undGemeinkosten bilden hier die grten Positionen. Gleichzeitig ist bekannt, dass nichtunerhebliche Kosten dadurch entstehen knnen, dass erst spt im Entwicklungs-prozess nderungen am Produkt vorgenommen werden mssen. So kann sich bei-117 118. spielsweise erst spt herausgestellt haben, dass es Probleme bei der Fertigbarkeitgibt: Das Produkt oder Teile lassen sich nur unter groem Aufwand oder gar nichtwie geplant herstellen. Die zugehrige Faustregel geht davon aus, dass die nde-rungskosten exponentiell mit dem Projektfortschritt ansteigen [Visintin].Natrlich ist es so, dass auf der anderen Seite der Kenntnisstand ja gerade erst mitdem Projektfortschritt ansteigt. Darber hinaus gilt: je komplexer das Produkt ist, des-to hher werden nderungskosten angesetzt [Aberdeen]. Wie existentiell wichtig dasThema fr die Wirtschaft ist, lsst sich auch daran ablesen, in welchem Umfang dieAnzahl Produktrckrufen in den letzten Jahren gestiegen ist. Von 139 Produkt-Rckrufen 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, mglichst viele Produkteigenschaften und-funktionen schn mglichst frh im Produktentwicklungsprozess berprfen und be-urteilen zu knnen. Nach Mglichkeit wird dabei kein Bereich ausgespart: Design,Ergonomie, physikalische Eigenschaften, Logik, Fertigbarkeit oder Montierbarkeitknnen zu den berprften Eigenschaften zhlen. Simulation und Visualisierungkommen zum Einsatz. Ein stringentes Produktdatenmanagement sorgt dafr, dasssmtliche Prozess-Schritte mit Daten aus vorhergehenden berprfungen versorgtwerden.Damit wird klar, dass Virtuelle Techniken nicht nur allein fr die Automobilindustrieund deren Zulieferer relevant sind: berall dort, wo in der fertigenden Industrie komp-lexe Produkte mit hohem Aufwand entwickelt werden, muss frhzeitig im Entwick-lungsprozess berprft und beurteilt werden. Der Maschinenbau zhlt somit auch zuden potentiellen Anwendungsfeldern virtueller Techniken.Neben den klassischen ingenieurtechnischen Feldern, die den Maschinenbau in derVergangenheit stark prgten, 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 Qualittsanmutungwerden knftig eine grere Rolle spielen. Einhergehend steigt die Produktkomplexi-tt erneut, ebenso wie die Qualittsanforderungen.118 119. Das Virtual Dimension Center (VDC) Fellbach hat innerhalb des Projekts VIPROFeine Umfrage unter Maschinenbau-Unternehmen durchgefhrt. Konkret ging es umdie Fragestellung, inwiefern Prozesse des Umformens, Fgens oder Lackierens imUnternehmen durchgefhrt werden, wer diese Prozesse auslegt und ob Simulations-werkzeuge zur Untersttzung eingesetzt werden. Dabei traten folgende Ergebnissezu Tage: Die Prozesse Umformen und Fgen sind weit verbreitet (86%). Lackiert wird sel-tener, dann aber hufiger ausgelagert (50%). Es gibt selten eine Personalunion (29%) derjenigen, die Umform-, Fge- und La-ckierprozesse auslegen. Darber hinaus arbeiten diejenigen, die dieses durchfh-ren, ebenso selten in der gleichen Organisationseinheit (29%). Querschnittsveranwortliche im Prozess sind hufig (29%) nicht benannt worden.Abstimmungstreffen werden in der Regel erst vor dem oder beim Anlauf odernach Problemen abgehalten. 71% der Firmen fhren Simulationen durch, vor allem, um Zeit und Kosten zusparen (67%) und die Qualitt 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 mglich oder organisatorisch nichtvorgesehen ist. Weiteres Optimierungspotenzial der Prozesse Umformen-Fgen-Lackieren ist zusignifikanten Anteilen nicht bekannt (25-50%).Mit diesen Antworten ergeben sich hinsichtlich der Relevanz der VIPROF-Ergebnissefr den Maschinebau folgende Schlussfolgerungen: die Anwendungsbereiche Um-formen und Fgen besitzen die grere Bedeutung. Interesse an Simulationstechni-ken ist vorhanden, aber auch eine Unsicherheit bezglich mglicher Einsatzpotenzia-le. Zur Untersttzung des Maschinenbaus zhlen somit nicht nur technische Lsun-gen, sondern auch und insbesondere organisatorische Hilfestellungen.Literatur[Munroe] Thedesign determines the Cost,Munroe&Associates, http://www.leandesign.com/leandesign.html[Visintin] Visintin, Gabi: Return on Investment bei VR- und Simulationslsungen. In: cad-cam, Carl-Hander-Verlag, 2003 119 120. [Aberdeen]The transition from 2D drafting to 3D modeling benchmark report, Aber-deen Group, Boston, 2006[Rapex] Rapex:http://ec.europa.eu/consumers/dyna/rapex/rapex_archives_en.cfmWeiterfhrende Literatur Belker, Reinhard: Virtuelle Produkt- und Produktionsentwicklung, Siemens AG,Siemens Transportation, Krefeld 2008 Decker R.; Bdeker, M.; Franke, K.: Potentiale und Grenzen von Virtual Reality-Technologien auf industriellen Anwendermrkten. Possibilities of virtual realitytechnologies, University Bielefeld. IM Information Management & Consulting(2002) Band 17 Engel, C.; Menzer, M.; Nienstedt, D.: GPM Deutsche Gesellschaft fr Projektma-nagement e.V. (Hrsg.) / PA Consulting Group (Hrsg.): Projektmanagementstudie2006. Ergebnisse der Projektmanangementstudie "Konsequente Bercksichti-gung weicher Faktoren", Frankfurt / Mnchen, 2006 Grimm, Sebastian: Icido Virtual Reality. Risikominimierung mit Virtual Reality, Eu-roMold, Demat: Frankfurt 2009 Jansen, A.; Stein, B.; Mller, C.; Ehlbeck, I.: SIKEBA - Software-Einfhrung inKMU - 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 industriellenEinsatz von VR. Aachen: Fraunhofer-Institut fr Produktionstechnologie IPT, 2003 Leston, J.; Ring, K.; Kyra, E.: Virtual reality. Business applications, markets andopportunities. London: Ovum Ltd. 1996 Runde, C.: Konzeption und Einfhrung von Virtueller Realitt als Komponente derDigitalen Fabrik in Industrieunternehmen. Heimsheim : Jost-Jetter Verlag, 2007 Runde, C. ; Westkmper, E. ; Kunst, S.: Ein Modell zur Wirtschaftlichkeitsbewer-tung des Einsatzes von Virtual Reality fr Aufgaben in der Digitalen Fabrik. In:Gausemeier, J.: Augmented & Virtual Reality in der Produktentstehung : 5. Pa-derborner Workshop, 31. Mai und 1. Juni 2006, Paderborn 120 121. 4 Zusammenfassung der 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, Fgen und Lackieren waren bisher nicht verknpft. Ergebnisseaus einer gewerkespezifischen Auslegung flossen kaum in die darauffolgenden Ge-werke ein. Allein in die Crash-Simulation wurden bereits in einigen wenigen Fllenplastische Formnderungen in der Blechebene und Blechdickennderungen halbau-tomatisch weitergereicht (in Abbildung 113 durch den vertikalen Pfeil angedeutet).Die gngige Praxis in nachgeschalteten Prozesssimulationen war vielmehr, dass Ma-terialeigenschaften aus dem ursprnglichen Zustand bernommen und konstanteBlechdicken angesetzt wurden. Denn in den Hauptprozessen kamen bisher nur Insel-lsungen fr die Simulation von Teilbereichen zum Einsatz, die keine datentechni-sche Kopplung nutzten. Abbildung 113: Stand der Technik zu Beginn des Vorhabens zum Ergebnistransferaus der Prozesssimulation in die ProduktsimulationWeiterhin bestand eine groe Herausforderung darin, dass fr die Durchfhrung deretablierten inkrementellen Umformsimulation ein hoher Modellierungs- und Berech-nungsaufwand erforderlich ist und diese deshalb erst zu einem relativ spten Zeit- 121 122. punkt im Produktentwicklungsprozess durchgefhrt wird. Fr die Absicherung derHerstellbarkeit neu entwickelter Produkte bedeutete dies, dass die Produktentwick-lung mit der Fertigungsplanung nur mangelhaft verknpft ist, so dass eine Prozess-absicherung erst zu einem sehr spten 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 frheren Ein-satz der Umformsimulation erffnet. Auf diese Weise knnen das Produkt eher abge-sichert und der zugehrige Prozess frher 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 verkrzt und die Pro-zessabsicherung bereits in einem sehr frhen Stadium der Produktentwicklung be-gonnen werden kann. Mit diesem virtuellen Simultaneous Engineering (siehe Abbil-dung 114 unten) knnen Planungsfehler frhzeitig aufgedeckt und die Produktquali-tt erhht werden. Ein weitgehend paralleler Ablauf von Produktentwicklung undProzessabsicherung strkt die Robustheit des Gesamtprozesses.Ein groer Fortschritt wurde dabei in der einheitlichen Ablage der Simulationsdatenim standardisierten XML-Format und der Entwicklung der dazu notwendigen ber-fhrungsroutinen erzielt (siehe Abbildung 115). 122 123. Stand des Simulationsdatenhand-Stand des Simulationsdatenhand- lings zu Beginn des Vorhabenslings, wenn die VIPROF-Ergebnisse bei VW implementiert sein werdenAbbildung 115: Vorteile der gewerkebergreifenden bertragung und Ablage von SimulationsdatenDamit wird es mglich, 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 fr alle frei zugngliche Visualisierung ge-neriert werden, die weitergegeben werden kann, ohne Know-how bzgl. Konstruk-tionsdetails preisgeben zu mssen dies war bei der ursprnglichen Visualisierung,die innerhalb der proprietren Programme stattfand, der Fall. Auerdem arbeitet derProzess nun effektiver im Hinblick auf Datenhandling und ermglicht fr die Zukunftdie Erweiterung der Prozesskette um weitere Simulationstools bzw. -anbieter undderen einfache Kopplung, sofern diese das XML-Format untersttzen. Der XML-Konverter hilft, die im Projekt anfallenden proprietren Daten automatisiert zu ber-fhren. Dies vereinfacht die Arbeit innerhalb des Prozesses und erhht auch seineQualitt, da ein manueller Eingriff bei der Transformation, und damit eine potenzielleFehlerquelle, entfllt. Ebenso untersttzt der XML-Konverter den Konstrukteur undBerechner bei der Rcktransformation der ursprnglichen Daten aus dem XML, umeventuell notwendige Neusimulationen starten zu knnen.Der wissenschaftlich-technische Stand zum Ende des Vorhabens besteht in der Ver-knpfung von Produktentwicklung und Fertigungstechnik zu einer durchgngigen,digitalisierten und kooperativen Entwicklungs- und Produktionsplanung. Es gelingteine frhzeitige Absicherung der fertigungsgerechten Produktgestaltung mittelsDurchgngiger ProzesskettensimulationBercksichtigung der Fertigungshistorie 123 124. Integration der Simulationsdaten ins PDM-System Datenbertragung inkl. Mapping durch offene Schnittstellen Prozessautomatisierung mit Hilfe von WorkflowsDie Verkettung wird zur Erhhung der Produktqualitt beitragen. Weitere Vorteilesind, dass der Reifegrad der Produktentwicklung jederzeit abrufbar ist und dass Ab-hngigkeiten vom Erfahrungsschatz einzelner Mitarbeiter reduziert werden knnen.4.2 Darstellung der durchgngigen SimulationsprozessketteVIPROF anhand eines AnwendungsbeispielsDie Durchgngigkeit der Prozesskettensimulation und die nahezu automatische Da-tenbertragung 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 Durchgngigkeit derProzesskette gezeigt wird. Das ist zum einen die Rolle des Planers, welcher die freine Simulation ntigen Inputdaten zusammenstellt, Strukturen verwaltet, die Pro-zesskette startet und die entstehenden Ergebnisse bewertet. Zum anderen ist es dieRolle des Berechners (Simulanten), der die Simulation ausfhrt und die Ergebnisseabspeichert.Des Weiteren werden im PDM-System mehrere Strukturen abgebildet, welche fr dieDatenhaltung und die Transparenz von groer 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 fr den Prozess des Umformens der B-Sule eines Fahrzeuges.Dieser Prozess kann in drei Operationen unterteilt werden. Operation 10 entsprichtdem Zufhren der Platine zur Maschine, Operation 20 ist das eigentliche Tiefzie-hen und Operation 30 beschreibt die Abfuhr des fertig umgeformten Bauteiles aus124 125. der Maschine. In allen Operationen sind jeweils die dafr genutzten Daten verknpft,wie zum Beispiel die Ziehanlage oder das Material beim Tiefziehen. Zustzlich hatder Planer bereits die Zielbauteilgeometrie der B-Sule 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 Fertigungsprozessstrukturverknpft, da somit fr alle folgenden Anwender und Prozesse die grtmglicheTransparenz 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 (Erluterung 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 Anhngen 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 bentigten Daten zusammengestelltwerden. Diese Daten und Objekte beschafft er sich aus den anderen Strukturen, wiezum Beispiel der Fertigungsprozessstruktur und fgt sie dem Reiter Produkt im CAE-Manager hinzu (Abbildung 118).125 126. Abbildung 118: Inputdeck im CAE-ManagerAuf Knopfdruck erstellt Teamcenter automatisch die dazugehrige 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 mglich anhand von zu definierenden Regeln eine komplexere CAE-Struktur erstellen zu lassen. Teamcenter verknpft im selben Schritt alle Objekte somiteinander, dass sie mit dem Analyse-Objekt ber spezielle Relationen verbundensind (Abbildung 120). Abbildung 120: Analyse-Objekt mit verknpften Modell und Inputdeck126 127. Anschlieend startet der Planer den Workflow Umformsimulation und hngt diesemdas Analyse-Objekt an (Abbildung 121). Abbildung 121: Starten des Workflow UmformsimulationDieses Objekt erhlt zuerst den Status Rot (Abbildung 122). Durch einen Status kn-nen bestimmte Rechte an das Objekt gekoppelt werden. Zum Beispiel nur Lese-,Schreib-, nderungs- oder Lschrechte usw., welche fr jeden einzelnen Status defi-niert werden knnen. Im weiteren Verlauf (Ablauf des Workflowprozesses in Abbil-dung 109) wird das Analyse-Objekt mit allen bereits angehngten Inputdaten demBerechner zugestellt.Abbildung 122: Analyse-Objekt mit Status RotIn der Taskbox des Berechners befindet sich die Aufgabe zusammen mit einer Be-schreibung und dem angehngten Simulationsobjekt (Abbildung 123). 127 128. Abbildung 123: Taskbox des Berechners mit AufgabenbeschreibungVon hier ausgehend kann der Berechner nochmals berprfen, ob alle relevantenDaten zur Verfgung stehen, und anschlieend das Simulationsobjekt an den CAEManager senden. Im CAE Manager wurde bereits eine Konfiguration fr das nunauszufhrende Simulationstool erstellt. Mit dieser Konfiguration lsst 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 whlt der Berechner nun aus und dasausgewhlte Analyse-Objekt wird mit der entsprechenden Konfigurationsdefinitionverarbeitet. Im Hintergrund werden die Daten (Geometrie, Beschnittkurven, Material-datei, Umformmaschine,) exportiert und ein Simulationswerkzeug gestartet. Lsstsich die Simulation komplett automatisiert durchfhren ist kein Eingreifen des An-wenders notwendig. Andernfalls wird der Berechner die Simulation manuell ausfh-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 zustzlich ein JT zur Visualisierung der Ergebnisse.Beide werden anhand von Skripten automatisch ausgefhrt. Im Anschluss erfolgt der 128 129. Import der entstandenen Ergebnisse nach Teamcenter, wobei diese an das Aus-gangs-Analyse-Objekt gehngt werden (Abbildung 124).Abbildung 124: Simulationsergebnisse angehngt an Analyse-ObjektDer Berechner hat jetzt die Mglichkeit die Ergebnisse zu verifizieren und seine Auf-gabe abzuschlieen. 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 Prfaufgabe mit Analyse-Objekt samt Ergebnissenund zustzlich ein Prfformular. In diesem kann der Planer einen Status fr die Simu-lation vergeben. Der Status orientiert sich an den Ampelfarben rot, gelb, grn(Abbildung 125). Der Planer berprft die Simulationsergebnisse. Sind sie in Ord-nung vergibt er den Status grn, bei Fehlern oder Problemen setzt er den Status aufrot, gibt es Klrungsbedarf wie mit dem Bauteil weiterverfahren werden soll wird derStatus gelb gesetzt. Abbildung 125: Prfbericht mit Statusvergabe129 130. 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 grnAbbildung 127: Analyse-Objekt in FertigungsprozessstrukturDiese Abfolge der Arbeitsschritte wiederholt sich fr alle nachfolgenden Simulatio-nen. Es fgt sich lediglich als Zwischenschritt das Mapping der Simulationsnetze,durch den SCAIMapper, ein. Dies wurde in Kapitel 3.2.2 bereits ausfhrlich beschrie-ben.130 131. 5 AusblickVolkswagen wird die Projektergebnisse im eigenen Unternehmen ggf. unter Einbe-ziehung von Zulieferern verwerten. Dazu erfolgt eine Integration des gewerkeber-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 Lsungen fr den Mit-telstand erarbeitet, die ohne TEAMCENTER auskommen. Die Hochschulen werdendie Projektergebnisse fr Forschung und Lehre nutzen.5.1 Ausblick VolkswagenKnftig sollen bei Volkswagen die Simulationsergebnisse gewerkebergreifend ber-tragen und konsequent abgelegt werden, damit sie in einem System verfgbar sind,wie in Abbildung 128 gezeigt. Auch Materialdaten sollen ber die Ressourcen-verwaltung von TEAMCENTER mit abgelegt werden, damit sich die Simulationendarauf verlinken knnen. Bei VW soll eine weltweite Vernetzung von Fahrzeug-projekten entstehen, damit an den verschiedenen Standorten einheitliche Produkt-und Fertigungsdaten vorliegen.Abbildung 128: Gewerkebergreifende bertragung von Simulationsergebnissen bei VWZur Verwertung der Projektergebnisse soll das Simulationsdatenmanagement abernicht komplett in das Produktdatenmanagement bernommen werden, da die Daten-haltung sonst zu unbersichtlich wrde. Vielmehr wird ein separater File-Server frdie Simulationsdaten vorgesehen. Bestimmte Simulationsstnde werden dann imProduktdatenmanagement archiviert, so dass der Stand einer Produkt- oder Fahr- 131 132. zeugentwicklung zu jedem Zeitpunkt abrufbar ist. Zugleich kann daraus eine Doku-mentation fr Folgeprojekte oder zu Kontrollzwecken bzw. fr Revisionen generiertwerden.Mit dem VIPROF-Projekt und der weiteren Integration der Projektergebnisse wirddem Management von Volkswagen ein Reifegrad-Cockpit zur Verfgung gestellt, umdie Herstellung simulationsbasiert bewerten zu knnen. Zudem soll jeder Planer undKonstrukteur Simulationsergebnisse im Gesamtfahrzeugkontext in 3D analysierenknnen. Nachdem bisher die Synchronisation zwischen Produktion und Entwicklungnicht durch IT-Systeme untersttzt 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 fr Fhrungskrfte und Managementjederzeit im Reifegrad-Cockpit einsehbar.5.2 Transfer der Ergebnisse von CADFEMCADFEM sieht eine Verwertungsmglichkeit der VIPROF-Ergebnisse in einer Koope-ration mit der Firma V-Collab, die eine kollaborative Lsung zur Visualisierung vonCAD- und CAE-Daten anbietet. Damit knnen Simulationsergebnisse komprimiertund im Simulationsdatenmanagement von ANSYS abgelegt werden. Mit der Soft-ware DIGIMAT besteht die Mglichkeit, inhomogene Verteilungen von faserverstrk-tem Material aus dem Spritzguss abzubilden, um die Herstellhistorie zu bercksichti-gen. Dieses Vorgehen wird in Abbildung 129 illustriert.Abbildung 129: Analyse von fasergefllten Polymerbauteilendurch integrative Simulation mit DIGIMAT132 133. Eine weitere Verwertung der Projektergebnisse fr 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 Verbreitungsmglichkeiten im Zusammenhang mit dem Projektwurde bei CADFEM eine Erweiterung fr die ANSYS Workbench entwickelt. DieBlechumformsimulation mit dem FTI One-Step Lser wurde in einem ANSYS-Workbench-Projekt als Lsungskomponente integriert. Die Geometrie der Bauteilewird aus der Workbench Umgebung als Eingangsgre verwendet. Die Blechdickenund die plastischen Vergleichsformnderungen knnen in andere Analysesystemeaus der Workbench bertragen werden. Werden mehrere Simulationen in einemANSYS-Workbench-Projekt miteinander verbunden, knnen damit alle verbundenenDaten in diesem Berechnungsprojekt verwaltet werden. Dieser in ANSYS V14 integ-rierte Workflow fr 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-knpfung mit Eingangsdaten und Folgerechnungen automatisiert verfgbar. Diesmacht die Methode zum einen attraktiv fr einen greren Kreis von Anwendern. Die 133 134. Bercksichtigung der Umformhistorie erzeugt so nur verhltnismig wenig zustzli-chen Bearbeitungsaufwand. Zum anderen ermglicht diese Automatisierung eineweitreichendere Analyse der Prozess- und Designparameter in Sensitivittsanalysen,Optimierungen und Robust Design Bewertungen.5.3Transfer der Ergebnisse von ESI fr Zulieferer mit VisualDSSDie in VIPROF erstmalig in dieser Breite aufgenommene Themenstellung der soge-nannten End to End Prozesskette, stie bei allen Vortrgen vor unseren Kundenund auch im Industriearbeitskreis auf lebhaftes Interesse der Beteiligten. Dies zeigtaus Sicht von ESI den Bedarf fr 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 Lsung JT2Go kann hiernicht stark genug betont werden. So dass auch hier eine Fortsetzung der ThematikJT for CAE angeregt wird.Die im Prinzip vorgestellte Methode der Neuvernetzung, hat ebenfalls das Potentialim Rahmen der industriellen Forschungsfrderung (AIF) einen nicht unwesentlichenBeitrag zur Optimierung der End to End Fertigungssimulationskette zu leisten. Dennber das Ausschwimmen zweier Bauteile, wie es z. B. im SCAIMapper mglich ist,hinaus, ist die akkurate bergabe der Geometrieform von einem Gewerk zum nch-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-Lsung stellt gegenber den schon erklrungsbedrftigenEinzelprodukten, wie der inkrementellen Umformsimulation, dem transientenSchweien oder dem Crash noch eine Steigerung an Komplexitt dar. Denn norma-134 135. lerweise ist die Zielgruppe der technischen Kufer 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 adquaten 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, Fgenund Crash-Simulation reduzierten Prozesskette begegnet der Zielgruppe typischerSystemlieferanten sehr gut. Denn diese betrachten schon heute die notwendigenKomponenten- und Systemeigenschaften, z. B. der Tren oder des Vorderwagens inRelation zu geforderten Crash- oder NVH-Vorgaben. Die Zielgruppe fr eine Vi-sualDSS Vorstellung ist die Geschftsfhrung, da diese ber die Einfhrung der Ver-kettung der Arbeitsablufe befhigt wird die Unternehmensablufe im Modulcockpitonline zu berschauen und anschlieend zu optimieren. Natrlich sind die unter-schiedlichen Gewerke bei der Umsetzung umfassend einzubinden. Doch die ber-greifende Integration der Arbeitsablufe lsst sich gerade mit der im VIPROF-Projektentwickelten Methodik auch ber anfngliche Bedenken hinweg zu einem positivenErgebnis fhren. Denn die Integration in das Simulationsdaten- und ablaufmanage-ment vereinfacht die Unternehmensablufe mittelfristig erheblich. Ein Zusatznutzenist sicherlich die revisionssichere, auditfhige Handhabung aller Daten und Prozesseohne auf die Papierform zurckgreifen zu mssen.Business ProcessesVisualDSS web client RailRAIL ASSEMBLY DecisionVisualDSS DatabaseMaking ToolAbbildung 131: Simulationsprozess- und Datenmanagement in VisualDSS135 136. 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. Auerdem 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 zusammengehrige Applikation samt For-matkonvertierung angeboten werden. Hierfr wird die Umsetzung des Modulcockpitsweiterverfolgt, um einen komplett transparenten Lsungsansatz zu bieten.Die Integration von Simulationsdaten in Teamcenter und das damit erarbeitete Wis-sen kann als zustzliche Entscheidungshilfe fr von ARC Solutions vertriebene CAEWerkzeuge (NX) dienen. Die Betreuung, Implementierung und Konfiguration vonSchnittstellen fr 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 einflieen. In der Vorlesung Blechbearbeitung im Fahrzeugbau(Bachelorstudiengang Maschinenbau) wird u.a. die Entwicklungsprozesskette thema-tisiert und entsprechend mit den Projektergebnissen ergnzt. Im Weiterbildungsstu-diengang fr Ingenieure und Ingenieurinnen, dem Master Automotive Produktionwerden die Projektergebnisse im Rahmen der Vorlesung Umformsimulation in derProduktentstehungsphase eingebunden.Das Institut fr Produktionstechnik der Ostfalia HaW (IPT) wird die VIPROF-Ergebnisse auch weiterhin mit Hilfe des Vereins Netzwerk Digitale Fabrik - imRahmen von kontinuierlichen Veranstaltungen - kleinen und mittelstndischen Unter-nehmen nherbringen.In den nchsten drei Jahren soll am IPT mit den im Projekt erworbenen Kompeten-zen die Integration der Warmumformung (Presshrten) in die Prozesskette entwickeltwerden. Ein Forschungsantrag wurde in der Frderlinie ProfilNT des BMBF gestellt. 136 137. Durch die durchgngige Virtualisierung der gesamten Prozesskette ist eine Basis frzuknftige Forschungsarbeiten bezglich neuer Produktentwicklungsmethoden ge-schaffen worden. Die Forschungsergebnisse bilden die Grundlage fr eine Ausdeh-nung der Prozesskette in weitere Simulationsbereiche. Zum Beispiel knnte am IPTmit den bestehenden Kompetenzen eine Erweiterung der Prozesskette auf den Be-reich der Montagesimulation mit dem Ziel eines vollstndigen Schlusses der gesam-ten Fertigungskette untersucht werden.5.6 Datentechnischer Ausblick der TU BerlinIn Zukunft knnten Mappingfunktionalitten in den XML-Konverter eingebettet wer-den. Sollten z. B. die Funktionalitt des SCAIMappers Einzug in den XML-Konverterfinden, und darber 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 erhht damit die Qualitt des Prozes-ses und seiner Outputs.Das XML-Format kann knftig um weitere Bestandteile erweitert werden. So knntenBereiche fr Materialdaten geschaffen bzw. Strukturen definiert werden, die beste-hende Elemente sogenannten Parts (also Elementgruppen) zuordnet. Dies erhhtdie Flexibilitt 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 knnen die Daten Gren 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-mengefhrt werden, erhht die Flexibilitt und vermindert die Last bei der Verarbei-tung der Daten, da nur die Daten bearbeitet werden, die notwendig sind, alle anderenbleiben unberhrt.5.7 Ausblick Professur Virtuelle FertigungstechnikDie Professur fr Virtuelle Fertigungstechnik schtzt die Ergebnisse dieses Projektesals positiv und insgesamt sehr gelungen ein. Es erfolgten bereits einige Publikatio-137 138. nen in einschlgigen Zeitschriften sowie auf nationalen und internationalen Tagun-gen. Eine weitere Verffentlichung ist fr 2012 auf dem ProSTEP iViP Symposiumgeplant.Als Professur der Technischen Universitt 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 fr Studierende aktualisiert und modernisiert werden.Die Vorlesung Produktdatentechnologie wird um den Teil der Ablage von Simulati-onsdaten in einem PDM-System ergnzt. Weiterhin kann die Steuerung des Daten-austauschs zwischen verschiedenen Simulationsprogrammen ber Workflows ge-zeigt werden. In den vorlesungsbegleitenden Praktika bekommen die Studierendendie Mglichkeit an einem Beispiel diese Funktionen direkt am PDM-System anzu-wenden.Den Studierenden der Vorlesung Simulation in der Umformtechnik knnen 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 hufiger Kommunikation beieiner abteilungsbergreifenden Projektbearbeitung.Zustzlich sollen aufbauend auf den Ergebnissen aus dem Projekt zuknftige For-schungsvorhaben und Industrieprojekte beantragt werden.138 139. 6ffentlichkeitsarbeitZur Information ber das Projekt wurde die Projekt-Homepage www.projekt-viprof.deeingerichtet. Whrend der Projektlaufzeit wurde der Industriearbeitskreis "Virtualisie-rung" zum Erfahrungs- und Informationsaustausch gegrndet. Der Arbeitskreis waroffen fr Interessenten auerhalb des Projektkonsortiums.Von Partnern des VIPROF-Projektes wurden im Projekt die folgenden Verbreitungs-aktivitten unternommen:DatumOrt / BeitragVeranstaltung AutorenJahr 2009 FellbachVDC-Newsletter und Pres-VDC Fellbachsemeldungen z. B. imNewsletter Kompetenz-netze Deutschland16.-18.06.Magdeburg Fachtagung Digitales En-Pinner (VW) et al.2009gineering, Fraunhofer Wis-senschaftstageTitel:Durchgngige Virtualisierung der Entwicklung und Produktion von Fahrzeu-gen16.-18.06.Verffentlich-12. IFF-Wissenschaftstage ARC Solutions2009ungTitel:Projektstand und Ergebnisse zum VIPROF-ProjektHerbstaus-Verffentlich-ProduktDatenJournal Nr. 2 Awiszus, Bolick (VIF),gabe 2009 ung / 2009, S. 39 43, Brylla (ARC Solutions), Pin-ISBN/ISSN: 1436-0403ner (VW), Schulz (TU Berlin)Titel:Produktdatenmanagement in der Entwicklung und Produktion von Fahrzeu-gen, Heft 2, S. 39 43, ISSN 1436-040319.11.2009Leipzig ANSYS Conference undPinner (VW) et al.27. CADFEM Users Meet-ingTitel:Einsatz inverser Solver innerhalb der Prozesskettensimulation im BereichKarosseriebau19.11.2009Leipzig CAE-Forum auf dem 27. Kulp (VW)CADFEM Users MeetingTitel:Impulsvortrag: Integrierte Prozesskettensimulation bei der Karosseriehers-tellung im Projekt VIPROF 139 140. DatumOrt / Beitrag VeranstaltungAutoren19.11.2009 LeipzigCAE-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 Project30.03.2010 Darmstadt16. JT-User Group Treffen, Pinner (VW)Fraunhofer IGDTitel: Universelle Visualisierung von Simulations-Ergebnisdaten im JT-FormatApr. 2010KarlsruheKarlsruher Arbeitsgespr-ARC Solutions, Ostfalia HaW (Ausstellung)che04.05.2010 Fellbach Internationale Konferenz Awiszus, Bolick (VIF),Neuere Entwicklungen in Leck (Ostfalia HaW), Bryllader Blechumformung(ARC Solutions), Pinner (VW)Titel: Durchgngige Simulationsprozessketten in der Fahrzeugentwicklung Tagungsband S. 65 84, ISBN 978-3-88355-378-808.06.2010 Fellbach Kick-off Veranstaltung In- Vortrge zu den Teilvorhabendustriearbeitskreis VIP- aller VIPROF-PartnerROF22.-23.06. Bonn 1st Conference on Multi- Leck/Rambke (Ostfalia HaW),2010physics Simulation Awiszus (VIF), Pinner (VW), Knick (CADFEM)Titel: End-to-end Virtualization of the Development and Production of Vehicles02.07.2010 Bekannt- Informationsnetzwerk ESI machungXING16.-17.11. Baden-BadenSIMVEC (15. Internat. VDI- Pinner (VW), Awiszus (VIF),2010Konferenz fr Simulation Vogel (ESI), Leck und Ramb-und Berechnung)ke (Ostfalia HaW)Titel: Prozesskettensimulation im Karosseriebau am Beispiel der Kopplung von Umform- und Fgesimulation16.-17.11. Baden-BadenSIMVEC (15. Internat. VDI- Knick / Steinbeck-Behrens2010Konferenz fr Simulation (CADFEM), Kulp / Pinnerund Berechnung)(VW)Titel: Integration der Lackiersimulation in den Herstellungsprozess von Karosse- rien im Forschungsprojekt VIPROF10.02.2011 Braunschweig Fachkonferenz Berech- Pinner (VW)nung im ProduktprozessTitel: Visualisierung von CAE-Ergebnisdaten im JT-Format 140 141. DatumOrt / 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 SeeheimSiemens PLM Connection Brylla (ARC Solutions), Pin-Deutschlandner (VW)Titel: Durchgngige Prozessketten fr CAE-Simulation in der Fahrzeugentwick- lung untersttzt mit Teamcenter26.05.2011 AschaffenburgPAM-CRASH Forum 2011 Pinner (VW), Schroeder (ESI)Titel: Einfluss der Fertigungsprozesskette im Karosseriebau auf das Crashverhal- ten28.-29.06. Berlin INPRO- Bohling / Pinner / Theilen2011Innovationsakademie(VW)Titel: Digitale Planung im Automobilbau - Einsatzfeld fr innovative Simulations- technikHerbstaus- MnchenInfoplaner 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. 2011Verffentlich- Artikel zu VIPROF im Wirt- ARC Solutions ungschaftsjournal15.-16.11. MnchenNAFEMS European Confe- Hoffmann / Brylla (ARC Solu-2011rence: Simulation Process tions), Awiszus / Bolick (VIF)and Data Management(SDM)Titel: Durchgngige Prozessketten fr CAE-Simulation in der Fahrzeugentwicklg. untersttzt mit Teamcenter-Ergebnisse aus dem BMBF-Projekt VIPROF22.11.2011 Fellbach Abschlussveranstaltung Vortrge aller VIPROF-Industriearbeitskreis VIP- Partner zu den Projektergeb-ROFnissen14.-15.02. Bad Boll 32. EFB-Kolloquium Pinner / Sthmeyer / Heyn2012Blechverarbeitung(VW), Menke / Gotthold (CADFEM)Titel: Verbesserte Bauteilauslegung durch Prozesskettensimulation20.11.2012 Baden-BadenSIMVEC - Berechnung, Volkswagen, CADFEM(geplant) Simulation und Erprobungim Fahrzeugbau 141 142. 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 Auftrgen fr 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 verffentlicht.Weiterhin wurde vom Projektpartner ARC Solutions ein Bildschirmfilm erstellt, der dieNutzung der Prozesskette in TEAMCENTER als Workflow zeigt.142

Recommended

View more >