Battery Sizing and Design for Electric Vehicles

Hi. My name is Mike Susina, and I'm one of the automotive product managers, here at MathWorks. I joined MathWorks in 2016. For the first 10 years or so of my career, I was in consulting, working on optimal control algorithms for hybrid and electric vehicle systems, and now I work with the development team in order to bring products to our automotive customers.

I'm joined today by my colleague Danielle Chu. Danielle will introduce herself later in the presentation today. But the two of us are here today to talk to you about battery sizing and design for electric vehicles. So what we're going to walk through today is a workflow where we're going to start by doing some kind of an optimal sizing for a battery pack. So we do some kind of an initial assessment of the system performance, and then we find an optimal battery pack size, before moving on to some design oriented workflows, where we want to get more in-depth with that battery model.

We'll be introducing a few different products over the course of this presentation. We'll show how Powertrain Blockset that can be used for system-level modeling, and we want to quantify different trade-offs in our design. Then, the Global Optimization Toolbox and Simulink Design optimization will be used to then solve those optimization problems efficiently, while accounting for those different trade-offs that we have and competing objectives. And then Danielle will talk about Simscape Battery and how it can be used to perform more detailed battery design studies. But most importantly, we're showing how these products are all complementary, and they can be part of a continuous workflow.

So I'll start by giving a little bit of context, and then we'll walk through the vehicle model and talk about the battery sizing problem we have. Then, Danielle we'll talk more about the battery design portions of the study, before we wrap it up. So first, some context. So powertrains, we're seeing more and more EV powertrains out there, and that's primarily because the automotive sector sees this as a very important initiative. For example, the EPA estimates that over a quarter of the CO2 emissions in the US come from the transportation sector.

So we see that battery electric vehicles can be a very promising option for us to consider. For one, they localize those CO2 emissions to the source of that energy production. So when you couple that with more and more renewable energy coming online, we have a really powerful way to fight back against those CO2 emissions, but there are significant engineering challenges to doing this.

So if you compare a diesel tank and electric vehicle battery, there are clear advantages for the diesel tank. It provides much more energy capacity. It's much lighter and much smaller in volume. So we have to deal with these as designers for that battery electric vehicle to overcome those challenges.

So how do we say whether a vehicle is good or bad? Well, one thing we do is look at the vehicle-level targets from the government. So they will run different drive cycle analyses. For example, in the US, we'll look at city and highway drive cycles, and we also look at things like the World Harmonized Light Duty Vehicle Test Procedures, or WLTP. These are different ways to measure, if you have a target vehicle speed, how much energy is consumed over that distance traveled.

And then different places will then quantify that in different ways. For example, US uses these MPGE, or Miles Per Gallon Equivalent, as a way to say this electric vehicle, or hybrid electric vehicle, would consume approximately as much gasoline over the same distance traveled. So you also see, in other countries, they'll use a watt hour per kilometer or per 100k as a way to estimate these things. But one way or another, the vehicle program, they set some kind of targets. They say, here's what the fuel efficiency of this vehicle is that we're trying to get, and those requirements then get handed down to the subsystem teams to do the design work.

So there's different kinds of targets that come into play. So fuel economy is just one of them, and to test fuel economy, they'll use things like see here, the dynamometer and the chassis dyno rig. Where we run a vehicle, there's a target velocity that the driver has to meet.

There's a little window around it. They have to see if they can keep the vehicle speed within that target, and then they will measure how much fuel or energy was used over the course of that drive cycle. You can also do that kind of drive cycle analysis to estimate the range of that vehicle by seeing how much energy was consumed in the battery.

You can also test things like a Wide Open Throttle, or WOT, test to find out what's the 0 to 100 KPH, or 0 to 60 mile per hour acceleration performance on the vehicle, and there's also cost targets. So how many dollars per kilowatt hour would you estimate to use for that kind of battery? So different constraints, different targets that we have in mind, but we see more and more increased use of simulation in our customers, because they want to frontload that design. They really need to get as much of this design work done, before they have the prototypes accessible to them.

