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

after talk with Andrew Fish 30JUL2010

Browse Source
This commit is contained in:
Robin 2010-08-01 16:41:15 +01:00
parent 24f0ce0b65
commit 35a08f62e8
4 changed files with 128 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

145
symptom_ex_process/algorithm.tex
View File

@ -18,34 +18,62 @@ than the functional~group it was derived from.
However, it can still be treated However, it can still be treated
as a component with a known set of failure modes. as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels} \paragraph{Enumerating abstraction levels}
If $DC$ were to be included in a functional~group, We can assign an attribute of abstraction level to
that functional~group must be considered to be at a higher level of components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathcal{N}$).
abstraction than a base level functional~group. For a base component let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$
the reulting derived~component will have an $\alpha$ value
one higher that the highest $\alpha$ value of any of the components
in the functional group used to derive it.
Thus a derived component sourced from base components
will have an $\alpha$ value of 1.
% %
In fact, if the abstraction level is enumerated, %If $DC$ were to be included in a functional~group,
the functional~group must take the abstraction level %that functional~group must be considered to be at a higher level of
of the highest assigned to any of its components. %abstraction than a base level functional~group.
% %
$DC$ can be used as a system building block at a higher %In fact, if the abstraction level is enumerated,
level of fault abstraction. Because derived components %the functional~group must take the abstraction level
are collected to form functional groups, a converging hierarchy is %of the highest assigned to any of its components.
%
With a derived component $DC$ having an abstraction level
attribute $\alpha$ we can use this to track the
level of fault abstraction through a hierarchy. Because base and derived components
are collected to form functional groups, a hierarchy is
naturally formed with the abstraction level increasing with each tier. naturally formed with the abstraction level increasing with each tier.
The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other. %\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
% \IF{$c.\alpha > \alpha_{max}$}
% $\alpha_{max} = c.\alpha$
% \ENDIF
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
%\ENDFOR
The algorithm, representing the function $\bowtie$, has been broken down into five consecutive stages.
These are described using the Algorithm environment in the next section \ref{algorithms}. These are described using the Algorithm environment in the next section \ref{algorithms}.
By defining the process and describing it using set theory, constraints and By defining the process and describing it using set theory, constraints and
verification checks in the process can be stated formally. verification checks in the process can be stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine} \subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine}
The first stage is to find the failure modes to consider for The first stage is to find the failure modes to consider for
analysis. analysis.
Let $FG$ be the set of components in the functional group under analysis, and $c$ From the earlier definition of the function `FM':
be components that are members of it. This function returns a flat set of failure modes $F$.
$$ FM: \mathcal{FG} \mapsto \mathcal{F}$$ The function $FM$ applied to a component returns the failure modes for that component.
The function $FM$ takes a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$.
$$ FM: \mathcal{FG} \rightarrow \mathcal{F}$$
%Let $FG$ be the set of components in the functional group under analysis, and $c$
%be components that are members of it. This function returns a flat set of failure modes $F$.
given by
$$FM(FG) = F$$
%% %%
%% Algorithm 1 %% Algorithm 1
%% %%
@ -54,31 +82,33 @@ $$ FM: \mathcal{FG} \mapsto \mathcal{F}$$
~\label{alg:sympabs1} ~\label{alg:sympabs1}
\caption{FM( $FG$ )} \label{alg:sympabs11} \caption{FM( $FG$ )} \label{alg:sympabs11}
\begin{algorithmic}[1] \begin{algorithmic}[1]
\REQUIRE {FG is a set of components} \REQUIRE {FG is a set of components (a functional~group)}
\STATE { Let $FG$ be a set of components } \COMMENT{ The functional group should be chosen to be minimally sized collections of components that perform a specific function} \STATE { Let $FG$ be a set of components } \COMMENT{ The functional group should be chosen to be minimally sized collections of components that perform a specific function}
\STATE { Let $c$ represent a component}
\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG | FM(c) \neq \emptyset$ } \FORALL { $c \in FG $ }
\REQUIRE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; such \; that\; FM(c) \neq \emptyset$ }
\ENDFOR
\STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$} \STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$}
%\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$}
%\FORALL { $c \in FG $ }
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
%\ENDFOR
\RETURN { $F$ } \RETURN { $F$ }
%\hline %\hline
%
\end{algorithmic} \end{algorithmic}
\end{algorithm} \end{algorithm}
Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ where each component has a known set of failure~modes. Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$
The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used (given that each component has a known set of failure~modes).
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used
in the analysis stages. in the analysis stages.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases} \subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases}
@ -86,10 +116,14 @@ From the failure modes associated with the functional~group
we now need to determine test cases. we now need to determine test cases.
The test cases are collections of failure modes. The test cases are collections of failure modes.
These could be formed from single failure modes or failure modes in combination. These could be formed from single failure modes or failure modes in combination.
Let $TC$ be the set of test cases associated withthe functional group $FG$. Let $TC$ be the set of test cases associated with the functional group $FG$.
$$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$ $$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$
given by
$$ DTC(F) = TC $$
%% %%
%% Algorithm 2 %% Algorithm 2
%% %%
@ -109,25 +143,37 @@ $$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$
\STATE { Let $TC$ be a set of test cases } \STATE { Let $TC$ be a set of test cases }
\STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$} \STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$}
\COMMENT { Each set $tc_j$ is a `test case' } \COMMENT { Each set $tc_j$ is a `test case' }
\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique} %\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique}
\FORALL { $tc_j \in TC$ } \FORALL { $tc_j \in TC$ }
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
\ENSURE {$ tc_j \in \mathcal{P}(F))$} \ENSURE {$ tc_j \in \mathcal{P}(F))$}
\COMMENT { require that the test case is a member of the powerset of $F$ } \COMMENT { require that the test case is a member of the powerset of $F$ }
\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $} %\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
\ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $}
\COMMENT { Test cases must be unique } \COMMENT { Test cases must be unique }
\ENDFOR \ENDFOR
\IF{Single fault checking}
\STATE { let $f$ represet a component failure mode } \STATE { let $f$ represet a component failure mode }
\ENSURE { That all failure modes are represented in at least one test case } %\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f | (f \in F)) \wedge (f \in \bigcup TC) $ } \ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
\COMMENT { This corresponds to checking that at least each failure mode is considered at \COMMENT { This corresponds to checking that at least each failure mode is considered at
least once in the analysis; more rigorous cardinality constraint least once in the analysis; more rigorous cardinality constraint
checks may be required for some safety standards} checks may be required for some safety standards}
\ENDIF
\IF{Double fault checking}
\STATE { let $f1,f2$ represet a component failure modes }
%\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f1,f2 \;where\; \not(f1,f2) \in c\;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
\COMMENT { This corresponds to checking that at least each possible double failure mode is considered at
least once in the analysis; more rigorous cardinality constraint
checks may be required for some safety standards. Not if both failure modes
in the check are sourced from the same component $c$ the test case is impossible
under unitary state failure mode conditions}
\ENDIF
\RETURN $TC$ \RETURN $TC$
% some european standards % some european standards
@ -144,13 +190,17 @@ The next stage is to analyse the effect of each test case on the functional grou
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases} \subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases}
%% %%
%% Algorithm 3 %% Algorithm 3
%% %%
The test cases are now analysed for their impact on the behaviour of the functional~group. The test cases are now analysed for their impact on the behaviour of the functional~group.
Let $R$ be a set of results indexed by $j$ (the same index used to identify the test cases $tc_{j}$). Let $R$ be a set of test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
$$ATC: \mathcal{TC} \mapsto \mathcal{R} $$ $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
@ -163,7 +213,8 @@ $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
\STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$} \STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$}
\FORALL { $tc_j \in TC$ } \FORALL { $tc_j \in TC$ }
\STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group} \STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group}
\STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R} %\STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R}
\STATE{ $ R := R \cap rc_j $ } \COMMENT{Add $rc_j$ to the set R}
\ENDFOR \ENDFOR
\RETURN $R$ \RETURN $R$
@ -174,6 +225,9 @@ $$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms} \subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms}
%% %%
@ -210,8 +264,7 @@ $$FCS: \mathcal{R} \mapsto \mathcal{SP} $$
causes in the functional group $FG$} causes in the functional group $FG$}
%\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $} %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $}
\REQUIRE {$ \forall a \in sp_l | \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$} \ENSURE {$ \forall a \in sp_l \;such\;that\; \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$}
\COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set } \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set }
\ENDFOR \ENDFOR
@ -231,6 +284,9 @@ We now have a set $SP$ of the symptoms of failure.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component} \subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component}
%% %%
@ -252,7 +308,9 @@ $$ CDC: \mathcal{SP} \mapsto \mathcal{DC} $$
\STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ } \STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ }
\FORALL { $sp_l \in SP$ } \FORALL { $sp_l \in SP$ }
\STATE { $ f_l = ConvertToFaultMode(sp_l) $} \STATE { $ f_l = ConvertToFaultMode(sp_l) $}
\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes} %\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
\STATE { $DC := DC \cap f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
\ENDFOR \ENDFOR
\RETURN DC \RETURN DC
%\hline %\hline
@ -276,11 +334,11 @@ $$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$
\begin{algorithmic}[1] \begin{algorithmic}[1]
\STATE {F = FM (FG)} \STATE {F = FM (FG)} \COMMENT{ collect all the failure modes from the from the components in the functional~group }
\STATE {TC = DTC (F)} \STATE {TC = DTC (F)} \COMMENT{ determine all test cases to apply to the functional group }
\STATE {R = ATC (TC)} \STATE {R = ATC (TC)} \COMMENT{ analyse the test cases, for failure mode behaviour of the functional~group }
\STATE {SP = FCS (R)} \STATE {SP = FCS (R)} \COMMENT{ find common symptoms of failure for the functional group }
\STATE {DC = CDC (SP)} \STATE {DC = CDC (SP)} \COMMENT{ create a derived component }
\RETURN $DC$ \RETURN $DC$
@ -299,7 +357,8 @@ from the bottom-up.
Because symptom abstraction collects fault modes, the number of faults to handle decreases Because symptom abstraction collects fault modes, the number of faults to handle decreases
as the hierarchy progresses upwards. as the hierarchy progresses upwards.
This is seen by casual observation of real life Systems. At the highest levels the number of faults %This is seen by casual observation of real life Systems. NEED A GOOD REF HERE
At the highest levels the number of faults
is significantly less than the sum of its component failure modes. is significantly less than the sum of its component failure modes.
A Sound system might have, for instance only four faults at its highest or System level, A Sound system might have, for instance only four faults at its highest or System level,
\small \small

2
symptom_ex_process/fmmd.tex
View File

@ -2,7 +2,7 @@
% Describe FMMD % Describe FMMD
\section{Background: FMMD outline} \section{Background:\\ FMMD outline}
The symptom abstraction process described here, is a core process in the The symptom abstraction process described here, is a core process in the
%Failure Mode Modular De-Composition %Failure Mode Modular De-Composition
FMMD modelling technique. FMMD builds a hierarchy of failure mode behaviours from the bottom up. FMMD modelling technique. FMMD builds a hierarchy of failure mode behaviours from the bottom up.

28
symptom_ex_process/process.tex
View File

@ -57,16 +57,17 @@ It is possible here for an automated system to flag unhandled failure modes.
To sumarise: To sumarise:
\begin{itemize} \begin{itemize}
\item Determine a minimal functional group \item Choose a set of components to form a functional group.
\item Obtain the list of components in the functional group % \item Obtain the list of components in the functional group
\item Collect the failure modes for each component \item Collect the failure modes of each component into a flat set.
\item Choose all single instances and selected combinations of the failure modes to
form `test cases'.
% \item Draw these as contours on a diagram % \item Draw these as contours on a diagram
% \item Where si,ultaneous failures are examined use overlapping contours % \item Where si,ultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case % \item For each region on the diagram, make a test case
\item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group \item Using the `test cases' determine their effects on the failure~mode behaviour of the functional group.
\item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. \item Collect common~symptoms. i.e. determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider'). \item The common~symptoms are now the fault mode behaviour of the functional~group.
\item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component.
\item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component.
\end{itemize} \end{itemize}
@ -94,7 +95,7 @@ and let the set of all possible failure modes be $\mathcal{F}$.
We can define a function $FM$ We can define a function $FM$
\begin{equation} \begin{equation}
\mathcal{FM} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} {FM} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F}
\end{equation} \end{equation}
defined by (where $C$ is a component and $F$ is a set of failure modes): defined by (where $C$ is a component and $F$ is a set of failure modes):
@ -205,9 +206,9 @@ a newly created derived component. Let $DC$ be the newly derived component.
This is assigned the failure modes that were derived from the functional~group. This is assigned the failure modes that were derived from the functional~group.
We can thus apply the function $FM$ on this newly derived component thus: We can thus apply the function $FM$ on this newly derived component thus:
$$ FM(DC) = \{ SP1, SP2, SP3 \} $$ $$ FM(DC) = \{ SP1, SP2, SP3 \} $$
Note that $g_6$, while %being a failure mode has Note that $g_6$ %, %while %being a failure mode has
% not being grouped as a common symptom % not being grouped as a common symptom
has \textbf{not dissappeared from the analysis process}. has \textbf{not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component. Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component.
@ -217,6 +218,7 @@ The process must not allow failure modes to be ignored or forgotten (see project
The newly derived compoennt $DC$ is availble for use to form higher level functional groups, and we can thus The newly derived compoennt $DC$ is availble for use to form higher level functional groups, and we can thus
consider DC as being in the set of components i.e. $DC \in \mathcal{C}$ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Defining the analysis process as a function} \subsection{Defining the analysis process as a function}
@ -259,3 +261,9 @@ hierarchical
fault~mode fault~mode
model. model.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %

12
symptom_ex_process/topbot.tex
View File

@ -1,5 +1,5 @@
\section{Fault Finding and Failure Mode Analysis} \section{Fault Finding \\ and Failure Mode Analysis}
\subsection{Static Analysis} \subsection{Static Analysis}
@ -21,7 +21,7 @@ can be derived.
FMMD can model electrical, mechanical and software using a common notation, FMMD can model electrical, mechanical and software using a common notation,
and can thus model an entire electro mechanical software controlled system. and can thus model an entire electro mechanical software controlled system.
\subsection{Top Down or natural trouble shooting} \subsection{Top Down or \\ natural trouble shooting}
It is interesting here to look at the `natural' trouble shooting process. It is interesting here to look at the `natural' trouble shooting process.
Fault finding is intinctively performed from the top-down. Fault finding is intinctively performed from the top-down.
A faulty piece of equipment is examined and will have a A faulty piece of equipment is examined and will have a
@ -173,7 +173,8 @@ System & A product designed to \\
Sub-system & A part of a system, \\ Sub-system & A part of a system, \\
-or- derived component & sub-systems may contain sub-systems. \\ -or- derived component & sub-systems may contain sub-systems. \\
& derived~components may by derived \\ & derived~components may by derived \\
& from derived components \\ \hline & from derived components \\
& Constraint: This object must have a defined set of failure~modes \\ \hline
Failure mode & A way in which a System, \\ Failure mode & A way in which a System, \\
& Sub-system or component can fail \\ \hline & Sub-system or component can fail \\ \hline
Functional Group & A collection of sub-systems and/or \\ Functional Group & A collection of sub-systems and/or \\
@ -181,8 +182,9 @@ Functional Group & A collection of sub-systems and/or \\
& perform a specific function \\ \hline & perform a specific function \\ \hline
Symptom & A failure mode of a functional group, caused by \\ Symptom & A failure mode of a functional group, caused by \\
& a combination of its component failure modes \\ \hline & a combination of its component failure modes \\ \hline
Base Component & Any bought in component, which \\ Base Component & Any bought in component, or \\
& hopefully has a known set of failure modes \\ \hline & lowest level module/or part \\
& Constraint: This object must have a defined set of failure~modes \\ \hline
\hline \hline
\end{tabular} \end{tabular}
\caption{Symptom Extraction Definitions} \caption{Symptom Extraction Definitions}