KI-gestützte Crashtest-Simulation und virtuelle Absicherung

Das echte Ausmaß des Problems

Ein modernes Fahrzeug muss vor der Serienfreigabe eine Vielzahl von Crashszenarien bestehen: Frontalaufprall mit voller Überdeckung und 40-%-Überdeckung gegen eine deformierbare Barriere, seitlicher Pfahl- und Barrierenaufprall, Heckaufprall, Fußgängerschutz-Szenarien, Far-Side-Impact, und bei Elektrofahrzeugen zusätzlich Batteriezellen-Integritätstests. Für jede Variante eines Fahrzeugs, jede Plattformableitung, jede Baureihe.

Die Zahlen dahinter sind brutal: Für eine einzelne Fahrzeugfrontstruktur sind laut EDAG Engineering zwischen 200 und 600 FEM-Simulationen notwendig, um alle relevanten Aufprallpunkte und Konfigurationen abzudecken. Datenvorbereitung, Berechnung, Validierung und eventuelle Neuberechnung summieren sich auf vier bis sechs Wochen pro Iterationszyklus, mit einem hochperformanten Rechencluster, der weder günstig noch für jeden Tier-1 ständig verfügbar ist.

Die physischen Tests am Ende dieser Pipeline kosten je nach Testaufbau und Fahrzeugreife zwischen 100.000 und 600.000 Euro pro Versuch, inklusive Instrumentierung, Messtechnik, Crash-Dummies und der Vollausstattungs-Rohkarosse. Ein vollständiges Euro-NCAP-Testprogramm für eine neue Plattform bindet über den gesamten Entwicklungszyklus leicht zweistellige Millionenbeträge.

Für einen OEM mit mehreren gleichzeitigen Plattformprojekten ist das beherrschbar. Für einen Tier-1-Zulieferer, der für drei OEMs parallel Crashzulieferteile entwickelt, wird die CAE-Kapazität zum chronischen Engpass, besonders in den kritischen Phasen vor Serienentscheidungen.

Das strukturelle Problem: Die Simulationszeit begrenzt nicht die Qualität der Lösung, sondern die Anzahl der Lösungen, die ein Team überhaupt evaluieren kann. Welche Geometrievarianten bleiben wegen Zeitmangel ungeprüft? Welche Leichtbaumaßnahme wird aufgegeben, weil kein Simulationsslot mehr frei ist?

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Erfahrungswerte aus EDAG-KI-Crash-Projekten und Neural-Concept-Implementierungen; stark abhängig von Datenmenge, Trainingsqualität und Lastfall-Komplexität. Physische Testreduktion setzt eine regulatorisch konforme Validierungsstrategie voraus.

Der wichtigste Effekt ist nicht Geschwindigkeit per se, er ist der Übergang von Selektion zu Exploration. Ohne KI wählt das Team unter Zeitdruck die vielversprechendsten drei Varianten aus und simuliert diese. Mit KI werden Tausende Varianten durchfiltert, bevor die vier besten in die teure Vollsimulation gehen.

Einschätzung auf einen Blick

Zeitersparnis, maximal (5/5)
Wenige Anwendungsfälle in der Automobilentwicklung haben eine so große Zeitdifferenz zwischen Status quo und KI-gestütztem Ansatz. Von 16 Stunden HPC-Laufzeit auf Sekunden GPU-Inferenz, das ist kein gradueller Unterschied, sondern ein Sprung um Größenordnungen, den auch NVIDIAs eigene Studie beschreibt. Einer der größten Zeithebel der Branche, auch wenn die initiale Einrichtung Monate dauert.

Kosteneinsparung, maximal (5/5)
Einsparen lässt sich nur der Versuch, der ohne Vorfilterung gescheitert wäre, nicht der Pflichtversuch für die Zulassung. Ein Bauteilversuch auf Tier-1-Ebene kostet 80.000 bis 250.000 Euro, ein Gesamtfahrzeugversuch beim OEM bis 600.000 Euro. Verhindert das Surrogate zwei bis vier Fehlversuche je Projekt, sind auf Tier-1-Ebene 160.000 bis 1.000.000 Euro drin, dagegen stehen je nach Weg 0 Euro (Open Source, dafür eigenes ML-Personal) bis ein unterer sechsstelliger Betrag im Jahr (Plattform-Abo). Bei mehreren Projekten im Jahr ist das ein sehr großer Kostenhebel, bei einem Projekt im Jahr kann das Abo ihn auffressen (Rechnung unten).

Schnelle Umsetzung, minimal (1/5)
Das ist der härteste Score in dieser Kategorie. Eine produktive KI-Surrogate-Integration in einen bestehenden Crash-CAE-Workflow dauert typisch 12–24 Monate: Datensichtung und -bereinigung, Modelltraining, Validierung gegen bekannte Tests, schrittweise Integration in den Freigabeprozess, regulatorische Absicherung. Kein Projekt dieser Komplexität geht schneller. Dieser Score ist beabsichtigt, er ist ehrlicher als jede Vereinfachung.

