Designing Edge-Case Scenario Catalogs for Occluded Intersections

/ General / By

Effective edge-case catalogs for occluded intersections turn vague “what if” concerns into reproducible, auditable test cases for perception, prediction and planning. Below is a practical, engineering-focused process teams can follow to create catalogs that exercise the intersection of occlusion and traffic-rule complexity.

1 — Define scope and objectives

Specify what the catalog must achieve (e.g., validate conservative planner responses under occlusion + stop-sign ambiguity; measure false-negative risk for unseen cross-traffic). Choose the system-under-test (perception stack, prediction, planner, or integrated). Define pass/fail criteria and which metrics matter: collision rate, near-miss counts, time-to-brake, violation of legal constraints, and uncertainty calibration.

2 — Taxonomy: decompose occlusion × rule dimensions

Create orthogonal axes so scenarios are combinable and searchable. Example axes:

  • Occlusion type: static (parked truck, building), dynamic (moving truck, bus), sensor (LiDAR blindspot), partial (curbside parked cars)
  • Visibility conditions: daylight, night, rain, glare, fog
  • Intersection geometry: T-junction, four-way, roundabout, multi-lane)
  • Traffic rule context: stop sign, traffic light (malfunctioning/hidden), yield, right-of-way ambiguity, temporary control (flagger/construction)
  • Actor behaviours: compliant (full stop), rolling stop, aggressive (pulls out), unpredictable (pedestrian darting), out-of-distribution actors (e.g., scooter with trailer)
  • Exposure parameters: approach speed, trigger distance, timing offsets, number of adversaries
  • Sensor state: degraded, miscalibrated, intermittent dropout

3 — Scenario representation and parametrization

Represent each catalog entry as a compact parametric template: geometry id, occluder type & location, actor templates (behavior models + probabilistic parameters), lighting/weather, sensor-mode flags, and acceptance thresholds. Use machine-readable formats (OpenSCENARIO/ASAM or internal JSON) so entries can be instantiated in simulators and replay pipelines.

4 — Sources and discovery methods

Populate the catalog from multiple signals:

  • Field telemetry & human incident reports: extract segments where occlusion + rule intersections correlate with anomalies.
  • Rule-based mining: query logs for patterns (e.g., ego stopped at stop sign while cross-traffic crosses within 2s).
  • Model-driven discovery: flag low-confidence perception/prediction episodes and trace to occlusion contexts.
  • Expert elicitation: safety engineers and human factors specialists suggest plausible-but-rare behaviours.
  • Synthetic generation: procedural parameter sweeps and RL-based adversarial generators to expose worst-case behaviors.

5 — Prioritization and triage

Score scenarios by three core axes and combine into a priority rank: severity (potential for harm), exposure (likelihood in operational design domain), and detectability (how hard it is for the system to identify). Use a simple weighted formula to produce high/medium/low priority buckets and focus validation resources on the top deciles.

6 — Labelling and metadata

Attach standardized metadata to each entry: unique ID, taxonomy tags, parametrization ranges, expected safe behaviour, failure modes, linked telemetry examples, reproducibility notes, and quality level (real / replay / synthetic). Include an explicit assertion of the required conservative behaviour (e.g., “yield until cross-traffic clearance > 3s”).

7 — Test harnesses: replay, simulation, and closed-loop

Ensure each scenario can be exercised in three modes:

  • Replay validation: run recorded sensor & ground-truth traces through perception/prediction modules.
  • High-fidelity simulation: instantiate parametrized scenarios to stress perception and planner with controlled variations (lighting, timing, sensor noise).
  • Closed-loop adversarial testing: run the full stack in-the-loop with behavioral agents that react to the ego’s actions to reveal planning weaknesses.

8 — Metrics, logging, and auditability

Log structured outcomes for each run: metric vector (collisions, TTC distribution, planner cost exceedances, violation flags), confidence/uncertainty traces, and decision rationales (rule constraints hit). Store run artifacts tied to the scenario ID for traceable audits and regression tests.

9 — Validation workflows and acceptance gates

Define acceptance gates per priority bucket (e.g., all high-priority scenarios must pass closed-loop simulation with zero collisions and no rule violations). Use continuous integration to re-run critical scenarios when perception or planner changes. Maintain an approval workflow for adding new high-priority scenarios.

10 — Maintenance: coverage tracking and lifecycle

Track catalog coverage by mapping production miles and failure reports to taxonomy buckets; visualize gaps and trending increases in a dashboard. Periodically prune obsolete scenarios, merge near-duplicates, and promote synthetic seeds to recorded-ground-truth pairings when real data appears.

Checklist (quick)

  • Define SUT, metrics, and acceptance criteria
  • Create occlusion × rule taxonomy
  • Parametrize scenarios in a machine-readable format
  • Source candidate cases from logs, models, experts, and simulation
  • Prioritize by severity, exposure, detectability
  • Attach rich metadata and expected conservative behaviour
  • Run replay, simulation, and closed-loop tests
  • Log auditable results and gate high-priority passes
  • Continuously track coverage and refresh the catalog

Following this process produces a usable, auditable edge-case catalog that specifically targets the risks at occluded intersections and the interaction with traffic rules—turning vague long-tail concerns into concrete validation workstreams.

Sources

Recevez toutes les dernières actualités et informations directement dans votre boîte mail.

r Français