Day3 Function FMEA

Day 3:
Design For Quality and Reliability
Systems Engineering Short Course V2.7.3 1

Small amounts of variation
can cause significant system
problems.
The design and manufacture

of the Nimrod fuselage means
that there is aircraft to aircraft
variation of up to 6 inches.
This was well known! (indeed
all the designers’ tolerances
were ±10thou) but
not understood.
A consequence of this was

that on the first development
aircraft the wings did not fit!
In fact very little fitted!!

Process and Tools
Specify and
Gather Requirements Access to Market,
Analyse Requirements Validate Requirements
Requirements, Orders Impose Restrictions
Rolls-Royce Influence
Pressure Groups
Airframe
Test Bed,
Manufacturers Fuel Dev’t
Demand Immediate Profit,
Provide Funding
Orders Orders Require
Gov’t et al Shareholders
Supply Operators & Funders
Demand Technology
Transfer
Fuel Suppliers
Influence
(Mainly
Military) Demand
Supply
Influence Friends Competitors
Users
As per RR
Stakeholder Map
Identify and group
stakeholders Specify the
Assess the functional sensitivity Requirements in the
and potential functional failure x
requirements database
x
x
modes to identify potential x
emergent functionality and risk
Containment
Im
Number entry
Coin handling
Optional Lan
Card reader
po Design
Wipe clean
rta
nc Requirements
Display
e to
Low Cost Available Cu
Safe Customer sto
me
r
Requirements
Sensitivity & Failure Analysis Quality Function Deployment 1 DOORS
Features
Easy to use 4
Reliable Multi-language 3
Output
Coin/card/credit
Durable
5
5
Correlate and cross-check
Viewpoint: Function S Severity of Occurrence Criticality Index Date............................... No: ....
requirements for completeness
Operation
Receiving .
Input IJK LMN O Probability of Occurrence
PQR C I = SOD
Function
Attractive
System: Washing Machine
D Probability of Detection
Author: .......................... Issue
Reliable 4
Performs ABC X
Subsystem: ...................................... Checked: ....................... ...........
Cleans easily
Fast
DEF X FUNCTION
LOAD DIRTY CLOTHES OVERLOAD

MODE
CHARACTERISTICS OF FAILURE
EFFECTS
POOR WASH
CAUSE
USER ERROR 6
O
INDEX
6 3
D CI
108
COMMENTS
Maintainable
2
5
and consistency
IJK Y UNDERLOAD POOR WASH USER ERROR 4 4 3 48
min ingress
validation
500k inserts
All standard
European
luminosity
1kN shock
EXTREME MIX OF POSSIBLE COLOUR EXTREMES NOT 8 8 3 96
16 max
1M ops
Arabic
LOAD RUN IDENTIFIED
95%
3 min
FABRIC SHRINK EXTREMES NOT 4 8 3 96
Target values
Affinity Diagram/Use Case
IDENTIFIED
DETERMINE LOAD MAKE INCORRECT LOAD POOR WASH ITEM OF CLOTHING 4 8 3 96

UP MAKE UP NOT INDENTIFIED
INDENTIFIED
POSSIBLE COLOUR
RUN
Technical competitive
FABRIC SHRINK
assessment
Via interviews and focus Importance Weighting 39 82 58 139 126 50 18
groups use Affinity Diagrams

and Use Cases to elicit,
capture and structure
expressed requirements
Determine Validation and
Determine System Functionality using as necessary:
ES
Verification methods for each
RIC
_P
NT
BUDGET
WEATHER
E
RR
SEEDS
requirement and specify V& V
CU
CVF MT30 Fuel System Functional Structure Chart
PURC
HASED
PROVIDE HIGH
_FERTI
PRESSURE REGULATED LIZER IL
TOASTING
SO
CLEAN FUEL TO THE GAS
SYSTEM TURBINE
requirements
Structured Textual Analysis PURCHASE
PURCHA
Project: 1 SED_SE
FERTILIZER EDS PLANTS
Author: DESIGN DISTRIBUTE & OPERATE SUPPORT DISPOSE CULTIVATE
MANUFACTURE SENSE FUEL CONTROL FUEL
DELIVER FUEL REMOVE FUEL COOL FUEL DRIVE VSV
TOASTER TOASTER SELL TOASTER TOASTER TOASTER TOASTER STATE FLOW
HEALTH_ITEMS
Requirements
PURCHASE 2 W
Context: D_HEALTH AT
_ITEMS ER
MEASURE FUEL REGULATE RECEIVE SHUT
RANSFER FUEL COOL FUEL
Operational Requirement: PRES & TEMP FUEL FLOW OFF COMMAND
CO
MP PICK
Structured Verification Plan

