Description of Corner Cases in Automated Driving: Goals and Challenges

In plain words

Self-driving cars have to handle rare and risky situations, which the field calls corner cases. Examples from the paper are glare that blinds the camera, an unknown object on the road, and a pedestrian who briefly disappears behind something. Machine-learning models learn from data, and these situations are rare in datasets.

The paper argues that the field needs a way to describe corner cases in a form a computer can read. With such a description, existing datasets could be checked for how many corner cases they contain, new ones could be recorded or simulated on purpose, and the car's software could use them while driving. The paper is an early overview. It lists open research questions and shows three example descriptions, but it does not present a finished method. It also proposes linking the new description to existing scenario description standards.

TL;DR

• Corner cases (CC) are rare or critical situations that automated-driving ML models need in their training and validation data, and they are scarce in datasets §1.
• The paper proposes a machine-interpretable corner-case description (CCD) that sits on top of existing scenario description languages §2.1, §3 RQ1.
• It is a position paper: six research questions §3 and three conceptual examples §4. It reports no experiments, no algorithm and no code.
• Use it to frame the problem and the open questions, not as an implementable method.

Problem

Corner cases are data that occur infrequently or represent a critical situation, and they are available in datasets only to a limited extent, if at all §1. ML models in automated driving can fail on them, and such failures can appear at several levels of the system, for example as missed detections or wrong behaviour predictions §1.

Existing scenario description languages cover the basic entities of a scene, but the paper states that they are currently limited in describing CC §2. Scenario languages are also used for automated testing and verification without information about the CC coverage of those scenarios §3 RQ6. The paper names "little research on machine-interpretable descriptions" of CC as the gap [abstract].

The paper also points out that describing CC inside an operational design domain (ODD) is hard, because many CC are by definition outside the ODD description. It says that temporal-context CC are out of range for a morphological-box ODD description §2.1.4.

Method

The paper proposes a direction, not an algorithm. The parts it sets out are:

1. Two-layer structure. Combine a high-level CC categorisation with a concrete scenario description. The categorisation follows Heidecker et al., who split CC into a sensor layer, a content layer and a temporal layer, and into method-layer CC §1, §2.2. Scenario elements come from existing languages §3 RQ1. The paper calls the combination a CCD and says it should cover "the details" of the CC after the category is given §3 RQ1.
2. Scene and scenario terms. A scene is a snapshot. A scenario is a sequence of successive scenes. This follows Ulbrich et al. §1 fn. 1.
3. Scenario languages used as building blocks. The paper reviews the PEGASUS six-layer model §2.1.1, ASAM OpenSCENARIO for multi-actor scenarios §2.1.2, ASAM OpenDRIVE and OpenCRG for road and surface data §2.1.2, ontologies §2.1.3 and ODD morphological boxes §2.1.4.
4. Machine-readable form. The CCD should be machine-readable so that algorithmic outputs can be turned into CCD automatically for each frame §3 RQ2. The paper does not define a schema, a file format or the automatic process itself.
5. Metric-based severity. The conclusion envisions a machine-interpretable CCD built from three parts: a high-level knowledge-based description, a low-level scenario-based description, and metric-based severity scores for CC §5. No metric or severity formula is given.
6. Intended uses. Offline: dataset analysis and coverage §3 RQ4, generating or recording CC from descriptions, including scenario catalogues, data augmentation and simulators such as CARLA §3 RQ3. Online: sensor fusion that weights sensors by how well they handle a CC, and an actionable interface for prediction and planning §3 RQ5. Validation: test cases that a model must pass §3 RQ6.

The use-case examples are conceptual sketches focused on vulnerable road users (VRU) §4. Each example is a list of field values written in prose. A form of that record is shown below. It restates the paper's example and is not an algorithm.

# Conceptual CCD record for the glare example  [§4.1] [fig. 2]
# Field values as the paper writes them; the paper gives no schema  [§4]

def describe_glare_frame():
    # CC level and type; the level names are the paper's own  [§4.1]
    description = {
        "cc_level": "physical level",
        "cc_type": "global outlier",
    }
    # Scene context  [§4.1]
    description["scene"] = {
        "season": "winter",
        "sun": "low, over the road",
        "visibility": "poor",
    }
    # Other vehicle: on the other lane, coming towards the observer  [§4.1]
    description["vehicle_1"] = {
        "lane": "other lane",
        "direction": "towards the observer",
    }
    # Pedestrian: ahead on the road, moving from left to right  [§4.1]
    description["vru_1"] = {
        "type": "pedestrian",
        "location": "ahead on the road",
        "motion": "from left to right",
    }
    return description

Hyperparameters

Not applicable. The paper reports no experiments, training runs or implementation details §1 §4 §5.

Results

Not applicable. The paper reports no quantitative results. Its three use cases §4.1–§4.3 are conceptual descriptions of example images fig. 2 fig. 3, not evaluations.

The paper leaves the combination in Method point 5 for future research §5.

Paper vs code

No official code.

Searched: the paper's text, the references and the arXiv source for code or project links. The source contains only standards, project and dataset URLs in the bibliography, plus a commented-out workshop link [content.tex line 7]. GitHub repository search for "corner case automated driving description" and "corner cases automated driving" returned no results.

Pitfalls

• No method to implement. The paper defines no CCD schema, no serialisation format, no labelling procedure and no severity metric. An implementer must design these from scratch; the card can only point to the examples §3, §4.
• Level names do not line up. Section 1 names a sensor layer, a content layer, a temporal layer and a method layer §1. The examples use CC-level values "physical level" §4.1, "object level" §4.2 and "scenario level" §4.3. The paper does not map one set onto the other, so an implementer should not assume a fixed level vocabulary.
• Zwicky boxes play two roles. Research question RQ2 calls them "efficient scenario description languages" §3 RQ2. Section 2.1.4 describes them as morphological boxes that describe an ODD §2.1.4. The paper does not resolve which role it means.
• Frame-level and scenario-level mixed. The scene is defined as a snapshot and the scenario as successive scenes §1 fn. 1. The occlusion example uses a scenario-level CC with a per-frame visibility flag §4.3. The paper gives no rule for how a per-frame flag relates to the scenario-level label.
• Occluded entities. In the middle frame of the occlusion sequence, the pedestrian is not visible but is kept as an entity with visible set to false §4.3 fig. 3. The paper does not say how an occluded entity is to be represented in general, or when the flag changes.
• Severity is only named. Metric-based CC assessments are cited as existing work, and the paper notes that such metrics "without a context" do not improve understanding §2.2. The combination with CCD is proposed as future work §5. No metric is defined here.
• Figures credit others. The captions of fig. 2 and fig. 3 credit other works: Heidecker et al. and the work cited as chan2021segmentmeifyoucan for fig. 2, and the work cited as Cordts2016 for fig. 3. Those images are not reproduced in this wiki, and the card describes them in words only.
• Version. The raw metadata lists arXiv v4, updated 2025-11-24. This card reads the LaTeX source that wikillm fetch downloaded for this paper. Later versions may differ.

Lineage

• Builds on: Heidecker et al. for the corner-case layers and levels §1, §2.2; the PEGASUS layer model §2.1.1; ASAM OpenSCENARIO, OpenDRIVE and OpenCRG §2.1.2. Heidecker et al. have no card in this wiki.
• Compared against: none. The paper compares existing description languages on their ability to describe CC §5.
• Superseded by: not stated.