
\chapter{Algorithmic Description of FMMD}
%\label{sec:symptom_abstraction}
\label{sec:algorithmfmmd}

This chapter defines the process for performing one stage of the FMMD process i.e.
from forming a {\fg} to creating a {\dc}.
%
The FMMD process is then examined in greater levels of detail and described with set theory in 
an algorithmic context.
%
%This section decribes the algorithm for performing one step of
%FMMD analysis
%analysing a {\fg} and determining from it a {\dc}.
%
%Algorithms using set theory describe the process.
%An overview of the FMMD process is presented and it is then compared to
%diagnostic analysis (fault finding). 
%This is followed by justification for using a bottom-up, forward search
%approach, along with modularisation.
%A theoretical example of FMMD using set theory is given following  on to
%a description of the process presented as an algorithm.
%for performing FMMD is then presented.

%
% \section{FMMD as a process.}
% 
% % In FMMD we take a group of components with a functional purpose, apply
% % FMEA, and then determine how the {\fg} can fail.
% % We determine the common symptoms of failure of the {\fg}, and then
% % create a new {\dc} which has, as its failure modes, the symptoms we determined.
% 
% \paragraph{FMMD and failure mode models.}
% 
% To perform FMMD a {\fg} (a collection of components) is chosen
% FMEA is applied to it.
% %
% %In this way, we determine how that {\fg} can fail.
% This gives us a set of failure modes for the {\fg}.
% %
% The {\fg} is not viewed as a component, or module,
% and the FMEA results considered
% be its symptoms of failure.
% %
% Because component failures will often manifest themselves as the same symptoms of failure,
% we are able to collect common symptoms of failure for the {\fg}.
% %
% %
% With the collected common symptoms, we can treat the {\fg}
% as a component in its own right. We term this a `{\dc}'.
% %This new component being derived from the {\fg}.
% %
% %The `{dc}' can be thought of as a low~level sub-system.
% %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/{\dc},
% this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}. 
% %
% In this way a hierarchy to represent the fault behaviour
% of a system can be built from the bottom~up. This process can continue
% until there is a complete hierarchy representing the failure mode
% behaviour of the entire system under analysis.
% %FMMD hierarchy
% Using the FMMD technique, the hierarchy is built from the bottom up to 
% ensure complete failure mode coverage.
% 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 generic failure mode model.
% \fmmdgloss
% %
% %From the fault data model, automatic generation
% %of FTA \cite{nasafta} (Fault Tree Analysis) and minimal cuts sets \cite{nucfta} are possible. 
% %Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced 
% %automatically\footnote{Where component failure mode statistics are available \cite{mil1991}}.
% %
% This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy. 
% We can term this stage in FMMD analysis as the `symptom abstraction' process. 
% %The symptom abstraction or abstraction process, is the key process in creating an FMMD hierarchy.
% }
%\vspace{40pt}
% %\today
% \paragraph{Mutual exclusive property of the failure modes of a {\dc}}
% Because the symptoms have been collected from
% identical failure effects of the {\fg} they are mutually exclusive.
% That is to say no failure mode effects of a component of a {\fg}
% can be shared by a {\dc} failure mode.
% This ensures the mutually exclusive, or unitary state failure mode property, meaning
% the failure modes of a {\dc}  are suitable for use in higher level {\fgs}.
% 
% \subsection{Diagnostic analysis and Failure Mode Analysis}
% Fault finding is a closely related discipline to failure mode analysis.
% In diagnostic analysis, we generally start with a high level --- or system ---failure type.
% We trace this from the top, de-composing the systems until we come to
% a component or sub-system that has caused the failure.
% While there are similarities between diagnostic failure mode tracing and static failure mode analysis
% it is important to discuss the differences between them.
% %
%\subsection{Static Analysis}
%
%In the field of safety critical engineering, to comply with 
%European Law, a product must be certified under the appropriate `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 methodologies are currently used,
%Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
%The FMMD process is a static modelling methodology, aimed primarily for design verification of
%safety critical systems.
%%
%However, FMMD  also provides the mathematical framework
%to assist in the production of the three traditional methods of static analysis.
%From the model created by the FMMD methodology, statistical, FTA and FMEA models
%can be derived.
%FMMD can model electrical, mechanical and software failures using a common notation,
%and can thus model an integrated electro-mechanical software controlled system.
%
% \subsection{Top Down or Natural Trouble Shooting}
% We firstly  look at the `natural' trouble shooting process.
% Fault finding is instinctively performed from the top-down.
% A faulty piece of equipment is examined and will have a 
% symptom or specific fault. 
% %
% The suspected area or sub-system within the 
% equipment will be looked into next. 
% %
% The trouble shooter will look for behaviour that is unusual or incorrect
% to determine the next area or sub~system to look into, each time
% moving to a more detailed lower level.
% Specific measurements
% and checks will be made, and finally a component or a low level sub-system
% will be found to be faulty.
% A natural fault finding process is thus top~down.
% Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}.
% Fault tree analysis is a top down static failure mode analysis technique~\cite{nucfta,nasafta}.
% %%
% %% to fool the graphics insertion to make it compatible
% %% with thesis and papaer level directories.
% %%
% %% ln -s . symptom_ex_process
% %%
% 
% %% insert diagram here
% 
% \begin{figure}[h]
%  \centering
%  \includegraphics[width=300pt,bb=0 0 587 445,keepaspectratio=true]{./CH4_FMMD/top_down_de_comp.png}
%  % top_down_de_comp.jpg: 587x445 pixel, 72dpi, 20.71x15.70 cm, bb=0 0 587 445
%  \caption{Top Down Failure De-Composition Diagram}
%  \label{fig:tdh}
% \end{figure}
% 
% %%
% %% FMEA and FTA and safety engineering people used the term SUB_SYSTEM ALOT
% %% this study needs to use this term to keep the interested/in context.
% The term `sub-system' is typically used in top down methodologies.
% It has two equivalents in FMMD. 
% Both {\fg} and {\dc} correspond to the top down concept of a `sub-system'.
% In FMMD a {\fg} becomes a {\dc} after analysis.
% The term sub-system will be used alongside both {\fg} and {\dc} where necessary.
% 
% \subsection{Top-Down System De-Composition}
% 
% A top down fault analysis system will take a system and divide it into
% several sub-systems, and determine the safety dependencies
% of the System on those sub-systems. In the case of large complicated 
% systems, the sub-systems themselves may be broken down into simpler sub-systems.
% A top down hierarchy is shown in figure \ref{fig:tdh}.
% 
% \subsection{FMMD - Bottom~up Analysis}
% The FMMD methodology does not follow the `natural fault finding' or top down approach,
% it instead works from the bottom up.
% Starting with a collection of base~components 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, as it has a known set of failure modes.
% %
% By reusing the `components' derived from functional~groups, an entire
% hierarchical failure mode model of the system can be built.
% That is to say, using derived components in higher level functional groups,
% a hierarchy is naturally formed.
% %
% By working from the bottom up, we can trace all possible sources
% that could cause a particular mode of equipment failure.
% This means that at the design stage of a product all component failure
% modes must be considered. A benefit of FMMD is  complete failure mode coverage.
% This also means that it is possible to obtain statistical estimates based on the known reliabilities
% of components~\cite{mil1991}.
% %It also means that every component failure mode must at the very least be considered.


%{
%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}
%}
%


%\vspace{0.3cm}
% \begin{table}[h]
% \center
% \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, \\
% -or- derived component           & sub-systems may contain sub-systems. \\     
%                                  & derived~components may be derived   \\     
%                                  & from derived components   \\
%                                  & Constraint: This object must have a defined set of failure~modes \\    \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  
% Symptom & A failure mode of a functional group, caused by \\
%              &  a combination of its component failure modes \\ \hline
% Base Component & Any bought in component, or \\
%                & lowest level module/or part \\      
%                & Constraint: This object must have a defined set of failure~modes \\    \hline 
%  \hline
% \end{tabular}
% \caption{Symptom Extraction Definitions}
% \label{tab:symexdef}
% \end{table}


\fmodegloss

\glossary{name={system}, description={A product designed to work as a coherent entity}}
\glossary{name={sub-system}, description={A part of a system, sub-systems may contain sub-systems and so-on}}
\glossary{name={derived component}, description={A theoretical component, derived from a collection of components (which may be derived components themselves)}}
\glossary{name={functional group}, description={A collection of sub-systems and/or components that interact to perform a specific function}}
\glossary{name={symptom}, description={A failure mode of a functional group (of components), caused by a combination of its component failure modes}}
\glossary{name={base component}, description={Any bought in component, or lowest level module/or part}}
%\glossary{name={entry name}, description={entry description}}



\nocite{safeware}
\section{Overview of  the FMMD analysis Process}
The FMMD process is described in chapter~\ref{sec:chap4}, to re-cap, FMMD has four main stages:
\begin{itemize}
 \item collection of components to form {\fgs},
 \item applying FMEA to the {\fg},
 \item collecting common symptoms from the FMEA results,
 \item creating a {\dc} representing the failure mode behaviour of the {\fg}.
\end{itemize}
%
%This is termed `symptom~abstraction'.
% TO DO: separate these two:
% 
% \paragraph{FMMD analysis 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.
% Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system
% with its own set of failure modes.
This process allows us to modularise and simply FMEA analysis of systems.
%
The FMEA process is described in greater detail below.


\paragraph{FMEA applied to the Functional Group.}
As a {\fg} is a set of components, the failure~modes
that we have to consider are the failure modes of its components.
%, as
%developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
%The aim here is to build `test cases', 
Single or combinations of failure~modes are used to create failure~mode analysis scenarios, or `test cases'.
%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 {\fg}.
%
The aim of this analysis is to find out how the {\fg} fails given
each test case.
%
%The goal of the process is to produce a set of failure modes from the perspective of the user of the {\fg}.
%
In other words, if a designer has a previously analysed module to use, he need not be concerned with
the failure modes of its components: it is handed it as a derived component, 
which has its own FMMD defined set of failure modes. % symptoms. 
%
The designer can now treat this module as a black box, or {\dc}.

\paragraph{Environmental Conditions or Operational 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 to which it may be exposed. In this way, all possible
failure mode behaviour due to all the conditions that can be applied to a test case will be examined.

%As part of this analysis process, 
To aid test repeatability, quality and audit trails, records should be kept
detailing not only each test case result along with its resultant 
{\fg} failure mode, but the reasoning applied to obtain the analysis.
%
This data can be  kept in the model as part of an analysis report.
%and could be used to
%automatically examine the effects of 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, m
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 symptom; $no\_sound$ !




\paragraph{Collection of Symptoms.}
%Looking at the 
% examining failure from the 
% functional group perspective failure modes, we collect 
% some of these into common `symptoms' where possible.
% %
% 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 create a new component and consider the symptoms as its failure modes.
Common symptoms of failure of the {\fg} are collected.
%
We can now create a new component and consider the symptoms as its failure modes.
%
We call this new component a `{\dc}'.
%
%Note that here, b
Because the FMMD process is bottom up, we can ensure that all failure modes
from the components in a {\fg} have been considered.
%\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 to be missed, the resulting failure mode model would be %dangerously 
incomplete. 
%
It is possible here for an automated system to flag un-handled 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{A single stage of the FMMD 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 simultaneous 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, applying FMEA for each test case.
%
Where specific environment conditions, or operational states are germane to the {\fg}, these must also 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 {\fg}}.
 %
 \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 `{\dc}' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component.
\end{itemize}



\ifthenelse {\boolean{paper}}
{
\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}
}.


\subsection{Define Failure mode function $fm$}

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}

We define one stage of the FMMD process, taking a {\fg} and deriving a {\dc}
by the symbol `D'.
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:
$$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent 
\derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
$$

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

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

It is useful to further define the $\derivec$ function, to
take the failure modes from derived components (as well as base components)
and return a new derived component.
This generalises the function $\derivec$ 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 $\derivec$
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 to the {\fg}
$FG_{derived}$ shown in equation \ref{eqn:fgderived}.

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


The case 
where a {\fg} has been created from {\dcs} 
using function `$\derivec$' 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}.

%%$$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent 
%%\derivec : FG_{derived} \rightarrow DC 
%%$$
%
%\begin{equation}
%  \derivec(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}
%%  \derivec((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 `$\derivec$' 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}

%% IF this is a paper it needs work on the description here.
} 
{
%To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}.
The FMMD process is now described introducing 
set theoretical definitions % formal definitions 
that will be used in the description of FMMD 
presented as an algorithm.
%
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 $$

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}



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:
$$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent 
\derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
$$

