Testdaten-Analytik in der Entwicklung & Reduzierung physischer Tests (Batterie, Antriebsstrang, Komponenten)

Eine Batterie, einen E-Antrieb oder eine Komponente zu validieren bedeutet Wochen an Zyklierung, Prüfstandsläufen und Klimakammern auf knappen Prototypen. ML-Modelle, die auf diesen Daten trainiert werden, sagen das Ergebnis ungetesteter Bedingungen voraus, ordnen, welcher Test als Nächstes laufen soll, und markieren fehlerhafte Läufe früh. So erreicht ein Validierungsprogramm dieselbe Sicherheit mit einer kleineren Testmatrix. Anbieter berichten von Einsparungen beim Testaufwand im zweistelligen Prozentbereich; die Ergebnisse hängen stark von der Datenqualität ab und davon, wie sehr neue Entwürfe früheren ähneln.

Problem & Nutzen

• Heute: Testmatrizen entstehen aus DoE-Regeln, Normen und Erfahrung der Ingenieure. Kampagnen werden oft vollständig gefahren, weil niemand nachweisen kann, welche Punkte überflüssig sind. Die Daten liegen in Silos (Zyklerdateien, MDF/MF4, Tabellen, Testberichte), Auffälligkeiten wie Sensordrift oder eine ausgefallene Klimakammer werden spät entdeckt, und jeder verlorene Lauf kostet Kammerzeit und einen Prototyp.
• KI-Nutzen: weniger physische Tests und Prototypen, frühere Go/No-go-Entscheidungen, schnellere Kalibrierung, höhere Datenqualität und Wiederverwendung von Testwissen über Programme und Standorte hinweg.
• Berichtete Zahlen (vom Anbieter berichtet, nicht unabhängig geprüft): Monolith nennt bis zu rund 70 % weniger Batterietests mit seinem Next Test Recommender sowie ein Beispiel mit einem Brennstoffzellen-Lüfter, bei dem 60 statt 129 Tests genügten, um die Leistung zu charakterisieren (53 % weniger) [1][2]. Kautex Textron (ein Unternehmen von Textron) hat Monolith von einem Pilotprojekt zu Kraftstoff-Schwappgeräuschen auf Tests von EV-Batteriegehäusen ausgeweitet [3].
• Wissenschaftliche Belege: Severson et al. (Nature Energy 2019) sagten die Zyklenlebensdauer von Lithium-Ionen-Zellen aus den ersten 100 Zyklen voraus, und Attia et al. (Nature 2020) nutzten Bayessche Optimierung mit Frühprognose, um die Suche nach einem Schnellladeprotokoll in einem sehr großen Suchraum mit deutlich weniger Experimenten zu verkürzen [4][5].

Varianten

• Batteriealterung und Zellcharakterisierung: Zyklenlebensdauer, kalendarische Alterung, Suche nach Schnellladeprotokollen, Lebensdauerprognose in der Frühphase (teilt Modelle mit PRED-026 für Batterien im Feld).
• Antriebsstrang und E-Antrieb: Wirkungsgradkennfelder, thermisches Derating, NVH, Dauerhaltbarkeit auf Rollenprüfständen; geringerer Kalibrieraufwand für Motor-/ECU-Kennfelder.
• Komponenten- und Strukturprüfung: Ermüdung, Vibration, Dichtheits-/Druckprüfungen für Tanks, Gehäuse, Bremsen, Sitze; Kombination von Test und Simulation (SCI-005).

So funktioniert es

1. test benches / cyclers / DAQ / MDF files + test plans + simulation data
2. ingestion & harmonisation (units, channels, metadata, test-ID lineage)
3. data quality & anomaly detection (invalid runs, sensor drift, chamber faults)
4. feature extraction (curve features, dQ/dV, degradation indicators, operating-point statistics)
5. surrogate / outcome models (Gaussian process, gradient boosting, neural nets) with uncertainty
6. active learning / Bayesian experimental design (next-best-test, matrix reduction)
7. engineer review of proposed test plan
8. run on bench
9. results feed back
10. reporting, release evidence, knowledge base

