Vehicle Modeling Using Powertrain Blockset
From the series: Improving Your Racecar Development
Ed Marquez and Christoph Hahn highlight the benefits of using Powertrain Blockset™. Some of these benefits include the ability to use well-documented, open, and reconfigurable blocks to represent powertrain components. In addition, Powertrain Blockset allows for highly detailed parametrization of components based on user data and supports code generation from models.
Three demo models are shown using Powertrain Blockset: a vehicle dynamics (glider) representation, a battery electric vehicle, and a combustion engine vehicle. The input to the models is a publicly available certification drive cycle (US06), and users can choose the information they wish to obtain from the model. Throughout the demos, Ed and Christoph verify that the speed output of the vehicle model matches the speed input from the drive cycle without any major trace misses.
The main takeaways from this video are that Powertrain Blockset:
- Is built on Simulink®, and the former provides an extension to the capabilities of the latter
- Implements an approach driven by available component test data
- Offers many options for each one of the components
- Is supported for code generation
Find the models used in this episode on MATLAB Central File Exchange.
Published: 15 Aug 2017
Hi, everybody. You're watching the MATLAB Simulink Racing Lounge, part two of our nice series about vehicle modeling. And I'm super glad that Ed is still on board.
Hi, Ed. How are you doing?
Hi, Christophe. Good, and you?
Very good. I'm looking forward to the second part of our series. And let's move to the agenda right away.
What did we cover last video, number one. What are we going to cover in that video? I'm just handing it over to you.
Excellent. So as you mentioned, we covered before in a question-based approach with Simulink in the first episode. Today, in this episode, what we're going to cover is modeling vehicle systems with the Powertrain Blockset. And it is a data-driven approach as opposed to equation-based.
Later on, coming soon, we're going to talk about Simscape, and also Simscape Multibody.
Again, no worries. We will show you a lot of models and we will put everything on file exchange. So no need to rebuild models. We will share it with you. And a second comment I have at that point, Powertrain Blockset is an add-on to Simulink. And Ed will touch that, so it's not a completely new tool. It's just an extension of Simulink. I think Ed is going to show you what Powertrain Blockset is, and what it can do for you.
Absolutely. And as you said, all the models will be provided. So sit back, relax. And what I want to show here is one of the models that I put together with the Powertrain Blockset, and this is what we would end up with at the end of this session.
So this is a conventional vehicle model that models a vehicle with a combustion engine. And one of the things that I want to start by showing is some of the information that you can get from these models. You can actually visualize the maps for engine speed and the actual torque output of the engine. And you can change these parameters and maps to fit your custom application.
And you can also get a lot information based on whatever data you have, even for mass flow, and also the torque and speed of an engine.
Sounds super interesting. So bear with us for 20 to 25 minutes, and we will walk you through the process of setting up a model in Powertrain Blockset.
We're going to do some software demos with the Powertrain Blockset, and then we'll summarize our key points as well.
Sounds good.
So as Christophe mentioned, the Powertrain Blockset is an add on to Simulink capabilities. It is built on top of Simulink, and the advantage of it is that you can combine both of these platforms for your modeling efforts.
So Christophe, if you look at this plot here on the screen, you can see that the Powertrain Blockset is great when you have a lot of data. So it can be used for data-driven modeling, and also for analysis because it can provide relatively high-fidelity results.
Similarly, on the other hand, it's more of an equation-based approach. And I would recommend it more to be used in design stages, when you're beginning. But know that Simulink can also be used for analysis. If you have a very high fidelity model that you've built through the months and years in Simulink, you can get pretty good results for analysis from that.
So the advantage of these two is, again, that you can combine them.
Right, what I will take from that slide is Simulink is to start in early stages of the design. And if I have the equations, I can set up the Simulink model. For Powertrain Blockset, I need a bit more data, and it's for analyzing systems that I already have. But I'm not worried at all, because Powertrain Blockset is on top of Simulink. So even if a component would be missing in Powertrain Blockset, one could set it up and Simulink, and can use these tools in conjunction. That's great to hear.
Exactly. Excellent. Yep, so some of the advantages of the Powertrain Blockset-- it was built on top of Simulink. It provides the ability to customize your blocks with test data that users may have. And you can also represent the operation of a single component with a single block.
So before, in Simulink, we were using a subsystem of many blocks. Now, you can just use a single block. And again, it is also supported-- the Powertrain Blockset-- for automatic code generation.
Nice.
Now, if the users are looking for well-documented, open, and reconfigurable models, the Powertrain Blockset is a great choice. Also, if the users have access to a lot of test data, Powertrain Blockset is a great choice.
And finally, the Powertrain Blockset can also decrease the number of blocks in the model while maintaining certain degree of fidelity.
I think a very good example here is an internal combustion engine. If you want to model the entire thermodynamics, mechanical properties, all the processes happening there, you would need a dozens of Simulink blocks. I would say in the Powertrain Blockset, use an engine block that parameterizes with the data available, and you're good to go.
Correct. All right, so another important aspect about the Powertrain Blockset that we have to keep in mind is that it offers a variety of component options. And what I mean by that is, for example, to represent engine operation, you can start with the most basic type of blocks. And these are called mapped blocks. So you can see, they usually use lookup tables or maps.
But you can also model the details and dynamics of an engine, whether it's compression-ignited or spark-ignited. So for this demo, we're going to stick to the map version of the blocks. But you can configure a lot of different aspects for the operation of the engine, like the power of the air mass flow rate, the fuel flow rate, the temperature, the efficiency, and even the emission aspects of the engine.
Also, for transmissions we have a variety of options. You can have continuously variable transmissions, dual-clutch transmissions, or in this case in our models what we're going to use is just a discrete manual transmission.
Again, in this models, I created the shift logic for my transmission using state flow. So that's a tool box that can add on to Simulink. And another piece of information that people may need access to is shift maps for the transmission. So determining at what speed an accelerator pedal position, the transmission, would shift gears.
So with that, those are the main components that I'm going to touch in my demo. But again, I have a lot of other components, like the vehicle dynamics, tires, and also driveline that I would like to cover in the demos here.
So we can start very simple with the glider. And we saw the glider in the first episode of these series. And here what we're doing is we're adding another degree of complexity. We can add wheels and brakes to our vehicle dynamics. So I'm going to start here with the vehicle dynamic system.
OK, so from the previous episode, we saw that the vehicle dynamics or the glider was represented by doing a summation of forces, many different blocks. In this case, all of that is summarized here in the vehicle body block. And I touch on the aspect that these blocks are open-ended and also reconfigurable. And what I mean by that is you can actually explore these blocks.
So for example, if you look under the Mask, you can actually customize some of the aspects of this block if you really want to get to that level.
Right, or you benefit from the block. You trust the MathWorks engineers and developers that this was implemented correctly, and you just use it. So you have the freedom to choose.
Exactly, so a lot of freedom when it comes to this. And again, what I'm doing here is just using some of the parameters that I have. I customize these blocks, and then I just plug them in my model.
Nice.
A lot of simplification here. Just one block to represent the vehicle dynamics. Here, what I'm doing is representing the tires of the vehicle. So the front tires and the rear tires-- this only models longitudinal dynamics.
Well, which is fair. You need to start at a certain point. And as we see it here, the tire model is referencing to the magic formula approach.
Correct.
So it can be parameterized using different tire models. In that case, we choose a pretty simple approach-- Pacejka Magic Formula. The good thing is we have developed the tool for you to obtain the magic formula coefficients from tire test data.
So we reference to the TTC from Calspan. This is another piece of software that we are going to share with you in another video, and also on file exchange. So this will allow you to obtain the coefficients B, C, D, and E from your tire test data. And I think bit by bit, we are really equipping you with all the things you need to set up a vehicle model.
All right, so we cover the wheels, the vehicle dynamics, and again here in this subsystem we're just going to see a driver. Where we have PID taking the error between the reference speed, the vehicle speed, and it outputs the braking and actual torque commands that we would desire.
Nice.
Again, if we run this model, this is a drive cycle that in reality is about 600 seconds. But this model can actually run in probably less than five seconds.
Probably four or five seconds.
So relatively quick. And you can also evaluate the results by comparing the reference speed to the speed that you're getting out of the model. And here, I can say that my model is actually meeting the drive cycle in an adequate manner.
Absolutely.
And another thing to remind the teams or the users is that they can customize these models to work with an input that fits their needs, whether it's a lap time or a drive cycle.
Exactly.
All right, so if we move to our next model I want to show a battery electric vehicle. So how can you model an electric powertrain with the Powertrain Blockset. And I want to start here with the motor. So the driver is actually providing an accelerator pedal position to the motor.
And you see that this is much cleaner, a lot less blocks, than what we had in the past with Simulink. And what I'm doing here is first predetermining the torque and the load for operation of the motor. And I scale that by the driver demand given by the accelerator's pedal position, and that comes in as my torque command.
So this battery voltage is something that comes from the battery model, from the battery block. And this motor speed is something that I'm calculating by the linear relationship between vehicle speed and the motor speed. So I have all these inputs. And this block actually gives me the battery load that actually goes to the battery system, and also the torque output from that motor.
Ed, a quick question about the battery in that model. Are you using the battery modeling approach that we introduced in the first video of the series, or is the Powertrain Blockset providing you a block for batteries here.
That's a great question. I'm using the block that is provided by the Powertrain Blockset. So I'm going to get into the details of that block in just a few seconds.
So here you have the ability to parameterize this motor to work with whatever speeds and torques you may have. And my recommendation would be to start, again, with some defaults that can meet the requirements of the user, and then parameterize that based on test data that you may have available later on.
Great.
So if we go to the battery system here, this is the block that is provided by the tool box. So again, the load current that comes from the motor subsystem, an ambient temperature input, and we get the output voltage for the battery.
OK, so here you can definitely characterize the efficiency and also the number of cells or the chemistry of the battery. In this case, I decided to change the number of cells in series and cells in parallel to meet my drive cycle in this model.
Excellent. And again, the rear differential is-- before we had some formulas modeling the drive line. Now, we just have an open differential block. So that simplifies things. And all I worried about here was just putting the gear ratio in the final drive. That's the only thing changed. And then that torque that comes from the motor to the real differential passes through an axle compliance.
And this block, what it does is it models a spring damper system. Pretty much like a shaft would be, or an axle. And then it goes to the wheels and vehicle dynamic subsystems that we had before. So these didn't change from the previous model. So that's one of the advantages of these models. You can build up the complexity. You can start with your very first models and add different components to those.
Perfect, that's great. Have we run that model already, or do we want to give it a go?
Let's run it. So again, the drive cycle about 600 seconds, but this model runs relatively quick. I think it runs in less than five seconds.
Nice.
So there it is. And we can visually inspect the high-level results. So am I meeting my drive cycle or not? In this case, we are. And these models also can provide a lot more detailed information for each one of the components-- the battery, the motor, and also the gear box.
I was just about to comment that. And so we let that model run, and we show one default plot. But you could attach a scope to pretty much any signal in that model-- you could monitor currents, you could monitor forces, compliance on your axle system, and information about battery-- so you have an insight to everything. It's based on Simulink, and you can save signals to your workspace in MATLAB. So this these models are super accessible and super easy to work with.
All right. So now the last model that I have that I want to show is a conventional vehicle. So how can we model combustion engine? And again, the driver subsystem-- and my drive line didn't actually change. I still have a rear differential with an axle, and the wheels, and the vehicle dynamic. So what actually changed was the powertrain. The different components producing the propulsion of the vehicle.
So here this case, I have an accelerator pedal position coming from the driver subsystem to the engine. And what I have here is just a major block-- the mapped spark-ignited engine. So here what I do is convert from accelerator pedal position to a torque command based on the characteristics of the engine. And if I open this block, I can customize a lot of different things.
So my recommendation for the teams or the users would be to start working with the defaults, characterize that, and then parameterize your components based on test data that you may get later on.
Yeah, I know that a lot of teams have access to a dyno. So this is exactly where you're taking all the input data to parameterize your engine here. And as Ed said, start with the defaults and add data as you go.
All right, so if we move on to the last different component, that is a transmission, here what we have is an ideal fixed-gear transmission. So I took care of the shifting logic with state flow-- that's a different tool box. And then I don't have a clutch model in this vehicle system. So what I did was I implemented some logic to model that clutch operation. So whenever the brake is pressed and there is no torque input then, the transmission and the engine decouple.
Cool.
So I provide those inputs to this transmission block. And I can get a lot of information from the transmission block. Also, the engine speed which is used for feedback. And then, the speed output which I can get the torque output from. And that is the torque that stars going down the drive line, to the differential, and to the wheels.
Cool. So the only component you haven't modeled as an actual component is the clutch. So what you've done is a logical clutch, which is a very smart simplification here. This is also the freedom that Simulink gives you-- set the modeling depth on your own, and if you can model simple, model simple.
Absolutely, simplicity is always good to start. And with this block, you have a lot of different things that you can parameterize. For example, the number of gears and each one of the gear ratios, and even the efficiencies. So it's up to the users to fill those gaps.
Yeah, right. And this is about reading the data sheet of your transmissions-- of the transmission you have in mind.
Absolutely. So again, if we run this model should take-- this one takes a little longer, but it's still much less than 10 seconds.
Nice, Ed. Well, these demos have been quite impressive-- great complexity with a decent amount of blocks. Can we try to summarize the key takeaways of today's episode a bit?
Absolutely, let's do that. So the Powertrain components, as we mentioned, are built on Simulink, so that gives a lot of flexibility. And these models are highly open and very configurable. There is a lot of documentation available for how this works, and how you can make appropriate modifications to these if necessary.
Also, it's worth remembering that the Powertrain Blockset components are data-driven. So your responsibility here is to parameterize those components to whatever test data you have available. And sometimes, I think a recommended workflow is starting with the default that is already provided with the components if you don't have access to some of that data.
And there are many options available, as we mentioned. For example, for engine options, for transmissions, and even differentials as well, and vehicle bodies, and all that. So a lot of flexibility offered with this tool. And the last thing I want to highlight is that the Powertrain is supported also for code generation if you need to do hardware testing or hardware deployment later on.
I think that that's a very good summary of today's episode. There will be more videos. So next video will be about Simscape. The keyword there is physical modeling. So actually modeling physical components. And if you feel that's interesting for you, stay tuned. Can you can you try to summarize next episode in one phrase? What are we going to do?
We're going to do Simscape, physical modeling. And it can be very intuitive and a lot of fun, so stay tuned.
Intuitive, perfect. Well, thanks very much.
Thank you, Christophe.
It was a pleasure to record with you. And towards the end of the episode-- you're used to that-- we are super interested in your feedback. If you would send us emails, or if you would to contact us on social media-- for example, Facebook-- that would be great. Because that's the foundation of our support. The more you share your questions, the more you share your problems, the better our support can be. So please, make use of that tool.
Another link for the sake of completeness, find all Racing Lounge episodes under mathworks.com/racinglounge. And in that ecosystem, you will also find a link to the software offer. And if you do use our software, we would be glad if you use the MathWorks logo on your car or on your reports.
Thanks for watching. See you next time.