Autonomous driving

Autonomous driving is the sustained performance by a vehicle system of part or all of the dynamic driving task. That task includes steering, acceleration, braking, monitoring the road environment, and responding to events. SAE International classifies driving-automation features from Level 0 through Level 5 according to which actor performs the task and, when needed, the fallback response.^[1] The classification applies to a feature in a defined operating context, not automatically to every capability of a vehicle.

The term is often used loosely. In regulatory and engineering usage, an automated driving system (ADS) performs the entire dynamic driving task while engaged and therefore corresponds to SAE Levels 3 through 5. A Level 2 system can control steering and speed at the same time, but it remains driver assistance: the human driver must continuously supervise it and remains responsible for the driving task.^[1][2] This distinction affects system design, testing, crash reporting, and the claims that can reasonably be made about safety.

Autonomous driving combines artificial intelligence, computer vision, localization, mapping, prediction, motion planning, control, vehicle engineering, human factors, and fleet operations. Deployed features remain bounded by operational conditions. Examples include a conditionally automated Level 3 feature approved for particular motorway use in Germany and a Level 4 driverless passenger-service permit with an explicit operational design domain in California.^[20][21] Neither example implies unrestricted Level 5 operation.

Levels of driving automation

SAE J3016 defines six levels by the allocation of the dynamic driving task and fallback role.^[1]

Scroll sideways for more →

The levels are not a simple ladder of sensor count or software sophistication. They describe the expected roles for a particular feature. A vehicle can contain Level 0 emergency intervention, a Level 2 motorway-assistance feature, and a separately defined automated-parking feature. Marketing labels such as "autopilot" or "self-driving" do not determine the SAE level.^[1]

Warnings and momentary crash-avoidance interventions are not sustained driving automation under J3016. Automatic emergency braking can act on the vehicle, for example, without changing the driver's continuing responsibility for the driving task. Conversely, a Level 3 feature performs the complete task while engaged even though it can require a fallback-ready user to resume driving.^[1]

Operational design domain

An operational design domain (ODD) is the set of conditions in which an automated feature is designed to operate. An ODD can specify:

• road types, lanes, intersections, and access restrictions;
• geographic or mapped areas;
• speed ranges and traffic conditions;
• weather, visibility, lighting, and road-surface conditions;
• required lane markings, localization quality, or infrastructure support;
• vehicle state, payload, and other operating constraints.

ODD boundaries are part of the safety specification. The system must determine whether required conditions are satisfied, prevent or end activation when they are not, and handle a foreseeable exit from the domain. The 2026 UN Global Technical Regulation on ADS treats ODD analysis, safety requirements, scenario generation, validation, and in-service monitoring as connected parts of the assurance process.^[13]

Fallback and minimal-risk response

Fallback is the response when an ADS cannot continue the dynamic driving task. At Level 3, the expected fallback can include a takeover by a fallback-ready user. At Level 4, the system must manage fallback within its ODD without assuming that an occupant will become the driver. A minimal-risk response can involve slowing, stopping in a suitable location, activating hazard signals, or another maneuver selected for the circumstances.^[1][13]

The distinction matters because a takeover request is not itself a safety solution. Detection range, warning timing, driver state, road geometry, surrounding traffic, and the time needed to understand the situation all affect whether a transition can be completed safely.^[8]

Historical development

Research on automated road vehicles predates modern deep learning. In 1989, Carnegie Mellon University's ALVINN used a three-layer neural network to map camera and laser-range-finder input to a road-following direction. Its authors reported successful road-following tests under limited field conditions, making it an early example of learned sensor-to-control behavior.^[3]

The US Defense Advanced Research Projects Agency then used public competitions to test integrated autonomous vehicles. No entrant completed the 2004 Grand Challenge desert course. Five vehicles completed the 2005 event, which was won by Stanford's Stanley.^[4] Stanley combined probabilistic reasoning, machine learning, perception, collision avoidance, and vehicle control in a system designed for high-speed off-road driving.^[5]