TOAST
HANDLE
BREAD/TOAST
BREAD MANAGE HEAT
SEAL FUEL OST VEGETABLE
PRODUCT SYSTEM
SEND PRESS & DRIVE DRIVE FUEL CONTROL FUEL
VEGETABLES
Non functional System Requirements: TEMP SIGNAL PRESSURIZER SHUT OFFF TEMP
_GRO D_HOME
ED
3
A1
WN_SE
LOAD BREAD APPLY HEAT TO
PRODUCT BREAD GENERATE HEAT RECIEVE FUEL MEASURE FUEL PRESSURIZE
SHUT OFF FUEL
FLOW FUEL
Functional Non Functional Non Functional N
Requirement Performance Implementation COMPOST EE TE
STORE
6 GR AS
A Requirement Requirement SENSE REMOVE SEND FUEL
UNLOAD TOAST
_W EXTRACT
SEND SHUT OFF
BROWNING PARTICTULATES FLOW SIGNAL SIGNAL
SEED
CONTROL
RECEIVE DRAIN 4
A2
FUEL COMMAND
BROWNING STORE
HOME_GROWN Component A Component B Component C
DRAIN FUEL DIAGRAM 0 _SEED HOME_GROWN
5 _SEED
Requirement 1 A1 E1 A1
System B
Analyse expressed Determine system Determine system Develop a model of the planned Requirement 2 E2 R1 A2
Requirement 3 R2 R2 R2
C
C1 requirements to deduce functionality from functionality from the system to identify logical interfaces
C2
missing requirements existing solutions experience of the team and functional dependencies
Tree Diagram Systemic Textual Analysis Functional Analysis Viewpoint Analysis Functional Modelling
Organize the expressed
requirements
Cleaning Disposable
Need Means Analysis
Nanobots
Service Clothes
House
Integrated
Clean
Clothes by Combined
Assess potential Meta-solutions to
Source System
Washing
Machine
Dishwasher
stakeholder needs
Stakeholder Ultrasonic
Cleaning
Dry
Cleaning
Steam
Cleaning
Requirements
Determine Meta-solution
Introduction
 The increase in complexity of systems has resulted in many displaying
undesirable emergent behaviour. Hindsight often shows these to be
“obvious” and therefore avoidable – “if only we had time to think!”
 One aspect of undesirable emergence

is system sensitivity which can be
assessed before design to provide:
– design suggestions to prevent or
detect the potential issue(s)
– an early understanding of possible
trade-offs
– an identification of critical functions
– the identification of “sensitive flows”
– the identification of potential system
failure modes, their effects and causes
 Such analyses will provide an early
assessment of risk and promotes
ideas and guidance for generating
and selecting conceptual solutions

Philosophy
 An understanding of undesirable
emergent behaviour due to system
sensitivity can be provided through the
work of Dr Genichi Taguchi
 Taguchi realised that apparently minor
variations in a system parameter can
have a significant effect on overall
system performance
 He also realised that aspects of the
traditional approach to sensitivity
through the use of tolerances and
specification limits can be very
misleading
 Taguchi proposed the idea of robust
design

Traditional Variation Cost Model
In here

In here Lower Spec Target Upper Spec
Limit Limit

In here

The traditional loss model implies
that an item just inside the
specification limit imparts no loss
and therefore is the same as the
item exactly on target
£x
Loss £0 Loss £0
Quality
Loss £x
In here
£0 
In here Lower Spec Target Upper Spec
Limit Limit

In here

2011 Quality Cost
2011 cost of non-quality
Total £709m

Which one would you take home
This Computer This Computer

passed its final passed its final
test just inside test exactly on
the specification target
limits
£399 £399

Common sense suggests there
is a difference between the item
just inside the specification limit
and the item exactly on target.
The traditional model is wrong!
£x
Loss £x Loss £0 Loss £0
Quality
Loss £x Is there a
Difference?
£0
Lower Spec Target Upper Spec
Limit Limit

Variation
 Taguchi realised that the traditional model is only “correct” up to the
point the product left the factory, but it does not take into account what
happens afterwards. He argued that all products will deteriorate with
use and therefore items close to specification limits will either:
– fail early because the deterioration takes them quickly out of specification
– have a very long life
 In other words, Taguchi realised he needed to understand the
through-life costs and reasoned that a loss is always incurred when a
system’s quality characteristic y deviates from its target value m,
regardless of how small the deviation is.
 Taguchi used the Taylor series to mathematically prove to the first
order:
Loss = k(y - m)2 = k2
 Taguchi applied his concepts to products, we now realise that it

applies to any system
Taguchi Variation Cost Model
Taguchi’s loss function states that any system that does not meet its
target specification will either impart a loss to the company or a loss
to the customer (he generalised this to talk about a loss to society)
Quality
Loss £ LSL USL
Loss £
Loss £?
Loss = k(y-m)2
Target
Deviation m
y from target