ROI-Sicherheit, mittel (3/5)
Der direkte Zeiteinsparungseffekt ist klar messbar. Schwieriger ist die Attribution: Wie viele physische Tests wurden wegen des Surrogates eingespart, und wie viele hätte man auch ohne KI eingespart, weil andere Design-Iterationen ohnehin nicht gebaut worden wären? Die regulatorische Unsicherheit (physische Tests bleiben Pflicht) begrenzt zudem die maximale Einsparung. Das ist kein schwacher ROI, aber kein so direkter Nachweis wie etwa bei automatisierter Rechnungsverarbeitung.

Skalierbarkeit, hoch (4/5)
Ein trainiertes Surrogate-Modell skaliert ohne proportionalen Mehraufwand auf weitere Varianten derselben Fahrzeugplattform. Weitere Lastfälle und neue Plattformprojekte erfordern allerdings Retraining, die Skalierbarkeit ist plattformintern stark, plattformübergreifend begrenzt.

Richtwerte, stark abhängig von Unternehmensgröße, CAE-Infrastruktur, Datenqualität und Fahrzeugplattform.

Was die KI-Simulation konkret macht

Der technische Ansatz heißt Surrogate Modeling oder Machine Learning-basierte Metamodellierung. Das Grundprinzip: Statt jede neue Designvariante durch eine vollständige FEM-Simulation zu schleusen, lernt ein neuronales Netz aus einer Sammlung bereits durchgeführter Simulationen das Verhalten des Bauteils, und kann dann neue, ungesehene Designvarianten in Sekundenbruchteilen einschätzen.

Der konkrete Ablauf

Phase 1, Trainingsdaten aufbauen. Aus dem bestehenden Simulations-Archiv werden 50–200 historische FEM-Crashsimulationen (typisch Ansys LS-DYNA - oder Altair HyperWorks -Berechnungen) mit variierenden Geometrie- und Materialparametern extrahiert. Diese Daten werden vorverarbeitet: Netzgeometrie, Wandstärken, Materialparameter als Inputs; Intrusion, Energieabsorption, Kraft-Weg-Kurven und Karosserie-Deformation als Outputs.

Phase 2, Modell trainieren. Plattformen wie Neural Concept oder NVIDIA PhysicsNeMo trainieren Graph-Neural-Networks auf diesen Daten. Der Trainingsprozess dauert typisch 5–15 Stunden auf einer leistungsstarken GPU, einmalig pro Lastfall und Plattform.

Phase 3, Explorative Parameterstudien. Das trainierte Modell bewertet 1.000 oder 10.000 neue Designvarianten in Minuten, ohne HPC-Cluster, ohne Lizenzkosten pro Lauf. Ingenieure können Parameterräume explorieren, die zuvor rechnerisch unerreichbar waren.

Phase 4, Selektion für Vollsimulation. Die vielversprechendsten 5–10 % der surrogat-evaluierten Varianten gehen in klassische Referenzsimulationen mit dem Vollmodell. Diese bleiben unverzichtbar, für die Dokumentation, für die regulatorische Absicherung und weil das Surrogate außerhalb seines Trainingsbereichs unzuverlässig werden kann.

Phase 5, Physische Tests selektiv. Die besten Kandidaten aus den Vollsimulationen werden für Komponenten- und Systemtests vorgeschlagen. Die Anzahl physischer Versuche sinkt, weil das Surrogate die unvielversprechenden Optionen schon früh aussortiert hat.

Was das System nicht ist

Ein Crash-Surrogate ist kein eigenständiger Simulator. Es lernt Muster aus vorhandenen Simulationen, und ist nur so gut wie diese Daten. Neue Topologien (ein völlig anders aufgebautes Bauteil), andere Crash-Konfigurationen (anderer Aufprallwinkel, andere Barriere) oder neue Materialien außerhalb des Trainingsraums produzieren unzuverlässige Vorhersagen. Das System erkennt diese Fälle oft nicht als “außerhalb meiner Kompetenz”, es gibt trotzdem eine Zahl aus.

Das CAE-Ökosystem: Solver und Surrogate im Zusammenspiel

Wer diesen Use Case implementiert, muss zwei getrennte Softwarewelten zusammenbringen: die klassische FEM-Simulation und die KI-Surrogate-Schicht. Beide Welten haben ihre eigene Logik, ihre eigenen Formate, ihre eigenen Experten.

Die Solver-Seite

Der Industriestandard für explizite Crash-FEM-Simulation ist Ansys LS-DYNA . Nahezu alle globalen OEMs und Tier-1-Zulieferer haben Ansys LS-DYNA in ihrem CAE-Workflow. Simulationsdaten liegen als K-Files und d3plot-Ausgaben vor, das sind die Rohmaterialien, auf denen KI-Surrogate trainieren.

