62 lines
2.5 KiB
TeX
62 lines
2.5 KiB
TeX
%%
|
|
%%
|
|
%% OBSOLETE DO NOT EDIT
|
|
%%
|
|
%%
|
|
%%
|
|
\section{The Symptom Extraction Process}
|
|
|
|
% TO DO: separate these two:
|
|
|
|
\paragraph{Symptom Extraction Described}
|
|
|
|
The objective of `symptom extraction' is to analyse the functional~group and find
|
|
how it can fail
|
|
when specified components within it fail.
|
|
Once we know how functional~group can fail, we can treat it as a component or sub-system
|
|
with its own set of failure modes.
|
|
|
|
\paragraph{FMEA applied to the Functional Group}
|
|
As the functional~group is a set of components, the failure~modes
|
|
that we have to consider are all the failure modes of its components.
|
|
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 functional~group.
|
|
%
|
|
The aim of this analysis is to find out how the functional~group reacts
|
|
to each of the test case conditions.
|
|
The goal of the process is to produce a set of failure modes from the perspective of the functional~group.
|
|
|
|
|
|
|
|
|
|
\paragraph{Symptom Identification}
|
|
When all `test~cases' have been analysed, a second phase is applied.
|
|
%
|
|
This looks at the results of the `test~cases' as failure modes from the perspective of
|
|
of the {\fg}/sub-system.
|
|
%%Single component failures (or combinations) within the functional~group may cause unique symptoms.
|
|
However, many failures, when looked at from the perspective of the functional group, will have the same `symptoms' (or
|
|
in other words the sub-system/{\fg} will fail in the same way for a variety of causes.
|
|
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; $no\_sound$ !
|
|
|
|
|
|
|
|
|
|
\paragraph{Collection of Symptoms}
|
|
The common symptoms of failure and lone~component failure~modes are identified and collected.
|
|
We can now consider the functional~group as a component and the symptoms as its failure modes.
|
|
Note that here because the process is bottom up, we can ensure that all failure modes
|
|
associated with a functional~group have been handled.
|
|
Were failure~modes missed, any failure mode model could be dangerously incomplete.
|
|
It is possible at this stage for an automated system to flag unhandled failure modes,
|
|
which fulfills the wish list in chapter \ref{requirement at the start}, removing
|
|
the main drawback with top-down methodologies, that of missing component failure mode
|
|
in the model \cite{nancy_crit_fta_top_down}.
|
|
|