The next section describes the details of the symptom abstraction process.

}



%\section{A Formal Algorithmic Description of `Symptom Abstraction'}
\section{Algorithmic Description}
\label{sec:symptomabs}
The algorithm for {\em symptom abstraction} is described in 
this section
%describes the symptom abstraction process 
using set theory and procedural descriptions.  
%
The {\em symptom abstraction process} (given the symbol `$\derivec$', D for derive) takes a functional group $FG$
and a new 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 from which it was derived.
% %Thus, ke

% $DC$ can now be treated  
% as a component with a known set of failure modes.


\paragraph{Enumerating abstraction levels}
\label{sec:abstractionlevel}
As described in section~\ref{sec:alpha} we can assign an attribute  of abstraction level $\abslev$  to
components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
For a base component, let the abstraction level be zero.
If we apply the symptom abstraction process $\derivec$,
the resulting derived~component will have an $\abslev$ value
one higher that the highest $\abslev$ 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 $\abslev$ 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 $\abslev$ 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.
\fmmdgloss


%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
% \IF{$c.\abslev > \abslev_{max}$} 
%   $\abslev_{max} = c.\abslev$
% \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 `$\derivec$', 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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



\section{Algorithmic Description of Symptom Abstraction}
%\clearpage
$$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$

\begin{algorithm}[h+]

\caption{Derive new `Component' from Functional Group: $\derivec(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 process 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. 





%\clearpage
\subsection{ Determine Failure Modes to Examine}

The first stage is to find the failure modes to consider for
analysis,
using the earlier definition of the function $fm$.

The function $fm$ applied to a component returns the failure modes for that component.
Thus its domain is the set of all components $\mathcal{C}$ and its range 
is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$.

$$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$

A {\fg} is a collection of components $G$ such that $\mathcal{G} \in \mathcal{P}\,\mathcal{C}$.

The function $fm$ can be overloaded with a {\fg} $\mathcal{G}$ as its domain
and the power-set of all failure modes as its range.


$$ fm: \mathcal{\FG} \rightarrow  \mathcal{P}\,\mathcal{G} $$

%
%%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
%%%
%
%%%-
%%%- A such that B is C
%%%- 
%
%
%\begin{algorithm}[h+]
% ~\label{alg1}
%\caption{Determine Failure Modes: fm( $FG$ )}           \label{alg11}
%\begin{algorithmic}[1]
%\REQUIRE {FG is a non empty set of components i.e. $ FG \in \mathcal{P}\,\mathcal{C} \wedge FG \neq \emptyset $. }
%\REQUIRE {Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; \big(  fm(c) \neq \emptyset \big)$.}
%
%%\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 $ }
%\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 can be formed from single failure modes or failure modes in combination.
Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$ 
be the set of all failure modes.
%(associated with the functional group $FG$).

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

