FAIL MODE ANLS DES
FAIL MODE ANLS DES ETM 5291
Popular in Course
Popular in Electronics Technology
verified elite notetaker
This 0 page Class Notes was uploaded by Xander Quitzon III on Sunday November 1, 2015. The Class Notes belongs to ETM 5291 at Oklahoma State University taught by Staff in Fall. Since its upload, it has received 23 views. For similar materials see /class/232770/etm-5291-oklahoma-state-university in Electronics Technology at Oklahoma State University.
Reviews for FAIL MODE ANLS DES
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 11/01/15
Failure Mode and Effect Analysis Lecture 43 Software FMEA Failure Mode and Effects Analysis in Software Software Development Pries SAE Technical Paper 982816 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 don39t fail because they are assembled from many loosely toleranced components A smgle wellplaced defect in a low level component can be catastrophic 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 FMEA Hardware vs Software Behavior over the system life cycle Hardware Model Early Life Failure Wearout Infant Mummy Usdul Li End of Life Cunslam Failure Rm Failures Time FMEA Software Life Cycle Trend Software Model Early Life Failure Wearoul MDImam Useful Life End nil ire Cnnslant Failure Rm Failures Time FMEA Software Life Cycle Trend Software does not wear out in the physical sense it deteriorates Deterioration is not a function of time It is a function of the side effects of changes made in the maintenance phase to correct latent defects adjust software to changing requirements improve performance FMEA Software LIfe Cycle Trend Hardware deteriorates due to lack of maintenance but software deteriorates because of maintenance Software doesn t wear out It ceases to be useful and or cost effective in a changing technical environment Software failure is a function of usage not of time FMEA Software FM EA Applications Anticipating software problems Prelude to test design Safety and hazard analysis causes and potential solutions Documentation FMEA SWFM EA 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 FMEA Begin wuth 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 Form Imam Inn2AM DESIGN FNIEA mume m lnmwmo mum lam In mum I oocukkmcrl mcnvmsrl I mu SxOxE ETECK OF RE U s pomm o a x mom rg mmm gggg wggg may c vni f o y p mm comma 22 335 T77 USERquot V mum2 ACTIVITIES F PRIOMY A010 DA C c FMEA Example Speedometer FMEA reuced Customer is uncomfortable FMEA Interface Analyses Software Software units and components interface with each otherthrough subroutine 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 quasiassignment statements as candidates for software interface variables FMEA Interface Analyses Hardware The engineer frequently will have a tendency to allow the software DFMEA to drift into becoming a hardware DFMEA To handle this issue the engineer can de ne a hardware input failure for example and then analyze the failure on the basis of how the software reacts to the hardware failure A typical case is that of an open circuit Does the software meet any requirements for handling this error condition Does the software ful ll design intent with respect to handling errors in the hardware Does the software provide some kind of visual indication that a negative event has occurred MEA SWFMEA and Software Quality Walkthroughs the software DFMEA can be used to enhance the quality of requirements design and code walkthroughs by highlighting potential failure modes As with inspections the DFMEA can be used to keep the walkthrough honest and ensure that product flaws are at least considered and heeded during the process IWEA SWFMEA and Software Quality lnspec ons Generally software inspections are a quasiformal event with a checklist of known software problems supplied to the inspectors The software DFMEA can be used to enhance the typical failures enu merated on the checklist or the checklist can be used to enhance the failure modes enumerated in the DFMEA The difference lies in the emphasis ofthe two methods inspection looks fortypical software problems DFMEA is a tool for anticipating failure mode effects and eliminating them when possible IWEA SWFMEA and Software Quality Tes ng The software DFMEA is a useful rstpass and multi pass tool for developing test cases The test designer can take the software DFMEA failure modes de ne them as test cases and develop procedures for stimulating the conditions that can lead to the failure All versions ofthe software DFMEA should be retained through the life ofthe project preferably under automated con guration control that way failure modes that have presumably been eliminated will not disappear from the software DFMEA document FMEA SWFMEA and Static Code Anavsis 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 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 FMEA Systems SWFM EA 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 ie design techniques Only a subset of nal system failure modes will be detectable at the design stage other failure modes will be introduced during implementation FMEA Systems SWFM EA SWFMEA may be used before implementation to help guide the selection of appropriate languages tools and testing techniques SWFMEA may be used before operational cutover to help gauge whether the implemented system falls within specified risk parameters 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 Failure Mode and Effect Analysis Lecture 53 FMEA Deployment FMEA Linkage with other tools and initiatives Deploying FMEA in the Organization FMEA Selective Select Review Develop Training Project Design FMEA I I I I Steering Allocate Requirements Assess 39H Resources pecs Effectiveness Groundrules Select Incorp Success Guidel39 es Team into Handbook Procedures Handbook Recall from Lecture 1 FMEA Quality Process Business 1 Objectives PrObem I Designof Solvmg EXpeIiments Prevention Plan Tools FMEA To plan support and analyze FMEA Quality Function Statistical Tools Deployment QFD Pareto diagram Root Cause Analysis Scatter Plot Fault Tree Analysis Statistical comparison Histogram Process Flow Diagram Control Chart Block Dlagram Process capability Responsibility Matrix study Area Chart Planned experiment CostBenefit Studies Other Documentation FMEA Quality plan contract Test plan Final design print Manufacturing control plan Standard operating procedures W Process flow diagram Preventive maintenance schedule Design repair procedures customer assembly instructions Summary FMEA FMEA is a tool that must be applied with other reliability and quality tools during the design and process development The design concept should be selected before developing the FMEA Quality Function Deployment is one tool that can provide inputs to the first column of an FMEA Summary FMEA Coordinating and tracking FMEA can be supported by Process Mapping and Responsibility Matrix Common analytical tools that assist in the development of FMEA include Fishbone Causeeffect diagrams Root Cause Analysis Fault Tree Analysis Planned Experiments Summary FMEA Output from the FMEA process may influence Quality plans Design prints Concurrent engineering plans tasks Manufacturing control plan Standard operating procedures Process ow diagrams Preventive maintenance schedule Design assembly and repair procedures Service procedures You are an Agent of Changel FMEA When contemplating getting involved in a new initiative you have a moral obligation to assess the situation carefully and objectively Avoid encouraging the organization to attempt more than it can accomplish Must Have s FMEA A compelling reason for change Suitable sponsors Informed commitment of the sponsors An adequate mandate forthe Team Leader Change Agent You need all of these to succeed Don t even think of compromising on these Wish List FMEA Top management credibility A cohesive top management team Informed commitment of top management team Ready access to expertise Some good improvement initiatives already underway If some of these exist lucky you Use them to the fullest If they don t exist develop them Mixed Blessing FMEA The organization is not autonomous Some other major forced change is in progress If either of these exist find out whether they are opportunities or threats and determine if they can be turned to your advantage Potential Major Barriers FMEA Massive success Full delegation of the process A superficial window dressing motivation Extreme dysfunction in the organization If any of these exist go back to the Must Haves and see if any of them really exist Set Realistic Objectives FMEA Build Steam Spend time getting educated Select and train a facilitator Develop a first draft manual Select an initial product or process Start execution Initial plan is agreed Team and facilitators are in place Management is getting regular updates Set Realistic Objectives FMEA 6 months Targeted education for early participants well underway Initial FMEA s complete and used as examples in class Some early results and success stories but few tangible results 1 year Some teams report significant progress Several FMEA s complete and some tangible results Set Realistic Objectives FMEA 1 8 months Completed design cycle using FMEA on selected items Some results are significant but not easily translated into bottom line results Opponents making last stand and arguing that the process is not accomplishing much and is not worth the effort 2 years Significant change is apparent in the style of working in many parts of the organizations Several accomplishments and recognition Some impact on results and ti metomarket FMEA Questions Failure Mode and Effect Analysis Lecture 21 CauseEffect Tools FMEA CauseEffect Analysis CauseEffect Principle CauseEffect Model Root Cause Analysis Problem Solving FMEA Typical problemsolving practices Stopping too soon The need to place blame Root cause myth Illusion of common sense and a single reality Storytelling Categorical thinking Reference Apollo Root CauseAnalysis Dean L Gano Causes if Ineffective Problem Solving FMEA Incomplete problem definition Unknown causal relationships Focus on solutions Reference Apollo Root CauseAnalysis Dean L Gano CauseEffect Principle FMEA 1 Cause and Effect are the same thing CAUSES EFFECTS Injury gt caused by gt Fall Fall gt caused by gt Wet Surface Wet Surface caused by Leaky Valve Leaky Valve gt caused by gt Seal Failure Seal failure gt caused by gt Poor Maintenance Reference Apollo Root CauseAnalysis Dean L Gano CauseEffect Principle FMEA 2 Causes and effects are part of an infinite continuum of causes 3 e e e e E E E E E E 5 5 In Faquot Wet Leaky Seal Poor J y Surface Valve Failure Maint Reference Apollo Root CauseAnalysis Dean L Gano CauseEffect Principle FMEA 3 Each effect has at least 2 causes in the form of actions and conditions Why Action Cause Condition Cause Reference Apollo Root CauseAnalysis Dean L Game 7 CauseEffect Principle FMEA 4 An effect exists only if its causes exist at the same poin 39me and space condition condition condition Reference Apollo Root CauseAnalysis Dean L Gano 8 CauseEffect Model FMEA POTENTIAL PROBLEM LIKELY EFFECTS LIKELY CAUSES TRIGGER CONTINGENT PREVENTIVE ACTIONS ADAPTIVE CORRECTIVE Initial Problem FMEA POTENTIAL PROBLEM WALK INTO DOOR LIKELY EFFECTS BUMP HEAD LIKELY CAUSES CAN T SEE CONTINGENT PREVEN11VE ACTIONS ADAPTIVE CORRECTIVE GET GLASSES WEAR HELMET REM O VE DOORS 1st Why FMEA POTENTIAL WALK INTO DOOR Cause becomes n PROBLEM problem Problem becomes effect LIKELY CAUSES LIKELY EFFECTS BUMP HEAD CONTINGENT PREVEN11VE ACTIONS ADAPTIVE CORRECTIVE GET GLASSES WEAR HELMET REM 0 VE DOOICSv FMEA POTENTIAL PROBLEM CAN T SEE NEARSI GH TED LIKELY CAUSES WALK INTO DOOR BUMP HEAD LIKELY EFFECTS CONTINGENT PREVEN11VE ACTIONS ADAPTIVE CORRECTIVE SURGERY REMOVE DOORS GET GLASSES 2nd Why FMEA POTENTIAL PROBLEM WALK INTO DOOR BUMP HEAD LIKELY CAUSES LIKELY EFFECTS CONTINGENT PREVEN11VE ACTIONS ADAPTIVE CORRECTIVE SURGERY REMOVE DOORS GET GLASSES POTENT39AL NEARSI GH TED PROBLEM T00 MUCHTV CAN TSEE LIKELY EFFECTS WALK INTO DOOR LIKELY CAUSES BUMP HEAD FAIL EYE EST CONTINGENT PREVEN11VE ACTIONS ADAPTIVE CORRECTIVE CUT OUT STAR TREK GET GLASSES REMOVE DOORS HAVE WE FOUND ROOT CAUSE Breaking the CauseEffect Chain FMEA POTENTIAL PROBLEM NEARSI GH TED T00 MUCHTV CAN TSEE WALKINTO DOOR BUMP HEAD LIKELY CAUSES LIKELY EFFECTS OR GONE TOO FA 39 CONTINGENT PREVEN11VE ACTIONS ADAPTIVE CORRECTIVE CUT OUT STAR TREK GET GLASSES REMOVEDOORS39 HAVE WE FOUND ROOT CAUSE 15 Million Dollar Question FMEA Potential Failure Mode At what point is the 9 Why39 causeeffect W 9 C chain sufficiently Y m broken H gm Far 32 Why You Go 16 Observed i Effect Root Cause Analysis FMEA CauseEffect is based on the idea that we can positively identify what we don t like about a situation and trace it back to some underlying cause or causes Effects can be Desirable quotdes f i f i but they can only be categorized by Nem 3 comparing them to some designated standard The CauseEffect tree is a very effective tool fora team to use to assess and trace a problem to root cause It is particularly effective with complex problems which have several effects and potential causes What is a Root Cause FMEA Lowest point in a cause effect chain at which we have capability to cause a break It is the lowest point at which human interaction can break the causeeffect chain Root Cause Analysis Method FMEA Once the problem or situation is defined brainstorm the effect From each effect ask Why and continue until root cause is reached Products are failing for contamination WHY Containers leak at mounting screw hole WHY Suppliers leak test may not detect porosity leak WHY Suppliers have different leak test processes WHY No standard process for supplier leak test 19 Root Cause Analysis Method Steps FMEA 1 Identify Span of control and Sphere of Influence 2 Create a List of Undesirable Effects UDE s Undesirable effects are negative by their own merit 3 Write the UDE s on to PostitTM Notes and place on a large sheet of paper EEEEE Undesirable Effect U DE FMEA Really Exists Negative on its own merits Undesirable on their own merits Workers are Laid Off I Absenteeism is rising Net Pro t is decreasing Englneerlngyand Production u cant agree My boss is angry with me I I am late for work J 3 UDE or fact of life Neutral or marginal Correlation vs CauseEffect FMEA CauseEffect diagram must not contain hidden correlations What is the difference between Cause Effect and Correlation How can chasing correlations lead you astray in a CauseEffect analysis Root Cause Analysis Method Steps FMEA 4 Connect UDE s if one leads to but not necessarily causes the other Lower UDE is the leader upper is m the follower J Test with IF THEN 5 Determine if any steps are THEN missing between the leader and the follower or if other contributing causes exist lF m Fill them in Use ellipses to represent AND situations Root Cause Analysis Method Steps FMEA 6 Connect other UDE s and build CauseEffect chain downward from each Continue adding missing steps and contributing causes G UDE s Do the originals still qualify in the context ofthe rest of the diagram Identify Root Causes and Core Problems Root causes are boxes with arrows coming out but none going in Root Cause Analysis Method Steps FMEA 7 Add or redesignate E Root Cause Analysis Method Steps FMEA 9 Look for common connections to the various branches These root causes could represent deep fixes 10 Determine causes which are within the Span of Control and the Sphere of Influence for the Black Belt Team