• Modelle: Lernverfahren für kleine Datenmengen (tabellarisch und Zeitreihen) überwiegen. Gauß-Prozesse und Bayessche Optimierung liefern kalibrierte Unsicherheit, und diese rechtfertigt es, einen Test auszulassen. Gradient Boosting und neuronale Netze eignen sich für größere Kampagnen. Physikinformierte oder hybride Modelle (Ersatzschaltbild, elektrochemisch) begrenzen die Extrapolation.
• Logik der Testreduzierung: Das System schlägt den Test mit dem höchsten erwarteten Informationsgewinn vor und hört auf, sobald die Vorhersageunsicherheit unter eine mit der Entwicklung vereinbarte Schwelle fällt.
• Mensch-in-der-Schleife (Human-in-the-Loop): Testingenieure genehmigen jede Verkleinerung der Matrix; sicherheitsrelevante, homologationspflichtige und gesetzlich vorgeschriebene Tests werden nie allein aufgrund von Modellergebnissen ausgelassen. Die endgültige Freigabe bleibt beim verantwortlichen Ingenieur und im Typgenehmigungsverfahren.

Datenaufbereitung

Prüfstandsdaten (Spannung, Strom, Temperatur, Drehmoment, Vibration) liegen typischerweise in Zykler- und DAQ-Software, in MDF4-Messdateien, in Excel-Auswertungen und in Testberichten als PDF oder auf Dateifreigaben; Testpläne und Probenmetadaten stehen oft in anderen Tabellen oder nur im Kopf des Ingenieurs. Typische Lücken sind uneinheitliche Kanalnamen und Einheiten, fehlende Verknüpfungen zwischen Messdatei und Prüfling, Testbedingungen und Test-ID, unterschiedliche Abtastraten, nicht gekennzeichnete ungültige Läufe und Altformate.

Schritte der Aufbereitung: 1. Erfassen Sie Quellen und Verantwortliche (PREP-001, PREP-004) und definieren Sie die Rückverfolgbarkeit der Test-ID vom Plan bis zur Rohdatei. 2. Exportieren und konvertieren Sie Dateien in ein offenes Format (asammdf, Parquet) und vereinheitlichen Sie Kanalnamen und Einheiten (PREP-005, PREP-007). 3. Überführen Sie Testpläne und DoE-Matrizen aus Excel in saubere Tabellen (PREP-011). 4. Kennzeichnen Sie ungültige Läufe und Sensorfehler; gewinnen Sie Labels wie bestanden/nicht bestanden oder Fehlerursache aus vorhandenen Berichten (PREP-020). 5. Legen Sie ein Glossar der Testarten und Kennzahlen fest (PREP-012).

Rechnen Sie mit 50 bis 60 Prozent des Projektaufwands für die Datenaufbereitung, dem größten Anteil der Arbeit. Die kommerziellen Plattformen verkürzen dies durch Import-Adapter, doch Metadaten und Disziplin bei der Test-ID bleiben Ihre Aufgabe. Beginnen Sie mit einer Testart und einigen hundert vollständigen Historien.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, da ausgereifte Testdaten-Plattformen (Monolith, MATLAB, AVL, dSPACE/ETAS) gängige Formate lesen und in Wochen Ergebnisse liefern, ohne dass Data Scientists nötig sind.
• Enterprise: Weg C, da Testhistorien zentrales Entwicklungs-Know-how sind und große Datenmengen die Lizenzkosten pro Arbeitsplatz hochtreiben; ein offener Stack (asammdf, BoTorch, MLflow) passt zu HW1 und einer gemeinsamen internen Plattform.
• Developer: Weg C, da der offene Python-Stack den gesamten Ablauf auf einem CPU-Server abdeckt.

Weg A — Kaufen (empfohlen für KMU)

