Batterie-Gesundheitszustand (SoH) & Restlebensdauer (RUL) vorhersagen (Elektrofahrzeuge, stationäre Speicher, Batteriepass)

Wert, Garantiekosten und Sicherheit einer Batterie hängen davon ab, wie viel nutzbare Kapazität noch vorhanden ist und wie schnell sie schwindet, doch der von einem Fahrzeug oder Wechselrichter angezeigte Wert ist oft unzuverlässig. Physikalisch informiertes maschinelles Lernen auf BMS- und Ladedaten schätzt den Gesundheitszustand (State of Health, SoH), prognostiziert die Restlebensdauer (Remaining Useful Life, RUL) und meldet auffällige Zellen. Die Ergebnisse fließen in die Preisbildung für gebrauchte Elektrofahrzeuge, die Flottenplanung, den Speichereinsatz, die Einstufung für die Zweitnutzung und den EU-Batteriepass ein.

Problem & Nutzen

• Wer: Hersteller (OEM) und Zulieferer, Flotten- und Leasingbetreiber, Eigentümer stationärer Speicher (BESS) und Versicherer, Gebrauchtwagenhändler und Marktplätze, Werkstätten, Recycler und Zweitnutzungsunternehmen; indirekt private Käufer von Elektrofahrzeugen.
• Heute: Der SoH stammt aus der eigenen BMS-Schätzung des Fahrzeugs, aus planmäßigen Kapazitätstests (langsam, das Gerät steht still) oder aus Faustregeln zu Laufleistung und Alter. Der BMS-Wert kann zu hoch oder zu niedrig ausfallen; AVILOO nennt das als Grund für BMS-unabhängige Messung [3]. Restwerte, Garantierückstellungen und Ersatzplanungen (Augmentation) für Speicher sind daher unsicher.
• KI-Nutzen: kontinuierlicher, nicht-intrusiver SoH aus Felddaten; RUL-Prognosen unter geplanter Nutzung; frühere Erkennung schwacher Zellen; unabhängige, vergleichbare Nachweise für Transaktionen.
• Regulatorischer Druck: Die Verordnung (EU) 2023/1542 verlangt für Batterien von Elektrofahrzeugen, Batterien für leichte Verkehrsmittel und Industriebatterien über 2 kWh, die ab dem 18. Februar 2027 auf dem EU-Markt in Verkehr gebracht werden, einen digitalen Batteriepass und sieht vor, dass Angaben zu Gesundheitszustand und erwarteter Lebensdauer für Eigentümer und Dritte verfügbar sind [1][2]. Prüfen Sie den Verordnungstext und die Durchführungsrechtsakte auf die genauen Datenfelder und Zugriffsrechte.
• Zahlen: Eine allgemeingültige ROI-Zahl gibt es nicht; Herstellerangaben sind selbst berichtet. Beispiele für die Größenordnung: ACCURE nennt 24+ GWh unterstützter BESS-Kapazität an 100+ Standorten [5]; AVILOO nennt mehr als 500.000 unabhängige Tests und eine Übereinstimmung von etwa +/-3 % zwischen seinem Schnelltest und seinem vollständigen Test (Herstellerangabe, Methode auf der Seite nicht veröffentlicht) [3].

Varianten

• Flottenanalytik für Elektrofahrzeuge und OEM: Garantiemanagement, Streuung von Zelle zu Pack, Coaching zum Ladeverhalten; Bezug zu PRED-025 (Garantie/Feldausfall).
• Zertifizierung gebrauchter Elektrofahrzeuge: BMS-unabhängige Prüfberichte für Händler, Versicherer und Marktplätze (AVILOO, DE/AT) [3]; Indikatoren für thermisches Durchgehen und Sicherheitsrisiko als Zusatz.
• Stationäre Speicher (BESS): Alterungsprognose für die Ersatzplanung, Garantieprüfung, Versicherungsrisiko (ACCURE mit HDI Global [5], volytica [4]); speist den Einsatzplan in OPT-032 und PRED-007.
• Zweitnutzung und Recycling: Einstufung zurückgegebener Packs für Wiederverwendung oder Recycling; Schätzung des Materialwerts.
• Batterieproduktion: frühe Vorhersage der Zelllebensdauer aus Formierungs- und End-of-Line-Daten, um Alterungstests zu verkürzen und Qualitätsabweichungen zu melden (Forschung und industrielle Pilotprojekte; bezogen auf PRED-014).
• Berichterstattung zum Batteriepass: dynamische Daten (SoH, Nutzungsereignisse) werden über einen Passdienst erfasst, signiert und veröffentlicht (zum Berichtsstack siehe DATA-012).
• Private Nutzung: Verbraucher-Apps, die OBD-/BMS-Daten auslesen, für einen persönlichen SoH-Bericht vor dem Kauf eines gebrauchten Elektrofahrzeugs; unteres Ende der Variante „Zertifizierung gebrauchter Elektrofahrzeuge“.

