Electrical System Design Exploration for Electric Vehicles

Hello, everyone, and welcome to this webinar on electrical system design exploration for electric vehicles. My name is Graham Dudgeon. And I would like to acknowledge the support of my colleague Jason Rodgers, who is a senior application engineer focused on supporting our customers in the automotive industry. Here's our agenda for today. Let's start with some key takeaways, and then we'll move through a number of design stages before performing final evaluation on the full system model.

Virtual vehicle design and evaluation are enabled by MathWorks tools. Today, we're going to work through our methodology for modeling subsystem level fuel cell systems, where we're going to build out fidelity and complexity incrementally, align model fidelity with specific design tasks, and minimize the time taken to perform design iterations. And we'll utilize first principle and data driven statistical approaches for appropriate tasks.

Electrification is a trending topic for the transportation sector. From the smallest e-scooters to the largest railway trains, engineers are looking for ways to electrify their systems. One topic of concern for some OEMs is how to meet the high power demands of heavy duty vehicles using electrical technology.

Our problem statement for today is how to efficiently explore the design space for a multi-stack fuel cell vehicle with an emphasis on providing efficient power response by providing a framework upon which we can incrementally creep towards a solution and build our confidence that the system is doing exactly what we designed it to do.

As we move through the design stages, we're going to align model fidelity with the design task, in order to make our design iterations and design space exploration as efficient as possible. In stage one, we are focused on the system architecture, system level voltage and current levels, meeting our electrical load, and also the interactions between our electrical sources. At this stage, we can use ideal voltage sources, basic power share algorithms, and average value power converters.

In stage two, we consider the design of an optimized power share algorithm and test the algorithm and stylized efficiency curves within the context of the full system architecture. In stage three, we incorporate reduced order models, or ROMs, over fuel cells, in order to capture acceptable accuracy of the electrical and thermal response while allowing us to run rapid system level simulations.

In stage four, we evaluate the electrical system response using detailed fuel cell models. The detailed fuel cell model takes longer to run, and so is not efficient for design space exploration or design iterations, but is a necessary part of our overall evaluation to build confidence that our design is operating as expected.

Stage five is where we evaluate the integration of the electrical system with the fuel vehicle. There is technically another state where we need to determine the motor loading requirements from which we get high level information on power generation sizing and battery sizing.

To determine motor loading requirements for this use case, we use the same multimodal as used in the fuel cell electric vehicle reference application in the Powertrain Blockset. We prerun the fuel cell electric vehicle reference application and we measure motor torque and motor RPM, which is derived from the full system simulation of an FTP-75 drive cycle. We don't need the full vehicle system model for electrical system design work, as we're interested only in what the electrical system sees. And we also want to perform rapid design iterations.

Before I move to the electrical system design task, let me show you the fuel cell electric vehicle reference application in the Powertrain Blockset. So here is the fuel cell electric vehicle reference application. Let's explore the model a little bit. I'm going to look sideways, so I can see my screen a little bit more clearly.

So we're going to look specifically under the passenger car system. Go to the electrical plant. And here we can see we have a basic fuel cell battery configuration already implemented in the fuel vehicle simulation. So we run this simulation. And from this, we get motor speed and motor torque for the FTP-75 drive cycle. And it's this data we then take and use in our electrical system design task. There are other reference applications within the Powertrain Blockset. Please, feel free to explore those reference applications in the documentation.

Here's the generated and regenerated power requirements on the motor for the FTP-75 drive cycle. Maximum generated power is around 35 kilowatts. The maximum regenerative power is around 28 kilowatts. These numbers will ultimately inform power rating of the power generation and battery systems. And here's the generated and regenerated energy of the motor. Regenerated energy informs the capacity of the battery.

In stage one of our electrical system design task, we want to look at how we form the voltage on the system. That means, what is the primary mechanism for controlling voltage and will a particular source be responsible for voltage control?

In this case, we're going to explore the following architecture. The fuel cells will be connected in parallel and will be under voltage droop, meaning we can control system voltage from the fuel cells and provide precise power sharing ratios. The battery will be under power control, meaning we will monitor system power demands and request power reference set points from the battery.

In this case, we want the battery to absorb all regenerated power and provide the peak lopping function, whereby the battery will provide power to supplement the fuel cell power, if a certain power demand is exceeded on the motor. We assume motor voltage is 500 volts in this case, although we can, of course, change component and system ratings as part of a design exploration exercise.

