Battery state-of-health & remaining-useful-life prediction (EV, stationary storage, battery passport)

Battery value, warranty cost and safety all depend on how much usable capacity is left and how fast it fades, yet the number shown by a vehicle or inverter is often unreliable. Physics-informed machine learning on BMS and charging data estimates state of health (SoH), forecasts remaining useful life (RUL) and flags abnormal cells. The results feed used-EV pricing, fleet planning, storage dispatch, second-life grading and the EU battery passport.

Problem & value

• Who: OEMs and suppliers, fleet and leasing operators, BESS (stationary storage) owners and insurers, used-car dealers and marketplaces, repairers, recyclers and second-life companies; indirectly private EV buyers.
• Today: SoH comes from the vehicle's own BMS estimate, scheduled capacity tests (slow, takes the asset offline) or rules of thumb on mileage and age. The BMS value can read too high or too low, which AVILOO cites as the reason for BMS-independent measurement [3]. Residual values, warranty reserves and augmentation plans for storage are therefore uncertain.
• AI value: continuous, non-intrusive SoH from field data; RUL forecasts under planned usage; earlier detection of weak cells; independent, comparable evidence for transactions.
• Regulatory pull: Regulation (EU) 2023/1542 requires a digital battery passport for EV batteries, light-means-of-transport batteries and industrial batteries above 2 kWh placed on the EU market from 18 February 2027, and the Regulation provides for information on state of health and expected lifetime to be available to owners and third parties [1][2]. Check the Regulation text and the implementing acts for exact data fields and access rights.
• Figures: no universally valid ROI number exists; vendor figures are self-reported. Examples of scale: ACCURE states 24+ GWh of supported BESS capacity across 100+ sites [5]; AVILOO states more than 500,000 independent tests and about +/-3 % agreement between its quick test and its full test (vendor claim, method not published on the page) [3].

Variants

• EV fleet and OEM analytics: warranty management, cell-to-pack variation, charging-habit coaching; links to PRED-025 (warranty/field failure).
• Used-EV certification: BMS-independent test reports for dealers, insurers and marketplaces (AVILOO, DE/AT) [3]; thermal-runaway and safety risk indicators as an add-on.
• Stationary storage (BESS): degradation forecast for augmentation planning, warranty verification, insurance risk (ACCURE with HDI Global [5], volytica [4]); feeds dispatch in OPT-032 and PRED-007.
• Second-life and recycling: grading of returned packs for reuse vs. recycling; material value estimate.
• Battery production: early-life prediction of cell lifetime from formation and end-of-line data to shorten ageing tests and flag quality deviations (research and industrial pilots; related to PRED-014).
• Battery passport reporting: dynamic data (SoH, usage events) collected, signed and published through a passport service (see DATA-012 for the reporting stack).
• Private use: consumer apps reading OBD/BMS data for a personal SoH report before buying a used EV; low-end of variant "used-EV certification".

How it works

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

• Estimator: classic is coulomb counting plus reference tests; modern is a grey-box approach: a physical model (equivalent circuit or single-particle/DFN, e.g. in the open-source PyBaMM [7]) corrected by gradient-boosting, LSTM/Transformer or Gaussian-process models trained on cycling data.
• RUL forecasting: early-cycle regression on tabular features, sequence models, or probabilistic models that report intervals; scenario simulation for different charging or dispatch strategies.
• Safety: unsupervised anomaly detection on cell-to-cell differences; thermal-runaway "early warning" is probabilistic and must never replace hardware protection in the BMS.
• Human-in-the-loop: engineers validate alerts, calibrate to reference tests, and sign off certificates; safety shutdowns remain deterministic BMS functions.

Data preparation

Needed are cell voltage, current, temperature and cycle data from the BMS, charge/discharge logs, capacity checks and service history. In an SMB this data sits in vendor portals, telematics platforms, CSV exports from chargers and storage inverters, and paper service logs. Typical gaps are low sampling rates, missing capacity reference tests (no ground truth for state of health), different formats per manufacturer, gaps from connectivity loss and unclear data access rights against the OEM or battery supplier.

Preparation steps: clarify access and export rights contractually; pull data through APIs or connectors (PREP-005); convert to a uniform time-series format with consistent units; remove outliers and gaps; harvest labels from capacity tests and warranty cases (PREP-020); pseudonymise vehicle-to-driver links (PREP-022). Typical tools are Python (pandas, PyBaMM), InfluxDB/TimescaleDB and MQTT bridges. Check readiness with PREP-001 and GUIDE-003. Expect around 50 percent of the effort in data access and cleaning, more if OEM data must first be negotiated.

