ASQ RD Webinar: Design for reliability a roadmap for design robustness

Design
for
Reliability

A
Roadmap
for

Design
Robustness

Moataz
Elheddeny

©2014
ASQ
&
PresentaCon
Elheddeny

hDp://reliabilitycalendar.org/
webinars/

ASQ
Reliability
Division

English
Webinar
Series

One
of
the
monthly
webinars

on
topics
of
interest
to

reliability
engineers.

To
view
recorded
webinar
(available
to
ASQ
Reliability

Division
members
only)
visit
asq.org/reliability

To
sign
up
for
the
free
and
available
to
anyone
live

webinars
visit
reliabilitycalendar.org
and
select
English

Webinars
to
ﬁnd
links
to
register
for
upcoming
events

hDp://reliabilitycalendar.org/
webinars/

Design for Reliability:
A Roadmap for Design Robustness
Moataz Elheddeny, MBB
Sr. Systems Engineer
Siemens Healthcare

Agenda
Introduction
What is Design for Reliability
Reliability Requirements
Application/Usage Stresses
Failure Mode/Site/Mechanism
Reliability Verification
Summary

Vocabulary
Acronyms:
ALT – Accelerated Life Test
DFR – Design for Reliability
DOE – Design of Experiments
FMEA – Failure Mode and Effects Analysis
FRACAS – Failure Reporting and Corrective Action
System
HALT – Highly Accelerated Life Test
RPN – Risk Priority Number
SME – Subject Matter Expert
VOC – Voice of the Customer

Introduction
Design for Reliability,
What is Design for Reliability?
Design for Reliability Roadmap
Customer Requirements
Verification

Design for Reliability (DFR)
What is Design for Reliability?
A discipline/roadmap that consists of different set of tools
and practices that are used during the product
development process.
Helps the organization identify, evaluate and address
reliability
risks,
improve
system
reliability,
and
consequently, meet customer requirements.

Design for Reliability (DFR)
How will the company benefit from implementing DFR
program?
Increase Customer Satisfaction
Increase Sales and Market Share
Optimize Warranty Periods
Minimize Replacement Parts Inventory
Reduce/Minimize Warranty Cost
Competitive edge
Company’s Reputation

DFR Roadmap
1. Reliability
Requirements

- Voice of the Customer (VOC)
- Benchmarking
- Best in Class

2. Application/
Usage Stresses

- Logistical Events
- Operational Events
- Operating Profiles

3. Failure Mode/
Site/Mechanism

4. Reliability
Verification

- Boundary/P-Diagram
- Lessons Learned
- FMEA
- Improvement and Verification Plan
- FRACAS
- Post Launch Reliability Monitoring

DFR Roadmap
1. Reliability
Requirements

- Benchmarking
- Best in Class

2. Application/
Usage Stresses

- Logistical Events

3. Failure Mode/
Site/Mechanism

4. Reliability
Verification

- Boundary/P- Diagram
- Lessons Learned
- FMEA
- FRACAS

Why is it important to identify Reliability requirements
early in the development process?
To help the organization:
-

Identify critical components

-

Decide where to focus improvement efforts

-

Make the right decisions and trade-offs to meet customer
requirements.

-

Get a baseline measure of customer satisfaction to
measure improvement against

-

Identify key drivers of customer satisfaction

Why do customers have different Reliability
requirements?
Reliability requirements could depend on,
Product Type:
Airplanes, cars, dishwashers and air conditioning units could all
have different reliability requirement

Application Type:
Hospitals, data centers, schools and offices could also have
different reliability requirement

1.

Voice of the Customer (VOC)
Proactive VOC System:
Customer Interviews
Focus Groups
Surveys
Customer Visits
Reactive VOC System:
Service Calls
Customer Complaints
Claims
Web Page/Blogs
Product returns

2.

Internal Benchmarking
Looking within the organization
Easier to collect and share data
Requires less resources
Limited data

3.

External Benchmarking / Best in Class
Gauging the organization against others
Benchmark companies who are doing the best possible
job
Set a goal of “As Good or Better”
Requires more resources
More difficult to collect data

Can we design a product without knowing what stresses
it will operate under?
Understanding the application/usage conditions of any system is a
crucial task for any reliability program.
To document application stresses, the following items need to be
identified:

1. Logistical & Operational Events
2. Operating Profiles/Usage Conditions

Describe all the events that the product will experience during its life
cycle, starting from the point it leaves the manufacturer final
inspection until the end of its useful life.

What are the possible environments and stresses for each event?

2. Operating Profile/Usage Conditions
a. Available Data:
Multiple sources could be used to document available data. For
example:
Fleet Leader units
Weather database
Industry Standards
Lessons Learned

2. Operating Profile/Usage Conditions
b. Design-Specific Data:
Develop test plans to document design-specific data. For example:
Motor temperature rise
Operational Vibration levels
Compressor oil viscosity during operation

