Thermal Management System Design for Battery-Electric Vehicles

Hello everybody.

I will now speak on the topic of thermal management system design for battery electric vehicles. Does everybody hear

electric vehicles. Does everybody hear me? Okay.

me? Okay.

Yes, we can hear you Martin. Thank you.

Thank you very much.

I can start with saying that in essence all models are wrong. There's no perfect model. There's no model detailed enough

model. There's no model detailed enough that it captures everything in reality.

And on the other hand, some are useful uh as George box said in 1979.

Um, and this is not all bad because a simple model uh purposely built not to contain

everything is often more than its accuracy and and level of detail is often more than enough.

And it often beats [snorts] a very detailed and complex model, not least when you're debugging it. Because trying to

debugging it. Because trying to calibrate it to data, you will find yourself with the huge model will take days and weeks to calibrate. Whereas a

simple model will not reach the same level of accuracy, but it's much more nimble, it's faster, and you can work it

more. uh and I'll come back to that.

more. uh and I'll come back to that.

So why does this even matter?

Well, [snorts] I work with thermal systems for battery electric vehicles uh of vehicles of the

larger kind. Uh but this is applicable

larger kind. Uh but this is applicable to most vehicles that have a thermal system or even you can extend it to any thermal system or actually any system.

Uh but I focus on the thermal kind. Uh

also for maybe a building or a vehicle that's not running on on the ground.

This could be for aircraft, thermal systems, ships, what have you. Doesn't

really matter.

Um modern systems include for battery electric vehicles often include heat pumps to save on battery energy.

uh we want to recycle residual heat uh from various components. For example,

the drivetrain contains a lot of heat that we can reuse on a cold day to um to heat the cab uh the cabin uh via the

heat pump. So these systems function in

heat pump. So these systems function in a multitude of modes depending on if it's hot outside, if it's moderate hot,

very hot, cold, super cold around this freezing point and what do I do with my vehicle? Do I uh do I have a heavy load?

vehicle? Do I uh do I have a heavy load?

I'm driving uphill, downhill, so on. So

they have to do a lot of things.

And as such, they contain a lot of stuff. Uh for example, the system I'm

stuff. Uh for example, the system I'm just working on has seven valves, four pumps, one electrical fan, one heat pump, one electrical heater, and the

different combinations of settings for all these components which are 14 in this example.

There are so many you see a small sample on the screen just to show you that this is a lot. Um

we um we really can't do everything like manually.

Uh we we can't control the system manually. So how do we decide when when

manually. So how do we decide when when to use what settings and how were things ever going to be optimal or optimally operated uh to preserve as much energy

in in our in our uh battery system as possible?

Well, it's it's no mean feat because even though it's a simple we we we we we pump around uh coolant uh glycol and water combination in in in in hoses and

pipes using standard turb machinery pumps the combinations the number of the sheer number of combinations in these systems for it for their operation it's

enormous.

So, we have some examples on the screen which I uh happily stole from the from the internet because if they're public on the internet, I could share them. I

thought you have the references there.

Here's the Tesla Model 3. This is

something from the Sheffra group automotive subsuplier on the screen. And

this is from a paper. Uh you can see it here if you're interested in it. Uh I

didn't read the paper. I just nicked the picture. Uh but you can see here that we

picture. Uh but you can see here that we have um an HVAC unit with a positive temperature coefficient electric heater.

We have a blower, we have valves, we have pumps, we have high voltage batteries, we have um the power train, we have

another pump, we have a chiller, fan. There's a lot of stuff and how to

fan. There's a lot of stuff and how to operate these simultaneously, it's a huge question.

So what to do? Well, if you look at all these details at once, you quickly become very lost very quickly.

Uh one solution is to segment the model buildup meaning um you have different levels of details in your model for different

project tasks or phases meaning oh I don't build a model of this particular thermal system for this particular vehicle I build a family of models which I use and I use different members of

these family for different task usually the simpler models early when you have more concepts to to develop Uh another complimentary approach is also to work with large experiment

matrices. Meaning I use my model

matrices. Meaning I use my model simplicity and speed to my advantage and then I spiral back. So meaning instead of as management theory always goes is

that our development is linear and then you you start with a wide range here wide scope and then you go on here.

Actually you do spiral back a lot. You defi you define your things. You you you design it, you test it virtually or in a test

