an introduction to failure modes effects and criticality ... · pdf file1 peuss 2011/2012 fmea...

1

PEUSS 2011/2012 FMEA

An Introduction to Failure ModesEffects and Criticality Analysis

FME(C)ADr Jane Marshall

Product Excellence using 6 SigmaModule

PEUSS 2011/2012 FMEA Page 2

Reliability tool and techniques

• Methods for fault avoidance

• Methods for architectural analysis andassessment

2


Methods for fault avoidance

• Parts derating and selection– Limiting component stress levels to below specified

maxima

– Ratio of applied stress to rated maximum stress

– Applied stress taken as maximum likely to beapplied during worst case operating conditions

• Stress-strength analysis


Methods for architecturalanalysis and assessment

• Bottom-up method

– Event tree analysis (ETA)

– FME(C)A

– Hazard and operability study (HAZOP)

• Top-down method

– Fault tree analysis (FTA)

– Reliability block diagram (RBD)

– Markov analysis

3

FME(C)A

• What is FME(C)A?

• Why FME(C)A?

• How to perform FME(C)A

• FME(C)A Exercise



Failure Modes and EffectsAnalysis (FMEA)

• A qualitative approach that is intended to:– Recognize and evaluate the potential failures of a product or

process and the effects of that failure

– Identify actions which could eliminate or reduce the chance ofthe potential failure occurring

– Document the entire process

• Failure Modes Effects and criticality Analysis (FMECA)– Extends FMEA to include criticality analysis

– Quantifies failure effects and severity

4

Definition

• Failure modes effects and criticality analysis (FMECA)is a step-by-step approach for identifying all possiblefailures in a design, a manufacturing or assemblyprocess, or a product or service.

• “Failure modes” means the ways, or modes, in whichsomething might fail.

• “Effects and criticality analysis” refers to studying theconsequences of those failures.


Why is it Important?

• Provides a basis for identifying root failurecauses and developing effective correctiveactions

• Identifies reliability/safety critical components• Facilitates investigation of design alternatives at

all stages of the design• Provides a foundation for other maintainability,

safety, testability, and logistics analyses


5

History/Standards

The FMEA was originally developed by NASA to improve and verifythe reliability of space program hardware.

• MIL-STD-785, Reliability Programs for System and EquipmentDevelopment and Production-Task 204, sets out the proceduresfor performing FMECA

• MIL-STD-1629 establishes requirements and procedures forperforming FMECA

• Automotive suppliers may use SAE J1739 FMEAs, or they mayuse the Automotive Industry Action Group (AIAG FMEA)

• QS-9000 standard

• IEC 60812 - Analysis techniques for system reliability – Procedurefor failure mode and effects analysis (FMEA)


Benefits of FME(C)A

• FME(C)A is one of the most important and most widelyused tools of reliability analysis.

• The FME(C)A facilitates identification of potentialdesign reliability problems

• It can help removing causes for failures or developingsystems that can mitigate the effects of failures.

• Help engineers prioritize and focus on high-riskcomponents/failures


6

Benefits of FME(C)A

• It provides detailed insight into the systemsinterrelationships and potentials for failure.

• Information and knowledge gained by performing theFME(C)A can also be used as a basis for troubleshooting activities, maintenance manual developmentand design of effective built-in test techniques.



• Systematically identifies cause and effect relationships

• Indicates critical failure modes

• Identifies outcomes from causes

• Framework for identifying mitigating actions

• Output may be large even for simple systems

• Prioritising may become difficult with competing failure modes

• May not easily deal with time sequences, environmentalconditions and maintenance aspects

Benefits and limitations

7

FME(C)A Applications - 1

• To identify failures which, alone or in combination, have

undesirable or significant effects; to determine the failure

modes which may seriously affect the expected or

required quality.

• To identify safety hazard and liability problem areas, ornon-compliance with regulations.

• To focus development testing on areas of greatest need.

PEUSS 2011/2012 13FMEA


