Predicting the Unseen
How a battery tells you it is about to fail, and what it costs to listen.
A lithium-ion pack does not fail suddenly. It fails slowly and then suddenly, and the interesting engineering lives entirely in the first half of that sentence.
My time at Romeo Power, starting in July 2021, was spent on that first half: building software that watches a battery management system’s telemetry and says, before anything is visibly wrong, that something is about to be.
The problem is not detection
Detecting thermal runaway is easy. By the time a cell is venting, every sensor on the pack agrees. The problem is that agreement arrives too late to be useful. A commercial vehicle carrying several hundred kilowatt-hours does not have a comfortable margin between “the data looks unusual” and “the data looks like a fire”.
So the target moves. You are not trying to classify a failure. You are trying to find the shape a pack makes in the minutes and hours before it fails, and to distinguish that shape from the many other unusual things a pack does on a hot day in traffic.
A false negative is a fire. A false positive is a truck stranded at the side of a motorway with a full load. Neither of these is an acceptable rounding error.
Working against real packs
Most of what made this hard was not the model. It was that the training data came from real vehicles, which means it was noisy, unbalanced in the worst direction, and expensive to add to. Thermal events are rare. That is excellent news for the world and terrible news for anyone trying to learn their signature.
What worked was refusing to treat the problem as a single classifier. A pack has structure: cells inside modules inside a pack, each with its own thermal neighbours. A cell warming faster than the ones next to it is saying something different from a pack warming uniformly because it is August. Encoding that structure did more for the result than any amount of tuning.
What safety-critical actually changes
The part I did not expect was how much the deployment constraints shaped the design. Code that runs on a BMS is code that has to be defensible line by line. It has a memory budget. It cannot allocate at runtime. It has to behave identically on the bench and in the field, and it has to keep behaving that way after someone else edits it in two years.
That discipline turned out to be the most portable thing I took from the job. Writing software where the failure mode is a fire changes what you consider finished.