System Safety Process Applied to Automotive High Voltage Propulsion Systems ISSC Tutorial Mark Vernacchia, Galen Ressler, Padma Sundaram August 2015
Tutorial Overview Objectives Safety Process Overview Safety Process Phases Safety Process Activities and Tools Applied to the Engineering Process Workshop Real Time Example Workshop Exercise Review Recap Summary Workshop Exercise Q&A Many thanks to Sheila Schultz who helped create the initial tutorial package. 2
Tutorial Objectives Understanding of What is a Safety-Critical System? Understanding of System Safety and System Safety Process Understanding of Steps followed for an Automotive System Safety Process applied to a High Voltage Propulsion system Application to Real Examples 3
What are Safety-Critical Systems? Safety-critical systems are any systems where unintended behaviors could result in a potential safety concern under certain conditions Example of Automotive Safety Critical Systems could include areas such as: Steering and Braking Propulsion Active Safety Systems 4
What is System Safety? System Safety is a disciplined and comprehensive engineering effort to identify safety related risks to be either eliminated or controlled It involves the identification of potential hazards, assessment of the risk, and mitigation of the risk to acceptable levels through design requirements Analyzes the overall effect at the vehicle level including the operator and the environment as part of the system Considers entire life cycle requirements including operation, maintenance and disposal phases where appropriate System can be comprised of software and hardware components. Each software and hardware component by itself can be safe, but interactions must also be analyzed. 5
System Safety Process Overview Modern automotive systems provide the benefits of enhanced vehicle functionality, fuel efficiency, safety, driver assistance, comfort, ride/handling, performance, and self-diagnostics Modern automotive systems include: electrical/ electronic sensors, embedded microcontrollers (processors), actuators, and communication devices Typically these systems use complex software control algorithms made of many functions Some of these systems are designed to autonomously activate independent of the user 6
ISO26262 ISO26262 - Functional Safety International Standard for Road Vehicles ISO26262 is an Adaptation of IEC 61508 (International Standard for Electrical, Electronic and Programmable Electronic Safety Related Systems) - to comply with the specific need of Electrical and Electronic systems within road vehicles. 7
System Safety Process Overview A system safety process that follows the ISO26262 standard would: Provide early input to the system design by identifying potential hazards and determining the safety strategy Specify appropriate hardware (HW), software (SW), and interface requirements Confirm system content will satisfy these requirements Validate and verify system performance to requirements Document safety review and approval content 8
System Safety Process Phases (Provided as Example) Concept Changes Concept Requirements Requirement Changes Supporting Processes Requirements Management Configuration and Change Control Management Quality Management Management of Development Tools /Reused components Safety Work products Retention Preliminary Hazard Analysis System Safety Program Planning System Safety Concept Single Element Fault Analysis Safety Concept Review Design Corrections Design Safety Functional Interface Analysis Translate Hazard Metrics into Engineering Requirements Safety Requirements Definition Safety V&V Planning Safety Requirements Review Development / Implementation Design Corrections Verification & Validation Production Observed Design Discrepancies System / Component DFMEA System Level Fault Tree Analysis Common Cause Failure Analysis Refine / Update Safety Requirements Safety V&V Plan Update System Technical Safety Concept Update Safety Design Solution Review Production / Deployment Software Fault Tree Analysis Software Detailed FMEA Software Code Reviews Closure of FTA / FMEA Issues Safety Implementation Review (Separate or Combined with Production Safety Design & Test Review) Safety Verification / Validation Component, Sub-system, System, Vehicle FTA & DFMEA Verification System Safety Report & Assessment Production Safety Design & Test Review System Safety Management 9
System Safety Process Typical Phases The system safety process has a number of formal technical safety peer reviews that are conducted at critical milestones in the vehicle development process Safety Concept Review Safety Requirements Review Safety Design Solution Review Safety Design and Test Review These formal reviews have independent review board requirements and are intended to assess the safety process execution from a technical standpoint. The formal reviews are intended to provide an independent assessment of the safety design and to confirm that the product satisfies the safety requirements 10
System Engineering V Model http://ops.fhwa.dot.gov/publications/seitsguide/section3.htm 11
System Engineering V Model with Safety Phases Concept Phase Req mt Phase V & V Phase Design Phase Development & Implementation Phase http://ops.fhwa.dot.gov/publications/seitsguide/section3.htm 12
Initial Activity - Define System Scope and Content Concept Requirements Design Development / Implementation First, identify major vehicle systems and the interfaces between these systems Verification & Validation Second, identify the safety-critical systems Third, determine scope boundary for the desired safety evaluation 13
Begin System Safety Strategy Determination Concept Requirements Hazard Analysis and Risk Assessment (HARA) Potential Hazards and Safety Goals High Level System Safety Requirements Hardware Integrity Requirements based on ASIL Design Constraints Final System State Mitigation Action Detection Method Hazard (Y/N?) Resulting State Hardware Fault Analysis (System Element Hazard Analysis) Lessons Learned from past and similar systems Design Development / Implementation Verification & Validation Functional System Safety Concept: Intended safety strategy to satisfy the safety goals and safety requirements. 14
Safety Strategy Considerations Concept Requirements Design Fail Safe or Fail Operational Relative Safe State Identification Compared to more serious hazard states Typical Safe State Identification Mitigation and/or Prevention System Redundancy Development / Implementation Verification & Validation Safe State: A system state with an acceptable risk 15
Assess Potential Hazards A hazard can be defined as any system state, event, or condition(s) that has the potential to cause physical harm to vehicle occupants and/or pedestrians Hazard Analysis and Risk Assessment (HARA) Systematically identify potential system hazards Analyze mishap potential Assess safety risk using the ISO26262 ASIL (Automotive Safety Integrity Level) methodology is one approach Determine of any Safety Goals Concept Requirements Design Development / Implementation Verification & Validation 16
Risk Workshop Assessment Tutorials Per ISO26262, Risk is expressed in terms of an Automotive Safety Integrity Level (ASIL) Concept Requirements Design Development / Implementation Verification & Validation ASIL => function of (S, E, C) S = Severity of the Hazard E = Exposure likelihood to the operating scenario C = Controllability of the operator/involved people Each of the factors have to be applied based on available data/statistics, experience and best engineering judgment ASIL specifies the developmental process rigor and the required hardware and software integrity requirements for the safety-critical system 17
Risk Workshop Assessment Tutorials Concept Requirements Design Development / Implementation Verification & Validation Hazard Occurred Risk Calculation Step 1 Risk Calculation Step 2 Risk Calculation Step 3 ASIL Determination Probability of Exposure to the Operating Scenario Severity of the Event (Potential impact on the involved people) Controllability of the operator in preventing the hazard from becoming a mishap For each identified hazard 1. Analyze the different operating scenarios: Consider normal driving conditions, maintenance/service and disposal phases 2. Identify the worst case severity potential for each identified hazard 3. Assess of operator will be able to prevent the hazard from becoming a mishap 4. Assign the ASIL 18
Driving Workshop Scenarios- Tutorials Analysis Consider: Normal Operation Degraded Operation with warning Concept Requirements Design Development / Implementation Verification & Validation Driving Situation Road/Location Type Road Conditions Other Road Characteristics Driving Manuveur Driving State Other Vehicle Characteristics High way/city road Off roads Parking lot Maintenance Garage Surface friction Slope Road width (US vs. Europe) Side wind Oncoming traffic Traffic jam Construction zone Accident scenario Starting Turning (forward-reverse) Going straight (forward reverse) Parking Getting off Coasting Stopped Accelerate Braking Parked Collision State of other systems Ignition off/on Heavily laden Maintenance Driver capability 19
Perform Workshop a Tutorials Hazard Analysis Determine ASIL Concept Requirements Design For each identified hazardous scenario, evaluate Development / Implementation Verification & Validation S0 S1 S2 S3 No injuries Light and moderate injuries Severe and lifethreatening injuries (survival probable) Life-threatening injuries (survival uncertain), fatal injuries E0 E1 E2 E3 E4 Incredible Very low probability Low probability Medium probability High probability C0 C1 C2 C3 Controllable in general Simply controllable Normally controllable Difficult to control or uncontrollable Source ISO 26262 20
Severity Exposure Severity, Exposure, Controllability to Select ASIL Risk Matrix with ASIL (based on ISO 26262) S1 S2 S3 Controllability C1 C2 C3 E1 QM QM QM E2 QM QM QM E3 QM QM ASIL A E4 QM ASIL A ASIL B E1 QM QM QM E2 QM QM ASIL A E3 QM ASIL A ASIL B E4 ASIL A ASIL B ASIL C E1 QM QM ASIL A E2 QM ASIL A ASIL B E3 ASIL A ASIL B ASIL C E4 ASIL B ASIL C ASIL D Concept Requirements Design Development / Implementation Verification & Validation QM = Quality Managed Source ISO 26262 21
Define Required Design Rigor and Integrity Concept Requirements The ASIL rating drives process rigor and design integrity Higher ASIL level equates to higher/more diagnostic capability Design Development / Implementation Verification & Validation Determine the diagnostic content needed to detect memory corruption or hardware failure to meet the requirements specified by the ASIL rating Detect system faults and take required remedial action to transition to a safe state where the hazardous condition is eliminated Examples of remedial actions include reduced performance or propulsion shut down Develop a diagnostic strategy and implement diagnostic content which will detect and mitigate as required Once integrity requirements are determined, system level interface analysis tasks may be started 22
Perform System Level Interface Analysis Concept Requirements Design Create a system Control Structure (Block Diagram) Identify functional requirements for each entity Determine information required between entities Identify system functional behavior and its interactions with other systems in the vehicle Define functional interactions among system entities Different subsystems Different control modules within the system Sensors outputs System actuator behaviors Development / Implementation Verification & Validation 23
Perform System Element Hazard Analysis Concept Requirements System level fault analysis of the subsystems, controllers and modules can support identification of critical components of the system Determine how system will behave when different portions of the system fail under different operating scenarios Performed at a high level (system vs. component) Fail one entity at a time and determine effect on system Determine how system will behave under different operating scenarios Engine provided vs. electric machine provided propulsion modes Park vs. Reverse vs. Neutral vs. Drive Define safety hazards that may appear when fault(s) occur Outline the initial diagnostic and mitigation strategies Define the resulting safe system state Identify the need for additional sensors, diagnostic SW, or required changes to system safety strategy so that critical component faults do not lead to potential safety hazards Design Development / Implementation Verification & Validation 24
Perform Hazard Operability Analysis(HAZOP) Define Unsafe Control Actions (UCA) by using guidewords such as: Not Provided Provided but Incorrect Too Early, Too Late Frozen/Stuck Concept Requirements Design Development / Implementation Verification & Validation Develop potential causes for each UCA Define design constraints (requirements) to prevent and/or minimize potential causes Multiple system engineering based processes may be utilized for this step. MIT s STPA is an example of such a process. 25
System Engineering V Model with Safety Phases Req mt Phase http://ops.fhwa.dot.gov/publications/seitsguide/section3.htm 26
ISO26262 Standard ISO26262 provides information regarding Hardware and Software development efforts Concept Requirements Design Development / Implementation Verification & Validation Hardware Controller Architecture Memory Diagnostic Strategies Software Redundancy Options Software Mechanisms for Error Detection Mechanisms for Error Handling 27
Controller Architecture Concept Requirements Safety requirement may drive the use of redundant processor architecture to ensure that certain faults do not lead to a hazard Design Development / Implementation Verification & Validation Delayed Dual Core Lock-Step Processor Architecture Two physical cores that act as one logical core (not seen by software and does not provide additional throughput) where the outputs (calculations) of both of these cores is compared against each other to detect single point failures The delay of one of the cores allows the comparison hardware to detect errors caused by external sources such as Power Supply Noise and Ionizing Radiation Leverage the diagnostic capabilities of this architecture to shift from software diagnostic to hardware diagnostic capability which reduces code development and testing 28
Memory Diagnostic Strategies RAM, ROM, flash, cache, stack, and Registers Detect and correct erroneous memory errors ECC: Error-Correcting Code protection Single bit errors are detected and corrected Most multi-bit errors are detected CRC Cyclic Redundancy Check protection - checksum Concept Requirements Single bit error within a Design Development / memory array Implementation Verification & Validation Parity check Parity bit bit encoding of there being an even or odd number of bits set to 1 Detects single bit errors Dual store Redundant storage of safety critical variables Register Configuration Check End-to-End (E2E) ECC - Reduces number of circuits w/o ECC protection Increased detectability and robustness from processor faults Protect the address lines to memory Integrate ECC encoders and decoders into the CPU cores 29
Software Redundancy Options Rationalize Outputs with Forward Redundancy Concept Requirements Design Development / Implementation Inputs: X Primary Control (Y=HX) Outputs: Y Verification & Validation Redundant Safety Inputs: X (Y =HX ) Outputs: Y Y==Y Error Maturing Filter Fault Rationalize Inputs with Backwards (Inverse) Redundancy Inputs: X Primary Control (Y=HX) Outputs: Y Fault Maturing Filter Error X X Inputs: X Redundant Safety (X =H -1 Y ) Outputs: Y 30
Latent Workshop Faults Tutorials Require Special Care Latent Failures are benign faults until another fault occurs Identified and managed through rigorous engineering process so they are detected and managed appropriately Concept Requirements Design Development / Implementation Verification & Validation 31
Allocate Safety Requirements to Engineering and Sourcing Documents Determine which engineering groups need to know about these requirements Concept Requirements Design Development / Implementation Verification & Validation Communicate the requirements to these groups Confirm requirements have been accommodated in external sourcing documents and internal engineering specifications 32
Requirement Summary and Allocation Concept Requirements Design Control Structure HAZOP Analysis System level Fault Analysis HARA Feedback System Level Interface Analysis Regulatory Requirements Safety Concept Document System Safety Requirements Development / Implementation Verification & Validation Hardware Integrity Requirements Other Documents.. Functional Subsystem Physical Subsystem High voltage Contactors Diagnostics Man con Software Components Housing Cells Electrical Electronics Module Physical Components - 33
System Engrg V Model with Safety Phases Design Phase http://ops.fhwa.dot.gov/publications/seitsguide/section3.htm 34
System Design and Analysis Tasks Concept Requirements Design Development / Implementation Verification & Validation DFMEAs (Design Failure Modes and Effects Analysis) SW Safety Analysis (HAZOP SAE ARP-5580) FTA (Fault Tree Analysis) CCA (Common Cause Analysis) identify of potential common cause failures 35
Produce 1 st Pre-Prototype Unit and Initial SW Early controller Electronic Controller hardware (Advanced technical work or early program work) Controller designed to requirements developed in Requirements phase Initial Safety Testing, Safe Usage, and Education Have potential hazards identified Install any required Mitigation Mechanism(s). Test the mitigation mechanism to ensure it operates as expected. Until mature well tested SW is available, limiting driver usage and locations may be an appropriate action Driver education regarding expected vehicle performance is helpful Concept Requirements Design Development / Implementation Verification & Validation 36
Produce 1 st Prototype Unit and Initial SW Concept Requirements Confirm Hazard Metric(s) Simulate potential system hazardous states in early development vehicle and verify that the fault response times and the remedial actions designed in the system are acceptable to mitigate the hazard Design Development / Implementation Verification & Validation Depending on the fidelity of the early hardware, this may need to be performed when higher fidelity hardware becomes available 37
System Engineering V Model with Safety Phases Development & Implementation Phase http://ops.fhwa.dot.gov/publications/seitsguide/section3.htm 38
Produce 1 st Prototype HW Unit and Beta SW Beta level controller hardware (more refined hardware) in a further refined development vehicle Mule vehicle Controller may have been updated to comprehend further developed requirements learned through the early hardware phase Simulate potential system hazardous states in design intent vehicle and verify that the fault response times and the remedial actions designed in the system are acceptable to mitigate the hazard Concept Requirements Design Development / Implementation Verification & Validation 39
Test 1 st Production Intent HW Unit and SW Concept Requirements Design Verify performance, correlation, and torque safety diagnostics are implemented properly Development / Implementation Verification & Validation System control content should be mature enough to allow the system to execute planned remedial actions Perform testing that exercises the interfaces between the vehicle s safety critical systems 40
System Engrg V Model with Safety Phases V & V Phase http://ops.fhwa.dot.gov/publications/seitsguide/section3.htm 41
Perform Final Vehicle Safety Validation Testing Concept Requirements Design Production Level Testing Development / Implementation Verification & Validation Final Bench and Vehicle Testing Execute/Complete testing to confirm system meets Safety Requirements Confirm no deficiencies in system safety / diagnostics Avoid False Fails Robustness 42
Document Safety Validation Results Concept Requirements Design Development / Implementation Complete execution of testing to verify and validate safety requirements Verification & Validation Document testing results in a Validation Report Trace validation testing completion to requirements 43
Document Safety Validation Results Concept Requirements PHA Safety Concept Safety Goals Achieved Design Development / Implementation Verification & Validation System Safety Requirements System Validation Functional Subsystem Physical Subsystem Functional Subsystem Verification Physical Subsystem Verification High voltage Contactors Diagnostics Man con Software Components Housing Cells Electrical Electronics Module Physical Components High voltage Contactors Diagnostics Man Software con Verification Housing Cells Electrical Electronics Module Component Verification 2011-01-1369 44
Create Safety Case Concept Requirements A Safety Case is a document that provides convincing and valid argument that the system is acceptably safe for a given application in a given environment. System safety steps conducted progressively (system safety process steps) Safety Case addresses: Does system satisfy technical system safety requirements? Are standard processes carried out? Are the System Safety Engineering Process steps carried out correctly? Are all identified system safety related issues over the course of product development addressed and resolved? Stored and retained according to document retention policies Design Development / Implementation Verification & Validation 45
Questions Before We Take a Break??? 46
And..... Let s Take a Break 47
Welcome Back..... Let s apply what we discussed to a working example.... 48
System Content Example Illustration 49
System Content Safety Critical Areas 12V Battery Engine Accelerator Pedal Assembly Engine Control Module Motor Control Module Electric Machines HV Battery Power Inverter Module 50
System Content Power and Communication Communication Path 12V Battery Engine Accelerator Pedal Assembly 12V Power 12V Power Communication Path Engine Control Module 12V Power HV DC Power Communication Path Motor Control Module OUTPUT TORQUE Communication Path Electric Machines HV Battery HV DC Power Power Inverter Module HV AC Power 51
Workshop Example Possible Answers Assess Potential Hazards HV Hazards Vehicle Motion Hazards Different Operation Scenarios xxx xxx 52
Workshop Example Possible Answers Assess Potential Hazards HV Hazards Shock Burn Heat Vehicle Motion Hazards Acceleration Deceleration Direction Different Operating Scenarios Driving Charging Service Crash Towing 53
Workshop Example Possible Answers Rating Potential Hazards (High, Medium, or Low) HV Hazards Shock Burn Heat Vehicle Motion Hazards Acceleration Deceleration Direction Result of Severity, Exposure, and Controllability High => ASIL??? Medium =>ASIL??? Low => ASIL??? 54
Example ASIL Determination Hazard Operating Scenario Severity Controllability Exposure ASIL Driving S3 C3 E4 D Shock Crash S3 C3 E2 B Service S3 C2 E3 B S0 S1 S2 S3 No injuries Light and moderate injuries Severe and lifethreatening injuries (survival probable) Life-threatening injuries (survival uncertain), fatal injuries E0 E1 E2 E3 E4 Incredible Very low probability Low probability Medium probability High probability C0 C1 C2 C3 Controllable in general Simply controllable Normally controllable Difficult to control or uncontrollable 55
Workshop Example Possible Answers Rating Potential Hazards (High, Medium, or Low) HV Hazards Shock - High Burn - Medium Heat - High Vehicle Motion Hazards Acceleration - High Deceleration - Medium Direction - Medium Result of Severity, Exposure, and Controllability (S, E, C) High => ASIL C and D Medium =>ASIL B Low => ASIL A 56
Workshop Example Possible Answers Diagnostic Integrity Requirements ** HV and Motion Hazards Single Point Dual Point Safety Metric Shock - High High High HV Metric Burn - Medium High Medium Burn Metric Heat - High High High Thermal Metric Acceleration - High High High Accel Metric Deceleration - Medium High Medium Decel Metric Direction - Medium High Medium Direction Metric ** Consult ISO-26262 Part 5 for Diagnostic Integrity Details 57
Safety Strategy Fail Safe or Fail Operational Fail Safe HV and Propulsion Fail Operational Steering and Brakes Relative Safe State Identification Remedial actions that lead to a lower ASIL state should only be used as a safe state alternative to more severe safety hazards Loss of Propulsion (Low) versus Unintended Acceleration (High) Typical Safe State Identification Secured vehicle (immobile) Reduced performance Mitigation and/or Prevention Design Options to Eliminate Potential Issues Mitigation Tactics that Achieve Safe States System Redundancy Alternate Batteries Reduced Propulsion Modes 58
System Workshop Control Tutorials Structure Environmental Feedback Factors Accelerator Pedal Assembly Vehicle Motion Desire Accel Pedal Sensor Input Power Coordination Communication Engine Control Module DRIVER Engine Feedback Engine Power Commands Electric Motor Resolver Input Visceral Vehicle Motion Feedback IC Engine IC Engine Torque to Driveline Motor Control Module 3F Motor Currents Electric Machines Electric Torque to Driveline Vehicle Motion Electric Motor Fdbk Back EMF Energy HV Insulation and Isolation Electric Machine and Inverter Feedback Electric Power Commands Power Inverter Module HV Supply Voltage Recharge Voltage HV Battery HV Insulation and Isolation 59
Workshop High Level Tutorials Example System Possible Element Answers Hazard Analysis Fault Analysis Results HV / Motion Hazards Detection Mitigation Shock - High Burn - Medium Heat - High Acceleration - High Deceleration - Medium Direction - Medium 60
Workshop High Level Tutorials System Element Hazard Analysis "0" = Not Operating 0 0 Primary Fault Resulting Fault "1" = Operating Normally Accelerator Pedal Assembly 12V Battery Power Engine Control Module IC Engine Motor Control Module Electric Machine Electric Motor Resolver Power Inverter Battery Disconnect HV Battery HV Insulation CAN Resulting State Safety Hazard Present? Normal Operation 1 1 1 1 1 1 1 1 1 1 1 1 System Working Properly No Accelerator Pedal Assembly 0 1 1 1 1 1 1 1 1 1 1 1 Accel Pedal Assembly Fails Unsecured accel request possble Drive Intent Not Known HIGH Unintended Longitudinal Motion 12V Battery Power 1 0 0 0 0 1 1 0 1 1 1 0 All controllers fail <OFF> LOW Loss of Propulsion Engine Control Module 1 1 0 0 1 1 1 1 1 1 1 1 ECM Fails <OFF> IC Engine Shutdown LOW Loss of Propulsion IC Engine 1 1 1 0 1 1 1 1 1 1 1 1 IC Engine Shutdown LOW Loss of Propulsion Motor Control Module 1 1 1 1 0 0 0 1 1 1 1 1 MCM Fails <OFF> Electric Motor Shutdown LOW Loss of Propulsion Electric Machine 1 1 1 1 1 0 1 1 1 1 1 1 Electric Motor Shutdown LOW Loss of Propulsion 61
Workshop High Level Tutorials System Element Hazard Analysis "0" = Not Operating 0 0 Primary Fault Resulting Fault "1" = Operating Normally Resulting State Safety Hazard Present? How Detected? Mitigation Strategy Final Vehicle State Normal Operation System Working Properly No NA NA Normal Operation Accelerator Pedal Assembly Accel Pedal Assembly Fails Unsecured accel request possble Drive Intent Not Known HIGH ECM diagnostics of Accel Unintended Pedal sensor Longitudinal Motion ECM commands IC Engine shutdown and vehicle transitions to EV mode Driver warning provided EV mode 12V Battery Power All controllers fail <OFF> LOW Loss of Propulsion Not Able to Detect by Diagnostics No Mitigation Strategy Possible Vehicle Propulsion Shuts Down Propulsion Shutdown Engine Control Module ECM Fails <OFF> IC Engine Shutdown LOW Loss of Propulsion Other Controllers detect ECM faliure thru CAN diagnostics Vehicle transitions to EV mode Driver warning provided EV mode IC Engine IC Engine Shutdown LOW Loss of Propulsion ECM diagnostics of Engine sensors Vehicle transitions to EV mode Driver warning provided EV mode Motor Control Module MCM Fails <OFF> Electric Motor Shutdown LOW Loss of Propulsion Other Controllers detect MCM faliure thru CAN diagnostics Vehicle transitions to IC Engine mode Driver warning provided IC Engine Mode Electric Machine Electric Motor Shutdown LOW Loss of Propulsion MCM readings of Resolver sensors Vehicle transitions to IC Engine mode Driver warning provided IC Engine Mode 62
Workshop High Level Tutorials Example System Possible Element Answers Hazard Analysis Fault Analysis Results HV / Motion Hazards Detection Mitigation Shock - High Burn - Medium Heat - High Acceleration - High Deceleration - Medium Direction - Medium 63
Workshop Example Possible Answers Fault Analysis Results HV / Motion Hazards Detection Mitigation Shock - High Voltage Sensors (Isolation) Burn - Medium None Heat - High Acceleration - High Deceleration - Medium Direction - Medium Temp Sensors Vehicle Speed, Clutch Speeds, Current Sensors, Torque Command Monitors Vehicle Speed, Clutch Speeds, Current Sensors Directional Speed Sensors, Torque Command Monitors 64
Workshop Example Possible Answers Fault Analysis Results HV / Motion Hazards Detection Mitigation Shock - High Current Sensors Insulation, Physical Barriers, Protective Covers, Cable Routing, Driver Notification, Disconnect HV Battery Burn - Medium None Prevention used to eliminate hot spots in design: Thermal Insulation / Isolation; Heat capacity of devices Heat - High Temp Sensors Heat Shields, Protective Covers Disconnect HV Battery Acceleration - High Deceleration - Medium Direction - Medium Vehicle Speed, Clutch Speeds, Current Sensors, Torque Command Monitors Vehicle Speed, Clutch Speeds, Current Sensors Directional Speed Sensors, Torque Command Monitors Disconnect HV Battery, Shutdown Motor Controller, Depower Motors Open Clutches, Shutdown Motor Controller, Depower Motors Override Torque Command, Open Clutches, Shutdown Motor Controller, Depower Motors 65
Workshop Example Possible Answers Fault Analysis Results HV / Motion Hazards Detection Mitigation Shock - High Current Sensors Insulation, Physical Barriers, Protective Covers, Cable Routing, Driver Notification, Disconnect HV Battery Burn - Medium None Prevention used to eliminate hot spots in design: Thermal Insulation / Isolation; Heat capacity of devices Heat - High Temp Sensors Heat Shields, Protective Covers Disconnect HV Battery Acceleration - High Deceleration - Medium Direction - Medium Vehicle Speed, Clutch Speeds, Current Sensors, Torque Command Monitors Vehicle Speed, Clutch Speeds, Current Sensors Directional Speed Sensors, Torque Command Monitors Disconnect HV Battery, Shutdown Motor Controller, Depower Motors Open Clutches, Shutdown Motor Controller, Depower Motors Override Torque Command, Open Clutches, Shutdown Motor Controller, Depower Motors 66
System Workshop Control Tutorials Structure Environmental Feedback Factors Accelerator Pedal Assembly Vehicle Motion Desire Accel Pedal Sensor Input Power Coordination Communication Engine Control Module DRIVER Engine Feedback Engine Power Commands Electric Motor Resolver Input Visceral Vehicle Motion Feedback IC Engine IC Engine Torque to Driveline Motor Control Module 3F Motor Currents Electric Machines Electric Torque to Driveline Vehicle Motion Electric Motor Fdbk Back EMF Energy HV Insulation and Isolation Electric Machine and Inverter Feedback Electric Power Commands Power Inverter Module HV Supply Voltage Recharge Voltage HV Battery HV Insulation and Isolation 67
System Workshop Control Tutorials Structure Environmental Feedback Factors Accelerator Pedal Assembly Vehicle Motion Desire Accel Pedal Sensor Input Power Coordination Communication Engine Control Module DRIVER Engine Feedback Engine Power Commands Electric Motor Resolver Input Visceral Vehicle Motion Feedback IC Engine IC Engine Torque to Driveline Motor Control Module 3F Motor Currents Electric Machines Electric Torque to Driveline Vehicle Motion Electric Motor Fdbk Back EMF Energy HV Insulation and Isolation Electric Machine and Inverter Feedback Electric Power Commands Power Inverter Module HV Supply Voltage Recharge Voltage HV Battery HV Insulation and Isolation ADDED Battery Disconnect 68
Define System Requirements HV Requirements May Apply to Components Electrical Isolation Cable Routing Clearances and Radii Protective Covers Finger Proof Connectors Heat Shields Battery Voltage/Current Sensors Propulsion Requirements May Apply to Components Electric Machine Speed Sensors Electric Machine Current Sensors Vehicle Speed Sensors Controller Microprocessor Architecture 69
Identify and Inform Groups Needing System Requirements Functional Group Requirements Propulsion Systems Chassis Systems Power Inverters High Voltage Systems Wire Harnesses Sensors and Actuators Software 70
Identify and Inform Groups Needing System Requirements Functional Group Propulsion Systems Chassis Systems Power Inverters High Voltage Systems Wire Harnesses Sensors and Actuators Software Requirements Output Shaft Speed Sensors, SW monitors Electrical isolation Protective covers Finger proof connectors, electrical isolation, HV Battery Disconnect Cable routing clearances and bend radii Sensing rates, resolution, response times Safety requirements integrity level (ASIL) Safety strategy and mitigation actions 71
Actual System Hardware and Software Design Activities Performance, Cost, Quality Trade-offs Component Packaging Design Reviews Budget Reviews DFMEAs, AFMEAs Simulation and Analysis Supplier Interactions Build 1 st Prototype Unit 72
Test and Validate Prototype Hardware and Software Test components to verify requirements met Hardware component tests Environmental Electrical Mechanical Software component tests Test subsystems and verify mitigation mechanisms Electronic device bench testing Test vehicles and verify mitigation mechanisms Define users and access Perform initial development testing Update system design content as required 73
Test and Validate Production Hardware and Software Test component changes to verify requirements met Hardware component tests (as required) Environmental Electrical Mechanical Software component tests (as required) Test subsystems and verify mitigation mechanisms Electronic device bench testing Test and validate safety diagnostics Evaluate mitigation action performance Test vehicles and verify mitigation mechanisms Update users and access Continue development testing Update system design content as required 74
Workshop Perform Tutorials Final Vehicle Safety Testing Verification confirms that work products properly reflect the requirements specified for them ( you built it right ) Methods used for Verification are: Analysis (e.g. FTA, FMEA), Demonstration, Inspection and Testing Validation confirms that the product fulfills its intended use in all of the environments that the product will be used in ( you built the right thing ) During Safety validation, e.g. hazard testing is performed to confirm that the hazard metrics are satisfied Complete Vehicle Level Safety Conformance Evaluation Reproduction or Reuse of this Material is Prohibited without Express Permission 75 from GM 75
Document Safety Validation Results Traceability to Requirements Source of Requirement HW and SW Content Technical Specifications V&V Test Procedures Objective Evidence Safety Reviews V&V Test Result Summaries Final Safety Assessment Approvals Documentation Archive and Retention 76
Workshop Tutorial Tutorials Summary System Safety is a disciplined and comprehensive engineering effort to identify safety related risks to be either eliminated or controlled System Safety assessments early in the process are essential A robust safety process is key and management support to employ and enforce it is critical Clear, well defined requirements are necessary Validation and verification are critical for success 77
Questions and Answer Period 78
Thank You 79
Backup 80
Risk = function of (S, E, C) = (Severity, Exposure, Controllability) Definition for Hazard Severity Hazard Severity Title Description S0* Low No injuries S1 Moderate Light or moderate non life-threatening injuries to the driver or passengers or people around the vehicle S2 Serious Severe and life-threatening (Survival possible) to the driver or passengers or people around the vehicle or in other surrounding vehicles S3 Severe Life-threatening injuries (Survival uncertain, fatal injuries) to the driver or passengers or people around the vehicle or in other surrounding vehicles Note: *No ASIL is assigned for S0 In evaluating the severity component of risk for a hazard, always work with the WORST CREDIBLE consequence. Source ISO 26262 81
Risk = function of (S, E, C) = (Severity, Exposure, Controllability) Definition for Likelihood of Exposure to Vehicle Operating Scenarios Exposure Title Definition E0* Incredible Situations that are extremely unusual. E1 Rare Very low probability. Situations that occur less often than once a year for the great majority of drivers E2 Sometimes Low probability. Situations that occur a few times a year for the great majority of drivers. < 1% of average operating time E3 Quite often Medium probability. Situations that occur once a month or more often for an average driver. 1% - 10% of average operating time. E4 Often-Always High probability. All situations that occur during almost every drive on average. > 10% of average operating time Note: *No ASIL is assigned for E0 Source ISO 26262 82
Risk = function of (S, E, C) = (Severity, Exposure, Controllability) Definition for Controllability Vehicle Controllability Title Definition C0* Controllable in general Generally Controllable by all drivers; C1 C2 C3 Simply Controllable Normally Controllable Difficult to Control Less than 1% of average drivers or other traffic participants are usually unable to control the damage. In this kind of a hazard scenario, it is likely that the vehicle will be controllable by most drivers. Again controllable is used in the sense that most drivers will be able to prevent a mishap by applying corrective counter steering/ or corrective braking. Less than 10% of average drivers or other traffic participants are usually unable to control the damage. In this kind of a hazard scenario, it is possible that the vehicle will be controllable by some drivers. Again controllable is used in the sense that some drivers will be able to prevent a mishap by applying corrective counter steering/ or corrective braking.. The average driver or other traffic participant is usually unable, or barely able, to control the damage. In this kind of a hazard scenario, it is unlikely that the vehicle will be controllable by average driver. Again uncontrollable is used in the sense that the average driver will be unable to prevent a mishap by applying corrective counter steering/ or corrective braking Note: *No ASIL is assigned for C0 Source ISO 26262 83