MPD 5750 DESIGN FOR QUALITY

Developed by:Dave Minock, J.D. Salinas, Dan Slater

MPD 5750 DESIGN FOR QUALITY

INTRODUCTION

■ Definition of Quality■ What is DFQ■ How DFQ fits into the Engineering V

process■ DFQ Process Flow■ Example of DFQ

Design for Assembly

(DFA)

Design for Craftsmanshi

p (DFC)

Design for Manufacturing

(DFM)

Design for Ergonomics

(DFE)

Design for NVH

(DFN)

Design for Environmental

Friendliness (DFEF)

Design for Cast and

Molded Parts (DFCMP)

Design for Reuse and

Recycle-ability (DFRR)

Design for Health and

Safety (DFHS)

Design for Serviceability

(DFS)

The World of Quality

Elements of Quality

Exciting& Innovative

Products

Customer Satisfactionand Owner

LoyaltySuperior

Purchase & Service Experience

HighProduct Quality

TGR TGW

DEFINITION OF QUALITY

■ The Customer defines Quality - products and services that meet their needs and expectations throughout the product life at a cost that represents value - Ford Quality Policy

■ The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs - ISO 8402

■ The loss a product imposes on society after it is shipped - Taguchi

■ A subjective term for which each person has his or her own definition - American Society for Quality

DESIGN FOR QUALITY (DFQ)■ Quality is intrinsic to a design and is dependent on:

■ Choice of system architecture■ Robustness of execution during the PD process

■ Quality is primarily associated with two aspects: functional performance and customer perception

■ DFQ is the disciplined application of engineering tools and concepts with the goal of achieving robust design development and definition in the PD process

■ The DFQ process allows the engineer to: identify, plan for and manage factors that impact system robustness , reliability and failures early in the design process

KEY DFQ TERMS

Design: Creative process in the Arts, Sciences and Technologies. There are many design heuristics that are derived from rules, relationships and experiences.Failure: A condition in which a system no longer performs its intended function, or is unable to do so at a level that meets customer satisfaction. Failure can also result from the emergence of an undesirable function.Reliability: Elimination/avoidance of failure modes/mistakes. The probability that a product will perform its intended function: 1. 1) Under customer operating conditions 2. 2) For a specified life 3. 3) In a manner that meets or exceeds customer expectations

Robustness: The capability of a product or process to perform its intended function consistently in the presence of noise during its expected life. The performance of the product or process is insensitive to sources of variabilityTestability: Ability to generate, evaluate and apply tests that improve quality and minimizes time-to-profit.

System Architecture: The art and science of creating and building complex systems. That part of systems development most concerned with scoping, structuring, and certification. [M&R, 1997].Failure Mode And Effect Analysis (FMEA): Systematic activities intended to:1. 1) recognize and evaluate potential failure of products/processes and its

effects2. 2) identify actions to eliminate or reduce the chance of the potential failure

occurring3. 3) document the process

Classification of failures:- - Hard failures cause complete loss of function, (ex: Driveline does not

transmit torque to wheels)

- - Soft failures cause degraded function, (ex: driveline whines at 45 mph steady vehicle speed.

Approach: Design for quality must be approached from a functional perspective as opposed to a hardware perspective. It is recommended to use a “function tree” to decompose functions from the system to the subsystems and components.

KEY DFQ TERMS

■ Common product design tools associated with DFQ, and discussed in this presentation, are:

■ Boundary Diagrams■ Interface Matrix■ Parameter Diagram (P-Diagram)■ Design Failure Mode and Effects Analysis (DFMEA)■ Reliability Checklist (RCL)■ Reliability Demonstration Matrix (RDM)■ Design Verification Plan (DVP)

■ The engineering concepts associated with the tools identified above are based on proven methods that can be applied across a variety of industries

QUALITY PRODUCT DESIGN TOOLS

• Control Factors: features of the design that can be changed by the engineer (dimensions, shapes, materials, positions, locations etc).

• Noise Factors: sources of disturbing influences that can disrupt ideal function, causing error states which lead to quality problems. Noise factors can be categorized into five categories:

1. Piece to Piece Variation2. Customer Usage3. Degradation Time/Mileage4. Environmental Usage5. System Interaction

• Error state: is an undesirable output of the engineering system (we can also call these failure modes), characterized by 1) variation in ideal function (soft failure), 2) degradation in ideal function (soft failure), 3) or loss of ideal function (hard failure).

TERMINOLOGY & CONCEPTS

• Reliability can make or break the long-term success of a product:o Too high reliability will cause the product to be too

expensiveo Too low reliability will cause warranty and repair costs to be

high and therefore market share will be lost

• A reliable product is robust and mistake-free• A robust design is a product which performs its function "on

target“ which will generate the smallest loss to the customer and producero Cost of customer dissatisfactiono Cost to repair or replace

• Customers tend to be more satisfied with their purchases if the product is robust and reliable

WHY DESIGN FOR QUALITY?

• Failures must be approached from a functional perspective as opposed to a hardware perspective. It is recommended to use a “function tree” to decompose functions from the system to the subsystems and components.

• Optimize the Designo Eliminate unacceptable failure modes, including but not

limited to high severity modes.o Substitute high severity failure modes by lower severity

failure modeo Iterate the designs through CAE and physical testing using

component and system level testing until reliability is established.


• Testability must be engineered into the product at the design stage itself, such that optimal compromise is archived between system maintainability and performanceo Ability to generate, evaluate and apply tests that improve quality

and minimizes time-to-profito Extent to which a design can be tested for the presence of

manufacturing, base component, system, and/or field defectso Measure of how easy it is to generate test sets that have a high

fault coverage


DESIGN FOR QUALITY TIMING

System design has three phases:1. Design the Product or Component2. Optimize the Design3. Validate the Design

DESIGN FOR QUALITY PHASES

Design the Product or Componento Complete System Architecture analysis. The focus should be placed

