mpd 5750 design for quality
Post on 31-Dec-2015
65 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
WHY DESIGN FOR QUALITY?
• 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
WHY DESIGN FOR QUALITY?
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 FOR QUALITY PHASES
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.
DESIGN FOR QUALITY PHASES
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.
DESIGN FOR QUALITY PHASES
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 PHASES
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
How to Complete an 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
How to Complete an 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
How to Complete an 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
7 5 4
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?
Time, Mileage or Cycles
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
FUNCTION FAILURE MODE DESCRIPTION
FMEA
Time, Mileage or Cycles
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
FUNCTION FAILURE MODE DESCRIPTION
FMEA
Function
Time, Mileage or Cycles
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
FUNCTION FAILURE MODE DESCRIPTION
FMEA
Function
0 %
50 %
120 % 100 %
When?
Ho
w
mu
ch
?
How long?
Time, Mileage or Cycles
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
FUNCTION FAILURE MODE DESCRIPTION
FMEA
Function
Function0 %
100 %Unintended Function
50 %
Time, Mileage or Cycles
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
FUNCTION FAILURE MODE DESCRIPTION
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
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
ROBUSTNESS CHECKLIST (RCL)
RCL
ROBUSTNESS CHECKLIST (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
top related