Deep Dive Into Battery Software - part 1
Deep Dive Into Battery Software - part 1
With Intercalation Station’s contributor Gaël and Breathe Battery Technologies’s CEO Ian Campbell.
Introduction
While the business model of battery producing companies is pretty clear, it can be less obvious what battery software companies do, and where they can add value. This article was prompted by a recent panel discussion organised by Breathe Battery Technologies and their scientific advisory board:
Where they cover very interesting points, such as what recent breakthroughs they find the most exciting. They touch upon the question of AI, data and physics, model parametrization, then computational cost and value proposition to manufacturing company, performance trade-offs and emerging chemistries. They conclude on a 10-year outlook for the industry, and long-term sustainability for the energy transition.
At Intercalation, we love seeing companies get together with their scientific advisory board to produce educational content, and we figured this video would provide a nice starting point for a discussion with Breathe’s CEO Ian Campbell.
In the first chapter of this three-part article, I will cover some of the basics of what battery software does (with a focus on Battery Management Software or BMS) so that you can better follow part 2 and 3, which are focused on market overview and market outlook, respectively. As you will see in these articles, battery software can do a lot more than just managing batteries, so I will cover some of that as well.
Battery Software 101
The underlying principle of BMS battery models is ultimately quite simple: calculate the cell voltage that results from a current going through the battery, which can be (very) roughly represented by the following equation:
where U0 is the open-circuit voltage (the voltage of a perfect battery), I is the current that goes through the battery (in a phone, the current is low when you lock it and put it in your pocket, but pretty high if you’re watching a movie), and Rcell is the total polarization resistance of the battery (the thing that makes your phone hotter as the movie is playing).
It would be convenient if the polarization was a constant, but that’s where battery software gets fun: in a nutshell, the goal is to calculate the polarization resistance precisely as a function of many variables, like voltage, temperature or number of cycles.
State-of-charge estimation
The most basic function of battery software, on which a lot of more advanced stuff depends, is state-of-charge estimation. This is a picture of Sony’s handycam screen (little piece of trivia: the 1991 version was the first ever consumer electronics device to use a lithium-ion battery):
We can see on the top left corner the battery charge icon which displays a pretty rough estimation of the state-of-charge (SoC) of the battery, with four levels of charge.
A simple method to estimate battery state-of-charge is coulomb-counting: the 1995 Sony Infolithium L batteries had a capacity around 2000 mAh. If recording draws a current of about 250 mA, the battery would lose 250 mAh per hour, so 25% of its charge every 2h. The Coulomb-counting algorithm would therefore update the battery icon with one fewer bar every 2h of use. Coulomb-counting by itself, however, poses problem because small errors pile up quickly and the charge reading can become inaccurate after some cycles, since there is no absolute reference for how much charge there is in the battery. This reference can be provided, to a certain extent, by voltage measurements at the cell level. The voltage / state-of-charge equivalence is not strictly linear however, so you first need to make an OCV curve for calibration, and then you need to estimate how much the current contributes to changing the voltage, to know where you are on the OCV curve.
Luckily, the handycam current is pretty stable as a function of time when you’re filming, so you can make a rough estimation of the ohmic resistance of the battery, and assume that it is a constant of the state-of-charge, the current, the temperature, etc... For a 25% accuracy, it’s probably enough.
In 2007 however came the release of the first iPhone (enabled, in part, by the use of a light 1’400 mAh lithium-ion battery) and the advent of smartphones. We can see on this iPhone screenshot a charge estimation precise at 1%:
The challenge here is that smartphone can be used for a lot of applications that may draw different currents. The good thing, however, is that they can support a software layer running more complex algorithms. Instead of a single resistance value, it's possible to store a look-up table of temperature-dependent values for example. It's also possible to solve equivalent circuit models with three Resistance-Capacitance (RC) branches instead of a single ohmic resistance. And we can add a Kalman filter on top to overcome sensor noise and add stability.
Electric vehicles basically have an onboard computer so you can imagine even more fancy stuff. Let’s say you program an SF-LA journey in your GPS. the forecast route can be used to estimate the future current profile in the car (which depends on its speed and acceleration). By inputting this current profile in the voltage modelling algorithm, it’s possible to output the future voltage profile (which will look a bit noisy if the car has to change speed often) and convert this to a forecast for the battery charge evolution. Inputting this back into the GPS gives the best charging stations, the ones that are the closest to the point where the car is forecast to reach about 20% charge.
However, you may have noticed that batteries (on your phone for example) loses capacity as years go by. This is due to a combination of battery aging over time and algorithms losing their accuracy, sometimes going quickly from 15% to 0% for example, instead of exhibiting the expected linear behavior.
State-of-health estimations
The intercalation and de-intercalation of lithium ions in the ordered structures of the cathode and the anode will lead to various changes in their microstructure, in the SEI layer thickness because of lithium plating, etc… which all contribute to reducing the capacity of the battery.
Modern smartphones have capacities around 4500 mAh, which may reduce to around 4000 mAh after 1000 cycles of use (around 3 years), although that figure depends a lot on how the phone is cycled, in terms of Depth-of-Discharge (the state-of-charge range that is used to define the 0-100% range that you see displayed on the screen), temperature, charging profile, etc…
Accounting for this degradation is important to keep the autonomy estimation algorithm’s accuracy over time. Since the algorithms are calibrated on a fresh battery, a change in the OCV or the battery resistance will change the current-voltage profile and will make the conversion from voltage to state-of-charge (and therefore the percentage you read on your screen) less accurate over time.
Again, there are various methods for countering this, such as updating the value of the equivalent-circuit model components (the ohmic resistance, for example, tends to increase with aging) or re-calibrating the open-circuit voltage of the model (although conceptually simple, this takes a long time which can be impractical for the end user).
Broadly speaking, when you’re trying to model the evolution of the battery’s polarization as a function of many parameters, there are two main approaches: physics-based and data-based.
Physics vs. data-based models
The parallel I like to draw to illustrate their difference is rocket science vs. drug design:
NASA needs to design the best rockets, in a cost-efficient way. In order to do that, they rely on careful mathematical modelling of the rocket shape and the calculation of optimal trajectories, with some tests to validate the models: this would be the physics-based approach. If they had to launch rockets after rockets to converge via trial-and-error to the optimal solution, it would quickly become prohibitively expensive (not that launching rockets is cheap to begin with).
Pharmaceutical companies, on the other hand, must quantify the impact of a drug and its side effects on patients in all kind of conditions. In order to do this computationnally, they would need to model a complete human body, with all its proteins and chemical components, and then scale that up to a large sample of different humans in different conditions to estimate the impact of the drug on the patients. The computational complexity is such that it is more straightforward to rely on clinical trials and statistics: the data-based approach.
In batteries, both are actually possible. Physics-based models typically rely on a mixture of electrochemical equations, transport laws and sometimes thermodynamics to model the relationships between current, voltage and various battery design parameters such as the nature of the electrolyte or the porosity of the electrodes. The main advantage, as in my NASA example, is that it allows to generate powerful insights from a relatively limited number of experiments.
Ian gave me some insights why Breathe Battery Technologies chose a physics-based approach:
Our main products, Breathe Charge, and Breathe Life are both software products that are built on a foundation of physics-based battery model, an architecture that we call PHI X2. These models enable our clients, battery teams from car OEMs, phone, laptops or audio companies, two things:
To extract quite substantially more insight from the existing battery that they have in their devices or vehicle, and avoid some of the trade-offs that they're so accustomed to in terms of energy density, charging speed or battery health.
The physics-based architecture being very fast for us to calibrate, that transfers to our customer experience in the sense that they can adopt our products incredibly fast. After just a couple of weeks they can have a feel for the model’s accuracy and the end-user experience. We have very low cost-to-market for our products and very low development time, and this matters a lot for them.
We deployed Breathe Life, our lifetime enhancing product, on Oppo’s smartphones (over 100 million units annually) for which we deliver a lot of value from a software-based perspective. So we originally shipped on Reno 8 series and FINDEX 5 Series of phones in 2022, and today we're on over 25 or or more different models of Oppo phones around the world, where we helped increase the cycle from a region of 800 cycles to 80% state-of-health all the way up to about 1600 cycles to 80% state-of-health. And that, as a company, is the kind of end-user impact that we were aiming for from day one.
Another type of battery software that heavily relies on physics is Finite Element Modelling (FEM) which can be useful for engineers to design battery packs for example:
While the heat source depends on the internal resistance of the battery and can be approached via electrochemical models, the way the heat propagates and dissipates within the battery pack is better approached by simulating heat transfer equations on fine, spatially-resolved meshes. The coupling between heat and electrochemistry can however quickly get quite complex.
The main drawback that I’ve personally encountered in some physics-based models (not all), is that their parametrization sometimes require to open the battery, like for measuring the porosity of the cathode for example, which is typically impractical to perform if you’re not making coin cells in a glove-box. But if you can manage the parametrization problem, they can give precious insights on the batteries.
Data-based models, on the other hand, rely on the characterization of the battery behaviour in various conditions of C-rate and temperature to derive empirical models (typically equivalent circuits). The main advantage, as in my drug design example, is that it is simple to execute and the results are pretty much guaranteed. All you need to do is buy many batteries and test them in different conditions. The main drawback is that it can quickly become expensive and time-consuming, and the models don’t always perform well in unseen conditions. This can be limiting in terms of time-to-market according to Ian:
When you take a data-driven approach today, you rely on having historical data for the batteries, and it can be quite a bit longer to let's say calibrate or adapt the models to different customers, different battery packs or cells, or different needs. And this is one of the downsides that we've historically seen. That being said we're constantly looking for innovations in the field of data-driven approaches and AI.
Indeed, AI has the potential to greatly improve data-based methods. I have written a whole article on this topic, but I think Ian and I broadly agree on the conclusions:
Broadly speaking, I mean outside of batteries alone, AI is one of the most exciting topics and one of the most exciting advancements that I've seen in my lifetime so far. I do think it has amazing potential for the battery landscape, but it's still so early that I don't think many people are clear on what the magnitude of the potential opportunity with AI and batteries could be. I'm fairly sure that, in combination with physics-based approaches or more bottom-up approaches, it can have an even greater impact than it could in isolation.
Indeed, the main take-away of my article was that good data is much harder to come by in batteries than, say, image treatment or games. Fields that involve some amount of physics, like self-driving or batteries, seem to be much harder to crack.
But as Ian said, it’s still very early and as more companies collect more and more data, there are reasons to be bullish on the future of AI in batteries, especially things like physics-inspired neural networks applied to battery management or large AI models in Industry 4.0 that could calculate the impact of temperature, humidity, solvent evaporation times, etc… on production line quality.
AI-based models are actually currently active in the latter space, although more at the lab-scale, by virtually exploring the space of battery design parameters such as active mass, anode and cathode thickness, gap size, coating temperature, additives, binders, solvents, etc… to output probable battery KPIs such as energy density, capacity, lifetime, internal resistance, etc… .
Its possible to apply neural networks with a Bayesian Tree Parzen Estimator algorithm to calculate the probability that the battery will meet performance criteria, from a set of input parameters. This probability is what the algorithm optimizes for.
Other areas where software can help is in testing the quality of batteries on the production line of gigafactories, or tracking the supply chain of materials.
Part 2 (coming very soon) will give you a brief overview of startups currently active in all the aforementioned applications of battery software.
🌞 Thanks for reading!
📧 For tips, feedback, or inquiries - reach out
there are a couple of "image not found"