4427b8ff3c
where the thesis level and the paper level have different paths for the graphics file. I do not know how to put a symbolic link like this into git and dont really dare to !
184 lines
9.1 KiB
TeX
184 lines
9.1 KiB
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 a static modelling methodology, aimed primarily as design verification for
|
|
safety critical systems.
|
|
However, FMMD also provides the mathematical frame work
|
|
to assist in the production of the three traditional methods of static analysis.
|
|
From the model created by the FMMD technique, statistical, FTA and FMEA models
|
|
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}.
|
|
|
|
%% 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}
|
|
|
|
\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 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 could be 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 its component failure modes.
|
|
We can thus 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}
|