Use Simulation to Frontload Vehicle Development

Good day, and welcome to this webinar on Frontloading Vehicle Development Using Simulation. My name is Rashmi Rao, and I work as the Industry Manager for Automotive in The MathWorks India office.

Hello, everyone. I'm Abhisek Roy. I work as an Application Engineer at MathWorks, focusing on plan modeling and control system design. Thank you.

We all have heard about the megatrends of case that is shaping the automotive industry. But thanks to these megatrends, the nature of the future vehicle is also changing. It is becoming increasingly defined by the software that goes into it.

In a recent report that McKinsey brought forward, they call out to automakers to view software as the primary driver for all development efforts. So what we are seeing is an industry that has been essentially mechanical centric slowly transform to a software-centric approach.

So what does this mean for organizations and for engineers like you and I? The first factor is that of increased complexity and multi-domain systems that need to be now integrated. Even if the software is increasing, the time to market is not. And typically, the software is always ready before the hardware or prototype vehicle which calls out to increased front loading and increased validation efforts for the software.

Along with this transformation comes the need to re-skill and up-skill to learn these new technologies; something that a lot of engineers working in new areas are experiencing today. Further, organizations have to be ready now with more agile processes like continuous integration and continuous development. Last but not the least, with more software and more compute power our vehicles today are generating a lot of data.

How do they manage that data? How do we leverage that data? And how do we maybe even monetize that data-- Is a question that a lot of organizations and teams are asking.

At MathWorks, we believe from experience that simulation can be the enabler and mitigate many of these challenges. Simulation essentially means using models for better understanding because they do not call for expensive hardware or expensive test tracks or vehicle prototypes. They dramatically lower the barrier to design, prototype, test, and then take to a vehicle.

Models also improve the understanding, which means collaboration between teams and across different disciplines is made easier. Models can be used to train newer engineers or engineers who are beginning to work on newer technology areas. Models and simulation allow validation engineers to test use cases that would otherwise have been difficult to do on a real vehicle. It also allows for defined and systematic processes, so you can scale your work from a desktop right up to the cloud without loss of legacy work.

And if you are a data scientist or a domain expert, simulation framework can help you to process, build, test, and deploy AI algorithms as you undertake the journey with data that is being generated from vehicles. But that is not all-- the real benefit of productivity comes from automation. And simulation and modeling means that you can use automation to the maximum.

Automation is the biggest multiplier for verification and validation in the vehicle development. As an industry, we have all understood on moving from a vehicle prototype to a HIL system to frontload it. However, the need is now to further frontload to a software and loop system or maybe even a modeling loop system.

And with this increased demand of frontloading, we have to also integrate systems or systems of systems to be able to have meaningful simulations. So the question that is being asked now is, how can be frontload from lab to math? Or as we like to call it, a lab to a model? And can we build a virtual vehicle instead of a real prototype vehicle that can help us to do a large part of vehicle development early on?

Over the last 35 years of being in the business, MathWorks has invested heavily in individual components of a vehicle from powertrain blocks to vehicle blocks, and we have also given users the flexibility to model with different levels of fidelity depending on the use case that you're trying to simulate our model for. Now we are looking at how we can integrate these different pieces to work with our customers and bring to them what we call as a virtual vehicle.

MathWorks defines a virtual vehicle as a functional simulation of full vehicle behavior which is capable of supplementing and/or even replacing a prototype vehicle for a specific set of tests and analysis. And of course, we have been working with a lot of customers on the area of front loading and the virtual vehicle.

So here are a few examples that I'd like to talk today of how we have worked with our customers and what are the use cases they have employed for such a virtual vehicle. The first story comes from Tesla.

In 2007, before the world knew Tesla as Tesla, when they were an up and coming startup trying to develop an electric drive train with the constraints of time and cost, they chose to work with MathWorks. They built the simulation of a full vehicle in order to optimize the drivetrain in order to make selections of components, such as battery and motor.