• To assist the design of Built-in-Test and failure

indications.

• To assist the preparation of diagnostic flow charts or

fault-finding tables.

• To assist maintenance planning.

• To identify key areas in which to concentrate quality

control, inspection and manufacturing controls.


8


• To provide a systematic and rigorous study ofthe process and its environment.

– To support the need for standby or alternativeprocesses or improvements to current processes.

– To identify deficiencies in operator and supervisortraining and practices.


FMEA -- Types

ConceptFMEA

Component

DesignFMEA

System

Sub-System

ProcessFMEA

Assembly

Manufacturing

System

Component

Sub-System

System

Component

Sub-System


9

Design FMEA -- Team

Design Engineer

Manufacturing /Process Engineer

CORETeam

Representativesfrom:

• Customer Service

• Suppliers

• Global TestOperations

• Corporate Quality

SupportTeam


FMEA Process


10

FMEA Procedure

• Identify all potential item failure modes and define theireffects on the immediate function or item, on the system,and on the mission to be performed

• Evaluate each failure mode in terms of the worst potentialconsequence, which may rank severity classification

• Identify failure detection methods and compensatingprovision for each failure mode

• Identify corrective design or other actions required toeliminate the failure or control the risk

• Document the analysis and identify the problems, whichcould not be corrected by design


Setting The Level OfAnalysis


11

How is it Done?

What are the effectsof part failures onthe board?

What are the effectsof board failures onthe box?

What are the effectsof box failures onthe system?

Note: This is a bottom up example.Top down examples are possible.


FMEA Cascade - GeneralSystem Sub-System Component Process

Effect

Failure

mode

Cause

Effect

Failuremode

Cause

Effect

Failuremode

Cause

Effect

Failuremode

Cause


12

FMEA Cascade - Flipchart Stand

Flip Chart Stand(System)

Clamp(Sub-System)

ScrewAssembly(Assembly)

Screw(Component)

Effect

Failuremode

Cause

Effect

Failuremode

Cause

Effect

Failuremode

Cause

Effect

Failure

mode

Cause

EmbarrassPresenter

Paper fallsout

Insufficientclampingforce

Paper fallsout


Screwfailure


Screwfailure

Threadfailure

Screwfailure

Threadfailure

Processfailure



Bonnet Release Example

• What can go wrong with the bonnet release onyour car?

13


BONNET RELEASE SYSTEM FMEA

FUNCTION FAILURE MODE CAUSE EFFECT

•To release Bonnet for openingwhen required

•Cannot release bonnet 1.Cannot operate lever •Customer annoyance•Cancelled journey•Curtailed journey

1.R.H. or L.H. does not releaserespective plunger

1.Secondary catch does notoperate

•Difficult to release bonnet •Difficult to operate lever 1.Customer annoyance

1.Secondary catch difficult tooperate

•To prevent Bonnet releasing oropening when not required to open

1.Bonnet opens when not requiredto open

1.Bonnet liner detaches frombonnet

•Safety (accident – loss of vision)

1.Primary & secondary catchfailure

1.Bonnet releases to safety catchwhen not required

1.Primary catch failure •Hazard (reduced safety)•Vibration or flexing

1.Inadvertent operation of lever

•To retain Bonnet in requiredclosed position (shut lines,aesthetics) without vibration orflexing

1.Bonnet vibrates 1.L.H. or R.H. plunger not fullyengaged in receptacle

•High customer annoyance

1.L.H. or R.H. plunger detachesfrom liner

1.L.H. or R.H. plunger can move inreceptacle

1.Bonnet flexes •As 3.1 1.Customer dis-satisfaction

1.Looks awful 1.Incorrect location of L.H. andR.H. plunger

1.High customer annoyance


FUNCTION FAILURE MODE CAUSE EFFECT

1.To prevent Bonnet beingopened by external means

1.Bonnet can be openedexternally

1.External access to primaryrelease mechanism

•High customer annoyance•Theft

