Requirement
Clear, attainable, and regulation-compliant requirements are essential to describe the ADF’s behaviour in dynamic and complex environments. Requirements for ADF should comprise both functional and non-functional requirements. Functional requirements include descriptions of the ADF and identifying what the ADF should do for e.g. performing DDT, specifying the limitations based on ODD etc., while the core technical requirements address the basis for operational approval. To ensure a robust and traceable development process, it is imperative that all requirements—both functional and non-functional—are identified and clearly defined early in the design phase. The use of Model-Based Systems Engineering (MBSE) supports this effort by helping to detect ambiguities, reduce development risks, and maintain consistency throughout the system lifecycle. Requirements category aims to present a starting point for specifying the minimum level of ADF operational requirements that define ODD conditions and introduce relevant ODD attributes and conditions for creating a basic ODD specification.
According to ISO/DIS 34503:2022, a critical aspect of safely deploying automated vehicle technologies is clearly defining their capabilities and limitations—and effectively communicating these to users to achieve a state of informed safety. The standard introduces a structured taxonomy and hierarchical format to support manufacturers in specifying the operating boundaries of ADF. In addition to the ODD, the standard introduces the concept of the Operational Domain (OD), which describes the real-world conditions an ADF may encounter. The Target Operational Domain (TOD) refers to the specific environment where the ADF is expected to operate. Depending on system design and requirements, the TOD may be a subset or superset of the defined ODD. The subtopic of ODD addresses the guidelines for defining the ODD for automated driving functions while also introducing the relevant physical and digital infrastructure attributes to be considered while defining the OD for ADF.
According to SAE J3016:2021, DDT is defined to cover all real-time operational and tactical functions required to operate a vehicle in on-road traffic, excluding the strategic functions such as trip scheduling and selection of destinations and waypoints. Once the ODD is defined, the system’s DDT capabilities and fallback strategies must be specified, including how the system perceives its environment and responds to ODD exits or failures. This is essential to safely return the control back to the driver or to engage a minimal risk manoeuvre (MRM). Regulatory standards, such as UNECE - ALKS, 2020 also specify technical expectations, including the system’s ability to safely hand over control to the driver and to perform a minimum risk maneuver if the driver fails to respond. DDT & Fallback Strategies topic aims to describe the guidelines for the functional requirements on the control behaviour of ADF while being active.
Non-functional requirements specify how the ADF should perform, and detail constraints, targets or control mechanisms related to the qualities of the ADF and its success. These can be conceptualized mainly with performance requirements, design constraints and quality attributes. The performance criteria shall be based on customer expectations, minimum targets for expected safe performance in ODD conditions, safety targets when the system is expected to control, and mitigation expectations when outside the defined ODD. These expectations span safety, comfort, usability, controllability, and overall acceptance. It is also essential to account for varying user abilities and learning curves. Defining clear performance boundaries between the ADF and the user is critical, and these boundaries should be continuously refined based on operational feedback to ensure alignment with real-world usage and evolving user.needs. The performance criteria sub-topic aims to outline the functional requirements and customer expectations that ADFs must meet, while considering the aspects of safety, comfort and drivability.
- Requirement – Robust Design
- Requirement – Operational Design Domain – Physical Road Infrastructure Characteristics
- Requirement – Identification of V2X Interactions
- Requirement – Interaction with Mixed Traffic and associated Failure Modes
- Requirement – Transition of Control in Mixed Traffic
- Requirement – Performance in Mixed Traffic
- Requirement – Object and Event Detection and Response in Mixed Traffic
- Requirement – Interaction with Mixed Traffic and associated Risks
- Requirement – Customer Expectations
- Requirement – Performance Boundary – Interaction with Cooperative Systems
- Requirement – Performance Criteria
- Requirement – User Requirements
- Requirement – Identification of Critical Scenarios
- Requirement – Operational Design Domain Limits
- Requirement – Scenarios and Limits
- Requirement – Data Driven Development
- Requirement – In-field Monitoring
- Requirement – Safety Impact of Requirements
- Requirement – Verification of Operational Design Domain
- Requirement – Operational Design Domain
- Requirement – Level of Driving Automation
- Requirement – Risk Identification and Functional Limitation
- Requirement – Automated Driving Function States
- Requirement – Design Methodology
- Requirement – Core Technical Requirements
- Requirement – Functional v/s Non-Functional Requirement
- Requirement – Implementation of Minimal Risk Manoeuvre
- Requirement – Sensor Constraints and Minimal Risk Manoeuvre Design
- Requirement – Minimal Risk Manoeuvre
- Requirement – Existing Standards and Regulations
- Requirement – Documentation
- HVI – Controllability of Vehicle from other Road-user’s Perspective
- HVI – Communication of Minimum Risk Maneuver to the User
- HVI – HVI Design for User’s Monitoring
- HVI – Unintentional Use of ADFs
- SOTIF – Limitations of the ADF
- SOTIF – Driver Monitoring System
- SOTIF – Risks Relating to the Take Over Request
- SOTIF – Identification and Evaluation of Risks
- SOTIF – Functional and System Specification
- Cyber Security – Requirements Evolution through Development
- Cyber Security – Derivation of Requirements
- Cyber Security – Threat Analysis and Risk Assessment
- Cyber Security – Security by Design
- Cyber Security – Organisational Processes
- Functional Safety – Minimal Risk Manoeuvre
- Functional Safety – ADF Transition to a Safe State
- Functional Safety – Derivation of Test Cases
- Functional Safety – Safety Concept
- — Cross-References after this —
- Testing – Test Concept Execution
- Vdata – Data Collection for Analysis of Incidents and Accidents
- V2X – V2X Security Mechanisms for Vehicle Applications
- V2X – Trust Management and Misbehavior Detection
- V2X – Suitability of V2X Technologies for Vehicle Applications
- V2X – V2X Radio Interference and Mitigation
- V2X – Interoperability of V2X Systems
- V2X – Backward Compatibility in V2X System Evolution
- Requirement – Identification of V2X interactions for AD Vehicles