The 2007 Urban Challenge added moving traffic, intersections, road rules, and urban maneuvers. Carnegie Mellon University's Boss won the event. Its architecture used onboard positioning, laser, radar, and camera sensing, with separate mission, behavioral, and motion-planning layers. The published system account also emphasized repeated regression testing during development.^[6] These competitions demonstrated integrated capabilities, but their routes and rules did not represent every condition encountered on public roads.

System architecture

An ADS is a closed-loop system. It repeatedly observes the vehicle and environment, estimates their state, predicts how the scene may change, selects a maneuver, controls the vehicle, and checks the outcome. A common modular architecture contains the following functions:^[7]

1. Sensing and vehicle-state estimation. Sensors measure the surrounding environment and the vehicle's motion, health, and actuator state.
2. Localization and mapping. The system estimates where the vehicle is relative to a coordinate frame, road geometry, and relevant map features.
3. Perception and tracking. Software estimates lanes, drivable space, traffic controls, objects, and other road users, then tracks them over time.
4. Prediction and scene assessment. The system estimates possible future motion and interactions while representing uncertainty.
5. Behavior and motion planning. Planning selects a driving maneuver and a feasible trajectory consistent with traffic rules, safety constraints, and vehicle dynamics.
6. Control. Feedback controllers translate the trajectory into steering, braking, acceleration, and other actuator commands.
7. Supervision and fallback. Independent monitoring detects faults, degraded capability, ODD exits, or unreasonable behavior and initiates a safe response.
8. Human and operational interfaces. Displays, alerts, remote assistance, maintenance processes, and fleet systems communicate state and support operation.

These functions are logical responsibilities rather than a mandatory software layout. They can be implemented as separate modules, learned jointly, or combined in a hybrid design.

Sensors and localization

Automated vehicles commonly combine cameras, radar, lidar, ultrasonic sensors, satellite navigation, inertial measurement, wheel odometry, and vehicle-network signals. The modalities have different strengths and failure modes. Cameras provide color and texture but are affected by illumination and do not directly measure depth. Radar measures range and relative velocity and can operate across a range of lighting conditions, but its returns are comparatively sparse. Lidar provides detailed three-dimensional geometry, while weather, surface properties, occlusion, and sensor configuration can affect its measurements.^[7]

Sensor fusion combines measurements to obtain a more useful state estimate than any one raw stream provides. Fusion does not make every sensor failure harmless. Its value depends on calibration, synchronization, coverage, independence of failure modes, diagnostics, and the software's treatment of conflicting evidence. The multimodal nuScenes dataset illustrates a research configuration with six cameras, five radars, one lidar, maps, and annotated scenes; its authors describe the modalities as complementary for detection and tracking.^[15]

Localization commonly fuses satellite positioning, inertial measurements, wheel motion, sensor observations, and map features. Dense urban areas, tunnels, construction, snow, changed lane markings, and stale maps can degrade one or more inputs. Map-based localization can be precise in a surveyed area, while simultaneous localization and mapping can update a representation from current observations. In both cases, the system needs an estimate of localization uncertainty rather than only a best position.^[7]

Perception and prediction

Perception turns sensor data into a scene representation. Typical tasks include object detection, semantic segmentation, lane and curb estimation, traffic-light recognition, free-space estimation, and multi-object tracking. Deep learning is widely used for these tasks, often together with geometric estimation and temporal filtering.^[7]

An ADS must also reason about what is not directly observed. Occluded pedestrians, a vehicle emerging from a side street, unusual loads, temporary signs, hand gestures, and emergency scenes can be safety-relevant. Prediction therefore considers multiple possible future paths rather than assuming that every actor follows a single forecast. Errors can propagate: a missed or misclassified object can distort prediction, which can then cause a planner to select an unsafe trajectory.^[7]

Uncertainty can arise from sensor noise, incomplete observations, model limitations, distribution change, and inherently ambiguous human behavior. Robust designs expose relevant uncertainty to later stages, preserve alternative hypotheses when necessary, and select conservative actions when the evidence is insufficient.^[7][13]

Planning and control

