German driving model separated the path from the speed. Test the safety score in traffic

THE SIGNAL IN ONE SENTENCE

A car can choose the right lane and still choose the wrong speed. That sounds obvious when a human does it. Inside an end-to-end driving model, the two decisions are often tangled together. The system watches the road and predicts a timed trajectory. Where to go and how fast to move arrive as one bundle. Researchers at the Technical University of Munich, BMW Group and TU Wien are trying a cleaner split. Their system, CLAP-AD, keeps imitation learning for the path. It then scores several candidate speeds against separate safety criteria. The paper was submitted October 26 and accepted to WACV 2027. The plain-language signal is useful. Do not ask one prediction to hide every driving decision. Choose the spatial path. Then make the speed earn its way onto that path. The argument begins with a weakness in ordinary imitation learning. An expert demonstration shows what one driver did in one recorded situation. It does not show every other acceptable response. A driver approaching the same clear intersection might safely travel at several speeds. If a model copies only the demonstrated speed, it may learn a preference rather than a safety boundary. The demonstration can also be noisy or ambiguous. Maybe the expert slowed because of traffic that is barely visible. Maybe the speed reflects comfort, habit or a distraction rather than a hard constraint. CLAP-AD treats path and speed differently because the authors argue that most of driving's valid variation lies in speed. The path is often constrained by lanes, road geometry and the destination. The speed has more legitimate options. So the system predicts a path from the upstream driving model, then evaluates predefined speed classes along it. Three learned scoring branches handle the paper's current criteria. One scores collision risk with surrounding traffic participants. One scores whether the vehicle can stop for a red light without requiring excessive braking. One applies a similar check for stop signs. These scores are trained from physically grounded targets derived from logged data. For collision supervision, the researchers compare the vehicle's candidate motion with the recorded future positions of other actors. For lights and stop signs, the target reflects the deceleration required to stop at the line. At inference time, the model does not run those physical calculations directly. It predicts the criterion scores from the scene context. That sentence is the safety hinge. The targets may come from geometry and motion. The deployed score is still a learned estimate. If perception misses a pedestrian, misreads a light or predicts another vehicle badly, a neat collision score can be confidently wrong. The architecture makes that wrongness easier to locate. Each speed receives separate collision, traffic-light and stop-sign scores. A threshold defines which candidates count as feasible. A selection rule then chooses among the feasible speeds. The authors describe several possible policies. Choosing the maximum feasible speed favors throughput. Choosing the median can produce a more defensive style. A requested target speed can be honored when it remains inside the safe set. If no candidate speed passes all the thresholds, the selector falls back to zero meters per second. That is a sensible shape for a safety fallback. It still needs a serious test. Zero in the model is not automatically a safe stop on the road. The low-level controller must brake the real vehicle. Tires, road friction, actuator delay, vehicle load and the distance to the hazard determine whether the stop arrives in time. The paper evaluates the planning head in three benchmark settings. Bench2Drive uses interactive CARLA simulation with 220 closed-loop test routes and challenging scenarios. Bench2Drive-Speed adds changing user-requested speeds across 48 routes. NAVSIM v2 begins with real logged driving data and adds synthetically rendered observations from perturbed vehicle states to test recovery. The authors report a Speed-Adherence Score of 82.53 on Bench2Drive-Speed, 12.9 points above the strongest listed baseline on that metric. They also report Driving Score improvements of 28.5 and 32.7 points over UniAD and VAD on Bench2Drive, plus a 6.1-point EPDMS improvement over the selected backbone on NAVSIM v2. Those are promising benchmark results. They are not public-road miles. Bench2Drive is simulation. NAVSIM uses real-world logs but is a pseudo-simulation benchmark, not a vehicle operating through live traffic. Its recovery stage uses synthetic views rendered from perturbed positions. The distinction is not a technical footnote. A benchmark controls what can happen. A street invents new combinations. Rain changes the camera image and the friction at the same time. A truck hides a pedestrian. Construction paint conflicts with old lane markings. A cyclist appears from behind a parked van. The light is visible but the sun washes out its color. A lead car brakes because someone else, outside the model's view, stepped into the road. The most valuable production test is therefore not whether the model follows a requested speed. It is whether the safe set stays safe when the evidence is incomplete. Start with perception corruption. Blur a traffic light, occlude a stop sign, remove one tracked actor, delay a motion estimate and inject a false detection. Record which criterion score changes and whether the system becomes more conservative when its evidence degrades. Unknown should not quietly become safe. Then test dynamics. Change tire grip, vehicle mass, brake response, controller delay and road grade. The scoring head reasons about candidate speeds. The physical car has to realize the chosen speed and stop within the assumed envelope. Connect those two layers in the acceptance report. Test interaction. Use cut-ins, hesitant pedestrians, bicycles, emergency vehicles and agents that do not follow the logged future. The collision targets in training use recorded actor motion. Real participants can react to the autonomous vehicle and change their plan. That feedback loop is the point of closed-loop driving. Next, audit the thresholds. A criterion score becomes feasible only after it crosses a chosen cutoff. Small score changes near that boundary can produce a different selected speed. Sweep the threshold under many weather, traffic and perception conditions. Look for brittle jumps, oscillation and repeated braking. The selection rule deserves its own audit. Maximum, median and requested-speed policies can all use the same score outputs and produce different behavior. Treat the rule as part of the safety-critical software, not a harmless preference knob. Log the rejected options. For every decision, preserve the predicted path, candidate speeds, three criterion scores, threshold, selected policy, chosen speed and fallback reason. If the vehicle slows, the reviewer should be able to see whether the red-light branch, stop-sign branch or collision branch caused it. That visibility is the best part of the design. It turns one opaque trajectory into a set of smaller claims. Smaller claims are easier to test. They are not automatically true. The paper's supplementary results show why a single headline score is not enough. On the already strong TFv6 backbone, traffic-sign and give-way abilities improved, while overtaking and emergency-braking scores fell. The authors connect that tradeoff to a modest Driving Score decline on that backbone. That is not a fatal flaw. It is the kind of result a useful paper should expose. A safety feature that improves one family of scenarios can reduce performance in another. The acceptance table needs scenario-level changes, not just an average. The authors also omit Bench2Drive's Comfort metric from their main comparisons because they argue that its implementation rewards standing still. In their analysis, models that stall or creep can appear highly comfortable because motion amplitudes remain small. That is another healthy warning. Metrics can teach the wrong lesson. Do not replace one questionable aggregate with another. Pair speed adherence and driving score with route completion, collision responsibility, traffic-rule compliance, false stops, passenger motion, intervention rate and distance traveled before a failure. Measure the fallback. When every candidate is rejected, does the vehicle brake smoothly, stop in time, remain in a safe position and communicate its state? Can it resume without oscillating between zero and a high candidate speed? Test the handoff to the controllers. CLAP-AD converts the predicted path and selected target speed into steering, throttle and brake commands through separate controllers. A correct high-level choice can still fail in control. Log command delay, saturation, tracking error and the distance between the planned stop and the physical stop. Keep a human gate for deployment changes. Changing the threshold or selection policy can alter behavior without retraining the model. That makes customization convenient. It also means a small configuration change can materially change road conduct. Version those settings. Review them. Regression-test them. Do not let an efficiency tweak arrive as an innocent number in a configuration file. CLAP-AD has a sensible engineering instinct. Separate the decision that is mostly geometric from the decision that has several acceptable answers. Give safety criteria their own outputs. Let the system explain why it rejected a speed. The next step is to make every score survive the messy road between a camera and a brake pad. The path says where. The score suggests how fast. Traffic gets the final vote.