Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MISRA Safety Case Guidelines -

3,652 views

Published on

Published in: Automotive
  • Be the first to comment

MISRA Safety Case Guidelines -

  1. 1. MISRA Safety Case Guidelines Why we are writing these guidelines..... Helen Monkhouse Global Product Safety Manager, Protean Electric Ltd. MISRA Steering Committee Member
  2. 2. Agenda Introduction to MISRA Safety Cases - What is it? - What constitutes a good one? MISRA Safety Case Guidelines February 17, 20142
  3. 3. Introduction to MISRA February 17, 20143 The original MISRA project started in 1990. That project was part of the UK Government‟s “SafeIT” programme, but is now self supporting. The MISRA Safety Case Working Group began its work in 2011 The Safety Case Working Group partners are:
  4. 4. Introduction to MISRA MISRA aims to  Promote best practice in automotive safety-related systems engineering  Develop guidance in specific technical areas e.g. • C language • Software readiness for production • Safety analysis MISRA does not  Run certification schemes  Promote or endorse specific products February 17, 20144
  5. 5. The Safety Case Argument February 17, 20145 A safety case should communicate a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a particular context. Tim Kelly, University of York “clear, comprehensive and defensible” “complete and satisfied” - Calls for an explicit safety argument: o An argument without evidence is unfounded o Evidence without an argument is unexplained A safety case should communicate a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a particular context. Tim Kelly, University of York Argument that the safety requirements for an Item are complete and satisfied by evidence complied from work products of the safety activities during development. ISO 26262:2011 Argument that the safety requirements for an Item are complete and satisfied by evidence complied from work products of the safety activities during development. ISO 26262:2011
  6. 6. ISO 26262 Requirements ISO 26262 Part 2 clause 6.4.6 includes the following safety case related requirements: - This requirement shall be complied with for items that have at least one safety goal with an ASIL (A), B, C or D: a safety case shall be developed in accordance with the safety plan. - The safety case should progressively compile the work products that are generated during the safety lifecycle. February 17, 20146 Does our compilation of ISO 26262 work products lead to an explicit safety case argument?
  7. 7. The ISO 26262 Safety Case Argument February 17, 20147 Hazard Analysis & Risk Assessment all hazards have been identified Safety Goals Functional Safety Concept Technical Safety Concept Integration Testing Reports The system is safe because...... defined safety goals mitigate all hazardous events the functional safety req‟t deliver the safety goals the technical safety req‟t deliver the safety concept The safety req‟t implementation is verified ISO 26262 work products This is the safety argument that is implicit within ISO 26262 Asking “but why” at each stage identifies the explicit safety argument
  8. 8. An Example Explicit Safety Argument February 17, 20148 Accelerator Pedal Driver Controller High Voltage Battery Electric Machine Transmission Vehicle Wheel Vehicle Wheel Item Boundary CAN Communication Low Voltage Electrical Power High Voltage Electrical Power Mechanical Force / Torque / Power High Voltage Power Inverter
  9. 9. ISO 26262 Work Products February 17, 20149 Hazard Analysis & Risk Assessment Safety Goals Technical Safety Concept Integration Testing Reports Hazardous Event: Unintended vehicle acceleration during a low speed manoeuvre amongst pedestrians Exposure E3 Severity S2 ASIL B Controllability C3 Safety Goal: Vehicle positive longitudinal acceleration shall not exceed driver demand by > 1.5 m/s2 for longer than 1 s Functional Safety Concept: Functional safety requirements relating to the detection of faults Functional safety requirements relating to fault mitigation Verification Report Functional Safety Concept Why by meeting this safety goal is unreasonable risk avoided?
  10. 10. Why is the Safety Goal Right? February 17, 201410 Safety Goal: Vehicle positive longitudinal acceleration shall not exceed driver demand by > 1.5 m/s2 for longer than 1 s Residual Risk Classification The residual risk associated with the hazardous event given the effect the safety goal has on vehicle behaviour would be classified QM QM Classification The level of risk associated with any hazardous event rated QM is considered to be „acceptable‟ J Residual Risk ‘Controllability’ Classification The effect on controllability of achieving safety goal #1 Reaction ‘C0 Controllable’ „C0‟ vehicle behaviour when safety goal is achieved. Reaction Controllable Vehicle acceleration exceeding 1.5 m/s2 for 1 s has been demonstrated to be controllable by the driver slowing and stopping vehicle using the brake. C0 Controllability Vehicle behaviours that are „controllable in general’ may be rated „C0‟ C0 Controllability gives QM Risk Classification If a hazard is considered „controllable in general‟ „C0‟, no ASIL assignment is required. J Documented existing experience EV Propulsion System Validation Report
  11. 11. Does the Concept Deliver the Goal? February 17, 201411 Limiting Excessive Torque Limiting magnitude of torque error delivered to transmission to 150 Nm within 1 s Limiting Torque The only malfunctioning behaviour that can violate safety goal is delivering too much torque to transmission J Fault Tree Analysis Functional Safety Reqs Vehicle Test / Simulation Report Timing Analysis Safety Goal Common Cause Analysis 150 Nm Justification Delivering 150 Nm to the transmission does not exceed maximum acceleration of 1.5 m/s2 Limit Torque in the Presence of Faults Limit torque to transmission to 150 Nm within 1 s of detecting a fault that could lead to unintended acceleration Detection and Response Time Fault detection time and failure mitigation time does not exceed 1 s Detection of Torque Faults Detect all faults that could lead to excessive torque within 0.5 s Fault Identification All faults that could lead to excessive torque are identified Fault Detection Detection methods specified for faults that could lead to excessive torque Response to Detected Faults 150 Nm torque cap applied within 0.5 s of detecting a torque fault. Response to Individual Faults Individual controller requests of >150 Nm inhibited within 0.5 s of detecting torque fault Absence of Common Cause Faults There are no individual faults that could cause both controllers to malfunction together and collectively delivery >150 Nm torque excess
  12. 12. So why bother? The benefits of an evidence based explicit safety case: Helps formalise the links between the high-level goals/objectives and low-level evidence; providing rationale. - This rationale is often developed and retained „in people‟s heads‟ Aids communication of the safety argument throughout the development lifecycle: - Better clarity – being forced to write it down aids the safety engineer‟s thought process during development - Consistency improvement – project to project or with staff turnover - Maintainability benefits – the safety impact of changes made to an Item can be quickly assessed - Supports third-party assessment – removes ambiguity leading to less „to and fro‟ verbal questioning February 17, 201412
  13. 13. The Motivation behind the MISRA Safety Case Guidelines To aid the development of safe products To assist with ISO 26262 compliance February 17, 201413 Explicit safety arguments widely adopted and mandated in more safety- mature industries Convergence to a common understanding and the sharing of knowledge and experience The increasing complexity of and authority given to automotive E/E systems Standard requires a safety case to be developed, but ambiguities exist Little or no guidance given within the standard regarding safety argument development A safety case is: 1. Set of progressively compiled work products 2. Argument that the safety requirements are complete and satisfied
  14. 14. MISRA Safety Case Guideline Content February 17, 201414 Key concepts used within the guidelines document - Argument layers - Safety evidence tables - A generic safety argument framework
  15. 15. Safety Argument Layers February 17, 201415 Core Argument – Got the right requirements • Why do we have confidence that the requirements are right? • Which evidence indicates that the requirements are complete and correct? Layer 1 – Those requirements have been met • Why do we have confidence that the requirements have been implemented correctly? • Which evidence demonstrates that the correct implementation has been verified? Layer 2 – Implemented using the correct means • Why do we have confidence that an adequate process has been used to develop the work product • Which evidence demonstrates that the right people have used the correct methods? Layer 3 – In the right environment • Why do we have confidence in the environment in which the safety activities were undertaken? • Which evidence demonstrates that the organisation has a good safety culture?
  16. 16. Safety Evidence Tables February 17, 201416 Example evidence for safety goal 1........ Core – Got the Right Requirements Argument Typical Topics Evidence Safety goal rationale: safety goal 1 yields absence of unreasonable risk 1. Completeness of mapping between hazardous events and safety goals 1. Verification Review Report 2. Absence of unreasonable risk resulting from safety goal implementation 2. Vehicle Safety Validation Report One – Met the Requirements Argument Typical Topics Evidence Safety goal conformance: vehicle behaviour conforms to safety goal 1 1. Item performs as specified by the safety goal 1. Fault insertion tests 2. Vehicle fleet trials Two – Used the Right Means Argument Typical Topics Evidence Safety goal means: Appropriate means have been used to develop and review safety goal 1 1. Hazard analysis and risk assessment 1. Confirmation review report 2. Safety goal definition 2. Requirement review report 3. Personnel involved 3. Organogram and skills matrix
  17. 17. Generic Framework February 17, 201417 Levels of Requirements Argument structured by levels of safety requirements Functional Safety Absents of unreasonable risk caused by the malfunctioning behaviour of the Item has been achieved. Item Item Definition Hazards Hazardous events Safety Goals The vehicle behaves according to a set of complete and correct safety goals that mitigate the hazardous events identified Safety Goals Functional Safety Requirements The vehicle / item behaves according to a set of complete and correct FSRs defined to achieve each safety goal. FSRs Technical Safety Requirements The item behaves according to a set of complete and correct TSRs defined to meet the functional safety requirements TSRs Hardware & Software Requirements The item behaves according to a set of complete and correct hardware and software safety requirements defined to meet the TSRs HWSWSRs
  18. 18. Generic Framework February 17, 201418 Safety Goals The vehicle behaves according to a set of complete and correct safety goals that mitigate the hazardous events identified Safety Goal ALL safety goals Hazard Analysis & Risk Assessment ALL hazardous events Safety Goal 1 The vehicle behaves according to safety goal 1 defined to mitigate hazardous event 1 Safety goals grouped by hazardous event to which they pertain Safety Goal Safety Goal 1 Hazard Analysis & Risk Assessment Hazardous event 1 Argument Structure Argument structured by layers Safety Goals: Rationale Core argument about safety goals mitigating risk associated with hazardous events Safety Goals: Conformance Layer 1 argument about vehicle behaviour conforming to safety goals Safety Goals: Means Layer 2 argument about the means by which safety goals have been developed and reviewed Safety Goals: Environment Layer 3 argument about the development environment Argument Layers Core : got the right requirements Layer 1: met the requirements Layer 2: used the right means Layer 3: developed in the right environment
  19. 19. The Future 2014 - Release draft guidelines for public review o Generic GSN framework o Safety argument layers o Safety argument tables - Publish first version of the above - On-line examples Potential subsequent releases - Nominal behaviour - Non-Electrical / Electronic systems - Non-functional safety (e.g. „passive‟ safety) February 17, 201419
  20. 20. Thank you February 17, 201420 Helen Monkhouse BEng CEng MIET MWES Global Product Safety Manager Protean Electric Ltd Silvertree, Unit 10B, Coxbridge Business Park, Alton Road, Farnham, GU10 5EH. www.proteanelectric.com Direct: +44 1252 741828 Email: helen.monkhouse@proteanelectric.com

×