See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/239406158

Modelling and reasoning for failure modes and effects analysis generation

Article in Proceedings of the Institution of Mechanical Engineers Part B Journal of Engineering Manufacture · March 2004
DOI: 10.1243/095440504322984849

CITATIONS READS

32 1,155

2 authors:

Ping Chow Teoh Keith Case

Wawasan Open University Loughborough University
19 PUBLICATIONS 276 CITATIONS 215 PUBLICATIONS 3,284 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Keith Case on 26 February 2014.

The user has requested enhancement of the downloaded file.

 289

Modelling and reasoning for failure modes and e€ects

analysis generation

P C Teoh and K Case*

Mechanical and Manufacturing Engineering, Loughborough University, Loughborough, Leicestershire, UK

Abstract: Failure modes and e€ects analysis (FMEA) is a quality improvement and risk assessment
tool commonly used in industry. It is a living document used to capture design and process failure
information. However, the traditional FMEA has its limitations in terms of knowledge capture and
reuse. In order to increase its e€ectiveness, much research has been carried out to ®nd an e€ective
way to provide FMEA generation. However, because of the complexity of the information needed,
most of the research concentrates on the application for a speci®c design domain. This paper
reviews various FMEA research studies and modelling and reasoning methods that can be used for
generic applications. A new proposal made is based on the `knowledge fragment’ reasoning concept
suggested by Kato, Shirakawa and Hori in 2002. FMEA is introduced in the conceptual design
stage so as to minimize the risks of costly failure. The method enables new knowledge to be formed
using the limited available information in the conceptual design stage. A prototype has been created
to evaluate the proposed method. Case studies have been conducted to validate the proposed
method. The case studies show that the method is able to provide reliable results with limited
information.

Keywords: failure modes and e€ects analysis (FMEA), conceptual design, modelling, causal reason-
ing, functional model

1 INTRODUCTION known as FMECA. Hence FMECA is an extension of

FMEA. In this research, FMEA and FMECA are treated
Concurrent engineering is an initiative to improve the as the same method. The method will include critical
competitiveness of manufacturing industry. The general analysis and be known only as FMEA.
aims are to improve quality, to reduce cost and to Basically, FMEA can be classi®ed into two main
reduce cycle times of the products. Many tools have types, i.e. design FMEA and process FMEA. Design
emerged in line with this initiative. One, which has FMEA deals with product design, while process
been adopted by the International Standard Organiza- FMEA is used to solve problems due to manufacturing
tion, is failure modes and e€ects analysis (FMEA) [1]. processes. The potential failure modes and potential
FMEA is a tool used to identify the potential failure causes for each component or process step are identi®ed.
modes of a product or a manufacturing process, and the This is followed by assessment of the failure e€ects to the
e€ects of the failures, and to assess the criticality of these end users. The risk of each failure is prioritized on the
e€ects on the product functionality. It provides basic basis of the risk priority number (RPN). RPN is a
information for risk assessment and quality improvement decision factor based on the product of three ratings:
of product and process design. According to BS 5760: Part occurrence, severity and detection. These ratings are
5 [2], `FMEA is a method of reliability analysis intended to scaled with numbers between 1 and 10. Failure modes
identify failures, which have consequences a€ecting the with high RPN values are selected. The corresponding
functioning of a system within the limits of a given appli- current controls (i.e. the solutions) will be implemented
cation, thus enabling priorities for action to be set.’ When on the basis of the selected failures.
the criticalities of the failures are assessed, the method is

The MS was received on 5 June 2003 and was accepted after revision for 2 MOTIVATION
publication on 28 November 2003.
*Corresponding author: Mechanical and Manufacturing Engineering,
Loughborough University, Loughborough, Leicestershire LE11 3TU, Traditionally, potential problems of a design or process
UK. are captured with FMEA manually using hard copy or
B09803 # IMechE 2004 Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture
290 P C TEOH AND K CASE

