Downloaded 57 times
Breinstorm@HUMIQ - Automotive functionalsafety
- 1. 21 oktober 2010www.humiq.nl Automotive Functional Safety M. Van der Cruijsen
- 2. Content Introduction TechniquesPractical examples 21 oktober 2010 www.humiq.nl
- 3. Domain 21 oktober2010 www.humiq.nl Infotainment Audio/video Entertainment Information, navigation Communication Chassis Stability systems Suspension, damping Steering Braking ACC Powertrain Engine Management Hybrid Propulsion Gearbox controller Powertrain Management Body Gateway Comfort systems (climate control, sunroof, access control, adjustment systems)
- 4. Domain 21 oktober2010 www.humiq.nl Safety critical Production Volume Automotive Chassis-, Driveline systems Automotive Body systems Automotive Infotainment systems Aerospace Industrial automation Consumer Electronics
- 5. What is functionalsafety? Functional safety Safe implementation of functionality that could cause injury or death to people or damage to environment in case of malfunction. Not (only) systems which product goal is safety (such as airbag). Ensuring safety in case of malfunction in the entire system (e.g. a leak, defect sensor, memory error, “bit-flips” due to EMC, etc.) 21 oktober 2010 www.humiq.nl
- 6. Example 21 oktober2010 www.humiq.nl Rear axle steering system No mechanical link to driver (“ steer-by-wire ”) Why rear-axle steering? Save fuel and less tire wear Why electro-hydraulic Packaging problems on vehicle level ECU sets angle of rear axle based on vehicle speed and front axle angle ECU
- 7. Example 21 oktober2010 www.humiq.nl Functional requirement #1 steer the rear axle based on front axle angle (manually set by driver) Safety requirement #1: Truck may not roll over, under any (abnormal) circumstance or condition, due to spontaneous or incorrect steering ECU
- 8. Example 21 oktober2010 www.humiq.nl Spontaneous steering could occur due to failures, causing a disaster + =
- 9. Why functional safety?Accident prevention Risk reduction Growing complexity But as well: Satisfaction of customers Law Reputation loss 21 oktober 2010 www.humiq.nl
- 10. 21 oktober 2010www.humiq.nl Defines what has to be done & how to prove it. IEC 61508: Functional Safety of E/E/P electronic safety-related systems. Safety Standards
- 11. Safety Standards (2)IEC 61508 highlights Consists of 7 parts. 378 required & 141 highly recommended requirements . 126 general requirements. 194 requirements on system and hardware 199 requirements on software Requirements coverage: Functional. Non-functional. Quality control at manufacturer. Consumer. Verification and Validation at manufacturer Verification and Validation by 3 rd party Informative: Abbreviations & Definitions Measures & Techniques Implementation Guidelines Safety Integrity Level 21 oktober 2010 www.humiq.nl
- 12. Safety Lifecycle Technicalframework Concept / analysis phase Development phase Hardware & Software V-Cycle After SOP Scope: Concept / analysis SW development 21 oktober 2010 www.humiq.nl
- 13. Hazard & RiskAnalysis Definitions Hazard Potential source of harm (for human and environment). Risk Combination of probability, and the severity (impact) of that harm. Risk = Probability x Impact Starting Point: Concept, e.g. premature requirement specification(s), etc. Goal: Definition of safety requirements which can be allocated to hard and/or software components. 21 oktober 2010 www.humiq.nl
- 14. Hazard & RiskAnalysis Identification of hazards. As well as the event sequences leading to them. Well known methods: FMEA (Failure Mode Effects Analysis) Fault Tree Analysis Event Tree Analysis Identification of risk for each identified hazard. What is the risk and is it tolerable? If not, risk reduction. Most commonly used: ALARP (As Low As Reasonably Practical) 21 oktober 2010 www.humiq.nl
- 15. FMEA Component orientedSystematic Focus on single failures. 21 oktober 2010 www.humiq.nl
- 16. Fault & EventTree Analysis Does take into account multiple errors . 21 oktober 2010 www.humiq.nl
- 17. Risk Analysis (ALARP)3 Regions ALARP Region Achieve justifiable residual risk. Risk Reduction Cost vs. Benefit Benefit > Cost Safety function (requirements) Tolerable when no further reduction possible, or costs are disproportionate to improvement 21 oktober 2010 www.humiq.nl Intolerable region Largely acceptable region ALARP or tolerable region Risk Negligible risk
- 18. ALARP region 21oktober 2010 www.humiq.nl
- 19. Example Scenario: Estimatedcost in case of incident: € 10.000.000,- System life span = 20 Years Estimated frequency = 6x10 -4 per year. Measure: € 160.000,- Solution: Cost = (6x10 -4 ) x 20 x 10.000.000 = € 120.000 No measure (risk reduction), cost > benefit. 21 oktober 2010 www.humiq.nl But… This is not only calculation also “common sense”
- 20. Safety Functions Afunction of a safety related system to reduce the risk in an application with the goal to achieve a safe state. For each identified hazard (Which will be implemented!) Create safety functions Which achieves and maintains a safe state for the system. Create the safety (system) requirements to accomplish the safety function . 21 oktober 2010 www.humiq.nl
- 21. Safety Integrity LevelSafety Integrity Probability of performing the required safety functions! Safety Integrity Level: Discrete level for specifying the software integrity! Determined for each safety function! Safety Integrity Levels (SIL) 1, 2, 3, 4. ASIL A, B, C, D for ISO 26262 Determination methods: Quantitative Qualitative Highest SIL level = System SIL level 21 oktober 2010 www.humiq.nl
- 22. Quantitative Example Definetolerable risk frequency For example from ALARP. Measure against risk frequency After risk reduction! 21 oktober 2010 www.humiq.nl
- 23. Safety Integrity RequirementsDepending on the system SIL Level Requirements for maintaining the SIL level Ensure the system performs the safety function with the defined probability! Partly available from standards! Measures & Techniques 21 oktober 2010 www.humiq.nl
- 24. Outcome: Safety RequirementsSystem Requirements Requirement allocation. Hardware & Software. Planning & Realization according Safety Life Cycle Safety Function & Integrity Requirements Safety functions 21 oktober 2010 www.humiq.nl
- 25. Realization According Part2 & 3 of IEC 61508 IEC 61508 requirement examples: 21 oktober 2010 www.humiq.nl
- 26. Measures & TechniquesReferenced from requirements. 21 oktober 2010 www.humiq.nl
- 27. 21 oktober 2010www.humiq.nl Measures & Techniques
- 28. IEC 61508 architecturecoverage 21 oktober 2010 www.humiq.nl
- 29. Practical Examples Sensorerror detection Emergency shutdown Software channels Software checks 3-Ebene Concept Common factor: Redundancy! Redundancy does not prevent systematic hardware & software design faults! 21 oktober 2010 www.humiq.nl
- 30. Sensor error detection(1)Redundancy with 2 sensors Sensor input comparison by software on microcontroller(s). Who is right? 21 oktober 2010 www.humiq.nl
- 31. Redundancy with 3sensors Drawbacks: High Cost Systematic Failures Sensor error detection(2) 21 oktober 2010 www.humiq.nl
- 32. Solution: Comparison toother (sensor) data! Front axle vs. rear axle angle. Crankshaft vs. camshaft speed. ABS speed vs. tacho speed. Sensor error detection(3) 21 oktober 2010 www.humiq.nl
- 33. Emergency Shutdown Pre-Condition:Static Fail-Safe State needed! If functional fail-safe controlled by SW fails! Example: Passive centering of rear axle in case of shutdown . One or multiple µC solution possible. 21 oktober 2010 www.humiq.nl
- 34. Open Loop ProtectedSingle Channel (1) Example: Read front & Rear axle sensors Check sensor data Determine rear axle valve positions Actuate valves Data integrity checks by means of redundant sensor of other data! Drawback Actuation errors not detected! 21 oktober 2010 www.humiq.nl
- 35. Closed loop protectedsingle channel(2) Extra safety by directly measuring output. E.g. Valve: PWM directly measured by ICU, and valve current by sensor and ADC. 21 oktober 2010 www.humiq.nl
- 36. Dual Closed-Loop ChannelsOn one or more µC’s. Most critical software parts. Easier to meet requirements from standards. Different designs & Implementations prevents systematic errors! 21 oktober 2010 www.humiq.nl
- 37. 3-Ebene Concept Mostcommon applied for “simple” SIL3 compliance. 21 oktober 2010 www.humiq.nl
- 38. Software & MicrocontrollerChecks Dedicated software safety framework for: Memory test CRC, Checkerboard I/O test CAN, DIO, ADC Instruction Set Test Check basic µC ALU functionality. Program Sequence Monitoring Test execution paths throughout the software. And many more… 21 oktober 2010 www.humiq.nl
- 39. Summary Base: IEC615098 Sector-application standard(s) Risk/Hazard analyses FMEA, Fault tree, Event tree Safety Integrity Level (SIL) Highest SIL level = System SIL level 21 oktober 2010 www.humiq.nl
- 40. 21 oktober 2010www.humiq.nl
Editor's Notes
- #3 Functional Safety is part of the overall safety that depends on a system or equipment operating correctly in response to it’s inputs. (per IEC 61508-0) Functional Safety is the way to evaluate and determine the risk of using complex and simple circuit to perform a safety function. The safety function must always be performed under normal/undisturbed conditions and under fault conditions (Fail Safe).
- #4 You can roughly split the automotive software domain into 4 different sub-domain. Infotainment: audio/video, naviation, communication Powertrain: engine managment, gearbox Chassis: breaking, steering, suspension applications Body: IVN gateway comort systems Infotainment is naar omvang de grootste, maar functional safety is vooral van toepassing op de andere 3 gebieden. Steeds meer verbindingen tussen de domeinen.: E-call: airbaig unit – comminicatie – navigatie.
- #5 Another way to look at this domain is characterizing prodution volume and the infuency on safety. A Car is a high volume consumer products, this means that there is similar pressure on cost-price and time-to-market as a CD-player. But some applications in a vehical have a direct impact on the safety of the passengers and the enviorment. Auto is het meest complexe consumenten product.
- #6 Functional Safety is part of the overall safety that depends on a system or equipment operating correctly in response to it’s inputs. (per IEC 61508-0) Functional Safety is the way to evaluate and determine the risk of using complex and simple circuit to perform a safety function. The safety function must always be performed under normal/undisturbed conditions and under fault conditions (Fail Safe).
- #7 The system can be described in only a few basic requirements. 1 functional requirment: The rea axle shall steer based on the front axle angle and speed. 1 safety requirement . Truck may not roll over, un any circumstance or condtion due to spontaneous or incorrect steering.
- #8 The system can be described in only a few basic requirements. 1 functional requirment: The rea axle shall steer based on the front axle angle and speed. 1 safety requirement . Truck may not roll over, un any circumstance or condtion due to spontaneous or incorrect steering.
- #9 Wrong steering actions are an immediat risk, especially for trucks transporting liquedes (like patrol). An accident with such a vehical on highway can have enourmous personal, enviormental and economical impact. Injuries of the truckdriver, leaking fluids, economical losses due to trafic jams etc.. All this can happen when a single bit is programmed wrong (e.g. positive/negative sign in a calculation).
- #10 Functional Safety is part of the overall safety that depends on a system or equipment operating correctly in response to it’s inputs. (per IEC 61508-0) Functional Safety is the way to evaluate and determine the risk of using complex and simple circuit to perform a safety function. The safety function must always be performed under normal/undisturbed conditions and under fault conditions (Fail Safe).
- #12 Part 1: General. Part 2: System & Hardware, Part 3: Software, Part 4: Definitions, Part 5: Determination of SIL Level, Part 6: Application of Part 2 & 3, Part 7: Measures & Techniques.
- #13 IEC-61508 life cycle just as reference example. - Highlight
- #15 Hazard & Risk Analysis are repeated when a requirement is changed. If needed risk can not be accepted, risk reduction needs to be done by means of safety systems, external facilities, etc.
- #16 Drawback: Focus on single failures, not combined failures.
- #18 * If risk can not be accepted, risk reduction needs to be done by means of safety systems, external facilities, etc. In the ALARP region: Risk is undertaken, only when a benefit is desired. Upper and lower ALARP regions are often chosen in probability of failure per year.
- #19 In orange: ALARP region to be analyzed!
- #20 * All depends on the needs of the customer and other related issues… This is just a guideine.
- #21 3.5.1 safety function function to be implemented by an E/E/PE safety-related system, other technology safetyrelated system or external risk reduction facilities, which is intended to achieve or maintain a safe state for the EUC, in respect of a specific hazardous event (see 3.4.1) 3.5.2 safety integrity probability of a safety-related system satisfactorily performing the required safety functions under all the stated conditions within a stated period of time
- #22 RS: SIL Level 3. SIL level 4 normally not obtained within automotive Nuclear factories etc.
- #23 Way in which a safety-related system is intended to be used, with respect to the frequency of demands made upon it, which may be either low demand mode: where the frequency of demands for operation made on a safety related system is no greater than one per year and no greater than twice the proof-test frequency. high demand or continuous mode: where the frequency of demands for operation made on a safety-related system is greater than one per year or greater than twice the proof-check frequency.
- #26 As well as for software architecture, design, etc. Also planning issues and processes. Mention referenced to tables.
- #31 If Sensor_1 = Sensor_2, no problems, little risk both are damaged. But what if Sensor_1 != Sensor_2, who is right…. 3 sensors… (Next slide)
- #38 Both micro’s with safety framework, status exchange. Dual channel on first uC, single channel on second channel Values are compared. Cyclic watchdog triggering
- #39 Self Diagnosis for each microcontroller.