

%\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.
Thus, it can be treated  
as a component with a known set of failure modes.





\paragraph{Enumerating abstraction levels}
We can assign an attribute  of abstraction level $\alpha$  to
components, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}_0$).
For a base component let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$
the resulting 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 
The attribute $\alpha$ can be used to track the 
level of fault abstraction  of components in an FMMD hierarchy. Because base and derived components
are collected to form functional groups, a hierarchy is
naturally formed with the abstraction levels 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, represented by the symbol `$\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 are stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{ 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 functional group $\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{alg1}
\caption{Determine Failure Modes: fm( $FG$ )}           \label{alg11}
\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}

\STATE { $ F := \emptyset $} \COMMENT{Clear the set of failure modes}
\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$ }
\STATE{ $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ } 
\ENDFOR
 
\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$}


\RETURN { $F$ }

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

Algorthim \ref{alg11} 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{ 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, which hold combinations of failure modes $F$ (associated with the functional group $FG$).

$$ dtc: \mathcal{F} \rightarrow  \mathcal{TC} $$

given by

$$ dtc(F) = TC $$

%%
%% Algorithm 2
%%


%%
%% Maybe need to iterate through each failure mode, adding a new test case
%% this would build up all single fault test cases.
%%
 
\begin{algorithm}[h+]
 ~\label{alg2}
\caption{Determine Test Cases: dtc: (F)            } \label{alg22}
\begin{algorithmic}[1]

   \REQUIRE {F is a non empty flat set of failure modes      }
   
     \STATE { All test cases are chosen by the investigating engineer(s). Typically all single 
           component failures are investigated
            with some specially selected combination faults}
  
   \STATE   { Let $TC$ be the 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}

   \STATE { $ TC := \emptyset $ } \COMMENT{Initialise set of test cases}
   \STATE { $ j := 1 $ } \COMMENT{Initialise index of test cases}

   \FORALL { $ f \in F $ }
	\STATE{$ tc_j := f $} \COMMENT{ Assign one test case per single fault mode }
        \STATE{ $ j := j + 1 $} 
   \ENDFOR 

   \STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes }
     
   \IF{DoubleFaultChecking} 

   \STATE { Let $ptc$ be a provisional test case }
   \FORALL { $ f1,f2 \in F $ }
	\STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make a provisional test case}
	%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
	%% OK maybe you can't have comments after IF: half an hour wasted...
	\IF { $ \mathcal{ISUNITARYSTATE}(ptc) $ } % \COMMENT{Ensure the chosen failure mode set is unitary state compliant}
           \STATE{ $ j := j + 1 $} % latex bug hunt game what fun ! #2 
           \STATE { $ tc_j := ptc $}
	   \STATE { $ TC := TC \cup tc_j $ }
	\ENDIF
   \ENDFOR
 \ENDIF
 




   \FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ }
	%%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case}
	\IF { $\mathcal{CHOSEN}(ptc) \wedge ptc \not\in TC  \wedge  \mathcal{ISUNITARYSTATE}(ptc)$ } %%% \COMMENT{IF this combination of faults is chosen as an additional Test case include it in TC}
           \STATE{ $ j := j + 1 $}  % latex bug hunt game #1
           \STATE { $ tc_j := ptc $}
	   \STATE { $ TC := TC \cup tc_j $ }
	\ENDIF
   \ENDFOR

   \FORALL { $tc_j \in TC$ }
     %\ENSURE   {$ tc_j  \in \bigcap FG_{cfm} $}
     \ENSURE   {$ tc_j  \in \mathcal{P}(F) $ } % \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$ represent 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$ represent component failure modes, and $c$ any 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\; (f1,f2 \in F))    \wedge  ( \{f1,f2\} \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{alg22} 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{ 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} \rightarrow \mathcal{R} $$A
given by
$$ atc(TC) = R $$

\begin{algorithm}[h+]
 ~\label{alg3}
\caption{Analyse Test Cases: atc(TC)           } \label{alg33}
\begin{algorithmic}[1]
 \STATE  { let r be a `test case result'}
 \STATE  { Let the function $Analyse : tc \rightarrow 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 \cup rc_j $ } \COMMENT{Add $rc_j$ to the set R}
   \ENDFOR 

  \RETURN $R$ 

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

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


The analysis is primarily a human activity.
%
Each test case is examined in detail.
%
%
Ideally calculations or simulations
are performed to determine the functional~group failure mode
the test case failure modes will cause. 
%
%
In the case of a simple
electronic circuit, we could calculate the effect on voltages
within the circuit given certain component failure modes, for instance.
The affect of these unusual volatges would then be a failure
mode of the functional group and become the result of the test case.
When each test case has been analysed, we have a set of
results. These are the failure modes of the functional group.

Once a functional group has been analysed, it can be re-used in 
any other design that uses it.
Often safety critical designs have repeated sections (such as safety critical digital inputs or $4\rightarrow20mA$
inputs), and in this case the analysis would only need to be performed once. 



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{ 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.
This stage collects results into `Symptom' sets.
Each result from the preceding stage is examined and collected
into common symptom sets.
That is to say, each result in a symptom set, from the perspective of the functional group
has the same failure symptom.
Let set $SP$ be the family of symptom sets for the functional group $FG$.

$$fcs:  \mathcal{R} \rightarrow \mathcal{SP} $$
given by
$$ fcs(R) = SP $$

\begin{algorithm}[h+]
 ~\label{alg4}

\caption{Find Common Symptoms: fcs($R$)} \label{alg44}

\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 the indexed `symptoms' $sp_l$} 
   \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
    \STATE{$SP   := 0$} \COMMENT{ initialise the `symptom family set'}
%   
   %\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}
\REPEAT 

    \STATE{$sp_l := 0$} \COMMENT{ initialise the `symptom'}
    \STATE{$sp_l \in \mathcal{P} R$} \COMMENT{Select common symptoms from the results set}
    \STATE{$ R := R \backslash sp_l $} \COMMENT{remove the results used from the results set}
    \STATE{$ SP := SP \cup sp_l$} \COMMENT{collect the symptom into the symtom family set SP}
    \STATE{$ l := l + 1 $} \COMMENT{move the index up for the next symptom to collect}

\UNTIL{ $ R = \emptyset $ } \COMMENT{continue until all results belong to a symptom}

%%   \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{alg44}  raises the failure~mode abstraction level, $\alpha$.
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.

\ifthenelse {\boolean{paper}}
{
Component failure modes must be mutually exclusive.
That is to say only one specific failure mode may be active at any time.
This condition/property has been termed unitary state failure mode.
Ensuring that no result belongs to more than
one Symptom set, enforces this, for the derived 
component created in the next stage.
}
{
Note ensuring that no result belongs to more than one symptom
set enforces the `unitary state failure mode constraint' for derived components.
}

%% Interesting to draw a graph here.
%% starting with components, branching out to failure modes, then those being combined to
%% test cases, the test cases producing results, and then the results collected into
%% symptoms.
%% the new component then gets the symptoms as failure modes.
%% must be drawn !!!!!
%% 04AUG2010 ~~~~ A27 refugee !!!


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{ 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} \rightarrow \mathcal{DC} $$

given by

$$ cdc(SP) = DC $$

\begin{algorithm}[h+]
 ~\label{alg5}

\caption{Create Derived Component: cdc(SP)            } \label{alg55}

\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 \cup 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{alg55} 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} \rightarrow \mathcal{DC} $$

\begin{algorithm}[h+]

\caption{Derive new `Component' from Functional Group: $\bowtie(FG)$} \label{alg66}

\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 provides the analysis `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 component failure~modes 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 likelihood of the component failures,
the MTTF and SIL\cite{en61508} levels can be automatically calculated.


\vspace{40pt}
%\today