So funktioniert es

1. BMS/telematics/charger data (CAN, OBD, cloud API, SCADA) + lab reference tests
2. ingestion & cleaning (resampling, unit/ID mapping, gap handling)
3. feature extraction (charge-curve segments, incremental capacity, resistance estimates, temperature exposure)
4. SoH estimator (hybrid: equivalent-circuit/electrochemical model + ML correction, Kalman-type filter)
5. degradation forecast (RUL under usage scenario, with uncertainty)
6. anomaly / safety layer (cell divergence, abnormal heating, voltage drift)
7. outputs: dashboard, API, certificate, warranty/valuation inputs, battery-passport record
8. human review for warranty disputes, safety alerts and certificates

• Schätzer: Klassisch sind Coulomb-Zählung plus Referenztests; modern ist ein Grey-Box-Ansatz: ein physikalisches Modell (Ersatzschaltbild oder Single-Particle/DFN, z. B. im Open-Source-Werkzeug PyBaMM [7]), korrigiert durch Gradient-Boosting-, LSTM-/Transformer- oder Gauß-Prozess-Modelle, die auf Zyklisierungsdaten trainiert wurden.
• RUL-Prognose: Frühzyklus-Regression auf tabellarischen Merkmalen, Sequenzmodelle oder probabilistische Modelle, die Intervalle ausweisen; Szenariosimulation für unterschiedliche Lade- oder Einsatzstrategien.
• Sicherheit: unüberwachte Anomalieerkennung auf Unterschieden zwischen Zellen; die „Frühwarnung“ vor thermischem Durchgehen ist probabilistisch und darf den Hardwareschutz im BMS nie ersetzen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Ingenieure validieren Meldungen, kalibrieren anhand von Referenztests und zeichnen Zertifikate ab; Sicherheitsabschaltungen bleiben deterministische BMS-Funktionen.

Datenaufbereitung

Benötigt werden Zellspannung, Strom, Temperatur und Zyklusdaten aus dem BMS, Lade-/Entladeprotokolle, Kapazitätsprüfungen und Servicehistorie. Im Mittelstand liegen diese Daten in Herstellerportalen, Telematikplattformen, CSV-Exporten von Ladegeräten und Speicher-Wechselrichtern sowie in Service-Logbüchern auf Papier. Typische Lücken sind niedrige Abtastraten, fehlende Kapazitäts-Referenztests (keine Wahrheitsbasis für den Gesundheitszustand), unterschiedliche Formate je Hersteller, Lücken durch Verbindungsabbrüche und unklare Datenzugriffsrechte gegenüber dem OEM oder Batterielieferanten.

Aufbereitungsschritte: Zugriffs- und Exportrechte vertraglich klären; Daten über APIs oder Konnektoren abrufen (PREP-005); in ein einheitliches Zeitreihenformat mit konsistenten Einheiten überführen; Ausreißer und Lücken bereinigen; Labels aus Kapazitätstests und Garantiefällen gewinnen (PREP-020); Verknüpfungen zwischen Fahrzeug und Fahrer pseudonymisieren (PREP-022). Typische Werkzeuge sind Python (pandas, PyBaMM), InfluxDB/TimescaleDB und MQTT-Brücken. Prüfen Sie die Reife mit PREP-001 und GUIDE-003. Rechnen Sie mit rund 50 Prozent des Aufwands für Datenzugang und Bereinigung, mehr, wenn OEM-Daten erst ausgehandelt werden müssen.

Umsetzungswege

Welcher Weg für wen

• smb: A, weil Anbieter für Batterieanalytik und BMS ausgereifte SaaS-Lösungen für Flotten und Speicher zu mittelstandstauglichen Preisen mit Standardzelldaten anbieten.
• enterprise: B, weil Batteriedaten ein strategisches Gut sind und Cloud-APIs es dem Unternehmen erlauben, Flottendaten mit eigenen Alterungsmodellen zu kombinieren.
• developer: B, weil verwaltete Zeitreihendienste plus offene Alterungsbibliotheken der schnellste Weg zu einem Produkt sind.
• public: C, weil öffentlich betriebene Flotten und Speicher Telemetrie auf souveräner EU-Infrastruktur halten sollten und Open-Source-Stacks auf HW1 laufen.

Weg A — Kaufen (für die meisten Organisationen empfohlen)