Implementation paths

Which path for whom

• smb: A, because battery analytics and BMS vendors offer mature SaaS for fleets and storage at SMB prices with standard cell data.
• enterprise: B, because battery data is a strategic asset and cloud APIs let the enterprise combine fleet data with own degradation models.
• developer: B, because managed time-series services plus open degradation libraries are the fastest route to a product.
• public: C, because publicly operated fleets and storage should keep telemetry on sovereign EU infrastructure and open-source stacks run on HW1.

Path A — Buy (recommended for most organisations)

• EU/German vendors: TWAICE (Munich; battery analytics for EV and BESS), volytica diagnostics (Dresden; manufacturer-independent health monitoring, RUL scenarios, BESS commissioning checks) [4], AVILOO (Austria; independent SoH tests and certificates, API/dashboard) [3], ACCURE (Germany; BESS safety, performance and lifetime analytics, insurer partnership) [5]. TWAICE details could not be verified from its website in this review; check current offering directly.
• Alternatives (non-EU): Voltaiq, Aurora/Nuvation-type BMS-plus-analytics offerings, and OEM-specific cloud services.
• Choose A when: you operate fleets or storage but are not a battery maker, data access is available through the OEM/integrator, and you need results within weeks to months. Ask for: BMS-independence, uncertainty reporting, EU hosting, data ownership, passport export.

Path B — Build on cloud APIs

• Generic cloud ML (managed time-series databases, AutoML, Azure/AWS/Google EU regions) for ingestion and training; there is no dominant "battery API" beyond vendor APIs above.
• LLMs add value around the numbers: summarising alerts, drafting warranty-case reports, extracting cell specs from datasheets (llm-general would be added if used; not required for the core model).
• Choose B when: you have a data team, fleet data already in a cloud lake, and want custom KPIs; combine with a vendor SoH API as ground truth.

Path C — Self-host (open source)

• Models and tooling: PyBaMM (BSD-3, physics-based simulation) [7]; Microsoft BatteryML (MIT) with loaders for public datasets CALCE, MATR, HUST, HNEI, RWTH, SNL and UL_PUR and baselines from ridge regression to LSTM/Transformer [6] (the repository is archived and read-only, so treat it as a benchmark and starting point); scikit-learn/XGBoost, PyTorch, time-series stores (TimescaleDB, InfluxDB), Kafka/MQTT for streams.
• Hardware: CPU servers or HW1 suffice for most inference; GPU (HW2) only for training deep sequence models or large simulation sweeps. Edge deployment on the vehicle/gateway possible via ONNX.
• Effort: need battery domain experts plus ML engineers; the hard part is data quality and calibration, not compute.

Path D — Custom training

Worthwhile for OEMs, cell makers and large fleet/BESS operators with their own chemistry and usage mix: publicly trained models transfer poorly across chemistries, formats and duty cycles. Needs long histories (years of field data) or an ageing test campaign with periodic reference tests, labels from reference capacity/resistance, and cell metadata. Use transfer learning from public datasets [6] and physics-informed models to cut data needs; validate on held-out vehicles/sites, not random time splits.

State of the art (2026)

• Hybrid physics + ML is the dominant industrial approach; pure deep learning on small datasets overfits to the cells it saw.
• Open benchmarks such as BatteryML consolidate public ageing datasets and standard RUL tasks [6]; cross-dataset generalisation remains the weak point.
• Field data vs. lab data: partial charges, noisy sensors and variable usage make field SoH much harder than lab RUL; uncertainty quantification is increasingly expected.
• Regulatory data layer: the battery passport shifts SoH from a proprietary estimate to a reportable, auditable figure; standard definitions and test methods matter, and the EU Commission's implementing/delegated acts determine the exact rules [1][2]. Vehicle-level durability rules are also developing (e.g. UN GTR on in-vehicle battery durability); verify the current status in the EU type-approval framework.
• Foundation models for time series and scientific data are being tried for battery forecasting; no clear production winner against tuned grey-box models in 2026. Treat vendor claims of "foundation models for batteries" with caution.
• Limits: chemistry changes (LFP vs. NMC, sodium-ion, solid state) break trained models; LFP's flat voltage curve makes SoC/SoH estimation hard; BMS data may be unavailable, coarse or locked by the OEM; thermal-runaway prediction is rare-event and has little labelled data.