The second screen shot is showing you a more recent article from 2020, where Tesla talks about how they continue to beat most other players in the range game. They speak about how they have built a simulation of the entire drivetrain and continually tweak the systems to get the best range and efficiency without actually having to change the hardware or components, such as battery and the motor.

So this is a great application of a virtual vehicle, system optimization, and components selection. Let's now go to the next story, which is coming from Ricardo-- more on the vehicle side; on the vehicle dynamics side.

So Ricardo believes that once the problem of safety has been established in autonomous vehicles, the next challenge for us would be to actually establish passenger comfort in an autonomous car; especially the factor of motion sickness in a car that is not being driven by the people in it.

So in this use case, Ricardo discusses how simulation models are being used to assess human passenger comfort in an autonomous vehicle. Ricardo says that safety which involves control spot planning and route planning will actually instill customer confidence to sit-in an autonomous car.

So they used MATLAB to objectively assess the motion sickness by building a motion sickness index, or an MSI, as they call it. They use the vehicle dynamics model from MathWorks along with a Simulink controller. They also established a course simulation with Unreal Engine to visualize the behavior of the vehicle better.

The results of the simulation was then used to tune the controller model behavior to maximize the passenger comfort. So again, in this story, we see how a virtual vehicle is helping developers to optimize their control software and their design; this time in the area of vehicle dynamics.

This next story comes to us from Ford, who were looking at automating the building of the virtual vehicle, and they did so with the help of The MathWorks Consulting Services. Ford's problem statement was simple but highly relevant-- How do we automate the vehicle building to spend less time building the virtual framework and debugging the virtual framework and go on to spending more time on actually simulating and testing with the framework?

Now, I'm sure this is a problem statement that many people in the area of modeling and simulation will identify with. So their problem statement, how can they build a virtual vehicle model-- not in weeks and days, but preferably in minutes. So what did Ford do?

Ford started with a CAN DBC file, which is essentially the architecture of the vehicle for which they are modeling. And from there, they went on to pull the relevant models of the sensors, actuators, controllers, and the corresponding plan models that they needed. Now Ford calls this as a bill of models.

They are all familiar with a bill of materials for building a physical car, but when it comes to a virtual vehicle, you actually need a bill of models. And then they integrate these different pieces to basically form the skeleton system of the vehicle, and remember-- all of this is automated.

In the next step then, Ford goes on to add the controller models, or what they call as virtual ECUs from their repositories, and then the corresponding plan models for each of these controllers so that they are able to have a full vehicle simulation or a virtual vehicle simulation, which can then be provided to their engineers.

The use cases for such a framework are plenty. They can be used by software developers. They can be used by calibration engineers for virtual calibration. They can be used for functional testing, for integration testing, and so on.

So these were a few of the stories that we wanted to bring to you about how a virtual vehicle is used by our customers for various use cases. You heard from me on the importance of simulation. You heard from me on how MathWorks is investing in the area of virtual vehicle to help more frontloading in vehicle development.

I would now like to call upon my colleague, Abhisek, to tell us on how we can actually build a virtual vehicle, and what are the different steps, and what are the different challenges that teams may face, and how MathWorks solutions are helping them? Abhisek, over to you.

Thank you so much for setting up the context well. So how do you build a virtual vehicle?

If we look at the recent vehicles, we will find that they are equipped with advanced features, and to support those functionalities we have various kinds of sensors as well. To effectively replicate this, we not only need a way to capture the traditional parts and components with various associated controllers, we also need a way to effectively capture these scenarios where we can test these kind of behaviors.

We also need to capture the driver behaviors to really understand how the vehicle dynamics might respond to those. Now, once we have created this kind of vehicle models, we can use it for various other purposes. We can use this to do early integration testing. We can also use them to test our control features, which can eventually help with saving a lot of time and money.

Now of course while building these kind of virtual vehicle models-- it's not an easy task, and it comes with various associated challenges. Let's have a look at those challenges.

