AF appendix B comments

This commit is contained in:
Robin Clark 2013-09-18 11:31:29 +01:00
parent d355adb7eb
commit 7358f999d6

View File

@ -26,7 +26,7 @@ The FMMD process is described in chapter~\ref{sec:chap4}.
\item collection of components to form {\fgs},
\item applying FMEA to the {\fgs},
\item collecting common symptoms from the FMEA results,
\item creating a {\dc} representing the failure mode behaviour of the {\fg}.
\item creating a {\dc} modelling the failure mode behaviour of the {\fg}.
\end{itemize}
%
\fmmdgloss
@ -283,10 +283,13 @@ The algorithm, represented by the symbol `$\derivec$', is described using five a
The symptom abstraction process allows us to take a {\fg} of components,
analyse the failure
mode behaviour and create a new entity, a {\dc} that has its own set of failure modes.
%
The checks and constraints applied in the algorithm ensure that all component failure
modes are covered.
%
This process provides the analysis `step' to building a hierarchical failure mode model
from the bottom-up.
%
\fmmdgloss
@ -331,7 +334,9 @@ test cases must next be determined.
%we now need to determine test cases.
%
The test cases are collections of failure modes.
%
These can be formed from single failure modes or failure modes in combination.
%
Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$
be the set of all failure modes.
%(associated with the functional group $FG$).
@ -378,9 +383,9 @@ all failure modes in components in the {\fg} are included in at least one test~c
component failures are investigated
with some specially selected combination faults}
\State { Let $TC$ be the set of test cases }
\State { Let $TC$ be a set of test cases } \Comment {this set is used to collect the test cases}
\State { Let $tc_j$ be a set of component failure modes where $j$ is an index of $J$}
\Comment { Each set $tc_j$ is a `test~case' and $TC = \bigcup_{j \in J} \{tc_j\}$ where $J \in \mathbb{N}_{+}$ }
\Comment { Each set $tc_j$ is a `test~case' and $TC = \bigcup_{j \in J} \{tc_j\}$ where $J \subset \mathbb{N}_{+}$ }
\State { $ TC := \emptyset $ } \Comment{Initialise set of test cases}
\State { $ j := 1 $ } \Comment{Initialise index of test cases}
@ -437,14 +442,14 @@ all failure modes in components in the {\fg} are included in at least one test~c
\State { let $f$ represent a component failure mode }
%\ENSURE { That all failure modes are represented in at least one test case }
\Ensure { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
\Comment { Check that at each single failure mode is
\Comment { Check that at each single failure mode in the {\fg} is
included as a test case.}
%\EndIf
%\If{Double fault checking}
\State { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group }
%\ENSURE { That all failure modes are represented in at least one test case }
\Ensure { $ \forall f1,f2 \;where\; (f1 \wedge f2) \not\in (\forall c) \;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) \wedge ({DoubleFaultChecking} = TRUE)$ }
\Comment { If ${DoubleFaultChecking}$ is required, check that all possible double failure modes (see section~\ref{sec:unitarystate}) are included
\Comment { If ${DoubleFaultChecking}$ is required, check that all possible double failure modes in the {\fg} (see section~\ref{sec:unitarystate}) are included
as a test cases.}
\State \textbf{return} $TC$
\end{algorithmic}
@ -505,6 +510,7 @@ The analysis is primarily a human activity.
Calculations or simulations
are performed to determine how the failure modes in each test case will
affect the functional~group.
%
Ideally field data and/or formal physical testing should be used in addition to static failure mode reasoning
where possible.
%
@ -525,7 +531,9 @@ A set of
results corresponding to our test cases is now available.
%
These share a common index value ($j$ in the algorithm description).
%
These results are the failure modes of the {\fg}.
%
\fmmdgloss
%Once a functional group has been analysed, it can be re-used in
%any other design that uses it.