Planning is often divided into three scales. Route planning chooses roads or corridors. Behavioral planning selects actions such as yielding, changing lanes, or proceeding through an intersection. Motion planning produces a collision-avoiding trajectory that respects road geometry, vehicle dynamics, comfort, and other constraints. Boss used a comparable mission, behavioral, and motion-planning hierarchy in the 2007 Urban Challenge.^[6]

Control closes the loop between a planned trajectory and the physical vehicle. Steering, braking, and propulsion controllers must account for latency, actuator limits, tire-road interaction, grade, payload, and disturbances. Techniques include feedback control and model predictive control. Safety monitoring must also detect when the planned motion is no longer feasible or when actual motion departs from the plan.^[7][13]

Planning is not only an optimization problem. Hard constraints, traffic-law interpretation, right-of-way, interaction with vulnerable road users, and fallback behavior require explicit treatment. A trajectory that is comfortable and efficient under the most likely prediction can still be unsafe under a plausible alternative.^[7][13]

Modular, end-to-end, and hybrid designs

In a modular design, separately testable components connect sensor input to vehicle control. This supports decomposition, interface monitoring, and diagnosis, but errors and assumptions can accumulate across module boundaries. A learned end-to-end design trains a model to map a broader input directly to trajectories, controls, or driving decisions. ALVINN was an early end-to-end road-following system; later approaches have used imitation learning and reinforcement learning.^[3][7]

End-to-end learning can optimize representations across tasks, but training performance does not by itself establish safe behavior outside the training distribution. Interpretability, coverage, data quality, uncertainty, and independent constraint enforcement remain assurance concerns. Production-oriented architectures can therefore be hybrid: learned perception or prediction is combined with structured world models, constrained planning, runtime monitors, and independently engineered fallback paths.^[7][10][13]

Human roles and interfaces

Human responsibility changes discontinuously between levels. At Level 2, the driver performs the monitoring and fallback role even when both steering and speed control are active. A driver-monitoring camera or hands-on-wheel check does not convert the feature into an ADS. At Level 3, the system monitors the driving environment while engaged, but a fallback-ready user must be able to respond when requested. At Level 4, occupants are not expected to take over within the feature's ODD.^[1][2]

Transition design is a human-factors problem as well as an alerting problem. A 2019 meta-analysis combined 129 studies of takeover time. It found that mean takeover time varied with urgency, prior takeover experience, handheld-device use, visual non-driving tasks, and alert modality. The authors cautioned that a shorter takeover time is not automatically a better design target, because drivers need enough time to understand and respond to the situation.^[8]

Interfaces should communicate the current mode, availability, limitations, reason for a transition, and expected user action. They should minimize mode confusion and account for visual, auditory, and physical accessibility. For supervised systems, monitoring should address attention without implying that monitoring can compensate for an unclear feature boundary or an unrealistically short response window.^[1][8][13]

Remote support is also distinct from remote driving. A remote assistant may supply information, confirm an interpretation, or help select a route without continuously performing the dynamic driving task. If remote personnel can directly control vehicle motion, communication delay, link loss, operator workload, licensing, and cybersecurity become part of the operational safety case.^[1][11][13]

Safety engineering

ADS safety cannot be reduced to a single perception score, number of test miles, or disengagement count. It concerns the behavior of a vehicle, its software and hardware, human users, fleet processes, maintenance, maps, remote services, and the organizations that manage them.^{[9][10][11][13]}

Hazard sources

Relevant hazard sources include:

• hardware or software faults;
• inadequate specifications, such as an ODD boundary that omits a foreseeable condition;
• correct implementation of an intended function that is nevertheless unsafe in a particular scene;
• perception, prediction, or planning insufficiency;
• training-data gaps, model drift, or an unsuitable machine-learning objective;
• misuse, mode confusion, delayed takeover, or inaccessible interfaces;
• map, calibration, maintenance, or configuration errors;
• cybersecurity compromise or unsafe software updates;
• weaknesses in testing, incident reporting, change control, or organizational oversight.

