Section 48.8: Route, behavior, and scenario-based planning

Driving is a stack of commitments at different time scales: which roads to take over minutes, which gap to take over seconds, and which steering angle to take right now.

On layered planning and the HD map

Route, Behavior, And Local Planning

Ask a self-driving car to choose steering angles once per minute and it will wander into oncoming traffic between decisions; ask it to re-plan the whole cross-town route sixty times a second and the road graph chokes before the wheel ever turns. A working driving stack escapes this bind by splitting the problem across four clocks that each run at their own speed, as Figure 48.8A illustrates with an occluded-pedestrian scene where route, behavior, prediction, trajectory, control, and fallback evidence all attach to one road situation. Route planning chooses a coarse path through a road graph. Behavior planning chooses maneuvers such as follow, yield, merge, stop, nudge, overtake, or pull over. Local planning turns that decision into a dynamically feasible trajectory with speed, curvature, comfort, and collision constraints. The layers operate at very different rates: route planning re-evaluates roughly once per minute, behavior planning replans every 100 to 500 ms, and local trajectory optimization runs at 10 to 20 Hz. Collapsing all three into a single loop at the local rate would typically demand roughly 10 times more compute and improve route quality not at all, since a road-graph search does not need to be re-solved 10 to 20 times a second to stay correct. Running route planning at the local rate would similarly flood the road graph with queries it cannot serve in time.

A term worth pinning down before it recurs below: a scenario in this section always means a structured, replayable test case (a road layout, actor scripts, and pass/fail criteria), not a live driving situation on the road. The rest of this section builds toward exactly that machinery: after covering how the four layers cooperate and how the map anchors them, later subsections show how to turn one driving situation into a functional, logical, and concrete scenario suite that produces auditable safety evidence.

HD Maps And Localization

The shared state that lets these layers cooperate has to be anchored to something the whole stack agrees on, and for driving that anchor is the map.

Route and behavior planning both stand on a high-definition map. Unlike a navigation map, an HD map encodes lane geometry, traffic signs, crosswalks, and stop lines to roughly 10 cm precision, organized as layers: lane centerlines and boundaries, regulatory elements (signs, signals, speed limits), and topology (which lane connects to which). The vehicle locates itself in this map by scan matching, aligning live LiDAR or camera features against the stored map, which yields a lane-relative pose far more precise than raw GNSS. Crowdsourced map updates, where the fleet reports discrepancies, keep the map fresh.

The most basic map query a planner makes is "which lane am I in, and where is its center?" The example below performs a nearest-centerline lookup: given the ego position, it returns the closest lane-centerline point, the seed of lane-relative localization and of the Frenet reference path from Section 48.4.

import numpy as np

# A tiny HD-map fragment: two lane centerlines as polylines of (x, y) points.
lanes = {
    "lane_L": np.array([[0, 1.8], [10, 1.8], [20, 1.9], [30, 2.2]], dtype=float),
    "lane_R": np.array([[0, -1.8], [10, -1.8], [20, -1.7], [30, -1.4]], dtype=float),
}

def nearest_centerline(ego_xy, lanes):
    """Return (lane_id, nearest centerline point, lateral distance) for the ego."""
    best = (None, None, np.inf)
    p = np.asarray(ego_xy, dtype=float)
    for lane_id, pts in lanes.items():
        d2 = np.sum((pts - p) ** 2, axis=1)   # squared distance to each map point
        i = int(np.argmin(d2))
        dist = float(np.sqrt(d2[i]))
        if dist < best[2]:
            best = (lane_id, pts[i], dist)
    return best

ego = (12.0, -1.2)                            # ego pose near the right lane
lane_id, cpt, lateral = nearest_centerline(ego, lanes)
print(f"ego in {lane_id}: nearest center {tuple(cpt)}, lateral offset {lateral:.2f} m")

Expected output: the ego at (12.0, -1.2) is assigned to lane_R with a nearest centerline vertex at (10.0, -1.8) and a distance of about 2.09 m (dominated by the 10 m vertex spacing of this coarse polyline; a real HD map is sampled far more densely). The lane assignment is the lane-relative localization a behavior planner needs before it can reason about gaps and maneuvers, and in a real stack the snap is refined by scan matching against the full HD map layers.

Scenario-Based Validation

Scenario testing is the bridge from impressive driving clips to engineering evidence. A scenario names the road layout, actors, initial states, behavior scripts, weather, sensor configuration, success criteria, and termination rules. OpenSCENARIO, ScenarioRunner, CommonRoad, and CARLA-style tooling make those assumptions explicit, forming the same scenario testing and safety case framework covered in Section 48.6.

A useful scenario program separates functional scenarios, logical scenarios, and concrete scenarios, a decomposition called the scenario abstraction hierarchy. The functional scenario says "occluded pedestrian after parked van." The logical scenario defines parameter ranges for speed, distance, visibility, and pedestrian timing. The concrete scenario fixes one reproducible test instance with exact values.

This hierarchy matters in embodied AI because a physical robot cannot brute-force every parameter combination in real space. A car that fails only above 1.8 m/s pedestrian emergence in a gap narrower than 4 m stays hidden until you know which parameters to vary. Pick arbitrary concrete instances instead and you miss whole failure regions, leaving the vehicle safe on the test track but dangerous at the deployment boundary. Passing every scenario in your suite proves only that the planner drives the roads you already imagined.

The mechanism works by treating parameters as intervals rather than points. A logical scenario stores a tuple of ranges, for example pedestrian speed in [0.8, 2.4] m/s and occlusion depth in [2, 8] m. Coverage tools such as PEGASUS or CommonRoad sample or grid these ranges, run each concrete instance through a closed-loop simulator, and record pass or fail. A grid of just five values per parameter across four parameters already produces 625 concrete scenarios from a single logical one. Without the hierarchy, a test engineer writing fixed concrete cases would have to author each of those 625 variants by hand to reach the same coverage. The resulting coverage map shows which parameter region the planner handles and where its safety margin collapses. It turns an unbounded physical test space into a finite, auditable evidence set.

Safety Case Thinking

Reproducible coverage across the parameter grid produces evidence, but evidence only earns deployment when it is assembled into an argument that a regulator or safety engineer can audit, which is the job of the safety case.

A safety case connects hazards, mitigations, tests, and residual risk. For driving, this means the evidence should be organized by operational design domain: road type, weather, speed range, traffic density, lighting, map quality, sensor availability, and fallback behavior.

SOTIF (Safety of the Intended Functionality)-style reasoning asks whether the intended function can be unsafe even without a component failure. That question is central for learned perception and planning: the camera may work, the model may run, and the vehicle may still choose an unsafe maneuver because the scenario sits outside the validated operational design domain.

Expected output: the scenario name should identify a recognizable hazard pattern and the metric count should confirm that the planner will be judged on more than route completion alone. If your scenario card cannot name its fallback behavior or its ODD, it is not strong enough to support a safety claim.