robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tidy

Browse Source
This commit is contained in:
Robin Clark 2013-04-01 09:59:09 +01:00
parent 5d8eb97000
commit 31e58f77e5
2 changed files with 11 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
submission_thesis/CH2_FMEA/copy.tex
View File

@ -1290,8 +1290,15 @@ failure symptoms of a system.
FMEDA classifies them as dangerous or safe failures. FMEDA classifies them as dangerous or safe failures.
FMECA gives us a statistically biased criticality level. FMECA gives us a statistically biased criticality level.
In both of these methodologies however, there is no formal stage where we map from an objective to subjective In both of these methodologies however, there is no formal stage where we map from an objective to subjective
system failure, the processes are intertwined with the basic analysis its self. system failure, the processes are intertwined with the basic analysis itself.
\paragraph{Re-use potential of an FMEA report.}
Each {\fm} entry in an FMEA report should have a reasoning or comments field.
This should provide a guide to someone re-examining, or trying to re-use results
on a similar project.
However, as with the compnents that we should check against a {\fm}, there are no guidelines for documenting
the reasoning stages for an FMEA entry.
%FMEA does not stipulat which %FMEA does not stipulat which

5
submission_thesis/CH3_FMEA_criticism/copy.tex
View File

@ -4,7 +4,7 @@
This chapter examines FMEA in a critical light. This chapter examines FMEA in a critical light.
The problems with the scope---or required reasoning distance---of detail to apply The problems with the scope---or required reasoning distance---of detail to apply
for FMEA analysis are examined. The impossibility of integrating software for FMEA analysis, the difficulties of integrating software
and hardware in FMEA failure models, and the impossibility of performing meaningful and hardware in FMEA failure models, and the impossibility of performing meaningful
multiple failure analysis are examined. multiple failure analysis are examined.
Additional problems such as the inability to easily re-use, and validate (through Additional problems such as the inability to easily re-use, and validate (through
@ -12,7 +12,7 @@ traceable reasoning) FMEA models is presented.
Finally we conclude with a list of deficiencies in current FMEA methodologies, and present a wish list Finally we conclude with a list of deficiencies in current FMEA methodologies, and present a wish list
for an improved methodology. for an improved methodology.
\section{Historical Origins of FMEA} \section{Historical Origins of FMEA: {\bc} {\fm} to system level failure/symptom paradigm}
\subsection{FMEA: {\bc} {\fm} to system level failure modelling} \subsection{FMEA: {\bc} {\fm} to system level failure modelling}
FMEA traces it roots to the 1940s when it was used to identify the most costly FMEA traces it roots to the 1940s when it was used to identify the most costly
@ -20,6 +20,7 @@ failures arising from car mass-production~\cite{bfmea}.
It was later modified slightly to include severity of the top level failure (FMECA~\cite{fmeca}). It was later modified slightly to include severity of the top level failure (FMECA~\cite{fmeca}).
In the 1980s FMEA was extended again (FMEDA~\cite{fmeda}) to provide statistics In the 1980s FMEA was extended again (FMEDA~\cite{fmeda}) to provide statistics
for predicting failure rates. for predicting failure rates.
%
However a typical entry in each of the above methodologies, starts with a However a typical entry in each of the above methodologies, starts with a
particular component failure mode and associates it with a system---or top level---failure symptom. particular component failure mode and associates it with a system---or top level---failure symptom.
This means that we have one analysis case per component failure mode for all the components in the system under investigation. This means that we have one analysis case per component failure mode for all the components in the system under investigation.