

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

The algorithm for {\em symptom extraction} 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 derived~component/sub-system $DC$.
%The sub-system $SS$ is a collection
%of failure~modes of the sub-system.
Note that
$DC$ is a derived component at a higher level of fault analysis abstraction,
than the functional~group it was derived from.
However, it can still be treated  
as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels}
We can assign an attribute  of abstraction level to
components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathcal{N}$).
For a base component let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$
the reulting derived~component will have an $\alpha$ value
one higher that the highest $\alpha$ value of any of the components
in the functional group used to derive it.
Thus a derived component sourced from base components
will have an $\alpha$ value of 1. 
%
%If $DC$ were to be included in a functional~group,
%that functional~group must be considered to be at a higher level of
%abstraction than a base level functional~group.
%
%In fact, if the abstraction level is enumerated, 
%the functional~group must take the abstraction level
%of the highest assigned to any of its components.
%
With a derived component $DC$  having an abstraction level 
attribute $\alpha$ we can use this to track the 
level of fault abstraction through a hierarchy. Because base and derived components
are collected to form functional groups, a hierarchy is
naturally formed with the abstraction level increasing with each tier.


%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
% \IF{$c.\alpha > \alpha_{max}$} 
%   $\alpha_{max} = c.\alpha$
% \ENDIF 
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
%\ENDFOR


The algorithm, representing the function $\bowtie$, has been broken down into five consecutive stages.
These are described using the Algorithm environment in the next section \ref{algorithms}.
By defining the process and describing it using set theory, constraints and 
verification checks in the process can be stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine}

The first stage is to find the failure modes to consider for
analysis.
From the earlier definition of the function `FM':

The function $FM$ applied to a component returns the failure modes for that component.

The function $FM$ takes  a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$.

$$ FM: \mathcal{FG} \rightarrow  \mathcal{F}$$


%Let $FG$ be the set of components in the functional group under analysis, and $c$
%be components that are members of it. This function returns a flat set of failure modes $F$.
given by
$$FM(FG) = F$$
%%
%% Algorithm 1
%%

\begin{algorithm}[h+]
 ~\label{alg:sympabs1}
\caption{FM( $FG$ )}           \label{alg:sympabs11}
\begin{algorithmic}[1]
\REQUIRE {FG is a set of components (a functional~group)} 

\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}

\FORALL { $c \in FG $ }
\REQUIRE{  Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; such \; that\;  FM(c) \neq \emptyset$ }
\ENDFOR
 
\STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$}


\RETURN { $F$ }

%\hline
%
\end{algorithmic}
\end{algorithm}

Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ 
(given that each component has a known set of failure~modes).
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used
in the analysis stages.




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases}

From the failure modes associated with the functional~group
we now need to determine test cases.
The test cases are collections of failure modes.
These could be formed from single failure modes or failure modes in combination.
Let $TC$ be the set of test cases associated with the functional group $FG$.

$$ DTC: \mathcal{F} \mapsto  \mathcal{TC} $$

given by

$$ DTC(F) = TC $$

%%
%% Algorithm 2
%%

 
\begin{algorithm}[h+]
 ~\label{alg:sympabs2}
\caption{DTC: (F)            } \label{alg:sympabs22}
\begin{algorithmic}[1]

   \REQUIRE {F is a flat set of failure modes      }
   
     \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 $ } \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}(F))$} 
     \COMMENT { require that the test case is a member of the powerset of $F$ }
     %\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
     \ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $}
     \COMMENT { Test cases must be unique } 
   \ENDFOR 

 
   \IF{Single fault checking} 
   \STATE { let $f$ represet a component failure mode }
   %\ENSURE { That all failure modes are represented in at least one test case }
   \ENSURE { $ \forall f \;such\;that\; (f \in F))    \wedge  (f \in \bigcup TC) $ }
   \COMMENT { This corresponds to checking that at least each failure mode is considered at 
              least once in the analysis; more rigorous cardinality constraint
              checks may be required for some safety standards}
   \ENDIF

   \IF{Double fault checking} 
   \STATE { let $f1,f2$ represet a component failure modes, and $c$ a component in the functional group }
   %\ENSURE { That all failure modes are represented in at least one test case }
   \ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f \in F))    \wedge  (f \in \bigcup TC) $ }
   \COMMENT { This corresponds to checking that each possible double failure mode is considered  
              as a test case; more rigorous cardinality constraint
              checks may be required for some safety standards. Note if both failure modes
              in the check are sourced from the same component $c$ the test case is impossible
              under unitary state failure mode conditions}
   \ENDIF

   \RETURN $TC$
% some european standards
%                imply checking all double fault combinations\cite{en298} }

%\hline

\end{algorithmic}
\end{algorithm}

Algorithm \ref{alg:sympabs22} has taken the set of failure modes $ F=FM(FG) $ and returned a set of test cases $TC$.
The next stage is to analyse the effect of each test case on the functional group.







%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases}
%%
%% Algorithm 3
%%
The test cases are now analysed for their impact on the behaviour of the functional~group.
Let $R$ be a set of test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).

$$ATC:  \mathcal{TC} \mapsto \mathcal{R} $$

\begin{algorithm}[h+]
 ~\label{alg:sympabs3}
\caption{ATC(TC)           } \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 $ } \COMMENT{Add $rc_j$ to the set R}
     \STATE{ $ R := R \cap rc_j $ } \COMMENT{Add $rc_j$ to the set R}
   \ENDFOR 

  \RETURN $R$ 

%\hline
\end{algorithmic}
\end{algorithm}

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



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms}
%%
%% Algorithm 4
%%
This stage analyses the results from bottom-up FMEA analysis ($R$), and collects
results that, from the perspective of the functional~group, have the same failure symptom.
Let set $SP$ be the set of symptoms for the functional group $FG$.

$$FCS:  \mathcal{R} \mapsto \mathcal{SP} $$


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

\caption{FCS($R$)} \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  \;such\;that\;    \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}

  \RETURN $SP$
%\hline

\end{algorithmic}
\end{algorithm}

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.






%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component}
%%
%% Algorithm 5
%%
This final stage, is the creation of the derived component.
This derived component may now be used to build
new functional groups at higher levels of fault abstraction.
Let $DC$ be a derived component with its own set of failure~modes.

$$ CDC:  \mathcal{SP} \mapsto \mathcal{DC} $$
\begin{algorithm}[h+]
 ~\label{alg:sympabs5}

\caption{CDC(SP)            } \label{alg:sympabs55}

\begin{algorithmic}[1]

 \STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ }
 \FORALL { $sp_l \in SP$ }
     \STATE { $ f_l = ConvertToFaultMode(sp_l) $}
     %\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
     \STATE { $DC := DC \cap f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}

   \ENDFOR 
   \ENSURE { $FM(DC) \neq \emptyset$ } \COMMENT{Ensure that DC has a known set of failure modes}
  \RETURN DC
%\hline

\end{algorithmic}
\end{algorithm}

Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a 
derived~component $DC$, which has its own set of failure~modes. This can now be
used in with other components (or derived~components) 
to form functional~groups at higher levels of failure~mode~abstraction.
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.

\section{Linking all five stages}

$$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$

\begin{algorithm}[h+]

\caption{$\bowtie(FG)$} \label{alg:sympabs66}

\begin{algorithmic}[1]

   \STATE {F  = FM (FG)}  \COMMENT{ collect all component failure modes }%from the from the components in the functional~group  }
   \STATE {TC  = DTC (F)}  \COMMENT{ determine all test cases } %to apply to the functional group }
   \STATE {R  = ATC (TC)}  \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group }
   \STATE {SP  = FCS (R)}  \COMMENT{ find common symptoms }%of failure for the functional group  }
   \STATE {DC  = CDC (SP)}  \COMMENT{ create a derived component }

 \RETURN $DC$

\end{algorithmic}
\end{algorithm}

The symptom abstraction technique allows us to take a functional group of components,
analyse the failure
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
The checks and constraints applied in the algorithm ensure that all component failure
modes are covered.
This process naturally takes one step to building a hierarchical failure mode model
from the bottom-up. 

\subsection{Hierarchical Simplification}

Because symptom abstraction collects fault modes, the number of faults to handle decreases
as the hierarchy progresses upwards.
%This is seen by casual observation of real life Systems.  NEED A GOOD REF HERE
At the highest levels the number of faults
is significantly less than the sum of its component failure modes. 
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 to the user, which combination of causes caused the fault.
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.
These trees can be traversed to produce 
minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by
analysing the statistical likelyhood of the component failures,
the MTTF and SIL\cite{en61508} levels can be automatically calculated.


\vspace{40pt}
%\today

