diff --git a/submission_thesis/CH1_introduction/copy.tex b/submission_thesis/CH1_introduction/copy.tex index 167d0c0..e7d5ba2 100644 --- a/submission_thesis/CH1_introduction/copy.tex +++ b/submission_thesis/CH1_introduction/copy.tex @@ -1,3 +1,4 @@ +\label{sec:chap1} %\paragraph{Abstract} % : The Scope of this study.}{ { diff --git a/submission_thesis/CH3_FMEA_criticism/copy.tex b/submission_thesis/CH3_FMEA_criticism/copy.tex index c56565e..885180b 100644 --- a/submission_thesis/CH3_FMEA_criticism/copy.tex +++ b/submission_thesis/CH3_FMEA_criticism/copy.tex @@ -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} diff --git a/submission_thesis/CH6_Evaluation/copy.tex b/submission_thesis/CH6_Evaluation/copy.tex index fb91984..dd85dd0 100644 --- a/submission_thesis/CH6_Evaluation/copy.tex +++ b/submission_thesis/CH6_Evaluation/copy.tex @@ -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!). %