Building Your Virtual Vehicle Simulation with Simulink
Overview
A virtual vehicle enables engineers to shift prototyping, integration, and validation to simulation. Depending on where a team is working along the V-cycle, the requirements for their virtual vehicle would vary. Building and maintaining multiple virtual vehicle simulations can be expensive. Use of specialist tools also limits how widely these virtual vehicle simulations can be deployed. In this presentation, MathWorks engineers will present how to build a virtual vehicle simulation using Simulink as a common platform. The overall workflow will be demonstrated through examples that cover a range of possible use cases.
Highlights
- Building an electric vehicle model for thermal analysis
- Building an automated driving vehicle model for algorithm validation
- Deploying a virtual vehicle simulation to the cloud
About the Presenter
Mike Sasena is a product manager focusing on the automotive products developed at the MathWorks office in Novi, Michigan. Prior to joining MathWorks, Mike spent 14 years working on model-based system engineering projects for the automotive industry. His experience includes hybrid electric vehicle modeling for fuel economy analysis, model predictive controls development, and heterogeneous system simulation. Mike received his Ph.D. in mechanical engineering from the University of Michigan.
Recorded: 4 Nov 2021
OK, let's get started. Let me get things rolling here. Hopefully that is sharing correctly.
Yeah, I can see it on my side.
OK, excellent. Well, let's get rolling. OK, so welcome everybody to our webinar here on "Building Your Virtual Vehicle Simulation with Simulink." My name is Brad Heeb, and myself and my colleague Mike will be discussing how Simulink is being used for virtual vehicle development.
This is a topic that MathWorks has been focused on quite a lot over the last few years. And what we're going to do today is provide an overview of what virtual vehicle simulation means, how you can perform these simulations with MathWorks tools, and highlight some new capabilities and best practices that you can use to help realize the benefits of virtual vehicle simulation for your work and your applications.
And as Mike pointed out a moment ago, if you do have questions during the presentation, yeah, please do put those in the Q&A. We've got a lot of time left at the end, so we should be able to get to those. So with that, we'll get started here. Let's see if I can make it advance. There we go.
So a couple of key points to keep in mind as we go through the presentation, MathWorks has taken a very balanced approach to helping customers build their virtual vehicle simulation capabilities. On the one hand, if you look on the left of the scale here, we have a very powerful platform that has lots of out-of-the-box capabilities needed for this kind of work. And we continue to invest heavily in this area, and to offer new features and products to provide the most complete and comprehensive solution available.
On the other hand, on the right-hand side of the scale, the platform is very flexible and open. And we do that because we recognize this is not a one size fits all proposition. Our customers often have unique requirements, so they need tools that are flexible, adaptable, that sort of thing.
So MathWorks tools are well known for that flexibility. And customers leverage this to create the custom solutions they need that work for their particular and unique use cases. And we've been helping customers build these virtual vehicle-type simulations for literally decades. And we can use the experience and expertise that we've accumulated over that time to provide guidance and support as needed for your specific applications.
So let's take a look at an example of an out-of-the-box capability that the Simulink platform offers to scale up testing and algorithm using virtual vehicle modeling. So suppose I'm developing a lane following controller, and I want to run regression tests every time I check any changes to any of my algorithms.
And these regression tests consists of vehicle scenarios designed to exercise the algorithms, I should say, under a variety of conditions, such as driving on a straight road, or a curved road, or maybe I'm in different lanes, where I have different vehicle oncoming traffic conditions coming at me, those sort of things.
So to perform these tests, I'm going to use a virtual vehicle model, which has a scenario input subsystem. This is where I inject those different traffic scenarios I mentioned, so that I can test my lane following controller, which in the center of that model.
And the output of a Lane Following Controller then sends signals to my vehicle dynamics model. And that model responds to those signals and calculates the position and orientation of the vehicle at every time step. And I've also built in some custom test metrics that allow me to assess or assign really a pass/fail criteria for each of those scenarios that I run through my model.
Now, if I'm in a situation where I only need to run a couple of these, running on a desktop would be fine. But very often, you may need to run hundreds, thousands, or maybe even tens of thousands of these simulations. And even if each of them only takes a few minutes to complete, you could still end up waiting several hours or perhaps longer to get your results.
So to avoid those kind of delays, what I'm going to do is scale up my virtual vehicle testing up to the cloud so that I can run these simulations in parallel. So to do that, what I'm going to do is use what's called a MATLAB reference architecture. And we use that to set up and instantiate a virtual machine instance on the cloud. And in, this case, I'm using the Amazon Web Services cloud.
And the nice thing about these reference architectures is that they make sure that all the software I need to run my regression tests, MATLAB, Simulink, Stateflow, whatever the case may be, all that stuff is going to be installed automatically on that remote machine. And what that allows me to do is then take my test files, in this case, my virtual vehicle model from my local desktop, transfer it over to my virtual machine, and then I'm ready to get started and run it.
So let me show you what this looks like when I run these tests. So what I'm going to do here is run a video. And it's going to start off with me already logged into the Amazon Web Services cloud machine that I've set up. And I'm using a remote desktop connection to do that.
And I've already transferred the virtual vehicle model over along with my scenario tests to that virtual machine. And then when I start the video, what I'm going to do is I'm going to fire up a program called Simulink Test. And it brings up the test manager. You can see the scenarios I want to run. I hit the Run button.
I have it enabled in parallel mode. And I set it up to run four tests at a time so you can see something going on here, but not so many tests that it clutters up my display. We sped up the vehicle-- I'm sorry-- the video playback by a factor of 20 so we could get this testing done in a few seconds instead of a few minutes, which it would normally take.
Now, when the tests complete, Simulink Test automatically generates a report for me. And I can browse through that report. I can look at the table of contents. I'm looking to see if any of my tests have failed, like this one here that I'm clicking on. And if it does, I click on that, go into the test, look at some of the details, try to figure out what's going on, what has failed, and what I should do about it to correct it, which is why we do these regression tests in the first place.
So, of course, that example that I just showed you is just one of many ways you could use a virtual vehicle simulation capability. Some of our customers have presented how they've used virtual vehicle simulation at recent events like the MATLAB Expo in the MathWorks automotive conference.
Ford talked about how they've automated the process of building a virtual vehicle model from months down to just a few minutes. And they leveraged our consulting services organization to build out that capability for them. GM, they presented on the development of autonomous parking features. And Bosch described some work they were doing with autonomous truck development.
So while these projects showed a wide range of different use cases for a virtual vehicle simulation, they all had common themes, such as automation of the model, creation part, the part where you're putting things together in the beginning, and then the simulation and analysis phases.
So the rest of this presentation, we're going to start with Mike taking you through some of the challenges to achieving the benefits of virtual vehicle simulation. And the two of us will describe how MathWorks tools can help you then overcome those challenges. So let's begin by describing some common challenges with virtual vehicle simulations.
All right. Thanks Brad. So if we go on to the challenges, one of the first things that we think about is, what is the Virtual Vehicle? Simulation here you have a diagram that talks about, you've got your chassis. You've got your Powertrain driver, controller, sensor, environment. You have all these pieces that together form a virtual vehicle.
But it's more about what you do with that virtual vehicle. And that's what those are workflow steps are along the top, showing how you can step through different portions to actually do something interesting with that model. Once you have the model, now you can start to front load a lot of your development activities. That's what brings in the savings on time and money.
But, of course, there are challenges to actually getting that virtual vehicle model ready. So if you step into the first one here, creating the virtual vehicle. So this challenge is often about the plant model. How do I pull together the right plant models, the right sensor models that are the right fidelity for the particular use case that I have in mind?
How do you calibrate that model with the data that you may have on hand to be able to meet the needs of the specific simulation you have? Once you have that model, now you can integrate in the software. And so there are different challenges associated with that, such as how do you pull in-- I guess there's a bit of a lag here. There we go.
So there is challenges in standardizing the interfaces and the data management. How do you connect the plant and the controller together? And then how you access that across the team, making sure that everybody has the models and the software that they need?
And sometimes that software is in the form of Simulink models. Sometimes it's in C code. Sometimes is is S functions or FMUs. So there's a variety of ways that you need to be able to integrate those pieces together.
The third challenge is about authoring scenarios. And this is where you need to now have that vehicle running in some kind of an environment. Maybe it's a 3D environment, or maybe you're just specifying input trajectories for your scenarios. But you need to define those scenarios, and then link those test cases back to the requirements that you have to see if the model meets the needs that you have.
The fourth challenge is in simulation and analysis. So at this point, you're now running those sims, but you need to be able to post-process and visualize the results to make meaningful decisions based on those results.
Sometimes you're generating reports and you want to automate as much of that as you can. Or you want to scale up and do large numbers of simulations. So there are a lot of challenges to just executing these kinds of things at scale.
The last challenge is in deploying the simulation. So I may want to take what I've created, and then get it into the hands of other people in the organization. So how do you deploy them effectively to people that may not be expert tool users? Or how do you deploy those models for other use cases, such as software or hardware in the loop settings?
So those are the high level challenges that we've talked to our customers about. So the next version of the presentation, Brad and I will walk you through that same workflow again, talking about the solutions that MathWorks has to help you overcome those challenges.
So if we go back to the beginning of that, we start with the create vehicle. So a lot of our customers they'll create what we call in-house vehicle models. So they may be using some of the base Simulink block libraries, or other things that they built up themselves, to create some kind of a virtual vehicle model.
And MathWorks often will help these customers to apply best practices. We've been helping people for the better part of 30 years on automotive models. So how do we help them to create the models that meet the needs that they have based on what we've learned?
We've also taken our knowledge and introduce reference applications. So we have new products that help customers have a complete vehicle model out of the box, so you can just open it up, press play, and start to do some analysis for Powertrain vehicle dynamics, ADAS-type applications.
Now, you'll see in the lower left corner there's links for more information on these. You'll find that throughout the section of the presentation so that when you get the PDF of this later, you can follow up on those links and get more information about the particular items we're talking about.
So beyond just having these reference applications, you may want to customize it. You may want to take what you have as a starting point and augment it with either the libraries from Simscape, or Simulink, or other in-house models that you have to complete the vehicle model.
You may also want to bring in tools from third parties. So there are over 100 connections partners MathWorks that create automotive simulation tools. So how do you pull those together? There's lots of capabilities we have with Simulink as an integration platform to get all those pieces running within your virtual vehicle model.
So in terms of where we've been investing lately, one example would be in this battery EV model. So we launched one of the Powertrain Blockset examples with this EV. But we've been investing in that recently. So on the left side, you can see a Battery Management System that we introduced as a way to have a more detailed controller for those that are looking for that level of fidelity in the controls.
We've also incorporated in Simscape components so you can model the battery in the HVAC cooling system, which allows you now to have a much higher fidelity thermal behavior, so you can capture those effects that are quite important for some of the analysis that you may be running.
In addition to the battery EV, we've also introduced a fuel cell model. So in R21A, the Simscape PEM fuel cell system model came out. So it's a way to look at that fuel cell stack model. We, in 21B, incorporated that system model into the vehicle-level model that we have.
So you can now have the controllers around that, and the driver and the rest of the vehicle system. So you can either test it as an isolated subsystem, or within the context of the vehicle simulation. We've included other kind of calibration workflows to give you additional tools to use with that.
In terms of non passenger vehicle, we've also been incorporating new models there. So you can see we've done some work on motorcycles. So we've introduced a braking test for motorcycles where you now have some new blocks that include things like the upper and lower front fork, and the rear spring arm and the main frame for the motorcycle.
And then there's chain drives you could use for either an electric motor or a gas-powered motorcycle. And with that, you have now an ABS algorithm to see how does the braking work for a more advanced braking system than something that's just a simple pressure command.
We've also invested in trucking applications. So we have tractors and trailers that we've been releasing for the last several years, where we have different degrees of freedom depending on what it is you're trying to do with the models, and different number of axles depending on the application.
We have also the front and rear hitch options for those rear trailers, so you could have doubles and triples if that's something you'd like to analyze to look at the system response or test the Swept Path that you're going through over different turning maneuvers.
So with that plant model in place, now it's time to start integrating in that software. And Brad will talk more about that next. Brad, you're muted. It wouldn't be a webinar if somebody didn't do that.
Yeah, I'm sorry about that. My little button here on my thing doesn't work. So I'll use the other way, sorry. Anyway, so as Mike said, once the vehicle model is assembled, now what we can do is move on to the next step in the workflow, which is the integrate software step.
And what we're going to do here is connect the virtual vehicle model to the algorithms that we want to test. And so those algorithms can come in a variety of different forms, which is why our platform supports a wide range of different integration techniques. So, for example, some customers, they have algorithms implemented in Simulink. And so that's straightforward. It's kind of just a cut and paste operation. You plop them in, so not surprising.
And as Mike mentioned, Simulink has supported integration with third party tools for a long, long time, decades really, using S functions. So that supported, well supported, in fact. More recently, we've been offering support for the functional mockup interface standard, the FMI standard for importing co-sim or model exchange FMUs. We can also export those.
And it's also possible to integrate C code directly into your Simulink models. And there are a variety of techniques available to do that. You just kind of pick the one you need based on your particular use case. So collectively, these techniques give you a very flexible platform to integrate algorithms from many different sources into your virtual vehicle model.
So what I want to do next here is just show you how you can use what we call a C function block, just one of those C software implementation methods, to easily integrate your C code into a Simulink model. So a little context here, let's say you've assembled a virtual vehicle simulation model like the one I'm showing here on the screen.
And you want to use that model to test lane mark detection algorithm that some of your colleagues have developed in C. And what I want to do now is look at how to integrate that code into your virtual vehicle simulation, where I've got the red box there, in a few simple steps.
So what I've got here is a video I'm about to show. And what I'm going to start with is the external C code that I want to integrate, what I'm showing here in this screenshot. So when I start the video, the first step I need to do to integrate it is go into the model, go into the configuration parameters, and tell it what header files, C source files I have, where they're located, and then specify any libraries that I might need to run my external code.
Once that's done, I'm going to drop in the C function block. I'm going to double click on it. And I'm going to configure it so that it calls the appropriate external function for every time step, other external functions I need for initialization and termination if I need to, and then I can actually specify the output, input output signal names and their data types, and then I'm ready to run it.
And here I'm showing the results of that. We're running a traffic scenario. And we're looking to make sure that the lane marks are detected correctly. And you can see that I've got that going. It's working well. I've got the red lines and the green lines here doing what I expect. So now that we have a vehicle model, we've integrated our software, we need a way to exercise it.
Thanks, Brad. So there are lots of different ways to create those scenarios. MathWorks as a few different tools. One we're showing here is called Driving Scenario Designer. That's an app with an automated driving toolbox. And this we sometimes refer to as the cuboid scenario world.
So it's where the cars are represented as simple boxes as a way to show how you quickly put together the lanes, and where the cars will move during the course of some kind of scenario that you'd like to set up. You can then share that with your MATLAB and Simulink models to continue the workflow and the analysis.
In addition, we have a tool called RoadRunner that we recently introduced. This is a program-- and it's frozen on my side-- there we go. So this is a program that's more for like the 3D visualization where the photorealism is more important for perception testing of something.
So you can see you can set up the lane markings. You can add different trees and other objects along the sides of the roads, the sidewalks. You can specify where the cars are supposed to be moving through those intersections, as well as setting up the traffic lights and things like that. So this gives you the capability then to create a more realistic scene, and then export it into other environments such as Unreal, Unity or CARLA to close the loop with the rest of your analysis.
So, in addition to that, you may want to then set up a sequence of these scenarios where you could use something like Simulink Test as a way to define a sequence of operations that you'll run in parallel, and then generate some kind of a custom report once it's done to look at the results of that, as Brad showed in the beginning of the video. So some more links there for you to follow to get more information on that.
One more example to show, and this is using RoadRunner to create some kind of a vehicle dynamics test. So here we've set up a road, a straight road, and put some of the speed bumps on it. And then we can use the Profile tool here. You could set a few waypoints and then change the height of the road at these different locations to create a hill.
And then put some grass around that, and now that I got the road, I can start by exporting that to Unreal. Now, Simulink has this connectivity the Unreal Engine, so I can then bring in my vehicle dynamics models and start to look at things like, what is the suspension travel as I go over these speed bumps?
So this gives you a way to test out that vehicle-level response with the scene that I just set up. You can also test out some kind of Powertrain capabilities, by looking to see, does that vehicle climb the hill that we've specified effectively at the target set speed?
So using RoadRunner, you can then create those scenes that you need and test them with the closed loop vehicle model. So at this point we'll talk some more about simulation analysis.
OK. Thanks, Mike. So now that you've assembled a virtual vehicle model. You've integrated your controls, created test. Now you can run simulations. And when you do that, you're going to produce data that you're going to need to analyze.
And when you do that, you're going to need to generate-- or you're going to have the ability to generate plots, or animations, or even automatically generate reports, or even create other tools to inspect the data and acquire insight from it so you can learn from it. And the flexibility of MATLAB is what makes that all possible. And it's always been one of its core strengths.
And as we mentioned previously, you may need to leverage parallel execution as part of your work. And for that, MathWorks tools can be scaled from running local multicore simulations, to running on a GPU, or maybe even deploying them all the way up to the simulations up to large computing clusters or on the cloud. And you can do all of that without the need to rewrite your simulation execution code, which is a huge benefit.
So here's another example of using parallel computing. And, in this case, I'm using it to help speed up the process of generating a reduced order model from my high fidelity, from my high fidelity model. So what I'm showing here is a screenshot of a Powertrain Blockset engine dynamometer reference application.
And what I'm going to do is plug in a very detailed, high fidelity, GT power engine model into this reference application model, so that I can automate the conversion from the detailed GT power model to a reduced-order Simulink, what we call mapped engine model.
And the way we do that is we run simulations to exercise this high fidelity engine model at a lot of different torque speed operating points. And then at each of those points, record the steady state engine response. And these reduced-order models, like this mapped engine model I'm describing, they're very useful in situations where I don't need a high degree of model fidelity. Maybe I'm doing some kind of system level analysis, or maybe an optimization study, for instance.
So to do this work, I'm going to again use that same approach that I showed at the very beginning where I instantiated a cloud machine instance, again, on the Amazon Web Services cloud. And what this allows me to do is take my virtual vehicle model, in this case, my Powertrain Blockset reference application, and the GT model files from my local PC, transfer them over to the remote machine on the cloud, and then I'm ready to go.
And the reason I'm doing this is for a couple of reasons. One, I want to take advantage of a machine on the cloud that has a lot more powerful computing resources than I have available to me on my desktop, for instance. And secondly, by moving that stuff over to the cloud and running it, I offload that work from my local desktop. So I'm free to do other tasks while that's running in the background, so to speak.
So let me show you what this looks like. So, again, I'm going to run a video here that starts with me already logged into this Amazon Web Services machine using remote desktop connection. As I mentioned, I've already transferred all the files over that I need along with my reference application.
And so when I start the video, what you're going to see is me double clicking on that green button there, which starts the conversion process. And now the Simulation Manager pops up. And I'm able to watch the various workers that are running in parallel, check their status.
I can even look at signals coming back as the simulation is progressing. In this case, I'm looking at the engine's output torque and just putting that into a surface plot so I can look to see if there's any anomalies, things that are strange that I might want to investigate.
Running this stuff on the cloud as I just showed here enabled me to get about a 20 times speed up versus me doing the same thing on my desktop in a serial fashion, which is a big deal. That took it from hours down to minutes, basically.
Now, if I take the reduced-order model that I just generated from this process, and I plug that thing into a virtual vehicle model to do some system-level analysis like an FTP-75 drive cycle, I observe basically only about a 0.3% difference in fuel economy compared to running that same FTP cycle with the high fidelity model.
So that small trade off in accuracy enabled me to get a 50 times speed up in execution speed, which is exactly what I was looking for in this kind of a case, and why I would go to a reduced-order model in the first place. OK, so at this point, we built models to integrated software. We've run simulations. We've analyzed results. And now what we want to do is deploy these virtual vehicle simulation environments to make it easy for more engineers to take advantage of them.
Yeah, and there are a lot of ways in which you could do that. So you can build custom UIs around some of the things that we've shown today. You can even create installers so that you can send it off to your colleagues as, say, a MATLAB app or a standalone desktop executable. You can send it as a web app or an FMU. So there's lots of capabilities as to how do you deploy that to your colleagues.
Of course, code generation from MathWorks has always been a strong suit, so you can generate code for SIL and HIL testing. You can also then deploy those models, either Simulink or Simscape models to the cloud through things like Databricks. So there's a lot of capabilities just on the deployment side, and there are some links there to follow to show you some additional examples of that.
In terms of FMU capabilities, we continue to invest there. So in recent versions, we've added the ability to have the C code included with your co-sim export. So now you can deploy to other platforms such as Linux or Windows.
And you can also make it easier to connect the model arguments you may have in Simulink with your FMU parameters to make it easier to define those things in the model description XML file. And we also now support nested FMU export, so a few capabilities to make it easier to deploy those models out.
One last example here is a web app example. So what we've done in this case is take those reference applications for one of the Powertrain models and deploy it on the cloud, or in this case a web app. So you're actually just logging into a web client. And then you can do things like select the drive cycle that you may want to test. In this case, it's just an FTP 75.
And then we've created a custom UI where you can expose just a subset of the parameters that you care about for your particular needs. And maybe you have sliders or other ways to set the values for those parameters. But once you've got them, then you can set up your simulation.
You can select which of the responses that you've exposed, do you want to start looking at while the simulation is running. And it'll go off and perform those simulations. When it's done, then you can compare it to previous results that you may have stored, or you can generate some kind of report to look at those results offline.
So the idea here is you can take those models that you built, the virtual vehicle, and then create some kind of a purpose-built interface to it, to help the people that are the end users to use it more effectively, that they may not be to experts, but they don't want to get the benefits of this virtual vehicle. And so now I think at this point Brad, can you tie together a lot of the things we've been talking about today?
Yeah, thanks, Mike. So we've just shown you a lot of capabilities for building, running, and analyzing these virtual vehicle simulations. And we can also help you apply those capabilities on your own. And so while our platform remains flexible enough for our customers to create the solutions they need, it's not always that they have the resources, experience, or the time to do this efficiently. It's not always the case.
So in these situations, our consulting services team is ready to help you in a variety of ways. So, for example, they can provide expert-level guidance for creating these virtual vehicle models, or infrastructures really, at your installation. They can automate various processes to improve your team's, productivity and they can create these custom UIs or tools to provide specific solutions that you need for your particular application.
We hope that this presentation has given you a better understanding of how MathWorks has been investing to provide a platform with powerful features and capabilities that you can use to support your virtual vehicle simulation efforts, and at the same time, though, maintaining an open, flexible environment that can be customized to suit specific use cases or requirements.
So here's our contact information. Please feel to reach out if you have any further questions. We'd be happy to speak with you. We're going to open a poll here so that we can try to understand a little bit more from you, which parts of this virtual vehicle workflow that we went through, those five steps, may have caused you the biggest challenge?
It could have been none of them, several of them, or all of them. We're just trying to get a feel for that. And so take a few minutes and have a look at those questions. At the same time, we did go through this rather rapidly and we had to keep the discussion at a very high level.
So if anything you heard piqued your interest and you'd like to get more details, please let us know and we can follow up with a meeting, conversation, whatever we need to get to the depth that you want in any of these particular areas. So you can indicate that in the chat or on the Q&A, I guess, as well.
And, yeah, and if you have any additional comments, I think the last question allows you to put that in as well, if you wanted. And that's, I guess, that could be, hey, contact me. I'd like to learn about A, B, and C, stuff like that. So let's see here. So I guess we're going to run this for a few minutes and see how this is going.
One comment while people are filling out the poll. So there's sometimes questions about, how would you integrate this with some kind of a CI-type environment? And if you haven't seen already, we actually have an entire session dedicated to a CI in continuous integration-type workflows.
That session is tomorrow. So I just, in the chat window, pasted a link to that page. So I'd encourage you to go check out that session if that's something you'd like to learn more about there.
Yeah, that's a good one. That's a good one. Because that's, for example, that kind of ties back to the very first example where, hey, I've got regression test suites. And I showed it going manually, where I went up there and did it interactively.
But that certainly could be automated, which is what-- they're going to talk about that and that webinar that Mike just indicated. So that might be a good thing to pick up. Let's see, are we able to see-- let's see if I can figure this out.
Yeah, I think we'll check with the polling as we go here. So, again, just encouraging you to use that Q&A session. There's a couple of questions that have come up during the presentation. So let's see. One of them, Brad, maybe you could speak to this a little bit. The question is, in addition to integrating controls algorithms in your vehicle model, does MathWorks have a solution to implement serial communications, CAN or LIN, so multiple controllers can talk to each other?
Oh, yeah, that's a good one. So, yes, the answer is yes So you can do-- we have specific tools. For serial, I think you'd probably use-- I think you probably borrow some capability out of an instrument control toolbox. So you could set up a serial communication connections, which I think that's the right one for CAN.
I know this one much better. This is the Vehicle Network toolbox. So you could very easily do that. And what you'd have is, you'd have basically going to drop blocks in that set up the transmit and receive connections.
And then there are facilities like in the CAN case, with vehicle network toolbox for packing signals into messages, unpacking them, specifying DBC files to make that easier for you. So, yeah, the short answer is yes, you definitely can do that. And we've worked with customers who have done that successfully many times. So I'd happy to talk about more that topic in more detail.
Great, thanks. There was also a couple of questions over the course of the chat about whether the slides would be available later. So, yes, the plant is that there will be a follow-up email after the event. You'll have a PDF of the slides. And that's why we put all those links into each of those sections, so that you could refer back to this material and learn a lot more.
I think the goal for Brad and I today was to give you this 30,000 foot view, to give you an overview of all the capabilities, and then give you the links you would need to follow up and give you the ability to reach out to us when you have questions now that you have a better understanding of the broad stroke capabilities we have.
There was another question. Brad, I'm not sure if you can answer this one or not. I'll have to think. So in driving scenario acceleration of the vehicle, of the target vehicle, so unless I'm mistaken, I think Driving Scenario Designer thinks more about the world in terms of specifying the position of the vehicle over time, like you're not specifying the acceleration of it?
Yeah, I think that's right. I think it's basically, you specify a trajectory, and it will just follow that. And you may be able to tell it how fast it's driving on that trajectory, but I don't believe that-- I'm not an expert here on this one. But I think it's more about, open loop, here's a trajectory, here's the path, it goes on that.
Yeah, if you're looking more for a closed loop scenario where you want to provide essentially a reference speed and let the vehicle try to match that by hitting the acceleration in the brake commands, then we have other tools like Vehicle Dynamics Blockset to take that approach.
So it depends on whether you want to just explicitly say, here's where the cars are in time, versus this is the trajectory goal, and now find out what the vehicle actually does to try and match that. So I think different takes on how you would want to approach that question.
So this is great. I'm seeing lots of questions come in. This is .
OK, cool, cool.
Another question coming in. Is C code incorporated into the Simulink model debugged during simulation with breakpoints?
Yeah, I believe that the answer to that is yes. You should be able to-- there are some requirements. I think you may have to use Visual Studio, or some kind of a IDE available. So we may have to follow up with an exact answer on this. But let me give you-- there's another thing that we've done.
So I've done this with-- I'm trying remember the exact case, where I had a DLL that I was running that was separate, that I was calling from Simulink. And I had the source code for that in Visual Studio. And I could-- there is a way of setting break points.
And step through the simulation, it halts when it hits a breakpoint in the source code. So very confident the answer is yes. The exact details of how you do it escaped me. But I do remember you had to have a IDE on board to do that.
Those are the kinds of things, the application engineers, we have a whole group of them, people like Brad that we can bring in and show you guys how to do those. So if you have questions, we'd be happy to support you on those.
Yeah, that's a good one Yeah, that makes sense.
There's another question here. If you're developing a new model, would you recommend using Simscape from the start, Vehicle Simulation Simulink, and then add Simscape later to add complexity? So that's a question that often comes up. We have different ways to build vehicle models depending on what it is you're trying to do.
And there's not a hard and fast rule as to how customers tend to do this. What we tend to see, generally speaking, is that people that are doing more design-oriented tasks, where they're focused on how do I design a specific subsystem where I have to have a lot of multi-domain modeling with thermal and fluid and mechanical, that seems to be a good fit for those kinds of approaches. So electrical modeling, things like that.
But when people are interested more in the system-level perspective, then the pre-built vehicle models that we have with things like Powertrain Blockset, Vehicle Dynamics Blockset, those are a good starting point for those customers. And then they will often augment them with Simscape to add in the particular detail.
So, for example, that example we showed at the beginning of the EV reference application, the battery EV. So we started with, originally it was all just Powertrain Blockset, Simulink-based library blocks that were used to create an EV model. And then in the 21B release, we added in the capability of selecting a variant, where you would switch from that block library to a Simscape-based block library.
So you could have things like the two phase flow for the cooling circuit. You can have a Simscape electrical network for the battery. So it gives you a different modeling approach to answer different kinds of questions. And they do complement each other.
It's just a question of where you need to start, and whether a prebuilt, complete vehicle model out of the is what you're looking for and then you augment it, or whether you're doing a design-oriented task and you want to start with those multi-domain tools. So you have a variety of tools at your disposal.
Right, I mean, just to add on to that, I like the idea-- a lot of customers like the idea of having that structure of the prebuilt models that gives them something, a kind of a scaffolding that they can then plug in things. We see that as being pretty popular.
So another question came in about motorcycles. So is the motorcycle reference application available in 21B release, or when that would be available? Yes, so in 21B we have a few different ways you can access that. So in the Vehicle Dynamics Blockset, we have both the block library for the chassis and the chain, as well as a braking example.
So you can kind put those together. Or they've already been put together into a braking example with an ABS controller. Powertrain Blockset that shares the block libraries, but we haven't yet put together the complete vehicle model to show that with one of those reference applications. That will come over time. But you have access to the block libraries for either of those two components there.
Let's see a question about FMUs, so once an FMU representing a virtual ECU has been integrated into the vehicle model, can Simulink connect to INCA or other calibration tools while the simulation is running for live, virtual calibration of the FMU?
This relates to things like INCA-SIP. So INCA has a program for a Simulink integration protocol. I can't remember exactly what they call it. But ETAS offers a way to connect their INCA machines to a Simulink model. And if the Simulink model has the FMU in it, there are ways to do the connection.
That's not something I do myself, so I can't speak to the details on it. But that would certainly be something we could follow up with you and find the experts there to answer that kind of a question. Let me take the questions here. Get more and more questions coming in. It's great.
Maybe another C code question for you, Brad. For C code integration in the case of MBD can I use C code integration from an embedded SDK to generate the code on the target?
Let's see if I understand that one. So embedded SDK to generate the code on it. Can you read that back to me? I'm not sure I get what the person is asking.
It says for C code integration in the case of MBD, can I use C code integration from an embedded SDK to generate the code on the target?
I think-- I'm not exactly sure I understand the question. But on, I guess, is if they're talking about generating code from-- it's in a model, so they have-- maybe they've dropped it in, and they've done some work from Simulink. And then they say, OK, now I want to generate specific code for an embedded target. And I already have this code in the model. How do I do that?
If that's the question, that I'd have to give some thought to. There should be a way of doing that with a custom TLC file, for example, so we omit the right kind of code, and we just bring the source code along. I don't think that's probably what they're asking. So I'm a little bit-- I guess I'm confused by the question, sorry.
So we can defer that, then. And if there's a follow up question, then of course, the author of the question, feel free to reach out to us. You have our emails here, and then we can get more specifics on that.
And they might even throw it in the chat before we exit. Sorry, I just I'm not sure I understand. I need some clarification, I guess.
For sure, for sure. There is another question said, are there any teaching videos about car modeling or virtual driving scene construction? So there are a lot of videos out there that we have. There is one I just put as an answer to that. And actually, I'm not sure, I'm assuming that everybody can see the Q&A responses in there as well. I'm not responding privately.
So those should be visible. But I've put in the link, and I'll just put in the chat as well, just to make sure. But there is a video series that we published maybe a year or two ago on how do you model hybrid electric vehicles with MathWorks tools. So it walks through a variety of different modeling techniques, and what are some of the different capabilities we have there.
So I would recommend starting with that video series. That's, I think, a good way to get started with that. In terms of the second part of the question, virtual driving scene construction, so just last week we actually published a new video series on using Unreal Engine with Simulink. And that's a way to kind of create those scenes.
So I'm going to look for that link and I'll send you send you the link in that chat window as well. But that's hot off the presses, a new video that will help explain some of that. And actually I think that may even be in the slides. Let me see if I can find the link, and I'll put that on in the chat window as well.
Do we have one that starts with RoadRunner as the scene creation
There is a video series on the RoadRunner. Yes, that one has been around for a while. And then the new one is the Unreal Engine for more general capability.
Yeah, you might, depending on what your use case is, if you-- I'm sorry, RoadRunner is fantastic for building up these road network kind of scenes. And it's a very intuitive thing. So if that's your goal and you want to add even some buildings and other kind of static actors in it, that might be a very good choice. Yeah, and that can be imported into Unreal, of course, you were talking about that.
Yeah, so there's different options there. So I put the-- I found the other link for the Unreal Engine series. So there's that. And there's some other tutorial video series on RoadRunner as well. And I think we have links to those in the slides as well.
OK. I think we do.
Another question here, how do you optimize existing models provided by MathWorks to match OEMs with data? So it's a bit of a calibration question. Do you want to start that?
Yeah, so depending on what you're doing, if it's engine stuff and you want to get that, engine mapping, engine response services, yeah, we have techniques. if. You're working with an OEM and they provide you data for that particular engine, we have techniques for using that to fit our models to that, so they'll respond in the same way.
In a similar vein, if you're worried about the chassis, a typical way that OEMs will characterize their suspensions, they use a thing called a K and C, kinematics and compliance test. And they do that routinely. They have this data available. We'll be able to-- is it 22A, I think when that block ships, we can bring that in.
We've been doing some work locally with that. So that data can be brought in and used to basically parameterize a vehicle dynamics model so it matches the chassis dynamics of the particular vehicle you're thinking or that you're developing. I hope that answers your question.
Yes, there's lots of different techniques. I mean, we have different blocks in there. Brad was talking about K and C. We also have things like for the engines, in some of the engine blocks where you can just click a button and then import some Excel data that you may have from a dyno test, or something like that. There's things for the motors, and compressors, and turbines. There's all kinds of things like that.
We use a Pacheco Tire model, so you can bring in TIR files if you have that. So that's all supported.
Yeah. Yeah, and they're often related questions we get from customers about, how have these models been validated? And so our answer to that is, MathWorks doesn't own a dyno test rig. So we don't have a lot of vehicle test data of our own. So what we often do is work with our customers that have that test data.
And then we will calibrate the models for them, or show them how to use our tools to calibrate them. And then they look at that, and they've always been quite satisfied with the results at the end of the day. We can't share that data, though, because it is their IP, and that's why we don't publish that data.
But we have published certain conference papers we've done or different webinars that we've hosted. So for example, Cooper Tire, who's part of the Goodyear family, they did a presentation with us a few years ago where they showed how they had some test data from the track and also from the tire, just the tire test rig itself and how they validated that against the models that we had.
There's also examples where we've taken tire test data, MathWorks has purchased test data from a place like GCAPS over at one of the Virginia Tech spin offs as a way to encapsulate the tire that we have, so you could have just a pull down menu of choices for tire data available in the models. So there's a variety of ways which we try and get the data into those models.
OK, going back to the chat and the Q&A. I see a question here. Or it looks like it was a clarification maybe to that question we had earlier. I wanted to generate code for a target, and I want to use the I2C API from SDK. That doesn't mean anything to me. I'm no expert in this area. But I don't know if that means anything to you.
Yeah, I don't know specifically, but I can conjecture that if they want to do that and they want to automate it, then that probably falls in the category of custom target. So this is one of those things where consulting comes in. And they've done this many, many, many times.
So you can use these APIs for these different SDKs or IDEs. There kind of a similar-- some overlap here, to do that. Now, I don't think in that particular case we have out of the box solution. But because we have APIs on our side and there's one there, those things can be constructed.
And we've done this many times. So if that's the case, I'd encourage you to get in touch with us to see if you'd like to have us build that interface for you, then that could be done.
So there's a question that came in. What are the differences between Simscape Driveline and Simulink Powertrain Blockset? So what you see is that Simscape Driveline is part of the Simscape product family, which means it's dealing with physical connections between subsystems. So it's dealing with an equation-oriented view of how do you model a system.
So there's the language that its uses that's different between Simulink and Simscape. And then there's also a focus of the products that are different between them. So Simscape Driveline focus very much on the driveline-type parts of the vehicle model that subsystem. Powertrain Blockset is looking, like it has some aspects of the driveline, but it's much simpler, I'd say, in that respect. There's just a few to choose from.
You're not going to use Powertrain Blockset to design a driveline. That's what Simscape Driveline would be, where you're putting in individual gears, and you're setting the planetaries up, and how do you assemble all those packs together? That's more a design-oriented workflow where Simscape makes sense.
Powertrain Blockset that is more the system-level thinking, where I have to look at a fuel economy analysis, where I want to look at some kind of a shuffle, or something like that. So I may want to then use the vehicle models that already provided prebuilt, and then augment them or customize them as needed.
So Powertrain Blockset includes the engine models, the transmission, the tire, the driver, the controllers, the batteries, the motors. So it gives you broad view of things, whereas Simscape Driveline is focused on that driveline specifically. So hopefully that clarifies that a bit.
Another question, in doing the simulation, can the vehicle tire contact with the ground to determine its effects, any directions? So there are a few different ways that you can model that contact patch. So if you saw in the video, I was showing an example of the vehicle going over speed bumps.
Actually, Brad, can you bring that slide back up?
Yeah, let me go back.
Just type in 26 enter, and it'll take you right there.
Wait, is that the right one?
Uh, 26 enter, well, I'll try it.
Just go to slide 26.
Oh, nice.
OK, let me see if I can get this out of the way, Yeow.
So then if you press play, and actually you can zip it forward to the port, like halfway through that video where it's what's going over speed bumps. So what we're looking at here is, how do you understand where is the ground underneath the tire? So what's happening is we have these things called ray trace sensors.
So it's projecting a line-- yeah, right there is good. It's projecting a line from underneath that center of the wheel to the ground below it. And those little red lines are showing the direction that the ray is pointed, and then that circle is showing where in the scene that it's connected to is the ground.
So as it starts to approach those bumps, it's then using that information. It's kind of taking the average of those different rays to estimate, where is the ground underneath the tire? And so that allows you, not just in pure longitudinal plane, but in other multidirectional things to see, where is the ground contact patch for that tire?
So that's one way in which you can input information. You can also just directly input that information as a ground height, as an input signal to the Simulink model. So you don't even have to use the Unreal Engine to do those kinds of workflows.
If you just have, say, like an xyz surface, you can specify that as a lookup table so that the tire, as it goes through the xyz plane, can give the associated height of the ground tire at any moment during the simulation. So a few different ways to configure that.
Question about headlamps. Is there a way to modify the headlamp light patterns? Yes. So in, I want to say 21A, I can't remember exactly when we introduced this. The block that controls that visualization that you're looking at right now, we added some input parameters to that, where you could specify when did the headlights turn on, when did the brake lights come on, when do I turn on the blinkers, those kinds of lights.
So you have both-- you can send it input signals to those, if you want, to control them for some external source. So that gives you some additional flexibility to control the headlamps there. Not see any additional questions in the chat yet. Can I add headlamp light segments? Ah, so that might be more on the custom mesh stuff, Brad. I don't know if you want to speak to that a little bit.
Yeah, I guess if they-- OK, so if they wanted to have it to where it's not just our standard light source and they wanted to have multiple ones, I believe they could do custom mesh. And then they use what we call a skeletal mesh. And then the bones in the mesh, they'd have to use a naming convention.
And they'd add additional ones, which then-- if they added a bunch more beyond the ones we ship, they could then go into Unreal and use the blueprints or even C++ if they wanted to animate those, provide that capability. So I think the answer is yes. But they'd have to do a little homework on their own to get that done.
Yeah. And that's often where some of the AEs can support our customers out there showing how to bring those workflows there. Sometimes we've also gotten questions about, is there a way to reuse existing models within that virtual vehicle model, and how would you do that? So, Brad, how would you come people that may already have existing models?
Right, so we talked about a little bit. We did it kind of fast. So if you have-- I guess a primary way, if you have models that are, say, in Simulink or even Simscape shape, and you use our prebuilt models, for example. Or maybe you built your own and you can use variant subsystems. So that would be a convenient way you could just drop them in there, in these variants, and then switch on to whichever one you want to use. That's a way.
You can use reference models to plug them in. If you have-- they're in a separate third-party tool, then Mike was talking about that. FMUs would be a good way, even S functions, depending. Some tool vendors, a lot of them, in fact, would you say over a hundred of them, provide this kind of a S function interface, a co-simulation interface. So that's another way. I talked about the C code, if you have it in that form. We have many techniques for just dropping that in.
So, basically, we try to make the MATLAB Simulink environment so it plays nice with everything else, so to speak. So if you have something that you want to get in and it's not covered by something that I mentioned, I'm pretty sure there's a way to do it.
Yeah, and we have customers doing both. We have some customers that start with our vehicle models and add their components in. They customize the prebuilt stuff by putting their components in. And we have other customers that are going to start with their own vehicle models and maybe take some components out of our libraries or augment them with some Simscape or Simuscape, and then augment with the pieces that we're providing. So we have both views, and it's depending on how people are working with the tools.
And, I guess just to emphasize, we fully expect people to want to do this sort of thing. And we're trying to support it very well.
Yeah, and that's the balance we talk about, between giving the prebuilt capabilities with a flexible platform.
Yeah, very much.
Another question about ground contact, and for example gravel road or sand. I don't think we have anything that wouldn't say out of the box with that, but I have seen some application engineers doing soil-tire interaction modeling using Simscape.
I think it was multibody they may have done that with. I'm trying to think if we have any papers or white papers written on that. But we can follow up on that. That's something I don't know the details of off the top of my head.
And that'll probably come down to what kind of tire model they're using, too. That'll affect it.
Yeah, we've had other customers doing things like tread-type vehicles. So there's a wide range out there. And there's some things that we support out of the box, and there's some things that you can customize, too. Maybe one last question we see, are there ways to automate the assembly of a virtual vehicle model from an existing set of components? Brad, you want to talk ?
Yeah, absolutely. So, in fact, that Ford talk that I mentioned, they were doing that. In fact, they had our consultants build that automation. So in that particular case, what they did is said, OK, we want to specify essentially an interface that we-- and they used the CAN network interface definition file, these so-called DBC files, to lay out all the ECUs that they wanted to include in the model, and all their interconnects.
And so you can use MATLAB scripting to go through, parse those files, and basically build the model. Simulink has an API, so you can build the model programmatically. So he did, consultant did that. The model framework is there. And then they had library slots where they could just plug in the various pieces. And they had a custom tool that did that.
So, yes, the answer is absolutely. There's many ways of doing it, in fact. I'm just giving you one example. But typically it's something where, hey, I have some way of specifying my architecture. What's the structure I want? There's many ways of doing that.
Some people are starting to look at our tool called System Composer to do that, to kind of specify that framework. And then you can automatically from there kick out a skeletal model, and then start populating it and establish interconnects. So there's a lot of ways we can go there. So we should-- and so there's not a one size fits all answer. There's many ways of doing.
It's, at least, a very interesting example, how it has done it with Ford. So there was a follow up. Somebody wanted it to touch back on again this idea of calibrating models to match OEM data. So, again, the h level answer to that is, within many of the blocks that we have in the block library, there are buckets where you can, for example, just load an Excel sheet that has the data.
So maybe it's an engine map, or maybe it's a motor map, or a suspension you know compliance data. We have buttons to help you automatically just import that data, fit models to it, and generate a lookup table. And then that lookup table becomes the empirical model version of that response.
There are other tools. We have model calibration-- or model-based calibration toolbox, which are designed very specifically to match data from tests, how do you define the design of experiments, how do you run the test that you need to do, import the data, fit models, run optimizations. So there's a huge variety of how people can tackle that problem.
But some of it's kind of baked in very simply with tools. Some of it, there's a whole tool suite dedicated to that workflow. So it kind of depends on what specifically you're looking at. But we have a range of capabilities. So I think we're at the top of the hour. Brad, any last comments you'd like to share?
No, just hopefully that folks got enough out of this that they, it piqued their curiosity and they want to learn more. So that's what we're encouraging, and hopeful they will be back to us.
OK, all right, so with that, we'll close the session. Again, just to remind you there was another session tomorrow in the CI pipeline if you're interested in checking that out. The link is in the chat. So thank you for your time, everyone. We'll follow up with those slides. Have a great afternoon.
Take care.