It s all about safety and validation

Transcription

1 It s all about safety and validation Dr. Karl-Heinz Glander ZF DivA GEE ADAS Function & Algorithm Internal

2 Agenda 1. Motivation 2. Introduction into ISO DPAS (SOTIF, Safety Of The Intended Functionality) 3. SOTIF and ISO Verification and Validation of Automated Vehicles: Extending of SOTIF for Automated Driving 5. Remarks on Validation of AI Algorithms 6. Summary Internal 2

3 01 Motivation Internal 3

4 Ancient vision of the future But this happened in between

5 Nominal Performance 5

6 Nominal Performance source: source:

7 02 Introduction into ISO DPAS Safety Of The Intended Function (SOTIF) Internal 7

8 Safety Of The Intended Functionality (SOTIF) Systems, which rely on sensors, complex algorithms and actuators implemented by electrical and/or electronic (E/E) systems, can lead to safety violations if a hazardous decision about the environment is made by the processing algorithm, based on the sensor input, even in the absence of fault in the system. ISO 26262:2011 addresses the safety risks that arise from malfunctions of the E/E systemin vehicles. A proper understanding of the function, its behavior and its limitations (including the human/machine interface) is key to ensuring the user s safety. SOTIF assumes that the E/E malfunctions of the item are addressed using ISO The activities of SOTIF are additional to those given in ISO SOTIF provides guidance on the design, verification and validation measures applicable to avoid a malfunctioning behavior in the system in the absence of faults, resulting from technological and system definition shortcomings. 8

9 Safety Of Intended Function Basis Understanding of Scope The SoTIFdiscussion has evolved from a problem of handling implicit complex items. Nominal performance limits of the sensing system are accepted on the risk of (very rare) situations leading to violations of SGs, without any fault in the sensing system itself. The SoTIFdiscussion is a consequence of improper safety requirement refinement and/or of improper item definition, i.e. the initial requirement statement. If the intended function is potentially hazardous in some situation, then the item is simply not well defined. 9

10 Evolution of the use case categories Minimize area 2 and 3 functional improvement use case restrictions test result evaluation 10

11 Flowchart of the SOTIF activities 11

12 03 SOTIF and ISO26262 Internal 12

13 ISO & SOTIF Mapping 13

14 Combination of safety analysis 14

15 Development Cycle incl. SOTIF activities System Engineering and System Test HARA Development Phase FuSa & SOTIF Item Definition System Description I. Scenarios Def n. System Development* 5 System Specification Verification& Validation Planning System V&V Plan FuSa& SOTIF V&V V&V Approach V&V Techniques 9 V&V Approach(es) V&V Techniques 6 II. Safety Eval. Safety Goals incl. ASIL levels Functional ETA Functional Safety Concept Use Cases Scenarios 7 Verification& Validation Phase Test Report Residual Risk Evaluation 12 7 * According to AutoSPICE Functional Safety Req. incl. ASIL levels Technical Safety Concept 7 System FTA Technical Safety Req. incl. ASIL levels 8 Requirements System Arch. & System Requ. Design Design FMEA 8 Validates Verifies System Test Specification System Integration Test Specification FuSa& SOTIF SOTIF

16 04 Verification and Validation of Automated Vehicles: Extending of SOTIF for Automated Driving Internal 16

17 Iterative development 6, 7-Hazard Identification and Evaluation of triggering events Derivation of test scenarios regarding triggering events 5-Functional and System specification Derivation of test scenarios regarding use cases, error guessing and field experience 8-Functional modifications to reduce SOTIF risk Tolerable risk of harm? Acceptable residual risk? 10-Verification of the SOTIF (Area 2) Test track, public road, simulation Prototype vehicles and measurement equipment 11-Validation of the SOTIF (Area 3) Public road Preseries vehicles Fleet tests 12-Methodology and Criteria for SOTIF release Risk accepted 17

18 Extending of SOTIF Flowchart for AD 18