on identifying the architecturally significant requirements, tracing the requirements to their owners, analyzing reusable components at their interfaces, selecting, assessing and accepting the system architecture.

o For each tasks, a list of risks and opportunities must be updated as the architecture is refined.

o Complete technical concept generation.o Complete concept DFMEA.


Design the Product or Componento Complete system and component level Design.o Complete P-diagrams, identify ideal functions, error states, control

factors, noise factors.o Conduct system and component DFMEA’so Address failure modes in order of severity and then in order of the

product of severity by occurrence.o Implement actions to reduce severity of failures identified as critical

and unavoidable by altering primary failure modes.


Optimize the Designo Eliminate unacceptable failure modes, including but not limited

to high severity modes.o Substitute high severity failure modes by lower severity failure

mode.o Document trade-offs.o Iterate the designs through CAE and physical testing using

component and system level testing until reliability is established.


Validate the Design (Testing)o Critical noise factors (internal and external) must be

included in the tests.o Duty cycle must be correlated to real life usage.o Tests must be run to failure to verify that the system failed

as intended and that the system is able to perform the protected functions under the test simulated conditions.

o Failure modes (primary, secondary,…) must be analyzed.o Teardown analysis are too often neglected. All parts must

be inspected to properly assess the failure mechanisms.o Product validation starts at the component level and ends

at the full system level.


Design for Quality should be considered throughout the PD cycle:

o Early - to develop "product concepts" which are well suited for production (i.e., conceptual product design)

• Gain the maximum benefit from the entire process

• Define intended functions, requirements, and noises to support the cascade process

o Continually - to ensure that the chosen product concept is implemented through optimal component design

• DFR should be conducted throughout the entire PD cycle.

DESIGN FOR QUALITY TIMING

Cascad

e and

Cascad

e and

Balan

ce Targets

Balan

ce Targets

Inte

gra

te a

nd

Inte

gra

te a

nd

V

erif

y D

esig

ns

Ver

ify

Des

ign

s

Phase II

Phase II

Phase IPhase I

Phase IIIPhase III

QUALITY DESIGNSDESIGNS

DefineDefineCustomer/System Requirements

Total System

Confirmation

DESIGN FOR QUALITY – THE SYSTEM V

PFMEA CONTROL PLAN

PROCESS DESIGN

BOUNDARY DIAGRAM

INTERFACE MATRIX

P-DIAGRAM

DFMEARELIABILITY CHECKLIST

ROBUSTNESS DEMONSTRATION

MATRIXDVP

PRODUCT DESIGN

DESIGN FOR QUALITY PROCESS FLOW

QUALITY HISTORY

WHAT IS QUALITY HISTORY AND WHY DO WE NEED IT?

• Research into the history of the system or component under development

• Identify opportunities (Close the gap on competition)

• Establish priorities(Establish weaknesses from data)

• Help set targets(What is it supposed to do)

• Financial reasons(Warranty costs, impact on sales)

• Improved efficiency (Not repeating the same errors)

QUALITY HISTORY

QUALITY HISTORY – LINKS TO OTHER FMA TOOLS

QUALITY HISTORY

WHY WE NEED QUALITY HISTORYQuality History

Failures

Effects of Failure

Problems with Target

Transformation characteristics badly defined

Functional Failure

Hardware Failure Modes

Target misses

customer want

Diverted Output

Classifying Customer Failures

Consequences

Potential Failure Modes

Cause of Failure

“It doesn’t work “It came off in my hand”

“I got soaked”

“It gets hot when it’s running”

“it doesn’t do it

when I want”

“it doesn’t do what I

expect”

QUALITY HISTORY

QUALITY HISTORY MATRIX EXAMPLE

Commodity

Core Engineer

Date reviewed/ Update

d

Issue

VEHICLE / ENGINE / TRANSMISSI

ON

MY

CAUSAL PART

CONCERN / FAILURE / SYMPTOM

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

IND

ICA

TO

RS

Part / Attribute Identification

Symptom / Failure Effects

Magnitude /Severity

QUALITY HISTORY

PRE-REQUISITES TO PERFORM ANALYSIS

To develop Quality History you will need the following…

• Warranty data

• Market Research

• Campaign Prevention Review

• Manufacturing data

• Service contact

• Test data

• External Media

QUALITY HISTORY

GATHERING DATA

Data gathering exercise:

How many Product Quality Indicators can you name…?

- Warranty - Consumer Research

- Manufacturing

- Service

- Product Development

- Public Domain/Media

QUALITY HISTORY

• Look at all sources- All data sources have blind-spots

• Understand the limitations of sources - Customer verbatim will only report squeaks from the

front of the vehicle, no detail!

• Use all metrics in data source - Can you see total costs and/or repair counts?

• Update matrix in real time for best results - Keep up to date so issues are not forgotten or lost and

are documented when top of mind

GATHERING DATA – USING SOURCES

Throw a wide net for data QUALITY HISTORY

• Data source summaries only indicate the presence of an issue

- They do not give any indication of Root Cause

• Summaries don’t tell you the importance of a problem

- Read customer verbatim for more detail

- Understand indicator & breakdown of issue

ANALYSING DATA

QUALITY HISTORY

Identify & Categorise unique issues:

Source data may include many problems:

- Are the problems distinct or unique in the description?

- Do unique problems exist in a subset of the sample

- Is it seasonal?

ANALYSING DATA

Find, Filter, Select

QUALITY HISTORY

Prioritise if many failures are identified:

• Identify every safety critical problem - Review all Campaign Issues

• Pick top X for each data source - Which issues cover 80% of

metric?

• Set a threshold for each data source & metric: - Warranty Data - R/1000 or CPU - AIMS - severity category

ANALYSING DATA

QUALITY HISTORY

Describe the problems you see:

• What does the customer experience? - Is that what we expect it to do? (Check Function versus target setting)

• Describe the condition when the problem occurs - What, Where, When, How big?

