Robin_PHD/symptom_ex_process/sys_abs.tex

ection{The Symptom abstraction Process}

% TO DO: separate these two:

\paragraph{Symptom Extraction Described}

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 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 symptoms 
of the 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}
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 common 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 here for an automated system to flag unhandled failure modes.
\ref{requirement at the start}

%%%
%%%\section{The Process : To analyse a base level Derived~Component/sub-system}
%%%
%%%To sumarise:
%%%
%%%\begin{itemize}
%%% \item Determine a minimal functional group
%%% \item Obtain the list of components in the functional group
%%% \item Collect the failure modes for each component
%%%% \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 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 Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use.
%%%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 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.
%%%\end{itemize}
%%%
%%%
%%%
%%%
%%%\section{A general derived Component/Sub-System 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 evironmental factors in  a variety of sources. \cite{mil1991}
%%%}.
%%%
%%%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} \mapsto \mathcal{P}\mathcal{F}
%%%\end{equation}
%%%
%%%defined by (where $C$ is a component and $F$ is a set of failure modes):
%%%
%%%$$  FM ( C ) = F $$
%%%
%%%%\\
%%%
%%%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 \} $$
%%%
%%%
%%%\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 thus:
%%%
%%%$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$
%%%
%%%We can actually 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 \mapsto \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}
%%%
%%%For this example we shall consider single failure modes.
%%%%For each of the failure modes from $FM(FG)$ we shall
%%%%create a test case ($fgfm_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$ & $fgfm_{1}$ & SP2     \\      \hline
%%%$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\    \hline 
%%%$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\    \hline  
%%%$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\    \hline  
%%%$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\     \hline  
%%%$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\    \hline  
%%%$c\_2$ & $fs\_7$ & $fgfm_{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 failure mode
%%%is represented by a test~case.
%%%The 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 ($fgfm$'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 $\{fgfm_2, fgfm_4, fgfm_5\}$  to be 
%%%identical from the perspective of the functional~group.
%%%That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_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 = \{fgfm_2, fgfm_4, fgfm_5\}$.
%%%% These can then be joined to form a spider. 
%%%Likewise
%%%let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$  be  an identical failure mode {\em from the perspective of the functional~group}.
%%%Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}.
%%%
%%%
%%%We have now in $SP1$, $SP2$ and $fgfm_6$ as 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$.
%%%%
%%%$$ SP = \{ SP1, SP2, fgfm_6 \} $$
%%%%
%%%%
%%%These three symptoms can be considered  the set of failure modes for the functional~group,  and
%%%we can 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, fgfm_6 \} $$
%%%
%%%Note that $fgfm_6$, while  %being a failure mode has 
%%%not being grouped as a common symptom
%%%has \textbf{not dissappeared from the analysis process}.
%%%Were the designer to have overlooked this test case, it would appear in the derived component.
%%%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!}!
%%%The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
%%%
%%%
%%%\subsection{Defining the analysis process as a function}
%%%
%%%It is useful to define this analysis process as a function.
%%%Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now
%%%write 
%%%
%%%$$
%%%\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent 
%%%$$
%%%%
%%%%\begin{equation}
%%%%  \bowtie(FG_{cfm}) = DC
%%%%\end{equation} 
%%%%
%%%%or applying the function $FM$ to obtain the $FG_{cfm}$ set 
%%%%
%%%Where DC is a derived component, and FG is a functional group:
%%%
%%%\begin{equation}
%%%  \bowtie(FM(FG)) = DC
%%%\end{equation}
%%%
%%%
%%%%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}
%%%
%%%
%%%This sub-system or derived~component $DC$ , with its three error modes, can now be treated as a component (although at a higher level of abstraction)
%%%with known failure modes. 
%%%This process can be repeated using derived~components to build a 
%%%hierarchical 
%%%fault~mode 
%%%model.
%%%
%%%
%%%
%%%
%%%