The first challenge is simply getting the vehicle model which we can use for closed loop testing. Sometimes the vehicle models are available from other projects, but they may or may not be well suited for this particular analysis. How easily can you customize those models which you have? Also, can you easily find plan, controller, and sensor models, which are needed to capture the effects of interest?

If they're from different modeling tools, how do we integrate the required subsystems into a coherent vehicle model? Also, it is important to calibrate the models so we can capture the behaviors effectively. How do we do that?

To help you with this, we have two approaches. The first is if you have in-house vehicle models, we can work with you in customizing them and apply the best practices of model based design. The second way is you can use our reference applications, which have detailed system and vehicle level models for powertrain, vehicle dynamics, and other applications.

Let's have a look at the second approach in detail. So the vehicle powertrain and the vehicle dynamics-- to help with the powertrain simulations, we have Powertrain Blockset; this provides a library of automotive components, engine models, and complete vehicle models for fast desktop simulation.

The goal here is to provide you with starting points for engineers to build good plan and controller models. It provides open end document models so that you can quickly understand what each component does and how they are implemented. You can also customize them if needed.

The models are built in a way that they are fast running and it will work with most of the popular HIL systems as well. We also provide a set of prebuilt reference applications using the library blocks, which shows you how to use the library blocks effectively with modeling best practices, like model componentizations, capturing the system architecture, having ways to easily swap out components and try various variants, et cetera.

You will find reference applications for almost all of the relevant powertrain architectures which you can quickly load and start using and repurpose them as you need. Here is a very short video of one of our reference application in action. So we took all the components from the library, and we assembled them into the complete reference architecture that I was alluding to.

So you can see the engine subsystem and you can see that we are putting all the rest of the components and completing the vehicle model. Now in this particular case, we are using as a drive cycle FTP75. It also comes with a longitudinal driver, which makes sure that we have the right build and also the gear components coming out of it. And here you can see a short run.

So what you're seeing here is, on the topmost block, we have the demand velocity and also how the actual vehicle is performing. You can see they're very close, almost overlapping on each other. And at the bottom, in the second graph you will see that we have engine speed and motor speed being plotted. This is actually a hybrid reference architecture that we have chosen, so that's why you're seeing both of them. And you can also see that during the braking phase our battery is recharging, so we have also captured the regenerative braking.

At the bottom most plot is the fuel economy plot. Now this is one of the plot that we have done, and these are a few of the signals that you can effectively capture. So based on what you need, you can perform this kind of analysis and then you can also use this model to properly size your components as well.

Along with the standard vehicle architecture models, we also have models for engine dynamometers. We can use this engine dynamometer model to create engine maps, calibrate control parameters, or the control maps. We can also use this to connect to a higher fidelity model if you have them in NGD or through s-function interfaces. It also comes with engine resize feature, which allows you to statistically upsize or downsize the engine maps. This is very handy when you are working on component sizing, component selection, and you do not have the actual engine available to you to have those maps which you can use.

So similarly to the Powertrain Blockset-- as you might have noticed that we are looking at only the longitudinal dimension simulation-- we have Vehicle Dynamics Blockset that simulates the lateral vehicle dynamics, and we can also make use of 3D virtual environment to visualize those effects. You can use this particular blockset for the following use cases.

The first one is for ride and handling. So here you are seeing a short snippet of a vehicle performing a double lane change maneuver, and this is one of the reference applications that we ship, so we can use this to really understand how the vehicle handles under various kinds of scenarios. We can start at various speeds and we can apply brakes at a certain level and then see the vehicle's stopping performance as well.

So the second could be chassis control. Now in this particular video, what I'm showing you is a comparison between two different controllers and these are braking controllers, so one has ABS and another one does not. So we'll see that one particular vehicle-- the green one-- it has a poor performance and then it has a longer stopping distance. The other vehicle was performing really great.