ISO 21448:2022 addresses safety of the intended functionality, including unreasonable risk caused by specification or performance insufficiencies in systems that depend on complex sensors and processing algorithms. It covers design, verification, validation, operation, and reasonably foreseeable misuse, while distinguishing those issues from faults and cybersecurity threats.^[9] ISO/PAS 8800:2024 addresses safety-related behavior arising from output insufficiencies and errors in automotive AI elements and frames safety properties as evidence for an assurance claim.^[10] ISO/SAE 21434:2021 provides a lifecycle cybersecurity-engineering framework for road-vehicle electrical and electronic systems.^[11]

These scopes overlap in a real ADS safety case. A camera can be electrically healthy yet produce insufficient information in glare. A well-trained model can receive inputs unlike its training data. A safe release can become unsafe after an incompatible map or software update. Assurance therefore needs traceability from hazards and requirements to design evidence, test results, configuration, field monitoring, and corrective action.

Safety case and safety management

A safety case is a structured argument that a system is acceptably safe for a stated use, supported by evidence. For ADS, the claim must be bounded by the feature, vehicle configuration, ODD, operating organization, and software version. Typical evidence includes:

• an explicit ODD and system boundary;
• hazard analysis and safety requirements;
• architectural measures, diagnostics, redundancy, and degraded modes;
• data and model governance;
• scenario-based simulation, track tests, and public-road evidence;
• human-factors and accessibility evaluation;
• cybersecurity and update controls;
• incident response, field monitoring, and change-impact analysis;
• independent review, audit, and documented residual risk.

The 2026 UN ADS regulation requires a safety-management system, a documented safety case, validation across multiple test pillars, and in-service monitoring. It also requires manufacturers to manage safety through the ADS lifecycle rather than treating approval as a one-time test.^[13] California's 2026 autonomous-vehicle regulations similarly require a structured safety case and staged progression from testing with a safety driver to driverless testing before commercial deployment, with mileage thresholds and expanded reporting.^[19]

Redundancy is useful only when failures are sufficiently independent and detected. Two sensors that share an obstructed field of view, a common power supply, or the same erroneous map may not provide meaningful protection against that shared cause. A fallback controller also needs valid state information, functional actuators, and a reachable safe maneuver.^[9][13]

Verification and validation

No single validation method covers the ADS problem. Road testing samples real interactions but exposes only a small portion of the scenario space. Closed-course testing is repeatable but simplified. Simulation can vary conditions and safely exercise dangerous events, but its conclusions depend on model fidelity and validation. Analysis and formal methods can establish selected properties under stated assumptions, while field monitoring reveals operational evidence after deployment.^[12][13][14]

Scenario-based evaluation

A scenario specifies the road geometry, actors, initial states, environmental conditions, and events relevant to a test. Scenarios can be:

• functional, expressed in natural-language terms such as a pedestrian emerging from occlusion;
• logical, expressed as parameter ranges and relationships;
• concrete, expressed as exact values for a reproducible run.

Scenario catalogs can be derived from crash data, naturalistic driving, field incidents, requirements, hazard analysis, expert review, and systematic variation. ISO 34502:2022 describes a scenario-based safety-evaluation framework for ADS development on limited-access highways. Its stated scope excludes human-machine-interface, misuse, and cybersecurity issues, illustrating why a scenario standard is one part of a larger assurance program.^[12][13]

The UN regulation uses a multi-pillar approach that connects scenario analysis with virtual testing, track testing, real-world testing, audit, and in-service reporting. It also requires evidence for the credibility and uncertainty of simulation toolchains.^[13] Passing a finite test catalog does not prove safety in every possible scene; the catalog, parameter coverage, oracle, and residual gaps all need justification.

Simulation and datasets

Simulation supports repeatable testing, controlled fault injection, rare-event variation, and tests that would be dangerous to stage. CARLA is an open-source urban-driving simulator designed for development, training, and validation. Its original paper described configurable sensor suites and environmental conditions and compared modular, imitation-learning, and reinforcement-learning approaches in controlled scenarios.^[14]