We'll now take a deeper look at the stage one model. So first of all, we'll look at the motor. And so here we have our motor and drive system level. It's an abstracted level, which can capture suitably the fidelity we need for the system level simulation. And you can see here I'm feeding a motor RPM and motor torque, which were derived from the full system simulation.

The battery in this case is just an ideal voltage source behind a resistor. This is all we need at this stage because what we are looking to do is rapidly evaluate the architecture and determine whether we can meet motor loading requirements with reasonable power response from our sources.

So likewise, if I double click on fuel cell 1, it's an ideal voltage source behind internal resistance. Fuel cell 2 is the same. Now, let's look at the converters and control. So for the battery-- First of all, our converters are average value, meaning they do an ideal conversion between DC and AC. So there is no power electronic switching. This level of fidelity is very valuable for system level simulation as we don't need to use the small timesteps we would need if we implemented full power electronic switching into our simulation.

We have a duty cycle controller here, which is keying off battery power. And the operational mode is we will consume all regenerated power from the motor. And if motor power demand exceeds some nominal maximum value from the fuel cells, we will then supplement that power with power from the battery. So a very basic structure for the battery in this case. For the fuel cell, average value power converter.

And I have implemented droop control. So we compared our reference voltage with the motor voltage, and then we droop that reference by a droop value, droop 1 multiplied by the current and scaled appropriately for the scaling of the system.

And with droop control-- So we establish voltage, so that the primary mechanism is voltage control. But by drooping that value as a function of current, we can actually achieve precise power sharing. And more of that later. Fuel cell to converter. it's the same average value converter, and then droop two in this case. Same feedback and control structure as fuel cell one.

And let me just simulate this. It's 2,500 seconds for the FTP-75 drive cycle. I'll just simulate it. And take a look down the bottom here. Once it compiles and starts simulating, you'll see how quickly it simulates. So there we go. It's up and running now. And as you can see, it's just taking a few seconds for us to get through the 2,500-second scenario.

If I open up the simulation data inspector, we can take a look at some of the results. So this is a simulation data inspector. So we can look at the-- See the power of the fuel cells. Just zoom in. We've got the same droop value in this case, so they're equal power share. And we can also see the current and the voltage on the motor as well.

So the simulation data inspector gives us access to all our measured signals. And we can very efficiently view and compare different simulation runs within this environment. And we'll look a little bit more at the comparison later.

So let's go back now to the presentation slides. So for those who may not be familiar with droop control, let's do a quick 101 on droop. I've got two examples of droop control here. On the left is where I've set the droop value to be the same value on each of the fuel cell systems. Now, what droop means, what does 5% droop means? Well, it means if we move from no loading on our fuel cell to full loading on our fuel cell, then voltage will drop from its nominal value, 100%, to 95% of its value at full loading.

And so we have a droop curve, which is actually a droop line, which you can see here. This line that goes from 1 to 0.95. Once we have that curve, we can tell exactly what the voltage will be for a given loading condition. So in this case, we've got a 30 kilowatt demand. Because our droop values are equal, each fuel cell provides 15 kilowatts, which we can see on the x-axis. And we can see at that point, voltage will have dropped to 0.97 or 97% of its nominal value.

On the right, we've changed droop two relative to droop one. Droop two is 2.5%, droop one is 5%. So droop two is half of droop one. And so we draw the two droop lines. And voltage is the same. So we can see here that for this loading of 30 kilowatts, what we do is we drop that voltage line until the sum of fuel cell one and fuel cell two equals 30.

So in this case, you can see fuel cell one provides 10 kilowatts, fuel cell two provides 20 kilowatts, and the voltage is 0.98 or 98%. So halving the droop value doubles the power, and that's a fundamental observation of droop control. So what this means is, by adjusting those droop values, we can adjust the power share precisely and achieve a given power share, which will be the premise of when we're looking to see if an optimized power share provides any benefit to a simple 50/50 power share split, which we see on the left here.

So I showed you this result in simulation, but let's just take a look again. We have a 50/50 power share when the droops are equal. And we also see the battery coming into play here as well, where the battery is providing that peak lopping. So when the fuel cell total power is 25 kilowatts, the battery will provide power, and the battery also absorbs regenerated power. So we're seeing expected behavior.

And in this case, we've done the 5% 2.5% droop, and we're seeing fuel cell two provide twice the power of fuel cell one. So again, we're seeing expected behavior, which obviously builds our confidence as we take the next step in our design task.