• Confirm the profile of the problem: - Was this a spike? - Is this a High TIS wear-out or an issue caused in the

factory?

Analysing Data

QUALITY HISTORY

Drilling Down

Identify the Root Cause(s) of the Failure - know where to look!

- Plant based PVTs are a good source of root cause data….will be tracked on VQR single agenda

- Parts Recall Centre (PRC)

- Dealerships will be more useful for Warranty issues

QUALITY HISTORY

Drilling DownTest if the Root Cause is fully defined

- Try the ‘5 whys’ technique as example

Problem statement

Cause

Cause

Cause

Cause

Root Cause

WHY?

WHY?

WHY?

WHY?

WHY?

QUALITY HISTORY

What exactly is going on?

• Check what investigations are on-going? - What 8D’s are available? Is 6-Sigma involved?- Don’t duplicate effort!

• What mechanism causes the part to fail? - What is the weakness in the design?

• What led to targets not being achieved? - Were they ever achieved? even on test?

Drilling Down

QUALITY HISTORY

• What actions will prevent re-occurrence?

- Quality History should be constantly updated

• Take actions that will last:

- Revise Design Rules

- Update D-FMEA’s

- Revise Test Methods

- Challenge Specifications

- Develop Robustness Strategies

Feed Forward

QUALITY HISTORY

BOUNDARY DIAGRAM

What does a boundary diagram do?■ Defines the scope of the system being studied■ Identifies components that are internal to the system■ Identifies system-system, system-human and system-

environment interfaces (External Components)■ Defines the scope of the DFMEA i.e. elements within the

boundary■ Indicates the nature of all interface relationships■ Represents all of the above in a clear graphical manner

BOUNDARY DIAGRAM

Interface Analysis

Robustness Demonstration Matrix

RDM

FMEA

Boundary Diagrams

Quality History

DVP

Function Analysis

Engineering with Robustness Linkages

P-Diagram

Robustness Checklist RCL

BOUNDARY DIAGRAM

BOUNDARY DIAGRAM

Why create a boundary diagram?■ Provide a disciplined approach to ensuring all

system interfaces are considered at design initiation

■ Understand the nature of interface relationships i.e.

▪ Physically touching (P)▪ Energy transfer (E)▪ Information transfer (I)▪ Material exchange (M)

■ Communication tool which facilitates team understanding and collaboration

BOUNDARY DIAGRAM

BOUNDARY DIAGRAM

How to create a boundary diagram?■ Identify components within the system as

blocks■ Establish relationships between the various

blocks■ Establish intra-system and system/component

relationships, including customer inputs■ Construct a boundary line around what should

be included in the analysis of the system■ Boundary diagram analysis should follow

system hierarchy down to the desired sub-system, component level

BOUNDARY DIAGRAM

• Use a hierarchical approach for the complete seat assembly

ElectricalHarness (B2)

Seatbelt (B3)

Console (B11)

Throw in mats(B10)

CushionAssembly(A1.0)

HVAC ducts (B5)

Headliner (B8)

Door Casing (B7)

Carpet (B9)

B PostFinisher (B6)

CurtainAirbag (B12)

BIW floor (B1)

Rear SeatAssembly (B4)

Head RestraintAssembly(A3.0)

SquabAssembly(A2.0)

In System Direct Interface

Indirect Interface

Direct Interface

In System Indirect Interface

Example a Boundary Diagram

BOUNDARY DIAGRAM: KEY LEARNING POINTS

• Defines scope for analysis

- identifies potential team members

• Foundation for: Interface Matrix, P-diagram and key tools DFMEA or Robustness study

- mandatory component of a D-FMEA

• Identifies Interfaces with other Systems

- aid to developing DFMEA and Robustness studies

• System, Sub-system and Component levels can be applied

- System hierarchy should be clear

BOUNDARY DIAGRAM

INTERFACE MATRIXWhat?■ Provides a supplemental analysis of the boundary

diagram■ Quantifies the strength of system interactions ■ Provides input to the Potential Effects of Failure and

Severity column of the DFMEA■ Robustness linkage to the P-Diagram

■ Positive interactions may be captured on the P-Diagram as input signals or output functions

■ Negative interactions may be captured on the P-Diagram as input noise or error states

Why?■ Cross-check boundary diagram interfaces■ Verify positive interactions■ Manage negative interactions for robustness

■ Interfaces of modern electrical systems are not easily done in this format, the use of SE/SA tools of PREEvision and Rhapsody, others are emerging to address this.

INTERFACE MATRIX

INTERFACE ANALYSIS – LINKS TO OTHER FMA TOOLS

INTERFACE MATRIX

INTERFACE MATRIX

How?■ List all elements within the boundary diagram and all

elements that interface across the boundary in the leftmost column of the Interface Matrix sheet

■ Fill the 4 quadrants (Q1-Q4) representing the interface relationship (P, E, M, I) between the elements of the Boundary Diagram with a rating from -2 to +2

2 = Necessary for function 1 = Beneficial but not absolutely necessary for function 0 = Does not affect functionality-1 = Causes negative effects but does not affect

functionality-2 = Must be prevented to achieve functionality

INTERFACE MATRIX

TYPES OF RELATIONSHIPS

• P – physically touching.• welded, bolted, clamped, etc

P E

I M

• E – energy transfer.

• Torque (Nm), heat, etc

• I – information transfer.

• ECU, sensors, signal, etc

• M – material exchange.

• cooling fluid, exhaust gases, etc

INTERFACE MATRIX

RELATIONSHIP STRENGTHS

+2 = Interaction is necessary for Function. (Part A is bolted to part B)

+1 = Interaction is beneficial, but not absolutely necessary for Functionality.

(Quick release switch on electrical lead)

0 = No interaction / interaction does not affect functionality

-1 = Interaction causes negative effects, but does not prevent Functionality (Upper link touches lower link causing

squeak)

-2 = Interaction must be prevented to achieve functionality (Suspension strut fouls Wheel arch lining)

