tidying up metrics chapter....
This commit is contained in:
parent
e7ce19d96c
commit
eb09ccf83f
@ -1,3 +1,4 @@
|
|||||||
|
\label{sec:chap1}
|
||||||
|
|
||||||
%\paragraph{Abstract} % : The Scope of this study.}{
|
%\paragraph{Abstract} % : The Scope of this study.}{
|
||||||
{
|
{
|
||||||
|
@ -2,7 +2,22 @@
|
|||||||
|
|
||||||
\section{Historical Origins of FMEA}
|
\section{Historical Origins of FMEA}
|
||||||
\subsection{FMEA designed for simple electro-mechanical systems}
|
\subsection{FMEA designed for simple electro-mechanical systems}
|
||||||
|
So its old and prob out of date
|
||||||
|
|
||||||
|
\subsection{FMEA does not support modularity.}
|
||||||
|
It is a common practise in industry to buy in sub-systems, especially sensors.
|
||||||
|
Most sensor systems now are `smart', that is to say, they contain programatic elemnts
|
||||||
|
even if they supply analog signals. For instance a liquid level sensor that
|
||||||
|
supplies a {\ft} output, would have been typically have been implemented
|
||||||
|
in analog electronics before the 1980s. After that time, it would be common to use a micro-processor
|
||||||
|
based system to perform the functions of reading the sensor and converting it to a current (\ft) output.
|
||||||
|
For the non-safety critical systems integrator this brings with it the advantages
|
||||||
|
that come with using a digital system (increased accuracy, self checking and ease of
|
||||||
|
calibration etc). For a safety critical systems integrator this can be very problematic when it
|
||||||
|
comes to approvals. Even if the sensor manufacturer will let you see the internal workings and software
|
||||||
|
we have a problem with tracing the FMEA reasoning through the sensor, through the sensors software
|
||||||
|
and then though the system being integrated.
|
||||||
|
This problem is compounded by the fact that traditional FMEA cannot integrate software into FMEA models~\cite{sfmea,safeware}.
|
||||||
\section{Reasoning Distance}
|
\section{Reasoning Distance}
|
||||||
\section{Comparison Complexity}
|
\section{Comparison Complexity}
|
||||||
|
|
||||||
|
@ -3,6 +3,25 @@
|
|||||||
\section*{Metrics}
|
\section*{Metrics}
|
||||||
|
|
||||||
|
|
||||||
|
%
|
||||||
|
It begins be defining a metric for the complexity of an FMEA analysis task.
|
||||||
|
%
|
||||||
|
This concept is called `comparisson~complexity' and is a means to assess FMMD against current FMEA methodologies.
|
||||||
|
%
|
||||||
|
This metric is developed formally and then formulae are presented for comparing the
|
||||||
|
complexity of using modularised or straightforward FMEA.
|
||||||
|
%
|
||||||
|
These formulae are then used for a hypothetical example, analysed by FMEA and FMMD.
|
||||||
|
|
||||||
|
FMMD makes the claim that it can perform double simultaneous failure mode analysis without an undue
|
||||||
|
state explosion drawback.
|
||||||
|
To back this up, an example of double failure analysis is provided, using single and double
|
||||||
|
failure analysis, using the four wire Pt100
|
||||||
|
temperature measurement sensor circuit. This example is also used to show how component failure rate statistics can be
|
||||||
|
used with FMMD.
|
||||||
|
|
||||||
|
This is followed by some critiques i.e. possible areas of difficulty when performing FMMD, and then
|
||||||
|
a general evaluation. % comparing it with traditional FMEA.
|
||||||
|
|
||||||
%
|
%
|
||||||
% Moving Pt100 to metrics
|
% Moving Pt100 to metrics
|
||||||
@ -19,7 +38,9 @@
|
|||||||
% DOMAIN == INPUTS
|
% DOMAIN == INPUTS
|
||||||
% RANGE == OUTPUTS
|
% RANGE == OUTPUTS
|
||||||
%
|
%
|
||||||
|
When we hear of a safety critical system we typically think of it in terms of
|
||||||
|
the physical plant---or in terms of its safety functionality.
|
||||||
|
%
|
||||||
When performing FMEA we consider the system under investigation
|
When performing FMEA we consider the system under investigation
|
||||||
to be a collection of components which have associated failure modes.
|
to be a collection of components which have associated failure modes.
|
||||||
%
|
%
|
||||||
@ -28,8 +49,8 @@ We apply reasoning to calculate, using the failure modes, the effects
|
|||||||
%from these failure modes (the causes, {\fms} of {\bcs}) to the effects
|
%from these failure modes (the causes, {\fms} of {\bcs}) to the effects
|
||||||
(or symptoms of failure) at the top level.
|
(or symptoms of failure) at the top level.
|
||||||
%
|
%
|
||||||
We can view FMEA as a process, taking each component in the system and for all its failure modes
|
We can view FMEA as a process, taking each component in the system and for each of its failure modes
|
||||||
applying analysis.
|
applying analysis with respect to the whole system.
|
||||||
%
|
%
|
||||||
This however entails a problem: which other components in the system must we
|
This however entails a problem: which other components in the system must we
|
||||||
check against the %current failure mode.
|
check against the %current failure mode.
|
||||||
@ -64,13 +85,16 @@ against all the components in the system.
|
|||||||
This would mean we would be looking for all possible side effects that a base component failure could cause.
|
This would mean we would be looking for all possible side effects that a base component failure could cause.
|
||||||
%
|
%
|
||||||
We could term this `rigorous~FMEA'~(RFMEA).
|
We could term this `rigorous~FMEA'~(RFMEA).
|
||||||
The number of checks we have to make to achieve this, gives an indication of the complexity of the task.
|
The number of checks we have to make to achieve this, gives an indication of the complexity of the analysis task.
|
||||||
This is described in section~\ref{sec:rd}, where the reasoning distance, or complexity to
|
%
|
||||||
analyse a single FMEA failure scenario, is given in equation~\ref{eqn:complexity}.
|
%This is described in section~\ref{sec:rd}, where the reasoning distance, or complexity to
|
||||||
|
%analyse a single FMEA failure scenario, is given in equation~\ref{eqn:complexity}.
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
We term this `comparison~complexity', the number of
|
It is desirable to be able to measure the complexity of an analysis task.
|
||||||
paths between failure modes and components necessary to achieve RFMEA for a given system/{\fg}.
|
%
|
||||||
|
We term this `comparison~complexity', count the number of
|
||||||
|
paths between failure modes and components necessary to achieve RFMEA for a given system or {\fg}.
|
||||||
|
|
||||||
% (except its self of course, that component is already considered to be in a failed state!).
|
% (except its self of course, that component is already considered to be in a failed state!).
|
||||||
%
|
%
|
||||||
|
Loading…
Reference in New Issue
Block a user