Source-linked AI summary
Scenarios for Development, Test and Validation of Automated Vehicles
Till Menzel, Gerrit Bagschik, Markus Maurer
TL;DR
Higher automation makes distance-based validation economically unacceptable, while ISO 26262 scenario use creates conflicting requirements for human-readable and machine-readable representations. The paper analyzes these requirements, proposes functional, logical, and concrete abstraction levels, and shows how scenarios can evolve across the development process. It concludes that the levels support work-product generation across ISO 26262 process steps, while future tools are needed for scenario generation and concretization.
Problem
Distance-based validation is economically unacceptable for higher automation, and scenario use across ISO 26262 process steps creates conflicting representation requirements.
Method
The authors analyze scenario requirements across ISO 26262 process steps and propose three abstraction levels with conversions along the development process.
Results
The paper defines functional, logical, and concrete scenarios and demonstrates their use in generating work products for different ISO 26262 process steps.
Takeaways & Limitations
A structured progression of scenario representations supports traceable scenario generation from concept development through safety verification and validation.
Abstract
from arXiv · showhide
The ISO 26262 standard from 2016 represents the state of the art for a safety-guided development of safety-critical electric/electronic vehicle systems. These vehicle systems include advanced driver assistance systems and vehicle guidance systems. The development process proposed in the ISO 26262 standard is based upon multiple V-models, and defines activities and work products for each process step. In many of these process steps, scenario based approaches can be applied to achieve the defined work products for the development of automated driving functions. To accomplish the work products of different process steps, scenarios have to focus on various aspects like a human understandable notation or a description via time-space variables. This leads to contradictory requirements regarding the level of detail and way of notation for the representation of scenarios. In this paper, the authors present requirements for the representation of scenarios in different process steps defined by the ISO 26262 standard, propose a consistent terminology based on prior publications for the identified levels of abstraction, and demonstrate how scenarios can be systematically evolved along the phases of the development process outlined in the ISO 26262 standard.
I. INTRODUCTION
Higher automation makes conventional distance-based validation economically unacceptable, motivating a traceable scenario-based alternative. The paper addresses inconsistent scenario terminology and representation needs across the ISO 26262 development process.
- Higher automation makes validating safety through many test kilometers economically unacceptable.
- The paper introduces purposeful variation and validation of operating scenarios with documented derivations and assumptions.
- ISO 26262 scenarios can support requirements derivation, component development, and safety verification and validation.
- The paper proposes functional, logical, and concrete scenarios that become more detailed along the V-model-based development process.
- Prior work uses different scenario abstraction levels and notations, while the term scenario lacks a uniform definition.
III. SCENARIO-BASED DESIGN AND TEST PROCESS REFERRING TO THE ISO 26262 STANDARD
The ISO 26262 process identifies where scenarios can generate work products, while requiring scenario use throughout development and validation.
- ISO 26262 provides a functional-safety framework for vehicle guidance systems, with scenario-relevant process steps identified in its development overview.
- The authors note that complete requirements for higher automation levels are impossible to generate, according to their opinion.
- Scenarios may support the lifecycle from concept through technical product development, system verification, and validation.
A. Scenarios in the concept phase
In the concept phase, scenarios describe the item and operational context in human-usable forms, supporting hazard analysis and risk assessment.
- The concept phase defines the item, performs hazard analysis and risk assessment, and develops a functional safety concept.
- Operating scenarios are derived from the functional concept, system boundaries, environment, legal requirements, and item dependencies.
- Hazardous scenarios combine operational scenarios with malfunctioning behavior and are rated using exposure, severity, and controllability.
- Hazardous-scenario analysis is expert-led, requiring natural-language descriptions and a unified, semi-formal vocabulary.
- Concept-phase scenarios must be formulable by human experts and represented semi-formally.
B. Scenarios in the system development phase
During system development, hazardous scenarios are converted from linguistic descriptions into state-value representations that support quantifiable and verifiable technical requirements.
- Hazardous scenarios are converted from linguistic and semi-formal descriptions into state values for system-level technical development.
- State-value lists precisely describe scenarios but are difficult for human experts to process because of their detail.
- Value ranges can summarize state values and later distinguish valid and invalid ranges for safe values and system boundaries.
- Detailed scenario representations make item requirements verifiable, supporting safety validation in ISO 26262 process step 4-9.
- System-development scenarios must include state-value parameter ranges and provide formal notation enabling automated processing.
C. Scenarios for verification and validation
Verification and validation require scenarios to become reproducible, consistent, machine-readable test inputs while retaining traceability to earlier development artifacts. Test cases derive concrete values and time sequences from scenario parameter spaces and technical safety requirements.
- Test activities must be systematically planned, specified, executed, evaluated, and documented to verify requirements from previous development steps.
- Test cases specify identification, verification references, preconditions, environmental conditions, time-sequenced inputs, and expected behavior with acceptable variations.
- Consistent input data can be derived from abstract, language-based scenarios in the item definition for test-case specification.
- Technical safety requirements define parameter ranges that must be covered during verification, linking detailed scenario specification to test generation.
- Concrete test inputs are selected from continuous scenario ranges using equivalence classes, boundary values, and combinatorial methods, although meaningful coverage remains unresolved.
- Testing scenarios require concrete state values, consistency, and efficient machine-readable representation for reproducible and automated execution.
D. Analysis of the derived requirements on scenarios
Derived scenario requirements conflict in both notation and detail. Human-readable linguistic descriptions support abstraction and discussion, whereas machine-readable concrete representations support processing and reproducible testing.
- Scenario requirements conflict because abstract linguistic descriptions are difficult for machines, while efficient machine-readable formats are difficult for humans to read.
- Parameter ranges provide degrees of freedom for selecting test values, whereas concrete parameter values are required for reproducible test cases.
IV. TERMINOLOGY FOR SCENARIOS ALONG THE DESIGN AND TEST PROCESS
The paper resolves conflicting scenario requirements by defining three abstraction levels that can be converted along the V-model-based development process.
- The proposed levels are functional, logical, and concrete scenarios, progressing from abstract concepts toward detailed test representations.
A. Functional scenarios
Functional scenarios are the most abstract, human-readable representation, describing domain entities and their relations with a consistent, use-case-specific vocabulary. Their detail varies with the development phase and item under development.
- Functional scenarios support item definition and hazard analysis and risk assessment by enabling human experts to understand, discuss, and create scenarios.
- They describe operating scenarios semantically through consistent linguistic descriptions of entities and their relations.
- The vocabulary is domain-specific and may vary in detail according to the use case and development phase.
- A highway-pilot vocabulary can cover road geometry, topology, traffic interactions, and weather, while a parking-garage pilot emphasizes building layout.
- The example functional scenario depicts a car following a truck in the right lane of a two-lane motorway curve.
- Scenarios can be varied by selecting different terms from the defined vocabulary.
B. Logical scenarios
Logical scenarios represent operating scenarios in state space using parameter ranges, formal notation, and relations among entities. They support technical-requirement derivation and systematic generation of concrete test scenarios.
- Logical scenarios describe entities and their relations using parameter ranges in the state space.
- Formal notation can specify parameter distributions, correlations, and numeric conditions among scenario variables.
- Logical scenario parameters provide the basis for deriving technical requirements and generating concrete scenarios for testing.
- A motorway-following example maps linguistic terms to state-space parameters such as lane width, curve radius, and vehicle positions.
- The relation “follows” is represented by requiring the truck’s longitudinal position to exceed the car’s position.
C. Concrete scenarios
Concrete scenarios instantiate logical scenarios by assigning specific state-space values while preserving their defined conditions. They can support reproducible test-case generation when augmented with expected behavior and test infrastructure.
- Concrete scenarios represent entities and their relations using distinct concrete parameter values in the state space.
- Any number of concrete scenarios can be derived from a logical scenario with continuous value ranges.
- The example concrete scenario selects one value within every defined range while satisfying the specified parameter condition.
- Concrete scenarios become test cases by adding the test object’s expected behavior and the test infrastructure to be used.
V. CONCLUSION AND OUTLOOK
The paper analyzes scenario-based development within ISO 26262, identifies representation requirements and their contradictions, and proposes three abstraction levels for connecting development work products. It concludes that additional methods and tools are needed to generate and transform scenarios across the process.
- The authors analyze where scenarios can generate ISO 26262 work products in the development of vehicle guidance systems.
- The paper defines scenario-representation requirements and identifies contradictions arising from different development-process steps.
- Three scenario abstraction levels are proposed, with definitions and transformations supporting work products across ISO 26262 process steps.
- Future work requires methods and tools to generate functional scenarios and convert them into concrete scenarios along the ISO 26262 process.