So the question then is, well, for simulations, what kind of models do you use to solve those problems? And it really depends on the task that you have at hand. So early in the design phase, you might want to use some very simple estimates, simple approximations to those models, with spreadsheets or 1D lookup tables, fast-running 1D models that they may neglect with thermal effects, spatial effects. They may have very simplified controls.

And as you move further along in the process, and you need to do more design-oriented tasks, then you may need the higher fidelity models that would come in with some of the multi-domain models. They run slower, but they give you the effects that you need to capture there. They include the spatial thermal effects. They can have more production-oriented controls in there. So it gives you a variety of tools at your disposal, depending on your needs.

Now, MathWorks offers a variety of solutions to help with these simulation challenges. When it comes to the step of creating the vehicle, we have different modeling templates we can provide. We have different libraries, different modeling guidelines to help you get a model started.

You may then also want to integrate in other pieces. So for example, you may have C or C++ code from your controllers. You may want to take a very high fidelity model and create a reduced order model, like a deep learning battery model to bring in that runs faster, or maybe integrate with a cosimulation using FMI, so different ways to use Simulink as an integration platform to pull these pieces together. Once you have the vehicle model, you have to do something with it. So we have tools to help you either run drive cycles, like we've talked about, or to have 3D environments with the RoadRunner tools to help you sketch out road networks and follow along through some kind of 3D environment.

You can run these simulations. Then, we have a lot of different tools to help you visualize them using 3D technology, using different mapping and data analysis, and report generation. Then lastly, you can run those simulations in other environments. So you could deploy it off to the cloud for large-scale simulation studies. You could run some HIL testing. We have a variety of ways to use those outside of the desktop environment.

But what's important is that MathWorks has been doing this for almost 40 years. We have proven tools for modeling both the physics and the software. We have reference applications to help you get started quickly, and we have a platform that you can reuse. It can scale up as you need, and it's a very flexible platform that will help the new use cases that you may need to grow into.

OK. So let's talk a little bit about the vehicle models we're going to use in this study. We mentioned at the beginning Powertrain Blockset that provides different options for you. So it has a library of blocks that you could use to build up your own vehicle model, but we also have pre-built reference applications, where we put together the plant and the controller into a closed loop system model for you out of the box. And we have a virtual Vehicle Composer app, which is a new addition, to help you create those models and configure and parameterized them.

In the MATLAB toolbar, you'll see the app menu. You can select, from the Automotive Tools, Virtual Vehicle Composer, and then this UI will open as a way for you to make high level selections. Like what kind of powertrain do you want? Do you want an EV, an HEV, a conventional? What kind of HEV?

You can make different choices for the fidelity of your components. You can specify different parameter values, like the vehicle mass, and create some kind of a parameterized, configurized model that you then add your scenarios to. Say which tests do you want to run, and then which variables do you want to log build your model? And at that point, it's just a Simulink model. So you can customize that model further, add your own components to it, and then generate any other tests that you need from it.

So this is a look at one of the vehicle models you can generate with the Virtual Vehicle Composer app. So on the top left, you have the Reference Generator. This is setting the target speed. It's saying, how fast should that car be going?

It also has an Environment Block, where you can set things like the ambient conditions. The driver model will then interpret those targets and say, OK, if you want me to go this fast, here's how much I need to press down the accelerator pedal or the brake pedal, or do I need to shift? And then those supervisory commands go to the controller, which says, OK, for that given acceleration command, how much do I need to set for the motor torque command or the engine command or both, if you have a hybrid?

And then the plant model will take those control inputs and will then step forward in time to calculate the vehicle response, so you can get the vehicle speed, fuel used, energy consumed, those kinds of things. And then lastly, we have a subsystem where we collect a lot of those signals back together, if you want to generate different plots and reports out of that. So in this first section, we just showed that the Virtual Vehicle Composer gives you a way to quickly configure and parameterized an EV model, closed-loop system model, and that model can be further customized, depending on your application.

