ISO meets AUTOSAR - First Lessons Learned Dr. Günther Heling

Transcription

1 ISO meets AUTOSAR - First Lessons Learned Dr. Günther Heling

2 Agenda 1. ISO and AUTOSAR Two Basic Contradictions Top-Down vs. Reuse Concentration vs. Distribution 2. Approach Mixed ASIL System 3. Lessons learned from Projects Slide: 2

3 Agenda 1. ISO and AUTOSAR Two Basic Contradictions Top-Down vs. Reuse Concentration vs. Distribution 2. Approach Mixed ASIL System 3. Lessons learned from Projects Slide: 3

4 ISO meets AUTOSAR 1 st Contradiction Top-down vs. Reuse ISO Guidelines to ensure safety Project related top-down approach AUTOSAR Standards to support SW reuse Reuse & configuration of building blocks Slide: 4

5 1 st Contradiction Top-down vs. Reuse Safety Elements out of Context (SEooC) acc. ISO solve the contradiction Vehicle Project SEooC Hazard analysis & risk assessment ASIL assignment Concrete use case is unknown! Safety concept Safety requirements Validate Safety Manual Assumptions on ASIL and safety requirements Development acc. ISO Process Development acc. ISO Process Integration Safety Case Consider Safety Case code partly generated! Slide: 5

6 2 nd Contradiction Concentration vs. Distribution Security! Safety! Safety! Connectivity Driver Assistance Electrification Distribution of functionality many components involved well supported by AUTOSAR but high effort acc. ISO single safety requirement enforces development acc. ISO process Slide: 6

7 2 nd Contradiction Concentration vs. Distribution Functional Safety Concept should be based on few networks and ECUs only 1. Link safety sensors to a safety ECUs instead of the nearest ECU 2. Avoid small portions of safety related software on one ECU 3. Link safety related actuators to a safety ECU (not efficient: one safety tell-tale in an Instrument Cluster) That might lead to extra costs in cabling and/or busload A system design tool like PREEvision can support to find the optimal solution Slide: 7

8 System and Component Design with PREEvision Lane Departure Warning ASIL Qualification ASIL Function Sensor ECU ECU with ASIL mismatch Slide: 8

9 Agenda 1. ISO and AUTOSAR Two Basic Contradictions Top-Down vs. Reuse Concentration vs. Distribution 2. Approach Mixed ASIL System 3. Lessons learned from Projects Slide: 9

10 Development of Mixed ASIL Software acc. ISO Options: a) ASIL Lift-up QM ASIL b) Coexistence Modules of different ASIL exist in one ECU 1. Develop software components according their individual ASIL 2. Ensure Freedom from Interference between software components with different ASIL provide a Safe Environment for safety modules Slide: 10

11 Safe Environment enabling Coexistence higher ASIL SWC1 Safe Environment COM Application specific algorithms Basic functions RTE SWCn CANDRV your job our job depending on your requirements Providing a Safe Environment Watchdog E2E Protection MPU handling RAM/ROM Test Silence Check Core Test Threat: Propagation of failures a. across defined interfaces b. across undefined interfaces cannot cover all HW failures ASIL compliant HW needed (ECC, Lockstep for higher ASIL) QM (or lower ASIL) SW HW Slide: 11

12 Agenda 1. ISO and AUTOSAR Two Basic Contradictions Top-Down vs. Reuse Concentration vs. Distribution 2. Approach Mixed ASIL System 3. Lessons learned from Projects Memory Protection Timing Protection Communication Protection Slide: 12

13 Base of Experience and General Lessons Learned MICROSAR Safe used in >150 projects SafeContext SafeWatchdog SafeCom SafeRTE SilentBSW SafeBSW 80% ASIL-A/B 20% ASIL-C/D Broad range of concepts different ECU types different Tier1s 1. Safety is not an Add-on Big impact on architecture Legacy solutions sometimes hinder Consider Functional and Technical Safety Concept very early! Slide: 13

14 Applying Memory Partitioning (MPU) - General Precondition: Controller with MPU + OS SC3 or SC4 Context switches have big impact on runtime overhead ball park figures: SC1: 100% SC3: 180% Safe SC3: 200% Capability of MPUs is different between different Controllers e.g. number of memory regions per partition, software extension possible but costs runtime Define partitions and mapping of runnables early and carefully Have a close look at C performance MemMap has to be maintained for all components Including MCAL and CDDs Check MPU configuration during startup To ensure that the defined configuration is active Access control to HW register partly need special algorithms Registers not accessible in some modes Slide: 14

15 Applying Memory Partitioning (MPU) - Communication Assumption: Communication BSW does not comply with highest ASIL For intra ECU communication context switches should be avoided Try to use sender/receiver communication For inter ECU communication number of context switches should be minimized Collect data in a proxy data space if delay is acceptable Alternatives: SilentBSW or SafeBSW avoid context switches Slide: 15

16 Applying Watchdog First thing to decide: internal or external watchdog Watchdog handling has quite an effect on runtime Define and implement checkpoints early Activate the watchdog early in the project Start and stop of the system need special attention > e.g. blocking of interrupts can be critical > e.g. early shutdown of OS can be critical Design and test stop/shutdown early Don t set watchdog too sensitive Handling of window watchdog needs special consideration Fast reaction on window-open trigger needed Slide: 16

17 Applying E2E Protection Synchronization of application to communication is hard to realize Make sure the receiver is tolerant regarding single inconsistencies of the message counter If tolerance is not acceptable: System design based on ECU wide synchronization with communication is needed Slide: 17

18 Lessons Learned ISO and AUTOSAR go together well when considering safety very early 1 Safety Elements out of Context support reuse 2 Concentration of safety related elements reduces effort 3 Coexistence concept supports Mixed ASIL systems 4 Take benefit from experiences made Slide: 18

19 Thank you for your attention! Dr. Günther Heling