Another use case is you could also use this for your ADAS or AD feature development as well. Since we are working with this kind of 3D virtual environment, it is also possible to equip our vehicles with camera, Lidar and radar sensors and get all the raw sensor output from this scenario. This can really help us in having a detailed vehicle model along with a virtual scenario which you can use for automated driving feature development.

So the Vehicle Dynamics Blockset, like the Powertrain Blockset, comes with a library of components for modeling the vehicle dynamics. It also includes an interface to a gaming engine for visualization and results, which can also help you in simulating lighting effects, collision effects, and to do that we are using Unreal Gaming Engine. So Simulink, through Vehicle Dynamics Blockset, can co-simulate with Unreal Engine and give you this realistic 3D behavior that I was just showing you in my earlier slides.

The Vehicle Dynamics Blockset puts all the library components into a fully assembled vehicle model where you can test the performance of the vehicle controller under various different maneuvers. The reference applications are also built to run fast by choosing medium fidelity level. These blocks are built using Simulink. If we need to add more dynamics into it, you can look under the mask and customize as you need. All these models are properly documented and you can also see exactly what equations are being implemented.

Since we have chosen medium fidelity development, these models are fast running and they are very good for a HIL use case as well. You can use these reference applications as a starting point for your scalable framework where you can start with this framework and then add the components and swap out multiple components and add more detail to it. So this is one approach or one way of modeling vehicle dynamics.

Moving on, we also have another way of capturing vehicle dynamics. And as you can see here, they're done through Simscape. Now the particular one that I'm showing you at this point, we are calling it Simscape Vehicle Templates, and as you can see in the video right now, we have provided you with a UI which allows you to quickly customize what kind of maneuver you want, what kind of powertrain architecture you want, and if you have a trajectory, you can also interface with those as well.

And once you are done, you can also evaluate them and then you can understand how it behaves. The idea here is that this particular model that uses Simscape to capture and model the vehicle dynamics-- and it can be used for various use cases, which are listed to your right hand side.

A few things to note-- you can model a detailed hybrid powertrain or conventional powertrain, where you can get into detailed analysis of each system component-- how it behaves-- in a really detailed manner. You can integrate hydraulics and pneumatic systems, you can integrate your suspension, and you can also integrate realistic road profiles and understand how the overall vehicle behaves.

The same thing can also be used for ADAS algorithm development and also be customized to use for HIL simulation. The advantage here is that we are adding higher fidelity models here. In the previous one I showed you, it was a simpler-- or medium-- fidelity. Here we can understand the thermal behaviors. You can also understand the effect of a harmonics into the system and everything, really, all of them together.

So here is another short video, which shows you how you can use this Simscape Vehicle Template Configuration and quickly customize and choose between various parts and components. So let me run it.

So what you're seeing here is that with the default condition. We have these three chassis and then here right now I'm changing it to three motors, and what we will eventually see is that all the components are automatically changed.

Now I can also add a trailer, like you can see, and you can also see that we are also providing you with the various other models that you can quickly switch from this configuration block. Now coming to the powertrain-- you briefly saw I was reaching toward three models-- what we actually have in that system is a detailed model of various kinds of converters with thermal dynamics enabled.

The model has-- the model is using quite a lot of different applications that were built-- that were available in our tools for quite some time. And we are assembling all of them and putting it there. So here is a list of all the models that we have used.

So here is another model, which is PMSM model with the thermal dynamics captured, and all of those are integrated into it. So here you can see that it starts it off with the speed demand. So if you remember, the driver block is telling us what is the speed that we need. So we take that as an input, and then we pass it on to our speed controller and then the PMSM controller, and then eventually we control the model.

Here are a few other examples that can also be used. I have put them here for you reference.

When coming to models, there are also other ways which you can make use of. So if you have, let's say, a dyno data or let's say you have a FEA-based model available to you. We can capture the non-linear relationship between flux and current and their outer angle very precisely.