• EU-/deutsche Anbieter: TWAICE (München; Batterieanalytik für Elektrofahrzeuge und BESS), volytica diagnostics (Dresden; herstellerunabhängige Zustandsüberwachung, RUL-Szenarien, Inbetriebnahmeprüfungen für BESS) [4], AVILOO (Österreich; unabhängige SoH-Tests und Zertifikate, API/Dashboard) [3], ACCURE (Deutschland; Sicherheits-, Leistungs- und Lebensdaueranalytik für BESS, Partnerschaft mit einem Versicherer) [5]. Die Angaben zu TWAICE konnten in dieser Prüfung auf der Website nicht verifiziert werden; prüfen Sie das aktuelle Angebot direkt.
• Alternativen (außerhalb der EU): Voltaiq, Angebote vom Typ Aurora/Nuvation (BMS plus Analytik) und OEM-spezifische Clouddienste.
• A wählen, wenn: Sie Flotten oder Speicher betreiben, aber kein Batteriehersteller sind, der Datenzugang über den OEM/Integrator möglich ist und Sie Ergebnisse innerhalb von Wochen bis Monaten brauchen. Fragen Sie nach: BMS-Unabhängigkeit, Ausweis der Unsicherheit, EU-Hosting, Dateneigentum, Passexport.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Allgemeines Cloud-ML (verwaltete Zeitreihendatenbanken, AutoML, Azure/AWS/Google-EU-Regionen) für Datenerfassung und Training; es gibt keine dominante „Batterie-API“ jenseits der oben genannten Anbieter-APIs.
• LLMs schaffen Mehrwert rund um die Zahlen: Meldungen zusammenfassen, Berichte zu Garantiefällen entwerfen, Zellspezifikationen aus Datenblättern extrahieren (llm-general würde ergänzt, wenn genutzt; für das Kernmodell nicht erforderlich).
• B wählen, wenn: Sie ein Datenteam haben, Flottendaten bereits in einem Cloud-Data-Lake liegen und Sie eigene Kennzahlen wollen; kombinieren Sie dies mit einer Anbieter-SoH-API als Wahrheitsbasis.

Weg C — Selbst betreiben (Open Source)

• Modelle und Werkzeuge: PyBaMM (BSD-3, physikbasierte Simulation) [7]; Microsoft BatteryML (MIT) mit Ladern für die öffentlichen Datensätze CALCE, MATR, HUST, HNEI, RWTH, SNL und UL_PUR und Baselines von Ridge-Regression bis LSTM/Transformer [6] (das Repository ist archiviert und schreibgeschützt, betrachten Sie es daher als Benchmark und Ausgangspunkt); scikit-learn/XGBoost, PyTorch, Zeitreihenspeicher (TimescaleDB, InfluxDB), Kafka/MQTT für Datenströme.
• Hardware: CPU-Server oder HW1 genügen für die meiste Inferenz; GPU (HW2) nur für das Training tiefer Sequenzmodelle oder große Simulationsläufe. Ein Einsatz am Rand (Edge) im Fahrzeug/Gateway ist über ONNX möglich.
• Aufwand: Es braucht Batterie-Fachleute plus ML-Ingenieure; schwierig sind Datenqualität und Kalibrierung, nicht die Rechenleistung.

Weg D — Eigenes Training

Lohnt sich für OEMs, Zellhersteller und große Flotten-/BESS-Betreiber mit eigener Chemie und eigenem Nutzungsmix: öffentlich trainierte Modelle übertragen sich schlecht über Chemien, Formate und Lastprofile hinweg. Es braucht lange Historien (Jahre an Felddaten) oder eine Alterungstestkampagne mit periodischen Referenztests, Labels aus Referenzkapazität/-widerstand und Zellmetadaten. Nutzen Sie Transferlernen aus öffentlichen Datensätzen [6] und physikalisch informierte Modelle, um den Datenbedarf zu senken; validieren Sie an zurückgehaltenen Fahrzeugen/Standorten, nicht an zufälligen Zeitaufteilungen.

Stand der Technik (2026)

