Good Saample

Integration of Failure Modes and Effects Analysis
(FMEA) in the Engineering Design Process
A Thesis in the Department of

Concordia Institute for Information Systems Engineering (CIISE)
Presented in partial fulfillment of the requirements for the degree of

Master of Applied Science (Quality Systems Engineering) at
Concordia University
Montreal, Quebec, Canada
August 2013
Hua-wei Wen, 2013
CONCORDIA UNIVERSITY
School of Graduate Studies
This is to certify that the thesis prepared
By:
Hua-wei Wen
Entitled:
Integration of Failure Modes and Effects Analysis (FMEA) in

the Engineering Design Process
and submitted in partial fulfillment of the requirements for the degree of

Master of Applied Science (Quality Systems Engineering)
complies with the regulations of the University and meets the accepted standards
with respect to originality and quality.
Signed by the final examining committee:

Dr. Ben Hamza
Dr.Simon Li
Dr.Gerard K. Gouw
Dr. Chun Wang
Approved by
Supervisor
External Examiner
Internal Examiner
Dr. Anjali Awasthi

Chair of Department or Graduate Program Director
Christopher Trueman
Dean of Faculty
Date
Chair
August 21, 2013
ABSTRACT
Integration of Failure Modes and Effects Analysis (FMEA) in the

Engineering Design Process
Hua-wei Wen
Failure modes and effects analysis (FMEA) is one of the most practical design
tools implemented in the product design to analyze the potential failures and to
improve the design. The practice of FMEA is diversified and different approaches
are proposed by different organizations and researchers from one application to
another. Yet, the question is how to systematically utilize the features of FMEA
along with the design process. This thesis aims to integrate different types of
FMEA in the design process, which is considered as the mapping between
customer requirements, product functions, and design components. These three
design elements are the foundation of the integration model proposed in this
thesis.
The objective of this thesis is to develop an integration approach of FMEA in the

design process. Particularly, an integration framework is developed to integrate
FMEA and design process. Then, a step-by-step FMEA-facilitated design process
is proposed to apply FMEA along with the design process. In the end, a detailed
case study of a smartphone model is conducted to demonstrate and verify the
iii
proposed methodology. The expectedly benefits of the proposed methodology are

the consistency of failure analysis information, and the utilization of the failure
analysis information from one stage to the later stages of the design process.
Keywords: Engineering design process, Failure modes and effects analysis

(FMEA), Failure analysis, Smartphone
iv
Contents
List of Figures ....................................................................................................... vii
List of Tables ........................................................................................................ viii
Chapter 1: Introduction ........................................................................................... 1
1.1. Background and Motivation ........................................................................ 1
1.2. Research Approach and Objectives ............................................................. 4
1.3. Thesis Organization ..................................................................................... 5
Chapter 2: Literature Review .................................................................................. 6
2.1. Development of FMEA in Industry Practice ............................................... 6
2.2. FMEA in Academic Research ..................................................................... 9
2.3. Research Gaps related to this Thesis ......................................................... 11
Chapter 3: Integration Framework ........................................................................ 13
3.1. Basic Elements in Engineering Design ...................................................... 13
3.2. Basic Elements of FMEA .......................................................................... 16
3.3. Definition of Failure Modes from Design Elements.................................. 20
3.4. Integration Model....................................................................................... 24
3.5. Smartphone Demonstration ....................................................................... 26
Chapter 4: FMEA-Facilitated Design Process ...................................................... 31
4.1. Three-Phase Design Process ...................................................................... 31
4.1.1. Identification of requirements ............................................................. 32
4.1.2. Deployment of product functions ....................................................... 34
4.1.3. Definition of product components ...................................................... 35
4.2. FMEA Evaluation Schemes in the Design Process ................................... 36
4.3. Reasoning of Causes and Effects in FMEA ............................................... 38
4.4. Methodical Procedure ................................................................................ 40
Chapter 5: Case Study........................................................................................... 45
5.1 Requirements Domain ................................................................................ 45
5.1.1 Identification of the requirements ........................................................ 46
5.1.2 Determination of the requirements failure modes ............................... 47
5.1.3 Effect analysis of the requirements failure modes ............................... 49
5.1.4 Prioritization of the requirements risk consequences .......................... 51
5.2 Function Domain ........................................................................................ 52
v
5.2.1 Deployment of functions...................................................................... 53

5.2.2 Determination of the function failure modes ....................................... 55
5.2.3 Effect analysis of function failure modes ............................................ 57
5.2.4 Reasoning of severity S(fi) ................................................................... 59
5.2.5 Prioritization of the function risk consequences .................................. 64
5.3 Component Domain .................................................................................... 66
5.3.1 Definition of the components............................................................... 66
5.3.2 Determination of components failure modes ....................................... 68
5.3.3 Effect analysis of the components failure modes ................................ 71
5.3.4 Reasoning severity S(ck) ...................................................................... 73
5.3.5 Cause analysis of components failure modes ...................................... 77
5.3.6 Reasoning of causes of components failure modes ............................. 80
5.3.7 Decision of control plan and detection ................................................ 81
5.3.8 Completion of FMEA for components ................................................ 82
5.4 Completion of the documentation for functions ......................................... 87
5.4.1 Causes of functions failure modes analysis ......................................... 88
5.4.2 Determine O(fj) .................................................................................... 91
5.4.3 Completion of the FMEA document of functions ............................... 92
5.5 Completion of the documentation for requirements ................................... 97
5.5.1 Analyze the causes of requirements based on Section 4.2................... 97
5.5.2 Determine O(ri) .................................................................................... 99
5.5.3 Completion of the FMEA document of requirements ....................... 100
Chapter 6: Discussion ......................................................................................... 104
Chapter 7: Conclusion......................................................................................... 107
References ........................................................................................................... 109
Appendices .......................................................................................................... 115
Appendix 1 List of components ...................................................................... 115
Appendix 2 Functional analysis ...................................................................... 119
vi
List of Figures
Figure 1 Fault tree analysis (FTA) diagram example .................................................................... 19
Figure 2 Integration model ............................................................................................................ 24
Figure 3 Schematic diagram of requirements domain analysis ..................................................... 26
Figure 4 Schematic diagram of function domain analysis ............................................................. 27
Figure 5 Schematic diagram of the relation between requirements and functions in the integration
model .............................................................................................................................................. 28
Figure 6 Schematic diagram of components domain analysis ....................................................... 28
Figure 7 Schematic diagram of the relation between functions and components in the integration
model .............................................................................................................................................. 30
Figure 8 Requirement matrix ......................................................................................................... 33
Figure 9 Schematic diagram of the procedure of FMEA-facilitated design process ..................... 43
vii
List of Tables
Table 1 FMEA evaluation scheme for occurrence ........................................................................ 37
Table 2 FMEA evaluation scheme for severity ............................................................................... 38
Table 3 FMEA evaluation scheme for control detection ................................................................ 38
Table 4 Requirement matrix of smartphone example ..................................................................... 47
Table 5 Worksheet for identifying the failure modes of requirements ............................................ 48
Table 6 Effects analysis of requirement failure modes ................................................................... 50
Table 7 RF matrix of the mapping between requirements and functions ....................................... 55
Table 8 Worksheet for identifying the failure modes of functions .................................................. 56
Table 9 Effect analysis of function failure modes ........................................................................... 57
Table 10 Severity of functions by reasoning from S(ri) .................................................................. 60
Table 11 Severity of functions by reasoning from S(FMafj) ............................................................ 60
Table 12 Modified severity of functions ......................................................................................... 61
Table 13 Modified effect analysis with severity values in function domain ................................... 62
Table 14 Components and their corresponding functions to achieve............................................. 67
Table 15 Mapping between functions and components (FC matrix) .............................................. 68
Table 16 Worksheet of components failure modes ......................................................................... 70
Table 17 Effect analysis of components failure modes ................................................................... 71
Table 18 Severity of components by reasoning from S(fj) .............................................................. 74
Table 19 Severity of components by reasoning from S(FMack) ....................................................... 74
Table 20 Modified severity of components ..................................................................................... 75
Table 21 Modified effect analysis with severity values in component domain ............................... 76
Table 22 Cause analysis of components failure modes .................................................................. 79
Table 23 Reasoned occurrence of components failures modes ...................................................... 80
Table 24 FMEA for components..................................................................................................... 83
Table 25 Cause analysis of function failure modes ........................................................................ 88
Table 26 the reasoned occurrence of causes of functions failure modes ....................................... 92
Table 27 FMEA for functions ......................................................................................................... 93
Table 28 cause analysis of requirements failure modes ................................................................. 98
Table 29 the reasoned occurrence of causes of requirements failure modes ................................. 99
Table 30 FMEA for requirements................................................................................................. 100
viii
Chapter 1: Introduction
1.1. Background and Motivation

Failure modes and effects analysis (FMEA) is a design tool to analyze and control
the potential impacts from failures (Anleitner 2010). Through the practice of
FMEA, it is expected to anticipate the possible failures from a product or system
before it is actually implemented. In such a way, engineers can improve the
design by deliberately controlling the causes of failures or limiting their negative
effects. One key benefit to implement FMEA in product design is due to the
Factor of 10 rule that early design improvements can substantially minimize the
expensive cost of modifications at the later stages of product development
(Carlson 2012, pp. 5-6).
Notably, the origin of FMEA comes from the industrial initiative, particularly
from military and automotive industries. In this sense, the procedure of FMEA
can be very practical towards a particular industrial sector. Yet, significant
adapting efforts are required if we want to use the same procedure from one
application to another application. Consequently, different standards related to
FMEA have been proposed from various organizations such as the military
standard of United States (MIL-P-1629), Society of Automotive Engineers (SAE:
ARP5580), and International Organization for Standardization (ISO/TS 16949).
In contrast to FMEA, academic researchers have devoted significant efforts in the

research of engineering design in the past few decades. The results can be found
in some notable texts by Pahl et al. (2007), Dieter and Schmidt (2009), and Ulrich
and Eppinger (2012). Intuitively, a design may be mainly referred to the artifact
(physical structure or software) that is perceived by the users directly. Yet, these
texts of engineering design have emphasized the significance of functions to
describe the artifact as part of the design process. That is, the design information
(e.g., requirements and functions) is essential before a design concept is
developed.
In this thesis, the design process is considered the mapping process between
design elements. Three types of design elements are particularly considered in this
thesis: customer requirements, product functions and design components.
Customer requirements are considered as the input information indicating the
needs of customers, and they are usually obtained and organized in a marketing
department through the market research activity. Product functions indicate the
intents of the design without stating the specific solutions. For example, if I want
to eat the food in the can, the function can be described as open the can.
Notably, there can be various ways to open the can. Design components are
referred to the specific design solutions that are implemented to achieve the
product functions. For example, an electric can opener from Company ABC can
be one design component to achieve the function open the can.
In brief, this thesis considers the design process as the mapping of requirements
functions components. This mapping has the reference to the methodology
of Quality Function Deployment (QFD) in quality management and Axiomatic
Design (AD) in engineering design. Particularly, QFD can involve several
mapping matrices from customer requirements to engineering characteristics and
then to part characteristics (Hauser and Clausing 1988). In AD, the mapping
framework has been proposed for four design domains: customer, functional,
physical and production (Suh 1990).
By considering FMEA as one design tool, the research question of this thesis is
how to utilize the features of FMEA systematically in a design process. The
academic efforts in engineering design have provided a solid foundation about
some key design concepts such as requirements, functions and components. The
research effort of this thesis is to interpret these design concepts systematically in
the context of FMEA. In such a way, the practice of FMEA can be carried along
with the design process. Expectedly, the information of failure analysis (from
FMEA) can be utilized at the later stages of the design process. This practice can
promote the consistency of the failure information among different teams in
product development.
1.2. Research Approach and Objectives

The research approach has two aspects. The first aspect is related to the design
process. In this aspect, it is required to specify the definition of design elements
and how these design elements are related to each other. This provides the
foundation for the integration effort with FMEA. The second aspect is related to
FMEA. In this aspect, the key is to clearly define the contents of failure modes
with respect to design elements. Once the failure modes are specified in a design
context, the procedure of FMEA can be adapted in the design process for risk
analysis.
To demonstrate and verify the research of this thesis, the smartphone of a specific
model will be used. In this research, the hardware pieces of the smartphone are
physically decomposed and studied for their functionalities. Then, the design
elements of the smartphone are captured, and the proposed FMEA procedure is
carried out for demonstration and verification. The details of the smartphone
study are treated as one research deliverable of this thesis.
The goal of this research is to develop an integration approach of FMEA in the

design process. To achieve this goal, three objectives are specified for this thesis.
Objective #1: Develop an integration framework so that both FMEA and the
design process can be integrated in a consistent manner.
Objective #2: Develop the FMEA-facilitated design process that consists of a
step-by-step process to apply FMEA along the design process.
4
Objective #3: Conduct a detailed case study of a smartphone model to

demonstrate and verify the methodology
1.3. Thesis Organization

The remaining chapters of the thesis are organized as follows. In Chapter 2, the
literatures related to FMEA are reviewed and also the research gaps related to this
thesis is highlighted. In Chapter 3, an integration framework is proposed by
specifying the design elements and the contents of failure modes in the design
process. Besides, a simple example from the Smartphone case study is carried in
the end of Chapter 3 to demonstrate the integration model. In Chapter 4, a stepby-step methodology is proposed, and it guides the use of FMEA along with the
design process. In Chapter 5, a case study from the specific model of a
Smartphone is used to demonstrate and discuss the utility of the proposed
methodology. In Chapter 6, the discussion of the benefits that we observed and
the contributions clarified in the case study are presented. In the end, the
conclusion of this thesis is provided in Chapter 7.
Chapter 2: Literature Review

2.1. Development of FMEA in Industry Practice
The origin of FMEA can be traced back to the military standard of United States
in 1949 (MIL-P-1629), and the procedure at that time was titled Failure Mode,
Effects and Criticality Analysis (FMECA). This military standard has been
revised in 1980 (Military 1980). According to the forward of this standard, the
purpose of FMECA is to identify the failure modes for assessing the feasibility
and adequacy of the design and supporting the design decision accordingly.
Beyond the military applications, FMECA has also been applied for space
missions. One famous example is that National Aeronautics and Space
Administration (NASA) has applied FMECA for the Apollo program for
analyzing the system unreliability and crew safety problems (NASA 1966). The
major difference between FMEA and FMECA is that FMECA additionally
involves a criticality analysis. For each failure mode, criticality analysis considers
the expected failure, mode ratio of unreliability and probability of loss. More
details can be found in Carlson (2012).
The wide use of FMEA and similar techniques in civil systems can be found in
the automotive industry. The Society of Automotive Engineers (now known as
SAE International) has introduced the FMEA standard in 2001 (coded as
ARP5580) (SAE 2001). As noted in Carlson (2012, chapter 1) and Bertsche
(2008, chapter 4), the Ford Motor Company has been the first automobile
6
manufacturer in the late 1970s applying FMEA, and FMEA remains one
important tool in reliability analysis. In addition, FMEA has been recognized as
one important tool in quality engineering as it is part of the body of knowledge to
the Black Belt Certification (ASQ 2013; Creveling et al. 2003). International
Organization for Standardization (ISO) has also managed relevant techniques in
one standard, ISO/TS 16949 (Duckworth and Moore 2010, p. 51). This indicates
the evidence about the popularity and usefulness of FMEA in industrial practice.
Beyond the aerospace and mechanical systems, other industrial sectors have also
reported the application of FMEA for reliability and quality analysis such as
healthcare (De Rosier et al. 2002) and software (Reifer 1979).
According to the military standards, the techniques of FMEA originally targets for
design improvement. That is, by identifying the potential failure modes during the
design stage, we can minimize the impacts from these failure modes by modifying
the original design. This practice can reduce the overall cost as compared to the
modifications at the later stages of the product development process. This domain
of FMEA has been termed as Design FMEA (Anleitner 2010). When FMEA
becomes familiar in the industrial practice, engineers have adapted and extended
the FMEA techniques to other domains. Three examples of different FMEA
domains are listed and briefly explained as follows.
Process FMEA (Teng and Ho 1996): the Process FMEA is used to analyze the
risks related to the manufacturing operations.
Concept FMEA (Carlson 2012, pp. 347-348): the Concept FMEA is used to
assess the safety and reliability of the design concepts during the multi-criteria
selection process.
Social Responsibility FMEA (Duckworth and Moore 2010): the Social
Responsibility FMEA is used to evaluate a companys operations in view of
social responsibility. In such a way, failure modes are referred to poor impacts
to the society and environment as a whole. It is intended to improve the social
responsibility performance so that the company can explore alternative ways
for the solutions for better society and environment.
After accumulating the experience of using FMEA in industrial practice, some