As you can see, we are using lookup tables. This can create a model that uses data to include non-linear saturation effects, but since these are lookup table based, this model will also be very fast running, so we are trying we are making use of the best of both worlds-- the FEA-based as well as the linear models.

Moving on, the model also has a detailed battery management system on it. And the way we have created those battery packs is we started off with battery cell level models and then the cell level models are equivalent circuit based models with thermal behavior enabling them. We assembled them in modules and then created the entire battery pack.

Now once we have the battery pack, we are monitoring all the individual cell voltages, current, and cell temperature, which can be used for cell balancing and cell diagnostics. And then finally, we have a supervisory controller, which is a master BMS, which has various other tasks like SOC estimation, contactor management, isolation monitoring, fault detection and recovery, thermal management, current and power limits, embedded in them.

To model the battery, there are multiple options that we have. Some of the options are provided to Powertrain Blockset, where you can use this lookup table based approach to really feed the tables. So what you see here is that I am providing my state of charge vector; I am providing a vector of temperature, and based on this, too, I am feeding my no-load voltage and terminal resistance-- also ampere-hour rating.

So this particular one, what you see is a lower fidelity model where we are using these lookup tables to really capture the behavior of the battery. There are also similar options that are present in Simscape, as you can see on your right hand side.

So here we have these blocks which you can customize to how many time constants. So these time constants effectively replicates to how many RC branches you want to have in a simulation. So by click of a dropdown you can quickly switch between all of them, and we can provide similar kind of parameterization values from your data set and then you can parameterize your battery.

If we have data, you can also add thermal and fade effects. You can also create a custom block using the one that I'm showing you to extend the features. So here is a quick snippet of how the cell model internally looks like.

So here we have my cell model, and I also have my heat getting generated and my thermal aspect, which is shown in the orange blocks-- and then we connect them in the back and we have all our monitoring units, and these monitoring units are connected to our battery pack dynamics.

Now when we create this model, we can now connect with our BMS ECU, which is our master ECU. And then we can run various test cases. So here what you are seeing is a plot against our drive cycle. So one discharging relaxation and charging cycle, and what you're seeing is how all the cell voltages are varying and how the temperatures of each of them are varying along the SOC as well.

So this kind of model you can use to validate your SOC SOH cell balancing algorithms, and they will give you a fairly good result. This can also be extended for a SIL simulation and HIL simulations as well. I have put up a reference page for you where you can learn more on what you can do in terms of detailed BMS designs.

Please visit this system and you can learn more about all these things. I highly encourage you to have a look at this battery pack design simulation for battery through Simscape. This is a model that is available in File Exchange, which you can download and use it as a reference as well.

So what I'm going to do now is I'm going to pick one of these use cases and show you how you can do it using the vehicle template. In our case, what I'm going to do is I'm going to test the regenerative braking algorithm. So what I do is I go to the powertrain subsystem, I choose one of the preset, and in this case, we have also included fuel cell models, so I am using that to power our system.

So going into the battery you saw that we had the battery and all the converters, and then here we also have an algorithm which is performing the series regen breaking, right? So you will also see that there are other blocks that are present in the model. I will highly encourage you to download this particular model, which is, again, available in File Exchange, and go through all the options that you are seeing here.

And in case you have anything that you find interesting or you need more clarification, feel free to reach out to me. I'll be happy to walk you through this entire model in more detail and show you what kind of analysis we can do.

So here what we're seeing in this video is that we are choosing our lap-- this is a circuit that has been used in racing and we have replicated that. And we are running our vehicle model there to really understand how the system behaves, so let me run this portion of the video again.

What you'll see at the bottom is that the battery is getting depleted as the lap number goes, and the idea really is that the powertrain that we're using is-- we have the flexibility to really tune the regenerative braking in a way that the battery depletion that you saw-- we can minimize it as much as possible.

So what we really need to do at this point is go through the braking algorithm and then try to customize it, and then change quick parameters and see if we can improve their performance. So I have put a reference here, which you can visit and then you can download all the models-- whatever I have just showed you.