DFR Roadmap
1. Reliability
Requirements

- Benchmarking
- Best in Class

2. Application/
Usage Stresses

- Logistical Events

3. Failure Mode/
Site/Mechanism

4. Reliability
Verification

- Boundary/P Diagram
- Lessons Learned
- FMEA
- FRACAS

1.

Boundary Diagram
Graphical tool aids the team to identify the system and
the elements outside its boundaries.
Some of those elements could become potential causes
(or effects) of system failure.

2.

Parameter Diagram
Provides a simplistic view of the system constrains and
the factors affecting its reliability
uncontrolled and could
contribute to system failure

Noise Factors
Piece to Piece

Change over time

Customer Usage

Environment

System Interaction

Torque

Corrosion

Duty Cycle

Temperature

Vibration

Input Signal
Control Signal

System
VFD

Ideal Function
Provide modulating signal to
control motor speed

material, energy, control

Control Factors
Enclosure type
controlled and their effects are
well understood

Failure Modes
No function (doesn't
provide modulating
signal)
error states

3. Lessons Learned
The process of documenting past learning to be used in
future projects
An effective tool to assist the team overcome some of the
challenges that other teams have experienced before
Some sources for Lessons Learned:
FRACAS
Tear down Analysis
Warranty
DFMEA
Fleet Leader
Corrective Action Database

3. Lessons Learned example
Design team is implementing a Variable Frequency Drive
to control motor speed
Lessons learned (from historical tear down analysis) shows
that motor bearing could fail due to shaft currents
Team used lessons learned to prevent future motor failures
by implementing a solution to ground/protect the bearings

4.

Design Failure Modes and Effects Analysis (DFMEA)
A risk assessment methodology to analyze different systems for
potential failure mode/site/mechanisms and their possible causes
Focuses on customer functional requirements
Includes failure modes caused by design weaknesses
Risks are weighted based on,

Severity
Occurrence
Detection
Actions will be based on the highest Risk Priority Number
RPN = Severity x Occurrence x Detection

4.

DFMEA requires a cross-functional team effort
Example:
Engineering
Manufacturing
Quality
Reliability
Materials
Subject Matter Experts (SMEs)

Product Management
Field Service

4.

DFMEA inputs could include:

4. Design Failure Modes and Effects Analysis (DFMEA)
Example:

4. Design Failure Modes and Effects Analysis (DFMEA)
DFMEA outputs
Improvement and Verification Plan
Process FMEA
Focuses on failure modes caused by process
weaknesses
Feeds into the Control Plan
DFMEA is a living document and is updated continuously,
using,
Test results
FRACAS
Field data
Etc.

Reliability Improvement/Verification
1.

Reliability Improvement/Verification Plan
Improvement and Verification plan is an output from
DFMEA, to address the identified risks
There are 2 primary questions to answer,
a.
What can we do to improve the design?
b.
How can we verify that the design meets the reliability
requirements?

1.

a.

What can we do to improve the design?
Different design methods could be used to improve the
reliability
Examples:
-

De-rating
Redundancy
Reduce part count
Reduce Stress-Strength interference
Poka-Yoke
Design for Manufacturability

1.

b.

How can we verify that the design meets the reliability
requirements?
Several verification methods/tests could be developed.
For example,
-

Tear Down Analysis
Design of Experiments
Vibration Test

- Material Analysis
- Salt Fog Test
- Field Trial

1.

Highly Accelerated Life Test (HALT)
Identify operating/destructive limits and design weaknesses
Typical HALT test includes:
Cold Step Stress
Hot Step Stress
Thermal Shock
Vibration Step Stress
Thermal Shock/Vibration
combined

1.

HALT example
A new Damper Actuator design is being qualified
HALT test was identified in the Reliability Verification Plan
Tear Down Analysis, for failed samples, shows:
1

2

Broken capacitor legs

Loose screws

1.

HALT example cont.
Corrective actions were implemented
Verification HALT test was performed on new design
Tear down was performed on the new samples after test (no
issues were found)
Design changes increased the actuators robustness

1.

Accelerated Life Test (ALT)
Used to quickly gain reliability results, by testing at various high
stress levels to speed the product failure
Could be used to test:
B vs. C (Better vs. Current)

Design 1 vs. Design 2
Supplier A vs. Supplier B

1.

Accelerated Life Test (ALT)

ALT Types:
Quantitative ALT:
Life prediction
Correlate test stresses to operating stresses (Acceleration
Factor)
Typically requires 2 or more stress levels

Qualitative ALT:
No life prediction
Acceleration factor is unknown
Could be used when test capabilities are limited or if life
predictions are not required
e.g. verifying corrective action

1.

Quantitative ALT example 1:
New motor insulation system is evaluated
DFMEA identified Insulation Thermal Degradation as a high risks
3 stress level ALT was developed to evaluate the Insulation
reliability

