%%
%%
%% OBSOLETE DO NOT EDIT
%%
%%
%%

%  
%     ________________,------.
%    /_|_____||____|__|    | |           ___________
%                     `,---,-'    __,---'           `---.__
%                     /   /  __,--'---._______________.---'
%                ____/   /--'___________.-'
%                `-./___/______________/
%                          `---------'
%  
%       .-.                             .-.
%      (   )        ___________        (   )
%       `-' __,----'    \v/    `----.__ `-'
%         \\'----._______________.----'//
%          \\________.-'/|\`-.________//
%           `=====<___   @   __>======'
%                     `-----'
%  
%     ________________,------.
%    (_)_____||____|__|    | |
%                     `,---,-'            _.-----._
%                     /___/            ,-'    |    `-.
%                    /    `-._       ,'       |       `.
%                    |        `-._  / `.      |      ,' \
%                   /             `/    `.    |    ,'_   \
%                   |__           |       `. .-. ,' /__   |
%                   |__|--O------<|-------- (   ) --|__>--|
%                   |             |       ,' `-' `. \_    |
%                   \            _,\    ,'    |    `.    /
%                    |       _,-'   \ ,'      |      `. /
%                    \___\,-'        `.       |       ,'
%                     \   \            `-._   |   _.-'
%     ________________,`---`-.             `-----'
%    (_)_____||____|__|    | |
%  
\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{Environmental Conditions or Applied States}

Each test case must be considered in the light of any operational states or
environmental conditions that it may be exposed to.

\paragraph{Electronics}
A {\fg} may, in the case of an electronic circuit have 
applied states. For instance test modes, shutdown or lockout modes etc.
which are inputs to the circuit.
In this case each test case from the {\fg} must be analysed with
respect to all these states.

\paragraph{Mechanical}
A mechanical device may be required to work in different 
temperature or pressure ranges for instance and its failure mode behaviour may 
change due to enviromental factors.

\paragraph{Software}
A software function may have an applied state, where it must modify 
its general behaviour.
For instance some states in an embedded real time system
may require special error or emergency handling behaviour.
This could be in the form of global variable which could indicate a system condition
such as NORMAL\_OPERATION, GRACEFUL\_DEGRADATION \cite{en61508}[SECTION XX] LOCKOUT or SHUTDOWN
for instance.

\subsection{Symptom Identification / collection}
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}.