1.To enable Bonnet to close andlock in required position usingminimal force

•Cannot close bonnet 1.Plunger cannot enterreceptacle

1.Cancelled journey

1.Secondary catch cannot entersecondary receptacle

•Cannot close bonnet in requiredposition

1.R.H. and/or L.H. plungersincorrectly adjusted

1.Customer annoyance

•Cannot lock bonnet 1.R.H. and/or L.H. plungersincorrectly adjusted (length)

•Cancelled journey

1.R.H. and/or L.H. receptaclefailure

•Difficult to close bonnet •R.H. and/or L.H. plungersincorrectly adjusted

1.High customer annoyance

•Incorrect plunger spring fitted

•Receptacle stiff to operate

•Difficult to lock bonnet 1.R.H. and/or L.H. plungersincorrectly adjusted

•Customer dis-satisfaction

1.Receptacle fails open(intermittent)

BONNET RELEASE SYSTEM FMEA

14

FMECA Techniques

• The FMEA can be implemented using a hardware or functionalapproach, and often due to system complexity, be performed asa combination of the two methods.

• Hardware Approach :– Firstly this method lists individual hardware items analyzes their possible

failure modes.

– This method is used when hardware items can be uniquely identified fromthe design schematics and other engineering data.

– The hardware approach is normally used in a bottom-up manner.


FMECA Techniques

• Functional Approach :– This approach considers the function of each item. Each

function can be classified and described in terms of havingany number of associated output failure modes.

– The functional method is used when hardware items cannotuniquely identified.

– Basically, this method should be applied to when the designprocess has developed a functional block diagram of thesystem, but not yet identifiedspecific hardware to be used.


15

Functional Block Diagram

• A functional block diagram is used to show how the differentparts of the system interact with one another to verify the criticalpath.

• It is recommended to break the system down to different levels.• Review schematics and/or other engineering drawings of the

system to show how different parts interface with one another bytheir critical support systems to understand the normal functionalflow requirements.

• A list of all functions of the equipment is prepared beforeexamining the potential failure modes of each of those functions.

• Operating conditions (such as; temperature, loads, andpressure), and environmental conditions may be included in thecomponents list.


Typical FME(C)A Worksheet

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken

Action ResultsResponse &

TragetComplete

Date

RecommendedActions

RPN

Detec

CurrentDesignControls

Occur

PotentialCause(s)/

Mechanism(s)Of Failure

Class

Sev

PotentialEffect(s) of

Failure

PotentialFailureMode

Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure


Function


16

Failure Definitions

• Failure Mode & Cause – Potential failure modes, for eachfunction, are determined by examination of the functionaloutputs contained on the system functional block diagram. Abottoms-up approach is used where by analysis begins at thecomponent level, followed by analysis of subsequent or highersystem levels

• Failure Effects – The consequences of each postulated failuremode is identified, evaluated, and recorded on the FMEAworksheets.


General

• Assumptions should be included in the header.

• Product/part names and numbers must be detailed in the header

• All team members must be listed in the header

• Revision date, as appropriate, must be documented in the header

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


17

Function

• Function should be written clearly and must be precise so there is no change ofmisinterpretation.

• Each function must have an associated measurable metric.

• EXAMPLES– HVAC system must defog windows and heat or cool cabin to 70 degrees in all operatingconditions (-40 degrees to 100 degrees)

• within 3 to 5 minutes

• As specified in functional spec #_______; rev. date_________

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


Failure Mode

• Failure modes be written clearly and must be precise so there is no change ofmisinterpretation.

• There are 5 types of failure modes:– complete failure,

– partial failure,

– intermittent failure,

– function out of specification

– unintended function

• EXAMPLES– HVAC system does not heat vehicle or defog windows

– HVAC system takes more than 5 minutes to heat vehicle

– HVAC system does heat cabin to 70 degrees in below zero temperatures

– HVAC system cools cabin to 50 degrees

– HVAC system activates rear window defogger

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