INTERFACE MATRIX

INTERFACE MATRIX - HOW TO COMPLETE

• Enter Components (blocks) into the matrix

• Look at where components should, or could, physically touch

• Enter the relationship strength

• These interactions are useful for P-Diagram noises

• Positive interaction ratings should be reviewed against the system functions

• Negative interaction ratings should be considered as potential causes in the DFMEA

INTERFACE MATRIX

Interface Matrix Example

INTERFACE MATRIX

INTERFACE ANALYSIS: KEY LEARNING POINTS

• Provides information to the P-diagram and DFMEA

• Positive interaction ratings should be reviewed against the system Functions

• Negative interaction ratings should be considered as possible causes in the DFMEA

• Examine interactions with items outside your scope, which may affect the Functionality of your system

• Establish an ownership contract for interfaces from your system to another

INTERFACE MATRIX

P-DIAGRAM

What?■ A graphical tool to identify the operating

environment in robustness focused analysis

■ Provides a structured method to identify:■ Intended Inputs (Signals)■ Intended Outputs (Ideal Function)■ Unintended Inputs (Noise Factors)■ Unintended Outputs (Error States)■ Design Controllable Factors

P-DIAGRAM

Parameter(P)-Diagram

System Function

InputSignal

OutputResponse

Parameters which influence system variability,but are difficult, expensive or impossible to control

Noise Factors

Control FactorsParameters whose nominal values can be adjusted by

the engineer, ideally with minimal impact on cost

Error States

P-DIAGRAM

P-DIAGRAM LINKAGE TO OTHER ENGINEERING TOOLS

Function Potential Failure Mode

Potential Effect of Failure

Potential Cause of Failure Mode

DetectionPreventionRecommended Action

Current Design Controls

Here we can see the linkage from the P-Diagram to the DFMEA header.P-Diagram also feeds into the RCL, RDM & DVP.

Failure Modes

Noises

P-Diagram

Control Factors

Function Description

Boundary Diagram

Diverted Output

Interface MatrixQuality History

P-DIAGRAM

P-DIAGRAM

Why?■ Brainstorming tool that supports

downstream noise factor management strategies (RCL) and verification methods (RDM/DV)

■ Links to the Function, Potential Failure Mode and Potential Effect of Failure columns of the DFMEA

P-DIAGRAM

P-DIAGRAM

What?Noise factors are classified as:■ Demand related noise which are external to the

design■ Piece-to-Piece Variation (N1)■ Changes Over Time (N2)

■ Capacity related noises which are internal to the design

■ Customer Usage (N3)■ External Environment (N4)■ System Interactions (N5)

P-DIAGRAM

P-DIAGRAMHow?■ P-Diagrams should support the scope of the system defined in the

Boundary Diagram

■ Input & Output Signals: Identified in terms of physics as positive interactions in the Interface Matrix

■ Noise Factors (N1-N5) & Error States: Identified in terms of physics as negative interactions in the Interface Matrix. Brainstorming should be applied to supplement identification of Noise Factors

■ Error States: Undesired function. Quality History should be used to supplement identification of error states

■ Control Factors: List of design factors that can be controlled in design i.e. materials, dimensions, location etc.

P-DIAGRAM

Terminology & Concepts

• Ideal Function: primary intended function of a design (e.g., in mechanical engineering it is often energy related, since the intended function is usually about moving or stopping something).

• Signal Factor: the energy which applied to the engineering system (either by the customer, or by a neighboring system) to make it work.

P-DIAGRAM

Terminology & Concepts

• Control Factors: features of the design that can be changed by the engineer (dimensions, shapes, materials, positions, locations etc).

• Noise Factors: sources of disturbing influences that can disrupt ideal function, causing error states which lead to quality problems. Noise factors can be categorized into five categories:

1. Piece to Piece Variation2. Customer Usage3. Degradation Time/Mileage4. Environmental Usage5. System Interaction

• Error state: is an undesirable output of the engineering system (we can also call these failure modes), characterized by 1) variation in ideal function (soft failure), 2) degradation in ideal function (soft failure), 3) or loss of ideal function (hard failure).

P-DIAGRAM

Input Signals

• Identify interfaces that generate a reaction e.g. neighbouring systems, user, power source

• Specify measurable dimensions• Input signals are mostly given and cannot be changed

• What starts the function happening?

• What controls the magnitude of the response?

What you put in to make it happen

RELATE INPUT TO OUTPUTS

P-DIAGRAM

Desired Output/Response

Is the intended output of the commodity…

• Can be adjusted by control factors

• Can be influenced by noise factors

• Must be measurable

What you want from the system

RELATE INPUT TO OUTPUTS

P-DIAGRAM

Control Factors:

• Can be changed or adjusted •Are design parameters which affect the system output •Are design parameters within the system boundary

What you can do to make it happen

DETAIL THAT YOU CAN CONTROL

P-DIAGRAM

WHAT MUST YOU TOLERATE?

Noise Factors Unwanted disturbances that can change performance

• Noises are influences which you cannot control, or are difficult or expensive to control

• Noise can influence levels of Output/Response- Sensitivity to noise can give rise to unacceptable system behaviour – Failure Modes or Diverted Output

All vehicles are subject to the same environment – some fail because they are more sensitive to it

Noises are split into 5 categories….

Don’t worry about which category it goes in, identifying the noise is priority

What interferes with getting what you want?

P-DIAGRAM

• Noise Factors are sources of disturbing influences that can disrupt the ideal function, causing error states which lead

to quality problems.• Noise factors can be categorized into five

categories– Piece to Piece Variation– Customer Usage– Degradation due to Time/Mileage– Environmental Usage– System Interaction

P-DIAGRAM

WHAT ARE NOISE FACTORS?

EFFECTIVE DESCRIPTIONS

Be precise in your Function Description !

• Functions must be described by Verb / Noun combination and should be measurable

• What do you need to measure?

