Home›Part 4 How Automated Driving Works›4.1

Part 4 · How Automated Driving Works

4.1 Levels of automation and the ODD

SAE J3016 and the Operational Design Domain

10-minute readPrerequisites: 1.1 What is probability? (multiplication and independence), 0.2 Reading math notation (the braking-distance formula)▶ Video (about 5 min)

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
LevelNameDriving controlsMonitoring and respondingHandling troubleConditions of use (ODD)
0No driving automationPersonPersonPerson—
1Driver assistancePerson and system (the system does longitudinal or lateral)PersonPersonLimited
2Partial driving automationSystem (both longitudinal and lateral)PersonPersonLimited
3Conditional driving automationSystemSystemPerson (takes over when asked)Limited
4High driving automationSystemSystemSystemLimited
5Full driving automationSystemSystemSystemUnlimited

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 conditionExamples
Roads and surroundingsRoad type (motorway, ordinary roads), number of lanes, junctions, curves and slopes, roadworks, a designated area (geofence)
EnvironmentWeather (rain, snow, fog), lighting (day, night, low sun), road surface (dry, wet, icy), GNSS and communications reception
Traffic and own vehicleTraffic 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).

Rain intensity (mm/h) 0 5 10 15 20 0 30 60 90 120 Vehicle speed (km/h) ODD (example) System drives inside Outside the ODD: the driver drives ① In a jam ② Takeover request ③ Driver drives ④ Heavy rain: outside the ODD
An example ODD for a Level 3 system for motorway traffic jams, drawn with two conditions (vehicle speed and rain intensity) (schematic). When the jam clears and speed rises, the system asks for a takeover before crossing the edge. A real ODD is set by a combination of many more conditions: roads, weather, lighting, traffic and so on.

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:

$$\text{ODD} = \{\text{motorway}\} \cap \{\text{traffic jam}\} \cap \{\text{no heavy rain}\}$$

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

$$P(\text{inside ODD}) = P(\text{motorway}) \times P(\text{jam} \mid \text{motorway}) \times P(\text{no heavy rain})$$

= 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:

$$N = n_1 \times n_2 \times \cdots \times n_k$$

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

$$d = v\,t$$

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

$$s = \frac{v^2}{2a} = \frac{16.7^2}{2 \times 2} \approx 70\ \text{m}$$

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).

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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).
StageWhat is decidedRainfall example
RequirementPerformance floor to keepDetection range ≥ 100 m (100 km/h)
Performance curveBad side of performance per rainfall level1% point drops below 100 m at 20 mm/h
Fallback marginDegradation between detection and completed fallbackFallback starts at 12 mm/h; nominal boundary 10 mm/h
DetectionTranslation into measurable quantitiesRain-sensor output ≥ X for 10 s, with hysteresis
Trade-offExposure versus availabilityAbove 10 mm/h for 1.5% of driving time locally
Verification and monitoringTests inside and outside the boundary; field indicatorsWatch 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