Robin_PHD/symptom_abstraction/symptom_abstraction.tex

\ifthenelse {\boolean{paper}}
{
\begin{abstract}
In modular systems design, it is often very useful to
know the failure modes of the sub-systems used.
This paper outlines a technique for determining the failure modes of a sub-system given 
its component parts.
%, and the failure modes of those parts.


The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint
diagrams\cite{constraint} to model failure modes and failure mode common symptom collection.
The technique is designed for making building blocks for a hierarchical fault model.

Once the failure modes have been determined for a sub-system,
that sub-system may be treated as a  `component' or `black box' and used 
in conjunction with other such analysed sub-systems, to model 
higher level sub-systems. In this way a hierarchy to represent the fault behaviour
of a system can be built.


%FMMD hierarchy
The hierarchy is built from the bottom up.
Starting with component failure modes at the bottom.
Because the process is bottom-up, syntax checking and tracking can ensure that
no component failure mode can be overlooked.
Once a hierarchy is in place it can be converted into a fault data model.

From the fault data model, automatic generation
of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} are possible. 
Also statistical reliability\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced 
automatically, where component failure mode statistics are available\cite{mil1991}.

This paper focuses on the process of building the blocks that are used in the hierarchy.

\end{abstract}
}
{}
%\clearpage

\section{Introduction}

Fault finding is intinctively performed from the top-down.
A faulty piece of equipment is examined and will have a 
symptom or specific fault. The area or sub-system within the 
equipemnt will next be looked into. Secific measurements
and checks will be made, and finally a component or a low level sub-system
will be found to be faulty.
The technique here works the other way. It works from the bottom up.
Starting with a collection of compoents that form
a simple functional group, the effect of all component error modes are
examined, as to their effect on the functional group.
The effects on the functional group can then be collected as common symptoms,
and now we may treat the functional group as a component. It has a known set of failure modes.
By working from the bottom up, we can trace all possible sources
that could cause a particular mode of equipment failure.
This means that we can obtainm statistical estimates based on the known reliabilities
of the components.
It also means that every component failure mode must at the very least be considered.

\subsection{Static Analysis}

In the field of safety critical engineering; to comply with 
European Law a product must be certified under the approriate `EN' standard.
Typically environmental stress, EMC, electrical stressing, endurance tests, 
software~inspections and project~management quality reviews are applied\cite{sccs}.

Static testing is also applied. This is theoretical analysis of the design of the product from the safety 
perspective.
Three main techniques are currenly used,
Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
The technique outlined here aims to provide a mathematical frame work
to assist in the production of these three results of static analysis.

{
The aims are
\begin{itemize}
 \item To automate the process where possible
 \item To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups)
 \item To use a modular approach so that analysed sub-systems can be re-used 
 \item Automatically ensure no failure mode is unhandled
 \item To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically
\end{itemize}
}


\subsection{Systems, functional groups, sub-systems and failure modes}

It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `sub-system'.

A System, is really any coherent entity that would be sold as a safety critical product.
A sub-system is a system that is part of some larger system.
For instance a stereo amplifier separate is a sub-system. The 
whole Sound System, consists perhaps of the following `sub-systems': 
CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
 
%Thinking like this is a top~down analysis approach
%and is the way in which FTA\cite{nucfta} analyses a System
%and breaks it down.

A sub-system will be composed of component parts, which
may themselves be sub-systems. However each `component part'
will have a fault/failure behaviour and it should
always be possible to obtain a set of failure modes
for each `component'. 

If we look at the sound system again as an
example; the CD~player could fail in serveral distinct ways, no matter
what has happened to it or has gone wrong inside it.


Using the reasoning that working from the bottom up forces the consideration of all possible
component failures (which can be missed in a top~down approach)
we are presented with a problem. Which initial collections of base components should we choose ?

For instance in the CD~player example; to start at the bottom; we are presented with
a massive list of base~components, resistors, motors, user~switches, laser~diodes all sorts !
Clearly, working from the bottom~up we need to pick small
collections of components that work together in some way.
These are termed `functional~groups'. For instance the  circuitry that powers the laser diode
to illuminate the CD might contain a handful of components, and as such would make a good candidate
to be one of the base level functional~groups.