spreadsheet. However, as the accumulated FMEA structure), as well as the design intent (the function) of
knowledge grows, the information becomes increasingly the product. A reasoning technique de®nes the causal
dicult to ®nd. Hence, it is increasingly harder to reuse. relationships between the information of the structures
It is very dicult to implement a highly manual and functions in the model.
FMEA (i.e. a report that is keyed in manually on to
paper or into a spread sheet). The manual method is
found to be not user friendly, hard to understand and 3.1 Modelling in FMEA research
of limited ¯exibility. As a result, many companies use
The models used in FMEA research can be divided into
FMEA merely to satisfy the contractual requirements
two types, i.e. functional models and structural models.
of their customers [3]. Users may ®nd FMEA a `tedious
Both types of model are needed to automate the
and time-consuming activity’ [4]. FMEA is often carried
FMEA process [14].
late in the design cycle after the design prototype has
A functional model describes the intended function or
been built [4], and the changes made at later stages will
the purpose of a system. The functional model is made
be very costly. Hence, there is considerable research
up of two main components: function and behaviour.
that attempts to improve FMEA usage in the earlier
The function of a system provides the design intent,
stages of the design process, such as the conceptual
whereas the behaviour describes how the structure of
design stage.
an artefact achieves its function [15]. A function can be
Much research has been carried out mainly to provide
decomposed into subfunctions to understand better the
automatic FMEA report generation. The research
design through functional analysis. This will be further
reviewed in this paper includes FLAME [4] and Auto-
discussed in a subsequent section.
SteveTM [5] for the design of automobile electrical
A structural model is de®ned as `the components that
systems, GENMech [6] for mechanical design and
make up an artifact and their relationships’ [15]. It refers
research by Atkinson et al. [7] and Hogan et al. [8] for
to the con®guration of the product or system. It contains
hydraulic systems design. Bouti et al. [9] and Price et al.
the information of all the components, entities, sub-
[10] suggested methods for process FMEA application.
processes or subsystems, and the interactions between
Eubanks et al. [11, 12] proposed a more generic approach
them that make up a useful structure for an intended
for both design and process FMEA. However, most of
purpose. A structural model may refer to a physical
the methods require a considerable amount of modelling
assembly of a mechanical or electrical product (such as
e€ort to be used e€ectively. Hence, despite all the e€orts,
a car, an engine or an electrical circuit), or a software
most of the mechanical, electromechanical and manufac-
con®guration.
turing process designs still use the conventional method
In design, each artefact is created to achieve one or
to create an FMEA.
more functions. At the same time, one or more artefacts
In order to improve FMEA usage in the early design
can achieve a function. The relationships between func-
stages, arti®cial intelligence (AI) techniques such as
tions and artefacts are represented by the mapping
modelling and reasoning are used. This paper speci®cally
between a functional and a structural model (Fig. 1), as
looks at a modelling and reasoning approach that pro-
de®ned by Eubanks et al. [12].
vides the basis for FMEA automation for more generic
product and process design applications.
3.2 Modelling in conceptual design
3 MODELLING AND REASONING There is much literature that suggests a systematic design
approach for the design process [16±18]. In general, the
Modelling and reasoning are two important and widely design process can be divided into four phases:
used concepts in FMEA research. A model is an
1. Design speci®cation. Establish the requirement speci-
abstracted picture of a concept. A model may represent
®cations.
a system, an object or a problem constructed for the
2. Conceptual design. Find the possible design concepts
purpose of analysis [13]. It is an approximation of
based on the requirements.
the real thing. Modelling is a process of transferring the
3. Embodiment design. Design the layout, schematic,
concept into a type of representation that people can
draft or con®guration drawing of the design.
comprehend, communicate and work upon.
4. Detail design. Establish the detail dimensions using
Reasoning is a decision-making process based on the
proper engineering drawings.
understanding of the available information. In AI
terms, reasoning represents the capability of the com- Conceptual design is a phase where ideas are gener-
puter to make decisions based on the given information. ated, evaluated and selected. The outputs of this phase
These two concepts are dependent on each other in are the design concepts that will be the basis for the
executing a task. In FMEA, a model can be used to embodiment and detail design. Brie¯y, the steps include
represent a product or the component of a product (the formulating the problem, establishing a functional
Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture B09803 # IMechE 2004
 MODELLING AND REASONING FOR FAILURE MODES AND EFFECTS ANALYSIS GENERATION 291

Fig. 1 Function±structure mapping [12]

model, searching for working principles or function

carriers, combining suitable working principles into
one or more concept variants and evaluating the con-
cepts. One or more selected concepts will go through
embodiment design, where the layout and forms of the
design will take shape. Further evaluations may take
place in that phase.
The functional model consists of the decomposed
functions of the design used to simplify the design prob-
lem in order to search for suitable working principles.
Hence, function decomposition provides the ®rst step
for FMEA involvement in the design process. The overall
process involved in function decomposition and searching Fig. 2 Functional model with energy, material and informa-
for working principles is known as functional analysis. tion ¯ows

4 FUNCTIONAL ANALYSIS motor `generates torque’, and torque `rotates pulley’. In

contrast, using an implicit concept, motor `moves pulley’
There are many ways to achieve function decomposition, implies the actions `generate torque’ and `rotate pulley’.
including the ¯ow-based approach, the integrated de®ni- The ¯exibility in modelling implicit concepts will release
tion (IDEF) method and a functional diagram approach. the designer from some burdens so that they can concen-
trate on design solutions. Ulrich and Eppinger [18] also
pointed out that, in some applications, the energy,
4.1 Flow-based black-box approach material and information ¯ows are dicult to identify.
Hence, a ¯ow-based approach imposes a restriction
Pahl and Beitz [17] and Ulrich and Eppinger [18] sug-
that hinders the formation of implicit relationships in a
gested a ¯ow-based `black-box’ design approach. The model.
black box represents the function of a design or process.
Normally, a function is represented by a verb±noun pair
[e.g. `moves printed-circuit board (PCB)’]. The role of the 4.2 IDEF methods
function is to convert an input into an output of a di€er-
ent state. The inputs and outputs of the black box (the Kusiak [13] showed that a process model could be repre-
operands) can be represented by three basic elements, sented by IDEF methods. IDEF methods are standard
i.e. energy, material and information (or signal) ¯ows. methodologies that are widely used in concurrent engin-
The main function in the functional model can be eering. IDEF represents a family of modelling methods
decomposed into many subfunctions, forming one or including IDEF0 for function models, IDEF3 for
more alternative functional structures (Fig. 2). process models, etc.
The main issue in using a ¯ow-based approach in con- The IDEF0 diagram introduced by the National
ceptual design is that the operand needs to be in the basic Institute of Standards and Technology [19] is shown in
form of the three types of ¯ow. For example, if a motor Fig. 3. The function name is a de®ned verb or verb
carries out the function `move pulley’ this can only be phrase. The input and output arrows represent the
represented by further decomposition into the following: operand of the system. A control from the top represents
B09803 # IMechE 2004 Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture
292 P C TEOH AND K CASE

the state of the operand. In fact there is no sequence or

direction involved that can be used to construct an
IDEF diagram.

4.3 Functional diagram

The functional diagram provides one of the simplest

models to represent function and structure interaction.
The basic unit (function unit) of the diagram consists
Fig. 3 IDEF0 function box of two objects linked by a function. The ®rst object is
the component in the structure model that acts as the
the elements that in¯uence the function performance. A operator to the function. The function is a verb or verb
mechanism is a means that enables the function to be phrase that de®nes the action. The second object is the
performed. A call arrow represents the communication operand of the model. An operator in one function
from one function box to another. A function box can unit can be an operand of the other function unit and
be decomposed into more detailed subfunctions, similar vice versa. Hence, the objects and functions are inter-
to the ¯ow-based `black-box’ approach. connected to form a network known as the functional
According to Dorador [20], IDEF0 lacks the capability diagram (Fig. 5).
to represent processes involving time and sequence (prece- The attractive aspects of applying functional models in
dence relationships). Hence, the IDEF3 diagram is conceptual design are their simplicity and user-friendli-
introduced to provide process modelling capability. The ness. This is very important for conceptual design since
IDEF3 diagram is provided with logical connectors to frequent design changes are essential in this phase.
represent timing and sequences, as shown in Fig. 4. However, because of its simplicity, the method lacks
According to Mayer et al. [21], the IDEF0 diagram other features in modelling. It cannot handle timing
can be used at the initial stage of complex model building and sequences as in IDEF3. The diagram can be too com-
where precedence relationships are not clear. Decompo- plicated when it is used to represent a complex design.
sition of the initial model will lead to a level where the There is no standard terminology for de®ning the objects
IDEF3 diagram is used to represent process models. and the function, and hence it is not ecient in reuse.
Kusiak [13] maintained the control and mechanism The modelling techniques reviewed above have their
arrows from IDEF0 in IDEF3 diagrams. This is very own advantages and weaknesses for conceptual design
helpful in representing the structure information in applications. In this research, a combination of model-
terms of `mechanism’ and `control’ of the function. ling techniques can be used. The functional diagram is
The downside of using IDEF methods is that the used for conceptual modelling, as it is the simplest. Its
method is not suitable for static model functions, i.e. a weaknesses can be complemented by other modelling
function that is achieved due to the structure of the techniques. The IDEF method is the common method
operand and not due to the state-change behaviour used in the industry. Hence, it provides a launch pad
[22]. For example, a function `support’ will only maintain for conceptual design. For example, IDEF3 diagrams

Fig. 4 IDEF3 diagram with logical connectors

Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture B09803 # IMechE 2004
 MODELLING AND REASONING FOR FAILURE MODES AND EFFECTS ANALYSIS GENERATION 293

Fig. 5 Functional diagram

can be used to build the initial model before trans- [7] and Hogan et al. [8]. In actual fact, there are rules
forming to the functional diagram. The method will be residing in many of the model-based systems. A model-
discussed in the following section. based approach can provide an accurate simulation of
the failure conditions. However, a rather comprehensive
structural model needs to be created before the reasoning
5 REASONING IN FMEA process can be carried out. A component library for the
prede®ned models needs to be created to eliminate
Reasoning in a design process is to search for possible modelling activities during FMEA generation. These
function and structure mapping. In FMEA, reasoning projects focus on speci®c areas such as electrical circuits
is carried out to establish cause-and-e€ect relationships for cars [5], or hydraulic components [7, 8]. Owing to
based on the functional and structural models, and to the complexity of the manufacturing process, to use this
generate the FMEA report. approach alone in process FMEA will require a complex
structure (component) model, which may not be practical.
Case-based reasoning has been used in problem diag-
5.1 Common reasoning approaches nosis [10] but not for FMEA generation. Case-based
reasoning relies on historical cases. The information of
There are three common reasoning approaches in AI,
the conditions during the occurrence of a failure can
i.e. rule-based reasoning, model-based reasoning and
constitute a case for the reasoning process. Hence, it is
case-based reasoning. According to Maher et al. [23],
theoretically possible to apply case-based reasoning in
rule-based reasoning uses IF±THEN rules to capture
FMEA generation. However, the information supplied
the knowledge. Domain experts are usually needed to
to the cases must be comprehensive enough to provide
identify these rules. Model-based reasoning aims at
an accurate result. This could be a problem for
formulating knowledge in the form of principles. These
conceptual design, where most of the information is
principles are more general than the IF±THEN rules.
still lacking.
Hence this method is applicable to a wider range of
problems than the rule-based method. Case-based
reasoning is an experience-based method that associates 5.2 `Knowledge fragment’ reasoning approach
prior problem experiences with the current cases. Thus
speci®c cases and the corresponding prior experience Besides FMEA research, reasoning has been applied to
form the main knowledge sources for a case-based conceptual design and problem solving. Kato et al. [24]
reasoning system. suggested a `knowledge fragment’ approach for reason-
There are di€erent reasoning approaches suggested in ing in a problem-solving tool. Previous failure reports
FMEA research. The model proposed by Bouti et al. [9] (fault cases) are knowledge fragments that re¯ect the
is rule based. The rules are built within the functional deliberation, reasoning and experience of the experts.
blocks to reason about the failure modes, causes and Each knowledge fragment is highly reusable. Initially, a
e€ects. Since a shallow knowledge reasoning approach model (Fig. 6) must be constructed using function and
has been used, the rules are generic for all function component ontologies. The failure reports can be repre-
blocks. Hence, it avoids complexity due to custom- sented by the schema shown in Table 1. Assuming that
made rules for di€erent functions. The disadvantage of there were previous failure reports recorded using the
this approach is that it relies on the data input to the schema, when a user provides a failure mode to one of
system. the components in the functional model, the tool will
Model-based reasoning has been used in some methods, compute all possible paths based on the functional
such as those of Price [5], Hughes et al. [6], Atkinson et al. links among the components in the model.
B09803 # IMechE 2004 Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture
294 P C TEOH AND K CASE

Fig. 6 Part of the satellite functional model [24]

Table 1 Schema for failure report [24] `command reception’ will be a€ected (fourth column in
Table 2).
Item Description The advantage of this approach is that reasoning can
Label The label of the fault case be carried out on the basis of a relatively small amount
A€ected component The component that failed in the fault case of information. Models are driven by information
A€ected function The function of the a€ected component that assigned to the ontologies rather than basic principles
was impaired in the fault case
Cause function The function of the cause component on which and can be easily composed from simple heuristic rules
the a€ected component depended to be using shallow knowledge reasoning. Hence, it is a suit-
operational able method for reasoning in conceptual design.
Details The description of details of the fault case

6 PROPOSED METHOD
Using the satellite example given by Kato et al. [24],
the voltage of the secondary battery in Fig. 6 is a€ected Using a combined method based on the above review, a
by low temperatures. Hence, the cause function new method known as FMAG (for FMEA generation)
`temperature dependence’ has in¯uenced the a€ected was created to automate the generic FMEA report
function `power supply’ (second column in Table 2). In generation. It can be illustrated by the following
a d.c.±d.c. converter, the a€ected function `power example.
supply’ from the secondary battery has become the The IDEF3 diagram in Fig. 7 can represent a process
cause function to the d.c.±d.c. converter. Hence the where a PCB is conveyed through a conveyor. The dia-
failure has been propagated to the d.c.±d.c. converter gram contains information about the functions and
(third column in Table 2). This will eventually lead to operands that can be mapped to relevant structures
the frequency-modulated receiver, where the function through functional units. The function units can be

Table 2 Failure case example

Temperature dependence of Inability of d.c.±d.c. converter to Inability of receiver to receive

Label secondary battery boost up voltage commands

A€ected component Secondary battery D.c.±d.c. converter Frequency-modulated receiver

A€ected function Power supply Power supply Command reception
Cause function Temperature dependency Power supply Power supply
Details When the temperature of a battery When the input voltage becomes low, There were some cases where commands
becomes low, the voltage provided the d.c.±d.c. converter cannot provide could not be received when the input
by the battery becomes low enough boost up to the output voltage voltage to the frequency-modulated
receiver becomes low

Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture B09803 # IMechE 2004
 MODELLING AND REASONING FOR FAILURE MODES AND EFFECTS ANALYSIS GENERATION 295

Fig. 7 Function and structure mapping

Fig. 8 Functional diagram

combined to form a functional diagram, as shown in As discussed in the previous section, the `knowledge
Fig. 8. fragment’ reasoning approach [24] has been employed.
However, unlike the work of Kato et al. [24] where
6.1 Cause-and-e€ect propagation both cause knowledge and e€ect knowledge were
stored under the same schema, FMAG divides the
In order to facilitate cause-and-e€ect propagation, a knowledge fragment into two parts. They are stored
functional diagram must be able to respond to stimula- separately in `precondition’ and `postcondition’ in the
tion or changes of state in its components. The causal forms of `operator failure state±failure behaviour’ and
reasoning drives this response. `failure behaviour±operand failure state’.
B09803 # IMechE 2004 Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture
296 P C TEOH AND K CASE

The causal reasoning in FMAG is based on two basic

assumptions:
1. There exists a state of an operator where, if there is a
change to that state, it will cause its functional beha-
viour to change accordingly.
2. There exists a functional behaviour where, if there is a
change to that behaviour, it will cause the correspond
operand to change its state accordingly.
The semantics of the knowledge fragments for the
precondition are based on assumption 1, whereas that
for the postcondition is based on assumption 2.
The precondition and postcondition gain knowledge
fragments through historical data extracted from failure
reports and the FMEA. For a particular function unit, Fig. 9 Precondition±postcondition relationship
the operator state and the behaviour of a failure event
form a set of preconditions. The behaviour and the
state of the operand form the postcondition of the sensing±PCB not sensed’. Figure 9 shows the precondi-
same event. Hence, with the accumulated events being tion±postcondition relationship in a [function unit].
recorded, precondition and postcondition tables (Figs 3 The knowledge is referred to the entities and their
and 4) will be formed. functions, but not to the function units. During the
Unlike other reasoning approaches, only the minimum reasoning process, it is possible to create new knowledge
information is used here. The reasoning process is carried by matching the precondition knowledge and post-
during the conceptual stage where much information is condition knowledge with the same failure behaviour.
still not available. During a reasoning process, only the This is demonstrated by the following example.
failure cause and e€ect will be required from the precon- In a conveying process, the function of the motor is to
dition and postcondition tables. The other properties of move the conveyor belt. The belt in turn is intended to
the operator and operand that remain in normal condi- move the PCB laid on top of the belt. At an event
tions are assumed and will not be required in the model. when the motor fails, the belt will not move, nor does
A cause-and-e€ect propagation method can be used to the PCB. Hence the knowledge captured in precondition
simulate the actual behaviour of a design in the real and postcondition tables can be arranged as in Tables 3
world. In a functional model, a state change in one and 4.
entity will a€ect the status of the interrelated entities. The precondition table de®nes the behaviour of
For example, a PCB that moves into the sensing range the motor when it fails, and the behaviour of the belt
of an inlet sensor will provide a good target for the when it is not moving. The postcondition table provides
sensor. The sensor will have a state change from `not knowledge about the response of the belt when it receives
sensing’ to `sensing’. This state change will trigger a the behaviour `not conveying’ from an operator that is
change in the controller from `not active’ to `activated’. supposed to make the belt move. The postcondition
The controller will in turn enable a motor. The move- table also provides knowledge about the response of
ment of a PCB is the cause that triggers changes across the PCB when it receives the behaviour `not conveying’.
the components in the model. The model is said to The knowledge is resident in the entities motor, belt
have a cause-and-e€ect propagation. and PCB, and not in the function units. This
The propagation is carried out through the behaviour
of a generic function via the precondition and post-
condition. The state of the operator will determine the Table 3 Precondition table
behaviour of the generic function within a function
Operator Generic function Precondition
unit. This is the precondition relationship. The behav-
iour will in turn decide the state of the operand within Motor Conveys Motor failure±not conveying
the function unit. This is termed the postcondition Belt Conveys Belt not moving±not conveying
relationship. For example, an inlet sensor senses a
PCB. The operator is `inlet sensor’, the generic function
is `senses’ and the operand is `PCB’. If a state description Table 4 Postcondition table
`sensor failure’ is introduced into the operator `inlet
sensor’, the behaviour for the function `senses’ is `not Generic function Operand Postcondition
sensing’, and the operand state is `PCB not sensed’.
Conveys Belt Not conveying±belt not moving
Hence, the precondition relationship is `sensor failure± Conveys PCB Not conveying±PCB not moving
not sensing’, and the postcondition relationship is `not
Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture B09803 # IMechE 2004
 MODELLING AND REASONING FOR FAILURE MODES AND EFFECTS ANALYSIS GENERATION 297

approach provides modularity for the creation of new 6.3 Hierarchical functional modelling
knowledge.
When a new function unit is used in a functional dia- The current FMAG is limited to provide cause-and-
gram, the operator, operand and the generic function e€ect propagation within a single level of abstraction;
involved can be used as keys to search for the matching i.e. state changes of all the objects can only be repre-
states and behaviours in the precondition and postcondi- sented within one functional diagram. Further develop-
tion tables. Hence, an entity is able to act or respond to ments could be made so that di€erent functional
the system through its historical knowledge. diagrams are used to represent the design models in
Generating the same result with an identical function di€erent levels of abstraction.
unit is straightforward. However, there is a possibility An abstract model can be decomposed into more
that new knowledge can be generated using a new func- detailed submodels so that analysis can be carried out,
tion unit. Using the same precondition and postcondition and this decomposition can be carried out at many
tables as above, consider the situation where another levels of abstraction. In terms of FMEA application,
designer is creating a design with the new function unit multiple-level modelling enables analysis to be carried
`motor conveys PCB’. Assuming that the function unit out across di€erent levels of abstraction. In fact, BS
has never been captured from the failure report, under 5760: Part 5 [2] discusses e€ects propagation in FMEA
normal circumstances, the knowledge will not be available for both single and multiple levels.
for reasoning. However, FMAG provides a means to Under the current FMAG structure, the function units
create new knowledge based on possible matching are connected to form a functional diagram. Each func-
between information in the precondition and post- tional diagram represents a scenario of a design opera-
condition tables. tion or process. A model is described by di€erent
The system will search for the operator with the name scenarios of the design or process. A model is a part of
`motor’ with function `conveys’ and retrieve the likely the entity class; hence it can serve as an operator or an
precondition `motor failure±not conveying’. The same operand of yet another functional diagram. The decom-
process is carried out on the operand with the name posed model can be represented by the example in
`PCB’ and function `conveys’. In this case, it retrieves Fig. 10.
the likely postcondition `not conveying±PCB not At the lowest level, generic functions in the functional
moving’. The combination of this information will basis are used in the functional models. However, at
result in a new case `motor failure±PCB not moving’. higher levels, non-standard terms are used. As shown in
Hence, PCB has the knowledge to respond to the Fig. 10, many of the function units in the second level
motor failure even though the case has never existed. functional diagram use the function `produces’, which is
The failure states of an object are not limited to binary not a generic function. The objects and functions in the
states (`move’, `not moving’, etc.) but can also include functional diagram at the lower level are aggregations of
states with intermittent failures such as `sometimes not the higher-level model. Hence, the hierarchical functional
moving’ or `intermittent movement’. diagrams represent the decomposition of structural and
functional models, and the relationships of the entities
in both models.
6.2 FMEA generation

FMEA generation is achieved when the causal reasoning 7 CASE STUDIES

technique is applied throughout the functional diagram.
When a new functional diagram is created for a particu- Prototype software has been created on the basis of the
lar design, the FMEA report is generated on the basis of FMAG method. Two design cases and three process
historical data saved in the database. The user can pro- cases for two-way radio design and manufacture have
vide additional information such as the RPNs, current been evaluated using the prototype software. Informa-
control and recommended action at certain stages of tion from previous FMEA reports and the failure reports
the FMEA generation process. Table 5 shows an have been entered into the software. Figure 11 shows a
example of the generated FMEA. screen dump of the prototype software.

Table 5 An example of a generated FMEA item

Part/ Part/process Potential Next

process step failure Potential high-level Current
step functions modes causes Occurrence Local e€ect e€ect End e€ect Seventy controls Detection RPN

Inductive Conveys Not Carbon brush 3 Belt not PCB not PCB not 4 Change 4 48
motor round conveying wear and moving moving moving carbon
belt tear brush

B09803 # IMechE 2004 Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture
298 P C TEOH AND K CASE

Fig. 10 FMAG model decomposition

Fig. 11 Data entry in FMAG software

Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture B09803 # IMechE 2004
 MODELLING AND REASONING FOR FAILURE MODES AND EFFECTS ANALYSIS GENERATION 299

Not all generated items are valid. For example, for the Motorola Technology Malaysia plc for supporting the
case where a feeder positions a component for a pick-and- research.
place process, the function unit is `feeder±positionsÐ
component’. If the failure is `feeder base not stable’, the
e€ect will be `component location not consistent’. In REFERENCES
another case where a nozzle places a component, the func-
tion unit is `nozzle±positions±component’. If the failure is
1 Chen, E. H. C. Failure Modes and E€ects Analysis Training
`nozzle not moving into position’, the e€ect will be `com- Manual, 1996 (Chen Technology, Inc.).
ponent not placed’. Both examples above are valid results. 2 BS 5760: Part 5: 1991 Reliability of Systems, Equipment and
However, the above data will cause the system to generate Components. Guide to Failure Modes, E€ects and Criticality
another result for the function unit `feeder±positions± Analysis (FMEA and FMECA), 1991 (British Standards
component’. Another e€ect for the failure `feeder base Institution, London).
not stable’ is `component not placed’, which is not valid. 3 Dale, B. G. and Shaw, P. Failure mode and e€ects analysis
Hence, di€erent interpretations of the function `positions’ in the U.K. motor industry: a state-of-the-art study. Qual.
can cause some confusion in the results produced. This Reliability Int., 1996.
weakness is yet to be resolved. 4 Price, C. J., Pugh, D. R., Wilson, M. S. and Snooke, N.
However, looking at the results in total, the percentage Flame system: automating electrical failure mode and
e€ects analysis (FMEA). In Proceedings of the Annual
of the invalid results is not high. Of the 339 FMEA items
Reliability and Maintainability Symposium, 1995, pp.
generated (each item is examined to determine whether 90±95.
the result is valid), 330 items were found to be valid 5 Price, C. J. AutoSteve: automated electrical design analysis.
(i.e. 97.3 per cent validity). Hence, the evaluation result In Proceedings of the 1997 IEE Colloquium on Applications
strongly supported the validity of the two proposed of Model-Based Reasoning, Instn Electr. Engrs Colloq.
basic assumptions used in the FMEA generation. (Dig.), 1997, 338, 4/1±4/3.
6 Hughes, N., Chou, E., Price, C. J. and Lee, M. Automating
mechanical FMEA using functional models. In Proceedings
8 CONCLUSION of the 12th International Florida AI Research Society
Conference, 1999, pp. 394±398 (AAAI Press).
FMEA users face many diculties due to the weakness 7 Atkinson, R. M., Montakhab, M. R., Pillay, K. D. A.,
Woollons, D. J., Hogan, P. A., Burrows, C. R. and Edge,
of the current approach. The need to improve knowledge
K. A. Automated fault analysis for hydraulic systems.
reuse at an early stage in design has prompted consider- Part 1: fundamentals. Proc. Instn Mech. Engrs, Part I:
able research in FMEA. An e€ective way to improve the J. Systems and Control Engineering, 1992, 206(I4), 207±214.
e€ectiveness of the FMEA is to automate the FMEA 8 Hogan, P. A., Burrows, C. R., Edge, K. A., Atkinson, R. M.,
authoring process. This paper has reviewed modelling Montakhab, M. R. and Woollons, D. J. Automated fault
and reasoning techniques that are used to provide auto- analysis for hydraulic systems. Part 2: application. Proc.
matic FMEA generation. Instn Mech. Engrs, Part I: J. Systems and Control Engineer-
The combination of IDEF3 and the functional dia- ing, 1992, 206(I4), 215±224.
gram provide the basic model for the process. A `knowl- 9 Bouti, A., Ait Kadi, D. and Dhouib, K. Automated manu-
edge fragment’ reasoning approach is used to create facturing systems failure analysis based on a functional
cause-and-e€ect relationships. The reasoning is con- reasoning. Information Technology for Modern Manu-
facturing, In Proceedings of the 10th ISPE±IFAC Inter-
trolled by the precondition and postcondition relation-
national Conference on CAD/CAM, Robotics and
ships based on two basic assumptions, which lead to Factories of the Future CARs and FOF’94, 1994, pp. 423±
the formation of FMEA knowledge. The new approach 429 (OCRI Publications, Kanata, Ontario).
has been tested and the case studies have shown promis- 10 Price, C. J., Pegler, I. S., Ratcli€e, M. B. and Sherwood, D.
ing results. QPAC HandbookÐHow to Implement Integrated Quality
The content of the FMEA is naturally domain depen- Systems in a Factory Floor, 1998 (Department of Computer
dent, but it is believed that the methodology is generic Science, University of Wales, Aberystwyth).
and could be used for many applications. However, it 11 Eubanks, C. F., Kmenta, S. and Ishii, K. System behavior
is true that, as knowledge increases, the computational modelling as a basis for advance failure modes and e€ects
load will be more demanding and there is a need to analysis. In Proceedings of the ASME Design Engineering
Technical Conference and Computers in Engineering
study methods of addressing this aspect before contem-
Conference, Irvine, California, 1996 (American Society of
plating large-scale practical implementations.
Mechanical Engineers, New York).
12 Eubanks, C. F., Kmenta, S. and Ishii, K. Advanced failure
modes and e€ects analysis using behavior modelling. In
ACKNOWLEDGEMENTS
Proceedings of the ASME Design Engineering Technical
Conference and Design Theory and Methodology Confer-
The authors would like to thank Mechanical and Manu- ence, Sacramento, California, 1997 (American Society of
facturing Engineering, Loughborough University and Mechanical Engineers, New York).

B09803 # IMechE 2004 Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture
300 P C TEOH AND K CASE

13 Kusiak, A. Engineering DesignÐProducts, Processes and 1993 (Federal Information Standards Publications);
Systems, 1999 (Academic Press, San Diego, California). http://www.idef.com/Downloads/pdf/idef0.pdf.
14 Hunt, J. E., Pugh, D. R. and Price, C. J. Failure mode 20 Dorador, J. M. Product and process information inter-
e€ects analysis: a practical application of functional model- action in assembly decision support system. Doctoral
ling. Appl. Artif. Intell., 1995, 9(1), 33±44. Thesis, Loughborough University, 2001.
15 Gero, J. S., Tham, K. W. and Lee, H. S. BehaviourÐa link 21 Mayer, R. J., Menzel, C. P., Painter, M. K., deWitte, P. S.,
between functional and structure in design. In Proceedings Blinn, T. and Perakath, B. Information integration for con-
of the IFIP WG 5.2 Working Conference on Intelligent current engineering (IICE) IDEF3 process description cap-
Computer Aided Design, 1991 (Elsevier, Amsterdam, The ture method. Report, Knowledge Based System Inc., 1995.
Netherlands). 22 Chandrasekaran, B. and Josephson, J. R. Representing
16 Hubka, V. and Eder, W. E. Theory of Technical Systems: function as e€ects: assigning functions to objects in context
A Total Concept Theory for Engineering Design, 1988 and out. In Proceedings of the AAAI Workshop on Model-
(Springer-Verlag, Berlin). ing and Reasoning with Function, 1996, pp. 30±37.
17 Pahl, G. and Beitz, W. Engineering Design, A Systematic 23 Maher, M. L. and Pu, P. Issues and Application of Case-Based
Approach, 2nd edition, 1996 (Springer-Verlag, London). Reasoning in Design, 1997 (Lawrence Erlbaum Associates).
18 Ulrich, K. T. and Eppinger, S. D. Product Design and 24 Kato, Y., Shirakawa, T. and Hori, K. Department of
Development, 1995 (McGraw-Hill, New York). Advanced Interdisciplinary Studies, University of Tokyo,
19 National Institute of Standards and Technology (1993). 2002; http://www.ai.rcast.u-tokyo.ac.jp/¹yoshi/papers/
Integrated De®nition for Function Modelling (IDEF0), kes2002.pdf.

Proc. Instn Mech. Engrs Vol. 218 Part B: J. Engineering Manufacture B09803 # IMechE 2004

View publication stats