The levels of vehicle autonomy describe how driving work is divided between a person and a system. The familiar SAE scale runs from Level 0, where the person drives, to Level 5, where the system can perform the complete driving task without a domain-specific limitation. The most consequential changes concern supervision, takeover responsibility, and where the feature can operate.
For a driver or fleet manager, start with three questions: Who watches the road? Who responds when automation cannot continue? Under what conditions is the feature available? A level number becomes useful only when those answers are explicit.
On This Page
- The six levels
- Supervision and handover
- Operating domains
- Sensing, planning, and control
- Failures and performance
- Comparing specific features
The six levels at a glance
The following comparison uses SAE J3016's April 2021 terminology, reproduced in the Canadian Council of Motor Transport Administrators' 2022 guidelines, alongside NHTSA's public explanation. It concerns road driving. Applying the numbers to aircraft, underwater vehicles, or industrial robots requires a separate framework appropriate to that domain.
| Level | SAE name | What the engaged feature does | Human role |
|---|---|---|---|
| 0 | No Driving Automation | May warn or intervene briefly; no sustained driving automation | Performs the driving task |
| 1 | Driver Assistance | Sustains steering assistance OR speed and braking assistance | Drives, monitors, and performs the remaining tasks |
| 2 | Partial Driving Automation | Sustains steering AND speed and braking assistance | Continuously supervises and responds to road events |
| 3 | Conditional Driving Automation | Performs the complete driving task within its specified conditions | Remains ready to take over when required |
| 4 | High Driving Automation | Performs the complete driving task and fallback within its specified conditions | Need not provide fallback while the feature operates |
| 5 | Full Driving Automation | Performs the complete driving task and fallback without a domain-specific restriction | No driving or fallback role required |
Source basis: CCMTA's SAE classifications, page 15, and NHTSA's automation-level overview. Descriptions summarize roles rather than reproduce the standard's definitions.
Automatic emergency braking illustrates Level 0: a brief intervention does not make the vehicle a sustained automated driver. Adaptive cruise control illustrates Level 1 when it controls speed while the person steers. Combining continuous lane centering and speed control can provide Level 2 assistance, but the person still supervises. A hands-free interface alone does not change that responsibility. These distinctions follow NHTSA's explanation.
The dynamic driving task, or DDT, includes real-time vehicle control, observing and responding to traffic, and planning maneuvers. Choosing a destination or scheduling a trip sits outside that task. Consequently, a passenger entering a destination does not become the driver. CCMTA reproduces these distinctions in its terminology section and Appendix D.
Level 2, Level 3, and Level 4 change the handover question
At Level 2, the person is already driving and supervising. At Level 3, the automated driving system, or ADS, handles the full driving task while engaged, but depends on a fallback-ready person when required. At Level 4, it must handle fallback without depending on that response. These roles follow the SAE definitions reproduced by CCMTA. Smooth lane following alone does not establish which role applies.
Consider an illustrative route ending at a construction diversion. For a Level 2 feature, ask how the driver recognizes its limits while continuously supervising. For Level 3, ask how the system requests intervention and confirms the person has resumed control. For Level 4, ask what the vehicle does if its operating conditions no longer permit continuation and nobody intervenes. These are questions for the exact feature, not claims that every implementation uses the same warning or maneuver.
A stopped vehicle can also be the outcome of a managed failure. NHTSA's 2017 voluntary ADS guidance calls for documented responses to faults, degraded operation, and domain exit. It describes a stop, preferably outside an active traffic lane, as a possible minimal-risk outcome. The appropriate response depends on the failure and surroundings; a feature's label does not specify its stopping location.
The operating domain determines practical usefulness
The operational design domain, or ODD, describes the conditions for which an automated driving feature is designed. NHTSA's guidance includes road type, geographic area, speed range, weather, and day or night conditions. A service-area map alone is therefore incomplete. A mapped street might still fall outside the feature's weather or speed limits.
For procurement, write the mission before choosing the level. An illustrative fixed-route passenger service needs answers about every road segment, operating hour, and weather condition in its intended schedule. A broad highway assistance feature addresses a different task if a supervising driver is part of the operating model. Comparing those offers solely by their numbers hides the staffing and coverage differences that matter.
Level 5 removes the domain-specific restriction in the classification. This concerns road conditions a human driver could negotiate, not physically impassable routes. When comparing services, ask suppliers to distinguish commercial service boundaries from limits of the driving technology. A boundary on a booking map does not explain why the boundary exists.
For a concrete comparison, imagine a site operator evaluating passenger transport between two buildings. One proposal requires an attentive onboard driver throughout the route. Another proposes operation without that driver, but only on a designated road in specified conditions. The first question is whether the service needs to remove the driving role at all. The second is whether the restricted operating domain covers the actual journey, including boarding areas and the return trip. Neither proposal can be evaluated from a promotional label alone.
Ask each supplier to describe the same disruption: the designated road closes after a trip starts. Can the vehicle use an alternate route within its documented domain, must a qualified person resume driving, or does the service stop and arrange recovery? Request the operating procedure and evidence for the offered behavior. This illustrative comparison exposes a coverage-versus-human-dependence tradeoff without assuming a particular product can resolve the closure. A restricted service may fit a repeatable route while failing the requirement for flexible destinations.
How sensing becomes steering and braking
An automation level describes assigned driving functions; understanding an implementation also requires following its data through the system. The Autoware Foundation's AWSIM Labs architecture guide provides a concrete modular example:
- Sensing collects and prepares measurements from devices such as cameras, lidar, satellite-navigation receivers, and inertial sensors.
- Perception identifies relevant surroundings, including vehicles, pedestrians, lanes, and signals. Localization estimates the vehicle's position and orientation.
- Planning combines environmental, position, and map information into a trajectory.
- Control converts that trajectory into requested steering, acceleration, and braking.
- The vehicle interface exchanges commands and vehicle feedback with the actual platform.
These are distinct integration boundaries. A correct trajectory is not enough if the vehicle cannot execute the command as intended. For an engineering review, request interface documentation covering measurement timestamps, coordinate references, command units, operating modes, and fault indications. Treat these as verification questions for the selected implementation, rather than capabilities established by the presence of a software module.
The human interface also matters. NHTSA's guidance discusses communicating system state and assessing takeover readiness. Ask a supplier to demonstrate the difference between a feature being available, engaged, requesting intervention, and unavailable. A single attractive dashboard icon does not answer those four questions.
Timing is part of the implementation
Autoware's real-time performance guide describes measuring processing times to locate bottlenecks. It identifies influences including operating-system scheduling, memory allocation, shared processor resources, and processor-frequency variation. Its worked measurement procedure concerns Linux on Intel processors, so the details should not be generalized to every vehicle computer.
For the integrator, the implication is to evaluate when information becomes usable, as well as what it contains. Request measurements from sensor acquisition through the relevant planning and control outputs under the intended system load. A component's isolated processing result and a complete vehicle response answer different questions. More processing resources or a different algorithm should be justified against the measured bottleneck; neither automatically changes the feature's automation level.
Keep timing limits specific to the function being evaluated. A bound for a steering-control update is not interchangeable with a deadline for a person to respond to an intervention request. Require the supplier to explain each limit, its operating assumptions, and the response to exceeding it, rather than applying one generic response-time number across the system.
Evaluate failures and performance separately from the level
NIST's September 2024 report, Feature Description for Assessing Autonomous Vehicle Performance, connects a feature's purpose and operating conditions with expected behaviors, specifications, and relevant test scenarios. This supports a practical evaluation rule: compare documented behavior under matched conditions rather than treating a higher level as a measured safety or reliability score.
The following review prompts are editorial examples applying that approach. They are not a prescribed certification test suite.
| Scenario to examine | What to request from the supplier |
|---|---|
| Sensor view becomes obscured | Detection criteria, permitted degraded behavior, and the response when usable sensing is insufficient |
| Position estimate disagrees with the mapped road | How the disagreement is identified and which movement remains permitted |
| Intended route leaves the operating domain | Advance indication, continuation limits, and the fallback sequence |
| Steering or braking feedback fails to match a command | Fault detection, retained control capability, and stopping behavior |
| A person does not respond to an intervention request | The exact feature response, its limitations, and supporting demonstrations |
| Remote support cannot be reached | Which onboard decisions remain possible and what ends the trip |
Broader coverage, tighter control tolerances, and reduced dependence on a person should each be evaluated against the mission. Request results with the route, traffic, software configuration, and environmental conditions identified. Distinguish trip completion from fallback success: a vehicle can end a trip appropriately without delivering the passenger to the requested destination. These are evaluation choices, not numerical claims about any supplier.
Remote assistance needs its own definition. In its February 2026 explanation, Waymo says its assistance staff respond to information requests from the ADS, which can accept or reject their advice; they do not remotely drive the vehicles. That is the operator's account of its architecture. When reviewing another service, establish whether people supply information, authorize an action, or actually control vehicle motion. Do not assume those roles are interchangeable.
Finally, distinguish a successful fallback from readiness to resume service. In the stopped-vehicle scenario, request the procedure for identifying the fault, assisting occupants if necessary, moving or recovering the vehicle, and authorizing its return. Ask who performs each step and whether that person must be on site. These operational questions are especially useful when a proposal claims reduced onboard staffing. They reveal work that remains after the automated driving task ends, without assuming that a driverless trip eliminates maintenance, passenger support, or incident response.
Specify the feature before comparing vehicles
Ask for a statement naming the exact driving feature and software configuration, its automation level, its operating domain, the human role, and its fallback behavior. Then request demonstrations that challenge those commitments, including the interface used to enter and leave automated operation.
For a driver, the immediate question is what attention and response the owner's instructions require. For a program manager, it is whether the complete operating arrangement meets the mission, including interruptions and recovery. A level number starts that discussion; the documented conditions and behavior make it actionable.
Sources
- NHTSA: Automated Vehicle Safety. Government overview of driving roles and representative assistance features; used for functional distinctions, not market-availability claims.
- CCMTA: Canadian Jurisdictional Guidelines, Version 2.0. February 2022 government-administrator guidance reproducing April 2021 SAE terminology, particularly pages 15, 18, and Appendix D.
- NHTSA: Automated Driving Systems 2.0, A Vision for Safety. September 2017 voluntary guidance on operating domains, fallback, and human interfaces; not a deployment authorization.
- Autoware Foundation: Autoware architecture in AWSIM Labs. Developer documentation explaining a modular sensing-to-control implementation.
- Autoware Foundation: Evaluating real-time performance. Developer documentation on processing-time measurement and bottlenecks, with a Linux/Intel example procedure.
- NIST IR 8534: Feature Description for Assessing Autonomous Vehicle Performance. September 2024 research framework for feature descriptions and relevant evaluation scenarios.
- Waymo: The role of Remote Assistance. February 17, 2026 operator explanation distinguishing advice from remote driving.
Last checked: September 7, 2026.