• What are all the characteristics that relate to a Function?

P-DIAGRAM

EFFECTIVE DESCRIPTIONS

• What properties or characteristics are associated with a Function?

• When should it do it?

• What are the limits of performance?

• How quickly should it respond?

• What is the nature of the relationship?

Improving the Description of Functions

Raise the Loadrest – 92-355mm in 113 turns = 3.14mm per turn*

Raise the Loadrest – 92-355mm

Raise the Loadrest - mm

Raise the Loadrest – to 355mm

Raise the Loadrest – 92-355mm in 113 turns

P-DIAGRAM

Types of Noise Factors(That Disrupt Ideal Function)

Operating Environment

1) Piece-to-piece variation of part dimensions

2) Changes over time/mileage in dimensions or strength (such as wear out or fatigue)

3) Customer usage and duty cycle

4) External (climatic and road conditions)

5) Internal , due to: a) error states being received as noise factors from neighboring sub-systems. b) unresolved design issues related to neighboring sub-systems.

NOTE: effects of noise factors can sometimes be represented or captured by others

Inner Noises

Outer Noises Conditions of use

P-DIAGRAM

Functiony = f(x)

Input

Desired Output/ Response

Noise Factors

Control Factors

What you put in to make it happen

What you want to happen

What you want from the system

What you don’t want from the system

What you can do to make it happen

What interferes with getting what you want

Diverted Output (Error State)

Understanding Function

Use P-diagrams to optimise output

• Maximise or Stabilise Desired Output

• Minimise Diverted Output

P-DIAGRAM

• What are P-Diagrams?

- Illustrate delivery of an engineered response- Versatile tool for analysis and generating ideas

Take care when re-using P-Diagrams!

• Analyse Functions One-at-a-Time - Too many factors confuses analysis

• Consider Conservation in the transformation - Energy is an ideal case, also consider movement, force, material, information

• Apply P-Diagrams when you study and optimise Output - Maximise Output, Reduce Variability, Minimise Diverted output

P-DIAGRAM

P-DIAGRAMS: KEY LEARNING POINTS

12/26/13

Concerns: high window effort, handle broken, high TGW and warranty

Automotive Window System Example

P-DIAGRAM

12/26/13

Door Glass Lifting System

Noise Factorsl Glass Run Thickness Variabilityl Customer Usage / Duty Cyclel Wear or Cyclesl Temperature / Environment / System Interfaces

Control Factorsl Clearance of Glass to A-Pillar Channell Clearance of Glass to B-Pillar Channell Glass Run Shapel Glass Run Thicknessl Regulator Angle

Signal

M = Motor Voltage

Response

y = Velocity orTorque

Automotive Window System ExampleEngineered System P-Diagram

P-DIAGRAM

DFMEA

What?■ A tool which supports activities that

recognize and evaluate potential failure modes of a product and the associated effects

■ Identifies actions which could reduce or eliminate the chances of the failure occurring

■ Documents the analysis process

FMEA

TYPES OF FMEAs

• Concept FMEA: performed on designs and processes• Design FMEA: Standardized in the automotive industry but

applicable to any design• Process FMEA: Standardized in the automotive industry but

applicable to any design

Each of these can be applied to a system, sub-system or component.

FMEA

CONCEPT FMEA BENEFITS AND USES

• Lists potential concept failure modes and causes• Lists design actions to eliminate causes of failure modes, or

reduce their rate of occurrence• Aids decision on which concept to choose• Specifies operating parameters as key specifications in the

design

FMEA

DESIGN FMEA BENEFITS AND USES

• Aids in the objective evaluation of the design• Increases the probability that potential failure modes have been

considered• Provides future reference (lessons learned) to aid in analyzing

field concerns• Helps identify potential Critical and Significant Characteristics• Helps validate the Design Verification Plan

FMEA

PROCESS FMEA BENEFITS AND USES

• Identifies the process functions and requirements• Identifies potential product and process related failure modes• Identifies the potential manufacturing or assembly process

causes• Identifies process variables on which to focus process controls• Aids in development of thorough manufacturing or assembly

control plans• Focuses on potential product failure modes caused by process

deficiencies

FMEA

FMEA

Why?• Using the FMEA as a disciplined technique helps

identify and minimize potential concerns. One of the most important factors for the successful implementation of an FMEA program is timeliness. It is meant to be an "before-the-event" action, not an "after-the -fact" exercise.

FMEA

DFMEA

Why?■ Determine how failure modes will be avoided in design■ Allows the engineer to recognize high priority/high impact failure modes

and prevent them from occurring■ Improve the robustness of the DVP and process control plans■ Document history of design changes and rationales■ Improves the quality, reliability and safety of the product or process■ Reduces product re-development timing and cost ■ Documents and tracks actions taken to reduce risk■ Aids in the development of robust control plans■ Aids in the development of robust design verification plans■ Helps prioritize and focus on eliminating/reducing product and process

concerns■ Improves customer satisfaction

FMEA

When is the FMEA Most Useful?

• There are three basic cases for which FMEAs are generated, each with a different scope or focus:

• Case 1: New designs, new technology, or new processes.

• Case 2: Modifications to existing design or process. The scope would focus on the modification to design or process, possible interactions due to the modification, and field history.

• Case 3: Use of an existing design or process in a new environment, location, or application. The scope is the impact of the new environment or location on the existing design or process.

FMEA

When is the FMEA Most Useful?

• To achieve the greatest value, the FMEA must be done before a product or process failure mode has been incorporated into a product or process. Thus, it can reduce or eliminate the need of implementing a corrective change at a later point in time.

FMEA

DFMEA

How?1. Review the Design and Interfaces

2. Brainstorm potential failure modes – Review existing documentation and data for clues

3. List potential effects of failure

4. Assign Severity rankings – What is the severity of the consequences of failure? Failures with severity 9 and 10 are potential critical characteristics. Failures with severity 5 thru 8 are potential significant characteristics.

