85 lines
3.5 KiB
TeX
85 lines
3.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{Environmental Conditions or Applied States}
|
|
|
|
Each test case must be considered in the light of any applied states or
|
|
environmental conditions that it may be exposed to.
|
|
|
|
\paragraph{Electronics}
|
|
A {\fg} may, in the case of an electronic circuit have
|
|
applied states. For instance test modes, shutdown or lockout modes etc.
|
|
which are inputs to the circuit.
|
|
In this case each test case from the {\fg} must be analysed with
|
|
respect to all these states.
|
|
|
|
\paragraph{Mechanical}
|
|
A mechanical device may be required to work in different
|
|
temperature or pressure ranges for instance and its failure mode behaviour may
|
|
change due to enviromental factors.
|
|
|
|
\paragraph{Software}
|
|
A software function may have an applied state, where it must modify
|
|
its general behaviour.
|
|
For instance some states in an embedded real time system
|
|
may require special error or emergency handling behaviour.
|
|
This could be in the form of global variable which could indicate a system condition
|
|
such as NORMAL\_OPERATION, GRACEFUL\_DEGRADATION \cite{en61508}[SECTION XX] LOCKOUT or SHUTDOWN
|
|
for instance.
|
|
|
|
\subsection{Symptom Identification / collection}
|
|
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}.
|
|
|