diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex
index a5186a8..72a96b5 100644
--- a/component_failure_modes_definition/component_failure_modes_definition.tex
+++ b/component_failure_modes_definition/component_failure_modes_definition.tex
@@ -15,6 +15,17 @@ for a given type of part can be obtained from standard literature\cite{mil1991}
 \cite{mech}. %The failure modes for a given component $K$ form a set $F$.
 
 
+Using these failure modes we can build a `failure model' from the bottom-up.
+Traditional static fault analysis methods work from the top down.
+They identify faults that can occur in a system, and then work down
+to see how they could be caused. Some apply statistical tequniques to
+determine the likelyhood of component failures causing specific system level errors (see Bayes theorem \ref{bayes}).
+Another top down technique is ato apply cost benifit analysis 
+to determine which faults are the highest priority to fix\cite{FMEA}.
+
+The aim of this study is to produce complete  failure
+models of safety critical systems  from the bottom-up
+starting, where possible with known component failure modes.
 
 
 \subsection{Systems, functional groups, sub-systems and failure modes}
@@ -102,13 +113,45 @@ Failure mode & of a `Failure Mode Group' \\ \hline
 Base Component & Any bought in component, which \\
                & hopefully has a known set of failure modes  \\    \hline  
  \hline
+\label{tab:def}
 \end{tabular}
 %\end{table}
 \vspace{0.3cm}
 
+\section{A UML Model of terms introduced}
+The diagram in figure \ref{fig:fmmd_uml}
+shows the relationships between the terms defined in table \ref{tab:def}.
+We can start with the functional group. This is a minimal collection
+of components that perform a simple given function.
+For our audio separates rig, this could be 
+the compoents that supply power to the laser diode.
+From the `Functional Group we can now collect
+all the `failure modes of the `components, and 
+produce a `Failure Mode Group. This
+has a reference to the `Functional Group, and is a collection
+of `failure modes.
+By analysing the effects of the failure modes in the `Failure Mode Group'
+we can determine the failure mode behaviour of the functional group.
+This failure mode behaviour is a collection of derived failure modes.
+We can now consider the Functional group as a component now, because
+we have a set of failure modes for it.
+We can term this set of failure modes a sub-system.
+
+Note that this is recursive. We can build functional groups using sub-systems
+as components. This UML model naturally therefore, forms a hierarchy
+of failure mode analysis, which has a one top level entry, that being the SYSTEM.
+The TOP level entry will determine the failure modes 
+for the product/system under analysis.
+
+
+We can refine this model a little by noticing that a system is merely the 
+top level sub-system. We can thus have System inherit sub-system.
+A derived failure mode, is simply a failure mode at a higher level of analysis
+it can therefore inherit `failure\_mode'.
+
 \begin{figure}[h]
  \centering
- \includegraphics[width=350pt,bb=0 0 680 500,keepaspectratio=true]{./fmmd_uml.jpg}
+ \includegraphics[width=350pt,bb=0 0 680 500,keepaspectratio=true]{component_failure_modes_definition/fmmd_uml.jpg}
  % fmmd_uml.jpg: 680x500 pixel, 72dpi, 23.99x17.64 cm, bb=0 0 680 500
  \caption{UML respresentation of Failure Mode Data types}
  \label{fig:fmmd_uml}
@@ -196,7 +239,7 @@ is therefore
 $$ F = \Omega(K) \backslash OK $$
 
 \subsection{Bayes Theorem}
-
+\label{bayes}
 Describe application - likely hood of faults being the cause of symptoms -
 probablistic approach - no direct causation paths to the higher~abstraction fault mode.
 Often for instance a component in a module within a module within a module etc
@@ -213,7 +256,9 @@ to
 %unitary~state set family.
 
 \subsection{Tests of Hypotheses and Significance}
-
+Linked in with Bayes theorem
+Accident analysis
+plane crashes and faults etc
 In high reliability systems the fauls are often logged - strange occurances - 
 processors resetting - what are the common factors - P values -
 for instance very high voltage spikes can reset micro controllers -