given by

$$ dtc(F) = TC $$

In algorithm \ref{alg22}, the function \textbf{chosen} means that 
the failure modes for a particular test case have been chosen by
a human operator and are additional to those chosen by the automated process (i.e they are 
special case test cases involving multiple failure modes)
The function \textbf{unitary state} means that all test 
cases can have no pairs of failure modes sourced from the same component, see section~\ref{sec:unitarystate}.

\label{sec:completetest}

This function also ensures completeness in the model.
It ensures that %for 
all failure modes in the {\fg} are considered in a test~case.
%
\ifthenelse {\boolean{paper}}
{
%% perhaps ref a paper here XXXXX
}
{
Components with a unitary state property are discussed in chapter \ref{sec:unitarystate}.
}
%%
%% 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 $ptc$ a provisional test case}
	%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
        % ESCPECIALLY IN THIS FUCKING ENVIRONMENT 22OCT2010
	%% OK maybe you can't have comments after IF: half an hour wasted...
	\IF { $ {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 { ${chosen}(ptc) \wedge ptc \not\in TC  \wedge  {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} $}
     %
     % Lone commoents like the one below causing incredibly annoying very difficult to trace errors: cunt
     %\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 ) $}
     %\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
%
     \ENSURE { $ \forall j1,j2 \in J \; such\; that\;  j1 \neq j2  \big( tc_{j1} \neq tc_{j2} \big)  $}
     \ENSURE { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ } 
   \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 $\mathcal{R}$ be the set of all test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).

$$ atc:  \mathcal{TC} \rightarrow \mathcal{R} $$
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 component 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$ } 
   \FORALL { Environmental and Specific Applied States }
     \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 
 \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.
%
%
Calculations or simulations
are performed to determine how the failure modes in each test case will
affect the functional~group.
Ideally field data and/or formal physical testing  should be used in addition static failure mode reasoning
where possible.
%
When the all the test cases have been analysed
we will have a `result' for each `test case'.
%
Each result will be described from the perspective of %{\wrt}  to 
the {\fg}, not the components failure modes.
%in its test case.
%
%In the case of a simple
%electronic circuit, we could calculate the effect on voltages
%within the circuit given a certain component failure mode, for instance.
%%

%
Thus we will have a set of 
results corresponding to our test cases. These share a common index value ($j$ in the algorithm description).
These results 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 $\mathcal{SP}$ be the set of all  symptoms,
and $\mathcal{R}$ be the set of all test case results.

$$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{$Let \; sp_l \in \mathcal{P} R$ such that R is in a common symptom group } \COMMENT{determine 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}  
This raises the failure~mode abstraction level, $\abslev$.
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 $$

The new component will have a set of failure modes that correspond to the common symptoms collected from the $FG$.

%\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} 
The function $cdc$ 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.
\subsection{Hierarchical Simplification}

Because symptom abstraction collects aggregates fault modes, the number of faults to handle should decrease
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 failure modes goes down for each level:
as is found in practise in real world systems.

\subsection{Traceable Fault Modes}

Because the fault modes are determined from the bottom-up, the causes
for all high level faults naturally form trees.
That is to say from the bottom-up causes become symptoms which in the next level become causes as we traverse up the tree.
This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms
in FMMD analysis hierarchies.
These trees can be also 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 Mean Time to Failure (MTTF) and SIL\cite{en61508} levels can be automatically calculated.









%%%\section{Example Symptom Extraction}
%% There already is an example of the process before the algorithmic description
%%%This is a simplified version of the pt100 example in chapter \ref{pt100}.

%\vspace{40pt}
%\today



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  %
..