practitioners propose a systematic FMEA methodology to construct the
fundamental principles. Anleitner (2010) has proposed the deductive design
FMEA method that rigorously specifies the inputs and outputs of each procedural
step. Carlson (2012, p. 18) has also constructed the relationship diagram between
Design FMEA and Process FMEA by systematically linking the required input
and output information.
Based on this review, two observations about FMEA in industrial practice are
made. Firstly, originated from the design domain, the application of FMEA has
been extended to other domains in product development. From a manufacturer
viewpoint, risks are not isolated. Such extension provides an opportunity to
integrate the information of risks across different domains (e.g., from customer
requirements to design and manufacturing). Secondly, early FMEA procedures

tend to provide practical but somewhat ad-hoc guidelines. Thus, the actual
outcomes from FMEA can vary significantly from one project to another. Recent
efforts have focused on formalizing the FMEA procedure to promote the utility of
FMEA in the actual practice. The research of this thesis basically corresponds to
these two observations by integrating the requirements, functions and components
in a framework for conducting FMEA.
2.2. FMEA in Academic Research

In academic research, one research direction related to FMEA is to enhance the
features of FMEA for more comprehensive risk and failure analysis in product
development. Stone et al. (2005) proposed the function-failure design method
(FFDM) to support the use of FMEA in the conceptual design stage. The
fundamental technique behind FFDM is to utilize the notion of functions to
systematically define failure modes in engineering design. Chao and Ishii (2007)
proposed the error-proofing method by adapting FMEA to prevent design errors,
which are classified into six categories: knowledge, analysis, communication,
execution, change and organization. FMEA was applied to guide engineers to
explore the potential errors in these categories through the question-asking
techniques.
One specific issue of FMEA research is to tackle the accuracy and

appropriateness of the risk priority number (RPN). In brief, RPN is the product
9
(i.e., by multiplication) of three numerical rankings: occurrence of risks, severity

of risks and control of risks. The higher ranking values indicate worse risk
situations, and RPN is used to prioritize the failure modes due to their risk
situations. Then, the fundamental issue of RPN is that the same value of RPN can
essentially represent different risk situations. For example, if the RPN value is
equal to 600, we actually cannot determine whether the risk situation is (1) high
occurrence and low severity or (2) low occurrence and high severity. It is because
all numerical rankings are simply aggregated into one value (i.e., RPN).
To address this specific issue of FMEA, several researchers have proposed more
detailed approaches to compute RPN and prioritize failure modes. Pillay and
Wang (2003) used fuzzy sets and rules to infer and prioritize the risk situations,
and their approach allowed users to define more specific scenarios of risks for
particular contexts. Kmenta and Ishii (2004) used the probability and cost as the
common basis to estimate and prioritize the risk situations in a more precise
manner. Chang and Cheng (2011) used the fuzzy ordered weighted averaging
(OWA) that allowed weighting factors and human imprecision in the assessment
of risk situations. Bradley and Guerrero (2011) developed a data-elicitation
technique integrated with the interpolation algorithm to support the risk
assessment in FMEA. Chang et al. (2013) proposed an exponential risk priority
number (ERPN) for providing more unique numerical values mapped to various
risk situations.
10
This thesis will not address the issue of RPN. Instead, this thesis focuses on the
methodology development for integrating FMEA in the design process. More
discussion will be provided in the next sub-section.
2.3. Research Gaps related to this Thesis

From the discussion of FMEA in industrial practice (i.e., Section 2.1), it is stated
that the application of FMEA becomes more popular in industry. As FMEA often
requires the effort of a team, the FMEA procedure needs to be more rigorous and
systematic for better communication and ensuring quality outcomes. Some latest
texts such as Anleitner (2010) and Carlson (2012) have supported the direction of
FMEA development in industry. In addition, it has been observed that FMEA has
been extended for the risk analysis in different stages of product development
(e.g., process FMEA and requirement FMEA). Such an extension effort remains
active for supporting the organization of the product development process. In
these views, this thesis is intended to contribute to the methodology development
for the systematic practice of FMEA in different stages of the design process.
From the discussion of FMEA in academics (i.e., Section 2.2), while this thesis
does not provide new approaches for handling RPN, it extends the research works
of Stone et al. (2005) and Chao and Ishii (2007) by integrating more design
elements in the practice of FMEA. Particularly, the design process of this thesis is
modeled as a flow from customer requirements to design functions and
components (i.e., requirements functions components). Essentially, this
11
kind of design flow is similar to the methodology of Quality Function

Deployment (QFD) (Suh 1990) or Axiomatic Design (AD) (Hauser and Clausing
1988). To our knowledge, integrating FMEA with these three types of design
elements has not been found in literature.
12
Chapter 3: Integration Framework

The purpose of this chapter is to develop the integration model that provides a
platform joining the information from the design and FMEA domains. The
information related to the design and FMEA domain is first discussed separately.
The integration is based on the definition of failure modes based on the design
elements. At the end of this chapter, the smartphone example will be used to
demonstrate and examine the integration concept.
3.1. Basic Elements in Engineering Design

The design process in engineering has not yet been standardized among
researchers and practitioners, and thus various terms and design processes can be
found from literature (Carlson 2012; Creveling et al. 2003; Pahl et al. 2007). In
this thesis, three foundational and representative elements in engineering design
are considered: requirements, functions and components.
Requirements are referred to the ultimate needs that are used to examine the
products goodness. In the field of quality engineering, requirements are mainly
referred to customer needs, where the concept of customers can involve multiple
aspects, and some examples are listed in the following.
The customers who pay for the product
The clients who use the product
The governmental policies and regulations
13
The environmental requirements
Generally, requirements can be viewed as the external and somewhat nontechnical expectations that are required to the products. Product failures can be
claimed if the requirements of a product cannot be met. This highlights the
significance of requirements in engineering design.
The concept of functions in engineering design may come from the philosophy
Form Follows Functions in architecture (Pahl et al. 2007). The basic idea of
functions is to distinguish between what and how in design. Particularly,
what describes the basic purposes (or functions) of the design, e.g., separating a
piece of paper into two piece. Then, how describes the solutions to achieve
these purposes, i.e., use a scissor as one solution to separate a piece of paper. The
significance of the function concept is that multiple solutions are possible to
achieve the same function. For example, in addition to using a scissor, we can use
a ruler or our hands to separate the same piece of paper. At this point, the concept
of functions can help engineers to creatively think of various solutions without
committing to any solutions too quickly.
In this research, the function concept based on functional basis for design (Stone
et al. 2000) is used. Particularly, a function is expressed in a phrase structure
verb + noun to emphasize the action to be carried in a function. Furthermore,
each action can be viewed as a transfer function that converts some input into
14
some output. For example, separate a piece of paper into two is a function with
an input one piece of paper and an output two pieces of paper. The inputs and
outputs are further classified into three types: material, information and energy.
Also, functions can be decomposed by describing how some sub-functions are
required to achieve a high-level function. At the point, a product can be described
by as a set of sub-functions that are purposely connected to deliver its major
functions. To organize the sub-functions, a functional block diagram is commonly
used in practice. Further details of functional design and analysis can be found in
Kossiakoff et al. 2011.
Components are referred to the solutions that are chosen to satisfy particular
function(s) or sub-function(s). Note that this research is confined to the scope of
conceptual design. Thus, a component is generally a concept that is defined by
Ulrich and Eppinger (2012, p. 98) as an approximate description of the
technology, working principles, and form of the product. For example, suppose
that a scissor is chosen as the component to separate a piece of paper. Then, the
scissor concept here only approximately implies the use of two blades for cutting,
and further engineering details are required for implementation (e.g., size of
scissor, blade materials, etc.) Yet, the choice of a concept confines the direction of
engineering efforts, and it is often considered a crucial decision towards the
success of a design (Ulrich and Eppinger 2012).
15
After explaining the meaning of requirements, functions and components, this

research focuses on the organization of these three types of elements along the
product development process. The first step of the organization is to itemize these
elements explicitly as the design information of a product. Let R, F and C be the
set of requirements, functions and components, respectively, and these items are
further denoted as follows.
Requirements: R = {r1, r2, , rm}, where m is the total number of

requirements
Functions: F = {f1, f2, , fn}, where n is the total number of functions
Components: C = {c1, c2, , cp}, where p is the total number of components
In addition to the design information, FMEA targets for the failure information of
a product. The next section will define and discuss the basic elements of FMEA.
3.2. Basic Elements of FMEA

Though FMEA is originated from a military standard (Military 1980), the practice
of FMEA becomes diversified by incorporating various documentation styles and
ranking schemes (Carlson 2012). Nevertheless, there are some basic elements that
characterize the fundamental principles of FMEA. In this research, these basic
elements are failure modes, causes and effects.
16
Based on Carlson (2012, p. 28), a failure mode can be defined as the manner in
which the product or operation failure to meet the requirements. In this sense, a
failure mode should be a plain description of the failure without stating the
reasons behind it or the impacts after it. In the context of engineering design, a
failure mode can be referred any dissatisfaction related to requirements, functions
and components. Towards the integration efforts, one important idea of this
research is that a failure mode should be defined based on the known
requirements, functions and component of the design. This idea provides the
guidance for engineers to prepare the FMEA documents logically related to the
design context.
The casual analysis in the study of engineering failures is always a challenging

task, and fault tree analysis (FTA) is often identified as one common tool for this
kind of tasks (OConnor 2012). Compared to FTA, FMEA does not particularly
focus on the casual relationships of failures. Instead, FMEA suggests identifying
the causes and effects associated with each failure mode. Particularly, the causes
are the possible reasons that can lead to the happening of the failure mode, and the
effects represent the negative impacts if the failure mode is materialized. In this
case, the causes and effects are basically connected by failure modes only without
involving the chain effects between causes and effects.
For example, when engineers make failure analysis of a phenomenon a user

cannot take photo, the analysis process in FTA may look like Figure 1, a top-
17
down analysis method to clarify and find the answers (i.e. root causes). In FTA,
all the events under the phenomenon being studied are viewed as possible causal
factors. In the meantime, one event can be a result of another event in the lower
level or a reason for the other event in the upper level, and therefore the causal
relationships of failures are broke down. Besides, one causal factor is possibly
rooted out in different branches in FTA. From Figure 1, we can find that camera
module is damaged is the upper event of the causal factor lack of R/C
components for protection, and it is also a causal factor for the event camera
module cannot be executed. Also, camera module is damaged can be a root out
under the analysis branch of Design factors or under the branch of
Manufacture factors.
In contrast, the cause-failure mode-effect chain is clearer in FMEA. In the similar

case, the failure mode is identified as Camera module is damaged if the
analyzed items in FMEA is components, the possible causes is lack of R/C
components for protection and Incorrect circuit design; the possible effect is
Camera module cannot be executed. Similarly, if the analyzed item in the
FMEA is functions, the failure mode is Camera module cannot be executed, and
the causes is identified as Camera module is damaged, Lack of power supply,
Incorrect patter, or so on; the effect is identified as A user cannot take photos.
Instead of considering what if continuously to build up the effect results or to
ask why continuously to find out the root causes, engineers focus on the direct
18
effects and the causes of the failure modes corresponding to the analyzed items in
FMEA.
A user cannot take

photos
Physical failures
Human factor
Operate the camera

improperly
Operate the
camera under
extreme weather
condition
Lack of power
supply
Design factors
Click the wrong

button
Damage the
camera by
external force
Incorrect circuit
pattern
Camera module
cannot be executed
Lack of drivers
to drive the
camera module
Camera module is
damaged
Lack of R/C
components for
protection
Manufacture factors
Camera module is
executed but the
photos are not clear
The lens is covered
Lack of flash
module
Improper
location of the
components
Incoming camera
module is nonfunction
Suppliers
provide
defective
components
Suppliers use
Improper
packing for
shipping
Camera module is
damaged
Lack od ESD
protection
during
assembly
Incorrect circuit
design (overcurrent)
Figure 1 Fault tree analysis (FTA) diagram example
After explaining the meaning of failure modes, causes and effects, this research
focuses on the organization of these three types of elements along the product
development process. The first step of the organization is to itemize these
elements explicitly as the failure information of a design. Let FM, CA and EF be
the set of failure modes, causes and effects, respectively, and these items are
further denoted as follows.
19
Improper
packing for
internal
shipping
Labors
assemble the
device
improperly
Failure modes: FM = {fm1, fm2, , fmq}, where q is the total number of

failure modes
Causes: CA = {caij}, where caij is the jth cause of the ith failure mode
Effects: EF = {efik}, where efik is the kth effect of the ith failure mode
In FMEA, the definition of failure modes is the key to investigate the

corresponding causes and effects. The next section will discuss the definition of
failure modes based on design information.
3.3. Definition of Failure Modes from Design Elements

The research effort of this thesis is about integrating the design process with the
practice of FMEA. The heart of this integration lies in the definition of failure
modes based on the design information. From Section 3.1, three design elements
(i.e., requirements, functions and components) have been classified to form the
information basis. At the same time, a failure mode can be viewed as the
manner in which the product fails. Then, the basic principle here is to define the
failure mode for each types of design elements by classifying their typical failure
manners.
When product requirements are considered as customer needs, the corresponding

failure modes can be generally viewed as failing to meet the requirements. More
specifically, there can be five different manners (or modes), in which failures can
20
take place related to requirements. These modes are listed and explained as
follows.
Absence: the requirement is totally not met
Incompleteness: the requirement is only met partially
Intermittence: the requirement cannot be smoothly met
Incorrectness: the requirement is met incorrectly
Improper occurrence: the requirement is met at the wrong time
For example, consider that one requirement of the smartphone example is have
an internet connection at all times. Then, the engineers can investigate in which
manners this requirement can fail, and three possible failure modes can be
identified as follows.
Absence: the smartphone cannot support internet connection
Intermittence: users experience frequent interruptions with internet connection
Improper occurrence: it takes long time to connect to the internet
Note that engineers only investigate the failure modes that are reasonable to the
requirements context. We can skip some modes that may not be too meaningful
for a particular requirement. For example, it is found that incompleteness is not
too meaningful concerning internet connection and thus it is not considered as
one failure mode. At the point, the value of the five modes (e.g., absence,
incompleteness, etc) is to provide the guideline for engineers to carry FMEA
systematically.
21
Similarly, the functions are expressed in a phrase structure Verb + Noun and
thus the failure modes of functions are viewed as the negative phrases structures
compared to the active verbs used in expressing the function. Furthermore, while
we emphasize the verbs in the function description, the failure modes are
considered as any negation from its original description. In this thesis, we
categorized the failure modes of functions into five types.
Malfunction: the function is not executed
Interference: the function execution is interfered
Decayed: declined function performance; the function execution doesnt reach
the standard after a certain of time
Incompleteness: the function is partly executed
Incorrectness: the function is incorrectly executed
For example, if the function display images is being studied, two failure modes
are possibly identified by engineers.
Malfunction: the smartphone does not display images
Interference: the image display is interfered
The failure modes of the component in this thesis are specified for electronic
components because the case study object is a smartphone. The electronic
components are sensitive to the design criteria and any design details may have
effects on the components performance. Yet, only the most serious failure modes
22
which stop components from performing the designed functions are considered in
this thesis, and we categorized them as below.
Damaged: components loss abilities to achieve the functions
Loss of efficiency: the components perform functions less efficiently than its
technical specifications
EMI: the components emit radiation
Non-compatible: a components specification is non-compatible to perform
the function properly
For example, a GSM transceiver is studied and the engineers possibly identify
three failure modes listed below.
Damaged: the GSM transceiver is damaged (might be burned out or
discharged)
Loss of efficiency: the GSM transceiver has difficulty to access GSM network
even when it is powered
EMI: the GSM transceiver emits the radiation
The symbols are used to denote the failure modes for each type of design
elements, respectively.
FMa = the ath failure mode (e.g., FM1)
FMari = the ath failure mode of the ith requirement (e.g., FM1r1)
FMafj = the ath failure mode of the jth function (e.g., FM1f1)
FMack = the ath failure mode of the kth component (e.g., FM1c1)
23
3.4. Integration Model

