The Hard Problems Automated Driving Has Not Solved
Level 4 services now carry public passengers without a driver in several cities, and Level 3 features are approved in production cars under limited conditions. The unsolved problem is defining, validating and operating acceptable behavior across a domain whose coupled conditions can force an exit before the system runs out of options.
Perception under degraded conditions
Rain, snow, fog, darkness, glare, spray and dirt affect sensors differently. Heating and cleaning can keep a lens or lidar window usable, while radar supplies complementary evidence, but no hardware combination makes severe weather disappear.
The system must estimate its current perception capability. That is harder than detecting a completely failed sensor. A partially obscured camera or a radar reflection may still produce plausible data with lower reliability.
Reducing speed can restore stopping margin, but only if surrounding traffic can understand the behavior and the system still has a safe place to stop or leave service.
Temporary and ambiguous roads
Maps and training data are built from yesterday. Road workers change lanes, cover markings, move barriers and direct traffic with hand signals. Emergency responders intentionally override normal rules. A delivery truck can block the view of a temporary sign.
These scenes combine perception, semantic understanding and social context. The vehicle needs to identify authoritative temporary control, reason about occlusion and proceed without blindly following either the map or the vehicle ahead.
Human drivers also negotiate with eye contact, vehicle position and small movements. Automated vehicles must communicate intent clearly without inventing unsafe conventions.
The long tail is not a list
Developers often call rare or unusual situations “edge cases.” The term can be misleading. Many are combinations of ordinary factors: a common pedestrian movement behind a common parked van during common rain.
It is impossible to enumerate every scene. The deeper requirement is resilient behavior under uncertainty:
- do not outdrive current visibility;
- preserve alternatives before committing;
- treat occluded space as uncertain, not empty;
- detect when the scene is outside validated experience; and
- use a safe fallback that fits the road.
Machine-learning models can generalize, but they can also fail confidently on unfamiliar inputs. Independent constraints, runtime monitoring and systematic scenario generation remain necessary.
Human factors at the automation boundary
Level 2 depends on continuous human supervision while making that supervision monotonous. Drivers can over-trust smooth performance, learn to satisfy weak steering-wheel alerts without watching the road or misunderstand a product name.
Level 3 removes continuous supervision but creates a transition problem. A fallback-ready user needs time to stop a secondary activity, orient to the scene and take control. The system must recognize a limit early enough to make that request meaningful.
Mode confusion can occur when the interface does not make the active level, availability or requested response clear. Foreseeable misuse should be addressed in design rather than dismissed as a warning-label problem.
Proving safety before rare harm occurs
Serious crashes are rare relative to distance travelled. Demonstrating a small statistical difference can require enormous matched exposure, and raw mileage can hide easier road types or weather.
Simulation scales scenario coverage but depends on model fidelity. Closed-course tests are repeatable but simplified. Public-road testing is realistic but inefficient for rare hazards. Retrospective crash comparisons depend on reporting thresholds, severity definitions, geographic mix and suitable human benchmarks.
The challenge is to build a safety case from complementary evidence, not search for one decisive number. Evidence should be specific to the vehicle, software, operating domain and version.
Public data also need independent scrutiny. Company-reported safety results can be valuable when methods, denominators and downloadable records are disclosed. They should not be generalized beyond the measured domain.
Fallback without creating a new hazard
“Pull over safely” is not always available. A motorway may have no shoulder; a tunnel may block connectivity; a city street may be crowded; a stopped vehicle can itself become a collision risk.
The minimal-risk condition depends on remaining capability, road geometry, traffic and the failure. The vehicle may need to continue at reduced speed, complete a lane change, reach a refuge or stop in lane.
Remote assistance can help interpret an unusual scene, but communications may be delayed or unavailable. The onboard system still needs a safe response. If a remote human continuously controls motion, the architecture and claims should say so.
Scaling the operating system, not only the car
A Level 4 fleet depends on mapping, dispatch, charging, cleaning, calibration, maintenance, remote assistance, emergency response and local permits.
Expansion creates operational questions:
- Can depots charge enough vehicles without reducing service coverage?
- How quickly are dirty or damaged sensors detected and serviced?
- How are road closures and emergency instructions communicated?
- What support exists for passengers with disabilities or in distress?
- How are incidents preserved, reported and investigated?
A vehicle that can navigate a new city in testing is not automatically ready for public commercial service there.
Cost, energy and repair
Redundant compute, lidar, radar, cleaning systems and fault-tolerant actuation add cost, energy use and maintenance. Roof hardware can add drag. Compute and sensor loads reduce EV range and produce heat.
Consumer vehicles face a repair problem as well. A minor collision or windscreen replacement may require calibration. If a vehicle is sold with hardware for a future feature, obsolescence and long-term parts support matter.
Scale will reduce some component costs, but higher capability can consume the savings by adding coverage, compute or redundancy.
Regulation and cross-border inconsistency
Approval pathways differ between driver assistance, conditional automation and fully automated vehicles. Vehicle type approval, permission to test, permission to operate without a driver and authority to charge passengers are separate.
A feature can be technically present but disabled in one market. Rules for permitted secondary activities, event data, insurance and remote operation also differ.
International standards and UN regulations reduce fragmentation, but deployment remains local because road law, infrastructure and enforcement are local.
Transport outcomes are not guaranteed
An automated EV can reduce certain crash outcomes and eliminate tailpipe emissions in use. A fleet can also add empty repositioning kilometres, compete with public transport or increase travel demand.
Accessibility gains depend on vehicle design, pricing, service area and passenger support—not automation alone. Congestion gains depend on occupancy and total vehicle kilometres, not smoother control by one car.
The correct unit of evaluation is the transport service as well as the vehicle.
What would count as real progress
Progress is more than a new demonstration. Strong evidence includes:
- a clearly expanded and validated ODD;
- better Level 2 misuse safeguards;
- safe Level 3 transitions measured with human-factors evidence;
- driverless public service with transparent operating scope;
- matched crash-outcome data with reproducible methods;
- lower energy and hardware cost without weaker fallback; and
- regulatory approval that states exactly what was assessed.
Full Level 5 is not required for automated driving to be useful. The more credible path is bounded capability that expands only when the evidence supports the new boundary.
Sources
- ISO 34503:2023 — Operational design domain specification
- ISO 21448:2022 — Safety of the intended functionality
- IIHS — Research on partial and high automation
- NTSB — Driver-assistance and automated-driving safety recommendations
- Waymo — Testing and operating in adverse weather
- Waymo — Deployment-readiness acceptance criteria
- Oak Ridge National Laboratory — Energy use of sensing and compute
- European Union — Type approval rules for fully automated vehicles