rig, then you go on take your feedback, you define it again and so you spiral back and you see that you actually move backwards in some respects.

So there is one there is one logical line going this way in in in that in that logic or in that space you actually move backwards but at the same time you move forward along the spiral which is

in another dimension if you want. So you

actually move forward along these lines but in in some respects you actually go back. So you can back from all my more

back. So you can back from all my more detailed models. Oh, I have to go back

detailed models. Oh, I have to go back because my test show me I have to redefine and then I move along and then I test again and see now you move further along according to both dimensions. So this is how I like to

dimensions. So this is how I like to think that it's no it's no disaster or it's no not a bad thing to actually move backwards in your simulation hierarchy.

Uh so how we did we do it? Well, we

created two new fluid libraries because I work with thermal systems. It's a lot of fluids. uh coolant liquid and air uh

of fluids. uh coolant liquid and air uh incompressible air incompressible air in this case. So we don't have to do any

this case. So we don't have to do any fancy stuff for incompressible or for compressible flow high mac number flu.

We created two libraries. We decided to call them thermofluid and flow. The

names are almost arbitrary. We created

them from scratch. Uh we had a new interface definition. We created new

interface definition. We created new media models based on the structure that we wanted. I will show you some

we wanted. I will show you some examples. Uh we created a full set of

examples. Uh we created a full set of components. Uh

components. Uh and as a design principle for these libraries, we use limited extends in modality. You can extend forever if you

modality. You can extend forever if you want, but we'd have limited extends and we don't use very many partial models, which goes contrary to the to the

software engineers thing that you should reuse and make maintenance easy and bug fixes only in one place and so on. We

since not everybody will be expert users we created these models from the perspective of ease of understanding and ease of reviewing rather than so so

if we introduce a bug it's possible you this approach it will actually be multiple places but most of the code is very similar in each component so it should be easy to find

but we do that because having an overview of almost the complete model at once actually also helps uh debugging and uh

introduction to model ease of understanding introduction to this library. So that's why we chose that uh

library. So that's why we chose that uh as a guiding principle when we wrote the library. We created everything you see

library. We created everything you see on screen we created uh components for and we created icons and everything from scratch.

So the connector we did in the flow library, the thermofluid I will not show because it's almost duplicate. Uh the

difference between the two libraries if I move back is that this deals with energy balances, heat heat flows and

energy flows but does not do any hydraulic calculations. If you're interested in

calculations. If you're interested in pressure drop and flow balances and stuff, you will have to use this in this library which is used for conceptual development. you will have to in each

development. you will have to in each branch of the system define your flow volume flow or mass flow it's your choice explicitly so I use this a lot

for concept development but then when I design my system I go to this one I will come back to this eventually so we uh had a fluid port you have to

have a flow variable uh we chose mass flow we have a uh potential variable pressure is an obvious choice in in fluid fluid

systems we have two stream variables. We

used enthalpy and we use a mass fraction X. Uh but in all practicality you can

X. Uh but in all practicality you can use X. X can be almost whatever uh

use X. X can be almost whatever uh depending on how you write your your um uh your your media model.

Uh the media model is uh written according to the uh this principle. We

created first a template uh and all uh functions are are have a name like property underscore and these are the input variables and for this for the flow library we take pressure

temperature and and and the variable x as input if we use them or not that's really not the question here we that's what each function needs to fun uh to

work and then uh we create a template and then uh we extend that template and for liquids we typically be populated directly with equations for the fluid

properties. In our case, uh different

properties. In our case, uh different versions of ethylene glycol. Um some of them are hard have a doesn't use X because they're hardcoded for certain

certain glycol concentrations. Some have

X as a um as an input. Uh and then you can vary uh very easily without changing the media. You can sh the glycol

the media. You can sh the glycol concentration. For idle gases, we did

concentration. For idle gases, we did little different approach because a lot of gases have you can use the same set of state equations and just change uh the coefficients.

For example, when you define viscosity, you use Southerntherland's law and they have the same type of coefficients regardless of the um

of uh of the gas if it's nitrogen or air or hydrogen for example. Same thing with uh if you use a variable CP you can use the NASA Glen coefficient

uh often called the Burkat Berkeley coefficients or polomials. Uh you can download a set of those uh for many different gases from from the web and and implement that. So that's how we did

it for gases. It's just more practical uh because those libraries are already there doesn't really exist for for different coolants. So there we