Effect of Variation
Every component in a system will have its own characteristic loss function,
but the ‘degree of loss’ is dependent upon the constant k.
Large k: loss is
sensitive to
variation
Small k: loss is
insensitive to
variation
Loss
Target
Note: Manufacturing Variation is only one of three sources of variation that lead to
performance degradation. The other two are environmental and use. System Designers
often take account of these as a matter of course – it’s the Manufacturing variation they
often choose to ignore!

The Robust Design Approach
Systems Design
Fundamental design and
engineering concepts
established
Parameter Design
Determination of target values and
sensitivity to variation – i.e. loss functions
determined. Elements that are sensitive
should be redesigned
Tolerance Design
Tolerances established based on
sensitivity analysis. Robust components
do not need a tight tolerance -
sensitive ones do

Taguchi and Requirements Interpretation
 Taguchi’s approach is applied only once the basic concept
design has been agreed which could result in an expensive
redesign (but not as expensive as a redesign after
production has started)
 It is possible is to apply his philosophy during requirements
determination since:
– all parameters in a system are subject to target values
– functionality will be affected through the variation of input quantities
about their respective target values
– functionality will be affected by the variation of the function’s
operation
 In other words it is possible to use previous experience and
common sense to identify potential issues before design
commences and hence design out problems ab initio

Functional Sensitivity Analysis
X1 Taguchi’s approach requires
us to know the transfer
function between the inputs
X2 Function and outputs of a particular
Y = f(X1, X2, X3)
Y function. This transfer
function can typically only be
determined after it has been
X3 designed
What is f? - the relationship between the Y and the Xs – if we know

what f is and the variation in the Xs we could determine the
impact on the output
Y = -17.4 + 3.2X1 - 0.4X22 - lnX3 + etc.
Variation in the Likely variation

output is transmitted in X3

Functional Requirement Sensitivity Analysis
X1
X2 Y
Function
X3
When engineering requirements we do not know what “f” is

(we know its name but not the mathematics) – but we can
use the knowledge of the team to assess how sensitive a
function’s outputs are to the likely input variation and how
that function might fail
Approach 1
Will the expected variation in the
inputs cause excessive variation
in the output of the CULTIVATE
CROP function assuming that the
WEATHER
SEEDS inputs are used correctly?
PURCHASE
SUPPLIES
1
FERTILIZER PLANTS
CULTIVATE
CROP
2
PICK
VEGETABLES
VEGETABLES
3
COMPOST
Approach 2 WASTE
What happens if an input is 6
EXTRACT
not used correctly? – How SEED
can the function fail, what will 4
STORE
be the effects experienced HOME_GROWN
by the user and what are the _SEED HOME_GROWN
causes? 5 _SEED

Sensitivity Analysis the Approach
 The basic approach is one of applied common sense! It is about
questioning to seek information in a structured manner
 The questions that need to be asked at this stage include:
– how sensitive is the function to the expected variation in an input?
• what are the likely variations in the inputs?
• how will variations in the inputs affect the variation of the outputs?
– how could the functions fail and what are the potential failure modes
and effects?
 The answers to these questions generate information about the
system and this knowledge is then helpful in:
– concept generation and selection
– assessing risk
– determining trade-off studies

Approach
Takes an external view
of the functions:
Input/Output sensitivity
(Black Box view) Takes an internal view
of the functions: Internal
failure modes
(White Box view)
Flow
Sensitivity
Robustness Assessment Function

Sensitivity

Flow Sensitivity Analysis
 What Is it?
– Flow Sensitivity Analysis is a simple tabular method for assessing the relative
effect of flow variation on the performance of a system
 Why do it?
– To determine where there may be potential undesirable emergence and therefore
design it out ab initio
 How to do it:
– The approach is to form an input/output matrix for the lowest level FFDs:
• identify and list, from the functional model, the input flows and their receiving functions
• Identify and list, from the functional model, the output flows
– Consider each input/output combination in the matrix and assess the effect of
variation in the input flow on that function and output flow as judged on a simple
three level scale:
• insensitive the input variation will not cause significant variation in the output
• med. sensitive
• very sensitive the input variation causes significant variation in the output

Example
ABC
IJK
PQR
X Y
DEF This cell is empty
since there is no direct
LMN
link between ABC and
List inputs PQR
& receiving Functions
Output
Receiving
Input IJK LMN PQR
Function
ABC X
DEF X
Record here the
sensitivity of the
input – output pair
IJK Y

Example
Output
Input Receiving PURCHASED PURCHASED PURCHASED PLANTS VEGETABLES COMPOST HOME_