18

Effect(s) of Failure

• Effects must be listed in a manner customer would describe them

• Effects must include (as appropriate) safety / regulatory body, end user,internal customers – manufacturing, assembly, service

• EXAMPLES– Cannot see out of front window

– Air conditioner makes cab too cold

– Does not get warm enough

– Takes too long to heat up

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


Severity Classification

• A qualitative measure of the worst potentialconsequences resulting from the item/functionfailure.

• It is rated relatively scaled from 1-10.


19

Mil-Std-1629 Severity Levels

• Category I - Catastrophic: A failure which may cause death or weaponsystem loss (i.e., aircraft, tank, missile, ship, etc...)

• Category II - Critical: A failure which may cause severe injury, major propertydamage, or major system damage which will result in mission loss.

• Category III - Marginal: A failure which may cause minor injury, minorproperty damage, or minor system damage which will result in delay or loss ofavailability or mission degradation.

• Category IV - Minor: A failure not serious enough to cause injury, propertydamage or system damage, but which will result in unscheduled maintenanceor repair.


Severity

• Severity values should correspond with AIAG, SAE, etc.

• If severity is based upon internally defined criteria or is based uponstandard with specification modifications, a reference to rating tables withexplanation for use must be included in FMEA

• EXAMPLES– Cannot see out of front window – severity 9

– Air conditioner makes cab too cold – severity 5

– Does not get warm enough – severity 5

– Takes too long to heat up – severity 4

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


20

Classification

• Classification should be used to define potential critical and significantcharacteristics

• Critical characteristics (9 or 10 in severity with 2 or more in occurrencesuggested) must have associated recommended actions

• Significant characteristics (4 thru 8 in severity with 4 or more in occurrencesuggested) should have associated recommended actions

• Classification should have defined criteria for application

• EXAMPLES– Cannot see out of front window – severity 9 – incorrect vent location – occurrence 2

– Air conditioner makes cab too cold – severity 5 - Incorrect routing of vent hoses (too closeto heat source) – occurrence 6

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


Cause(s) of Failure

• Causes should be limited to design concerns

• Analysis must stay within the defined scope (applicable system and interfaces toadjacent systems)

• Causes at component level analysis should be identified as part or systemcharacteristic (a feature that can be controlled at process)

• There is usually more than one cause of failure for each failure mode

• Causes must be identified for a failure mode, not an individual effect

• EXAMPLE– Incorrect location of vents

– Incorrect routing of vent hoses (too close to heat source)

– Inadequate coolant capacity for application

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class


Failure

Function


21

Occurrence Classification

Description

10 >= 50% (1 in two)

9 >= 25% (1 in four)

8 >= 10% (1 in ten)

7 >= 5% (1 in 20)

6 >= 2% (1 in 50)

5 >= 1% (1 in 100)

4 >= 0.1% (1 in 1,000)

3 >= 0.01% (1 in 10,000)

2 >= 0.001% (1 in 100,000)

1 Almost Never


Occurrence

• Occurrence values should correspond with AIAG, SAE

• If occurrence values are based upon internally defined criteria, a reference must beincluded in FMEA to rating table with explanation for use

• Occurrence ratings for design FMEA are based upon the likelihood that a cause mayoccur, based upon past failures, performance of similar systems in similarapplications, or percent new content

• Occurrence values of 1 must have objective data to provide justification, data orsource of data must be identified in Recommended Actions column

• EXAMPLES– Incorrect location of vents – occurrence 3

– Incorrect routing of vent hoses (too close to heat source) – occurrence 6

– Inadequate coolant capacity for application – occurrence 2

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

CurrentOccur

PotentialCause(s)/


Class

Sev


Failure

Function


22

Current Design Controls

• Preventive controls are those that help reduce the likelihood that a failure modeor cause will occur – affects occurrence value

• Detective controls are those that find problems that have been designed intothe product – assigned detection value

• If detective and preventive controls are not listed in separate columns, theymust include an indication of the type of control

