robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tidying up metrics chapter....

Browse Source
This commit is contained in:
Robin Clark 2013-01-18 21:56:33 +00:00
parent e7ce19d96c
commit eb09ccf83f
3 changed files with 48 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
submission_thesis/CH1_introduction/copy.tex
View File

@ -1,3 +1,4 @@
\label{sec:chap1}
%\paragraph{Abstract} % : The Scope of this study.}{
{

15
submission_thesis/CH3_FMEA_criticism/copy.tex
View File

@ -2,7 +2,22 @@
\section{Historical Origins of FMEA}
\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{Comparison Complexity}

40
submission_thesis/CH6_Evaluation/copy.tex
View File

@ -2,7 +2,26 @@
\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
@ -19,7 +38,9 @@
% DOMAIN == INPUTS
% 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
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
(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
applying analysis.
We can view FMEA as a process, taking each component in the system and for each of its failure modes
applying analysis with respect to the whole system.
%
This however entails a problem: which other components in the system must we
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.
%
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.
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}.
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}.
%
%
We term this `comparison~complexity', the number of
paths between failure modes and components necessary to achieve RFMEA for a given system/{\fg}.
It is desirable to be able to measure the complexity of an analysis task.
%
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!).
%