• Hybrid aus Physik und ML ist der vorherrschende industrielle Ansatz; reines Deep Learning auf kleinen Datensätzen passt sich zu stark an die gesehenen Zellen an (Überanpassung).
• Offene Benchmarks wie BatteryML bündeln öffentliche Alterungsdatensätze und Standard-RUL-Aufgaben [6]; die Verallgemeinerung über Datensätze hinweg bleibt der Schwachpunkt.
• Felddaten vs. Labordaten: Teilladungen, verrauschte Sensoren und wechselnde Nutzung machen den SoH im Feld deutlich schwieriger als die RUL im Labor; die Quantifizierung von Unsicherheit wird zunehmend erwartet.
• Regulatorische Datenebene: Der Batteriepass macht aus dem SoH von einer proprietären Schätzung eine berichtspflichtige, prüfbare Größe; einheitliche Definitionen und Prüfverfahren sind wichtig, und die Durchführungs-/delegierten Rechtsakte der EU-Kommission legen die genauen Regeln fest [1][2]. Auch Haltbarkeitsregeln auf Fahrzeugebene entwickeln sich (z. B. UN GTR zur Haltbarkeit von Fahrzeugbatterien); prüfen Sie den aktuellen Stand im EU-Typgenehmigungsrahmen.
• Foundation-Modelle für Zeitreihen und wissenschaftliche Daten werden für Batterieprognosen erprobt; 2026 gibt es keinen klaren Produktionssieger gegenüber abgestimmten Grey-Box-Modellen. Behandeln Sie Herstellerangaben zu „Foundation-Modellen für Batterien“ mit Vorsicht.
• Grenzen: Chemiewechsel (LFP vs. NMC, Natrium-Ionen, Festkörper) machen trainierte Modelle unbrauchbar; die flache Spannungskurve von LFP erschwert die Schätzung von SoC/SoH; BMS-Daten können fehlen, grob sein oder vom OEM gesperrt sein; die Vorhersage des thermischen Durchgehens betrifft seltene Ereignisse und bietet wenig gelabelte Daten.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (time-series, tabular-ml, anomaly-detection, streaming): PRED-006 vorausschauende Wartung, PRED-025 Frühwarnung vor Feldausfällen, PRED-007 Prognose von Energielast/-erzeugung, Sensor-Anomalieerkennung vom Typ ANOM-001. Eine Streaming- und Zeitreihenplattform (Kafka/MQTT + TimescaleDB + MLflow) bedient alle diese Fälle.
• Bewertung und Finanzwesen: PRED-015 (AVM-Methoden lassen sich auf Restwertmodelle für gebrauchte Elektrofahrzeuge übertragen), PRED-010 (Versicherungsrisiko für BESS/Elektrofahrzeuge).
• Betrieb: OPT-032 Energiemanagement für Haushalte/Prosumer und BESS-Einsatzplanung nutzen den SoH als Randbedingung und als Eingang für die Alterungskosten.
• Berichterstattung: DATA-012 (ESG-/CSRD-Berichterstattung) und Pass-/Produktdatensysteme teilen Stammdaten und Signierung.
• Hardware: überwiegend CPU/HW1 und Edge-Gateways; HW2 nur für das Training.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis wenige Monate; SaaS-Gebühr pro Anlage oder pro MWh; Hauptaufwand ist der Datenzugang vom OEM/Integrator.
• Weg B: 3–6 Monate für eine individuelle Plattform mit einem Datenteam.
• Weg C/D: 6–18 Monate einschließlich Testkampagnen; Kosten entstehen durch Data Engineering, Labor-Referenztests und Fachleute.
• Kennzahlen: SoH-Fehler gegenüber dem Referenztest (MAE in Prozentpunkten), RUL-Fehler und Abdeckung der Intervalle, Anteil der Anlagen mit ausreichenden Daten, vermiedene oder korrekt abgelehnte Garantieansprüche, Fehler der Restwertprognose, Falschalarmrate bei Sicherheitswarnungen, Vollständigkeit der Passdaten.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung für den Business Case und die Pflichten zum Batteriepass ein, die Abteilungsleitung (Flotten- oder Anlagenmanagement) als Prozessverantwortliche, IT und IT-Sicherheit für die Datenanbindungen sowie Lieferanten oder den OEM für den Datenzugang. Der Betriebsrat wird in der Regel nicht ausgelöst, da das System Batterien und nicht Personen überwacht; wenn sich Telematik mit Fahrern verknüpfen lässt, gilt §87 Abs. 1 Nr. 6 BetrVG. Halten Sie die Daten daher auf Fahrzeugebene oder pseudonymisiert und informieren Sie den Betriebsrat frühzeitig (§90 Abs. 1 Nr. 3). Beziehen Sie die/den Datenschutzbeauftragte(n) ein, wenn Fahrzeugdaten Fahrer identifizieren können; eine Datenschutz-Folgenabschätzung (DSFA) ist wahrscheinlich nur nötig, wenn Standort oder Fahrverhalten in großem Umfang verarbeitet werden. Schließen Sie mit SaaS-Anbietern einen Auftragsverarbeitungsvertrag (AVV) ab.