• KI-Plattformen für Testdaten: Monolith (UK; No-Code-ML für Testdaten, Empfehlung für den nächsten Batterietest, Anomalie-Erkennung) [1][2]; Siemens Simcenter und Altair (jetzt Teil von Siemens; RapidMiner, HyperStudy) sowie Dassault Systemes (BIOVIA/SIMULIA) für DoE- und Surrogat-Workflows; MathWorks (MATLAB Model-Based Calibration Toolbox, Statistics and ML Toolbox); AVL (Österreich, EU; AVL CAMEO / modellbasierte Kalibrierung und Prüfstandsdaten-Werkzeuge); dSPACE (DE, EU) und ETAS (DE, EU) für ECU-Kalibrierung und Messdaten; Voltaiq (USA, Batterie-Analytik).
• Wählen Sie A, wenn: Sie Ergebnisse in Wochen möchten, ein Entwicklungsteam, aber keine Data Scientists haben und Ihr Datenformat (MDF4, Zyklerdateien) unterstützt wird.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Data Lake plus verwaltetes ML in EU-Regionen (Azure ML, AWS SageMaker in Frankfurt, Google Vertex AI in der EU), mit scikit-learn, XGBoost/LightGBM, GPyTorch und BoTorch für die Modelle.
• LLM-Schicht (Mistral, Claude, GPT, Gemini mit Datenhaltung in der EU) für die Suche in Testberichten und das Erstellen von Testzusammenfassungen; numerische Entscheidungen bleiben bei den klassischen Modellen, nicht beim LLM.

Weg C — Selbst betreiben (Open Source)

• Stack: Python mit scikit-learn, GPyTorch/BoTorch, Ax (adaptives Experimentieren), Optuna, asammdf für MDF4-Dateien, PyBaMM für die Batteriephysik, pandas, MLflow für das Tracking [6][7]. Anomalie-Erkennung in Zeitreihen mit PyOD, tsfresh-Merkmalen oder Isolation Forests.
• Hardware: HW1 (CPU-Server) deckt die meisten Engineering-Modelle für kleine Datenmengen ab; GPUs (HW2) nur für große neuronale Surrogatmodelle oder ein lokales LLM für den Berichts-Copiloten.

Weg D — Eigenes Training

Lohnt sich für Programme mit hohem Volumen (Zellhersteller, Tier-1 mit vielen ähnlichen Teilen), bei denen ein eigenes Alterungs- oder Dauerhaltbarkeitsmodell zu einem Wettbewerbsvorteil wird. Erfordert hunderte vollständige Testhistorien je Produktfamilie, konsistente Metadaten und eine zurückgehaltene Validierungskampagne.

Stand der Technik (2026)

• Active Learning und Bayessches optimales Versuchsdesign sind die wichtigsten Treiber der Testreduzierung; Kampagnen im geschlossenen Kreislauf (Attia 2020) sind die Referenz [5]. Anbieter bieten dies als Empfehlung für den nächsten Test an [1].
• Frühprognose der Batterielebensdauer aus kurzer Zyklierung ist bei Laborzellen bekannter Chemie ausgereift [4]; die Übertragung auf andere Chemien, Formate und reale Lastprofile ist weiterhin begrenzt.
• LLM-Copiloten werden für die Berichtssuche, das Entwerfen von Testplänen und Code zur Datenaufbereitung eingesetzt, nicht für numerische Vorhersagen.
• Grenzen und Fehlerbilder: Die Extrapolation auf neue Werkstoffe, Geometrien oder Lastfälle ist unzuverlässig; verrauschte oder inkonsistente Testdaten erzeugen übermütige Modelle; ausgelassene Tests können seltene Fehlerarten verbergen (den langen Schwanz, den die Validierung finden soll); die vom Anbieter berichteten Einsparungen sind nicht unabhängig verglichen. Halten Sie stets eine Verifikations-Testmenge vor und überwachen Sie die Modelldrift, wenn sich Entwürfe ändern.

