%%
%%
%% OBSOLETE DO NOT EDIT
%%
%%
%%
\section{The Symptom Extraction Process}

% TO DO: separate these two:

\paragraph{Symptom Extraction Described}

The objective of `symptom extraction' is to analyse the functional~group and find 
how it can fail
when specified components within it fail.
Once we know how functional~group can fail, we can treat it as a component or sub-system
with its own set of failure modes.

\paragraph{FMEA applied to the Functional Group}
As the functional~group is a set of components, the failure~modes
that we have to consider are all the failure modes of its components.
Each failure mode (or combination of) investigated is termed a `test case'.
Each `test case' is analysed.
%
The component failure modes in each test case 
are examined with respect to their effect on the functional~group.
%
The aim of this analysis is to find out how the functional~group reacts
to each of the test case conditions.
The goal of the process is to produce a set of failure modes from the perspective of the functional~group.




\paragraph{Symptom Identification}
When all `test~cases' have been analysed, a second phase is applied.
%
This looks at the results of the `test~cases' as failure modes from the perspective of 
of the {\fg}/sub-system. 
%%Single component failures (or combinations) within the functional~group may cause unique symptoms. 
However, many failures, when looked at from the perspective of the functional group, will have the same `symptoms' (or
in other words the sub-system/{\fg} will fail in the same way for a variety of causes.
These can be collected as `common symptoms'.
To go back to the CD~player example, a failed
output stage, and a failed internal audio amplifier, 
will both cause the same failure; $no\_sound$ !




\paragraph{Collection of Symptoms}
The common symptoms of failure and lone~component failure~modes are identified and collected.
We can now consider the functional~group as a component and the symptoms as its failure modes.
Note  that here because the process is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled.
Were failure~modes missed, any failure mode model could be dangerously incomplete. 
It is possible at this stage for an automated system to flag unhandled failure modes,
which fulfills the wish list in chapter \ref{requirement at the start}, removing
the main drawback with top-down methodologies, that of missing component failure mode
in the model \cite{nancy_crit_fta_top_down}.

