4.1 Levels of automation and the ODD
SAE J3016 and the Operational Design Domain
What you will learn
- Explain the differences between Levels 0–5 of driving automation in terms of who — the person or the system — handles the driving controls, monitoring the surroundings, and what to do when things go wrong
- Explain what an ODD (Operational Design Domain) specifies, and what happens when leaving it (takeover requests and the minimal risk condition)
- Use simple calculations to relate the size of the ODD to usable time and the number of conditions to check, and to estimate the distance needed for a takeover
Build intuition
“Self-driving cars” covers a wide range, from features that help with steering on the motorway to driverless taxis with nobody in the driver’s seat. To tell them apart, the classification in SAE J3016, compiled by the engineering association SAE International, is widely used; systems and explanations in Japan use the same Levels 0–5.
The levels are divided not by how capable a system is but by division of roles. The real-time work of driving (the dynamic driving task, DDT) is split as follows, and the levels differ in whether a person or the system handles each part:
- Driving controls: accelerating and braking (longitudinal) and steering (lateral)
- Monitoring and responding: noticing surrounding vehicles, pedestrians, traffic lights and so on, and responding to them
- Handling trouble (fallback): responding when the system has a fault or is about to leave the conditions it can work in
| Level | Name | Driving controls | Monitoring and responding | Handling trouble | Conditions of use (ODD) |
|---|---|---|---|---|---|
| 0 | No driving automation | Person | Person | Person | — |
| 1 | Driver assistance | Person and system (the system does longitudinal or lateral) | Person | Person | Limited |
| 2 | Partial driving automation | System (both longitudinal and lateral) | Person | Person | Limited |
| 3 | Conditional driving automation | System | System | Person (takes over when asked) | Limited |
| 4 | High driving automation | System | System | System | Limited |
| 5 | Full driving automation | System | System | System | Unlimited |
The biggest divide is between Level 2 and Level 3. Up to Level 2, even when the system operates both acceleration and steering, the person is driving. Even with features that allow hands off the wheel (hands-off), the person must keep watching the road and be ready to respond at any moment. From Level 3, while the system is engaged it is the system that drives, and the person no longer has to keep watching the road. At Level 3, however, the person must stay ready to take over promptly when the system issues a takeover request. At Level 4, even if nobody responds, the system itself brings the vehicle into a safe state (such as stopping on the shoulder). This state is called the minimal risk condition (MRC).
Note that warnings, and features such as autonomous emergency braking (AEB) that act only briefly in an emergency, do not handle driving on a sustained basis, so they are not counted as driving automation.
Except at Level 5, the conditions in which a system can be used are limited. That range of conditions is the ODD (Operational Design Domain): a commitment that “this system was designed to work within these conditions”. An ODD is mainly specified as a combination of conditions like these:
| Kind of condition | Examples |
|---|---|
| Roads and surroundings | Road type (motorway, ordinary roads), number of lanes, junctions, curves and slopes, roadworks, a designated area (geofence) |
| Environment | Weather (rain, snow, fog), lighting (day, night, low sun), road surface (dry, wet, icy), GNSS and communications reception |
| Traffic and own vehicle | Traffic volume, speed of surrounding vehicles, presence of pedestrians and cyclists, own vehicle speed |
For a “Level 3 system for motorway traffic jams”, for example, the ODD might be “motorway, speed 60 km/h or less, no heavy rain”; for a “Level 4 mobility service in a limited area”, it might be “a fixed route, maximum 20 km/h, daytime, suspended on snowy days” (both illustrative examples).
If, while engaged, the vehicle is about to leave the ODD, the system notices early and issues a takeover request (② in the figure). Some edges, like a motorway exit, are known in advance from the map; others, like sudden heavy rain (④ in the figure), can only be noticed on the spot. If the person does not take over, the system brings the vehicle into the minimal risk condition, for example by slowing down and stopping.
A higher level does not mean safer. The levels classify the division of roles; whether a system is safe must be shown separately (Part 5). A Level 4 vehicle driving slowly in a limited area and a Level 2 car on the motorway are not ranked above one another. When comparing performance or safety, always make sure you are talking about the same ODD.
Check with math
① The ODD is an “and” of conditions
The ODD is where the ranges satisfying each condition overlap. Using \(\cap\) (the overlap) from the IoU of 3.4, the example in the figure is:
Let’s estimate the share of driving time spent inside the ODD. Suppose 30% of driving time is on motorways, 20% of motorway time is in traffic jams, and 90% of the time there is no heavy rain, and assume the weather is unrelated to (independent of) roads and jams. The multiplication of 1.1 and 1.2 gives
= 0.3 × 0.2 × 0.9 = 0.054, about 5% of driving time. Widening the ODD to “any motorway driving, jam or not” gives 0.3 × 0.9 = 0.27 — five times the usable time. In exchange, the situations that must be checked grow a great deal: merging and changing lanes at speed, stopping from high speed, and so on.
In reality, conditions are not always independent — jams are more likely on rainy days, for instance (the common causes of 1.1). When estimating shares, check them against real data for each combination of conditions.
② Combinations of conditions multiply
When testing within the ODD, dividing each condition into categories and counting the combinations gives the product of the numbers of categories:
3 road types × 4 kinds of weather × 3 lighting conditions × 3 traffic levels gives 3 × 4 × 3 × 3 = 108 combinations. Adding road surface (3 kinds) makes 324: each added condition multiplies the count. Many conditions, such as speed and rain intensity, also vary continuously, so not everything can be checked by test driving. It becomes important not to make the ODD wider than needed, and to be smart about simulation and about choosing the important situations. → 5.6 Scenario-based testing, 5.7 Simulation and XiL
③ The distance needed for a takeover
After a takeover request, it takes time for a person to get back to driving. A person who was doing something else is known to need several seconds or more to grasp the situation. With a margin of t seconds, the vehicle travels
in the meantime. At 60 km/h (about 16.7 m/s) with a 10-second margin, d ≈ 167 m; at 100 km/h (about 27.8 m/s), about 278 m. The system must notice the edge of the ODD and issue the request at least this far ahead (② in the figure).
If the person does not take over and the system stops with a deceleration of \(a = 2\ \mathrm{m/s^2}\) (gentle braking), the braking-distance formula of 0.2 gives
and stopping takes \(v / a \approx 8.3\) seconds. Adding the takeover margin and the stopping distance, at 60 km/h the request should go out about 240 m (167 + 70) before the edge of the ODD. The actual length of the margin and the way of stopping are set by international regulations (such as UN R157) and by each manufacturer’s design.
Advanced: how to set the boundary of the ODD
The question is not “is rain inside the ODD?” but “up to what rainfall?”. The answer is not simply the point where performance drops; it is worked out backwards in the order requirement, performance curve, margin for the fallback, detection, exposure. Let us follow rainfall as the example (illustrative numbers).
- Derive the performance floor from the requirement: with an ODD speed limit of 100 km/h, a processing and reaction delay of 1.0 s and a deceleration of 6 m/s², stopping takes about 28 + 64 ≈ 92 m (4.2). Being able to detect objects about 100 m ahead, in any rain, is the floor that must be kept.
- Measure performance as a function of rainfall: step the rainfall through several levels (0, 5, 10, 20, 30, 50 mm/h) and measure detection range and other quantities. Draw the curve not for the average but for the bad side of the distribution (for example the 1% point, 1.9). Measure combined conditions too — rain at night, rain with oncoming headlights — in their worst combinations.
- Separate the performance boundary from the operational boundary: the point where the curve meets the requirement (say 20 mm/h, where the 1% point of detection range drops below 100 m) is the performance boundary. The ODD boundary is set before it, because from the moment intensifying rain is detected until the handover (10–15 s) or the transition to a minimal risk condition (30 s or more) is complete, performance must still meet the requirement. A shower can intensify by more than 10 mm/h within a minute.
- Define it in quantities the vehicle can measure: mm/h is a meteorological quantity that the vehicle cannot measure directly. Write the boundary in quantities that can be judged while driving (rain-sensor output, wiper speed, attenuation of LiDAR returns and so on), and calibrate them against mm/h by measuring both in the same situations. To stop the judgement flickering, use separate entry and exit thresholds (hysteresis) and a confirmation time. Include the error of the proxy in the margin.
- Trade off exposure against availability: a stricter boundary is safer but leaves the function unavailable more often. From weather data for the target region, find the share of driving time above 10 mm/h (the exposure of 1.4), and compare the gain in availability and the rise in residual risk from widening the boundary in the same table.
- Verify the boundary and keep watching: show that the requirement is met with scenario tests aimed at conditions right at the boundary (5.6), and test slightly beyond it to confirm that performance degrades gracefully rather than collapsing, so that the fallback completes in time. In the field, make the frequency of handovers near the boundary and the time spent operating beyond it safety performance indicators (5.11).
| Stage | What is decided | Rainfall example |
|---|---|---|
| Requirement | Performance floor to keep | Detection range ≥ 100 m (100 km/h) |
| Performance curve | Bad side of performance per rainfall level | 1% point drops below 100 m at 20 mm/h |
| Fallback margin | Degradation between detection and completed fallback | Fallback starts at 12 mm/h; nominal boundary 10 mm/h |
| Detection | Translation into measurable quantities | Rain-sensor output ≥ X for 10 s, with hysteresis |
| Trade-off | Exposure versus availability | Above 10 mm/h for 1.5% of driving time locally |
| Verification and monitoring | Tests inside and outside the boundary; field indicators | Watch the handover frequency near the boundary |
The frameworks for describing an ODD (ISO 34503, PAS 1883) also call for ODD attributes to be measurable and verifiable (a summary of the idea). The grounds for the boundary are kept in the safety case (5.10) in the form of this table.
Connection to SOTIF and safety
- The ODD sets the scope of the safety argument: a claim that a system “is safe” is a claim about the inside of its ODD. Test driving and validation are planned to match the ODD’s conditions, and the kilometres driven are counted separately for each ODD. → 1.8, 5.6 Scenario-based testing
- Hazards remain inside the ODD: even within the ODD there are situations that expose the limits of the function (triggering conditions), such as low sun, reflections from the road and unfamiliar objects. Setting the ODD is the starting point of safety, not the finish line. → 5.3 Functional insufficiencies and triggering conditions
- Noticing that the vehicle has left the ODD: rain intensity and lane visibility are estimated by sensors, and those estimates have errors. Outside the range of the training data, an AI’s confidence may not be reliable either. Carrying on outside the ODD without noticing is the most dangerous case. → 2.8, 3.7
- Misunderstanding the person’s role: believing a Level 2 driver-assistance feature is “self-driving” and no longer watching the road, or being unable to respond to a takeover request at Level 3, are uses that differ from the designer’s intent yet are easy to foresee. Such reasonably foreseeable misuse is also handled in SOTIF, and is countered with driver monitoring and clear displays. → 5.1 What is SOTIF?
- Designing the takeover is part of safety: how warnings are given, how long the margin is and how the vehicle stops when nobody takes over are all design decisions that can lead to harm. They are considered both for faults (functional safety) and for cases with no fault where the function cannot cope (SOTIF). → 4.7 Three pillars of safety
Summary
- The levels of driving automation (0–5) classify the division of roles, not performance. Up to Level 2 the person is the driver; from Level 3 the system is the driver while engaged. When trouble arises, at Level 3 the person takes over, and from Level 4 the system brings the vehicle into the minimal risk condition
- The ODD is the range of conditions a system “was designed to work within”, set as a combination of road, environment and traffic conditions. Every level except Level 5 has a limited ODD
- Widening the ODD increases usable time, but the combinations of conditions to check multiply. When leaving the ODD, request a takeover early, allowing for the distance travelled during the margin (d = vt) and the stopping distance
Quick quiz
Q1. A motorway feature lets the driver take their hands off the wheel, but uses a camera to check that the driver is watching the road. What level is it?
Level 2. Hands can be off, but monitoring and responding are assumed to be the person’s job, so the person is driving.
Q2. What is the main difference between Level 3 and Level 4?
How trouble is handled (about to leave the ODD, or a system fault). Level 3 assumes the person responds to a takeover request and takes over the driving; at Level 4, even if the person does not respond, the system brings the vehicle into the minimal risk condition.
Q3. Driving at 80 km/h, the vehicle is approaching the edge of its ODD. Allowing a 10-second takeover margin, how many metres before the edge must the takeover request be issued?
80 km/h is about 22.2 m/s, so 22.2 × 10 ≈ 222 m. In practice, time to notice and distance to stop are added, and the request goes out even earlier.
Q4. “A Level 4 bus that can only run in a limited area is less advanced than a Level 2 car that can be used anywhere.” What is wrong with this view?
The levels classify the division of roles; they do not compare the size of the ODD, performance or safety. Within its ODD, Level 4 needs neither a person monitoring nor a takeover, whereas at Level 2 the person is the driver everywhere. Comparisons should line up performance and safety evidence for the same ODD.
Further reading
- Next lesson: 4.2 System overview
- Related: 0.2 Reading math notation (braking distance), 1.1 What is probability? (independence and common causes), 1.2 Conditional probability and Bayes’ theorem (the ODD changes what results mean), 1.8 Statistics of rare events (what the kilometres consist of), 2.8 Data splits and distribution shift
- Glossary: Levels of driving automation, Operational Design Domain (ODD), ODD boundary, Dynamic driving task (DDT), Takeover request / DDT fallback, Minimal risk condition
- Video lecture: YouTube (about 5 minutes) (the key points explained with slides and narration; the Japanese article has a Japanese video)
- References (this lesson summarizes the standards in its own words; check the originals for exact definitions)
- SAE International, “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,” SAE J3016, 2021.
- ISO 34503:2023, “Road Vehicles — Test scenarios for automated driving systems — Specification for operational design domain.”
- BSI, “Operational Design Domain (ODD) taxonomy for an automated driving system (ADS) — Specification,” PAS 1883, 2020.
- UNECE, “UN Regulation No. 157 — Automated Lane Keeping Systems (ALKS),” 2021.