• EXAMPLES– Engineering specifications (P) – preventive control

– Historical data (P) – preventive control

– Functional testing (D) – detective control

– General vehicle durability (D) – detective control

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


Detection rating

• A numerical ranking based on an assessment ofthe probability that the failure mode will bedetected given the controls that are in place.

• It is rated relatively scaled from 1-10.


23

Detection

• Detection values should correspond with AIAG, SAE

• If detection values are based upon internally defined criteria, a reference must beincluded to rating table with explanation for use

• Detection is the value assigned to each of the detective controls

• Detection values of 1 must eliminate the potential for failures due to designdeficiency

• EXAMPLE:– Engineering specifications – no detection value

– Historical data – no detection value

– Functional testing – detection 3

– General vehicle durability – detection 5

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


Rate the Risks Relatively

• A systematic methodology is used to rate the risks relative toeach other. The RPN is the critical indicator for each failuremode. The RPN is a function of three factors: The Severity ofthe effect, the frequency of Occurrence of the cause of thefailure, and the ability to Detect (or prevent) the failure or effect.

• RPN = Severity rating X Occurrence rating X Detection rating– The RPN can range from a low of 1 to a high

of 1,000

– Higher RPN higher priority to be improved.


24

RPN (Risk Priority Number)

• Risk Priority Number is a multiplication of the severity,occurrence and detection ratings

• Lowest detection rating is used to determine RPN

• RPN threshold should not be used as the primary trigger fordefinition of recommended actions

• EXAMPLE– Cannot see out of front window – severity 9,

– incorrect vent location – occurrence 2,

– Functional testing – detection 3,

– RPN - 54

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


Recommended Actions

• All critical or significant characteristics must have recommended actionsassociated with them

• Recommended actions should be focused on design, and directed towardmitigating the cause of failure, or eliminating the failure mode

• If recommended actions cannot mitigate or eliminate the potential forfailure, recommended actions must force characteristics to be forwarded toprocess FMEA for process mitigation

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


25

Responsibility & Target Completion Date

• All recommended actions must have a person assignedresponsibility for completion of the action

• Responsibility should be a name, not a title

• Person listed as responsible for an action must also be listed as ateam member

• There must be a completion date accompanying eachrecommended action

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


Action Results

• Action taken must detail what actions occurred, and the results of thoseactions

• Actions must be completed by the target completion date

• Unless the failure mode has been eliminated, severity should not change

• Occurrence may or may not be lowered based upon the results of actions

• Detection may or may not be lowered based upon the results of actions

• If severity, occurrence or detection ratings are not improved, additionalrecommended actions must to be defined

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


TargetComplete

Date

RecommendedActions

RPN

Detec


Occur

PotentialCause(s)/


Class

Sev


Failure


Item

DetectPrevent

RPN

DET

OCC

SEV

ActionTaken


CompleteDate

RecommendedActions

RPN

Detec

Current

Controls

Occur

PotentialCause(s)/


Class

Sev


Failure

Function


26

Criticality – Mil-Std-1629Approach

• Occurrence is a measure of the frequency of anevent.

– May be based on qualitative judgment or

– May be based on failure rate data (most common)


Criticality Analysis

• Qualitative analysis:

– Used when specific part or item failure rates are notavailable.

• Quantitative analysis:

– Used when sufficient failure rate data is available tocalculate criticality numbers.


27

Quantitative CriticalityAnalysis• Define the reliability/unreliability for each item, at a given operating

time.

• Identify the portion of the items unreliability that can be attributed toeach potential failure mode.

• Rate the probability of loss (or severity) that will result from eachfailure mode that may occur.– Calculate the criticality for each potential failure mode by obtaining the product of

the three factors:

– Mode Criticality = Item Unreliability x Mode Ratio of Unreliability xProbability of Loss

• Calculate the criticality for each item by obtaining the sum of the criticalities for eachfailure mode that has been identified for the item.