Shared resources & combinations

• Same building blocks (time-series, tabular-ml, anomaly-detection, streaming): PRED-006 predictive maintenance, PRED-025 field-failure early warning, PRED-007 energy load/generation forecasting, ANOM-001-type sensor anomaly detection. One streaming and time-series platform (Kafka/MQTT + TimescaleDB + MLflow) serves all of them.
• Valuation and finance: PRED-015 (AVM methods transfer to used-EV residual-value models), PRED-010 (insurance risk for BESS/EV).
• Operation: OPT-032 home/prosumer energy management and BESS dispatch use SoH as constraint and cost-of-degradation input.
• Reporting: DATA-012 (ESG/CSRD reporting) and passport/product-data systems share master data and signing.
• Hardware: mostly CPU/HW1 and edge gateways; HW2 only for training.

Effort, cost & KPIs

• Path A: weeks to a few months; SaaS fee per asset or per MWh; main effort is data access from OEM/integrator.
• Path B: 3-6 months for a custom platform with a data team.
• Path C/D: 6-18 months incl. test campaigns; costs are data engineering, lab reference tests and domain experts.
• KPIs: SoH error vs. reference test (MAE in % points), RUL error and interval coverage, share of assets with sufficient data, warranty claims avoided or correctly rejected, residual-value forecast error, false alarm rate for safety warnings, passport data completeness.

People & change

Involve management for the business case and battery passport duties, the department lead (fleet or asset management) as process owner, IT and IT security for data connections, and suppliers or the OEM for data access. The works council is generally not triggered because the system monitors batteries, not people; if telematics can be linked to drivers, §87(1) no. 6 BetrVG applies, so keep data at vehicle level or pseudonymised and inform the council early (§90(1) no. 3). Involve the DPO when vehicle data can identify drivers; a DPIA is likely only if location or driving behaviour is processed at scale. Conclude an AVV with SaaS vendors.

AI literacy measures (Art. 4 AI Act): brief training for fleet managers and service staff on what an SoH estimate and its error band mean. Choose a small pilot fleet or one storage site (GUIDE-009). Typical concern: trust in predicted remaining life for resale or warranty decisions; address with validation against periodic capacity tests and a rule that critical decisions stay with a human expert. See GUIDE-008, GUIDE-005 and GUIDE-010.

Risks, regulation & compliance

• EU AI Act: typically minimal risk. A battery-health model is not an Annex III use case. It becomes high risk only if it is a safety component of a product under Annex I legislation (e.g. an AI function integrated in a regulated vehicle's safety system); assess case by case. Art. 4 AI literacy applies. Using SoH to rate individuals (e.g. insurance pricing) should be checked separately.
• Battery Regulation (EU) 2023/1542: passport, SoH/expected-lifetime information, due diligence and carbon-footprint duties, with staggered application dates; obligations rest on the economic operator, so data accuracy and traceability of the estimator should be documented [1][2].
• GDPR: vehicle and charging data can be personal (location, driver behaviour) and the EU Data Act affects access to connected-product data; minimise, pseudonymise by VIN/asset ID, and agree data-sharing contracts with owners.
• Safety: AI alerts do not replace functional-safety BMS protection (UN 38.3, IEC 62619/ISO 26262 context); alert thresholds need documented validation.
• Commercial: SoH certificates affect prices and warranty disputes; state methodology, uncertainty and test conditions.
• Mitigation: reference-test calibration, drift monitoring, version-controlled models, audit log.

Getting started

1. Inventory the assets and the data you can really get (CAN/BMS signals, cloud APIs, sampling rate, per-cell vs. per-pack); secure the contractual right to use it.
2. Define the target quantity (capacity-based SoH vs. resistance-based vs. usable energy) and a reference test protocol.
3. Pilot one vendor from Path A (e.g. volytica, AVILOO or ACCURE depending on EV vs. BESS) on 10-50 assets and compare with your own reference tests.
4. In parallel, prototype an open baseline with BatteryML/PyBaMM on public data to understand error levels [6][7].
5. Map outputs to your passport and reporting obligations before February 2027 and decide who owns the SoH record.

Sources

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