Research datasets support perception, prediction, and planning benchmarks. nuScenes contains 1,000 annotated scenes of 20 seconds each, with a 360-degree sensor suite of cameras, radar, and lidar.^[15] Such datasets make methods comparable, but benchmark performance is not equivalent to whole-vehicle safety. Dataset geography, sensor configuration, annotation policy, class balance, and weather coverage constrain what a result demonstrates.

Simulation and data-driven tests should be linked to requirements and field evidence. Useful practices include preserving test provenance, reproducing failures, validating simulator components against measurements, measuring uncertainty, tracking software and model versions, and rerunning affected tests after a change.^[13][14]

Metrics

Metrics can include collision and injury outcomes, traffic-rule violations, minimum distance, time to collision, hard braking, fallback frequency, localization integrity, perception recall for safety-critical classes, takeover quality, and service interruptions. Each metric has a denominator and a scope. A crash count without exposure, road type, geography, speed, traffic mix, reporting threshold, and ODD does not support a fair comparison.^[2][13][17]

Leading indicators such as failed diagnostics or safety-critical interventions can reveal emerging problems before severe crashes accumulate. Lagging indicators such as injuries measure outcomes but are statistically sparse. A mature monitoring program uses both, investigates precursors, and does not optimize a proxy at the expense of unmeasured risk.^[13][17]

Interpreting safety evidence

The central empirical question is not whether an ADS has ever crashed, but how its risk compares with a suitable benchmark within the same conditions and with comparable reporting. That requires aligned exposure, outcome definitions, vehicle and road types, geography, time, and uncertainty.^[2][17]

In the United States, NHTSA's Standing General Order requires named manufacturers and operators to report certain crashes involving ADS or Level 2 driver assistance. NHTSA warns that the public data can include duplicates, incomplete information, corrected system classifications, and differences in what reporting entities can observe. Reporting requirements also differ between ADS and Level 2 systems. NHTSA therefore cautions against comparing raw entity counts without considering mileage, operating location, system capability, and access to crash data.^[2]

A 2025 peer-reviewed study compared Waymo's rider-only Level 4 operation with human benchmarks aligned by location, road type, and vehicle type. Across 56.7 million rider-only miles through January 2025, it reported statistically lower aggregate crashed-vehicle rates for any-injury-reported, airbag-deployment, and suspected-serious-injury-or-worse outcomes, with no statistically significant disbenefit among the 11 crash-type groups examined.^[17] All authors were affiliated with Waymo, the company supplied the mileage through a public site, and the paper identifies residual differences that may remain between the ADS exposure and human benchmarks. The result is evidence about that system, release history, service model, and ODD in the studied locations. It is not a result for every ADS or for unrestricted driving.

Statistical significance also does not remove the need to inspect severity, confidence intervals, crash contribution, reporting completeness, or rare scenarios. A system can reduce aggregate risk while retaining weaknesses in a particular interaction. Conversely, a high count can reflect greater exposure or more complete telemetry rather than a higher rate.^[2][17]

Incidents and organizational learning

Public-road incidents show how technical and organizational factors interact. In March 2018, an Uber developmental ADS test vehicle struck and killed a pedestrian in Tempe, Arizona. The NTSB found that the ADS detected the pedestrian 5.6 seconds before impact but did not correctly classify her or predict her path. The design precluded emergency braking in the relevant condition and relied on operator intervention. The NTSB determined that operator distraction was the probable cause and identified Uber's inadequate safety-risk assessment, ineffective operator oversight, insufficient measures against automation complacency, and Arizona's inadequate testing oversight as contributing factors.^[16]

The case was not only a perception failure. It involved the allocation of fallback responsibility, braking design, operator monitoring, organizational safety culture, and regulatory oversight. It demonstrates why a safety case must cover the complete operating system and why foreseeable human behavior cannot be treated as an external detail.

Reporting is another safety control. In 2024, NHTSA entered a consent order with Cruise after finding that reports about an October 2023 driverless crash omitted post-impact details, including that the vehicle dragged a pedestrian approximately 20 feet before stopping. The order imposed monetary and oversight provisions.^[18] Accurate, timely reporting enables regulators and operators to identify hazards, compare evidence, and verify corrective action.