Based on the elements of engineering design and FMEA, the integration model of
this research is shown in Figure 2. In this graphical model, the boxes represent the
design elements, and the ovals represent the FMEA elements. Particularly, the
single-head arrows connecting the design elements indicate the flow of a design
process from requirements to functions and components. The double-head arrows
between design elements and failure modes show the dependency about how the
design elements are used to define the failure modes of a product (i.e., the
discussion in Section 3.3). Furthermore, the curved arrows belong to FMEA, and
they indicate the causes and effects related to the failure models. Notably, the
integration model in Figure 2 has not been found in literature and is considered
one contribution of this research.
Causes
Causes
Failure
Modes
Causes
Failure
Modes
Effects
Requirements
Failure
Modes
Effects
Functions
Effects
Components
Figure 2 Integration model
Different formats and contents of FMEA exist nowadays depending on the usage
timing and situations (Carlson 2012). The common FMEA applied in engineering
industry is the design FMEA. In the design FMEA, as indicated in the name, it is
24
applied during design development process, and the analyzed items are generally
the functions or components. Researchers propose methodologies to apply FMEA
as early as possible in the conceptual design stage in order to design out the
potential causes of failure modes to lower down the risk and quality cost (Stone et
al. 2005). However, it barely connects different FMEAs. As well-known, FMEA
is a tedious and time consuming process (Hunt et al. 1995), and thus engineers
hardly apply several FMEAs in one project especially when the development time
is limited to as short as possible for an engineering product such as a smartphone.
As a result, the integration model developed in this research aims to extend the
existing knowledge about FMEA to connect different FMEA documents. The
integration model enables engineers to apply FMEA in different key stage of
design development mentioned in Section 3.1 based on the part of the efforts put
in the previous analysis. That is, when engineers deploy functions based on
requirements, the integration model enables engineers use part of the efforts from
requirement FMEA analysis to function FMEA analysis. The FMEA connect with
each other make sure the analysis consistent, especially the risk rating number.
The most important requirements remain important and the identified critical
failures remain critical throughout the product development process. At the point,
it helps engineers prioritize and select the components corresponding to the
analysis. Furthermore, the integration model also enables engineers make
documentation of FMEAs and it potentially helps engineers to modify and reuse
the FMEA documents in the future for product redesign and reengineering.
25
3.5. Smartphone Demonstration

A common requirement for a smartphone is used as a start point to demonstrate
the methodology. Noted the complete case study is in Chapter 5.
Firstly, engineers collect and define the requirements and features to be designed
in the product. Assume there is one requirement R1: have an internet connection
at all time. The failure modes and effects are then identified respectively in the
following.
R1: have an internet connection at all time
Failure
mode
Effects
Requirements
Figure 3 Schematic diagram of requirements domain analysis
Failure modes of R1:

FM1r1: the smartphone cannot connect to internet
FM2r1: the users experience frequent interruptions of internet connection
FM3r1: it takes long time to connect to the internet
Effects and causes of requirement failure modes:
EF11r1: the users will change the smartphone
EF21r1: the users might complain it and try to fix the problem
EF31r1: the users might accept it or tolerate it
26
Secondly, engineers need to deploy functions and also identify the failure modes
and effects respectively.
Deploy function and identify the failure modes of functions:
Failure
mode
Effects
Requirements
Functions
Figure 4 Schematic diagram of function domain analysis
R1 F1: Receive internet signal, F2: Transmit internet signal

Failure modes and corresponding effects of F1:
FM1f1: The smartphone doesnt receive internet signal
FM2f1: It takes too much time to receive internet signal
EF11f1: the users cannot connect to the internet
EF21f1: the users have to wait and be patient to connect to the internet
Failure modes and corresponding effects of F2:
FM3f2: The smartphone doesnt transmit internet signal
FM4f2: It takes too much time to transmit internet signal
EF12f2: the users cannot connect to the internet
EF22f2: the users have to wait and be patient to connect to the internet
27
When the engineers deploy the functions from requirements and relate
requirements and functions, the effects of function failures modes are the guide
for the engineers to analyze the causes of requirements failure modes. In other
words, functions are deployed to satisfy requirements and thus any failure modes
of functions might affect the completion of requirements. The schematic diagram
is showed in Figure 5. The dotted line represents the two elements are related in
the integration model.
Causes
Failure
mode
Failure
mode
Effects
Functions
Requirements
Figure 5 Schematic diagram of the relation between requirements and functions

in the integration model
Thirdly, engineers define the components to achieve functions and make failure
analysis accordingly.
Define components and identify the failure modes and effects:
Failure
mode
Effects
Functions
Components
Figure 6 Schematic diagram of components domain analysis

28
F1: Receive internet signal C1: Wi-Fi antenna, C2: GSM transceiver
F2: Transmit internet signal C1: Wi-Fi antenna, C2: GSM transceiver
Failure modes and corresponding effects of C1:
FM1c1: Wi-Fi antenna loses efficiency
FM2c1: GSM transceiver is damaged
EF11c1: the smartphone meets difficulty to connect to Wi-Fi network
EF21c1: the smartphone is unable to connect to GSM network
Failure modes and corresponding effects of C2:

FM3c2: GSM transceiver loses its efficiency
FM4c2: GSM transceiver emits radiation
EF11c2: the smartphone is unable to connect to GSM network
EF21c2: the signal display is interred (e.g. users see or hear noise signal)
Similar to the elements relations between requirements and functions, the failures
of components affect the achievement of functions because the components are
selected to be the solutions for functions description. The schematic diagram is
showed in Figure 7.
29
Causes
Failure
mode
Failure
mode
Effects
Functions
Components
Figure 7 Schematic diagram of the relation between functions and components in

the integration model
At the point, we have showed how the integration model benefits in FMEAs. The
cause analysis is not a brainstorming process but a systematically analysis process
when the design elements (e.g. requirements, functions, and components) are
linked closely with each other and its the goal in the product development
process.
30
Chapter 4: FMEA-Facilitated Design Process

The purpose of this chapter is to propose the methodical procedure for facilitating
the practice of FMEA in the design process. Firstly, the three-phase design
process is provided based on the three elements in engineering design (i.e.,
requirements, functions and components). Based on this design process, a
methodical procedure is developed that incorporates the FMEA practice. The
benefits of the methodical procedures will be discussed at the end of this chapter.
4.1. Three-Phase Design Process

The three-phase design process focuses on the acquirement of the design
information as part of the design efforts. Particularly, the design information in
this research is referred to the design requirements, functions and components.
Notably, the development of this design information is similar to the mapping
process from the customer domain to the functional domain and then to the
physical domain in axiomatic design (Suh 2001). The research work here
emphasizes how to acquire the information of requirements, functions and
components systematically. The three phases of the process are labeled and listed
as follows.
Phase 1: Identification of requirements
Phase 2: Deployment of product functions
Phase 3: Definition of product components
31
4.1.1. Identification of requirements

In Phase 1, the major duty is to identify the list of customer requirements that can
characterize the directions of product development. The significance of
requirements has been well studied in quality engineering and six-sigma
management (Evans and Lindsay 2005). At this point, market research has
traditionally played an important role to collect and analyze the customers
expectations, needs, perceptions, and preferences. Typical techniques from market
research include formal survey, focus group, and internet monitoring (Bradley
2010).
Besides, the insights from designers and engineers are also important according
their knowledge and experiences. Meeting customer expectations is often
considered the minimum required to reach the bottom line of customer
satisfaction. To be competitive, it is necessary to delight customers by going
beyond the expectation, and therefore engineers insights about the industry
tendency and challenge are critical in identifying the requirements. Particularly,
the insights of engineers are important to determine the exciters / delighters in the
Kano classification system (Evans and Lindsay 2005). In addition, the insights of
engineers make sure the results of market research can be translated into technical
aspects without deviation.
Furthermore, the information of existing products can help the identification of

requirements. By studying the existing products from the competitors in the same
32
industry, we can compare the technical performance, product features and other
characteristics. This technique is so-called competitive benchmarking that is
common for setting realistic and competitive goals in product development
(Stapenhurst 2009).
The expected output of phase 1 is a list of requirements that characterize the

directions of product development. To get this point, method of quality function
decomposition (QFD) matrix is used. QFD is a focused methodology for carefully
listening to the voice of customer and then effectively responding to those needs
and expectations (Evans and Lindsay 2005). Several different types of matrices
are developed for different purposes of practicing QFD, such as requirements
matrix, design matrix, product characteristic matrix, and so on. For the purpose of
requirements identification here, the requirements matrix is used to transform the
customer requirements to design requirements, which is illustrated in the Figure 8.
Figure 8 Requirement matrix
33
4.1.2. Deployment of product functions

Based on the list of requirements, product functions are deployed to indicate the
engineering goals that are expected in the product. The deployment of product
functions can be viewed as translating the descriptions of a product from customer
languages into engineering languages. In product development, this process is
similar to the design matrix in QFD, which involves the mapping between
requirements to engineering characteristics (ASQ 2004). Yet, it should be noted
that engineering characteristics in QFD are referred to some measurable quantities
that are relevant to the satisfaction of customer requirements. Functions in this
research (discussed in Section 3.2) are different by definition.
To deploy the functions based on requirements, we can use some question-asking

techniques that are not uncommon in conceptual design. Given below are two
possible questions that are useful to deploy functions from requirements.
What are the expected inputs and outputs if the requirement is satisfied? The
conversion process between inputs and outputs can be described as
function(s).
What actions of the product need to be carried out in order to satisfy the
requirement?
The actions here can be expressed as the verbs of the
functional descriptions.
After deploying the product functions, two specific outputs are expected: a set of
functions and the mapping between requirements and functions. Referring to
34
Section 3.1, the set of functions is denoted as F = {f1, f2, , fn}. The mapping can
be expressed in a matrix denoted as RF = {rfij}, where rfij is equal to one if the jth
function is necessary to satisfy the ith requirement. Otherwise, rfij is equal to zero.
4.1.3. Definition of product components

Based on the list of functions, product components are defined to specify the
particular solutions to achieve the functions. A design concept is generally
obtained after defining the components that address all the product functions.
Then, the definition of product components can be viewed as the process of
concept generation in engineering design. Various techniques have been proposed
for concept generation such as brainstorming, morphological chart and axiomatic
design (Suh 2001).
In this research, the information of functions is one important input to stimulate

the definition of components. Particularly, the inputs and outputs of each function
help engineers imagine what engineering components are able to achieve such
conversion. Ulrich and Eppinger (2012, chapter 7) have introduced various search
techniques for concept generation such as searching the patents and engineering
handbooks. In addition, they have suggested some strategies for getting design
ideas in the thinking such as make analogies and wish and wonder.
Defining the components for achieving the functions can be viewed as a creative
process in design. The adjective creative here implies that we do not have an
35
automated path that can always lead to successful designs. Among some design
best practices (Stapenhurst 2009), engineers are suggested to focus on the
functional descriptions in view of the necessary inputs and outputs. This helps
them to clarify what exactly needs to be achieved in the products.
After defining the components, two specific outputs are expected: a set of
components and the mapping between functions and components. Referring to
Section 3.1, the set of components is denoted as C = {c1, c2, , cp}. The mapping
can be expressed in a matrix denoted as FC = {fcjk}, where fcjk is equal to one if
the kth component is required to achieve the jth function. Otherwise, fcjk is equal
to zero.
Notably, the aim of this section is not to propose a new design process. The
design information of requirements, functions and components has been discussed
abundantly in the literature of engineering design and product development (Pahl
et al. 2007). In this view, the purpose of this section is to generally discuss how
we obtain the design information in this research and specify the outputs that are
required in the methodical integration with FMEA.
4.2. FMEA Evaluation Schemes in the Design Process

Risk Priority number (RPN) is numerical ranking of the risk on each potential
failure mode, made up of the arithmetic product of the three elements: severity of
the effect, likelihood of occurrence of the cause, and likelihood of detection of the
36
cause. (Carlson 2012, chapter 3). The severity is given associated with the most
serious effect based on the scheme. The occurrence associates with the chance a
failure mode may occur. The detection is given based on the control plan, and it
associates with the chance a cause may be detected by the control method. The
schemes are specific to the companies, projects or products (e.g., the scaling table
may vary depending on the usage.) In this section, the evaluation scheme of these
three numerical ranking are provided in Table 1, Table 2, and Table 3. To give the
assessing number to each element, engineers followed by the evaluation scheme
tables in general. In the next section, a reasoning method is developed to obtain
these evaluated ranking systematically.
Definition of symbols:
S = severity ranking
O = occurrence ranking
D = detection ranking
RPN = (S x O x D)
Table 1 FMEA evaluation scheme for occurrence

Rank Occurrence
9-10 Frequency 1 in 20
7-8
Frequency 1 in 125
5-6
Frequency 1 in 1250
2-4
1 in 100000 Frequency 1 in 10000
1
Frequency 1 in 1000000
(ISO MIL-STD-105E & average sales quantity per model per region)
37
Table 2 FMEA evaluation scheme for severity

Rank Severity Requirement
Severity Function
9-10
7-8
Safety issue
The users meet difficulty
to operate the function
The users can operate
functions but the
performance is under
standard
Isolated defect and
doesnt affect function
execution
Invisible to users
5-6
2-4
Safety issue
The users choose
competitors products
The users need to return
the device to fix the
problem
The users might tolerate
the problem and continue
to use the product
Invisible to a user (make
no difference to a user)
Severity
Component
Safety issue
Effects on
primary function
Effects only on
secondary
function
Non-functional
effects
Invisible to a
user
Table 3 FMEA evaluation scheme for control detection

Rank
9-10
7-8
5-6
2-4
1
Detection
No apparent method to detect
Controlled by design analysis
Controlled by following standard design documents
Controlled by pass/fail or reliability test
Controlled by real-life product test (function-simulated test)
4.3. Reasoning of Causes and Effects in FMEA

Definitions of symbols:
S(FMari) = severity ranking of the ath failure mode of the ith requirement
S(FMafj) = severity ranking of the ath failure mode of the jth function
S(FMack) = severity ranking of the ath failure mode of the kth component
O(FMack) = occurrence ranking of the ath failure mode of the kth component
S(ri) = severity ranking of the ith requirement
38
S(fj) = severity ranking of the jth function

S(ck) = severity ranking of the kth component
O(ri) = occurrence ranking of the ith requirement
O(fj) = occurrence ranking of the jth function
O(ck) = occurrence ranking of the kth component
D(ck) = detection and control ranking of the kth component
Forward analysis of effects