Maßnahmen zur KI-Kompetenz (Art. 4 KI-Verordnung): kurze Schulung für Flottenmanager und Servicepersonal, was eine SoH-Schätzung und ihr Fehlerband bedeuten. Wählen Sie eine kleine Pilotflotte oder einen Speicherstandort (GUIDE-009). Typische Sorge: Vertrauen in die vorhergesagte Restlebensdauer bei Wiederverkaufs- oder Garantieentscheidungen; begegnen Sie dem mit Validierung gegen periodische Kapazitätstests und einer Regel, dass kritische Entscheidungen bei einem menschlichen Experten bleiben. Siehe GUIDE-008, GUIDE-005 und GUIDE-010.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko. Ein Batteriegesundheitsmodell ist kein Anwendungsfall nach Anhang III. Hohes Risiko liegt nur vor, wenn es eine Sicherheitskomponente eines Produkts nach Rechtsvorschriften des Anhangs I ist (z. B. eine KI-Funktion, die in das Sicherheitssystem eines regulierten Fahrzeugs integriert ist); prüfen Sie dies im Einzelfall. Art. 4 KI-Kompetenz gilt. Die Nutzung des SoH zur Bewertung von Personen (z. B. Versicherungspreise) ist gesondert zu prüfen.
• Batterieverordnung (EU) 2023/1542: Pass, Angaben zu SoH/erwarteter Lebensdauer, Sorgfaltspflichten und Pflichten zum CO2-Fußabdruck mit gestaffelten Anwendungsterminen; die Pflichten liegen beim Wirtschaftsakteur, daher sollten Genauigkeit und Rückverfolgbarkeit des Schätzers dokumentiert werden [1][2].
• DSGVO: Fahrzeug- und Ladedaten können personenbezogen sein (Standort, Fahrverhalten), und der EU Data Act wirkt sich auf den Zugang zu Daten vernetzter Produkte aus; minimieren Sie, pseudonymisieren Sie über Fahrgestellnummer/Anlagen-ID und vereinbaren Sie Datenaustauschverträge mit den Eigentümern.
• Sicherheit: KI-Meldungen ersetzen nicht den funktional sicheren BMS-Schutz (UN 38.3, Kontext IEC 62619/ISO 26262); Schwellenwerte für Meldungen brauchen eine dokumentierte Validierung.
• Kommerziell: SoH-Zertifikate beeinflussen Preise und Garantiestreitigkeiten; geben Sie Methodik, Unsicherheit und Testbedingungen an.
• Gegenmaßnahmen: Kalibrierung mit Referenztests, Drift-Überwachung, versionierte Modelle, Auditprotokoll.

Erste Schritte

1. Die Anlagen und die Daten erfassen, die Sie wirklich bekommen können (CAN-/BMS-Signale, Cloud-APIs, Abtastrate, je Zelle vs. je Pack); das vertragliche Nutzungsrecht sichern.
2. Die Zielgröße festlegen (kapazitätsbasierter SoH vs. widerstandsbasiert vs. nutzbare Energie) und ein Referenztest-Protokoll definieren.
3. Einen Anbieter aus Weg A (z. B. volytica, AVILOO oder ACCURE, je nach Elektrofahrzeug vs. BESS) mit 10–50 Anlagen pilotieren und mit den eigenen Referenztests vergleichen.
4. Parallel eine offene Baseline mit BatteryML/PyBaMM auf öffentlichen Daten prototypisieren, um das Fehlerniveau zu verstehen [6][7].
5. Die Ausgaben vor Februar 2027 auf Ihre Pass- und Berichtspflichten abbilden und entscheiden, wer den SoH-Datensatz verantwortet.

Quellen

1. European Commission — Batteries (Regulation (EU) 2023/1542 overview, application date 18 Feb 2024) — https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en
2. Battery Pass / BatteryPass-Ready project — passport mandatory from 18 Feb 2027 for EV, LMT and industrial batteries > 2 kWh — https://thebatterypass.eu
3. AVILOO — independent EV battery SoH tests and certificates — https://aviloo.com
4. volytica diagnostics — battery health monitoring and RUL software — https://www.volytica.com
5. ACCURE — BESS battery intelligence — https://www.accure.net
6. Microsoft BatteryML repository and paper (ICLR 2024, arXiv 2310.14714) — https://github.com/microsoft/BatteryML ; https://arxiv.org/abs/2310.14714
7. PyBaMM — open-source battery modelling — https://github.com/pybamm-team/PyBaMM
8. Regulation (EU) 2023/1542 (Batteries Regulation), full text — https://eur-lex.europa.eu/eli/reg/2023/1542/oj