So next, we're going to talk about the optimization study that we would like to perform. So we said in the beginning, we're going to first assess the vehicle. Then, we're going to do some optimization, before doing the design validation. I'm going to just walk through the first two portions of that now. Then, Danielle will talk about the last two.

So what is the problem statement? At a high level, what we're trying to do is say, I have a battery electric vehicle, and I want to have a good balance between range and price. So there are certain constraints. So you've got to stay within the window of that drive cycle we talked about, so you can actually meet the demand that the vehicle is trying to achieve.

And then you have to have at least an electric range that's reasonable. You can't say, well, give me the cheapest, smallest battery possible, but it can only go 10 kilometers. So you have to have a reasonable electric range.

You also have to have a reasonable acceleration, so that people would actually want to drive that car. And we'll be changing a few design variables in this study, we're going to change the number of cells in series and the number of cells in parallel in our battery model. And then we're also going to change the gearbox ratio, so we can do some kind of sizing there.

So in terms of a formal optimization problem statement, that objective becomes a weighted multi-objective function. So we have cost and range, and since we're minimizing them, we put a minus sign in front of the range. And so the weight one and weight two, those become like weights to say how important is cost relative to range? And you could create different trade-offs through a Pareto study.

For the constraints, we have a signal that tells us whether or not we actually stayed within the tolerance on the vehicle drive trace. So we say that that fault must be 0. We say the range has to be at least 400 kilometers, and the 0 to 100 KPH time can be no more than 7 seconds.

So we set those constraints, and then we also set simple bounds across the design variables, saying, how many cells can we afford, or do we want to consider for the cells in series and parallel? Those are integer values, and then what is the upper and lower bound on the gearbox ratio that we want to consider? That's a continuous variable. So in this case, we have what's called a mixed-integer problem.

So to do the initial assessment, we run the WLTP cycle, and you can see the speed trace there on top, in the SOC, and the battery in the middle. So we can then use this to say how much energy was consumed over the distance traveled? That becomes then an estimate of our range.

We also assume a certain dollar per kilowatt hour of the battery we designed, and we come up with a cost. We then run the wide-open throttle, or WOT, test in order to estimate that 0 to 100 KPH time, and we see that that's within tolerance, but the range is not. The range was lower than the 400 kilometer range that we had for our target. So the defaults in our EV model don't meet the system-level requirements. So we need to do a redesign.

So rather than going immediately to optimization, we first want to search the design space. So we start with a quick parameter sweep. We look through np, ns, and nd, and we get a sense of how are these impacting the targets that we have? We can see that the range is obviously good where the battery pack is big, in part because you have more capacity, but also because you have a higher voltage on the bus, and you have lower losses.

But you also see that the cost is much higher, when the battery is big. So you want to have a small battery to keep the cost down. So that's the trade-off that we have that we have to weigh between. And we also see there are some nonlinearity with things like the performance constraint. You can see that the diff ratio and even the size of the battery pack has a little bit of nonlinearity in that response.

So how do we solve these kinds of problems? Well, we can now use a formal optimization method to say, well, what is the exact trade-off we want between cost and range, while still staying feasible? We would start by picking some kind of initial design variables, and we would run through those simulations to say, OK, if we choose these values for these parameters, have we met our objectives, yes or no? And then we can iterate on those. We try different values for ns, np, and nd, and we keep iterating until we're satisfied that the optimization has converged on an optimal design.

So MATLAB can help you choose which optimization algorithm or which solver you would want to use for these kinds of problems, and it really depends on the form of the problem you have. So the design variable space could be continuous, like on the left here, or it could be a discrete or integer variable, where you can only choose the red dots, like on the one on the right. Or it could be mixed integer, like we have, with some of each, and those can lead to very different solutions. Different algorithms are better at solving those kinds than others.