In choosing the lowest level (base component) sub-systems we would look 
for the smallest `functional~groups' of components within a system. A functional~group is a set of components that interact
to perform a specific function.

When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'.
We can now call our functional~group a sub-system. The goal here is to  know how will behave under fault conditions !
%Imagine buying one such `sub~system'  from a very honest vendor.
%One of those sir, yes but be warned it may fail in these distinct ways, here
%in the honest data sheet the set of failure modes is listed!
This type of thinking is starting to become more commonplace in product literature, with the emergence
of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}.
FIT (Failure in Time - expected number of failures per billion hours of operation) values
are published for some micro-controllers. A micro~controller
is a complex sub-system in its self and could be considered a `black~box' with a given reliability.
\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD
1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component}

As electrical components have detailed datasheets a useful extension of this would
be failure modes of the component, with environmental factors and MTTF statistics.

Currently this sort of information is generally only  available for generic component types\cite{mil1991}.

 
%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to
%erform a given function.

\vspace{0.3cm}
%\begin{table}[p]
\begin{tabular}{||l|l||} \hline \hline
  {\em Definition } & {\em Description}    \\ \hline
System & A product designed to  \\
       & work as a coherent entity  \\  \hline   
Sub-system & A part of a system, \\
           & sub-systems may contain sub-systems \\    \hline 
Failure mode & A way in which a System, \\
             & Sub-system or component can fail \\     \hline  
Functional Group & A collection of sub-systems and/or \\
                 & components that interact to \\
                 & perform a specific function  \\    \hline  
Base Component & Any bought in component, which \\
               & hopefully has a known set of failure modes  \\    \hline  
 \hline
\end{tabular}
%\end{table}
\vspace{0.3cm}


\section{The Symptom abstraction Process}

% TO DO: separate these two:

\paragraph{symptom abstraction described}

The objective of `symptom abstraction' is to analyse the functional~group and find out what will happen to it,
when specified component failure modes occur.
Once we know how it fails as a functional~group, we can treat it as a component or sub-system
with its own set of failure modes.

Each failure mode (or combination of) investigated is termed a `test case'.
Each `test case' is analysed. 
The component failure modes are examined with respect to their effect on the functional~group.
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.
 In this way `test~case~results' are grouped as common symptoms, from the perspective of the sub-system.
 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{symptom abstraction represented on the diagram}
This process can be applied using a diagram.
From the collection of parts for the sub-system under analysis, a set of failure
modes for each component is obtained. A diagram is then drawn with
each component failure mode represented by a contour.
Component failure mode combinations are
chosen for `test cases'.\footnote{Combinations of component failure modes can be represented by overlapping contours}

A `test case' is represented on the diagram as a point or asterisk, 
in a region enclosed by the contours representing the failure modes it investigates.

The effect on the sub-system of each test case is analysed.
%It is then represented on the diagram by an asterisk on the contour representing the failure mode.
The `test~case~results' are archived.
When all test cases have been analysed, we switch our attention to a higher abstraction level.
% We treat the sub-system as a black box, or as a component part itsself.
% We can now look at the test case results from the perspective of a `user'
% of this sub-system.
% 
% 
% We treat the sub-system as a `black box' and view the effects of the component failure
% at the sub-system level. This mean we are not interested so much in what the compoent does,
% but how the sub-system reacts when it fails in a certain way.
% 
% Each `test case' is labelled from the perspective of the failure as seen at sub-system level.

% 
We can now try to simplfy by determining common symptoms.
A common symptom, in this context, is defined as faults caused by different  
component failure modes that have the same effect from the perspective
of a `user' of the sub-system.

Test case results can now viewed as failure modes of the sub-sytem or `black box', and grouped together
where there are common symptoms. 
These are grouped together by joining them with lines. These lines form  collected groups (or `spiders').
See figure \ref{fig:gensubsys3}.
% 
It can be seen now that each {\em lone test case} and {\em spider} on the 
diagram is a distinct failure mode of the sub-system.
This means that these failure modes represent the fault behaviour of the sub-system.
We can now treat this sub-system as a component in its own right, or in other words,
we have derived a failure mode model at a higher level of abstraction.

