Optimising the Energy Efficiency of Electric Vehicles with Simulink and Simscape

So hello. Welcome. Good morning. My name is Victoria Rothwell. I am the Group Lead for Energy Attributes here at Polestar UK. And this is my colleague, Andrew Curtis. He's a Senior Engineer looking at thermal and energy simulations. And Andrew is leading the development of our new Simscape and Simulink-based simulation platform called Pandora, which is what we're here to talk to you about today. I'm just going to give you a quick introduction to Polestar, and then I'll hand over to Andrew, who will tell you a bit more about Pandora.

So who are Polestar? We are a progressive Swedish electric performance brand making electric vehicles. We're a very small company compared to traditional manufacturers. But we have the backing of two very large businesses in Volvo and Geely group.

We run as a startup, which means we can move quickly. We can adapt. We can change direction. And we can work in sometimes unconventional ways. Our purpose is to improve the society that we live in by accelerating the shift to sustainable mobility.

Polestar is based on three pillars-- sustainability, design, and technology. We are design-led. We produce cars that look different to the norm, not just another shapeless electric vehicle. We integrate and develop innovative technology, new features, new hardware. We partner with new and exciting businesses to bring sustainable technology to the mass market. We strive for sustainability in everything that we do as we design towards zero and towards true climate neutrality in the coming years.

Now, sustainability in the use case of a vehicle, when the customer actually gets the product, is delivered by giving them real-world efficiency. And the only way that we can deliver that is by using simulation tools early on in the development process to embed efficiency in everything that we do. We believe that electric car technology can and does deliver an amazing driving experience.

You have high-output electric motors with instant torque, large-capacity batteries with efficient designs, both for power and for range, and smart packaging and integration on specifically designed EV platforms. All of that is only delivered by using detailed component simulations and whole-vehicle simulations in all sorts of different environments. And that's what we've developed Pandora to do.

A little bit about our future-- you may have seen in the news recently we've announced our intention to produce the Polestar 0. That's a vehicle with zero greenhouse emissions by 2030, without offsetting. And that goes from the extraction of raw materials through supply chain, transportation, manufacturing, all the way through to end-of-life recycling.

And obviously, this is a huge task. We can't do this alone. We're currently in the research phase. We're working with partners, universities, and suppliers to develop new supply chains, new materials, and new technologies to help us achieve this.

At Polestar, we have big dreams. And just one of the tools that we've developed to help us achieve these dreams is Pandora. We began life with an inherited simulation tool which had a number of limitations. So we decided to develop our own new platform.

Over the past just nine months, Andrew and a small group of part-time supporting engineers have built a brand new, ground-up, holistic, whole-vehicle simulation platform. Pandora is now in use at Polestar to run quick high-level simulations, to run detailed studies, including thermal systems and complex component analysis. And this is only the start of what we want Pandora to do. So I'm now going to hand over to Andrew to tell us a little bit more about Pandora and its development.

Thanks, Victoria. So now you've got a bit more of an understanding about who Polestar are and what our aims and goals are. It's time to talk a bit about how we use simulation in our vehicle development. So we use simulation in every part of our vehicle design process. Here's just a snapshot of some of the simulations that go on every day at Polestar.

We have aerodynamicists performing 3D CFD on our vehicle bodies, making sure the design is efficient and the correct cooling performance to meet our vehicle needs. We have our structural teams performing finite element analysis on our vehicle structures, making sure the designs are as strong and as safe as they need to be. And we have our propulsion teams performing multiphysics simulations on the batteries and electric motors, making sure that the designs are as efficient and have the performance needed to meet our vehicle targets.

The reason we use so much CAE is to follow the processes of data-driven design. Data-driven design means using quantitative data to make our design decisions. This gives our engineers much more freedom to pursue out-of-the-box solutions. They don't need to be constrained by what's come before. They can use virtual testing and simulation to evaluate new design concepts long before we'd ever have hardware available.