Function _FERTILIZER _SEEDS _HEALTH GROWN
_ITEMS _SEEDS
SEEDS 1 
FERTILIZER 1 
HEALTH_ITEMS 1 
BUDGET 1 o o o
CURRENT 1 o o o
_PRICES
PURCHASED _ 2 o
SEEDS
PURCHASED _ 2 
FERTILIZER
PURCHASED _ 2 
HEALTH_ ITEMS
WEATHER 2
SOIL 2 
PLANTS 3
VEGETABLES 4
COMPOST 2 o
HOME_ GROWN _ 2 o
SEEDS

Causal Effect
WEATHER
SEEDS
PURCHASE
SUPPLIES
1
FERTILIZER PLANTS
CULTIVATE
CROP
2
PICK
VEGETABLES
VEGETABLES
3
COMPOST
WASTE
6
EXTRACT
SEED
4
STORE
HOME GROWN
SEED HOME_GROWN
5 _SEED

Function Sensitivity
Assuming that the
inputs are correct
 Flow sensitivity examines the effect of how can the function
variation in flows on functionality. fail?
However, while this does indicate whole
system effects we also need to consider
WEATHER
the internal failure of the functions.
 Although the precise nature of the
functional failure is unlikely to be known
until its implementation is decided, it is still CULTIVATE
PLANTS
CROP
possible to make an assessment by 2
considering functional failure modes,

effects and causes
 Rather than ‘invent’ a new tool Failure
Mode and Effects Analysis (FMEA) is
ideal for conducting the necessary
functional failure assessment

Functional Failure Modes and Effects Analysis
 What is it?
– A systematic approach to identifying,
documenting, and prioritising potential
functional failure modes, effects and
FUNCTIONAL FMEA causes
System: Autonomous Lawn Mower
Subsystem:
Element:
O – probability of Occurrence
S – Severity of occurrence
D – probability of Detection
1: Very rare  10: Frequent
1: No Effect  10: Most Severe
1: Certain to Detect  10: Cannot Detect

Date: 1 April
Author: D Blunt
Checked: C Cut
No
Issue
 Why do it?
FUNCTION
FUNCTIONAL
FAILURE MODE
EFFECTS S CAUSES O
DETECTION
Current Employed Method D

RPN Design Suggestions/Comments
– Helps identify additional functionality or
Cut Grass Under Cut Lawn not short
enough
5 Cutter
damaged
5 None relies on
Human User
10 250 Monitor Motor Torque for
hitting objects and inform
features ab initio that will make the system
user
more robust in the hands of the customer

Cutter Height 3 None relies on 10 150
not set Human User
correctly
Cutter worn 4 None relies on 10 200 Monitor machine usage

How to do it?
Human User
Over Cut Lawn too short 6 Cutter
damaged
5 None relies on
Human User
user
– Functional FMEA works best when drawing
Cutter Height
not set
3 None relies on
Human User
10 180
upon the expertise and knowledge of a
correctly
Damage to lawn 8 Cutter 5 None relies on 10 400 Monitor Motor Torque for
multi-disciplinary team
– The team should consider the system
damaged Human User hitting objects and inform
user
not set Human User
correctly functions and how they might fail,
identifying potential:
• Failure mode
• Effects of failure
• Causes of failure
– Ratings are assigned to the probability of
occurrence, severity of an occurrence and
probability of detection, and these are then
used to determine an overall risk value
Functional FMEA - How to do it
STEP 1: Identify and list
the system functions
STEP 2: For each function identify

potential failure modes
STEP 3: For each failure mode identify

effects experienced by the user
STEP 4: For each failure mode

identify causes
STEP 5: For each failure mode identify

current detection methods employed
STEP 6: Rate probability of Occurrence,

Severity and probability of Detection
STEP 7: Determine RPN
STEP 8: Consider high RPN for new

functionality or design ideas
The Functional FMEA Form
FUNCTIONAL FMEA
System: O – probability of Occurrence 1: Very rare ® 10: Frequent Date: No
Subsystem: S – Severity of occurrence 1: No Effect ® 10: Most Severe Author: Issue
Element: D – probability of Detection 1: Certain to Detect ® 10: Cannot Detect Checked:
FUNCTIONAL DETECTION/PREVENTION
FUNCTION EFFECTS S CAUSES O RPN Design Suggestions/Comments
FAILURE MODE
© Burge Hughes Walsh 2005

Failings of FMEA
Define what you understand by Failure?
FMEAs often fail to deliver because people apply their own

understanding of what is meant by failure. It is an everyday
word that is often associated with schooling and education,
poor services as well as equipment breakdowns.
In the serious world of engineering we have to be

precise – people’s lives depend on it!

A Systems View of Failure
 FAILURE: The termination of the
ability of an item to perform a required SYSTEM, SUBSYSTEM, … has
COMPONENT FUNCTION
function. (BS4778-3.1:1991)
 FUNCTION: what the item does, its fails to deliver
purpose func on via defin s
 FAILURE MODE: the manner in results in
