How to do Vehicle-in-the-Loop Simulation

Why do you need vehicle-in-the-loop simulation?

Hans Christian Döring, Senior Application Engineer, Automated Driving & Software Solutions, dSPACE GmbH

Jan Deppermann, Application Engineer, Real-Time Test & Development Solutions, dSPACE GmbH

Real vehicle tests are still an important part of the optimization and validation process of ECU features. Not only do they cover the complete vehicle and ECU network, but they also include the driver and their driving experience during these tests. However, for testing ADAS/AD (advanced driver assistance systems/autonomous driving) features, these real vehicle tests become more and more complex.

Why? These tests not only have to cover the vehicle itself, but also a sophisticated dynamic environment. Creating such an environment in reality is a time-consuming and difficult-to-coordinate task at best.

To reduce the effort of creating this real environment, a simulated environment is used instead. This is achieved by measuring the real vehicle movements and feeding them into a virtual clone simulated on a real-time system. On the same real-time system, a virtual environment is simulated that will be detected by virtual sensors attached to the clone of the real vehicle. The detected sensor data is then transmitted back to the real vehicle as the system under test (SUT). With this, the SUT can react to the injected sensor data in closed-loop operation.

This approach with a real vehicle driving in a simulated world is called Vehicle-in-the-Loop (VIL). And this is where dSPACE provides comprehensive support with state-of-the-art hardware and software as well as years of experience regarding simulation.

Components of the VIL System

The dSPACE vehicle-in-the-loop system consists of a real-time system like the dSPACE SCALEXIO Autobox, which is specifically designed for in-vehicle use. With its configurable I/O modules, it acts as a bus gateway between the ADAS ECUs under test (e.g., camera, radar, lidar and ultrasonic sensors) and the rest of the vehicle’s bus network. Additionally, a clone of the ego vehicle with its environment is simulated on the real-time processor of the SCALEXIO Autobox. This simulation is used similarly as in a HIL use case as a source for a variety of sensor simulations and restbus implementations.

Advantages of Vehicle-in-the-Loop Simulation

In addition to the already mentioned time and cost reduction of real vehicle tests, especially for the test preparation, VIL offers the following advantages:

  • Large variety of test scenarios:

    • Individual configurable or standardized scenarios (compliant to EuroNCAP)

    • Scenarios covering longitudinal (e.g. adaptive cruise control - ACC) or lateral dynamics (e.g. lane keeping)

    • Safety (e.g. autonomous emergency braking - AEB) or comfort-focused scenarios

    • ADAS and AD feature testing

    • Simulation of high-risk scenarios, e.g., with expected but mitigated collisions

    • Reusable scenarios from model-in-the-loop (MIL), software-in-the-loop (SIL), and hardware-in-the-loop (HIL) tests

  • Time and cost reduction for integrating a VIL test system compared to a virtual vehicle HIL system

  • Test of DUTs (ECUs) in complete real vehicle network

  • Human factor: optimized controller intervention with a real driver in the loop

During the vehicle-in-the-loop simulation the position and heading data of the real vehicle and the vehicle simulated with ASM are synchronized.

One essential part of the vehicle-in-the-loop system is the global navigation satellite system sensor (GNSS) with integrated inertial measurement unit (IMU), that measures and transmits the position and heading of the real vehicle to the dSPACE real-time system. The simulated ego vehicle then uses these measurements to move in the same way as the real vehicle does. For the global position measurement, the most common systems like GPS, GLONASS, Galileo and Beidou are used. For a high-precision position measurement, correctional data (Ntrip) needs to be received via mobile internet connection or a separate base station.

The host PC for the dSPACE SCALEXIO real-time system is integrated into the vehicle. It serves, together with a touch screen and additional periphery, not only as a control interface for the dSPACE toolchain (ControlDesk, ModelDesk, AURELION), but also for the GNSS/IMU. Furthermore, it provides important feedback to the driver about the simulated environment and the current scenario. The visualization is implemented with AURELION.

For comfortable electrical integration of the system, dSPACE provides a custom-made power distribution box. This works as a power supply interface between the system and the vehicle with fused outputs for each consumer. With the main power switch, the VIL system is turned off completely, to avoid draining the car battery when the system is not in use.

Setup and Formats of the Sensor Simulation

The crucial part of closing the control loop between the simulated environment and the real vehicle is done via sensor simulation. It is achieved either by the replacement of complete environment sensor ECUs with SoftECUs or with the injection of environment data into the corresponding real ECUs. Depending on the specific use-case and the ECU architecture of the VIL vehicle, one of dSPACE’s manifold solutions for simulating cameras, radars, lidars or ultra-sonic sensors is used.

The VIL simulator provides the sensor data in any of the following formats:

  • Ideal ground truth or probabilistic object list: A filtered list of relevant objects is generated per sensor or as a result of sensor fusion. The list contains, for example, information about the object position, movement, dimensions, and type. It is enriched with additional sensor-type-specific attributes like radar cross-section, object color or traffic sign labeling. The list can contain ideal data based on ground-truth information or it can include (sensor-type-specific) probabilistic effects like measurement noise or clutter.

  • Phenomenological or physical target/detection list: Instead of a list of actual complete objects, the VIL simulator can also provide a list or an array of detected targets. Compared with the object list, these targets and their detected attributes are highly technology-dependent – for example, a list of echoes and their travel time for an ultra-sonic sensor, a point cloud and its reflectivity for a lidar or the (clustered) reflections and their radar cross sections for a radar. This option is used if the object detection algorithm has to be included in the test.

  • Physical signal: Here, the actual physical signal that is either detected by the sensing element or that is provided by the sensing element itself is injected in an early stage of the sensor processing stack. Once again, this is completely sensor-type-specific. It can be a matrix of pixel values for a camera, a channel impulse response in a radar, or the ultra-sonic soundwave for an ultra-sonic sensor. This early injection point allows to include the vast part of the sensor itself into the test chain.

The test scope required by the customer determines which sensor data format is needed. The simulation complexity increases with growing realism.

Based on the selected format for the sensor data, the corresponding dSPACE solution for injecting this data into the vehicle’s ECU network is used.

dSPACE provides and uses for example the following technologies:

  • Automotive buses (CAN, LIN, Flexray, (Automotive) Ethernet)
  • Proprietary injection points of the ECUs
  • Standardized sensor interfaces like PSI5, MIPI CSI-2, GMSL1/2, FPD-Link III/IV
  • Over-the-air systems

Comparison of a Real and a Simulated Test

The following video shows an example of a low-speed VIL scenario. The VIL test vehicle (Ego) is driving on an empty parking deck. To provide a reference to the driver of the Ego vehicle, the same parking deck structure is simulated by the test system. However, for performing the test case, the simulated environment is enriched with other vehicles and traffic participants.

While the Ego vehicle is driving, one of those simulated cars leaves its parking spot and enters the path of the test vehicle. This is detected by the simulated front radar. The information is forwarded to the real ADAS controller, which immediately initiates an emergency brake intervention that brings the real vehicle to a stop.

This deceleration is measured by the test system and mirrored by the simulated vehicle. The imminent collision with the simulated target is prevented.


Vehicle-in-the-loop simulation provides a sophisticated way to test the sensor input for ADAS/AD functions. The comprehensive dSPACE product portfolio of simulation hardware and software offers you an easy way to set up and configure your test scenario.

Our experienced test engineers are ready to help you get started. Just give us a call.

More Information Product Information

Subscribe newsletter

Subscribe to our newsletters, or manage or delete your subscriptions