This means we can massively speed up our design and development processes. Not having to rely on traditional design, prototype, manufacture, test before we understand how our systems work, we can use simulation and virtual testing to really understand how our systems are going to work long before we'd ever have hardware available.

This is especially important in the world of battery electric vehicle design. With battery electric vehicles, the integration and level of complexity in our systems has increased exponentially. So to truly understand this, we need detailed system-level simulation to understand what's going on. And this is where one-dimensional, or 1D, simulation really comes in. So 1D simulation is the art of simplifying components down to their base equations, allowing us to run really fast simplified component models and string those together to model the behavior of entire systems.

So this has three main application areas in vehicle development. Firstly, by modeling the behavior of systems, we can understand how the behavior of a single component affects all the components in that system. Instead of just focusing heavily on the design of that single component, we can understand how its behavior and performance will affect all the other components in that system.

And this leads us on to design optimization. By having fast-running system-level models, we can simulate and develop the performance of the vehicle over a wide range of operating conditions by performing large-scale design-of-experiment simulations or case-parameter sweeps. As you can imagine, the performance of a vehicle is very different compared to if it's doing a top-speed run at a hot ambient, if it's trying to heat the cabin from subzero, or doing its optimal fast charge. But those system-level models allow us to understand the performance in all those operating conditions.

And then, finally, for our control systems, having fast-running system-level models allows us to design and develop our control systems alongside the plant models. This gives us a great advantage in terms of software development. We can start designing and testing our software long before any vehicle hardware would ever be available. By running software in the loop simulations, this means we can maximize the design time available for our control systems, allowing us to achieve the best of our hardware performance by optimizing the software.

So at Polestar, we realized we needed a simulation platform that would model all the effects going on in the vehicle so we could really understand the behavior of all our systems. So we set out on a project to create that platform. And that project had a seemingly simple goal-- develop a simulation platform to model electric vehicle performance. I mean, how hard could that be?

But it means not just modeling the systems within the vehicle-- so the mechanical systems, modeling the driveline, the wheels, and tires; the thermal systems, so we can understand our cooling performance and what effect the temperature of components has on their performance; and then the electrical systems, not just the design of the battery and motors, but also the ancillary losses and what effect they have on the vehicle's range.

And the key thing, really, is not just modeling these systems in isolation, but modeling the interaction between these different systems. This means we can have the best understanding of the vehicle performance over all its operating conditions, both from our design perspective and also allowing us to be as transparent as possible with our customers about their vehicle range and performance.

And the platform we created is called Pandora. So the first part of the Pandora project was really determining the requirements. We needed to understand what it was we wanted to do, both in terms of the modeling requirements and then the functional requirements.

So to look at our modeling requirements, we need to understand how we were going to use those simulations in our design process and how we were going to use that data. So we needed to model the vehicle energy consumption and performance, allowing us to assess the vehicle's range, its acceleration, and its top speed. But we also needed more detailed models of the thermal systems, allowing us to evaluate cooling performance and then the effect that has on the rest of the vehicle.

This is also true for the powertrain systems, where we needed to understand both the energy efficiency of the powertrain systems, but also aid the design of those detailed systems. And then, finally, from a controls perspective, we needed to be able to model the control systems not just within the platform, but actually bringing in the real control models from our controls team to make sure our understanding and the development of the control systems is as accurate as possible.

So then, in terms of functional requirements, so as Victoria mentioned, Pandora has been developed by a group of engineers working not just across different teams, across different countries. That means we need a single repository that can be accessed and worked on by multiple users at the same time, along with a model traceability and version control to make that all work smoothly and seamlessly.

So once we had our requirements, the next challenge was what platform were we going to develop the system in. So we evaluated several different simulation platforms and determined that Simulink and Simscape met our requirements best. So in terms of Simscape, we have a physical modeling domain, allowing us to model large-scale energy networks and energy flows, simulating the energies across the entire vehicle. We also had the specialist vehicle component library, giving us a great head start on modeling systems like our wheels and tires and driveline.