which the item fails to meet its FAILURE MODE EFFECT
intended function. (SAE J1739
JAN2009) has
generatese
 EFFECT: The consequence(s) a
failure mode has on the operation, ini ates
FAILURE MECHANISM CAUSE
function, or status of the highest
indenture level. This is expressed
as what the CUSTOMER/USER
might experience as a result of the
failure mode. [MIL Std 1629A]
 CAUSE: the underlying event that
leads to a failure mode, it initiates the
failure mechanism. Most FMEA templates do not include a column to capture Failure
 FAILURE MECHANISM: The Mechanism and in consequence when users identify a failure
mechanism they capture it as the Failure Mode or Cause.
physical, chemical or other process
that results in failure. (BS4778- This leads to an inconsistent use of the tool, confusion and
3.1:1991) frustration – p.s. even the standards get it wrong!
Failure Demonstration
has
PART/COMPONENT FUNCTION
fails to deliver
function via defines
results in
FAILURE MODE EFFECT
has
generates
initiates

has
PAPER CLIP FUNCTION
fails to deliver
results in
FAILURE MODE EFFECT
has
generates
initiates

has HOLDS 2 OR MORE PIECES OF

PAPER CLIP
PAPER TOGETHER
fails to deliver
results in
FAILURE MODE EFFECT
has
generates
initiates


PAPER CLIP
PAPER TOGETHER
fails to deliver
results in
NO HOLD - Broken EFFECT
has
generates
initiates


PAPER CLIP
PAPER TOGETHER
fails to deliver
results in
NO HOLD - Broken PAPER NOT HELD TOGETHER
has
generates
initiates


PAPER CLIP
PAPER TOGETHER
fails to deliver
results in
has
generates
initiates
FAILURE MECHANISM CYCLICAL LOADING


PAPER CLIP
PAPER TOGETHER
fails to deliver
results in
has
generates
initiates
FATIGUE CYCLICAL LOADING

The Functional FMEA Form
FUNCTIONAL FMEA
System: O – probability of Occurrence 1: Very rare ® 10: Frequent Date: No
Subsystem: S – Severity of occurrence 1: No Effect ® 10: Most Severe Author: Issue
Element: D – probability of Detection 1: Certain to Detect ® 10: Cannot Detect Checked:
FUNCTIONAL DETECTION/PREVENTION
FAILURE MODE
Use this column to Use this column

record the system Use this column to to record
Use this columns to rate
functions record the currently Risk Priority
the Severity of occurrence
employed detection Number RPN
method
Use this column to
record the Use this column to
functional failure record the potential
mode and actual causes Use this columns to rate
of the failure the probability of Detection
Use this column to

record the symptoms of It is the comments
the failure experienced column that is the
Use this columns to rate
by the customer important output since it
the probability of Occurrence
© Burge Hughes Walsh 2005 flags design ideas/issues
Functional Failure Mode
 A Functional FMEA examines the functions and the failure modes must be
expressed in this context
– In fact all Failure Modes must be defined relative to a function since it is central
to the definition of failure
– Failure modes are used in preference to failures, since a given failure may have
several failure modes.
 Failure modes should be written in the context of the verb description, as
“anti-functions”
 There are only 5 types of failure modes – the “usual suspects”:
– Over, Under, No, Intermittent, Unintended
– Example: The key to Functional Failure Modes is to put the
• Wash Clothes function’s verb after the usual suspects and then
– Over wash interpret for the particular situation
– Under wash (wash cycle completed and wash cycle not complete)
– No wash
– Intermittent wash (sometimes washes sometimes doesn’t)
– Unintended wash (oops it’s the cat!)
• Note: not every generic failure case will apply and for a specific function
there may be others
Effects
 The EFFECT of a potential failure mode is what the USER of the system
might actually experience as a result of that failure mode
 User dissatisfaction is not an effect – all the effects will result in
dissatisfaction – the purpose of the effects column is to record why the
user is dissatisfied
 It is important to recognise here that for any potential functional failure
mode there can be several possible effects experienced by the user of
the system. Each of these should be recorded. For example the “wash
items” function has the potential functional failure mode of “over-wash”
this could have several effects including:
– shrinkage
– colour run
– colour fade
– physical fibre damage
 Note that different failure modes could have the same effect
 Other stakeholders may also experience effects as a consequence of the
failure mode – these are not recorded on the FFMEA – if necessary a
FFMEA can be performed for another stakeholder
Severity S
 Severity relates to the effect experienced by the user/customer (i.e. to
the description given in the “effects” column). It is a measure of how
dissatisfied they would be if they experienced the effect
 Severity is assessed on a simple 1 to 10 scale
1 10
Not severe Extremely severe
The user may not
Usually reserved for
know the failure
death or injury of user
has occurred
 Severity needs to be “calibrated” against the context and user