In the next stage, we're going to consider how we can implement a power share algorithm that will optimize power share based on the efficiency curves of each fuel cell. And we'll determine if there's a measurable benefit, in this case, to doing this over a simple 50/50 power split. So we use stylized efficiency curves to proof out the algorithm. And the curves on the right, I set that up because, the stylized curves like this that intersect, they'll favor fuel cell one at lower powers and they'll favor fuel cell two at higher powers, in terms of the most efficient selection. And we can readily check that in simulation.

The optimization algorithm uses fmincon. And the aim is to minimize an objective function that will give us the most efficient operation as a function of the fuel cell efficiency curves. So now, let's take a look at this model. And I'll delve a little bit deeper into the architecture. So here is our stage two model. And just quickly let me show you the battery is still the ideal voltage source and both fuel cells are still ideal voltage sources. The difference is that we are now implementing an optimization algorithm.

I use a MATLAB function for this. And I have the ability to check a simple 50/50 power split or the optimized power share. So we need the efficiency curves, stylized efficiency curves in this case, which we also feed in to our MATLAB function. Let me just show you the MATLAB code. I wouldn't dwell on this, but we'll just take a quick look at this.

So the heart of this is this power sharing function. So let me just open this and show you, so that you can see what it looks like in terms of the implementation using fmincon. So using fmincon here, I define a function, which I feed in, the efficiency curves as a function of power, and the optimization then spits out a ratio, which I then use to implement the power share by adjusting the droop values.

So with this algorithm, when we're doing the optimized power share, it updates the droop values dynamically. And we can set that updated value. In this case, I just set as one second, although we can change that. And then, we can compare the consumed energy for both cases.

And so for the FTP-75 drive cycle, we observe a 0.6% reduction in energy consumption for the optimized power share relative to the 50/50. The benefit is small, but it does demonstrate that the optimization is working. And we now have a baseline upon which to perform further evaluation as we continue our design exploration.

An important part of effective design space exploration is to implement models that suitably capture the response of system components, but do so with a reduced amount of computational overhead during simulation, the so-called reduced order models, or ROMs.

As I have access to detailed simulation models of the fuel cells, I'm going to use those detailed models to generate and lookup tables, which I can then implement in the system. The main purpose of a lookup table is to capture the status data response for a given operating point. We'll discuss the implications of this in terms of electrical and thermal behavior in a moment. But first, I'll discuss how we generate the tables.

To generate the tables, we perform an electrical power ramp that starts at a high power and then reduces to 0 power. We also include a coolant flow rate, so we can capture static temperature as a function of flow rate and electrical power. The key to this is for the ramp to move slowly enough that we capture a steady-state response.

As the thermal time constant is much slower than the electrical time constant, I ramp the power down over a 5,000-second period in this case. Once we have the lookup tables, we need to consider the time constants for system simulation. As electrical time constants are very fast, we use the lookup tables for voltage and current as is. But we need to add a first order time constant at the output of the thermal lookup table, in order to capture the thermal time constant of the system.

So let's now take a look at the stage three model in more detail. So with our stage three model, we've introduced lookup tables for the battery. We use the Battery Table-Based block within Simscape Electrical. And for the fuel cells, we use two-dimensional lookup tables. We have two here. We have the lookup table that generates voltage as a function of current and current flow rate. And we also have the lookup table that generates temperature as a function of current and flow rate.

And you can see here the upper table is the temperature table. We convert to Celsius, and then use a first order time constant to capture the thermal dynamics. Our pump control, in this case, is just a PI controller with a first order low-pass filter. Fuel cell two, same architecture, two two-dimensional lookup tables with our pump control in place. And the power share optimization uses the efficiency curves that we have created from our reduced order modeling exercise. Let me now simulate this model. So we can see how quickly it runs.

It's just going through its compile phase and then it will kick into gear in just a second. There we go. It's now running. And as you can see, it simulates much faster than real time. So we're already up past 200 seconds in this case. So this model runs quickly and we can use it also for real time studies in hardware-in-the-loop testing. So let me stop this. And we'll go back to our presentation slides.

So when we have created a reduced order model, we want to build our confidence that the model is a reasonable approximation of the fully detailed system, so we can run a comparison with the power share algorithm implemented. And in this case, I just used a fixed coolant flow rate, so I didn't implement temperature regulation in this case. I want to compare the open thermal responses to build that confidence that we have a compatible response before we do some design on the coolant feedback system.

