Automotive companies across the industry are increasingly relying on virtual development methods that use vehicle models to enable virtual prototyping, validation, and integration. This approach offers significant advantages—both in cost saving and decreased development time—because physical prototypes are used only for final validation.
Engineering teams are finding, however, that a few hurdles must be cleared before the benefits of virtual development can be realized. First, teams need to create virtual vehicle models at the right level of fidelity. That is, the model must be sufficiently detailed to capture the effects of interest, but not so detailed that the simulation times are prohibitive. Next, they need to integrate physical plant models and software models. Engineering teams also need to incorporate driving scenarios that exercise the closed-loop model and visualize simulation results to extract useful insights. In many cases, they also need a way to run large-scale simulations to support design tradeoff studies or optimizations.
In this article, we describe a workflow that addresses all these key areas. The workflow includes building a model with the Virtual Vehicle Composer app, customizing that model, using it to run simulations on the desktop, and then deploying it to the cloud to run large-scale studies (Figure 1). Many MathWorks customers already use this workflow or a similar one to reduce time-to-simulation, simplify cloud-based simulations, and support a growing number of virtual vehicle modeling use cases.
Generating and Customizing a Virtual Vehicle Model
Building a vehicle model from scratch is not a trivial task. It helps a great deal to start with a reference model before customizing it to meet the requirements of a particular project. That’s one reason why MathWorks has, for several years, been providing prebuilt vehicle reference applications for a broad variety of vehicle tests and maneuvers. In R2022a, MathWorks released the Virtual Vehicle Composer app in Powertrain Blockset™ and Vehicle Dynamics Blockset™. This app makes it even easier for engineering teams to configure and build virtual vehicles for performance testing and analysis via an intuitive user interface. When using the app, engineers begin by selecting a powertrain for the vehicle (for example, a two-motor EV powertrain), specifying either a pure longitudinal model or one that also includes lateral dynamics, and configuring key parameters—such as the vehicle mass, tire size, maximum motor torque, and so on. They can then select which test cases to run from a set of drive cycles and maneuvers, as well as which signals to log during simulations. Once these configuration choices are made, a single click will generate a Simulink® model that is ready for simulation (Figure 2).
Figure 2. The Virtual Vehicle Composer app.
The Virtual Vehicle Composer app enables teams to configure and generate complete models within minutes. More importantly, however, the resulting model is fully customizable, so teams can augment it with new plant, controller, or sensor model features, or with additional functions written in C or MATLAB®.
To illustrate this part of the workflow, we implemented a use case in which we customized a version of an EV model generated with the Virtual Vehicle Composer app and then used it to study the performance of an autonomous emergency braking (AEB) system.
The EV model we generated did not include the sensors, control algorithms, and test scenarios needed to run AEB tests, so we incorporated these components from an Automated Driving Toolbox™ sample model. At that point, it was a matter of dragging and dropping the AEB components we needed, connecting the necessary signals to fit into the model’s framework, and copying over the vehicle parameter and controller calibration data from the AEB sample model. The resulting closed-loop model, including both the EV plant and AEB controller, comprised close to 33,000 blocks (Figure 3).
Performing Desktop Simulations
Once a complete system model is assembled and configured, the next step in the workflow is to perform simulations on the desktop. In our example use case, the goal was to understand how well the AEB control algorithm worked for the EV we had modeled. For example, we wanted to know if the controller safely stopped the car—with no collisions—across a variety of scenarios and a range of vehicle weights. We also wanted to evaluate key control parameters, such as the initial application of brake force (or brake pressure) and the specific moment the brakes were fully applied (Figure 4). Desktop simulations provide a way to validate the model, evaluate the test configuration, and verify automation scripts with a limited set of test runs before scaling to a more comprehensive study.
To design synthetic driving scenarios for testing, we used the interactive Driving Scenario Designer app from Automated Driving Toolbox, which also provides several AEB and collision avoidance example applications. We had a simple pass/fail criterion for each scenario: If the ego vehicle stopped before colliding with the vehicle, pedestrian, or obstacle in its path, then the test passed (Figure 5).
We wanted to run several test cases, so we decided to automate test execution, which can be done via a MATLAB script or Simulink Test™. For the initial round of desktop simulations, we decided to run 16 different tests, varying parameters, such as vehicle speed, in both the plant and control algorithm as well as the test scenario to exercise the system over a wide range of conditions. On a single processing core, this 16-run sweep took about 23 minutes to complete. To shorten simulation times, we used Parallel Computing Toolbox™ to run the same tests in parallel on four cores. This reduced the simulation time to a little over 7 minutes. Even at this faster pace, however, it would take days to complete the full-factorial study that we wanted to run, which involved thousands of simulations. Such large-scale studies are well-suited to the cloud. Performing this small-scale parameter sweep first on the desktop enabled us to confirm that our automation scripts for running the simulations and checking the pass/fail criterion worked as intended. That, in turn, gave us the confidence to scale up the study for a much larger combination of test conditions in the cloud.
Running Large-Scale Simulation Studies in the Cloud
There are many reasons for running simulations in the cloud. Scaling, to take advantage of greater computational resources, is a common motivation. Engineers may also want to simply offload computational jobs from their main workstation, or teams may want on-demand access to specialized computational hardware that is only needed on occasion.
When working in MATLAB, the transition from desktop to cloud is straightforward; there’s no need to rewrite scripts or algorithms. MathWorks offers reference architectures for running MATLAB and Simulink on virtual machines (VMs) in the cloud, as well as prebuilt containers that can be deployed to the cloud.
For our study, we used the reference architecture for running MATLAB Parallel Server™ on Amazon® Web Services. Available on GitHub®, this reference architecture makes it easy to launch Windows® or Linux® virtual machine instances based on the latest prebuilt MathWorks® Amazon Machine Images (AMIs)—even for teams with little or no cloud experience. Once the instance was launched, we connected to it via a remote desktop, uploaded our test setup files, and then we were ready to start running tests on a Linux VM cluster with four 32-core machines.
We ran a full factorial study that included 28 scenarios, 16 values for a plant model parameter, and five values each for two control parameters. This resulted in a 11,200-simulation test suite. In the cloud, the test runs were finished in about 90 minutes, whereas on a four-core workstation, the same study would have taken about two days.
Reviewing the results from this study, we confirmed that the AEB controller was reasonably robust across all tests. We did notice some failure cases, in which the virtual vehicle failed to stop in time (Figure 6). In a typical workflow, these cases would be examined in more detail back on the desktop, where engineers would analyze the results in MATLAB and Simulink to identify the root cause of the failure, decide how to remediate the issue (for example, by tuning controller parameters), and, if needed, update the model for a follow-up test run in the cloud. Large-scale simulation studies with virtual vehicle models make it easier to identify these potential failure cases and enable engineering teams to focus on potentially critical problems early in the design process.
Conclusion
As virtual vehicle development becomes more central to the overall automotive workflow, engineering teams will need ways to keep up with the ever-increasing demand for simulation. Virtual Vehicle Composer provides teams with a significant productivity advantage in this area by enabling them to quickly configure suitable vehicle models. Because these models are not black boxes, engineers have the flexibility to rapidly enhance and customize them in Simulink to the specific needs of their project. Further, the teams can then continue to use MATLAB and Simulink along with cloud computing to automate simulation studies at scale and analyze their systems over a wide range of conditions to identify potential issues, evaluate design tradeoffs, and perform optimizations.
