From bad6a518b350dc88ff396cb89c57f395d35121ee Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 12 May 2012 11:48:52 +0100 Subject: [PATCH] . --- submission_thesis/CH4_FMMD/copy.tex | 12 +++++++++--- submission_thesis/CH6_Evaluation/copy.tex | 2 +- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index eb55035..168021e 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -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} diff --git a/submission_thesis/CH6_Evaluation/copy.tex b/submission_thesis/CH6_Evaluation/copy.tex index 165f047..2149b6c 100644 --- a/submission_thesis/CH6_Evaluation/copy.tex +++ b/submission_thesis/CH6_Evaluation/copy.tex @@ -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