OK morning edit. Now off to Mums to collect Pip

perhaps see Cap on the way back.

submission_thesis/CH2_FMEA/copy.tex

@@ -661,6 +661,10 @@ Perhaps we should: this would be a more rigorous and complete
 approach in looking for system failures. We could term FMEA where 
 each failure mode is compared against all other components
 as exhaustive FMEA (XFMEA).
+%
+An indicator of the potential vagueness, in terms of failure outcome,
+is manifested in the UML relationship in figure~\ref{fig:component_fm_rel_ana}
+giving a one to many mapping for a failure mode and its system level symptom.
 
 
 \section{Theoretical Concepts in FMEA}
@@ -973,6 +977,10 @@ The discussion on reasoning distance leads provides us with a metric to examine
 the state explosion problems associated with forward search failure investigation
 methodologies.
 
+It is apparent that the shorter the reasoning distance, the more precisely our theoretical examination
+is to determine failure symptoms. For instance for a very simple small circuit, we can have a better understanding
+of failure effects, than for a very large system where there are more variables and potential {\fm} interactions.
+
 %.... general concept... simple ideas about how complex a
 %failure analysis is the more modules and components are involved
 % cite for forward and backward search related to safety critical software
@@ -1185,7 +1193,7 @@ and require re-design of some systems.
 
 
 \section{FMEDA - Failure Modes Effects and Diagnostic Analysis}
-
+%
 %\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
 % \begin{figure}
 %  \centering
@@ -1193,16 +1201,7 @@ and require re-design of some systems.
 %  % SIL.jpg: 350x286 pixel, 72dpi, 12.35x10.09 cm, bb=0 0 350 286
 %  \caption{SIL requirements}
 % \end{figure}
-
-
-
-
-
-
-
-
-
-\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
+%\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
 %
 \fmmdglossFMEDA
 %

submission_thesis/CH3_FMEA_criticism/copy.tex

@@ -127,6 +127,25 @@ examined in section~\ref{sec:distributed}.
 % 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}.
 
+%% Ideal case where we can determine one to one mapping of failure modes
+%% to system level failures
+
+\subsection{FMEA one to many mapping for component failure to system level {\fms}}
+\label{sec:onetoone}
+Traditional FMEA allows for the possibility of {\bc} {\fms} causing
+more than one potential system failure mode.
+%
+This can be seen as an indicator of the lack of
+cause to effect precision possible when analysing
+large systems using FMEA.
+% 
+Ideally this relationship would be one to one.
+%
+This would be beneficial in terms of validating
+precision of analysis, and for by-products of
+the process such as developing diagnostic fault trees from
+FMEA analyses.
+
 
 \section{Reasoning Distance used to measure Comparison Complexity}
 \label{sec:reasoningdistance}
@@ -474,6 +493,7 @@ in an improved FMEA methodology,
     \item traceable reasoning inherent in system failure models,% to aid repeatability and checking,  
     \item re-usable i.e. it should be possible to re-use analysis,
     \item possibility to analyse simultaneous/multiple failures, 
+    \item one to one mapping from {\bc} {\fms} to system level failures (see section~\ref{sec:onetoone}),
     \item modular --- i.e. usable in a distributed system.
   % \item  
 \end{itemize}

submission_thesis/CH4_FMMD/copy.tex

@@ -2276,9 +2276,13 @@ by a symptom within a {\fg}, and therefore the failure modes of a {\dc} are mutu
 %
 Thus FMMD naturally produces {\dcs} with failure modes that are mutually exclusive.
 %
+This property forces the FMMD analyst to
+create failure modes models that have a one to one mapping from {\bc} {\fm}
+to system level failure, or symptom (see section~\ref{sec:onetoone}).
+%
 \fmmdglossMUTEX
 %
-This property is examined in more detail in section~\ref{ch7:mutex}.
+This property, termed a `unitary~state~failure~mode', is examined formally in section~\ref{ch7:mutex}.
 
 \paragraph{Objective and contextual/subjective failure symptoms.}
 Because the top level failure symptoms of an FMMD analysis are objective, or the result of reasoning,

submission_thesis/CH8_Conclusion/copy.tex

@@ -83,15 +83,15 @@ These benefits fall under the following assumptions and constraints:
 
 Whilst investigating FMMD a number of further areas for research revealed themselves. 
 These are presented below.
-
+%
 %\section{Conclusion}
-
+%
 % It is the authors belief that the practise of FMEA would be improved by taking a modular approach
 % and that it is necessary that software and hardware should be included in the same failure mode models.
 % %
 % The proposed methodology, FMMD, provides the means to do this, and it is the authors hope that this
 % or a variant thereof is taken up and used to improve system safety.
-
+%
 \section{Further Work}
 %This section describes areas that the study has revealed where the FMMD methodology may be extended or improved.
  \subsection{How traditional FMEA reports can be derived from an FMMD model.}
@@ -466,9 +466,9 @@ both environmental conditions and failure modes.
 \paragraph{UML Diagram Additional Objects.}
 The additional objects System, Environment, Inhibit and Operational States
 are added to  UML diagram in figure \ref{fig:cfg} are represented in figure \ref{fig:cfg2}.
-
+%
 \label{completeumlfurtherwork}
-
+%
 \begin{figure}[h]
  \centering
  \includegraphics[width=400pt,keepaspectratio=true]{./CH8_Conclusion/master_uml_further_work.png}
@@ -500,13 +500,29 @@ Because we can enforce a `complete' analysis, FMMD can find failure modes were m
 other FMEA processes; meaning that the  FMMD process can expose un-handled 
 failure modes.
 %come to light.
-
+\paragraph{Retrospective Failure Mode analysis and software}
 We can apply retrospective FMMD to electronic and software hybrid systems as well.
 %
 The electronic components {\fms} are established in the literature~\cite{fmd91,mil1991,en298,en230}.
 %
 Each function in the software would have to be assigned a `design~contract'~\cite{dbcbe} (where violations of
 contract clauses will be treated as failure modes in FMMD).
+
+\paragraph{Effect of newly discovered failure modes in components.}
+Using traditional FMEA when discovering a new failure mode in a component or
+sub-system it could be difficult to know
+which parts of the FMEA analysis to
+re-visit. For instance, which components in the system should 
+we check against this newly discovered failure mode?
+%
+This is linked to the concepts behind
+the need for failure mode coverage against all components in the system, that provoked discussions
+leading to idealised XFMEA requirements (see section~\ref{sec:reasoningdistance}).
+\fmmdglossSFMEA
+%
+Using FMMD only those modules in the hierarchy above the 
+component with the new failure mode need be re-visited.
+This means that with FMMD the re-work task can be precisely defined.
 %
 % By %doing 
 % applying contracts and seeing how calling functions deal with