Die wichtigste Alternative ist Altair HyperWorks mit dem RADIOSS-Solver und dem spezialisierten HyperCrash-Preprocessing. RADIOSS liest LS-DYNA-Formate, was die Migration erleichtert. Ein eingebautes Surrogate-Modul (HyperStudy Fit) macht parametrische Optimierungen ohne separates ML-Tool möglich, weniger leistungsfähig als spezialisierte Plattformen, aber integrierter.

Für OEMs mit Dassault-Systèmes-Ökosystem übernimmt 3DEXPERIENCE mit SIMULIA (Abaqus/Explicit) eine ähnliche Rolle, ebenfalls EU-Datenhosting, allerdings andere Modellformate als Ansys LS-DYNA .

Die Surrogate-Schicht

Neural Concept ist eine spezialisierte Plattform für Crash-Surrogate aus der Schweiz, laut Anbieter unter anderem für Abaqus- und Ansys-Daten; LS-DYNA und RADIOSS nennt Neural Concept nicht ausdrücklich, das vor dem Pilot klären. Referenzen in der Automobilindustrie in der Crashoptimierung. Den Hosting-Standort im Vertrag festhalten, unsere Toolseite führt ihn nicht als EU-Hosting.

NVIDIA PhysicsNeMo ist ein Open-Source-Framework für physics-informed ML-Modelle. Eine Studie von NVIDIA-Forschern (arXiv, Oktober 2025) zeigt für Crash-Surrogate mit PhysicsNeMo eine Senkung des Rechenaufwands um Größenordnungen, hält aber auch fest, dass die Modelle die Genauigkeit einer vollen FE-Rechnung noch nicht erreichen. PhysicsNeMo ist frei verfügbar auf GitHub, erfordert aber erhebliche ML-Expertise für Integration und Training.

EDAG KI-Crash ist ein proprietäres Werkzeug des Ingenieurdienstleisters EDAG Engineering, das auf physikerweiterte neuronale Netze setzt. Das Tool liefert Ergebnisse für Euro-NCAP-Crashworthiness-Assessments in ein bis zwei Tagen statt vier bis sechs Wochen, und läuft laut EDAG auf einer mobilen Workstation ohne Rechenzentrumsanbindung. Als Dienstleistung nutzbar, keine eigene Lizenzierung notwendig.

Wann welcher Ansatz

• Eigene Solver-Landschaft ist LS-DYNA-basiert, ML-Expertise intern vorhanden → NVIDIA PhysicsNeMo + eigener ML-Stack (günstigster Weg, höchste Anforderungen)
• Spezialisierte Crash-Surrogate-Plattform gesucht, europäischer Vertragspartner wichtig → Neural Concept
• Altair HyperWorks -Ökosystem bereits vorhanden, einfacher Einstieg → HyperStudy Fit als erster Schritt
• Kein eigenes CAE-Team, aber Crashtest-Optimierung nötig → EDAG KI-Crash als Dienstleistung

Regulatorischer Rahmen, was Euro NCAP virtuell erlaubt

Das zentrale Missverständnis: KI-Surrogate ersetzen keine physischen Tests für die Homologation. Sie beschleunigen den Weg dahin.

Was aktuell virtuell gilt

Euro NCAP hat virtuelle Simulationen schrittweise in seinen Bewertungsprozess integriert. Seit 2020 wird die Far-Side-Impact-Bewertung (Seitenaufprall mit Verformung der Beifahrerseite) teilweise virtuell durchgeführt, das war der erste Lastfall, für den virtuelle Dossiers regulatorisch anerkannt wurden. Ab 2024 ist Far-Side virtuelles Testing vollständig in Kraft; Euro NCAP arbeitet an der Ausweitung auf Frontal- und HWS-Schutz-Bewertungen als Teil des 2030-Roadmaps.

Das Protokoll ist dabei strikt: Mindestens 75 Prozent der Euro-NCAP-Verifikationstests eines Szenarioclusters müssen die Qualifikationskriterien erfüllen, sonst wird das Simulationsdossier nicht akzeptiert. Hersteller müssen zusätzlich physische Validierungsversuche (Sled-Tests) einreichen, um die Übereinstimmung zwischen Simulation und realem Versuch zu belegen.

Was physisch Pflicht bleibt

Für alle Lastfälle, die Euro NCAP noch nicht als virtuell anerkannt hat, und das ist 2026 noch die Mehrheit der Crash-Testpunkte, sowie für die finale Typgenehmigung nach UN-ECE-Regularien (UN R94, R95, R137) bleibt der physische Test obligatorisch. Keine Behörde akzeptiert derzeit ein KI-Surrogate als Ersatz für einen physischen Crash.

Die KI-Einsparung liegt daher im Vorfeld: Welche Variante geht in den physischen Test? Das Surrogate filtert die Kandidaten so, dass der physische Test mit hoher Wahrscheinlichkeit besteht, und nicht als teurer Fehlversuch endet.

UN R137, Frontalaufprall Vollüberdeckung