Gemeinsame Bausteine & Kombinationen

• Surrogat-/DoE-Stack gemeinsam mit SCI-005 (Simulations-Surrogate) und SCI-006 (generatives Design); das Modell zur Testreduzierung wird oft gemeinsam auf Simulations- und Testdaten trainiert.
• Batteriemodelle gemeinsam mit PRED-026 (Gesundheitszustand im Feld) und PRED-006 (vorausschauende Wartung); der Code zur Anomalie-Erkennung nutzt Pipelines im Stil von ANOM-006 weiter.
• Automatisierung: SCI-007 (selbststeuernde Labore) schließt den Kreislauf mit automatisierten Prüfständen; SCI-025 (FMEA, 8D/CAPA) verwertet Befunde zu auffälligen Läufen; SCI-013 (MBSE) verknüpft Tests mit Anforderungen.

Aufwand, Kosten & Kennzahlen

• Weg A: Pilot in 4-8 Wochen mit einer Kampagne; Lizenz pro Arbeitsplatz oder pro Projekt; Kostentreiber sind die Datenbereinigung und die Anbindung an Prüfstände.
• Weg B: 3-6 Monate für eine produktive Pipeline mit Governance; Cloud-Rechenleistung fällt im Vergleich zum Daten-Engineering kaum ins Gewicht.
• Weg C: 3-6 Monate, ein Data Scientist plus Testingenieure in Teilzeit.
• Kennzahlen: Anteil vermiedener Tests gegenüber einer Basis-Matrix, Vorhersagefehler und Kalibrierung der Unsicherheit auf zurückgehaltenen Tests, eingesparte Prototypen, Durchlaufzeit der Validierung, Erkennungsrate auffälliger Läufe und Fehlalarme, Kalibrieriterationen je Freigabe, Nacharbeit oder spät gefundene Fehler.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsleitung und der Leitung von Test bzw. Validierung, die den Prozess verantwortet und entscheidet, welche Tests nie reduziert werden dürfen. Beziehen Sie die Testingenieure ein, die jede vorgeschlagene Verkleinerung der Matrix genehmigen, sowie die Verantwortlichen für Zykler, DAQ-Systeme und Archive (Datenverantwortliche). Die IT kümmert sich um Dateizugriff, Integration und Server; binden Sie sie ein, sobald der Data Lake oder der Server geplant wird (GUIDE-003).

Betriebsrat: abhängig vom Einzelfall. Das System analysiert Maschinen- und Prüflingsdaten, nicht Personen, doch Prüfstandsprotokolle und Berichte können offenlegen, wer welchen Test wie schnell durchgeführt hat, und eine Plattform, die Nutzeraktivitäten protokolliert, kann unter §87 Abs. 1 Nr. 6 BetrVG fallen, weil die objektive Eignung genügt. Klären Sie dies früh und informieren Sie den Betriebsrat über den KI-gestützten Arbeitsprozess (§90 Abs. 1 Nr. 3); oft genügt eine kurze Betriebsvereinbarung (GUIDE-004). Personenbezogene Daten fallen kaum an, daher ist eine DSFA meist unnötig, doch der Datenschutzbeauftragte sollte dies bestätigen.