5. Assign Occurrence rankings – How frequently is the cause of failure likely to occur?

6. Assign Detection rankings – What are the chances that the failure will be detected prior to the customer finding it?

7. Calculate the RPN – Severity x Occurrence x Detection

8. Develop the action plan

9. Take Action

10. Calculate the resulting RPN

FMEA

P-Diagram

Linkage

Boundary

Diagram

Linkage

Interface

Matrix

Linkage

DFMEA: ROBUSTNESS LINKAGES

FMEA

How to Complete an FMEA

• 1) Define the functions, features and requirements. This can be visualized, e. g. with the help of a process flowchart.

• 2) List the failure modes (e.g. no function, partial function, intermittent function, unintended / degraded function)

• 3) Define the possible effects.• 4) Assess the impact of an effect on the customer

(How bad is it?). Each effect would get a severity ranking* from 1 (None) to 10 (Hazardous without Warning).

FMEA


• 5) Identify possible causes for each malfunction. These can be identified via a Cause-Effect diagram (Ishikawa)

• 6) Quantify how often a failure mode could occur. The occurrence evaluation criteria* would range from 1 (remote, failure is unlikely) to 10 (very high, persistent failures).

7) Identify current design (for DFMEA) and process (for PFMEA) controls to detect the failure modes.

FMEA


• 8) Assess how good the identified method is at detecting. The detection evaluation criteria* would range from 1 (very high) to 10 (almost impossible).

• 9) Calculate the Risk Priority Number (RPN) = Severity x Occurrence x Detection.

• 10) Failure modes with a severity of 9 or 10 should be treated first. Failure modes, with the highest product of Severity by Occurrence, should be addressed next. The rest should be addressed in decreasing order of RPN. Actions could comprise design changes, process changes, special controls and / or changes to standards, procedures or guides.

FMEA


• 11) Assign responsibilities and target completion dates to each action. Document action taken appropriately.

• 12) Re-calculate the RPN of the action results. All revised ratings should be reviewed and if further action is considered necessary, repeat the analysis. The focus should always be on continuous improvement.

FMEA

WHEN IS AN FMEA Started or Updated

• Design FMEA should be initiated before or at finalization of design concept

• Design FMEA should be continually updated as changes occur or additional information is obtained

• Process FMEA should be initiated before or at feasibility state and prior to tooling for production

• Design and Process FMEA are living documents

FMEA

DFMEA: HOW?

FMEA

7 5 4

FMEA

SEAT CUSHIONSupport 200Kjounce cycles(90cpm) of 50thpercentile malebutt formloaded to 200 lbswith seat sag <25mm

Seat sag >25mm Poor appearanceCustomer discomfort

5 Inadequate foamdensity and ILD

3 D: DV Jounce Testing

2 30

DFMEA EXAMPLE

RISK PRIORITY NUMBER (RPN)

• Is the Product of Severity (S), Occurrence (O) and Detection (D) ranking

RPN = (S) x (O) x (D)

• Within Ford we do not use RPN threshold figures, however the value can be used for ‘Pareto’ type analysis

FMEA

LINKAGES AND OUTPUTS

• DFMEA detection controls contribute to a DVP’s ability to detect potential failure modes

• Current design controls feed into the RCL verification methods

• Recommended actions to modify the DV testing must be fed into the DVP & RCL

• Potential effects of failure YC’s/YS’s feed into the PFMEA and Control Plans for the manufacturing process via SCCAF

FMEA

FUNCTIONAL VS. HARDWARE APPROACH TO DFMEA

Listing of Functions for the assembly e.g.:

Transmit energy as torque of 2000 N and speed of 3000rpm

Listing of hardware parts e.g.:

Part A → Gear 1

Part B → Gear 2

Functional Approach:

Hardware Approach:

FMEA

HOW TO DEFINE FAILURE MODES(BASED ON “WHAT COULD GO WRONG”)

Describe in technical terms what Failure you could observe from your Component or System.

Describe the offset from target.

Note:Don‘t describe causes! Do not write:

“partial function”….

Write: “heater does not

achieve temperature x deg.C in time T…”

FMEA

FUNCTION FAILURE MODE DESCRIPTION

Time, Mileage or Cycles

Function

0 %

No Function

100 %

FunctionWhen?

Examples:- A/C compressor does not transport refrigerant on demand- Starter Motor does not engage to fly wheel at key on- Remote Key fob signal not transmitted on demand- Rear view mirror adjustment stuck

Function fails operating completely and does not recover without intervention

FMEA

Function When?


0 %

100 %

Partial Function 80 %

Function

Ho w

mu

ch ?

Function operates at an abrupt reduced level and does not recover without intervention

Examples:- A/C compressor transports less refrigerant than required- Starter Motor does not fully engage to fly wheel- Remote Key fob signal is only transmitted by less than 1metre, should be greater than 5 metres- Rear view mirror visibility reduced


FMEA


Function

0 %

100 %

Over Function110 %

FunctionWhen

?

Ho

w

mu

ch?

Function operates at an abrupt increased level and does not recover without intervention

Examples:- A/C compressor transports too much refrigerant than required


FMEA

Function


Function

0 %

100 %

Degraded Function b)

When?

H o w

m uc

h?

Function slowly reduces / increases and does not recover without intervention.

Examples:- A/C compressor transports a lesser amount of refrigerant than required- Wiper blade cleaning quality reduces- Brake pedal travel increases


FMEA

Function

0 %

50 %

120 % 100 %

When?

Ho

w

mu

ch

?

How long?


Function operates, then fails and recovers without intervention

Examples:- A/C compressor transports refrigerant at reduced levels and fully recovers - Lights flicker- Remote Key fob signal sometimes transmitted


FMEA

Function

Function0 %

100 %Unintended Function

50 %


Function operates, when input or signal is missing