UN R137 (Frontalaufprall mit voller Überdeckung gegen eine starre Barriere, 50 km/h) gehört neben R94 (versetzter Aufprall gegen eine deformierbare Barriere) zu den Frontalcrash-Vorschriften der Typgenehmigung. Die Anforderungen an Fahrgastzellen-Integrität und Rückhaltesystem-Performance sind umfangreich und erfordern physische Nachweise. KI-Surrogate können hier die Entwicklungsphase erheblich beschleunigen, aber nicht den abschließenden physischen Test ersetzen.

Praktische Implikation für den Einkauf: Wer KI-Crash-Simulationsdienste von einem Dienstleister bezieht, muss sicherstellen, dass der Dienstleister den regulatorischen Kontext kennt und die Ergebnisse entsprechend einordnet. Ein „Surrogate sagt Bestehen” ist keine Zulassungsaussage.

Genauigkeitsschwellen und Validierung

Wie gut muss ein Crash-Surrogate sein, damit es als Entscheidungsgrundlage taugt? Die Antwort hängt davon ab, wofür man es einsetzt, und das ist eine Designfrage, keine technische.

Genauigkeit für Exploration vs. Selektion

Für explorative Parameterstudien (Tendenz: Welche Richtung ist vielversprechend?) ist eine relative Fehlerquote von 10–20 % oft ausreichend. Das Surrogate muss nicht exakt sein, es muss die Topkandidaten von den Schlechtesten trennen können.

Für selektive Vollsimulation (Welche 5 von 500 Kandidaten gehen in den HPC?) sind 5–10 % relativer Fehler auf kritische Größen wie maximale B-Säulen-Intrusion oder Energieabsorption anzustreben. Laut der Dokumentation des NVIDIA PhysicsNeMo -Crashbeispiels erreichen die besten Modelle (GeoFlare) auf dem Stoßfänger-Testset relative L²-Fehler unter 1 % und beim Gesamtfahrzeug zwischen knapp 0,9 und 1,6 %. Das sind Werte auf NVIDIAs Testdaten, nicht auf euren.

Für die regulatorische Dokumentation gilt: Nur Vollsimulationen mit dem validierten FEM-Solver zählen. Surrogate-Ergebnisse sind interne Entscheidungshilfen, keine Zulassungsgrundlage.

Das Out-of-Distribution-Problem

Jedes Surrogate-Modell hat eine Trainingsdomäne, den Parameterraum, den die historischen Simulationen abgedeckt haben. Außerhalb dieser Domäne degradiert die Genauigkeit, und das Modell erkennt das typischerweise nicht selbst. Es gibt trotzdem eine Zahl aus.

Konkrete Fälle, in denen Surrogate-Modelle für Crash versagen:

• Neue Topologie: Ein Konstrukteur schlägt eine Hohlstruktur mit inneren Rippen vor, die im Trainingsset nicht vorkommt. Das Modell hat keine Grundlage für diese Geometrie.
• Anderes Material: Ein neuer hochfester Stahl (HX420) mit anderem Versagensverhalten als die Trainingswerkstoffe.
• Anderer Aufprallwinkel: Das Trainingsset deckt 0° Frontalaufprall ab, aber das neue Szenario ist ein 15°-Schrägaufprall.
• Geometrie-Sprung: Wenn eine Blechdicke außerhalb des trainierten Parameterbereichs liegt, z.B. alle Trainingsläufe lagen bei 0,8–1,5 mm, ein neuer Vorschlag liegt bei 2,0 mm.

Die Validierungsstrategie muss dieses Risiko adressieren: Für jede neue Plattform oder jeden neuen Lastfall muss das Surrogate gegen eine Handvoll gezielter Referenzsimulationen validiert werden, bevor es produktiv eingesetzt wird.

Konkrete Werkzeuge, was wann passt

Zusammenfassung: Wann welche Strategie

• Erster Pilot, kein eigenes ML-Team → EDAG KI-Crash als Dienstleistung oder Neural Concept mit Onboarding
• Bestehendes Ansys LS-DYNA -Archiv, ML-Expertise intern → NVIDIA PhysicsNeMo (Open Source)
• Altair-Shop → HyperStudy Fit als Einstieg, Neural Concept für Skalierung
• Abaqus/SIMULIA-Umgebung → Neural Concept (trainiert auch auf Abaqus-Daten)

Datenschutz und Datenhaltung

Crash-Simulationsdaten sind Konstruktionsdaten, keine personenbezogenen Daten im Sinne der DSGVO. Der klassische AVV-Pfad nach Art. 28 DSGVO greift hier nicht primär. Relevanter ist der Schutz von Geschäftsgeheimnissen: Fahrzeuggeometrien, Materialparameter, Crashbox-Topologien und Versuchsergebnisse vor dem Launch sind hochsensibles Entwicklungs-IP.

Cloud vs. On-Premises

Das erste zu klärende Risiko ist Datenresidenz, nicht DSGVO:

• Neural Concept ist ein Schweizer Anbieter; die Hosting-Region ist laut unserer Toolseite nicht öffentlich dokumentiert, dedizierte Cloud- oder On-Premises-Setups sind nach Anbieterangaben möglich. Region vor dem ersten Datentransfer schriftlich festlegen. Vertragsgrundlage ist ein NDA mit IP- und Löschklauseln; ein Auftragsverarbeitungsvertrag nur, soweit doch Personendaten verarbeitet werden, etwa Nutzerkonten.
• NVIDIA PhysicsNeMo ist Open-Source und kann vollständig On-Premises auf eigenem HPC-Cluster oder in der firmeninternen Cloud betrieben werden, volle Datenkontrolle.
• EDAG KI-Crash als Dienstleistung bedeutet: Konstruktionsdaten gehen an EDAG. Für Fahrzeugkonzepte, die noch nicht öffentlich sind, ist ein striktes NDA mit definierten Datenlöschfristen Pflicht.
• Altair HyperWorks und Ansys LS-DYNA laufen typisch On-Premises auf dem eigenen HPC, kein Cloud-Datentransfer für die eigentliche Simulation.

Was mit eurem Datenschutzbeauftragten zu klären ist

Für Simulationsdaten, die ausschließlich technische Konstruktionsparameter enthalten (keine Personendaten), ist kein AVV im DSGVO-Sinne erforderlich. Wichtig ist aber eine IP-Schutzklausel im Dienstleistervertrag: Wer trainiert auf euren Daten? Werden Modelle nach Projektende gelöscht? Kann der Anbieter aus euren Daten lernen und dieses Wissen für andere Kunden nutzen?

Diese Fragen sind bei jedem KI-Anbieter im CAE-Bereich aktiv zu stellen, und vertraglich zu fixieren, bevor CAD-Modelle hochgeladen werden.

Was es kostet, realistisch gerechnet

Einmalige Kosten

• Datensichtung und -aufbereitung (FEM-Archiv bereinigen, Trainingsset zusammenstellen): 2–8 Wochen Ingenieurszeit intern; typisch 20.000–60.000 Euro wenn extern unterstützt
• Modelltraining und Validierung (Erstes Surrogate für einen Lastfall): 30.000–100.000 Euro für professionelles Onboarding (z.B. Neural Concept ), oder 3–6 Monate ML-Engineering intern
• Infrastruktur (falls NVIDIA PhysicsNeMo On-Premises): Leistungsfähige GPU-Workstation (NVIDIA A100/H100-Klasse): 15.000–60.000 Euro einmalig; Cloud-GPU laut unserer Toolseite ab etwa 4 US-Dollar je Stunde (A100 bei AWS)

Laufende Kosten

• Neural Concept : Subscription, Preise nur auf Anfrage; für ein OEM-Team typisch im unteren sechsstelligen Jahresbereich
• Altair HyperWorks HyperStudy Fit: Inbegriffen in bestehender HyperWorks-Lizenz (wenn vorhanden), kein Zusatzpreis
• NVIDIA PhysicsNeMo : Open Source, kostenlos; laufende Kosten nur für GPU-Infrastruktur
• EDAG KI-Crash: Projektbasiertes Dienstleistungsmodell; für ein Fahrzeugprojekt typisch 50.000–200.000 Euro je nach Umfang
• Ansys LS-DYNA als Trainingsdaten-Solver: Typisch bereits vorhanden bei OEM/Tier-1; Jahreslizenzen sechs- bis siebenstellig

Was du dagegen rechnen kannst

Ein physischer Crashversuch (Komponentenebene Tier-1) kostet 80.000–250.000 Euro. Einsparen lässt sich nur ein Versuch, der ohne Vorfilterung gescheitert wäre, die Pflichtversuche bleiben. Wie viele Fehlversuche ihr habt, steht in euren Versuchsprotokollen: Zählt die gescheiterten Bauteilversuche der letzten zwei, drei Projekte.

Rechenbeispiel für ein einzelnes Fahrzeugprojekt: 2 bis 4 verhinderte Fehlversuche, 2 mal 80.000 bis 4 mal 250.000 Euro, also 160.000 bis 1.000.000 Euro direkte Kosteneinsparung, plus die kürzere Entwicklungszeit, die schwerer zu beziffern ist, aber für OEMs mit Markteinführungsterminen viel wert ist.

Vorsichtiges Szenario: Ein Projekt im Jahr, ein verhinderter Fehlversuch zu 100.000 Euro, Setup 150.000 Euro, Plattform-Abo im unteren sechsstelligen Bereich, hier 100.000 Euro im Jahr. Dann frisst das Abo die Einsparung auf, 100.000 minus 100.000 = 0, und das Setup amortisiert sich nie. Erst ab zwei verhinderten Fehlversuchen im Jahr bleiben 100.000 Euro übrig, dann sind die 150.000 Euro Setup nach anderthalb Jahren zurück. Der Open-Source-Weg spart das Abo, bindet dafür ML-Personal. Das ist ein strategisches Infrastrukturinvestment, kein Quick-Win.

Typische Einstiegsfehler

