Robin_PHD/symptom_ex_process/topbot.tex

\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 approriate `EN' standard.
Typically environmental stress, EMC, electrical stressing, endurance tests, 
software~inspections and project~management quality reviews are applied\cite{sccs}.

Static testing is also applied. This is theoretical analysis of the design of the product from the safety 
perspective.
Three main techniques are currently used,
Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
The FMMD technique is aimed primarily as design verification for
safety critical systems.
However, FMMD  also provides the mathematical frame work
to assist in the production of these three results of static analysis.
From the model created by the FMMD technique, the three  above failure mode
descriptions can be derived.
FMMD can model electrical, mechanical and software using a common notation,
and can thus model an entire 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 intinctively 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 next be looked into. 
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 fault isolation/finding techniques are described in \ref{NETWORKDECOMPOSITION}.
\subsection{FMMD - Bottom~up Analysis}
The FMMD technique 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 mode of the system can be built.
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 the components.
%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 some terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'.
These are listed in table~\ref{tab:symexdef}.

A System, is really 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 is a sub-system. The 
whole Sound System, consists perhaps of the following `sub-systems': 
CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
 
%Thinking like this is a top~down analysis approach
%and is the way in which FTA\cite{nucfta} analyses a System
%and breaks it down.

A sub-system will be composed of 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 couldbe due to a large 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)
we are presented with a problem. Which initial collections of base components should we choose ?

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


In choosing the lowest level (base component) sub-systems we would look 
for the smallest `functional~groups' of components within a system. 
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 the component failure modes.
We can make a new `component' derived from the functional~group.
The symptoms 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 by derived   \\     
                                 & from derived components   \\    \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, which \\
               & hopefully has a known set of failure modes  \\    \hline  
 \hline
\end{tabular}
\caption{Symptom Extraction Definitions}
\label{tab:symexdef}
\end{table}