Examples:- A/C compressor transports refrigerant without the customer activating the A/C system- Starter Motor engages fly wheel without customer starting the engine- Remote Key fob signal transmitted without pressing button- Airbag activates without accident


FMEA

POTENTIAL EFFECTS OF FAILURE

• Effects are the inevitable consequences of a Failure Mode:

1:1 relationship exists between Effects and Failure Modes

No Failure Mode -> No effect

•Potential Effects of Failure should be considered against the

following list:• Parts or subcomponents• Next higher assembly• System• Vehicle• Customer• Government regulations

FMEA

CHARACTERISTIC CLASSIFICATION

FMEA

POTENTIAL CAUSE(S) / MECHANISM(S) OF FAILURE

• Causes explain why the failure (eg high efforts after long periods of inactivity) occurred (eg screw seized within jack pivot)• Mechanism of Failure explains why the cause happened (eg corrosion due to lubrication migration from screw thread due to high temperatures) (remember the 5 why’s from Quality History) Where can causes be found:• Quality History Matrix needs to be reviewed to identify potential causes of failure• The Outcome of brain storms are useful sources of information from team meetings or corridor conversations• Negative relationships identified in Interface Matrix • Sensitivity to the Noises demonstrated in the P-Diagram

FMEA

DFMEA CURRENT DESIGN CONTROLS: PREVENTION

• Design parameter ‘norms’

• Lessons Learned

• Design Guides (eg best practices, rules of thumb)

• Legal Standards

• Computer Models Programs

• Analytical Tolerance Studies

• Campaign Prevention Sessions

• Design Reviews

These are possible Prevention Methods:

FMEA

DFMEA CURRENT DESIGN CONTROLS: DETECTION

This is what we need to find out to detect Failures

They are the investigations we need to perform:

• Answers to be found ?

• Values to be established ?

• Calculations to be performed ?

• Operating ranges to be established ?

FMEA

DFMEA CURRENT DESIGN CONTROLS: DETECTION

• Analytical Calculations•Finite Element Calculations• Thermal Aero System Engineering Calculations•Existing and proven test methods

• Physical hardware / prototype testing

Note• Carried out on component, subsystem, system or vehicle level• Should be listed as tests

These are possible Detection Methods:

FMEA

LINKAGES DFMEA WITH PFMEA

Effective Robustness Checklist RCL - Robustness Part II

Robustness Demonstration Matrix

DFMEA

P-Diagram Robustness Part I

Boundary Diagrams

Quality History

DVP

Interface Analysis

Function Analysis

YC / YS

Control Plan

For Prototype Builds

Control Plan

For Vehicle Assembly

PFMEA

FMEA

LINKAGES DFMEA WITH PFMEA

FMEA

DFMEA RECOMMENDED ACTION

What it is:

Use Recommended Actions to improve the Design, Detection Controls and Communications.

Should be considered when occurrence and/or detection rating is too high (eg greater than 4)

Reduce the Risk of your Design:Reduce or eliminate the risk of Failure Modes occurring, by applying Prevention Controls i.e Control Factors from P-diagram.

Improve your Testing:Upgrade your Detection Controls by timing, test sensitivity and/or adjustment to noise factor levels in an application that identify the weakness (failure modes) i.e. improved DVP.

FMEA

DFMEA RECOMMENDED ACTION EXAMPLE

Det RPN

Recommended

Action

Responsibility & Target

Completion DateAction Results

Actions TakenO

c

D

e

R

P

125

2 505Design Engineer

Design Engineer

Design Engineer

Update test, RCL & DVP

Introduce grease

SDS Updated

5Notes from Design Review.

Consider resilience of grease to higher temperatures?.

Update testing to include specific noise factors, condensation, usage cycle (long periods of inactivity), and high temps.

Release new grease with greater resilience to higher temperatures for application

Update Design guides and SDS with recommendations and specifications and add into Prevention column to reduce Occurrence rating

Only update new Ratings if Recommended Actions are to be implemented on this program.

2 2 20

FMEA

DFMEA LINKS TO OTHER ENGINEERING TOOLS

Workshop D – D-FMEA

Function Potential Failure Mode

Potential Effect of Failure

Potential Cause of Failure Mode DetectionPrevention

Recommended Action

Current Design Controls

Interface Matrix Interface Matrix

Function Analysis

P-DiagramP-DiagramP-Diagram P-Diagram

Robustness Check List

Robustness Check List

RDM & DVPRDM & DVP

Quality History Quality History Quality History Quality History Quality History

Boundary Diagram

Boundary Diagram

Boundary Diagram

Interface Matrix

Function Analysis

P-Diagram

FMEA

What?■ Captures noise factors and error states

identified in the P-Diagram

■ Identifies areas that require design based noise factor management strategies

■ Indicates verification methods which provide the ability to test for the error states associated with the noise factors

RCL

ROBUSTNESS CHECKLIST (RCL)

Why?■ Initiate team discussion regarding noise factor

management strategy (NFMS) and robust verification

■ Focus on noise factors which have the highest impact on system robustness

■ Understand the correlation between the error states and associated noise factors

■ Assist robust verification by identifying noise factors which are currently not captured by existing DVM’s

RCL


RCL


Step 1: Choose ideal functions

Step 2: Choose focused error states

Step 3: List associated noise factors

Step 4: Define

metric and

range for

each noise

factor

Step 5: Assess strength

of correlation

between error state

and noise factor

Step 6: Define NFMS

Step 7: List

applicable

DVM’s

Step 8: Use an X

to show

error states

identified

by DVM. Identify

High Impact DVM’s

Step 9: Use an X

to show

noise factors

included in the

DVM

RCL

RCL: HOW?

RCL

SEAT SYSTEM RCL

What?■ Planning tool that documents:

■ Design Verification Methods (DVM) ■ Level Tested■ Acceptance Criteria■ Test Timing

■ RDM is a subset of the DVP that documents:■ Failure Mode (Hard or Soft)■ DVM for select tests specified by the RCL■ Noise Factors being tested ■ Robustness targets in relation to customer expected