Regulation and deployment

ADS regulation is divided among vehicle approval, road-traffic rules, driver and operator licensing, testing permits, commercial-service authority, privacy, cybersecurity, insurance, and local operations. The allocation differs by jurisdiction.^[19][20][22]

The European Union's Implementing Regulation (EU) 2022/1426 established technical procedures for approving ADS in fully automated vehicles for defined uses, including operations within predefined areas, hub-to-hub transport, and automated valet parking. Its requirements address the ODD, dynamic driving task, safety concept, scenarios, validation, and in-service information.^[22]

In June 2026, UNECE's World Forum for Harmonization of Vehicle Regulations adopted a UN Global Technical Regulation and a parallel UN Regulation for ADS. The framework uses lifecycle safety management, safety-case assessment, credible testing, and in-service monitoring.^[13][23] A UN rule does not by itself authorize every vehicle to operate everywhere; it supplies harmonized technical requirements within the relevant treaty and national implementation systems.

California's 2026 rules expanded its permit framework for light-duty and heavy-duty autonomous vehicles. They require staged testing, a structured safety case, remote-operations qualifications, first-responder interaction plans, collision and operational reporting, and allow targeted restrictions on fleet size, location, speed, or weather.^[19] Separate commercial passenger-service authority is administered by the California Public Utilities Commission. Its current permit list identifies Waymo as holding a driverless-deployment permit and links that authority to an explicit ODD statement and service-area maps.^[20]

Level 3 deployment follows a different model. Mercedes-Benz states that Germany's Federal Motor Transport Authority approved an update to its Drive Pilot feature for conditionally automated operation in flowing motorway traffic at up to 95 km/h under specified conditions. The driver can perform other activities while the feature is active but must remain available for a requested takeover.^[21] This vendor account illustrates a driver-available Level 3 feature, not a driverless Level 4 service.

These examples show why availability should be described by feature, ODD, jurisdiction, vehicle configuration, and date. A permit is not proof of universal capability, and a deployment in one city or road class does not establish performance in another.

Open technical and policy problems

Autonomous driving remains constrained by several connected problems:

• Rare and changing conditions. Construction, unusual vehicles, severe weather, emergency scenes, damaged infrastructure, and uncommon human behavior are difficult to sample and model.^[12][13][14]
• Assurance of learned components. High average benchmark accuracy can coexist with dangerous localized failures. Specifications, uncertainty, distribution shift, data provenance, and change control remain active assurance problems.^[9][10]
• Safe interaction. An ADS must communicate and negotiate with pedestrians, cyclists, human drivers, police, road workers, and emergency responders without assuming perfectly rule-following behavior.^[13][19]
• Transitions and mode understanding. Level 2 supervision and Level 3 takeover create different but persistent human-factors risks.^[8]
• Validation completeness. Scenario coverage, simulator credibility, real-world representativeness, and the treatment of unknown scenarios require explicit arguments rather than a mileage total.^[12][13]
• Operational governance. Maintenance, mapping, remote support, cybersecurity, incident response, software updates, and organizational learning can change risk after initial approval.^[11][13]
• Comparable evidence. Public crash and exposure data need consistent definitions, denominators, and ODD context to support meaningful evaluation.^[2]

Progress is therefore measured not only by how far a prototype drives, but by whether a defined feature can sustain safe behavior, detect its limits, produce a safe fallback, and support a transparent lifecycle safety argument.

References