Causes
 Causes should be limited to design concerns i.e. we
assume that the system is manufactured/implemented
correctly
 Analysis must stay within the defined scope (applicable
system and interfaces to adjacent systems)
 There is usually more than one cause of failure for each
failure mode
 Causes must be identified for a failure mode, not an
individual effect. Causes may be repeated if a failure
modes has several effects
 Causes can be either potential or actual. FFMEA is about
stopping people making the same mistake as well as
potentially new ones

Occurrence O
 Occurrence relates to the likelihood that a particular cause will occur leading
to the failure mode and ultimately the effect
 Occurrence is assessed on a simple 1 to 10 scale
Very rare 1 10 Frequent
OCCURRENCE RATINGS
Rating Description Criteria Probability of Failure
1 Remote Occurrence Failure highly unlikely to occur. History of similar 1 in 1,500,000
design satisfactory with no failures
2 Very Slight Occurrence Failure very unlikely to occur. History of very few 0.0000067
failures
3 Slight Occurrence Very few and infrequent failures 0.000067
4 Low Occurrence Few and infrequent failures may be expected 0.0005
5 Medium Occurrence Some failures likely, but not in major proportions 0.0025
6 Regular Occurrence Regular failures may be expected 0.0125
7 Moderately High Occurrence Frequent failures may be expected 0.05
8 High Occurrence Failure of major proportions may be expected 0.125
9 Very High Occurrence Frequent failures. History of similar design issues 0.33
10 Extremely High Occurrence Constant failure 0.5

Failure Mechanisms
 Most FMEA forms, including the one presented here, don’t have a
column for the failure mechanism
 This is indeed unfortunate because in completing FMEAs is a common
error to confuse failure modes, causes and failure mechanisms!
PIVOT
Two FUNCTIONS
1 Aligns Shear Surfaces

2 Control Motion of Shear Surfaces
FAILURE MODES
(For Control Motion of
Shear Surfaces)
CAUSES FAILURE No Control EFFECT

Poor material selection MECHANISM Over Control
Poor tolerances Under Control Poor “cut”
Uneven load distribution Wear Unintended Control edges
Systems Engineering Short Course V2.7.3
Intermittent Control 45
Detection/Prevention
Currently Employed Method
 On a Functional FMEA “Detection/Prevention” relates to
what we did last time.
– There is an implicit assumption that we have designed a similar
system before and may, therefore, have experienced the failure
mode.
– In which case, it is possible some detection or prevention method
has been incorporated in the previous design.
 The purpose of the Detection/Prevention column is to
identify and record this and assess how effective it was
 If there was none – write none. This often happens if it is
an unprecedented function or system

Detection D
 The “D” column is an assessment of “how good” the
currently employed Detection/Prevention method is at
preventing or providing a warning of the impending failure
 The 1 to 10 Detection scale is based upon whether or not
the user will experience the effects of the failure mode
1 10
Certain to Cannot detect

detect failure failure - user
before user A classic example of a certain to
experiences 1 is a car fuel gauge. experience
the effects This device can give failure effects
ample warning of the
fact the car will stop if
the fuel is not
replenished

Detection Ratings
DETECTION RATINGS
Rating Description Criteria
1 Remote probability of failure A known detection method exists for similar systems with a
reaching the user strong history of excellent performance and is included in the
system requirements
2 Very Slight probability the failure A known detection method exists for similar systems and is
mode will reach the user included in the system requirements
3 Slight probability the failure mode A known and robust detection method exists for other systems
will reach the user and is included in the system requirements
4 Low probability the failure mode will A known detection method exists for other systems and is
reach the user included in the system requirements
5 Medium probability the failure A known and robust detection method exists for other systems
mode will reach the user but is not included in the system requirements
6 Moderately probability the failure A known method exists for other systems but is not included in
mode will reach the user the system requirements
7 Moderately High probability the An experimental detection method exists for other systems and
failure mode will reach the user is included in the system requirements
8 High probability the failure mode An experimental detection method exists for other systems but
will reach the user is not included in the system requirements
9 Very High probability the failure No known detection method but one is included in the system
mode will reach the user requirements
10 It is certain that the failure mode No known detection method and no requirement to do so
will reach the user specified

Risk Priority Number RPN
 The values assigned to S, O and D are now multiplied

together to give a Risk Priority Number (RPN)
 The purpose of the RPN is to direct action where it is
required
 Care must be exercised, since the S, O and D ratings are
not absolute but relative! Different teams constructing the
same FMEA will typically generate the same failure
modes, effects and causes - but will assign different
values to SOD - BUT the prioritisation is likely be the
same

Design Suggestions/ Comments
 The final column of a Functional FMEA is that allocated
for fixes!
 Although the system has yet to be designed per se,
