\nocite{safeware}
\section{Overview of  Symptom Extraction Process}

% TO DO: separate these two:

\paragraph{Symptom Extraction Objective.}
The objective of `symptom abstraction' is to analyse the functional~group and find 
how it can fail
when specified components within it fail.
Once we know how a 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 contains a set of components, the failure~modes
that we have to consider are all the failure modes of its components, as
developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$.
The aim here is to build `test cases', combinations of failure~modes
to use as failure~mode analysis scenarios.
%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 fails given
the test case conditions, for each test case.
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  for all applied/operational states and 
%in the for the case of each  applied states or
environmental conditions that it may be exposed to. In this way all possible
failure mode behaviour due to the test case conditions will be examined.

As part of this analysis process, records must be kept
detailing each test case result along with its resultant 
{\fg} failure mode.
This data will be kept in the model and can be used to
examine environmentally sourced common mode failure scenarios.


%%- 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.
%%- 
%%- 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{Symptom Identification.}
When all `test~cases' have been analysed, a second phase can be actioned. % applied.
%
This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but 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.
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.}
Looking at the functional group perspective failure modes, we can collect 
some of these into common `symptoms'. Some test cases may cause
unique failure modes at the functional group level. These can be termed
lone symptoms.
The common symptoms of failure and lone~symptoms 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
from the components in a functional~group have been handled\footnote{Software can check that all 
failure modes have been included in at least one test case, and modelled individually. For Double
Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}.
Were failure~modes missed, any failure mode model could be dangerously incomplete. 
It is possible here for an automated system to flag unhandled failure modes,
which solves the main failing of top~down methodologies \cite{topdownmiss}, that of not
guaranteeing to model all component failure modes.
\ref{requirement at the start}


\section{The Process}

\paragraph{To analyse a base level Derived~Component/sub-system}

To summarise:

\begin{itemize}
 \item Choose a set of components to form a functional group.
% \item Obtain the list of components in the functional group
 \item Collect the failure modes of each component into a flat set.
 \item Choose all single instances (and optional selected combinations\footnote{
Some specific combinations of failure modes might be included. For instance where
a very reliable part is duplicated but very critical, like the 4 engines on a 747
aircraft.}) of the failure modes to
form `test cases'.
  \item If required, create test cases from all valid double failure mode combinations within the {\fg}.
% \item Draw these as contours on a diagram
% \item Where si,ultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case
 \item Using the `test cases' as scenarios to examine the effects of component failures
we determine the failure~mode behaviour of the functional group. 
This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}.
Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined
for each test case.
 \item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
 \item The common~symptoms are now the fault mode behaviour of the {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail.
 \item A new `derived component' can now be created where each common~symptom, or lone symptom is a failure~mode of this new component.
\end{itemize}



\pagebreak[1]
\section{A theoretical `Derived Component' example}
Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$.

$$ FG = \{ C_1 , C_2 , C_3 \} $$

Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly).
Let us define the following failure modes for each component, defining a function $fm()$ 
that is passed a component and returns the set of failure modes associated with it
\footnote{Base component failure modes are defined, often with 
statistics and environmental factors in  a variety of sources. \cite{mil1991}
}.


\ifthenelse {\boolean{paper}}
{
\subsection{Define Failure mode function $fm$}
}
{
To re-cap from the definitions chapter \ref{chap:definitions}.
}

Let the set of all possible components  be $\mathcal{C}$
and let the set of all possible failure modes be $\mathcal{F}$.

We can define a function $fm$  

\begin{equation}
{fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F}
\end{equation}

defined by (where $C$ is a component and $F$ is a set of failure modes):

$$  fm ( C ) = F $$

%\\
e.g.
%And for this example:

$$ fm(C_1) =  \{ a_1, a_2, a_3 \} $$
$$ fm(C_2) =  \{ b_1, b_2 \} $$ 
$$ fm(C_3) =  \{ c_1, c_2 \} $$

where $a_n,b_n,c_n$ are component failure modes.

\paragraph{Finding all failure modes within the functional group}

For FMMD failure mode analysis, we need to consider the failure modes
from all the components in the functional group as a flat set.
This can be found by applying function $fm$ to all the components
in the functional~group and taking the union of them (where F is the set of all failure modes for all components in the functional group) thus:

$$ F = \bigcup_{j \in \{1...n\}} fm(C_j) $$

We overload the notation for the function $fm$
and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:

\begin{equation}
fm : FG \rightarrow \mathcal{F}
\end{equation}

Applied to the functional~group $FG$ in the example above:
\begin{equation}
 fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}.
\end{equation} 

This can be seen as all the failure modes that can affect the failure mode group $FG$.

\subsection{Analysis of the functional group failure modes}

\label{theoreticalsx}
For this example we shall consider single failure modes.
%For each of the failure modes from $fm(FG)$ we shall
%create a test case ($g_i$). Next each test case is examined/analysed
%and its effect on the functional group determined.

\par
%\vspace{0.3cm}
\begin{table}[h]
\begin{tabular}{||c|c|c|c||} \hline \hline
  {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group}    \\ 
  {\em                        } & {\em          } & {\em failure mode}     & {\em Symptom}                \\ \hline
%
$a\_1$ & $fs\_1$ & $g_{1}$ & SP2     \\      \hline
$a\_2$ & $fs\_2$ & $g_{2}$ & SP1 \\    \hline 
$a\_3$ & $fs\_3$ & $g_{3}$ & SP2\\    \hline  
$b\_1$ & $fs\_4$ & $g_{4}$ & SP1 \\    \hline  
$b\_2$ & $fs\_5$ & $g_{5}$ & SP1 \\     \hline  
$c\_1$ & $fs\_6$ & $g_{6}$ & SP3 \\    \hline  
$c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\    \hline
%
 \hline