The reasoning of effects showed below is to obtain the severity of effects of an
element (i.e. requirements, functions, and components). The purpose is to
prioritize the risk consequence of the element.
S(ri) = Maximum of S(FMari) (e.g. S(r1)= Max[S(FMar1)]
S(fj) = Maximum of S(FMafj) (e.g. S(f1)= Max[S(FMaf1)]
S(ck) = Maximum of S(FMack) (e.g. S(c1)= Max[S(FMac1)]
The reasoning of effects showed below is to obtain the severity of functions (and
components) from requirements (and functions.)
S(fj) = Maximum of [S(ri) of all rfij] (e.g. if f1 is deployed to satisfy both r1 and
r2 , then S(f1) is the maximum value of S(r1) and S(r2))
S(ck) = Maximum of [S(fi) of all fcjk] (e.g. if c1 is defined to achieve both f1
and f2 , then S(c1) is the maximum value of S(f1) and S(f2))
39
Backward analysis of causes

The reasoning of causes showed below is to obtain the occurrence of causes an
element (i.e. requirements, functions, and components). The purpose is to know
the chance of occurrence and complete the documentation of FMEAs to prioritize
the risk of failure modes.
O_components O_functions O_requirements

O(ck) = max O(FMack)
O(fj) = Maximum of [O(ck) of all fcjk] (e.g. if f1 has to be achieved by both c1
and c2 , then O(f1) is the maximum value of O(c1) and O(c2))
O(ri) = Maximum of [O(fi) of all rfij] (e.g. if r1 has to be satisfied by both f1
and f2 , then O(r1) is the maximum value of O(f1) and O(f2))
4.4. Methodical Procedure

A methodical procedure is developed that incorporates the FMEA practice in this
section. The procedure aligns with the general FMEA practice but the evaluation
rating is supported by the reasoning based on Section 4.3. The procedure is
showed as following and a comprehensive case study based on the procedure is
done in Chapter 5.
Step 1: identify the requirements and determine their failure modes

Identify the requirements (based on Section 4.1.1)
Determine their failure modes (based on Section 3.3)
40
Step 2: analyze the effects of requirements

Analyze the effects of requirements and decide severity (based on Section 4.2)
Determine S(ri) from reasoning by S(FMari) (based on Section 4.3)
Prioritize the risk consequences of requirements
Step 3: deploy the functions and determine their failure modes

Deploy the functions (based on Section 4.1.2 plus the risk consequences of
requirements from Step 2)
Step 4: analyze the effects of functions

Analyze the effects of functions and decide severity (based on Section 4.2)
Reasoning S(fj) by S(ri) (based on Section 4.3)
Reasoning S(fj) by S(ri)
Reasoning S(fj) by S(FMafj)
Determine S(fj)
Prioritize the risk consequences of functions
Step 5: define the components and complete the FMEA document in the
component domain
Define the components (based on Section 4.1.3) plus the information from
Step 4
41

Analyze effects and decide severity (based on Section 4.2)
Determine S(ck) (based on Section 4.3)
Reasoning S(ck) by S(fj)
Reasoning S(ck) by S(FMack)
Determine S(ck)
Causes
Analyze the causes of components and decide occurrence (based on
Section 4.2)
Determine L(FMack) (occurrence ranking) determine L(ck)
Define current control plan and assign detection (based on Section 4.2)
Complete the FMEA of component
Step 6: complete the FMEA document in the function domain

Analyze the causes of functions (based on Section 3.4)
Determine O(fj) (based on Section 4.3)
Complete FMEA of functions
Step 7: complete the FMEA document in the requirement domain

Analyze the causes of requirements (based on Section 3.4)
Determine O(ri) (based on Section 4.3)
Complete FMEA of requirements
42
Figure 9 below shows where above steps are incorporated in the procedure of
FMEA-facilitated design process.
Causes
Causes
Failure
Modes
Causes 5
6
3
Failure
Modes
Effects
2
3
Functions
Requirements
5
Failure
Modes
Effects
4
Effects
5
Components
Figure 9 Schematic diagram of the procedure of FMEA-facilitated design

process
After completing the FMEA-facilitated design process, benefits of the procedure

can be expected in view of the design practice, listed as below.
Cascade of the information of effects when performing the component
design helps engineers prioritize not only the failure mode itself but also the
risk of a component, a function, or a requirement. Besides, it motivates the
engineers make decisions on safe solutions at some critical parts when the
components selections are on the basis of the prioritization of the functions
risk consequences.
Logical development of FMEA documents by the support of reasoning the
rating numbers minimize the mental efforts and mistakes. At the same time,
the FMEA documents are completed in a relatively shorter time and more
accurate results.
43
The documentation of the FMEA of functions or the FMEA of requirements is

potentially to be used for re-design or re-engineering of the product. The
documents provide a guideline for engineers to assess the risk of the similar
products with similar requirements or functions.
44
Chapter 5: Case Study

A step-by-step real-life product case study is presented in this chapter to
demonstrate how the dependency model is applied and how it integrates the
failure modes and effects analysis documents in the product development process.
Three benefits are showed in the case study. First, one of the main outputs of each
phase (e.g. phases defined in Section 4.1) is the risk consequences. Supporting
with the method of reasoning the severity, it minimizes the human mistakes
during the severity rating activities. Second, the prioritization of risk
consequences helps engineers select components and be aware of the design detail
to prevent critical failures. Third, by the method of reasoning the occurrences of
causal factors, it helps engineers do the documentation of the efforts put in the
requirements and function analysis, and it is potentially re-used for the product
redesign.
In this research, design information is referred to the design requirements,

functions and components. Thus, the case study is presented based on the
sequence of these three design information: requirements domain, functions
domain and components domain.
5.1 Requirements Domain

In the requirements domain, the main object is to prioritize the customer needs
and the features which are going to delight and surprise the users. In the case
45
study, we started from listing five common customer requirements for the
smartphones in the market nowadays. After a series of analyses and reasoning the
severity rating value, we got the output of requirements domain: a list of
requirements and a list of prioritized risk consequences of requirements. They are
the inputs to deploy the functions in the next domain.
5.1.1 Identification of the requirements

First, five most common customer requirements are listed as below.
I can check and use my emails whenever I need it
I need videoconference to keep connective for my job
I like to listen to music sometimes
I like to have digital agenda and notebook with me
I like to keep in touch with friends through different social networks
The concept of requirement matrix in QFD methodology is used in this thesis to

translate customer requirements to design requirements (see Section 4.1.1). The
requirement matrix for this case study is showed in Table 4. After the analysis, we
got a list of design requirements showed as below.
R2: support videoconferencing
R3: support playing music
R4: support taking notes
R5: support sending messages
46
Table 4 Requirement matrix of smartphone example

support sending messages
support taking notes
support playing music
x
x
support videoconferencing
have an internet
connection at all time
I can check and use my emails whenever I need it
I need videoconference to keep connective for my job
I like to listen to music sometimes
I like to have digital agenda and notebook with me
I like to keep in touch with friends through different
social networks
x
x
x
x
5.1.2 Determination of the requirements failure modes

The classical failure manners can be classified because the failure modes are
considered and defined as the negation of the requirement description. In Section
3.3, modes of possible requirement failures are classified into five categories, and
here the worksheet is used to check each possible mode one by one. The list of
requirements failure modes is identified as below.
FM1r1: the smartphone cannot connect to internet
FM2r1: the users experience frequent interruptions of internet connection
FM3r1: it takes long time to connect to the internet
FM4r2: the smartphone doesnt support videoconferencing
FM5r2: the smartphone only supports part of the functions required in
videoconferencing
47
FM6r2: the users experience interruptions of image or voice transfer during

videoconferencing
FM7r3: the smartphone cannot play music
FM8r3: the smartphone can only play specific music files
FM9r4: the users cannot take notes by the smartphone
FM10r4: the users cannot take notes (e.g. some texts are unable to edit)
FM11r4: the users meet difficulties to take notes correctly (i.e. The users see
incorrect notes which are different from the ones edited)
FM12r5: the users cannot send messages
FM13r5: the users meet difficulties to send complete messages (e.g. some texts
are unable to edit)
FM14r5: the users meet difficulties to send correct messages (some texts are
different from the ones that users edited)
Table 5 Worksheet for identifying the failure modes of requirements
X
X
Improper
occurrence
X
X
X
X
Incorrectness
48
X
X
X
X
X
Intermittence
Have an internet connection at all times

Support video-conference
Support playing music
Support taking notes
Support sending messages
Incompleteness
Absence
R1
R2
R3
R4
R5
X
X
5.1.3 Effect analysis of the requirements failure modes

The effect analysis of the requirements failure modes is on the basis of the point
of view of users experiences because the requirements are identified to delight
the customers. Besides, the severity values are given based on the severity
evaluation scheme table (see Section 4.2), which is as same as the process in the
classical FMEA methodology, and the result is presented in Table 6.
Notably, how we predicted the users reactions in a reasonable manner when we

analyzed the effects of the failure modes of requirements? Keep in mind that the
design requirements are from customer requirements which were collected from
the market survey plus the engineers insights. As a result, the importance of these
requirements is categorization and prioritization during market research. For
example, if a requirement is considered as a must for all the users, such as having
internet connection, the absence of this requirement is considered as a critical
issue with a severity value 8. On the other hand, if a requirement is important for
some users but may not be a must for other users, such as supporting of taking
notes, the absence of this requirement is viewed as serious (because it is still listed
in the requirement list) but not critical, and thus we gave it a severity value 5.
The step follows by the effect analysis is to apply the concept of reasoning of
effects (see Section 4.3) after we marked all the severity values (See Table 6). The
49
first approach of reasoning of severity is defined as the maximum severity value

among all the failure modes of that requirement (i.e. S(ri) = Maximum of
S(FMari)). For example, the requirement R1 having an internet connection at all
times has three possible failure modes and each of them has one effect. Their
severity values are 8, 6, 4 respectively, and thus the reasoned severity value of R1
is 8 (e.g. S(r1) is 8.) The reasoned severity values of each requirement are listed as
below.
S(r1) = max S(FMar1)=8
Table 6 Effects analysis of requirement failure modes

Failure modes (FM) of requirements
The smartphone cannot support internet
connection
The users experience frequent interruptions
with internet connection
It takes long time to connect to the internet
The smartphone cannot support videoconference
The smartphone only supports part of the
functions required in video-conference
The users experience interruptions of
image or voice transfer during video50
Effects of requirements
FM
The users will change
smartphone
The users might
complain it and try to fix
the problem
The users might accept it
or tolerate it
The users will change
smartphone
The users will complain
it and try to fix the
problem
The users might
complain it
Severity
8
6
4
8
6
conferencing
The smartphone cannot play music
The smartphone can only play specific
music formats
The users cannot take notes by the
smartphone
The users cannot take all the notes desired,
some texts is unable to edit
The users meet difficulty to take notes
correctly (i.e. The users see incorrect notes
different from the ones edited)
The users cannot send messages
The users meet difficulty to send complete
messages, some texts is unable to edit
The users meet difficulty to send correct
messages (some texts is different from
edited)
The users might accept or

tolerate it
The users might not care
about it and adapt it
The users might
complain it
The users might
the problem.
The users might
the problem.
The users might change
smartphone.
and try to fix the problem
and try to fix the problem
3
3
4
5
7
6
6
5.1.4 Prioritization of the requirements risk consequences

From the severity value assigned to each effects of requirement failure mode, it is
obviously which requirement failure mode has higher risk and on which we need
to pay more attentions. In general, each company has their own standard in
selecting the critical ones according to the value of the severity value. In this case
study, we point out the ones with severity greater than or equal to 7. The
prioritization is to help engineers deploy the functions and make effect analysis
accordingly (e.g. if time is limited, the followed FMEA may only focus on the
critical requirements on the top of the prioritization list.)
51
The main requirements (Select the ones with S(ri) greater than or equal to 7):
The requirements failure modes on which engineers need to pay more attention:
The smartphone cannot support internet connection (SEV=8)
The smartphone cannot support video-conference (SEV=8)
The users cannot send messages (SEV=7)
5.2 Function Domain

In the function domain, two main inputs are the list of requirements and the list of
prioritized risk consequences of requirements. A RF matrix is made to show the
mapping between requirements and functions after deploying the functions from
requirements. Then, in the effect analysis, we obtained S(fj) by two different
approaches based on Section 4.3. One approach is obtaining S(fj) from the
severity value assigned by the evaluation scheme table (see Section 4.2). The
other approach is obtaining S(fj) from reasoning of severity values of relevant
requirements (see Section 4.3). From the comparison of these two S(fj) values
from different reasoning approaches, the more accurate severity values are
decided and assigned eventually to the corresponding effects of function failure
modes.
52
5.2.1 Deployment of functions

The input of the list of requirements helps us deploy functions (see Section 4.1.2).
With the question-asking technique and the experience of engineers, a set of
functions are listed as below. Accordingly, the mapping between requirements
and functions is presented in RF matrix (See Table 7). In the RF matrix, rfij is
equal to one represents that the jth function is necessary to satisfy the ith
requirement. Otherwise, rfij is equal to zero.
Deployment of functions:
R1: Have an internet connection at all time
Receive internet signal
Transmit internet connection request
Capture video
Capture sound
Process image signal
Process sound signal
Display image signal
Display sound signal
Transport sound signal to other device
Connect to Internet/network
53
R3: support playing music

Transport sound signal to other device
R4: support taking notes
Input texts
Process texts
Display texts
Store edited files
Input texts
Process texts
Display texts
Connect to internet/network
Thus, we got a list of functions.
F1: Receive internet signal
F2:Transmit internet signal
F3:Capture video
F4:Capture sound
F5:Process image signal
F6:Process sound signal
F7:Display image signal
F8:Display sound signal
54
F9:Transport sound to other device

F10:Input texts
F11:Process texts
F12:Display texts
F13:Store edited files
Table 7 RF matrix of the mapping between requirements and functions

R1
R2
R3
R4
R5
F1
1
1
0
0
1
F2
1
1
0
0
1
F3
0
1
0
0
0
F4
0
1
0
0
0
F5
0
1
0
0
0
F6
0
1
1
0
0
F7
0
1
0
0
0
F8
0
1
1
0
0
F9
0
1
1
0
0
F10
0
0
0
1
1
F11
0
0
0
1
1
F12
0
0
0
1
1
F13
0
0
0
1
0
5.2.2 Determination of the function failure modes

Using the worksheet with the failure modes of functions defined in Section 3.3,
we reviewed each possible mode and then got a list of function failure modes. The
worksheet is showed in Table 8.
FM1f1: The smartphone doesnt receive internet signal
FM2f1: It takes too much time to receive internet signal
FM3f2: The smartphone doesnt transmit internet signal
FM4f2: It takes too much time to transmit internet signal
FM5f3: The smartphone doesnt capture video
FM6f4: The smartphone doesnt capture sound
FM7f5: The smartphone doesnt process image signal
55
FM8f5: It takes too much time to process image signal

FM9f6: The smartphone doesnt process sound signal
FM10f7: The smartphone doesnt display image signal
FM11f7: The image display is interfered
FM12f8: The smartphone doesnt display sound signal
FM13f8: The sound display is interfered
FM14f9: The smartphone doesnt transport sound to other device
FM15f10: It doesnt input texts (no reaction after users entered texts)
FM16f10: After certain of time, it doesnt input texts
FM17f10: Some texts cannot be input
FM18f10: The input texts are different from users action
FM19f11: The smartphone cannot process texts
FM20f11: It takes too much time to process texts
FM21f12: The smartphone cannot display texts
FM22f12: The texts display is interfered
FM23f13: The smartphone cannot store edited files
Table 8 Worksheet for identifying the failure modes of functions

Incorrectness
X
X
Incompleteness
56
Improper
occurrence
X
X
X
Decayed

Transmit internet signal
Capture video
Interference
Malfunction
F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
Capture sound
Transport sound to other device
Input texts
Process texts
Display texts
Store edited files
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
5.2.3 Effect analysis of function failure modes

The effect of function failure modes is on the point of view that how it affects the
requirement satisfaction (see the integrated dependency model presented in
Section 4.4.) And according to the evaluation scheme table (see Section 4.2) and
with the support reference of the prioritized risk consequences of requirements,
the severity value of each effect is marked preliminarily (e.g. the prioritized risk
consequences of requirements provide engineers an overview on the impacts of
the potential failure modes). The complete analysis is showed in Table 9.
Table 9 Effect analysis of function failure modes

Functions Failure modes (FM) of
functions
F1
The smartphone
doesnt receive
internet signal
It takes too much time
to receive internet
signal
Effects of functions FM
Severity
The users cannot connect to

internet
The users have to wait some

time to connect to internet
57
F2
F3
F4
F5
F6
F7
F8
F9
F10
The smartphone
doesnt transmit
internet signal
to transmit internet
signal
The smartphone
doesnt capture video
The smartphone
doesnt capture sound
The smartphone
doesnt process image
signal
to process image
signal
The smartphone
doesnt process sound
signal
The smartphone
doesnt display image
signal
The image display is
interfered
The smartphone
doesnt display sound
signal
The sound display is
interfered
The smartphone
doesnt transport
sound to other device
It doesnt input texts
(no reaction after users
enter texts)
After certain time, it
doesnt input texts
Some texts cannot be
input
The input texts are

internet
The users have to wait some

time to connect to internet
The users cannot make

videoconferencing
The users cannot make phone
calls
The users cannot take photos or
see any images on the screen
The users have to wait to see the

processed result showed on the
screen
calls or listen to music
The users see nothing on the

screen
The users see extra lines or dots

on the screen
The users hear noise
The users cannot use their own

device (such as earphone) to
hear the sound
The users cannot enter texts
The users might meet difficulties

to enter texts after certain time
The users cannot enter all the
texts desired
58
8
8
8
8
F11
F12
F13
different from users

action
The smartphone
cannot process texts
to process texts
The smartphone
cannot display texts
The texts display is
interfered
The smartphone
cannot store edited
files
correctly
screen
screen
screen
on the screen
The users might lose files
8
3
8
6
7
5.2.4 Reasoning of severity S(fi)

According to Section 4.3, the severity value can be reasoned by two approaches:
Reasoning from S(ri) : S(fj) = Maximum of [S(ri) of all rfij]
Reasoning from S(FMafj): S(fj) = Maximum of S(FMafj)
The severity evaluation scheme table provides a general idea about the impact of
the function failure modes. Meanwhile, it is necessary to take consideration on the
severity of requirement failure modes because the reason we deployed functions
is to satisfy the requirements.
59
First approach (e.g. S(fj) = Maximum of [S(ri) of all rfij]:

We already knew S(ri) from Section 5.1.3 , and we also know the mapping
between requirements and functions from Table 7. By applying the reasoning of
severity, we got the S(fj) from the first approach and showed them in the Table 10.
Table 10 Severity of functions by reasoning from S(ri)

S(fj)
F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13

8 8 8 8 8 8 8 8 8
7
7
7
5
Second approach (e.g. S(fj) = max S(FMafj) ):

We have preliminarily marked severity values to all the effects of function failure
modes in Table 9. From the reasoning of S(fj) = max S(FMafj), we got the S(fj)
from the second approach and showed them in the Table 11.
Table 11 Severity of functions by reasoning from S(FMafj)

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13
S(fj) 8 8 7 8 8 8 8 8 3
8
8
8
7
Comparing the S(fj) obtained from two approaches, we noted that the severity
value of function Transport sound to other device (F9) is obviously different.
How does it happen? Lets go back to review the analysis process.
In the effect analysis of function failure modes (See Table 9), function transport
sound to other device might have one failure modes which is the malfunction
(e.g. the function cannot be executed), and its effect is that the user cannot use
60
their own device such as earphone to hear the sound. It doesnt sound too serious
because the smartphone is still able to play the sound and thus the severity value
was given as 3 (i.e. According to the evaluation scheme table, it is an isolated
problem that does not affect executing the function of playing the sound.) Yet, if
we take a closer look at the function deployment process and the relations
between requirements and functions, we also have to consider that having privacy
during making videoconferencing is an important aspect especially the failure
mode The smartphone only supports part of the functions required in videoconference was listed as critical failure modes on the top of prioritization list of
risk consequences of requirements. Viewed on this point, the severity of effect of
unable to transport sound to other device should be marked at least more serious
than others.
To make sure the severity value doesnt be mistakenly assigned less serious, we
compared the Table 10 and Table 11, the bigger value was treated as the relatively
more accurate value. The modified severity of effects of function failure modes is
showed in Table 12. By referring to the severity of functions, it is obviously the
functions with bigger severity values are the main functions the engineers need to
pay more attention.
Table 12 Modified severity of functions

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13
S(fj) 8 8 8 8 8 8 8 8 8
8
8
8
7
61
Noted the severity values in FMEA only provide an idea about which failure
mode is relatively more serious or less serious and thus the values absolute
values have no meaning in the analysis unless it is compared with others.
Therefore, when we modified one value, it was necessary to review other values
to make sure the tendency and relative relationship still exist. Thus,
meanwhile we modified the severity value in the effect analysis (Section 5.2.3) by
taking reference of Table 10, and the modified effect analysis of function domain
is showed in the Table 13.
Table 13 Modified effect analysis with severity values in function domain

Functions Failure modes of
functions
F1
The smartphone
doesnt receive internet
signal
to receive internet
signal
F2
The smartphone
doesnt transmit
internet signal
to transmit internet
signal
F3
The smartphone
doesnt capture video
F4
The smartphone
doesnt capture sound
F5
The smartphone
doesnt process image
signal
to process image signal
Severity

internet
The users have to wait some time

to connect to internet

internet
The users have to wait some time

to connect to internet

videoconferencing
calls
The users cannot take photos or
see any images on the screen

62
8
8
F6
F7
F8
F9
F10
F11
F12
F13
The smartphone
doesnt process sound
signal
The smartphone
doesnt display image
signal
The image display is
interfered
The smartphone
doesnt display sound
signal
The sound display is
interfered
The smartphone
doesnt transport sound
to other device
It doesnt input texts
(no reaction after users
entered texts)
After certain of time, it
doesnt input texts
Some texts cannot be
input
The input texts are
different from users
action
The smartphone cannot
process texts
to process texts
display texts
The texts display is
interfered
store edited files
screen

screen

on the screen
The users cannot use their own

device (such as earphone) to hear
the sound
The users might meet difficulties

to entered texts after certain of
time
The users cannot enter all the
texts desired
correctly

screen
screen
screen
on the screen
The users might lost files
63
8
8
8
6
7
5.2.5 Prioritization of the function risk consequences

From the modified severity value showed in Table 13, the risk consequences of
functions are prioritized and listed as below. Similar to Section 5.1.4, the
engineers are free to choose the critical ones to monitor depending on the projects.
In this case study, we listed the functions and their failure modes with the severity
greater than or equal to 7.
The main functions (Select the ones with S(fj) greater than or equal to 7):
In this case study, all the functions are treated as main functions because all the
S(fj) are greater than or equal to 7. The list below is the relatively more serious
ones and therefore we treated them as prioritized functions.
The most important function (S(fj) is 8):
F1: Receive internet signal
F2: Transmit internet signal
F3: Capture video
F4: Capture sound
F5: Process image signal
F6: Process sound signal
F7: Display image signal
F8: Display sound signal
F9: Transport sound to other device
64
Notably, the prioritized risk consequences of functions and requirements should

be matched with each other because the functions are deployed from the
requirements. If the results are not matched, the engineers have to review the
analysis process.
For their failure modes, we listed the failure modes with severity value greater
than or equal to 7.
The most critical ones: (SEV=8)
The smartphone doesnt receive internet signal
The smartphone doesnt transmit internet signal
The smartphone doesnt capture video
The smartphone doesnt capture sound
The smartphone doesnt process image signal
The smartphone doesnt process sound signal
The smartphone doesnt display image signal
The smartphone doesnt display sound signal
The smartphone doesnt transport sound to other device
Also critical ones that need to pay more attention on: (SEV=7)
It doesnt input texts (no reaction after users entered texts)
Some texts cannot be input
The input texts are different from users action
The smartphone cannot process texts
The smartphone cannot display texts
65
Before moving on to the next domain in the case study, notably, as so far we have
already showed the two benefits that how the dependency model helps to
minimize the mistakes of human factors and how it helps save time when
engineers are giving the severity value. Even though the mistake may be avoided
by reviewing each effect analysis one by one carefully, it will take much more
time.
5.3 Component Domain

In the component domain, the main input is the function list. After defining the
components to achieve the functions, the design concept is now ready to define
the solutions for each function. Similarity to the function domain, the reasoning
approaches also help engineers make effect analysis. What we should not forget is
that the purpose of performing FMEA is to prevent serious failures and to do
quality management. In other words, the main output of the component domain is
not only a design concept but also a control plan. Based on this point, we also
make causes analysis and define the control plan to complete the FMEA
document for components.
5.3.1 Definition of the components

To define the components, we have two inputs: a list of functions and a list of risk
consequences prioritization of functions. The definition of components is the
66
particular solutions to achieve the functions, and thus the components are defined
one by one based on the list of functions. Particularly, the function description
and the knowledge from engineers help us to imagine what components are
required. For example, to achieve the function receive internet signal, the
engineers knows there are two main internet signals: one is from Wi-Fi and
another one is from GSM, and therefore the product might need Wi-Fi antenna or
GSM transceiver or both of them to achieve the function.
The components are defined in Table 14 by taking reference of the smartphone

that we disassembled (e.g. the complete component list is displayed in Appendix
1). For example, different components are available to achieve the function of
input texts nowadays such as capacitive touchscreen, resistive touchscreen,
keyboard, or so on. In this case study, we defined the component to satisfy the
function of input texts as keyboard from the real-life product on hand. Besides, a
FC matrix is showed in Table 15 to present the mapping between functions and
components. In the FC matrix, fcjk is equal to one represents that the kth
component is defined to achieve the jth function. Otherwise, fcjk is equal to zero.
Table 14 Components and their corresponding functions to achieve

F1
Functions
F2
Transmit internet signal
F3
F4
F5
Capture video
Capture sound
Components (sub-systems)
Wi-Fi antenna
GSM transceiver
Wi-Fi antenna
GSM transceiver
Camera module
Microphone
Graphic processing unit (GPU)
67
F6
F7
F8
F9
F10
F11
F12
F13
Central processing unit (CPU)

Audio Codec
Audio processing unit (APU)
CPU
LCD display module
Headphone, speaker
Transport sound to other device Audio jack
Input texts
Keyboard module, scroll key module
Process texts
CPU
Display texts
LCD display module
Store edited files
ROM, RAM, expansion slot
Table 15 Mapping between functions and components (FC matrix)

F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
C1
1
1
0
0
0
0
0
0
0
0
0
0
0
C2
1
1
0
0
0
0
0
0
0
0
0
0
0
C3
0
0
1
0
0
0
0
0
0
0
0
0
0
C4
0
0
0
1
0
0
0
0
0
0
0
0
0
C5
0
0
0
0
1
0
0
0
0
0
0
0
0
C6
1
1
1
1
1
1
1
1
1
1
1
1
1
C7
0
0
0
0
0
1
0
0
0
0
0
0
0
C8
0
0
0
0
0
1
0
0
0
0
0
0
0
C9
0
0
0
0
0
0
1
0
0
0
0
1
0
C10
0
0
0
0
0
0
0
1
0
0
0
0
0
C11
0
0
0
0
0
0
0
1
0
0
0
0
0
C12
0
0
0
0
0
0
0
0
1
0
0
0
0
C13
0
0
0
0
0
0
0
0
0
1
0
0
0
C14
0
0
0
0
0
0
0
0
0
1
0
0
0
C15
0
0
0
0
0
0
0
0
0
0
0
0
1
C16
0
0
0
0
0
0
0
0
0
0
0
0
1
5.3.2 Determination of components failure modes

Failure modes of components are already defined in Section 3.3. Here, we used
the worksheet to review each possibility, and the result is displayed in Table 16.
In the product design, it is assumed and it is suggested to assume the raw
materials (i.e. components or sub-systems in the case study) all function well and
68
C17
0
0
0
0
0
0
0
0
0
0
0
0
1
meet their specifications because the manufacturing, processing or shipping

process are not controllable at this stage of conceptual design development. If
engineers focus too much on the uncontrollable failure modes and causes, the
FMEAs wont benefit in the design to improve the product quality because the
analysis tend to blame the suppliers or manufacturers but not make quality
improvement on the design itself.
The failure modes of components are listed as below.
FM1c1: Wi-Fi antenna loses efficiency
FM2c2: GSM transceiver is damaged
FM3c2: GSM transceiver loses its efficiency
FM4c2: GSM transceiver emits radiation
FM5c3: Camera module is damaged
FM6c3: Camera modules driver is not compatible
FM7c4: Microphone is damaged
FM8c4: Microphones driver is not compatible
FM9c5: GPU is damaged
FM10c5: GPU emits radiation
FM11c5: GPU and operating system (OS) is not compatible
FM12c6: CPU is damaged
FM13c6: CPU emits radiation
FM14c6: CPU and OS is not compatible
FM15c7: Audio Code is damaged
FM16c7: Audio Code is not compatible with drivers
69
FM17c8: APU is damaged

FM18c8: APU emits radiation
FM19c8: APU and OS is not compatible
FM20c9: LCD display module is damaged
FM21c10: Headphone is not compatible with its driver
FM22c11: Speaker is not compatible with its driver
FM23c12: Audio jack is damaged
FM24c13: Keyboard is damaged
FM25c13: Keyboard module loses its efficiency
FM26c14: Scroll key module loses its efficiency
FM27c15: ROM emits radiation
FM28c16: RAM emits radiation
FM29c17: Expansion slot is damaged
Table 16 Worksheet of components failure modes
C1
C2
C3
C4
C5
C6
C7
C8
C9
Wi-Fi antenna
GSM transceiver
Camera module
Microphone
Graphic processing unit
(GPU)
Central processing unit
(CPU)
Audio Codec
Audio processing unit
(APU)
LCD display module
Damaged Loss of
efficiency
X
X
X
X
X
X
X
X
X
X
70
EMI Noncompatible
X
X
X
X
X
X
X
X
X
C10
C11
C12
C13
C14
C15
C16
C17
Headphone
Speaker
Audio jack
Keyboard module
scroll key module
ROM
RAM
Expansion slot
X
X
X
X
X
X
X
X
5.3.3 Effect analysis of the components failure modes

Effect of components failure modes focus on the impacts of functions
achievement, the mapping is showed in the integrated model in Section 4.4. For
example, if a Wi-Fi antenna loses efficiency (e.g. doesnt function as wrote in the
specification), it might have an effect that the smartphone meet difficulty to
connect to Wi-Fi network. The severity value is assigned based on the evaluation
scheme table defined in Section 4.2, and the effect analysis is showed in Table 17.
Table 17 Effect analysis of components failure modes

Components Failure modes (FM) of
components
C1
Wi-Fi antenna loses
efficiency
C2
C3
GSM transceiver is
damaged
GSM transceiver loses
its efficiency
GSM transceiver emits
radiation
Camera module is
Effects of components FM
The smartphone meets
difficulty to connect to Wi-Fi
network
connect to GSM network
difficulty to connect to GSM
network
Signal output display might
be interfered
The smartphone cannot get
71
Severity
7
8
7
4
7
C4
damaged
Camera modules driver
is not compatible
Microphone is damaged
C5
Microphones driver is
not compatible
GPU is damaged
GPU emits radiation
C6
GPU and operating

system (OS) are not
compatible
CPU is damaged
CPU emits radiation
C7
CPU and OS are not

compatible
Audio Code is damaged
C8
Audio Code is not

compatible with drivers
APU is damaged
APU emits radiation
C9
C10
C11
C12
APU and OS is not

compatible
LCD display module is
damaged
Headphone is not
compatible with its
driver
Speaker is not
compatible with its
driver
Audio jack is damaged
images
images
sounds from users
sounds from users
process image signal
The signal output display
might be interfered
7
8
8
8
4
8

execute any function
might be interfered
process sound signal
might be interfered
display images/texts
display sounds

display sounds
Sound signal cannot be

transported to other devices
72
4
8
8
8
8
4
8
8
8
C13
Keyboard is damaged
C14
C15
Keyboard module loses

its efficiency
Scroll key module loses
its efficiency
ROM emits radiation
C16
RAM emits radiation
C17
Expansion slot is
damaged
The users cannot input

texts/instruction by keyboard
The users meet difficulty to
input texts/instruction
might be interfered
might be interfered
The smartphone has limited
storage capacity
8
5
5
4
4
3
5.3.4 Reasoning severity S(ck)

Two reasoning approaches are used to get severity of components failure modes
based on Section 4.3.
Reasoning from S(fj): S(ck) = Maximum of [S(fi) of all fcjk]
Reasoning from S(FMack): S(ck) = Maximum of S(FMack)
The first approach considers that the components are defined to achieve function
description and therefore the severity of components failure modes can be derived
from the severity of the function and the mapping between functions and
components. The second approach considers the severity valueing from the
evaluation scheme table defined in Section 4.2.
73
First approach (e.g. S(ck) = Maximum of [S(fi) of all fcjk]:

We got the S(fj) in Table 12 in Section 5.2.1, and the mapping between functions
and components is showed in Table 15. By the reasoning of severity, the S(ck) is
presented in Table 18.
Table 18 Severity of components by reasoning from S(fj)

Components S(ck) Components S(ck)
C1
8
C10
8
C2
8
C11
8
C3
8
C12
8
C4
8
C13
7
C5
8
C14
7
C6
8
C15
6
C7
8
C16
6
C8
8
C17
6
C9
8
Second approach (e.g. S(ck) = Maximum of S(FMack)):
The severity values are preliminarily marked in Table 17 based on the evaluation
scheme table defined in Section 4.2. By the reasoning of severity from it, we got
the S(ck) and they are displayed in Table 19.
Table 19 Severity of components by reasoning from S(FMack)

C1
7
C10
8
C2
8
C11
8
C3
7
C12
6
C4
8
C13
8
C5
8
C14
5
C6
8
C15
4
C7
8
C16
4
74
C8
C9
8
8
C17
From the comparison of the S(ck) reasoned by two approaches, obviously some
effects of components failure modes are under estimated in Table 17. For
example, the damaged expansion slot (C17) has an effect the smartphone has
limited storage capacity, if engineers dont consider it has negative effect on the
function description store edited files, the severity rating will be low based on
the evaluation scheme table. It may not be totally wrong if other components (e.g.
ROM and RAM) support this function both work perfectly, and it is the reason
that on the effect analysis, the defect of expansion slot is not marked as serious
effect. But when dont have control or confidence that other components are
without any defects, it is better we assume the function need this component to be
executed. Thus, the modified severity of components is showed in Table 20.
As mentioned in function domain, we also modified the severity values based on

the Table 20, and the modified effect analysis is displayed in Table 21.
Table 20 Modified severity of components

C1
8
C10
8
C2
8
C11
8
C3
8
C12
8
C4
8
C13
8
C5
8
C14
7
C6
8
C15
6
C7
8
C16
6
C8
8
C17
6
75
C9
Table 21 Modified effect analysis with severity values in component domain

Components Failure modes
C1
Wi-Fi antenna loses
efficiency
SEV
8
C2
C3
C4
C5
C6
C7
Effects
difficulty to connect to Wi-Fi
network
GSM transceiver is
damaged
connect to GSM network
GSM transceiver loses its The smartphone meets
efficiency
difficulty to connect to GSM
network
GSM transceiver emits
Signal output display might be
radiation
interfered
Camera module is
damaged
images
Camera modules driver is The smartphone cannot get
not compatible
images
sounds from users
Microphones driver is not The smartphone cannot get
compatible
sounds from users
GPU is damaged
GPU emits radiation
might be interfered
GPU and operating
system (OS) are not
compatible
CPU is damaged
CPU emits radiation
might be interfered
CPU and OS are not
compatible
Audio Code is not
76
6
8
8
8
8
8
6
8
8
6
8
8
8
C8
C9
C10
C11
C12
C13
C14
C15
C16
C17
compatible with drivers

APU is damaged

APU emits radiation
might be interfered
APU and OS are not
compatible
The smartphone cannot display
damaged
images/texts
Headphone is not
The smartphone cannot display
compatible with its driver sounds
Speaker is not compatible The smartphone cannot display
with its driver
sounds
Sound signal cannot be
transported to other devices
Keyboard is damaged
The users cannot input
texts/instruction by keyboard
Keyboard module loses its The users meet difficulty to
efficiency
Scroll key module loses
its efficiency
ROM emits radiation
might be interfered
RAM emits radiation
might be interfered
Expansion slot is damaged The smartphone has limited
storage capacity
8
6
8
8
8
8
8
8
7
7
6
6
6
5.3.5 Cause analysis of components failure modes

Based on Section 3.2, the cause analysis in FMEA has to be the controllable and
improvable causes that are capable being eliminated or monitored by engineers.
View on this point, for every cause of component failure modes, the reason for the
causal factor existence is the improper design. Thus, we listed some common
possible design failures as below.
77
Improper calculation of dimension, tolerance or shape

Improper component selection, including materials and specifications.
Improper circuit analysis
Lack of components or required protection
Inconsideration of operation conditions in real life
The cause analysis mainly depends on engineers experience and knowledge. The
above list is only a reference for engineers to review and assess the possibility in a
certain failure mode. In the real situation, it is still suggested engineers write
down the causes in a clear manner. For example, the Wi-Fi antenna loses
efficiency is analyzed to be caused by shielding (i.e. the component Wi-Fi
antenna works complying with its specification and the signal coverage is good
and strong. Nevertheless, the component (may be a frame) between the signal
coverage and the antenna shields the signal and prevent the Wi-Fi antenna
receiving the signal.) It belongs to the improper component selection (i.e. the
thickness of the frame may be too thick that is over the Wi-Fi antennas capacity).
Another possible cause is the static electricity from the users and it can be
categorized into the design failure of inconsideration of operation conditions in
real life and as well as improper component selection (the material of the frame is
too sensitive to the static electricity and affects the components inside the frame).
The reason that engineers should think from the possible design failures and write
down in a clear description is that it is clearer for the record and it is easier for
engineers to assess the occurrence.
78
After the cause analysis, the occurrence value is given preliminarily based on the
evaluation scheme table defined in Section 4.2. (See Table 22)
Table 22 Cause analysis of components failure modes

Failure modes of components
Wi-Fi antenna loses efficiency
GSM transceiver is damaged
GSM transceiver loses its
efficiency
GSM transceiver emits radiation
Camera module is damaged
Camera modules driver is not
compatible
Microphones driver is not
compatible
GPU is damaged
GPU emits radiation
GPU and operating system (OS)
are not compatible
CPU is damaged
CPU emits radiation
CPU and OS are not compatible
Audio Code is not compatible
with drivers
APU is damaged
APU emits radiation
APU and OS are not compatible
Causes of components FM
Shielded
Static electricity
Electrostatic discharge (ESD)
Shielded
Occurrence
6
6
4
6
Lack of proper EMI shielding

ESD
Overcurrent
Improper components selection
4
4
4
2
ESD
4
2
ESD
Overcurrent
4
4
4
2
ESD
Overcurrent
ESD
Overcurrent
4
4
4
2
4
4
2
ESD
Overcurrent
4
4
4
2
79
LCD display module is damaged

Headphone is not compatible
with its driver
Speaker is not compatible with
its driver
Keyboard is damaged
Keyboard module loses its
efficiency
Scroll key module loses its
efficiency
ROM emits radiation
RAM emits radiation
Expansion slot is damaged
Overcurrent
External force
3
3
2
Insensitive contact (improper

component selection or
improper
tolerance design)
External force
Improper tolerance design
Improper component selection

Dimension mismatch
4
5
Improper component selection

External force
4
4
4
1
3
5
5.3.6 Reasoning of causes of components failure modes

The reasoning of causes of components failure modes is defined as O(ck) = max
O(FMack) in Section 4.3. The reasoned O(ck) are listed in Table 23.
Table 23 Reasoned occurrence of components failures modes

Components L(ck) Components L(ck)
C1
6
C10
2
C2
6
C11
2
C3
4
C12
1
C4
4
C13
5
C5
4
C14
5
C6
4
C15
4
C7
4
C16
4
80
C8
C9
4
3
C17
5.3.7 Decision of control plan and detection

One of the valuable outputs of FMEA is the quality control plan. After the cause
and effect analysis for the component failure modes and relevant severity and
occurrence ranking, the engineers get basic ideas about the failure modes. The
occurrence and the severity values provide a guideline for designers to decide the
control methods. If these two rating values are both high, it is necessary for
engineers to decide a control method with low detection.
One type of control plan is eliminating the causal factor, such as setting the
dimension tolerance by following a guideline (might be an internal document
such as SOP in a company) to prevent dimension miscalculation. The other type
of the control plan is detecting the causal factor, such as performing function test.
Nevertheless, it is relatively harder to define the control method because the case
study focuses on the early design stage (i.e. conceptual design). In other words,
the engineers may suggest that the component needs to be checked by functional
test in order to monitor the possible failure modes, but the functional test machine
will not be made in the conceptual design. Yet, the engineers can still write down
the current control method and rate them based on Section 4.2 to assess overall
risk by the risk priority value (RPN). (See Table 24)
81
5.3.8 Completion of FMEA for components

After all the preparing work in Section 5.3, we had all the materials on hands to
complete the document of FMEA for component. The completion of FMEA for
components is one of the milestones in the product development process. The
FMEA for components provides a guideline for engineers to consider the
components specification selection and the proper quality control plan to prevent
critical failures. The critical failures mean the critical ones that we prioritized in
requirements and functions domains.
With the supporting document of the prioritized risk consequences of functions,

the engineers are able to review design concept. In other words, engineers are able
to define a component or components as a solution of a functional description
easily. However, it doesnt give engineers more information on selecting the
specification of components or the design details such as component location and
relations with other components. For example, the engineers may put Wi-Fi
antenna and GSM transceiver in the smartphone design to provide the feature of
internet connection to the users, but without careful thinking about how serious
the impact is when the component failure modes occurred or how it may affect the
users, the engineers may not pay much attention on these components. The wellknown examples are antennagate happened on iPhone 4 and similar issue
happened on HTC legend.
82
It doesnt mean that the integration of FMEA and design development process can
prevent such fails, but at least the engineers have more chance to see the
possible result about the improper design by the supporting documents of
prioritized risk consequences. Besides, the integration of FMEAs in the
conceptual design makes sure the ratings are consistent throughout the product
development process and minimize the mistakes of human factors by reasoning
the cause and effects.
Furthermore, engineers are able to review the critical failure modes of

components after completing the FMEA for components by RPN. It gives
engineers more information to select proper components or to decide the control
plan when the design is done. For example, in Table 24, the row with relatively
higher RPN is GSM transceiver is damaged by ESD and it has a high severity
effect because the smartphone will be unable to connect to GSM network. In this
case, the engineers definitely need to design protection to protect GSM
transceiver from ESD in the processes of handling the GSM transceiver
component, or to design the method to eliminate the static electricity, or to select
a GSM transceiver less sensitive to static electricity.
Table 24 FMEA for components

Components Failure
modes
Wi-Fi
Wi-Fi
antenna
antenna loses
efficiency
Effects
S Causes
O Control
D RPN
The
smartphone
meets difficulty
to connect to
8 Shielded
83
Follow
design
SOP
240
Wi-Fi network
Static
electricity
GSM
transceiver
GSM
transceiver is
damaged
GSM
transceiver
loses its
efficiency
Camera
module
Microphone
GPU
GSM
transceiver
emits
radiation
Camera
module is
damaged
The
smartphone
cannot connect
to GSM
network
The
smartphone
meets difficulty
to connect to
GSM network
Signal output
display might
be interfered
8 Electrostatic 4
discharge
(ESD)
The
smartphone
cannot get
images
Camera
modules
driver is not
compatible
Microphone
is damaged
The
smartphone
cannot get
images
The
smartphone
cannot get
sounds from
users
Microphones The
driver is not
smartphone
compatible
cannot get
sounds from
users
GPU is
The
84
Follow
design
SOP
None
240
288
7 Shielded
Follow
design
SOP
210
6 Lack of
proper EMI
shielding
Design 7
analysis
168
8 ESD
None
288
Overcurrent
160
8 Improper
components
selection
Follow 5
design
SOP
Design 7
analysis
8 ESD
None
288
8 Improper
components
selection
Design 7
analysis
112
8 ESD
None
288
112
damaged
GPU emits
radiation
CPU
GPU and
operating
system (OS)
are not
compatible
CPU is
damaged
CPU emits
radiation
CPU and OS
are not
compatible
Audio Code
Audio Code
is damaged
Audio Code
is not
compatible
smartphone
cannot process
image signal
Overcurrent
The signal
output display
might be
interfered
The
smartphone
cannot process
image signal
6 Lack of
proper EMI
shielding
8 Improper
components
selection
The
smartphone
cannot execute
any function
8 ESD
The signal
output display
might be
interfered
The
smartphone
cannot execute
any function
The
smartphone
cannot process
sound signal
The
smartphone
cannot process
85
Follow 5
design
SOP
Design 7
analysis
160
Design 7
analysis
112
None
288
Overcurrent
160
6 Lack of
proper EMI
shielding
Follow 5
design
SOP
Design 7
analysis
8 Improper
components
selection
Design 7
analysis
112
8 ESD
None
288
Overcurrent
160
8 Improper
components
selection
Follow 5
design
SOP
Design 7
analysis
168
168
112
APU
with drivers
APU is
damaged
APU emits
radiation
APU and OS
is not
compatible
LCD
display
module
Headphone
Speaker
Audio jack
Keyboard
module
LCD display
module is
damaged
sound signal
The
smartphone
cannot process
sound signal
The signal
output display
might be
interfered
The
smartphone
cannot process
sound signal
The
smartphone
cannot display
images/texts
Headphone is
not
compatible
with its driver
Speaker is
not
compatible
with its driver
Audio jack is
damaged
The
smartphone
cannot display
sounds
The
smartphone
cannot display
sounds
Sound signal
cannot be
transported to
other devices
Keyboard is
damaged
The users
cannot input
86
8 ESD
None
288
Overcurrent
160
6 Lack of
proper EMI
shielding
Follow 5
design
SOP
Design 7
analysis
8 Improper
components
selection
Design 7
analysis
112
8 Overcurrent
Follow
design
SOP
120
External
force
8 Improper
components
selection
None
243
Design 7
analysis
112
8 Improper
components
selection
Design 7
analysis
112
8 Insensitive
contact
(improper
component
selection or
improper
tolerance
design)
8 External
force
Design 7
analysis
56
None
243
168
Keyboard
module loses
its efficiency
Scroll key
module
Scroll key
module loses
its efficiency
ROM
ROM emits
radiation
RAM
RAM emits
radiation
Expansion
slot
Expansion
slot is
damaged
texts/instruction
by keyboard
The users meet 7 Improper
difficulty to
tolerance
input
design
texts/instruction
Improper
component
selection
The users meet 7 Dimension
difficulty to
mismatch
input
texts/instruction
Improper
component
selection
The signal
6 Lack of
output display
proper EMI
might be
shielding
interfered
The signal
6 Lack of
output display
proper EMI
might be
shielding
interfered
The
6 External
smartphone has
force
limited storage
capacity
Follow
design
SOP
175
Design 7
analysis
196
Follow
design
SOP
175
Design 7
analysis
196
Design 7
analysis
168
Design 7
analysis
168
None
54
5.4 Completion of the documentation for functions

In Section 5.4 and Section 5.5, its the case study about documentation for
FMEAs of functions and requirements based on the analyzed in Section 5.1
Section 5.3. The documentation of the complete FMEAs of functions or
requirements has no direct help in the engineering product development process.
87
Nevertheless, it will benefit the engineers to check and modify the relative
FMEAs when this product is re-designed.
5.4.1 Causes of functions failure modes analysis

Causes of functions failure modes are inspired by the effects of component failure
modes. The FC matrix (Table 15) provides a mapping between functions and
components and from which we know a function is achieved by several
components. For example, F1 is achieved by C1, C2 and C6. On this point, the
failure of C1, C2 and C6 might affect F1. Thus, we needed to check components
C1, C2 and C6 when we analyzed the possible causes responsible for the failure
modes of function F1. Based on this principle, we completed the caused analysis
in the Table 25.
Table 25 Cause analysis of function failure modes

Functions Failure modes (FM) of functions
F1
The smartphone doesnt receive
internet signal
It takes too much time to receive

internet signal
F2
The smartphone doesnt transmit

88
Causes of function FM
Wi-Fi antenna loses
efficiency
efficiency
CPU is damaged.
CPU and OS are not
compatible.
Wi-Fi antenna loses
efficiency
efficiency
Wi-Fi antenna loses
internet signal
It takes too much time to transmit

internet signal
F3
F4
F5
F6
The smartphone doesnt capture

video
The smartphone doesnt capture

sound
The smartphone doesnt process

image signal
It takes too much time to process

image signal
The smartphone doesnt process
sound signal
efficiency
efficiency
CPU is damaged.
CPU and OS are not
compatible.
Wi-Fi antenna loses
efficiency
efficiency
Camera module is damaged
Camera modules driver is
not compatible
CPU is damaged.
CPU and OS are not
compatible.
Microphones driver is not
compatible
CPU is damaged.
CPU and OS are not
compatible.
GPU is damaged.
GPU and OS are not
compatible.
CPU is damaged.
CPU and OS are not
compatible.
Improper GPU and CPU
selection.
CPU is damaged.
CPU and OS are not
compatible.
Audio Code is damaged.
Audio code is not compatible
89
F7
F8
F9
F10
The smartphone doesnt display

image signal
The image display is interfered

The smartphone doesnt display
sound signal
The sound display is interfered

The smartphone doesnt transport
sound to other device
It doesnt input texts (no reaction

after users entered texts)
After certain of time, it doesnt

input texts
F11
The input texts are different from

users action
The smartphone cannot process
texts
with drivers.
APU is damaged.
APU and OS are not
compatible.
CPU is damaged.
CPU and OS are not
compatible.
damaged.
Components emit radiation.
CPU is damaged.
CPU and OS are not
compatible.
Headphone is not compatible
with its driver.
Speaker is not compatible
with its driver.
CPU is damaged.
CPU and OS are not
compatible.
Audio jack is damaged.
CPU is damaged.
CPU and OS are not
compatible.
Keyboard is damaged.
efficiency.
efficiency.
efficiency.
CPU is damaged.
CPU and OS are not
compatible.
90
F12
F13
It takes too much time to process

Improper CPU selection.
texts
The smartphone cannot display texts CPU is damaged.
CPU and OS are not
compatible.
damaged.
The texts display is interfered
The smartphone cannot store edited CPU is damaged.
files
CPU and OS are not
compatible.
Expansion slot is damaged
Notably, we didnt consider components relations in this research and therefore

some causes may not be noticed at the first sight for engineers without experience
by considering only the functions and components relations. The possible solution
is making a component-component (CC) matrix to map the relations between
components and thus the failure modes of related components are also considered.
We recommend it to be done in the future work.
5.4.2 Determine O(fj)

Based on Section 4.3, the occurrence of function is determined by the occurrence
of components (i.e. O(fj) = Maximum of [O(ck) of all fcjk]). Accordingly, the
roccurrence of the causes of functions failure modes is reasoned and showed in
Table 26.
91
Table 26 the reasoned occurrence of causes of functions failure modes

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13
O(fj) 6 6 4 4 4 4 4 4 4 5
4
4
5
Notably, the occurrence of the causes of functions failure modes can be assigned
based on the evaluation scheme table if the engineers have experiences on it.
Otherwise, O(fj) is more accurate based on the chance of causes responsible for
components failure modes (i.e. O(ci)).
5.4.3 Completion of the FMEA document of functions

The FMEA of functions (See Table 27) is completed based on Table 13, Table 25
and Table 26. For re-design, the components may be changed and thus the causes
of function FM are just a reference. But the valuable result by take it as a
reference is that the engineers are able to assess the possible occurrence based on
it (i.e. the similar design.) The documentation helps engineers maintain the
corresponding FMEAs in re-design process. For example, when engineers select
resistant-touch screen instead of LCD display module to achieve F7 (i.e. display
signal), the causes that related to LCD display module have to be evaluated.
Besides, if engineers have made CC matrix, it will also help to do the evaluation
over the whole functions cause analysis.
92
Table 27 FMEA for functions

F
F1
Failure modes
(FM) of
functions
The smartphone The users cannot
doesnt receive connect to internet
internet signal
It takes too
much time to
receive internet
signal
F2
The users have to wait

some time to connect to
internet
The smartphone The users cannot

doesnt transmit connect to internet
internet signal
It takes too
much time to
transmit
internet signal

some time to connect to
internet
93
S Causes of
function FM
O RPN
8 Wi-Fi antenna
loses efficiency
GSM transceiver
is damaged
GSM transceiver
loses its
efficiency
CPU is
damaged.
CPU and OS are
not compatible.
5 Wi-Fi antenna
loses efficiency
GSM transceiver
loses its
efficiency
8 Wi-Fi antenna
6
loses efficiency
GSM transceiver
is damaged
GSM transceiver
loses its
efficiency
CPU is
damaged.
CPU and OS are
not compatible.
5 Wi-Fi antenna
loses efficiency
48
30
48
30
F3
F4
F5
F6
The smartphone The users cannot make

doesnt capture videoconferencing
video
The smartphone The users cannot make

doesnt capture phone calls
sound
The smartphone The users cannot take

doesnt process photos or see any
image signal
images on the screen
It takes too
much time to
process image
signal
The smartphone
doesnt process
sound signal

to see the processed
result showed on the
screen
phone calls or listen to
music
94
GSM transceiver
loses its
efficiency
8 Camera module 4
is damaged
Camera
modules driver
is not
compatible
CPU is
damaged.
CPU and OS are
not compatible.
8 Microphone is
damaged
Microphones
driver is not
compatible
CPU is
damaged.
CPU and OS are
not compatible.
8 GPU is
damaged.
32
32
GPU and OS are

not compatible.
CPU is
damaged.
CPU and OS are
not compatible.
3 Improper GPU
and CPU
selection.
8 CPU is
damaged.
32
12
32
F7
F8
F9
The smartphone The users see nothing

doesnt display on the screen
image signal
The image
display is
interfered
The smartphone
doesnt display
sound signal
The sound
display is
interfered
The smartphone
doesnt
transport sound
to other device
The users see extra

lines or dots on the
screen
phone calls or listen to
music
The users cannot use

their own device (such
as earphone) to hear the
sound
95
CPU and OS are

not compatible.
Audio Code is
damaged.
Audio code is
not compatible
with drivers.
APU is
damaged.
APU and OS are
not compatible.
8 CPU is
damaged.
CPU and OS are

not compatible.
LCD display
module is
damaged.
6 Components
emit radiation.
8 CPU is
damaged.
24
CPU and OS are

not compatible.
Headphone is
not compatible
with its driver.
Speaker is not
compatible with
its driver.
6 Components
emit radiation.
8 CPU is
damaged.
32
32
24
32
F10 It doesnt input

texts (no
reaction after
users enter
texts)
After certain of
time, it doesnt
input texts
Some texts
cannot be input
F11
The users cannot enter

texts
CPU and OS are

not compatible.
Keyboard is
damaged.
The users might meet
5 Keyboard
difficulties to enter texts
module loses its
after certain of time
efficiency.
7 Keyboard
all the texts desired
module loses its
efficiency.
7 Keyboard
texts correctly
module loses its
efficiency.
The input texts

are different
from users
action
cannot process on the screen
texts
It takes too
much time to
process texts
F12
CPU and OS are

not compatible.
Audio jack is
damaged.
7 CPU is
damaged.

to see the processed
result showed on the
screen
cannot display
on the screen
texts
7 CPU is
damaged.
CPU and OS are

not compatible.
LCD display
module is
damaged.
96
25
35
35
CPU and OS are

not compatible.
3 Improper CPU
selection.
7 CPU is
damaged.
35
28
12
28
F13
The texts
display is
interfered
The smartphone
cannot store
edited files
The users see extra

lines or dots on the
screen
The users might lose
files
6 Components
emit radiation.
6 CPU is
damaged.
24
30
CPU and OS are

not compatible.
Expansion slot is
damaged
5.5 Completion of the documentation for requirements

Similarity to the FMEA of functions, the FMEA of requirements is completed for
the documentation purpose.
5.5.1 Analyze the causes of requirements based on Section 4.2

Causes analysis of requirements failure modes can be inspired by the effects of
functions failure modes (See Figure 5). We know the mapping between
requirements and functions in the RF matrix (Table 7) and accordingly we check
the possible causes for requirements failure modes from the effects of functions
failure modes. For example, R1 is satisfied by f1 and f2. On this point, the failure
of f1 and f2 might affect the complement of r1. Based on this principle, we
completed the cause analysis in the Table 28.
97
Table 28 cause analysis of requirements failure modes

Failure modes (FM) of requirements
Causes of requirements FM
The smartphone cannot support internet
- Doesnt receive internet signal
connection
- Doesnt transmit internet signal
The users experience frequent
The function is not executed
interruptions with internet connection
perfectly (meet the standard)
It takes long time to connect to the internet - Take much time to receive
internet signal
- Take much time to transmit
internet signal
The smartphone cannot support video- Doesnt receive internet signal
conference
- Doesnt transmit internet signal
- Doesnt capture video
- Doesnt capture sound
- Doesnt process image signal
- Doesnt process sound signal
- Doesnt display image signal
- Doesnt display sound signal
- Doesnt transport sound
The smartphone only supports part of the
- Might not receive internet signal
functions required in video-conference
- Might not transmit internet signal
- Might not capture video
- Might not capture sound
- Might not process image signal
- Might not process sound signal
- Might not display image signal
- Might not display sound signal
- Might not transport sound
The users experience interruptions of
image or voice transfer during videoperfectly (meet the standard)
conferencing
The smartphone cannot play music
- Doesnt process sound signal
- Doesnt display sound signal
- Doesnt transport sound
The smartphone can only play specific
music formats
The users cannot take notes by the
smartphone

perfectly (meet the standard)
- Doesnt input texts
- Doesnt process texts
98
The users cannot take all the notes desired, some texts is unable to edit
The users meet difficulty to take notes
correctly (i.e. The users see incorrect notes
different from the ones edited)
The users cannot send messages
The users meet difficulty to send complete messages, some texts is unable to edit
The users meet difficulty to send correct
messages (some texts is different from
edited)
Doesnt display texts

Doesnt store files
Input texts are incorrect
Doesnt receive internet signal

Doesnt transmit internet signal
Doesnt input texts
Doesnt process texts
Doesnt display texts
5.5.2 Determine O(ri)

The occurrence of causes of requirements failure modes is reasoned from the
occurrence of causes of functions failure modes based on Section 4.3 (i.e. O(ri) =
Maximum of [O(fj) of all rfij]). The reasoned occurrence is showed in Table 29.
Table 29 The reasoned occurrence of causes of requirements failure modes

R1 R2 R3 R4 R5
O(rj) 6 6 4 5 6
99
5.5.3 Completion of the FMEA document of requirements

In Table 30, a complete FMEA for requirement is showed based on above
analysis. In this document, engineers are able to prioritize the risk based on the
RPN.
Table 30 FMEA for requirements

R
R1
Failure modes (FM) of

requirements
support internet
connection
Effects of
requirement FM
The users will
change
smartphone
The users experience

frequent interruptions
with internet
connection
It takes long time to
connect to the internet
The users might

complain it and
try to fix the
problem
The users might
accept it or
tolerate it
R2 The smartphone cannot

support videoconference
The users will

change
smartphone
100
S Causes of
O RPN
requirements FM
8 - Doesnt
6 48
receive
internet signal
- Doesnt
transmit
internet signal
6 The function is
36
not executed
perfectly (meet
the standard)
4 - Take much
24
time to
receive
internet signal
- Take much
time to
transmit
internet signal
8 - Doesnt
6 48
receive
internet signal
- Doesnt
transmit
The smartphone only

supports part of the
functions required in
video-conference
The users will

complain it and
try to fix the
problem
6 -
101
internet signal
Doesnt
capture video
Doesnt
capture sound
Doesnt
process image
signal
Doesnt
process sound
signal
Doesnt
display image
signal
Doesnt
display sound
signal
Doesnt
transport
sound
Might not
receive
internet signal
Might not
transmit
internet signal
Might not
capture video
Might not
capture sound
Might not
process image
signal
Might not
process sound
signal
Might not
display image
signal
Might not
36
R3
The users experience

interruptions of image
or voice transfer during
video-conferencing
play music
The users might

complain it
The smartphone can

only play specific
music formats
The users might

not care about it
and adapt it
R4 The users cannot take

notes by the
smartphone
The users might

accept or
tolerate it
The users might

complain it
The users cannot take

all the notes desired,
some texts is unable to
edit
The users might

complain it and
try to fix the
problem.
The users meet

difficulty to take notes
correctly (i.e. The users
see incorrect notes
The users might

complain it and
try to fix the
problem.
102
display sound
signal
- Might not
transport
sound
6 The function is
not executed
perfectly (meet
the standard)
3 - Doesnt
process sound
signal
- Doesnt
display sound
signal
- Doesnt
transport
sound
36
12
The function is
not executed
perfectly (meet
the standard)
4 - Doesnt input 5
texts
- Doesnt
process texts
- Doesnt
display texts
- Doesnt store
files
5 - Some texts
cannot be
input
- Input texts are
incorrect
5 - Input texts are
incorrect
12
20
25
25
R5
different from the ones

edited)
The users cannot send
messages
The users might

change
smartphone.
7 -
The users meet

difficulty to send
complete messages,
some texts is unable to
edit
The users meet
difficulty to send
correct messages (some
texts is different from
edited)
The users will

complain and
try to fix the
problem
6 -
The users will

complain and
try to fix the
problem
6 -
103
Doesnt
6 42
receive
internet signal
Doesnt
transmit
internet signal
Doesnt input
texts
Doesnt
process texts
Doesnt
display texts
Some texts
36
cannot be
input
Input texts are
incorrect
Input texts are
36
incorrect
Chapter 6: Discussion
As showed in the case study (e.g., Chapter 5), the integration model of FMEA
applied along with the engineering design process is implemented using a stepby-step FMEA-facilitated design process methodology that is proposed in Chapter
4. Notable observations from the case study are listed as bellows.
Observation #1: The information of failure analysis can be utilized at the later
stages and ensure the analysis consistent among design teams. (See Section
5.2.4 and Section 5.3.4)
The practice of reasoning the severity of failure modes in the requirement

domain is used as a supporting method for double-checking the severity value
assigned to the failure modes in the function domain. The practice promotes
the consistency of the failure information even when the failure analyses are
done by different teams. Similar logical scenario is also applied from function
domain to component domain.
Observation #2: The practice of prioritizing the risk consequence of

requirements and functions helps engineers to select proper components and
make better design based on the consideration of corresponding risk
consequences. (See Section 5.3.8)
104
The risk consequences lists gathered from each domain (e.g. requirement
domain, function domain and component domain) are used as supporting
documents throughout the FMEA. In the end of component selection of before
the selection, the engineers are suggested to review the design and risk
consequences to ensure the critical situations are considered and avoided. The
critical situations indicates the ones impact users the most and which is
analyzed in requirement domain.
Observation #3: The completion of FMEA in the components domain

promotes the completion of function-FMEA and requirement-FMEA. (See
Section 5.4 and Section 5.5) The documentation purpose activities help
engineers to maintain the corresponding FMEAs when the product is redesigned or revised in the future.
Even though the integration model enables engineers to implement FMEA along
with the engineering design process, we also notice some limitations in the case
study. The limitations are the result of lack of inputs of product information and
which is pointed out in Section 5.3.7 and Section 5.4.1. The limitations are
discussed respectively as following.
Limitation #1: The control plan is decided based on the developers internal
regulation and also on the project budget. Therefore, we have limited
information to put inside the case study. (See Section 5.3.7)
105
This limitation will not exist in the real situation when the FMEA is
implemented in a real project development process in industry.
Limitation #2: The cause of a function failure mode can be inspired by the
effect of the corresponding components failure modes. Yet, we didnt consider
the components relationship in the case study and thus some causes of
function failure modes are not directly observed from the failure analysis of
components. (See Section 5.4.1)
The possible solution to this limitation is that engineers make a mapping

between components to know the components relationships, and therefore the
possible causes from the related components can also be observed and taken
into account.
106
Chapter 7: Conclusion
For decades, FMEA is used in industry and different approaches are proposed and
improved by researchers. The practice of FMEA allows engineers to examine the
design and control or eliminate the possible causes of failures. In this thesis, an
integration framework is developed to integrate FMEA and engineering design
process and the goal is to utilize the failure analysis information from one stage to
another stage of the design process. To reach this goal, it is necessary to integrate
different FMEA documents that are implemented throughout the product
development process. In this thesis, the engineering design process is defined by
specifying three key design elements: requirements, functions, and components. It
is by the reference of QFD and AD methodologies. These design elements are
treated as a foundation of the proposed integration model.
This thesis aims to apply FMEA along with the design process, and thus a stepby-step FMEA-facilitated design procedure is proposed. The procedure then is
demonstrated and verified by a case study. From the case study, we have three
observations and also notice two limitations about the integration model.
The first observation is the information of failure analysis can be utilized at the
later stages and it ensures the failure analysis is consistent. The second
observation is that the practice or prioritizing the risk consequence of
requirements and functions helps engineers to select components and design the
product according to the consideration of the risk consequence that the engineers
107
listed in the earlier analysis process. The third observation is the completion of
FMEA in the components domain promotes the documentation of the FMEA of
functions and FMEA of requirements. Nevertheless, there are two limitations of
applying the integration model in the real design practice. The detection assessing
value is required in FMEA practice most of time. Yet, this research is unable to
capture the real control method due to the lack of information. Instead, we made
an assumption on the control and detection part in the FMEA of component
domain in Section 5.3.7. Secondly, due to the limitation of time, component
relations are not mapped in this thesis. As a result, some causes of function failure
modes are unable to be observed by only reviewing the failure analysis of
components and the mapping between functions and components. These two
limitations are left to be addressed in the future research.
Notably, the contributions of this thesis are pointed out as below.

First, the integration of different types of FMEA documents in the product
development process, which has not been found in the literature.
Second, a step-by-step FMEA-facilitated design process is proposed, and it
ensures the consistent of failure analysis among product design process.
Third, a real-life product is studied.
108
References
Anleitner, M.A., 2010, The Power of Deduction: Failure Modes and Effects
Analysis for Design, ASQ Quality Press, Milwaukee.
ASQ, 2013, Six Sigma Black Belt: Body of Knowledge, retrieved from
http://prdweb.asq.org/certification/resource/docs/sixsigma_bok_2007.pdf
ASQ Quality Press, 2004, pp.152-155, Quality Function Development (QFD),

retrieved
from
http://asq.org/learn-about-quality/qfd-quality-function-
deployment/overview/overview.html.
Bertsche, B., 2008, Reliability in Automotive and Mechanical Engineering,

Springer, Berlin.
Bradley, N., 2010, Marketing research: tools & techniques, 2nd edition, New
York, Oxford University Press.
Bradley, J.R. and Guerrero, H.H., 2011, An Alternative FMEA Method for
Simple and Accurate Ranking of Failure Modes, Decision Sciences, Vol. 42, pp.
743-771.
109
Carlson, C.S., 2012, Effective FMEAs: Achieving Safe, Reliable, and Economical
Products and Processes using Failure Mode and Effectives Analysis, Wiley, New
Jersey.
Chang, K.H. and Cheng, C.H., 2011, Evaluating the Risk of Failure using the
Fuzzy OWA and DEMATEL method, Journal of Intelligent Manufacturing, Vol.
22, pp. 113-129.
Chang, K.H., Chang, Y.C. and Lai, P.T., 2013, Applying the Concept of
Exponential Approach to Enhance the Assessment Capability of FMEA, Journal
of Intelligent Manufacturing, Published Online, DOI 10.1007/s10845-013-0747-9.
Chao, L.P. and Ishii, K., 2007, Design Process Error Proofing: Failure Modes
and Effects Analysis of the Design Process, ASME Journal of Mechanical
Design, Vol. 129, pp. 491-501.
Chin, K.S., Chan, A., and Yang, J.B., 2008, Development of a fuzzy FMEA
based product design system, International Journal of Advanced Manufacturing
Technology, Vol. 36, pp. 633-649.
Creveling, C.M., Slutsky, J.L. and Antis, D., 2003, Design for Six Sigma, Pearson,
New Jersey.
110
De Rosier, J., Stalhandske, E., Bagian, J.P. and Nudell, T., 2002, Using health
care Failure Mode and Effect Analysis: the VA National Center for Patient
Safety's prospective risk analysis system, Joint Commission Journal on Quality
and Patient Safety, Vol. 28, No. 5, pp. 248-267.
Dieter, G.E. and Schmidt, L.C., 2009, Engineering Design, Fourth Edition,
McGraw-Hill, Boston.
Duckworth, H.A. and Moore, R.A., 2010, Social Responsibility: Failure Mode
Effects and Analysis, CRC Press, New York.
Evans, J.R., and Lindsay, W.M. 2005, An Introduction to Six Sigma & Process
Improvement, Mason, Ohio, Thomson/South-Western.
Hauser, J.R. and Clausing, D., 1988, The House of Quality, Harvard Business
Review, Vol. 66, No. 3, pp. 63-74.
Hunt, J. E., Pugh, D. R. and Price, C. P., 1995, Failure Mode Effects Analysis: A
Practical Application of Functional Modeling, Applied Artificial Intelligence,
9 (1), pp. 33-44.
ISO MIL-STD-105E
111
Kmenta, S. and Ishii, K., 2004, Scenario-based Failure Modes and Effects
Analysis using Expected Cost, ASME Journal of Mechanical Design, Vol. 126,
pp. 1027-1035.
Kossiakoff, A. and Sweet, W.N, 2011, Systems Engineering Principles and

Practice, Wiley.
Kurtoglu, T., Tumer, I.Y. and Jensen, D.C., 2010, A functional failure reasoning
methodology for evaluation of conceptual system architectures, Research in
Engineering Design, Vol.21, pp.209-234.
Military, 1980, MIL-STD-1629A: Procedures for Performing a Failure Mode,

Effects and Criticality Analysis, Department of Defense, United States.
NASA, 1966, Procedure for Failure Mode, Effects and Criticality Analysis
(FMECA), Apollo Reliability and Quality Assurance Office.
Noh, K.W., Jun, H.B., Lee, J.H., Lee, G.B. and Suh H.W., 2011, Module-based
Failure Propagation (MFP) model for FMEA, International Journal of Advanced
Manufacturing Technology, Vol 55, pp. 581-600.
OConnor P., and Kleyner, A., 2012, Practical Reliability Engineering, 5th
edition, Wiley.
112
Pahl, G., Beitz, W., Feldhusen, J. and Grote, K.H., 2007, Engineering Design: A
Systematic Approach, Third Edition, Springer, London.
Pillay, A. and Wang, J., 2003, Modified Failure Modes and Effects Analysis
using Approximate Reasoning, Reliability Engineering and System Safety, Vol.
79, pp. 69-85.
Reifer, D.J., 1979, Software Failure Modes and Effects Analysis, IEEE
Transactions on Reliability, Vol. 28, No. 3, pp. 247-249.
SAE, 2001, SAE ARP5580: Recommended Failure Mode and Effects Analysis
(FMEA) Practices for Non - Automotive Applications
Stapenhurst, T., 2009, The Benchmarking Book: a how-to-guide to best practice

for managers and practitioners, 1st edition, Elsevier Butterworth-Heinemann
Stone, R.B., Tumer, I.Y. and Stock, M.E., 2005, Linking Product Functionality
to Historic Failures to Improve Failure Analysis in Design, Research in
Engineering Design, Vol. 16, pp. 96-108.
Stone, R.B. Wood, K.L., 2000, Development of a Functional Basis for Design,
Journal of Mechanical Design, Vol. 122, pp. 359-370.
113
Suh, N.P., 1990, The Principles of Design, Oxford University Press, New York.
Suh, N.P., 2001, Axiomatic design: advances and applications, New York, Oxfor
University Press.
Teng, S.H. and Ho, S.Y., 1996, Failure Mode and Effects Analysis: An
Integrated Approach for Product Design and Process Control, International
Journal of Quality and Reliability Management, Vol. 13, No. 5, pp. 8-26.
Teoh, P.C. and Case K., 2004, Failure modes and effects analysis through
knowledge modeling, Journal of Materials Processing Technology, Vol. 153154, pp.253-260.
Ulrich, K.T. and Eppinger, S.D., 2012, Product Design and Development, Fifth
Edition, McGraw-Hill, New York.
114
Appendices
Appendix 1 List of components
Decomposed product: BlackBerry Smartphone Bold 9650
Back assembly
Front assembly
Systems
Front
assembly
Subsystems
Frames
Components
Photos
Headphone cover
Front main frame
Protector pad
Liner profile & frame
Down outer profile

Input subsystem
Interior assembly
Keypad
Top key dome-switch pad
Top key liner
115
Interior
assembly
Signal
exchange
subsystem
Antenna #1
Display
module
LCD screen mounted with

Connector and circuit board
Main
board
Micro USB port

SIM card connector
Connectors
Battery
Blue-tooth transceiver
Audio Codec
GPS receiver
GSM transceiver
Vibrator
Micro SD slot
Power AMP/multiplexer array
CPU
GPU
APU
Input subsystem
Dome-switch pad
Scroll Key
module
Scroll key mounted on

Circuit board
(with a connector)
Scroll key holder
116
Sound and
VGA
Camera module, Audio jack,

Connectors, R/C components
are mounted on circuit board
Headphone speaker
Back
assembly
Power
supply
subsystem
Wires and wire holders
Protection
EMI gaskets
(conductive sponges)
Frames
Battery cover
Trigger
Back frame
Bottom fixture
Liners
117
Conductive layer between

Main board and battery
Input subsystem
Side buttons
Flash
module
R/C components
mounted on circuit board
LED
Signal
exchange
subsystem
Antenna #2
Sounddisplay
subsystem
Speaker
Antenna #3
118
Appendix 2 Functional analysis
Top level block diagram:
Manage energy
supply
Energy
Energy
Process signals
3
Connect to
networks
Hardware
Display signals
5
Store signals
Signals
6
Software
Interaction between the user

and the device
119
Signals
Function 1: Manage energy supply
1.1
1.2
Convert energy to
appropriate voltage
Energy
1.3
Supply
components with
energy
Store energy
Function 2: Processing
2.1
Receive input from

user
Signal
2.2
2.4
Software
communicates with
Hardware
Software
Handle result
2.3
Hardware
2.5
Perform requested
task
Display result
Function 2.1: Receive input from user

2.1.1
Receive input from

peripheral
2.1.2
Store
input
120
Signals
Function 2.2: Software communicates with Hardware
2.2.1
2.2.2
Application
acknowledges the
input, relays it to OS
OS Contacts
processor
2.2.3
Store signals
Function 2.3: Perform requested task
2.3.1
2.3.2
Store partial
results /
instructions
Processor
executes
instructions
Function 2.4: Handle result
2.4.1
Receive result
from processor
(OS)
2.4.3
2.4.2
Give format to
result
(Application)
121
Forward
formatted result
to display (OS)
Function 2.5: Display result
2.5.1
2.5.1
Display
signals
Store signals
Function 3: Connect to network:
3.1
Request connection
to hardware
Software
3.2
Hardware
Establish connection
Function 3.2: Establish connection
Send connection
info to requester
3.2.2
3.2.3
3.2.4
3.2.1
Hardware
Receive and
follow
connection
instructions
Send connection
request to service
provider
Software
Check connectivity
hardware status
122
Connect to the
network
Function 4: Display signal
4.1
Send data to display
Software
4.2
Display data via the

channel requested
Hardware
Data out
Function 4.1: Send signal to display
4.1.1
Software
4.1.2
Software requests to
display data
OS Contacts
processor
4.1.4
4.1.3
Store / Read
signals
Hardware
123
Processor tells
hardware to
display
Function 5: Store signal
5.1
Request to
store/delete signals
Software
5.2
Perform action
requested
Hardware
Function 5.1: Request to store/delete signal
5.1.1
Software
5.1.2
Software requests to
store/delete signal
OS Contacts
processor
5.1.4
5.1.3
Store / Read
signals
Hardware
124
Processor orders
hardware to
perform task
requested

Good Saample

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Good Saample

Caricato da

Copyright:

Formati disponibili

Integration of Failure Modes and Effects Analysis

(FMEA) in the Engineering Design Process

A Thesis in the Department of

Presented in partial fulfillment of the requirements for the degree of

Integration of Failure Modes and Effects Analysis (FMEA) in

and submitted in partial fulfillment of the requirements for the degree of

Signed by the final examining committee:

Dr. Anjali Awasthi

August 21, 2013

Integration of Failure Modes and Effects Analysis (FMEA) in the

The objective of this thesis is to develop an integration approach of FMEA in the

proposed methodology. The expectedly benefits of the proposed methodology are

Keywords: Engineering design process, Failure modes and effects analysis

5.2.1 Deployment of functions...................................................................... 53

1.1. Background and Motivation

In contrast to FMEA, academic researchers have devoted significant efforts in the

1.2. Research Approach and Objectives

The goal of this research is to develop an integration approach of FMEA in the

Objective #3: Conduct a detailed case study of a smartphone model to

1.3. Thesis Organization

Chapter 2: Literature Review

After accumulating the experience of using FMEA in industrial practice, some

requirements to design and manufacturing). Secondly, early FMEA procedures

2.2. FMEA in Academic Research

One specific issue of FMEA research is to tackle the accuracy and

(i.e., by multiplication) of three numerical rankings: occurrence of risks, severity

2.3. Research Gaps related to this Thesis

kind of design flow is similar to the methodology of Quality Function

Chapter 3: Integration Framework

3.1. Basic Elements in Engineering Design

The environmental requirements

After explaining the meaning of requirements, functions and components, this

Requirements: R = {r1, r2, , rm}, where m is the total number of

3.2. Basic Elements of FMEA

The casual analysis in the study of engineering failures is always a challenging

For example, when engineers make failure analysis of a phenomenon a user

In contrast, the cause-failure mode-effect chain is clearer in FMEA. In the similar

A user cannot take

Operate the camera

Click the wrong

The lens is covered

Figure 1 Fault tree analysis (FTA) diagram example

Failure modes: FM = {fm1, fm2, , fmq}, where q is the total number of

In FMEA, the definition of failure modes is the key to investigate the

3.3. Definition of Failure Modes from Design Elements

When product requirements are considered as customer needs, the corresponding

3.4. Integration Model

Figure 2 Integration model

3.5. Smartphone Demonstration

Failure modes of R1:

Figure 4 Schematic diagram of function domain analysis

R1 F1: Receive internet signal, F2: Transmit internet signal

Figure 5 Schematic diagram of the relation between requirements and functions

Figure 6 Schematic diagram of components domain analysis

Failure modes and corresponding effects of C2:

Figure 7 Schematic diagram of the relation between functions and components in

Chapter 4: FMEA-Facilitated Design Process

4.1. Three-Phase Design Process

4.1.1. Identification of requirements

Furthermore, the information of existing products can help the identification of

The expected output of phase 1 is a list of requirements that characterize the

Figure 8 Requirement matrix

4.1.2. Deployment of product functions

To deploy the functions based on requirements, we can use some question-asking