Problem Statement: L4 Autonomous Mobility Platform
Problem Statement: L4 Autonomous Mobility Platform — autonomous vehicle system design depth
Problem Statement: L4 Autonomous Mobility Platform
Design a production L4 autonomous vehicle platform (Waymo/Cruise-class robotaxi): a closed sense-plan-act loop on the vehicle, a fleet operations center (FOC) overseeing hundreds of cars, and regulatory-grade logging where every safety-critical decision can be replayed deterministically. L4 means the car handles the entire driving task inside its Operational Design Domain (ODD) — a geofenced area, set weather, set speeds — with no human fallback within that domain.
The system splits into two planes with opposite requirements:
- On-vehicle real-time loop. Perception → prediction → planning → control at a hard cadence (sensors 10–40Hz, planning p99 in the low tens of milliseconds). It is deterministic, safety-critical, and local — it must keep working with the network cut, because a robotaxi cannot pause for the cloud.
- Fleet/cloud control plane (FOC). Dispatch, remote assist, HD-map distribution, OTA updates, incident triage, and the evidence pipeline. It is elastic, eventually-consistent, and throughput-bound — it ingests a sensor-log firehose and proves the fleet is safe.
What makes it hard (and what interviewers probe):
- Safety is the product. The headline metric is disengagements per 1,000 miles and collision frequency, not QPS. A minimal-risk-condition ladder (full → degraded → pull-over → safe-stop) governs how the car fails.
- Determinism for evidence. Any incident must replay bit-for-bit from logged inputs, because regulators (and courts) will ask 'why did the car do that?'
- The data firehose. Each vehicle generates terabytes of sensor data per day; you cannot upload all of it, so the design is about which data to keep and when.
The failure stories that prove domain fluency: sensor dropout mid-merge, phantom braking from lidar multipath, and HD-map version skew across the fleet — each maps to a concrete mitigation later in the design.
Key Highlights
- •sense-plan-act loop with safety case
- •ODD geofencing and weather gates
- •fleet operations center (FOC) oversight
- •regulatory incident replay
Minimal-Risk-Condition ladder — how an L4 vehicle degrades instead of crashing
An L4 car never just 'fails' — faults step it down an MRC ladder (full → degraded → pull-over → safe-stop). Worse or actuator-level faults select a more conservative action, so loss of a sensor degrades driving while loss of brakes triggers an immediate safe stop.
1 # L4 safety: faults never 'crash' the car -- they step it down a Minimal Risk 2 # Condition (MRC) ladder. Worse faults -> a more conservative action. 3 4 from enum import IntEnum 5 6 class MRC(IntEnum): 7 FULL = 0 # nominal autonomy 8 DEGRADED = 1 # reduced speed / simpler maneuvers 9 PULLOVER = 2 # leave the traffic lane, stop safely 10 STOP = 3 # immediate in-lane safe stop 11 12 def select_mrc(faults: dict) -> MRC: 13 if faults.get('brakes') or faults.get('steering'): 14 return MRC.STOP # actuator loss -> stop now 15 if faults.get('localization') or faults.get('primary_lidar'): 16 return MRC.PULLOVER # cannot localize -> exit traffic 17 if faults.get('one_sensor') or faults.get('planner_slow'): 18 return MRC.DEGRADED # degrade, keep driving 19 return MRC.FULL 20 21 def action_for(level: MRC) -> str: 22 return {MRC.FULL: 'drive', MRC.DEGRADED: 'slow_and_simplify', 23 MRC.PULLOVER: 'pull_over', MRC.STOP: 'safe_stop'}[level]
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I'll separate the deterministic on-vehicle real-time loop from the elastic FOC control plane, and anchor every decision in deterministic replay for evidence."
- "Let me quantify sense-plan-act loop with safety case before picking databases or cloud regions."