• Item Criticality = SUM of Mode Criticalities


• Calculate the expected numberof occurrences over a specific time interval.

• Many different methods are used

– Use handbook reliability data

– Use past experience

– Uses various Bayesian combinations of pastexperience data and expertjudgement

– Uses other analysis methods (RBD, FTA etc.)

Quantitative Analysis


28

Qualitative criticality analysis

• To use the method to evaluate risk and prioritizecorrective actions, the analysis team must:

– Rate the severity of the potential effects of failure.

– Rate the likelihood of occurrence for each potentialfailure mode.

– Compare failure modes via a Criticality Matrix, whichidentifies severity on the horizontal axis andoccurrence on the vertical axis.


Qualitative Analysis

• Because failure rate data is not available, failure mode ratios and failuremode probability are not used.

• The probability of occurrence of each failure is grouped into discrete levelsthat establish the qualitative failure probability level for each entry based onthe judgment of the analyst.

• The failure mode probability levels of occurrence are:

– Level A - Frequent

– Level B - Probable

– Level C - Occasional

– Level D - Remote

– Level E - Extremely Unlikely


29

• System description/specification

• Ground rules

• Block Diagram

• Identify failure modes

• Failure effect analysis

• Worksheet (RPN ranking)

• Recommendations (Corrective action)

• Reporting

FME(C)A Checklist


The results of the FME(C)A

• Highlight single point failures requiring correctiveaction

• Rank each failure mode.

• Identify reliability, safety critical components

• FMECA is a living document


30

Integrated FMECA

• FMECAs are often used by other functions such asMaintainability, Safety, Testability, and Logistics.

– Coordinate effort with other functions up front

– Integrate as many other tasks into the FMECA as possibleand as make sense (Testability, Safety, Maintainability, etc.)

• Integrating in this way can save considerable cost over doing theefforts separately and will usually produce a better product.

• If possible, use the same analyst to accomplish these tasks for thesame piece of hardware. This can be a huge cost saver.


FMECA Facts and Tips• FMECAs should begin as early as possible

– This allows the analyst to affect the design before it is set instone.

– If you start early (as you should) expect to have to redo portionsas the design is modified.

• FMECAs take a lot of time to complete.

• FMECAs require considerable knowledge of system operationnecessitating extensive discussions with software/hardware DesignEngineering and System Engineering.

• Spend time developing ground rules with your customer up front.


31

Exercise : Flashlight

This flashlight is for use by fire and rescue operative involved in

emergency operation to rescue people from fires, floods and other disasters.

Perform an FMECA on the torch.


Flashlight (cont.)

Item Failure Mode End Effect

bulb dim light flashlight output dimno light no flashlight output

switch stuck closed constant flashlight outputstuck open no flashlight outputintermittent flashlight sometimes will not turn on

contact poor contact flashlight output dimno contact no flashlight outputintermittent flashlight sometimes will not turn on

battery low power flashlight output dimno power no flashlight output

How can it fail?

What is the effect? Notethat Next Higher Effect =End Effect in this case.

Part


32

Simple Example: Flashlight(cont.)

• Severity

– Severity I Light stuck in the “on” condition

– Severity II Light will not turn on

– Severity III Degraded operation

– Severity IV No effect



Item Failure Mode End Effect Severity

bulb dim light flashlight output dim IIIno light no flashlight output II

switch stuck closed constant flashlight output Istuck open no flashlight output IIintermittent flashlight sometimes will not turn on III

contact poor contact flashlight output dim IIIno contact no flashlight output IIintermittent flashlight sometimes will not turn on III

battery low power flashlight output dim IIIno power no flashlight output II


33




Can circled items be designed out or mitigated?(There may be others that need to addressed also.)


34

Summary

• Defined FMEA

• Difference between FMEA and FMECA

• Standard approach and pro-forma

• Applications


an introduction to failure modes effects and criticality ... · pdf file1 peuss 2011/2012 fmea...

Documents