You'll be able to also add your own custom blocks and then integrate it with this UI that I was showing you. I hope you find it useful, and if you have any questions on this, feel free to drop in and get in touch with me.

All right, so we have seen how to model vehicle systems at various fidelity levels by using various different tools and use those models to design and test the controllers. Now the next logical step would be to bring in virtual scenarios and see how those vehicles perform in those scenarios.

Now to be able to simulate such scenarios, we need to have these three things-- The first is the scene itself. So scene stands for all the static aspects-- for example, roads, lane markings, materials, various kind of traffic signs, guardrails, foliage-- all those things to be captured as close to real life as possible.

Then the second thing will be the actors-- so actors being the objects that are going to be moving in that scenario. So in our case, the vehicle that we are controlling, which is the Echo vehicle, is one actor. We can have multiple different actors as well, and we can have various vehicles, pedestrians, and, let's say, bicyclist-- all of them defined there. And we can have a predefined trajectory to capture their behaviors as well. So that's the second piece.

And the third piece will be to have the sensors equipped on the Echo vehicle so that the Echo vehicle can perceive the environment and can understand what scene it is in and what is the situation of the current scenario, including the actor positions and all those aspects.

So for the sensor side, we really need to have a camera, we need to have Lidars, we need to have radar, and also emission measurement units as well. So let's have a look how we can capture all these things in MathWorks toolset.

In general, we offer two types of simulations-- the simpler one is by using the cuboid world, which you see on the left hand side. Actors in this world are represented as cubes, and they can have measures associated to them. The measures are used to approximate a non-square shape. The lane detections are generated using probabilistic methods. We use that cuboid world mainly for our control, sensor fusion, and planning aspects.

We have also started to offer higher fidelity simulation environment based on Unreal Engine, like I showed you earlier. In the high fidelity environment, algorithm, testing, design-- they can span across controls, sensor fusion planning, and perception as well.

Perception is feasible because in this high fidelity environment, it can provide pixel level feedback by using monocular camera and fish-eye camera. Radar and Lidar can also produce contour objects and/or other controls around various objects.

If we compare between these two, we can see there are various things that these two approaches will provide. And based on what we are interested in analyzing, we have to choose the right way of modeling. So I'll go through each of these ways of creating scenarios in detail to help you in choosing the right one for your use case.

So to enable the two options, we provide graphical user interfaces. In the back end there is also a programmatic way by which we can design our scenarios. The method that I am currently showing you is called Driving Scenario Designer, and using Driving Scenario Designer, we can create a cuboid world where we can use waypoints to mark our lanes, roads, road markings, and trajectory of various other actors.

Now as you can see, for actors, we can have various sides of cuboids to represent various vehicles of various dimensions. We can have roads imported from open drive-- here is the live map as well.

The driving scenario through Driving Scenario Designer-- we have also provided pre-built scenes from Euro NCAF so that you can quickly load them and then you can use it for your purpose. Now with the help of the various sensors that are present, we can also statistically define the behavior of those sensors; we can define the cross section, we can define at what rate they generate the detections and if there are any false positives, what are the ranges? All those aspects.

So let me run a small video to show you how a scenario or a scene might look like. So here what you are seeing is a scenario where one of the vehicle in yellow is cutting into a lane, and as you can see there are also other actors that are there. And all of those that you can see here in this particular road-- all of the trajectories are built or provided through waypoints.

So on the left hand side, you can see that I have given my road centers two way points. I have also said how many lanes I have, what are the lane widths, and what are the markings. I can add or various actors from here, and then I'll be able to give a trajectory like what they were supposed to follow through these waypoints again.

So this way of parameterizing or creating a driving scenario has certain benefits. These are fast running. And since we have seen some models that are statistically parameterized, they're fast running and they can also give you detections directly. And eventually, without even getting into a detailed perception layer, you can directly get detections as an output based on what kind of sensors you are working with.