1. Mit dem falschen Lastfall starten.
Der Reflex: “Wir machen zuerst den komplexesten Lastfall, Frontalaufprall mit vollständiger Fahrzeugkarosse.” In der Praxis scheitert das fast immer, weil die Modellkomplexität die verfügbaren Trainingsdaten übersteigt. Lösung: Mit einem überschaubaren Komponenten-Lastfall starten, Crashbox, Stoßfänger, B-Säulen-Segment. Dort ist die Geometrievariabilität gering, die Datenlage oft gut, und ein erster valider Surrogate ist in 3–6 Monaten möglich. Erst danach eskalieren.

2. Trainingsdaten ohne Konsistenzprüfung verwenden.
Viele FEM-Archive enthalten Simulationen aus verschiedenen Projekten, verschiedenen Solver-Versionen, verschiedenen Materialmodellen und verschiedenen Netzdichten. Ein Surrogate, das auf inkonsistenten Daten trainiert, lernt Rauschen statt Physik. Lösung: Vor dem Training eine Datenklassifizierung durchführen, welche Simulationen sind für denselben Lastfall, dieselbe Geometriefamilie, dieselbe Solver-Version? Nur konsistente Subsets trainieren.

3. Surrogate-Ergebnisse ohne Validierung in Entscheidungen einbeziehen.
”Das Surrogate sagt, Variante 7 ist gut”, und das Team baut direkt den Prototyp. Ohne Validierung gegen eine Handvoll Referenzsimulationen (außerhalb des Trainingssets) ist diese Entscheidung blind. Lösung: Für jeden neuen Einsatzbereich mindestens 5–10 % der evaluierten Varianten mit Vollsimulationen gegenchecken. Die Accuracy-Metrics des Surrogates auf diesen Hold-Out-Datensätzen bestimmen, wie viel Vertrauen das Team in die Vorhersagen setzen darf.

4. Das Modell wird einmalig trainiert und dann unbegrenzt genutzt.
Das ist der gefährlichste Fehler, weil er still eskaliert.

Ein Crash-Surrogate trainiert auf Daten einer bestimmten Fahrzeugplattform und Materialgeneration. Wenn ein neuer hochfester Stahl eingeführt wird, ein Konstrukteur Geometriebereiche außerhalb des Trainingsparameters vorschlägt, oder die Plattform grundlegend geändert wird, produziert das Modell falsche Vorhersagen, ohne das anzuzeigen. Es gibt immer eine Zahl aus. Das Team verlässt sich auf diese Zahl, wählt die “beste” Variante, und scheitert beim physischen Test.

Die organisatorische Lösung: Jedes Surrogate-Modell braucht eine definierte Domänengrenze (welche Parameter- und Geometriebereiche wurden trainiert?), einen Retraining-Trigger (neue Materialien, Plattformänderung, Solver-Update), und eine namentlich benannte Person, die diese Grenzen kennt und kommuniziert. Das ist keine Aufgabe für die IT, es ist eine Aufgabe für den leitenden CAE-Ingenieur.

Was mit der Einführung wirklich passiert, und was nicht

Die technische Integration eines Crash-Surrogates ist im Vergleich zum kulturellen Wandel das kleinere Problem.

Der Glaubwürdigkeitstest. Erfahrene Crashberechnungsingenieure, Menschen, die seit Jahren FEM-Modelle aufbauen und die Grenzen dieser Methode kennen, werden einem neuronalen Netz zu Recht misstrauen. “Das Surrogate sagt, die Variante ist gut, aber ich sehe in der Deformationsoptik ein Problem” ist eine legitime Einschätzung, die das Team ernst nehmen muss. Lösung: Den Surrogate nie als Entscheidungsersatz präsentieren, sondern als Exploration-Tool. Die FEM-Ingenieure behalten das letzte Wort, das Surrogate filtert vor.

Der Kompetenz-Silo-Effekt. ML-Wissen und CAE-Wissen sind selten in einer Person vereint. Ein Projekt, das beide Welten verbinden muss, braucht entweder seltene Hybridprofile, oder ein funktionierendes Interface zwischen einem ML-Team und einem CAE-Team. Ohne dieses Interface entstehen Modelle, die technisch korrekt trainiert, aber für die Simulation des falschen Verhaltens zuständig sind. Lösung: Gemeinsame Kickoffs, in denen CAE-Ingenieure den ML-Ingenieuren erklären, warum Crash-Physik kompliziert ist, und welche Ausgabegrößen wirklich entscheidungsrelevant sind.

Der Langzeithorizont. Die erste Frage nach 6 Monaten: “Wann sparen wir wirklich Geld?” Das Surrogate reduziert erst dann physische Tests, wenn es gut genug validiert ist, um Vertrauen zu genießen. Das dauert länger als die Technik suggeriert. Ein realistischer Kommunikationsrahmen: “Im ersten Jahr bauen wir die Infrastruktur und validieren. Im zweiten Jahr explorieren wir damit, sparen aber noch keine physischen Tests. Im dritten Jahr beginnt die echte Amortisation.”

Was konkret hilft:

