From Code to Road: A Vehicle-in-the-Loop and Digital Twin-Based Framework for Central Car Server Testing in Autonomous Driving

This paper presents a Vehicle-in-the-Loop and digital twin-based framework that integrates a physical test vehicle on a dynamometer with a synchronized virtual environment to enable safe, cost-effective, and realistic validation of autonomous driving algorithms on centralized E/E architectures without requiring individual ECU testing or intermediate software layers.

The Gist

Imagine you are a chef trying to invent a new, complex recipe for a flying car. In the old days, to test if your recipe worked, you'd have to build a real flying car, fly it into a wall, fix it, change the recipe, build it again, and fly it again. It's expensive, dangerous, and slow.

This paper introduces a new way to test the "brain" of self-driving cars. Instead of building a new car every time you want to test a change, they built a "Video Game Simulator that talks to a Real Car."

Here is the breakdown of their invention, using simple analogies:

1. The Problem: The "Lego Tower" vs. The "Super Computer"

Old cars are like giant towers made of 100+ different Lego blocks (called ECUs). Each block does one tiny job (like controlling the wipers or the radio). If you want to change how the car drives, you have to take apart the tower, swap out specific blocks, and reassemble it. It's a nightmare for software updates.

New cars are moving toward a "Central Car Server" (like a super-computer brain). Instead of 100 small blocks, you have one giant brain that does everything. This is faster and smarter, but it's very hard to test because you can't just "swap a block" anymore; you have to test the whole brain at once.

2. The Solution: The "Digital Twin" Dance

The authors created a testing framework called Vehicle-in-the-Loop (ViL). Think of it as a dance between a Real Car and a Virtual Ghost.

• The Real Car: It's a real Volkswagen ID Buzz, but it's strapped to a giant treadmill (a dynamometer). It can't go anywhere physically, but its wheels spin, and it feels the resistance of the road.
• The Virtual Ghost: This is a perfect digital copy (a "Digital Twin") of the real car, living inside a video game called CARLA.
• The Magic Link: They are connected by a high-speed wire. When the real car moves on the treadmill, the ghost car moves in the video game. When the ghost car sees a virtual pedestrian, the real car's sensors (cameras) see a real image of that pedestrian projected on a screen in front of the driver.

3. How It Works: The "Code-to-Road" Pipeline

Usually, testing software is a messy process:

1. Write Code: You type code on a laptop.
2. Flash the Chip: You have to physically plug into the car's computer to upload the code.
3. Test: You drive and see if it works.
4. Repeat: If it fails, you go back to step 1.

Their New Method:
They built a system where the software runs directly on the car's "Central Brain" (the CeCaS computer) without needing to be physically re-flashed every time.

• The Setup: The car is on the treadmill. The "Brain" is connected to the treadmill and the video game.
• The Test: The video game creates a scenario (e.g., a child runs into the street). The car's camera sees the child (either a real camera looking at a screen, or a virtual camera). The "Brain" decides to brake. The treadmill feels the brakes.
• The Result: You get the safety of a video game with the reality of a physical car.

4. The Experiments: "The Ghost and the Driver"

They tested this in two ways:

• Human Driver Mode: A human sits in the car, steering and braking. The video game mirrors their moves perfectly. It's like a high-tech driving simulator where the car actually feels the road resistance.
• Self-Driving Mode: The computer takes over. They tested two things:
  • Cruise Control: The car follows a virtual lead car, keeping the perfect distance.
  • Emergency Braking: A virtual person jumps in front of the car. The real camera sees them, the computer says "STOP," and the car slams on the brakes on the treadmill.

5. Why This is a Big Deal

• Safety: You can crash the virtual car a thousand times without hurting anyone or breaking anything.
• Speed: You don't need to take the car apart to change the software. You just update the code, and the "Brain" runs it immediately.
• Realism: Unlike pure video games, the car actually feels the weight, the friction, and the physics of the road because it's a real machine on a real treadmill.
• Cost: It saves millions of dollars because you don't need to build new prototypes for every software update.

The Bottom Line

This paper describes a "Flight Simulator for Cars," but instead of a plastic cockpit, they use a real car strapped to a treadmill, connected to a video game. It allows engineers to teach self-driving cars how to drive safely in the real world, without ever leaving the garage. It turns the messy, dangerous process of car testing into a clean, fast, and safe digital loop.

Technical Summary

Here is a detailed technical summary of the paper "From Code to Road: A Vehicle-in-the-Loop and Digital Twin-Based Framework for Central Car Server Testing in Autonomous Driving."

1. Problem Statement

The automotive industry is transitioning from distributed Electronic/Electrical (E/E) architectures to Centralized E/E architectures to support Software-Defined Vehicles (SDVs) and complex autonomous driving (AD) algorithms. However, this shift creates significant testing challenges:

• Limitations of Traditional Methods: Conventional Software-in-the-Loop (SiL) and Hardware-in-the-Loop (HiL) tests often fail to capture the full dynamics of the interaction between a central server and the physical vehicle.
• Inefficiency of Distributed Testing: Traditional validation requires flashing individual Electronic Control Units (ECUs) for every software update, which is time-consuming and complex.
• The "Sim-to-Real" Gap: Purely virtual simulations struggle to accurately model real-world factors (e.g., sensor noise, mechanical dynamics), while real-world testing is expensive, unsafe, and difficult to reproduce.
• Lack of Integrated Frameworks: There is a gap in frameworks that allow for the validation of full autonomous driving software stacks running directly on centralized hardware (Central Car Servers) before deployment on public roads.

2. Methodology

The authors propose a Vehicle-in-the-Loop (ViL) framework integrated with Digital Twin technology. This setup couples a physical test vehicle on a dynamometer with a synchronized virtual counterpart in a simulation environment.

A. Hardware Architecture

• Physical Test Vehicle: A reconstructed rear-wheel-drive Volkswagen ID Buzz with unmounted wheels, mechanically connected to a Siemens powertrain dynamometer.
• Central Car Server (CeCaS): A High-Performance Computer (HPC) equipped with an AMD TRP 5955WX CPU and RTX 4090 GPU, acting as the central brain for AD functions.
• Simulation Computer: A powerful HPC (AMD TRP 5995WX, 6x RTX 4090) running CARLA to generate the virtual environment and the vehicle's digital twin.
• Sensors:
  • Virtual: Simulated RGB, depth, LiDAR, and radar sensors within CARLA.
  • Physical: A Basler Ace 2 PoE camera mounted on the test vehicle to detect real objects or projected simulation environments.
• Control Interface: A custom Vehicle Motion Gateway (redundant ECUs) bridges the CeCaS and the vehicle's legacy ECUs, enabling external control of acceleration, braking, and steering while ensuring functional safety.

B. Software & Workflow

The framework supports a three-stage development process:

1. Internal Test (SiL): Software tested on the same hardware with a simulated environment.
2. External Test (HiL): Software on isolated hardware communicating via Ethernet with a simulated environment.
3. ViL Test (The Proposed Framework): The full AD software runs on the CeCaS mounted on the physical test vehicle. The vehicle is controlled by the CeCaS based on inputs from either virtual sensors (CARLA) or real physical sensors (camera).
   • Synchronization: The CARLA world ticks synchronously with algorithmic calculations. Control signals (steering, throttle) are sent at 20ms intervals, while less critical signals (turn signals) are sent at 50ms.
   • Hybrid Sensing: The system supports "mixed" testing where real camera data can trigger the spawning of digital twins (e.g., a pedestrian) in the simulation, creating a closed-loop interaction between physical perception and virtual reaction.

3. Key Contributions

• Novel ViL Validation Setup: A dedicated test bench for vehicles with centralized E/E architectures, eliminating the need to test individual ECUs separately.
• Full Software Integration: The ability to run the complete autonomous driving stack (Perception, Planning, Control) directly on the central car server hardware without intermediate flashing layers.
• Digital Twin Synchronization: A synchronized environment where the physical vehicle's kinematics (measured by the dynamometer) drive the virtual twin in CARLA, and vice versa.
• Real Sensor Integration: Demonstration of using physical cameras to detect objects, which then spawn corresponding digital twins in the simulation, bridging the gap between physical perception and virtual scenario generation.
• Human-in-the-Loop Capability: The framework supports both fully autonomous operation and manual driving (with a human driver), allowing for ergonomic studies and safety validation.

4. Experimental Results

The framework was validated using two primary scenarios:

• Manual Driving: A human driver controlled the physical vehicle while the digital twin mirrored its behavior in CARLA. This demonstrated precise synchronization between real-world dynamics and the virtual environment.
• Autonomous Driving:
  • ACC & LKA (Adaptive Cruise Control & Lane Keeping Assist): The system successfully followed a lead vehicle and maintained lane position. The average lateral error was kept under 0.05 meters, proving high precision in path following.
  • Emergency Braking: A physical camera detected a person, triggering the emergency brake. The system successfully spawned a digital twin of the person in the simulation and executed a braking maneuver.
• Performance Analysis:
  • Latency: Connection latency was measured based on camera frame rates (FPS). At 5 FPS, latency was manageable, but increased significantly at lower FPS due to computational resource consumption during the car-following phase.
  • Robustness: The system successfully handled the closed-loop delays and middleware scheduling effects inherent in a real centralized architecture.

5. Significance and Impact

• Cost and Time Efficiency: By testing the entire centralized system as a single unit, the framework eliminates the tedious process of flashing individual ECUs, significantly reducing development cycles and integration efforts.
• Safety and Reproducibility: It allows for the testing of dangerous scenarios (e.g., emergency braking, pedestrian detection) in a safe, controlled laboratory environment with perfect reproducibility.
• Scalability: The "Code-to-Road" workflow enables rapid iteration of algorithms on realistic hardware before deployment, facilitating the transition to Software-Defined Vehicles.
• Future-Proofing: The framework is designed to be expandable, capable of integrating additional sensors (LiDAR, Radar) and connecting to broader vehicle IT infrastructures (Zone ECUs, Ethernet Backbones) for comprehensive system evaluation.

In conclusion, this work presents a pivotal step toward efficient autonomous vehicle development by providing a realistic, safe, and integrated testing environment that bridges the gap between algorithmic code and physical road deployment.