Driving simulators: drive the car before it is built

Physical prototypes are expensive, slow to change and arrive late in a program. A driver-in-the-loop simulator lets engineers and test drivers drive a vehicle while it is still a set of models, and change it between runs instead of between builds. Done well, it moves decisions about ride, handling, steering feel and driver assistance earlier, when they are cheaper to make.

What teams use them for

• Ride and handling development: comparing suspension, steering and tire options with the drivers who will sign them off.
• Driver assistance and automated driving: testing lane keeping, adaptive cruise control and takeover scenarios with a real driver reacting to them, in traffic situations that would be unsafe or unrepeatable on a test track.
• HMI and human factors: displays, warnings and controls studied with real drivers under controlled conditions.
• ECU integration: production controllers such as electric power steering or brake systems connected to the simulator, so the driver feels the real software.
• Training: test drivers and race drivers learning a car or a track before they reach it.

What the simulator has to do, every frame

A driving simulator is several real-time systems that have to agree on what the car is doing.

• Vehicle dynamics: a model from Simulink, Simpack or MSC Adams computes the vehicle’s motion from the driver’s inputs at a fixed step, commonly 1 ms.
• Image generation: an image generator such as rFpro renders the road, traffic and surroundings from the vehicle’s position for every displayed frame.
• Motion cueing: a motion platform reproduces the accelerations the driver should feel, within the limits of its travel, and washes out sustained accelerations it cannot hold.
• Cockpit and vehicle I/O: steering torque feedback, pedals, shifter and instrument cluster, plus any real ECUs, connected over CAN, automotive Ethernet and SOME/IP, and through analog, digital and PWM signals.
• Data logging: every signal recorded with a timestamp, so runs can be compared objectively afterward.

Each piece runs at its own rate on its own hardware. The driver experiences all of them at once.

Timing is what drivers feel

Drivers are very sensitive to the delay between a steering input and the response they see and feel. A constant delay is bad. A varying one is worse, because drivers adapt more easily to a fixed delay than to one that changes. A model step that occasionally runs long, a network packet that arrives a frame late, or an image generator that drops a frame will show up as a driver complaint long before it shows up in a test report.

That makes the simulator’s architecture a timing problem first:

• Set a latency budget from driver input to image and motion, and give every component its share.
• Run the models on a deterministic real-time platform, with the vehicle model, I/O and logging scheduled on dedicated cores.
• Keep the models independent of the I/O hardware, so replacing a steering wheel or a CAN interface does not mean changing model code.
• Measure cycle times and overruns on every run, not only during commissioning.

A use case: choosing a steering and handling setup

Consider a chassis team that has to choose between two suspension and steering setups before the next prototype build.

1. Build the loop. The team’s full multibody vehicle model, with its tire model, runs on the real-time platform. The production electric power steering controller is connected over CAN, so the assist the driver feels comes from the real software. A proving-ground track model runs in rFpro.
2. Drive it. Test drivers run standard maneuvers such as steady-state circular driving (ISO 4138), step steer (ISO 7401) and a double lane change (ISO 3888), then drive freely. Switching between setups is a parameter change at run time, so drivers can compare them back to back, even blind.
3. Compare. Logged signals give objective measures such as yaw-rate gain, response time and steering torque build-up, next to the drivers’ subjective ratings. Every run has the same road, the same wind and the same traffic, which no test track can promise.
4. Carry it forward. The chosen setup goes into the prototype. The same model and maneuver scripts later run on hardware-in-the-loop rigs as regression tests for the steering ECU.

The decision is made earlier, with less hardware, and the evidence behind it can be repeated.

Where we help

We develop real-time systems for driving simulators and hardware-in-the-loop rigs, and we have built and debugged both. We help teams set the architecture and timing budgets, integrate vehicle models with image generators, motion systems and cockpit I/O, connect real ECUs, and track down the latency and jitter problems that make a simulator feel wrong.

If you are planning a simulator or trying to fix one that does not feel right, tell us about it.