• Einen “Champion”-Ingenieur pro Projekt benennen, der beide Welten versteht oder aktiv als Übersetzer fungiert
• Ersten Pilot-Einsatz auf einem Projekt, bei dem der physische Test schon abgeschlossen ist, Surrogate-Ergebnisse für bekannte Outcomes validieren, bevor echte Entscheidungen damit getroffen werden
• Monatliche Review-Meetings: Welche Surrogate-Vorhersagen wurden durch Vollsimulationen oder Tests bestätigt, welche nicht?

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Das ist ein 24-Monats-Investment, kein 6-Wochen-Projekt. Wer schnellere Ergebnisse braucht, sollte mit EDAG KI-Crash als Dienstleistung starten, und parallel die interne Infrastruktur aufbauen.

Häufige Einwände, und was dahintersteckt

„Unsere FEM-Ingenieure vertrauen dem KI-Modell nicht.”
Das ist kein irrationaler Widerstand, das ist Kompetenz. Ein guter FEM-Ingenieur weiß, was Simulationsmodelle falsch machen können, und überträgt das Misstrauen zu Recht auf das Surrogate. Die Lösung ist nicht Überzeugung, sondern Validation: Zeig, dass das Surrogate auf 20 bekannten Testcases korrekt liegt, bevor du es auf unbekannte anwendest. Dann entscheidet das Team nach Evidenz, nicht nach Vertrauen.

„Physische Tests bleiben doch Pflicht, was spart das dann?”
Korrekt. Physische Tests für die Homologation werden durch kein Surrogate ersetzt. Die Einsparung liegt in den physischen Tests, die scheitern, weil die falsche Variante nominiert wurde. Wie viele schlechte Varianten ein Surrogate zuverlässig aussortiert, lässt sich nicht pauschal sagen, das zeigt erst die Validierung gegen eure eigenen Hold-out-Simulationen, bevor teures Metall verformt wird. Zusätzlich: Entwicklungszeit. Wenn ein Redesign-Zyklus von 4 Wochen auf 3 Tage sinkt, kommen mehr Varianten zum Testen, und die beste hat mehr Zeit, bis zur Nominierung poliert zu werden.

„Wir haben nicht genug historische Simulationsdaten für das Training.”
Das ist die ehrlichste Ausschluss-Aussage, die es gibt. Miura Simulation berichtet von brauchbaren Surrogaten schon ab 20 hochgenauen Simulationen, wenn viel Physikverständnis in die Datenaufbereitung fließt; wir setzen die Schwelle vorsichtiger bei rund 50 konsistenten Simulationen für denselben Lastfall. Die Lösung ist nicht “Surrogate einführen”, sie ist “erstmal mehr Simulationsdaten produzieren und dokumentieren, damit wir in zwei Jahren starten können”. Diese Aussage verdient Respekt, nicht Rationalisierung.

„Das ist doch nur für OEMs, wir als Tier-1 können das nicht stemmen.”
Nicht mehr. Neural Concept nennt Referenzkunden aus Automobil- und Zulieferindustrie, darunter Subaru und Eaton. EDAG KI-Crash als Dienstleistung erfordert keine eigene Infrastruktur. Der Einstieg für ein Tier-1-Team mit 5–10 CAE-Ingenieuren und einem spezifischen Crashbox-Problem ist realistisch, wenn die Datenbasis stimmt.

Woran du merkst, dass das zu dir passt

• Ihr habt rund 50 oder mehr konsistente FEM-Crashsimulationen auf vergleichbaren Geometrien und demselben Lastfall im Archiv, du hast die Trainingsdaten
• Deine Designoptimierungszyklen dauern 3–6 Wochen und der Engpass ist die Simulationskapazität, nicht die Konstruktionszeit
• Physische Crashtests scheitern gelegentlich, weil zu wenig Zeit war, alle vielversprechenden Varianten zu simulieren, das Surrogate würde genau diese Lücke schließen
• Du hast oder planst EV-Entwicklung: Batteriegehäuse-Crashabsicherung ist ein hervorragender Einstiegsfall für Surrogate, definierter Parameterraum, hohe Variationsvielfalt, klare Messgröße (maximale Intrusion)
• Dein Unternehmen hat Zugang zu ML-Expertise, intern oder über einen Dienstleister wie EDAG oder Neural Concept

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Weniger als ~50 historische FEM-Crashsimulationen auf demselben Lastfall und derselben Geometriefamilie. Ohne diese Datenbasis ist kein verlässliches Surrogate-Modell trainierbar. Der erste Schritt ist dann nicht KI-Einführung, sondern Simulation-Workflow-Aufbau: Mehr simulieren, besser dokumentieren, konsistenter parametrisieren, damit in 12–24 Monaten ein Trainingsdatensatz vorhanden ist.

2. Kein expliziter FEM-Crash-Solver im Einsatz (kein Ansys LS-DYNA , kein RADIOSS, kein Abaqus/Explicit). Statische Struktursimulationen mit impliziten Solvern wie Nastran sind keine Grundlage für Crash-Surrogate, die Physik ist eine andere. Ohne Crash-Solver gibt es keine Trainingsdaten, kein Modell, keinen Einstieg.