knowledge of potential failures can lead to design ideas
which if built in ab initio will be minimum cost
 It is important to remember why we are conducting the
FFMEA – to identify new functionality/ideas for either
eliminating the potential failure mode or detecting it.
Accordingly there are levels of intervention:
1. Design the failure mode out completely
2. Provide a detection method that warns the user of impending
failure – e.g. a fuel gauge on a motor car warns when the car is
about to fail (run out of fuel)
3. Inform the user the failure has occurred

Example
FUNCTIONAL FMEA
System: Washing Machine O – probability of Occurrence 1: Very rare ® 10: Frequent Date: 1/1/01 No 123
Subsystem: S – Severity of occurrence 1: No Effect ® 10: Most Severe Author: S. Powder Issue 1
Element: D – probability of Detection 1: Certain to Detect ® 10: Cannot Detect Checked: A. Spinner
FUNCTIONAL DETECTION
FAILURE MODE
LOAD DIRTY No Load No wash 3 User Error 2 None – but requirement for 9 54 Include load cell or other sensor for load
weigh load function identified detection
CLOTHES
Over Load Very poor wash 5 User Error 6 None – but requirement for 9 270 Include load cell or other sensor for load
weigh load function identified detection – will need to guard against wet
towels or similar giving false-positive type
signal
None – but requirement for Include load cell or other sensor for load
Under Load Poor Wash 4 User Error 4 9 144 detection
weigh load function identified
Intermittent Load Colour run 6 Items shielded 9 None – but functionality 9 486
identified for detecting mixed Line of sight sensing will not detect
(Hidden extreme by others loads this situation and therefore system
mix of load) Fabric Shrink 7 Items shielded 9 None – but functionality 9 567 solution should attempt to avert this
identified for detecting mixed
by others loads
Could include a fast stop button that

Unintended Load Injury/death of 8 User Error 2 None 10 160
overrides any interlocks
(pet or object in pet
items)
Object damages 7 User error 3 None 10 210
items For heavy objects the use of load cell
may indicate the presence
Object damages 8 User Error 2 None 10 160
machine
It is the comments column that is the important output since it is used

to capture design ideas that can be built into the systems ab initio
© Burge
Systems HughesShort
Engineering Walsh 2005 V2.7.3
Course 51
Exercise – FFMEA
 In teams
– Conduct a functional FMEA for a particular
function
• List all the Failure Modes
• Select one Failure Mode and list all the
Effects
• Select one Effect and list all the Causes
• Select one Cause and list the Current
Detection Methods (guess)
• Assign S, O, and Ds as you proceed
• Determine some suitable design ideas
– Flip chart the outcomes and be prepared to
share with the rest of the group
– Time: 30 Minutes

A New Functionality
 So far, the various tools have been used to identify
system functionality associated with the operation of the
system – i.e. what's needed to make it work - the
Operational Functionality
 Completing a FFMEA will lead to many design ideas.
These should be reviewed to:
– Identify common themes
– Determine additional system functionality
 This new functionality is called Emergent Functionality
and can often delight the customer, but remember - they
don’t necessarily want to pay for it
Operational Functionality: the functionality necessary for a system to
deliver its operational requirement
Emergent Functionality: the functionality of a system that addresses
emergent behaviour
Tying up loose ends

FUNCTIONAL FMEA
Flow Sensitivity Analysis and System: Autonomous Lawn Mower
Subsystem:
Element:
O – probability of Occurrence
S – Severity of occurrence
D – probability of Detection
1: Very rare ® 10: Frequent
1: No Effect ® 10: Most Severe
1: Certain to Detect ® 10: Cannot Detect

Date: 1 April
Author: D Blunt
Checked: C Cut
No
Issue
Functional FMEA are very good at FUNCTION

FUNCTIONAL
FAILURE MODE
EFFECTS S CAUSES O
DETECTION/PREVENTION

RPN Design Suggestions/Comments
helping to identify 10% - 20% of Cut Grass Under Cut Lawn not short
enough
5 Cutter
damaged
5 None relies on
Human User
user
system functionality not discovered not set

correctly
Human User
Cutter worn 4 None relies on 10 200 Monitor machine usage
by Viewpoint Analysis Over Cut Lawn too short 6 Cutter

Human User
5 None relies on 10 300 Monitor Motor Torque for

damaged Human User hitting objects and inform
user
Functional FMEA is very good at Cutter Height

not set
correctly
3 None relies on
Human User
10 180
defining emergent functionality. Damage to lawn 8 Cutter

damaged
5 None relies on
Human User
user

not set Human User
If a Functional Model, Viewpoint correctly
Analysis and/or Systemic Textual © Burge Hughes Walsh 2005
Non-functional Functional Non-functional

Analysis have been undertaken Implementation Requirement Performance
Requirement Requirement
they should be updated with the Grass up to 100mm
new derived requirements from the Different grass types
Functional FMEA Navigate Lawn
 If a Systemic Textual Analysis has Inform user
