Virtuelle Crash-Tests vs. Realität
Profis aus der Fahrzeugindustrie zeigen anhand eines nachgestellten Lego-Crashs, wie ein virtuelles Abbild von Crash-Tests im Rechner entsteht. Der reale Lego-Crash macht die Probe aufs Exempel.
- Sven Hansen
"Wie geil“, entfährt es Simulationsingenieur Thorsten Gerlinger unter seiner Shutter-Brille im Simulationsraum. Das erste Mal erlebte er das von ihm maßgeblich mit aufgebaute virtuelle Crash-Szenario zweier Lego-Modelle hautnah. Auch ich kann mich der Faszination der auf mich einströmenden Pixel-Flut nicht entziehen. Zu zweit stehen wir mit Shutter-Brillen auf dem Kopf in der 2,7 × 2,7 Meter großen 3D-Cave des Höchstleistungsrechenzentrums Stuttgart und staunen Bauklötze: In Superzeitlupe segeln uns übergroße Legosteine um die Ohren – besonders belastete Bauteile werden mit Heatmaps eingefärbt, sodass sich das Kräftespiel während der Kollision der zwei Lego-Boliden in einzelnen Steinen widerspiegelt.
Im dreidimensionalen, begehbaren Crash-Video zweier Lego-Supercars kann man sich frei bewegen oder die Modelle über den Controller wie Butter zerschneiden, um während des Crashs in die Innereien zu schauen (siehe "In der Lego-Höhle"). „Eigentlich kenne ich inzwischen jeden einzelnen Stein in dieser Crash-Anordnung, aber es ist doch vollkommen anders, mittendrin zu stehen“, meint Gerlinger. In zwei Stunden wird sich der Simulationsprofi festlegen und mir seine Lego-Wette ins Mikrofon sprechen. Das ehrgeizige Ziel: Die Simulation soll den Ausgang eines realen Crash-Versuchs mit zwei Lego-Modellen vorhersagen.
Achtung, Cliffhanger!
Diese Story hat ein offenes Ende – denn wie gut die Simulationsprofis den Ausgang eines 60-km/h-Crashs zwischen zwei Lego-Boliden voraussagen konnten, erfahren Sie in c’t 22/2019. Dann crasht c’t in Kooperation mit dem ADAC die echten Lego-Autos.
Um die Wartezeit zu versüßen, bietet dieser Artikel viel Futter, unter anderem Informationen zur Arbeit der Crash-Profis und die technischen Hintergründe zur 3D-Cave des Höchstleistungsrechenzentrums in Stuttgart.
Die Bilder im Artikel können nur einen groben Eindruck der spektakulären Aufnahmen des virtuellen Crash-Geschehens vermitteln. Alle Videos zum Artikel finden Sie auf unserer Aktionseite ct.de/crash. Wer eine Cardboard-Brille oder ein VR-Headset besitzt, kann sogar persönlich in die Welt der fliegenden Legosteine eintauchen. Viel Spaß beim Lesen, Schauen und Staunen.
Zurück auf null
Losgetreten hat die Geschichte Gerlingers Kollege Marko Thiele, der als IT-Fachmann für CAE-Prozesse (Computer Aided Engineering) beim Simulationsspezialisten DYNAmore arbeitet. Normalerweise werden dort Fahrzeugkomponenten für die Automobilindustrie modelliert und virtuell gecrasht. Die Hersteller optimieren ihre Fahrzeuge auf diese Weise beispielsweise für die Crash-Anforderungen in unterschiedlichen Märkten. Schon im Designprozess lässt sich durch kleine Veränderung ein besseres Ranking im ein oder anderen Crash-Test herausholen.
Mit Spannung hatten Thiele und seine Kollegen den in Kooperation mit dem ADAC durchgeführten Lego-Crash in c’t 12/2017 verfolgt, der mit einem kleinen Wettbewerb verbunden war. Der Ausgang des Crashtests sollte vorhergesagt werden, und schnell war man sich im Unternehmens-Chat einig: „Wer, wenn nicht wir, sollte so etwas bewerkstelligen können?“. In der Kürze der Zeit war der simulierte Aufprall aber nicht zu stemmen, denn so ein Lego-Modell „tickt“ dann doch vollkommen anders als ein herkömmliches Fahrzeug. Doch auch nachdem das spektakuläre Video vom ersten Lego-Crash veröffentlicht war, ließ Marko Thiele die Idee nicht los.
Im Thiele-Keller in Ingolstadt entstand so kurzerhand eine Crash-Anlage en miniature: Mit einem Holzkatapult Marke Eigenbau beschleunigte Familie Thiele das selbst entworfene Lego-„Scale-Car“ auf bis zu 25 km/h und ließ es mehrfach an einer Holzplatte zerschellen. Die Vortests mit einem kleinen Auto waren nötig, um den Aufwand an Rechenleistung zunächst gering zu halten und sich so an die Simulation des Porsche-Crashs heranzutasten. Parallel baute Thiele ein virtuelles Abbild des kleinen Flitzers in der Simulationsumgebung LoCo auf, die er auch im Job benutzt.
Als High-Speed-Kameras für die Real-Crashes dienten zwei Smartphones. „Wie bei den großen Fahrzeugen benötigt man zur Validierung einer Simulation möglichst viele reale Crash-Versuche“, erklärt Thiele. Die Videos werden herangezogen, um die Umgebungsparameter und Materialeigenschaften so zu justieren, dass sie möglichst nah an die Realität heranreichen.
Realitätsgetreues Modell
Nach einigen kleineren Anpassungen verhält sich das vereinfachte Lego-Auto im Rechner ähnlich wie sein Vorbild auf dem hölzernen Crash-Katapult. „Nur das Zusammensuchen der Teile nach jedem Crash-Durchlauf war etwas nervig“, erinnert sich Thiele. Nun steht der Nachbau des ersten c’t-Lego-Crashs auf dem Plan und damit auch die komplette Virtualisierung des orangenen Porsches GT3 RS aus 2704 Bausteinen. Hierfür geht das ein oder andere Wochenende drauf, denn die Bausteine müssen im Rechner händisch für die Simulation vorbereitet werden.
Während des sogenannten Vernetzens entscheidet der Simulationsingenieur wie bei großen Fahrzeugen, welche Details eines Bauteils für den Crash-Verlauf entscheidend sind und welche nicht (siehe "Arbeiten wie die (Simulations-)Profis"). So lässt sich beispielsweise der Lego-Schriftzug auf jeder Noppe entfernen, da er offensichtlich das Crash-Geschehen nicht beeinflusst.
„Immerhin gab es schon passende CAD-Dateien im Netz, sodass sowohl die Bauteile als auch der komplette Bauplan des Porsches in digitaler Form vorlagen“, erzählt Thiele. Durch das Vernetzen jedes beteiligten Teils wurden die CAD-Daten in sogenannte finite Elemente umgewandelt (siehe "Arbeiten wie die (Simulations-)Profis"). Jeder Lego-Baustein ist in sich ein Puzzle aus Tausenden dieser kleinsten Teilchen. Aus der Berechnung des physikalischen Verhaltens jedes dieser Einzelteile entsteht mit der Finiten-Elemente-Methode (FEM) ein virtuelles Abbild des gesamten Lego-Modells.
Die Legowette: In kleinen Schritten zum virtuellen Modell (8 Bilder)
Am Ende steht das digitale Abbild des orangenen Lego-Porsches für den virtuellen Crash bereit – ein physikalisch korrektes 3D-Puzzle aus 18 Millionen Teilen. Einmal erfasst, kann man das virtuelle Lego-Modell beliebig stressen: Man kann es mit 300 km/h an eine Wand fahren, aus 10 Meter Höhe auf den Boden fallen lassen oder es mit der 20-fachen Erdanziehungskraft zerquetschen. Mit dem virtuellen Nachbau des Lego Fun-Tests in der Tasche kontaktieren die Simulationsprofis c’t.
Die Lego-Wette
Nun ist es eine Sache, einen bereits gelaufenen Test nachzubilden. Deutlich spannender ist es, wenn man eine Vorhersage für einen neuen Test treffen muss. Die Simulations-Profis lassen sich darauf ein, das Crash-Szenario deutlich zu erweitern. Zum fast fertig aufgebauten Lego-Porsche kommt nun noch das 2018 vorgestellte Nachfolgemodell, der Lego-Bugatti. Die Challenge für die „Simulanten“: Eine Vorhersage des Schadensbildes für eine Kollision der zwei Supercars. Für den ultimativen Realitätscheck sollen die Crash-Profis vom ADAC Technikzentrum in Landsberg/Lech sorgen, die schon unseren ersten Porsche fachgerecht „versenkt“ haben.
- Mehr zum Crashtest Porsche vs Bugatti unter ct.de/crash
DYNAmore nimmt die Herausforderung an, nun als internationales Team an weltweit vier Standorten. Auch hier gibt es durchaus Parallelen zu echten Großprojekten: „Unsere Simulationsumgebung ist für das kollaborative Arbeiten ausgelegt“, erklärt Andre Haufe von DYNAmore. Komplexe Virtualisierungsaufgaben werden in Tranchen aufgeteilt und an unterschiedlichen Standorten parallel bearbeitet – so ergeht es nun auch dem Lego-Bugatti. Zur Validierung der Fahrzeugmodelle dürfen die Crash-Profis auf das Material sämtlicher High-Speed-Kameras aus dem alten Porsche-Crash zugreifen. Die zeigen letztendlich immer dasselbe Geschehen aus unterschiedlichen Winkeln. Um zu einem robusteren Modell zu kommen, wären Aufnahmen unterschiedlicher Real-Crashs aus einer einzigen Perspektive hilfreicher gewesen.
Teile eines riesigen Puzzles zusammensetzen
In Kooperation mit dem ADAC stecken wir zunächst die konkrete Aufgabenstellung ab. Wir entscheiden uns für einen Seitenaufprall der zwei Lego-Modelle, der wie der AE-MDB-Seiten-Crash nach Euro NCAP mit einer Geschwindigkeit von 60 km/h auf die B-Säule durchgeführt wird. Dabei wird das Porsche-Modell bewegt – vom vergangenen Versuch ist bekannt, dass es zumindest eine Geschwindigkeit von 46 km/h fahren kann. Für unsere Lego-Wette wird der orangene GT3 RS also 14 km/h schneller mit seiner Mittelachse seitlich auf die B-Säule des blauen Bugatti prallen – die Simulationsexperten sollen den Ausgang des Crashes vorhersagen.
Die gesamte Simulation mit den zwei virtuellen Fahrzeugmodellen umfasst am Ende 45 Millionen finite Elemente – übrigens zehnmal so viele wie bei einem echten Fahrzeug. Echte Autos sind aus viel gebogenem Blech geformt, sodass für die Simulation ein Modell aus Schalenelementen genügt. Bei den Lego-Boliden kommt hingegen ein Volumenmodell zum Einsatz, das jeden Stein komplett in seiner dreidimensionalen Struktur erfasst.
Um das 45-Millionen-Teile-Puzzle nach den Gesetzen der Physik in Bewegung zu setzen, benötigt man ein Rechenzentrum. Für unseren virtuellen Lego-Crash wird auch die Anfahrt mitberechnet: „Normalerweise beginnt eine Crash-Simulation mit dem Punkt null im Moment des Aufschlags. Dem virtuellen Fahrzeug wird einfach die Momentangeschwindigkeit zu diesem Punkt zugewiesen“, erklärt Gerlinger. Das Höchstleistungsrechenzentrum Stuttgart erledigt den Job – für den ersten Durchlauf des virtuellen Crash-Tests benötigen 1000 der rund 185.000 Cores eine Woche Rechenzeit.
Die Prognose
Heute nun müssen die Simulanten ihre Wette für den Lego-Crash abgeben. Nachdem mir Gerlinger den simulierten Crash-Verlauf in der 3D-Cave erläutert hat, zeigt er mir die in der Simulation hervorgetretenen Schwachstellen der Modelle in der Software METApost, die auf die Darstellung von Simulationsergebnissen spezialisiert ist. Hier hat der Simulationsingenieur das Geschehen in jeder 1000stel Sekunde perfekt im Griff. Zu jedem Zeitpunkt lässt sich der Simulationsablauf pausieren und auch hier kann man wie in der Cave beliebige Schnitte durch die virtuelle Wirklichkeit ziehen und das Unfallgeschehen verfolgen. „Über farbliche Markierungen lässt sich die Belastung einzelner Teile visualisieren“, so Gerlinger.
Darüber hinaus kann die Software beliebige Fahrzeugteile als festen Bezugspunkt (Follower) setzen, sodass sich das Unfallgeschehen auf dem Bildschirm nur um dieses Teil dreht. Genauso leicht lässt sich die Verformung von Bauteilen unterdrücken, sodass die Fahrzeuge scheinbar intakt bleiben, die Kraftverteilung aber dennoch hervorgehoben wird. „Diese Ansicht nutzen wir häufig, denn bei den echten Autos geht es den Auftraggebern oft um das konkrete Verhalten eines einzelnen Bauteils“, erklärt Gerlinger. Die Beanspruchung der Bauteile im Crash-Verlauf lässt sich in der „unverknautschten“ Ansicht gut erkennen.
Die Prognose für den realen Crash am nächsten Tag nehme ich im Anschluss komplett „analog“ ab – auf einem Flipchart. In einem Konferenzraum des HLRS schlägt die Stunde der Wahrheit: Die Simulationsexperten legen sich fest.
Schadensbegutachtung
An meiner groben Skizze erläutert mir Thorsten Gerlinger zunächst das erwartete Schadensbild. „Wir denken, dass sich der Bugatti stark durchbiegt, aber nicht bricht“, erklärt er. „An der abgewandten Seite wird jedoch eine deutliche Rissbildung im Bereich des Unterbodens zu beobachten sein“ – „eine Bugatti-Banane“, sage ich.
Für den Porsche schaut es nach dem Ergebnis der Simulation etwas besser aus. „Im vorderen Bereich steckt unter dem Kofferraumdeckel eine massive Struktur ähnlich einem Rammbock“, so Gerlinger. „Die Front wird zwar im Crash-Verlauf zerstört, die Fahrgastzelle wird wahrscheinlich intakt bleiben.“
Meine nächste Frage zielt auf Teile, die die Experten als bruchgefährdet einstufen würden. „Sie befinden sich nach der Simulation in der linken B-Säule des Bugatti und in der Front-Partie des Porsches.“ Wir einigen uns darauf, die betreffenden Teile vor dem Real-Crash farblich zu markieren.
Überlebenschancen
Und unsere Dummys? Werden sie überleben? „Im Bugatti schaut es für den Dummy schlecht aus, im Porsche gibt es eine Überlebenschance“, lacht Gerlinger. Allerdings muss man beachten, dass es in den Lego-Fahrzeugen quasi keine Knautschzone gibt, weil sich die Verbindungen zwischen den Teilen einfach lösen. „Alles fliegt weg und der Aufprall ist in jedem Fall hart.“ Für ein echtes Auto ein untypisches Verhalten.
Mir fällt auf, dass das prognostizierte Schadensbild weniger dramatisch ausfällt, als es sich bei unserem vorherigen Crashtest mit dem Einzelfahrzeug dargestellt hat. „Vor zwei Jahren fuhr das Fahrzeug mit 46 km/h auf ein nahezu festes Hindernis“, erläutert mir Gerlinger. Nun trifft der Porsche auf den quer geparkten Bugatti. „Beim Seitenaufprall mit 60 km/h entscheidet am Ende Masse, Trägheit und Reibungswiderstand zwischen Bugatti und Fahrbahn darüber, wie stark der Porsche geschädigt wird.“
Nach einem spannenden Tag verlassen wir das HLRS mit den zwei Lego-Modellen und der Prognose in der Tasche. Am nächsten Morgen soll der reale Crash in Landsberg am Lech zeigen, wie nah die Simulation an der Realität lag. Die Simulationsexperten dürften mindestens so gespannt sein wie ich.
In der Lego-Höhle
In der 3D-Cave des HLRS konnte man komplett ins virtuelle Crash-Geschehen eintauchen.
Die Cave des Höchstleistungsrechenzentrums Stuttgart (HLRS) ist ein Würfel mit 2,7 Meter Kantenlänge, der zu einer Seite geöffnet ist. Fünf Projektoren projizieren ein 3D-Bild auf die drei Wände, den Boden und die Decke. Die Projektoren bekommen über je zwei Eingänge 3D-Bilder zugespielt, sodass mehrere Besucher mit 3D-Shutter-Brillen in eine virtuelle Realität eintauchen können.
Die Videos werden von zehn Rechnern mit Quadro-P6000-Grafikkarte zugespielt, je ein Rechner für den rechten und linken Kanal für jede Projektionsfläche. Die Projektoren lösen bis 1600 × 1600 Pixel auf, wegen der Rückprojektion auf Boden und Decke erstreckt sich die Cave über drei Etagen. Ein Steuerrechner koordiniert die Ausspielung. Die insgesamt elf Rechner kümmern sich auch um das parallele Postprocessing, sodass jeder Cluster-Knoten nur einen Teil der Daten verarbeiten muss. Erst für das Rendering werden die Daten auf alle Knoten verteilt, sodass jeder Projektor die vollständige Simulation anzeigen kann.
Die Visualisierung des Lego-Crashs wurde mit der Software Vistle (https://vistle.io) erzeugt, die am HLRS unter einer Open-Source-Lizenz entwickelt wird. In Vistle lassen sich mit einem grafischen Editor Workflows aus Modulen erzeugen, die einzelne Arbeitsschritte zu einer Visualisierungsprozesskette verbinden.
Die 960 GByte großen Daten wurden als 3D-Volumen-Daten angeliefert und vom Modul ReadDyna3D verarbeitet. Da die Größe „plastische Verformung“ nur pro Volumenzelle vorlag, wurde sie mit CellToVert auf die Ecken der Zellen (= Knoten/Vertices) übertragen. Das Modul DomainSurface hat dann für die insgesamt 6243 Lego-Bausteine, die jeweils als Volumengitter vorlagen, die Oberfläche eines jeden Steins als Dreiecksnetze bestimmt. ColorMetapostPart legt für die einzelnen Lego-Teile, wie von DYNAmore für METApost vorbereitet, Farben aufs Modell. Assemble hat die Dreieckslisten für die Lego-Teile nach der Farbe gruppiert und zu größeren Dreieckslisten zusammengefasst, um das Rendering zu beschleunigen.
Color hat für alle Knoten/Vertices eine zusätzliche Farbe auf Grundlage der plastischen Verformung ermittelt: halbtransparentes Grau für niedrige Verformung und leuchtende Farben von Blau über Rot nach Gelb für
hohe Werte
Arbeiten wie die (Simulations-)Profis
Von Marko Thiele
Bei einem CAE-Prozess (Computer Aided Engineering) leitet man aus CAD-Daten eines Produktes die CAE-Daten zur Simulation ab, die der virtuellen Produktentwicklung dient. Das entstehende Modell soll in der Lage sein, die gesamte Physik wie Werkstoffverhalten, Verformung, Bewegung und Beschleunigung zu beliebigen Punkten in Raum und Zeit zu beschreiben.
Dieses möglichst detaillierte, physikalische Modell wird in einem zweiten Schritt einem Lösungsalgorithmus (Solver) zugeführt, in unserem Fall LS-DYNA. Die Berechnung für die Crash-Prognose ist dabei nichtlinear bezüglich der Geometrie-, Werkstoff- und Kontaktbeschreibung. So kann ein Werkstoff etwa bis zu einem gewissen Punkt voll belastet werden, bis es zu einem Materialversagen kommt und sich der Gesamtverlauf einer Simulation signifikant verschiebt.
Bei komplexen Produkten, wie sie etwa in der Fahrzeugindustrie üblich sind, betrachtet man hierfür sehr viele einzelne Bauteile, was die Zusammenarbeit vieler Ingenieure in unterschiedlichen Fachbereichen an verschiedenen Standorten notwendig macht. Für die Zusammenarbeit bei der Erstellung komplexer Modelle und Daten werden hierzu Simulationsdaten-Management-Systeme (SDM) eingesetzt, in unserem Falle LoCo. Das SDM-System vereinfacht, automatisiert und verteilt die für die Umsetzung anfallende Arbeit. Die getrennt erzeugten CAE-Daten werden am Ende automatisch zusammengeführt. Zusätzlich verwaltet das SDM-System sämtliche Daten und definiert CAE-Prozesse, um aus den Informationen je nach Bedarf die Simulationsmodelle abzuleiten.
Auch der Lego-Porsche durchlief diesen Prozess. Er besteht aus 2704 Einzelteilen, wobei nur 182 wirklich unterschiedliche Bauelemente zum Einsatz kommen. Für den Aufbau des Simulationsmodells wurde die Geometrie für jeden dieser 182 Steine definiert und abgelegt. Weiterhin musste für jeden Stein zusätzlich ein Modell für die Finite-Elemente-Methode (FEM) erstellt werden, das für die physikalischen Berechnungen notwendig ist. Anschließend wurden die Steine, sowohl im CAD- als auch im FEM-Modell, an die jeweiligen räumlichen Positionen im Gesamtsimulationsmodell platziert.
Den größten Aufwand stellt wie bei großen Fahrzeugen die Erstellung der FEM-Modelle dar. Dabei müssen die sehr hoch aufgelösten Formen durch endlich viele, jedoch geometrisch einfache Grundformen ersetzt werden. Diese finiten Elemente haben die Form von Dreiecken, Rechtecken, Tetraedern oder Hexaedern. Krümmungen oder sehr kleine Details löst man nur näherungsweise auf.
Da Anzahl und Größe der finiten Elemente Einfluss auf Berechnungszeit und die Prognosegüte haben, legt man die Elementgröße vorab fest. Beim virtuellen Lego-Crash lag sie bei minimal 0,3 Millimeter. Ein kleinerer Wert hätte für eine höhere Prognosegüte bei steigender Rechenzeit gesorgt. Der Vernetzungsprozess wird teilweise manuell durch Ingenieure oder in einigen Bereichen bereits automatisiert durchgeführt. Der Simulations-Ingenieur bearbeitet und prüft jedes einzelne Bauteil.
Bei der Erzeugung eines belastbaren Simulationsmodells für den eingesetzten Lösungsalgorithmus ist die umfängliche Definition aller weiteren relevanten physikalischen Parameter ebenso wichtig. Dazu zählen Werkstoffeigenschaften, Reibungs- und Kontaktkräfte zwischen den Steinen sowie zwischen Rädern und Fahrbahn, Klemmkräfte für Steine mit Noppen und vieles mehr.
Im SDM-System LoCo werden diese Daten vorgehalten und bei Bedarf für die Durchführung einer Simulation zusammengeführt und an einen HPC-Cluster (High-Performance-Computing) übertragen. Für die Berechnung des Crash-Modells bei DYNAmore kam ein HPC-Cluster mit 192 CPUs zum Einsatz. Die Berechnungszeit bei dem Modell „Porsche vs. Barriere“ betrug 26 Stunden, „Porsche vs. Bugatti“ brauchte 54 Stunden.
Dieser Artikel stammt aus c't 21/2019. (sha)
