Virtual Vehicle: Transforming Vehicle Engineering Through Simulation
Sree Varshini Bhattu, MathWorks
Abhisek Roy, MathWorks
Rahul Choudhary, MathWorks
Veer Alakshendra, MathWorks
This panel discussion explores how the automotive industry is leveraging simulation and Model-Based Design to revolutionize vehicle engineering. From system modeling and controls engineering to validation and large-scale studies, industry experts discuss the transformative impact of creating virtual vehicles. Real-world examples, including AMZ Racing’s record-breaking motor controller design and Rivian’s scalable simulation platform, highlight how virtual development accelerates innovation, reduces costs, and ensures robust vehicle performance. Attendees will gain insights into cutting-edge simulation techniques driving the future of vehicle engineering.
Published: 5 Jan 2025
I'm really excited to open today's session by spotlighting on a very powerful example on innovation and precision engineering in the field of electric racing. Now, as a part of Formula Student, AMZ Racing builds a prototype of their vehicles each year. Now, a quick question to you guys, what do you think is the record-breaking time set by AMZ racing for accelerating from 0 to 100 kilometers per hour?
Now, you have some options here. I can see that. In the meantime that you figure out the answer, let me call upon our panelist. I would like to call upon Veer. Veer is managing our education team. He's also a mentor in fostering industry-ready skills in students. Also, he's very familiar or very known as guiding Formula Student teams. A big round of applause for Veer, please.
[APPLAUSE]
Next, we have Abhishek Roy, who's our senior application engineer. He focuses on virtual vehicle modeling and deals with intricacies of creating accurate models. A round of applause for Abhishek, please. Thank you.
[APPLAUSE]
Next, we have Rahul Chaudhary. He's also a senior application engineer. And he works with electrification. Today, we'll be discussing on interesting topics like battery management system and electric motors with Rahul. Quick round of applause for Rahul as well.
[APPLAUSE]
OK. So getting back to the question-- now, what do you think the record time would have been? So let me quickly answer that for you. C. OK. Let me quickly get that. OK. So the record time set by AMZ Racing to accelerate from 0 to 100 kilometers per hour is 0.956 seconds. And that's a world-breaking record.
Now, this is incredible. And this is a compelling example, if you see, set by students in the field of electric racing. Now, Veer, you are someone who's closely worked with AMZ Racing, right? Can you help us understand who AMZ Racing is and give us more insights about AMZ Racing?
Yeah. Thanks, Sri. That's an incredible history that they have made. And yeah, I mean, I've been working with these teams and multiple Formula One competition teams. And just to give a background, this is not the first time they have made the world record, so a few years back as well.
And as you can see, it's a complex system that they are working on. And they are doing different dynamic rounds, as you can see in the picture. So the record was 1.513 seconds earlier. And the further they challenge themselves and work on their complex systems and whatever challenges they encountered-- and further, they optimized the vehicle. And then we got this final result that you see is 0.956.
So the interesting part is we will be covering a few more aspects of how did they achieve this and also how we are also addressing the industry challenges. So yeah, we are looking forward to have a great interaction with you all. Thank you.
Thank you, Veer. Let me just quickly tell about what we are going to talk about in today's session. So the idea today is together we'll be looking at three important topics. That's system-level modeling, validation and testing, and large-scale studies.
Now, as we are talking about Formula Student cars and engineering that goes behind these, they are themselves a complex system. But when it comes to production-level cars, we are really looking at complex system. And in today's automotive industry, there's intense focus on reducing time-to-market cost, building cost-efficient vehicles. Also, industry's shifting towards-- the shift left of the V-Cycle that we really look at.
Now, with this, we are really looking at a virtualization and the idea of reducing time spent on hardware and physical prototype here. But the challenges remain same. So Abhishek, you're someone who works very close on the virtualization. Can you help us understand what are the challenges and how are these addressed?
Sure, Sri. Thank you so much. So one of the point that we saw was the complexity. And a few things to point out is that one of the primary challenges that we see are how the systems are complex and how the number of components that are talking to each other, they are quite large. To tell you how complex it can be, I have taken one of our customer's story that they have spoken at one of our conferences.
And this from Ford. And if you see the number of systems that they have-- so they have systems for ADAS. They have systems for steering, vehicle dynamics, brakes. And as a system integrator or tester, you have to check how all of the things are working together. And because of that, what happens is that the complexity of this goes through the roof.
And what we have also seen is that this is not just with Ford, but with various other companies as well. And this is our observations. The challenge is, if I break it down in three sub bullets, what you will see is that the first one is, of course, to address the complexity and based on what you are working on, you would be choosing one particular component and the model fidelity or the complexity that goes with it.
And now once you have selected that, then you-- most of the time, what happens is that you would have some of your legacy software or models that you would want to integrate in your system. So how do you do that? How do you make sure you have the right set of physics that you need?
Then the second thing is, what we're seeing more is that a lot of people from the organization need these kind of results so that they know where the project is going, how the product is turning out. And based on that, they are figuring out if we are on track or not. So it is not only important that the development team is having access to the models, but you also need other users who can just run the model, get the results.
So how do you facilitate that? And another common theme that we see is that most of the time, you would have different departments building same models but of different flexibility. If you really see we can do a lot of improvement there.
So how Ford handled it? They handled it by building a system called FASST. And what they did was they automated this entire process, where they brought in a lot of tools in one place. And this is, again, from the same article. I have referenced the article here so that you can go and have a look at it.
What they did is in this system, they had a skeleton model where all the components and everything were there. And a user could select what is the feature that they are developing and what sort of flexibility they need. And the tool was automated in such a fashion that in GitHub, they had all of these components of physics of various fidelity already hosted. And based on the user's choice, our model will be automatically assembled for that.
The steps typically involved having a model bill of material, or called as a bill of models, which would have the list of what kind of feature that the user wants to test. And based on that, they had a CAN Model Builder, which would read those DBC files and figure out what the model complexity and everything is needed, will pick up the ECU models, the components, and put together a vehicle model. And that's the overall automation that they worked with.
Now, if you look at the last point, one thing that you will notice is that on the vehicle plant models, there are a lot of tools. So they also automated this part, where based on what the user need, it will pick up the right fidelity for them.
Now, we have been working with-- we had helped Ford a lot on this project. And we have built something very similar in our tool chain so that all of us can make use of that. The process is very simple. It starts off with first creating the vehicle model.
Now, the way we create this vehicle model is, of course, we have given you the libraries, the subsystem libraries that you would need. That has been the legacy. A lot of time, you will find them. But what we have done is we have introduced a app called Virtual Vehicle Composer. And this app simplifies the whole process of assembling a vehicle model based on what powertrain architecture and the model template that you want.
The expectation here, really, is that you should not be spending too much time in building the foundation model or the skeleton model. Rather, we assemble it for you. And then we let you incorporate the models that you want.
So what you're seeing here is that you also have options to put the parameters that you want. And then once you are happy, you can choose the test cases that you want to do. And once all of those things are done, you will be presented with this particular view, where you have all the model assembled together.
And once you are done, the next step is that we have to now bring in the components or the controllers that you have into the system. And that's where most of you may already know that we have options for C++ interfacing or FMU integration. And also methods like user modeling can help you bring those components in or the controllers that you have.
Once you are done with these things, the next logical step is you define the scenario against which you want to test your system. And there are various tools for that. And there is a demo. We were talking about it outside. And once you are done-- so essentially, now you have a system where you have your vehicle model with your controller, what you need in a scenario, which you can now run multiple number of iterations to test to understand what's going on.
Now, one important step here is that just analyzing on a desktop machine most of the time is not enough because you will have thousands of test cases that you would want to run. And that's where deployment of the simulation comes in.
Thanks for that, Abhishek. Now, Ford FASST is a really great example when you look at how they've used virtualization to reduce time to market, right? Now, with this understanding of Virtual Vehicle-- back to you, Veer. So industry is using shift-left approach, right? So what's the motivation for student teams to move towards virtualization?
Yeah. Thanks, Sri. So it's nothing different from what the workflow is in the industry. It's basically the same workflow even the students are trying to do. Because as Roy mentioned, one of the important aspect is modeling the software. So they also try to do the same thing.
And going back to our previous talks that we had from Bosch and Mahindra, they also impose the importance of having system modeling. So they also sort of do similar thing. Yes, of course, they have to reach to a point that they can do further-- I mean add up in their workflow so that they can be more industry ready.
But yeah, looking at this example for AMZ, as you asked, Sri, is the first motivation or the driving factor for them was that to redesign the motor and the motor controller. So they specifically put a good amount of time in modeling the system, so just focusing on the powertrain. So this is basically we're just focusing on the powertrain. They have other systems as well, but focusing on the powertrain. As you can see, they have, again, used Simscape blocks for modeling their powertrain, involving inverters, batteries, and motors.
So this kind of activity, all the students who are participating in these competitions, they often do, reason being that they want to size their motors or different subsystems that they want because they have a certain performance target. So this is one example that AMZ has done. And further, once they are done, once they have optimized their model based on different subsystems, later they worked on the motor controller. So this is their field-oriented control algorithm that they developed using the reference examples that they have.
Now, one of the important aspect for these teams is that they have to go into multiple different dynamic events. So having just one type of subsystem doesn't help. So that's why they also, many a times, in different kind of subsystems, they look into different various subsystem, for example, depending on the fidelity, which Roy also spoke about briefly.
So what kind of fidelity do they need? For example, if a team member is focused on specific analysis of a battery pack-- so in that case, they can have a full-fledged battery pack, basically getting the sim modeling. Or if one of the team members is just targeting that, OK, I just want to calculate the state of charge of the model, for them it is just one simple battery that they can use.
So apart from having system modeling, getting into system modeling, parameterizing their model, they also invest a good amount of time bringing varying subsystems, which we'll be also covering in the later part. So yeah, this is one of the examples like how AMZ has done, just to give you a heads up, that we have just given an example of varying subsystem. But actually, what's inside that, we have to further disclose. Yeah, you can check out the article that we have published, so yeah. Thanks, Sri.
Thanks, Veer. Now, this is interesting. We are looking at a master model. And then based on different requirements, we are looking at variants of these master model or variant subsystems based on the different fidelity, right?
Now, back to you, Abhishek. We have just spoken about the Ford story, right, where we have built a virtual vehicle model. Now, what are the other use cases where engineers can adopt Virtual Vehicle?
Thank you. I thought-- let me list a few of the user stories that we have. I briefly talked about the Ford, how they built their virtual vehicles in minutes. And let's understand the other two. GM had worked in developing an autonomous parking system.
And the challenge that they were addressing is that for them, due to the environmental conditions, the last hundred meters for which the autonomous vehicle has to drive, it didn't have any GPS signal. And that's one of the problem, like when you are going inside, indoor.
And then so how do you handle that? They use something very similar. They build not only the vehicle model, they also build the entire environment, the camera. And they model the fisheye camera to really see the environment and then decide what has to be done. And now, as you can understand, to really replicate what happens in the real world, you need a lot of detail to have. So they were able to follow this process and build a system.
Another example is from Bosch. And they built autonomous truck. And they used, again, the same kind of system, where they build the vehicle models. They integrated their controller models. Cosimulation was important for them. They had a lot of components that they wanted to bring in. And also, for the 3D scenario that you see, they used Unreal Engine to cosimulate and have all the physics in detail.
So these are few of the examples where we see that there are a lot of use cases of this kind of virtual vehicle. And most of the time, the common theme would be automation, simulation, and doing a lot of analysis.
Thanks for that, Abhishek. I can really see how cross-functional teams can leverage virtual vehicle modeling and how different engineering roles can also use or leverage virtual vehicle modeling here. Thanks for giving those insights, Abhishek and Veer.
Now, Rahul, you work closely on electrification projects. So with rise of electrification, how has Virtual Vehicle evolved? And what are the new challenges and opportunities you see when it comes to modeling different powertrain architectures?
Yeah. Thanks, Sri. And thank you, Veer and Abhishek, for highlighting the importance of system-level model. When it comes to electrification, we can definitely reuse the system-level model to derive insights about the electric vehicle.
So for example, we can start with the same model, what Abhishek showed, and then integrate the components which are crucial for an electric vehicle, such as the drive train, motor, or battery. And then we can do something like the component selection or component sizing.
For a given performance for a given range, what should be the size of my battery pack? What should be the size of my motor? And all these things we can do. In fact, we can also test different hybrid electric vehicle powertrain architecture and do some kind of trade-off study.
This model can also be used for designing a detailed controller model, but that is a separate topic. Once we have this model built, the system-level model built with all the electrification components, then we can quickly run this model for different drive cycles and then get some of the performance-related parameters, such as approximately how much range we are going to get, what is the overall cost of the battery pack, or what is the 0 to 100 time this vehicle can achieve.
This is interesting, Rahul. Now, if I were to put myself in the shoes of a system engineer, I would first lock the powertrain architecture. Once I do that, my consequent step or logical step would be looking at performance optimization. Now, how can engineers use or leverage Virtual Vehicle for optimizing for different targets?
Yeah, definitely, Sri. So through initial analysis, we can get the size of the battery pack, size of the motor. But definitely, we want to get the maximum out of these models, right? So we would like to optimize in terms of how many cells we want to place in parallel and series to get the desired performance to get the desired range.
Similarly, some of the other parameters we can also optimize, such as, what is the overall drive ratio in order to get the desired performance or range? And if you have access to the virtual model, we can actually create an optimization problem with the help of a tool called Simulink Design Optimization, where we can state our objective function, that we have to basically get the reasonable range and then acceptable price. So this is the cost function, which we would like to minimize.
And the constraints are the vehicle should be able to follow any standard drive cycle without too much deviation. The range should be reasonable. We can put some number, 300 kilometers, 250 kilometers. And then also, we need some reasonable acceleration. This is going to be our constraint for the optimization problem.
And then we can also have some of the design variables, which optimization algorithm can really change. So in this case, we can have number of cells in series and parallel as our design variable. And also, we can have the final drive ratio, which optimization algorithm can change to meet our objective within the specified constraints. Once we run this kind of objective problem, then you can see that we can get the desired outcome in terms of 0 to 100 kilometers acceleration time or the overall range what we are expecting from the battery.
All right. Now, optimization, as it sounds, I believe, is not so simple. But how do simulation engineers have to decide based on accuracy and computation time it takes when you're working with an optimization problem? Can you show some light on that?
Yeah, sure. So as we all know, accuracy and speed, they don't go hand in hand. If you try to improve the accuracy of the model, the simulation time is going to increase because now we are simulating more and more details of the model. Veer and Abhishek, they briefly highlighted the importance of model fidelity. And they spoke primarily in terms of the use case. But the model fidelity can also change depending upon where you are in your development process.
So if you're early at the concept stage, probably we can have a very abstract model, which does not capture intricate details of the component. But instead, it tries to capture the overall behavior of the system. If you are early in the control design aspect, then probably we need a very simplified actuator model.
And we need a plant model, which is not capturing a lot of nonlinearities, right, because these kind of models can be used for quick control design. Later, as the control algorithm matures, we want to capture more and more realistic behavior of the system. And that's when we can have more realistic actuators and incorporate some of the nonlinearities to the plant model.
If I take example of a motor, which is basically one of the critical component for any electric vehicle, during the initial phase, we can have a motor model where we assume that the torque produced by the motor is going to vary linearly as a function of current. But later on, we can switch to a more nonlinear behavior, where we can capture the effect of saturation or spatial harmonics.
Same thing we can do with the batteries. So when we are doing initial range estimation, probably we can have a battery model which is based on the charge-discharge profiles. But as we move forward, and if you have to develop critical BMS components, in that case, we can start capturing effects of the transient dynamics or the effect of temperature on the overall battery pack.
Thanks for that, Rahul. Now, let me quickly summarize on what we are looking when we're talking about system-level modeling here. First, we started with an understanding of the need for virtualization and what are the challenges and how are these addressed using some of MathWorks solutions. We also looked upon different use cases. Also, we spoke about master model and then different variants of it. Rahul had touched upon the trade off between accuracy and computation time there.
Now, when we speak about creating virtual vehicle models, it's equally important to create accurate virtual vehicle models. So that brings me to the next interesting topic. That's validation and testing. Now, a quick question to you, Veer. In your experience, how do you see student teams-- how do they ensure that their model accuracy reflects the real-world performance?
Yeah. Thanks, Sri. And again, thanks to Rahul for covering in detail what system modeling is and how to perform that. So yeah, so these teams are doing multiple track tests that they are performing to check whether the simulation that they have performed, those are correct or not. So this is one of the example-- again, going back to the AMZ Racing-- model that they created.
So here that you see on the screen, so once the motor controller was built-- so they generated the STL code and deployed on the AMD FPGA. And the results that they got, they further did some track testing. And they obtained it. And you can see how close the simulation result and the hardware results are.
So the goal here was to assess the controller at 28,000 RPM because the end goal was to make the world record and make it move faster. So once they arrived at this result, they were confident enough that they have a perfect simulation model which is accurate enough to perform different test cases. And at the same time, it was a realistic representation of the hardware so that now they can control the gains. So this is one aspect.
Further, the team is also working to set up their hardware-in-the-loop simulation. So this is with the goal that they can build the traction control system. And at the same time, they are able to operate their vehicle at 200 hertz. So this is one example from the powertrain aspect.
Now, another use case or another example from one of the teams is based on the vehicle dynamics. So as you can see, this is another team from Dynamis PRC Polytechnic Milano. So what they did was they created multiple track simulations. As you can see, the simulation is built using Unreal and Simulink. And further, they built a driver-in-the-loop, which is running in real time using the real-time target machine.
And now, once they did the track test-- so again, they performed multiple track tests to log their data real time. And as you can see, for one of the track tests, the results are quite close. So the main approach that the teams do-- so they keep multiple sensors on the vehicles to lock the data when they are driving around through the tracks, even when they are in the competition. And further, they go back and try to compare it with their simulation results, so yeah. Thanks.
Thanks, Veer. Now, when it comes to production-level programs, Abhishek, we are really dealing with much more complex systems, right? So what's the correlation that you see between simulation and real-world performance?
Yes. So to address that question, let me take again another user story. And this is from They had been using our model, which are being generated out of the Virtual Vehicle Composer. And they did a benchmark study as well. What you see here is that whatever I showed you earlier, like putting together the vehicle model on its own automatically, they did the same thing. And however, they spent time on parameterizing the model and using the generated model to optimize it and get the real-world results.
So if you see the benchmarking data, they got very good correlations. And the error were within a few percent of RMSE, which was excellent for their use case. So this kind of validates that the model that we have that we are generating, they're quite accurate enough, captures a lot of the physics that are needed. And so it's not important that we redo the same thing. And we can make use of it for the initial steps.
All right. Now, that's a very interesting user story, I would say, where Virtual Vehicle is kind of leveraged for validation and testing. Earlier, when we were talking about system-level modeling, you spoke about how different engineers use Virtual Vehicle, right? I have a specific question on how software engineers would leverage Virtual Vehicle for validation and testing. When I mean software engineers, I'm talking about engineers who work on critical projects like battery management system, motor control unit, or vehicle control unit.
Got it. That's an excellent question. And so what we propose and suggest them is that the models that we provide are quite good. You start off with those. Get the component models. You spend some time parameterizing it. But once that is done, you replace the controllers that are present, or you use these models to build your control system.
Now, this is the typical model-in-the-loop framework, where you would use these models to develop the foundation controller, tune PID algorithms, and all those things. But this point of view is from someone who is developing the control algorithm.
If we talk about the users, most of the time, they would have some control algorithm which they have already built, which they would want to validate. That is where the software-in-the-loop and the workflow would come in. And they can use as functions or see other blocks to ingest those models, in fact even FMU for that matter, and interface this.
The models that are available through Virtual Vehicle Composer, they are open for study and customization as well. So it's very easy to tap into the right feedback signals that are needed, connect to your controller, generate the-- or controllers, generate the signals, and feed it to the plant.
Now, the final step is hardware-in-the-loop. And that's where the same models, whatever I have showed you, are also code-generated. So what it means is based on whichever hardware-in-the-loop system you are using, the plant models can be converted to a C code and then can be deployed to any performance real-time machine.
And the controller can go to either-- we can, again, if we don't have production issue available, we can put it through some other hardware and prototype boards. And then we can do hardware-in-the-loop simulation to validate them. The idea here, really, is that the reuse. This is also something that Rahul and I have been talking about, that how those models can be reused for the same things.
Interesting. Now, you started off by talking about model-in-the-loop, software-in-the-loop, and then connected it with hardware-in-the-loop validation, right? Now, Rahul, you are someone who closely works with customers on hardware-in-the-loop validation. Do you find any interesting challenges that engineers face? And how are these addressed?
Yeah. Sure, Sri. So thank you, Abhishek, for highlighting the importance of hardware-in-the-loop simulation. It is not just one of the steps that one has to do, but it is also one of the mandatory steps if you are going for certain certifications.
And our previous speakers from the previous session, they highlighted the challenges what typically people face when they want to do hardware-in-the-loop simulation. They mentioned that they have to do a lot of optimization with respect to the plant models to make sure that it runs in the real time, right?
So I would like to share one user story from one of our customer, Navistar. They also presented in one of the automotive-- MathWorks Automotive Conference. And they wanted to perform hardware-in-the-loop simulation to test their thermal management system for their electric trucks.
If you think about thermal management system, it's a very complicated system from computation point of view, especially when you are dealing with a system where it is going to simulate the behavior of chiller or heat exchanger, because typically, those models can be simulated with the help of two-phase liquid. And two-phase liquid simulation is typically computationally intensive.
What they did was they first gathered the data for that two-phase liquid subsystem or chiller subsystem. And then they created a reduced order model. And for the rest of the system, they created a Simscape model. So what we can essentially do, in order to optimize the overall system performance to run on the real-time hardware is whatever bottlenecks we have on the model, we can basically create a reduced order model, maybe get rid of some of the dynamics so that it can run in the real time. And the rest of the model we can keep as it is.
So basically, we can take a hybrid approach, where certain parts of the model is developed using MATLAB, Simulink, Simscape. And then the rest of the model can be developed with the reduced order model workflow. And then we can run this model on the real-time target machine to achieve the real-time performance.
Another component which I would like to highlight is the battery management system because testing out battery management system is also very, very critical. And if you think about how much time it is going to take to completely charge and discharge or how you are going to test some of the safety-critical parameters, such as thermal runaway or some of the faults, all those things, it makes more sense to do a trial simulation.
Now, for testing BMS hardware, we need a special kind of setup because, basically, we have to simulate the voltage, current, and temperature profile of each cell. So essentially, what we need is a programmable power source which can deliver all these values. Or in other words, we can call it a battery emulator car.
So this is what you see. On the left-hand side, we have a BMS HIL setup, where at the top you see the battery emulator. And it is sending all those signals back to the Speedgoat hardware. And on the right-hand side, we have our BMS algorithm, which is basically going to exchange certain signals and going to take corrective actions based on different test cases. So this is how a typical BMS HIL setup looks like, which you can leverage to test some of the safety-critical functionality of the BMS algorithm.
Now I would like to talk about another use case or user story here from Leclanché and how they leverage BMS HIL to reduce their overall development time, automate some of the testing, so what they used to do for those BMS hardwares, and how they could cover the safety feature by 40% and detect early bugs in their BMS algorithm.
Thanks, Rahul. Now, I really want to connect back to the Navistar story here. We were talking about HIL simulation, right? That's, again, real-time testing. And earlier, when Mahindra was also presenting, we were talking about-- they were talking about RCP. And that's also real-time testing. It's interesting to see how you can really use ROM workflows to address on how we want an accurate and fast models when we're working with real-time testing here.
Now, let me quickly summarize here. We spoke about system-level modeling. And then we looked into validation and testing. Here, we have touched upon topics of correlation with real-world behavior, Virtual Vehicle for software engineers who work on BMS, MCU, and VCU. And then Rahul talked about ROM workflows here.
Now, when we talk about validation and testing, we are really looking at thousands and more number of test cases right now. This is often computationally very expensive. And logically, this should bring us to another larger topic. That's large-scale studies. Now, Abhishek, a question to you. Can you please elaborate the term "large-scale studies" and how organizations use or leverage cloud-based simulation to address large-scale studies?
Sure, Sri. So what we have spoken till this point, there is a theme, that we are building a model, and then we are trying to test it. And most of the time, what happens is that we have one or two test cases that we can run in our computer. And we are mostly happy with it.
But imagine when you are scaling it up for 1,000 test cases. And that's what happens when you have a production component that really needs to be thoroughly tested. So that is where cloud-based simulation comes in.
And by large-scale study, we are referring that how we can take those, scale it up to those kind of cloud systems so that we can use the computational resources that we have. And the idea, really, is that we take the same system that we have built and then use any machine for that matter, be it Windows or Linux-- we should be able to take it to the cloud and then use those resources to get the results.
How MathWorks supports that-- one approach that we have is that we can use MathWorks-provided reference architectures specific to the operating system and software stack on virtual machines. These whole machines can be hosted on public clouds. Like, AWS is one example.
What basically happens there is that in that environment, we will be running a virtual machine. And MATLAB runs as is. So whatever model you have built there, you just push it to the cloud. And then you do all your tests there. That's one use case that we have.
Now, another use case that I want to talk about is-- this is another way that the same virtualization and then scaling up can be used, which Rivian did. They really pushed the boundary. What they did was they deployed these models that were made on the cloud and generated a custom front end for that. The idea is that you should be able to configure, run, and post-process large number of full vehicle simulation models.
And I know you may wonder, how is this different, and why they are doing that? One of the things that Rivian figured out was-- and I'm pretty sure that other organizations will also find it useful-- is that based on the persona that we are talking-- for example, leaders, attribute engineers, simulation engineers, or modeling engineer-- all of them have separate needs from these models. And there are a lot of insights to be gathered from those. But not everyone needs the same model fidelity.
So that's what they wanted to address. But in the process, they also figured out that it is very difficult to standardize this vehicle models and execute all the simulations one by one. And another problem is that, how do you make these modules available to everyone throughout the organization? And then running those, getting the results, debugging, it was really a challenge.
So what they did, they did something very interesting. They built a front end called a Vehicle Simulation Interface. And what this does is that simplifies your whole process of creating a vehicle model from the vehicle database. Select the tests that you want to run. And once you have done all this preconfiguration, you just push it to the cloud.
Now, something interesting they did, they did piggy backing. Now, what it means-- now, as you figured out, there is a chance that there are a lot of overlaps in the configuration can happen. Some engineer can select the same vehicle parameter, same test. Another one can also use the same thing.
So they built in a system where they could track that. And whatever simulations were already done they would not run it. They will just get the results and show. That helped them in making this whole system available to everyone, also generating the results that were important to them, and all those things. As you see, everything is using cloud. And the app that I showed you, Vehicle Simulation Interface, was also built using MATLAB toolboxes.
A few other things that they talk about-- I will not get into the details of it, but this is for you to figure out. As you can understand, these kind of models will come with overhead and vice versa with simulation time. They did a study and figured out for what sort of use cases cloud helps and for what use cases cloud doesn't help.
I will encourage you to have a look at the article there. They talk about this in great detail. And it's a recorded video. So you can also hear them talk about that in detail. So please go and check it out.
Thanks, Abhishek. Now, the term "simulation piggyback" is really interesting. And we see a lot of organizations take the same approach here. Now, what Abhishek has essentially spoken about is how to speed up validation process by using or leveraging cloud-based solution.
Another interesting use case is running simulation on cloud would be to create digital twins and connect that back to the real-world data. Now, when I use the term "data," that's the biggest challenge. Most of the times, we do not have access to data, or we don't have data with us. Now, in those scenarios-- Rahul, a question to you. How can engineers address this issue?
Yeah, sure. So as we put back the detailed component-level model to the system-level model, the complexity is going to increase, right? And if you are going to use these models to generate your synthetic data, it is going to take a lot of time. So definitely, scaling these kind of desktop simulation to the cloud is more logical thing to do, where we can take these detailed, complicated models and run through different what-if scenarios and then generate a lot of data.
In fact, we have a talk-- or we did a talk on the same topic in the last MathWorks Automotive Conference, where we covered all these things about how we can leverage cloud computing to run different what-if scenarios, simulation to generate data, and then analyze that data.
But here, I would like to talk about one of the user story from one of our customer, NIO Inc. They wanted to build a battery state of health estimation algorithm for their electric vehicles. But the problem was whatever vehicles they had on the field, they used to generate very less data. So they did not have a lot of fleet out available which can generate a lot of data to build a very good or state-of-the-art health of state estimation algorithm.
So they leverage this cloud-based architecture, where they created the detailed vehicle model which consists of the powertrain, the electric motor, and the detailed battery model. And then they ran different scenarios using these vehicles and then generated the data, which later they utilized to build the state of health estimation algorithm.
Thanks, Rahul. Now, that's really interesting. Let me quickly summarize on the topics we have covered so far. So again, we started with system-level modeling. We spoke a lot about how system engineers use or leverage Virtual Vehicle for addressing different challenges. And then we looked into validation and testing, where we wanted to create accurate virtual vehicle models.
And then we dwelled into large-scale studies, where we have talked about large-scale simulation on cloud or building digital twins, and then connecting that with real-world data. And other interesting use cases that Rahul just brought about was about NIO's story, where they have generated data synthetically. And that's essentially how you address the challenge with data.
Now, that really brings us to the end of the discussion. I think I have asked you to wait long for the questions. So let me quickly take the questions now. Thank you, Vinayak. OK. OK, the first question we have is, how accurate are the models used in Virtual Vehicle Composer app? Have they been benchmarked? I think this question should be addressed by Abhishek. Yes.
I mean, I also kind of answered it. has done that study. And that's one of the reasons that we have that is publishable, and we can talk about that. But there are a lot of other-- we're working with quite a few customers globally who have also experienced similar things. So I hope that answers that question.
Another question we have is, can off-road or agricultural vehicles be modeled using Virtual Vehicle Composer app?
OK, I'll take that question. Yes, it is possible, but not through Virtual Vehicle Composer. We do that using a tool called Simscape and Simscape Multibody. Now, it is possible for us to create and use the same Virtual Vehicle Composer model to create a two-axle vehicles. But here, my assumption is that you probably want more axles. So if you are having with two, the model that gets generated can be used for off-roading as well. Whereas for other things, multi-axles, I will recommend it to use Simscape. And based on the fidelity, we can even further elaborate on that.
Thanks, Abhishek. Adding to that, we've also seen customers use Virtual Composer app to model their electric three-wheels.
That's right.
Our next question-- I think this is an interesting question, I would say, to Rahul. When we are in component sizing stage, we do not have any controller available. So how can we perform vehicle-level simulation?
Yeah, that's a very interesting question. And luckily, in Simscale, we have a lot of blocks. We call it system-level blocks, where you don't really need the control algorithm. For example, motor plus drive block is capable of doing closed-loop motor control simulation, where you don't have to explicitly build the control algorithm.
Similarly, the other thing what we can try for other components is build abstract models. Instead of going into plant and controller approach, try to approximate the overall behavior of the complete component. And that's how we can build it.
Thanks, Rahul. I think there is another question. Generally, OEMs don't change anything with regards to motor or battery pack sizing. Which other areas can be looked upon while using Simulink in order to improve the range of the electric vehicle?
OK. Yeah. So again, that's a very great question. So there are two ways to it. One, as an engineer, if you know which all critical components are there on your system which is going to affect the overall range and performance of the vehicle, you can go and directly pick it up.
The other approach what we can take is there is something called sensitivity analysis. So sensitivity analysis will tell you which all parameters are critical for your range and performance. And it will give you a list in order based on how much they can impact, right? And from that list, you can pick which all parameters you would like to tune to basically improve the performance.
Rahul talked about the plan modeling side. Another option that you have is your vehicle control unit. Now, most of the time, OEMs would be building the VCO in their premises. So in that case, the first thing is that you could probably tune your controller that you have and make sure that you are running it at optimal conditions.
Another option most of the time that they have is during the calibration phase, some of the controls-- like, even if they are a bought-out part, let's say-- they will be exposed, a few calibration parameters which could be tuned. Now, we have tools and workflows where you can either do this tuning at a vehicle level or at a component level. The name of the tool is model-based calibration. Some of you may be familiar with it. If not, we cannot talk about that.
Thanks, Abhishek. Now, there's one last question I would like to take. It is easy to generate code using Simulink models. However, how do these autogenerated code compare with handwritten code with respect to memory utilization or execution time? Are there any guidelines to produce optimized production-level codes using Simulink?
Yeah. So actually, it's a code generation question. And we are all from a simulation background. But I can tell you what we can do. So when we generate code out of any Simulink Simscape model, it is typically done through our coder products like Symbol Encoder or Embedded Coder.
If you are completely new to this, we have something called Quick Start Guide for Embedded Code Generation. And it is going to walk you through some of the necessary settings based on what kind of performance you are looking from the generated code in terms of the RAM utilization, or reducing the overall memory footprint of the code, or increasing the execution efficiency of the code. So these are some of the checks what you can put while generating the code. And then tool can generate a custom code according to those checks.
However, these are just the surface we are scratching for embedded code generation. There are a lot of settings, which typically you would you can understand or explore by going through some of the training curriculum what we have on embedded code generation or talking to our application engineering team who focuses on the code generation workflow.
Yeah. So that brings us to the end of our session. And thanks to you, Veer, Abhishek, and Rahul, for the wonderful session. And also, thank you to all our speakers today from Mahindra and Bosch as well for sharing insightful presentations.
If you have any questions or any problem statements that you found interesting today and you want to again explore, please feel free to reach out to us. We are available here. We can talk more about it. So thank you for joining us today. Thank you.
Thanks, everyone.
[MUSIC PLAYING]