not been undertaken – start one Monitor system
now. Easy Replaceable

Blades
240v 60hz ac

Functional FMEA
 Pros  Cons
– Simple to use – Often left until it’s too late –
– Leads to shared and common once the design has been done
understanding – Can become tedious
– Identifies potential problems – Identified causes are not the
early root cause
– Through identifying potential – Can result in over design
problem areas, risk because too many ideas are
management can begin at a generated and incorporated
much earlier stage and
influence concept generation
and selection
– Since for a given Operational
Requirement, the underlying
functionality is invariant, the
FFMEAs will have aspects that
are also invariant and therefore
reuse can reduce the analysis
effort in the longer term
Summary
Functional FMEA and Flow Sensitivity are simple tools that uses the knowledge and
experience of the team to identify potentially sensitive functions and flows that could
result in undesirable emergent behaviour – they identify the critical functions and inputs
Expressed Delight
CUSTOMER EXCITMENT
Systemic Textual
Those requirements (features and Failure
Those requirements (features and
High aspects) that are sufficiently aspects) that cannot be articulated
Analysis
important to be verbalised by the Analysis
because the customer does not know
customer. In general, the more the they want them, but if provided will
better! surprise and delight. These are NOT
over design!
Basic Assumed
Those requirements (features and Those requirements (features and
aspects) that are so obvious to the aspects) that while not basic yet are
Low type of system that the customer will Functional
starting to be taken for granted. If not
Viewpoint/
not mention them. However, if not provided the customer will be
provided the customer will be
Functional Analysis disappointed! Modelling
dissatisfied!
Low High
CUSTOMER SATISFACTION

Day3 Function FMEA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Day3 Function FMEA

Uploaded by

Copyright:

Available Formats

Day 3:

Design For Quality and Reliability

Systems Engineering Short Course V2.7.3 1

The design and manufacture

A consequence of this was

Systems Engineering Short Course V2.7.3 3

Influence Friends Competitors

emergent functionality and risk

Sensitivity & Failure Analysis Quality Function Deployment 1 DOORS

requirements for completeness

LOAD DIRTY CLOTHES OVERLOAD

DETERMINE LOAD MAKE INCORRECT LOAD POOR WASH ITEM OF CLOTHING 4 8 3 96

groups use Affinity Diagrams

requirement and specify V& V

Structured Verification Plan

 One aspect of undesirable emergence

Systems Engineering Short Course V2.7.3 5

Systems Engineering Short Course V2.7.3 6

Systems Engineering Short Course V2.7.3 9

This Computer This Computer

Systems Engineering Short Course V2.7.3 10

Loss £x Loss £0 Loss £0

Systems Engineering Short Course V2.7.3 11

 Taguchi applied his concepts to products, we now realise that it

Systems Engineering Short Course V2.7.3 13

Systems Engineering Short Course V2.7.3 14

Systems Engineering Short Course V2.7.3 15

Systems Engineering Short Course V2.7.3 16

What is f? - the relationship between the Y and the Xs – if we know

Variation in the Likely variation

Systems Engineering Short Course V2.7.3 17

When engineering requirements we do not know what “f” is

Systems Engineering Short Course V2.7.3 19

Systems Engineering Short Course V2.7.3 20

Robustness Assessment Function

Systems Engineering Short Course V2.7.3 21

Systems Engineering Short Course V2.7.3 22

Systems Engineering Short Course V2.7.3 23

Input Receiving PURCHASED PURCHASED PURCHASED PLANTS VEGETABLES COMPOST HOME_

Systems Engineering Short Course V2.7.3 24

Systems Engineering Short Course V2.7.3 25

considering functional failure modes,

Systems Engineering Short Course V2.7.3 26

1: No Effect  10: Most Severe

1: Certain to Detect  10: Cannot Detect

Current Employed Method D

Cutter worn 4 None relies on 10 200 Monitor machine usage

STEP 2: For each function identify

STEP 3: For each failure mode identify

STEP 4: For each failure mode

STEP 5: For each failure mode identify

STEP 6: Rate probability of Occurrence,

STEP 7: Determine RPN

STEP 8: Consider high RPN for new

Subsystem: S – Severity of occurrence 1: No Effect ® 10: Most Severe Author: Issue

Element: D – probability of Detection 1: Certain to Detect ® 10: Cannot Detect Checked:

© Burge Hughes Walsh 2005

Define what you understand by Failure?

FMEAs often fail to deliver because people apply their own

In the serious world of engineering we have to be

Systems Engineering Short Course V2.7.3 30

Systems Engineering Short Course V2.7.3 32

Systems Engineering Short Course V2.7.3 33

has HOLDS 2 OR MORE PIECES OF