CASE-31 · Case Study — Uber's Self-Driving Fatality: When Perception and Safety Both Failed
What happened
On the night of 18 March 2018 in Tempe, Arizona, an Uber test vehicle operating in autonomous mode struck and killed a pedestrian, Elaine Herzberg, who was walking a bicycle across a road outside a crosswalk. It was the first recorded pedestrian death involving a self-driving vehicle. The US National Transportation Safety Board's investigation found the automated system detected her about 5.6 seconds before impact — but a chain of design decisions meant it never braked, and the safety driver, watching a phone, reacted too late.
See it — a detection that led nowhere
flowchart LR A["Sensors detect object<br/>5.6s before impact"] --> B["Classifier flip-flops:<br/>vehicle? bike? unknown"] B --> C["Each re-class resets<br/>the motion track"] C --> D["Emergency braking<br/>DISABLED in autonomy"] D --> E["Inattentive safety driver<br/>→ no intervention"]
The root cause
This was a defence-in-depth collapse, not a single bug. The perception system repeatedly re-classified the pedestrian — as an unknown object, then a vehicle, then a bicycle — and each re-classification threw away the object's motion history, so the system never built a stable track predicting she was on a collision course. Worse, engineers had disabled the vehicle's factory automatic emergency braking while in autonomy (to avoid erratic stops) and suppressed the system's own hard-braking, choosing instead to rely on the human safety driver to intervene — but provided no alert to wake that driver. The final layer, the human, was disengaged. Every safeguard had been individually rationalised, and together they left nothing between detection and death.
The fix that would have prevented it
Safety-critical ML demands layered, independent fallbacks: never let a single flaky classifier be the last line of defence, and never disable a working safety system (factory AEB) in favour of an unproven one without an equivalent backstop. Persist object tracks across re-classification so uncertainty about what something is doesn't erase certainty about where it's heading. Define and enforce the operational design domain — the exact conditions the system is validated for — and degrade gracefully outside it. And treat the human monitor as a system component with its own failure mode: complacency is predictable, so you must detect and alert on inattention, not assume vigilance.
The blast radius
A person died. Uber suspended all autonomous testing, later exited the self-driving business, and reached a settlement with the family. The safety driver was ultimately charged. The NTSB report reshaped how the entire industry and regulators think about test-vehicle safety cases, driver-monitoring requirements, and the danger of "automation complacency" — the well-documented tendency of humans to stop paying attention to a system that usually works.
The lesson
In safety-critical systems, an uncertain model must fail toward caution, and no single component — perception, planning, or the human backstop — can be trusted alone. Disabling a proven safeguard to smooth out a new one, and leaning on a bored human as the final catch, is how independently reasonable choices combine into a fatal system. Defence in depth is not redundancy for its own sake; it is the acknowledgement that any one layer will, eventually, fail.
Where it rhymes
- CASE-29 (Knight Capital) — an automated system with its human off-switch too slow to matter.
- CASE-18 (Stuxnet) — a physical-world outcome from software behaving exactly as configured.
