Rivian Scales Full-Vehicle Simulations with MATLAB and MATLAB Parallel Server
By Adithya Vignesh Jayaraman, Rivian
Designing and building the Rivian Vehicle Simulation Interface platform with MATLAB and Simulink enabled us to achieve our key objectives. We created a single platform for engineers and nonengineers alike to run full-vehicle simulations, postprocess results, and create reports.
Engineers across the automotive industry are increasingly relying on simulations to assess handling, acceleration, range, and other key performance metrics. Compared to physical testing, evaluating vehicle performance via simulation is both faster and significantly less expensive. Full-vehicle simulation also allows design work to progress earlier in the development process before prototype hardware is available. However, as the cost and efficiency advantages of vehicle simulations become more apparent within an organization, increased demand for simulation leads to its own set of challenges.
Due to the complexity involved in interfacing with commercial simulation software and running full-vehicle simulations, it makes sense to have a dedicated team of simulation engineers with the necessary expertise. This team, however, can soon become overwhelmed with requests from various stakeholders—including attribute engineers, performance engineers, dynamics engineers, range and efficiency engineers, and senior management. Simply executing the many simulations requested by these teams can also become a bottleneck, particularly when they are run on commercial software in sequential fashion. Lastly, a lack of standardized vehicle data, along with ad hoc postprocessing of simulation results, leaves engineers scrambling for gold-source data and approved methods to report results, compounding these difficulties.
At Rivian, our team has developed a scalable, easy-to-use platform for configuring, running, and postprocessing large numbers of full-vehicle simulations. Developed with MATLAB® and Simulink®, this Vehicle Simulation Interface (VSI) platform has reduced redundancy, increased reuse, and improved throughput for simulations via parallel processing. With an intuitive user interface built using App Designer, the platform has also eliminated simulation request bottlenecks by democratizing access to simulations for engineering teams throughout the company (Figure 1).
Figure 1. The VSI user interface.
This article covers how we designed VSI using object-oriented principles, how we use it to democratize simulations, and how we employ parallel processing to scale simulation workloads.
The Object-Oriented Design of VSI
When we began designing the VSI platform, it became clear that an object-oriented approach was the most straightforward way to meet our goals for flexibility, scalability, and reuse. We started by clearly defining a few fundamental objects: a Vehicle, a Load Case, and a Simulation. In this context, a Vehicle object is used to represent a Rivian vehicle, such as a Rivian R1T, a Rivian R1S, or a Rivian EDV (our electric delivery van). This object also represents the vehicle’s configuration, which defines its specific battery pack, powertrain, tires, front and rear drive units, and other components. A Load Case object is used to define a simulation scenario, which includes a speed profile, ambient conditions, and driver profile. A VSI Simulation object, in turn, is simply a pairing of a Vehicle instance with a particular Load Case (Figure 2).
Figure 2. A VSI simulation comprises a specific vehicle configuration and predefined load case.
From a programming perspective, the concept of a Simulation can be thought of as a superclass that forms the base framework for the VSI platform. The properties of this superclass include the vehicle configuration and load case properties that can be selected via the user interface, as well as a set of methods that create a model, run a simulation, perform postprocessing, extract metrics, and share the results (Figure 3). The object-oriented programming capabilities of MATLAB enabled us to create a straightforward implementation of this class structure for the VSI platform. MATLAB handle objects, in particular, were useful in encapsulating all information contained within a simulation—including not only the vehicle and load case but also user settings, results, and metrics—and transporting it within the VSI efficiently without duplicating data. These objects could then be converted into metadata text files and archived, enabling us to recreate any historic simulation by reconstructing objects from the metadata.
Figure 3. The VSISim superclass, including simulation inputs and execution methods.
Democratizing Simulations and Maximizing Reuse
We’ve deployed VSI both as a MATLAB toolbox and as a standalone executable—built with MATLAB Compiler™—that can be used by our colleagues who don’t have MATLAB installed. With easy access to VSI, teams no longer have to wait for simulation engineers to run simulations and get results.
The left side of the VSI interface (as shown in Figure 1) is used to select a vehicle configuration and a load case, while the right side of the interface shows a color-coded list of simulations. Red indicates a simulation that has yet to be run, green indicates a completed simulation, and amber indicates a completed simulation with out-of-date results (which can happen, for example, when new component data becomes available or when a model is revised). It’s important to note that simulation results in VSI are shared; an engineer may find that a simulation they want to run has already been completed by someone on their team or on a completely different team. By taking advantage of this “simulation piggybacking,” the engineer can access results immediately without wasting time and computing resources running an identical and unnecessary simulation.
Once an engineer has defined and selected the simulations to be run, they click the button labeled “Run & Post-Process” (as shown in Figure 1). The simulations are launched in the background using a combination of Simulink and commercial simulation software via a MATLAB API (Figure 4).
Figure 4. Workflow diagram for cluster simulations, along with VSI interface showing five scheduled simulations (highlighted in blue). The purple status indicates a simulation in progress; red indicates a simulation to be completed.
When an individual simulation is complete, logged data is sent back to the MATLAB workspace, where it is processed, converted to the Apache® Parquet data file format, and finally archived in a shared directory. We have also developed a set of MATLAB scripts that aggregate results to generate key metrics, report the status of the simulation against targets that are set in our requirements management system, and generate automated reports to summarize key performance indicators for Rivian’s senior management.
Scaling Up With Parallel Processing
Within the VSI user interface, engineers are given the option to run simulations in parallel using either multiple cores on their local machine or a remote Amazon® Web Services (AWS®) cluster (Figure 5). The local option, which makes use of Parallel Computing Toolbox™, is most often chosen when engineers want to test model updates and changes. The remote option, which is based on AWS EC2 instances running MATLAB Parallel Server™, is used in production with models that have already been tested and verified.
Figure 5. VSI options for parallel processing.
In the remote parallel workflow, MATLAB Parallel Server and MATLAB Job Scheduler play instrumental roles. VSI first invokes the parcluster function from MATLAB Parallel Server to create a cluster object based on an AWS EC2 profile we have defined. After creating a simulation object for each simulation to be run in parallel, VSI then creates a job on the cluster and a separate task for each simulation. The job and its tasks are submitted to the AWS EC2 instance using MATLAB Job Scheduler, which coordinates the execution of jobs and distributes tasks to individual cluster workers. When the simulations are complete, MATLAB postprocessing functions are run on the cluster before the results are archived and shared. For large jobs, say those involving 14 lengthy simulations, the remote parallel option is significantly faster, completing the job in 68 minutes compared to more than 9 hours that would be required with a sequential approach (Figure 6).
Figure 6. Benchmarking simulation times for sequential (yellow), local parallel (blue), and remote parallel (red) approaches.
In the past six months, our colleagues at Rivian have used VSI to run more than 9,000 full-vehicle simulations, totaling approximately 2 million simulated miles driven.
Planned Improvements
Designing and building the VSI platform with MATLAB and Simulink enabled us to achieve our key objectives. We created a single platform for engineers and nonengineers alike to run full-vehicle simulations, postprocess results, and create reports. We eliminated simulation request bottlenecks, reduced redundancy in simulation tasks, and increased simulation reuse. We also maximized throughput by enabling simulations to be run in parallel on an AWS cluster or across multiple cores on a local workstation.
We have planned a number of improvements to VSI, including deploying the platform as a web application, adding a dashboard for key performance indicators, and streamlining the use of design of experiments (DOE) from the user interface. At the same time, we are continuing to develop and expand Rivian’s MATLAB Minimart, a collection of MATLAB toolboxes built in-house for data conversion and viewing, launch and braking analysis, and a variety of other frequently needed capabilities.
Published 2023