3. Kein CAE-Ingenieur mit Crash-Spezialwissen im Haus oder als verlässlichen Partner. Ein ML-Team allein, ohne jemanden, der die Crash-Physik versteht, kritische Ausgabegrößen kennt und das Surrogate-Verhalten hinterfragen kann, produziert Modelle, die technisch gut trainiert sind und trotzdem das falsche Problem lösen. ML ohne Domain-Expertise ist in diesem Bereich nicht nur nutzlos, sondern potenziell gefährlich: Es gibt Zahlen aus, die niemand hinterfragen kann.

Das kannst du heute noch tun

Statt eines teuren Einstiegs gibt es einen konkreten Erkenntnisschritt, der nichts kostet: Schreib die offenen Auslegungsfragen aus deinem letzten Crashtest-Projekt auf und notiere je Frage, wie viele Simulationsläufe du dafür gebraucht hättest, und wie viele du tatsächlich durchgeführt hast. Zähl dazu die Bauteilversuche, die gescheitert sind.

Diese Lücke ist dein Business Case. Wenn sie größer als 3 Varianten pro Frage ist und du mehr als 10 solcher Fragen pro Projekt hast, lohnt es sich, eine Machbarkeitsstudie zu beauftragen (EDAG oder Neural Concept bieten initiale Assessment-Sessions an).

Für einen ersten Eindruck, wie ein Crash-Surrogate technisch gebaut wird: Das NVIDIA PhysicsNeMo -Beispiel ist open-source auf GitHub verfügbar (NVIDIA/physicsnemo, Verzeichnis examples/structural_mechanics/crash). Einen Datensatz liefert das Beispiel laut Dokumentation nicht mit, du brauchst vorverarbeitete LS-DYNA-Daten, etwa eine Handvoll eigener Stoßfänger-Simulationen. Wer PyTorch-Kenntnisse hat, versteht damit die Methode, bevor Entwicklungsbudget bewilligt wird.

Wenn dein Team den Business Case formulieren will, hier ist ein Prompt, der das strukturiert:

Quellen & Methodik

• EDAG Engineering, „Effiziente Berechnung zum Euro-NCAP-Crashtest” (insights.edag.com, 2023): KI-Crash-Tool liefert Ergebnisse in 1–2 Tagen statt 4–6 Wochen; läuft auf mobiler Workstation ohne Rechenzentrum; 200–600 FEM-Simulationen für eine Fahrzeugfront als Branchenwert. Quelle: insights.edag.com/de/euro-ncap-crashtest-optimierung-fahrzeugentwicklung-mit-kuenstlicher-intelligenz
• NVIDIA PhysicsNeMo, Crashbeispiel: Dokumentation mit relativen L²-Fehlern auf den Testsets (Stoßfänger unter 1 %, Gesamtfahrzeug knapp 0,9 bis 1,6 %, bestes Modell GeoFlare); kein Datensatz im Beispiel enthalten. docs.nvidia.com/physicsnemo/latest, abgerufen am 18.09.2026.
• Nabian et al., „Automotive Crash Dynamics Modeling Accelerated with Machine Learning” (arXiv 2510.15201, Oktober 2025): Größenordnungen weniger Rechenaufwand mit MeshGraphNet und Transolver in PhysicsNeMo, Genauigkeit einer vollen FE-Rechnung noch nicht erreicht. arxiv.org/abs/2510.15201, abgerufen am 18.09.2026.
• Miura Simulation, „Use of scarce crash simulation data to build efficient surrogate models” (miurasimulation.com, 2023): Surrogate-Optimierung möglich mit nur 20 Hochgenauigkeitssimulationen; Prediction in unter 1 Sekunde nach Training; Physikverständnis für sinnvolle Datentransformation unverzichtbar. Quelle: miurasimulation.com
• Euro NCAP Virtual Testing Protocols (euroncap.com, 2024/2025): Far-Side virtual testing seit 2020, vollständig in Kraft ab 2024; 75-%-Qualifikationsschwelle für Verifikationstests; Crash Protection Virtual Testing Protocol v1.0, März 2025. Quellen: euroncap.com/media/85850/; euroncap.com/media/85832/
• Neural Concept, „Simulation Crash Testing” (neuralconcept.com, 2024): Crashbox- und Battery-Encasing-Use-Cases; abhängig von Datenmenge und -konsistenz; physische Tests für Zertifizierung Pflicht. Quelle: neuralconcept.com
• Preisangaben LS-DYNA, Altair HyperWorks, Neural Concept, PhysicsNeMo: Unsere Toolseiten, Stand 18.09.2026. Keiner der Anbieter veröffentlicht Listenpreise für Enterprise-CAE-Software; alle Angaben sind Schätzkorridore, keine verbindlichen Angebote.

Willst du wissen, ob dein FEM-Datenarchiv als Trainingsgrundlage geeignet ist oder welcher Einstiegsweg für dein Team realistisch ist? Das klären wir gerne in einem kurzen Gespräch.