www.pegasusprojekt.de REQUIREMENTS AND CONDITIONS – Booth No. 03 V-MODEL AND PROCESS ANALYSIS Analysis of established processes regarding automated driving In which steps do the established development and safety processes need to be extended to enable the development and safeguarding of automated driving functions? The V-model is a process model originating from software development that has been established for the development of complex safe-critical systems in the avionics and the automotive domain. Requirements Acceptance Tests Vehicle Level Vehicle Level The first step is to specify the For the final approval it is examined requirements for the complete product whether the complete product (which is the vehicle here) from the satisfies the requirements of the perspective of the stakeholders. stakeholders. System Design System Tests The remaining part of the left branch of the V covers the design of the system on multiple levels of abstraction finally resulting in a technical implementation. Subsystem Design Integration Tests The right branch of the V describes the verification and validation of the developed system. For this purpose for each abstraction level test obligations are defined that need to be satisfied for a successful product development. Component Component Design Tests V Model Technical Implementation www.pegasusprojekt.de REQUIREMENTS AND CONDITIONS – Booth No. 03 V-MODEL AND PROCESS ANALYSIS The ISO 26262 is a standard for safeguarding electric and electronic (E/E) systems in passenger cars. Based on the V-model the standard defines a process to ensure the functional safety of such systems before putting them into operation. This process has been and still is successfully applied for vehicles that are exclusively operated by human drivers and for vehicles equipped with advanced driver assistance systems (ADAS). It does not address the nominal performance of the E/E systems. Requirements Acceptance Tests Vehicle Level Vehicle Level Functional Functional Specification Safety After defining the functional specification of the system under Assessment Hazard Analysis and development a hazard analysis and risk assessment is Risk Assessment performed. Based on these results the system is designed and a safety concept is developed. The hardware and software development then takes place in further parallel runs of the V- System Design System Tests model. System Design and Safety Validation Safety Concept On the right branch of the V integration tests for the developed components are performed and a validation of the safety goals (safety validation) takes places as well as a functional safety assessment of the Subsystem Design complete vehicle against the functional specification. Integration Tests Hardware Development Software Development Component Component Design Tests V Model ISO 26262 Technical Implementation www.pegasusprojekt.de REQUIREMENTS AND CONDITIONS – Booth No. 03 V-MODEL AND PROCESS ANALYSIS The ISO/PAS 21448 provides guidance on the applicable design, verification and validation needed to archive the Safety of the Intended Functionality (SOTIF) for SAE Level ≤ 2 does not apply to faults covered by the ISO 26262 is intended to be applied where proper situational awareness is critical to safety. Functional safety (ISO 26262) and SOTIF (ISO/PAS 21448) are distinct and complimentary aspects of safety. Methodology and 12 Criteria for SOTIF Release 9 Requirements Definition of the Verification and Validation Strategy Acceptance Tests Vehicle Level Vehicle Level 5 Functional Functional Specification Safety Assessment 6 The SOTIF related Hazard identification process 11 Validation of the HazardSOTIF Analysis related and is similar to the process described by the ISO SOTIF: Evaluate HazardRisk Assessment Identification 26262, because the vehicle-level effects of SOTIF and Risk Assessment related potentially hazardous behaviour and the Unknown Scenarios system failures covered by the ISO 26262 series System Design System Tests can be identical. System Design and Safety Validation Safety Concept 7 10 Identification and Verification of the Evaluation of SOTIF: Evaluate Note that the steps 5 , 6 , 7, 8 Triggering Events Known Scenarios (referring to clause numbers in the ISO/PAS Subsystem Design 21448) may require several iterations (not depicted Integration Tests here). 8 Functional Hardware Development Software Development Modification to reduce SOTIF risk Component Component Design Tests V Model ISO 26262 ISO/PAS 21448 Technical Implementation www.pegasusprojekt.de REQUIREMENTS AND CONDITIONS – Booth No. 03 V-MODEL AND PROCESS ANALYSIS New Challenges arise with the introduction of highly automated driving functions, thus requiring extensions of established development and safeguarding processes Interaction with other human traffic (mixed traffic) Operation in highly complex and hardly predictable environment (open world) Loss of human driver as a fallback (fail operational instead of fail-safe) Changing safety-critical functional requirements during product life Intensive use of machine learning techniques Treatment of Human Behavior Tests under Consideration of (Driver and Other Traffic Participants) Human Behavior Requirements Development Test HMI Acceptance Tests Vehicle Level HMI Concept Concept Vehicle Level Functional Functional Specification Lifting ISO/PAS Safety 21448 to Level 3 Assessment Hazard Analysis and Risk Assessment System Design Scenario-based Approach to Handle Complex Environments System Tests System Design and Safety Validation Safety Concept Development Test Fallback Fallback Concepts Concepts Subsystem Design Integration Tests Hardware Development Software Development Test Development Update Update Strategy Component Strategy Component Design Tests Consideration of Systematic V Model Faults (Design / Software) ISO 26262 Safeguarding Self-learning Algorithms ISO/PAS 21448 Extensions Technical Implementation .