\end{tabular}
\caption{Component to functional group to failure symptoms example}
\label{tab:fexsymptoms}
\end{table}
%\vspace{0.3cm}

Table~\ref{tab:fexsymptoms} shows the analysis process.
As we are only looking at single fault possibilities for this example each test case
is represented by one failure mode.
Chosen combinations of component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes.}.
The test cases are analysed w.r.t. the functional~group.
These become functional~group~failure~modes ($g$'s).
The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed.

For the sake of example, let us consider the fault symptoms of the {\fg} $FG$  to be $\{g_2, g_4, g_5\}$ 
As failure modes, these are
identical from the perspective of the functional~group.
That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes
occur, is going to be the same. 
For example, in our CD player example, this could mean the common symptom `no\_sound'.
No matter which component failure modes, or combinations thereof cause the problem, 
the failure symptom is the same. 
It may be of interest to the manufacturers and designers of the CD player why it failed, but 
as far as we, the users, are concerned it has only one symptom, 
`no\_sound'!
We can thus group these component failure modes into a common symptom, $SP1$, thus
$ SP1 = \{g_2, g_4, g_5\}$.
% These can then be joined to form a spider. 
Likewise
let $SP2 = \{g_1, g_3, g_7\}$  be  an identical failure~mode {\em from the perspective of the functional~group}.
Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom},
but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$.

We now have in $SP1$, $SP2$ and $SP3$ the three ways in which this functional~group can fail.
In other words we have derived failure modes for this functional~group.
We can place these in a set of symptoms.
%
$$ SP = \{ SP1, SP2, SP3    \}. $$
%
%
These three symptoms can be considered  the set of failure modes for the functional~group,  if
we treat it as though it were a {\em black box}
or a {\em component} to be used in higher level designs.
%
The next stage of the process could be applied automatically.
Each common symptom becomes a failure mode of 
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.
We can thus apply the function $fm$ on this newly derived component thus:

$$ fm(DC) = \{ SP1, SP2, SP3 \} $$

Note that $g_6$ has \textbf{not disappeared from the analysis process}.
Were the designer to have overlooked this test case, it could appear as a failure mode of the derived component.
i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ could have been $ \{ SP1, SP2, g_6 \}$.
Because the process can be computerised, we can easily flag symptoms that have not been 
included as failure modes in a {\dc}.
% Aw boring ! no jokes ?
% This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}!
%
\ifthenelse {\boolean{paper}}
{
An advantage of a bottom-up process is that failure modes
from base level components cannot be overlooked.
}
{
An advantage of a bottom-up process is that failure modes
from base level components cannot be overlooked.
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{sec:aims}).
}
%
This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component 
with known failure modes 
(although at a higher level of abstraction).
This process can be repeated using {\dcs} to build a 
hierarchical fault~mode model.
The newly derived component $DC$ is available 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}$

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Defining the analysis process \\ as a function}

Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ 
is the set of all derived components, we can define the symptom abstraction process thus:
$$
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent 
\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} .
$$

Given by
$ \bowtie ( FG ) = DC $
as per the example in precedeing section \ref{theoreticalsx}.

\paragraph{Extending $\bowtie$ to {\dcs}}

It is useful to further define the $\bowtie$ function, to
take the failure modes from derived components (as well as base components)
and return a new derived component.
This generalises the function $\bowtie$ and allows us to build
hierarchical failure mode models.

Where a {\fg} is composed of derived components, for sake of example
where $DC_1, DC_2, DC_3 $ are {\dc}s  we could collect these into a {\fg} thus
$FG_{derived} = \{ DC_1, DC_2, DC_3 \}$. 

$DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$ 
$DCFM = fm(FG_{derived})$.

We can apply the symptom abstraction process $\bowtie$
to the {\fg} comprised of derived components
because we can obtain a failure mode set,
(the failure mode set we have named $DCFM$).

Thus we can now move up another abstraction level by applying 
symptom abstraction/extraction to the functional group
$FG_{derived}$ shown in equation \ref{eqn:fgderived}.

\begin{equation}
\label{eqn:fgderived}
 \bowtie ( FG_{derived} ) = DC_{derived} 
\end{equation}


The case 
where a {\fg} has been created from {\dcs} 
using function `$\bowtie$' leads us to
{\dc}s at a higher level of failure mode abstraction.
A notation will be described in the next section
to keep track of the abstraction level of a {\dc}.

%%$$
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent 
%%\bowtie : FG_{derived} \rightarrow DC 
%%$$
%
%\begin{equation}
%  \bowtie(FG_{cfm}) = DC
%\end{equation} 
%
%or applying the function $fm$ to obtain the $FG_{cfm}$ set 
%
%%To put this in context, where FG is a functional group, sourced from base or derived components,
%%we may state the process of 
%%analysing the failure modes in the {\fg} and returning a {\dc} thus:
%%\begin{equation}
%%  \bowtie((FG)) = DC
%%\end{equation}


In other words by analysing a functional group containing derived components,
we have a new derived component as our result. 
This naturally
builds a bottom-up failure mode model and
with each iteration the model becomes more abstract will eventually reach
the SYSTEM level.

%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour.
%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4}

% \begin{figure}[h+]
%  \centering
%  \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg}
%  % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
%  \label{fig:gensubsys3}
%  \caption{Deriving a new diagram}





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
