K6.08.1takeover request lead timedesignresearch

Takeover needs enough lead time

Aliases: TOR · time budget · fallback-ready user · takeover time

What it is

Takeover lead time is the budget between a takeover request (TOR) and the moment the driver must actually hold lateral and longitudinal control. A chime is not completion. The person has to leave a non-driving task, rebuild who is beside them and why the system is handing over, then put hands and feet where they can act. SAE J3016 writes conditional driving automation as: the system performs the dynamic driving task inside its operational design domain (ODD) and, on exit, must request a fallback-ready user. A short window is only an accident announcement. This entry is about whether the time is enough. It is not about how many sensory channels carry the alert, and not about how the interface names who is driving the instant control transfers.

Why it happens

Once eyes, hands, and attention go to video, menus, or talk, the driver is out of the loop. Situation awareness has to be rebuilt through perceive–understand–project: which lane, whether the neighbor is accelerating or cutting in, whether the handoff is an upcoming ramp or a sensor that can no longer see. That rebuild is not an instantaneous switch. Deeper non-driving tasks, denser traffic, and less preview all lengthen the window. Systems also tend to speak when they are already losing their grip—the very moment the scene is hardest to read—so the budget is squeezed where it is most needed. Shortening the window does not make people faster; it deposits an unfinished rebuild into the first seconds after takeover.

Studying it

Run takeovers in a driving simulator, not a parked bench that only times a button press. Let the system drive for a stretch, then issue a TOR at a scheduled or sudden point.

Independent variables: time from request to required control, type of non-driving related task (visual-manual / auditory / cognitive), whether the request can be anticipated from the road, scene complexity. Dependent variables: time to stable control, post-takeover path error, conflicts or severe departures, situation-awareness scores, moment of first effective steer or brake.

Lab participants usually know a takeover is coming, so vigilance is higher than on a real long trip; uneventful miles on the road drive monitoring down. Mean takeover time is not a reusable number of seconds—the same interval is not the same difficulty on a straight cruise and in a work-zone lane change. Eye tracking and steering torque separate “hands are on” from “the road has been read”; the latter is what the budget is supposed to buy.

Where it stops holding

Parking, low-speed valet, and closed campuses keep the person in the loop, so lead-time pressure is much smaller. Level 2 and below still require continuous supervision; an on-screen “please take over” is mostly a feature exit, not pulling back someone who was legally allowed to look away. Copying a conditional-automation budget onto a hands-off reminder for driver support both startles people and trains the wrong expectation. Sudden mechanical loss may not yield a human-factors-adequate window at all; the problem then is a minimal-risk manoeuvre, not issuing the chime half a beat earlier. Simulator success with young participants, short tasks, and no real crash cost does not transfer to production sign-off.

Applying it

  • Specify the earliest moment a request must fire for ODD exit, sensor degradation, and driver non-response separately; do not specify only “play a sound.”
  • Bind allowed cabin task depth to the budget: if video is permitted, budget for returning from video, not for someone whose hands are already on the wheel.
  • For foreseeable exits (leaving the motorway), count down or degrade before the actual handoff so reconstruction happens first; use a stronger interrupt for sudden requests, and do not pretend a window exists when it does not.
  • Verify in a simulator or closed-road run that includes non-driving tasks: look at the distribution of time from TOR to stable control and at the post-takeover path. If the tail still shows people meeting a conflict before they have read the road, lengthen the budget, not the chime volume.

Related

  • Within the group: K6.08.2 Takeover alerts need redundant channels · K6.08.3 System state must be clear the instant takeover completes
  • Adjacent: K6.09 Expressing Automation State · X4.05 Takeover and Handoff · A5.03 Sustained attention and vigilance decrement
  • Search terms: takeover request · TOR lead time · out of the loop · SAE J3016

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/K6.08.1