git did a merge which is always worrying

t did a fucking merge I fucking hate that#	../thesis_back_up.Tue_Feb_14_16_55_55_GMT_2012.tar.gz

mybib.bib

@@ -584,30 +584,19 @@ ISSN={1530-2059},}
 	keywords = "fault-tolerance"
 }
 
+@INPROCEEDINGS{syssafe2012,
+	author={Clark, R. and Fish, A. and Garrett, C. and Howse, J.},
+	booktitle={System Safety, incorporating the Cyber Security Conference 2012, 7th IET International Conference on}, title={Applying Failure Mode Modular De-Composition (FMMD) across the software/hardware interface},
+	year={2012},
+	pages={1-6},
+	keywords={safety-critical software;system recovery;EN298 standard;EN61508 standard;FMEA;FMMD;component failure modes;electro-mechanical-software hybrids;electronic systems;failure mode effects analysis;failure mode modular decomposition;language feature constraints;mechanical systems;nonanalytical limbo;resultant system failures;review processes;safety critical control systems;software-hardware interface;static failure mode modelling;system wide behaviour;test efficiency benefits;safetycritical;software fmea;static failure mode modelling},
+	doi={10.1049/cp.2012.1506},}
+
+
+
+
 
 
-@article{syssafe2012,
-	title = "Applying Failure Mode Modular de-composition (FMMD) across the Software/Hardware Interface",
-	journal = "7th IET International Conference on System Safety 2012",
-	volume = "",
-	number = "",
-	pages = "",
-	year = "2012",
-	note = "",
-	issn = "",
-	doi = "",
-	url = "",
-	author = "Clark, R and Fish, A and Garrett, C and Howse, J",
-	keywords = "Failsafe",
-	keywords = "Software",
-	keywords = "FMEA",
-	keywords = "FMEDA",
-	keywords = "FMECA",
-	keywords = "fault",
-	keywords = "double-fault",
-	keywords = "single-fault",
-	keywords = "fault-tolerance"
-}
 
 @ARTICLE{ontfmea,
   AUTHOR =       "Lars Dittman et all",

submission_thesis/CH2_FMEA/copy.tex

@@ -632,13 +632,13 @@ In this section we examine some fundamental concepts and underlying philosophies
 It is desirable that the failure modes for a component are mutually exclusive, were a component able
 to fail in several ways at the same time, this would complicate analysis. 
 It would mean having to consider combinations of internal component failures
-as separate failure modes. This concept is discussed in sections ~\ref{ch4:mutex} 
-and ~\ref{ch7:mutex}.
+as separate failure modes. This concept is discussed in sections~\ref{ch4:mutex} 
+and~\ref{ch7:mutex}.
 %
 In general failure modes
 for simple components   are mutually exclusive
 but large and complex components (such as integrated circuits), especially where they contain separate modules,
-could have non mutually exclusive failure modes and these need spacial handling, see section~\ref{ch3:mutex}.
+could have non mutually exclusive failure modes and these need special handling, see section~\ref{ch7:indfm}.
 
 \paragraph{The signal path.}
 

submission_thesis/CH3_FMEA_criticism/copy.tex

@@ -377,13 +377,13 @@ All these FMEA based methodologies have the following short comings:
 We now form a wish list, stating the features that we would want
 in an improved FMEA methodology,
 \begin{itemize}
-    \item Must be able to analyse {\fms} in hybrisd software/hardware systems, 
-    \item No state explosion making analysis impractical,  
-   \item  Exhaustive checking (total failure coverage within {\fgs} all interacting component and failure modes checked),
-    \item Reasoning Traceable in system models,  
-    \item Re-useable i.e. it should be possible to re-use analysis performed previously,
-    \item It must be possible to analyse simultaneous/multiple failures, 
-    \item Modular --- i.e. usable in a distributed system.
+    \item Must be able to analyse hybrid software/hardware systems, 
+    \item no state explosion (which would make analysis impractical),  
+    \item exhaustive checking at a modular level, %(total failure coverage within {\fgs} all interacting component and failure modes checked),
+    \item traceable reasoning system 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 modular --- i.e. usable in a distributed system.
   % \item  
 \end{itemize}
 

submission_thesis/CH4_FMMD/copy.tex

@@ -1326,6 +1326,7 @@ structure with its associated failure modes.
 %
 From this diagram we see that each component must have at least one failure mode.
 %
+\label{ch4:mutex}
 To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component,
 each failure mode is referenced back to only one component.
 %

submission_thesis/CH7_Evaluation/copy.tex

@@ -207,7 +207,7 @@ $i$ for identification and a superscript for  the $\alpha$~level (see section~\r
 %---
 %o identify the hierarchy. 
 For example  the first {\fg} in a hierarchy containing base components only
-i.e. at the zeroth level of an FMMD hierarchy where $\alpha=0$, would have the superscript 0 and a subscript of 1: $FG^{0}_{1}$.
+i.e. at the zero'th level of an FMMD hierarchy where $\alpha=0$, would have the superscript 0 and a subscript of 1: $FG^{0}_{1}$.
 %
 The {\fg} representing the potential divider in section~\ref{sec:pd}
 has an $\alpha$ level of 0 (as it contains base components). The {\fg}
@@ -659,6 +659,7 @@ are level shifted, adding to the complication of analysing it for failures.
 %
 \section{Unitary State Component Failure Mode Sets}
 \label{sec:unitarystate}
+%\label{ch7:mutex}
 \label{ch7:mutex}
 \paragraph{Design Decision/Constraint}
 An important factor in defining a set of failure modes is that they
@@ -1182,7 +1183,7 @@ failure modes are unitary state.
 % \end{figure}
 
 \section{Components with Independent failure modes}
-
+\label{ch7:indfm}
 Suppose that we have a component that can fail simultaneously
 with more than one failure mode.
 This would make it seemingly impossible to model as  `unitary state'.