You also need to consider, do you have just a single minimum, like the ones on the right, or do you have multiple minima, like the one on the left? And that's where you may want to switch between the Optimization Toolbox and the Global Optimization Toolbox to have a wider look at the search space. So we considered our options, knowing the problem statement we have, and decided that something called Surrogate Opt is a good choice for us, because it can solve these expensive nonlinear program problems quite efficiently.

So the idea of Surrogate Opt is it makes a surrogate model of your functions. So you start by sampling the space at a few points. Then, you create a model of your objective function and of your constraints.

And then the algorithm looks at that and says, well, where is the objective good? I'm going to add some more points around there. Where are the models uncertain? I'm going to add some more points there to make sure the models are more accurate. And it will keep iterating, adding more points as you go, until you reach the max number of function calls.

Now, this algorithm is really good for the problem we have. It allows us to build these cheap surrogates, if we want to use them off the shelf. It does a global search. As we saw from our parameter sweep, we probably only have one local minima. So I'm not worried about that, but it doesn't hurt.

But most importantly, it's a very efficient. It's good at solving this in very few function evaluations. And that's important, because for each of those points, we have to run the WLTP cycle, and we have to run the WOT test. It could take a few minutes to get those SIM results back, so you want to run as few of them as possible. So it's quite good at that, and it also allows us to work at continuous and integer variables and allows for nonlinear constraints.

So we can use things like Simulink Design Optimization as a way to set that problem statement up. You can say which are the continuous design variables, which are the discrete variables, and what are the values we want to choose for them? Then, we can also choose which algorithm we want to set for this. In our case, we chose the Surrogate Opt, or Surrogate Optimization.

And we can also play some tricks to speed up this result. So for example, on the bottom there, the original model just had a single drive cycle in it. When we added another drive cycle with a switch block that's controlled by a constant, what that allows us to do is use fast restart. So it can change the constant value to switch which drive cycle I'm running without recompiling the model. So that means you can run through iterations much more quickly.

And also on the top right, you can see use parallel pool during optimization. What that does is it can run multiple SIMs at the same time, on parallel cores or on an HPC, as a way to get you through these iterations much more efficiently. So now, we run these. We find we have the range on the bottom x-axis, where you've got to be to the right of that 400 kilometer space.

So the further to the right, the better. And then the cost, on the y-axis, we're further to the bottom, the better. And so you want to be down on the bottom left corner, but you can't be in that space where it's infeasible, where we're below a 400 kilometer range.

And you can see that Surrogate Opt does as we expect. It has a good cluster of points around a good solution, near that boundary point, but it also has a spread of solutions to increase the model accuracy throughout. But it's never quite getting exactly at that 400 kilometer range, because remember, we have integer values for those design variables. So it's difficult to find one that exactly hits 400 kilometers.

But we let this thing run for 300 function calls, and then at the end of the day, we see that, compared to the baseline, the optimal solution has found something that's pretty close to that 400 kilometer range. It's as low of a cost as we can get. So it balances that trade-off that we specified in here, meets our constraints, and keeps the cost down as much as it can.

So what we've shown here is the numbers themselves on the result are not important. It's more about the methodology, and we've shown that we have these formal optimization tools that allow you to iterate on the design parameters and find the solution to these conflicting objectives with constraints in mind. We've also shown how you can set up and automate the process using Simulink Design Optimization or other MATLAB scripts. So at this point, I'm going to hand it over to Danielle who will talk about how to use optimization study results to then start performing a more detailed design-oriented analysis on the battery system.

OK. Thank you, Mike. Hello. My name is Danielle Chu. I have been a product manager at MathWorks for two years. Prior to MathWorks, I worked at John Deere for seven years on power electronics control and control systems integration. And before John Deere, I did a half-year post-doctoral experience at the Florida State University, after getting my PhD at the University from South Carolina.

