Real-time vehicle dynamics with more than 800 degrees of freedom

Real-time vehicle models have traditionally been simplified. A model with a few dozen degrees of freedom fits comfortably inside a 1 ms step, so that is what drives the simulator and the hardware-in-the-loop rig. Meanwhile, the chassis team’s offline models in Simpack or MSC Adams describe the same vehicle in far more detail. The result is two cars: the one the engineers designed and the one the driver and the ECU actually meet.

We run multibody vehicle models with more than 800 degrees of freedom in hard real time. That lets one detailed model serve the desk, the driving simulator and the test rig.

Where 800 degrees of freedom come from

A detailed vehicle model reaches that size quickly:

• Suspension links mounted on elastic bushings rather than ideal joints, so each link keeps all six degrees of freedom.
• Subframes, engine and transmission on compliant mounts.
• Flexible bodies such as frame rails, twist beams, anti-roll bars and the steering column, represented by their mode shapes.
• A driveline with compliant half shafts, propeller shaft and differentials.
• A steering system with column, intermediate shaft, rack and assist.
• Tire models with their own internal states for the belt and the contact patch.
• For trucks, a ladder frame, cab suspension and trailers, which multiply everything above.

These details carry the effects that simplified models miss: compliance steer, body and frame flex, driveline wind-up, and the way the vehicle responds over rough roads.

Why it is hard in real time

In hard real time, every step has a deadline, typically 1 ms, and the deadline has to be met on every step. A model that is fast on average but occasionally runs long is not a real-time model. Large multibody models make this hard in three ways. Stiff elements such as bushings and tires push toward small steps or implicit solvers. Implicit solvers iterate, and a varying number of iterations means a varying step time. And once the model is spread across several cores, exchanging data between them costs time as well.

How we make it fit

1. Measure the worst case. Profile each subsystem across realistic maneuvers and rough-road inputs, and size the system to the longest step, not the average one.
2. Bound the solver. Use fixed-step integration with a fixed or capped number of iterations, so the cost of every step is predictable.
3. Partition the model. Split the vehicle into subsystems, such as axles, tires, driveline and steering, and run them in parallel on dedicated cores, exchanging a small, well-defined set of signals every step.
4. Use more than one rate. Run stiff, fast subsystems at a higher rate and slower ones at a lower rate, instead of running everything at the rate the fastest part needs.
5. Remove what does not matter. Truncate flexible-body modes above the frequency range of interest and simplify contacts that never engage, then check the result against the offline model after every change.
6. Protect the cores. Run on real-time Linux with the simulation cores shielded from interrupts and other processes, and let a frequency-based scheduler drive the frame.
7. Keep watching. Log cycle times and overruns on every run, so a rare spike shows up in the data and not as an unexplained jump in a test result.

Proving it is the same car

Real-time performance only matters if the model still behaves like the original. We run the same maneuvers through the offline model and the real-time version, compare the signals that matter for the application, such as wheel loads, steering torque, yaw rate and body accelerations, and agree on acceptance limits with the vehicle team before the model goes onto a rig.

What it enables

• One vehicle model from engineering analysis to driving simulator to hardware-in-the-loop rig, with no separate real-time approximation to maintain.
• Drivers in the simulator who feel compliance, flex and driveline effects that a simplified model cannot reproduce.
• ECUs on hardware-in-the-loop rigs tested against loads and motions closer to the real vehicle.

The real-time systems we work with run Simulink, Simpack and Adams models alongside hand-written code, natively or through FMI. If you have a detailed model that you would like to run in real time, get in touch.