19 HARA process for Automated Driving Phase I: Scenario Definition Mapping Mapping Mapping + Aggregation Operating States Resulting Situations Resulting Scenarios Representative Scenarios Situations Environmental Situations/Events Products Phase II: Safety Evaluation Mapping Risk Assessment Legend Representative Scenarios Generic Hazards Automation Level Hazardous Events ASIL Rated Safety Goals + Safe States Product specific Product & Level specific 19

20 HARA process example Phase I: Scenario Definition Operating State Vehicle drives forward Situation On a motorway with low speed Phase II: Safety Evaluation Representative Scenario Dangerous obstacle occurs in lane Hazard Intended deceleration is not initiated Automation Level Conditional Automation Mapping Mapping Mapping + Aggregation Mapping Resulting Situation Vehicle drives forward on a motorway with low speed Environmental Event With obstacles on the road Hazardous Event Conditional automated HTJA is not initiating braking when dangerous obstacle occurs in lane Risk Assessment Resulting Scenario Vehicle drives on a motorway with low speed with obstacles on the road Product Highway Traffic Jam Assist (HTJA) Safety Goal and Safe State ASIL B: Collision with hazardous objects shall be avoided. A. Longitudinal control is taken over by driver. B. As long as the driver has not taken over the driving task, any deceleration is automatically initiated until standstill within ego lane is reached (or) an automatic collision avoidance maneuver is performed. Representative Scenario Dangerous obstacle occurs in lane Legend Generic Product specific Product & Level specific 20

21 Addressing SOTIF Vehicle Validation: Where do I need to drive? Conditions / Events Weather / Visibility Diver behaviour Road & Lane Surrounding vehicle Miscellaneous environmental events Relevant night, fog, low sun in the morning or evening, with other vehicles or people close to the ego vehicle, heavy snowfall, water spray by ahead driving or passing vehicles, sandstorm, heavy rain, with leaves on the lane, with changing brightness caused by shadows etc. Eyes-off, Hands-off approaching lane end, with different kinds of lane markings, and curvy road, on surface with low friction, on rough roads etc. Traffic jam (low/med/hi), ego vehicle is involved in accident Use cases and targets for the function are more important than driving for millions of KM The analysis of traffic statistics can provide an initial idea about a reasonable target for validation mileage: We want our systems to be more robust than the most advanced AD currently available: humans Where needs to be driven is more important than how much we need to drive: It is important to stimulate the system to handle all critical uses cases and exercise all critical detection characteristics Driver events Door open, Driving style inaccurate in lane etc. Surrounding vehicles events Emergency vehicle approaches, etc. With autonomous driving on the horizon, how much and where to drive is a debate that needs to be taken seriously! 21

22 Real-world Synthesis System V&V Strategy Extensive verification and validation through combination of test approaches V&V for AD System & Components SyntheticScenarios using Simulation Import & parameterize Real World Data FOT Performance Test DB GIDAS SOTIF V&V Area 2 Definition of V&V Strategy 10 Scenario DB (Synthetic + Real World) 22

23 Determination of System Failure Rate Scenario #1 Scenario #2 P(Scene#1)= 10-5 /h P(Scene#2)= 10-6 /h Scenario #n P(Scene#n)= 10 -? /h FIXED VALUES by Data Modelling or Real World Data Goal: P F < /h for unprotected system X P F = X X (estimation: fleet of vehicles x km lifetime / average speed of 40 km/h) P F, System (Scene#1)= 10-7 /h Sensor Sensor Sensor P F, System (Scene#2)= 10-6 /h System Configuration Brake Steering Powertrain AD Functions & SDE P F, System (Scene#n)= 10 -? /h HMI ENGINEERING VARIABLES by Quality and Redundancy

24 Simulation of Relevant Scenarios N-dim. parameter space for specific use case/feature N-dim. parameter space for specific use case/feature Coverage of scenario space Simulative variation 1. Define representative sample of the overall scenario space and all relevant parameters. 2. Assign criticality (ASIL level related) to these scenarios. 3. Decision on the extend of testing based on Point 2. 24