We can now draw a new diagram to represent the failure modes of the sub-system.
Each spider or lone test case, becomes a contour representing a failure mode
of the sub-system in this new diagram (see figure \ref{fig:gensubsys4}.



\section{The Process : To analyse a base level sub-system}

To sumarise:

\begin{itemize}
 \item Determine a minimal functional group
 \item Obtain 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 multiple failures are examined use overlapping contours
 \item For each region on the diagram, make a test case
 \item Examine each test case and determine the effect of the component failure modes on the 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. Join common symptoms with lines connecting them (sometimes termed a `spider').
 \item The lone test cases and the spiders are now the fault mode behaviour of the sub-system. 
 \item A new diagram can now be drawn where each spider, or lone test case from the original diagram
is represented as a contour. These contours represent the failure modes of the sub-system.
\end{itemize}




\section{A general Sub-System example}

Consider a functional group $FG$ with component parts $A$,$B$ and $C$.
Each part 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 part, defining a function $FM()$ where $K$
is a component part and $F$ is its set of failure modes\footnote{Base component failure modes are defined, often with 
statistics and evironmental factors in  a variety of sources. \cite{mil1991}
}.

$$ 
FM : K  \mapsto F
$$
\\
For our example above
\\
$$ FM(A) =  \{ a_1, a_2, a_3 \} $$
$$ FM(B) =  \{ b_1, b_2 \} $$ 
$$ FM(C) =  \{ c_1, c_2 \} $$

We can now represent the sub-system as a set of component faulure modes $FG_{cfm}$,
thus 

\begin{equation}
 FG_{cfm} = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}
\end{equation} 




The failure modes of the components can be represented as contours on
on the diagram in \ref{fig:gensubsys1}.
\begin{figure}
 \centering
 \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/synmptom_abstraction.jpg}
 % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
\label{fig:gensubsys1}
 \caption{$FG_{cfm}$ Component Failure modes represented as contours}
\end{figure}

% % DIAGRAM WITH SPIDER
% \begin{figure}
%  \centering
%  \includegraphics[scale=20]{./synmptom_abstraction.jpg}
%  % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
%  \label{fig:gensubsys2}
%  \caption{$SS_{cfm}$ Component Failure modes represented as contours}
% \end{figure}


We can now look at the effects that  component failure modes have 
on the sub-system.
This process involves examining `test cases'. Each `test case' represents the fault behaviour
of the sub-system due to particular combinations of component fault modes.

Each test case can be represented on the diagram as a labeled point.
The labeled point will reside in a region on the diagram
enclosed by the contours representing particular component fault modes.
The label will indicate the fault symptom from the perspective of the sub-system.
For the sake of example, only single component failure modes are considered.
We can now assign a test~case to each contour, and mark it on the diagram.

% \begin{figure}[h+]
%  \centering
%  \includegraphics[scale=20]{./symptom_abstraction2.jpg}
%  % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
%  \label{fig:gensubsys2}
%  \caption{Component Failure modes with analysed test cases}
% \end{figure}
\begin{figure}
 \centering
 \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction2.jpg}
 % symptom_abstraction2.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
 \label{fig:gensubsys2}
 \caption{Component Failure modes with analysed test cases}
\end{figure}

\par
\vspace{0.3cm}
\begin{tabular}{||l|l||} \hline \hline
  {\em Component Failure Mode } & {\em test case}    \\ \hline
$a\_1$ & $fs\_1$       \\      \hline
$a\_2$ & $fs\_2$  \\    \hline 
$a\_3$ & $fs\_3$  \\    \hline  
$b\_1$ & $fs\_4$  \\    \hline  
$b\_2$ & $fs\_5$ \\     \hline  
$c\_1$ & $fs\_6$  \\    \hline  
$c\_2$ & $fs\_7$  \\    \hline
 \hline
\end{tabular}
\vspace{0.3cm}



The sub-system fault symptoms are now represented on the diagram as in figure \ref{fig:gensubsys2}.

A second stage of analysis is now applied.
Empirically, it is often noticed that a sub-system will fail in the same way due to a variety of reasons.
To the `user' of the sub-system, it does not matter which component or combination of components has failed.
The sub-system can thus be considered to have its own set of failure modes.
This stage of the analysis is to determine these, to collect `like symptoms'.
This is performed on the diagram by linking the test cases with lines to form `spiders'

For the sake of example let us consider the fault symptoms $SP1 = \{fs_2, fs_4, fs_5\}$ to be an identical
failure mode at the {\em sub-system} level. These can then be joined to form a spider. Likewise
let $SP2 = \{fs_1, fs_3, fs_7\}$  be  an identical failure mode at the {\em sub-system} level.
Let $\{fs_6\}$ be a distinct failure mode at {\em sub-system} level.

The diagram can now be drawn as in figure \ref{fig:gensubsys3}.

% \begin{figure}[h+]
%  \centering
%  \includegraphics[scale=20]{./symptom_abstraction3.jpg}
%  % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
%  \label{fig:gensubsys3}
%  \caption{Common failure modes collected as `Spiders'}
% \end{figure}
\begin{figure}[h+]
 \centering
 \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction3.jpg}
 % symptom_abstraction3.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
 \label{fig:gensubsys3}