And then, from the Simulink perspective, we have a suite of data analysis tools at our fingertips, both from a modeling perspective and then a post-processing and data analysis perspective. We also had the source control integration and integration with our current control systems to make the modeling of those as seamless and as smooth as possible.

So one of the main challenges we faced with the development of Pandora was understanding what level of detail to model our plant models at. And I think that's a challenge seen across all of 1D simulation, really, with the objective of 1D simulation being to get the level of accuracy and the detail needed from your results in the most efficient way possible because once you've got the level of detail you need, any other complexity in your plant models is simply wasted resources, both in terms of the runtime of the models, but also the engineering time needed to create, maintain, and develop those models.

If we consider the example of an electric motor, as shown here, if we're modeling the thermal systems in a vehicle, all the information we really need from the electric motor plant is how much heat it's rejecting and what its coolant pressure drop is. Anything else is simply just extra detail that's not helping us. But if we want to model the performance of the vehicle, we need a bit more detail from the plant model. We need to understand its torque and speed properties alongside its mechanical properties, like its inertia.

But then, if we want to consider the vehicle range, we need another level of detail from our plant models, again. We need to understand how the plant model converts between electrical and mechanical energy. So we need to know the efficiencies alongside any other losses in the system, such as mechanical losses from the bearings.

And then, if we want to use our simulations for motor design, we needed another level of detail as well. We need to start modeling the motor in terms of its internal components, understanding the electrical and thermal behavior going on within the motor itself. So as you can see, the level of detail we need from a plant model is highly dependent on what we're actually using the simulation for.

And within Pandora, we handle this using variant subsystems. So for each component, we have a selection of different subsystems and variant models available, depending on what simulation the user is performing and what level of accuracy they need. And the user can swap between different plant models depending on their needs.

So continuing with the electric motor, as you can see here, we have a plant model or a subsystem for the electric motor within our vehicle concept. So the vehicle concept describes the architecture of the vehicle. And in those individual subsystems, you can see we have different variants available depending on what the user needs.

So here we can see three different examples of how we'd model an electric motor-- in the first case, the top, just a very simple Simscape motor and drive component, allowing us to understand the electrical and the mechanical performance of the motor. But if we wanted to model the inverter and the motor losses separately, we have a separate plant available for that, with an additional component allowing us to model the inverter separately to the motor itself.

And then, if we want to bring in thermal aspects, we have another plant model available. As you can see, it's still got the motor and drive component and the inverter, but now with an additional thermal port. And the user can switch between these different components or these different plant models depending on what level of accuracy and what runtime they need from their simulations.

This has the added advantage that these plant models can be worked on separately from the main vehicle concept. And it allows us to bring in the expertise from our different subsystems. In this case, the motor design team can have proper input to how their motor simulation model is running without having to worry about the rest of the vehicle.

This is incredibly important when we consider the sheer amount of inputs and data that need to go into a single vehicle simulation. So this is an example of just some of the teams we'll interact with on a daily basis performing vehicle simulations. We've got component design teams, such as the battery and the electric drive. They'll give us data in the forms of loss maps or internal resistances for their components.

And then we have attribute teams, such as the vehicle dynamics or aerodynamics. They perform their own large-scale suites of simulations and testing that get fed back into Pandora through values such as our drag coefficients and rolling resistance coefficients. And then we have teams such as our homologation teams, working on how the vehicle is going to be certified so we can make sure our certification simulations are as accurate and match reality as best as possible.

And this level of flexibility means we can really build Pandora simulations into every part of our vehicle development process. So that's shown here with our systems engineering V diagram. At the start, in our definition phase, we'll be running large-scale design-of-experiment tests with simplified vehicle models, looking at what level of efficiency and what technology we need to achieve our design targets.

Then, as the design of the vehicle evolves, so too do our simulations. As the CAD gets developed, as the vehicle gets designed, our simulation complexity develops as well, and we can start using Pandora for design trade-offs, concept evaluation, and design development. As we move from definition to implementation, we'll start getting physical hardware and component prototypes that we can use to correlate our simulation models and verify the performance of our initial simulations. This gives us great verification of how our simulations work and any design changes we need to make based on the actual performance of the hardware.