1. ^SAE International. "Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles," SAE J3016_202104. Revised April 30, 2021. doi:10.4271/J3016_202104.
2. ^National Highway Traffic Safety Administration. "Standing General Order on Crash Reporting." Current crash-reporting requirements, data, and limitations for ADS and Level 2 ADAS. Accessed July 28, 2026.
3. ^Dean A. Pomerleau. "ALVINN: An Autonomous Land Vehicle in a Neural Network." *Advances in Neural Information Processing Systems*, 1989.
4. ^Defense Advanced Research Projects Agency. "Grand Challenge." DARPA innovation timeline. Accessed July 28, 2026.
5. ^Sebastian Thrun et al. "Stanley: The Robot that Won the DARPA Grand Challenge." *Journal of Field Robotics* 23, no. 9 (2006): 661-692. doi:10.1002/rob.20147.
6. ^Chris Urmson et al. "Autonomous Driving in Urban Environments: Boss and the Urban Challenge." *Journal of Field Robotics* 25, no. 8 (2008): 425-466. doi:10.1002/rob.20255.
7. ^Ekim Yurtsever, Jacob Lambert, Alexander Carballo, and Kazuya Takeda. "A Survey of Autonomous Driving: Common Practices and Emerging Technologies." *IEEE Access* 8 (2020): 58443-58469.
8. ^Bo Zhang, Joost de Winter, Silvia Varotto, Riender Happee, and Marieke Martens. "Determinants of Take-Over Time from Automated Driving: A Meta-Analysis of 129 Studies." *Transportation Research Part F* 64 (2019): 285-307.
9. ^International Organization for Standardization. "ISO 21448:2022, Road Vehicles: Safety of the Intended Functionality." June 2022.
10. ^International Organization for Standardization. "ISO/PAS 8800:2024, Road Vehicles: Safety and Artificial Intelligence." December 2024.
11. ^International Organization for Standardization and SAE International. "ISO/SAE 21434:2021, Road Vehicles: Cybersecurity Engineering." August 2021.
12. ^International Organization for Standardization. "ISO 34502:2022, Road Vehicles: Test Scenarios for Automated Driving Systems: Scenario-Based Safety Evaluation Framework." November 2022.
13. ^United Nations Economic Commission for Europe. "Proposal for a New United Nations Global Technical Regulation on Automated Driving Systems (ADS), ECE/TRANS/WP.29/2026/139." May 22, 2026.
14. ^Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio Lopez, and Vladlen Koltun. "CARLA: An Open Urban Driving Simulator." *Proceedings of the 1st Annual Conference on Robot Learning*, 2017.
15. ^Holger Caesar et al. "nuScenes: A Multimodal Dataset for Autonomous Driving." *Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition*, 2020.
16. ^National Transportation Safety Board. "Collision Between Vehicle Controlled by Developmental Automated Driving System and Pedestrian, Tempe, Arizona, March 18, 2018." Highway Accident Report NTSB/HAR-19/03, 2019.
17. ^Kristofer D. Kusano, John M. Scanlon, Yin-Hsiu Chen, Timothy L. McMurry, Tilia Gode, and Trent Victor. "Comparison of Waymo Rider-Only Crash Rates by Crash Type to Human Benchmarks at 56.7 Million Miles." *Traffic Injury Prevention* (2025). doi:10.1080/15389588.2025.2499887.
18. ^National Highway Traffic Safety Administration. "NHTSA Announces Consent Order with Cruise After Company Failed to Fully Report Crash Involving Pedestrian." September 30, 2024.
19. ^California Department of Motor Vehicles. "New Autonomous Vehicle Regulations Strengthen Oversight and Enforcement, Authorize Trucks and Transit." April 28, 2026.
20. ^California Public Utilities Commission. "Autonomous Vehicle Program Permits Issued." Accessed July 28, 2026.
21. ^Mercedes-Benz Group. "Mercedes-Benz Increases Top Speed of Its Level 3 Automated Driving System to 95 km/h." December 17, 2024.
22. ^European Commission. "Commission Implementing Regulation (EU) 2022/1426 of 5 August 2022 Laying Down Rules for the Application of Regulation (EU) 2019/2144 as Regards Uniform Procedures and Technical Specifications for the Type-Approval of the Automated Driving System of Fully Automated Vehicles." *Official Journal of the European Union*, August 26, 2022.
23. ^United Nations Economic Commission for Europe. "UNECE Adopts First-Ever Global Rules Allowing Fully Autonomous Vehicles." June 24, 2026.