%%
%%
%% OBSOLETE DO NOT EDIT
%%
\section{Fault Finding and Failure Mode Analysis}

\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}
It is interesting here to 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}.

%%
%% 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]{symptom_ex_process/top_down_de_comp.jpg}
 % 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
hierarichal 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. The aim here is for complete failure mode coverage.
This also means that we can obtain statistical estimates based on the known reliabilities
of components\cite{mil1992}.
%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}
%}
%

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

It is helpful here to define the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'.
These are listed in table~\ref{tab:symexdef}.

A system, is any coherent entity that would be sold as a product. % safety critical product.
A sub-system is a system that is part of some larger system.
For instance a stereo amplifier separate/slave 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.
\paragraph{Sub-systems, {\fgs} and components.}
A sub-system will be composed of components, which
may themselves be sub-systems. However each `component'
will have a fault/failure behaviour and it should
always be possible to obtain a set of failure modes
for each `component'.  
%In FMMD terms a sub-system is a derived component.

If we look at the sound system example, 
the CD~player could fail in several distinct ways, 
and this could  have been caused by a number of component failure modes.
%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 \cite{faa}[Ch.9])
we are presented with a problem. Which initial collections of base components should we choose?

For instance in the CD~player example; if we 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.

\paragraph{Functional group to {\dc} process outline.}
In choosing the lowest level (base component) sub-systems we would look 
for the smallest `functional~groups' of components within a system. 
We can define a functional~group as 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'.
The fault behaviour will consist of a set of `symptoms' caused by combinations
of its component failure modes.
We can thus make a new `component' derived from the functional~group.
The symptoms of the {\fg} are the failure modes of this new `derived component'.

%We can now call our functional~group a sub-system or a derived~component. 
%The goal here is to know how it 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}

Electrical components have detailed datasheets associated with them. A useful extension of this could
be failure modes of the component, with environmental factors and MTTF statistics.
Currently this sort of failure mode information is generally only  available for generic component types \cite{mil1991}.

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