Downloaded 192 times
More Related Content
Similar to An integrative solution towards SOTIF and AV safety
An integrative solution towards SOTIF and AV safety
- 1. Bernhard Kaiser ANSYS Inc. AnIntegrative Solution towards SOTIF and AV Safety IQPC SOTIF Conference Oct 1-2, 2019, Austin, TX
- 2. Agenda New safety challengesfor Automated Driving - SOTIF A practical integrated FuSa & SOTIF approach with medini analyze Outlook on Integration of SOTIF analysis and simulation
- 3. What’s so newabout Safety in the Domain of Automated Vehicles? Traditional Functional Safety (FuSa) is about hazards induced by failures • E.g. Bug in the control software, broken wire, drift in a resistor, random bit-flip in a computer memory • Malfunctions can be traced down to their causes (e.g. hardware part failure) by safety analysis techniques • To either prevent these (e.g. by more reliable parts, better development processes…) or to detect these at runtime and take appropriate counter-action (e.g. safe state), that’s what ISO 26262 is all about. • Sensors and perception algorithms have inherent limitations of nominal performance, even in absence of any failure. • These can further be reduced due to circumstances of the situation, like weather and light conditions, objects around. • There usually not a single hazard cause – a radar that used to work well on an open highway might be blind in a tunnel. • More hazard causes are of systemic nature (i.e. failure in interaction, not in parts - including interaction with humans) • Situations may vary in tiny details, some of them even not known to be relevant, but resulting in different behavior. The part of safety that is not related to failures, but to limitations of the nominal performance has been termed Safety of the Intented Functionality (SOTIF) and will be regulated by upcoming standard ISO 21448 (applicable to automated vehicles of all levels)
- 4. SOTIF vs. FuSa:At First Glance Not That Much in Common FuSa-Lifecycle acc. ISO 26262 SOTIF-Lifecycle: Upcoming ISO 21448 …different main process model, partially different vocabulary, more V&V, less analysis, less focus on design activities etc. ?
- 5. FuSa acc. ISO26262 vs. SOTIF acc. ISO 21448 FuSa acc. ISO 26262 SOTIF acc. ISO 21448 HARA FTA Limitation and weakness analysis FMEA HAZOP STPA FMEDA Technical Safety Concept SOTIF Concept Triggering condition analysis
- 6. ISO 21448 ProcessModel – With Increased Focus on Analysis Techniques PAS 21448 Process Flow (numbered as in the standard acc. clause numbers): 5. Functional and System Specification (comparable to Item Definition in ISO 26262) 6. Identification and Evaluation of hazards caused by the intended functionality (comparable to HARA in ISO 26262) 7. Hazard Cause Analysis, Limitation and Weakness Analysis, Identification and Evaluation of Triggering Conditions 8. Functional improvement or ODD restriction to reduce SOTIF related risks 9. Definition of the Verification and Validation strategy 10. Verification of the SOTIF (Area 2 in diagram) 11. Validation of the SOTIF (Area 3 in diagram) 12. Methodology and criteria for SOTIF release Annexes provide examples and guidance for application. Chapter 1 to 4 comprise front matter, terminology etc.ISO 21448 Process Flow (adapted acc. to a pending change proposal discussed in US WG) START Known Hazards and Situations Functional and System Specification and Design Hazard Identification and Risk Evaluation (HARA) Limitation and Weakness Analysis Hazard Cause Analysis (e.g. FTA, FMEA, STPA) Risks acceptable after analysis? Identification of Triggering Conditions no Definition/Update of the Verification Strategy Verification (e.g. Simulation, Lab Tests, HIL, Vehicle Tests) Risks acceptable after verification? no yes Validation (e.g. Random Simulation, Road Test Rides) Risks acceptable after validation? no yes Functional Improvement or ODD restriction to reduce SOTIF-related risk (SOTIF Concept) 6 7 Methodology and Criteria for SOTIF Release Risks acceptable for release? No potential of severe harm? END Evaluate by Analysis Evaluate acc. Requirements and Known Triggering Conditions Evaluate acc. Unknown Triggering Conditions Definition/Update of the Validation Strategy Field Operation no yes yes yes 6 8 5 7 7 7 9 9 1010 1111 1212
- 7. Agenda New safety challengesfor Automated Driving - SOTIF A practical integrated FuSa & SOTIF approach with medini analyze Outlook on Integration of SOTIF analysis and simulation
- 8. Item Definition andArchitecture Modeling for SOTIF and FuSa Functional and System Specification (Item Definition) 5 ISO 21448 requires some more details than ISO 26262 Item Definition, but the extended Item Definition can still be one common document for FuSa and SOTIF!
- 9. Item Definition andArchitecture Modeling for SOTIF and FuSa Model system architecture, boundaries, interfaces and functions → This can be done in common with FuSa, embracing existing models Functional and System Specification (Item Definition) 5
- 10. Defining Automated DrivingFunctions and Candidate Malfunctions Describing the intended functions and external interfaces in the Item Definition is key for all further SOTIF and FuSa steps. Catalogs of standard functions can help. Hazards and Malfunctions already known from past experience can be put in collections as candidates for HARA and Safety Analysis. HAZOP Guidewords can be applied to systematically derive malfunctions
- 11. HARA for FuSaand for SOTIF Initial HARA can be the same as in ISO 26262, but will evolve and finally contain more malfunctions, new systemic hazards, and much more situations, including triggering conditions. Hazard Identification and Risk Evaluation (HARA) 6
- 12. Some Note onHARA in FuSa vs. SOTIF Are SOTIF HARA and FuSa HARA identical? • The FuSa HARA can serve as an initial population for the SOTIF HARA, but has to be extended as project evolves • The FuSa HARA is normally finished, reviewed and sealed in an early phase – SOTIF HARA will rather be a living document • There will be more functions (e.g. safely braking for an object) and more malfunctions (e.g. leaving safe trajectory) for highly automated vehicles than for ADAS with human driver responsibilities (some may not just be related to one single actuator!) • There will be much more situations to consider for highly automated vehicles → you may start with an enumerative list, but eventually the list may explode because of combinatorics, or enumeration of nameable situations is no longer possible → new kinds of situation respresentation and coverage might become necessary Will there be something like an ASIL for hazards? • There was some discussion in the WG, currently there is no such thing! • Definitely, ASIL is a just measure for process integrity and does not say anything about performance or limitations • Nevertheless, a hazard found to be ASIL x will ever remain ASIL x, no matter what the cause is → there is no use in improving detection performance with big efforts, but afterwards a software bug spoils it all. So consider the ASIL for „good craftsmanship“! • Some ASIL requirements do not fit for AI → but ISO 26262 does allow adaptation and tailoring, solutions will have to be found • Attention: In ISO 26262, low situation probability (E-Factor) means low safety criticality, because situation and failure occurrence are independent. This does not work anymore for SOTIF: The system doesn‘t misbehave in a situation, but because of that situation!
- 13. SOTIF Hazard Genesis Triggering Condition*) *) known or unknown Weakness / Limitation A N D Malfunctioning Behavior Misuse Scenario Scenario where this hazard can lead to harm Hazard A N D Hazardous Event O R A N D Harm Humans do not control hazardous eventScenario where specified behavior is hazardous Graphics from ISO 21448, adapted according to a pending change request Unlike for FuSa, where hazards result from failures, In SOTIF they are caused by: • Triggering conditions from outside that trigger a limitation or weakness of the system (neither of them a failure) • Human misunderstanding or even foreseeable misuse • Lacks in the specification or conception of the use cases the system might be exposed to (e.g. overlooked use case) acc. ISO 26262-1 (2018)
- 14. Hazard Genesis –A Unified View For FuSa and SOTIF Triggering Condition *) *) known or unknown Weakness / Limitation A N D Malfunctioning Behavior O R Failure ISO 21448 ISO 26262 Hazard O R
- 15. New Model ElementsFor Generalized Fault Trees / Failure Nets Triggering Condition *) *) known or unknown Weakness / Limitation A N D Malfunctioning Behavior Triggering Conditions Weaknesses and Limitations Malfunctioning Behavior
- 16. New Medini ModelElements for Analysis in the SOTIF Domain A component (e.g. Sensor) A function of that component A malfunction to that function A (nominal) characteristics of that sensor A limitation of that characteristics A general limitation of that sensor
- 17. Causal Analysis usingFault Trees (FuSa vs. SOTIF) Continue towards SOTIF (ISO 21448) Continue towards FuSa (ISO 26262) Hazard on Vehicle Level Intermediate Malfunctions (at this level, causes can be either failures or weaknesses) Investigative / Causal Analysis (e.g. FTA,FMEA, Failure Net) 7a Note: VRU = Vulnerable Road User (e.g. pedestrian)
- 18. Causal Analysis usingFault Trees (FuSa vs. SOTIF) Subtree for SOTIF (continue in ISO 21448) Subtree for FuSa (continue in ISO 26262)
- 19. SOTIF Investigative /Causal Analysis (similar to FTA, FMEA/Failure Net* ) Investigative / Causal Analysis (e.g. FTA,FMEA, Failure Net) 7a Hazard (Safety Goal Violation) Causes (lower level malfunctions) On functional level the distinction FuSa/SOTIF is optional. * = On functional level, malfunctions can be same for FuSa and SOTIF. On technical level replace „failure“ by „weakness“.
- 20. SOTIF Investigative /Causal Analysis (similar to FTA, FMEA/Failure Net* ) Hazard (Safety Goal Violation) SOTIF Root Causes (Weaknesses) Intermediate Malfunctions (could be FuSa or SOTIF caused) Investigative / Causal Analysis (e.g. FTA,FMEA, Failure Net) 7b * = On functional level, malfunctions can be same for FuSa and SOTIF. On technical level replace „failure“ by „weakness“.
- 21. SOTIF Investigative /Causal Analysis using STPA STPA is a systemic approach that addresses not just local failures and weaknesses, but also hazards resulting from the interaction of systems (including human-machine interaction) and therefore complements traditional analysis approaches. As it covers both failures and other kinds of weaknesses / insufficiencies, it serves in an integrated fashion for • FuSa • SOTIF • Safety in Use The consequences drawn from the analysis can be treated separately for FuSa and SOTIF. STPA Workflow in the Context of ISO 21448 / ISO 26262 STPA Control Loop and Hazard Causation Model
- 22. SOTIF Investigative /Causal Analysis using STPA with medini analyze
- 23. Limitation and WeaknessAnalysis (in the style of Matrix / FMEA / HAZOP) Put sensor / function characteristics into relationship to feataures / aspects of potential scenarios • Repository of Scenario Aspects must be defined (e.g. weather, road layout, objects around…). • Sensor characteristics and their nominal limitations and their susceptibilities to disturbances must be investigated. Limitation / Weakness Features / aspects that can appear in scenarios Guidewords or Characteristics of the used sensors and algorithms (from architecture) Limitation and Weekness Analysis 7b
- 24. Triggering Conditions Analysis TriggeringConditions can be found: 1. By causal analysis: • Identify malfunctions leading to hazards (deductive analysis) • Identify the weaknesses in the nominal performance of the system (inductive analysis) • Identify the triggering conditions for these weaknesses (deductive or inductive analysis) 2. By evaluating mishap scenarios from sensor tests, vehicle road tests and simulation Triggering Conditions can be named and listed in collections and even modelled as abstract scenario fragments. Identification of Triggering Conditions 7c
- 25. Triggering Conditions Collections Identificationof Triggering Conditions 7c Identified Triggering Conditions can be kept in collection for further use in new projects. If helpful, a SysML model for their evolution over time (Activity Diagram) can be attached.
- 26. Functional Safety Concept,Technical Safety Concept, SOTIF Concept Solution Improvement or ODD restriction (SOTIF Safety Concept) 8 Functional Safety Concept (optionally for ISO 26262 and ISO 21448 in common) SOTIF Concept (ISO 21448) Technical Safety Concept (ISO 26262)
- 27. Functional Improvement: SOTIFConcept Functional Requirements first derived from Safety Goal, on lower levels by derived from identified malfunctions. Subsequent Refinement into Technical (FuSa) and Performance (SOTIF) Requirements in separate Safety Concepts (TSC / SOTIF Concept) Safety Goal (from common FuSa/SOTIF HARA) Handling SOTIF and FuSa in one concept for the functional level is possible, but not a must! Solution Improvement or ODD restriction (SOTIF Safety Concept) 8
- 28. Functional Improvement: SOTIFConcept Enhancement of architecture in terms of performance / weakness avoidance by additional SOTIF mechanisms from requirements Solution Improvement or ODD restriction (SOTIF Safety Concept) 8
- 29. Deriving Verification Tasksfrom SOTIF Concept Requirements Verification Strategy (initial + cyclically upated) 9 • Verification Cases can be derived from requirements. • Triggering Conditions can be exported and fed into Scenario Generator as a basis for simulation case generation. • Robustness / Regression Tests show success of system improvement. • V&V Tasks can be created out of medini and exported into Jira and other tools.
- 30. Agenda New safety challengesfor Automated Driving - SOTIF A practical integrated FuSa & SOTIF approach with medini analyze Outlook on Integration of SOTIF analysis and simulation
- 31. Motivation for CloserIntegration of SOTIF Analysis and Verification • In traditional FuSa, the safety engineer could do his/her job mainly on his/her own • Sometimes having to invite domain experts for HARA, FMEA, discussion on test findings or possible solutions etc. • Some interaction points in the process workflow (architecture import, requirements export…) • Typical car usage scenarios were known, typical part failure modes (short circuit etc.) and their consequences also • For verification/validation, the safety engineer could rely on accepted practices (e.g. MC/DC) well-known to engineers • The behavior of some perception algorithms can be so unpredictable that analytical techniques alone may not discover malfunctions (e.g. Why is a pedestrian usually detected, but not when he wears a warning vest?) • Even if a SOTIF analyst thinks about a problem cause (e.g. dim light and dark object color), without simulation or test it would remain guesswork whether it is an issue at all and under which exact conditions (How dark? Which colors?) • Causal chains are often obscure, and it takes simulative exploration, problem injection and monitors to explain them • Safety engineers have to specify what to verify – but cannot go as deeply into the details as a simulation expert can do
- 32. Use Case 1:Exploiting Test Drive / Simulation Results in Medini Analyze HARA / Triggering Cond Triggering Conditions, Malfunctions, Hazards OpenLoop SensorSimulation ClosedLoop ScenarioSimulation UC1 Evaluationof Recordedroadtests Scade Vision
- 33. VRXPERIENCE High FidelitySimulation Uncovers Triggering Conditions medini analyze HARA Cause-Effect-Analysis Triggering Conditions SOTIF-Concept Add „Sunglare“ to Triggering Conditions In traditional FuSa, you might find all failure mode by systematic analysis with experienced experts. In SOTIF, you will never guess all possible Triggering Conditions! Physically accurate sensor simulation helps discovering Triggering Concitions, faster and less expensive than road testing. UC1 Physically accurate simulation can reveal that sunglare could prevent your camera from detecting a person on the crossing.
- 34. SCADE Vision IdentifiesEdge Cases from Recorded Road Data http://bit.ly/2tvCCPK https://goo.gl/3dzguf Scenario Database Customer Road Data Interesting Scenarios medini analyze SCADE Vision … that an analyst would probably never have found on his own! UC1
- 35. SCADE Vision*) Findsand Labels Edge Cases Automatically Did not see the construction worker in yellow warning vest UC1 *) powered by Hologram from Edge Case Research Find in huge amounts of recorded data Weak detection / false negative Assignment of Cause HypothesisFrame with Detection Error
- 36. SCADE Vision HelpsAnalysts to Assign Root Cause Hypotheses Rain Low contrast Orange clothing Proximate to vehicle Low contrast Wearing shorts Proximate to vehicle Low contrast Holding an object Three occurrences of weak detection of a person. But what could be the cause (triggering condition acc. to SOTIF)? Frequent combination of perception malfunction and suspect triggering conditions → probably a cause-effect relation! UC1
- 37. Find Triggering Conditionswith SCADE Vision and Analyze in medini • SCADE Vision analyzes recorded video for camera malfunctions (e.g. false positive, false negative, weak detection, duplicate) • Manual annotation of cause hypotheses, i.e. Triggering Conditions (e.g. partially obstructed, similar color as background etc.) • From SCADE Vision, reports for selected SUTs, trip segments and class types can be exported to an EXCEL file • This EXCEL file is imported into medini • In medini, a causal link between imported Triggering Conditions and camera malfunctions is automatically established UC1
- 38. Find Triggering Conditionswith SCADE Vision and Analyze in medini Import and Post-Process in medini • Link malfunctions and Triggering Conditions to existing malfunctions and triggers or extend collection • Analyse frequency of observed combinations of malfunctions and their triggering conditions • Frequent case → Suspect for actual causal relation • Sporadic case → Request more testing or simulation UC1
- 39. Find Triggering Conditionswith SCADE Vision and Analyze in medini Effects of the SOTIF-caused malfunctions are added by the safety analyst in medini. Failure Net automatically shows path to vehicle malfunctions and hazards UC1
- 40. Use Case 2:SOTIF Analysis Suggests Triggering Conditions to Simulation Scenario Generator Evaluation Monitor Generator Database Scenarios Maneuvers Environm. Conditions medini analyze HARA Cause-Effect-Analysis Limitation&Weakness Analysis Triggering Conditions Log: Constraint Violations Critical Limits/Parameters VRXPERIENCE Driving Simulator Run Simulation Scenarios Observe Monitors UC2 I‘m afraid that a close merge into my lane by another vehicle could be detected too late. Could you check this for me? Safety Analyst One underspecified scenario fragment may result in hundreds of scenarios to be executed.
- 41. 42 Export Example of aprototypical domain specific language exported from medini and imported into a Scenario Generator, which generates scenario specs and monitors for simulation by VRXPERIENCE Scenario fragment modeling in medini analyze UC2
- 42. Closed-loop simulation offull AV stack (Hardware-in-the-loop) Camera and LiDAR synchronized simulation Camera Sensor • Lens model • Color filter • Image sensor • Circuit board • Noise model Road Environement & Scenario Simulation Vehicle dynamic Simulation Rest-of-bus Simulation Front camera ECUdata overCANbus Internal Renderingdata Bus Interface ECU data over USB s y n c h r o n i s e d synchronised Image Injection Adapter Camera image Real-Time Camera Adaption / Injection Camera ControlFeedback Loop Dynamics data over Ethernet Internal Simulation Bus UC2
- 43. Combining VRXPERIENCE andSCADE Vision • Photo-realistic simulated VRXPERIENCE scenarios can be loaded into SCADE Vision just like real camera recordings • Perfect ground truth, because all participants of a scenario are known • Analysis for sensor malfunctions and potential triggering conditions can be performed faster and on more variants • Light conditions can be changed, disturbances (e.g. fog) can be added • Regression and Robustness Testing after improvement UC1+2
- 44. Integrated Round-Trip Use-Casemedini / VRXPERIENCE / SCADE Vision Scenario Generator VRXPERIENCE SCADE Vision Medini analyze I‘m afraid that a person partially hidden behind a pole could be missed by the detection. Could you check this for me? Safety Analyst Abstract Scenario Specification (Key Features) ManyConcrete ScenarioVariants Many Photorealistic Video Files Reportwith MalfunctionOccurrences AndTriggeringCondition Hypotheses Creation of huge amounts of scenario variants to verify / falsify triggering condition hypotheses Disturbance Injection possible – including gradual variation of disturbances to evaluate robustness UC1+2
- 45. Some Use CaseExamples for Integrative SOTIF Approaches • Regular road Testing or Simulation (outside the SOTIF process) discovers new malfunctioning behavior, new triggering conditions or even new hazards, which must be submitted to the SOTIF analyst for consideration • The SOTIF anlyst discovers possible issues through deductive or inductive analysis techniques and requests the simulation / testing team to verify/falsify this hypothesis and to determine relevant side conditions • Certain kind of malfunctions have been observed, but cannot be explained – simulation team and SOTIF analyst collaborate on modeling a causal net and exploring by whitebox-simulation with monitors • In the SOTIF concept, architecture / algorithm improvement has been elaborated implemented. Regression testing and disturbance injection verify the appropriateness and robustness of the improved solution • Based on SOTIF requirements he/she derived, the SOTIF analyst suggests simulation or test runs to be performed on the release candidate vehicle function as a means of verification or validation • … to be continued, there are even more promising ideas under evaluation! UC1 UC2 UC3 UC4 UC5 UC n
- 46. Conclusion • New mechanismsleading to malfunctions and hazards to be considered for AVs: Weaknesses / Limitations in combination with Triggering Conditions, Specification Flaws and Misuse / Misunderstanding • ISO 21448 looks different (and is different in some aspects) than ISO 26262 But many analysis methods can be reused or perfomed combined for both purposes • Safety (SOTIF) Analysis and Verification/Simulation will have to be closer integrated E.g. Safety Analysis gives directions what to simulate, simulation finds issues that analysis would never have found etc.
- 47.