Today, I will be covering the battery design section. So Mike has shown how the Powertrain Blockset that and Simulink Design Optimization gives you the battery size information to achieve a good balance of range and price for an electric vehicle. What I am going to show is how, based on the battery size information from simulation results, how we can do an effective battery system design using Simscape Battery and validate the battery design by putting the back into the full vehicle simulation for final evaluation. I'm not going to show the details of the design or the design outcome. Instead, I will walk you through the design workflow and how Simscape Battery supports the design along the workflow.

The battery design study workflow has a five steps. Step one is to size battery pack within context of full system operation, which Mike just covered. Step two, easy to create lambda battery pack in Simscape Battery and demonstrate equivalence.

Step three is to design battery system in Simscape battery. It's therefore easy to select appropriate modal fidelity for full system evaluation. Finally, the last step is to evaluate battery design in full system.

The tool we use in the battery design is Simscape Battery. This slide is an overview of the value and capabilities of a Simscape Battery. It provides design tools to design and simulate battery and energy storage systems, including electrothermal cell behavior, battery pack design, and battery management system.

With the Simscape Battery, you can evaluate battery pack architectures or electrical and thermal requirements, verify robustness of discharge, charge, and thermal management algorithms, and validate the algorithms using hardware in the loop testing. Simscape Battery models integrated directly with the block diagrams in Simulink state machines in state flow and MATLAB functions, and you can simulate your entire system in a single environment. Because we have users using Simulink battery model, like the one in Powertrain Blockset, on the left, which is a lamba representation of a battery, before going to the details of battery design in Simscape Battery, we would like to demonstrate the equivalence of Simulink Battery model and the lambda battery pack model in Simscape Battery.

On the right, we took the parameterization from the Simulink Battery model on the left and use either to populate the battery module in Simscape Battery. It's very simple. We ran a unit test to demonstrate the two battery models are equivalent. We run a scenario with the Simulink Battery using the same current and temperature profile of the Simulink Battery model and run through the created lambda battery pack model test harness. The are two voltages are within a very small tolerance, which demonstrates equivalence and builds confidence that we are operating on the same battery characteristics.

We further demonstrated equivalence through system test. It shows how we connect the created lambda battery pack model in the system. We connected the two battery models to the full vehicle system and ran the two simulations side by side. Whether you are using Simulink Battery model or Simscape Battery lambda model, the results are almost the same in a demonstrated equivalence in a system contest.

The lambda model for the entire pack is just a single-cell model, as shown on the left. Now, we would like to demonstrate some real battery design work, the details of the battery design. With a Simscape Battery, we can create a battery pack with a higher resolution, depending on your design or simulation needs. For example, on the right, there are 96 individual panel assemblies using only one line of code in Simscape Battery. We needed the 96 parallel assemblies individually modeled, so we can conduct, still balancing among the parallel assemblies.

The MSCI battery provides passive cell balancing within. The cells within a parallel assembly will naturally balance. For each series connected parallel assembly, there is one cell balancing circuit. The response on the left is when you are not actively charging the battery, and every parallel assembly has a different state of charge.

The passive cell balancing strategy will bleed the energy, and each cell, we have the same state of charge and automatically match the lowest state of charge, as shown on the left. Of course, in practice, we are charging with a constant current, constant voltage charge cycle, as on the right. We start off from different state of charge, and as we start charging, we don't go over 100% of charge, so never no overcharging.

We can apply animation with the MATLAB to give us a further clarity, and that's what the animation is about. This is another way to look at the charging response with the constant current, constant voltage charge cycle. These are the 96 parallel assemblies, and it shows you the state of charge. So you can see, it's doing exactly what the simulation results on the left are showing. The passive cell band is the algorithm gives all the cells the same state of charge, until the first one has full charge, and once the first one has full charge, the rest of the parallel assemblies will started creeping up.

We talked about cell balancing. Let's move on to thermal management. In this example, we'll look at the cooling system. Simscape Battery has three different types of cooling plates available, as cooling, U-shaped cooling, and panel cooling.