25 ZF Approach to Functional Testing Serial Ready Collection of synthetic scenarios Systematic Test Scenario Generation Experience based randomized Test scenario Collection of real world data (Euro) Field Operational Tests GIDAS NCAP World-wide L2 Fleetbased data collection Validate Models Semantic and Synthesized Scenario DB Statistical rating, assessment of severity & derivation of parameters Real world scenario DB ZF Test Methods Test Scenario DB Parameter Variation & Distribution to different test environments Test environments Vehicle Tests Static & Dyn Simulator HiL (Network of ECUs) SiL (AD Algos) Industry/Consortiums

26 SOTIF Example: Automated Highway Exit (AHEx) Test Report Residual Risk Evaluation Minimized residual risk by: SY_Req (KPIs) V&V Plan amount variety quality HIL mileage Result: Residual risk is acceptable. hours driver locations ambience real world data driving simulator SIL Unknown Use Case Quantified Targets Fulfilled? YES Residual Risk Evaluation 12 Residual risk accepted? YES 26

27 05 Remarks on Validation of AI Algorithms Internal 27

28 Powers and Risks of Machine Learning Techniques Sitawarin et al. (2018), arxiv: Black box: Difficult or impossible to understand failure Tech:AD Berlin 2018 ZF Div A GEE ADAS Function & Algorithm Dr. Karl-Heinz Glander It s all about safety and validation 28

29 Strategy for Integration of Machine Learning Techniques for AD Problem with misclassifications Semantic knowledge is missing Humans also cannot always explain their thought processes: We intuitively trust/gauge people Solution Stick to very limited competence frame Test for completeness More difficult for complex classifiers Strategicrevenue.com 29

30 How to Understand Artificial Intelligence Visualization of functional layers Lower: simple things Higher: more complex structures Top: identifiesobjectasawhole nvidia.com Deep dream (Google, 2015) Strategy to capture decision making process Reverse process: algorithm to generate objects Shows how different deep learning is from human perception Artifactswouldbeignoredbyahuman 30

31 Different Approaches for AD and their Limitations End-to-end approach Small networks for well-defined tasks Input Measured sensor data (e.g. radar) Higher level processed data Network Complex network across all functional layers of AD (1000s units per layer, 100s of layers) Small network in one functional layer of AD Output Operation commands (e.g. brakes) Classifications/decisions Benefits vs. Risks +One simple architecture for all scenarios Complex architecture, use case based Test for completeness impossible + Test for completeness possible Impossible to predict failures Causal relationship unclear due to complexity +Defined competence frame: limitations known + Failures can be understood 31

32 Summary Systematic approach to System Safety and (new) Verification & Validation Methods are key for the Industrialization of Automated Vehicles Unified HARA approach allows combination of SOTIF and ISO26262 in standard system engineering approach Function and scenario driven approach to HARA; can be easily applied to all previously evaluated products A catalogue of evaluated scenarios covering all ZF Automated Driving products is automatically developed over time Inconsistencies between diverse products and automation levels can be easily recognized and corrected Differences and similarities from functional safety point of view between diverse products and automation levels can be easily emphasized to facilitate architectural decisions Validation of Automated Driving needs quality data not necessarily massive amount of data No need to drive billions of km or miles. All the key characteristics of the system shall be exercised during the development. The scenarios are expanded to cover the requirements for the intended use. Then completeness can also be argued for SOTIF and must also include statistical confidence. Validation of Artificial Intelligence needs cautious approach in utilizing NN

33 Thank you Dr. Karl-Heinz Glander Chief Engineering Manager Automated Driving & Integral Cognitive Safety ZF Group - TRW Automotive GmbH Hansaallee 190, Düsseldorf Karl-Heinz.Glander@zf.com, ZF Friedrichshafen AG behält sich sämtliche Rechte an den gezeigten technischeninformationeneinschließlichder RechtezurHinterlegungvon Schutzrechtsanmeldungen und an daraus entstehenden Schutzrechten im In- und Ausland vor. ZF Friedrichshafen AG reserves all rights regarding the shown technical information including the right to file industrial property right applications and the industrial property rights resulting from these in Germany and abroad. Internal 33