diff --git a/opamp_circuits_C_GARRETT/Makefile b/opamp_circuits_C_GARRETT/Makefile
index b7b1f86..922bb51 100644
--- a/opamp_circuits_C_GARRETT/Makefile
+++ b/opamp_circuits_C_GARRETT/Makefile
@@ -1,6 +1,6 @@
 
 
-PNG_DIA = circuit1_dag.png mvampcircuit.png pd.png invamp.png shared_component.png tree_abstraction_levels.png three_tree.png blockdiagramcircuit2.png circuit2h.png bubba_oscillator_block_diagram.png
+PNG_DIA = circuit1_dag.png mvampcircuit.png pd.png invamp.png shared_component.png tree_abstraction_levels.png three_tree.png blockdiagramcircuit2.png circuit2h.png bubba_oscillator_block_diagram.png dubsim1.png
 
 
 
diff --git a/opamp_circuits_C_GARRETT/dubsim1.dia b/opamp_circuits_C_GARRETT/dubsim1.dia
new file mode 100644
index 0000000..20163df
Binary files /dev/null and b/opamp_circuits_C_GARRETT/dubsim1.dia differ
diff --git a/opamp_circuits_C_GARRETT/opamps.tex b/opamp_circuits_C_GARRETT/opamps.tex
index 1c618e9..cfc2d87 100644
--- a/opamp_circuits_C_GARRETT/opamps.tex
+++ b/opamp_circuits_C_GARRETT/opamps.tex
@@ -1382,6 +1382,107 @@ $$
 % \subsection{Exponential squared to Exponential}
 % 
 % can I say that ?
+
+
+
+\section{Double Simultaneous Failures}
+
+The probability for independent double simultaneous component failures (because we would multiply the probabilities of failure) is very low.
+However, some critical systems have to consider these type of eventualities.
+The burner control industry has to consider these, and these are written into the 
+the gas burner standard EN298~\cite{en298}. EN298 does not specifically state that
+double simultaneous failures must be considered. What it does say is that
+in the event of a lockout -- a condition where an error has been detected and 
+the equipment moves to a safe non-functioning state -- no secondary failure may cause a dangerous condition.
+This is slightly vague: there are so many possible component failures that could
+cause a secondary failure, that it is very difficult not to interpret this
+as meaning we have to cater for double simultaneous failures for the most critical sections
+of a system. In practise -- in the field of EN298: burner controllers --  this means triple safeguards to ensure the fuel
+is not allowed to flow under an error condition. This would of course leave the possibility of
+other more complex double failures tricking the controller into thinking the 
+combustion was actually safe when it was not.
+
+It has been shown that, for all but trivial small systems, double failure mode checking
+is impossible from a practical perspective.
+FMMD can reduce the number of checks to make to achieve double simultaneous failure checking -- but by the very nature 
+of choosing {\fgs} we will not (in the initial stages) be cross checking all possible
+combinations of double failures in all the components.
+
+The diagram in figure~\ref{fig:dubsim1}, uses Euler diagrams to model failure modes (as closed contours) and asterisks 
+to model failure mode scenarios. The failure scenario is defined by the contours that enclose it.
+Consider a system which has four components $c_1 \ldots c_4$.
+Consider that each of these components may fail in two ways: $a$ and $b$, i.e $fm(c_1) = fm(c_2) = \{a,b\}$.
+Now consider two {\fgs}, $fg1 = \{ c_1, c_2 \}$ and $fg2 = \{ c_3, c_4 \}$.
+
+We list all the possible failure scenarios as $FS1 \ldots FS6$ for each functional group.
+For instance $FS5$ is the result of component $c_2$ failing with failure mode $a$ and component $c_1$ failing
+with failure mode $b$. We can express this as $c_2 a \cup c_1 b$.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=300pt,keepaspectratio=true]{./dubsim1.png}
+ % dubsim1.png: 612x330 pixel, 72dpi, 21.59x11.64 cm, bb=0 0 612 330
+ \caption{Simultaneous Failure Mode Scenarios}
+ \label{fig:dubsim1}
+\end{figure}
+
+
+
+From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined.
+How do we model the double failures that occur across the {\fgs}, for instance
+$c_4 a \cup c_1 a$.
+It could be argued that because functional groups are chosen for their functionality, and re-usability
+that component failures in one should not affect a different {\fg}, but this is a weak argument.
+Merely double checking within {\fgs} would be marginally better than
+only applying it to the most obvious critical elements of a system.
+
+What is really required is a way that all double simultaneous failures
+are checked.
+
+One way of doing this is to apply double failure mode
+checking to all {\fgs} higher up in the hierarchy.
+
+This guarantees to check the symptoms caused by the 
+failure modes in the other {\fgs} with the symptoms
+derived from the other {\fgs} modelling for double failures.
+This guarantees
+double failure move coverage.
+
+To extend the example in figure~\ref{fig:dubsim1} we can map the failure 
+scenarios.
+For Functional Group 1 (FG1), let us map:
+\begin{eqnarray*}
+  FS1 & \mapsto & S1   \\
+  FS2 & \mapsto & S3    \\
+   FS3 & \mapsto & S1     \\
+  FS4 & \mapsto & S2     \\
+  FS5 & \mapsto & S2     \\
+  FS6 & \mapsto & S3    
+\end{eqnarray*}
+
+Thus a derived component, DC1, has the failure modes defined by $fm(DC1) = \{ S1, S2, S3 \}$.
+
+
+For Functional Group 2 (FG2), let us map:
+\begin{eqnarray*}
+  FS1 & \mapsto & S4   \\
+  FS2 & \mapsto & S5    \\
+   FS3 & \mapsto & S5     \\
+  FS4 & \mapsto & S4     \\
+  FS5 & \mapsto & S6     \\
+  FS6 & \mapsto & S5    
+\end{eqnarray*}
+
+This 
+% does not cover what weird side effect may occur though, but then the {\fg} was not modelled correctly in the first place...
+
+
+
+
+
+
+
 \bibliographystyle{plain}
 \bibliography{../vmgbibliography,../mybib}