Battery Lifetime Prediction: An End-to-End Case from Scientific Problem to Software Delivery

Case positioning: This article is a full demonstration of the Software Factory "one problem, one software" methodology — using BatteryLife-AI (corresponding to Case-003: Battery Lifetime & Thermal Management) to walk a replicable end-to-end loop. After reading it, you should be able to translate "a scientific problem" into "a deliverable AI+HPC software package."

1. Scientific Problem Definition (Step One: State the Problem Clearly)

Battery lifetime prediction sounds concrete, but falls apart as soon as you dig in. Define four elements first:

Element	Definition	Engineering implication
Prediction target	SOH (State of Health) / RUL (Remaining Useful Life)	regression vs classification
Input	voltage/current/temperature curves across charge-discharge cycles	time series, variable length
Prediction timing	offline diagnosis vs online rolling prediction	decides feature window and inference frequency
Evaluation metric	RMSE / early-warning hit rate	aligns with business language

Key decision: Phase 1 does "offline diagnosis" (given historical data, judge health state); Phase 2 does "online early warning" (monitor in real time, warn N cycles ahead). The two problems differ in complexity — deliver them separately.

2. Data: Public Datasets + HPC Parallel Simulation

2.1 Data Source Design

A single dataset is usually insufficient (few samples, narrow operating conditions). Combine "public + self-generated":

Source	Content	Purpose
Public datasets (e.g., NASA PCoE, Oxford, CALCE)	aging cycles under different temperatures/rates	train the main model
HPC parallel simulation data	parameterized electrochemical models generate bulk "virtual operating conditions"	fill long-tail conditions, validate generalization
Lab measurement (if available)	small sample of target conditions	final calibration

2.2 HPC Side: Batch Simulation Pipeline

Electrochemical models (equivalent circuit / quasi-2D P2D) take minutes to hours per solve; a thousand operating conditions must go through Slurm batch processing:

# sample parameter space → submit simulations in batch
# each job: run one operating-condition parameter set, output capacity fade curve
for i in $(seq 1 1000); do
    sbatch --array=$i simulate_one.sh   # Slurm job array
done

Key point: job arrays are natively suited to parameter sweeps (scheduling reference: 07 · Slurm Heterogeneous Scheduling); version the simulation results together with parameter metadata to back training and reproduction.

3. AI Model: From Curves to Lifetime Prediction

3.1 Features and Model Selection

Option	Input	Model	Pros	Cost
Baseline	hand-crafted features (capacity fade rate, internal-resistance growth rate)	XGBoost / Random Forest	interpretable, fast training	feature engineering relies on experience
Advanced	raw charge-discharge curves	LSTM/GRU	automatic feature extraction	higher data requirements
Production	curves + operating-condition metadata	time-series model + feature fusion	best generalization	highest engineering complexity

3.2 Training Decisions

• Windowing: use fixed-length cycle windows for rolling prediction (e.g., last 50 cycles → future SOH);
• Normalization: absolute capacity differs hugely across cells — normalize by initial capacity, otherwise the model just learns "big battery = big capacity";
• Early stopping & validation: split train/validation by battery ID (never random-cycle split — adjacent cycles of the same battery are highly correlated; random splitting badly overestimates performance).

4. HPC Validation: Not Just "Running a Test"

The validation stage spans both AI-compute and HPC sides:

1. Cross-validation: run the trained model on HPC-generated "virtual condition" sets to verify long-tail generalization;
2. Parameter search: search model hyperparameters (window length, hidden size, learning rate) in parallel on the cluster (Grid/Random/Bayesian) — submit dozens of training jobs in one batch;
3. Interpretability spot-checks: attribute the worst-error samples (which condition, which curve segment) to feed data resampling.

An easily overlooked point: validating an AI model is itself an HPC workload — hyperparameter search and batch inference also eat GPUs. A full loop means "data generation uses HPC, model validation also uses HPC"; cluster planning must account for both.

5. Software Delivery: Two-Phase Rollout

v0 · Offline Diagnosis

• Input: historical charge-discharge data files;
• Output: SOH estimate, RUL distribution, health report;
• Form: CLI tool + report generation, runs on the data side.

v1 · Online Early Warning

• Input: real-time monitoring data stream;
• Output: degradation warning N cycles ahead + risk level;
• Form: lightweight inference service (model packaged as API), scheduled/event triggered;
• Key point: warning thresholds are set by the business (prefer high recall where false alarms are acceptable); inference service design reference: 12 · Inference Engines.

6. Pitfalls and Tuning (Field Experience)

1. "Cycle count" ≠ "time": calendar aging (storage fade) and cycle aging have different mechanisms; modeling only cycles severely overestimates lifetime in low-utilization scenarios. At minimum add a "time" feature dimension.

2. Cell-to-cell variance > condition variance: same-model cells scatter widely; pure data-driven approaches can learn "individual noise" as "law." Mitigation: group validation by battery ID + output confidence intervals rather than point estimates.

3. Offline accuracy ≠ online accuracy: offline historical data arrives incrementally in online scenarios — feature distributions drift. Early production needs rolling prediction-error monitoring; error above threshold triggers retraining or rule fallback.

4. Don't let "demo accuracy" hold delivery hostage: paper-grade RMSE looks nice, but the business wants "how many cycles early, what hit rate." Translate metrics into business language from day one, or model-tuning drifts off course.

7. Full-Loop Retrospective

Stage	Key deliverable	Acceptance criteria
Problem definition	four-element table	business and engineers aligned
Data	public data + HPC simulation data (versioned)	covers target-condition long tail
Model	offline diagnosis model	RMSE on battery-ID-split validation meets target
Validation	virtual-condition generalization report + hyperparameter search results	long-tail error controllable
Delivery	v0 tool + v1 warning service	business metric (warning hit rate) met

Engineering takeaways:

• This chain (problem → data → model → validation → delivery) holds for any "AI for Science" topic — swap the data source in 2.1 and the model in 3.1, and the skeleton stays;
• "One problem, one software" is not one-shot: every stage has an iteration hook (resampling, retraining, threshold tuning), letting the software evolve as data grows;
• Data generation (HPC), model training (AI-compute) and validation/inference (both stacks) have different resource profiles — exactly the value of unified scheduling on the AI-HPC platform.