1.

Quantitative ALT example 2:
Field failures were reported for current motor
Tear down analysis shows motor corrosion
Better motor was developed, and a “SingleLevel” verification ALT was required
Acceleration Factor (AF) was calculated:
AF = Luse / LAccelerated

2.

Failure Reporting and Corrective Action System
(FRACAS)
What happens when a failure occurs during testing?
FRACAS is the process of capturing, analyzing and
correcting failures that occur during product development
process
Failures could be design, process or supplier related
8D problem solving process to investigate/correct failures
Linked to the DFMEA and lessons learned

3. Post Launch Reliability Monitoring
Launching the products doesn’t necessarily mean that the
project is complete.
Other post launch activities are required, as part of the
reliability verification plan:
a.
b.
c.

Field Monitor
Parts Return
Warranty Analysis

Data could be used as follows:

Update DFMEA
Design verification
Document Lessons Learned
Early Launch Containment

3.

Post Launch Reliability Monitoring
a.

Field Monitor
Field monitoring is a unit verification test in the actual
application
Several critical parameters are monitored/measured for
several months
Data is analyzed regularly, and compared to preestablished criteria
Parameters measured could be:
Cycles
Temperature
Pressure
Etc.

3.

b.

Parts Return
Develop a program to return critical components that fail
in the field
Returned parts would be analyzed to identify failure
modes and causes
Data would be used to drive corrective actions and
document lessons learned for future projects

c.

Warranty Analysis
Monitoring and analyzing warranty data is used to
identify possible trends, compare 2 (or more) designs
and verify that customer reliability requirements are met
Different analysis tools could be use.
Examples:
Re liaSoft W eibull++ 7 - www. Relia Soft. com

Probability - Lognormal

Run/Trend Charts
SPC Charts
Hypothesis Testing
Weibull Analysis

99. 000

Proba bility-Lognorma l
230V GEN IData 1
Lognorma l-2P
RRX SRM MED F M
F =168/S=16142
Probability Line
230V GEN IIData 1
Lognorma l-2P
RRX SRM MED F M
F =6/S=5046
Probability Line

50. 000

Unreliability, F(t)

3.

10. 000
5. 000

1. 000
0. 500

0. 100
0. 050

0. 010
0. 100

1. 000

10. 000

T ime, (t)
230V GEN IDa ta 1: µ=10 .32 39, σ=3.29 11, ρ=0.991 0, Ζ=0.9 99 9
230V GEN IIDa ta 1: µ=10.819 5, σ=2.9784 , ρ=0 .9 974 , Ζ=0 .99 96

Moataz Elhedde ny
Tra ne
03/15/2012
11:00:10 AM
100. 000

DFR Improvements Example
Does DFR roadmap really work?
Team has followed the DFR roadmap to change system design
and ensure the reliability of the new system
Several design improvements were made and tested/verified
Post Launch Reliability Monitoring has confirmed that the new
design has reduced field failures by > 80%, over the old design

> 80% improvement

Summary
“Design for Reliability” process steps:
1.
2.
3.
4.

Understand the requirements
Document/Measure application stresses
Identify failure modes and develop a plan to eliminate them
Verify, Verify, Verify

Reliability is an essential part of any product
development process and should be integrated as early
in the program as possible. It could provide new
perspectives to the design.
Always include SMEs and cross-functional teams in
program activities (e.g. DFMEA, FRACAS, Test
Planning).

Where to Get More Information
-

-

-

Life Data Analysis Reference Book – Reliasoft
Accelerated Life Testing Data Analysis Book – Reliasoft
MIL STD-810F “Environmental Engineering Considerations and
Laboratory Tests”
Defence Standard 00-35(PART 4)/Issue 3 “Environmental Handbook
for Defence Materiel”
Design for Six Sigma Workshop – Ingersoll Rand 2010

Moataz Elheddeny
-

Experienced Six Sigma practitioner, with a broad experience in
Quality and Reliability methodologies. He has served in different
reliability and quality roles for different companies, including
Siemens Healthcare, Ingersoll Rand and Brunswick.

-

Some of his responsibilities include developing/improving Design
for Reliability programs, ensuring the reliability of new products and
developing reliability specifications and test plans for different
components/subsystems.

-

Education/Certifications:
-

Ph.D. candidate, Industrial Engineering – University of Tennessee
Certified Reliability Engineer – American Society for Quality
Six sigma Master Black Belt – Arizona State University

Linkedin:
www.linkedin.com/in/elheddeny/
-

ASQ RD Webinar: Design for reliability a roadmap for design robustness

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to ASQ RD Webinar: Design for reliability a roadmap for design robustness (20)

More from ASQ Reliability Division (20)

Recently uploaded (20)

ASQ RD Webinar: Design for reliability a roadmap for design robustness