Fördern Sie die KI-Kompetenz durch Schulungen für Ingenieure zu Unsicherheit, Grenzen der Extrapolation und dazu, warum Sicherheits- und Homologationstests nie allein aufgrund von Modellergebnissen ausgelassen werden (GUIDE-006). Wählen Sie einen Piloten mit einer Komponentenfamilie und vergleichen Sie die Vorhersagen mit einer zurückgehaltenen Kampagne (GUIDE-009). Typische Sorge: Weniger Tests bedeuten weniger Arbeitsplätze oder weniger Sicherheit. Begegnen Sie ihr, indem Sie die Entscheidungsregeln offenlegen und die Ingenieure als endgültige Freigeber behalten (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko bei Engineering-Analytik; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Ein Modell, das eine Sicherheitskomponente eines regulierten Produkts ist, würde nach dem Produktrecht beurteilt, ein von Ingenieuren genutztes Validierungswerkzeug ist jedoch normalerweise kein Hochrisiko-System. Keine Rechtsberatung.
• DSGVO: Testdaten sind normalerweise nicht personenbezogen; Bediener-IDs oder Freitextnotizen können personenbezogene Daten enthalten, pseudonymisieren Sie sie daher. Telemetrie aus Kundenfahrzeugen (Felddaten) sind personenbezogene Daten.
• Branchenregeln: Typgenehmigung und Homologation (UNECE-Regelungen, EU 2018/858) verlangen vorgeschriebene physische Tests; die EU-Batterieverordnung (EU) 2023/1542 enthält Pflichten zu Haltbarkeit, Leistung und Batteriepass, auf die KI-gestützte Testnachweise rückführbar bleiben müssen [8]. Prozesse nach ISO 26262/ISO 21434 und Prüfspezifikationen der Kunden können dokumentierte Nachweise verlangen.
• Geistiges Eigentum: Testdaten sind zentrales Know-how; prüfen Sie die Datennutzungsbedingungen der Anbieter und das Hosting in der EU [9].
• Hauptrisiko: zu großes Vertrauen in ein Modell und das Auslassen eines entscheidenden Tests. Gegenmaßnahmen: Schwellen für die Unsicherheit, verpflichtende Bestätigungstests, Freigabe durch den verantwortlichen Ingenieur, Nachweise zur Modellvalidierung und Änderungskontrolle, wenn sich Entwürfe oder Lieferanten ändern.

Erste Schritte

1. Wählen Sie eine wiederholbare Kampagne (z. B. Zellzyklierung oder einen Dauerhaltbarkeitstest) und erfassen Sie die Daten: Formate, Vollständigkeit der Metadaten, Anzahl abgeschlossener Testhistorien.
2. Bauen Sie einen sauberen Datensatz mit einheitlichen Test-IDs und Einheiten auf; ergänzen Sie zuerst Anomalie-Markierungen, denn das ist der Gewinn mit dem geringsten Risiko.
3. Führen Sie einen Rückvergleich durch: Trainieren Sie auf älteren Tests und prüfen Sie, ob das Modell zurückgehaltene Tests vorhergesagt hätte und welche Tests es ausgelassen hätte.
4. Betreiben Sie einen Schattenpiloten, in dem das Modell eine verkleinerte Matrix empfiehlt, während die vollständige Matrix weiter läuft; vergleichen Sie die Ergebnisse.
5. Vereinbaren Sie Abbruchkriterien und Freigaberegeln mit Qualität und Homologation, bevor Sie tatsächlich reduzieren.

Quellen

1. Monolith AI — EV battery testing with AI — https://www.monolithai.com/battery-testing
2. Design News — AI tool reduces battery testing by up to 70% — https://www.designnews.com/batteries-energy-storage/ai-tool-reduces-battery-testing-by-up-to-70-
3. Monolith — Kautex-Textron reduces development time — https://www.monolithai.com/press-release/kautex-textron-reduces-development-time-with-monolith
4. Severson et al., Data-driven prediction of battery cycle life before capacity degradation, Nature Energy 2019 — https://www.nature.com/articles/s41560-019-0356-8
5. Attia et al., Closed-loop optimization of fast-charging protocols for batteries with machine learning, Nature 2020 — https://www.nature.com/articles/s41586-020-1994-5
6. BoTorch — https://github.com/pytorch/botorch
7. PyBaMM — https://github.com/pybamm-team/PyBaMM
8. Regulation (EU) 2023/1542 (Batteries Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1542/oj
9. Regulation (EU) 2023/2854 (Data Act) — https://eur-lex.europa.eu/eli/reg/2023/2854/oj
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj