Introduction
Virtual vehicles are becoming a common part of modern automotive development, helping teams validate vehicle behavior, driver interaction, and system integration in realistic digital environments before moving to broader physical testing.
The goal of this first article is to present the virtual vehicle system used in the Hello World demo at a high level and establish the context for the articles that follow. The focus here is on what the subsystem is, why it is relevant in the demo, and how Model-Based Design supports its development within the MathWorks and NXP ecosystem.
Overview
The importance of this subsystem lies not only in its functional role of simulating the vehicle and linking it to a physical zonal architecture, but also in how it demonstrates an efficient model-based workflow.
Rather than building separate assets for vehicle behavior, driver interaction, visualization, and hardware communication, the workflow starts from a configurable virtual vehicle model that can be tested, extended, and connected to other parts of the system.
The Virtual Vehicle Composer is a MathWorks tool that enables you to create a Simulink vehicle model for system-level testing, software integration testing, and driver-in-the-loop workflows. The generated model can simulate key vehicle functions such as powertrain, steering, braking, and overall vehicle dynamics.
Powertrain Blockset and Vehicle Dynamics Blockset provide reference applications and component models that help define and simulate vehicle behavior in more detail. Simulink 3D Animation supports visualization and interaction with 3D environments, helping connect the vehicle model to a more realistic driving experience.
This accelerates development in several ways:
- The vehicle can be configured and built from a structured workflow rather than assembled manually from scratch.
- The same model can support simulation, software integration, and connection to external hardware.
- The built-in 3D interface with Unreal Engine helps connect the vehicle behavior to a realistic visual environment.
- RoadRunner scenes and scenarios can be incorporated into the simulation workflow to create interactive driving scenarios.
- CAN communication and feedback from the physical setup can be integrated into the Simulink-based system model.
- The same workflow can be extended to support additional sensing paths, such as radar data generation and off-board processing on NXP radar hardware.
This series is intended for:
- Engineers learning Model-Based Design with MATLAB and Simulink
- Developers working with NXP automotive processors and microcontrollers
- Teams building virtual validation and hardware-connected automotive demonstrations
- Engineers interested in Driver-in-the-Loop workflows
- Students and researchers studying vehicle architectures, simulation, and embedded integration
- Anyone interested in a reproducible example of simulation-to-hardware integration using MathWorks tools and NXP platforms
Readers will gain a clearer, step-by-step understanding of how a virtual vehicle can be created, integrated into a 3D driving scene, connected to a physical zonal platform, and used as part of a broader model-based development workflow.
Context
Created with the Virtual Vehicle Composer, the Simulink hybrid electric vehicle (HEV) model is used not only for standalone simulation, but is reused as the common integration point for driver inputs, RoadRunner-based scene interaction, including actor scenarios implemented in RoadRunner, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup.
In the implemented setup, a driver controls the virtual vehicle through an Xbox-compatible steering wheel and pedals. These inputs are processed by the Simulink model, which updates the vehicle behavior inside a RoadRunner scene rendered through Unreal Engine.
At the same time, the virtual vehicle sends key signals such as speed, steering, braking, turn indicators, hazard lights, and beam light commands over CAN to a physical setup that represents an electric vehicle built from multiple NXP reference boards organized in a zonal architecture.
The physical platform includes a main node, zonal nodes, and multiple end nodes. These elements receive the simulation-driven commands and reproduce the state of the virtual vehicle in hardware.
Communication is bidirectional, so feedback generated by the physical setup can also influence the simulated vehicle. For example, if front or rear parking sensors detect an obstacle, that information can be returned to the virtual vehicle model and used to trigger braking behavior.
All major functional aspects of this interaction, including driver input handling, vehicle behavior, signal exchange, and feedback response, are defined in the Simulink model. This supports rapid refinement and validation before deeper integration into the full system.
An additional part of the setup extends the virtual vehicle interaction toward sensing and perception workflows. Actor poses from the virtual scene are used to generate a radar cube, which is sent to an NXP S32R45 board that runs a radar processing chain.
This expands the role of the virtual vehicle beyond motion and body-domain interaction. It shows how the simulated environment can also stimulate external sensing functions and hardware processing paths as part of the same demo workflow.
The virtual vehicle component is highlighted in the architecture diagram from Figure 3 to show its position in the overall project setup and its connection to the driver interface, the 3D environment, the physical zonal platform, and the radar processing path.
The next articles in the series will build on this system overview and examine the virtual vehicle in more detail, including the software and hardware environment, the model architecture, the vehicle creation workflow, the driver input options, RoadRunner and Unreal integration, CAN communication, and the final results and challenges observed during development.
References
The following resources provide useful background for the technologies referenced in this article:
Conclusion
The virtual vehicle subsystem provides the foundation for the Hello World demo by supplying a reusable vehicle model that supports simulation, validation, and integration within a model-based workflow. This article established its purpose and position in the overall architecture. In the next articles, we will move from this high-level overview to the practical details of how the subsystem is created, connected, and exercised in the complete demo.
