Why autonomous driving fails on rare scenarios
The long tail of rare scenarios is not an exotic exception but everyday reality: cargo lost up ahead, a detour along the shoulder, lane markings under snow, a cyclist darting out from behind a parked van.
Autonomous driving relies on the statistics of training data, and such situations almost never make it into that data — so the perception and planning pipeline loses stability precisely on them.
Then perception failures begin. Sensor fusion stitches camera frames, the point cloud, and rangefinder readings into a single picture, and if timestamps drift apart or calibration shifts, the object doubles.
Wet asphalt, glare from a low sun, and reflection in a storefront produce an obstacle that is not physically on the road.
Trajectory prediction adds a second layer of error.
The model estimates the intentions of surrounding traffic, and in a rare scenario the spread of hypotheses diverges so widely that the planner either freezes in indecision or chooses a maneuver that stops being safe a second later.
The cost on the road differs, and both extremes are bad. A false positive is hard braking on an empty stretch, into which someone behind crashes who was not expecting it. A missed object is contact.
Reliability here is determined not by the average quality of the model but by behavior in the tail of the distribution.
That is why we start with a scenario registry and metrics for each layer — from reproducible checks of rare scenes to conservative planning logic; we work out how this is covered on the customer's specific route.
Measurable effect of a modular perception architecture
A monolithic pipeline shows only the final result: the system drove better or worse, but which part made that happen is unknown.
A modular architecture removes this question: perception, planning, and control each have their own quality metrics, so a change is visible in a specific number rather than in the general impression from a run.
We measure perception separately — detection recall, tracking robustness under occlusions, and the share of false positives at dusk and on wet roads. Planning — by the share of maneuvers with fallback and by deviation from the target trajectory. Regression is caught in a specific block and is not smeared across the entire pipeline.
The class of failures becomes manageable. Previously, a planning failure looked like a perception error, and the investigation covered the whole system. Now a failure has an address, and therefore a clear list of checks that close it.
This also gives model resilience: updating one block does not require retraining the others and fully rechecking the pipeline. Having lost confidence in an unfamiliar scene, the module enters a conservative mode instead of dragging all the vehicle's behavior along with it.
Incident investigation time is reduced by an end-to-end log: the recording is tagged with module versions, and the cause is found from a fragment rather than by replaying the entire run.
In practice, this is hours of work instead of days, and the fix concerns one block rather than the entire pipeline.
Approaches to building: modular, end-to-end, hybrid
The choice of scheme is determined by the operating route and sensor suite, not by team preferences.
A modular pipeline separates perception, planning, and control into independent blocks: a failure is localized to a specific node, and a block can be replaced without rebuilding the entire system.
An end-to-end trainable model learns directly from video and telemetry — more confident in complex scenes, but it requires a large volume of annotation and explains its decisions poorly.
A hybrid scheme combines trainable perception with formal planning: behavior remains verifiable while recognition quality grows.
Fine-tuning an existing stack for your own sensor suite delivers results faster than the others, but it remains within the bounds of the original architecture.
| Option | When it fits | Limitations |
|---|---|---|
| Modular pipeline | A defined route, incident investigation by node, phased feature rollout | Errors accumulate at block interfaces, new scenes require manual tuning |
| End-to-end trainable model | A diverse environment, with a data stream and annotation | Requires regular retraining, decisions are poorly interpretable |
| Hybrid scheme | Both controllable behavior and accurate recognition are needed | Harder to maintain: two subsystems and rules for reconciling them |
| Fine-tuning an existing stack | A quick start on your own sensor suite | Limited by the boundaries of the base model and its updates |
We start the assessment with three questions: which sensors are already installed, how predictable the route is, and who will investigate incidents after launch. The answers determine which option can withstand your operating conditions.
Development stages: from scenario audit to acceptance
Developing an autonomous driving system is not one long sprint but a sequence of stages, each with a verifiable result.
We build the process so that the state of the perception, planning, and control modules is visible through metrics on annotated scenario sets rather than through presentations.
- Scenario audit. We record the operating conditions, object classes, and maneuvers the system must handle, and what we consciously leave outside the perimeter. The result is a scenario matrix with priorities and a list of limitations.
- Data preparation. We collect sensor recordings, annotate and balance the dataset for rare situations, and separately form validation sets that do not overlap with the training sets.
- Module tuning. We debug perception, planning, and control separately, each with its own metrics: detection recall, share of missed objects, trajectory smoothness. We assemble them into the overall pipeline only after each module passes its threshold.
- Testing. First a virtual run in a simulator across thousands of scenarios, then a closed test site and public roads with a test driver. We investigate every incident down to the cause, not just the symptom.
- Calibration and regression. Any change goes through a full regression on a fixed set: the system must not gain on a new scenario while losing on an old one.
- System acceptance. We deliver according to an agreed protocol: safety metrics, share of driver interventions, recovery time after sensor failure, scenario coverage report, and documentation.
The checkpoint for each stage is a reproducible run that can be repeated on your side. We close disputed points before the start of the next stage, not after delivery.
Autonomous driving delivery: models and regulations
The result of the project is not a demonstration at a test site but a package with which your team continues working without us. Each artifact is versioned in your repository, checked at acceptance, and remains with you along with usage rights.
- Weights of trained perception, planning, and control models in an exportable format, with control quality metrics on a held-out set.
- Configurations and training reproduction scripts — from data preparation to model export, so that a repeated run produces a comparable result.
- Architecture diagrams: the data flow from sensors to control actions, module boundaries, and degradation modes when a signal is lost.
- Testing regulations: scenario sets, pass criteria, order of runs on the bench and at the closed test site, and rules for investigating discrepancies.
- Documentation: interfaces between modules, data formats, annotation requirements, and instructions for deploying the pipeline on your hardware.
- Training for the customer's engineers — sessions on your data and your bench, so that the team can edit datasets, fine-tune models, and read run reports on its own.
- Acceptance protocols, known limitations, and a decision log for disputed scenarios as a basis for subsequent iterations.
Acceptance follows agreed criteria: a scenario is closed when it is reproduced on your bench and confirmed by a protocol. Anything that does not pass remains in progress rather than being moved into 'known limitations'.
Case study: reducing failures in dense traffic
The client came with a working prototype: the vehicle completed an urban route, but in dense traffic the autonomous mode had to be interrupted too often — around 12 driver interventions per 100 km.
More than half of the cases were traffic merges, narrow lanes, and neighboring vehicles changing lanes. Each such run was reset and did not allow accumulating statistics to move the system into operation.
Where reliability was lost
Analysis of the recordings showed that the cause was not in an individual model but at the interface between links.
Perception updated the scene less frequently than the planner required, and object tracks broke during brief occlusions — a bus occluded a passenger car, and it reappeared already at a dangerous proximity.
The planner operated on a single trajectory option without risk assessment, so instead of a smooth detour it chose hard braking.
What we changed and what we achieved
We reworked the perception and planning pipeline: we linked tracks using motion history, added prediction of neighboring vehicles' maneuvers, and switched the planner to comparing several trajectories with risk assessment for each.
The scenarios were run in the CARLA simulator and at a closed test site, then on the same urban route.
Interventions per 100 km dropped from 12 to 3, false braking fell by almost three times, and the share of runs without a single interruption grew from 18% to 64%. The test fleet began completing the route three times faster because it stopped restarting runs.
How does a modular pipeline differ from an end-to-end model?
The difference lies in where the boundaries of responsibility run. In a modular pipeline, perception, prediction of other participants' behavior, trajectory planning, and actuator control are separate blocks with explicit input and output contracts.
An end-to-end model learns from sensors to control commands directly, and the intermediate representations in it are not described by a human but arise as a byproduct of training.
Error traceability is the main divide.
In a pipeline, a failure is localized: from the recording and intermediate artifacts it is clear that an object was lost at the perception stage rather than removed by the planner, and one block can be replaced or tightened with rules without retraining the others.
An end-to-end model has no such attachment: the cause of a failure is sought through statistics on large samples, and the answer 'the network didn't notice' is not an answer.
Data requirements also diverge. Modules can get by with their own datasets: for detection — bounding box annotation, for prediction — tracks, and planning can be refined on simulation and geometry.
An end-to-end model needs long, consistent sequences where state labels and control signals are synchronized; otherwise training drifts into artifacts. Rare but critical scenarios have to be collected separately — otherwise the model simply will not see them in the overall mass.
Maintenance follows from this. A pipeline is released in parts, versions the interfaces between modules, and checks regression by interface metrics — updating one block does not break the others.
An end-to-end model retrains entirely when any part is changed, and the entire route must be checked again.
That is why in practice a hybrid is more often assembled: end-to-end blocks inside a modular frame, where the engineer retains control over the interfaces and the ability to explain every failure.
Common technical questions about deployment and testing
Before work starts, the customer checks not the architecture but the risks: how the system will behave in rain and snow, who is responsible for an incident, whether it can be fine-tuned on their own data, and what to do with an already installed sensor suite.
Below are short answers to each concern; during the task assessment we go through them on your configuration and routes.
How are tests conducted in difficult weather?
We put scenarios with rain, snow, fog, low sun, and dirt on sensors into a separate set of checks and run them regularly, not just once before delivery.
We separately test degradation: if a channel loses data, the system reduces speed and hands control to the operator instead of moving on an incomplete picture of the world. It is precisely such checks that most often reveal weak points that are not visible on dry asphalt.
Who is responsible for an incident?
We fix areas of responsibility in the contract and operating regulations — they are not implied but described.
We are responsible for the components we supply and for the evidence base: continuous event logs, sensor recordings, and the ability to reconstruct the incident step by step.
Without such a trace, investigation is impossible, so recording is carried out from the first day of testing.
Can the system be fine-tuned on our data?
Fine-tuning on customer data is a standard part of the work, not a separate project. We collect recordings from your routes, annotate difficult cases, fine-tune, and check on a held-out set plus a closed scenario set so as not to lose already achieved quality.
Each update cycle goes through regression checks; otherwise a fix for one road breaks behavior on another.
We have a partially installed sensor suite — will everything have to be replaced?
A partially installed suite is a normal starting point. First we describe what is already installed and which parts of the route are covered, then we fill only the gaps: blind zones, missing viewing angles, insufficient overlap.
We check existing sensors for calibration and synchronization — often they are sufficient, and replacement is required only where coverage cannot physically be closed.
What remains outside the scope is timelines for your route and the scope of work for the current hardware. Describe the task: we will come back with an estimate and a plan.Let's discuss the task: what data is needed for assessment
Assessing an autonomous driving task begins not with choosing a model but with inventorying what already exists: without source data, any timeline figure is a guess. Below is the minimum after which we come back with a work plan and a breakdown by stages.
- Operating scenarios — where the platform moves: a closed site, city, highway; which maneuvers are mandatory and which are unacceptable.
- Sensor recordings — raw data from cameras, lidars, and radars with timestamps, synchronization, and calibration between sensors.
- Annotation and its quality — whether there are annotations of objects, lanes, and free space, who made them, and according to which instruction.
- Behavior requirements — rules for right of way, distances, reaction to pedestrians and emergency situations, described in text rather than 'verbally'.
- Platform and constraints — compute module, available memory, permissible response time of the control loop, interfaces to actuators and brakes.
- Acceptance metrics — what the result is accepted by: share of passed scenarios, number of operator interventions, list of unacceptable failures.
- Infrastructure — where we train and reproduce experiments: cluster, storage, versioning of datasets and model weights.
Requirements discussion runs in parallel with collection: we record what is included in the scope and what is left out, and where the boundary of responsibility lies between the perception, planning, and control modules.
If some data is missing, that is not a stop but a separate preparation stage in the plan, with a clear cost in terms of timeline and risk. Send what you have: we will come back with an estimate, the order of work, and a list of what needs to be added before the start.
