Software Failure Mode & Effects Analysis: Importance & Differences in Development, Study notes of Engineering

Download Software Failure Mode & Effects Analysis: Importance & Differences in Development and more Study notes Engineering in PDF only on Docsity! 1 Failure Mode and Effect Analysis Lecture 4-3 Software FMEA “Failure Mode and Effects Analysis in Software Software Development,” Pries, SAE Technical Paper 982816 2 FMEA Software Development is Different • Process variation can never be eliminated or even reduced below a moderate level • No two modules are alike so process performance always includes an intrinsic degree of variability • There are very large differences in skills and experience from one developer to another • Specifications are not based around tolerances • Systems don't fail because they are assembled from many loosely toleranced components. A single well-placed defect in a low level component can be catastrophic 2 3 FMEA Measurements Software development processes can be fully characterized by three simple measurements • Time: the time required to perform a task • Size: the size of the work product produced • Defects: the number and type of defects, removal time, point of injection and point of removal 4 FMEA Hardware vs Software Behavior over the system life cycle Hardware Model Wearout (End of Life) Early Life Failure (Infant Mortality) Useful Life (Constant Failure Rate) Time Fa ilu re s 5 9 FMEA SWFMEA • SWFMEA is not to be a replacement for traditional software reliability methods, rather it is intended to be a systematic thinking tool, a means of anticipating issues and improving validation 10 FMEA Begin with Outputs • Outputs are observable behavior • Observable behavior leads to failure modes that may be detected by a driver, customer test group, or a servide organization • One or more inputs will be related to each output • At the end of the process, all outputs must capture all inputs 6 11 FMEA Form PRODUCT: FMEA NO DES IGN FMEA PART / SYSTEM: PAGE DRAWING REFERENCE: DATE: BY: RES UL S E V O C C S E V O C C E F F R P N EFFECTIVENESSEVERITY OCCURRENCE RPN = S x O x E PART OR SYSTEM NAME DESIGN VERIFICATION ACTIVITES EFFECTS OF FAILURE -LOCAL, NEXT LEVEL, END USERFUNCTION(S) POTENTIAL CAUSES OF FAILURE POTENTIAL FAILURE MODE ACTION PRIORITY RECOMMEN. CORRECTIVE ACTIONS RESPONSIB & DUE DATE ACTIONS TAKEN FUNCTION POTENTIAL EFFECTS OF SEV POTENTIAL OCC ENGINEERING EFF OUTPUT FAILURE MODE FAILURE CAUSES VERIFICATION RPN Speedometer / correct vehicle speed Gauge dither aperiodic Driver cannot assess speed resulting in safety hazard 10 Poor filter algorithm and oscillating data from sensor output 5 Test 001 - randomly oscillating signal 3 150 10 Input values not properly scaled 7 Test 003 - scaled input 2 140 Guage dither periodic Driver cannot assess speed resulting in safety hazard 10 Poor filter algorithm and oscillating data from sensor output 3 Test 001 - randomly oscillating signal 3 90 12 FMEA Example - Speedometer FUNCTION POTENTIAL EFFECTS OF SEV POTENTIAL OCC ENGINEERING EFF OUTPUT FAILURE MODE FAILURE CAUSES VERIFICATION RPN Speedometer / correct vehicle speed Gauge dither aperiodic Driver cannot assess speed resulting in safety hazard 10 Poor filter algorithm and oscillating data from sensor output 5 Test 001 - randomly oscillating signal 3 150 10 Input values not properly scaled 7 Test 003 - scaled input 2 140 Guage dither periodic Driver cannot assess speed resulting in safety hazard 10 Poor filter algorithm and oscillating data from sensor output 3 Test 001 - randomly oscillating signal 3 90 7 13 FMEA Severity None No effect 1 Very Minor Observable software-driven behavior does not conform to spec. Discriminating customer notices 2 Minor Observable software-driven behavior does not conform to spec. Average customer notices 3 Very low Observable software-driven behavior does not conform to spec. Customer notices. 4 Low Software makes item operable but comfort/convenience items have reuced performance. Customer is uncomfortable 5 Moderate Software makes item operable but comfort/convenience items are inoperable. Customer is uncomfortable 6 High Software makes item operable but at reduced levels of performance. Customer dissatisfied 7 Very high Software makes item inoperable with loss of primary function 8 Hazardous - warning Software failure affects safe operation of item and / or non- compliance with government regulation 9 Hazardous - no warning Software failure affects safe operation of item and / or non- compliance with government regulation 10 SEVERITY of Effect 14 FMEA Interface Analyses Software Software units and components interface with each other through sub-routine arguments, through messages, or through a global pool. When possible, the software engineer should generate a complete analysis of interface variables using a software tool. Otherwise, the engineer must examine all assignment and quasi-assignment statements as candidates for software interface variables. 10 19 FMEA SWFMEA and Static Code Analysis The DFMEA technique allows the software engineer to anticipate software problems based on defined outputs and inputs. The DFMEA method has no code requirement; that is, the engineer can apply this method early in the life cycle of project development—a capability generally unavailable when using other techniques of requirements, design, and code analysis. 20 FMEA Key Challenges • To find effective ways of classifying software failures into appropriate failure modes • Estimating the likelihood of each failure mode Significant difference from traditional FMEA is that the software design is not assumed to be perfect and will contain systematic faults inadvertently introduced by software developers 11 21 FMEA Systems SWFMEA • SWFMEA may be used very early (before design) to indicate whether the technical plan for SW development is sufficiently robust, to prevent, detect and remove, likely kinds of design faults • SWFMEA may be helpful in the design stage to identify aspects of the design which may need modification (i.e. design techniques) Only a subset of final system failure modes will be detectable at the design stage - other failure modes will be introduced during implementation 22 FMEA Systems SWFMEA • SWFMEA may be used before implementation to help guide the selection of appropriate languages, tools and testing techniques • SWFMEA may be used before operational cut-over to help gauge whether the implemented system falls within specified risk parameters 12 23 FMEA Areas of Research Need for major research • into causes and effects of failures in software- based systems • establish appropriate measures and metrics • address the causal chain in system development • establish an effective classification scheme for failures • costs and benefits in the development process