Multi-Stack Fuel Cell Electric Vehicle Modeling and Applications - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 19:10
Loaded: 0.86%
Stream Type LIVE
Remaining Time 19:10
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 19:10

    Multi-Stack Fuel Cell Electric Vehicle Modeling and Applications

    Multi-stack fuel cells offer various performance improvements over traditional fuel cell systems. In this talk, see how MATLAB® and Simulink®  can be used to simulate these systems on a component and system level. As an application of this type of model, investigate a control approach to improve the overall efficiency of this multi-stack electric vehicle model for a given drive cycle.

    Published: 30 May 2022

    So again, my name is Jason Rodgers. Thanks for joining this talk on multi-stacked fuel cell electric vehicle modeling and applications. What we're going to do in this talk is go through this workflow that we use to investigate how we could model a multi-stack fuel cell electric vehicle model and then also look at how we kind of did a quick investigation on determining the control for such a system. I only have 15 minutes. The amount of content in these slides could easily take an hour. So I anticipate questions and hopefully some follow-up discussions as well.

    So let's go ahead and get started. So I always like to start with these key takeaway slides. These are the things that if you were to walk out in five minutes or after this talk, this is what I want you to remember. So first, multi-stack fuel cell virtual vehicle models can be enabled by MathWorks tools. We provide a realistic environment where you can do multiple testing scenarios. Of course, you can do things like analyzing the system, control design, optimization of components, and vehicle simulations.

    The second key thing is this methodology, this workflow that we use for this approach, we used it for modeling the electrical and the fuel cell system. But of course, it could be used for multiple different architectures or different scenarios you might want to investigate. The main idea with that is we want to build out fidelity complexity incrementally.

    So we start really simple. And then as we go along, we're focusing on specific design tasks. And we're adding fidelity where we need it and when we need it. Overall, this can help minimize the time taken between your different iterations.

    So just to kind of really get you on the same page of why we wanted to do this, we wanted to say, electrification around the world is a trending topic. It's happening in every industry. Most of you here probably touched on it in some way.

    Specifically within transportation sectors, we are seeing it everywhere from small e-bikes all the way up to large railways and marine vehicles. Within specific segment for heavy-duty vehicles, such as trucks, logistical vehicles, and buses, we're seeing a lot of work where OEMs are trying to investigate, how can we meet this heavy-duty power requirement while considering electrification? So it's a really interesting field that poses kind of a unique problem.

    And that's kind of what we tried to tackle with this project. We tried to kind of meet that problem that we're seeing OEMs tackle and provide an example workflow of how we would use our tools to do something like that. So we posed, as some team of engineers, where we were tasked to investigate building a PEM-based multi-stack fuel cell vehicle model because these are able to be stacked up together. So it can meet the heavy-duty vehicle power requirements.

    But on top of that, we also wanted to develop a controller so we could take the different stack models. Let's say they have different power characteristics. We want to take those and figure out how we can more efficiently split the power share between the multiple stacks so we can actually meet this real power demand.

    So the way that we went about this, to solve this problem-- of course, there's many ways that we could investigate the architecture and the control design. But what we did was use this four-stage process so it could help facilitate faster architecture exploration and control development. The main idea here is we're building out fidelity and complexity incrementally. So we can focus on specific design tasks in order to minimize the overall time between design iterations.

    So we're going to start very simple and add complexity as we go along. So stage 1, we're going to develop a low-fidelity electrical system model. When we're happy with that, we're going to move on and start to build in the optimal power sharing control.

    Again, once we're good there, and we've confirmed it works, we'll go on and look at the kind of full system. We're going to add in the rest of the balance of the plant and look at the functional response of that high-fidelity electrical system.

    And the last stage we do is we take this electrical system that's highly detailed. We have our controller we're happy with. And we integrate it into a full model so we can look at what the system level response is.

    So stage 1, again, what we're trying to do here is isolate the electrical system and really focus on just those electrical components. So we've pulled out just the multiple fuel cell stacks. We have some parameters, some sizing specs that we chose for those.

    We have multiple DCDC converters. There's battery models, electric machines. All of the power sources were modeled using simple Thevenin equivalents. If you're unfamiliar, that's basically just saying it's a voltage source with a resistor in series.

    We used this assumption because it allowed for really quick design iterations. We could kind of go around and quickly change where the stacks are located or where the batteries are located and quickly scale them up or down, as needed, to meet our power requirements. Another thing I want to point out is at this stage we used Simscape for the modeling.

    This was a really nice tool to use for this approach because it allows for design-style modeling. So if I wanted to design the architecture that I have on the left, which is what we ended up using for this multi-stack fuel cell, I could actually just draw the mathematical model with the Simscape components to look exactly like this. So it's really helpful for understanding and communicating to others what we had going on in our architecture.

    So to create this model, we started with a powertrain blockset fuel cell reference application model. We've kind of talked a little bit about powertrain blockset already. But this is a fully configured powertrain model. It has all the electrical plant we need. [INAUDIBLE] starting places. There's various controllers-- closed loop, longitudinal, driver models, drive cycles, et cetera.

    And what we did is we scaled this model up to be a heavy-duty vehicle. And then we pulled out the motor and copied the battery specs over. So those start were the basis of using our-- excuse me, the basis of our electrical system for the fuel cell. We also ran this model through an FTP75 drive cycle.

    And in doing so, we recorded the system power demand and the motor speeds and torques as we go along. So what these are used for is for allowing us to focus only on the electrical subsystem. And we can get kind of a drive cycle type performance by feeding in these signals into our electrical model.

    This particular powertrain blockset model is really nice because it's a combination of Simscape and Simulink-based models. So if you ever are interested in learning how to connect those two tools together, this is a good model to start with because we do show you as an example of one way you could do that. So this slide is used to show the results.

    So we wanted to make sure that our electrical system is behaving as expected. So to control the power share between the different stacks, we use the voltage droop check control. This is a traditional approach in DC systems for power sharing.

    And what we're basically doing is we're fixing that voltage droop on stack 1 at 5% just for this example. And then we fixed the voltage droop at 2 and 1/2% here. And then we ran the drive cycle.

    So what we're looking at is a function of time, which is what the figure on the right shows, is we want to see that can our total power meet the request? Which it did. And then are we able to somehow control how much power we're sharing? Which we did. So 5% droop on stack 1 leads to about 33% power share. And then 2 and 1/2 droop on stack 2 lead so about 67% power share.

    I also wanted to point out that the battery is going to regenerate any power during a braking event. And then it also tries to boost the power if we go above 25 kilowatts. So that leads us to stage 2. So we're happy with our electrical system. We did some analysis to make sure we can meet our power demand. And I kind of glazed over all the state steps in that stage just for time.

    But in stage 2, this is where we're bringing in our optimization of power sharing. So the main idea is we want to implement some kind of power share algorithm so we can optimize the power output of each one of the stacks. And in doing that, we're going to consider the efficiency curves of each of the fuel cells.

    Thevenin models are still used for this because we're trying to develop controllers. We want to have fast-running models. And these circuits are going to allow us to do that.

    So this is some math just showing what the approach we used-- what the optimization routine is. But all this is saying is, as a function of time, we're wanting to determine what the optimal power share is so we minimize total power loss, right? But we need to do so, so we're considering the total power of all the wheels.

    On the right, I have some stylized efficiency curves. These are not necessarily what you'd see in a real stack model. These are just used to confirm that our optimization routine is working.

    So we do these in a way so that stack 1 is going to be more efficient at lower power and stack 2 is more efficient at higher power. And just to let you know, at each time step in our simulation, we are running something called fmincon, which is an optimization routine that is shipped with our optimization toolbox. So we're actually solving this problem online at every time step. I believe we ran at 10 milliseconds.

    So we've gone through this process of setting up our problem. We're happy with it. We think we can solve it. So what we want to look at now is, is our power sharing correct? Is our optimizer doing what it's supposed to?

    So this figure on the right shows a snippet of time of what the power sharing is. And what we do see is that in a low-power request region, we see stack 1 providing power, more power, which is what our efficiency curves dictated. And then at the higher power region, we see stack 2 providing more power. So that's good.

    Another thing we can look at is the figure on the left. So we kind of ran the full FTP75 cycle with just our electrical network. And we looked at, what's the total energy use for our optimal share approach? And then what is the energy use for just running stack 1 or stack 2 alone?

    So quickly we can see, OK, even though it's kind of stylized, we do see some improvement on our fuel economy-- or, excuse me, our energy usage for this drive cycle. So we're happy. We think our controller is working and our architecture's working. So now we can move on to stage 3, where we're going to remove some of the assumptions that we had.

    So we get rid of the Thevenin equivalent circuits, and we put in more detailed fuel cell stack models. Specifically, we're bringing in the balance of the plant. So we're adding in the error handling system, the hydrogen handling system. We're keeping our power distribution. We're bringing in coolant/thermal management, et cetera.

    And at this stage, we're doing this because, again, we want to make sure that our controller is going to work in the presence of more realistic systems. And we also want to make sure that our power is being met. So we're really confirming the functional response of that full electrical system.

    So on the right, I have a snippet of the stack models that we use. These are based on some shipping examples we have in the Simscape tool. So all of these are going to be Simscape driven.

    And what's really nice about this is, this model has got multiple species tracking. So not only are we tracking hydrogen. We're also tracking what's the amount of water vapor that's in the network. We do account for any saturation that might occur with the water as it becomes liquid. All of that's being included.

    There's also the rest of the balance of plant that I mentioned, so a compressor model, humidifier, hydrogen recirculation, water management. So we've really ramped up the complexity of this model, which is going to, of course, slow down our simulation time. But now we're starting to converge on more realistic physics in the system.

    One other thing to point out is the efficiency curves. So before I used this very simple efficiency curve just to confirm our controller is doing what we expect. So on the right here, now we've regenerated the efficiency curve. So we've taken these stack models. We run them. We generate the efficiency curves over some conditions.

    What I just want to point out here is we're still kind of leaning more on fuel cell stack 1 than we were before. So we're seeing that it's operating at a little more efficient. So when we look at some-- if we were to look at some time series data, we would see that we are leaning on stack 1 and providing more power with that.

    So at this stage, we can look at what changed with our fuel cell performance? So I have this figure in the top here. And what this is, is a comparison of the stack power between our previous states, where we had the simple controller in the simple electrical system. And then we can compare that to how we're currently controlling with the more realistic results.

    So on the surface this might not look so important. But I actually like this kind of an analysis because it can clearly indicate that if we have some crazy power demand now from our newly controlled system, our statutory system, it would indicate that maybe we should actually go back and revisit our controller. For example, previously we weren't considering any power constraints really on what the stack can put out.

    But as we go here, and we go to this stage, now we have more realistic effects and limits on the power output of the motors and the batteries and the stacks. So this kind of analysis can point to where we may see some improvements. Another thing we can look at is the kind of full electrical system behavior.

    So on the bottom, I have a couple of plots just to show you the stack coolant temperature. So we start at about 20 degrees C. And as we go through the drive cycle, we go up to about 80 degrees C. It's possible that we could use some improvement on that. Maybe we want to keep the stacks at 60 degrees C. So we did scale up the stack system, but we didn't really change the coolant system. So this kind of analysis helped indicate that.

    So we'll keep going here. So at this stage, we've gone through, and we've confirmed our architecture looks OK with the simple models in stage 1. Stage two, we developed our controller, and it behaved OK. And then after some iterations, in stage 3, we've converged on a controller and a system that can meet the power demand for the electrical system.

    So at this stage, we're going to take that. We're going to implement it into our powertrain. And we're doing this so we can confirm that our system level response for untested drive cycles is going to behave as expected. So we've only been focused on FTP75. But what about other drive cycles, is the question there.

    We can also start to look at system level metrics, like miles per gallon equivalent. If you're interested in acceleration performance for a heavy-duty vehicle, it could be done, things of that nature. And the last key point we can look at is confirming that the power sharing control behavior we developed, we want to make sure that it can work well when interfacing with other control systems.

    So our models are going to include not just our simple power sharing, but there's also the other control of the powertrain that's being lumped in there as well, which is kind of shown here in this figure. So this is a reminder of our powertrain blockset fuel cell electric vehicle model. So this is the same one we used earlier that we've scaled up to be heavy-duty vehicle. Except now we take out the shipping fuel cell stack model, and we put in our more detailed multi-stack model there.

    So now we're going to run it. We're going to confirm that our system level simulation behaves as expected. So on the left, I have FTP75 being simulated. And on the right, I have a different drive cycle, the 5-truck peak cycle.

    So the quick results I will point out here is we're seeing that our target and our actual speeds are on top of each other. So, OK, great, we are actually outputting the correct power. We can look at fuel economy. The numbers may be not so important for this. We're just highlighting that we do calculate this in the model.

    But one thing I'll point out is on the bottom, the SOC starts around 60% for both cycles. But we actually end around 80%. So what this tells me is, one, we should be using more battery throughout the drive cycle. And, two, it actually means we are not interfacing well with the load balancing control that is shipped with this model. So it suggests that maybe some iteration should be done on how we connect those two controllers.

    So just in conclusion, in this presentation, we looked at how we can best explore architecture designs for multi-stack fuel cell virtual vehicle models. We're trying to achieve the most efficient operation over some given load profile. But we're also wanting to provide an architecture so it's resilient to different fuel cell-- excuse me, fuel cell stacks of different characteristics.

    So you may recall I kind of showed how we had different stacks. And the main idea there is we want to make sure our approach is going to be realistic, and it's going to work if those stack models were changed, and the power's outputs were changed as well. So we presented this workflow so we could go through and build out fidelity and complexity kind of incrementally as we go along.

    This let us focus on specific tasks for each one of the stage. And then kind of going back and comparing that, our results were as expected and kind of focused on specific design tasks with each iteration. So I'll just close and give you a quote that my colleague Graham says, and it kind of encapsulates this approach that we use today. "Ultimately, we have some solution we want. And by using this approach, we start to creep towards that solution." And of course MathWorks tools is available to help facilitate that. So that is the end of my presentation.

    View more related videos