226 lines
11 KiB
TeX
226 lines
11 KiB
TeX
%%
|
|
%%
|
|
%% 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}}
|