\caption{Common failure modes collected as `Spiders'}
\end{figure}


The third stage of the process can be applied automatically.
Each `spider' or `lone test case' becomes a contour
in the new diagram (see figure \ref{fig:gensubsys4}.

The result of this will be, a set of failure modes for the sub-system,  as though it were a {\em black box}
or a {\em component} to be used in higher level designs.


We have now in $SP1$, $SP2$ and $fs_6$ the three ways in which this sub-system can fail.
In other words we have derived failure modes for this sub-system.


%\section{The Process : To analyse a base level sub-system}

% \REQUIRE Obtain a list of components for the System $S$ under investigation. \ENSURE Decomposition of $S$ into atomic
% components where each component $c$ has a know set of $fm$ failure modes.
% 
% \STATE Determine functional groups $fg_n \subset S$ of components, where n is an index number 
% \COMMENT{ The functional groups should be chosen to be minimally sized collections of components that perform a specific function.}
% \REQUIRE{ Ensure that all components belong to at least one functinal group $\bigcup_i fg_i = S $
% %
% \FORALL { $fg_i \in S$}
% 
%    \STATE state something
% 
% \ENDFOR
% 
% \STATE Check for cut vertices \COMMENT{here we choose to decompose
% all nested components in one go}
% %
% \FORALL {vertices $v \in G$}
%  \STATE Check if $v$ is a cut vertex. \COMMENT{so $d$ is nested and in
% $d$ there must be a 0-separating curve in the zone corresponding to $v$}
% \ENDFOR
%
%
%%%%%%%%%%%%


% \begin{itemize}
%  \item determine a minimal functional group
%  \item obtain 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 multiple failures are examined use overlapping contours to represent this
%  \item for each region on the diagram, make a test case
%  \item examine each test case and determine the effect of the component failure modes on the 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.
% which test cases produce the same fault symptoms. Join common symptoms with `spiders', lines connecting them
%  \item The lone test cases and the spiders are now the fault mode behaviour of the sub-system 
%  \item A new diagram can now be drawn where each spider, or lone test case from the original diagram
% is represented as a contour. These contours represent the failure modes of the sub-system.
% \end{itemize}

This sub-system may now therfore, be represented as three separate failure modes.
We may now treat this sub-system as we would a component with a known set of failure modes.
The failure modes of the Sub-system $SS$ are now the set $SS_{fm} = \{ SP1, Sp2, fs_6 \}$.

Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now
write 

$$
\bowtie : SubSystemComponentFaultModes \mapsto SubSystemFaultModes 
$$

\begin{equation}
  \bowtie(FG_{cfm}) = SS_{fm}
\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}
% \end{figure}
% 

\begin{figure}[h+]
 \centering
 \includegraphics[width=3in,height=3in,bb=0 0 376 410]{symptom_abstraction/symptom_abstraction4.jpg}
 % symptom_abstraction4.jpg: 418x455 pixel, 80dpi, 13.27x14.45 cm, bb=0 0 376 410
 \caption{Deriving a new diagram}
 \label{fig:gensubsys4}
\end{figure}


The derived diagram in figure \ref{fig:gensubsys4} shows the functional group of components $A,B,C$
analysed as a sub-system. The result is a set of fault modes that define the fault mode behaviour of that sub-system.


This sub-system, with its three error modes, can now be treated as a component (although at a higher level of abstraction)
with known failure modes.




\clearpage
\section{A Formal Algorithmic Description of `Symptom Abstraction'}

The algorithm for {\em symptom abstraction} is described in 
this section
%describes the symptom abstraction process 
using set theory.  

The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$
and converts it to a sub-system $SS$.
The sub-system $SS$ is a collection
of failure~modes of the sub-system.
The sub-system $SS$ may now be treated  
as a component with a known set of failure modes.
Thus $SS$ can be used as a system building block at a higher
level of fault abstraction.


The algorithm has been broken down into five stages, each following on from the other.

\begin{algorithm}[h+]
 ~\label{alg:sympabs1}
\caption{Determine failure modes: $FG \mapsto FG_{cfm}$} \label{alg:sympabs11}
\begin{algorithmic}[1]
%\REQUIRE Obtain a list of components for the System $S$ under investigation. 
%ENSURE Decomposition of $S$ into atomic components where each component $c$ has a know set of $fm$ failure modes.


%\STATE Determine functional groups $fg_n \subset S$ of components, where n is an index number and the number of functional groups found. 

\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}
\STATE { Let $CFM$ represent a set of failure modes }
\STATE { $FM(c) \mapsto CFM $} \COMMENT {Let the function $FM$ take a component and return a set of all its failure modes}

%\ENSURE { $ \forall c | c \in FG \wedge  FM(c) \neq \emptyset $}
%\ENSURE { $ c | c \in FG \wedge  FM(c) \neq \emptyset $}
\ENSURE{  Each component $c \in FG $ has a known set of failure modes i.e. $FM(c) \neq \emptyset$ }
%\REQUIRE{ Ensure that all components belong to at least one functional group $\bigcup_{i=1...n} fg_i = S $ }
%symptom_abstraction
%   okular 
 
\STATE {let $FG_{cfm}$ be a set of failure modes}

\STATE {Collect all failure modes from the components into the set $FM_{cfm}$}
%\FORALL { $c \in FG $ }
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from the components into the set $FM_{cfm}$}
%\ENDFOR

%\hline
Algorthim \ref{alg:sympabs11} has taken a functional group $FG$ and returned a set of failure~modes $FG_{cfm}$.
The next task is to formulate `test cases'. These are the collections of failure~modes that will be used
in the analysis stages.
 

\end{algorithmic}
\end{algorithm}

 
\begin{algorithm}[h+]
 ~\label{alg:sympabs2}
\caption{Determine Test Cases: $FM_{cfm} \mapsto TC $} \label{alg:sympabs22}
\begin{algorithmic}[1]

   \REQUIRE {Determine the test cases to be applied}
   
     \STATE { All test cases are now chosen by the investigating engineer(s). Typically all single 
           component failures are investigated
            with some specially selected combination faults}
  
   \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$} 
   \COMMENT { Each set $tc_j$ is a `test case' }
   \STATE   { $ \forall j \in J  |  tc_j \in TC $ } 

   %\STATE { $ \bigcup_{j=1...N} tc_j =  \bigcup TC $ } 
   %\COMMENT { All $tc_j$ test cases sets belong to $TC$ }
 
    %\REQUIRE { $ TC \subset  \bigcup (FM_{cfm}) $ }  
   %\COMMENT { $TC$ is the set of all test_cases
% Let TC be a subset of the powerset of the failure modes $ FG_{cfm} $, 
%i.e. only failure modes present in $ FG_{cfm} $ are present in sets belonging to $ TC $}


   \COMMENT { Ensure the test cases are complete and unique }

   \FORALL { $tc_j \in TC$ }
     %\ENSURE   {$ tc_j  \in \bigcap FG_{cfm} $}
     \ENSURE   {$ tc_j  \in \mathcal{P} FG_{cfm} $}
     \COMMENT { require that the test case is a member of the powerset of $FM_{cfm}$ }
     \ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
     \COMMENT { Test cases must be unique } 
   \ENDFOR 

 
  
   \STATE { let $f$ represet a component failure mode }
   \REQUIRE { That all failure modes are represented in at least one test case }
   \ENSURE { $ \forall f | (f \in FM_{cfm}) \wedge  (f \in \bigcup TC) $ }
   \COMMENT { This corresponds to checking that at least each failure mode is considered at least once in the analysis; some european standards
imply checking all double fault combinations\cite{en298} }

%\hline
Algorithm \ref{alg:sympabs22} has taken the set of failure modes $FM_{cfm}$ and returned a set of test cases $TC$.
The next stages is to analyse the effect of each test case on the functional group.

\end{algorithmic}
\end{algorithm}

\begin{algorithm}[h+]
 ~\label{alg:sympabs3}
\caption{Analyse Test Cases: $ TC \mapsto R $} \label{alg:sympabs33}
\begin{algorithmic}[1]
 \STATE  { let r be a `test case result'}
 \STATE  { Let the function $Analyse : tc \mapsto r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions}
 \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$ }
     \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 $ }
   \ENDFOR 

%\hline
Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. 
\end{algorithmic}
\end{algorithm}




\begin{algorithm}[h+]
 ~\label{alg:sympabs4}

\caption{Find Common Symptoms: $ R \mapsto SP $} \label{alg:sympabs44}

\begin{algorithmic}[1]


   %\REQUIRE {All failure modes for the components in $fm_i = FM(fg_i)$}
 \STATE   {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$} 
   \STATE   {Let $SP$ be a set whose members are sets $sp_l$} 
   \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
%   
   %\COMMENT{This corresponds to a fault symptom of the functional group $FG$}
    %\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode}

   \FORALL { $ r_j \in R$ } 
          \STATE    { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ } 
          \STATE   { $sp_l \in \bigcap R \wedge sp_l \in SP$ } \COMMENT{ Collect common symptoms.
 Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it
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 a \in sp_l  |    \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 }
       	  
   \ENDFOR

  
  
    \STATE  { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents}

%\hline
Algorithm \ref{alg:sympabs44}  raises the failure~mode abstraction level.
The failures have now been considered not from the component level, but from the sub-system or
functional group level.
We now have a set $SP$ of the symptoms of failure.

\end{algorithmic}
\end{algorithm}

\begin{algorithm}[h+]
 ~\label{alg:sympabs5}

\caption{Treat the symptoms as failure modes of the Sub-System: $ SP \mapsto SS $} \label{alg:sympabs55}

\begin{algorithmic}[1]

 \STATE { Let $SS$ be a set of faliure modes with failure modes $f$ indexed by $l$ }
 \FORALL { $sp_l \in SP$ }
     \STATE { $ f_l = ConvertToFaultMode(sp_l) $}
     \STATE { $ f_l \in SS $}
   \ENDFOR 
%\hline

Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a 
sub-system $SS$, which has its own set of failure~modes. This can now be treated
as a component, and used to form functional~groups at a higher level of failure~mode~abstraction.
\end{algorithmic}
\end{algorithm}



\clearpage
\section{To conclude}

The technique provides a methodology for bottom-up analysis of the fault behaviour of complex safety critical systems.

\subsection{Hierarchical Simplification}

Because symptom abstraction collects fault modes, the number of faults to handle decreases
as the hierarchy progresses upwards.
This is seen in real life Systems. At the highest levels the number of faults
reduces. A Sound system might have, for instance only four faults at its highest or System level,
\small
$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
\normalsize
The number of causes for any of these faults is very large ! 
It does not matter which combination of causes caused the fault to the user.
But as the hierarchy goes up in abstraction level the number of faults goes down.

\subsection{Tracable Fault Modes}

Because the fault modes are determined from the bottom-up, the causes
for all high level faults naturally form trees.
Minimal cut sets \cite{nasafta} can be determined from these, and by
analysing the statistical likely hood of the component failures
the MTTF and SIL\cite{en61508} levels can be automatically calculated.