![7
ODD Definition
extend road_type: [city_expressway]
extend path:
slope: angle
adhesion: real wih: keep(it >= 0)
curvature:curvature
type: road_type
modifier map.path_in_odd:
p:path with:
keep(it.curvature in [straightish, soft_left, soft_right])
keep(it.slope in [-8..8]degree)
keep(it.adhesion >= 0.3)
keep(it.signals.length() == 0 )
keep(type in [highway, city_expressway])
path_length(p, [0..]m, [0..]m, allow_junction: false)
path_min_lanes(p, 2)
modifier traffic.highway_authorized_traffic:
keep(traffic.filter(is_pedestrian(it)).length() == 0)
keep(traffic.filter(is_bicycle(it)).length() == 0)
keep(traffic.filter(it.speed >= 60kph).length() == 0)
Road Type Highway, city expressway (includes road
diversion/confluence; does not include
entrance/exit ramp, isolation strip between two
opposite lanes, junctions, traffic lights, pedestrians,
obstacles, construction, roadworks, traffic control
and all non-structure factors; all lanes are clearly
visible)
Vehicle Speed
Request
≤40km/h
Lane Type straight lane, curve lane (radius>250m), double or
more lane
Lane Width 2.8m-4.2m
Lane Line Width 100-300mm
Lane Line Type Color: white, yellow.
Line type: solid, dashed, single line, double line,
curb, traffic barrier
Road Surface adhesion coefficient≥0.3
slope between -8° and 8°
Weather
Condition
Light rain (Visibility>200m), light snow, fog,
except for heavy rain, heavy fog, heavy snow and
strong light
Illumination
Condition
All day and all night (near light is requested in
night), illuminance>10lux.
Traffic Condition A front car with low driving speed.
Adjacent lanes are passable but with low-speed
vehicles or adjacent lanes are not passable.
ASAM OpenODD is a standard in preparation to formalize the ODD specification and allow metrics on it.](https://image.slidesharecdn.com/imbsa2022-250117122138-15d2c8e3/85/An-AEBS-Use-Case-for-Model-Based-System-Design-Integrating-Safety-Analyses-and-Simulation-7-320.jpg)
![8
Scenario (one out of many): NCAP CCRs
Scenario Name CCRs
Type of test AEB
VUT speed [km/h] 10 - 80
VUT direction Forward
Target speed [km/h] 0
Impact location [%] [-75;-50;100;50;75]
Lighting condition Day
Description:
The CCRs (Car-to-car rear, stationary) scenario is
a combination of speed and overlap with 5km/h
incremental steps in speed and 25% in overlap
within the ranges as shown in the tables below.](https://image.slidesharecdn.com/imbsa2022-250117122138-15d2c8e3/85/An-AEBS-Use-Case-for-Model-Based-System-Design-Integrating-Safety-Analyses-and-Simulation-8-320.jpg)
An AEBS Use Case for Model-Based System Design Integrating Safety Analyses and Simulation
- 1. An AEB use case for Model-Based System Design integrating Safety Analyses and Simulation Bernhard Kaiser, Bernard Dion, Ilya Tolchinsky, Thierry Le Sergent, and Max Najork IMBSA 22 Munich, Germany September 5th, 2022
- 2. 2 What’s this talk about? Over several months we have developed a simplified Autonomous Emergency Braking (AEB) Function applying model-based systems and safety engineering methods. AEB is an ADAS function that continuously observes distance and speed difference to vehicles and other objects in front, assesses the risk of a collision, and if necessary, warns the driver or even triggers an emergency braking.
- 3. 3 What were our research / demonstration questions? • How can a modern and practicable MBSE process look like? • How and in which phases can we smoothly integrate safety activities and profit from existing models? • How can SOTIF (Safety of the intended functionality) be addressed? • How can we profit from SysML models to support (early) V&V activities by simulation? • How do we assure that feedback from analysis and simulation flows back into the design activities? … and of course: • How can Ansys tools support the suggested development process?
- 4. 4 Iterations Driven by Safety Analysis and Early Validation Step numbers according to white paper „Safety of the Intended Functionality: How Ansys Can Help You Meet This New Standard for Autonomous Vehicles “, available at www.ansys.com/resource-center/white-paper/safety-of-intended-functionality
- 5. 5 Formalizing the proceeding: The Ansys MBSE Workflow
- 6. 6 The Beginning – Informal Feature Idea Feature List Use Cases / Application Scenarios AEB • Brake for traffic jam end • Brake for decelerating vehicle • Acceptable false positives • Overridable • NCAP compliant Preliminary Architecture / Solution Idea Target Vehicles, Target Countries, Road Types etc.
- 7. 7 ODD Definition extend road_type: [city_expressway] extend path: slope: angle adhesion: real wih: keep(it >= 0) curvature:curvature type: road_type modifier map.path_in_odd: p:path with: keep(it.curvature in [straightish, soft_left, soft_right]) keep(it.slope in [-8..8]degree) keep(it.adhesion >= 0.3) keep(it.signals.length() == 0 ) keep(type in [highway, city_expressway]) path_length(p, [0..]m, [0..]m, allow_junction: false) path_min_lanes(p, 2) modifier traffic.highway_authorized_traffic: keep(traffic.filter(is_pedestrian(it)).length() == 0) keep(traffic.filter(is_bicycle(it)).length() == 0) keep(traffic.filter(it.speed >= 60kph).length() == 0) Road Type Highway, city expressway (includes road diversion/confluence; does not include entrance/exit ramp, isolation strip between two opposite lanes, junctions, traffic lights, pedestrians, obstacles, construction, roadworks, traffic control and all non-structure factors; all lanes are clearly visible) Vehicle Speed Request ≤40km/h Lane Type straight lane, curve lane (radius>250m), double or more lane Lane Width 2.8m-4.2m Lane Line Width 100-300mm Lane Line Type Color: white, yellow. Line type: solid, dashed, single line, double line, curb, traffic barrier Road Surface adhesion coefficient≥0.3 slope between -8° and 8° Weather Condition Light rain (Visibility>200m), light snow, fog, except for heavy rain, heavy fog, heavy snow and strong light Illumination Condition All day and all night (near light is requested in night), illuminance>10lux. Traffic Condition A front car with low driving speed. Adjacent lanes are passable but with low-speed vehicles or adjacent lanes are not passable. ASAM OpenODD is a standard in preparation to formalize the ODD specification and allow metrics on it.
- 8. 8 Scenario (one out of many): NCAP CCRs Scenario Name CCRs Type of test AEB VUT speed [km/h] 10 - 80 VUT direction Forward Target speed [km/h] 0 Impact location [%] [-75;-50;100;50;75] Lighting condition Day Description: The CCRs (Car-to-car rear, stationary) scenario is a combination of speed and overlap with 5km/h incremental steps in speed and 25% in overlap within the ranges as shown in the tables below.
- 9. 9 Aggregating Requirements From Different Sources Market Research § Legislation Standards OEMs End Users Competition Requirements DB (recommended: template language) R&D
- 10. 10 Stakeholder requirements for AEB UNECE Requirements Proposal for an Advanced Emergency Braking Function Note: Most stakeholder requirements tell us when to brake – but not when NOT to brake! This will be added later in the course of Hazard Analysis. Source: UN ECE Draft Std on AEB
- 11. 11 Derived Top-Level Requirements for Highway AEB Function
- 12. 12 Initial Functional Architecture in SysML Functional Architecture, Top Level
- 13. ? The Requirements Refinement Problem Sensor (e.g. Camera) Pre- Processing Detektion/ Tracking Sensor Data Fusion D A ... ... Feature Extractor 3 Track Planner EPS ESC Engine Control Feature Extractor 2 Feature Extractor 1 Arbiter Sensor (e.g. Lidar) Pre- Processing Detektion/ Tracking D A Decider 3 Decider 2 Decider 1
- 14. ? The Requirements Refinement Problem Sensor (e.g. Camera) Pre- Processing Detektion/ Tracking Sensor Data Fusion D A ... ... Feature Extractor 3 Track Planner EPS ESC Engine Control Feature Extractor 2 Feature Extractor 1 Arbiter Sensor (e.g. Lidar) Pre- Processing Detektion/ Tracking D A Decider 3 Decider 2 Decider 1
- 15. Systematic Architecture and Requirements Refinement Applying the requirements refinement process to the AEB Core Function (Steps 1 to 5 according process in the paper, 6 to 8 is performed in the RM tool)
- 16. 16 Systematic Architecture and Requirements Refinement Functional Architecture, Level 1 Functional Architecture, Level 2
- 17. 17 Resulting Requirements on Sensor / ECU Level
- 18. 18 Refined Architecture and Early Function Model Behavior modeling (on abstract level) by state machine, data flows, differential equations etc. enables early simulation
- 19. 19 Connection of Early Model to Driving Simulator as FMU
- 20. 20 Early validation by MiL simulation of scenarios (e.g. NCAP CCRm)
- 21. Model-based Integrated Safety Analysis with medini analyze Transformation Integration X ! FMEA FMEA FMEDA SPF/LF Metrics FMEDA SPF/LF Metrics SysML Models HAZOP HAZOP Safety Requirements Safety Requirements Hazard Analysis & Risk Assessment Hazard Analysis & Risk Assessment Safety Case Safety Case Reliability Prediction Reliability Prediction FTA FTA
- 22. 23 Hazard Analysis for FuSa and SOTIF Safety Goals from HARA constitute additional top-level requirements. Hazards are root for Fault Tree Analysis
- 23. 24 ©2020 Ansys, Inc. / Confidential Architecture-Based Safety Analysis: Enrich Model With Malfunctions
- 24. 25 Construct Fault Tree and Derive Requirements for Improvement
- 25. 26 Improving the functional architecture with a trajectory prediction Functional Architecture: Iteration 1 Functional Architecture: Iteration 2
- 26. AFTER: AEB with trajectory prediction BEFORE: AEB without trajectory prediction MiL Simulation for Early Validation of Safety Improvement Functional Software Model At this stage, 3D closed-loop simulation with ideal sensors is used. 27
- 27. Technical Architecture - Vehicle Level Solution Definition – Allocating from functional to technical architecture Function blocks are allocated to ECUs, sensors, hardware or software components (which can technically fail) Functional Architecture
- 28. 29 Solution Definition – Comparing design alternatives in a trade study
- 29. 30 Execution plan to evaluate city/highway AEB capability
- 30. 31 DOE Results: Determining the best sensor configuration Winner in terms of weighted KPIs Make design decision, update architecture then validate.
- 31. 32 Technical Allocation: Vehicle Level and ECU Level Technical Vehicle Architecture (ECUs / Sensor Nodes and Busses) ©2020 Ansys, Inc. / Confidential 2 1 HW ECU Requirements / Assumptions + ECU Interfaces + ECU Modular Safety Artefacts ECU Architecture IF Basic SW Application SW S1 S2 S3 Component X Requirements Assumptions + Component Interfaces + Modular Safety Artefacts Component Architecture IF System Architecture Technical ECU Architecture (HW and SW Blocks, Processor and Peripherals)
- 32. Derive Requirements to cope with HW failures
- 33. Transition to SW Architecture Sync SCADE Architect with SCADE Suite 34 Lowest Architecture Level in SCADE Architect Highest Software Architecture Level in SCADE Suite Sync SCADE Suite is a certified model-to-code generator for MISRA compliant, ASIL D / DAL A certified embedded control software.
- 34. Model-based Testing and Coverage Measurement SCADE Test enables SW MIL/PIL testing • Traceability to requirements • Model coverage metrics • Back-to-back testing with function level models from early phase • Test case management and reporting
- 35. 2 3 4 5 SW HW 6 Allocation to Physical Architecture Functional Architecture Modeling MiL SiL HiL HiL MiL SiL HiL 36 The Story Continued… (Right Leg of the V-Model) ASIL D certified C code generation from models Model-based SW Unit Test w coverage Physically accurate and reduced-order sensor modeling HIL Integration test for sensors HIL Integration test with fault injection Closed-loop simulaton of traffic scenarios Managing evidences for safety case
- 36. 37 Safety-Integrated Cyclic Model-Based Workflow Requirements Safety Analysis Safety Engineer Simulation / Validation Engineer System Engineer MIL/SIL Simulation Architecture := Function Developer
- 37. 38 Take-aways • SysML architectue is the backbone for refinement, safety analysis and simulation • Requirements refinement and architecture refinement go hand in hand • Nominal functionality, FuSa and SOTIF are repeatedly evaluated as design progresses • Early identification of specification gaps through early scenario simulation • Actual embedded application software is step-by-step refined from functional model