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

.

Browse Source
This commit is contained in:
Robin Clark 2012-05-12 11:48:52 +01:00
parent 87bf343ac0
commit bad6a518b3
2 changed files with 10 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
submission_thesis/CH4_FMMD/copy.tex
View File

@ -175,6 +175,7 @@ To look in detail at half a million fault~scenarios is obviously impractical.
Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
working heuristically. A base component failure will typically
be conceptually removed by several stages from a top level event.
%In electronics terms, all components on the signal path from the component that failed.
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
that must interact to reach the top level event.
Where $C$ represents the set of components in a failure mode causation chain,
@ -212,14 +213,14 @@ a {\bc} {\fm} and not investigate other possibilities, using FMEA or FTA techniq
\paragraph{Software FMEA models are performed separately from Hardware FMEA.}
%If software FMEA or Software FTA is performed it is always performed separately from
%hardware FMEA.
Work on SFMEA (where it is actually performed) does not seek to integrate
Work on SFMEA (which is yet to be widely employed in international standards) does not seek to integrate
hardware and software models, but to perform
FMEA on the software in isolation~\cite{procsfmea}.
Some work has been performed using databases
to track the relationships between variables
and system failure modes~\cite{procsfmeadb}, and work has been performed to
introduce automation into the FMEA process~\cite{appswfmea} and code analysis
automation~\cite{modelsfmea}. Performing these analyses separate breaks the reasoning chain for tracing
automation~\cite{modelsfmea}. Performing these analyses separately breaks the reasoning chain for tracing
failure causation through the software hardware interfaces.
Although the SFMEA and hardware FMEAs are performed separately
@ -1076,7 +1077,11 @@ Derived Component & A theoretical component, created to represent the failure
Unitary State & A component with `unitary~state' failure modes, means that it may cannot fail
with more than one of its failure modes at a time. \\
with more than one of its failure modes at a time.\\ \hline
Failure Scenario & A single failure mode (or a combination), used to
determine failure mode effects on a system or {\fg}.
\\
\hline
\end{tabular}
@ -1784,6 +1789,7 @@ failure modes combinations have been analysed as failure scenarios.
%This AUTOMATIC check can reveal WHEN double checking no longer necessary
%in the hierarchy to cover dub sum !!!!! YESSSS
\section{Conclusion}
%\subsection{Evaluation of FMMD}

2
submission_thesis/CH6_Evaluation/copy.tex
View File

@ -18,7 +18,7 @@ against all the components in the system.
We could term this `rigorous~FMEA'~(RFMEA).
The number of checks we have to make to achieve this, gives an indication of the complexity of the task.
This is described in section~\ref{sec:rd}, where the reasoning distance, or complexity to
analyse a single FMEA failure scenario, is given in equation \ref~{eqn:complexity}.
analyse a single FMEA failure scenario, is given in equation~\ref{eqn:complexity}.
%
We could term this `comparison~complexity', as the number of