different coolants. So there we implement them directly.

Uh then we build a conceptual model. Uh

this the example shown here is not really it's a lot simplified from uh what we would have in a vehicle because here we have a radiator uh in the simplified uh thermofluid

library which is yellow. I call it the yellow library. Uh we don't have a

yellow library. Uh we don't have a pressure drop or anything. So we don't have fan to drive the flow through radiator. So that's explicitly input. We

radiator. So that's explicitly input. We

have a subcircuit here for something we can say it's it's the battery. uh have a heat pump or a refrigeration system with a refrigerant um not modeled. We model

we model its behavior not its internals.

Uh then we have um uh two um two branches of um coolant going to the drivetrain to my little drivetrain model. Uh one for the gearbox and one

model. Uh one for the gearbox and one for the uh the motor uh inverter combination. And then this little

combination. And then this little drivetrain pushes on our our vehicle model and then some controls into that.

And then yeah we can drive this. We can

define a drive profile here. So we can drive from E to B as it happens. I will

show you some results later.

Uh so this is the library where I mentioned we have energy balances and heat flow only. Uh we will have to you can see here I I put in my in this my my pump I'm going I actually put in

explicitly what my mass flow should be and also in the subcircuit here. uh and

then I explicitly define in this I use a valve icon but it's actually a flow splitter telling 7 uh the fraction 7 of of this flow here goes in this branch

and then 30% it goes here I explicitly define that in this library oh what happened okay back again not sure what happened

there Um so I use typically use this library in this type of detail in models to evaluate many many concepts and this can

be used to [snorts] create the first conceptual design of a control system.

Uh this conceptual model I ran in the um in a drive cycle because I have a drivetrain and a vehicle model. So I can evaluate in the drive cycle. Uh it does require that I first created a

conceptual control system because otherwise my thermal system won't work without the control system.

It'll work in in in manual mode or steady state modes only.

So before we actually do the drive cycle, we create a large test matrix matrix with thousands of points and then we do something called a system characterization.

Uh or I create data and hand it over to my my control system team members uh who use that to perform a system characterization uh often using Simolink

as tools for this. Modelica and then from that they define a control system uh they define the system from the control system point of view or we decide to do a hybrid approach and maybe

use this data to train an ML algorithm.

uh we did show in an advanced engineering program last year together with with Wolffront that it was possible actually to train with using data from these models exclusively to train an ML

without any different control functions just an ML algorithm a neural net created in Mathematica to control one of these systems uh over 4hour drive cycle in various uh for

various times of the year meaning different ambient temperatures and then once we've done that uh we model the system again using the other library the flow library which I where I

showed you the connector and the media model and we include hydraulics. So this

allows us to actually design the hydraulic circuit. Uh we can select

hydraulic circuit. Uh we can select component. We can use this as a guide in

component. We can use this as a guide in selecting components. Uh pumps, fans, we

selecting components. Uh pumps, fans, we can size the heat pump, uh hose and pipe diameters and lengths.

Um yeah, we design the system hydraulically and at the same time we continue with the next step in the control system development because at this stage we add more functionality, we

add more detail. So the control system designs need to be fine-tuned.

Uh once we have rig testing meaning data from the real world can be scary but we use that data to calibrate these models to see that our pressure losses and flow

balances are correct, our thermal masses are adequ ad adequately uh represented and then we can uh calibrate the control

system again. And the reason we do that

system again. And the reason we do that in steps is that typically historically you would design your system then you would design your control system as a side activity. These come together first

side activity. These come together first time in the vehicle and then you spend months calibrating and fixing things uh on the software in the vehicle which is

very expensive and also not very practical because you only have the vehicle very late in the development process. So now we can do it way before

process. So now we can do it way before years before we actually have a vehicle to find bugs and things we haven't thought of which we always do uh early.

So to wrap things up to provide a couple of minutes for questions no model is perfect. Uh so we utilize a stepwise approach uh a tiered approach

if you want or we add detail as we go along and as we go back and forth. You

can see there's a pendulum or as a spiral in my view to first to down select concepts. We run huge DE tens of

select concepts. We run huge DE tens of thousands of of cases. Uh we haven't really gotten to the tens of thousands yet, but maybe a thousand. It's where we got so far. We're developing a new

workflow as well to do system characterization, train algorithms or something else.

And we add detail as we go. And then we start all over.

Thank you very much.