So in this case, we can see that, while the responses are not perfectly overlaid, they are compatible enough for us to conduct design iterations with confidence on the reduced order model. And here we see a comparison of stack voltage of fuel cell one for both the fully detailed model and the reduced order model. We can see that, while the responses are not perfectly overlaid, they are compatible enough for us to conduct design iterations with confidence on our reduced order model.

Having a mechanism to explore multiple parameterizations gives us the ability to conduct the trade studies and/or conduct studies on tolerance variations. To effectively conduct these studies, we first set the physical parameters in Simscape that we wish to change as runtime parameters, an example of which is shown on the left.

Runtime parameters means that the model will be compiled only once and we can modify the parameter value for subsequent simulation runs. Second, we run the simulations on multiple cores using the parsim command. In the code snippet on the right, I set up all the scenarios I wished to run in a simulation input object, and then run parsim. Parsim will run the scenarios of multiple cores, and then gather all the simulation results in a single output data structure for subsequent analysis.

In this example, I ran 50 different fuel cell parameterizations and compared the use of the 50/50 power share with the optimized power share. For this particular study, we observed that the optimized power share consistently delivers efficiency improvement over the 50/50 power share, albeit a small percentage gain.

When we run a large number of scenarios-- We've done 50 in this case, but you could potentially be running up thousands or tens of thousands of simulations. We want to take advantage of statistical analysis and visualization. In this case, I'm showing a histogram of fuel cell energy on the left and a box plot of fuel cell energy on the right for both the 50/50 power share and the optimized power share.

Once we have a design that's functioning as expected and we have sufficiently explored the design space on the reduced order system model, we can confirm the operation response using more detailed simulation. So let me just go back in to Simulink and show you the more detailed model, the stage four model.

So with this model, the battery remains as the Table-Based battery model. But now, we swap out fuel cell one and fuel cell two for the more detailed fuel cell model. So there's fuel cell one and fuel cell two. And we also include the fuel cell auxiliaries. And in this case, the hydrogen source and oxygen source I've kept them separate for each fuel cell.

So let's just quickly look at the hydrogen source here. So there's our hydrogen source model and oxygen source and the cooling system. Here we have our pump control, which we've also implemented in our stage three, our lookup table model, as well. And the auxiliaries are the same for fuel cell two.

And for more thorough design exploration, we would consider the auxiliary setup for the two fuel cell systems. In this case, I just kept them both separate. So we can then compare the stage three and stage four models. And we see the power share is equivalent in the reduced order model, stage 3, with the detailed model, stage four.

What I'm going to do, actually, is bring up the simulation data expect that I preran these simulations. I just want to show you some more of the results. So stage four and stage three. So let's take a look at the temperatures of stack one and stack two. I'm regulating to no more than 40 degrees Celsius here, so they will limit at 40 degrees Celsius. This is the fully detailed model. Let's just scroll down and take a look at the lookup table. Stack one and stack two. So you can see they're compatible. They're not perfectly overlaid, but they are compatible.

And let's take a look at one more response. Let's take a look at the-- Let's see. We already looked at fuel cell power, temperature. Let's take a look at voltage. So fuel cell one voltage. This is for the fully detailed model. And let's look at fuel cell one voltage for our lookup table. So we can see that there's some bias offset in the no loading condition, but we're capturing the responses quite well here. Well enough for us to have confidence that we can design and we can perform our design exploration and design iterations on our lookup table model.

OK. Back to our presentation slides. In stage five, we integrate the electrical power generation system into the full vehicle simulation. We do this to evaluate the full system response with considerations, such as miles per gallon equivalent, acceleration performance and other performance indicators. We also wish to confirm that the energy management functionality is operating as expected. We can choose which level of fidelity we want to integrate back into the full vehicle simulation.

For real time testing, we would select the reduced order model as it runs comfortably in real time. For detailed evaluation on the desktop, where we are not constrained to run in real time, we can integrate the detailed fuel cell models into the full vehicle. Here are some results from full vehicle evaluation using the detailed fuel cell models within the fuel cell electric vehicle reference application. We confirm that the control system as designed operates as expected. And we also highlight our simple battery management system needs some fine tuning to contribute to overall system efficiency.

In conclusion, we've looked at how we can best explore architectural design for a multi-stack fuel cell vehicle to explore design options for efficient operation over a given load profile and provide an architecture that is resilient to fuel cells with different characteristics. By building out fidelity and complexity incrementally, we can focus on specific design tasks and minimize the time taken to perform design iterations.

At each stage of design, we can compare system response to ensure we have operational consistency and build our confidence that the system is doing exactly what we have designed it to do. Thank you for listening.