Similar to a battery pack itself, you can change the simulation strategy of cooling plates to meet your model resolution needs. The top one is just a lambda model of a cooling plate, one single model. The bottom one is eight elements to model the cooling plate.

For initial design, it's very useful to only just use a lambda model to get an initial parameterization, but if you want to see the temperature gradients, you need to have a higher resolution. For example, we chose the parallel channel cooling in plates and did an 11-by-11 resolution and warranted along the x-axis. One cooling channel is on the left, three cooling channels is in the middle, and a five cooling channels is on the right.

We use the MATLAB Heatmap function to plot out a thermal response for different number of channel configurations. As you can see, the thermal response are quite different. You can certainly clearly tell that the one on the left is one channel, and the one on the right is the five channels. You can see the temperature gradients, and this kind of modeling allows you quantify the cooling effectively for different cooling architectures.

We can also look at the thermal response, if we reoriented the cooling channel along the y-axis. You can see the cooling going down, rather than across. Reorientation of the channels and the number of the channels are selected through appropriate parameters in the cooling plates.

Now, we have done the battery design, including cell balancing and thermal management. What's next then? The system engineers may ask a representation of battery system to evaluate in the full system. So we needed to select the appropriate model fidelity for full system evaluation.

For many scenarios, a lambda battery is sufficient for system integration. For example, you don't need cell balancing when you evaluate the energy efficiency and the drive cycle, but you do need to add a cooling system, since the energy kicks in. You may choose different fidelities as needed, when you incorporate a battery model into a system.

With the lambda battery model and lambda coding plate model, the full vehicle system is evaluated on a LLTP drive cycle. Without a miles per gallon of gasoline equivalent, a measurement of fuel efficiency for non-gasoline vehicles compared to no cooling, the miles per gallon equivalent decreases near the end of the cycle, as this is the most demanding stage of the cycle, and that's when the cooling activates. The examples that we presented is not a detailed, rigorous design. Instead, it shows the value and some capabilities of using Simscape Battery during the battery design workflow.

There are two takeaways. First, with the Simscape Battery, you can select appropriate modal fidelity to answer different engineering questions during the overall workflow exclusion. At an initial design, lambda model is sufficient. A detailed model is necessary, if we would like to answer detailed design questions, for example, the size of the cell-balancing circuit resistor, the details of the cooling system architectures.

The second takeaway is that the design information is effectively shared across different engineering teams. Whether you are system engineers, control engineers, or hardware design engineers, you have all the design parameters that you need for your work. Mike will take over to tell where to go for more information as a next step.

OK. Thank you, Danielle. So let's get you some more information. Training, so one way that MathWorks can help increase your productivity is by helping you to use the tools more effectively. We have a variety of training courses available. There are free on ramps for things like optimization and Simscape, as well as paid training services to go more in-depth on these products.

We also have automotive-specific training for things like Simulink fundamentals for automotive. We even have a battery modeling and algorithm development specific training course, as well as jumpstart training for Powertrain Blockset. If you have the PDF of these slides, you'll be able to click on those links, and you'll get more information there.

The consulting services is another way that MathWorks can help our customers to achieve the specific results that they're looking for. We can provide expert guidance. We can provide automation of different workflows. We can help develop custom UIs. There's many ways in which our consulting team can help. Say, if you don't have the right resources, the right skills, or the right people to help with particular projects, MathWorks services can help you to do that.

And then lastly, there are additional resources you may be interested in. We have some links here that you can check out for electric vehicle development, virtual vehicle, and even some upskilling for those that are transitioning into an EV-oriented role. And lastly, we have some product highlights that we've talked about in this presentation. You can click on the links to get more information about those products.

So hopefully, over the course of this presentation, you got a sense of how MathWork's tools can be used for this continuous workflow, through the assessment, the optimization, the design, and the validation stages of the work. We thank you very much for your time and interest today, and we look forward to continuing that conversation. Thank you.