So this is extremely good when you're focusing completely on the control algorithm or the planning algorithm design, and you don't want to spend too much time on pixel level information analysis. That brings me to the other option, where we can work with raw sensory information.

We have recently introduced Roadrunner as a tool to create static 3D scenes for testing your algorithm. It provides an intuitive interface for generating complex road networks. One of the powerful features of Roadrunner is its ability to export to various different file formats and simulators. Roadrunner's functionality nicely complements existing MathWorks tools, and we are also invested in-- to increase the interoperability between various other tools over time.

On the left hand side, you will see that we can export it to OpenDRIVE, FBX-- you can also use these scenes in Unreal, Unity, CARLA, and various other simulators. What you are seeing here is how the tool comes with various automations that help you in quickly modifying the scene, even creating the scene-- you just saw how we are adding various kind of trees into the scene and then adding more information to it.

So I'd like you to visit our page on Roadrunner and understand more if you find this interesting. All right, to show you how we can work with these scenarios and then we can have a model of our sensors, let's take a simple example.

We have a lane following example, which includes perception, control, sensor fusion-- everything in one test bench. In order to test the perception algorithm, the integrated system obviously includes scenes, target vehicles, and sensors.

Based on the simulated scenario, perception components, such as vision detection and tracking or fusion can be tested. Once we include the decision and controlling the test bench, vehicle dynamics is also required so that we can run it in a closed loop fashion and see how everything behaves.

So let me show you this particular model with the help of a video and show you all the components that it has. If you look at the simulation 3D Scenario Subsystem, you will see that we have our scenes here. Then you will see we have all our target vehicle poses and we have our sensor, our camera, and radar, in this particular case, defined. So that subsystem includes scene, the target vehicles and sensors.

Now, from that we are having vision processing and we are then generating the signals that we-- all the tracks for all of the objects and then we are sending it to our sensor fusion algorithm. The sensor fusion algorithm is finally generating the tracks that we are interested in and sending it to our decision and control logic.

The decision and control logic is generating the vehicle control signals, like setting angle, acceleration, deceleration commands-- the vehicle will respond to those commands and then we will be visualizing it in our scenario, and thus we are closing the loop. So this is a complete closed loop scenario that we have-- a model that we have provided, which you can use as a test bench.

Now let us see how the final response looked like. So what we did was we tuned the various algorithms that are present-- for example, the detection algorithms and then our tracking algorithms, and then finally our controller algorithm. And then we ran multiple simulations to verify that it's working. And then we have logged the simulation result so that we can plot it in various ways.

Now in this example, we show how you can take the data that was logged and use custom functions in MATLAB to plot it in various intuitive ways. So let me run the video and show you what kind of results we're generating. Now as you can see, on the left hand side, we have the Unreal visualization-- the 3D visualization-- and on the right hand side, we have our cueball visualization.

In our simulation, we have used both to generate the right signals and the information that we needed. So let's have a look.

So here all you see is that on the left hand side, we are tracking the vehicles and we are trying to find out what is the vehicle that we are interested in, the most important object. And right now, as you can see, that one is marked in yellow. So yellow is the vehicle that is in our lane, and we want to keep a safe distance with it.

On the right hand side, what you saw is a detailed list of the history of each of the objects that are being tracked. You will also see that we are plotting the vehicle speed, the relative speed, and then we are trying to analyze it and see how it performs.

What you saw just was-- I was going back and forth between one particular case where there were some issues in identifying, or rather I should say, in separating two vehicles and really understand that they are not one singular vehicle. And we are trying to tune the detection algorithm to track them separately.

So, with the help of the models that we just created, our little vehicle model and also our little scenario, we also saw how we can have a simplified scenario instead and do similar work. Or you can have both, if that's what we need.

So I will highly encourage you to have a look at this particular highway lane following example, which plugs together all of the aspects that we have seen until this point and can really show you how different features can be built based on that and tested as well.