function. Targets of R/C (R90/C90) are not acceptable

RDM/DVP

RDM/DVP

WHY?■ Demonstrates that components/systems fulfill

reliability requirements identified in the RCL ■ Provides a forum to review the high impact error

states and noise factors that affect the system along with the identified DVM to prove out their system

■ Structured documentation of verification test plans and timing

■ Provides single point summary of test plansRDM/DVP

RDM/DVP

FROM RCL

RDM/DVP

RDM: HOW?

RDM/DVP

DVP: HOW?

• Define the useful life of the product and its failures.

• Develop customer satisfaction criteria for all types of uses/ misuses (additional failures).

• Develop products or processes that meet the failure mode and is robust against different sources of variation

• Address new technology or existing technology in new environments against the failure mode

• Design the product so that its failure has the least impact on the user.

• Many CAE models have limited capability to represent real-world noise; therefore, surrogate noise based on engineering knowledge is required.

• Precise reliability estimates require precise knowledge of statistical distributions of noise factors.

– As a contrast, comparative reliability assessments and robust design require only approximate knowledge of statistical distributions.

CONCLUSIONS

• Prototype designs work, problems show up later

• Diagnostics are highly efficient in finding solved problems

• Murphy’s law applies 95% of the time. The other 5% we are on coffee breaks

• Testing plan must have management's full commitment and support if it is to succeed

• In practice, many analytical (CAE) models are focused on the error states (NVH, fatigue, etc.). It is important to be cautious that reducing one error state does not generate other error states.

• Many CAE models have limited capability to represent real-world noise; therefore, surrogate noise based on engineering knowledge will be required.

• In early product development, when the impact of robust design can be greatest, design objectives and constraints are still imprecise.

CONCLUSIONS

• Concentrate on Ideal Function and establish a way to measure it; do not use symptoms of poor quality.

• Identify sources of the five types of noises an expected magnitude; remember system interactions.

• Concentrate on the effects of the noises; maybe one noise can be used to represent others.

• Understand how error states and noise factors cross system interfaces and boundaries; establish contracts with neighboring systems.

• Plan a robustness assessment of current design to compare against ideal performance.

• Where robustness improvement strategy is obvious from knowledge of physics, DO IT!

CONCLUSIONS

• Many CAE models are computationally expensive (both preparation time to set up the model and computing time

• It is often desirable to study a large number of design variables within a large design space; in this situation, nonlinear relationships between input (design variables) and output (performance) will be commo

• Many CAE models focus on “error states” (e.g., fatigue, vibration, noise); therefore, a multi-objective optimization is often needed

• Develop a noise factor management strategy; Removing the noise might be easier than becoming robust to it. The laws of physics are strict.

• Work out how to include remaining Noise Factors in all tests in the DVP.

• Where robustness improvement is not obvious, plan parameter design studies (using DOE if necessary) to discover the improvement.

CONCLUSIONS

When Failure is an Option: Redundancy, reliability and regulation in complex technical systems – John Downer

FRG, Module 18, Ford Automotive Operations – Quality, 1999.

Robustness Thinking & Robust Engineering Design, Ford Motor Company Quality Office, Quality & Reliability Implementation Group, August 2000; Edition 7.01.

FAO Reliability Guide PD Useful Life Reliability Commitment Edition 4, Ford Automotive Operations – Quality, 1996,1997,1998.

Ford Design Institute, The Robustness Imperative, Ford Motor Company, 1993

REFERENCES

(RPDP) Robust Product Development Process, One of Six Powertrain “Breakthrough Initiatives” Ford Motor Company, Release 1.0, June 1996

Ford Design Institute, Robustness: Parameter Design, Ford Motor Company, January 1998.

Don Clausing, Total Quality Development, 1994.

AR&R http://www-c3s.pd9.ford.com/vehs/arr/index

Nam P. Suh, The Principles of Design, Oxford University Press, Inc., New York, 1990

REFERENCES

Reliability - Ford Design Institute

Ford Reliability Class – T. P. Davis, V. Krivtsov/ VKRIVTSO

http://www.reliabilityanalysislab.com/ReliabilityServices.asp

U.S.: R.L. Polk Vehicles in Operation Report June, 1997 Europe: New Car Buyer StudyEuropean Buyer - Big Five Survey 1995

Ford's Strategy in Reliability (Prof. Tim Davis)

http://pms401.pd9.ford.com:8080/arr/concept.htm

REFERENCES

The Art of System Architecting, M. Maier & Rechtin, 2nd edition, CRC Press, 2000

Systems Architecting of Organizations, CRC Press, 2000

Product Design and Development, Karl T. Ulrich and Steven Eppinger, 2nd edition

Mechanics of Materials, A. Higdon, E. Ohlsen, W. Stiles, J. Weese, W. Riley; John Wiley & Sons, Inc, 4th Edition, 1985

Mechanical Engineering Design, Joseph Edward Shigley, Charles Mischke; McGraw-Hill, Inc, 5th Edition, 1989

REFERENCES

Smead, David. “Vessel Networking #2.” On-line posting. 8 May, 2007. Available: http://www.amplepower.com/dave_blog/2/vessel_networking_2.pdf

Greene M.D., Alan. “A Tragic Lesson.” On-line posting. 20 Aug, 2003. Available: http://www.drgreene/com/21_1660.html

“Failsafe.” Wikipedia [On-line]. 26 Oct, 2007. Available: http://en.wikipedia.org/wiki/Failsafe

Leveson, Nancy & Clark Turner. “An Investigation of the Therac-25 Accidents.” IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41.

REFERENCES

http://www.amplepower.com/dave_blog/2/vessel_networking_2.pdf

http://www.amplepower.com/dave_blog/2/vessel_networking_2.pdf

MPD 5750 DESIGN FOR QUALITY

Documents

Transcript of MPD 5750 DESIGN FOR QUALITY