43
HUGHES PROPRIETARY by Bob (Abbas) Youssef Hughes Networks Systems October 9, 2008 DFMEA Training Workshop

Bob (ababs) Youssef FMEA Workshop Training at Hughes rev3

Embed Size (px)

Citation preview

HUGHES PROPRIETARY

by

Bob (Abbas) Youssef

Hughes Networks SystemsOctober 9, 2008

DFMEA Training Workshop

HUGHES PROPRIETARY

FMEA Workshop Agenda

1. What is, History, and Why develop FMEA?

2. FMEA as a design tool.

3. FMEA development Process according to the automotive

industry standards [AIAG standard (US Automotive Industry

Action Group] and [VDA standard (German and Europeans

Standard)]

4. Management role and responsibility

5. What is required of team members to contribute to the FMEA

development process

6. Hockenheim project FMEA Example/Exercise

7. Silverstone project FMEA example/exercise.

8. Wrap Up with Q & A.

HUGHES PROPRIETARY

What is FMEA?

• Failure Mode and Effect Analysis is an

analytical methodology used to ensure that

potential problems have been considered

and addressed throughout the product and

process development process.

• Two types of FMEA, Design and Process.

Both are designated by:

– Design Failure Mode and Effect Analysis (DFMEA)

– Process Failure Mode and Effect Analysis

(PFMEA)

HUGHES PROPRIETARY

History

• NASA developed the FMEA methodology for the

Apollo project.

• Aviation, Aerospace, and Nuclear technology adopted

and applied the FMEA methodology.

• Then, the automotive industry adopted the FMEA

methodology to meet its quality challenges. And

therefore, the automotive suppliers are required to

develop DFMEA and PFMEA for their subsystems

and/or components.

• DFMEA is required and is not an option.

• FMEA methodology is extensively used worldwide.

• FMEA is also used in non-manufacturing areas.

HUGHES PROPRIETARY 5

Why Develop FMEA?

• Identify potential failure modes, their effects

• Prioritize risks associated with specific causes

• Identify ways of eliminating or reducing the specific

causes

• Use it as a design tool for design change and

product improvement.

• Identify key products characteristics, Critical

characteristics

• Identify key process characteristics

HUGHES PROPRIETARY 6

Why Develop FMEA?

• Allows the engineer to develop prevention control and

detection control early on in the product development

process.

• Document the control plan

• Improve product launch with fewer failures

• Improve quality, reliability, and safety of product

• $$$$ Reduce warrantee cost and improve company

bottom line $$$.

• It is complementary to the process of defining what

a design or process must do to satisfy the customer.

• Most importantly Improve customer satisfaction

HUGHES PROPRIETARY

FMEA as a Design tool

• FMEA must be and is best developed “before-the-event”

not “after-the-event.”

• Ideally, the Design FMEA process should be initiated in the

early stage of the design.

• The Process FMEA is best initiated before tooling or

manufacturing equipment is developed or purchased.

• In both FMEA types, if potential failure is identified, it

allows the engineer to change the design, the process, the

equipment without major cost commitment upfront.

• One of the FMEA result is the documentation of the

collective knowledge of cross-functional teams.

HUGHES PROPRIETARY

FMEA as a Design tool

• A major part of the Evaluation and analysis is the assessment of

risk and the discussion conducted regarding the design

(product/process) and the review of the functions and any

changes in the application and the resulting risk of potential

failure.

• FMEA identifies severity of the effect of a potential failures and

to provide an input to mitigating measures and controls to

reduce risk.

• Control Actions and countermeasures are outputs of the FMEA

and determined by Risk Priority Number (RPN)

• Simply if used as a design tool, it is worth the

investment

HUGHES PROPRIETARY

FMEA as a Design tool

When must we create DFMEA?

• Initial within 90 days of “selection”.

• Revised submitted 12 weeks prior to tooling release.

• Revise after ED testing based on failures.

• Revise during DV testing if there are failures.

• Revise after PV testing if there are failures.

• DFMEAs are “continuous improvement” tools which means they are “in progress” continuously during the project.

HUGHES PROPRIETARY

AIAG Standard

1. Identify Functions requirements and

Specifications (inputs)

2. Identify Potential Failures

3. Identify Effects of each Failure Mode

associated with the inputs,

4. Identify Potential Causes of each Failure

Mode

5. Identify Current Controls (Preventive and

Detection) of the causes

6. Identifying and Assessing Risk

1. Assign Severity, Occurrence and Detection

ratings to each Cause

2. Calculate (RPN) Risk Priority Number

7. Determine Recommended Actions to reduce

High RPN’s

8. Take appropriate Actions and Document

results of countermeasures

9. Recalculate RPN’s

VDA StandardStep 1: Draw up system elements and system structure tree

(system elements)

Step 2: Depict functions and function structure (Function tree)

Step 3: Perform failure analysis (Failure Nets)

– A failure analysis must be performed for each system

element

– The potential failure Causes are the conceivable

malfunctions of the lower SEs.

– The potential Effects of each Failure Mode associated with

the inputs.

– Identify Current Controls (Preventive and Detection) of the

causes

Step 4: Carry out RISK Assessment

– Assign Severity, Occurrence and Detection ratings to each

Cause

– Calculate (RPN) Risk Priority Number

Step 5: Perform Optimization

– Determine Recommended Actions to reduce High RPN’s

– Take appropriate Actions and Document results of

countermeasures

– Recalculate RPN’s

Process Steps To Complete FMEA

Always document, review and update the latest revision of FMEA document

(It is a live dynamic document).

HUGHES PROPRIETARY

Management Role is to Identify the TEAM

• *KEY* Create a cross-functional team (all areas of engineering,

quality, verification and validation testing, process and

manufacturing, program management)

• Appoint a team leader that would work as a facilitator as well

recommended.

• *KEY* Identify and appoint subject matter experts to

participate, consult, and lead the design change efforts if

needed.

• Empower the team to make recommendations and

countermeasures corrective actions to design changes,

prevention and detection controls.

HUGHES PROPRIETARY

FMEA development Process according to the automotive industry standards

• Team Members Roles and Responsibilities – Team leader will facilitate the discussion and maintain the team

discussion focused on the issue.

– Identify a scriber to help document the outcome of the

discussion

– Team members must encompass the necessary knowledge on

the subject.

– This is a data driven activities, each SME brings design

documents, schematics, bench test results, CAE analysis results,

components specifications, functional requirements, test

requirements and capabilities, Bill of Materials, and of course

cooperation and professional spirit.

– Lead engineers are to follow up and lead the efforts to implement

the recommended actions.

HUGHES PROPRIETARY

FMEA development Process according to the automotive industry standards

• SCOPE

– *KEY* Before the FMEA can begin, a clear understanding of

what is being evaluated must be determined.

– The scope of the FMEA defines the boundaries of the FMEA

analysis.

– Define the Customer

• End User ( Driver, passenger, etc)

• OEM assembly and manufacturing facilities

• Supply chain manufacturing facilities

• Government Regulators

– The scope of the DFMEA is the TCU and its

interface with the vehicle.

HUGHES PROPRIETARY

FMEA development Process according to the automotive industry standards

For DFMEA – Boundary diagram

– P diagram,

– Interface diagrams

– Block diagram

– Schematics

– Drawings, Bill of Materials

– Compliance testing

capabilities

– Assembly Sequence

For PFMEA – Boundary diagram

– P diagram,

– Interface diagrams

– Block diagram

– Schematics

– Drawings, Bill of Materials

– Assembly sequence

– Process Flow

– Testing Capabilities

Information Needed:

HUGHES PROPRIETARY

Function Structure and Boundary Diagrams

CustomerVehicleEnvironmentNoise

Noise

Expand this Block

• Failures modes are typically manifest at interfaces

• Understanding how the parts of the system interface is key

to defining the failure modes

• Failure mechanisms can be either at boundaries or within

blocks

HUGHES PROPRIETARY

Failure Modes

Identify the failure modes by asking

“What can go wrong” with each function.

Failure modes generally fall in one of the following 4

categories:

• No Function

• Partial/Over/Degraded Function

• Intermittent Function

• Unintended Functions

HUGHES PROPRIETARY

Examples

• Failure mode is a technical mechanism

that will cause an effect on a user.

– LED driver device fails

• An instrument panel warning light is on when

not supposed to be on.

• The light is not on when it should be on.

• The light is on when it’s supposed to be, but is

dim and hard to see.

HUGHES PROPRIETARY

Potential Effect(s) of Failure

Identify the potential effects by asking “If this Failure Mode happens, what will be the consequences” on:

The operation, function, or status of the item’s subcomponents?

The operation, function, or status of the next higher assembly?

The operation, function, or status of the system?

The operation, drive-ability, or safety of the vehicle?

What the customer will see, feel, or experience?

Compliance with government regulations?

HUGHES PROPRIETARY

What Effect does the mechanism have on the customer?

SPECIAL ATTENTION:

Potential Effect(s) of Failure are defined as the effects of the Failure Mode on the function, as perceived by the

customer

Describe the effects of the failure in terms of what the customer might notice or experience. Remember that the customer may be an internal customer as well as

the ultimate end user.

State clearly if the function could impact safety or noncompliance to regulations.

The effects should always be stated in terms of the specific system, subsystems, or component being

analyzed.

HUGHES PROPRIETARY

How severe is the failure?

For each failure mode listed on the FMEA we also include a Severity rank in Col. 4:

• In cases with multiple effects per failure mode, select the effect with the most Serious rank.

• A reduction in Severity ranking can be effected only through a design change.

HUGHES PROPRIETARY

DFMEA Suggested Severity Evaluation Criteria

Effect Criteria: Severity of Effect Defined Rank

Potential Failure mode affects safe vehicle operation and / or involves

noncompliance with government regulation WITHOUT warning.10

Potential Failure mode affects safe vehicle operation and / or involves

noncompliance with government regulation WITH warning.9

Loss of primary function (vehicle operable, but comfort / convenience functions

inoperable)8

Degradation of primary function (vehicle operable, but comfort / convenience

functions at reduced level of performance)7

Loss of secondary function (vehicle operable, but comfort / convenience

functions inoperable)6

Degradation of secondary function (vehicle operable, but comfort / convenience

functions at reduced level of performance)5

Appearance or Audible noise, vehicle operable, item does not conform and

noticed by most customerss (75%).4

Appearance or Audible noise, vehicle operable, item does not conform and

noticed by many customerss (50%).3

Appearance or Audible noise, vehicle operable, item does not conform and

noticed by discriminating customerss (<25%).2

No Effect No effect. 1

Failure to

meet safety

and/or

Regulatory

Requirement

s

Loss or

Degradation

of Primary

Function

Loss or

Degradation

of Secondary

Function

Annoyance

HUGHES PROPRIETARY 22

From Cause To Effect…

External customer or downstream

process step

Cause

Function

or

Process step

Component, Material or

process input

Failure Mode

(Defect)

Effect

ON

Controls

HUGHES PROPRIETARY

Occurrence Rating

• The likelihood that a specific Cause/Mechanism will

occur during the design life, or the probability that a

failure mechanism will be active, is represented by the

Occurrence number.

• Estimate the likelihood of Occurrence on a 1 to 10 scale.

In determining this estimate, questions such as the

following should be considered:

– Has an engineering analysis (e.g., reliability) been used to

estimate the expected comparable Occurrence rate ?

– Has a reliability prediction been performed using

analytical models to estimate the Occurrence rating?

HUGHES PROPRIETARY

DFMEA Occurrence Evaluation Criteria

Probability of Failure

3rd

editionPossible

Failure Rates

RankingPossible Failure

RatesRanking

Likelyhood of

Failure

Very High: 1 in 2 10 1 in 10 100k PPM 10 Very High

Failure is almost inevitable 1 in 3 9 1 in 20 50k PPM 9

High: Generally associated with

processes similar to previous1 in 8 8 1 in 50 20k PPM 8

processes that have often failed 1 in 20 7 1 in 100 10k PPM 7

Moderate: Generally associated with

processes similar to1 in 80 6 1 in 500 2k PPM 6

previous processes which have 1 in 400 5 1 in 2,000 500 PPM 5

experienced occasional failures, but

not in major proportions1 in 2,000 4 1 in 10k 100 PPM 4

Low: Isolated failures associated

with similar processes1 in 15,000 3 1 in 100k 10 PPM 3

Very Low: Only isolated failures

associated with almost identical

processes

1 in 150,000 2 1 in 1M 1 PPM 2

Remote: Failure is unlikely. No

failures ever associated with almost

identical processes

1 in 1,500,000 1Failure is eliminated

by Prevention control1 Very Low

Low

Moderate

High

3rd edition 4th Edition

HUGHES PROPRIETARY 25

Detection Scores At Various Levels Of The Process

Material or process input

Prevention Detection Detection Detection

Det = 1 Det = 3 Det = 7 Det = 10

External customer or downstream

process step

Cause

Process StepMaterial or process input

Failure Mode

(Defect)Effect

Controls

HUGHES PROPRIETARY

DFMEA Suggested Detection/Prevention Evaluation Criteria

Opportunity for

Detection

Criteria: Likelihood the existence of a defect will be detected by test content before product

advances to next or subsequent process

Detection Rank

No Detection

Opportunity

No current design control; Cannot detect or is not analyzed Almost

Impossible

10

Not Likely to

detect at any

stage

Design analysis/detection control have a weak detection capability; Virtual (i.e. CAE, FEA) is not

correlated to expected actual operating conditions

Very

Remote

9

Post Design

Freeze and prior

to launch

Product verification/validation after design freeze and prior to launch with PASS/FAIL testing (Subsystem

or system testing with acceptance criteria such as ride and handling, shipping evaluation, etc.)

Remote 8

Product verification/validation after design freeze and prior to launch with test to failure testing

(Subsystem or system testing until failure occurs, testing or system interactions etc.

Very Low 7

Product verification/validation after design freeze and prior to launch with Degradation testing (Subsystem

or system testing after durability test, e.g. function check)

Low 6

Prior to design

Freeze

Product validation (reliability testing, development or validation tests) prior to design freeze using Pass/Fail

testing (e.g. acceptance criteria for performance, function checks, etc.).

Moderate 5

Product validation (reliability testing, development or validation tests) prior to design freeze using test to

failure (e.g. until leaks, yields, cracks, etc.).

Moderately

High

4

Product validation (reliability testing, development or validation tests) prior to design freeze using

Degradation testing (e.g. data trends, before/after values, etc.).

High 3

Virtual Analysis

Correlated

Design analysis/detection controls have a strong detection capability. Virtual analysis (e.g. CAE, FEA, etc.)

is highly correlated with actual or expected operating conditions prior to design freeze.

Very High 2

Detection not

applicable;

failure

prevention

Failure cause or failure mode cannot occur because it is fully prevented through design solutions (e.g.,

proven design standard, best practice or common material, etc.).

Almost

Certain

1

HUGHES PROPRIETARY

Criticality

Each failure mode has a severity and each failure

mechanism has an occurrence.

The criticality of the failure mechanism is the severity of

the failure mode times the occurrence of the failure

mechanism.

Criticality = Severity x Occurrence

This is a good measure of the impact of a failure mode.

HUGHES PROPRIETARY 28

Risk Priority Numbers, RPN

• The risk priority number (RPN) is the product of the

rankings for:

– Severity (SEV)

– Probability of Occurrence (OCC)

– Difficulty to Detect (DET)

• High RPN’s are flags to take effort to reduce the

calculated risk

RPN = SEV x OCC x DET

Effects Causes Controls

Regardless of RPN, high severity scores must be given

special attention

HUGHES PROPRIETARY 29

Summary of Rating Definitions

Severity Occurrence Detection

Hazardous without

warning

Very high and

almost inevitable

Cannot detect or

detection with very

low probability

Loss of primary

function

High repeated

failures

Remote or low

chance of detection

Loss of secondary

function

Moderate failures Low detection

probability

Minor defect Occasional failures Moderate detection

probability

No effect Failure unlikely Almost certain

detection

High 10

Low 1

Ratin

g

Severity Occurrence Detection

Hazardous without

warning

Very high and

almost inevitable

Cannot detect or

detection with very

low probability

Loss of primary

function

High repeated

failures

Remote or low

chance of detection

Loss of secondary

function

Moderate failures Low detection

probability

Minor defect Occasional failures Moderate detection

probability

No effect Failure unlikely Almost certain

detection

Note: AIAG Definitions are

in the appendix!

HUGHES PROPRIETARY 30

The First Half of the FMEA Form

Product

Function/

Item

Potential Failure

Mode

Potential Failure

Effects

S

E

V

Potential Causes

O

C

C

Current Controls

D

E

T

R

P

N

What is the

function /

Item

In what ways

COULD the

Function go

wrong?

What is the impact

on the Key Output

Variables

(Customer

Requirements) or

internal

requirements?

Ho

w S

eve

re is th

e e

ffe

ct to

the

cu

so

tme

r?

What causes the

Key Input to go

wrong?

Ho

w o

fte

n d

oe

s c

au

se

or

FM

occu

r?

What are the existing

controls and

procedures (inspection

and test) that prevent

either the cause or the

Failure Mode? Some

forms have two

columns prevention

controls and detection

controls

Ho

w w

ell

ca

n y

ou

de

tect ca

use

or

FM

?

Ris

k P

rio

rity

Nu

mb

er

S*O

*D

0 0 0 0

0 0 0 0

0 0 0 0

HUGHES PROPRIETARY 31

The Second Half of theFMEA Form

Actions Recommended Resp. Actions Taken

S

E

V

O

C

C

D

E

T

R

P

N

What are the actions for reducing the

occurrance of the Cause, or improving

detection? Must address Critical

Failures (YC), high RPN's and hanging

fruits (easy fixes).

Whose

Responsible for the

recommended

action?

What are the completed

actions taken with the

recalculated RPN? Be sure

to include completion

month/year

Do

es n

ot ch

an

ge

Ne

w n

um

be

r b

ase

d o

n th

e c

ou

nte

r

me

asu

res T

ake

n

Ne

w n

um

be

r b

ase

d o

n th

e c

ou

nte

r

me

asu

res T

ake

n

Ne

w n

um

be

r b

ase

d o

n th

e c

ou

nte

r

me

asu

res T

ake

n

BY

7 1 2 14

MS

0

0

HUGHES PROPRIETARY

32

Pareto Of Top Ranking RPN’s

• Must Address Actions Recommended for:

– High severity rating 9 &10

– High Criticality (S*O)

– Then high RPN’s S*O*D)

• Key is FOCUS! And dedicat resources in the most effective way

HUGHES PROPRIETARY

Countermeasures

Two basic countermeasures:

1. Redesign to eliminate the failure modes

2. Reduce the occurrence of the failure mechanism (Robustness)

Countermeasures should be documented on the FMEA as

Recommended Actions (Col. 12) and followed up with the

effectiveness of the countermeasures (Revised Sev, Occ. ratings)

in Col. 13-18.

Countermeasures

Results of countermeasures

Col.

12

Col.

13-18

HUGHES PROPRIETARY

1. Eliminate the Failure

• The number of failure modes increases with the

number of components and interfaces.

• Changing the design to eliminate unneeded

components will also eliminate failure modes.

(Parsimony)

Two plates joined by a nut and

bolt is replaced by a single

thick plate.All failure modes

associated with the nut,

bolt, and interface

between the two plates

have been eliminated.

HUGHES PROPRIETARY

EXAMPLES

HUGHES PROPRIETARY

Real Time Exercise

Divide into Two groups, Silverstone and Hokenheim

Develop the FMEA of one function; remember that

Follow the process

20 minutes session

5 minutes report out per group

Have Fun

• each function will have more than one failure, and

• each failure will have more than one cause, and

• each cause will have prevention and detection controls

HUGHES PROPRIETARY

Group 1: Hockenheim project FMEA

• Report out and fill in the first four columns

• Potential failure modes >1

• Potential effects of the failure >1

• Potential causes/mechanisms of failure >1

• Estimate Severity of Failure, Probability of occurrence of cause and probability of prevention or detection

• Determine Current design controls for prevention

• Assess the risk of that failure with the RPN

• Countermeasures for high RPN failures

• Recommended actions

• New Occurrence and Detection

• New RPN

Develop the

FMEA for one function

HUGHES PROPRIETARY

Group 2: Silverstone project FMEA

Develop the

FMEA for one

function

• Report out and fill in the first four columns

• Potential failure modes >1

• Potential effects of the failure >1

• Potential causes/mechanisms of failure >1

• Estimate Severity of Failure, Probability of occurrence of cause and probability of prevention or detection

• Determine Current design controls for prevention

• Assess the risk of that failure with the RPN

• Countermeasures for high RPN failures

• Recommended actions

• New Occurrence and Detection

• New RPN

HUGHES PROPRIETARY

FMEA Links to design for six sigma

DFSS

HUGHES PROPRIETARY

Connection to Z-Score

0.5 308,5371.5 66,8072.5 6,2103.5 2334.5 3.4

“Z-score”

A standard Six Sigma metric

expressed in units of standard

deviation (s); corresponds to

probability of producing a defect

Z-score is a standard measure of the probability that a failure mechanism will be active given the amount of noise present.

Failure mechanisms associated with high z-scores are rarely active.

Failure mechanisms associated with low z-scores are often active.

Z Defects per Million

Opportunities (DPMO)

3210-1-2-3

0.4

0.3

0.2

0.1

0.0

Normal

CD

F

Z

Standard Normal Distribution: m=0, s=1

PD

F

HUGHES PROPRIETARY

Z-Score vs. Occurrence

1

1.5

2

2.5

3

3.5

4

4.5

1 2 3 4 5 6 7 8 9 10

Occurrence

Z-S

co

re

Z = 4.4 - 0.3 * Occ.

Z-Score and Occurrence measure exactly the same thing. On an FMEA we use Occurrence; in a Six Sigma project we use Z-Score. The above formula is useful for translating.

DFSS Connection: Robust delivery of technology is the primary goal of DFSS

projects. A typical Black Belt project should decrease occurrence of a failure

mechanism rate by 70%.

This is a decrease of 2 in occurrence if the initial occurrence is above 8 and a

decrease of 1 in occurrence if the initial occurrence is 2 to 7.

HUGHES PROPRIETARY

Prioritizing Actions

The purpose of the FMEA is to reduce risk.

The FMEA team should prioritize their actions based on the following:

first, on effects that have the highest Severity ratings (9-10)

second, on Causes that have the highest Criticality ratings (Severity times Occurrence)

third, on the highest RPNs

HUGHES PROPRIETARY

WRAP UP

• Thank you for coming and participating

• Please remember as we work on the DFMEAs, this

material is confidential and Hughes proprietary

since it summarizes all of our design concepts and

potential failures and effects.

• Take pride of what you do and be ready to embrace

this methodology as it can be very useful if used as

a design tool from the get go.

• In addition, it is required by our customers and fits

well within our concurrent engineering process.