OK, so we spent a significant amount of time in understanding how we can create this kind of system level simulation models and do various analysis. So let's come back to, again, what are the challenges that we started off with in building a virtual vehicle.

The next set of challenge, or typically what we have seen, is to really use controllers from various suppliers. So as you have seen, we have created a framework where we can test our various kinds of system level simulations. And we can also have some controllers available to us.

Now sometimes you also get controllers delivered to us by our suppliers. So we would like to integrate them in our model that we just created.

To do that, what we can do is we can spend some time in building a framework where we have all the interfaces needed to really connect with the other intellectual properties. We can use the models and build a controller as model requirements also from scratch-- anything is fine.

To help you with the import, we can use the s-function builder blocks. Most of you are familiar with this. There is also a new addition called C Caller Block that we have added, and it allows you to add your C files and header it's really easy to model and integrate with the rest of the system.

So just to give you an idea of how that might look like, let's consider the platform, X. And if you look at the left hand side, that's the typical vehicle architecture that we will have. Now imagine that this VECU is something that we are building in-house, and the rest of the components that you're seeing are all from supply components.

Now if I want to do this and convert this to a vehicle simulation model-- if you look at the right hand side, what we need to do is for all the controllers we need to connect the two respective plan models. So it could be engine model, battery model, and motor model. And we have seen how we can do that.

Sometimes what we can do is that from our own perspective, you might be interested in doing one particular feature in-house but get the rest of the features from your suppliers. And in that case, what we can very easily do is if we know the interfaces that are needed and replicate them in the model, we can very easily do a plug and play and switch between various implementations and understand that.

So the framework that we spend a significant time in building can also help us in scaling up and then add this kind of analysis to it. We can also extend that for the HIL purpose as well, so we can have the plan models running in real time and then have our features running in either another time machine or in an ECU, and then do a close up simulation. So we have a lot of flexibility in this regards.

Now, another challenge that can happen, which we looked into is that, based on what interfaces are needed or what is the complexity that we are looking at, we may need various fidelity models available to us, and not all the requirements will need the same high fidelity model or the medium fidelity model.

So to help you with that, what we have done is we have provided a lot of blogs through various toolboxes and in Simulink, which can help you in choosing the right model fidelity that you have-- that you require for a particular requirement. Sometimes we have seen that a customer may have in-house models or they may have built these kind of models in third party tools. And you would probably like to interface with them because there is no point in reinventing the wheel.

So to do that, we are also working significantly in supporting or making Simulink as a good platform where you can do a lot of integration as well. So what you see at the bottom is the tools that also we can co-simulate with. And through either list functions or through functional units, or through the C Caller block that I have shown.

This list is not exhaustive, and if you're using any other tool to develop your plan model, chances are that we are already co-simulating with it. So if you're not sure and you have some portion of your model in Simulink and you would like to co-simulate it, please feel free to reach out to us.

Another challenge we have seen in bigger organizations is that there will be cross-functional teams and what we are seeing, which is happening recently, is they want to maintain one set of models or at least a central repository-- like you have seen in Ford's first use case-- and they want that same thing to be used by various other teams. We don't really-- not having knowledge of how other teams are doing.

So for that, what we have come up with is to be able to create UIs where you can expose only certain parameters to the designer or the user which they can quickly change. You can see that the bottom right that we are trying to change a mass initially for the spring, and then trying to understand the behavior.

So the user in this case really doesn't need to know how the equations are implemented, they can just feed in the parameters an understand the behavior. It solves their problem.

So to do that, we have been investing in our compiler products also, which allows one to compile an assembling model and then deploy onto a distributable server. And then you can connect to them and give a UI to the other teams who can just use that particular model and then generate responses out of that.

So this is very particularly handy, and I also encourage you to look at the Learn More, which is the Learn More links that are posted on the top right to understand more on how we are doing this. So it is also possible to deploy the model as executables, FMUs, or web apps.