As we move through implementation, we'll move from just single-prototype correlation to system-level correlation to whole-vehicle correlation. And all that correlation and information gets fed back into the Pandora platform, allowing us to develop and increase the accuracy of our simulations as we move through the design process. And of course, all the learning that we're getting from our current Polestar projects gets fed back into Pandora to the benefit of our future vehicle projects.

So now I've talked a bit about how we've developed Pandora, it's time to show how we use it in action. So at Polestar, we're always looking to increase both the efficiency and the performance of our vehicles to give our customers the best vehicle possible. So a common scenario we'll come across in our day-to-day work is evaluating the effect of a design change on the vehicle performance. And the component that we're going to be investigating today is the tires.

So we all like kind of nice, grippy tires to keep us on the road in tight corners. But those tires count for a significant portion of the vehicle's energy consumption. That grip, or friction, between the tire compound and the road results in a load that the vehicle motors have to overcome to drive the vehicle forward. And that grip, that friction, is the enemy of energy efficiency.

So here, we're using Pandora to investigate the effect of reducing the rolling resistance of a tire on the vehicle's performance. So we've simulated a battery electric vehicle over the Worldwide Harmonized Light Vehicle Test Cycle, or WLTC cycle. So this is a standard drive cycle used to range certification in Europe. It drives the vehicle through rural, urban, and motorway settings to give us a great understanding of on-the-road vehicle performance.

And within the WLTC cycle, tires are divided into classes based on their energy efficiency. So we've investigated the effect of changing from a class 3 tire with a rolling resistance 8.4 kilograms per tonne to a class 2 tire with a rolling resistance of 7.1 kilograms per tonne. And within Pandora, we model this using our tire plant.

Here you can see broken up into its base components, all built in Simscape, using friction for the bearings, a wheel plant to give us our geometry and slip performance, and then our rolling resistance plant, allowing us to model with both a constant rolling resistance, which we'd use early on in the project, or as we develop our tires, we can start to parameterize that rolling resistance based on more detailed performance, such as the vehicle speed and tire pressure. And we developed those models alongside our vehicle attributes team and our tire suppliers.

So here we can see the effect of that design change in a Pandora simulation. So we've evaluated the changing from a class 3 tire to a class 2 tire. And you can see what the effect of that is in both the tire rolling resistance, in the top graph, and the battery state of charge, in the bottom graph.

So we can see making that design change, reducing the rolling resistance, has reduced the rolling resistance force in the tire by 15%. Over a drive cycle, this has meant we've used 0.2% less energy. And if this design change was applied to a Polestar 2, based on its current certified range, it would increase that range by over 13 kilometers. And that would be passed directly as a range increase to the customer.

But of course, this isn't the end of the system or the end of the question, because this reduction in motor demand is also a benefit to the thermal system. So at this point, we'd look into our complex thermal system models, being able to evaluate what the effect of using the-- or that reduction in motor demand has on our cooling performance. If we need to use the thermal system less, then we have less ancillary losses, giving us an additional range benefit, potentially, from this design change.

And of course, this design change also needs to be balanced with other attribute performance. So at this stage, we'd bring in expertise from our vehicle dynamics and NBH teams so they could assess the design change on their vehicle area as well because, of course, the design change is never just a benefit to one area. There are design trade-offs throughout all our vehicle. But using Pandora, we can really have the quantity of data we need to make that design decision.

So in summary, at Polestar, we've developed the Pandora simulation platform from a vehicle template from MATLAB in just nine months to revolutionize our vehicle simulation capability. Every day, we're using Pandora simulations for vehicle range analysis, system design studies, software-in-the-loop testing, and our research and development projects. And at Polestar, we'll keep pushing the boundaries of CAE, adding more functionality and correlation into the Pandora system.

So I hope you found that insightful. And thank you for your time today.

[APPLAUSE]